All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.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 09:34:49 -0800	[thread overview]
Message-ID: <Z4FaOW3-hen3nIpF@google.com> (raw)
In-Reply-To: <20250110180225.06dfba3c@p-imbrenda>

On Fri, Jan 10, 2025, Claudio Imbrenda wrote:
> On Fri, 10 Jan 2025 08:22:12 -0800
> Sean Christopherson <seanjc@google.com> wrote:
> > 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?

Ya, I'll refresh it today, and then I can apply it early next week and provide
an immutable topic branch/tag.

My thought is to have you carry the below in the s390 series though, as I don't
have a way to properly test it, and I'd prefer to avoid having to do a revert on
the off chance removing the limit doesn't work for ucontrol.

  reply	other threads:[~2025-01-10 17:34 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
2025-01-10 17:34           ` Sean Christopherson [this message]
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=Z4FaOW3-hen3nIpF@google.com \
    --to=seanjc@google.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=imbrenda@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=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.