All of lore.kernel.org
 help / color / mirror / Atom feed
From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	frankja@linux.ibm.com, schlameuss@linux.ibm.com,
	david@redhat.com, willy@infradead.org, hca@linux.ibm.com,
	svens@linux.ibm.com, agordeev@linux.ibm.com, gor@linux.ibm.com,
	nrb@linux.ibm.com, nsg@linux.ibm.com
Subject: Re: [PATCH v1 02/13] KVM: s390: fake memslots for ucontrol VMs
Date: Fri, 10 Jan 2025 18:02:25 +0100	[thread overview]
Message-ID: <20250110180225.06dfba3c@p-imbrenda> (raw)
In-Reply-To: <Z4FJNJ3UND8LSJZz@google.com>

On Fri, 10 Jan 2025 08:22:12 -0800
Sean Christopherson <seanjc@google.com> wrote:

> On Fri, Jan 10, 2025, Claudio Imbrenda wrote:
> > On Fri, 10 Jan 2025 10:31:38 +0100
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >   
> > > Am 08.01.25 um 19:14 schrieb Claudio Imbrenda:  
> > > > +static void kvm_s390_ucontrol_ensure_memslot(struct kvm *kvm, unsigned long addr)
> > > > +{
> > > > +	struct kvm_userspace_memory_region2 region = {
> > > > +		.slot = addr / UCONTROL_SLOT_SIZE,
> > > > +		.memory_size = UCONTROL_SLOT_SIZE,
> > > > +		.guest_phys_addr = ALIGN_DOWN(addr, UCONTROL_SLOT_SIZE),
> > > > +		.userspace_addr = ALIGN_DOWN(addr, UCONTROL_SLOT_SIZE),
> > > > +	};
> > > > +	struct kvm_memory_slot *slot;
> > > > +
> > > > +	mutex_lock(&kvm->slots_lock);
> > > > +	slot = gfn_to_memslot(kvm, addr);
> > > > +	if (!slot)
> > > > +		__kvm_set_memory_region(kvm, &region);  
> 
> The return value definitely should be checked, especially if the memory regions
> are not KVM-internal, i.e. if userspace is allowed to create memslots.
> 

will fix, unless we do what you propose below

> > > > +	mutex_unlock(&kvm->slots_lock);
> > > > +}
> > > > +    
> > > 
> > > Would simply having one slot from 0 to TASK_SIZE also work? This could avoid the
> > > construction of the fake slots during runtime.  
> > 
> > unfortunately memslots are limited to 4TiB.
> > having bigger ones would require even more changes all across KVM (and
> > maybe qemu too)  
> 
> AFAIK, that limitation exists purely because of dirty bitmaps.  IIUC, these "fake"
> memslots are not intended to be visible to userspace, or at the very least don't
> *need* to be visible to userspace.
> 
> Assuming that's true, they/it can/should be KVM-internal memslots, and those
> should never be dirty-logged.  x86 allocates metadata based on slot size, so in
> practice creating a mega-slot will never succeed on x86, but the only size
> limitation I see in s390 is on arch.mem_limit, but for ucontrol that's set to -1ull,
> i.e. is a non-issue.
> 
> I have a series (that I need to refresh) to provide a dedicated API for creating
> internal memslots, and to also enforce that flags == 0 for internal memslots,
> i.e. to enforce that dirty logging is never enabled (see Link below).  With that
> I mind, I can't think of any reason to disallow a 0 => TASK_SIZE memslot so long
> as it's KVM-defined.
> 
> Using a single memslot would hopefully allow s390 to unconditionally carve out a
> KVM-internal memslot, i.e. not have to condition the logic on the type of VM.  E.g.

yes, I would love that

the reason why I did not use internal memslots is that I would have
potentially needed *all* the memslots for ucontrol, and instead of
reserving, say, half of all memslots, I decided to have them
user-visible, which is hack I honestly don't like.

do you think you can refresh the series before the upcoming merge
window?

otherwise I should split this series in two, since page->index needs to
be removed asap.

> 
>   #define KVM_INTERNAL_MEM_SLOTS 1
> 
>   #define KVM_S390_UCONTROL_MEMSLOT (KVM_USER_MEM_SLOTS + 0)
> 
> And then I think just this?
> 
> ---
> From: Sean Christopherson <seanjc@google.com>
> Date: Fri, 10 Jan 2025 08:05:09 -0800
> Subject: [PATCH] KVM: Do not restrict the size of KVM-internal memory regions
> 
> Exempt KVM-internal memslots from the KVM_MEM_MAX_NR_PAGES restriction, as
> the limit on the number of pages exists purely to play nice with dirty
> bitmap operations, which use 32-bit values to index the bitmaps, and dirty
> logging isn't supported for KVM-internal memslots.
> 
> Link: https://lore.kernel.org/all/20240802205003.353672-6-seanjc@google.com
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  virt/kvm/kvm_main.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 8a0d0d37fb17..3cea406c34db 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1972,7 +1972,15 @@ int __kvm_set_memory_region(struct kvm *kvm,
>  		return -EINVAL;
>  	if (mem->guest_phys_addr + mem->memory_size < mem->guest_phys_addr)
>  		return -EINVAL;
> -	if ((mem->memory_size >> PAGE_SHIFT) > KVM_MEM_MAX_NR_PAGES)
> +
> +	/*
> +	 * The size of userspace-defined memory regions is restricted in order
> +	 * to play nice with dirty bitmap operations, which are indexed with an
> +	 * "unsigned int".  KVM's internal memory regions don't support dirty
> +	 * logging, and so are exempt.
> +	 */
> +	if (id < KVM_USER_MEM_SLOTS &&
> +	    (mem->memory_size >> PAGE_SHIFT) > KVM_MEM_MAX_NR_PAGES)
>  		return -EINVAL;
>  
>  	slots = __kvm_memslots(kvm, as_id);
> 
> base-commit: 1aadfba8419606d447d1961f25e2d312011ad45a


  reply	other threads:[~2025-01-10 17:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-08 18:14 [PATCH v1 00/13] KVM: s390: Stop using page->index and other things Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 01/13] KVM: s390: wrapper for KVM_BUG Claudio Imbrenda
2025-01-10  9:09   ` Christian Borntraeger
2025-01-10 13:13   ` Christoph Schlameuss
2025-01-08 18:14 ` [PATCH v1 02/13] KVM: s390: fake memslots for ucontrol VMs Claudio Imbrenda
2025-01-10  9:31   ` Christian Borntraeger
2025-01-10 11:47     ` Claudio Imbrenda
2025-01-10 16:22       ` Sean Christopherson
2025-01-10 17:02         ` Claudio Imbrenda [this message]
2025-01-10 17:34           ` Sean Christopherson
2025-01-10 17:43             ` Claudio Imbrenda
2025-01-10 15:40   ` Christoph Schlameuss
2025-01-10 16:18     ` Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 03/13] KVM: s390: use __kvm_faultin_pfn() Claudio Imbrenda
2025-01-14 17:34   ` Christoph Schlameuss
2025-01-14 17:56     ` Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 04/13] KVM: s390: move pv gmap functions into kvm Claudio Imbrenda
2025-01-09 17:42   ` kernel test robot
2025-01-15 12:48   ` Janosch Frank
2025-01-15 12:59     ` Claudio Imbrenda
2025-01-15 13:23       ` Janosch Frank
2025-01-08 18:14 ` [PATCH v1 05/13] KVM: s390: get rid of gmap_fault() Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 06/13] KVM: s390: get rid of gmap_translate() Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 07/13] KVM: s390: move some gmap shadowing functions away from mm/gmap.c Claudio Imbrenda
2025-01-15  8:56   ` Janosch Frank
2025-01-15 10:20     ` Claudio Imbrenda
2025-01-15 11:48       ` Janosch Frank
2025-01-08 18:14 ` [PATCH v1 08/13] KVM: s390: stop using page->index for non-shadow gmaps Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 09/13] KVM: s390: stop using lists to keep track of used dat tables Claudio Imbrenda
2025-01-15  9:01   ` Janosch Frank
2025-01-08 18:14 ` [PATCH v1 10/13] KVM: s390: move gmap_shadow_pgt_lookup() into kvm Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 11/13] KVM: s390: remove useless page->index usage Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 12/13] KVM: s390: move PGSTE softbits Claudio Imbrenda
2025-01-08 18:14 ` [PATCH v1 13/13] KVM: s390: remove the last user of page->index Claudio Imbrenda
2025-01-15 12:17   ` Janosch Frank
2025-01-15 12:23     ` Claudio Imbrenda
2025-01-20  9:43     ` David Hildenbrand
2025-01-20 10:28       ` Claudio Imbrenda
2025-01-20 10:34         ` David Hildenbrand

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=20250110180225.06dfba3c@p-imbrenda \
    --to=imbrenda@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=nrb@linux.ibm.com \
    --cc=nsg@linux.ibm.com \
    --cc=schlameuss@linux.ibm.com \
    --cc=seanjc@google.com \
    --cc=svens@linux.ibm.com \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.