On 4/3/25 20:08, John Levon wrote:
On Thu, Apr 03, 2025 at 07:13:30PM +0200, Cédric Le Goater wrote:
On 2/19/25 15:48, John Levon wrote:
From: Jagannathan Raman <[email protected]>
Split out code specific to the kernel-side vfio implementation from the
VFIOPCIDevice class into a VFIOKernelPCIDevice. The forthcoming
VFIOUserPCIDevice will share the base VFIOPCIDevice class.
The new VFIOKernelPCIDevice struct is not needed. Please drop it.
I presume the idea was if something was ever needed in the struct that was
kernel vfio specific, it could go there. But sure.
>> I am not sure the new TYPE_VFIO_PCI_BASE class is needed too.
Are the properties the only difference ?
I'm not sure if you're talking about the type specifically (a bit sketchy on how
qemu's klass/type system works) or the existence of the base/kernel/user
separation at all.
I am talking about the base/kernel/user separation.
If it's possible to set up vfio_user_pci_dev_info and its callbacks without
needing a sub-type then maybe not?
I think the vfio-user-device could inherit directly from vfio-pci
and override the io ops callbacks. It would minimize the changes.
Honestly I'm not really sure why we have sub-classes and inheritance like this.
The VFIO Devices have a double nature : VFIO and a bus device
nature (PCI, AP, etc) and multi-inheritance is not (well)
supported by QOM. We have interfaces but they are stateless.
Thanks,
C.
