From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC PATCH] kvm-unit-tests : Basic architecture of VMX nested test case Date: Fri, 19 Jul 2013 14:06:58 +0200 Message-ID: <51E92BE2.1080600@redhat.com> References: <1374087242-6125-1-git-send-email-yzt356@gmail.com> <51E78295.2010700@redhat.com> <20130718072652.GB11772@redhat.com> <51E7C7D2.5040303@redhat.com> <20130718110639.GA26173@redhat.com> <51E7DAD3.8000906@redhat.com> <20130718195712.GN13732@redhat.com> <51E8DFCC.8060108@redhat.com> <20130719094027.GY13732@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Chunqi Li , kvm@vger.kernel.org, jan.kiszka@web.de To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:2037 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243Ab3GSMHM (ORCPT ); Fri, 19 Jul 2013 08:07:12 -0400 In-Reply-To: <20130719094027.GY13732@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Il 19/07/2013 11:40, Gleb Natapov ha scritto: >> Because this is written in C, and I know trying to fool the compiler is >> a losing game. So my reaction is "okay, HOST_RIP must be set so that >> code will not jump around". If I see >> >> asm("vmlaunch") >> exit(-1) >> >> the reaction is the opposite: "hmm, anything that jumps around would >> have a hard time with the compiler, there must be some assembly >> trampoline somewhere; let's check what HOST_RIP is". >> > We do try to fool compiler often even without vmx: code patching. This is > why asm goto was invented, no? So, like you said in previous emails, > asm goto is appropriate way here to tell compiler what is going on. Code patching is "only" reimplementing an existing C structure (if/else) in a different manner. Here the actual code flow (location of HOST_RIP and value of HOST_RSP) cannot be expressed correctly to the compiler because we do not use the C label (we use an asm label). I don't think asm goto can be made to work for vmx_return, though if we go for a big blob it could be useful to jump to the error handling code. >> I don't see anything bad in jumping completely to a different context. >> The guest and host are sort of like two coroutines, they hardly have any >> connection with the code that called vmlaunch. > You can see it as two coroutines, or you can see it as linear logic: > do host stuff > enter guest > do guest stuff > exit guest > continue doing host stuff > > Both can be implemented, I prefer linear one. I would prefer linear one > to coroutine in any code design, no connection to vmx. Sometimes > coroutine are better than alternative (and in those cases alternative is > never a linear logic), but this is not the case. Fair enough. As things stand, we have only one version that works reliably with past/present/future compilers, and that is the one with setjmp/longjmp. A v5 would be needed anyway. If Arthur (and Jan) want to write the vmentry as a big asm blob, that's fine by me. Still, some variety adds value in a testsuite: think of a hypothetic nested VMX implementation that ignores HOST_RIP and just falls through to the next host %rip, we want that to fail the tests! (*) (*) In fact, I think this must be a requirement even if Arthur goes for a big asm blob. If they prefer to keep setjmp/longjmp and fix the few remaining nits, I think that should be acceptable anyway. It would even make sense to have multiple vmentries if you can show they stress the hypervisor differently. In any case, I think we all agree (Arthur too) that this RFC doing mixed asm and C is the worst of both worlds. >>> The actually differences in asm instruction between both >>> version will not be bigger then a couple of lines (if we will not take >>> setjmp/longjmp implementation into account :)), >> >> I was waiting for this parenthetical remark to appear. ;) >> > I've put a smile there :) I realize this argument is not completely fair, > but for the sake of argument everything goes! Yes, I caught the irony. ;) Paolo