Re: [Xen-devel] [PATCH v2 1/2] xc_cpuid_x86.c: Simplify masking conditions and remove redundant work

[z <alfred.z.song@xxxxxxxxx>]

On Tue, Sep 9, 2014 at 9:23 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 09.09.14 at 14:29, <andrew.cooper3@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel