public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Arthur Chunqi Li <yzt356@gmail.com>,
	kvm@vger.kernel.org, jan.kiszka@web.de
Subject: Re: [RFC PATCH] kvm-unit-tests : Basic architecture of VMX nested test case
Date: Thu, 18 Jul 2013 12:47:46 +0200	[thread overview]
Message-ID: <51E7C7D2.5040303@redhat.com> (raw)
In-Reply-To: <20130718072652.GB11772@redhat.com>

Il 18/07/2013 09:26, Gleb Natapov ha scritto:
> > I had written a long explanation here about why I don't trust the
> > compiler to do the right thing, and ideas about how to fix that.  But in
> > the end the only workable solution is a single assembly blob like vmx.c
> > in KVM to do vmlaunch/vmresume, so I'll get right to the point:
> > 
> >    *  the "similarity with KVM code" and "as little assembly as  *
> >    *  possible" goals are mutually exclusive                     *
> 
> I never said that code should be similar to KVM code or have as little
> assembly as possible :) Reread the thread. The only thing I asked for
> is to make code flow linear, if it makes code looks more like KVM or
> reduce amount of assembly this is just a bonus.

Point taken.

> > and for a testsuite I'd prefer the latter---which means I'd still favor
> > setjmp/longjmp.
> > 
> > Now, here is the long explanation.
> > 
> > I must admit that the code looks nice.  There are some nits I'd like to
> > see done differently (such as putting vmx_return at the beginning of the
> > while (1), and the vmresume asm at the end), but it is indeed nice.
>
> Why do you prefer setjmp/longjmp then?

Because it is still deceiving, and I dislike the deceit more than I like
the linear code flow.

> Agree, I dislike this magic too, but this is fixed by you suggestion
> above about putting vmx_return at the beginning of while(). So the logic
> will looks like that:
> 
> asm volatile("vmlaunch;setbe %0\n\t" : "=m"(ret));
> while(ret) {

while(!ret) if you use setbe, of course.

>    vmx_return:
>    SAVE_GPR_C
>    eax = exit_handler();
>    switch(eax) {
>    }
>    LOAD_GPR_C
>    asm volatile("vmresume;seta %0\n\t" : "=m"(ret));
> }

It is still somewhat magic: the "while (ret)" is only there to please
the compiler, and you rely on the compiler not changing %rsp between the
vmlaunch and the vmx_return label.  Minor nit, you cannot anymore print
different error messages for vmlaunch vs. vmresume failure.

In the end the choice is between "all in asm" and "small asm trampoline"
(which also happens to use setjmp/longjmp, but perhaps Arthur can
propagate return codes without using setjmp/longjmp, too).

> Rewriting the whole guest entry exit path in asm like you suggest bellow
> will eliminate the magic too.

> I much prefer one big asm statement than many small asm statement
> scattered among two or three C lines.

It's not many asm statements, it's just a dozen lines:


	align	4, 0x90
	entry_vmx:
		SAVE_GPR
		call default_exit_handler
		/* Should not reach here*/
		mov $1, %eax
		call exit
	.align	4, 0x90
	entry_sysenter:
		SAVE_GPR
		and	$0xf, %eax
		mov	%eax, %edi
		call	default_syscall_handler
		/* Arthur, is something missing here? :)) */

Paolo

  reply	other threads:[~2013-07-18 10:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 18:54 [RFC PATCH] kvm-unit-tests : Basic architecture of VMX nested test case Arthur Chunqi Li
2013-07-18  5:52 ` Paolo Bonzini
2013-07-18  7:26   ` Gleb Natapov
2013-07-18 10:47     ` Paolo Bonzini [this message]
2013-07-18 11:06       ` Gleb Natapov
2013-07-18 12:08         ` Paolo Bonzini
2013-07-18 14:11           ` Arthur Chunqi Li
2013-07-18 19:57           ` Gleb Natapov
2013-07-19  6:42             ` Paolo Bonzini
2013-07-19  9:40               ` Gleb Natapov
2013-07-19 12:06                 ` Paolo Bonzini
2013-07-24  6:11                   ` Arthur Chunqi Li
2013-07-24  6:40                     ` Paolo Bonzini
2013-07-24  6:46                       ` Arthur Chunqi Li
2013-07-24  6:48                         ` Paolo Bonzini
2013-07-24  8:48                           ` Arthur Chunqi Li
2013-07-24  8:53                             ` Jan Kiszka
2013-07-24  9:16                             ` Paolo Bonzini
2013-07-24  9:56                               ` Arthur Chunqi Li
2013-07-24 10:03                                 ` Jan Kiszka
2013-07-24 10:16                                   ` Arthur Chunqi Li
2013-07-24 10:24                                     ` Jan Kiszka
2013-07-24 11:20                                       ` Arthur Chunqi Li
2013-07-24 11:25                                         ` Jan Kiszka

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=51E7C7D2.5040303@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=gleb@redhat.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=yzt356@gmail.com \
    /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