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: Tue, 29 Jun 2010 09:50:45 +0300 [thread overview]
Message-ID: <4C2997C5.1020302@redhat.com> (raw)
In-Reply-To: <AANLkTim7furDw0Z7qBc82_1X9Zh023y4Qro4fP3QkyJi@mail.gmail.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.
next prev parent reply other threads:[~2010-06-29 6:50 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
2010-06-28 20:38 ` Cam Macdonell
2010-06-29 6:50 ` Avi Kivity [this message]
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=4C2997C5.1020302@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).