[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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
> > guests.
> To be able to change portions of the physical memory mapping right?
> don't strictly need a map cache for this (you can simply remap
> 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,
> > you still need the ability to do invalidates. BTW: I'm comfortable
> > V2E only works on 64b.
> We may be able to work around this using one of QEMU's TLB.  If the
> cache goes in for 3.0.4, then we can look at just supporting 64 bit
> 3.0.5 and fixing 32 bit post 3.0.5 (if that's necessary).  Sound like
> 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). 


> 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.