Re: [Xen-devel] [Xenhackthon] Virtualized APIC registers - virtual interrupt delivery.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > >>>>> OK, in which case Linux ~v2.6.32 (when the event callback mechanism 
> > >>>>> was
> > >>>>> introduced for HVM guests) will _not_ take advantage of this, right?
> > >>>> Yes, event mechanism cannot benefit from it.
> > >>> 
> > >>> I think that Konrad was referring to the vector callback mechanism:
> > >> You are right. What I want to say is vector callback mechanism.
> > >> 
> > >>> 
> > >>> linux side  drivers/xen/events.c:xen_callback_vector
> > >>> xen side    xen/arch/x86/hvm/irq.c:hvm_set_callback_via
> > >>> 
> > >>> Also see:
> > >>> 
> > >>> commit e5fd1f6505c43440bc2450253c79c80174b693bc
> > >>> Author: Keir Fraser <keir.fraser@xxxxxxxxxx>
> > >>> Date:   Tue May 25 11:28:58 2010 +0100
> > >>> 
> > >>>     x86 hvm: implement vector callback for evtchn delivery
> > >>>     
> > >>>     Signed-off-by: Sheng Yang <sheng@xxxxxxxxxxxxxxx>
> > >>>     Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > >>>     Signed-off-by: Keir Fraser <keir.fraser@xxxxxxxxxx>
> > >>> From the guest point of view it looks like a normal vector callback
> > >>> (similar to an IPI).
> > >>> 
> > >>> 
> > >>>>> Is there a way to solve this so that they _will_ take advantage of 
> > >>>>> this.
> > >>>> Perhaps not. virtual interrupt delivery relies on EOI logic to inject 
> > >>>> the
> > > pending
> > >>> interrupt. But event channel doesn't have such mechanism.
> > >>> 
> > >>> It's true that we don't do any EOIs with the vector callback mechanism,
> > >>> the same way the operating system doesn't do any EOIs when it receives
> > >>> an IPI.
> > >> IPI also need EOI.
> > > 
> > > Ooops, you are right.
> > > 
> > > Does guest EOI still cause a trap into Xen?
> > It depends on the bit in EOI exit bitmap. If it is set, then EOI still will 
> > cause vmexit(EOI-induced vmexit). Otherwise, no vmexit happened.
> > 
> > The following pseudocode details the behavior of EOI virtualization:
> > Vector â SVI;
> > VISR[Vector] â 0;
> > IF any bits set in VISR
> > THEN SVI â highest index of bit set in VISR
> > ELSE SVI â 0;
> > FI;
> > perform PPR virtualiation
> > IF EOI_exit_bitmap[Vector] = 1 
> > THEN cause EOI-induced VM exit with Vector as exit qualification;
> > ELSE evaluate pending virtual interrupts; 
> > FI;
> 
> Thanks for the explanation.
> 
> At this point I wonder: would vector callbacks, that doesn't do any
> guest EOIs, create any problems to this new virtual interrupt delivery
> mechanism?
> If the guest does not do any EOIs after receiving a vector callback,
> then other pending interrupts are never evaluated (the last ELSE
> condition in your pseudocode cannot happen), is that correct?
> 
> In any case we could consider introducing an ack_APIC_irq() call at the
> beginning of xen_evtchn_do_upcall, so that the vector callback mechanism
> can take advantage of posted interrupts too.

Or just split the mechanism. Meaning use the event callback for "legacy"
type events, and for PCI passthrough devices (where the host supports
posted interrupts) just use the baremetal implementation.

That would entail some form of hypercall to identify whether a PCIe device
is "posted-interrupt" candidate and if so don't use the event channel
mechanism for it.

> Of course we would do that only if posted interrupts are available.

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


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