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
On Sep 19, 2014, at 10:58 AM, Borislav Petkov b...@alien8.de 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.
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
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, Intel would
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!
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-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 for
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 respect.
You
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 memory
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 Reserved Bits
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 na...@cs.technion.ac.il
---
arch/x86/include/asm/cpuid_def.h | 163 +++
1 file changed, 163
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 na...@cs.technion.ac.il
---
arch/x86/include/asm/cpuid_def.h | 163
Boris,
Thanks for you comments - please see inline.
On Wed, Sep 17, 2014 at 4:21 PM, Borislav Petkov b...@alien8.de 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
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
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 na...@cs.technion.ac.il
---
arch/x86/include/asm/cpuid_def.h | 163
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. Anyhow, it is
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
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
other options
18 matches
Mail list logo
