On 12/01/2010 01:17 PM, Andre Przywara wrote:
Currently the number of CPUID leaves KVM handles is limited to 40. My desktop machine (AthlonII) already has 35 and future CPUs will expand this well beyond the limit. Extend the limit to 80 to make room for future processors. Signed-off-by: Andre Przywara<andre.przywara@xxxxxxx> --- arch/x86/include/asm/kvm_host.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Hi, I found that either KVM or QEMU (possibly both) are broken in respect to handling more CPUID entries than the limit dictates. KVM will return -E2BIG, which is the same error as if the user hasn't provided enough space to hold all entries. Now QEMU will continue to enlarge the allocated memory until it gets into an out-of-memory condition. I have tried to fix this with teaching KVM how to deal with a capped number of entries (there are some bugs in the current code), but this will limit the number of CPUID entries KVM handles, which will surely cut of the lastly appended PV leaves. A proper fix would be to make this allocation dynamic. Is this a feasible way or will this lead to issues or side-effects?
Well, there has to be some limit, or userspace can allocate unbounded kernel memory.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
