OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [RFC] virtio-iommu version 0.5


On 25/10/17 12:05, Linu Cherian wrote:
>>> Also does this solution intend to cover the page table sharing of non SVM 
>>> cases. For example, if we need to share the IOMMU page table for 
>>> a device used in guest kernel, so that map/unmap gets directly handled by the guest
>>> and only TLB invalidates happens through a virtio-iommu channel.
>>
>> Yes for non-SVM in SMMuv3, you still have a context table but with a
>> single descriptor, so the interface stays the same. 
> 
> So for non SVM case, 
> guest virtio-iommu driver will program the context descriptor such a way that,
> ASID is not in shared set(ASET = 1b) and hence Physical IOMMU TLB invalidates would get triggered 
> from software for every viommu_unmap(in guest kernel) through Qemu(using vfio ioctls) ? 

That's right. viommu_unmap will send an INVALIDATE request on the virtio
request queue, forwarded to the driver via a VFIO ioctl.

> And for SVM case, ASID would be in shared set and explicit TLB invalidates 
> are not required from software ?

Yes, although that's only true for integrated devices (non-PCI). On PCI,
devices will have an ATC (a device IOTLB), in which case we still have to
send an invalidation request through virtio and then VFIO, so that the
SMMU driver sends an CMD_ATC_INV.

Thanks,
Jean



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]