From: Igor Mammedov <imammedo@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: mst@redhat.com, aliguori@amazon.com, qemu-devel@nongnu.org,
afaerber@suse.de, kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/2] pc: add 'etc/reserved-memory-end' fw_cfg interface for SeaBIOS
Date: Tue, 12 Nov 2013 21:17:01 +0100 [thread overview]
Message-ID: <20131112211701.48039b03@thinkpad> (raw)
In-Reply-To: <528272BA.30402@redhat.com>
On Tue, 12 Nov 2013 19:26:02 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 12/11/2013 14:58, Igor Mammedov ha scritto:
> > 'etc/reserved-memory-end' will allow QEMU to tell BIOS where PCI
> > BARs mapping could safely start in high memory.
> >
> > Allowing BIOS to start mapping 64-bit PCI BARs at address where it
> > wouldn't conflict with other mappings QEMU might place before it.
> >
> > That permits QEMU to reserve extra address space before
> > 64-bit PCI hole for memory hotplug.
>
> I may be royally wrong, but I think the new file should only be added to
> new machine types. Otherwise, after migrating old machine types from
> new QEMU to old QEMU, you may end up with PCI BARs mapped outside the
> "PCI windows" that exist until before patch 1/2 of this series.
>
> Does this make sense?
it will shift BARs only when 'etc/reserved-memory-end' != above4gram_end,
presently 'etc/reserved-memory-end' == above4gram_end, so it doesn't affect
new->old or old->new migration.
Just to be sure I've done new->old and old->new migration testing, it looks
like nothing is broken by patch.
When 'etc/reserved-memory-end' > above4gram_end, new->old migration is
unlikely (unrealistically) to be broken due to default 64bit PCI hole size in
old QEMU is 1ULL << 62, so to become broken guest should have a BAR that will
go beyond 1ULL << 62 border.
But your question have reminded me to make sure that memory hotplug should be
disabled for old machine type to avoid clash of memory hotplug region and old
64-bit PCI window.
>
> Also, would it make sense to use the e820 interface that Gerd has added,
> instead of a new fw_cfg file?
Gerd suggested it before, but we've come to agreement that dedicated file
is cleaner approach than extending standard e820 table with QEMU specific
extensions. http://www.mail-archive.com/qemu-devel@nongnu.org/msg200359.html
>
> Thanks,
>
> Paolo
>
>
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> > hw/i386/pc.c | 14 +++++++++++++-
> > hw/pci-host/piix.c | 3 ++-
> > hw/pci-host/q35.c | 3 ++-
> > include/hw/i386/pc.h | 3 ++-
> > 4 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > index 6c82ada..b504047 100644
> > --- a/hw/i386/pc.c
> > +++ b/hw/i386/pc.c
> > @@ -1095,11 +1095,23 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t below_4g_mem_size,
> >
> > /* setup pci memory address space mapping into system address space */
> > void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
> > - MemoryRegion *pci_address_space)
> > + MemoryRegion *pci_address_space,
> > + uint64_t reserved_memory_end)
> > {
> > + uint64_t *val;
> > + FWCfgState *fw_cfg = fw_cfg_find();
> > +
> > /* Set to lower priority than RAM */
> > memory_region_add_subregion_overlap(system_memory, 0x0,
> > pci_address_space, -1);
> > + g_assert(fw_cfg);
> > + /*
> > + * Align address at 1G, this makes sure it can be exactly covered
> > + * with a PAT entry even when using huge pages.
> > + */
> > + val = g_malloc(sizeof(*val));
> > + *val = cpu_to_le64(ROUND_UP(reserved_memory_end, 0x1ULL << 30));
> > + fw_cfg_add_file(fw_cfg, "etc/reserved-memory-end", val, sizeof(*val));
> > }
> >
> > void pc_acpi_init(const char *default_dsdt)
> > diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> > index 5d4e290..16205e7 100644
> > --- a/hw/pci-host/piix.c
> > +++ b/hw/pci-host/piix.c
> > @@ -351,7 +351,8 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
> >
> > /* setup pci memory mapping */
> > pc_pci_as_mapping_init(OBJECT(f), f->system_memory,
> > - f->pci_address_space);
> > + f->pci_address_space,
> > + 0x100000000ULL + above_4g_mem_size);
> >
> > memory_region_init_alias(&f->smram_region, OBJECT(d), "smram-region",
> > f->pci_address_space, 0xa0000, 0x20000);
> > diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> > index d1792de..1293353 100644
> > --- a/hw/pci-host/q35.c
> > +++ b/hw/pci-host/q35.c
> > @@ -353,7 +353,8 @@ static int mch_init(PCIDevice *d)
> >
> > /* setup pci memory mapping */
> > pc_pci_as_mapping_init(OBJECT(mch), mch->system_memory,
> > - mch->pci_address_space);
> > + mch->pci_address_space,
> > + 0x100000000ULL + mch->above_4g_mem_size);
> >
> > /* smram */
> > cpu_smm_register(&mch_set_smm, mch);
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index 8b3be3c..2663046 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -130,7 +130,8 @@ PcGuestInfo *pc_guest_info_init(ram_addr_t below_4g_mem_size,
> >
> >
> > void pc_pci_as_mapping_init(Object *owner, MemoryRegion *system_memory,
> > - MemoryRegion *pci_address_space);
> > + MemoryRegion *pci_address_space,
> > + uint64_t reserved_memory_end);
> >
> > FWCfgState *pc_memory_init(MemoryRegion *system_memory,
> > const char *kernel_filename,
> >
>
--
Regards,
Igor
next prev parent reply other threads:[~2013-11-12 20:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 13:58 [Qemu-devel] [PATCH for-1.8 0/2 v3] pc: inform SeaBIOS where 64-bit PCI hole begins Igor Mammedov
2013-11-12 13:58 ` [Qemu-devel] [PATCH 1/2] pc: map PCI address space as catchall region for not mapped addresses Igor Mammedov
2013-11-12 16:29 ` Laszlo Ersek
2013-11-12 13:58 ` [Qemu-devel] [PATCH 2/2] pc: add 'etc/reserved-memory-end' fw_cfg interface for SeaBIOS Igor Mammedov
2013-11-12 18:26 ` Paolo Bonzini
2013-11-12 20:17 ` Igor Mammedov [this message]
2013-11-12 22:10 ` Michael S. Tsirkin
2013-11-12 23:03 ` Paolo Bonzini
2013-11-13 12:04 ` Igor Mammedov
2013-11-14 7:40 ` Michael S. Tsirkin
2013-11-14 13:37 ` Igor Mammedov
2013-11-15 1:07 ` [Qemu-devel] [PATCH 2/2 v4] " Igor Mammedov
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=20131112211701.48039b03@thinkpad \
--to=imammedo@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).