RE: [RFC PATCH v2 05/20] hw/arm/smmuv3-accel: Associate a pxb-pcie bus

Mon, 24 Mar 2025 09:07:13 -0700 


> -----Original Message-----
> From: Nicolin Chen <[email protected]>
> Sent: Monday, March 24, 2025 4:02 PM
> To: Eric Auger <[email protected]>
> Cc: Shameerali Kolothum Thodi
> <[email protected]>; Donald Dutile
> <[email protected]>; [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 Mon, Mar 24, 2025 at 02:13:20PM +0100, Eric Auger wrote:
> > >> 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.
> 
> Hmm, that sounds troublesome. IORT mappings are done using the bus
> number, which is fixed to a vSMMU. Can we disable that reordering?

DSM 5# is actually a way to do that. But I don't think we need that as host
kernel also will have the same issues with IORT if re enumeration happens.
I think the iommu_fwspec mechanism is to take care of this. I need to double
check though.
 
Thanks,
Shameer
























					Reply via email to