Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

["Xu, Quan" <quan.xu@xxxxxxxxx>]

>> >>>On 13.10.2015 at 17:35, <tim@xxxxxxx> wrote:
> At 11:09 +0000 on 11 Oct (1444561760), Xu, Quan wrote:


> What in particular is worrying you about scheme A?  AFAICS you need to build
> the same refcount-taking mechanism for either scheme.
> 
> Is it the interactions with other p2m-based features in VMs that don't have
> devices passed through?  In that case perhaps you could just mandate that ATS
> support means no shared HAP/IOMMU tables, and do the refcounting only in the
> IOMMU ones?
> 

I am worrying that I should keep a log of all relevant pending derefs and to be 
processed when the flush completes for __scheme_A__..
Now I know only need the log/deref whenever you need to flush the IOMMU. :):)


> >  I think __scheme_A__ is complex to keep a log of all relevant pending
> > derefs, and to be processed when the flush completes;
> >
> > optimized __scheme_A__:
> > It could keep a log of the reference only when the IOMMU entry is _
> removed/overwritten_.(if the IOMMU entry is not _ removed/overwritten_, it is
> safe.).
> 
> Yes, though I'd add any change from read-write to read-only.
> Basically, you only need the log/deref whenever you need to flush the
> IOMMU. :)
> 

A summary of __scheme_A__:

 Q1: - when to take the references?
     take the reference when the IOMMU entry is _created_;
     in detail:
      --iommu_map_page(), or
      --ept_set_entry() [Once IOMMU shares EPT page table.]

 Q2: how do you know when to drop them?
    - Log (or something) when the IOMMU entry is removed/overwritten; and
    - Drop the entry when the flush completes.
    in detail:
       --iommu_unmap_page(); or
       --ept_set_entry() [Once IOMMU shares EPT page table.]


   **The challenge: how to log when IOMMU entry is removed/overwritten?



 Q3: what to do about mappings of other domains' memory (i.e. grant and
 foreign mappings).

i.e. grant:
    -Take the reference when the IOMMU entry is _created_;
    then,
    -Queue the reference drop;and
    -Queue grant iflag update(only for grant_unmap and grant_transfer are 
enough -- we can hold on this question).



 __afaics__:
       1. Are Q1/Q2/Q3 enough for this memory security issue?
       2. Are there any other potential memory issues, when I finish  
__scheme_A__?
       3. Do you have any idea how to log when IOMMU entry is 
removed/overwritten?
      
Tim, thanks for your help!


Quan






























_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel