kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>
Subject: Re: [PATCH RFC 3/4] KVM: Define KVM_USER_MEM_SLOTS in arch-neutral include/linux/kvm_host.h
Date: Mon, 18 Jan 2021 10:52:19 +0100	[thread overview]
Message-ID: <87wnwa608c.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <YAHLRVhevn7adhAz@google.com>

Sean Christopherson <seanjc@google.com> writes:

> On Fri, Jan 15, 2021, Vitaly Kuznetsov wrote:
>> Memory slots are allocated dynamically when added so the only real
>> limitation in KVM is 'id_to_index' array which is 'short'. Define
>> KVM_USER_MEM_SLOTS to the maximum possible value in the arch-neutral
>> include/linux/kvm_host.h, architectures can still overtide the setting
>> if needed.
>
> Leaving the max number of slots nearly unbounded is probably a bad idea.  If my
> math is not completely wrong, this would let userspace allocate 6mb of kernel
> memory per VM.  Actually, worst case scenario would be 12mb since modifying
> memslots temporarily has two allocations.

Yea I had thought too but on the other hand, if your VMM went rogue and
and is trying to eat all your memory, how is allocating 32k memslots
different from e.g. creating 64 VMs with 512 slots each? We use
GFP_KERNEL_ACCOUNT to allocate memslots (and other per-VM stuff) so
e.g. cgroup limits should work ...

>
> If we remove the arbitrary limit, maybe replace it with a module param with a
> sane default?

This can be a good solution indeed. The only question then is what should
we pick as the default? It seems to me this can be KVM_MAX_VCPUS
dependent, e.g. 4 x KVM_MAX_VCPUS would suffice.

>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>>  include/linux/kvm_host.h | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index f3b1013fb22c..ab83a20a52ca 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -425,6 +425,10 @@ struct kvm_irq_routing_table {
>>  #define KVM_PRIVATE_MEM_SLOTS 0
>>  #endif
>>  
>> +#ifndef KVM_USER_MEM_SLOTS
>> +#define KVM_USER_MEM_SLOTS (SHRT_MAX - KVM_PRIVATE_MEM_SLOTS)
>> +#endif
>> +
>>  #ifndef KVM_MEM_SLOTS_NUM
>>  #define KVM_MEM_SLOTS_NUM (KVM_USER_MEM_SLOTS + KVM_PRIVATE_MEM_SLOTS)
>>  #endif
>> -- 
>> 2.29.2
>> 
>

-- 
Vitaly


  reply	other threads:[~2021-01-18 10:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 13:18 [PATCH RFC 0/4] KVM: x86: Drastically raise KVM_USER_MEM_SLOTS limit Vitaly Kuznetsov
2021-01-15 13:18 ` [PATCH RFC 1/4] KVM: x86: Drop redundant KVM_MEM_SLOTS_NUM definition Vitaly Kuznetsov
2021-01-15 16:47   ` Sean Christopherson
2021-01-15 13:18 ` [PATCH RFC 2/4] KVM: mips: Drop KVM_PRIVATE_MEM_SLOTS definition Vitaly Kuznetsov
2021-01-15 13:18 ` [PATCH RFC 3/4] KVM: Define KVM_USER_MEM_SLOTS in arch-neutral include/linux/kvm_host.h Vitaly Kuznetsov
2021-01-15 17:05   ` Sean Christopherson
2021-01-18  9:52     ` Vitaly Kuznetsov [this message]
2021-01-19 17:20       ` Sean Christopherson
2021-01-20 11:34         ` Igor Mammedov
2021-01-20 12:02           ` Vitaly Kuznetsov
2021-01-20 17:25             ` Sean Christopherson
2021-01-15 13:18 ` [PATCH RFC 4/4] KVM: x86: Stop limiting KVM_USER_MEM_SLOTS Vitaly Kuznetsov
2021-01-15 16:03 ` [PATCH RFC 0/4] KVM: x86: Drastically raise KVM_USER_MEM_SLOTS limit Sean Christopherson
2021-01-15 16:23   ` Vitaly Kuznetsov
2021-01-15 16:45     ` Sean Christopherson
2021-01-15 18:47 ` Maciej S. Szmigiero
2021-01-27 17:55   ` Vitaly Kuznetsov
2021-01-27 22:26     ` Maciej S. Szmigiero
2021-01-28  8:47       ` Vitaly Kuznetsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnwa608c.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).