From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: When would Xen reset page access rights for a non-migrating guest? Date: Thu, 20 Mar 2014 18:22:50 +0000 Message-ID: <532B31FA.1000208@citrix.com> References: <20140320170354.GF68664@deinos.phlegethon.org> <532B2FCC.7060707@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <532B2FCC.7060707@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Razvan Cojocaru Cc: Tim Deegan , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 20/03/14 18:13, Razvan Cojocaru wrote: > 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. Tmem is not compiled into Xen for XenServer. What sort of quirks are you on about? > > 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 Trying to use any of those should result in an -ENOSYS. > >> 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 Given the default setup, there will almost certainly be PoD, and probably also be some Ballooning in there. ~Andrew