Re: [Xen-devel] map memory holes with same page

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

Surprisingly, resume from hibernate is very fast. Maybe windows knows the pages 
are already scrubbed or something...

I've asked the "don't hibernate these pages" question on ntdev but I think 
they're sick of my absurd questions :)

Sent from my iPhone

On 23/05/2011, at 20:37, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:

> At 11:29 +0100 on 23 May (1306150145), James Harper wrote:
>> I guess the only way to solve this is to stop every access hitting an
>> emulation. Either I can map a common read-only page into every hole
>> (which doesn't sound like a workable solution based on feedback so far),
>> or Xen could keep a common read-only page and map it into a hole every
>> time it is accessed (and then move the page when another hole is
>> accessed), which would reduce the problem to emulation on the first time
>> a different hole is accessed...
> 
> That's pretty ugly, though.  Is there really no way to tell Windows not
> to bother hibernating your ballooned-out memory?  Surely there must be
> equivalent cases in real hardware: GART framebuffers and so on?
> 
> What happens when Windows tries to load all your ballooned memory back
> in on resume, btw?  Will it uncompress all those frames back onto
> non-existent RAM?  (i.e. would we have to have this scratch frame be
> writable - and if so would we need to properly discard writes to
> correctly emulate missing RAM?)
> 
> Cheers,
> 
> Tim.
> 
> -- 
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, Xen Platform Team
> Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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