|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge.
On Sat, Jun 22, 2013 at 2:03 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > On Wed, Jun 19, 2013 at 06:37:06PM +0800, G.R. wrote: >> I'm going to rework this patch to address Jan's concern. >> Here is my proposal, please review and comment before I begin: >> >> The proposal is to read a shadow copy of the exposed host register into >> the config space of the emulated host bridge and relies on the >> pci_default_read_config() function >> to provide proper access. >> >> This methodology only works for constant values, which is our case here. >> The exposed value is either read-only or write-locked (for BIOS). >> >> The only exception is that the PAVPC (0x58) register is write-locked >> but not for BIOS. > > So only SeaBIOS or hvmloader should touch it? > No, here I mean the host BIOS. Those write-locked registers should have been locked by host BIOS and be read-only after boot. Most of these are for graphics memory. I'm not sure how the value specified by host BIOS works in the VM, but it just works. You can find a list of these registers in this document (section 2.5, page 47): http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/3rd-gen-core-desktop-vol-2-datasheet.pdf Just for your reference, here are the list of registers that exposed RO (with the exception of 0x58 as RW): 198 case 0x00: /* vendor id */ 199 case 0x02: /* device id */ 201 case 0x06: /* status, needed for the cap list bit*/ 202 case 0x08: /* revision id */ 203 case 0x2c: /* sybsystem vendor id */ 204 case 0x2e: /* sybsystem id */ 205 case 0x50: /* SNB: processor graphics control register */ 206 case 0x52: /* processor graphics control register */ <= actually RSVD from datasheet 207 case 0xa0: /* top of memory */ 208 case 0xb0: /* ILK: BSM: should read from dev 2 offset 0x5c */ 209 case 0x58: /* SNB: PAVPC Offset */ 210 case 0xa4: /* SNB: graphics base of stolen memory */ 211 case 0xa8: /* SNB: base of GTT stolen memory */ >> This is exposed for RW and my proposal is to perform write-through in >> the register write-support. > > What does PAVPC do? As in if the driver wrote 0xdeadbeef in there what > would happen? Is there a list of the appropiate values it should > accept? > I have no idea about this. I can't get meaningful data from the datasheet. And the value returned from lspci can't decode well according to the datasheet. The datasheet above shows only one write-lock bit at bit 2, while all others are RO and reset to zero. But here is the lspci value from my system (The four bytes starting from 0x58): 50: 41 02 00 00 11 00 00 00 07 00 90 df 01 00 00 cf Anyway, I don't think we should dig into the detailed register spec. The good news is that none of the registers in device 0:00.0 have side effect for read. We should be able to perform write to host and read-back to shadow for RW support. >> >> > >> > Also, why would removing the next capability be correct here, >> > when you're not removing _all_ other capabilities? >> I have no answer about this question. *Jean*, could you help comment >> since this is from your code? > > > If he doesn't answer - if you don't remove the capability does it > still work? Should work at least for IVB -- since this is the only cap. Not sure if there will be other concerns. >> >> Thanks, >> Timothy >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxx >> http://lists.xen.org/xen-devel >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |