[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.