All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Alexey Korolev <alexey.korolev@endace.com>
Cc: sfd@endace.com, yamahata@valinux.co.jp, seabios@seabios.org,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)
Date: Fri, 16 Dec 2011 10:23:39 +0100	[thread overview]
Message-ID: <4EEB0E1B.5070002@redhat.com> (raw)
In-Reply-To: <4EEACBFB.7000909@endace.com>

On 12/16/11 05:41, Alexey Korolev wrote:
>>> I wonder if there any particular reason to separate prefetchable a
>>> non-prefetchable memory regions in pciinit? Extra two more regions would
>>> make code more complex.
>> Oh yes, there is.  Which reminds me that the whole thing isn't that easy
>> unfortunaly ...
>>
>> The reason are pci bridges.  They have two memory regions, one for
>> prefetchable and one for non-prefetchable memory.  All devices behind a
>> pci bridge must have the bars within the bridges memory regions, thats
>> why they are grouped together.
>>
>> This also implies that a 32bit and a 64bit bar (of the same type) behind
>> a pci bridge must be mapped next to each other, so moving up 64bit bars
>> unconditionally isn't going to fly.  Devices behind bridges need some
>> extra care, only when all bars are 64bit capable they can actually be
>> mapped above 4G.
> The qemu actually does not simulate PCI bridges at all. So good question
> shall we bother about this?

Yes.  There is work in progress to add pci-express and a more modern
chipset emulation to qemu.

I think for now it is fine if we simply map everything behind a bridge
below 4G and hash out the details (i.e. whenever we can move the bridge
memory window above 4G or not) later.

> I did some preliminary tests: 64bit BARs
> are working quite well for linux 2.6.18 - 3.0 and windows 2008.

Nice.

> Also I've found important detail that according to PCI architecture
> specification, the bridges can describe 64bit ranges for prefetchable
> type of memory only. So it's very unlikely that devices exporting 64bit
> non-prefetchable BARs. I guess we just need to add one extra type.

Agree.

> Even if there are two separate prefetchable memory regions (32 bit and
> 64bit), it won't be a problem as there is no bridge on the 440FX inside
> the virtual machine.

Yes, devices attached to the root bus don't have to care about bridge
windows.

cheers,
  Gerd

  reply	other threads:[~2011-12-16  9:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-30  1:04 [Qemu-devel] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method) Alexey Korolev
2011-11-30  7:49 ` Michael S. Tsirkin
2011-12-01  5:19   ` Alexey Korolev
2011-12-01 11:25     ` Gerd Hoffmann
2011-12-01 11:41       ` Gerd Hoffmann
2011-12-05  4:29         ` Alexey Korolev
2011-12-12  8:10           ` Gerd Hoffmann
2011-12-13  4:19             ` Alexey Korolev
2011-12-14  4:30               ` Alexey Korolev
2011-12-14  5:10                 ` Kevin O'Connor
2011-12-15  8:48                 ` Gerd Hoffmann
2011-12-16  4:41                   ` Alexey Korolev
2011-12-16  9:23                     ` Gerd Hoffmann [this message]
2011-12-01  5:49   ` Alexey Korolev
2011-12-01 10:17     ` Michael S. Tsirkin
2011-12-05  4:20       ` Alexey Korolev
2011-12-05  6:31         ` Michael S. Tsirkin
2011-12-06  4:23           ` Alexey Korolev
2011-12-13 11:11             ` [Qemu-devel] [SeaBIOS] " Gerd Hoffmann
2011-12-14  4:31               ` 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=4EEB0E1B.5070002@redhat.com \
    --to=kraxel@redhat.com \
    --cc=alexey.korolev@endace.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    --cc=sfd@endace.com \
    --cc=yamahata@valinux.co.jp \
    /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.