All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexey Korolev <alexey.korolev@endace.com>
Cc: sfd@endace.com, Kevin O'Connor <kevin@koconnor.net>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC/PATCH] Fix guest OS panic when 64bit BAR is present
Date: Wed, 25 Jan 2012 14:51:31 +0200	[thread overview]
Message-ID: <20120125125131.GC22203@redhat.com> (raw)
In-Reply-To: <4F1F971B.4020309@endace.com>

On Wed, Jan 25, 2012 at 06:46:03PM +1300, Alexey Korolev wrote:
> Hi, 
> In this post
> http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg03171.html I've
> mentioned about the issues when 64Bit PCI BAR is present and 32bit
> address range is selected for it.
> The issue affects all recent qemu releases and all
> old and recent guest Linux kernel versions.
> 
> We've done some investigations. Let me explain what happens.
> Assume we have 64bit BAR with size 32MB mapped at [0xF0000000 -
> 0xF2000000]
> 
> When Linux guest starts it does PCI bus enumeration.
> The OS enumerates 64BIT bars using the following procedure.
> 1. Write all FF's to lower half of 64bit BAR
> 2. Write address back to lower half of 64bit BAR
> 3. Write all FF's to higher half of 64bit BAR
> 4. Write address back to higher half of 64bit BAR
> 
> Linux code is here: 
> http://lxr.linux.no/#linux+v3.2.1/drivers/pci/probe.c#L149
> 
> What does it mean for qemu?
> 
> At step 1. qemu pci_default_write_config() recevies all FFs for lower
> part of the 64bit BAR. Then it applies the mask and converts the value
> to "All FF's - size + 1" (FE000000 if size is 32MB).
> Then pci_bar_address() checks if BAR address is valid. Since it is a
> 64bit bar it reads 0x00000000FE000000 - this address is valid. So qemu
> updates topology and sends request to update mappings in KVM with new
> range for the 64bit BAR FE000000 - 0xFFFFFFFF. This usually means kernel
> panic on boot, if there is another mapping in the FE000000 - 0xFFFFFFFF
> range, which is quite common.
> 
> 
> The following patch fixes the issue. It affects 64bit PCI BAR's only. 
> The idea of the patch is: we introduce the states for low and high BARs
> whose can have 3 possible values: BAR_VALID, PCIBAR64_PARTIAL_SIZE_QUERY
> - someone has requested size of one half of the 64bit PCI BAR,
> PCIBAR64_PARTIAL_ADDR_PROGRAM - someone has sent a request to update the
> address of one half of the 64bit PCI BAR. The state becomes BAR_VALID
> when both halfs are in the same state. We ignore BAR value until both
> states become BAR_VALID
> 
> Note: Please use the latest Seabios version (commit
> 139d5ac037de828f89c36e39c6dd15610650cede and later), as older versions
> didn't initialize high part of 64bit BAR. 
> 
> The patch is tested on Linux 2.6.18 - 3.1.0 and Windows 2008 Server
> 
> Signed-off-by: Alexey Korolev <alexey.korolev@endace.com>

Interesting. However, looking at guest code,
I note that memory and io are disabled
during BAR sizing unless mmio always on is set.
pci_bar_address should return PCI_BAR_UNMAPPED
in this case, and we should never map this BAR
until it's enabled. What's going on?

  reply	other threads:[~2012-01-25 12:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-25  5:46 [Qemu-devel] [RFC/PATCH] Fix guest OS panic when 64bit BAR is present Alexey Korolev
2012-01-25 12:51 ` Michael S. Tsirkin [this message]
2012-01-26  3:20   ` Alexey Korolev
2012-01-25 15:38 ` Michael S. Tsirkin
2012-01-25 18:59   ` Alex Williamson
2012-01-26  3:19     ` Alexey Korolev
2012-01-26 13:51       ` Avi Kivity
2012-01-26 14:05         ` Michael S. Tsirkin
2012-01-26 14:33           ` Avi Kivity
2012-01-26  9:14 ` Michael S. Tsirkin
2012-01-26 13:52   ` Avi Kivity
2012-01-26 14:36     ` Michael S. Tsirkin
2012-01-26 15:12       ` Avi Kivity
2012-01-27  4:42         ` Alexey Korolev
2012-01-31  9:40           ` Avi Kivity
2012-01-31  9:43             ` Avi Kivity
2012-02-01  5:44               ` Alexey Korolev
2012-02-01  7:04                 ` Michael S. Tsirkin
2012-02-02  2:22                   ` Alexey Korolev
2012-01-31 10:51           ` Avi Kivity
2012-01-27  4:40       ` Alexey Korolev

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=20120125125131.GC22203@redhat.com \
    --to=mst@redhat.com \
    --cc=alexey.korolev@endace.com \
    --cc=kevin@koconnor.net \
    --cc=qemu-devel@nongnu.org \
    --cc=sfd@endace.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.