From mboxrd@z Thu Jan 1 00:00:00 1970 From: z Subject: Re: [PATCH v2 1/2] xc_cpuid_x86.c: Simplify masking conditions and remove redundant work Date: Tue, 9 Sep 2014 22:43:33 +0800 Message-ID: References: <1410237112-21177-1-git-send-email-alfred.z.song@gmail.com> <540EF66C0200007800032929@mail.emea.novell.com> <1410265317.8217.151.camel@kazak.uk.xensource.com> <540EF29F.9000501@citrix.com> <540F1B640200007800032AF7@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4958874890839091675==" Return-path: In-Reply-To: <540F1B640200007800032AF7@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Ian Campbell , Stefano Stabellini , Andrew Cooper , ian.jackson@eu.citrix.com, Zhuo Song , =?UTF-8?B?6ams5rabKOS8r+eRnCk=?= , jinsong.liu@alibaba-inc.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============4958874890839091675== Content-Type: multipart/alternative; boundary=001a1135e2deb5677a0502a2f54b --001a1135e2deb5677a0502a2f54b Content-Type: text/plain; charset=UTF-8 On Tue, Sep 9, 2014 at 9:23 PM, Jan Beulich wrote: > >>> On 09.09.14 at 14:29, wrote: > > On Intel, syscall is strictly only available in long mode, being an AMD > > instruction mandated in the 64bit spec. > > > > is_64bit is disappearing as Xen is unconditionally 64bit these days, but > > preventing the guest using PAE will preclude it being able to enter long > > mode. > > > > I would agree that it is not necessarily obvious, and based on this > > consideration, I think it would be better to keep the variable > > "is_64bit" as it is more informative than "is_pae" in the contexts used. > > Or drop the conditional, as suggested before. After all I don't think > Intel CPUs advertise the bit in CPUID only when in long mode. Plus > even if they did, what we do (did) here still wouldn't match their > behavior (since is_64bit really is a hypervisor property, not a guest > one). I.e. at the tools level we should leave the flag as is. And if > indeed CPUID output changes when entering long mode (didn't > check the spec), this could only be mimicked in hypervisor code > anyway. > > Jan > > Hi, Jan Generally, I agree with you. Another implicit reason is Xen is always 64-bit now, which also means that the Intel CPU (if not AMD) on which the hypervisor is running should be 64-bit. The SYSCALL could be reported to guest as long as the CPU supports it and it would be emulated once guest run its own CPUID, and is_pae could even be dropped to some extent. But from performance point of view, there might be more work in the handler of vmexit (e.g. adding more bits to be emulated). And I agree with you is_pae does not mean the guest must be long mode, instead, it is long mode _or_ pae mode. In pae mode, SYSCALL should not be exported to guest either. So the conditional is_pae for SYSCALL is not that accurate (as you said it is partial effective). Maybe we need a better way here. But I can not figure it out yet. Zhuo --001a1135e2deb5677a0502a2f54b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 9, 2014 at 9:23 PM, Jan Beulich <JBeulich@suse.com>= wrote:
>>> On 09.09.14 at 14:29, <andrew.cooper3@citrix.com> wrote:
> On Intel, syscall is strictly only available in long mode, being an AM= D
> instruction mandated in the 64bit spec.
>
> is_64bit is disappearing as Xen is unconditionally 64bit these days, b= ut
> preventing the guest using PAE will preclude it being able to enter lo= ng
> mode.
>
> I would agree that it is not necessarily obvious, and based on this > consideration, I think it would be better to keep the variable
> "is_64bit" as it is more informative than "is_pae"= in the contexts used.

Or drop the conditional, as suggested before. After all I don't = think
Intel CPUs advertise the bit in CPUID only when in long mode. Plus
even if they did, what we do (did) here still wouldn't match their
behavior (since is_64bit really is a hypervisor property, not a guest
one). I.e. at the tools level we should leave the flag as is. And if
indeed CPUID output changes when entering long mode (didn't
check the spec), this could only be mimicked in hypervisor code
anyway.

Jan


Hi, J= an

Generally, I agree with you.
Another implicit reason is Xen is always = 64-bit now, which also means that the Intel CPU (if not AMD) on which the h= ypervisor is running should be 64-bit.
The SYSCALL could be reported to guest as long as the CPU supports it and = it would be emulated once guest run its own CPUID, and is_pae could even be= dropped to some extent. But from performance point of view, there might be= more work in the handler of vmexit (e.g. adding more bits to be emulated).=

And I agree with you is_pae does n= ot mean the guest must be long mode, instead, it is long mode _or_ pae mode= .=C2=A0 In pae mode, SYSCALL should not be exported to guest either. So the= conditional is_pae for SYSCALL is not that accurate (as you said it is par= tial effective). Maybe we need a better way here. But I can not figure it o= ut yet.=C2=A0

Zhuo
--001a1135e2deb5677a0502a2f54b-- --===============4958874890839091675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4958874890839091675==--