On Fri, Dec 15, 2023 at 12:01:19PM +0800, Yi Liu wrote:
On 2023/12/15 11:32, Nicolin Chen wrote:
On Fri, Dec 15, 2023 at 03:04:44AM +0000, Tian, Kevin wrote:
From: Nicolin Chen nicolinc@nvidia.com Sent: Friday, December 15, 2023 10:28 AM On Fri, Dec 15, 2023 at 01:50:07AM +0000, Tian, Kevin wrote:
From: Liu, Yi L yi.l.liu@intel.com Sent: Thursday, December 14, 2023 7:27 PM
On 2023/11/17 21:18, Yi Liu wrote:
and for this error reporting case what we actually require is the reverse map i.e. pRID->vRID. Not sure whether we can leverage the same RID mapping uAPI as for ARM/AMD but ignore viommu_id and then store vRID under device_domain_info. a bit tricky on life cycle management and also incompatible with SIOV...
One thing that I am not very clear here: since both vRID and dev_id are given by the VMM, shouldn't it already know the mapping if the point is to translate (pRID->)dev_id->vRID?
it's true for current Qemu.
but there is plan to support Qemu accepting a fd passed by Libvirt. In that case Qemu even doesn't see the sysfs path hence is not aware of pRID. otherwise yes we could leave the translation to VMM instead.
I think I misread Yi's narrative: dev_id is a working approach for VMM to convert to a vRID, while he is asking for a better alternative :)
In concept, dev_id works, but in reality we have problem to get a dev_id for a given device in intel iommu driver, hence I'm asking for help here. :)
Yea, I got that.
Would it be possible for us to postpone this error report in the vtd driver?
Jason is taking vacation, so he'll unlikely be very active until the new year, although he would probably spare some time taking the cache_invalidate series once it's mature.
If the final solution is to use pRID<->vRID mappings for vtd too, we'd likely need the viommu/dev_set_virtual_id series that I am still working on, which certainly won't make it to this cycle.
Thanks Nic