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