linux-kernel - Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8e0182b9-7a8b-4388-9f22-c39bfbaf3df1@amd.com>
Date: Wed, 7 May 2025 21:18:29 +1000
From: Alexey Kardashevskiy <aik@....com>
To: Jason Gunthorpe <jgg@...dia.com>, Nicolin Chen <nicolinc@...dia.com>
Cc: kevin.tian@...el.com, will@...nel.org, joro@...tes.org,
 suravee.suthikulpanit@....com, robin.murphy@....com, dwmw2@...radead.org,
 baolu.lu@...ux.intel.com, shuah@...nel.org, linux-kernel@...r.kernel.org,
 iommu@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-kselftest@...r.kernel.org, eric.auger@...hat.com,
 jean-philippe@...aro.org, mdf@...nel.org, mshavit@...gle.com,
 shameerali.kolothum.thodi@...wei.com, smostafa@...gle.com, yi.l.liu@...el.com
Subject: Re: [PATCH v2 06/19] iommufd/viommu: Add
 IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl



On 6/5/25 22:58, Jason Gunthorpe wrote:
> On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
>> On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
>>> On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:
>>>
>>>>> ... and I just hit a problem with it - this is basically guest BDFn
>>>>> and it works as long as I'm hotplugging the TEE-IO VF into an SNP VM
>>>>> but does not when I pass through via the QEMU cmdline - bus numbers
>>>>> are not assigned yet. So I have to postpone the vdevice allocation
>>>>> till run time, did I miss something here? Thanks,
>>>>
>>>> I have a similar case with QEMU ARM64's VM: so vDEVICE on ARM is
>>>> allocated at runtime as well because the BDF number isn't ready
>>>> at the boot time.
>>>
>>> Oh that's ugly then.. So you'll need to add some kind of 'modify
>>> sid/bdf' operation I think.
>>
>> But the initial vDEVICE would be still unusable. Its BDF number is
>> literally 0 in my case. It can't be used for SID-based invalidation
>> nor the reverse vSID lookup for fault injection..
> 
> That's fine, that is actually what it is in the vPCI topology. Until
> the bus numbers are assigned at least.
> 
> So you'd have SID conflicts in the kernel, just pick the first one or
> something until it gets sorted out.
> 
>>> The bus numbers can be reassigned at any time on the fly by the guest
>>> by reprogramming the PCI hierarchy.
>>
>> Yes. If we take some aggressive use case into account, where its
>> BDF number could change multiple times, I think it's natural for
>> VMM to simply destroy the previous vDEVICE and allocate a new one
>> with a new BDF number, right?
> 
> We should not destroy the vdevice for something like that. In a CC
> case that would unplug it from the VM which is not right.

vdevice is not directly seen by the guest, is not it? The guest will see, for example, an "AMD IOMMU" and assume there is device table for all 64K devices, and so on, it is QEMU which will be reallocating vdevice in the host's IOMMUFD. Did I miss something here? Thanks,



-- 
Alexey