>>> On 10.10.16 at 11:21, <xuqu...@huawei.com> wrote: > 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?
I don't think there was anything left open on the other sub-thread; if there is, please point out specific aspects which are still unclear. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
