RE: [RFC v3 14/25] intel_iommu: add virtual command capability support

[Liu, Yi L]

> From: Peter Xu < address@hidden >
> Sent: Thursday, February 13, 2020 11:09 PM
> To: Liu, Yi L <address@hidden>
> Subject: Re: [RFC v3 14/25] intel_iommu: add virtual command capability 
> support
> 
> On Thu, Feb 13, 2020 at 09:31:10AM -0500, Peter Xu wrote:
> 
> [...]
> 
> > > > Apart of this: also I just noticed (when reading the latter part of
> > > > the series) that the time that a pasid table walk can consume will
> > > > depend on this value too.  I'd suggest to make this as small as we
> > > > can, as long as it satisfies the usage.  We can even bump it in the
> > > > future.
> > >
> > > I see. This looks to be an optimization. right? Instead of modify the
> > > value of this macro,  I think we can do this optimization by tracking
> > > the allocated PASIDs in QEMU. Thus, the pasid table walk  would be more
> > > efficient and also no dependency on the VTD_MAX_HPASID. Does it make
> > > sense to you? :-)
> >
> > Yeah sounds good. :)
> 
> Just to make sure it's safe even for when the global allocation is not
> happening (full emulation devices?  Do they need the PASID table walk
> too?). 

I'd say no. For full emulation devices, just needs to ensure the pasid cache
is latest (do what guest told). Even the invalidation flushes too much cache,
it just affects the performance but no correctness issue.  This is different
with passthru devices, if unbind too much, it means some passthru devices
may encounter DMA  fault later.

> Anyway, be careful to not miss some valid PASID entries, or we
> can still use the MIN(PASID_MAX, CONTEXT_ENTRY_SIZE) to be safe as a
> first version.  Thanks,

Agreed. First version to ensure 100% safe.

Regards,
Yi Liu