Hi,
We have got some issues with 64bit PCI devices support under Windows guests.
Windows fails to start any PCI devices with 64bit BARs when size exceeds
512MB with error code 12 (can't allocate resources). In other words it
fails when the PCI memory region is located above 4GB.
I tried to investigate this problem and found document from Microsoft:
http://msdn.microsoft.com/en-us/windows/hardware/gg462986
It states that the _DSM method must be implemented to support devices
above 4GB.
Unfortunately I'm not familiar with ACPI code of seabios, so can't
implement the _DSM method. May be you have other ideas what needs to be
done to fix it? Any help is appreciated.
Thanks,
Alexey
On Thu, Oct 13, 2011 at 03:56:48PM +0200, Wolfgang Kamp - datakamp wrote:
>
> Hi,
>
> is there any solution for the usb boot issue of the AMD SB800 Persimmon platform
> with SeaBIOS 1.6.3 and actual Coreboot version?
I'm unfamiliar with the issue. Can you post the SeaBIOS debug output
along with a description of the issue you are seeing?
-Kevin
On 09/09/11 15:08, Amos Kong wrote:
> Hello all,
>
> I'm working on hotplug pci multifunction.
>
> 1. qemu cmdline:
> ./x86_64-softmmu/qemu-system-x86_64 -snapshot -m 2000 /home/kvm_autotest_root/images/rhel61-64-virtio.qcow2 -vnc :0 -monitor unix:/tmp/a,server,nowait --enable-kvm -net none
>
> 2. script to add virtio-blk devices:
> for i in `seq 1 7` 0;do
> qemu-img create /tmp/resize$i.qcow2 1G -f qcow2
> echo drive_add 0x6.$i id=drv$i,if=none,file=/tmp/resize$i.qcow2 | nc -U /tmp/a
> echo device_add virtio-blk-pci,id=dev$i,drive=drv$i,addr=0x6.$i,multifunction=on | nc -U /tmp/a
> done
>
> 3. script to add virio-nic devices:
> for i in `seq 1 7` 0;do
> echo netdev_add tap,id=drv$i | nc -U /tmp/a
> echo device_add virtio-net-pci,id=dev$i,netdev=drv$i,addr=0x6.$i,multifunction=on | nc -U /tmp/a
> done
>
> 4. current qemu behaviors
> 4.1. add func 1~7 one by one, then add func 0
> virtio-nic : success, all funcs are added
> virtio-blk : success
>
> 4.2. add func 0~7 one by one
> virtio-nic : failed, only func 0 is added
> virtio-blk : success
>
> 4.3. removing any single func in monitor
> virtio-nic: func 0 are not found in 'lspci', func 1~7 also exist. eth1~eth7 also exist.
> virtio-blk: func 0 are not found in 'lspci', func 1~7 also exist. the device. /dev/vda disappears,
> vdb,vdc,vde,vdf,vdg,vdh,vdi,vdj also exist. If I re-add 8 funcs to guest, they all works.
> # lspci (00:06.1 ~ 00:06.7 exist, 00:06.0 doesn't exit)
> 00:06.1 SCSI storage controller: Red Hat, Inc Virtio block device (rev ff)
>
> qemu sends an acpi event to guest, then guest will remove all funcs in the slot.
> linux-2.6/drivers/pci/hotplug/acpiphp_glue.c:
> static int disable_device(struct acpiphp_slot *slot) {
> list_for_each_entry(func,&slot->funcs, sibling) {
> ...
Hello all,
I re-tested the multifunction hotplug of winxp,rhel6,win7 guest.
(upstream qemu-kvm)
For all the guests, func0 needs to be added, otherwise no func can be
found in guest.
RHEL6 needs to add fun0 in the end, otherwise, the funcs added after
hot-adding func0 could not be found in guest.
For winxp,win7, add func0 in any time, all the funcs can be found in guest.
This is the test result( hogplug order of funcs & funcs can be found in
guest):
hotplug order xp win7 rhel6
------------ -- ---- -----
func 0~7 0~7 0~7 0~7
func 0~5 0~6 0~6 0~6
func 1~4,0,5 0~5 0~5 0~4
func 1~4 no no no
It looks like the 'problem' of linux guest, or could we accept to add
func0 after adding other funcs for linux guest?
Thanks,
Amos
> Questions:
> 1. why func1~7 still can be found after hot-remove? is it same as real hardware?
> 2. why the func 1~7 could not be added to guest (addingfunc 0~7 one by one)?
> 3. how about this interface to hotplug/hot-unplug multifunction:
> 1) Add func 1-7 by monitor, add func 0, then send an acpi event to notice guest
> 2) Remove func0, send an acpi event to guest. (all funcs can be removed)
> 4. what does "reversion 0xff" stand for?
>
> Thanks in advance,
> Amos
Here's an updated revision of acpi runtime patching patchset.
Lightly tested.
changes in v4:
- split PCI hotplug handling out to a separate SSDT
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 (3):
acpi: add ssdt for pci hotplug
acpi: EJ0 method name patching
acpi: remove _RMV
Makefile | 2 +-
src/acpi-dsdt.dsl | 132 +--------------------------------------------------
src/acpi.c | 40 ++++++++++++++++
src/ssdt-pcihp.dsl | 98 ++++++++++++++++++++++++++++++++++++++
4 files changed, 142 insertions(+), 130 deletions(-)
create mode 100644 src/ssdt-pcihp.dsl
--
1.7.5.53.gc233e
On Tue, Nov 22, 2011 at 05:39:07PM +0100, Wolfgang Kamp - datakamp wrote:
> Hi,
>
> I want to implement a Callback Function (04E08H- System BIOS INT
> 15H) for the AMD Video vBIOS (ATOM BIOS Extension Functions) to
> support LVDS TFT Displays with AMD G-Series processors (Persimmon
> mainboard). What is the best way to do this in SeaBIOS?
Take a look at src/vgahooks.c. You'll want to extend that for your
board.
> I need some parameter like UMA base and size from Coreboot. How can
> I transfer this information from Coreboot to SeaBIOS?
As ruik mentions - coreboot is itself getting the info from somewhere
(eg, the hardware) - if it's not too hard to have seabios pull the
info directly that would be ideal.
-Kevin
> I want to implement a Callback Function (04E08H- System BIOS INT 15H) for the
> AMD Video vBIOS (ATOM BIOS Extension Functions)
>
> to support LVDS TFT Displays with AMD G-Series processors (Persimmon mainboard).
Is there any freely accessible documentation? Do you know if VBIOS calls this? I
tried to investigate if mine video BIOS is doing any calls but if I recall
correctly i havent seen that. I have some trouble with flicker during FID/VID
changes any clue here?
>
> What is the best way to do this in SeaBIOS?
I guess just implementing that.
> I need some parameter like UMA base and size from Coreboot. How can I transfer
> this information from Coreboot to SeaBIOS?
Read the config out of the hardware if possible.
Check gfx.c in coreboot how to do that.
Thanks
Rudolf
> Thanks,
>
> Wolfgang
>
>
>
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS(a)seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
Hi,
I want to implement a Callback Function (04E08H- System BIOS INT 15H) for the AMD Video vBIOS (ATOM BIOS Extension Functions)
to support LVDS TFT Displays with AMD G-Series processors (Persimmon mainboard).
What is the best way to do this in SeaBIOS?
I need some parameter like UMA base and size from Coreboot. How can I transfer this information from Coreboot to SeaBIOS?
Thanks,
Wolfgang
