Re: kvm vmload/vmsave vs tss.ist

[Ingo Molnar]

* Avi Kivity <avi@xxxxxxxxxx> wrote:

> 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?

i'd suggest to reuse the irq-stacks for this. Right now on 64-bit we've 
got the following stack layout: 8K process stacks, a 16K IRQ stack on each 
CPU, shared by all IRQs. Then we have the IST stacks with weird sizes: 
debug:8K, the others: 4K.

Then all the unnecessary IST complications can be removed. If nesting ever 
becomes an issue, the IRQ stack size can be doubled to 32K.

This way we save some small amount of RAM too (right now the IST stacks 
take up 28K of RAM per CPU), and reduce complexity and fragility quite 
visibly. And help KVM ;-)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/