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 12:02, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Mon, 4 Aug 2014, Jan Beulich wrote:
>> >>> On 01.08.14 at 19:00, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > On Fri, 25 Jul 2014, Jan Beulich wrote:
>> >> but I still don't see why ARM needs what x86 (even for HVM) appears to
>> >> get along fine without.
>> > 
>> > Good question.
>> > x86 PV guests have in xen_irq_enable:
>> > 
>> > if (unlikely(vcpu->evtchn_upcall_pending))
>> >         xen_force_evtchn_callback();
>> > 
>> > Also xen_irq_enable_direct calls check_events.
>> > 
>> > I suspect that PV on HVM guests that get events via gsi interrupts get
>> > away without it because they only call VCPUOP_register_vcpu_info on
>> > secondary cpus.
>> 
>> But my pointer was specifically to pure HVM guests (among all the
>> other possible kinds)...
> 
> Pure HVM guests don't map the vcpu info struct so they don't have this
> problem. After all they don't have event channels.
> More advanced forms of PV on HVM guests have vector callbacks that need
> no emulation at the vioapic/vlapic level.
> So that leaves us with old style PV on HVM guests, that receive event
> notifications via legacy interrupts, but only to the first vcpu. This is
> the case I am talking about.
> 
> Am I missing anything?

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?

Jan


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