On Tue, 17 Jun 2025 08:56:41 +0800 Tomita Moeko <tomitamo...@gmail.com> wrote:
> On 2025/5/29 18:41, Tomita Moeko wrote: > > On 2025/5/29 2:30, Alex Williamson wrote: > >> On Wed, 28 May 2025 23:55:48 +0800 > >> Tomita Moeko <tomitamo...@gmail.com> wrote: > >> > >>> Introduce x-pci-class-code option to allow users to override PCI class > >>> code of a device, similar to the existing x-pci-vendor-id option. Only > >>> the lower 24 bits of this option are used, though a uint32 is used here > >>> for determining whether the value is valid and set by user. > >>> > >>> Additionally, to prevent exposing VGA ranges on non-VGA devices, the > >>> x-vga=on option requires x-pci-class-code is either unset or set to > >>> VGA controller class. > >>> > >>> This is mainly intended for IGD devices that expose themselves either > >>> as VGA controller (primary display) or Display controller (non-primary > >>> display). The UEFI GOP driver depends on the device reporting a VGA > >>> controller class code (0x030000). > >>> > >>> Signed-off-by: Tomita Moeko <tomitamo...@gmail.com> > >>> --- > >>> v2: > >>> * Add vdev class code check in vfio_populate_vga(). > >>> * Fix type in trace-events. > >>> Link: > >>> https://lore.kernel.org/all/20250524153102.19747-1-tomitamo...@gmail.com/ > >>> > >>> hw/vfio/pci.c | 25 +++++++++++++++++++++++++ > >>> hw/vfio/pci.h | 1 + > >>> hw/vfio/trace-events | 1 + > >>> 3 files changed, 27 insertions(+) > >>> > >>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c > >>> index b1250d85bf..d57cb7356e 100644 > >>> --- a/hw/vfio/pci.c > >>> +++ b/hw/vfio/pci.c > >>> @@ -2726,6 +2726,14 @@ bool vfio_populate_vga(VFIOPCIDevice *vdev, Error > >>> **errp) > >>> return false; > >>> } > >>> > >>> + /* vdev class should be either unmodified (PCI_ANY_ID), or VGA > >>> controller */ > >>> + if ((vdev->class_code != PCI_ANY_ID) && > >>> + (vdev->class_code != (PCI_CLASS_DISPLAY_VGA << 8)) && > >>> + (vdev->class_code != (PCI_CLASS_NOT_DEFINED_VGA << 8))) { > >>> + error_setg(errp, "vdev is not a VGA device"); > >>> + return false; > >>> + } > >> > >> I think we should follow the scheme used for vendor_id and device_id to > >> populate the struct field when not specified. That let's us use it > >> more easily and consistently for things like this. > > > > Hi, Alex > > > > The class code override takes place in vfio_pci_config_setup(), where > > is after vfio_populate_vga() is called in vfio_populate_device(). So > > I have to check if it equals to default or VGA class code here, and > > not initializing the sturct field with device value. If we decide to > > initialize it for other purpose, I personally think we should also > > save the subvendor/subdevice value as well. > > It have been several weeks, wondering if there is further comments. Hi Moeko, Thank you for your patience. I'm still a little confused how this works. AIUI you have an GPU reported as a display controller, but you want to change the class code to VGA, despite there being no VGA region provided by vfio, right? So the GOP driver only depends on the legacy VGA class code and not the VGA regions. vfio_populate_vga() initializes the vfio VGA region and calls pci_register_vga(). Therefore with the ability to modify the class code we only want to register the device as VGA if the class code is unmodified, where the VGA vfio regions will only exist if the device is VGA, or if the class override is VGA, where the VGA vfio regions again only exist if the device is actually VGA and therefore the override is a no-op. But we only get to vfio_populate_vga() if the user specifies x-vga=on. So I think we're really just trying to prevent a physical VGA device overridden as a non-VGA class code, but still specified with x-vga=on, from calling pci_register_vga(), right? What if we just separate pci_register_vga() out of vfio_populate_vga()? Then we can continue the semantics of making class_code valid regardless of whether it's been specified and around the point where we call vfio_bars_register() we can also call pci_register_vga() if and only if the class code is VGA and vdev->vga is configured. Does that make sense? Thanks, Alex
