xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "James Harper" <james.harper@bendigoit.com.au>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: RE: PoD in other (not GPLPV) drivers
Date: Mon, 28 Feb 2011 23:28:44 +1100	[thread overview]
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01C55A30@trantor> (raw)
In-Reply-To: <291EDFCB1E9E224A99088639C47620228D3EDCA7C9@LONPMAILBOX01.citrite.net>

> 
> I actually have plans to push it earlier because we balloon down quite
late at
> the moment (off the back of the START IRP in the top level bus
driver). We are
> reliant upon zero-page sweeping code in Xen to save us from guest
crashing up
> to that point.
> 

I've modified GPLPV to balloon down at DriverEntry time, which seems to
be early enough. Prior to that, memory=128 and maxmem=1024 was enough to
cause a crash under 2008, basically as soon as I tried to access the
registry in DriverEntry. My drivers are using WDF and are therefore
loading after the KMDF framework which is going to use additional
resources. My backup plan is to write a WDM driver that loads even
earlier than that and does the allocation, passing it to the real PV
drivers later on, although my concern there is that Windows may not like
memory allocated by one driver being freed by another...

I've never heard of 'zero-page sweeping code' before... is that a way of
xen reallocating a previously touched page if it contains all 0's if we
want a page beyond our allocation limit? That might explain why my
initial balloon down is so slow! I can tell windows to not zero pages
before it gives them to me when I do the initial balloon down... what
are your thoughts on that? Although it's unlikely at boot time, in
theory they could contain sensitive information and I'm supposed to zero
them before handing them back to xen according to the docs.

James

  reply	other threads:[~2011-02-28 12:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AcvWIEDjcPpdP6eLTlqDXQDFzQWlHw==>
2011-02-27  1:47 ` PoD in other (not GPLPV) drivers James Harper
2011-02-28 11:59   ` George Dunlap
2011-02-28 12:17     ` Paul Durrant
2011-02-28 12:28       ` James Harper [this message]
2011-02-28 13:41         ` Paul Durrant
2011-02-28 14:17           ` George Dunlap
2011-02-28 22:09             ` James Harper
2011-02-28 22:20     ` James Harper
2011-03-03  9:58       ` George Dunlap
2011-03-03 10:22         ` James Harper
2011-03-03 11:30           ` Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AEC6C66638C05B468B556EA548C1A77D01C55A30@trantor \
    --to=james.harper@bendigoit.com.au \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).