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

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

  • To: Roman Shaposhnik <roman@xxxxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Fri, 2 Aug 2019 11:41:43 +0100
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=anthony.perard@xxxxxxxxxx; spf=Pass smtp.mailfrom=anthony.perard@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 02 Aug 2019 10:42:05 +0000
  • Ironport-sdr: GGFKh7brsA8RXLjqHTUfBgU2Y/mSR/zVaDOewQVkiOzwZptJ9iIGWby3aJd+4U5pFevIFZ3Wo8 XUDn/Omc/lYngayRrlzAgbm4tGPirJ9eWTPPoovrhuiUVSUF87x4CxeNI+J4PF98hcbEGezO6/ 1+ccDzWQQXOIsP3YjZZzsi90sfbppl+2Ti0I/5QstvakGgTzFSSWwrkqEmYXofp1xmuVVnjLd/ N2/NrF4lVCHwHbEMW1kd90j0yJ8iKUridoykh6K946uBFmESThH+Gc6Xh7Q8pbwAE2buqr7rYM H+k=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Aug 01, 2019 at 11:00:42AM -0700, Roman Shaposhnik wrote:
> Got it! So please bear with me for a little bit longer: I'm looking at
>      http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=summary
> and I see that it is based on a stock, upstream qemu 4.0.0 with
> just two patches on top:
> http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=9cca02d8ffc23e9688a971d858e4ffdff5389b11
> http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=1bcf484fa9f451cc8c290fe80fd0e764199ca81c
> 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?

So the workflow for qemu-xen is that patches are upstreamed first. Of
the two patches on top of 4.0, one is a simple build fix cherry-picked
from upstream. The other
  main loop: Big hammer to fix logfile disk DoS in Xen setups
isn't going to be upstream, it would need a proper solution provided by
Xen, not QEMU. Xen would needs some kind of daemon to save logs and
rotate them as needed to avoid filling up the disk. Libvirt has that I

> 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?

I think most developers would simply use qemu-xen that comes out of
xenbits (and not necessarily the last version if they didn't update the
qemu-xen clone as the build system doesn't update it).
But, osstest does test qemu-xen and QEMU upstream with Xen.
    - QEMU upstream (called qemu-mainline in osstest), is tested
      regulary with Xen unstable (to be Xen 4.13 currently).
    - qemu-xen is tested with Xen unstable.
    - Xen unstable-staging is tested with qemu-xen (tested version).

As for 'distro QEMU', I don't think any developer can use it. QEMU
needs to be builds against the current version of Xen, or it doesn't

Anthony PERARD

Xen-devel mailing list



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