Re: [Xen-devel] [PATCH] vpci: don't allow access to devices not assigned to the domain

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Sep 02, 2019 at 04:15:02PM +0200, Jan Beulich wrote:
> On 02.09.2019 15:58, Roger Pau Monné  wrote:
> > On Mon, Sep 02, 2019 at 01:58:07PM +0200, Jan Beulich wrote:
> >> On 02.09.2019 13:30, Roger Pau Monne wrote:
> >>> Don't allow the hardware domain to access the PCI config space of
> >>> devices not assigned to it. Ie: the config space of iommu devices
> >>> in use by Xen should not be accessible to the hardware domain.
> >>
> >> Well, I agree with what you say above, but the code change disallows
> >> much more than this. In particular Dom0 (and maybe stub domains too)
> >> need to be able to access the config space of devices assigned to
> >> guests, e.g. for qemu to control MSI and/or MSI-X.
> > 
> > Right, I was overlooking the fact that a domain using vPCI itself
> > should be able to handle passthrough backends for other domains.
> > 
> > I think the condition should instead check if the device is assigned
> > to dom_xen, and don't allow domains access to devices assigned to
> > dom_xen.
> 
> Even that goes too far imo: We deliberately allow read access to
> r/o devices, in order to avoid anomalies in bus enumeration in
> Dom0. And I'd very much hope write attempts already honor the
> pseg->ro_map bit for a device.

Hm, no, AFAICT vPCI was just bypassing the ro_map ATM.

So the problem I found, and that I was trying to address with this
patch is that a PVH dom0 on AMD hardware finds the iommus by scanning
the PCI bus, and a Linux dom0 seems to immediately turn off the MSI
enable control bit on any devices it finds, thus leaving the iommu
without being able to generate interrupts.

I can implement the RO stuff, but it seems weird to me. AFAICT the
only devices owned by Xen should be the serial console, the iommu and
the HPET maybe. How can hiding those cause anomalies in bus
enumeration?

Thanks, Roger.

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