On 07/25/2010 08:19 PM, Kevin O'Connor wrote:
On Sun, Jul 25, 2010 at 12:42:46PM -0400, Kevin O'Connor wrote:
On Sun, Jul 25, 2010 at 11:55:47AM +0300, Avi Kivity wrote:
What conditions are needed to trigger this path? This can't occur
under normal operation, since it will fail badly with kvm on Intel.
It's called on every boot. I've personally only tested kvm on amd,
but I'd have to assume something must be allowing this to work on
intel.
BTW, the transition16big code does:
ljmpl $SEG32_MODE16BIG_CS, $(0xf0000 + 1f)
.code16gcc
1:
// Disable protected mode
movl %cr0, %eax
andl $~CR0_PE, %eax
movl %eax, %cr0
// far jump to flush CPU queue after transition to real mode
ljmpw $0xf000, $2f
2:
Only the ljmpw is in big real mode with a code address>64K - the
"Disable protected mode" code is technically in 16bit protected mode.
I'm not sure if that helps explain why it works.
What happens is kvm enters real mode with cs.limit=0xffff, the guest
#GPs due to segment limit violation, and enters the emulator, which
emulates the far jump correctly.
So this works, and will continue to work even after we fix limit
checking. It's still cleaner IMO to use normal code segments.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
