This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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