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

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

[Tian, Kevin]

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.
> 
> Thanks
> Kevin

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

[Alex Williamson]

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

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

[Tian, Kevin]

> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> 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

[Qemu-devel] driver enhancement for Intel IGD passthrough

[Tian, Kevin]

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.

Thanks
Kevin