Messages in this thread | | | Date | Thu, 25 Dec 2008 17:46:45 +0200 | From | Avi Kivity <> | Subject | Re: kvm vmload/vmsave vs tss.ist |
| |
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
| |