| Message ID | 20211125110251.2877218-1-andr2000@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | PCI devices passthrough on Arm, part 3 | expand |
Dear rest maintainers! Could you please review this series which seems to get stuck? Thank you in advance, Oleksandr On 25.11.21 13:02, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> > > Hi, all! > > 1. 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. > > 2. 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. > > 3. The series has complete re-work of the locking scheme used/absent before with > the help of the work started by Roger [1]: > [PATCH v5 03/13] vpci: move lock outside of struct vpci > > This way the lock can be used to check whether vpci is present, and > removal can be performed while holding the lock, in order to make > sure there are no accesses to the contents of the vpci struct. > Previously removal could race with vpci_read for example, since the > lock was dropped prior to freeing pdev->vpci. > This also solves synchronization issues between all vPCI code entities > which could run in parallel. > > 4. There is an outstanding TODO left unimplemented by this series: > for unprivileged guests vpci_{read|write} need to be re-worked > to not passthrough accesses to the registers not explicitly handled > by the corresponding vPCI handlers: without fixing that passthrough > to guests is completely unsafe as Xen allows them full access to > the registers. > > Xen needs to be sure that every register a guest accesses is not > going to cause the system to malfunction, so Xen needs to keep a > list of the registers it is safe for a guest to access. > > For example, we should only expose the PCI capabilities that we know > are safe for a guest to use, i.e.: MSI and MSI-X initially. > The rest of the capabilities should be blocked from guest access, > unless we audit them and declare safe for a guest to access. > > As a reference we might want to look at the approach currently used > by QEMU in order to do PCI passthrough. A very limited set of PCI > capabilities known to be safe for untrusted access are exposed to the > guest and registers need to be explicitly handled or else access is > rejected. Xen needs a fairly similar model in vPCI or else none of > this will be safe for unprivileged access. > > 5. 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 > > [1] https://lore.kernel.org/xen-devel/20180717094830.54806-2-roger.pau@citrix.com/ > > Oleksandr Andrushchenko (13): > rangeset: add RANGESETF_no_print flag > vpci: fix function attributes for vpci_process_pending > vpci: cancel pending map/unmap on vpci removal > 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 > xen/arm: account IO handlers for emulated PCI MSI-X > vpci: add TODO for the registers not explicitly handled > > Roger Pau Monne (1): > vpci: move lock outside of struct vpci > > tools/tests/vpci/emul.h | 5 +- > tools/tests/vpci/main.c | 4 +- > xen/arch/arm/vpci.c | 33 +++- > xen/arch/x86/hvm/vmsi.c | 8 +- > xen/common/rangeset.c | 5 +- > xen/drivers/Kconfig | 4 + > xen/drivers/passthrough/pci.c | 11 ++ > xen/drivers/vpci/header.c | 352 +++++++++++++++++++++++++++------- > xen/drivers/vpci/msi.c | 11 +- > xen/drivers/vpci/msix.c | 8 +- > xen/drivers/vpci/vpci.c | 252 +++++++++++++++++++++--- > xen/include/xen/pci.h | 6 + > xen/include/xen/rangeset.h | 7 +- > xen/include/xen/sched.h | 8 + > xen/include/xen/vpci.h | 47 ++++- > 15 files changed, 644 insertions(+), 117 deletions(-) >
On 15.12.2021 12:56, Oleksandr Andrushchenko wrote: > Dear rest maintainers! > > Could you please review this series which seems to get stuck? I don't seem to have any record of you having pinged Roger as the vPCI maintainer. Also, as said on the Community Call when discussing this, I don't think I'd view this series as in a state where an emergency fallback to REST would be appropriate. As indicated, in particular I wouldn't want to commit any of it without Roger's basic agreement. IOW while REST maintainer reviews may help making progress (but as much would reviews by anyone else), they may not put the series in a state where it could go in. In any event, as also said on the call, afaic this series is in my to- be-reviewed folder, alongside a few dozen more patches. I'll get to it if nobody else would, but I can't predict when that's going to be. There's simply too much other stuff in need of taking care of. Jan > Thank you in advance, > Oleksandr > > On 25.11.21 13:02, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >> >> Hi, all! >> >> 1. 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. >> >> 2. 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. >> >> 3. The series has complete re-work of the locking scheme used/absent before with >> the help of the work started by Roger [1]: >> [PATCH v5 03/13] vpci: move lock outside of struct vpci >> >> This way the lock can be used to check whether vpci is present, and >> removal can be performed while holding the lock, in order to make >> sure there are no accesses to the contents of the vpci struct. >> Previously removal could race with vpci_read for example, since the >> lock was dropped prior to freeing pdev->vpci. >> This also solves synchronization issues between all vPCI code entities >> which could run in parallel. >> >> 4. There is an outstanding TODO left unimplemented by this series: >> for unprivileged guests vpci_{read|write} need to be re-worked >> to not passthrough accesses to the registers not explicitly handled >> by the corresponding vPCI handlers: without fixing that passthrough >> to guests is completely unsafe as Xen allows them full access to >> the registers. >> >> Xen needs to be sure that every register a guest accesses is not >> going to cause the system to malfunction, so Xen needs to keep a >> list of the registers it is safe for a guest to access. >> >> For example, we should only expose the PCI capabilities that we know >> are safe for a guest to use, i.e.: MSI and MSI-X initially. >> The rest of the capabilities should be blocked from guest access, >> unless we audit them and declare safe for a guest to access. >> >> As a reference we might want to look at the approach currently used >> by QEMU in order to do PCI passthrough. A very limited set of PCI >> capabilities known to be safe for untrusted access are exposed to the >> guest and registers need to be explicitly handled or else access is >> rejected. Xen needs a fairly similar model in vPCI or else none of >> this will be safe for unprivileged access. >> >> 5. 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 >> >> [1] https://lore.kernel.org/xen-devel/20180717094830.54806-2-roger.pau@citrix.com/ >> >> Oleksandr Andrushchenko (13): >> rangeset: add RANGESETF_no_print flag >> vpci: fix function attributes for vpci_process_pending >> vpci: cancel pending map/unmap on vpci removal >> 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 >> xen/arm: account IO handlers for emulated PCI MSI-X >> vpci: add TODO for the registers not explicitly handled >> >> Roger Pau Monne (1): >> vpci: move lock outside of struct vpci >> >> tools/tests/vpci/emul.h | 5 +- >> tools/tests/vpci/main.c | 4 +- >> xen/arch/arm/vpci.c | 33 +++- >> xen/arch/x86/hvm/vmsi.c | 8 +- >> xen/common/rangeset.c | 5 +- >> xen/drivers/Kconfig | 4 + >> xen/drivers/passthrough/pci.c | 11 ++ >> xen/drivers/vpci/header.c | 352 +++++++++++++++++++++++++++------- >> xen/drivers/vpci/msi.c | 11 +- >> xen/drivers/vpci/msix.c | 8 +- >> xen/drivers/vpci/vpci.c | 252 +++++++++++++++++++++--- >> xen/include/xen/pci.h | 6 + >> xen/include/xen/rangeset.h | 7 +- >> xen/include/xen/sched.h | 8 + >> xen/include/xen/vpci.h | 47 ++++- >> 15 files changed, 644 insertions(+), 117 deletions(-) >>
Hi, Jan! On 15.12.21 14:07, Jan Beulich wrote: > On 15.12.2021 12:56, Oleksandr Andrushchenko wrote: >> Dear rest maintainers! >> >> Could you please review this series which seems to get stuck? > I don't seem to have any record of you having pinged Roger as the vPCI > maintainer. No, I didn't. Roger is on CC, so he might shed some light on when it might happen, so we, those who work on PCI passthrough on Arm, can also plan the relevant upcoming (re)work: we still miss MSI/MSI-X and IOMMU series which do depend on this one > Also, as said on the Community Call when discussing this, > I don't think I'd view this series as in a state where an emergency > fallback to REST would be appropriate. No emergency here, but v5 without any ack/nack might ring a bell Which made me write this e-mail > As indicated, in particular I > wouldn't want to commit any of it without Roger's basic agreement. This is clear as it is up to the relevant maintainer to commit which I might not expect from the rest maintainers > IOW > while REST maintainer reviews may help making progress (but as much > would reviews by anyone else), This is my goal: to have ack/nack at least from the REST mainatainers > they may not put the series in a state > where it could go in. Fair enough > > In any event, as also said on the call, afaic this series is in my to- > be-reviewed folder, Appreciate this > alongside a few dozen more patches. I'll get to it > if nobody else would, but I can't predict when that's going to be. Thank you > There's simply too much other stuff in need of taking care of. Sure, our companies do want us to do something useful for them as well, but review Thank you, Oleksandr > > Jan > >> Thank you in advance, >> Oleksandr >> >> On 25.11.21 13:02, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >>> >>> Hi, all! >>> >>> 1. 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. >>> >>> 2. 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. >>> >>> 3. The series has complete re-work of the locking scheme used/absent before with >>> the help of the work started by Roger [1]: >>> [PATCH v5 03/13] vpci: move lock outside of struct vpci >>> >>> This way the lock can be used to check whether vpci is present, and >>> removal can be performed while holding the lock, in order to make >>> sure there are no accesses to the contents of the vpci struct. >>> Previously removal could race with vpci_read for example, since the >>> lock was dropped prior to freeing pdev->vpci. >>> This also solves synchronization issues between all vPCI code entities >>> which could run in parallel. >>> >>> 4. There is an outstanding TODO left unimplemented by this series: >>> for unprivileged guests vpci_{read|write} need to be re-worked >>> to not passthrough accesses to the registers not explicitly handled >>> by the corresponding vPCI handlers: without fixing that passthrough >>> to guests is completely unsafe as Xen allows them full access to >>> the registers. >>> >>> Xen needs to be sure that every register a guest accesses is not >>> going to cause the system to malfunction, so Xen needs to keep a >>> list of the registers it is safe for a guest to access. >>> >>> For example, we should only expose the PCI capabilities that we know >>> are safe for a guest to use, i.e.: MSI and MSI-X initially. >>> The rest of the capabilities should be blocked from guest access, >>> unless we audit them and declare safe for a guest to access. >>> >>> As a reference we might want to look at the approach currently used >>> by QEMU in order to do PCI passthrough. A very limited set of PCI >>> capabilities known to be safe for untrusted access are exposed to the >>> guest and registers need to be explicitly handled or else access is >>> rejected. Xen needs a fairly similar model in vPCI or else none of >>> this will be safe for unprivileged access. >>> >>> 5. 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 >>> >>> [1] https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20180717094830.54806-2-roger.pau@citrix.com/__;!!GF_29dbcQIUBPA!ntDLQ-kiosLLPDLG_D7C7Sdeb1Ad1j-43XjuCGTMgeJNboANStsYFP6a1hR43s67GNuFAx7Hug$ [lore[.]kernel[.]org] >>> >>> Oleksandr Andrushchenko (13): >>> rangeset: add RANGESETF_no_print flag >>> vpci: fix function attributes for vpci_process_pending >>> vpci: cancel pending map/unmap on vpci removal >>> 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 >>> xen/arm: account IO handlers for emulated PCI MSI-X >>> vpci: add TODO for the registers not explicitly handled >>> >>> Roger Pau Monne (1): >>> vpci: move lock outside of struct vpci >>> >>> tools/tests/vpci/emul.h | 5 +- >>> tools/tests/vpci/main.c | 4 +- >>> xen/arch/arm/vpci.c | 33 +++- >>> xen/arch/x86/hvm/vmsi.c | 8 +- >>> xen/common/rangeset.c | 5 +- >>> xen/drivers/Kconfig | 4 + >>> xen/drivers/passthrough/pci.c | 11 ++ >>> xen/drivers/vpci/header.c | 352 +++++++++++++++++++++++++++------- >>> xen/drivers/vpci/msi.c | 11 +- >>> xen/drivers/vpci/msix.c | 8 +- >>> xen/drivers/vpci/vpci.c | 252 +++++++++++++++++++++--- >>> xen/include/xen/pci.h | 6 + >>> xen/include/xen/rangeset.h | 7 +- >>> xen/include/xen/sched.h | 8 + >>> xen/include/xen/vpci.h | 47 ++++- >>> 15 files changed, 644 insertions(+), 117 deletions(-) >>>
On Wed, Dec 15, 2021 at 12:22:32PM +0000, Oleksandr Andrushchenko wrote: > Hi, Jan! > > On 15.12.21 14:07, Jan Beulich wrote: > > On 15.12.2021 12:56, Oleksandr Andrushchenko wrote: > >> Dear rest maintainers! > >> > >> Could you please review this series which seems to get stuck? > > I don't seem to have any record of you having pinged Roger as the vPCI > > maintainer. > No, I didn't. Roger is on CC, so he might shed some light on when it might > happen, so we, those who work on PCI passthrough on Arm, > can also plan the relevant upcoming (re)work: we still miss MSI/MSI-X and > IOMMU series which do depend on this one Hello, I'm quite overloaded with patch review and other stuff, since I've taken over the Community Manager role while George is away. There are series on the mailing list that have been pending for way longer, and while I understand that this is of no help or relief for you it wouldn't be fair for me to review this piece for work before other series that have been pending for longer, as other submitters also deserve review. Sorry, but I think it's unlikely I will get to it until after new year. Thanks, Roger.
Hi, Roger! On 15.12.21 16:51, Roger Pau Monné wrote: > On Wed, Dec 15, 2021 at 12:22:32PM +0000, Oleksandr Andrushchenko wrote: >> Hi, Jan! >> >> On 15.12.21 14:07, Jan Beulich wrote: >>> On 15.12.2021 12:56, Oleksandr Andrushchenko wrote: >>>> Dear rest maintainers! >>>> >>>> Could you please review this series which seems to get stuck? >>> I don't seem to have any record of you having pinged Roger as the vPCI >>> maintainer. >> No, I didn't. Roger is on CC, so he might shed some light on when it might >> happen, so we, those who work on PCI passthrough on Arm, >> can also plan the relevant upcoming (re)work: we still miss MSI/MSI-X and >> IOMMU series which do depend on this one > Hello, > > I'm quite overloaded with patch review and other stuff, since I've > taken over the Community Manager role while George is away. > > There are series on the mailing list that have been pending for way > longer, and while I understand that this is of no help or relief for > you it wouldn't be fair for me to review this piece for work before > other series that have been pending for longer, as other submitters > also deserve review. This is fair > > Sorry, but I think it's unlikely I will get to it until after new > year. Thank you in advance, Oleksandr > > Thanks, Roger.
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Hi, all! 1. 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. 2. 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. 3. The series has complete re-work of the locking scheme used/absent before with the help of the work started by Roger [1]: [PATCH v5 03/13] vpci: move lock outside of struct vpci This way the lock can be used to check whether vpci is present, and removal can be performed while holding the lock, in order to make sure there are no accesses to the contents of the vpci struct. Previously removal could race with vpci_read for example, since the lock was dropped prior to freeing pdev->vpci. This also solves synchronization issues between all vPCI code entities which could run in parallel. 4. There is an outstanding TODO left unimplemented by this series: for unprivileged guests vpci_{read|write} need to be re-worked to not passthrough accesses to the registers not explicitly handled by the corresponding vPCI handlers: without fixing that passthrough to guests is completely unsafe as Xen allows them full access to the registers. Xen needs to be sure that every register a guest accesses is not going to cause the system to malfunction, so Xen needs to keep a list of the registers it is safe for a guest to access. For example, we should only expose the PCI capabilities that we know are safe for a guest to use, i.e.: MSI and MSI-X initially. The rest of the capabilities should be blocked from guest access, unless we audit them and declare safe for a guest to access. As a reference we might want to look at the approach currently used by QEMU in order to do PCI passthrough. A very limited set of PCI capabilities known to be safe for untrusted access are exposed to the guest and registers need to be explicitly handled or else access is rejected. Xen needs a fairly similar model in vPCI or else none of this will be safe for unprivileged access. 5. 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 [1] https://lore.kernel.org/xen-devel/20180717094830.54806-2-roger.pau@citrix.com/ Oleksandr Andrushchenko (13): rangeset: add RANGESETF_no_print flag vpci: fix function attributes for vpci_process_pending vpci: cancel pending map/unmap on vpci removal 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 xen/arm: account IO handlers for emulated PCI MSI-X vpci: add TODO for the registers not explicitly handled Roger Pau Monne (1): vpci: move lock outside of struct vpci tools/tests/vpci/emul.h | 5 +- tools/tests/vpci/main.c | 4 +- xen/arch/arm/vpci.c | 33 +++- xen/arch/x86/hvm/vmsi.c | 8 +- xen/common/rangeset.c | 5 +- xen/drivers/Kconfig | 4 + xen/drivers/passthrough/pci.c | 11 ++ xen/drivers/vpci/header.c | 352 +++++++++++++++++++++++++++------- xen/drivers/vpci/msi.c | 11 +- xen/drivers/vpci/msix.c | 8 +- xen/drivers/vpci/vpci.c | 252 +++++++++++++++++++++--- xen/include/xen/pci.h | 6 + xen/include/xen/rangeset.h | 7 +- xen/include/xen/sched.h | 8 + xen/include/xen/vpci.h | 47 ++++- 15 files changed, 644 insertions(+), 117 deletions(-)