qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] driver enhancement for Intel IGD passthrough


From: Tian, Kevin
Subject: Re: [Qemu-devel] driver enhancement for Intel IGD passthrough
Date: Mon, 4 May 2015 08:08:51 +0000

> From: Alex Williamson [mailto:address@hidden
> Sent: Tuesday, April 21, 2015 2:13 AM
> On Thu, 2015-04-16 at 17:24 +0000, Tian, Kevin wrote:
> > ping...
> >
> > > From: Tian, Kevin
> > > Sent: Friday, April 10, 2015 10:33 AM
> > >
> > > Hi,
> > >
> > > We are working on Linux/Windows graphics driver enhancement to
> > > remove those non-standard PCI resource accesses, e.g. to PCH/MCH
> > > registers, in parallel with the ongoing effort from Tiejun on current
> > > driver support.
> > >
> > > When the goal is to make IGD passthrough like a standard PCI
> > > passthrough w/o IGD specific patches, there is one open about VBT
> > > table which contains important display information (resolution,
> > > timing, etc.) for embedded panels (e.g. on laptop) which may not
> > > be detected through normal EDID query interface. Lacking of VBT
> > > may lead to a suboptimal display quality and other tricky issues.
> > >
> > > So we want to hear your opinions whether it makes sense to you
> > > to only maintain one IGD specific logic by exposing VBT through
> > > OpRegion to the guest. Except it all current IGD specific tweaks
> > > will not be required in the future w/ planned driver enhancements.
> 
> Hi Kevin,
> 
> I found the VBT in chapter 4 here:
> 
> https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opre
> gion_spec.pdf
> 
>         How ASL/Driver use it:
> 
>         The system BIOS during, POST, decompresses (if necessary) the
>         video BIOS image to physical RAM, scans VBIOS image, and copies
>         ONLY the VBT block (all of the VBT data including its header) to
>         OpRegion memory. This must be done whether IGD is primary or
>         secondary VGA, and after VBIOS POST. The driver, during
>         initialization, reads this data, validates it, and uses it.
> 
> So this sounds like a simple extension required in SeaBIOS and OVMF to
> perform this additional operation to create this opregion in guest
> memory, right?  I'm not really seeing why this needs to be anything
> special beyond some guest BIOS code and maybe some procedure to extract
> the VBIOS from the host or expose it through sysfs.  I'd expect we need
> a VBIOS to initialize the card in the guest anyway.  There isn't really
> any requirement to pass through the host VBT, is there?  Seems like we
> can recreate it ourselves once we have the VBIOS.  If that's the case,
> it seems fairly agreeable to me, especially if it's more of an
> optimization than a requirement.  Thanks,
> 
> Alex

either presenting VBT in guest BIOS or in guest OpRegion is OK because
guest driver will try another if one is lacking. You can even create a new
VBT with filtered information. 

Here the background of this ask, is that we initially plan to make IGD 
passthru exactly same as normal PCI passthru w/o IGD specific patches, 
by providing driver enhancements, however w/o a valid VBT presented 
there will be feature/quality impact on some platforms. 

So we want to know whether keeping this very IGD specific logic only for
VBT is acceptable to the community, after removing other hacks on
MCH/ICH, etc.

Looks from your feedback it should be fine. :-)

Thanks
Kevin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]