Re: [Xen-devel] vMCE vs migration

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.02.12 at 15:20, Olaf Hering <olaf@xxxxxxxxx> wrote:
> On Mon, Feb 13, Jan Beulich wrote:
> 
>> >>> On 10.02.12 at 22:28, Olaf Hering <olaf@xxxxxxxxx> wrote:
>> > These functions are called for dom0, but not for domU. And as a result
>> > arch.nr_vmce_banks remains zero. I assume the guest needs to be
>> > initialized in some way as well, and that does not happen?
>> 
>> Below/attached a fixed version of the patch.
> 
> I get some mismatch after migration, both hosts run the same xen binary.

Are you sure about that? I'm asking because ...

> The small debug patch I use is attached.
> 
> 
> Also: The tools do not catch the restore error so that the guest continues 
> to
> run on the source host.
> 
> Olaf
> 
> nicolai login: (XEN) vmce_init_vcpu 0 o 0 n 806
> (XEN) vmce_init_vcpu 1 o 0 n 806
> (XEN) vmce_init_vcpu 2 o 0 n 806
> (XEN) vmce_init_vcpu 3 o 0 n 806
> (XEN) save.c:62:d0 HVM restore (1): VM saved on one CPU (0x206c2) and 
> restored on another (0x10676).
> (XEN) save.c:234:d0 HVM restore: CPU 0
> (XEN) save.c:234:d0 HVM restore: CPU 1
> (XEN) save.c:234:d0 HVM restore: CPU 2
> (XEN) save.c:234:d0 HVM restore: CPU 3
> (XEN) save.c:234:d0 HVM restore: PIC 0
> (XEN) save.c:234:d0 HVM restore: PIC 1
> (XEN) save.c:234:d0 HVM restore: IOAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 1
> (XEN) save.c:234:d0 HVM restore: LAPIC 2
> (XEN) save.c:234:d0 HVM restore: LAPIC 3
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
> (XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
> (XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
> (XEN) save.c:234:d0 HVM restore: PCI_LINK 0
> (XEN) save.c:234:d0 HVM restore: PIT 0
> (XEN) save.c:234:d0 HVM restore: RTC 0
> (XEN) save.c:234:d0 HVM restore: HPET 0
> (XEN) save.c:234:d0 HVM restore: PMTIMER 0
> (XEN) save.c:234:d0 HVM restore: MTRR 0
> (XEN) save.c:234:d0 HVM restore: MTRR 1
> (XEN) save.c:234:d0 HVM restore: MTRR 2
> (XEN) save.c:234:d0 HVM restore: MTRR 3
> (XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
> (XEN) save.c:291:d0 HVM restore mismatch: expected type 18 length 8, saw type 
> 18 length 1

... this suggests the source host was still running with the old binary
(where the save record was indeed just 1 byte in size)...

> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff82c4802c7d28 ffffffff -1 o 806 n 
> ea
> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0
> (XEN) vmce_init_vcpu 0 o 0 n 806
> (XEN) vmce_init_vcpu 1 o 0 n 806
> (XEN) vmce_init_vcpu 2 o 0 n 806
> (XEN) vmce_init_vcpu 3 o 0 n 806
> (XEN) save.c:62:d0 HVM restore (2): VM saved on one CPU (0x206c2) and 
> restored on another (0x10676).
> (XEN) save.c:234:d0 HVM restore: CPU 0
> (XEN) save.c:234:d0 HVM restore: CPU 1
> (XEN) save.c:234:d0 HVM restore: CPU 2
> (XEN) save.c:234:d0 HVM restore: CPU 3
> (XEN) save.c:234:d0 HVM restore: PIC 0
> (XEN) save.c:234:d0 HVM restore: PIC 1
> (XEN) save.c:234:d0 HVM restore: IOAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 0
> (XEN) save.c:234:d0 HVM restore: LAPIC 1
> (XEN) save.c:234:d0 HVM restore: LAPIC 2
> (XEN) save.c:234:d0 HVM restore: LAPIC 3
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 0
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 1
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 2
> (XEN) save.c:234:d0 HVM restore: LAPIC_REGS 3
> (XEN) save.c:234:d0 HVM restore: PCI_IRQ 0
> (XEN) save.c:234:d0 HVM restore: ISA_IRQ 0
> (XEN) save.c:234:d0 HVM restore: PCI_LINK 0
> (XEN) save.c:234:d0 HVM restore: PIT 0
> (XEN) save.c:234:d0 HVM restore: RTC 0
> (XEN) save.c:234:d0 HVM restore: HPET 0
> (XEN) save.c:234:d0 HVM restore: PMTIMER 0
> (XEN) save.c:234:d0 HVM restore: MTRR 0
> (XEN) save.c:234:d0 HVM restore: MTRR 1
> (XEN) save.c:234:d0 HVM restore: MTRR 2
> (XEN) save.c:234:d0 HVM restore: MTRR 3
> (XEN) save.c:234:d0 HVM restore: VMCE_VCPU 0
> (XEN) vmce.c:360:d0 vmce_load_vcpu_ctxt ffff83082e377d28 0 0 o 806 n 1809
> (XEN) vmce.c:77: HVM restore: unsupported MCA capabilities 0x1809 for d2:v0 
> (supported: 0x800)

... whereas this one suggests that the size check passed (same binary
on both ends) but the feature sets of the hosts are different (sorry,
I can't suggest a way around this, the hosts must be sufficiently
matching in MCA features - those differences that are tolerable are
already being handled). I'm confused as to what was running on the
source host.

Let me check what bit 12 is: The latest SDM considers this reserved,
so the only way I can see how to deal with this is to switch the
setting up of g_mcg_cap from a back-listing approach to a white-listing
one.

> (XEN) save.c:239:d0 HVM restore: failed to load entry 18/0

Bottom line - it appears to work as intended considering the second
attempt.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel