From: Gerd Hoffmann <kraxel@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
seabios@seabios.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH] acpi: hide 64-bit PCI hole for Windows XP
Date: Thu, 08 Aug 2013 16:56:55 +0200 [thread overview]
Message-ID: <5203B1B7.5000102@redhat.com> (raw)
In-Reply-To: <20130808141347.GA30200@redhat.com>
On 08/08/13 16:13, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 2013 at 12:21:32PM +0200, Gerd Hoffmann wrote:
>> On 08/08/13 11:52, Michael S. Tsirkin wrote:
>>> On Thu, Aug 08, 2013 at 10:57:44AM +0200, Gerd Hoffmann wrote:
>>>> On 08/08/13 10:37, Michael S. Tsirkin wrote:
>>>>> On Thu, Aug 08, 2013 at 09:57:39AM +0200, Gerd Hoffmann wrote:
>>>>>> Also coreboot and seabios use different values for pmbase. coreboot on
>>>>>> q35 maps the pmbase below 0x1000. Which surely makes sense. When we
>>>>>> don't place chipset stuff at 0xb000 we can assign the 0xb000->0xbfff
>>>>>> window to a pci bridge instead.
>
> Re-reading this - if this has value, can't we generalize it
> and make all firmware behave the same, getting values from QEMU?
pmbase is a compile-time constant (aka #define) in both seabios and
coreboot, and making this runtime-configurable is non-trivial. See
src/smm.c in seabios for one reason why.
Moving it to another fixed address below 0x1000 doesn't work, breaks
with old qemu+new seabios and other way around.
I think easiest is to allow firmware pick it and fixup the tables
provided by qemu accordingly.
Picking pmbase works in firmware today btw as both coreboot+seabios
generate a fadt with the correct values. Only nit is that this depends
on qemu 1.4+ as piix4 pmbase register was read-only in older qemu
versions. So everybody uses 0xb000 by default for bug compatibility
with older qemu versions.
>> Yes, the address ranges used for pci devices (aka 32bit + 64bit pci
>> window) need to be there. Well, placing in SSDT, then referencing from
>> DSDT works too, and this is what seabios does today to dynamically
>> adjust stuff. Fixing up the SSDT using the linker is probably easier as
>> we generate it anyway.
>>
>> cheers,
>> Gerd
>
> Yes but as I said, this makes things messy, since AML encoding for
> numbers isn't fixed width.
In seabios we have fixed 32bit / 64bit width today, from acpi.c:
// store pci io windows
*(u32*)&ssdt_ptr[acpi_pci32_start[0]] = cpu_to_le32(pcimem_start);
*(u32*)&ssdt_ptr[acpi_pci32_end[0]] = cpu_to_le32(pcimem_end - 1);
if (pcimem64_start) {
ssdt_ptr[acpi_pci64_valid[0]] = 1;
*(u64*)&ssdt_ptr[acpi_pci64_start[0]] = cpu_to_le64(pcimem64_start);
*(u64*)&ssdt_ptr[acpi_pci64_end[0]] = cpu_to_le64(pcimem64_end - 1);
*(u64*)&ssdt_ptr[acpi_pci64_length[0]] = cpu_to_le64(
pcimem64_end - pcimem64_start);
} else {
ssdt_ptr[acpi_pci64_valid[0]] = 0;
}
Storing fixup instructions for these fields in the linker script
shouldn't be hard I think.
cheers,
Gerd
next prev parent reply other threads:[~2013-08-08 14:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1375167638-4325-1-git-send-email-imammedo@redhat.com>
[not found] ` <20130731055959.GA31017@redhat.com>
[not found] ` <20130731081459.77eba7bb@nial.usersys.redhat.com>
[not found] ` <51FFCCF4.706@redhat.com>
[not found] ` <20130805181618.GB4244@redhat.com>
[not found] ` <911613672.9763982.1375729901921.JavaMail.root@redhat.com>
[not found] ` <20130806143901.GA17072@redhat.com>
[not found] ` <1243962588.10286037.1375807384073.JavaMail.root@redhat.com>
[not found] ` <20130806165820.GB20305@redhat.com>
[not found] ` <5201F763.3030507@redhat.com>
2013-08-08 6:04 ` [Qemu-devel] [SeaBIOS] [PATCH] acpi: hide 64-bit PCI hole for Windows XP Michael S. Tsirkin
[not found] ` <20130807095019.GA26266@redhat.com>
[not found] ` <5202218C.70005@redhat.com>
[not found] ` <20130807111031.GC3068@redhat.com>
[not found] ` <52023A52.6010208@redhat.com>
[not found] ` <20130807123509.GA10670@redhat.com>
[not found] ` <520257F8.1080501@redhat.com>
[not found] ` <20130807145312.GA14308@redhat.com>
[not found] ` <52034F73.4040904@redhat.com>
2013-08-08 8:37 ` Michael S. Tsirkin
2013-08-08 8:57 ` Gerd Hoffmann
2013-08-08 9:52 ` Michael S. Tsirkin
2013-08-08 10:21 ` Gerd Hoffmann
2013-08-08 14:13 ` Michael S. Tsirkin
2013-08-08 14:56 ` Gerd Hoffmann [this message]
2013-08-09 4:13 ` Kevin O'Connor
2013-08-09 6:25 ` Gerd Hoffmann
2013-08-10 3:10 ` Kevin O'Connor
2013-08-12 6:05 ` Gerd Hoffmann
2013-08-12 22:42 ` Kevin O'Connor
2013-08-13 6:49 ` Gerd Hoffmann
2013-08-14 12:38 ` Kevin O'Connor
2013-08-14 14:52 ` Gerd Hoffmann
2013-08-09 9:45 ` Gerd Hoffmann
2013-08-10 3:30 ` Kevin O'Connor
2013-08-10 15:50 ` Kevin O'Connor
2013-08-09 15:49 ` Michael S. Tsirkin
2013-08-10 3:06 ` Kevin O'Connor
2013-08-12 6:37 ` Gerd Hoffmann
2013-08-12 7:56 ` Michael S. Tsirkin
2013-08-12 13:08 ` Laszlo Ersek
[not found] ` <20130808082212.GA26837@redhat.com>
[not found] ` <52035C2F.4040700@redhat.com>
2013-08-08 9:37 ` Michael S. Tsirkin
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=5203B1B7.5000102@redhat.com \
--to=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.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 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.