From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: pbonzini@redhat.com, kevin@koconnor.net, seabios@seabios.org,
qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [Qemu-devel] [RFC] map 64-bit PCI devices after all possible RAM
Date: Thu, 10 Oct 2013 14:40:37 +0300 [thread overview]
Message-ID: <20131010114037.GE7582@redhat.com> (raw)
In-Reply-To: <1381321384-17270-1-git-send-email-imammedo@redhat.com>
On Wed, Oct 09, 2013 at 02:23:04PM +0200, Igor Mammedov wrote:
> I'm posting it to get an oppinion on one of possible approaches
> on where to map a hotplug memory.
>
> This patch assumes that a space for hotplug memory is located right
> after RamSizeOver4G region and QEMU will provide romfile to specify
> where it ends so that BIOS could know from what base to start
> 64-bit PCI devices mapping.
>
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Well there are two things bios does with RamSizeOver4G:
determine where to map PCI devices, and fill in smbios.
I wonder whether QEMU should fill smbios from qemu too,
that would let us side-step the issue and just make
RamSizeOver4G larger.
Let's see how the ACPI patchset fares first ...
> ---
> src/fw/pciinit.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> index b29db99..62f8d4e 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,8 @@ 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 base64 = le64_to_cpu(romfile_loadint("etc/mem64-end",
> + 0x100000000ULL + RamSizeOver4G));
> r64_mem.list.first = NULL;
> r64_pref.list.first = NULL;
> pci_region_migrate_64bit_entries(&busses[0].r[PCI_REGION_TYPE_MEM],
> @@ -779,7 +783,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
prev parent reply other threads:[~2013-10-10 11:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 12:23 [Qemu-devel] [RFC] map 64-bit PCI devices after all possible RAM Igor Mammedov
2013-10-09 13:12 ` Gerd Hoffmann
2013-10-09 17:27 ` Igor Mammedov
2013-10-10 10:56 ` Gerd Hoffmann
2013-10-10 11:35 ` Michael S. Tsirkin
2013-10-10 12:14 ` Gerd Hoffmann
2013-10-10 12:21 ` Michael S. Tsirkin
2013-10-10 12:42 ` Gerd Hoffmann
2013-10-10 13:12 ` Igor Mammedov
2013-10-10 13:21 ` Gerd Hoffmann
2013-10-10 13:50 ` Igor Mammedov
2013-10-11 6:28 ` Gerd Hoffmann
2013-10-10 13:17 ` Igor Mammedov
2013-10-10 11:40 ` Michael S. Tsirkin [this message]
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=20131010114037.GE7582@redhat.com \
--to=mst@redhat.com \
--cc=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.