[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |