Yes, things like kvm_lapic_state are way too big to be on the stack.
I had a quick look at the code, and my worry about dynamic allocation
would be that handling allocation failure seems like it might get
tricky. Eg for handling struct kvm_pv_mmu_op_buffer (which is 528 bytes
on the stack in
On Thu, 2008-07-17 at 08:52 +0300, Avi Kivity wrote:
Dave Hansen wrote:
Avi, how would you like this fixed? I'd be happy to prepare some
patches. Do you have a particular approach that you think we should
use? Just make the big objects dynamically allocated?
Yes, things like
A newer gcc (4.2) makes this a wee bit better, but probably still
worrisome.
[EMAIL PROTECTED]:~/src/kvm-userspace-virgin/kernel$ objdump -d *.ko | perl
/home/dave/kernels/linux-2.6.git-t61/scripts/checkstack.pl i386
0x7b33 kvm_arch_vm_ioctl [kvm]: 1164
0x72e8
Dave Hansen wrote:
switch (...) {
case x: {
struct medium a;
...
}
case y:
struct medium b;
...
}
};
These could be solved either by stack allocation, or by moving into
functions marked noinline. Whichever is easier.
Did you mean
Dave Hansen wrote:
On Wed, 2008-07-16 at 23:08 -0700, Roland Dreier wrote:
Yes, things like kvm_lapic_state are way too big to be on the
stack.
I had a quick look at the code, and my worry about dynamic allocation
would be that handling allocation failure seems like it might get
tricky.
On Wed, 2008-07-16 at 14:44 -0700, Dave Hansen wrote:
On a suggestion of Anthony's, I tried a defconfig kernel.
It is now bombing out on an assertion in the lapic code:
http://sr71.net/~dave/linux/2.6.26-oops1.txt
I think I found it!!!
$ (objdump -d kvm.ko ; objdump -d kvm-intel.ko
Dave Hansen wrote:
On Wed, 2008-07-16 at 14:44 -0700, Dave Hansen wrote:
On a suggestion of Anthony's, I tried a defconfig kernel.
It is now bombing out on an assertion in the lapic code:
http://sr71.net/~dave/linux/2.6.26-oops1.txt
I think I found it!!!
$ (objdump -d
