Hi,
when interrupting a guest (grub in graphical mode) in this state
EAX=00000011 EBX=0004bc88 ECX=0000000d EDX=000db51d
ESI=000008ff EDI=002462da EBP=00000000 ESP=00001fbc
EIP=000078b6 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
CS =2d32 0002d320 0000ffff 00009b00 DPL=0 CS16 [-RA]
SS =45aa 00045aa0 0000ffff 00009300 DPL=0 DS16 [-WA]
DS =2d32 0002d320 0000ffff 00009300 DPL=0 DS16 [-WA]
FS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
GS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
LDT=0000 00000000 ffffffff 00000000
TR =0048 00266009 00000067 00008b00 DPL=0 TSS32-busy
GDT= 0002dd48 0000004f
IDT= 0026607a 000007ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
the SS alignment to CPL corrupts the guest state on write back:
if (env->cr[0] & CR0_PE_MASK) {
/* force ss cpl to cs cpl */
sregs.ss.selector = (sregs.ss.selector & ~3) |
(sregs.cs.selector & 3);
sregs.ss.dpl = sregs.ss.selector & 3;
}
Aligning SS.RPL to CPL is not problematic here (as it already is), but
forcing SS.DPL to CPL is definitely wrong and causes an immediate guest
reboot.
Looking at commit 292a55081e5eee62db42209463cf385e7ff1d86d of qemu-kvm
which introduced this workaround I wonder if it still applies and if it
wasn't misplaced from day one anyway. If we really need this (when
BTW?), doesn't it belong into the kernel, particularly into vmx.c as it
addresses an _Intel_ quirk?
Jan
PS: There is another problem, namely in set_seg's DPL transfer, which
contributes to the guest crash, but that one is easily fixable. Patch
will follow.
Attachment:
signature.asc
Description: OpenPGP digital signature
