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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of Andrew Cooper
> Sent: 09 December 2014 00:21
> To: Konrad Rzeszutek Wilk
> Cc: Xen-devel List
> Subject: Re: [Xen-devel] XenServer Xen-4.5 (-rc3ish) testing
> 
> 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.

IIRC the ranges in question are sections of BAR on the GPU which the dom0 code 
is trying to inject into the guest.

  Paul

> 
> 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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel