On 14/11/2015 00:16, Atom2 wrote:

Am 13.11.15 um 11:09 schrieb Andrew Cooper:

On 13/11/15 07:25, Jan Beulich wrote:

On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote:

Am 12.11.15 um 17:43 schrieb Andrew Cooper:

On 12/11/15 14:29, Atom2 wrote:

Hi Andrew,
thanks for your reply. Answers are inline further down.

Am 12.11.15 um 14:01 schrieb Andrew Cooper:

On 12/11/15 12:52, Jan Beulich wrote:

On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote:

After the upgrade HVM domUs appear to no longer work - regardless
of the
dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV
domUs, however, work just fine as before on both dom0 kernels.

xl dmesg shows the following information after the first crashed HVM
domU which is started as part of the machine booting up:
[...]
(XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest
state (0).
(XEN) ************* VMCS Area **************
(XEN) *** Guest State ***
(XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011,
gh_mask=ffffffffffffffff
(XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000,
gh_mask=ffffffffffffffff
(XEN) CR3: actual=0x0000000000800000, target_count=0
(XEN)      target0=0000000000000000, target1=0000000000000000
(XEN)      target2=0000000000000000, target3=0000000000000000
(XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc)  RIP =
0x0000000100000000 (0x0000000100000000)

Other than RIP looking odd for a guest still in non-paged protected
mode I can't seem to spot anything wrong with guest state.

odd? That will be the source of the failure.

Out of long mode, the upper 32bit of %rip should all be zero, and it
should not be possible to set any of them.

I suspect that the guest has exited for emulation, and there has been a
bad update to %rip.  The alternative (which I hope is not the case) is
that there is a hardware errata which allows the guest to accidentally
get it self into this condition.

Are you able to rerun with a debug build of the hypervisor?

Now _without_ the debug USE flag, but with debug information in
        the binary (I used splitdebug), all is back to where the problem
        started off (i.e. the system boots without issues until such
        time it starts a HVM domU which then crashes; PV domUs are
        working). I have attached the latest "xl dmesg" output with the
        timing information included.
 

I hope any of this makes sense to you.

Again many thanks and best regards

Right - it would appear that the USE flag is definitely not what you wanted, and causes bad compilation for Xen.  The do_IRQ disassembly you sent is a the result of disassembling a whole block of zeroes.  Sorry for leading you on a goose chase - the double faults will be the product of bad compilation, rather than anything to do with your specific problem.

However, the final log you sent (dmesg) is using a debug Xen, which is what I was attempting to get you to do originally.

We still observe that the VM ends up in 32bit non-paged mode but with an RIP with bit 32 set, which is an invalid state to be in.  However, there was nothing particularly interesting in the extra log information.

Please can you rerun with "hvm_debug=0xc3f", which will cause far more logging to occur to the console while the HVM guest is running.  That might show some hints.

Also, the fact that this occurs just after starting SeaBIOS is interesting.  As you have switched versions of Xen, you have also switched hvmloader, which contains the SeaBIOS binary embedded in it.  Would you be able to compile both 4.5.1 and 4.5.2 and switch the hvmloader binaries in use.  It would be very interesting to see whether the failure is caused by the hvmloader binary or the hypervisor.  (With `xl`, you can use firmware_override="/full/path/to/firmware" to override the default hvmloader).