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_andrushche...@epam.com>
> >
> > 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.
