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

[Jan Beulich]

>>> On 18.03.16 at 11:06,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 17 March 2016 16:43
>> >>> On 17.03.16 at 13:13,  wrote:
>> > @@ -1170,10 +1183,27 @@ int vlapic_has_pending_irq(struct vcpu *v)
>> >   !nestedhvm_vcpu_in_guestmode(v) )
>> >  return irr;
>> >
>> > +/*
>> > + * If APIC assist was used then there may have been no EOI so
>> > + * we need to clear the requisite bit from the ISR here, before
>> > + * comparing with the IRR.
>> > + */
>> > +if ( viridian_complete_apic_assist(v, ) &&
>> > + vector != -1 )
>> 
>> Afaict "vector" is uninitialized here when initialize_apic_assist()
>> didn't run for that vCPU yet (which includes the case where no
>> Viridian emulation is active at all).
>> 
> 
> Yes, vector will be uninitialized in that case but viridian 
> _complete_apic_assist() will return 0 (because the va will be zero) and so 
> the second clause of the if will not be evaluated.

Ah, true. But raises the question why viridian_complete_apic_assist()
doesn't return the vector then rather then using indirection.

>> > +/*
>> > + * This vector is edge triggered and there are no lower priority
>> > + * vectors pending, so we can use APIC assist to avoid exiting
>> > + * for EOI.
>> > + */
>> > +viridian_start_apic_assist(v, vector);
>> >
>> > +done:
>> 
>> Labels indented by at least one space please.
> 
> OK, sorry, emacs keeps moving them back.

That's very unfriendly of it.

Jan


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

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

[Jan Beulich]

>>> On 17.03.16 at 13:13,  wrote:
> @@ -262,6 +258,59 @@ static void initialize_apic_assist(struct vcpu *v)
>   page ? page_to_mfn(page) : INVALID_MFN);
>  }
>  
> +static uint32_t *get_apic_assist_word(struct vcpu *v)
> +{
> +if ( !(viridian_feature_mask(v->domain) & HVMPV_apic_assist) )
> +return NULL;
> +
> +return v->arch.hvm_vcpu.viridian.apic_assist.va;

Does this need to be conditional, i.e. isn't the field NULL anyway
when the flag is not set?

> +void viridian_start_apic_assist(struct vcpu *v, int vector)
> +{
> +uint32_t *va = get_apic_assist_word(v);
> +
> +if ( !va )
> +return;
> +
> +/*
> + * If there is already an assist pending then something has gone
> + * 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 )
> +domain_crash(v->domain);
> +
> +v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
> +*va |= 1u;

Are the u suffixes here really good for anything?

> +bool_t viridian_complete_apic_assist(struct vcpu *v, int *vector)
> +{
> +uint32_t *va = get_apic_assist_word(v);
> +
> +if ( !va )
> +return 0;
> +
> +if ( *va & 1u )
> +return 0; /* Interrupt not yet processed by the guest */

Missing full stop.

> @@ -1170,10 +1183,27 @@ int vlapic_has_pending_irq(struct vcpu *v)
>   !nestedhvm_vcpu_in_guestmode(v) )
>  return irr;
>  
> +/*
> + * If APIC assist was used then there may have been no EOI so
> + * we need to clear the requisite bit from the ISR here, before
> + * comparing with the IRR.
> + */
> +if ( viridian_complete_apic_assist(v, ) &&
> + vector != -1 )

Afaict "vector" is uninitialized here when initialize_apic_assist()
didn't run for that vCPU yet (which includes the case where no
Viridian emulation is active at all).

> @@ -1181,13 +1211,29 @@ int vlapic_has_pending_irq(struct vcpu *v)
>  int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool_t force_ack)
>  {
>  struct vlapic *vlapic = vcpu_vlapic(v);
> +int isr;
>  
> -if ( force_ack || !vlapic_virtual_intr_delivery_enabled() )
> -{
> -vlapic_set_vector(vector, >regs->data[APIC_ISR]);
> -vlapic_clear_irr(vector, vlapic);
> -}
> +if ( !force_ack &&
> + vlapic_virtual_intr_delivery_enabled() )
> +return 1;
> +
> +if ( vlapic_test_vector(vector, >regs->data[APIC_TMR]) )
> +goto done;
> +
> +isr = vlapic_find_lowest_vector(>regs->data[APIC_ISR]);
> +if ( isr >= 0 && isr < vector )
> +goto done;

These two new extra operations aren't exactly expensive, but
they also aren't for free. Would it make sense to at least avoid
the second one if the respective Viridian feature bit is clear?

> +/*
> + * This vector is edge triggered and there are no lower priority
> + * vectors pending, so we can use APIC assist to avoid exiting
> + * for EOI.
> + */
> +viridian_start_apic_assist(v, vector);
>  
> +done:

Labels indented by at least one space please.

> +vlapic_set_vector(vector, >regs->data[APIC_ISR]);
> +vlapic_clear_irr(vector, vlapic);
>  return 1;
>  }




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

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

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 March 2016 16:43
> To: Paul Durrant
> Cc: Andrew Cooper; Wei Liu; Ian Jackson; Stefano Stabellini; xen-
> de...@lists.xenproject.org; Keir (Xen.org)
> Subject: Re: [PATCH v5 2/2] x86/hvm/viridian: Enable APIC assist
> enlightenment
> 
> >>> On 17.03.16 at 13:13,  wrote:
> > @@ -262,6 +258,59 @@ static void initialize_apic_assist(struct vcpu *v)
> >   page ? page_to_mfn(page) : INVALID_MFN);
> >  }
> >
> > +static uint32_t *get_apic_assist_word(struct vcpu *v)
> > +{
> > +if ( !(viridian_feature_mask(v->domain) & HVMPV_apic_assist) )
> > +return NULL;
> > +
> > +return v->arch.hvm_vcpu.viridian.apic_assist.va;
> 
> Does this need to be conditional, i.e. isn't the field NULL anyway
> when the flag is not set?

No. Because Windows 8 will barf on boot if we don't handle set and get of the 
MSR the page is always mapped and zeroed. However, I could optimize this test 
by unmapping the page after handling the MSR write if the flag is not set, then 
the va will indeed be zero if the enlightenment is not in use. I'll do that.

> 
> > +void viridian_start_apic_assist(struct vcpu *v, int vector)
> > +{
> > +uint32_t *va = get_apic_assist_word(v);
> > +
> > +if ( !va )
> > +return;
> > +
> > +/*
> > + * If there is already an assist pending then something has gone
> > + * 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 )
> > +domain_crash(v->domain);
> > +
> > +v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
> > +*va |= 1u;
> 
> Are the u suffixes here really good for anything?
> 

Probably not, but *va is unsigned so I was just trying to be consistent.

> > +bool_t viridian_complete_apic_assist(struct vcpu *v, int *vector)
> > +{
> > +uint32_t *va = get_apic_assist_word(v);
> > +
> > +if ( !va )
> > +return 0;
> > +
> > +if ( *va & 1u )
> > +return 0; /* Interrupt not yet processed by the guest */
> 
> Missing full stop.
> 

Ok.

> > @@ -1170,10 +1183,27 @@ int vlapic_has_pending_irq(struct vcpu *v)
> >   !nestedhvm_vcpu_in_guestmode(v) )
> >  return irr;
> >
> > +/*
> > + * If APIC assist was used then there may have been no EOI so
> > + * we need to clear the requisite bit from the ISR here, before
> > + * comparing with the IRR.
> > + */
> > +if ( viridian_complete_apic_assist(v, ) &&
> > + vector != -1 )
> 
> Afaict "vector" is uninitialized here when initialize_apic_assist()
> didn't run for that vCPU yet (which includes the case where no
> Viridian emulation is active at all).
> 

Yes, vector will be uninitialized in that case but viridian 
_complete_apic_assist() will return 0 (because the va will be zero) and so the 
second clause of the if will not be evaluated.

> > @@ -1181,13 +1211,29 @@ int vlapic_has_pending_irq(struct vcpu *v)
> >  int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool_t force_ack)
> >  {
> >  struct vlapic *vlapic = vcpu_vlapic(v);
> > +int isr;
> >
> > -if ( force_ack || !vlapic_virtual_intr_delivery_enabled() )
> > -{
> > -vlapic_set_vector(vector, >regs->data[APIC_ISR]);
> > -vlapic_clear_irr(vector, vlapic);
> > -}
> > +if ( !force_ack &&
> > + vlapic_virtual_intr_delivery_enabled() )
> > +return 1;
> > +
> > +if ( vlapic_test_vector(vector, >regs->data[APIC_TMR]) )
> > +goto done;
> > +
> > +isr = vlapic_find_lowest_vector(>regs->data[APIC_ISR]);
> > +if ( isr >= 0 && isr < vector )
> > +goto done;
> 
> These two new extra operations aren't exactly expensive, but
> they also aren't for free. Would it make sense to at least avoid
> the second one if the respective Viridian feature bit is clear?
> 

Yes, that's worth doing.

> > +/*
> > + * This vector is edge triggered and there are no lower priority
> > + * vectors pending, so we can use APIC assist to avoid exiting
> > + * for EOI.
> > + */
> > +viridian_start_apic_assist(v, vector);
> >
> > +done:
> 
> Labels indented by at least one space please.

OK, sorry, emacs keeps moving them back.

  Paul

> 
> > +vlapic_set_vector(vector, >regs->data[APIC_ISR]);
> > +vlapic_clear_irr(vector, vlapic);
> >  return 1;
> >  }
> 
> 


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

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

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 March 2016 10:25
> To: Paul Durrant
> Cc: Andrew Cooper; Ian Jackson; Stefano Stabellini; Wei Liu; xen-
> de...@lists.xenproject.org; Keir (Xen.org)
> Subject: RE: [PATCH v5 2/2] x86/hvm/viridian: Enable APIC assist
> enlightenment
> 
> >>> On 18.03.16 at 11:06,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 17 March 2016 16:43
> >> >>> On 17.03.16 at 13:13,  wrote:
> >> > @@ -1170,10 +1183,27 @@ int vlapic_has_pending_irq(struct vcpu *v)
> >> >   !nestedhvm_vcpu_in_guestmode(v) )
> >> >  return irr;
> >> >
> >> > +/*
> >> > + * If APIC assist was used then there may have been no EOI so
> >> > + * we need to clear the requisite bit from the ISR here, before
> >> > + * comparing with the IRR.
> >> > + */
> >> > +if ( viridian_complete_apic_assist(v, ) &&
> >> > + vector != -1 )
> >>
> >> Afaict "vector" is uninitialized here when initialize_apic_assist()
> >> didn't run for that vCPU yet (which includes the case where no
> >> Viridian emulation is active at all).
> >>
> >
> > Yes, vector will be uninitialized in that case but viridian
> > _complete_apic_assist() will return 0 (because the va will be zero) and so
> > the second clause of the if will not be evaluated.
> 
> Ah, true. But raises the question why viridian_complete_apic_assist()
> doesn't return the vector then rather then using indirection.
> 

Yes, I guess that would be more obvious.

> >> > +/*
> >> > + * This vector is edge triggered and there are no lower priority
> >> > + * vectors pending, so we can use APIC assist to avoid exiting
> >> > + * for EOI.
> >> > + */
> >> > +viridian_start_apic_assist(v, vector);
> >> >
> >> > +done:
> >>
> >> Labels indented by at least one space please.
> >
> > OK, sorry, emacs keeps moving them back.
> 
> That's very unfriendly of it.
> 

Indeed.

  Paul

> Jan


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

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

[Ian Jackson]

> > > OK, sorry, emacs keeps moving them back.
> > 
> > That's very unfriendly of it.
> 
> Indeed.

I think this could be fixed by adjusting the parameters provided at
the bottom of each file in an Emacs `Local variables' block.

See the variable help for c-file-offsets and c-offsets-alist.

I think you want to set a minimum of 1 for `label' and perhaps some
other entries.

Ian.

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