On 01/08/2019 18:35, Roman Shaposhnik wrote: > On Thu, Aug 1, 2019 at 3:30 AM Anthony PERARD <anthony.per...@citrix.com> > 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
