From: David Hildenbrand <david@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>,
David Dai <david.dai@montage-tech.com>
Cc: peter.maydell@linaro.org, vsementsov@virtuozzo.com,
eajames@linux.ibm.com, qemu-devel@nongnu.org,
changguo.du@montage-tech.com, Igor Mammedov <imammedo@redhat.com>,
kuhn.chenqun@huawei.com
Subject: Re: [PATCH] hw/misc: Add a virtual pci device to dynamically attach memory to QEMU
Date: Mon, 27 Sep 2021 11:07:43 +0200 [thread overview]
Message-ID: <38a0312e-3b00-ac41-3cb0-ab5592b06dc1@redhat.com> (raw)
In-Reply-To: <YVGAWh7e96f8yed0@stefanha-x1.localdomain>
On 27.09.21 10:27, Stefan Hajnoczi wrote:
> On Sun, Sep 26, 2021 at 10:16:14AM +0800, David Dai wrote:
>> Add a virtual pci to QEMU, the pci device is used to dynamically attach memory
>> to VM, so driver in guest can apply host memory in fly without virtualization
>> management software's help, such as libvirt/manager. The attached memory is
We do have virtio-mem to dynamically attach memory to a VM. It could be
extended by a mechanism for the VM to request more/less memory, that's
already a planned feature. But yeah, virito-mem memory is exposed as
ordinary system RAM, not only via a BAR to mostly be managed by user
space completely.
>> isolated from System RAM, it can be used in heterogeneous memory management for
>> virtualization. Multiple VMs dynamically share same computing device memory
>> without memory overcommit.
This sounds a lot like MemExpand/MemLego ... am I right that this is the
original design? I recall that VMs share a memory region and dynamically
agree upon which part of the memory region a VM uses. I further recall
that there were malloc() hooks that would dynamically allocate such
memory in user space from the shared memory region.
I can see some use cases for it, although the shared memory design isn't
what you typically want in most VM environments.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-09-27 9:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-26 2:16 [PATCH] hw/misc: Add a virtual pci device to dynamically attach memory to QEMU David Dai
2021-09-27 8:27 ` Stefan Hajnoczi
2021-09-27 9:07 ` David Hildenbrand [this message]
2021-09-27 12:28 ` david.dai
2021-09-29 9:30 ` David Hildenbrand
2021-09-30 9:40 ` david.dai
2021-09-30 10:33 ` David Hildenbrand
2021-10-09 9:42 ` david.dai
2021-10-11 7:43 ` David Hildenbrand
2021-10-13 8:13 ` david.dai
2021-10-13 8:33 ` David Hildenbrand
2021-10-15 9:10 ` david.dai
2021-10-15 9:27 ` David Hildenbrand
2021-10-15 9:57 ` david.dai
2021-09-27 12:17 ` david.dai
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=38a0312e-3b00-ac41-3cb0-ab5592b06dc1@redhat.com \
--to=david@redhat.com \
--cc=changguo.du@montage-tech.com \
--cc=david.dai@montage-tech.com \
--cc=eajames@linux.ibm.com \
--cc=imammedo@redhat.com \
--cc=kuhn.chenqun@huawei.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.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).