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.
On Tue, 2011-12-06 at 14:39 +1100, Matt Evans wrote:
> Architectures can recommend/count/determine number of CPUs differently, so move
> this out of generic code.
>
> Signed-off-by: Matt Evans <matt@xxxxxxxxxx>
> ---
> tools/kvm/kvm.c | 30 ------------------------------
> tools/kvm/x86/kvm.c | 30 ++++++++++++++++++++++++++++++
> 2 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
> index 7ce1640..e526483 100644
> --- a/tools/kvm/kvm.c
> +++ b/tools/kvm/kvm.c
> @@ -259,17 +259,6 @@ void kvm__register_mem(struct kvm *kvm, u64 guest_phys, u64 size, void *userspac
> die_perror("KVM_SET_USER_MEMORY_REGION ioctl");
> }
>
> -int kvm__recommended_cpus(struct kvm *kvm)
> -{
> - int ret;
> -
> - ret = ioctl(kvm->sys_fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS);
> - if (ret <= 0)
> - die_perror("KVM_CAP_NR_VCPUS");
> -
> - return ret;
> -}
> -
> static void kvm__pid(int fd, u32 type, u32 len, u8 *msg)
> {
> pid_t pid = getpid();
> @@ -282,25 +271,6 @@ static void kvm__pid(int fd, u32 type, u32 len, u8 *msg)
> pr_warning("Failed sending PID");
> }
>
> -/*
> - * The following hack should be removed once 'x86: Raise the hard
> - * VCPU count limit' makes it's way into the mainline.
> - */
> -#ifndef KVM_CAP_MAX_VCPUS
> -#define KVM_CAP_MAX_VCPUS 66
> -#endif
> -
> -int kvm__max_cpus(struct kvm *kvm)
> -{
> - int ret;
> -
> - ret = ioctl(kvm->sys_fd, KVM_CHECK_EXTENSION, KVM_CAP_MAX_VCPUS);
> - if (ret <= 0)
> - ret = kvm__recommended_cpus(kvm);
> -
> - return ret;
> -}
> -
> struct kvm *kvm__init(const char *kvm_dev, u64 ram_size, const char *name)
> {
> struct kvm *kvm;
> diff --git a/tools/kvm/x86/kvm.c b/tools/kvm/x86/kvm.c
> index ac6c91e..75e4a52 100644
> --- a/tools/kvm/x86/kvm.c
> +++ b/tools/kvm/x86/kvm.c
> @@ -76,6 +76,36 @@ bool kvm__arch_cpu_supports_vm(void)
> return regs.ecx & (1 << feature);
> }
>
> +int kvm__recommended_cpus(struct kvm *kvm)
> +{
> + int ret;
> +
> + ret = ioctl(kvm->sys_fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS);
> + if (ret <= 0)
> + die_perror("KVM_CAP_NR_VCPUS");
> +
> + return ret;
> +}
> +
> +/*
> + * The following hack should be removed once 'x86: Raise the hard
> + * VCPU count limit' makes it's way into the mainline.
> + */
> +#ifndef KVM_CAP_MAX_VCPUS
> +#define KVM_CAP_MAX_VCPUS 66
> +#endif
> +
> +int kvm__max_cpus(struct kvm *kvm)
> +{
> + int ret;
> +
> + ret = ioctl(kvm->sys_fd, KVM_CHECK_EXTENSION, KVM_CAP_MAX_VCPUS);
> + if (ret <= 0)
> + ret = kvm__recommended_cpus(kvm);
> +
> + return ret;
> +}
> +
> /*
> * Allocating RAM size bigger than 4GB requires us to leave a gap
> * in the RAM which is used for PCI MMIO, hotplug, and unconfigured
> --
> 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
--
Sasha.
--
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
