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, "Corvin Köhne" <c.koehne@beckhoff.com>
Subject: Re: [PATCH] vfio/igd: Check host PCI address when probing
Date: Wed, 16 Apr 2025 11:57:02 -0600	[thread overview]
Message-ID: <20250416115702.41b2dc4e.alex.williamson@redhat.com> (raw)
In-Reply-To: <0ec0fa57-1e99-4e21-b0c5-991806f4bd6d@gmail.com>

On Thu, 17 Apr 2025 01:41:22 +0800
Tomita Moeko <tomitamoeko@gmail.com> wrote:

> On 4/17/25 00:10, Alex Williamson wrote:
> > On Wed, 16 Apr 2025 23:45:08 +0800
> > Tomita Moeko <tomitamoeko@gmail.com> wrote:
> >   
> >> On 4/16/25 03:04, Alex Williamson wrote:  
> >>> On Wed, 16 Apr 2025 01:36:15 +0800
> >>> Tomita Moeko <tomitamoeko@gmail.com> wrote:    
> >>>>
> >>>> The generation register also exists on discrete GPUs. In the new xe
> >>>> driver [1], the Battlemage discrete GPU shares the same logic reading
> >>>> GMD_ID_DISPLAY register. The driver itself uses is_dgfx bit mapped to
> >>>> device id. In QEMU, we need to know whether the device is a supported
> >>>> IGD device first before applying the IGD-specific quirk, especially
> >>>> for legacy mode.
> >>>>
> >>>> The most feasible way is to check if kernel exposes VFIO_REGION_SUBTYPE_
> >>>> INTEL_IGD_OPREGION on that device I think, as only IGD has OpRegion.
> >>>>
> >>>> i915 driver [2] and Arrow Lake datasheet [3] shows that Intel has
> >>>> removed the BDSM register by making the DSM range part of BAR2 since
> >>>> Meteor Lake and onwards. QEMU only need to quirk on the register for
> >>>> IGD devices until Raptor Lake, meaning that the device list is fixed
> >>>> for now.
> >>>>
> >>>> By the way, for legacy mode, I think we should only support it until
> >>>> Gen 9, as Intel only provide VBIOS or CSM support until that generation,
> >>>> and seabios cannot handle 64 bit BDSM register. I'm also wondering if
> >>>> VGA really works on newer generations.    
> >>>
> >>> If it's a VGA class device, it really should, but without CSM I could
> >>> see why you have doubts.    
> >>
> >> Without CSM/VBIOS there is no pre-boot video, but when it booted to OS,
> >> driver is used for video rather than VGA. Though it claims itself as
> >> VGA class, it does not have VGA compatiblity. A770 even does not have
> >> IO BAR, definitely it cannot handle VGA decoding.  
> > 
> > VGA ranges are implicit in a VGA class device, they're not backed by
> > BARs.  Lack of CSM support makes it more difficult to prove whether VGA
> > support is present since we can't easily initialize the device for a
> > legacy OS, but I don't think lack of CSM necessary proves the hardware
> > doesn't support VGA.  If we really cared, we could probably do some low
> > level experiments writing into the VGA frame buffer range to test if
> > it's present and behaves as expected relative to memory and IO enable
> > bits.  
> 
> Sorry for my misunderstanding. The bridge control register in PCI bridge
> config space determines forwarding VGA IO/MMIO accesses to which device,
> BAR is not related in this process.
> 
> As device initialization (by legacy VBIOS) is required for booting
> legacy OS with seabios, limiting legacy mode to gen9 and older sounds
> resonable.
> 
> Trying VGA framebuffer would be difficult we have to disable EFI GOP and
> manually instruct the device to enter VGA mode without VBIOS routines.
> It's not a major problem here, let's skip it for now?

This is only a curiosity as far as I'm concerned, I agree with your
proposal that we can drop legacy mode where the bare metal system
doesn't even support CSM.  Thanks,

Alex



  reply	other threads:[~2025-04-16 17:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-25 17:22 [PATCH] vfio/igd: Check host PCI address when probing Tomita Moeko
2025-04-09 17:18 ` Alex Williamson
2025-04-10  7:34   ` Cédric Le Goater
2025-04-13 17:23     ` Tomita Moeko
2025-04-14 22:05       ` Alex Williamson
2025-04-15 17:36         ` Tomita Moeko
2025-04-15 19:04           ` Alex Williamson
2025-04-16 15:45             ` Tomita Moeko
2025-04-16 16:10               ` Alex Williamson
2025-04-16 17:41                 ` Tomita Moeko
2025-04-16 17:57                   ` Alex Williamson [this message]
2025-04-13 11:30   ` Tomita Moeko
2025-04-14 21:51     ` Alex Williamson

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=20250416115702.41b2dc4e.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).