qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Cam Macdonell <cam@cs.ualberta.ca>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
Date: Sun, 27 Jun 2010 11:39:01 +0300	[thread overview]
Message-ID: <4C270E25.7070409@redhat.com> (raw)
In-Reply-To: <AANLkTinLUaXs0GwcwC9Zj9B1fWeSFZxwt8dNnD-OuBfD@mail.gmail.com>

On 06/25/2010 12:51 AM, Cam Macdonell wrote:
> On Tue, Jun 15, 2010 at 5:04 AM, Avi Kivity<avi@redhat.com>  wrote:
>    
>> On 06/11/2010 08:31 PM, Cam Macdonell wrote:
>>      
>>> 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.
>>>
>>>        
>> The guest kernel should never have generated an address that is bigger than
>> cpu_phys_bits in the first place.  What's the value for cpu_phys_bits in the
>> guest? (/proc/cpuinfo, 'address sizes :' line).
>>      
> Sorry I missed your reply until now.  The guest address sizes are as follows:
>
> address sizes   : 40 bits physical, 48 bits virtual
>    

So the address c20000000000 is illegal.

>> Is this really the address the guest programmed, or is qemu misinterpreting
>> it?
>>      

Well, what's the answer?

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2010-06-27  8:39 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 ` [Qemu-devel] " Cam Macdonell
2010-06-15 11:04   ` Avi Kivity
2010-06-24 21:51     ` Cam Macdonell
2010-06-27  8:39       ` Avi Kivity [this message]
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=4C270E25.7070409@redhat.com \
    --to=avi@redhat.com \
    --cc=cam@cs.ualberta.ca \
    --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).