qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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, 12 Feb 2020 17:07:19 +0000	[thread overview]
Message-ID: <fad66252aa8f4b46816f21b5315b6358@huawei.com> (raw)
In-Reply-To: <b4ccf1d9-4514-6b63-5ef9-1d337f539267@redhat.com>



> -----Original Message-----
> From: David Hildenbrand [mailto:david@redhat.com]
> Sent: 10 February 2020 09:54
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> Igor Mammedov <imammedo@redhat.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 10.02.20 10:50, Shameerali Kolothum Thodi wrote:
> >
> >
> >> -----Original Message-----
> >> From: David Hildenbrand [mailto:david@redhat.com]
> >> Sent: 10 February 2020 09:29
> >> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> >> Igor Mammedov <imammedo@redhat.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
> >>
> >>>> Can you look the original value up somehow and us the resize callback
> >>>> only as a notification that something changed? (that value would have to
> >>>> be stored somewhere and migrated I assume - maybe that's already
> being
> >>>> done)
> >>>
> >>> Ok. I will take a look at that. But can we instead pass the
> block->used_length
> >> to
> >>> fw_cfg_add_file_callback(). That way we don’t have to change the
> >> qemu_ram_resize()
> >>> as well. I think Igor has suggested this before[1] and I had a go at it before
> >> coming up
> >>> with the "req_length" proposal here.
> >>
> >> You mean, passing the old size as well? I don't see how that will solve
> >> the issue, but yeah, nothing speaks against simply sending the old and
> >> the new size.
> >
> > Nope. I actually meant using the block->used_length to store in the
> > s->files->f[index].size.
> >
> > virt_acpi_setup()
> >   acpi_add_rom_blob()
> >     rom_add_blob()
> >       rom_set_mr()  --> used_length  = page aligned blob size
> >         fw_cfg_add_file_callback()  --> uses actual blob size.
> >
> >
> > Right now what we do is use the actual blob size to store in FWCfgEntry.
> > Instead pass the RAMBlock used_length to fw_cfg_add_file_callback().
> > Of course by this, the firmware will see an aligned size, but that is fine I think.
> > But at the same time this means the qemu_ram_resize() can stay as it is
> > because it will invoke the callback when the size changes beyond the aligned
> > page size. And also during migration, there won't be any inconsistency as
> everyone
> > works on aligned page size.
> >
> > Does that make sense? Or I am again missing something here?
> 
> Oh, you mean simply rounding up to full pages in the fw entries? If we
> can drop the "sub-page" restriction, that would be awesome!
> 
> Need to double check if that could be an issue for fw/migration/whatever.

Hmm..it breaks x86 + seabios boot. The issue is seabios expects RSDP in FSEG
memory. With the above proposed change, RSDP will be aligned to PAGE_SIZE and
seabios mem allocation for RSDP fails at,

https://github.com/coreboot/seabios/blob/master/src/fw/romfile_loader.c#L85

To get pass the above, I changed "alloc_fseg" flag to false in build_rsdp(), but
seabios seems to make the assumption that RSDP has to be placed in FSEG memory
here,
https://github.com/coreboot/seabios/blob/master/src/fw/biostables.c#L126

So doesn’t look like there is an easy fix for this without changing the seabios code.

Between, OVMF works fine with the aligned size on x86.

One thing we can do is treat the RSDP case separately or only use the aligned
page size for "etc/acpi/tables" as below,

diff --git a/hw/core/loader.c b/hw/core/loader.c
index d1b78f60cd..f07f6a7a35 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -60,6 +60,7 @@
 #include "hw/boards.h"
 #include "qemu/cutils.h"
 #include "sysemu/runstate.h"
+#include "hw/acpi/aml-build.h"
 
 #include <zlib.h>
 
@@ -1056,6 +1057,7 @@ MemoryRegion *rom_add_blob(const char *name, const void *blob, size_t len,
     if (fw_file_name && fw_cfg) {
         char devpath[100];
         void *data;
+        size_t size = rom->datasize;
 
         if (read_only) {
             snprintf(devpath, sizeof(devpath), "/rom@%s", fw_file_name);
@@ -1066,13 +1068,21 @@ MemoryRegion *rom_add_blob(const char *name, const void *blob, size_t len,
         if (mc->rom_file_has_mr) {
             data = rom_set_mr(rom, OBJECT(fw_cfg), devpath, read_only);
             mr = rom->mr;
+           /*
+            * Use the RAMblk used_length for acpi tables as this avoids any
+            * inconsistency with table size changes during hot add and during
+            * migration.
+            */
+           if (strcmp(fw_file_name, ACPI_BUILD_TABLE_FILE) == 0) {
+                size = memory_region_get_used_length(mr);
+           }
         } else {
             data = rom->data;
         }
 
         fw_cfg_add_file_callback(fw_cfg, fw_file_name,
                                  fw_callback, NULL, callback_opaque,
-                                 data, rom->datasize, read_only);
+                                 data, size, read_only);
     }
     return mr;
 }


Thoughts?

Thanks,
Shameer



  reply	other threads:[~2020-02-12 17:09 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
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 [this message]
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=fad66252aa8f4b46816f21b5315b6358@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).