On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
> On Tue, Sep 22, 2015 at 5:35 AM, Ed Swierk <eswi...@skyportsystems.com> wrote:
> > So if the contract is that Dom0 tells Xen about mmcfgs before the
> > devices they cover, then Linux ought to call pci_mmcfg_reserved from
> > (or immediately after) both pci_mmcfg_early_init() and
> > pci_mmcfg_late_init().
> 
> Brainstorming possible approaches:
> 
> I don't see an obvious way to hook into those functions (or their
> callers) without injecting Xen-specific code. Is there a precedent to
> follow?

No.
> 
> Alternatively, we could just call the equivalent of xen_mcfg_late()
> from the existing xen_{add,remove}_device() notifiers. This would
> generate a lot of useless pci_mmcfg_reserved hypercalls (number of
> devices times number of mmcfg areas), but pci_mmcfg_arch_enable() in
> Xen should happily ignore the redundant ones. The advantage of this
> approach other than simplicity is that it makes the mmcfg -> device
> setup ordering very explicit.

While that will update the Xen's view of MMCFG it won't update the
existing configuration that Xen has slurped up during bootup.

As in, you will still get warnings.
> 
> Any other ideas?

I like it - as it will update it right away. However we would need some
extra smarts in Xen to reconfigure its view of the PCI device now that the
extended configuration space has become available.

> 
> --Ed
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Reply via email to