From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
qemu-devel@nongnu.org, "Amit Shah" <amit@kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
dgilbert@redhat.com, "Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2 10/10] hostmem: use object id for memory region name with >= 3.1
Date: Thu, 1 Nov 2018 16:16:12 +0100 [thread overview]
Message-ID: <20181101161612.0287cdb5@redhat.com> (raw)
In-Reply-To: <20181031202757.GE30771@habkost.net>
On Wed, 31 Oct 2018 17:27:57 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Tue, Oct 30, 2018 at 07:04:53PM +0400, Marc-André Lureau wrote:
> > hostmem-file and hostmem-memfd use the whole object path for the
> > memory region name, and hostname-ram uses only the path component (the
> > object id, or canonical path basename):
> >
> > qemu -m 1024 -object memory-backend-file,id=mem,size=1G,mem-path=/tmp/foo -numa node,memdev=mem -monitor stdio
> > (qemu) info ramblock
> > Block Name PSize Offset Used Total
> > /objects/mem 4 KiB 0x0000000000000000 0x0000000040000000 0x0000000040000000
> >
> > qemu -m 1024 -object memory-backend-memfd,id=mem,size=1G -numa node,memdev=mem -monitor stdio
> > (qemu) info ramblock
> > Block Name PSize Offset Used Total
> > /objects/mem 4 KiB 0x0000000000000000 0x0000000040000000 0x0000000040000000
> >
> > qemu -m 1024 -object memory-backend-ram,id=mem,size=1G -numa node,memdev=mem -monitor stdio
> > (qemu) info ramblock
> > Block Name PSize Offset Used Total
> > mem 4 KiB 0x0000000000000000 0x0000000040000000 0x0000000040000000
> >
> > Use the object id for -file and -memfd with >= 3.1 for consistency.
> > Having a consistent naming allow to migrate to different hostmem
> > backends.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> I don't want to make you feel like you wasted your time on the
> global property system refactor, but:
>
> Maybe it would be simpler to add a
> bool MachineClass::canonical_path_for_ramblock_id
I dislike adding compat flags in random places in this case
it has nothing to do with machine.
> field, instead of refactoring the global property system,
> considering that we're past soft freeze?
We can merge it for 3.2,
I have another potential usage for Mark's work,
converting initial memory to memory devices (so far only ARM),
where we would need to keep ramblock id's compatible across
different machine versions and a different way we were creating
initial memory memory regions so migration would not fail.
> Sometimes I think the global property system was a mistake, and
> that we should avoid spreading it to other subsystems.
Well user accessible globals might be a mistake,
but it's quite useful/convenient API to fix compatibility parameters
for different machines/versions in uniform way without hacking
unrelated code.
next prev parent reply other threads:[~2018-11-01 15:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-30 15:04 [Qemu-devel] [PATCH v2 00/10] hostmem: use object "id" for memory region name with >= 3.1 Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 01/10] qom: make user_creatable_complete() specific to UserCreatable Marc-André Lureau
2018-11-01 11:03 ` Igor Mammedov
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 02/10] accel: register global_props like machine globals Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 03/10] qdev: move qdev_prop_register_global_list() to tests Marc-André Lureau
2018-10-31 20:22 ` Eduardo Habkost
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 04/10] qom/globals: move qdev globals to qom Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 05/10] qom/globals: generalize object_property_set_globals() Marc-André Lureau
2018-10-31 20:12 ` Eduardo Habkost
2018-11-01 10:18 ` Igor Mammedov
2018-11-01 15:27 ` Eduardo Habkost
2018-11-01 15:58 ` Igor Mammedov
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 06/10] qom/object: set globals when initializing object Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 07/10] qom/object: add set_globals flags Marc-André Lureau
2018-10-31 20:23 ` Eduardo Habkost
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 08/10] tests: add user-creatable test to test-qdev-global-props Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 09/10] hw/i386: add pc-i440fx-3.1 & pc-q35-3.1 Marc-André Lureau
2018-10-31 20:14 ` Eduardo Habkost
2018-11-01 14:59 ` Igor Mammedov
2018-11-20 12:00 ` Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 10/10] hostmem: use object id for memory region name with >= 3.1 Marc-André Lureau
2018-10-31 20:27 ` Eduardo Habkost
2018-11-01 15:16 ` Igor Mammedov [this message]
2018-11-01 15:31 ` Eduardo Habkost
2018-10-31 14:41 ` [Qemu-devel] [PATCH v2 00/10] hostmem: use object "id" " no-reply
2018-10-31 14:43 ` no-reply
2018-11-03 3:37 ` no-reply
2018-11-03 3:39 ` no-reply
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=20181101161612.0287cdb5@redhat.com \
--to=imammedo@redhat.com \
--cc=afaerber@suse.de \
--cc=amit@kernel.org \
--cc=atar4qemu@gmail.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).