Re: [Xen-devel] [BUG] pci: mixed allocation pf and non-pf PCI MEM BAR (OVMF crash)

[Martin Cerveny <martin@xxxxxxxxx>]

Hello.

On Fri, 5 Apr 2019, Igor Druzhinin wrote:
> On 01/04/2019 19:48, Martin Cerveny wrote:
> > On Mon, 1 Apr 2019, Jan Beulich wrote:
> > > > > > On 31.03.19 at 10:11, <martin@xxxxxxxxx> wrote:
> > > > There is problem in PCI device allocation algorithm (pci_setup()).
> > > > Algorithm allocates PCI BAR sorted by size and this allows
> > > > mixed allocation of prefetchable and non-prefetchable PCI MEM BAR.
> > > > This leads to wrong config of PCI root port (see "Type 1 Configuration
> > > > Space Registers (Root Ports)").
> > > >
> > > > Tested with version xen 4.11.1 + "export
> > > > OVMF_UPSTREAM_REVISION=ef529e6ab7c31290a33045bb1f1837447cc0eb56"
> > > > (embeded commit OVMF does not work (crashed even in Win10.iso and
> > > > uncompilable with newer gcc)).
> > > >
> > > > Attached also testing patch.
> > > I agree the problem wants addressing, but I'm afraid the patch is
> > > incomplete: Afaict it won't work if there is a non-prefetchable BAR
> > > larger than the smallest prefetchable one, due to the necessary
> > > extra padding that would need inserting between the two.
> > I make this patch as proof-of-concept to get it compatible with OVMF.
> > But I am not aware if OVMF is OK and all other consequences, like:
> >
> > - allocation aligning as you mention
> > - PF region to be placed first or last in MMIO hole - some PCI express
> > documents says that all 64bit MEM BAR must be prefetchable
> > [ But if I activate "usbversion=3" it generates 64bit MEM BAR but
> > without prefetchable bit (so PCI_BASE_ADDRESS_MEM_PREFETCH is implicit?)
> > and actual code allocates MMIO under 4G. But OVMF requires that 64bit
> > MEM BAR must be placed over 4G (just another problem/BUG). ]
> >
> > (example -
> > https://resources.infosecinstitute.com/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/
> > )
> Hi Martin,
>
> We're aware of the problem and it needs to be fixed on OVMF side where
> Xen specific code incorrectly tries to initialize a prefetchable
> aperture where it in fact doesn't exist in our root bridge. I'm actively
> working on a series for OVMF which addresses the problems that you
> mentioned [1].
>
> As to hvmloader, coexisting of prefetchable and non-prefetchable BARs in
> a single aperture is perfectly normal from PCI specification point of
> view (e.g. see "PCI-TO-PCI BRIDGE ARCHITECTURE SPECIFICATION, REV 1.2").
>
> [1] https://marc.info/?l=xen-devel&m=155187612626640&w=2
Good news!

I see ignoring PF/non-PF differences in your patch probably it can be
possible in virtualized world. I do not known.

And do not forget that XEN using (old) fork of OVMF :-(
XEN4.12 - commit ef529e6ab7c31290a33045bb1f1837447cc0eb56 (2018-07-25)
XEN4.11.1 - commit 947f3737abf65fda63f3ffd97fddfa6986986868 (2017-09-19)

Thanks, M.C>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel