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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 3 Jun 2013, Konrad Rzeszutek Wilk wrote:
> > > >>>>> 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.

That should also work.

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