Re: [Xen-devel] [PATCH 2/2] x86/hvm/viridian: Enable APIC assist enlightenment

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 16 March 2016 16:28
> To: Paul Durrant
> Cc: Andrew Cooper; Ian Jackson; Stefano Stabellini; Wei Liu; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek Wilk; Keir (Xen.org)
> Subject: RE: [Xen-devel] [PATCH 2/2] x86/hvm/viridian: Enable APIC assist
> enlightenment
> 
> >>> On 16.03.16 at 16:02, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> >> Sent: 15 March 2016 23:18
> >> On Tue, Mar 15, 2016 at 04:14:16PM +0000, Paul Durrant wrote:
> >> > +        domain_crash(v->domain);
> >> > +
> >> > +    v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
> >> > +    *(uint32_t *)va |= 1u;
> >>
> >> Oh my. What does that do? Why not 0xBADF00D
> >> Is that prescriped in the spec?
> >
> > The LSB is the only bit that has defined functionality. The next 31 bits are
> > reserved and the rest of the page is undefined.
> >
> >>
> >> That looks quite unhealthy to do.
> >>
> >
> > Reading the spec. again I do see that the reserved bits are defined to be
> > zero, so it looks like I can use = rather than |=.
> 
> Wouldn't that put at risk forward compatibility?
> 

The spec just says "Reserved to Zero" so it's hard to know what the right thing 
to do is until further bits are defined.

  Paul

> Jan


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