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

Re: [Xen-devel] [PATCH] xc_cpuid_x86.c: No need to mask NX twice

Hi, Jan

I am sorry for making you confused.

What I mean is there seems to be some redundant work. For example, to leaf 0x80000001, the generic work (masking NX and PSE36) has been overwritten by the the vendor's functions (amd_xc_cpuid_policy and intel_xc_cpuid_policy) , why couldn't we just drop them and leave the work to the vendor? Of cause, another way is just like you said, keeping the generic ones, and changing the logic in the vendor-based implementation.

What I want to do is to simplify this if possible. :)


On Fri, Sep 5, 2014 at 10:10 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 05.09.14 at 15:54, <alfred.z.song@xxxxxxxxx> wrote:
> Hi, Jan
> Generally, I agree with you. But it seems that we may not simply remove the
> ones from the 2 vendor specific functions and keep the generic one, because
> the bit could be still cleared eventually when is_pae is true. And I find
> PSE36 will be cleared permanently no matter is_pae is true or not. Actually
> the work below has been totally overlapped:
>Â Â Â Â Âif ( !is_pae )
> {
>Â Â Â Â Â Â Âclear_bit(X86_FEATURE_NX,
> regs[3]);
>Â Â Â Â Â Â Âclear_bit(X86_FEATURE_PSE36,
> regs[3]);
>Â Â Â Â Â}
> How can we just "passthrough to cpu vendor specific functions" like leaf
> 0x80000000? like this:
>Â Â Âcase 0x80000000:
>Â Â Âcase
> 0x80000001:
>Â Â Â Â Â/* Passthrough to cpu vendor specific functions
> */
>Â Â Â Â Âbreak;
> Correct me if I missed something.

I'm sorry, but I don't think I understand what you're trying to say
or you're asking.


Xen-devel mailing list



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