qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
Subject: Re: [PATCH 00/10] vfio/igd: Remove legacy mode
Date: Thu, 27 Feb 2025 14:55:38 -0700	[thread overview]
Message-ID: <20250227145538.4735420c.alex.williamson@redhat.com> (raw)
In-Reply-To: <20250224182927.31519-1-tomitamoeko@gmail.com>

On Tue, 25 Feb 2025 02:29:17 +0800
Tomita Moeko <tomitamoeko@gmail.com> wrote:

> This patchset removes some legacy checks and converts the legacy mode
> implicitly enabled by BDF 00:02.0 into x-igd-* options, including:
> * Removing PCI ROM BAR and VGA IO/MMIO range check before applying quirk
> * Using unified x-igd-opregion option for OpRegion access.
> * Introducing new x-igd-lpc option for the LPC bridge / Host bridge ID
>   quirk. Currently this is only supported on i440fx.
> * Extending quirk support when IGD is not assigned to BDF 00:02.0
> 
> The first 2 patches of this patchset was taken from a previous one,
> details can be found at:
> https://lore.kernel.org/all/20250124191245.12464-1-tomitamoeko@gmail.com/
> 
> This patchest was mainly tested on Alder Lake UHD770, with Debian 12
> (kernel 6.1), Windows 11 (driver 32.0.101.6458) and Intel GOP driver
> 17.0.1081.
> 
> If the design is good to go, I will update the documentation also.
> 
> A open question is whether the old legacy mode behavior should be kept
> or not. Checking if all the condition of legacy mode were met and
> toggling correspoding options is more complicated then I expected :(
> Any ideas would be appreciated.

I dusted off a working IGD assignment configuration on an i7-7700 Kaby
Lake system with HD630 graphics.  This series breaks it a couple times.

First, while the host system itself may support UEFI (some systems may
not), I had dumped the VGA ROM in CSM mode and run the VM with SeaBIOS.
Therefore it needs VGA support.  This is the recommended configuration
for legacy mode in our current documentation.  Patch 4/ requires that I
add x-vga to continue using this VM.

Then of course since this VM is specifically using legacy mode, patch
10/ requires that I also add both x-igd-opregion and x-igd-lpc.

Therefore I go from a VM that works with IGD assignment in legacy mode,
with no unsupported options:

<domain type="kvm">
    ...
    <type arch="x86_64" machine="pc-i440fx-10.0">hvm</type>
    ...
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
      </source>
      <rom file="/var/lib/libvirt/images/igd-i7-7700.rom"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
    </hostdev>

To one that requires multiple unsupported, experimental options:

<domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm">
    ...
    <type arch="x86_64" machine="pc-i440fx-10.0">hvm</type>
    ...
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
      </source>
      <alias name="ua-igd"/>
      <rom file="/var/lib/libvirt/images/igd-i7-7700.rom"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
    </hostdev>
  ...
  <qemu:override>
    <qemu:device alias="ua-igd">
      <qemu:frontend>
        <qemu:property name="x-vga" type="bool" value="true"/>
        <qemu:property name="x-igd-opregion" type="bool" value="true"/>
        <qemu:property name="x-igd-lpc" type="bool" value="true"/>
      </qemu:frontend>
    </qemu:device>
  </qemu:override>

I don't know how we justify this within our defacto support contract
with users.  Legacy mode needs to continue to exist and be
automatically enabled unless we want to figure out a deprecation
process for it and queue this sort of change for sometime in the
future.  Thanks,

Alex



      parent reply	other threads:[~2025-02-27 21:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-24 18:29 [PATCH 00/10] vfio/igd: Remove legacy mode Tomita Moeko
2025-02-24 18:29 ` [PATCH 01/10] vfio/igd: Remove GTT write quirk in IO BAR 4 Tomita Moeko
2025-02-24 18:29 ` [PATCH 02/10] vfio/igd: Do not include GTT stolen size in etc/igd-bdsm-size Tomita Moeko
2025-02-24 18:29 ` [PATCH 03/10] vfio/igd: Remove rombar check for legacy mode Tomita Moeko
2025-02-24 18:29 ` [PATCH 04/10] vfio/igd: Remove implicit VGA access enabled by " Tomita Moeko
2025-02-24 18:29 ` [PATCH 05/10] vfio/pci: Make vfio_populate_vga static Tomita Moeko
2025-02-24 18:29 ` [PATCH 06/10] vfio/igd: Consolidate OpRegion initialization into a single function Tomita Moeko
2025-02-24 18:29 ` [PATCH 07/10] vfio/igd: Move LPC bridge initialization to a separate function Tomita Moeko
2025-02-24 18:29 ` [PATCH 08/10] vfio/pci: Add placeholder for device-specific config space quirks Tomita Moeko
2025-02-24 18:29 ` [PATCH 09/10] vfio/igd: Refactor vfio_probe_igd_bar4_quirk into pci config quirk Tomita Moeko
2025-02-24 18:29 ` [PATCH 10/10] vfio/igd: Replace legacy mode with options Tomita Moeko
2025-02-27  8:28 ` [PATCH 00/10] vfio/igd: Remove legacy mode Cédric Le Goater
2025-02-27 16:03   ` Tomita Moeko
2025-02-27 21:55 ` Alex Williamson [this message]

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=20250227145538.4735420c.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.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).