From: Igor Mammedov <imammedo@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: pbonzini@redhat.com, kevin@koconnor.net, seabios@seabios.org,
kraxel@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] map 64-bit PCI BARs at location provided by emulator
Date: Sun, 13 Oct 2013 17:11:54 +0200 [thread overview]
Message-ID: <20131013171154.1abb4542@thinkpad> (raw)
In-Reply-To: <20131013123123.GA10887@redhat.com>
On Sun, 13 Oct 2013 15:31:23 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Sun, Oct 13, 2013 at 02:13:44PM +0200, Igor Mammedov wrote:
> > Currently 64-bit PCI BARs are unconditionally mapped by BIOS right
> > over 4G + RamSizeOver4G location, which doesn't allow to reserve
> > extra space before 64-bit PCI window. For memory hotplug an extra
> > RAM space might be reserved after present 64-bit RAM end and BIOS
> > should map 64-bit PCI BARs after it.
> >
> > Introduce "etc/pcimem64-start" romfile to provide BIOS a hint
> > where it should start mapping of 64-bit PCI BARs. If romfile is
> > missing, BIOS reverts to legacy behavior and starts mapping right
> > after high memory.
> >
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> > v2:
> > * place 64-bit window behind high RAM end if "etc/pcimem64-start"
> > points below it.
>
> Hmm I had an alternative suggestion of passing smbios
> tables in from QEMU (seabios already has a mechanism for this).
> We could then simply increase the existing RamSize variable.
>
> What do you think about this idea?
There is several issues with RamSizeOver4G I see:
1. As Gerd pointed out it is also used to setup a part of e820 tables.
It possibly could be also changed see "[Qemu-devel] [RfC PATCH] e820: pass
high memory too" but it will be more complicated to keep seabios
backward/forward compatible if we use RamSizeOver4G for passing.
2. It doesn't scale if we are going to use more than 1Tb future.
Extending RamSizeOver4G value via additional CMOS port wasn't welcomed
either, see
http://www.seabios.org/pipermail/seabios/2010-September/000911.html
It looks like fw_cfg interface is preferred one and "etc/pcimem64-start"
approach doesn't have backward/forward compatibility issues.
>
>
> > ---
> > src/fw/pciinit.c | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> > index b29db99..798309b 100644
> > --- a/src/fw/pciinit.c
> > +++ b/src/fw/pciinit.c
> > @@ -18,6 +18,8 @@
> > #include "paravirt.h" // RamSize
> > #include "string.h" // memset
> > #include "util.h" // pci_setup
> > +#include "byteorder.h" // le64_to_cpu
> > +#include "romfile.h" // romfile_loadint
> >
> > #define PCI_DEVICE_MEM_MIN 0x1000
> > #define PCI_BRIDGE_IO_MIN 0x1000
> > @@ -764,6 +766,15 @@ static void pci_bios_map_devices(struct pci_bus *busses)
> > {
> > if (pci_bios_init_root_regions(busses)) {
> > struct pci_region r64_mem, r64_pref;
> > + u64 ram64_end = 0x100000000ULL + RamSizeOver4G;
> > + u64 base64 = le64_to_cpu(romfile_loadint("etc/pcimem64-start",
> > + ram64_end));
> > + if (base64 < ram64_end) {
> > + dprintf(1, "ignorig etc/pcimem64-start [0x%llx] below present RAM, "
> > + "placing 64-bit PCI window behind RAM end: %llx",
> > + base64, ram64_end);
> > + base64 = ram64_end;
> > + }
> > r64_mem.list.first = NULL;
> > r64_pref.list.first = NULL;
> > pci_region_migrate_64bit_entries(&busses[0].r[PCI_REGION_TYPE_MEM],
> > @@ -779,7 +790,7 @@ static void pci_bios_map_devices(struct pci_bus *busses)
> > u64 align_mem = pci_region_align(&r64_mem);
> > u64 align_pref = pci_region_align(&r64_pref);
> >
> > - r64_mem.base = ALIGN(0x100000000LL + RamSizeOver4G, align_mem);
> > + r64_mem.base = ALIGN(base64, align_mem);
> > r64_pref.base = ALIGN(r64_mem.base + sum_mem, align_pref);
> > pcimem64_start = r64_mem.base;
> > pcimem64_end = r64_pref.base + sum_pref;
> > --
> > 1.8.3.1
>
--
Regards,
Igor
next prev parent reply other threads:[~2013-10-13 15:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-13 12:13 [Qemu-devel] [PATCH v2] map 64-bit PCI BARs at location provided by emulator Igor Mammedov
2013-10-13 12:31 ` Michael S. Tsirkin
2013-10-13 15:11 ` Igor Mammedov [this message]
2013-10-13 15:59 ` Michael S. Tsirkin
2013-10-13 16:23 ` Igor Mammedov
2013-10-13 16:46 ` Michael S. Tsirkin
2013-10-13 17:33 ` Igor Mammedov
2013-10-13 18:19 ` [Qemu-devel] [SeaBIOS] " Igor Mammedov
2013-10-13 19:53 ` Kevin O'Connor
2013-10-14 8:01 ` Gerd Hoffmann
2013-10-13 20:28 ` [Qemu-devel] " Michael S. Tsirkin
2013-10-14 10:27 ` Igor Mammedov
2013-10-14 11:00 ` Michael S. Tsirkin
2013-10-14 12:16 ` Gerd Hoffmann
2013-10-14 12:38 ` Michael S. Tsirkin
2013-10-14 13:04 ` Gerd Hoffmann
2013-10-14 14:00 ` Michael S. Tsirkin
2013-10-14 16:15 ` Igor Mammedov
2013-10-14 16:37 ` Michael S. Tsirkin
2013-10-15 8:01 ` Gerd Hoffmann
2013-10-15 9:05 ` Igor Mammedov
2013-10-15 9:14 ` [Qemu-devel] [SeaBIOS] " Gerd Hoffmann
2013-10-15 12:36 ` Igor Mammedov
2013-10-15 9:16 ` [Qemu-devel] " Michael S. Tsirkin
2013-10-15 9:24 ` Gerd Hoffmann
2013-10-15 9:53 ` Igor Mammedov
2013-10-15 9:47 ` Igor Mammedov
2013-10-15 9:08 ` Michael S. Tsirkin
2013-10-14 12:28 ` Igor Mammedov
2013-10-13 15:15 ` Kevin O'Connor
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=20131013171154.1abb4542@thinkpad \
--to=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.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).