Re: [Xen-devel] [PATCH] x86/hvm/viridian: save APIC assist vector

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.16 at 10:57, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 29 March 2016 09:42
>> To: Paul Durrant
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx 
>> Subject: Re: [PATCH] x86/hvm/viridian: save APIC assist vector
>> 
>> >>> On 24.03.16 at 18:19, <paul.durrant@xxxxxxxxxx> wrote:
>> > @@ -293,10 +292,11 @@ void viridian_start_apic_assist(struct vcpu *v, int
>> vector)
>> >       * wrong and the VM will most likely hang so force a crash now
>> >       * to make the problem clear.
>> >       */
>> > -    if ( v->arch.hvm_vcpu.viridian.apic_assist.vector >= 0 )
>> > +    if ( v->arch.hvm_vcpu.viridian.apic_assist.vector != 0 )
>> >          domain_crash(v->domain);
>> >
>> > -    v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
>> > +    /* Increment the value so that zero is always invalid. */
>> > +    v->arch.hvm_vcpu.viridian.apic_assist.vector = vector + 1;
>> 
>> From an APIC perspective, aren't vectors below 0x10 invalid
>> anyway? I.e. can't zero serve the "none" indication just as much
>> as -1 did without this new biasing? Or otherwise I'd still expect ...
>> 
> 
> I can do that, if you're happy with it. If I'm going to do it this way 
> though I will also put in an explicit check to make sure APIC assist is not 
> used for vectors < 0x16.

As long as you mean 0x10 or 16, yes (at once allowing the fields to
be uint8_t, as would be customary for vectors). I had actually half
written a comment to that effect on the original patch, until I
realized that the only harm caused by using a bogus low vector
would be to the guest itself.

Jan


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