On 09/11/2023 13:09, Jason Gunthorpe wrote:
> On Thu, Nov 09, 2023 at 01:03:02PM +0000, Joao Martins wrote:
>
>>> I am not talking about mdevs; but rather the regular (non mdev) case not
>>> being
>>> able to use dirty tracking with autodomains hwpt allocation.
>>
>> ... without any vIOMMU.
>
> Ah, well, that is troublesome isn't it..
>
> So do we teach autodomains to be more featured in the kernel or do we
> teach the generic qemu code to effectively implement autodomains in
> userspace?
The latter is actually what we have been doing. Well I wouldn't call autodomains
in qemu, but rather just allocate a hwpt, instead of attaching the IOAS
directly. But well mdevs don't have domains and we overlooked that. I would turn
the exception into an exception rather than making the norm, doesn't look to be
much complexity added?
What I last re-collect is that autodomains represents the 'simple users' that
don't care much beyond the basics of IOMMU features (I recall the example was
DPDK apps and the like). You could say that for current needs IOMMU autodomains
suffices for qemu.
For more advanced features we have advocating into our new iommu domain
manipulation i.e the more advanced API or manipulation domain objects. Nesting
is obviously the one that stresses 99% of the hwpt APIs (beyond alloc), and the
other one has been dirty tracking as the domain is where we enforce current
device support and future device attachments.
Connecting autodomains to this enforcing on the hwpt is relatively simple btw,
it just needs to connect the dirty tracking flag with same semantic of
hwpt-alloc equivalent and pass the hwpt flags into the domain allocation.
It's more of what of a question should be the expectations to the user when
using ATTACH_HWPT with an IOAS_ID versus direct manipulation of HWPT. I am
wondering if dirty tracking is alone here or whether there's more features that
start to mud the simplicity of autodomains that would approximate of hwpt-alloc.
Joao
