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

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

Keir Fraser wrote on 2013-03-26:
> On 26/03/2013 03:15, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> 
>>>> Also, should we care about such malicious guest? If the guest really did
>>>> such
>>>> thing, it just block himself. It just eat the cpu time which belong to
>>>> himself. A malicious guest can run a non-stop loop to do same thing.
>>> 
>>> No, the spin loop is in the hypervisor. So it is a denial-of-service attack
>>> on the hypervisor -- i.e., a security concern.
>> 
>> Ok. So we cannot simply removing the tasklet mechanism to fix the issue.
>> How about we add all target vcpu to a list and iterate the list to wake up 
>> all
>> VCPUs in then tasklet callback. Then we can wake up all vcpus by call tasklet
>> once.
>> 
>> Like this:
>> static int vlapic_schedule_init_sipi_tasklet(struct vcpu *target, uint32_t
>> icr)
>>  {
>> add target to a list; schedule tasklet; return X86EMUL_OKAY; //here we
>> return ok instead retry, because we can handle all vcpus just once. }
>> 
>> And in tasklet call back:
>> for_each_entry_in list
>> {
>> call vlapic_init_sipi_action();
>> }
> 
> You'll have t elaborate on the problem *you* are trying to solve, and why
> such a change would do the trick. If there's good reason, I'm not against a
> change such as this. But the code is subtle and I don't want to mess with it
> if there are simpler solutions.
The problem is:
With apicv support, the apic write is trap like vmexit. We cannot fallback to 
guest to retry the instruction. So it will break current logic.

Best regards,
Yang



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