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

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

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. :)

Zhuo

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.

Jan

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