From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35018 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OTUek-00068c-3f
	for qemu-devel@nongnu.org; Tue, 29 Jun 2010 02:50:55 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OTUei-0003HX-UZ
	for qemu-devel@nongnu.org; Tue, 29 Jun 2010 02:50:53 -0400
Received: from mx1.redhat.com ([209.132.183.28]:28682)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OTUei-0003HP-Nv
	for qemu-devel@nongnu.org; Tue, 29 Jun 2010 02:50:52 -0400
Message-ID: <4C2997C5.1020302@redhat.com>
Date: Tue, 29 Jun 2010 09:50:45 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <y2u8286e4ee1004190941jfa473787z795d8a4dd1b295d5@mail.gmail.com>	<AANLkTikru9Ge2f2vr4dgi9Icn6D9THYiJmEb5-xpBIro@mail.gmail.com>	<4C175E30.2030605@redhat.com>	<AANLkTinLUaXs0GwcwC9Zj9B1fWeSFZxwt8dNnD-OuBfD@mail.gmail.com>	<4C270E25.7070409@redhat.com>
	<AANLkTim7furDw0Z7qBc82_1X9Zh023y4Qro4fP3QkyJi@mail.gmail.com>
In-Reply-To: <AANLkTim7furDw0Z7qBc82_1X9Zh023y4Qro4fP3QkyJi@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: Unusual physical address when using 64-bit BAR
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Cam Macdonell <cam@cs.ualberta.ca>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>, "Michael S. Tsirkin" <mst@redhat.com>

On 06/28/2010 11:38 PM, Cam Macdonell wrote:
>
>>
>>>> Is this really the address the guest programmed, or is qemu
>>>> misinterpreting
>>>> it?
>>>>
>>>>          
>> Well, what's the answer?
>>      
> You're going to have to give me a hint on how to determine that.
>
> lspci in the guest shows the following
>
> Memory at c20000000000 (64-bit, non-prefetchable) [size=1024M]
>
> does that demonstrate a guest generated address?
>    

That's the result of a round trip: the guest programmed the address and 
then read it back.  It could have been screwed up in the first place, or 
perhaps qemu screwed it up.

Add a printf() to the config space handlers in qemu (likely in your own 
code) on writes and reads, and show the relevant writes (and reads) for 
this BAR.

That's the theory of deductive debugging; however browsing the code 
shows the guest is at fault:

         for (i = 0; i < PCI_NUM_REGIONS; i++) {
             int ofs;
             if (i == PCI_ROM_SLOT)
                 ofs = PCI_ROM_ADDRESS;
             else
                 ofs = PCI_BASE_ADDRESS_0 + i * 4;

             u32 old = pci_config_readl(bdf, ofs);
             u32 mask;
             if (i == PCI_ROM_SLOT) {
                 mask = PCI_ROM_ADDRESS_MASK;
                 pci_config_writel(bdf, ofs, mask);
             } else {
                 if (old & PCI_BASE_ADDRESS_SPACE_IO)
                     mask = PCI_BASE_ADDRESS_IO_MASK;
                 else
                     mask = PCI_BASE_ADDRESS_MEM_MASK;
                 pci_config_writel(bdf, ofs, ~0);
             }
             u32 val = pci_config_readl(bdf, ofs);
             pci_config_writel(bdf, ofs, old);

             if (val != 0) {
                 u32 size = (~(val & mask)) + 1;
                 if (val & PCI_BASE_ADDRESS_SPACE_IO)
                     paddr = &pci_bios_io_addr;
                 else
                     paddr = &pci_bios_mem_addr;
                 *paddr = ALIGN(*paddr, size);
                 pci_set_io_region_addr(bdf, i, *paddr);
                 *paddr += size;
             }
         }
         break;
     }

Seabios completely ignore the 64-bitness of the BAR.  Looks like it also 
thinks the second half of the BAR is an I/O region instead of memory 
(hence the c200, that's part of the pci portio region.

Do post those reads and writes, I think there's more than one thing 
wrong here.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.