Re: [Xen-ia64-devel] PATCH: cleanup of tlbflush

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Jeudi 11 Mai 2006 03:26, Tian, Kevin a écrit :
> From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>
> >Sent: 2006年5月11日 0:01
> >
> >> The key point is to pass in the gva address (host_addr) which is
> >> previously mapped to granted frame. It's guest's responsibility to
> >
> >record
> >
> >> those mapped address and then passed in at unmap request. For
> >> example, xen/x86 use pre-allocated virtual address range while
> >
> >xen/ia64
> >
> >> uses identity-mapped one. It's current para-driver style and we can
> >> trust domain since guest needs to be cooperative or else domain itself
> >> is messed instead of xen.
> >>
> >> Isaku, how about your thought on it?
> >
> >I don't think that tracking virtual address cause much performance loss.
> >At least for vbd.
>
> My point is, current para-driver already tracks virtual address in domain,
> and we can do quick efficient support by simply implementing
> destroy_grant_host_mapping to purge vhpt entry based on passed gva
> upon receiving unmap request. If you suggestion about track in xen really
> helps, that's a common enhancement which should be added for all but
> can be done later.
>
> I think the logic here is simple: domain assigns a virtual address to map
> granted frame, and then later domain itself passes in same virtual address
> to unmap granted frame. Xen simply helps domain upon its request.
However we can't trust domU.  This model is too simple from a security point 
of view.

> >The reason is that a underlying block device doesn't need to
> >read its data. Then unmapping such a granted page doesn't require
> >any flush. (I'm just guessing. The md driver or lvm may read its
> >contents to calculate checksum though.)
> >We can enhance grant table to allow no-read/no-write(dma-only)
> >mapping.
>
> That's OK to add to common code, if necessarily helps. But anyway,
> there's no reason for flush_tlb_mask to purge whole VHPT tables, which
> is overkill. First step I think is to follow syntax of unmap ops structure
> which already ensures more efficiency than current flush all style and
> it's easy.

Tristan.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel