WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Enble 6 argument hypercalls for HVMs

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Ross Philipson <Ross.Philipson@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Enble 6 argument hypercalls for HVMs
From: Keir Fraser <keir@xxxxxxx>
Date: Wed, 15 Dec 2010 11:43:45 +0000
Cc: George Dunlap <dunlapg@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 15 Dec 2010 03:44:49 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:user-agent:date :subject:from:to:cc:message-id:thread-topic:thread-index:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=w3bV0wSpk0c/uBihf381Sy5ytjuDrmQZucnIIG7XCfs=; b=Ht1FePtvt4qxNuJhwLoYdRwUWjYfS7VsCezm89QL36aZ60rdw/lgSE1vAwIn1PrDtR 9YYv8lZ8mLI1Z6kjBDwac+xNRrA2kj1z80U5Db6l+PS8KZU0dBBN6kN9Nn1TobG2WZWt wpIoo8lmshZYba+azLEfc3wIOcURL8DhZPrbw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=mxHi2EUKxAvqnAglXqg0vdZHI3CPw7d14irc7qCvmIKD9NV6T2guESmN+65feK2Yb+ OmNtDCqTqVDHtbOZCm6j1sVCd1Zi9eBTUa5hKZEZLgLpAYUtlDhmG7b+c2yOFln7jU8w vkNnkZ4oEK1m+7WO/BjysWYDnG3ee8kcdp+U8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D08A920020000780002811F@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcucTVQ+OufKJx6pqE6o6i8ceHbLsw==
Thread-topic: [Xen-devel] [PATCH] Enble 6 argument hypercalls for HVMs
User-agent: Microsoft-Entourage/12.27.0.100910
On 15/12/2010 10:40, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>>>> On 15.12.10 at 11:06, Keir Fraser <keir@xxxxxxx> wrote:
>> On 15/12/2010 09:07, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> 
>>>>>> On 14.12.10 at 23:16, Ross Philipson <Ross.Philipson@xxxxxxxxxx> wrote:
>>>> Enable 6 argument hypercalls for HVMs. The hypercall code handles a sixth
>>>> argument in EBP or R9 but the HVM code is not passing the value.
>>>> 
>>>> Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxx>
>>> 
>>> I'm curious what hypercall there is that takes 6 arguments,
>>> particularly on 64-bit (where the maximum so far is 4).
>> 
>> The v4v hypercalls in XenClient (not as yet submitted upstream) take 6
>> arguments. Multicalls also need fixing up for a sixth argument, making
>> everything consistent with existing PV hypercall logic.
> 
> I would generally take this as an indication that this actually works,
> but at least with tracing enabled I can't see how it would on 64-bit
> (note the last two reloads):

Yes, well, obviously noone has tried 6-arg (or 5-arg!) hypercalls from a
64-bit PV guest with tracing enabled. The code appears obviously wrong here.
Cc'ing George -- he should be able to test this and submit the obvious
patch. This looks like a cut-n-paste error from x86_64/compat/entry.S into
x86_64/entry.S -- it wouldn't have been picked up by George because we don't
generally run any 64-bit PV guests.

>         call  trace_hypercall
>         /* Now restore all the registers that trace_hypercall clobbered */
>         movq  UREGS_rax+SHADOW_BYTES(%rsp),%rax   /* Hypercall #  */
>         movq  UREGS_rdi+SHADOW_BYTES(%rsp),%rdi   /* Arg 1        */
>         movq  UREGS_rsi+SHADOW_BYTES(%rsp),%rsi   /* Arg 2        */
>         movq  UREGS_rdx+SHADOW_BYTES(%rsp),%rdx   /* Arg 3        */
>         movq  UREGS_r10+SHADOW_BYTES(%rsp),%rcx   /* Arg 4        */
>         movq  UREGS_rdi+SHADOW_BYTES(%rsp),%r8    /* Arg 5        */
>         movq  UREGS_rbp+SHADOW_BYTES(%rsp),%r9    /* Arg 6        */
> 
> Looking at this code also makes me wonder once again whether
> it really is a good idea to have a generally not taken forward
> branch here.

Which generally not-taken branch? The 'je 1f' instruction generally *will*
be taken!

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel