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