Hi guys,
I'm currently debugging a generic PCI Option ROM
(seen as legacy ROM since there is no PnP header).
This is the setup:
a. The Option ROM "merged" to coreboot binary as CBFS component
(./cbfstool <option-rom-path> genroms/option-rom.rom raw)
b. SeaBIOS would recognize the Option ROM and execute it. The execution
seems to take place after most PnP option ROM.
c. Coreboot+Seabios is running inside qemu.
d. The entire process (qemu with coreboot as "BIOS") is debugged remotely
using IDA Pro. The connection is through GDB remote debugging "plugin"
in IDA Pro.
Therefore, from Qemu persepective, its being debugged remotely by GDB.
Now, my question:
In this particular option ROM, a call to POST Memory Manager (PMM) is made
to allocate 64KB of memory. What "reaction" SeaBIOS would carry-out to
such request?
I've trying to debug this call but nothing seems to happen as I see it
from inside IDA Pro.
Any clues? or where should I peek in the source code?
TIA,
Darmawan
--
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-
On 09/26/2011 04:21 PM, Avi Kivity wrote:
> On 09/25/2011 08:22 PM, Jan Kiszka wrote:
>> On 2011-09-25 16:07, Avi Kivity wrote:
>> > On 09/23/2011 12:31 PM, Lai Jiangshan wrote:
>> >> > Moreover: wrong indention.
>> >> >
>> >> > You know that this won't work for qemu-kvm with in-kernel irqchip? You
>> >> > may want to provide a patch for that tree, emulating the unavailable
>> >> > LINT1 injection via testing the APIC configration and then raising an
>> >> > NMI as before if it is accepted.
>> >> >
>> >>
>> >> It works in my box but the NMI is not injected through the in-kernel
>> >> irqchip,
>> >> I will implement it as you suggested.
>> >
>> > Somewhat hacky; isn't it better to test LINT1 in the kernel (and
>> > redefine the KVM_NMI ioctl as "toggle LINT1")?
>>
>> KVM_NMI is required for user space IRQ chip as well.
>
> We could define KVM_NMI as edging the core NMI input if !irqchip_in_kernel, and toggling LINT1 otherwise. Hardly nice though.
>
> The current KVM_NMI with irqchip_in_kernel is not meaningful, since it doesn't obey the rules of any NMI source.
>
>> Introducing some KVM_SET_LINT1 is an option though. But emulating it for
>> the NMI button on older kernels sounds worthwhile nevertheless.
>>
>
> Perhaps this is the best option to avoid confusion.
>
(add cc: seabios(a)seabios.org)
Hi, All,
When I was implementing KVM_SET_LINT1, I found many places of
the qemu-kvm code need to be changed, and it became nasty.
And as Avi said KVM_NMI with irqchip_in_kernel is not meaningful,
so KVM_NMI is not used anymore when KVM_SET_LINT1 & irqchip_in_kernel,
it is dead.
Now, we redefine KVM_NMI with more proper meaning, when irqchip_in_kernel,
it is kernel/kvm's responsibility to simulate the NMI-injection and set LINT1.
When !irqchip_in_kernel, it is userspace's responsibility.
It results more real simulation and results simpler code,
and it don't need to add new ioctl interface,
and it can make use of existing KVM_NMI.
Thanks,
Lai
The 1.6.3 version of SeaBIOS is now ready. For more information on
the release, please see:
http://seabios.org/Releases
New in this release:
* Initial support for Xen
* PCI init (on emulators) uses a two-phase initialization
* Fixes for AHCI so it can work on real hardware. AHCI is now enabled by default.
* Bootsplash support for BMP files
* Several configuration options can now be configured at runtime via CBFS files
(eg, "etc/boot-menu-wait")
* PCI device scan is cached during POST phase
* Several bug fixes
For information on obtaining SeaBIOS, please see:
http://seabios.org/Download
-Kevin
Here's an updated revision of acpi runtime patching patchset.
As promised, this revision replaces the hardcoded offsets
in the ssdt_proc table with ones generated dynamically
from the mixed asl/aml listing.
Changes in v3:
- change ssdt generation code to get rid of hardcoded offsets
- enhancements to acpi_extract: add more extract methods
ACPI_EXTRACT_NAME_WORD_CONST - extract a Word Const object from Name()
ACPI_EXTRACT_NAME_BYTE_CONST - extract a Byte Const object from Name()
ACPI_EXTRACT_PROCESSOR_START - start of Processor() block
ACPI_EXTRACT_PROCESSOR_STRING - extract a NameString from Processor()
ACPI_EXTRACT_PROCESSOR_END - offset at last byte of Processor() + 1
Changes in v2:
- tools rewritten in python
- Original ASL retains _EJ0 methods, BIOS patches that to EJ0_
- generic ACP_EXTRACT infrastructure that can match Method
and Name Operators
- instead of matching specific method name, insert tags
in original DSL source and match that to AML
-----
Here's a bug: guest thinks it can eject VGA device and ISA bridge.
[root@dhcp74-172 ~]#lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 PCI bridge: Red Hat, Inc. Device 0001
00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device
00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device
01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03)
[root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/
adapter address attention latch module power
[root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/
adapter address attention latch module power
[root@dhcp74-172 ~]# echo 0 > /sys/bus/pci/slots/2/power
[root@dhcp74-172 ~]# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:03.0 PCI bridge: Red Hat, Inc. Device 0001
00:04.0 Ethernet controller: Qumranet, Inc. Virtio network device
00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device
01:00.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03)
This is wrong because slots 1 and 2 are marked as not hotpluggable
in qemu.
The reason is that our acpi tables declare both _RMV with value 0,
and _EJ0 method for these slots. What happens in this case
is undocumented by ACPI spec, so linux ignores _RMV,
and windows seems to ignore _EJ0.
The correct way to suppress hotplug is not to have _EJ0,
so this is what this patch does: it probes PIIX and
modifies DSDT to match.
With these patches applied, we get:
[root@dhcp74-172 ~]# ls /sys/bus/pci/slots/1/
address
[root@dhcp74-172 ~]# ls /sys/bus/pci/slots/2/
address
Michael S. Tsirkin (4):
acpi: generate and parse mixed asl/aml listing
acpi: EJ0 method name patching
acpi: remove _RMV
acpi: automatically generated ssdt proc
Makefile | 12 +-
src/acpi-dsdt.dsl | 96 +++++--------
src/acpi.c | 64 ++++++---
src/ssdt-proc.dsl | 19 +--
tools/acpi_extract.py | 278 ++++++++++++++++++++++++++++++++++++++
tools/acpi_extract_preprocess.py | 37 +++++
6 files changed, 411 insertions(+), 95 deletions(-)
create mode 100755 tools/acpi_extract.py
create mode 100755 tools/acpi_extract_preprocess.py
--
1.7.5.53.gc233e
Some cleanups to the pciinit.c code.
These are some things I noticed while tracking down the recent bug
reports caused by calling ALIGN_DOWN with a zero alignment. The fix
to that bug was small enough to commit immediately. However, I think
it would be worthwhile to also commit the cleanups I found.
Given this is just a cleanup, I don't intend to commit until after
v1.6.3 is tagged.
-Kevin
Kevin O'Connor (6):
Use standard formatting for PCI info during PCI init pass.
Separate pciinit.c into clearly delineated sections.
Simplify pci_bios_init_root_regions().
Use pci->header_type in pci_bar() to avoid unnecessary
pci_config_readb.
Introduce PCI child device iterators and use in pciinit.c.
Simplify pci_slot_get_irq().
src/pci.c | 2 +
src/pci.h | 12 ++
src/pciinit.c | 337 +++++++++++++++++++++++++++------------------------------
3 files changed, 173 insertions(+), 178 deletions(-)
--
1.7.6.2
