[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-ia64-devel] PATCH: cleanup of tlbflush
On Thu, May 11, 2006 at 09:26:28AM +0800, Tian, Kevin wrote: > >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. > > >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. I agree with you that a simple and certain way should be adopted as a first step and that complex and uncertain thing should be examined later. In this case it is that xen should be given virtual addresses to flush trusting dom0. I have to admit that tracking virtual addresses would require complex coding. I'm not sure its gain neigher. -- yamahata _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |