LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [x86] - technical questions about HV implementation on Intel VT
@ 2008-10-20 17:27 Eric Lacombe
2008-10-21 9:05 ` Avi Kivity
0 siblings, 1 reply; 4+ messages in thread
From: Eric Lacombe @ 2008-10-20 17:27 UTC (permalink / raw)
To: avi; +Cc: linux-kernel
Hello,
I worked on a particular hypervisor, that just put in a VM the currently
running kernel. But I faced some problems and I would like to know some good
practices in order to debug the module I develop.
When the module put the current kernel in "vmx non-root mode", some conditions
irremediably trigger a VM-Exit (with the processor I use, loading cr3 always
trigger a vmexit). And here comes my problem. How can I reliably get
information (by way of printk) when my hypervisor screw something up, and
crash the machine with lots of debug info that scroll quickly on the screen,
just before freezing the machine.
In fact, It seems that in some situations the machine "loop on page faults".
Let me depict the scenario:
After a vmxlaunch, the host hand over the cpu to the guest then a vmexit
occurs. Thus, the guest hand over to the host. the host checks some things
and issue a vmxresume, and.. a vmexit occurs again, etc. etc.
So, when the host take control for the first time after the first vmexit, I
would like the host to print informations and to "die correctly", so as I
could read these information on the screen (ie, without being polluted with
lots of debug messages that scroll on the screen).
Note: I already have some vmexits due to invalid guest state during vmxlaunch,
but it seems (because my trivial printings for those situations do not show
again) I fully repaired those problems. Now there is a lot of debug info
quickly scrolling on the screen before the system crashes :/
Thanks in advance for your answers.
Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [x86] - technical questions about HV implementation on Intel VT
2008-10-20 17:27 [x86] - technical questions about HV implementation on Intel VT Eric Lacombe
@ 2008-10-21 9:05 ` Avi Kivity
2008-10-27 14:29 ` Eric Lacombe
0 siblings, 1 reply; 4+ messages in thread
From: Avi Kivity @ 2008-10-21 9:05 UTC (permalink / raw)
To: Eric Lacombe; +Cc: linux-kernel
Eric Lacombe wrote:
> [...]
> So, when the host take control for the first time after the first vmexit, I
> would like the host to print informations and to "die correctly", so as I
> could read these information on the screen (ie, without being polluted with
> lots of debug messages that scroll on the screen).
>
You should add a serial console or netconsole to your hypervisor; that
means implementing a serial or network card driver.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [x86] - technical questions about HV implementation on Intel VT
2008-10-21 9:05 ` Avi Kivity
@ 2008-10-27 14:29 ` Eric Lacombe
2008-10-27 16:38 ` Avi Kivity
0 siblings, 1 reply; 4+ messages in thread
From: Eric Lacombe @ 2008-10-27 14:29 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-kernel
Hi,
Thanks for your answer.
I will eventually add a netconsole, but for now, I find how to bypass my
problem (getting debug information).
However I come with a new question, related to an unexpected VM-exit.
The scenario is as follows:
1. some setup occur
2. vmlaunch is executed by a function F, so the guest is launched. This guest
(as I explained in my previous mail) executes the end of the function F.
3. The end of F, do some "printk" then return to the module init function.
The problem is that I get a VM-exit during the step 3. In fact after the
first "printk", a vm-exit occurs with exit_reason=2 (triple-fault).
Do you have an idea of what could be the cause of this vm-exit?
Note:
- If I do no "printk" at the end of F, then F returns without any problems to
the caller, and when this caller do a "printk" the vm-exit occurs (I can see
the result of "printk" on the screen).
- I also tried to insert 2 "printk" and a "panic" at the end of F. result:
the "panic" is never reached. (so the vm-exit occurs after the first "printk"
has done his job).
Thanks in advance for your answer,
Eric
On Tuesday 21 October 2008 11:05:24 Avi Kivity wrote:
> Eric Lacombe wrote:
> > [...]
> > So, when the host take control for the first time after the first vmexit,
> > I would like the host to print informations and to "die correctly", so as
> > I could read these information on the screen (ie, without being polluted
> > with lots of debug messages that scroll on the screen).
>
> You should add a serial console or netconsole to your hypervisor; that
> means implementing a serial or network card driver.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [x86] - technical questions about HV implementation on Intel VT
2008-10-27 14:29 ` Eric Lacombe
@ 2008-10-27 16:38 ` Avi Kivity
0 siblings, 0 replies; 4+ messages in thread
From: Avi Kivity @ 2008-10-27 16:38 UTC (permalink / raw)
To: Eric Lacombe; +Cc: linux-kernel
Eric Lacombe wrote:
> Hi,
>
> Thanks for your answer.
> I will eventually add a netconsole, but for now, I find how to bypass my
> problem (getting debug information).
>
> However I come with a new question, related to an unexpected VM-exit.
> The scenario is as follows:
> 1. some setup occur
> 2. vmlaunch is executed by a function F, so the guest is launched. This guest
> (as I explained in my previous mail) executes the end of the function F.
> 3. The end of F, do some "printk" then return to the module init function.
>
> The problem is that I get a VM-exit during the step 3. In fact after the
> first "printk", a vm-exit occurs with exit_reason=2 (triple-fault).
>
> Do you have an idea of what could be the cause of this vm-exit?
>
Almost any emulation error can cause this. Something goes wrong, an
exception is raised, can't be handled due to the same problem (or maybe
another one), triple fault.
You need to print out the entire contents of the vmcs before the last
entry and check it out carefully.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-10-27 16:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-20 17:27 [x86] - technical questions about HV implementation on Intel VT Eric Lacombe
2008-10-21 9:05 ` Avi Kivity
2008-10-27 14:29 ` Eric Lacombe
2008-10-27 16:38 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).