Re[2]: [Qemu-devel] Storing code caching

[Igor Shmukler]

> I think a more interesting idea is to 'virtualize' the memory.... That
> is, we provide a means for a guest to request more physical memory and
> to be able to release that memory back to the host... Perhaps also some
> method in which the host can warn the guest of low memory situations so
> that the guest can be more aggressive on memory reclaiming.
> 
> Of course, this optimization would require changes to the guest OS to
> take advantage of it but it would mean that the guest would no longer
> have to worry about swap pressures and that the host can perform the
> swapping on behalf of the guest - this would be much faster as the
> guest's virtual hardware will be much slower to swap to than the hosts'
> real hardware.
> 
> This communication mechinism has to be well defined and audited as it
> could potentially allow the guest the ability to 'break out' of it's
> box. I would suggest that the best way would be to make the
> communication channel look like some piece of hardware - but there are
> other options available - such as magic opcodes...

VMWare developed a solution for this issue a while ago. They described a 
technique called balooning at the OSDI'02. Their approach allows to address 
issues you raised without modifications to the guest OS.
All the is needed is a baloon driver.

I don't see how it would help with caching execution profile, though.

IS.