Xen project Mailing List

On Tue, Oct 29, 2013 at 7:00 PM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:

On 29/10/13 11:52, George Dunlap wrote:
> On 10/29/2013 09:57 AM, Jan Beulich wrote:
>>>>> On 29.10.13 at 10:49, Luwei Cheng <chengluwei@xxxxxxxxx> wrote:
>>> On Tue, Oct 29, 2013 at 5:34 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>> On 29.10.13 at 10:02, Luwei Cheng <chengluwei@xxxxxxxxx> wrote:
>>>>> On Tue, Oct 29, 2013 at 4:19 PM, Jan Beulich <JBeulich@xxxxxxxx>
>>>>> wrote:
>>>>>>>>> On 29.10.13 at 03:56, Luwei Cheng <chengluwei@xxxxxxxxx> wrote:
>>>>>>> Hmm.. though all vCPUs can serve the events, the hypervisor
>>>>>>> delivers the
>>>>>>> event to only "one" vCPU at at time, so only that vCPU can see
>>>>>>> this event.
>>>>>>> Analytically no race condition will be introduced.
>>>>>>
>>>>>> No - an event is globally pending (at least in the old model, the
>>>>>> situation is better with the new FIFO model), i.e. if more than
>>>>>> one of the guest's vCPU-s allowed to service it would be looking
>>>>>> at it simultaneously, they'd still need to arbitrate which one
>>>>>> ought to handle it.
>>>>>>
>>>>>> So your proposed extension might need to be limited to the
>>>>>> FIFO model.
>>>>>
>>>>> Thanks for your reply. Yes, you are right. My prior description was
>>>>> incorrect.
>>>>> When there are more than one vCPUs picking the event, even without
>>>>> arbitrary, will it cause "correctness" problem? After the event is
>>>> served by
>>>>> the first entered vCPU, and the rest vCPUs just have noting to do
>>>>> in the
>>>>> event handler (no much harm).
>>>>
>>>> That really depends on the handler. Plus it might be a performance
>>>> and/or latency issue to run handlers that don't need to be run.
>>>
>>> I think the situation is much like IO-APIC routing in physical SMP
>>> systems:
>>
>> Indeed, yet you draw the wrong conclusion.
>>
>>> in logical destination mode, all processors can serve I/O interrupts.
>>
>> But only one gets delivered any individual instance - there is
>> arbitration being done in hardware.
>
> Xen should be able to arbitrate which one gets the actual event
> delivery, right? So the only risk would be that another vcpu would
> notice the pending interrupt and handle it itself.

If events are no longer assigned to a single CPU there's no guarantee
that the CPU you deliver the event to is the one that's actually going
to handle it, another CPU might be already in the event channel upcall
and stole it from under your feet (or event worse, the event could be
fired on several CPUs at the same time, at least with the current
implementation).

The goal is: to process the event asap. So, if the event is indeed stolen by

another vCPU, we should be happy about it because it means that the event

can be processed "faster”, before the targeted vCPU picks it:)

With current implementation, the upcall only happens when the processor

switches from the hypervisor world to the guest world. It seems that the

likelihood that, such"switch" happens on multiple CPUs at the same time, is very small.

Even if the event fires on several vCPUs, what is the negative effect..?

Is the guest OS able to tolerate it (reentrant IRQ handler)?

Thanks,

Luwei

Re: [Xen-devel] [PROPOSAL] Event channel for SMP-VMs: per-vCPU or per-OS?