From: Alex Williamson <alex.williamson@redhat.com>
To: Tomita Moeko <tomitamoeko@gmail.com>
Cc: "Cédric Le Goater" <clg@redhat.com>,
qemu-devel@nongnu.org, "Corvin Köhne" <c.koehne@beckhoff.com>
Subject: Re: [PATCH 03/11] vfio/igd: Detect IGD device by OpRegion
Date: Thu, 24 Apr 2025 16:57:20 -0600 [thread overview]
Message-ID: <20250424165720.6265e113.alex.williamson@redhat.com> (raw)
In-Reply-To: <20250421163112.21316-4-tomitamoeko@gmail.com>
On Tue, 22 Apr 2025 00:31:03 +0800
Tomita Moeko <tomitamoeko@gmail.com> wrote:
> There is currently no straightforward way to distinguish if a Intel
> graphics device is IGD or discrete GPU. However, only IGD devices expose
> OpRegion. Use the presence of VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION
> to identify IGD devices.
>
> Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com>
> ---
> hw/vfio/igd.c | 26 ++++++++++++++++++--------
> 1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c
> index 36316e50ea..7a7c7735c1 100644
> --- a/hw/vfio/igd.c
> +++ b/hw/vfio/igd.c
> @@ -479,6 +479,7 @@ void vfio_probe_igd_bar0_quirk(VFIOPCIDevice *vdev, int nr)
>
> static bool vfio_pci_igd_config_quirk(VFIOPCIDevice *vdev, Error **errp)
> {
> + g_autofree struct vfio_region_info *opregion = NULL;
> int ret, gen;
> uint64_t gms_size;
> uint64_t *bdsm_size;
> @@ -486,16 +487,20 @@ static bool vfio_pci_igd_config_quirk(VFIOPCIDevice *vdev, Error **errp)
> bool legacy_mode_enabled = false;
> Error *err = NULL;
>
> - /*
> - * This must be an Intel VGA device at address 00:02.0 for us to even
> - * consider enabling legacy mode. The vBIOS has dependencies on the
> - * PCI bus address.
> - */
> if (!vfio_pci_is(vdev, PCI_VENDOR_ID_INTEL, PCI_ANY_ID) ||
> !vfio_is_vga(vdev)) {
> return true;
> }
>
> + /* IGD device always comes with OpRegion */
> + ret = vfio_device_get_region_info_type(&vdev->vbasedev,
> + VFIO_REGION_TYPE_PCI_VENDOR_TYPE | PCI_VENDOR_ID_INTEL,
> + VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION, &opregion);
> + if (ret) {
> + return true;
> + }
> + info_report("OpRegion detected on Intel display %x.", vdev->device_id);
> +
> /*
> * IGD is not a standard, they like to change their specs often. We
> * only attempt to support back to SandBridge and we hope that newer
> @@ -570,9 +575,14 @@ static bool vfio_pci_igd_config_quirk(VFIOPCIDevice *vdev, Error **errp)
> }
>
> /* Setup OpRegion access */
> - if ((vdev->features & VFIO_FEATURE_ENABLE_IGD_OPREGION) &&
> - !vfio_pci_igd_setup_opregion(vdev, errp)) {
> - goto error;
> + if ((vdev->features & VFIO_FEATURE_ENABLE_IGD_OPREGION)) {
> + if (vdev->pdev.qdev.hotplugged) {
> + error_setg(errp, "OpRegion is not supported on hotplugged device");
> + goto error;
> + }
> + if (!vfio_pci_igd_opregion_init(vdev, opregion, errp)) {
> + goto error;
> + }
> }
>
> /* Setup LPC bridge / Host bridge PCI IDs */
I think this still needs some refactoring work. The setup function
currently does:
a) test hotplugged
b) get opregion
c) call init
We implemented b) above and therefore do a) and c) here, duplicating
them from the setup function. It would be valid to test a) as we're
getting the opregion, so wouldn't it make sense to turn setup into a
function that does a) and b), returning an opregion, called by both
this path and GVT-g path, and each would call the init function
themselves? The latter is already implemented in the next patch, but
a) and b) are still duplicated in GVT-g specific code. Thanks,
Alex
next prev parent reply other threads:[~2025-04-24 22:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 16:31 [PATCH 00/11] vfio/igd: Detect IGD by OpRegion and enable OpRegion automatically Tomita Moeko
2025-04-21 16:31 ` [PATCH 01/11] vfio/igd: Restrict legacy mode to Gen6-9 devices Tomita Moeko
2025-04-24 22:57 ` Alex Williamson
2025-04-21 16:31 ` [PATCH 02/11] vfio/igd: Always emulate ASLS (OpRegion) register Tomita Moeko
2025-04-21 16:31 ` [PATCH 03/11] vfio/igd: Detect IGD device by OpRegion Tomita Moeko
2025-04-23 6:54 ` Corvin Köhne
2025-04-28 15:23 ` Tomita Moeko
2025-04-24 22:57 ` Alex Williamson [this message]
2025-04-21 16:31 ` [PATCH 04/11] vfio/igd: Remove vfio_pci_igd_setup_opregion Tomita Moeko
2025-04-21 16:31 ` [PATCH 05/11] vfio/igd: Check vendor and device ID on GVT-g mdev Tomita Moeko
2025-04-21 16:31 ` [PATCH 06/11] vfio/igd: Enable OpRegion by default Tomita Moeko
2025-04-21 16:31 ` [PATCH 07/11] vfio/igd: Allow hotplugging with OpRegion enabled Tomita Moeko
2025-04-24 22:57 ` Alex Williamson
2025-04-28 15:18 ` Tomita Moeko
2025-04-21 16:31 ` [PATCH 08/11] vfio/igd: Allow overriding GMS with 0xf0 to 0xfe on Gen9+ Tomita Moeko
2025-04-23 7:13 ` Corvin Köhne
2025-04-21 16:31 ` [PATCH 09/11] vfio/igd: Only emulate GGC register when x-igd-gms is set Tomita Moeko
2025-04-21 16:31 ` [PATCH 10/11] vfio/igd: Remove generation limitation for IGD passthrough Tomita Moeko
2025-04-23 7:19 ` Corvin Köhne
2025-04-21 16:31 ` [PATCH 11/11] vfio/igd: Update IGD passthrough documentation Tomita Moeko
2025-04-23 7:21 ` Corvin Köhne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250424165720.6265e113.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=c.koehne@beckhoff.com \
--cc=clg@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tomitamoeko@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).