qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-s390x@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Huth <thuth@redhat.com>, Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>
Subject: Re: [PATCH v1 06/14] s390x: introduce s390_get_memory_limit()
Date: Tue, 17 Sep 2024 14:48:37 +0200	[thread overview]
Message-ID: <229425cd92897e4ff3b5f4456c1c75215668358e.camel@linux.ibm.com> (raw)
In-Reply-To: <e91fa726-2a72-486a-a687-ec3a29100cc0@redhat.com>

On Tue, 2024-09-17 at 13:23 +0200, David Hildenbrand wrote:
> On 16.09.24 15:20, Nina Schoetterl-Glausch wrote:
> > On Tue, 2024-09-10 at 19:58 +0200, David Hildenbrand wrote:
> > > Let's add s390_get_memory_limit(), to query what has been successfully
> > > set via s390_set_memory_limit(). Allow setting the limit only once.
> > > 
> > > Signed-off-by: David Hildenbrand <david@redhat.com>
> > 
> > Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> > 
> > Comment below.
> > > ---
> > >   target/s390x/cpu-sysemu.c | 19 +++++++++++++++++--
> > >   target/s390x/cpu.h        |  1 +
> > >   2 files changed, 18 insertions(+), 2 deletions(-)

[...]

> > > +
> > > +uint64_t s390_get_memory_limit(void)
> > > +{
> > 
> > Might be nice to guard/warn against s390_set_memory_limit not having been called before.
> > 
> 
> What about the following on top:
> 
> diff --git a/target/s390x/cpu-sysemu.c b/target/s390x/cpu-sysemu.c
> index 1915567b3a..07cb85103a 100644
> --- a/target/s390x/cpu-sysemu.c
> +++ b/target/s390x/cpu-sysemu.c
> @@ -263,6 +263,8 @@ int s390_set_memory_limit(uint64_t new_limit, uint64_t *hw_limit)
>   
>       if (memory_limit) {
>           return -EBUSY;
> +    } else if (!new_limit) {
> +        return -EINVAL;
>       }
>       if (kvm_enabled()) {
>           ret = kvm_s390_set_mem_limit(new_limit, hw_limit);
> @@ -275,6 +277,8 @@ int s390_set_memory_limit(uint64_t new_limit, uint64_t *hw_limit)
>   
>   uint64_t s390_get_memory_limit(void)
>   {
> +    /* We expect to be called after s390_set_memory_limit(). */
> +    assert(memory_limit);
>       return memory_limit;
>   }

Looks good.

Looking at the patch again I'm wondering if using globals in qemu is still encouraged.
I know it's a common pattern today, but seeing efforts like the multiarch binary or Unicorn
I'm wondering if there is aspirations to do things more "cleanly", in general, for far out benefits?
I.e. memory_limit could be a machine property instead.


  reply	other threads:[~2024-09-17 12:49 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10 17:57 [PATCH v1 00/14] s390x: virtio-mem support David Hildenbrand
2024-09-10 17:57 ` [PATCH v1 01/14] s390x/s390-virtio-ccw: don't crash on weird RAM sizes David Hildenbrand
2024-09-11 11:28   ` Janosch Frank
2024-09-11 12:38     ` David Hildenbrand
2024-09-11 12:46       ` Thomas Huth
2024-09-11 12:54         ` David Hildenbrand
2024-09-11 11:58   ` Thomas Huth
2024-09-12 20:28   ` Eric Farman
2024-09-23  9:19   ` David Hildenbrand
2024-09-23 15:36     ` Thomas Huth
2024-09-23 15:39       ` David Hildenbrand
2024-09-10 17:57 ` [PATCH v1 02/14] s390x/s390-virtio-hcall: remove hypercall registration mechanism David Hildenbrand
2024-09-11 16:02   ` Thomas Huth
2024-09-10 17:57 ` [PATCH v1 03/14] s390x/s390-virtio-hcall: prepare for more diag500 hypercalls David Hildenbrand
2024-09-11 17:04   ` Thomas Huth
2024-09-12 13:22   ` Nina Schoetterl-Glausch
2024-09-17 10:45     ` David Hildenbrand
2024-09-17 10:50       ` David Hildenbrand
2024-09-17 11:02         ` David Hildenbrand
2024-09-17 12:59           ` Nina Schoetterl-Glausch
2024-09-10 17:57 ` [PATCH v1 04/14] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2024-09-11 17:05   ` Thomas Huth
2024-09-10 17:58 ` [PATCH v1 05/14] s390x/s390-virtio-ccw: move setting the maximum guest size from sclp to machine code David Hildenbrand
2024-09-12  8:07   ` Thomas Huth
2024-09-10 17:58 ` [PATCH v1 06/14] s390x: introduce s390_get_memory_limit() David Hildenbrand
2024-09-12  8:10   ` Thomas Huth
2024-09-16 13:20   ` Nina Schoetterl-Glausch
2024-09-17 11:23     ` David Hildenbrand
2024-09-17 12:48       ` Nina Schoetterl-Glausch [this message]
2024-09-23  9:20         ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 07/14] s390x/s390-hypercall: introduce DIAG500 STORAGE_LIMIT David Hildenbrand
2024-09-12  8:19   ` Thomas Huth
2024-09-12 10:54     ` Janosch Frank
2024-09-27 18:05     ` Halil Pasic
2024-09-27 18:34       ` David Hildenbrand
2024-09-30 11:11       ` Christian Borntraeger
2024-09-30 12:57         ` Halil Pasic
2024-10-01  9:15           ` Christian Borntraeger
2024-10-01 13:31             ` Halil Pasic
2024-10-01 14:35               ` Christian Borntraeger
2024-09-30 13:13         ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 08/14] s390x/s390-stattrib-kvm: prepare memory devices and sparse memory layouts David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 09/14] s390x/s390-skeys: prepare for memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 10/14] s390x/pv: check initial, not maximum RAM size David Hildenbrand
2024-09-24 16:22   ` Nina Schoetterl-Glausch
2024-09-24 20:17     ` David Hildenbrand
2024-09-26  9:04       ` David Hildenbrand
2024-09-30 11:15       ` Christian Borntraeger
2024-09-30 11:37         ` Claudio Imbrenda
2024-09-30 13:14           ` David Hildenbrand
2024-09-30 13:26             ` Claudio Imbrenda
2024-09-10 17:58 ` [PATCH v1 11/14] s390x/s390-virtio-ccw: prepare for memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 12/14] s390x: introduce s390_get_max_pagesize() David Hildenbrand
2024-09-26 10:22   ` David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 13/14] s390x/virtio-ccw: add support for virtio based memory devices David Hildenbrand
2024-09-10 17:58 ` [PATCH v1 14/14] s390x: virtio-mem support David Hildenbrand
2024-09-10 18:33 ` [PATCH v1 00/14] " Michael S. Tsirkin
2024-09-10 18:45   ` David Hildenbrand
2024-09-11 11:49 ` Janosch Frank
2024-09-11 12:28   ` David Hildenbrand
2024-09-11 14:04     ` Michael S. Tsirkin
2024-09-11 15:38       ` Cornelia Huck
2024-09-11 19:09         ` David Hildenbrand
2024-09-27 18:20           ` Halil Pasic
2024-09-27 18:29             ` David Hildenbrand
2024-09-30 21:49               ` Halil Pasic
2024-10-01  8:54                 ` David Hildenbrand
2024-10-02  9:04                   ` Janosch Frank
2024-10-07 12:23                     ` 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=229425cd92897e4ff3b5f4456c1c75215668358e.camel@linux.ibm.com \
    --to=nsg@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.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).