On 3/24/25 2:55 PM, Shameerali Kolothum Thodi wrote:
> 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.
Agreed. I just meant discriminating between devices that can bring
trouble and others may require some caution
Eric
>
> Thanks,
> Shameer
>
>
>
