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

Re: [Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue



>>> On 24.09.16 at 03:06, <xuquan8@xxxxxxxxxx> wrote:
> On September 24, 2016 7:34 AM, Tian Kevin < kevin.tian@xxxxxxxxx > wrote:
>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>> Sent: Friday, September 23, 2016 11:34 PM
>>>
>>> >>> On 20.09.16 at 15:30, <xuquan8@xxxxxxxxxx> wrote:
>>> > --- a/xen/arch/x86/hvm/vlapic.c
>>> > +++ b/xen/arch/x86/hvm/vlapic.c
>>> > @@ -433,6 +433,12 @@ void vlapic_EOI_set(struct vlapic *vlapic)
>>> > void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)  {
>>> >      struct domain *d = vlapic_domain(vlapic);
>>> > +    struct vcpu *v = vlapic_vcpu(vlapic);
>>> > +    struct hvm_intack pt_intack;
>>> > +
>>> > +    pt_intack.vector = vector;
>>> > +    pt_intack.source = hvm_intsrc_lapic;
>>> > +    pt_intr_post(v, pt_intack);
>>>
>>> This also sits on the EOI LAPIC register write path, i.e. the change
>>> then also affects non-apicv environments.
>>
>>The new logic should be entered only when EOI-induced exit happens.
>>
> 
> Yes, more that the EOI-induced exit is conditional, specifically, the bitmap 
> is set by vmx_set_eoi_exit_bitmap().
> Jan, what do you think? While I recall from v1 discussion, you have the same 
> comment. We can dig it deep..

See my reply to Kevin sent a minute ago. As I'm not sure what
Kevin means to state with several of his responses, I can't
properly respond for now. And then what you say doesn't
really address my concern - things being conditional elsewhere
doesn't mean we won't get here too in the non-apicv case, at
least not in a way that I can follow right away.

Jan


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

 


Rackspace

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