From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: use tasklet to handle init/sipi? Date: Tue, 26 Mar 2013 06:07:14 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Yang Z" , "xen-devel@lists.xen.org" Cc: "Zhang, Xiantao" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 26/03/2013 03:15, "Zhang, Yang Z" 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. -- Keir