From: Avi Kivity <avi@redhat.com>
To: Cam Macdonell <cam@cs.ualberta.ca>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Qemu-devel] Guest cannot handle a PCI BAR > 1GB
Date: Sun, 05 Sep 2010 19:50:34 +0300 [thread overview]
Message-ID: <4C83CA5A.7030404@redhat.com> (raw)
In-Reply-To: <AANLkTimk19OmkNYvVemxgyFfgByNDDq6R2fa6=FQ8H9L@mail.gmail.com>
On 09/04/2010 01:22 AM, Cam Macdonell wrote:
> Hi,
>
> I'm trying to test 2 GB (and eventually larger) BARs with ivshmem and
> I get an error in the guest that it is able to find a mem resource for
> a BAR larger than 1GB. I'm using 64-bit BARs.
>
> when running with 6GB of RAM and a 1GB BAR for ivshmem, it finds a
> resource (and searches beyond 32-bit values to find it). Here is a
> log from printfs added to the loop that searches the resources from
> find_resource() in kernel/resource.c:363.
>
This is a kernel question, not a qemu issue. Copying lkml.
> trying 'tmp.start' 1000 to
> 'tmp.end' fff
> trying 'tmp.start' 9f400 to
> 'tmp.end' 9f3ff
> trying 'tmp.start' a0000 to
> 'tmp.end' effff
> trying 'tmp.start' 100000 to
> 'tmp.end' fffff
> trying 'tmp.start' dfffd000 to
> 'tmp.end' dfffcfff
> trying 'tmp.start' e0000000 to
> 'tmp.end' efffffff
> trying 'tmp.start' f2000000 to
> 'tmp.end' f1ffffff
> trying 'tmp.start' f2001000 to
> 'tmp.end' f200ffff
> trying 'tmp.start' f2020000 to
> 'tmp.end' f201ffff
> trying 'tmp.start' f2021000 to
> 'tmp.end' f202ffff
> trying 'tmp.start' f2040000 to
> 'tmp.end' f203ffff
> trying 'tmp.start' f2040100 to
> 'tmp.end' febfffff
> trying 'tmp.start' fec00400 to
> 'tmp.end' fffbffff
> trying 'tmp.start' 100000000 to
> 'tmp.end' ffffffff
> trying 'tmp.start' 1a0000000 to
> 'tmp.end' ffffffffffffffff
> pci 0000:00:04.0: BAR 2: assigned [mem 0x1c0000000-0x1ffffffff 64bit]
> pci 0000:00:04.0: BAR 2: set to [mem 0x1c0000000-0x1ffffffff 64bit]
> (PCI address [0x1c0000000-0x1ffffffff]
>
> and you can see the BAR is successfully assigned.
>
> However, with a 2GB BAR (below), the search fails, but it also never
> searches beyong 32-bits. Again, all that's changed is the size of the
> ivshmem region.
>
> trying 'tmp.start' 1000 to
> 'tmp.end' fff
> trying 'tmp.start' 9f400 to
> 'tmp.end' 9f3ff
> trying 'tmp.start' a0000 to
> 'tmp.end' effff
> trying 'tmp.start' 100000 to
> 'tmp.end' fffff
> trying 'tmp.start' dfffd000 to
> 'tmp.end' dfffcfff
> pci 0000:00:04.0: BAR 2: can't assign mem (size 0x80000000)
>
> Is there a limit to PCI BAR sizes or resources? Any pointers or
> further debugging tips are greatly appreciated.
>
What kernel version are you looking at?
Please add printks to the loop so we can see this->start and this->end.
It smells like a truncation issue.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-09-05 16:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-03 22:22 [Qemu-devel] Guest cannot handle a PCI BAR > 1GB Cam Macdonell
2010-09-05 16:50 ` Avi Kivity [this message]
2010-09-06 16:37 ` Cam Macdonell
2010-09-06 17:24 ` Cam Macdonell
2010-09-08 0:01 ` [Qemu-devel] [solved] " Cam Macdonell
2010-09-08 0:25 ` [Qemu-devel] [PATCH] pci: fix pci_resource_alignment prototype Chris Wright
2010-09-09 20:41 ` [Qemu-devel] " Jesse Barnes
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=4C83CA5A.7030404@redhat.com \
--to=avi@redhat.com \
--cc=cam@cs.ualberta.ca \
--cc=linux-kernel@vger.kernel.org \
--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).