From: "Michael S. Tsirkin" <mst@redhat.com>
To: qemu-devel@nongnu.org, cam@cs.ualberta.ca, stefanha@redhat.com
Cc: Anthony Liguori <anthony@codemonkey.ws>
Subject: [Qemu-devel] large size PCI windows vs ivshmem vs windows guests
Date: Thu, 18 Jul 2013 19:32:18 +0300 [thread overview]
Message-ID: <20130718163218.GA32343@redhat.com> (raw)
Currently seabios simply looks for 64 bit BARs and sums them up
to get the size of the region.
The result is reported in the CRS method in ACPI tables.
But this means that e.g. hotplug is broken - if we try to
add a huge ivshmem device there won't be place for it
in the 32 bit PCI hole, and a 64 bit one isn't declared.
So we really should declare some 64 bit windows,
but the question is - what's a good value for CRS?
It would appear that we should be able to declare
a very large window in CRS and be done with it.
Works fine for linux, but it turns out adding the following in CRS is
enough to make e.g. win7 x86 crash on boot:
diff --git a/src/acpi-dsdt-pci-crs.dsl b/src/acpi-dsdt-pci-crs.dsl
index d421891..405859d 100644
--- a/src/acpi-dsdt-pci-crs.dsl
+++ b/src/acpi-dsdt-pci-crs.dsl
@@ -36,6 +36,13 @@ Scope(\_SB.PCI0) {
0x00000000, // Address Translation Offset
0x00020000, // Address Length
,, , AddressRangeMemory, TypeStatic)
+ QWordMemory(ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
+ 0x00000000, // Address Space Granularity
+ 0x8000000000, // Address Range Minimum
+ 0x80FFFFFFFF, // Address Range Maximum
+ 0x00000000, // Address Translation Offset
+ 0x0100000000, // Address Length
+ ,, , AddressRangeMemory, TypeStatic)
DWordMemory(ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
0x00000000, // Address Space Granularity
0xE0000000, // Address Range Minimum
The issue is the Length field - if it's 0x0080000000 or
less win7 32 bit boots (an interesting tidbit - it seems
possible to declare more than one 2G resource,
but each one needs to be at most 2G - did they use some
signed integer somewhere?).
I'd like to propose the following:
- declare a safe value (2G) in CRS by default
you won't be able to use ivshmem with huge sizes
we can detect common cases and warn users
- add a flag controlling size of 64 bit window declared
I am guessing most people use <2G shared memory so won't
be affected.
Comments?
--
MST
reply other threads:[~2013-07-18 16:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20130718163218.GA32343@redhat.com \
--to=mst@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=cam@cs.ualberta.ca \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 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).