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

[Rahul Singh <Rahul.Singh@xxxxxxx>]

Hi Oleksandr,

> On 19 Jul 2022, at 6:42 pm, Oleksandr Tyshchenko <olekstysh@xxxxxxxxx> wrote:
> 
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> 
> Hi, all!
> 
> You can find previous discussion at [1].
> 
> 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 domain 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 been updated due to the new PCI(vPCI) locking scheme 
> implemented
> in the prereq series which is also on the review now [2].
> 
> 4. For unprivileged guests vpci_{read|write} has been re-worked
> to not passthrough accesses to the registers not explicitly handled
> by the corresponding vPCI handlers: without that passthrough
> to guests is completely unsafe as Xen allows them full access to
> the registers. During development this can be reverted for debugging purposes.
> 
> !!! OT: please note, Oleksandr Andrushchenko who is the author of all this 
> stuff
> has managed to address allmost all review comments given for v6 and pushed 
> the updated
> version to the github (23.02.22). 
> So after receiving his agreement I just picked it up and did the following 
> before
> pushing V7:
> - rebased on the recent staging (resolving a few conflicts)
> - updated according to the recent changes (added cf_check specifiers where 
> appropriate, etc)
> and performed minor adjustments
> - made sure that both current and prereq series [2] didn't really break x86 
> by testing
> PVH Dom0 (vPCI) and PV Dom0 + HVM DomU (PCI passthrough to DomU) using Qemu
> - my colleague Volodymyr Babchuk (who was involved in the prereq series) 
> rechecked that
> both series worked on Arm using real HW
> 
> You can also find the series at [3].
> 
> [1] 
> https://lore.kernel.org/xen-devel/20220204063459.680961-1-andr2000@xxxxxxxxx/
> [2] 
> https://lore.kernel.org/xen-devel/20220718211521.664729-1-volodymyr_babchuk@xxxxxxxx/
> [3] https://github.com/otyshchenko1/xen/commits/vpci7
> 

I tested the whole series on ARM N1SDP board everything works as expected.

So for the whole series:
Tested-by: Rahul Singh <rahul.singh@xxxxxxx>

Regards,
Rahul