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 not different
> > than bitmasks in this respect.
>
> You still don't get my point: what are you going to do when
> min_monitor_line_size needs to be 17 bits all of a sudden?
>
> Currently, you simply do an if-else check before using the respective
> mask and with your defined structs, you need to keep two versions:
>
> union cpuid5_ebx_before_family_X {
> struct {
> unsigned int max_monitor_line_size:16;
> unsigned int reserved:16;
> } split;
> unsigned int full;
> };
>
> union cpuid5_ebx_after_family_X {
> struct {
> unsigned int max_monitor_line_size:17;
> unsigned int reserved:15;
> } split;
> unsigned int full;
> };
New union wouldn't be very convenient if the change touched just a small
part of the register ... probably the best choice is using anonymous
elements like this,
union cpuid5_ebx {
union {
struct {
unsigned int max_monitor_line_size:16;
unsigned int reserved:16;
};
struct {
unsigned int max_monitor_line_size_after_family_X:17;
unsigned int reserved_after_family_X:15;
};
} split;
unsigned int full;
};
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_monitor_line_size
or even
ebx.split.max_monitor_line_size.after_family_X
Flat namespace is more flexible wrt. code.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
