From: Eric Lacombe <goretux@gmail.com>
To: kvm@vger.kernel.org, Avi Kivity <avi@redhat.com>
Subject: Re: [x86] - technical questions about HV implementation on Intel VT
Date: Mon, 20 Apr 2009 19:53:53 +0200 [thread overview]
Message-ID: <200904201953.53815.goretux@gmail.com> (raw)
In-Reply-To: <200904141424.01608.goretux@gmail.com>
Hi,
I reviewed my code (modify some things and add missing features) and made more
tests, but I'm stuck with the same problem.
Nonetheless, all the tests I've done seem to freeze my machine when files are
used.
When I try the commands "echo", "pwd" in the console (X is not started), the
machine behaves nicely. When I try completion (with double-tab) on a command,
it also works. But, when I try for instance "more help.c", the machine
freezes, likewise when I try "more hel"+double-tab.
I really would appreciate some help on this.
Please, could you tell me what I could check (because I already checked a lot
of things and can't figure out what happens)? I would also give you all the
information you need.
(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.)
Thanks in advance for your response.
Eric Lacombe
Le mardi 14 avril 2009 14:24:01 Eric Lacombe, vous avez écrit :
> Hi,
>
> I analysed some of my logs and see that sometimes, two successive VM-exits
> handle exactly the same instruction (a wrmsr with the same MSR ID and
> data), like below. Is it not strange ? and could it help to focus on the
> problem I have (the freeze of the machine).
>
> I can understand that you have no time to spend on my problem, but could
> someone give me some ideas on what I could check/print/... in order to fix
> my problem.
>
> Thanks in advance,
>
> Eric Lacombe
>
> I also join the complete log file from which is extracted this sample.
>
> ## Hytux: VM-EXIT (#000024) ##
> Hytux: interruptibility_state=0, activity_state=0
> Hytux: EXIT_REASON = 0x20, EXIT_QUALIF = 0x0
> Hytux: INTR_INFO is not valid
> Hytux: instruction_len=0x2
> Hytux[000024]: handle_wrmsr: ecx=0xc0000100 (MSR id), data=0x7f83583e56e0
> ## GUEST REGISTERS DUMP ##
> ----------------------------------------------------------
> GRFLAGS(VMCS): 0x0000000000000002 GRSP(VMCS): 0xffff88007854da18
> GRIP(VMCS): 0xffffffff80209c07
> HRFLAGS: 0x0000000000000086 HRSP: 0xffff88006d5cd000
> ----------------------------------------------------------
> rax: 0x00007f83583e56e0 rbx: 0xffff88007d127280 rcx: 0x00000000c0000100
> rdx: 0x0000000000007f83
> rsi: 0x0000000000000000 rdi: 0xffff88007d03e050 rbp: 0xffff88007d03e050
> rsp: 0xffff88007854da18
> r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0xffff88007d38c640 r11:
> 0x0000000000000001
> r12: 0x0000000000000000 r13: 0xffff8800790786c0 r14: 0xffffffff80818fa0
> r15: 0x0000000000000000
> ----------------------------------------------------------
> cr2: 0x0000000000615618 cr3(VMCS): 0x0000000078532000
> ----------------------------------------------------------
> ## Hytux: VM-EXIT (#000025) ##
> Hytux: interruptibility_state=0, activity_state=0
> Hytux: EXIT_REASON = 0x20, EXIT_QUALIF = 0x0
> Hytux: INTR_INFO is not valid
> Hytux: instruction_len=0x2
> Hytux[000025]: handle_wrmsr: ecx=0xc0000100 (MSR id), data=0x7f83583e56e0
> ## GUEST REGISTERS DUMP ##
> ----------------------------------------------------------
> GRFLAGS(VMCS): 0x0000000000000002 GRSP(VMCS): 0xffff88007854da18
> GRIP(VMCS): 0xffffffff80209c07
> HRFLAGS: 0x0000000000000086 HRSP: 0xffff88006d5cd000
> ----------------------------------------------------------
> rax: 0x00007f83583e56e0 rbx: 0xffff88007d127280 rcx: 0x00000000c0000100
> rdx: 0x0000000000007f83
> rsi: 0x0000000000000000 rdi: 0xffff88007d03e050 rbp: 0xffff88007d03e050
> rsp: 0xffff88007854da18
> r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0xffff88007d38c640 r11:
> 0xffffffff80241868
> r12: 0x0000000000000000 r13: 0xffff880079590980 r14: 0xffffffff80818fa0
> r15: 0x0000000000000000
> ----------------------------------------------------------
> cr2: 0x0000000000615618 cr3(VMCS): 0x0000000078532000
> ----------------------------------------------------------
>
> Le Tuesday 7 April 2009 19:26:30 Eric Lacombe, vous avez écrit :
> > Hello,
> >
> > I forgot to mention that my module only supports a single processor
> > (that's why I run a kernel with SMP disabled).
> >
> > I was able to run my module on two different machines (both are
> > core2-based) and that led to the same outcome: both machines freeze
> > without any bad printk messages :/
> >
> > I join another log file where the guest registers are always dumped for
> > each VM-exit. The log file begins with the loading of the module and ends
> > when the system crash.
> >
> > Could someone look at it please and maybe have an hint on what occurs ?
> >
> > If you need other information, just ask me and I will fulfil your needs.
> >
> > Best regards,
> >
> > Eric
> >
> > Le mardi 24 mars 2009 18:22:11 Eric Lacombe, vous avez écrit :
> > > Hello,
> > >
> > > I work on the implementation of a "particular" hypervisor for my PhD
> > > and I face a problem I have not resolved yet. Let me explain it.
> > >
> > > I have a module that when it is loaded triggers vmx mode, and load the
> > > current running kernel in a VM. The code seems to work at some extents.
> > > For the moment, I just handle the mandatory vm-exit (with my CPU: cr3,
> > > msr). I log information of each VM-exit (if I my module is loaded with
> > > my debug parameter), and see CR3 accesses, wrmsr execution, etc.
> > > After some time the machine freeze, there is no information logged by
> > > printk. The sysrq key do not work anymore (at least do not print
> > > information on the console) but some interrupt handling seems to work
> > > as the num-lock key of the keyboard causes the LED to light up (only
> > > with X started).
> > >
> > > Also, after loading the module (without X started), the machine succeed
> > > in executing a command like "echo test", but if I try a "ls" the
> > > machine instantaneously freezes, and no special logging is performed
> > > (my hypervisor does not printk a problem on the console). When I load
> > > the module from X, the machine freezes before I can execute a command
> > > (however a lot of vm-exit are still logged).
> > >
> > > I will be very glad if you have any idea of what occurs here ;)
> > > For that purpose, I join an output from my module from the loading
> > > process to the system crash, when running under X.
> > > Notes: - I only dump guest register contents for the first 10 vm-exit.
> > > - I use the netconsole provided by the kernel to get the logs.
> > >
> > > If you need more information, just ask me.
> > >
> > > Thanks in advance,
> > >
> > > Eric Lacombe
> > >
> > > PS: as I am not subscribed to the list, please do not forget to include
> > > my address.
next prev parent reply other threads:[~2009-04-20 17:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200903241822.11529.goretux@gmail.com>
[not found] ` <200904071926.30643.goretux@gmail.com>
2009-04-14 12:24 ` [x86] - technical questions about HV implementation on Intel VT Eric Lacombe
2009-04-20 17:53 ` Eric Lacombe [this message]
2009-04-20 18:22 ` Avi Kivity
2009-04-21 11:16 ` Eric Lacombe
2009-04-29 14:50 ` Eric Lacombe
2009-04-29 16:13 ` Eric Lacombe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200904201953.53815.goretux@gmail.com \
--to=goretux@gmail.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox