Re: [PATCH 1/2] conf: Introduce mshv hypervisor type

On Wed, Jan 31, 2024 at 12:49:50PM -0800, Praveen Paladugu wrote: > > Am I right in thinking that "Microsoft Hypervisor" in this context is > > simply Hyper-V, aka, the same hypervisor you traditionally have under > > a Windows Dom0 ? > > > > If so then I could think that we probably don't need to have a new > > virDomainVirt type enum entry. We could simply use the pre-existing > > VIR_DOMAIN_VIRT_HYPERV to represent this configuration in the > > cloud-hypervisor configuration. > > > > I considered reusing VIR_DOMAIN_VIRT_HYPERV entry. From what I > understand, this hypervisor option implies Libvirt talks to HyperV using > WMI. Although the binary bits of the hypervisors may be the same in both > configurations, the interfaces to interact with the hypervisors are > completely different. In the context of libvirt XML config, the virDomainVirt enum is very specifically referring to the underlying hypervisor guest ABI. This is distinct from any protocol used for the management of the platform by libvirt. This is why both the CloudHypervisor and QEMU drivers in libvirt will both support the VIR_DOMAIN_VIRT_KVM for guests, despite being completely different mgmt APIs. Similarly in the past we have have multiple drivers all use VIR_DOMAIN_VIRT_XEN for the guest, while using completely different mgmt APIs. So if "mshv" in the context of CloudHypervisor is running HyperV under Dom0 and the guest primarily needs to support the HyperV ABI, then I would say VIR_DOMAIN_VIRT_HYPERV could be the appropriate choice. > 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.