From: Gerd Hoffmann <kraxel@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
kevin@koconnor.net, seabios@seabios.org, qemu-devel@nongnu.org,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] map 64-bit PCI BARs at location provided by emulator
Date: Mon, 14 Oct 2013 14:16:23 +0200 [thread overview]
Message-ID: <1381752983.30262.32.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <20131014110012.GE30954@redhat.com>
Hi,
> > And there is slight difference between PCI holes and PCI address space mappings
> > represented by MemoryRegion-s in QEMU.
> >
> > Basically we only need to inform BIOS where to PCI address spaces start and
> > simple "etc/pcimem64-start" + "etc/pcimem32-start" are just fine for that.
> > And for now (memory hotplug) we need only the first one, the second one is
> > very well hardcoded in Seabios/QEMU.
Yes, 32bit hole is basically the [ end-of-memory -> ioapic ] range.
Can't see any reason to make that configurable, it is quite unlikely
that this ever changes.
For the 64bit window it makes sense to configure it, to give qemu a
little more control about the address space layout.
> Hmm okay but the only reason we want to control this is
> because it conflicts with memory hotplug, no?
> I vaguely recall we discussed just passing amount of
> hot-pluggable memory in, in the past, but I don't
> remember the reason we decided against it.
> Could you refresh my memory?
To me it makes more sense to just go the direct route and say "please
put the 64bit bars at this location" rather than indirect "we might want
hotplug $thatmuch memory" and then expect the bios to leave that much
room.
If we ever want reserve more address space for other reasons it'll be
easier with the direct variant as the bios doesn't need to be aware that
we'll need some address space for $newfeature too.
> > A more flexible approach would be a separate table (like e820 table, but only
> > for PCI ranges), but it seems a bit of overkill for now (I can't picture
> > a need for more than 2 PCI address space mappings).
>
> It's not unthinkable.
> Multiple ECAM regions (for multi-root systems) can make holes in the address space.
Sounds pretty theoretic ...
> Also, we just ignore everything above the ioapic, but that's
> not a must, we could maybe use address space above ioapic.
Any reason why we should that?
cheers,
Gerd
next prev parent reply other threads:[~2013-10-14 12:16 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
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 [this message]
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=1381752983.30262.32.camel@nilsson.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--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).