[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> >> On October 01, 2015, at 5:09 PM <tim@xxxxxxx> wrote:
> At 15:05 +0000 on 30 Sep (1443625549), Xu, Quan wrote:
> > >> >>> On September 29, 2015, at 5:12 PM, <tim@xxxxxxx> wrote:

> > Could I introduce a new typed reference which can only been deref in
> > QI interrupt handler(or associated tasklet)?? --(stop me, I always want to 
> > add
> some new flag or typed ..) And preventing changes of ownership/type on the
> relevant pages.
> 
> If you get_page_and_type(PGT_writable_page), then that guarantees that the
> page won't change type or be freed until the matching put_page_and_type(),
> which does what you want.  Likewise, for read-only mappings, get_page() will
> guarantee that the page isn't freed until you call put_page().  (We don't care
> about read-only DMA mappings of specially-typed pages so you don't need a
> typecount there).
> 
Thanks for your further clarification.

> That leaves three questions:
>  - when to take the references?
>  - how do you know when to drop them?
>  - what to do about mappings of other domains' memory (i.e. grant
>    and foreign mappings).
> 

I think this are the key points. Look at the below answers.

> IIUC your current scheme is to take the reference as the page is freed and 
> drop it
> after the flush.

Yes,

> That's not enough for pages where permissions change for
> other reasons, so it will at least have to be "take the reference when the 
> IOMMU
> entry is removed/changed".  IMO that's sufficiently invasive that you might as
> well:
>  - take the reference when the IOMMU entry is _created_;
>  - log (or something) when the IOMMU entry is removed/overwritten; and
>  - drop the entry when the flush completes.


__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.]

That leaves one question:
    -- how to do with hot-plug ATS device pass-through? As the EPT doesn't 
aware IOMMU will share EPT page table when EPT page table was _created_.

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.
   
   -- We can add a new page_list_entry structure per page_info, and Add the 
page with the new page_list_entry structure to per domain page list, when
    the IOMMU entry is removed/overwritten; and drop the entry when the flush 
completes. 

Q3: what to do about mappings of other domains' memory (i.e. grant and foreign 
mappings).
   Between two domains, now I have only one idea to fix this tricky issue -- 
waitqueue.
   I.e. grant.
    For gnttab_transfer /gnttab_unmap , wait on a waitqueue before updating 
grant flag, until the Device-TLB flush is completed.
    For grant-mapped, it is safe as the modification of gnttab_unmap.



__scheme B__
Q1: - when to take the references?

    take the reference when the IOMMU entry is _ removed/overwritten_;
    in detail:
     --iommu_unmap_page(), or
     --ept_set_entry() [Once IOMMU shares EPT page table.]

    * Make sure IOMMU page should not be reallocated for
     another purpose until the appropriate invalidations have been
     performed. 
    * in this case, it does not matter hot-plug ATS device pass-through or ATS 
device assigned in domain initialization.

Q2 / Q3: 
    The same as above __scheme A__ Q2/Q3.

One question: is __scheme B__ safe? If it is safe, I prefer __scheme B__..



Tim, thanks very much!


Quan



> 
> Like other schemes (I'm thinking about the p2m foreign mapping stuff
> here) the reference counting is best done at the very bottom of the stack, 
> when
> the actual entries are being written and cleared.  IOW I'd be adding more code
> to atomic_write_ept_entry() and friends.
> 
> Cheers,
> 
> Tim.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.