|
On 16/11/15 00:39, Atom2 wrote:
Am 15.11.15 um 16:12 schrieb Andrew Cooper:
[big snip]
Great - so confirms the issue as a SeaBIOS interaction issue,
rather than a hypervisor regression.
As I said before, I am still certain that a guest should not be
able to get itself into the crashing state (short of a hardware
errata), so I still suspect that there is a latent hypervisor
emulation bug which has been tickled by the SeaBIOS update.
Would you please mind running the bad HVMLoader on Xen 4.5.2
with hvm_debug=0xc3f ? I am still hoping that that will shed
some light on SeaBIOS actions just leading up to the crash.
Hi Andrew,
Please see the attached two files. One is the dmesg from booting
the system. This looks pretty normal in my view. The other is the
output of "xl dmesg" which is most likely what you were after.
It's probably worth noting that the "traps.c" output between lines
259 and 314 and again between lines 346 and 353 seem to be
xen-4.5.2 specific and don't show up under xen-4.5.1, but that may
not be of any relevance for the SeaBIOS issue we are experiencing.
Though I'd still be interested to know whether that's anything for
me to worry about ...
Sorry, but you need to be using a debug build of Xen. The internals
of hvm_debug are not compiled in a regular build.
I am also only interested in `xl dmesg`. There will be lots of log
lines prefixed with [HVM:$DOMID.$VCPUID].
Are you able to experiment with newer versions of Xen? It would
be interesting to see whether the issue is still present in Xen
4.6
Currently xen-4.6 is not stable in gentoo and I try to stick to
stable packages as much as possible. But in case the above does
not help you any further, I am happy to give this a try as well.
Would this just be a straightforward test to see whether it works
at all or would you require debug symbols as well?
That's ok. It is unlikely that this issue has been fixed since, so
I suspect that it is still present.
~Andrew
|
