From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: David Hildenbrand <david@redhat.com>,
Igor Mammedov <imammedo@redhat.com>
Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"xiaoguangrong.eric@gmail.com" <xiaoguangrong.eric@gmail.com>,
"mst@redhat.com" <mst@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Linuxarm <linuxarm@huawei.com>,
"shannon.zhaosl@gmail.com" <shannon.zhaosl@gmail.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"xuwei \(O\)" <xuwei5@huawei.com>,
"lersek@redhat.com" <lersek@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>
Subject: RE: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
Date: Wed, 5 Feb 2020 16:29:41 +0000 [thread overview]
Message-ID: <8e0b2c762e914c64bebfab5fc7441661@huawei.com> (raw)
In-Reply-To: <4ce41554-8b8e-dbb5-5fe9-43af09950f23@redhat.com>
Hi David,
> -----Original Message-----
> From: Qemu-devel
> [mailto:qemu-devel-bounces+shameerali.kolothum.thodi=huawei.com@nongn
> u.org] On Behalf Of David Hildenbrand
> Sent: 04 February 2020 19:05
> To: Igor Mammedov <imammedo@redhat.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>
> Cc: peter.maydell@linaro.org; xiaoguangrong.eric@gmail.com;
> mst@redhat.com; shannon.zhaosl@gmail.com; qemu-devel@nongnu.org;
> xuwei (O) <xuwei5@huawei.com>; Linuxarm <linuxarm@huawei.com>;
> eric.auger@redhat.com; qemu-arm@nongnu.org; lersek@redhat.com
> Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
>
> On 04.02.20 17:44, David Hildenbrand wrote:
> > On 04.02.20 16:23, Igor Mammedov wrote:
> >> On Fri, 17 Jan 2020 17:45:16 +0000
> >> Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:
> >>
> >>> If ACPI blob length modifications happens after the initial
> >>> virt_acpi_build() call, and the changed blob length is within
> >>> the PAGE size boundary, then the revised size is not seen by
> >>> the firmware on Guest reboot. The is because in the
> >>> virt_acpi_build_update() -> acpi_ram_update() -> qemu_ram_resize()
> >>> path, qemu_ram_resize() uses used_length (ram_block size which is
> >>> aligned to PAGE size) and the "resize callback" to update the size
> >>> seen by firmware is not getting invoked.
> >>>
> >>> Hence make sure callback is called if the new size is different
> >>> from original requested size.
> >>>
> >>> Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> >>> ---
> >>> Please find the previous discussions on this issue here,
> >>> https://patchwork.kernel.org/patch/11174947/
> >>>
> >>> But this one attempts a different solution to fix it by introducing
> >>> req_length var to RAMBlock struct.
> >>>
> >>
> >> looks fine to me, so
> >> Acked-by: Igor Mammedov <imammedo@redhat.com>
> >
> > Thanks for CCing.
> >
> > This in fact collides with my changes ... but not severely :)
> >
> >>
> >> CCing David who touches this area in his latest series for and
> >> might have an opinion on how it should be handled.
> >>
> >
> > So we are talking about sub-page size changes? I somewhat dislike
> > storing "req_length" in ram blocks. Looks like sub-pages stuff does not
> > belong there.
Thanks for taking a look at this. Agree, I didn’t like that "req_length" either.
> > Ram blocks only operate on page granularity. Ram block notifiers only
> > operate on page granularity. Memory regions only operate on page
> > granularity. Dirty bitmaps operate on page granularity. Especially,
> > memory_region_size(mr) will always return aligned values.
> >
> > I think users/owner should deal with anything smaller manually if
> > they really need it.
> >
> > What about always calling the resized() callback and letting the
> > actual owner figure out if the size changed on sub-page granularity
> > or not? (by looking up the size manually using some mechanism not glued to
> > memory regions/ram blocks/whatever)
> >
> > diff --git a/exec.c b/exec.c
> > index 67e520d18e..59d46cc388 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -2130,6 +2130,13 @@ int qemu_ram_resize(RAMBlock *block,
> ram_addr_t newsize, Error **errp)
> > newsize = HOST_PAGE_ALIGN(newsize);
> >
> > if (block->used_length == newsize) {
> > + /*
> > + * The owner might want to handle sub-page resizes. We only
> provide
> > + * the aligned size - because ram blocks are always page aligned.
> > + */
> > + if (block->resized) {
> > + block->resized(block->idstr, newsize, block->host);
Does it make sense to pass the requested size in the callback than the aligned size
as the owner might be interested more in the org_req_size vs new_req _size case?
> > + }
> > return 0;
> > }
> >
> Oh, and one more reason why the proposal in this patch is inconsistent:
>
> When migrating resizable memory regions (RAM_SAVE_FLAG_MEM_SIZE) we
> store the block->used_length (ram_save_setup()) and use that value to
> resize the region on the target (ram_load_precopy() -> qemu_ram_resize()).
>
> This will be the value the callback will be called with. Page aligned.
>
Sorry, I didn’t quite get that point and not sure how "req_length" approach
will affect the migration.
Anyway, I have reworked the patch(below) with the above suggestion, that is
always calling the resized() callback, but modified it to pass the requested size
instead of the page aligned size. Please let me know your feedback.
Thanks,
Shameer
diff --git a/exec.c b/exec.c
index 67e520d18e..c9cb9a54fa 100644
--- a/exec.c
+++ b/exec.c
@@ -2123,13 +2123,22 @@ static int memory_try_enable_merging(void *addr, size_t len)
* resize callback to update device state and/or add assertions to detect
* misuse, if necessary.
*/
-int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
+int qemu_ram_resize(RAMBlock *block, ram_addr_t size, Error **errp)
{
+ ram_addr_t newsize;
assert(block);
- newsize = HOST_PAGE_ALIGN(newsize);
+ newsize = HOST_PAGE_ALIGN(size);
if (block->used_length == newsize) {
+ /*
+ * RAM blocks are always page aligned, but the owner might want
+ * to handle sub-page resizes. Let the owner know about any
+ * sub-page changes.
+ */
+ if (block->resized) {
+ block->resized(block->idstr, size, block->host);
+ }
return 0;
}
@@ -2155,7 +2164,7 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
DIRTY_CLIENTS_ALL);
memory_region_set_size(block->mr, newsize);
if (block->resized) {
- block->resized(block->idstr, newsize, block->host);
+ block->resized(block->idstr, size, block->host);
}
return 0;
}
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 179b302f01..ec9cfa4d10 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -934,9 +934,11 @@ void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
for (i = 0; i < index; i++) {
if (strcmp(filename, s->files->f[i].name) == 0) {
- ptr = fw_cfg_modify_bytes_read(s, FW_CFG_FILE_FIRST + i,
- data, len);
- s->files->f[i].size = cpu_to_be32(len);
+ if (s->files->f[i].size != cpu_to_be32(len)) {
+ ptr = fw_cfg_modify_bytes_read(s, FW_CFG_FILE_FIRST + i,
+ data, len);
+ s->files->f[i].size = cpu_to_be32(len);
+ }
return ptr;
}
}
---
next prev parent reply other threads:[~2020-02-05 16:30 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-17 17:45 [PATCH v2 0/7] ARM virt: Add NVDIMM support Shameer Kolothum
2020-01-17 17:45 ` [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback Shameer Kolothum
2020-02-04 15:23 ` Igor Mammedov
2020-02-04 16:44 ` David Hildenbrand
2020-02-04 19:05 ` David Hildenbrand
2020-02-05 16:29 ` Shameerali Kolothum Thodi [this message]
2020-02-05 16:40 ` David Hildenbrand
2020-02-06 10:20 ` Shameerali Kolothum Thodi
2020-02-06 10:55 ` David Hildenbrand
2020-02-06 11:28 ` Shameerali Kolothum Thodi
2020-02-06 14:54 ` David Hildenbrand
2020-02-07 16:05 ` Shameerali Kolothum Thodi
2020-02-10 9:29 ` David Hildenbrand
2020-02-10 9:50 ` Shameerali Kolothum Thodi
2020-02-10 9:53 ` David Hildenbrand
2020-02-12 17:07 ` Shameerali Kolothum Thodi
2020-02-12 18:20 ` David Hildenbrand
2020-02-13 16:38 ` Shameerali Kolothum Thodi
2020-02-13 16:59 ` David Hildenbrand
2020-02-13 17:09 ` David Hildenbrand
2020-02-28 16:49 ` Shameerali Kolothum Thodi
2020-02-28 17:59 ` David Hildenbrand
2020-03-11 17:28 ` Shameerali Kolothum Thodi
2020-01-17 17:45 ` [PATCH v2 2/7] hw/acpi/nvdimm: Fix for NVDIMM incorrect DSM output buffer length Shameer Kolothum
2020-01-28 17:08 ` Auger Eric
2020-02-06 16:06 ` Igor Mammedov
2020-03-10 11:22 ` Shameerali Kolothum Thodi
2020-03-10 11:36 ` Michael S. Tsirkin
2020-03-10 11:59 ` Shameerali Kolothum Thodi
2020-01-17 17:45 ` [PATCH v2 3/7] nvdimm: Use configurable ACPI IO base and size Shameer Kolothum
2020-01-17 17:45 ` [PATCH v2 4/7] hw/arm/virt: Add nvdimm hot-plug infrastructure Shameer Kolothum
2020-01-28 13:02 ` Auger Eric
2020-02-10 13:35 ` Igor Mammedov
2020-01-17 17:45 ` [PATCH v2 5/7] hw/arm/virt: Add nvdimm hotplug support Shameer Kolothum
2020-01-28 16:29 ` Auger Eric
2020-02-10 13:43 ` Igor Mammedov
2020-01-17 17:45 ` [PATCH v2 6/7] tests: Update ACPI tables list for upcoming arm/virt test changes Shameer Kolothum
2020-01-17 17:45 ` [PATCH v2 7/7] tests/bios-tables-test: Update arm/virt memhp test Shameer Kolothum
2020-01-28 16:29 ` Auger Eric
2020-01-29 10:35 ` Shameerali Kolothum Thodi
2020-01-29 13:01 ` Auger Eric
2020-02-11 10:20 ` Michael S. Tsirkin
2020-01-28 15:29 ` [PATCH v2 0/7] ARM virt: Add NVDIMM support Auger Eric
2020-01-29 10:44 ` Shameerali Kolothum Thodi
2020-01-29 12:55 ` Auger Eric
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=8e0b2c762e914c64bebfab5fc7441661@huawei.com \
--to=shameerali.kolothum.thodi@huawei.com \
--cc=david@redhat.com \
--cc=eric.auger@redhat.com \
--cc=imammedo@redhat.com \
--cc=lersek@redhat.com \
--cc=linuxarm@huawei.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
--cc=xiaoguangrong.eric@gmail.com \
--cc=xuwei5@huawei.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).