SeaBIOS

seabios@seabios.org

3801 discussions

Re: [SeaBIOS] About hotplug multifunction
by Amos Kong 23 Nov '11

23 Nov '11

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

1 0

[PATCHv4 0/3] acpi: DSDT/SSDT runtime patching
by Michael S. Tsirkin 23 Nov '11

23 Nov '11

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

2 6

[PATCH] virtio-pci: include pci.h and pci_regs.h
by Sebastian Herbszt 23 Nov '11

23 Nov '11

Include pci.h and pci_regs.h. Signed-off-by: Sebastian Herbszt <herbszt(a)gmx.de> diff --git a/src/virtio-pci.c b/src/virtio-pci.c index 7e0c1a5..4b9ad0a 100644 --- a/src/virtio-pci.c +++ b/src/virtio-pci.c @@ -19,6 +19,8 @@ #include "virtio-pci.h" #include "config.h" // CONFIG_DEBUG_LEVEL #include "util.h" // dprintf +#include "pci.h" // pci_config_readl +#include "pci_regs.h" // PCI_BASE_ADDRESS_0 int vp_find_vq(unsigned int ioaddr, int queue_index, struct vring_virtqueue **p_vq)

2 1

Re: [SeaBIOS] VGA Callback function in SeaBIOS
by Kevin O'Connor 23 Nov '11

23 Nov '11

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

1 0

Re: [SeaBIOS] VGA Callback function in SeaBIOS
by Rudolf Marek 22 Nov '11

22 Nov '11

> 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

2 1

VGA Callback function in SeaBIOS
by Wolfgang Kamp - datakamp 22 Nov '11

22 Nov '11

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

1 0

[SeaBIOS PATCH] usb: fix boot paths
by Paolo Bonzini 22 Nov '11

22 Nov '11

The fw paths for USB devices that SeaBIOS computes are off-by-one, because QEMU builds those paths with a numbering that starts from one (see usb_fill_port and usb_hub_initfn in QEMU). Fix that so that the numbering agrees. --- src/boot.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/boot.c b/src/boot.c index 946850d..434bf80 100644 --- a/src/boot.c +++ b/src/boot.c @@ -205,9 +205,9 @@ int bootprio_find_usb(struct pci_device *pci, u64 path) for (i=56; i>0; i-=8) { int port = (path >> i) & 0xff; if (port != 0xff) - p += snprintf(p, desc+sizeof(desc)-p, "/hub@%x", port); + p += snprintf(p, desc+sizeof(desc)-p, "/hub@%x", port+1); } - snprintf(p, desc+sizeof(desc)-p, "/*@%x", (u32)(path & 0xff)); + snprintf(p, desc+sizeof(desc)-p, "/*@%x", (u32)(path & 0xff)+1); return find_prio(desc); } -- 1.7.7.1

2 3

[PATCH 00/16] make SCSI and virtio layers more generic, fix usb-msc bugs
by Paolo Bonzini 20 Nov '11

20 Nov '11

Hi all, this are the preparatory bits for virtio-scsi support in SeaBIOS. They mostly aim at making code more generic in SeaBIOS for both SCSI and virtio, but (on the SCSI side) they also fix some bugs, so I'm sending them early to get more exposure. New features are mostly visible on the USB side since that's currently the main consumer of the SCSI implementation. They include more robust LUN detection, support for hard disk geometry, and USB mass storage write support. I also fixed for real the race that the RFC series was working around. For virtio, the series adds a few extra interface bits that are common to both virtio-scsi and virtio-blk. The two parts are logically separate but they have a small conflict, so I'm sending them together. Paolo Bonzini (16): cdrom: use TEST UNIT READY to detect ready medium usb-uhci: reorganize wait_qh into wait_pipe usb-uhci: fix race against host controller usb-msc: support commands without payload usb-msc: add usb_msc_send usb-msc: support WRITE commands usb-msc: move READ CAPACITY to usb_msc_init, fix off-by-one usb-msc: pass drive to setup_drive_* usb-msc: rename INQUIRY types usb-msc: go through TEST UNIT READY for hard disks. usb-msc: move common scsi code to blockcmd.c usb-msc: move cdb dispatch to block.c scsi: get physical chs geometry from mode page 0x04 always specify virtio-blk rather than virtio virtio-pci: introduce vp_init_simple virtio-pci: allocate vq in vp_find_vq v1->v2: do not send commands to CDs until they are actually selected for boot; fix usb-uhci race for real; virtio-scsi driver not yet included. src/Kconfig | 4 +- src/block.c | 34 ++++++++++-- src/blockcmd.c | 157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/blockcmd.h | 42 ++++++++++++++- src/cdrom.c | 58 +------------------- src/disk.c | 4 +- src/disk.h | 18 +++--- src/usb-msc.c | 132 ++++++++++++++------------------------------- src/usb-msc.h | 3 - src/usb-uhci.c | 91 +++++++++++++++---------------- src/virtio-blk.c | 25 +++------ src/virtio-blk.h | 2 +- src/virtio-pci.c | 33 ++++++++++-- src/virtio-pci.h | 3 +- 14 files changed, 364 insertions(+), 242 deletions(-) -- 1.7.7.1

3 28

[PATCH 0/3] Additional USB fixes
by Kevin O'Connor 19 Nov '11

19 Nov '11

This series ports Paolo's uhci fixes to the ehci code. Unfortunately, I'm still seeing an occasional hang with my flash drives on my e350m1 (ehci controller), so there's still some other bug lurking in the ehci code. I also noticed an error in the usb-uhci (missing GET_FLATPTR) which is also in this series. Kevin O'Connor (3): usb-uhci: Be sure to wrap pipe->iobase in GET_FLATPTR(). usb-ehci: Convert ehci_wait_qh to ehci_wait_pipe. usb-ehci: Fix race with host controller. src/usb-ehci.c | 70 ++++++++++++++++++++++++------------------------------- src/usb-uhci.c | 7 +++-- 2 files changed, 35 insertions(+), 42 deletions(-) -- 1.7.6.4

2 5

Booting from USB cdrom device doesn't work
by Sven Schnelle 18 Nov '11

18 Nov '11

Hi List, i have seabios running on a Thinkpad T60 with coreboot and seabios as Payload. When trying to boot from a USB cdrom, i get the following errors: Booting from DVD/CD... wait_td error - status=184007ff uhci_send_bulk failed USB transmission failed wait_td error - status=184007ff uhci_send_bulk failed USB transmission failed WARNING - Timeout at wait_td:427! uhci_send_bulk failed USB transmission failed WARNING - Timeout at wait_td:427! uhci_send_bulk failed USB transmission failed read capacity failed atapi_is_ready returned -1 WARNING - Timeout at wait_td:427! uhci_send_bulk failed USB transmission failed Boot failed: Could not read from CDROM (code 0003) I have no knowledge about USB, so if anybody could help me in interpreting those messages, or has an other idea what the problem is, that would be great. Thanks, Sven

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS