[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 16.03.16 at 18:23, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 16 March 2016 16:28
>> >>> 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.

The same as with any other reserved bits, I would say: Leave
them alone.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.