public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
Cc: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: Re: [PATCH 1/5] KVM: Make the maximum number of user memslots a per-VM thing
Date: Thu, 28 Jan 2021 09:45:56 +0100	[thread overview]
Message-ID: <877dnx30vv.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <09f96415-b32d-1073-0b4f-9c6e30d23b3a@oracle.com>

"Maciej S. Szmigiero" <maciej.szmigiero@oracle.com> writes:

> On 27.01.2021 18:57, Vitaly Kuznetsov wrote:
>> Limiting the maximum number of user memslots globally can be undesirable as
>> different VMs may have different needs. Generally, a relatively small
>> number should suffice and a VMM may want to enforce the limitation so a VM
>> won't accidentally eat too much memory. On the other hand, the number of
>> required memslots can depend on the number of assigned vCPUs, e.g. each
>> Hyper-V SynIC may require up to two additional slots per vCPU.
>> 
>> Prepare to limit the maximum number of user memslots per-VM. No real
>> functional change in this patch as the limit is still hard-coded to
>> KVM_USER_MEM_SLOTS.
>> 
>> Suggested-by: Sean Christopherson <seanjc@google.com>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>
> Perhaps I didn't understand the idea clearly but I thought it was
> to protect the kernel from a rogue userspace VMM allocating many
> memslots and so consuming a lot of memory in kernel?
>
> But then what's the difference between allocating 32k memslots for
> one VM and allocating 509 slots for 64 VMs?
>

It was Sean's idea :-) Initially, I had the exact same thoughts but now
I agree with

"I see it as an easy way to mitigate the damage.  E.g. if a containers use case
is spinning up hundreds of VMs and something goes awry in the config, it would
be the difference between consuming tens of MBs and hundreds of MBs.  Cgroup
limits should also be in play, but defense in depth and all that. "

https://lore.kernel.org/kvm/YAcU6swvNkpPffE7@google.com/

That said it is not really a security feature, VMM still stays in
control. 

> A guest can't add a memslot on its own, only the host software
> (like QEMU) can, right?
>

VMMs (especially big ones like QEMU) are complex and e.g. each driver
can cause memory regions (-> memslots in KVM) to change. With this
feature it becomes possible to set a limit upfront (based on VM
configuration) so it'll be more obvious when it's hit.

-- 
Vitaly


  reply	other threads:[~2021-01-28  8:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 17:57 [PATCH 0/5] KVM: Make the maximum number of user memslots configurable and raise the default Vitaly Kuznetsov
2021-01-27 17:57 ` [PATCH 1/5] KVM: Make the maximum number of user memslots a per-VM thing Vitaly Kuznetsov
2021-01-27 22:27   ` Maciej S. Szmigiero
2021-01-28  8:45     ` Vitaly Kuznetsov [this message]
2021-01-28 10:48       ` Maciej S. Szmigiero
2021-01-28 13:01         ` Paolo Bonzini
2021-01-28 15:26           ` Vitaly Kuznetsov
2021-01-28 17:31           ` Sean Christopherson
2021-01-28 17:59             ` Paolo Bonzini
2021-02-08 14:20               ` Vitaly Kuznetsov
2021-02-08 15:02                 ` Paolo Bonzini
2021-01-27 17:57 ` [PATCH 2/5] KVM: Raise the maximum number of user memslots Vitaly Kuznetsov
2021-01-27 17:57 ` [PATCH 3/5] KVM: Make the maximum number of user memslots configurable Vitaly Kuznetsov
2021-01-27 17:57 ` [PATCH 4/5] selftests: kvm: Test the newly introduced KVM_CAP_MEMSLOTS_LIMIT Vitaly Kuznetsov
2021-01-27 17:57 ` [PATCH 5/5] selftests: kvm: Raise the default timeout to 120 seconds 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=877dnx30vv.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=maciej.szmigiero@oracle.com \
    --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