From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: pbonzini@redhat.com, kevin@koconnor.net, seabios@seabios.org,
Gerd Hoffmann <kraxel@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] map 64-bit PCI BARs at location provided by emulator
Date: Mon, 14 Oct 2013 19:37:14 +0300 [thread overview]
Message-ID: <20131014163714.GA13477@redhat.com> (raw)
In-Reply-To: <20131014181525.22240a98@nial.usersys.redhat.com>
On Mon, Oct 14, 2013 at 06:15:25PM +0200, Igor Mammedov wrote:
> On Mon, 14 Oct 2013 17:00:47 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Mon, Oct 14, 2013 at 03:04:45PM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > >
> > > > > 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.
> > > >
> > > > Only if the newfeature address is not under bios control. I know that
> > > > bios is simplistic so all it cares about ATM is pci window, but can't
> > > > shake the impression that we are better off telling the guest what's
> > > > going on rather than what it should do.
> > > >
> > > > In particular the issue that was discussed (what to do
> > > > if pci start is set by host to below ram end)
> > > > will simply go away if we pass in an incremental
> > > > value: there will be no invalid configurations.
> > >
> > > The "what is going on" might need updates in both qemu and seabios if
> > > something new goes on. For example qemu getting support non-contignous
> > > memory. The "leave that much address space free above memory" suddenly
> > > is ambiguous as there are two (or more) memory blocks above 4g. "please
> > > place 64bit pci bars there" continues to work just fine.
> >
> > Yes but at the cost of overspecifying it.
> > I think it's down to the name: it's called pcimem64-start
> > but it can actually be less than 4G and we need to worry what to
> > do then. Also, 64 doesn't really mean >4G.
> Why 64bit PCI window can't start below 4G, is there a SPEC that forbids it?
> If hardware says it has window start below 4G, than it's build this way.
That's the issue.
There's no such thing as a 64 bit window in spec or any
real hardware.
On PIIX RAM had priority so where you put RAM
you could't put PCI devices.
This is what creates the "64 bit window".
> I'd use v1 of this patch, i.e. if QEMU tells that window starts below 4G,
> then it supports such configuration.
How does this work exactly?
"64 bit window" is simply BIOS putting devices
above 4G if it can't put them all below 4G.
It seems that if you create this config you will
just get a broken system.
> >
> > So how about "reserve-memory-over-4g"?
> > bios then does 1ull << 32 + reserve-memory-over-4g
> > to figure out how much to skip.
>
> That name means making implicit assumption that PCI windows start after
> "reserve-memory-over-4g". I'd rather have an explicit interface that tells
> where window starts, without making any assumptions.
Not at all. It allows bios to put pci where it wants.
QEMU just tells bios where it *can't* go.
> Alternatively how about
> something like "pcimem64-start-high-dword" and making it 32 bit value
> passing 32-63 bits?
>
>
>
It's an option ...
next prev parent reply other threads:[~2013-10-14 16:34 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
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 [this message]
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=20131014163714.GA13477@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 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).