linux-kernel - Re: [Qemu-devel] Guest cannot handle a PCI BAR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4C83CA5A.7030404@redhat.com>
Date:	Sun, 05 Sep 2010 19:50:34 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Cam Macdonell <cam@...ualberta.ca>
CC:	"qemu-devel@...gnu.org Developers" <qemu-devel@...gnu.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Qemu-devel] Guest cannot handle a PCI BAR > 1GB

  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/