Hi Eric, > -----Original Message----- > From: qemu-devel- > bounces+shameerali.kolothum.thodi=huawei....@nongnu.org <qemu- > devel-bounces+shameerali.kolothum.thodi=huawei....@nongnu.org> On > Behalf Of Eric Auger > Sent: Monday, March 24, 2025 1:13 PM > To: Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com>; Nicolin Chen > <nicol...@nvidia.com> > Cc: Donald Dutile <ddut...@redhat.com>; qemu-...@nongnu.org; qemu- > de...@nongnu.org; peter.mayd...@linaro.org; j...@nvidia.com; > berra...@redhat.com; nath...@nvidia.com; mo...@nvidia.com; > smost...@google.com; Linuxarm <linux...@huawei.com>; Wangzhou (B) > <wangzh...@hisilicon.com>; jiangkunkun <jiangkun...@huawei.com>; > Jonathan Cameron <jonathan.came...@huawei.com>; > zhangfei....@linaro.org > Subject: Re: [RFC PATCH v2 05/20] hw/arm/smmuv3-accel: Associate a pxb- > pcie bus > > Hi Shameer, > > On 3/24/25 9:19 AM, Shameerali Kolothum Thodi wrote: > > > >> -----Original Message----- > >> From: Nicolin Chen <nicol...@nvidia.com> > >> Sent: Thursday, March 20, 2025 5:03 PM > >> To: Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com> > >> Cc: Donald Dutile <ddut...@redhat.com>; qemu-...@nongnu.org; > qemu- > >> de...@nongnu.org; eric.au...@redhat.com; peter.mayd...@linaro.org; > >> j...@nvidia.com; berra...@redhat.com; nath...@nvidia.com; > >> mo...@nvidia.com; smost...@google.com; Linuxarm > >> <linux...@huawei.com>; Wangzhou (B) <wangzh...@hisilicon.com>; > >> jiangkunkun <jiangkun...@huawei.com>; Jonathan Cameron > >> <jonathan.came...@huawei.com>; zhangfei....@linaro.org > >> Subject: Re: [RFC PATCH v2 05/20] hw/arm/smmuv3-accel: Associate a > pxb- > >> pcie bus > >> > >> On Wed, Mar 19, 2025 at 09:26:29AM +0000, Shameerali Kolothum Thodi > >> wrote: > >>> Having said that, current code only allows pxb-pcie root complexes > >> avoiding > >>> the pcie.0. The idea behind this was, user can use pcie.0 with a non > accel > >> SMMUv3 > >>> for any emulated devices avoiding the performance bottlenecks we are > >>> discussing for emulated dev+smmuv3-accel cases. But based on the > >> feedback from > >>> Eric and Daniel I will relax that restriction and will allow association > with > >> pcie.0. > >> > >> Just want a clarification here.. > >> > >> If VM has a passthrough device only: > >> attach it to PCIE.0 <=> vSMMU0 (accel=on) > > Yes. Basically support accel=on to pcie.0 as well. > > agreed we shall be able to instantiate the accelerated SMMU on pcie.0 too. > > > >> If VM has an emulated device and a passthrough device: > >> attach the emulated device to PCIE.0 <=> vSMMU bypass (or accel=off?) > >> attach the passthrough device to pxb-pcie <=> vSMMU0 (accel=on) > > This can be other way around as well: > > ie, > > pass-through to pcie.0(accel=on) and emulated to any other pxb-pcie with > accel = off. > +1 > > > > I think the way bus numbers are allocated in Qemu for pcie.0 and pxb- > pcie allows > > us to support this in IORT ID maps. > One trouble we may get into is possible bus reordering by the guest. I > don't know the details but I remember that in certain conditions the > guest can reorder the bus numbers.
Yeah, Guest kernel can re-enumerate PCIe. I will check. > Besides what I don't get in the above discussion, related to whether the > accelerated mode can also sipport emulated devices, is that if you use > the originally suggested hierarchy (pxb-pcie + root port + VFIO device) > you eventually get on guest side 2 devices protected by the SMMU > instance: the root port and the VFIO device. They end up in different > iommu groups. So there is already a mix of emulated and VFIO device. True. But I guess the root port associated activity(invalidations etc) will be very minimal(or nil?) compared to a virtio device. Thanks, Shameer
