From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 Date: Mon, 16 Nov 2015 23:01:56 +0000 Message-ID: <564A6064.4080800@citrix.com> References: <5644A248.1060505@web2web.at> <5644C1CD.3020202@citrix.com> <56451A2B.9090706@web2web.at> <56459E5F02000078000B4944@prv-mh.provo.novell.com> <5645B6BC.6030603@citrix.com> <56467D44.5040205@web2web.at> <56479A6B.6080102@citrix.com> <5647CE57.50209@web2web.at> <5648E727.6080204@cardoe.com> <56492BDF.5030208@web2web.at> <20151116153107.GD13720@char.us.oracle.com> <564A2B91.2090501@web2web.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <564A2B91.2090501@web2web.at> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Atom2 , Konrad Rzeszutek Wilk Cc: Doug Goldstein , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 16/11/2015 19:16, Atom2 wrote: > > > Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: >>>>> Your analysis was absolutely spot on. After re-thinking this for a >>>>> moment, I thought going down that route first would make a lot of >>>>> sense >>>>> as PV guests still do work and one of the differences to HVM domUs is >>>>> that the former do _not_ require SeaBIOS. Looking at my log files of >>>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to >>>>> 1.8.2 in >>>>> the relevant timeframe which obviously had not made it to the >>>>> hvmloader >>>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of >>>>> SeaBIOS. >>>>> >>>>> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS >>>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that >>>>> seemed >>>>> to strongly indicate that there indeed might be an issue with >>>>> SeaBIOS as >>>>> this probably was the only variable that had changed from the >>>>> original >>>>> install of xen-4.5.1. >> I recall seeing this way back in Fedora 20 days. I narrowed it down the >> SeaBIOS version that was a standalone package to not have CONFIG_XEN. >> >> Having that fixed in the SeaBIOS package fixed it. > Hi Konrad, Doug, Andrew (specifically added to this part of the thread)! > Konrad, you might have found an interesting point. I did have a look > at the ebuild for the failing version and in there I found the > following comment: > ====== comment from ebuild ======= > # Upstream hasn't released a new binary. We snipe ours from > Fedora for now. > # http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz > ====== end comment from ebuild ======= > which might in fact underline that there might be an issue similar to > what you described above. > > What is also pretty interesting is the fact that the old (working) > SeaBIOS version 1.7.5 installed as "bios.bin" under /usr/share/seabios > is actually 262.144 bytes in size whereas the new (invalid) SeaBIOS > 1.8.2 installed in the same location is only half as big: 131.072 bytes. > > I checked at the download site and the 1.8.2 binary version is indeed > not available from http://code.coreboot.org/p/seabios/downloads/. But > both the binary versions for 1.7.5 and 1.8.0 are available and both > are acutually 262.144 bytes in size, so I'd be very surprised if the > 1.8.2 version is really only half that size. By the way, the old > working version (according to the ebuild) was directly downloaded from > the above url and also shows an identical SHA1 digest to that version > available for download there. > > To me this looks as if something is really wrong here. If anybody of > you has access to a 1.8.2 version, could you please confirm whether > there's really that big a size difference between the 1.7.5 and the > 1.8.2 versions? Or is that difference probably attributable to the > missing CONFIG_XEN option? > > Andrew: I havent't gotten around to run the debug version of the > hypervisor again, but if the current suspicion turns out to be true, > there's probably not much value in that anyways. Would you agree? Sadly not. I accept that this issue is possibly fixed in newer SeaBIOS by working around the issue. However, I stand by my original point. *There is no way the guest should be able to get into this situation in the first place*, and its implication of *there is a genuine hypervisor bug which we should track down*, irrespective of whether the issue has been worked around elsehow. ~Andrew