Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough

[Kay, Allen M]

> -----Original Message-----
> From: Alex Williamson [mailto:address@hidden
> Sent: Tuesday, February 09, 2016 1:33 PM
> To: Kay, Allen M <address@hidden>
> Cc: address@hidden; address@hidden;
> address@hidden; address@hidden;
> address@hidden; address@hidden; Ruan, Shuai
> <address@hidden>
> Subject: Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to
> passthrough
> 
> Hi Allen,
> 
Hi Alex,

> Thanks for the reply.  I'm totally onboard with you for BDW/SKL for
> supported platforms, but I'd like to understand what the incremental
> investment is for each back step within reason for older GPUs, at least for
> best-effort, community support.  If we want to assume BDW/SKL and
> Universal Passthrough Mode, then we could abandon the host bridge and
> ISA bridge modifications altogether, right?

Right.

> On the other hand, it's not clear
> to me that UPT drivers are that pervasive and if we need to enable some
> degree of host bridge/ISA bridge poke thrus, why not enable a fair chunk of
> users, including me.
> 

Sounds good.

> My IVB desktop seems to be working well (win10 + linux) with only poking
> through the standard host bridge and ISA bridge identifications.  Yes, I need
> to know about the different GMCH layout of IVB vs BDW in the IGD device,
> but I've already taken care of that.

Other than VendorID/DeviceID, which other PCI config fields in host bridge and 
ISA bridge fields did you have to passthrough to get your IVB to work.  Are you 
passing IGD through as primary or secondary?

> It seems like SNB is pretty similar to IVB (they run on the same chipsets),

Agree.

> but I haven't yet fgured out the magic to make an SNB laptop light up with IGD
> assignment, which would be useful to show that OpRegion passthrough is
> actually doing something.
> 

There might be a difference in BDSM definition.  You might want to add 0xb0 in 
host bridge passthrough and try SNB again.

It is also possible the difference might be caused by difference in driver 
version.  If I google "sandybridge windows graphics driver" and "ivybridge 
windows graphics driver" I get the following:

SNB driver: 
https://downloadcenter.intel.com/product/81502/Intel-HD-Graphics-2000-for-2nd-Generation-Intel-Core-Processors
IVB driver: 
https://downloadcenter.intel.com/product/81501/Intel-HD-Graphics-2500-for-3rd-Generation-Intel-Core-Processors

SNB driver points to version 15.28 driver binary.  This driver supports SNB and 
ILK graphics.
IVB driver points to version 15.33 driver binary.  This driver supports IVB and 
SNB graphics.

One experiment you can try is to install same IVB 15.33 binary on both IVB and 
SNB systems.  To prevent Windows update messing with driver version, you should 
do the following:

1)  disable MSFT driver update: Computer->"Advance system 
settings"->Hardware->"Device Installation Settings"->"No, let me choose what to 
do"->"Never install driver software from Windows Update".
2) Disable Windows update to never check or download updates.
3) remove "c:\windows\system32\DriverStore\FileRepository\igd*"
4) re-install IGD driver to desired binary.
5) Double check driver versions of both IVB and SNB are the same after reboot 
guest.  Unfortunately, it won't said 15.33 but have a version number starts 
with 10.*.

> If we ignore IronLake and older GPUs, how many VM chipset hacks do we
> need?  What combinations would require GMCH mirrored in the host bridge,

Base on original code in Xen, you can try the following host bridge offset 
passthrough.  I have also attached pt-graphics.c from Xen/QEMU for your 
reference.

       case 0x00:        /* vendor id */
        case 0x02:        /* device id */
        case 0x08:        /* revision id */
        case 0x2c:        /* sybsystem vendor id */
        case 0x2e:        /* sybsystem id */
        case 0x50:        /* SNB: processor graphics control register */
        case 0x52:        /* processor graphics control register */
        case 0xa0:        /* top of memory */
        case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
        case 0x58:        /* SNB: PAVPC Offset */
        case 0xa4:        /* SNB: graphics base of stolen memory */
        case 0xa8:        /* SNB: base of GTT stolen memory */

> and couldn't we mirror it from the IGD device itself since it's present in the
> same location all the way back through SNB.
> 

Yes, you can copy content from MCCG in IGD device to same 0x50 offset in host 
bridge.

> We certainly don't want to get into the nastiness of RMRRs in a VM, but do
> the stolen memory use cases you've outlined explain the DMAR faults to that
> region that I was seeing just booting a VM with a Linux live CD?

What I described about stolen memory was based on Windows driver usage.  I will 
need to try Linux live CD to see DMAR faults you encountered.  I will try that 
after I finish setting up my environment.  I have been following your blog.  
Great instructions!

> Again, it seems just as easy, if not easier to copy GMCH from the IGD itself 
> into the
> host bridge.
> 
Not sure if I follow ... how does this would solve stolen memory/RMRR issue...?

> 
> Ok, unless anyone shouts really loudly and it doesn't affect anything newer
> than IronLake, I'm happy to let those fall off the plate.  I don't have any 
> older
> systems that I care to make work with this.
> 
Sounds good.

> 
> Ok, so the code comment is pretty misleading for these.  Would anything
> since SNB need these?
>
We did not do much pruning pre-SNB.  Tiejun and I did checked HSW last year, 
most (maybe all) of these register are not needed.

> What about the BDSM register in the host bridge?
>  Is the Xen experience of not needing to copy it relevant since stolen memory 
> is
> identity mapped into the VM anyway?  Maybe Xen achieves the same effect
> by not copying it and exposing it as zero.

In SNB, BDSM is at offset 0xb0 in host bridge.  Xen/QEMU passes thru 0xb0 in 
host bridge.  Although the comment says it is for ILK.  It is also true for 
SNB.  In current BDW/SKL driver, BDSM is located at 0x5c in IGD device.

Allen

pt-graphics.c
Description: pt-graphics.c