Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.12.14 at 20:03, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel