Re: HVM virtualization?

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Nov 1, 10:40, Greg Troxel wrote:
} Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
} > On Sat, Oct 31, 2020 at 06:36:45PM -0400, Greg Troxel wrote:
} >> Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
} >> > On Sat, Oct 31, 2020 at 01:37:17PM -0500, Jeremy C. Reed wrote:
} >> >> One of my hosting providers is converting VPSes from PV to HVM=20
} >> >> virtualization due to security issue
} >> >> https://xenbits.xen.org/xsa/advisory-286.html
} >> >> 
} >> >> They say NetBSD does not work under HVM mode and can choose a different
} >> >> BSD (or Linux).
} >> >> 
} >> >> Can someone tell me about this? I did look briefly at=20
} >> >> http://wiki.netbsd.org/ports/xen/howto/ but don't understand the context
} >> >> of the wiki saying it is supported but the hosting provider saying it
} >> >> does not work.
} >> >
} >> > plain HVM, with emulated devices, works without problems (and always has).
} >> > If they only support PV devices, then it works only in HEAD (GENERIC supports
} >> > it)
} >>
} >> 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.

} I realize that's a good workaround, but I also wonder if anyone else has
} tried 9-stable GENERIC as HVM with a dom0 that is using stub domains for
} qemu.

     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.

} (It seems obvious that NetBSD dom0s do not use stub domains.)

     No they do not, but that is neither here nor there.  The last
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.

     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.

     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.  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.

}-- End of excerpt from Greg Troxel