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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Stefano Stabellini wrote on 2013-06-03:
> 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?
No. Vector callback mechanism totally by pass the lapic(Please corrected me if 
I am wrong), it will not touch vIRR,vISR and no eoi needed.
So if we want to benefit from virtual interrupt delivery, we should change the 
vector callback mechanism to use lapic. But it appears to change the original 
purpose of introduce vector callback.

>>> 
>>> 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.
Currently, we don't deliver "hvm_intsrc_vector" via posted interrupt. So we 
cannot take advantage of posted interrupts even adding ack_APIC_irq() into 
xen_evtchn_do_upcall.

>> 
>> 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.
What you mean "a PCIe device is posted-interrupt candidate"? Do you mean 
pass-through device will use event channel currently?

> 
> That should also work.


Best regards,
Yang

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