On Thu, Mar 24, 2022 at 4:54 PM Tian, Kevin <kevin.t...@intel.com> wrote:
>
> > From: Jason Wang
> > Sent: Monday, March 21, 2022 1:54 PM
> >
> > This patch introduce ECAP_PASID via "x-pasid-mode". Based on the
> > existing support for scalable mode, we need to implement the following
> > missing parts:
> >
> > 1) tag VTDAddressSpace with PASID and support IOMMU/DMA translation
> >    with PASID
> > 2) tag IOTLB with PASID
>
> and invalidate desc to flush PASID iotlb, which seems missing in this patch.

It existed in the previous version, but it looks like it will be used
only for the first level page table which is not supported right now.
So I deleted the codes.

>
> > 3) PASID cache and its flush
> > 4) Fault recording with PASID
> >
> > For simplicity:
> >
> > 1) PASID cache is not implemented so we can simply implement the PASID
> > cache flush as a nop.
> > 2) Fault recording with PASID is not supported, NFR is not changed.
> >
> > All of the above is not mandatory and could be implemented in the
> > future.
>
> PASID cache is optional, but fault recording with PASID is required.

Any pointer in the spec to say something like this? I think sticking
to the NFR would be sufficient.

> I'm fine with adding it incrementally but want to clarify the concept first.

Yes, that's the plan.

>
> >
> > Note that though PASID based IOMMU translation is ready but no device
> > can issue PASID DMA right now. In this case, PCI_NO_PASID is used as
> > PASID to identify the address w/ PASID. vtd_find_add_as() has been
> > extended to provision address space with PASID which could be utilized
> > by the future extension of PCI core to allow device model to use PASID
> > based DMA translation.
>
> I didn't get the point of PCI_NO_PASID. How is it different from RID_PASID?
> Can you enlighten?
>
> >
> > This feature would be useful for:
> >
> > 1) prototyping PASID support for devices like virtio
> > 2) future vPASID work
> > 3) future PRS and vSVA work
>
> Haven't got time to look at the code in detail. stop here.

Fine.

Thanks

>
> Thanks
> Kevin
>


Reply via email to