Re: [RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820
On Thu, Mar 10, 2022 at 10:12 PM Igor Mammedov wrote:
>
> On Thu, 10 Mar 2022 11:51:37 +0530
> Ani Sinha wrote:
>
> > On Mon, Feb 28, 2022 at 8:56 PM Ani Sinha wrote:
> > >
> > > e820 reserved entries were used before the dynamic entries with fw config
> > > files
> > > were intoduced into qemu with the following change:
> > > 7d67110f2d9a6("pc: add etc/e820 fw_cfg file")
> > >
> > > Identical support was introduced into seabios as well with the following
> > > commit:
> > > ce39bd4031820 ("Add support for etc/e820 fw_cfg file")
> > >
> > > Both the above commits are now quite old. Seabios uses fw config files and
> > > dynamic e820 entries by default and only falls back to using reserved
> > > entries
> > > when it has to work with old qemu (versions earlier than 1.7). Please see
> > > functions qemu_cfg_e820() and qemu_early_e820(). It is safe to remove
> > > legacy
> > > FW_CFG_E820_TABLE and associated code. It would be incredibly rare to run
> > > the
> > > latest qemu version with a very old version of seabios that did not
> > > support
> > > fw config files for e820.
> > >
> > > As far as I could see, edk2/ovfm never supported reserved entries and
> > > uses fw
> > > config files from the beginning. So there should be no incompatibilities
> > > with
> > > ovfm as well.
> >
> > Igor, Gerd, as I had replied in the other thread, I am not sure if we
> > need the compatibility dance in order to do this. I think we can't
> > carry this legacy stuff on forever.
> > Please advice.
>
> see commit 7d67110f2d
> until we have older machine types it must stay or have a compat knob,
> once they are gone we can remove it as 1.7 and older machine types
> are supposed to have newer SeaBIOS version that doesn't utilize
> it anymore.
>
> so add a compat knob (not sure if it's worth the trouble) or
> wait till pre 1.7 machines are gone and then rebase/repost.
We have just released QEMU 7.0. I have reposted the patch after rebase.
Re: [RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820
On Thu, Mar 10, 2022 at 10:12 PM Igor Mammedov wrote:
>
> On Thu, 10 Mar 2022 11:51:37 +0530
> Ani Sinha wrote:
>
> > On Mon, Feb 28, 2022 at 8:56 PM Ani Sinha wrote:
> > >
> > > e820 reserved entries were used before the dynamic entries with fw config
> > > files
> > > were intoduced into qemu with the following change:
> > > 7d67110f2d9a6("pc: add etc/e820 fw_cfg file")
> > >
> > > Identical support was introduced into seabios as well with the following
> > > commit:
> > > ce39bd4031820 ("Add support for etc/e820 fw_cfg file")
> > >
> > > Both the above commits are now quite old. Seabios uses fw config files and
> > > dynamic e820 entries by default and only falls back to using reserved
> > > entries
> > > when it has to work with old qemu (versions earlier than 1.7). Please see
> > > functions qemu_cfg_e820() and qemu_early_e820(). It is safe to remove
> > > legacy
> > > FW_CFG_E820_TABLE and associated code. It would be incredibly rare to run
> > > the
> > > latest qemu version with a very old version of seabios that did not
> > > support
> > > fw config files for e820.
> > >
> > > As far as I could see, edk2/ovfm never supported reserved entries and
> > > uses fw
> > > config files from the beginning. So there should be no incompatibilities
> > > with
> > > ovfm as well.
> >
> > Igor, Gerd, as I had replied in the other thread, I am not sure if we
> > need the compatibility dance in order to do this. I think we can't
> > carry this legacy stuff on forever.
> > Please advice.
>
> see commit 7d67110f2d
> until we have older machine types it must stay or have a compat knob,
> once they are gone we can remove it as 1.7 and older machine types
> are supposed to have newer SeaBIOS version that doesn't utilize
> it anymore.
>
> so add a compat knob (not sure if it's worth the trouble) or
> wait till pre 1.7 machines are gone and then rebase/repost.
Ok fine,. I will wait till 7.0 is released at which point
pc-1440fx-1.7 machine will be deprecated.
I will repost it again after that.
Re: [RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820
On Thu, 10 Mar 2022 11:51:37 +0530
Ani Sinha wrote:
> On Mon, Feb 28, 2022 at 8:56 PM Ani Sinha wrote:
> >
> > e820 reserved entries were used before the dynamic entries with fw config
> > files
> > were intoduced into qemu with the following change:
> > 7d67110f2d9a6("pc: add etc/e820 fw_cfg file")
> >
> > Identical support was introduced into seabios as well with the following
> > commit:
> > ce39bd4031820 ("Add support for etc/e820 fw_cfg file")
> >
> > Both the above commits are now quite old. Seabios uses fw config files and
> > dynamic e820 entries by default and only falls back to using reserved
> > entries
> > when it has to work with old qemu (versions earlier than 1.7). Please see
> > functions qemu_cfg_e820() and qemu_early_e820(). It is safe to remove legacy
> > FW_CFG_E820_TABLE and associated code. It would be incredibly rare to run
> > the
> > latest qemu version with a very old version of seabios that did not support
> > fw config files for e820.
> >
> > As far as I could see, edk2/ovfm never supported reserved entries and uses
> > fw
> > config files from the beginning. So there should be no incompatibilities
> > with
> > ovfm as well.
>
> Igor, Gerd, as I had replied in the other thread, I am not sure if we
> need the compatibility dance in order to do this. I think we can't
> carry this legacy stuff on forever.
> Please advice.
see commit 7d67110f2d
until we have older machine types it must stay or have a compat knob,
once they are gone we can remove it as 1.7 and older machine types
are supposed to have newer SeaBIOS version that doesn't utilize
it anymore.
so add a compat knob (not sure if it's worth the trouble) or
wait till pre 1.7 machines are gone and then rebase/repost.
>
> >
> > CC: Gerd Hoffmann
> > Signed-off-by: Ani Sinha
> > ---
> > hw/i386/e820_memory_layout.c | 20 +---
> > hw/i386/e820_memory_layout.h | 8
> > hw/i386/fw_cfg.c | 3 ---
> > hw/i386/fw_cfg.h | 1 -
> > hw/i386/microvm.c| 2 --
> > 5 files changed, 1 insertion(+), 33 deletions(-)
> >
> > diff --git a/hw/i386/e820_memory_layout.c b/hw/i386/e820_memory_layout.c
> > index bcf9eaf837..06970ac44a 100644
> > --- a/hw/i386/e820_memory_layout.c
> > +++ b/hw/i386/e820_memory_layout.c
> > @@ -11,29 +11,11 @@
> > #include "e820_memory_layout.h"
> >
> > static size_t e820_entries;
> > -struct e820_table e820_reserve;
> > struct e820_entry *e820_table;
> >
> > int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> > {
> > -int index = le32_to_cpu(e820_reserve.count);
> > -struct e820_entry *entry;
> > -
> > -if (type != E820_RAM) {
> > -/* old FW_CFG_E820_TABLE entry -- reservations only */
> > -if (index >= E820_NR_ENTRIES) {
> > -return -EBUSY;
> > -}
> > -entry = _reserve.entry[index++];
> > -
> > -entry->address = cpu_to_le64(address);
> > -entry->length = cpu_to_le64(length);
> > -entry->type = cpu_to_le32(type);
> > -
> > -e820_reserve.count = cpu_to_le32(index);
> > -}
> > -
> > -/* new "etc/e820" file -- include ram too */
> > +/* new "etc/e820" file -- include ram and reserved entries */
> > e820_table = g_renew(struct e820_entry, e820_table, e820_entries + 1);
> > e820_table[e820_entries].address = cpu_to_le64(address);
> > e820_table[e820_entries].length = cpu_to_le64(length);
> > diff --git a/hw/i386/e820_memory_layout.h b/hw/i386/e820_memory_layout.h
> > index 2a0ceb8b9c..daf41cc4b4 100644
> > --- a/hw/i386/e820_memory_layout.h
> > +++ b/hw/i386/e820_memory_layout.h
> > @@ -16,20 +16,12 @@
> > #define E820_NVS4
> > #define E820_UNUSABLE 5
> >
> > -#define E820_NR_ENTRIES 16
> > -
> > struct e820_entry {
> > uint64_t address;
> > uint64_t length;
> > uint32_t type;
> > } QEMU_PACKED __attribute((__aligned__(4)));
> >
> > -struct e820_table {
> > -uint32_t count;
> > -struct e820_entry entry[E820_NR_ENTRIES];
> > -} QEMU_PACKED __attribute((__aligned__(4)));
> > -
> > -extern struct e820_table e820_reserve;
> > extern struct e820_entry *e820_table;
> >
> > int e820_add_entry(uint64_t address, uint64_t length, uint32_t type);
> > diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> > index a283785a8d..72a42f3c66 100644
> > --- a/hw/i386/fw_cfg.c
> > +++ b/hw/i386/fw_cfg.c
> > @@ -36,7 +36,6 @@ const char *fw_cfg_arch_key_name(uint16_t key)
> > {FW_CFG_ACPI_TABLES, "acpi_tables"},
> > {FW_CFG_SMBIOS_ENTRIES, "smbios_entries"},
> > {FW_CFG_IRQ0_OVERRIDE, "irq0_override"},
> > -{FW_CFG_E820_TABLE, "e820_table"},
> > {FW_CFG_HPET, "hpet"},
> > };
> >
> > @@ -127,8 +126,6 @@ FWCfgState *fw_cfg_arch_create(MachineState *ms,
> > #endif
> > fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, 1);
> >
> > -fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE,
> > - _reserve, sizeof(e820_reserve));
> >
Re: any opinion on the patch "[RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820"? EOM
On Fri, 4 Mar 2022 16:16:38 +0530 Ani Sinha wrote: > On Fri, Mar 4, 2022 at 4:11 PM Ani Sinha wrote: > > > > On Fri, Mar 4, 2022 at 3:48 PM Gerd Hoffmann wrote: > > > > > > On Thu, Mar 03, 2022 at 03:12:51PM +0530, Ani Sinha wrote: > > > > On Thu, Mar 3, 2022 at 15:11 Gerd Hoffmann wrote: > > > > > > > > > Sorry, no. Noticed the discussions but don't remember the details and > > > > > didn't took the time to wade through the code to refresh my memory. > > > > > > > > Could you please take a look when you get time? You have the most > > > > context > > > > in this space I believe. > > > > > > Should indeed not be needed unless you use a stone-aged seabios version. > > > But I think you can't simply drop it for live migration compatibility > > > reasons. So you'll need do the compatibility dance and drop it for new > > > machine types only. I doubt the benefits outweigh that effort .. well, it's mostly dead and unused code path that needlessly complicates code and silently bit-rots for several years. (on both SeaBIOS and QEMU sides) > > Igor what do you think? > Since the static entries are separate from the rom file entries, I > think we are in trouble only if the destination is using an old bios? > Otherwise, the non-existence of the static entries should be simply > ignored right? If you take into account migration from older QEMU, it will migrate with old SeaBIOS (one that VM was started with on source side), then you can't just remove interfaces it might access from under its foot. So compat knobs are necessary. Considering that SeaBIOS switched to QEMU provided ACPI tables since 1.7, this machine type can serve as point where compat knob should be. Newer machine type (though technically possible) and SeaBIOS should not build its own ACPI tables and not use legacy interfaces necessary for it. Also since machine types older that 1.7 are deprecated now, we can remove them in 2 releases, which rules pre-QEMU-ACPI SeaBIOS out of the picture. So I'd think about preparing cleanup for SeaBIOS which removes legacy ACPI tables from it, and merge that once deprecated machine types are removed on QEMU side. And after that drop legacy ABI on QEMU side as no longer used.
Re: [RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820
On Mon, Feb 28, 2022 at 8:56 PM Ani Sinha wrote:
>
> e820 reserved entries were used before the dynamic entries with fw config
> files
> were intoduced into qemu with the following change:
> 7d67110f2d9a6("pc: add etc/e820 fw_cfg file")
>
> Identical support was introduced into seabios as well with the following
> commit:
> ce39bd4031820 ("Add support for etc/e820 fw_cfg file")
>
> Both the above commits are now quite old. Seabios uses fw config files and
> dynamic e820 entries by default and only falls back to using reserved entries
> when it has to work with old qemu (versions earlier than 1.7). Please see
> functions qemu_cfg_e820() and qemu_early_e820(). It is safe to remove legacy
> FW_CFG_E820_TABLE and associated code. It would be incredibly rare to run the
> latest qemu version with a very old version of seabios that did not support
> fw config files for e820.
>
> As far as I could see, edk2/ovfm never supported reserved entries and uses fw
> config files from the beginning. So there should be no incompatibilities with
> ovfm as well.
Igor, Gerd, as I had replied in the other thread, I am not sure if we
need the compatibility dance in order to do this. I think we can't
carry this legacy stuff on forever.
Please advice.
>
> CC: Gerd Hoffmann
> Signed-off-by: Ani Sinha
> ---
> hw/i386/e820_memory_layout.c | 20 +---
> hw/i386/e820_memory_layout.h | 8
> hw/i386/fw_cfg.c | 3 ---
> hw/i386/fw_cfg.h | 1 -
> hw/i386/microvm.c| 2 --
> 5 files changed, 1 insertion(+), 33 deletions(-)
>
> diff --git a/hw/i386/e820_memory_layout.c b/hw/i386/e820_memory_layout.c
> index bcf9eaf837..06970ac44a 100644
> --- a/hw/i386/e820_memory_layout.c
> +++ b/hw/i386/e820_memory_layout.c
> @@ -11,29 +11,11 @@
> #include "e820_memory_layout.h"
>
> static size_t e820_entries;
> -struct e820_table e820_reserve;
> struct e820_entry *e820_table;
>
> int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> {
> -int index = le32_to_cpu(e820_reserve.count);
> -struct e820_entry *entry;
> -
> -if (type != E820_RAM) {
> -/* old FW_CFG_E820_TABLE entry -- reservations only */
> -if (index >= E820_NR_ENTRIES) {
> -return -EBUSY;
> -}
> -entry = _reserve.entry[index++];
> -
> -entry->address = cpu_to_le64(address);
> -entry->length = cpu_to_le64(length);
> -entry->type = cpu_to_le32(type);
> -
> -e820_reserve.count = cpu_to_le32(index);
> -}
> -
> -/* new "etc/e820" file -- include ram too */
> +/* new "etc/e820" file -- include ram and reserved entries */
> e820_table = g_renew(struct e820_entry, e820_table, e820_entries + 1);
> e820_table[e820_entries].address = cpu_to_le64(address);
> e820_table[e820_entries].length = cpu_to_le64(length);
> diff --git a/hw/i386/e820_memory_layout.h b/hw/i386/e820_memory_layout.h
> index 2a0ceb8b9c..daf41cc4b4 100644
> --- a/hw/i386/e820_memory_layout.h
> +++ b/hw/i386/e820_memory_layout.h
> @@ -16,20 +16,12 @@
> #define E820_NVS4
> #define E820_UNUSABLE 5
>
> -#define E820_NR_ENTRIES 16
> -
> struct e820_entry {
> uint64_t address;
> uint64_t length;
> uint32_t type;
> } QEMU_PACKED __attribute((__aligned__(4)));
>
> -struct e820_table {
> -uint32_t count;
> -struct e820_entry entry[E820_NR_ENTRIES];
> -} QEMU_PACKED __attribute((__aligned__(4)));
> -
> -extern struct e820_table e820_reserve;
> extern struct e820_entry *e820_table;
>
> int e820_add_entry(uint64_t address, uint64_t length, uint32_t type);
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index a283785a8d..72a42f3c66 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -36,7 +36,6 @@ const char *fw_cfg_arch_key_name(uint16_t key)
> {FW_CFG_ACPI_TABLES, "acpi_tables"},
> {FW_CFG_SMBIOS_ENTRIES, "smbios_entries"},
> {FW_CFG_IRQ0_OVERRIDE, "irq0_override"},
> -{FW_CFG_E820_TABLE, "e820_table"},
> {FW_CFG_HPET, "hpet"},
> };
>
> @@ -127,8 +126,6 @@ FWCfgState *fw_cfg_arch_create(MachineState *ms,
> #endif
> fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, 1);
>
> -fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE,
> - _reserve, sizeof(e820_reserve));
> fw_cfg_add_file(fw_cfg, "etc/e820", e820_table,
> sizeof(struct e820_entry) * e820_get_num_entries());
>
> diff --git a/hw/i386/fw_cfg.h b/hw/i386/fw_cfg.h
> index 275f15c1c5..86ca7c1c0c 100644
> --- a/hw/i386/fw_cfg.h
> +++ b/hw/i386/fw_cfg.h
> @@ -17,7 +17,6 @@
> #define FW_CFG_ACPI_TABLES (FW_CFG_ARCH_LOCAL + 0)
> #define FW_CFG_SMBIOS_ENTRIES (FW_CFG_ARCH_LOCAL + 1)
> #define FW_CFG_IRQ0_OVERRIDE(FW_CFG_ARCH_LOCAL + 2)
> -#define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3)
> #define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4)
>
> FWCfgState *fw_cfg_arch_create(MachineState *ms,
> diff --git a/hw/i386/microvm.c
Re: any opinion on the patch "[RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820"? EOM
On Fri, Mar 4, 2022 at 4:11 PM Ani Sinha wrote: > > On Fri, Mar 4, 2022 at 3:48 PM Gerd Hoffmann wrote: > > > > On Thu, Mar 03, 2022 at 03:12:51PM +0530, Ani Sinha wrote: > > > On Thu, Mar 3, 2022 at 15:11 Gerd Hoffmann wrote: > > > > > > > Sorry, no. Noticed the discussions but don't remember the details and > > > > didn't took the time to wade through the code to refresh my memory. > > > > > > Could you please take a look when you get time? You have the most context > > > in this space I believe. > > > > Should indeed not be needed unless you use a stone-aged seabios version. > > But I think you can't simply drop it for live migration compatibility > > reasons. So you'll need do the compatibility dance and drop it for new > > machine types only. I doubt the benefits outweigh that effort .. > > Igor what do you think? Since the static entries are separate from the rom file entries, I think we are in trouble only if the destination is using an old bios? Otherwise, the non-existence of the static entries should be simply ignored right?
Re: any opinion on the patch "[RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820"? EOM
On Fri, Mar 4, 2022 at 3:48 PM Gerd Hoffmann wrote: > > On Thu, Mar 03, 2022 at 03:12:51PM +0530, Ani Sinha wrote: > > On Thu, Mar 3, 2022 at 15:11 Gerd Hoffmann wrote: > > > > > Sorry, no. Noticed the discussions but don't remember the details and > > > didn't took the time to wade through the code to refresh my memory. > > > > Could you please take a look when you get time? You have the most context > > in this space I believe. > > Should indeed not be needed unless you use a stone-aged seabios version. > But I think you can't simply drop it for live migration compatibility > reasons. So you'll need do the compatibility dance and drop it for new > machine types only. I doubt the benefits outweigh that effort .. Igor what do you think?
[RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820
e820 reserved entries were used before the dynamic entries with fw config files
were intoduced into qemu with the following change:
7d67110f2d9a6("pc: add etc/e820 fw_cfg file")
Identical support was introduced into seabios as well with the following commit:
ce39bd4031820 ("Add support for etc/e820 fw_cfg file")
Both the above commits are now quite old. Seabios uses fw config files and
dynamic e820 entries by default and only falls back to using reserved entries
when it has to work with old qemu (versions earlier than 1.7). Please see
functions qemu_cfg_e820() and qemu_early_e820(). It is safe to remove legacy
FW_CFG_E820_TABLE and associated code. It would be incredibly rare to run the
latest qemu version with a very old version of seabios that did not support
fw config files for e820.
As far as I could see, edk2/ovfm never supported reserved entries and uses fw
config files from the beginning. So there should be no incompatibilities with
ovfm as well.
CC: Gerd Hoffmann
Signed-off-by: Ani Sinha
---
hw/i386/e820_memory_layout.c | 20 +---
hw/i386/e820_memory_layout.h | 8
hw/i386/fw_cfg.c | 3 ---
hw/i386/fw_cfg.h | 1 -
hw/i386/microvm.c| 2 --
5 files changed, 1 insertion(+), 33 deletions(-)
diff --git a/hw/i386/e820_memory_layout.c b/hw/i386/e820_memory_layout.c
index bcf9eaf837..06970ac44a 100644
--- a/hw/i386/e820_memory_layout.c
+++ b/hw/i386/e820_memory_layout.c
@@ -11,29 +11,11 @@
#include "e820_memory_layout.h"
static size_t e820_entries;
-struct e820_table e820_reserve;
struct e820_entry *e820_table;
int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
{
-int index = le32_to_cpu(e820_reserve.count);
-struct e820_entry *entry;
-
-if (type != E820_RAM) {
-/* old FW_CFG_E820_TABLE entry -- reservations only */
-if (index >= E820_NR_ENTRIES) {
-return -EBUSY;
-}
-entry = _reserve.entry[index++];
-
-entry->address = cpu_to_le64(address);
-entry->length = cpu_to_le64(length);
-entry->type = cpu_to_le32(type);
-
-e820_reserve.count = cpu_to_le32(index);
-}
-
-/* new "etc/e820" file -- include ram too */
+/* new "etc/e820" file -- include ram and reserved entries */
e820_table = g_renew(struct e820_entry, e820_table, e820_entries + 1);
e820_table[e820_entries].address = cpu_to_le64(address);
e820_table[e820_entries].length = cpu_to_le64(length);
diff --git a/hw/i386/e820_memory_layout.h b/hw/i386/e820_memory_layout.h
index 2a0ceb8b9c..daf41cc4b4 100644
--- a/hw/i386/e820_memory_layout.h
+++ b/hw/i386/e820_memory_layout.h
@@ -16,20 +16,12 @@
#define E820_NVS4
#define E820_UNUSABLE 5
-#define E820_NR_ENTRIES 16
-
struct e820_entry {
uint64_t address;
uint64_t length;
uint32_t type;
} QEMU_PACKED __attribute((__aligned__(4)));
-struct e820_table {
-uint32_t count;
-struct e820_entry entry[E820_NR_ENTRIES];
-} QEMU_PACKED __attribute((__aligned__(4)));
-
-extern struct e820_table e820_reserve;
extern struct e820_entry *e820_table;
int e820_add_entry(uint64_t address, uint64_t length, uint32_t type);
diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
index a283785a8d..72a42f3c66 100644
--- a/hw/i386/fw_cfg.c
+++ b/hw/i386/fw_cfg.c
@@ -36,7 +36,6 @@ const char *fw_cfg_arch_key_name(uint16_t key)
{FW_CFG_ACPI_TABLES, "acpi_tables"},
{FW_CFG_SMBIOS_ENTRIES, "smbios_entries"},
{FW_CFG_IRQ0_OVERRIDE, "irq0_override"},
-{FW_CFG_E820_TABLE, "e820_table"},
{FW_CFG_HPET, "hpet"},
};
@@ -127,8 +126,6 @@ FWCfgState *fw_cfg_arch_create(MachineState *ms,
#endif
fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, 1);
-fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE,
- _reserve, sizeof(e820_reserve));
fw_cfg_add_file(fw_cfg, "etc/e820", e820_table,
sizeof(struct e820_entry) * e820_get_num_entries());
diff --git a/hw/i386/fw_cfg.h b/hw/i386/fw_cfg.h
index 275f15c1c5..86ca7c1c0c 100644
--- a/hw/i386/fw_cfg.h
+++ b/hw/i386/fw_cfg.h
@@ -17,7 +17,6 @@
#define FW_CFG_ACPI_TABLES (FW_CFG_ARCH_LOCAL + 0)
#define FW_CFG_SMBIOS_ENTRIES (FW_CFG_ARCH_LOCAL + 1)
#define FW_CFG_IRQ0_OVERRIDE(FW_CFG_ARCH_LOCAL + 2)
-#define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3)
#define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4)
FWCfgState *fw_cfg_arch_create(MachineState *ms,
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index 4b3b1dd262..f2101e7293 100644
--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -324,8 +324,6 @@ static void microvm_memory_init(MicrovmMachineState *mms)
fw_cfg_add_i16(fw_cfg, FW_CFG_MAX_CPUS, machine->smp.max_cpus);
fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)machine->ram_size);
fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, 1);
-fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE,
- _reserve,
