pekka-vm and kvm documentation
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Avi,
Quoted 1 line · Avi Kivity
When you come up against something that is undocumented or badly described, please complain on kvm@. We will then update the documentation.
So one thing I'm wondering is in what mode do we enter the guest? Is that entirely specified with KVM_SET_REGS and KVM_SET_SREGS?
I assume we're entering real mode as per how I set up "rflags" but for some reason I'm seeing "cs" base being zeroed out before first instruction is executed with my simple kvm program which could mean that it's trying to use GDT (which is not set up at that point).
Pekka
Quoted 6 lines · Pekka Enberg
Hi Avi,
Quoted 1 line · Avi Kivity
When you come up against something that is undocumented or badly described, please complain on kvm@. We will then update the documentation.
So one thing I'm wondering is in what mode do we enter the guest? Is that entirely specified with
KVM_SET_REGSandKVM_SET_SREGS?
Yes. cr0.pe = real/protected, eflags.vm = vm86 mode, cs.d = prot16/prot32, efer.lme/efer.lma/cs.l = longmode.
Quoted 2 lines
I assume we're entering real mode as per how I set up "rflags" but for some reason I'm seeing "cs" base being zeroed out before first instruction is executed with my simple kvm program which could mean that it's trying to use GDT (which is not set up at that point).
I see you set up the cpu as if after reset (cs:ip = f000:fff0) but just dumped a kernel there. That won't work, you need real code.
Try poking 'e9 fd ff' at your entry point (ffff0) and see the cpu pegged at 100% (1: jmp 1b) (this is probably the largest possible kernel that is bug-free).
Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.