On Fri, Sep 19, 2014 at 03:40:29PM +0200, Paolo Bonzini wrote:
> And similarly, Intel would not extend a bit from 16 to 17 bits if it
> weren't zero on all older processors.
Nothing is stopping a hw designer to say we're using 17 bits now. And
software needs to deal with that. It is that simple!
Il 19/09/2014 09:58, Borislav Petkov ha scritto:
>> > The trivial example is feature bits like XSAVE. We query them all the
>> > time without checking the family when they were first introduced,
>> > don't we?
> The feature bits would obviously be 0 if features are not supported.
And similarly, In
On Fri, Sep 19, 2014 at 11:59:32AM +0300, Nadav Amit wrote:
> As for the concern that CPUID fields would be extended into non-zero
> reserved bits - can someone point me to a single case that occurred in
> the last 20 years during which CPUID existed?
Do you have a guarantee that this won't happen
On Sep 19, 2014, at 10:58 AM, Borislav Petkov wrote:
> On Thu, Sep 18, 2014 at 03:36:43PM +0200, Paolo Bonzini wrote:
>> We're talking about the case where the field is not reserved anymore and
>> we _know_ that the vendor has just decided to grow the bitfield that
>> precedes it.
>
> We're tal
On Thu, Sep 18, 2014 at 03:36:43PM +0200, Paolo Bonzini wrote:
> We're talking about the case where the field is not reserved anymore and
> we _know_ that the vendor has just decided to grow the bitfield that
> precedes it.
We're talking about the case where you assumed that a reserved bit is 0
wh
Il 18/09/2014 15:26, Borislav Petkov ha scritto:
> On Thu, Sep 18, 2014 at 03:06:59PM +0200, Paolo Bonzini wrote:
>> The extra bit used to be reserved and thus will be zero on older
>> families. So, nothing?
>
> "thus will be zero" is unfortunately simply not true.
>
> From the SDM:
>
> "1.3.2
On Thu, Sep 18, 2014 at 03:06:59PM +0200, Paolo Bonzini wrote:
> The extra bit used to be reserved and thus will be zero on older
> families. So, nothing?
"thus will be zero" is unfortunately simply not true.
>From the SDM:
"1.3.2 Reserved Bits and Software Compatibility
In many register and m
Il 17/09/2014 16:06, Borislav Petkov ha scritto:
>> > AFAIK backward compatibility is usually maintained in x86. I did not
>> > see in Intel SDM anything that says "this CPUID field means something
>> > for CPU X and something else for CPU Y". Anyhow, it is not different
>> > than bitmasks in this
2014-09-18 09:19+0200, Borislav Petkov:
> On Thu, Sep 18, 2014 at 02:29:54AM +0200, Radim Krčmář wrote:
> > I think you proposed to use magic constant in place of of MASK_FAM_X, so
>
> Huh, what?
Your example. It cannot be verbatim MASK_FAM_X in real code.
I interpreted it to be a placeholder f
On Thu, Sep 18, 2014 at 02:29:54AM +0200, Radim Krčmář wrote:
> I think you proposed to use magic constant in place of of MASK_FAM_X, so
Huh, what?
> Second problem: Most elements don't begin at offset 0, so the usual
> retrieval would add a shift, (repurposing max_monitor_line_size)
So what?
2014-09-17 17:22+0200, Borislav Petkov:
> On Wed, Sep 17, 2014 at 05:04:33PM +0200, Radim Krčmář wrote:
> > which would result in a similar if-else hack
> >
> > if (family > X)
> > ebx.split.max_monitor_line_size_after_family_X = 0
> > else
> > ebx.split.max_monitor_line_size = 0
> >
On Wed, Sep 17, 2014 at 05:04:33PM +0200, Radim Krčmář wrote:
> which would result in a similar if-else hack
>
> if (family > X)
> ebx.split.max_monitor_line_size_after_family_X = 0
> else
> ebx.split.max_monitor_line_size = 0
>
> other options are
> ebx.split.after_family_X.max
2014-09-17 16:06+0200, Borislav Petkov:
> On Wed, Sep 17, 2014 at 04:53:39PM +0300, Nadav Amit wrote:
> > AFAIK backward compatibility is usually maintained in x86. I did not
> > see in Intel SDM anything that says "this CPUID field means something
> > for CPU X and something else for CPU Y". Anyho
On Wed, Sep 17, 2014 at 03:54:12PM +0300, Nadav Amit wrote:
> Adding structs that reflect various cpuid fields in x86 architecture. Structs
> were added only for functions that are not pure bitmaps.
>
> Signed-off-by: Nadav Amit
> ---
> arch/x86/include/asm/cpuid_def.h | 163
> +
On Wed, Sep 17, 2014 at 04:53:39PM +0300, Nadav Amit wrote:
> AFAIK backward compatibility is usually maintained in x86. I did not
> see in Intel SDM anything that says "this CPUID field means something
> for CPU X and something else for CPU Y". Anyhow, it is not different
> than bitmasks in this r
Boris,
Thanks for you comments - please see inline.
On Wed, Sep 17, 2014 at 4:21 PM, Borislav Petkov wrote:
> On Wed, Sep 17, 2014 at 03:54:12PM +0300, Nadav Amit wrote:
>> Adding structs that reflect various cpuid fields in x86 architecture. Structs
>> were added only for functions that are not
On Wed, Sep 17, 2014 at 03:54:12PM +0300, Nadav Amit wrote:
> Adding structs that reflect various cpuid fields in x86 architecture. Structs
> were added only for functions that are not pure bitmaps.
>
> Signed-off-by: Nadav Amit
> ---
> arch/x86/include/asm/cpuid_def.h | 163
> +
Adding structs that reflect various cpuid fields in x86 architecture. Structs
were added only for functions that are not pure bitmaps.
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/cpuid_def.h | 163 +++
1 file changed, 163 insertions(+)
create mode 1006
18 matches
Mail list logo
