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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

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