Re: [Xen-devel] use tasklet to handle init/sipi?

["Qiu, Shuang" <shuang.qiu@xxxxxxxxx>]

Hi Keir,

Thank you for the patch.

We've patched the enclosed file on xen-unstable and tested on qemu.git and 
qemu-upstream-unstable.git as backends.
In both cases, your patch works.

Best regards!
Shuang


-----Original Message-----
From: Keir Fraser [mailto:keir.xen@xxxxxxxxx] 
Sent: Tuesday, March 26, 2013 4:02 PM
To: Zhang, Yang Z; xen-devel@xxxxxxxxxxxxx
Cc: Jan Beulich; Zhang, Xiantao; Qiu, Shuang
Subject: Re: use tasklet to handle init/sipi?

On 26/03/2013 07:55, "Keir Fraser" <keir.xen@xxxxxxxxx> wrote:

> On 26/03/2013 07:41, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> 
>> Keir Fraser wrote on 2013-03-26:
>>> On 26/03/2013 07:17, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>>> 
>>>>>> Oh, I see. Well I think it is fine to have
>>>>>> vlapic_schedule_init_sipi_tasklet() return X86EMUL_OKAY rather 
>>>>>> than X86EMUL_RETRY. We used to need to return RETRY, but the code 
>>>>>> got simplified and now it is actually unnecessary.
>>>>>> 
>>>>>> That should make your patch a lot simpler eh? ;)
>>>>> 
>>>>> Given that you ignore the return code on the apicv call path, is 
>>>>> there currently a bug at all for you? Seems what is there already 
>>>>> must work for you?
>>>> It do cause bug after we change to use seabios. For seabios, it 
>>>> will send INIT/SIPI to all vcpus via broadcasting. And there only 
>>>> one vcpu is waken up via tasklet with current logic. That's the 
>>>> reason why I want to wakeup all vcpus on one callback. Just change 
>>>> X86EMUL_RETRY to OK cannot solve the problem. still need the logic I 
>>>> mentioned above.
>>> 
>>> Ok, wait a sec, I will sort out a patch for you to try...
>> Thanks. Actually, I have patch on hand and testing it now. But it's 
>> ok if you can provide a more better solution.
> 
> See how you like it compared with the attached patch. Attached doesn't 
> really make the code any more complicated, which is nice. However it 
> is not tested, at all. ;)

And here's a version which actually net *reduces* the code size.

 -- Keir

>  -- Keir
> 
>> Best regards,
>> Yang
>> 
>> 
> 


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