On 26/04/2009 16:08, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
> And i wonder if this has something to do with the problem i 'm experiencing.
> First, i don't understand this code, since the comment is talking about vm86
> mode, while the actual code checks for realmode. Is this ok?
Yes, Xen tries to emulate real mode by running the guest in vm86 mode. This
is faster than full emulation. You have a guest that really is in vm86 mode
(not merely to emulate real mode).
> Second, i wonder if there is a problem in updating the current state of the
> CPU, if it was changed during a task-switch (to vm86 mode), and it wasn't
> updated in the arch.hvm_vmx.vmx_realmode flag, then this might cause the
> problem, no?
No, the guest isn't in real mode, it really is in vm86 mode.
> And last: i found that the last trap/event which is re-happening all the time,
> and by that trashes all the memory untill the domain crashes, is trap 0x20,
> which i'm not sure, but i think it's a system call. Do u have any reason to
> think why trap 0x20, could lead to this problem?
Trap 0x20 is either a hardware interrupt or a software interrupt. Since the
meaning of vectors >=0x20 is configured by software, we can't know what
vector 0x20 is being used for here. However, often the 8259 PIC is based at
vector 0x20, and that might mean that this recurring interrupt is the PIT
(programmable interval timer).
> maybe there is a bug in the task-switch code which might cause it?
You wish. ;-)
Xen-devel mailing list