[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [BUG] Assertion failed: !blk->legacy_dev

On Thu, Aug 1, 2019 at 10:44 AM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 01/08/2019 18:35, Roman Shaposhnik wrote:
> > On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD <anthony.perard@xxxxxxxxxx> 
> > wrote:
> >> On Wed, Jul 31, 2019 at 01:11:22PM -0700, Roman Shaposhnik wrote:
> >>> Hi!
> >> Hi Roman,
> >>
> >> Thanks for the bug report!
> >>
> >> That bug (technical debt really) was fixed in QEMU 4.0 (so will be fixed
> >> in Xen 4.13). It's a series of patch with the last one been db9ff46 if
> >> you want to have a look.
> > Got it! Is there any quick way how I can check that this, indeed, solves
> > our problem and I can remove the out-of-tree patch? I just really
> > want to make sure that when 4.13 comes out -- the issue is fixed.
> >
> > I'm still a little bit new to Xen development, so I guess I need to combine:
> >      http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
> >      http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=summary
> > somehow to get the same tree I get when I download an official release?
> >
> > Is there a script or better yet a nightly build of some sort?
> So this is an area of the Xen build system which all distro downstreams
> hate and work around.
> Distros don't ship two verisons of qemu, and don't want Xen to have its
> own private version.  The current behaviour is somewhere between "thats
> how it was always done" and a convenience for developers.
> The common solution is to build the Xen tools with
> ./configure --with-system-qemu=/usr/lib64/xen/bin/qemu-system-i386
> (path as appropriate for dom0) which tells xl(/libxl? I forget which)
> where to find qemu, but otherwise keeps it as an independent component.

Got it! So please bear with me for a little bit longer: I'm looking at
and I see that it is based on a stock, upstream qemu 4.0.0 with
just two patches on top:

So here's my question: when there's time to release Xen 4.13, is the
expectation for these patches to get upstreamed into a particular patch
release of qemu 4.0.x or that distros (like ourselves) will be on the hook
of lifting those patches off of Xen tree and merging in whatever version
of qemu 4.y they ship?

Also, in terms of testing, what does the majority of folks who will be working
on Xen 4.13 release be testing it with? qemu that comes out of xenbits.xen.org,
upstream qemu + custom patches, distro QEMU, something else?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.