>>> On 08.12.14 at 20:03, <andrew.coop...@citrix.com> wrote: > XEN_DOMCTL_memory_mapping hypercall fails with EPERM where it didn't in > xen-4.4, given identical parameters. The hypercall gained an extra > permission check as part of 0561e1f01e. Our usecase here is a daemon in > dom0 mapping guest RAM to emulate a graphics card, but I currently don't > see how that is incompatible with the new permissions check.
This seems quite obvious: The added check makes sure that what gets mapped is I/O memory both domains have access to, yet you say the daemon maps guest RAM. What I can't see is why you need this hypercall in this case - given what you say it's certainly not meant for the daemon to map memory into the guest? Mapping guest RAM ought to work via the privcmd kernel interface. > We have certain machines which are showing reliable failure to boot > under Xen-4.5, where they worked with 4.4. Symptoms range from the dom0 > kernel crashing before printing anything, to complaining that the initrd > is corrupt when attempting to decompress. This appears to be hardware > specific. Any chance this is C-state related, just like narrowed down to for http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00228.html? I.e. Westmere Xeons being affected? If not, this would seem rather worrying to me (read: a release blocker). And even if so, a workaround would be minimally needed. Otoh you didn't report so for earlier RCs - was that just because the testing scope was more narrow then, or can we imply that this is a recently introduced regression? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
