On Mon, Feb 05, 2024 at 08:12:15AM -0800, Praveen Paladugu wrote: > On Wed, Jan 31, 2024 at 08:57:04PM +0000, Daniel P. Berrang?? wrote: > > > With the introduced "mshv" hypervisor option, Libvirt doesn't interact > > > with "/dev/mshv" at all. Libvirt just invokes cloud-hypervisor which in > > > turn talks to mshv via kernel ioctls as necessary. > > > > That's OK. The distinction of control/mgmt API is represented > > by the different libvirt virConnect URI schemes. virDomainVirt > > is exclusively about what primary hypervisor guest ABI is exposed. > > > > Thanks for the explanation, Daniel. > By "underlying hypervisor guest ABI" I am guessing you are referring to > the interfaces used for starting and managing guests. If so, the ABIs available > in Hyperv(VIR_DOMAIN_VIRT_HYPERV) and "mshv" configurations are completely > different too. This is because the underlying Operating systems: Windows and > Linux respectively, provide different interfaces for programs to start and > manage guests. So, I'd say the hypervisor guest ABIs are different in > these 2 configurations. By 'hypervisor guest ABI' I'm referring to the general virtualization ABI that the hypervisor exposes to guest OS. ie the functionality that a Linux guest enables with CONFIG_HYPERV, or with CONFIG_KVM Kconfig build options. IIUC, there is no new CONFIG_MSHV in Linux guests, and they would be expected to be built with CONFIG_HYPERV enabled, or am I wrong in that respect ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
