All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH RFCv3 9/9] s390x: initial support for virtio-mem
Date: Mon, 27 Jul 2020 12:03:08 +0200	[thread overview]
Message-ID: <20200727120308.39a4c810.cohuck@redhat.com> (raw)
In-Reply-To: <20200724143750.59836-10-david@redhat.com>

On Fri, 24 Jul 2020 16:37:50 +0200
David Hildenbrand <david@redhat.com> wrote:

> Let's wire up the initial, basic virtio-mem implementation in QEMU. It will
> have to see some important extensions (esp., resizeable allocations)
> before it can be considered production ready. Also, the focus on the Linux
> driver side is on memory hotplug, there are a lot of things optimize in
> the future to improve memory unplug capabilities. However, the basics
> are in place.
> 
> Block migration for now, as we'll have to take proper care of storage
> keys and storage attributes. Also, make sure to not hotplug huge pages
> to a setup without huge pages.
> 
> With a Linux guest that supports virtio-mem (and has
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE set for now), a basic example.
> 
> 1. Start a VM with 2G initial memory and a virtio-mem device with a maximum
>    capacity of 18GB (and an initial size of 300M):
>     sudo qemu-system-s390x \
>         --enable-kvm \
>         -m 2G,maxmem=20G \
>         -smp 4 \
>         -nographic \
>         -chardev socket,id=monitor,path=/var/tmp/monitor,server,nowait \
>         -mon chardev=monitor,mode=readline \
>         -net nic -net user \
>         -hda s390x.cow2 \
>         -object memory-backend-ram,id=mem0,size=18G \
>         -device virtio-mem-ccw,id=vm0,memdev=mem0,requested-size=300M
> 
> 2. Query the current size of virtio-mem device:
>     (qemu) info memory-devices
>     Memory device [virtio-mem]: "vm0"
>       memaddr: 0x80000000
>       node: 0
>       requested-size: 314572800
>       size: 314572800
>       max-size: 19327352832
>       block-size: 1048576
>       memdev: /objects/mem0
> 
> 3. Request to grow it to 8GB:
>     (qemu) qom-set vm0 requested-size 8G
>     (qemu) info memory-devices
>     Memory device [virtio-mem]: "vm0"
>       memaddr: 0x80000000
>       node: 0
>       requested-size: 8589934592
>       size: 8589934592
>       max-size: 19327352832
>       block-size: 1048576
>       memdev: /objects/mem0
> 
> 4. Request to shrink it to 800M (might take a while, might not fully
>    succeed, and might not be able to remove memory blocks in Linux):
>   (qemu) qom-set vm0 requested-size 800M
>   (qemu) info memory-devices
>   Memory device [virtio-mem]: "vm0"
>     memaddr: 0x80000000
>     node: 0
>     requested-size: 838860800
>     size: 838860800
>     max-size: 19327352832
>     block-size: 1048576
>     memdev: /objects/mem0
> 
> Note 1: Due to lack of resizeable allocations, we will go ahead and
> reserve a 18GB vmalloc area + size the QEMU RAM slot + KVM mamory slot
> 18GB. echo 1 > /proc/sys/vm/overcommit_memory might be required for
> now. In the future, this area will instead grow on actual demand and shrink
> when possible.
> 
> Note 2: Although virtio-mem-pci is wired up as well, it does not seem to
> work currently on s390x due to lack of MSI-X.

IIRC, you can trick virtio-pci into using msi-x via nvectors. Might be
interesting to try.

> 
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  hw/s390x/Kconfig           |   1 +
>  hw/s390x/Makefile.objs     |   1 +
>  hw/s390x/s390-virtio-ccw.c | 121 ++++++++++++++++++++++++++++++++++++-
>  hw/virtio/virtio-mem.c     |   2 +
>  4 files changed, 123 insertions(+), 2 deletions(-)



  reply	other threads:[~2020-07-27 10:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 14:37 [PATCH RFCv3 0/9] s390x: initial support for virtio-mem David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 1/9] s390x: move setting of maximum ram size to machine init David Hildenbrand
2020-07-27  9:13   ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 2/9] s390x/diag: no need to check for PGM_PRIVILEGED in diag308 David Hildenbrand
2020-07-27  9:14   ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 3/9] s390x: remove hypercall registration mechanism David Hildenbrand
2020-07-27  9:24   ` Cornelia Huck
2020-07-27  9:29     ` David Hildenbrand
2020-07-27  9:48     ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 4/9] s390x: prepare for more diag500 hypercalls David Hildenbrand
2020-07-27  9:42   ` Cornelia Huck
2020-07-27 10:45     ` Christian Borntraeger
2020-07-24 14:37 ` [PATCH RFCv3 5/9] s390x: rename s390-virtio-hcall* to s390-hypercall* David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 6/9] s390x/diag: subcode to query device memory region David Hildenbrand
2020-07-27  9:48   ` Cornelia Huck
2020-07-27  9:52     ` David Hildenbrand
2020-07-27 10:09       ` Cornelia Huck
2020-07-27 10:12         ` David Hildenbrand
2020-07-27 11:15           ` Heiko Carstens
2020-07-27 12:02             ` David Hildenbrand
2020-07-28  7:10               ` Cornelia Huck
2020-07-29  8:57                 ` David Hildenbrand
2020-07-29  9:37                   ` Cornelia Huck
2020-07-29  9:57                     ` David Hildenbrand
2020-07-29 10:13                       ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 7/9] s390x: prepare device memory address space David Hildenbrand
2020-07-27  9:56   ` Cornelia Huck
2020-07-27  9:57     ` David Hildenbrand
2020-07-24 14:37 ` [PATCH RFCv3 8/9] s390x: implement virtio-mem-ccw David Hildenbrand
2020-07-27  9:58   ` Cornelia Huck
2020-07-27 10:02     ` David Hildenbrand
2020-07-27 10:11       ` Cornelia Huck
2020-07-24 14:37 ` [PATCH RFCv3 9/9] s390x: initial support for virtio-mem David Hildenbrand
2020-07-27 10:03   ` Cornelia Huck [this message]
2020-07-27 10:04     ` 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=20200727120308.39a4c810.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --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 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.