John Nemeth <jnemeth%cue.bc.ca@localhost> writes: > } >> I have heard that the issue with with qemu "stub domains" and with > } >> those, NetBSD ends up with PIO on disks and is thus unusably slow. > } >> > } >> https://wiki.xen.org/wiki/QEMU_vs_qemu-traditionnal_Feature_Comparison > } > > } > So running a HEAD GENERIC, which has the PV drivers, would solve this. > } > } It would work around it, not solve it, but yes getting to a functional > } state is really the goal. > > I would argue that it solves it. It solves the "how to you run a VPS" issue. It does not solve the With a Linux dom0 wtih stub domains running as HVM, and netbsd-9, NetBSD ends up using PIO and is unusably slow problem. (It may make it such that nobody would want to solve that problem.) > Note that HVM (without qualifiers) is full hardware emulation > and thus should be capable of running any OS without modification. > If the hypervisor isn't providing full hardware emulation then it > either isn't HVM or it is broken. This is not a NetBSD fault. That is making a lot of assumptions about the fine points. There aren't really formal specs for hardware, and it's entirely possible that the emulation would be considered good but somehow NetBSD code objects to something and won't enable DMA. Until we understand the details it's hard to say exactly what's wrong and assign fault. We certainly have had cases where our code is basically fine but doesn't quite work on some new slightly unusual hardware, and then we tweak something or add a quirk, etc.. This smells like that kind of thing. > } (It seems obvious that NetBSD dom0s do not use stub domains.) > > No they do not, but that is neither here nor there. The last I think it's quite relevant, because it means that people who run a NetBSD dom0 and then run NetBSD 9 in HVM find that it works. Therefore nobody has figured out why netbsd-hvm on linux-dom0-stub has trouble. > time I asked a Xen developer about stub domains, I was told that > the code is tightely tied to Linux, and isn't portable. I find > Xen's infatuation with Linux to be rather interesting since the > Linux seems to be hooked on KVM and isn't that interested in Xen > (there is/was interest amongst the large cloud providers, but that > seems to be changing). FreeBSD has bHyve. As far as I can tell, > NetBSD is one of the largest users of Xen, but unfortunately is > behind on modern Xen support. No arguments there... > For reference, stub domains are an intermediary between dom0 > and domU. They are not strictly needed, but likely offer security > enhancement. The issue with emulating hardware in dom0 means that > a security bug in the emulator exposes the entire box. But, if > you put the hardware emulation in a stub domain, then only that > stub domain is exposed. Yes, it seems to be about isolating qemu because it's too much code to trust. > It would appear that what is happening in this case is that > the VPS is using stub domains and that stub domains don't do full > hardware emulation. I don't see that this hypothesis is supported by any evidence, compared to some tiny interaction betwween netbsd and stub/qemu that leads to not enabling DMA. If you can explain why you think that, please do. > Running a newer version of NetBSD that can do > PVHVM means that the disk and network drivers talk to the hypervisor > to exchange buffers with data instead of performing I/O operations > which have to be emulated. Agreed completely. However, there is today no released version that does that, and current has recently had filesystem corruption issues. I realize nobody may want to spend time understanding what happens in 9, but it still would be good to resolve it.
Attachment:
signature.asc
Description: PGP signature