On September 26, 2016 2:39 PM, Jan Beulich < jbeul...@suse.com > wrote: >>>> On 24.09.16 at 03:06, <xuqu...@huawei.com> wrote: >> On September 24, 2016 7:34 AM, Tian Kevin < kevin.t...@intel.com > wrote: >>>> From: Jan Beulich [mailto:jbeul...@suse.com] >>>> Sent: Friday, September 23, 2016 11:34 PM >>>> >>>> >>> On 20.09.16 at 15:30, <xuqu...@huawei.com> 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, any idea now? Quan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
