From: Cam Macdonell <cam@cs.ualberta.ca>
To: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Avi Kivity <avi@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
Date: Fri, 11 Jun 2010 11:31:16 -0600 [thread overview]
Message-ID: <AANLkTikru9Ge2f2vr4dgi9Icn6D9THYiJmEb5-xpBIro@mail.gmail.com> (raw)
In-Reply-To: <y2u8286e4ee1004190941jfa473787z795d8a4dd1b295d5@mail.gmail.com>
On Mon, Apr 19, 2010 at 10:41 AM, Cam Macdonell <cam@cs.ualberta.ca> wrote:
> Hi,
>
> I'm trying to use a 64-bit BAR for my shared memory device. In simply
> changing the memory type in pci_register_bar() to
> PCI_BASE_ADDRESS_MEM_TYPE_64 I get an unusual physical address for
> that BAR (and my driver crashes in pci_ioremap).
>
> from lspci:
>
> 00:04.0 RAM memory: Qumranet, Inc. Device 1110
> Subsystem: Qumranet, Inc. Device 1100
> Flags: fast devsel, IRQ 10
> Memory at f1020000 (32-bit, non-prefetchable) [size=1K]
> Memory at f1021000 (32-bit, non-prefetchable) [size=4K]
> Memory at c20000000000 (64-bit, non-prefetchable) [size=1024M]
> Capabilities: <access denied>
> 00: f4 1a 10 11 03 00 10 00 00 00 00 05 00 00 00 00
> 10: 00 00 02 f1 00 10 02 f1 04 00 00 00 00 c2 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 f4 1a 00 11
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
>
> with DEBUG_MEMREG, I see
>
> kvm_unregister_memory_area:666 Unregistering memory region
> c20000000000 (40000000)
> kvm_destroy_phys_mem:649 slot 7 start c20000000000 len 0 flags 0
> IVSHMEM: addr = 3221225472 size = 1073741824
> kvm_register_phys_mem:605 memory: gpa: c200c0000000, size: 40000000,
> uaddr: 7f6dd7ffe000, slot: 7, flags: 0
> kvm_unregister_memory_area:666 Unregistering memory region
> c200c0000000 (40000000)
> kvm_destroy_phys_mem:649 slot 7 start c200c0000000 len 0 flags 0
> IVSHMEM: addr = 0 size = 1073741824
> kvm_register_phys_mem:605 memory: gpa: c20000000000, size: 40000000,
> uaddr: 7f6dd7ffe000, slot: 7, flags: 0
> kvm_unregister_memory_area:666 Unregistering memory region
> c20000000000 (40000000)
> kvm_destroy_phys_mem:649 slot 7 start c20000000000 len 0 flags 0
> IVSHMEM: addr = 0 size = 1073741824
> kvm_register_phys_mem:605 memory: gpa: ffffffff00000000, size:
> 40000000, uaddr: 7f6dd7ffe000, slot: 7, flags: 0
> kvm_unregister_memory_area:666 Unregistering memory region
> ffffffff00000000 (40000000)
> kvm_destroy_phys_mem:649 slot 7 start ffffffff00000000 len 0 flags 0
> IVSHMEM: addr = 0 size = 1073741824
> kvm_register_phys_mem:605 memory: gpa: c20000000000, size: 40000000,
> uaddr: 7f6dd7ffe000, slot: 7, flags: 0
>
> (the IVSHMEM lines are my debug statements)
>
> address sizes : 40 bits physical, 48 bits virtual (guest)
> address sizes : 38 bits physical, 48 bits virtual (host)
>
Hi, I happened to run into this problem again when trying to use a
64-bit BAR. I did a bit more digging and the test that is failing is
called from arch/x86/mm/ioremap.c in the guest and here it is.
static inline int phys_addr_valid(resource_size_t addr)
{
#ifdef CONFIG_PHYS_ADDR_T_64BIT
return !(addr >> boot_cpu_data.x86_phys_bits);
#else
return 1;
#endif
}
the value of addr (in this case the 48-bit virtual address
c20000000000) is shifted to the right shift by
boot_cpu_data.x86_phys_bits (which is 40 bits, the physical address
size), so a non-zero value is returned which causes the test to fail
and generates the "invalid physical address" error in the guest.
Any help is appreciated as to whether this is a Qemu or guest kernel issue.
Thanks,
Cam
next prev parent reply other threads:[~2010-06-11 17:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 16:41 [Qemu-devel] Unusual physical address when using 64-bit BAR Cam Macdonell
2010-06-11 17:31 ` Cam Macdonell [this message]
2010-06-15 11:04 ` [Qemu-devel] " Avi Kivity
2010-06-24 21:51 ` Cam Macdonell
2010-06-27 8:39 ` Avi Kivity
2010-06-28 20:38 ` Cam Macdonell
2010-06-29 6:50 ` Avi Kivity
2010-06-29 17:48 ` Cam Macdonell
2010-06-30 3:29 ` Isaku Yamahata
2010-07-13 20:05 ` Cam Macdonell
2010-07-13 20:41 ` Isaku Yamahata
2010-07-13 22:48 ` Cam Macdonell
2010-07-14 2:52 ` Isaku Yamahata
2010-07-14 15:10 ` Cam Macdonell
2010-07-20 9:52 ` Isaku Yamahata
2010-07-21 3:31 ` Michael S. Tsirkin
2010-07-21 3:49 ` Isaku Yamahata
2010-08-24 16:52 ` Cam Macdonell
2010-08-25 2:21 ` Isaku Yamahata
2010-08-27 19:35 ` Cam Macdonell
2010-08-30 2:36 ` Isaku Yamahata
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=AANLkTikru9Ge2f2vr4dgi9Icn6D9THYiJmEb5-xpBIro@mail.gmail.com \
--to=cam@cs.ualberta.ca \
--cc=avi@redhat.com \
--cc=mst@redhat.com \
--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).