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