Re: [DRAFT RFC] PVHv2 interaction with physical devices

["Roger Pau Monné" <roger.pau@citrix.com>]

On Fri, Nov 11, 2016 at 03:04:49AM -0700, Jan Beulich wrote:
> >>> On 10.11.16 at 18:21, <konrad.wilk@oracle.com> wrote:
> > On Thu, Nov 10, 2016 at 04:20:34PM +0100, Roger Pau Monné wrote:
> >> > 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function
> >> > (rev 01)
> >> >         Subsystem: Super Micro Computer Inc Device 10c9
> >> >         Flags: bus master, fast devsel, latency 0
> >> >         [virtual] Memory at fbdb8000 (64-bit, non-prefetchable) [size=16K]
> >> >         [virtual] Memory at fbd98000 (64-bit, non-prefetchable) [size=16K]
> >> >         Capabilities: [70] MSI-X: Enable+ Count=3 Masked-
> >> >         Capabilities: [a0] Express Endpoint, MSI 00
> >> >         Capabilities: [100] Advanced Error Reporting
> >> >         Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> >> >         Kernel driver in use: igbvf
> >> 
> >> So it seems that the memory for individual VFs is taken from the BARs listed 
> >> inside of PCI_EXT_CAP_ID_SRIOV.
> > 
> > Yup! I think that is right as the BIOS also enable SR-IOV to figure out how
> > many bus addresses to reserve for the PCIe device - and then it turn it off.
> > (I know this as I had a motherboard with half-broken implemention that booted
> > in OS with VFs already there).
> 
> But remember that in the common case you won't be able to access
> the SR-IOV capability structure before launching Dom0 (as being
> located in extended config space).

Since we need PHYSDEVOP_pci_mmcfg_reserved anyway, the newly added bus will be 
scanned in order to find devices, and those SR-IOV BARs will be added then into 
the Dom0 memory map.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel