[PATCH v3 00/11] PCI devices passthrough on Arm, part 3

Oleksandr Andrushchenko posted 11 patches 3 years, 2 months ago
Failed in applying to current master (apply log)
There is a newer version of this series
xen/arch/arm/domain.c         |   1 +
xen/arch/arm/vpci.c           |  86 ++++++-
xen/arch/arm/vpci.h           |   3 +
xen/common/domain.c           |   3 +
xen/drivers/Kconfig           |   4 +
xen/drivers/passthrough/pci.c |  94 ++++++++
xen/drivers/vpci/header.c     | 411 +++++++++++++++++++++++++++-------
xen/drivers/vpci/vpci.c       |  42 +++-
xen/include/asm-arm/pci.h     |   1 +
xen/include/xen/pci.h         |  23 ++
xen/include/xen/sched.h       |  10 +
xen/include/xen/vpci.h        |  36 ++-
12 files changed, 623 insertions(+), 91 deletions(-)
[PATCH v3 00/11] PCI devices passthrough on Arm, part 3
Posted by Oleksandr Andrushchenko 3 years, 2 months ago
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@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: Make vpci registers removal a dedicated function
  vpci: Add hooks for PCI device assign/de-assign
  vpci/header: Move register assignments from init_bars
  vpci/header: Add and remove register handlers dynamically
  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

 xen/arch/arm/domain.c         |   1 +
 xen/arch/arm/vpci.c           |  86 ++++++-
 xen/arch/arm/vpci.h           |   3 +
 xen/common/domain.c           |   3 +
 xen/drivers/Kconfig           |   4 +
 xen/drivers/passthrough/pci.c |  94 ++++++++
 xen/drivers/vpci/header.c     | 411 +++++++++++++++++++++++++++-------
 xen/drivers/vpci/vpci.c       |  42 +++-
 xen/include/asm-arm/pci.h     |   1 +
 xen/include/xen/pci.h         |  23 ++
 xen/include/xen/sched.h       |  10 +
 xen/include/xen/vpci.h        |  36 ++-
 12 files changed, 623 insertions(+), 91 deletions(-)

-- 
2.25.1