Hi Eric, > -----Original Message----- > From: qemu-devel- > [email protected] <qemu- > [email protected]> On > Behalf Of Eric Auger > Sent: Monday, March 24, 2025 1:13 PM > To: Shameerali Kolothum Thodi > <[email protected]>; Nicolin Chen > <[email protected]> > Cc: Donald Dutile <[email protected]>; [email protected]; qemu- > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; Linuxarm <[email protected]>; Wangzhou (B) > <[email protected]>; jiangkunkun <[email protected]>; > Jonathan Cameron <[email protected]>; > [email protected] > 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 <[email protected]> > >> Sent: Thursday, March 20, 2025 5:03 PM > >> To: Shameerali Kolothum Thodi > <[email protected]> > >> Cc: Donald Dutile <[email protected]>; [email protected]; > qemu- > >> [email protected]; [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected]; > >> [email protected]; [email protected]; Linuxarm > >> <[email protected]>; Wangzhou (B) <[email protected]>; > >> jiangkunkun <[email protected]>; Jonathan Cameron > >> <[email protected]>; [email protected] > >> 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
