Re: [Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Thu, Aug 31, 2017 at 04:45:23PM +0800, Chao Gao wrote:
> On Thu, Aug 31, 2017 at 10:03:19AM +0100, Roger Pau Monne wrote:
> >On Thu, Aug 31, 2017 at 03:32:42PM +0800, Chao Gao wrote:
> >> On Tue, Aug 29, 2017 at 08:33:25AM +0100, Roger Pau Monne wrote:
> >> >On Mon, Aug 28, 2017 at 06:18:13AM +0000, Tian, Kevin wrote:
> >> >> > From: Roger Pau Monne [mailto:roger.pau@xxxxxxxxxx]
> >> >> > Sent: Friday, August 25, 2017 9:59 PM
> >> >> > 
> >> >> > On Fri, Aug 25, 2017 at 06:25:36AM -0600, Jan Beulich wrote:
> >> >> > > >>> On 25.08.17 at 14:15, <roger.pau@xxxxxxxxxx> wrote:
> >> >> > > > On Wed, Aug 23, 2017 at 02:16:38AM -0600, Jan Beulich wrote:
> >> >> > > >> >>> On 22.08.17 at 15:54, <roger.pau@xxxxxxxxxx> wrote:
> >> >> > > >> > On Tue, Aug 22, 2017 at 06:26:23AM -0600, Jan Beulich wrote:
> >> >> > > >> >> >>> On 11.08.17 at 18:43, <roger.pau@xxxxxxxxxx> wrote:
> >> >> > > >> >> > --- a/xen/arch/x86/dom0_build.c
> >> >> > > >> >> > +++ b/xen/arch/x86/dom0_build.c
> >> >> > > >> >> > @@ -440,6 +440,10 @@ int __init
> >> >> > dom0_setup_permissions(struct domain *d)
> >> >> > > >> >> >              rc |= rangeset_add_singleton(mmio_ro_ranges, 
> >> >> > > >> >> > mfn);
> >> >> > > >> >> >      }
> >> >> > > >> >> >
> >> >> > > >> >> > +    /* For PVH prevent access to the MMCFG areas. */
> >> >> > > >> >> > +    if ( dom0_pvh )
> >> >> > > >> >> > +        rc |= pci_mmcfg_set_domain_permissions(d);
> >> >> > > >> >>
> >> >> > > >> >> What about ones reported by Dom0 later on? Which then raises 
> >> >> > > >> >> the
> >> >> > > >> >> question whether ...
> >> >> > > >> >
> >> >> > > >> > This should be dealt with in the PHYSDEVOP_pci_mmcfg_reserved
> >> >> > handler.
> >> >> > > >> > But since you propose to do white listing, I guess it doesn't 
> >> >> > > >> > matter
> >> >> > > >> > that much anymore.
> >> >> > > >>
> >> >> > > >> Well, a fundamental question is whether white listing would work 
> >> >> > > >> in
> >> >> > > >> the first place. I could see room for severe problems e.g. with 
> >> >> > > >> ACPI
> >> >> > > >> methods wanting to access MMIO that's not described by any PCI
> >> >> > > >> devices' BARs. Typically that would be regions in the chipset 
> >> >> > > >> which
> >> >> > > >> firmware is responsible for configuring/managing, the addresses 
> >> >> > > >> of
> >> >> > > >> which can be found/set in custom config space registers.
> >> >> > > >
> >> >> > > > The question would also be what would Xen allow in such 
> >> >> > > > white-listing.
> >> >> > > > Obviously you can get to map the same using both white-list and
> >> >> > > > black-listing (see below).
> >> >> > >
> >> >> > > Not really - what you've said there regarding MMCFG regions is
> >> >> > > a clear indication that we should _not_ map reserved regions, i.e.
> >> >> > > it would need to be full white listing with perhaps just the PCI
> >> >> > > device BARs being handled automatically.
> >> >> > 
> >> >> > I've tried just mapping the BARs and that sadly doesn't work, the box
> >> >> > hangs after the IOMMU is enabled:
> >> >> > 
> >> >> > [...]
> >> >> > (XEN) [VT-D]d0:PCI: map 0000:3f:13.5
> >> >> > (XEN) [VT-D]d0:PCI: map 0000:3f:13.6
> >> >> > (XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c00021b000
> >> >> > 
> >> >> > I will park this ATM and leave it for the Intel guys to diagnose.
> >> >> > 
> >> >> > For the reference, the specific box I'm testing ATM has a Xeon(R) CPU
> >> >> > E5-1607 0 @ 3.00GHz and a C600/X79 chipset.
> >> >> > 
> >> >> 
> >> >> +Chao who can help check whether we have such a box at hand.
> >> >> 
> >> >> btw please also give your BIOS version.
> >> >
> >> >It's a Precision T3600 BIOS A14.
> >> 
> >> Hi, Roger.
> >> 
> >> I found a Ivy bridge box with E5-2697 v2 and tested with "dom0=pvh", and
> >
> >The ones I've seen issues with are Sandy Bridge or Nehalem, can you
> >find some of this hardware?
> 
> As I expected, I was removed from recipents :(, which made me
> hard to notice your replies in time. 

Sorry, I have no idea why my MUA does that, it seems to be able to
deal fine with other recipients.

> Yes. I will. But may take some time (for even Ivy Bridge is rare).
> 
> >
> >I haven't tested Ivy Bridge, but all Haswell boxes I've tested seem to
> >work just fine.
> 
> The reason why I chose Ivy Bridge partly is you said you found this bug on
> almost pre-haswell box.

I tested Nehalem, Sandy Bridge and Haswell, but sadly not Ivy Bridge
(in fact I didn't even know about Ivy Bridge, that's why I said all
pre-Haswell).

In fact I'm now trying with a Nehalem processor that seem to work, so
whatever this issue is it certainly doesn't affect all models or
chipsets.

Thanks, Roger.

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