[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][XSA-126] xen: limit guest control of PCI command register
On Mon, Jun 08, 2015 at 11:55:22AM +0100, Jan Beulich wrote: > >>> On 08.06.15 at 11:36, <mst@xxxxxxxxxx> wrote: > > On Mon, Jun 08, 2015 at 10:03:18AM +0100, Jan Beulich wrote: > >> >>> On 08.06.15 at 10:09, <malcolm.crossley@xxxxxxxxxx> wrote: > >> > I believe the correct behaviour is happening but a PCIE completion > >> > timeout > >> > is occurring instead of a > >> > unsupported request. > >> > >> Might it be that with the supposedly correct device returning UR > >> the root port reissues the request to the sibling device, which then > >> fails it in a more dramatic way (albeit the sibling's Uncorrectable > >> Error Status Register also has only Unsupported Request Error > >> Status set)? > > > > Isn't the sibling a function on the same device? > > Yes. > > And is the request causing the UR a memory read? > > No, it's a write according to the ITP log. So as far as I know, requesters normally can't reissue posted requests such as writes. See 6.2.3.1. Completion Status. > > If so doesn't this use address routing? > > What does it mean that the request is "to the sibling device" then? > > The way I expressed things above may simply be due to my limited > knowledge of PCIe terminology: I simply don't know (and can't find > this spelled out in the spec) what the root port's behavior ought to > be when a transaction comes in with an address that's within one of > its base/limit regions, but none of the endpoints can fulfill the > request. I think that's because root port doesn't know this. root port forwards the transaction downstream. It then gets back a UR. > But you asking this made me look more closely at the > memory ranges dumped out to the ITP log: The root port has > > 0x20: Memory Base = 0xca40 > 0x22: Memory Limit = 0xca40 > 0x24: Prefetchable Mem Base = 0xca21 > 0x26: Prefetchable Mem Limit = 0xca21 > > while function 0 has > > 0x10: Base Address Register 0 = 0xca23000c (Memory space, 64-bit access, > prefetchable) > 0x18: Base Address Register 2 = 0xca24000c (Memory space, 64-bit access, > prefetchable) > 0x20: Base Address Register 4 = 0xca25000c (Memory space, 64-bit access, > prefetchable) > > and function 1 > > 0x10: Base Address Register 0 = 0xca20000c (Memory space, 64-bit access, > prefetchable) > 0x18: Base Address Register 2 = 0xca21000c (Memory space, 64-bit access, > prefetchable) And what is the size of this BAR? > 0x20: Base Address Register 4 = 0xca22000c (Memory space, 64-bit access, > prefetchable) > > Isn't is bogus for all but one of the BARs being outside the root > ports prefetchable memory window (the MSI-X tables being inside > the BAR 4 region in both cases)? I think it's an OK configuration in the sense that the spec does not prohibit it. But the root port will never forward a transaction to these addresses, so they can't be accessed from outside. > > Does the sibling device have a BAR overlapping the address? > > No, its BARs are fully separate. > > Jan Judging from the above, it's actually function 1's BAR 2 that is accessed? Are you saying disabling memory on function 0 breaks function 2 somehow? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |