WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [Patch] Qemu map cache

To: "Anthony Liguori" <aliguori@xxxxxxxxxxxxxxxxxx>, "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [Patch] Qemu map cache
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 6 Dec 2006 00:33:53 -0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Delivery-date: Tue, 05 Dec 2006 16:34:26 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <666CC8FCE3247C4DA876BA979059781A5C27DD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4574A813.5050402@xxxxxxxxxxxxxxxxxx> <8A87A9A84C201449A0C56B728ACF491E04EDB4@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4575DB09.7000105@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccYrrk8xAzIatr0Rb6iNGmaLgoDhAAHpLIA
Thread-topic: [Xen-devel] [Patch] Qemu map cache
> > Being able to invalidate (sections of) qemu's mappings (at least
> > asynchronously) is essential to allow the balloon driver to work for
HVM
> > guests.
> 
> To be able to change portions of the physical memory mapping right?
You
> don't strictly need a map cache for this (you can simply remap
portions
> of the address space). 

Yes (where remap includes 'unmap')

> You really only need the map cache for > 2GB
> guests (which admittedly could be a ballooned down guest that started
> out > 2GB).

One could argue that for large memory guests having a mapping of all of
guest memory is 'wasteful' anyhow, not that page tables take up that
much space. It's probably good hygiene to only map what you need.

> >  V2E is going to have to bite the bullet on this one.
> >
> > Of course, in a 64b environment the map cache can be direct mapped,
but
> > you still need the ability to do invalidates. BTW: I'm comfortable
if
> > V2E only works on 64b.
> 
> We may be able to work around this using one of QEMU's TLB.  If the
map
> cache goes in for 3.0.4, then we can look at just supporting 64 bit
for
> 3.0.5 and fixing 32 bit post 3.0.5 (if that's necessary).  Sound like
a
> reasonable plan?

If necessary, however I still like the mapcache approach. I think
running a 32b dom0 on a 64b hypervisor is actually going to be a pretty
common way of running things (likely gives best performance). 

Ian

> Regards,
> 
> Anthony Liguori
> 
> >  Sooner or latter there's going to be some new
> > feature which isn't supported on Yonah...
> >
> > Ian
> >


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