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: Alex Williamson
Subject: Re: [Qemu-devel] driver enhancement for Intel IGD passthrough
Date: Mon, 20 Apr 2015 12:12:58 -0600

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_opregion_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




reply via email to

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