Thanks a lot for your answer ;)
Le lundi 20 avril 2009 20:22:21 Avi Kivity, vous avez écrit :
> Eric Lacombe wrote:
[...]
> echo and pwd are part of bash, so they are probably in memory. I guess
> once you go to disk things fail.
>
> Try to boot the entire OS from initramfs (and keep it there).
I will try this but maybe what follows say that the problem is elsewhere.
[...]
> > (Recall: When loaded, my module use VT-x to go on vmx root operation,
> > then it creates a vmcs in order to execute the OS inside a VM.)
>
> I imagine you have interrupts working properly? Does 'watch -d cat
> /proc/interrupts' give the expected results (run it before you enter vmx
> to load it into cache)?
I made many times this test:
1. I run on a first console 'watch -n0,2 -d cat /proc/interrupts'
2. I load from another console my module (that is modified at the beginning of
its init step with the addition of a schedule_timeout_uninterruptible())
3. I switch to the first console and wait for schedule_timeout to return
And when my module does its stuff, the machine freezes... Maybe my module
"implies" a deadlock in the VFS after a VM-entry?
Note: in my module, I do not intercept (in the VM-execution controls) external
interruptions nor exception.
I also check in the documentation the "VMX aborts" but it does not seem to be
my problem --- the freeze occurs when I do not use MSR load/store areas as
well as when I use them.
Note: now, I just load/store the Kernel_GS_BASE MSR to cover swapgs, even if
it is not actually necessary for my module. (Besides, I intercept rdmsr/wrmsr
as can be seen in the logs, and modify accordingly the VMCS when needed).
>
> Are you virtualizing memory, or does the guest manipulate page tables
> directly?
The guest manipulates directly page tables in my current module.
I just handle two cases of cr3 access ("mov from" and "mov to") by just
carrying out the "mov" in the guest registers.
Best regards
Eric Lacombe
--
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
