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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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