Re: [Xen-devel] [PATCH v9 07/10] xen: remove workaround to inject evtchn_irq on irq enable

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 5 Aug 2014, Jan Beulich wrote:
> >>> On 04.08.14 at 22:29, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Mon, 4 Aug 2014, Jan Beulich wrote:
> >> No, you're right. So coming back to your suspicion above: Nothing
> >> prevents a HVM guest to also call VCPUOP_register_vcpu_info on
> >> the boot CPU (and in fact such an asymmetry would seem pretty
> >> odd); old-style HVM guests with PV drivers (built from
> >> unmodified_drivers/) don't call VCPUOP_register_vcpu_info at all.
> >> But in the end if what you say is true there would be a case where
> >> x86 is also broken, just that there doesn't appear to be a kernel
> >> utilizing this case. Since especially for HVM guests we shouldn't be
> >> making assumptions in the hypervisor on guest behavior, shouldn't
> >> your patch at least try to address that case then at once?
> > 
> > The most logical thing to do would be to implement arch_evtchn_inject on
> > x86 as:
> > 
> > void arch_evtchn_inject(struct vcpu *v)
> > {
> >     if ( has_hvm_container_vcpu(v) )
> >         hvm_assert_evtchn_irq(v);
> > }
> > 
> > however it is very difficult to test because:
> > - the !xen_have_vector_callback code path doesn't work properly on a
> > modern Linux kernel;
> > - going all the way back to 2.6.37, !xen_have_vector_callback works but
> > then calling xen_vcpu_setup on vcpu0 doesn't work anyway. I don't know
> > exactly why but I don't think that the reason has anything to do with
> > the problem we are discussing here. In fact simply calling on vcpu0 an
> > hypercall that only sets evtchn_upcall_pending and then calls
> > arch_evtchn_inject works as espected.
> > 
> > I know we are not just dealing with Linux guests, but given all this I
> > am not sure how useful would actually be to provide the implementation
> > of arch_evtchn_inject on x86.  What do you think?
> 
> I think having the implementation you suggest above is in any
> event better than just an empty one. And with that I would also
> suggest that its declaration be moved to a common header.

OK

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