Re: [DRAFT RFC] PVHv2 interaction with physical devices

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Nov 10, 2016 at 09:37:19AM -0700, Jan Beulich wrote:
> >>> On 10.11.16 at 11:39, <roger.pau@citrix.com> wrote:
> > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> >> > PCI memory BARs
> >> > ---------------
> >> > 
> >> > PCI devices discovered by Xen will have it's BARs scanned in order to detect
> >> > memory BARs, and those will be identity mapped to Dom0. Since BARs can be
> >> > freely moved by the Dom0 OS by writing to the appropriate PCI config space
> >> > register, Xen must trap those accesses and unmap the previous region and
> >> > map the new one as set by Dom0.
> >> 
> >> You can make that simpler - we have hypercalls to "notify" in Linux
> >> when a device is changing. Those can provide that information as well.
> >> (This is what PV dom0 does).
> >> 
> >> Also you are missing one important part - the MMCFG. That is required
> >> for Xen to be able to poke at the PCI configuration spaces (above the 256).
> >> And you can only get the MMCFG if the ACPI DSDT has been parsed.
> > 
> > Hm, I guess I'm missing something, but at least on my hardware Xen seems to 
> > be able to parse the MCFG ACPI table before Dom0 does anything with the 
> > DSDT:
> > 
> > (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f
> > (XEN) PCI: MCFG area at f8000000 reserved in E820
> 
> This is the crucial line: To guard against broken firmware, we - just
> like Linux - require that the area be reserved in at least one of E820
> or ACPI resources. We can check E820 ourselves, but we need
> Dom0's AML parser for the other mechanism.

And in fact I do have such box!

When it boots:
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 3f^M^M
(XEN) PCI: Not using MCFG for segment 0000 bus 00-3f^M^M

.. and then later:

[    3.880750] NetLabel:  unlabeled traffic allowed by default^M^M^M
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f^M^M

(when it gets the hypercall)
This is Intel DQ67SW  with SWQ6710H.86A.0066.2012.1105.1504 BIOS

It is an SandyBridge motherboard.
> 
> >> So if you do the PCI bus scanning _before_ booting PVH dom0, you may
> >> need to update your view of PCI devices after the MMCFG locations
> >> have been provided to you.
> > 
> > I'm not opposed to keep the PHYSDEVOP_pci_mmcfg_reserved, but I still have 
> > to see hardware where this is actually needed. Also, AFAICT, FreeBSD at 

Here is the spec:
ttp://ark.intel.com/products/51997/Intel-Desktop-Board-DQ67SW


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