Re: XenServer Xen-4.5 (-rc3ish) testing

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 08/12/2014 20:00, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 07:03:19PM +0000, Andrew Cooper wrote:
>> Hi,
> Hey Andrew!
>> Over the weekend, XenServer testing managed to run a side-by-side test
>> of XenServer trunk and XenServer experimental xen-4.5.  These are
>> identical other than the version of Xen (and associated libraries) in
>> use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
>> other than as linked against newer Xen libraries.
>>
>> The Xen-4.5 tests were on top of c/s e6c3d371d4 "systemd: use pkg-config
>> to determine systemd library availability"
>>
>> There are a few notable issues exposed:
>>
>> 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.
> I presume the daemon also does 'XEN_DOMCTL_iomem_permission' to grant
> the other domain access to its RAM? And before it makes the
> XEN_DOMCTL_memory_mapping hypercall.

This is purely an implementer of the ioreq server infrastructure
providing an emulated set of BARs in the guest as qemu would, but
without using dom0 map-foreign powers.  The gfn ranges in question are
regular guest RAM as far as I am aware, and should not require any
special io permissions.

Either way, the identified changeset has apparently caused a regression,
but I am not yet certain whether it is legitimately disabling something
which should not have worked in the first place, or whether it is a
change which needs reconsidering.

>
>> Migrations from older Xens to Xen-4.5 fairly reliably crash domains (90%
>> of the time, both PV and HVM guests).  This includes migrates from older
>> XenServers using the legacy->v2 migration code which is confirmed-good
>> in "upgrade to Xen-4.4" case.  The migration v2 code in use is identical.
> The XenServer is not using the in-the-tree migration system except in
> the older version of XenServer right?

XenServer expermental-4.5 is strictly using migration v2, including
upgrade from legacy, but as far as I am aware identical migration v2 as
our current Xen-4.4 trunk which works fine for all tests.

>> 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.
> Hardware specific is good. Could you give some ideas of what make/model
> this is?

They are all IBM blades to the best of my knowledge, which are a similar
system to the hardware which gave me 1ed7679 to debug, so I am hoping it
is a latent BIOS issue and not a Xen 4.5 issue.

~Andrew