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

[Tim Deegan <tim@xxxxxxx>]

Hi,

At 15:05 +0000 on 30 Sep (1443625549), Xu, Quan wrote:
> >> >>> On September 29, 2015, at 5:12 PM, <tim@xxxxxxx> wrote:
> > So you'll need to do something else to make the unmap safe.
> >The usual
> > method in Xen is to hold a reference to the page (for read-only
> > mappings)
> 
> 
> Read-only mapping refers to 'PGT_pinned'?

Read-only mappings usually take an 'untyped' reference, with
get_page().  Read-write mappings take one of those plus a typecount
reference for type PGT_writable_page (i.e. get_page_and_type()).  The
reference counts are described in a comment which is currently at the
top of xen/arch/x86/mm.c, but which is mostly talking about PV memory
management.

The PGT_pinned bit is not relevant here - it's used to indicate that a
PV _guest_ has asked for a page to have a particular type (useful for
PV pagetables).

> 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).

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).

IIUC your current scheme is to take the reference as the page is freed
and drop it after the flush.  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.

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