On 07/12/11 18:24, Alexander Graf wrote: > > On 07.12.2011, at 08:19, Matt Evans <[email protected]> wrote: > >> On 07/12/11 17:34, Sasha Levin wrote: >>> On Wed, 2011-12-07 at 17:17 +1100, Matt Evans wrote: >>>> On 06/12/11 19:20, Sasha Levin wrote: >>>>> Why is it getting moved out of generic code? >>>>> >>>>> This is used to determine the maximum amount of vcpus supported by the >>>>> host for a single guest, and as far as I know KVM_CAP_NR_VCPUS and >>>>> KVM_CAP_MAX_VCPUS are not arch specific. >>>> >>>> I checked api.txt and you're right, it isn't arch-specific. I assumed it >>>> was, >>>> because PPC KVM doesn't support it ;-) I've dropped this patch and in its >>>> place >>>> implemented the api.txt suggestion of "if KVM_CAP_NR_VCPUS fails, use 4" >>>> instead >>>> of die(); you'll see that when I repost. >>>> >>>> This will have the effect of PPC being limited to 4 CPUs until the kernel >>>> supports that CAP. (I'll see about this part too.) >>> >>> I went to look at which limitation PPC places on amount of vcpus in >>> guest, and saw this in kvmppc_core_vcpu_create() in the book3s code: >>> >>> vcpu = kvmppc_core_vcpu_create(kvm, id); >>> vcpu->arch.wqp = &vcpu->wq; >>> if (!IS_ERR(vcpu)) >>> kvmppc_create_vcpu_debugfs(vcpu, id); >>> >>> This is wrong, right? The VCPU is dereferenced before actually checking >>> that it's not an error. >> >> Yeah, that's b0rk. Alex, a patch below. :) > > Thanks :). Will apply asap but don't have a real keyboard today :).
Ha! Voice control on your phone, what could go wrong? > I suppose this is stable material? Good idea, (and if we're formal, Signed-off-by: Matt Evans <[email protected]> ). I suppose no one's seen a vcpu fail to be created, yet. Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
