On Mon, 2015-09-21 at 12:22 +0000, Wu, Feng wrote: > > > -----Original Message----- > > From: George Dunlap [mailto:george.dun...@citrix.com]
> > You also need to check that local_events_need_delivery() will > > return > > "true" if you get an interrupt between that time and entering the > > hypervisor. Will that happen automatically from > > hvm_local_events_need_delivery() -> hvm_vcpu_has_pending_irq() -> > > vlapic_has_pending_irq()? Or will you need to add a hook in > > hvm_vcpu_has_pending_irq()? > > I think I don't need to add hook in hvm_vcpu_has_pending_irq(), what > I need > to do in vcpu_block() and do_poll() is as below: > > 1. set_bit(_VPF_blocked, &v->pause_flags); > > 2. ret = v->arch.arch_block(), in this hook, we can re-use the same > logic in > vmx_pre_ctx_switch_pi(), and check whether ON bit is set during > updating > posted-interrupt descriptor, can return 1 when ON is set > It think it would be ok for an hook to return a value (maybe, if doing that, let's pick variable names and use comments to explain what goes on as good as we can). I think I also see why you seem to prefer doing it that way, rather than hacking local_events_need_delivery(), but can you please elaborate on that? (My feeling is that you want to avoid having to update the data structures in between _VPF_blocked and the check local_events_need_delivery(), and then having to roll such update back if local_events_need_delivery() ends up being false, is that the case?). Code would look better, IMO, if we manage to fold that somehow inside local_events_need_delivery(), but that: 1. is hard to tell without actually seeing how the code will end up being 2. might be my opinion only, so let's see what others think. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel