Re: [PATCH v4 00/11] PCI devices passthrough on Arm, part 3

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

On Fri, Nov 19, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
> > 
> > Hi, all!
> > 
> > This patch series is focusing on vPCI and adds support for non-identity
> > PCI BAR mappings which is required while passing through a PCI device to
> > a guest. The highlights are:
> > 
> > - Add relevant vpci register handlers when assigning PCI device to a domain
> >   and remove those when de-assigning. This allows having different
> >   handlers for different domains, e.g. hwdom and other guests.
> > 
> > - Emulate guest BAR register values based on physical BAR values.
> >   This allows creating a guest view of the registers and emulates
> >   size and properties probe as it is done during PCI device enumeration by
> >   the guest.
> > 
> > - Instead of handling a single range set, that contains all the memory
> >   regions of all the BARs and ROM, have them per BAR.
> > 
> > - Take into account guest's BAR view and program its p2m accordingly:
> >   gfn is guest's view of the BAR and mfn is the physical BAR value as set
> >   up by the host bridge in the hardware domain.
> >   This way hardware doamin sees physical BAR values and guest sees
> >   emulated ones.
> > 
> > The series also adds support for virtual PCI bus topology for guests:
> >  - We emulate a single host bridge for the guest, so segment is always 0.
> >  - The implementation is limited to 32 devices which are allowed on
> >    a single PCI bus.
> >  - The virtual bus number is set to 0, so virtual devices are seen
> >    as embedded endpoints behind the root complex.
> > 
> > The series was also tested on:
> >  - x86 PVH Dom0 and doesn't break it.
> >  - x86 HVM with PCI passthrough to DomU and doesn't break it.
> > 
> > Thank you,
> > Oleksandr
> > 
> > Oleksandr Andrushchenko (11):
> >   vpci: fix function attributes for vpci_process_pending
> >   vpci: cancel pending map/unmap on vpci removal
> >   vpci: make vpci registers removal a dedicated function
> >   vpci: add hooks for PCI device assign/de-assign
> >   vpci/header: implement guest BAR register handlers
> >   vpci/header: handle p2m range sets per BAR
> >   vpci/header: program p2m with guest BAR view
> >   vpci/header: emulate PCI_COMMAND register for guests
> >   vpci/header: reset the command register when adding devices
> >   vpci: add initial support for virtual PCI bus topology
> >   xen/arm: translate virtual PCI bus topology for guests
> 
> If I'm not mistaken by the end of this series a guest can access a
> device handed to it. I couldn't find anything dealing with the
> uses of vpci_{read,write}_hw() and vpci_hw_{read,write}*() to cover
> config registers not covered by registered handlers. IMO this should
> happen before patch 5: Before any handlers get registered the view a
> guest would have would be all ones no matter which register it
> accesses. Handler registration would then "punch holes" into this
> "curtain", as opposed to Dom0, where handler registration hides
> previously visible raw hardware registers.

FWIW, I've also raised the same concern in a different thread:

https://lore.kernel.org/xen-devel/YYD7VmDGKJRkid4a@Air-de-Roger/

It seems like this is future work, but unless such a model is
implemented vPCI cannot be used for guest passthrough.

I'm fine with doing it in a separate series, but needs to be kept in
mind.

Regards, Roger.