From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm vmload/vmsave vs tss.ist Date: Thu, 25 Dec 2008 17:46:45 +0200 Message-ID: <4953AAE5.4000708@redhat.com> References: <49539FD0.7070103@redhat.com> <20081225151757.GA25117@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "H. Peter Anvin" , Joerg Roedel , Benjamin Serebrin , linux-kernel , kvm@vger.kernel.org, Alexander Graf To: Ingo Molnar Return-path: Received: from mx2.redhat.com ([66.187.237.31]:44580 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751950AbYLYPrB (ORCPT ); Thu, 25 Dec 2008 10:47:01 -0500 In-Reply-To: <20081225151757.GA25117@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: Ingo Molnar wrote: > i think we should actually do #1 unconditionally. > > ISTs are bad for the native kernel too. They have various nasty > complications in the stack walker (and hence they _reduce_ reliability in > practice), and they are non-preemptible as well. Plus we have the > maximum-stack-footprint ftrace plugin now, which can remove any perception > about how bad the worst-case stack footprint is in practice. > > If it ever becomes an issue we could also soft-switch to a larger (per > CPU) exception stack from the exception handlers themselves. The > architectural stack footprint of the various critical exceptions are > calculatable and low - so we could switch away and get almost the kind of > separation that ISTs give. There's no deep reason to actually make use of > hw switched ISTs. > > So feel free to send a patch that just standardizes the critical > exceptions to use the regular kernel stack. (I havent actually tried this > but it should be relatively simple to implement. Roadblocks are possible.) > Certainly. There is provision for a debug stack that can be larger than the normal exception stack. This is used for vectors 1 and 3. If we wish to preserve this, we need to to manual stack switching. Currently DEBUG_STKSZ is 8K, the same as the normal stack (compared to 4K for the other execption stacks). Do we need to implement stack switching for debug vectors? -- error compiling committee.c: too many arguments to function