All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rzvncj@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: When would Xen reset page access rights for a non-migrating guest?
Date: Thu, 20 Mar 2014 20:13:32 +0200	[thread overview]
Message-ID: <532B2FCC.7060707@gmail.com> (raw)
In-Reply-To: <20140320170354.GF68664@deinos.phlegethon.org>

Hello Tim, thanks for answering!

>> However, it seems that once in a great while, after setting access
>> rights, something happens that allows unnotified writes to these
>> pages. Working under the assumption that it might have something to do
>> the the live-migration mechanism, I've set "nomigrate = 1" in the
>> guest's configuration file. When that did not work, I even called
>> xc_domain_disable_migrate() from my application, again to no avail.
> 
> Is there some higher-level thing you can do to make sure the VM isn't
> getting migrated/saved/restored?  Or conversely, have you any reason
> to believe that that's what's happening?

Well, I'm sure that the guest is not actually being migrated at the
time, and as I've said I've done my best to completely disable migration
for it, but I've ruled out everything else I could think of, and that's
what's left. I don't seem to be losing any events because of the
mem_event mechanism (if I understand it correctly, the VCPU is paused
until the event is handled, and also if the ring buffer is full), the
page access rights are properly being set.

Again, I'm open to (thankful for) suggestions.

>> I also though it might have something to do with balooning, but the
>> only memory-related keyword in my guest's configuration file is
>> "memory = 2048" (no maximum memory specified that would hint towards
>> ).
> 
> AFAIK the guest could still be ballooning; in any case the interaction
> with ballooning seems like one you should test and fix. :)  It should
> be mostly working already, I think: pages added during ballooning will
> get the default mem-access settings (but will have undefined contents).

I'll take a look there, thanks.

>> It probably has something to do with the code in tmem.c
>> (save/restore). What could cause this?
> 
> That's very unlikely unless you've specifically turned tmem on.

Ah, but I'm not using the vanilla Xen 4.3 release. I'm using a Citrix
XenServer development snapshot from late last year (back when they made
the source code freely available). It's got quite a few quirks of it's
own, and I'm afraid active tmem might be one of them.

Running xl does show tmem parameters:

# xl | grep tmem
  tmem-list           List tmem pools
  tmem-freeze         Freeze tmem pools
  tmem-thaw           Thaw tmem pools
  tmem-set            Change tmem settings
  tmem-shared-auth    De/authenticate shared tmem pool
  tmem-freeable       Get information about how much freeable memory
                      (MB) is in-use by tmem

> I think the most likely thing is some path that writes to guest memory
> without being explicitly a CPU->RAM write from the guest.  E.g. a guest
> with PV drivers making a hypercall that copies some results back, or
> some emulated DMA, or the guest has granted write access to another VM.

These were all Windows HVM guests. No PV or special drivers involved
whatsoever.


Thanks,
Razvan

  reply	other threads:[~2014-03-20 18:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 12:42 When would Xen reset page access rights for a non-migrating guest? Razvan Cojocaru
2014-03-20 17:03 ` Tim Deegan
2014-03-20 18:13   ` Razvan Cojocaru [this message]
2014-03-20 18:22     ` Andrew Cooper
2014-03-20 18:30       ` Razvan Cojocaru

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=532B2FCC.7060707@gmail.com \
    --to=rzvncj@gmail.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.