[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] When would Xen reset page access rights for a non-migrating guest?
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |