linux-kernel - Re: [PATCH 0/4] KVM: add KVM_CREATE_VM2 to allow dynamic kvm->vcpus array

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Apr 2017 14:29:03 +0200
From:   Cornelia Huck <cornelia.huck@...ibm.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     Radim Krčmář <rkrcmar@...hat.com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Christoffer Dall <cdall@...aro.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        James Hogan <james.hogan@...tec.com>,
        Paul Mackerras <paulus@...abs.org>,
        Alexander Graf <agraf@...e.com>
Subject: Re: [PATCH 0/4] KVM: add KVM_CREATE_VM2 to allow dynamic kvm->vcpus
 array

On Tue, 18 Apr 2017 13:11:55 +0200
David Hildenbrand <david@...hat.com> wrote:

> On 13.04.2017 22:19, Radim Krčmář wrote:
> > The basic idea is to let userspace provide the desired maximal number of
> > VCPUs and allocate only necessary memory for them.
> > 
> > The goal is to freeze KVM_MAX_VCPUS at its current level and only increase the
> 
> KVM_MAX_VCPUS might still increase e.g. if hw support for more VCPUs is
> comming.
> 
> > new KVM_MAX_CONFIGURABLE_VCPUS, probably directly to INT_MAX/KVM_VCPU_ID, so we
> > don't have to worry about it for a while.
> > 
> > PPC should be interested in this as they set KVM_MAX_VCPUS to NR_CPUS
> > and probably waste few pages for every guest this way.
> 
> As we just store pointers, this should be a maximum of 4 pages for ppc
> (4k pages). Is this really worth yet another VM creation ioctl? Is there
> not a nicer way to handle this internally?
> 
> An alternative might be to simply realloc the array when it reaches a
> certain size (on VCPU creation, maybe protecting the pointer via rcu).
> But not sure if something like that could work.

I like that idea better, if it does work (I think it should be doable).
If we just double the array size every time we run out of space, we
should be able to do this with few reallocations. That has also the
advantage of being transparent to user space (other than increased
number of vcpus).

> 
> > 
> > 
> > Radim Krčmář (4):
> >   KVM: remove unused __KVM_HAVE_ARCH_VM_ALLOC
> >   KVM: allocate kvm->vcpus separately
> >   KVM: add KVM_CREATE_VM2 system ioctl
> >   KVM: x86: enable configurable MAX_VCPU
> > 
> >  Documentation/virtual/kvm/api.txt | 28 +++++++++++++++
> >  arch/x86/include/asm/kvm_host.h   |  1 +
> >  arch/x86/kvm/irq_comm.c           |  4 +--
> >  include/linux/kvm_host.h          | 23 +++++-------
> >  include/uapi/linux/kvm.h          |  8 +++++
> >  virt/kvm/kvm_main.c               | 76 +++++++++++++++++++++++++++++++++------
> >  6 files changed, 114 insertions(+), 26 deletions(-)
> > 
> 
>