> On Jun 16, 2020, at 7:02 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 16/06/20 15:02, Thomas Huth wrote: >> On 08/06/2020 18.00, Paolo Bonzini wrote: >>> Currently setup_vm cannot assume that it can invoke IPIs, and therefore >>> only initializes CR0/CR3/CR4 on the CPU it runs on. In order to keep the >>> initialization code clean, let's just call smp_init (and therefore >>> setup_idt) unconditionally. >>> >>> Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> >>> --- >>> x86/access.c | 2 -- >>> x86/apic.c | 1 - >>> x86/asyncpf.c | 1 - >>> x86/cmpxchg8b.c | 1 - >>> x86/cstart.S | 6 +++--- >>> x86/cstart64.S | 6 +++--- >>> x86/debug.c | 1 - >>> x86/emulator.c | 1 - >>> x86/eventinj.c | 1 - >> >> Hi Paolo, >> >> this patch broke the eventinj test on i386 on gitlab: >> >> https://gitlab.com/huth/kvm-unit-tests/-/jobs/597447047#L1933 >> >> if I revert the patch, the test works again: >> >> https://gitlab.com/huth/kvm-unit-tests/-/jobs/597455720#L1934 >> >> Any ideas how to fix that? > > I'm not sure why it starts failing now, the bug is unrelated and I see > the same compiler output even before. I encountered the same problem on my (weird) setup, and made some initial triage. Apparently, it is only the #DE that causes the mess. As the #DE uses vector number 0, and the IDT base is 0, it hints that the data in address 0 is corrupted. I presume there is somewhere a rogue store into a NULL pointer during the 32-bit setup. But I do not know where.
