December 2015 - SeaBIOS - mail.coreboot.org

Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
by Kevin O'Connor Jan. 8, 2016

Jan. 8, 2016

On Mon, Dec 21, 2015 at 11:50:07AM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 12/17/2015 05:22:56 PM: > > > > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote: > > > Hello, > > > > > > I noticed that a lot of work is going on for the TPM support in > SeaBIOS. > > > > > > All of this work is TPM 1.2 based. I was wondering if there are any > > > plans to support TPM 2.0 in the future. > > > > I'm not aware of any plans. > > We're working on it... > > > So maybe you have some comments to the following: > > There will be a patch for probing the TPM TIS hardware interface for > whether there's a TPM 1.2 or a TPM 2. > We then have a patch for prefixing all TPM 1.2 functions with tpm12_ and > then introduce functions like these ones here: > > static ... tpm12_foo() { ... } > static ... tpm2_foo() { ... } > > tpm_foo() > { > [...] > > switch (tpmversion) { > case TPM_VERSION_1_2: > tpm12_foo() > break; > case TPM_VERSION_2: > tpm2_foo(); > break; > } > > [...] > } Is the difference between 1.2 and 2.0 so large that the above is needed? -Kevin

4 6

[PATCH 0/8] TPM return code simplifications
by Kevin O'Connor Jan. 5, 2016

Jan. 5, 2016

Hi Stefan, I cleaned up the additional patches I mentioned yesterday. Some time back, you posted a series of patches that removed the use of TCG 16bit BIOS structs from internal functions. Many of those functions were still using return codes from the spec though. I found using these return codes in internal functions to be annoying because they conflict with the TIS return codes. This series mostly just separates out the return codes so that only the TCG 16bit BIOS functions deal with the TCG 16bit BIOS return codes. This series is on top of patches 1-9 of the previous series (it replaces patch 10 of the previous series). Both series are also available at: https://github.com/KevinOConnor/seabios/tree/testing I'm not currently planning any other TPM changes after these. -Kevin Kevin O'Connor (8): tpm: Don't return a status from external bios measurement functions tpm: No need to check the return status of measurements tpm: Don't call tpm_set_failure() from tpm_log_extend_event() tpm: Don't use 16bit BIOS return codes in build_and_send_cmd() tpm: Don't use 16bit BIOS return codes in tpm_log_event() tpm: Don't use 16bit BIOS return codes in tpmhw_* functions tpm: Don't use 16bit BIOS return codes in TPM menu functions tpm: Replace build_and_send_cmd with tpm_send_cmd and tpm_send_check_cmd src/hw/tpm_drivers.c | 20 +- src/hw/tpm_drivers.h | 2 +- src/tcgbios.c | 718 +++++++++++++++++++-------------------------------- src/tcgbios.h | 8 +- 4 files changed, 287 insertions(+), 461 deletions(-) -- 2.5.0

3 12

[PATCH 00/10] Some TPM simplifications
by Kevin O'Connor Jan. 5, 2016

Jan. 5, 2016

The following series involves some code reorganization in the TPM code that I found useful in understanding the code. Patches 3-5 simplify the hardware interface by only exporting three commands to the underlying TIS hardware (tpmhw_probe, tpmhw_transmit, tpmhw_set_timeouts). Patches 8-10 simplify the parameters to the build_and_send_cmd() function. The remaining patches are mostly just code reorg. I have only compile tested these changes. -Kevin Kevin O'Connor (10): tpm: Add banner separating the TCG bios interface code from TCG menu code tpm: Avoid macro expansion of tpm request / response structs tpm: Simplify hardware probe and detection checks tpm: Add wrapper function tpm_set_timeouts() tpm: Move TPM hardware functions from tcgbios.c to hw/tpm_drivers.c tpm: Rework TPM interface shutdown support tpm: Simplify tcpa probe tpm: Introduce tpm_get_capability() helper function tpm: Eliminate response buffer parameter from build_and_send_cmd() tpm: Return returnCode from build_and_send_cmd() instead of via pointer param src/hw/tpm_drivers.c | 84 ++++++ src/hw/tpm_drivers.h | 28 +- src/std/tcg.h | 55 ++-- src/tcgbios.c | 704 +++++++++++++++------------------------------------ 4 files changed, 317 insertions(+), 554 deletions(-) -- 2.5.0

3 19

Re: [SeaBIOS] SeaBIOS crashes on CBFS without legacy header
by Kevin O'Connor Dec. 28, 2015

Dec. 28, 2015

On Thu, Dec 24, 2015 at 03:45:03PM -0800, Alex Gagniuc wrote: > When SeaBIOS is run on an FMAP-based CBFS (AKA, without a CBFS master > header, it crashes). The problem is in coreboot_cbfs_init. A > disassembly with -Mintel shows the following: > > 00000000 <coreboot_cbfs_init>: > ... > 7: 8b 35 fc ff ff ff mov esi,DWORD PTR ds:0xfffffffc > d: 81 3e 4f 52 42 43 cmp DWORD PTR [esi],0x4342524f > > > 7: 8b 35 fc ff ff ff mov esi,DWORD PTR ds:0xfffffffc > > Move the contents of memory address 0xfffffffc to esi. Since there's > no legacy CBFS pointer, the region is all 1's. esi now contains > 0xffffffff > > > d: 81 3e 4f 52 42 43 cmp DWORD PTR [esi],0x4342524f > > 32-bit dereference esi (0xffffffff) -- causes general protection > fault. The dereference is not because of unaligned access, but because > the access goes over the 32-bit address space in flat mode. The way > around this iss to sanitize the value at [0xffffffff] before > dereferencing it. A sane check is: > > if(address_of_hdr > (0xfffffff0 - sizeof(*hdr))) > fail(); > This is sane check because because the x86 reset vector is resides at > 0xfffffff0 (there are cases where this isn't true, but that's besides > the point here). Thanks. Can you put together a patch, or do you want me to? > There's also an unrelated problem with the C code that generates this assembly: > > > struct cbfs_header *hdr = *(void **)(CONFIG_CBFS_LOCATION - 4); > > With CONFIG_CBFS_LOCATION = 0, this places a negative value (-4) in an > unsigned type (pointer). The behavior of this is undefined according > to the C standard. Are you suggesting that an (unsigned) cast should be added? I doubt it would matter. -Kevin

2 2

[PATCH] build: fix typo in buildversion.py
by Roger Pau Monne Dec. 28, 2015

Dec. 28, 2015

Fixes the following build error: Building ld scripts Traceback (most recent call last): File "./scripts/buildversion.py", line 134, in <module> main() File "./scripts/buildversion.py", line 114, in main cleanbuild, toolstr = tool_versions(options.tools) File "./scripts/buildversion.py", line 90, in tool_versions vers[isbinutils] = "mixed" NameError: global name 'vers' is not defined Makefile:160: recipe for target 'out/romlayout16.lds' failed Signed-off-by: Roger Pau Monné <roger.pau(a)citrix.com> --- Cc: Kevin O'Connor <kevin(a)koconnor.net> --- scripts/buildversion.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/buildversion.py b/scripts/buildversion.py index ad47b90..4692898 100755 --- a/scripts/buildversion.py +++ b/scripts/buildversion.py @@ -87,7 +87,7 @@ def tool_versions(tools): if versions[isbinutils] and versions[isbinutils] != ver: logging.debug("Mixed version %s vs %s" % ( repr(versions[isbinutils]), repr(ver))) - vers[isbinutils] = "mixed" + versions[isbinutils] = "mixed" continue versions[isbinutils] = ver success += 1 -- 1.9.5 (Apple Git-50.3)

3 2

[PATCH 1/2] scsi: Do not call printf() from scsi_is_ready()
by Kevin O'Connor Dec. 28, 2015

Dec. 28, 2015

The scsi_is_ready() function may be called from a thread, and it is not valid to call printf() from a thread. Convert printf() to dprintf() to avoid this possibility. This does mean that cdrom detection (from cdrom_boot() ) may not give notification of slow cdrom drives to a user. However, the extra medium detection time is unlikely to be large anyway. Reported-by: Tobias Diedrich <tobiasdiedrich(a)gmail.com> Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/blockcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c index e20e3fc..0725b46 100644 --- a/src/hw/blockcmd.c +++ b/src/hw/blockcmd.c @@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op) if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) { /* IN PROGRESS OF BECOMING READY */ - printf("Waiting for device to detect medium... "); + dprintf(1, "Waiting for device to detect medium... "); /* Allow 30 seconds more */ end = timer_calc(30000); in_progress = 1; -- 2.5.0

1 2

[PATCH] nmi: Don't try to switch onto extra stack in NMI handler
by Kevin O'Connor Dec. 28, 2015

Dec. 28, 2015

The NMI could occur when already on the extra stack, which would corrupt it. Always use the current stack on an NMI to avoid this. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/romlayout.S | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/romlayout.S b/src/romlayout.S index fedadfe..53cc0f5 100644 --- a/src/romlayout.S +++ b/src/romlayout.S @@ -548,7 +548,10 @@ entry_post: ENTRY_INTO32 _cfunc32flat_handle_post // Normal entry point ORG 0xe2c3 - IRQ_ENTRY 02 + .global entry_02 +entry_02: + ENTRY handle_02 // NMI handler does not switch onto extra stack + iretw ORG 0xe3fe .global entry_13_official -- 2.5.0

1 1

SeaBIOS crashes on CBFS without legacy header
by Alex Gagniuc Dec. 24, 2015

Dec. 24, 2015

When SeaBIOS is run on an FMAP-based CBFS (AKA, without a CBFS master header, it crashes). The problem is in coreboot_cbfs_init. A disassembly with -Mintel shows the following: 00000000 <coreboot_cbfs_init>: ... 7: 8b 35 fc ff ff ff mov esi,DWORD PTR ds:0xfffffffc d: 81 3e 4f 52 42 43 cmp DWORD PTR [esi],0x4342524f > 7: 8b 35 fc ff ff ff mov esi,DWORD PTR ds:0xfffffffc Move the contents of memory address 0xfffffffc to esi. Since there's no legacy CBFS pointer, the region is all 1's. esi now contains 0xffffffff > d: 81 3e 4f 52 42 43 cmp DWORD PTR [esi],0x4342524f 32-bit dereference esi (0xffffffff) -- causes general protection fault. The dereference is not because of unaligned access, but because the access goes over the 32-bit address space in flat mode. The way around this iss to sanitize the value at [0xffffffff] before dereferencing it. A sane check is: if(address_of_hdr > (0xfffffff0 - sizeof(*hdr))) fail(); This is sane check because because the x86 reset vector is resides at 0xfffffff0 (there are cases where this isn't true, but that's besides the point here). There's also an unrelated problem with the C code that generates this assembly: > struct cbfs_header *hdr = *(void **)(CONFIG_CBFS_LOCATION - 4); With CONFIG_CBFS_LOCATION = 0, this places a negative value (-4) in an unsigned type (pointer). The behavior of this is undefined according to the C standard. Hope this helps, Alex

1 0

[PATCH] xhci: Wait for port enable even for USB3 devices
by Kevin O'Connor Dec. 23, 2015

Dec. 23, 2015

Some USB3 controllers (and/or devices) need additional time after the device is detected to place the port in an enabled state. Wait for the controller to report enabled before proceeding. This fixes several reports of devices that showed a "stall" error (cc 4) during set address. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> --- src/hw/usb-xhci.c | 43 +++++++++++++++++++++---------------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/src/hw/usb-xhci.c b/src/hw/usb-xhci.c index 945b462..654feba 100644 --- a/src/hw/usb-xhci.c +++ b/src/hw/usb-xhci.c @@ -350,42 +350,41 @@ xhci_hub_reset(struct usbhub_s *hub, u32 port) { struct usb_xhci_s *xhci = container_of(hub->cntl, struct usb_xhci_s, usb); u32 portsc = readl(&xhci->pr[port].portsc); - int rc; if (!(portsc & XHCI_PORTSC_CCS)) // Device no longer connected?! return -1; switch (xhci_get_field(portsc, XHCI_PORTSC_PLS)) { case PLS_U0: - // A USB3 port - no reset necessary. - rc = speed_from_xhci[xhci_get_field(portsc, XHCI_PORTSC_SPEED)]; + // A USB3 port - controller automatically performs reset break; case PLS_POLLING: - // A USB2 port - perform device reset and wait for completion + // A USB2 port - perform device reset xhci_print_port_state(3, __func__, port, portsc); writel(&xhci->pr[port].portsc, portsc | XHCI_PORTSC_PR); - u32 end = timer_calc(100); - for (;;) { - portsc = readl(&xhci->pr[port].portsc); - if (!(portsc & XHCI_PORTSC_CCS)) - // Device disconnected during reset - return -1; - if (portsc & XHCI_PORTSC_PED) - // Reset complete - break; - if (timer_check(end)) { - warn_timeout(); - return -1; - } - yield(); - } - rc = speed_from_xhci[xhci_get_field(portsc, XHCI_PORTSC_SPEED)]; break; default: - rc = -1; - break; + return -1; + } + + // Wait for device to complete reset and be enabled + u32 end = timer_calc(100); + for (;;) { + portsc = readl(&xhci->pr[port].portsc); + if (!(portsc & XHCI_PORTSC_CCS)) + // Device disconnected during reset + return -1; + if (portsc & XHCI_PORTSC_PED) + // Reset complete + break; + if (timer_check(end)) { + warn_timeout(); + return -1; + } + yield(); } + int rc = speed_from_xhci[xhci_get_field(portsc, XHCI_PORTSC_SPEED)]; xhci_print_port_state(1, "XHCI", port, portsc); return rc; } -- 2.5.0

1 1

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
by Kevin O'Connor Dec. 23, 2015

Dec. 23, 2015

On Wed, Dec 23, 2015 at 06:40:12AM +0000, Gonglei (Arei) wrote: > > From: Kevin O'Connor [mailto:kevin@koconnor.net] > > On Tue, Dec 22, 2015 at 02:14:12AM +0000, Gonglei (Arei) wrote: > > > Sorry, it doesn't work. What's worse is we cannot stop SeaBIOS stuck by > > > Setting "CONFIG_ENTRY_EXTRASTACK=n" after applying this patch. > > > > Oops, can you try with the patch below instead? > > > > It works now. Thanks! > > But do we need to check other possible situations > that maybe cause *extra stack* broken or overridden? I believe the issue is that an NMI could occur while SeaBIOS is already using its extra stack. The code is not prepared to switch into the extra stack while already on the extra stack. SeaBIOS is careful to always disable IRQs while running C code to prevent this issue, but disabling normal IRQs does not disable NMIs. So, I believe this issue is specific to the nature of NMIs. -Kevin

2 2

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Kevin O'Connor Dec. 23, 2015

Dec. 23, 2015

On Wed, Dec 23, 2015 at 09:14:44PM +0100, Tobias Diedrich wrote: > Final diff attached (without the src/stacks.c change, with %d->%u change > for sector counts). > Bootlog with debug_level 1 attached. Great! Patches sent - if no further comments I'll commit in a few days. -Kevin

1 0

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Tobias Diedrich Dec. 23, 2015

Dec. 23, 2015

Final diff attached (without the src/stacks.c change, with %d->%u change for sector counts). Bootlog with debug_level 1 attached. On Wed, Dec 23, 2015 at 8:56 PM, Tobias Diedrich <tobiasdiedrich(a)gmail.com> wrote: > I replaced the printf(...) with dprintf(1, ...) (since a dprintf earlier > in the function was working fine). > > This appears to have fixed the issue (though PCHS seems to be wrong, maybe > because sector count is negative when parsed as a signed int). Full log > attached. > > |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0 > removable=0 > \dfc04000/ End thread > |dfbfd000| USB MSC vendor='Multiple' product='Card Reader' rev='1.00' > type=0 removable=1 > |dfbfd000| Device reports MEDIUM NOT PRESENT > |dfbfd000| scsi_is_ready returned -1 > |dfbfd000| Unable to configure USB MSC drive. > |dfbfd000| Unable to configure USB MSC device. > \dfbfd000/ End thread > |dfc02000| Waiting for device to detect medium... \dfc03000/ End thread > |dfc02000| USB MSC blksize=512 sectors=-388003840 > |dfc02000| Registering bootable: USB MSC Drive WD Elements 10B8 1012 > (type:2 prio:103 data:f6110) > \dfc02000/ End thread > \dfc08000/ End thread > All threads complete. > Scan for option roms > > Press ESC for boot menu. > > > On Wed, Dec 23, 2015 at 7:58 PM, Kevin O'Connor <kevin(a)koconnor.net> > wrote: > >> On Wed, Dec 23, 2015 at 07:39:56PM +0100, Tobias Diedrich wrote: >> > On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor <kevin(a)koconnor.net> >> wrote: >> > >> > > On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote: >> > > > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 >> > > esp=dfbf3e50 >> > > > >> > > > .text._farcall16 0x9563 : { *(.text._farcall16) } >> > > > >> > > >> > > Can you include the full log? It looks like the code tried to call a >> > > 16bit function while in a "thread", and I need to figure out which >> > > thread did that. >> > >> > >> > From the esp address it looks like it'sin the USB probe for the MSC >> device >> > (full log attached): >> > /dfc02000\ Start thread func=dfc135f1 >> > |dfc02000| set_address 0xdfc0a200 >> > |dfc02000| config_usb: 0xdfc0a0d0 >> > |dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64 >> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5 >> /*@0/*@0,0 >> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5 >> > |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0 >> > removable=0 >> > Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0 >> esp=dfc02e54 >> > ret=0x000f0604 >> >> What happens if you apply the patch below? (If it looks like it is >> hanging, give it at least a minute before stopping it.) >> >> -Kevin >> >> >> --- a/src/hw/blockcmd.c >> +++ b/src/hw/blockcmd.c >> @@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op) >> >> if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) { >> /* IN PROGRESS OF BECOMING READY */ >> - printf("Waiting for device to detect medium... "); >> + //printf("Waiting for device to detect medium... "); >> /* Allow 30 seconds more */ >> end = timer_calc(30000); >> in_progress = 1; >> > >

1 0

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Kevin O'Connor Dec. 23, 2015

Dec. 23, 2015

On Wed, Dec 23, 2015 at 07:39:56PM +0100, Tobias Diedrich wrote: > On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > > > On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote: > > > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 > > esp=dfbf3e50 > > > > > > .text._farcall16 0x9563 : { *(.text._farcall16) } > > > > > > > Can you include the full log? It looks like the code tried to call a > > 16bit function while in a "thread", and I need to figure out which > > thread did that. > > > From the esp address it looks like it'sin the USB probe for the MSC device > (full log attached): > /dfc02000\ Start thread func=dfc135f1 > |dfc02000| set_address 0xdfc0a200 > |dfc02000| config_usb: 0xdfc0a0d0 > |dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64 > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5/*@0/*@0,0 > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5 > |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0 > removable=0 > Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0 esp=dfc02e54 > ret=0x000f0604 What happens if you apply the patch below? (If it looks like it is hanging, give it at least a minute before stopping it.) -Kevin --- a/src/hw/blockcmd.c +++ b/src/hw/blockcmd.c @@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op) if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) { /* IN PROGRESS OF BECOMING READY */ - printf("Waiting for device to detect medium... "); + //printf("Waiting for device to detect medium... "); /* Allow 30 seconds more */ end = timer_calc(30000); in_progress = 1;

2 1

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Kevin O'Connor Dec. 23, 2015

Dec. 23, 2015

On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote: > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50 > > .text._farcall16 0x9563 : { *(.text._farcall16) } > Can you include the full log? It looks like the code tried to call a 16bit function while in a "thread", and I need to figure out which thread did that. -Kevin

2 1

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Kevin O'Connor Dec. 23, 2015

Dec. 23, 2015

On Wed, Dec 23, 2015 at 07:13:27PM +0100, Tobias Diedrich wrote: > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50 > ret=0x000f2304 > > │.text:000F22C8 sub_F22C8 proc near ; CODE XREF: > sub_F2309+2Cvp > ▒ > │.text:000F22C8 ; sub_F2309+35vj > FYI, to line up "ret" with the code, one can look in out/romlayout32flat.lds . I prefer to run the following though: objdump -m i386 -M suffix -d out/rom.o | less and then look for the function containing the desired address. The thread associated with esp=dfbf3e50 is key though, which is why the full log is useful. -Kevin

1 0

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Kevin O'Connor Dec. 23, 2015

Dec. 23, 2015

On Wed, Dec 23, 2015 at 04:27:55PM +0100, Tobias Diedrich wrote: > And with verbose logging (level 8). > > [...] > Wcall16 with invalid stack Strange. Can you report the output with the patch below? -Kevin --- a/src/stacks.c +++ b/src/stacks.c @@ -274,7 +274,8 @@ call16(u32 eax, u32 edx, void *func) { ASSERT32FLAT(); if (getesp() > MAIN_STACK_MAX) - panic("call16 with invalid stack\n"); + panic("call16 with invalid stack eax=%x edx=%x func=%p esp=%x\n" + , eax, edx, func, getesp()); if (CONFIG_CALL32_SMM && Call16Data.method == C16_SMM) return call16_smm(eax, edx, func);

2 3

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Tobias Diedrich Dec. 23, 2015

Dec. 23, 2015

And with verbose logging (level 8). [...] |dfbf9000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0 removable=0 |dfbf9000| scsi_is_ready (drive=0x000f5c40) |dfbf9000| ehci_send_pipe qh=0x0009ed80 dir=0 data=0xdfbf9e45 size=31 |dfbfe000| ehci_send_pipe qh=0x0009ef00 dir=128 data=0xdfbfeed2 size=18 |dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9e38 size=13 |dfbfe000| ehci_send_pipe qh=0x0009ef00 dir=128 data=0xdfbfee38 size=13 |dfbf9000| ehci_send_pipe qh=0x0009ed80 dir=0 data=0xdfbf9e45 size=31 |dfbfe000| Device reports MEDIUM NOT PRESENT |dfbfe000| scsi_is_ready returned -1 |dfbfe000| Unable to configure USB MSC drive. |dfbfe000| phys_free f5c70 (detail=0xdfc08fe0) |dfbfe000| Unable to configure USB MSC device. |dfbfe000| phys_free dfc090f0 (detail=0xdfc090c0) |dfbfe000| phys_free dfc05400 (detail=0xdfc04e40) \dfbfe000/ End thread phys_free dfbfe000 (detail=0xdfc04e10) |dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9ed2 size=18 |dfc02000| ehci_free_pipes 0xdfc057b0 |dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9e38 size=13 |dfc02000| phys_free dfc08f00 (detail=0xdfc08f70) |dfc02000| phys_free 9ee80 (detail=0xdfc09060) |dfc02000| phys_free 9ef00 (detail=0xdfc09090) Wcall16 with invalid stack [hangs here] On Wed, Dec 23, 2015 at 4:05 PM, Tobias Diedrich <tobiasdiedrich(a)gmail.com> wrote: > Hi, > > I've attached a WD Elements 2TB drive to my pcengines APU1 as external > storage and just found that with the disk attached SeaBIOS crashes on boot. > :/ > The controller is USB2, not USB3. > > Both the stock rom "Build 4/5/2014 (current production)" and a > self-compiled coreboot rom with SeaBIOS master from git > (rel-1.9.0-43-g76327b9) exhibit the same issue. > > I'm not sure if > http://www.seabios.org/pipermail/seabios/2015-November/009910.html is the > same issue since it doesn't have log messages and doesn't seem to complain > about it not booting at all. > > Cheers, > Tobias >

1 0

WD Elements hang SeaBIOS at boot with "call16 with invalid stack"
by Tobias Diedrich Dec. 23, 2015

Dec. 23, 2015

Hi, I've attached a WD Elements 2TB drive to my pcengines APU1 as external storage and just found that with the disk attached SeaBIOS crashes on boot. :/ The controller is USB2, not USB3. Both the stock rom "Build 4/5/2014 (current production)" and a self-compiled coreboot rom with SeaBIOS master from git (rel-1.9.0-43-g76327b9) exhibit the same issue. I'm not sure if http://www.seabios.org/pipermail/seabios/2015-November/009910.html is the same issue since it doesn't have log messages and doesn't seem to complain about it not booting at all. Cheers, Tobias

1 0

Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
by Wim Vervoorn Dec. 23, 2015

Dec. 23, 2015

Hello Kevin, Understood. Thanks. Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervoorn(a)eltan.com W : http://www.eltan.com "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." From: Stefan Berger [mailto:stefanb@us.ibm.com] Sent: Tuesday, December 22, 2015 3:30 PM To: Wim Vervoorn <wvervoorn(a)eltan.com> Cc: Kevin O'Connor <kevin(a)koconnor.net>; seabios(a)seabios.org Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> wrote on 12/22/2015 09:15:55 AM: > > Hello Stefan, > > I think it will work perfectly for the higher level functions like : > tpm_smbios_measure(void) etc. Here you can easily implement tpm 1.2 > and 2.0 handling. For the functions like tpm_add_measurement_to_log() > I don’t think it is that easy or useful. For those it’s probably > better to have a tpm 1.2 and a tpm 2.0 variant each with their own > API but not with a wrapper. If TPM 2 is not operated in sha1 mode, then we may need different *internal* functions, yes (tpm2_bar()). Otherwise it's mostly byte streams being passed into the TPM parts to which sha1 is applied if needed; the exception is the BIOS API which seems to return SHA1 hashes in some structures. For the BIOS API functions where applications expect structures with embedded sha1 hashes, we will need to restrict those APIs to sha1 mode, return failure otherwise. If the standard defines structures (for BIOS) for sha256 etc., and possibly new API functions, then we can implement those for TPM 2 and they would result in an error if invoked by TPM 1.2 (which only supports sha1). Stefan > > Please note I did not look into all details so I might be seeing > problems that aren’t there (or can be solved easily). > > > Best Regards, > Wim Vervoorn > > Eltan B.V. > Ambachtstraat 23 > 5481 SM Schijndel > The Netherlands > > T : +31-(0)73-594 46 64 > E : wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com> > W : http://www.eltan.com<http://www.eltan.com/> > "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE > INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS > STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, > PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 > OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." > > > > > > > From: Stefan Berger [mailto:stefanb@us.ibm.com] > Sent: Tuesday, December 22, 2015 2:56 PM > To: Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> > Cc: Kevin O'Connor <kevin(a)koconnor.net<mailto:kevin@koconnor.net>>; seabios(a)seabios.org<mailto:seabios@seabios.org> > Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 > > Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> wrote on 12/22/2015 08:43:54 AM: > > > > > Hello Stefan, > > > > I have my doubts. This will work fine as long as the toplevel > > function tpm_foo() in your example can be implemented to have a > > single API independent of the required support. If the API differs > > between the tpm 1.2 and tpm 2.0 case I think it will only be > confusing things. > > > > Given the differences between tpm 1.2 and 2.0 do you think you will > > be able to maintain this single API? > > The top level function tpm_foo() will be called by other SeaBIOS > code for doing TPM initialization, > measurements, the menu, S3 resume, and for the BIOS API. For the API > we would support the same API > for TPM 1.2 and for TPM 2. The difference between the tpm12_foo and > tpm2_foo functions are mainly > that different TPM commands are created and sent to the TIS. So far, > this works fine. > > Do you have concrete concerns regarding this? How else would you do it ? > > Regards, > Stefan > > > > > > > Best Regards, > > Wim Vervoorn > > > > Eltan B.V. > > Ambachtstraat 23 > > 5481 SM Schijndel > > The Netherlands > > > > T : +31-(0)73-594 46 64 > > E : wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com> > > W : http://www.eltan.com<http://www.eltan.com/> > > "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE > > INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS > > STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, > > PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 > > OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." > > > > > > > > > > From: Stefan Berger [mailto:stefanb@us.ibm.com] > > Sent: Monday, December 21, 2015 5:50 PM > > To: Kevin O'Connor <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> > > Cc: seabios(a)seabios.org<mailto:seabios@seabios.org>; Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> > > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 > > > > "Kevin O'Connor" <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> wrote on 12/17/2015 05:22:56 PM: > > > > > > > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote: > > > > Hello, > > > > > > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS. > > > > > > > > All of this work is TPM 1.2 based. I was wondering if there are any > > > > plans to support TPM 2.0 in the future. > > > > > > I'm not aware of any plans. > > > > We're working on it... > > > > > > So maybe you have some comments to the following: > > > > There will be a patch for probing the TPM TIS hardware interface for > > whether there's a TPM 1.2 or a TPM 2. > > We then have a patch for prefixing all TPM 1.2 functions with tpm12_ > > and then introduce functions like these ones here: > > > > static ... tpm12_foo() { ... } > > static ... tpm2_foo() { ... } > > > > tpm_foo() > > { > > [...] > > > > switch (tpmversion) { > > case TPM_VERSION_1_2: > > tpm12_foo() > > break; > > case TPM_VERSION_2: > > tpm2_foo(); > > break; > > } > > > > [...] > > } > > > > That way the probing will lead us to use either TPM1.2 or TPM 2 > > specific code. There will be multiple such constructs in tcgbios.c file. > > > > Stefan

1 0

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
by Kevin O'Connor Dec. 22, 2015

Dec. 22, 2015

On Tue, Dec 22, 2015 at 02:14:12AM +0000, Gonglei (Arei) wrote: > > From: Kevin O'Connor [mailto:kevin@koconnor.net] > > Sent: Tuesday, December 22, 2015 2:47 AM > > To: Gonglei (Arei) > > Cc: Xulei (Stone); Paolo Bonzini; qemu-devel; seabios(a)seabios.org; > > Huangweidong (C); kvm(a)vger.kernel.org; Radim Krcmar > > Subject: Re: [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy > > problem on qemu-kvm platform > > > > On Mon, Dec 21, 2015 at 09:41:32AM +0000, Gonglei (Arei) wrote: > > > When the gurb of OS is booting, then the softirq and C function > > > send_disk_op() may use extra stack of SeaBIOS. If we inject a NMI, > > > romlayout.S: irqentry_extrastack is invoked, and the extra stack will > > > be used again. And the stack of first calling will be broken, so that the > > SeaBIOS stuck. > > > > > > You can easily reproduce the problem. > > > > > > 1. start on guest > > > 2. reset the guest > > > 3. inject a NMI when the guest show the grub surface 4. then the guest > > > stuck > > > > Does the SeaBIOS patch below help? > > Sorry, it doesn't work. What's worse is we cannot stop SeaBIOS stuck by > Setting "CONFIG_ENTRY_EXTRASTACK=n" after applying this patch. Oops, can you try with the patch below instead? > > I'm not familiar with how to "inject a > > NMI" - can you describe the process in more detail? > > > > 1. Qemu Command line: > > #: /home/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4096 -smp 8 -name suse -vnc 0.0.0.0:10 \ > -device virtio-scsi-pci,id=scsi0 -drive file=/home/suse11_sp3_32_2,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native \ > -device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \ > -chardev file,id=seabios,path=/home/seabios.log -device isa-debugcon,iobase=0x402,chardev=seabios \ > -monitor stdio -qmp unix:/tmp/qmp,server,nowait > > 2. Inject a NMI by QMP: > > #: /home/qemu/scripts/qmp # ./qmp-shell /tmp/qmp > Welcome to the QMP low-level shell! > Connected to QEMU 2.5.0 > > (QEMU) system_reset > {"return": {}} > (QEMU) inject-nmi > {"return": {}} > (QEMU) inject-nmi > {"return": {}} > I tried a few simple tests but was not able to reproduce. -Kevin --- a/src/romlayout.S +++ b/src/romlayout.S @@ -548,7 +548,10 @@ entry_post: ENTRY_INTO32 _cfunc32flat_handle_post // Normal entry point ORG 0xe2c3 - IRQ_ENTRY 02 + .global entry_02 +entry_02: + ENTRY handle_02 // NMI handler does not switch onto extra stack + iretw ORG 0xe3fe .global entry_13_official

2 1

Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
by Kevin O'Connor Dec. 22, 2015

Dec. 22, 2015

On Tue, Dec 22, 2015 at 11:03:09AM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 12/22/2015 10:40:03 AM: > > On Mon, Dec 21, 2015 at 11:50:07AM -0500, Stefan Berger wrote: > > > tpm_foo() > > > { > > > [...] > > > > > > switch (tpmversion) { > > > case TPM_VERSION_1_2: > > > tpm12_foo() > > > break; > > > case TPM_VERSION_2: > > > tpm2_foo(); > > > break; > > > } > > > > > > [...] > > > } > > > > Is the difference between 1.2 and 2.0 so large that the above is > > needed? > > TPM 2 and TPM 1.2 have completely different commands, so yes, > unfortunately it's needed. Okay. Just so I understand, is TPM 2.0 a new interface to the hardware, new BIOS API, or both? -Kevin

2 1

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
by Kevin O'Connor Dec. 22, 2015

Dec. 22, 2015

On Tue, Dec 22, 2015 at 03:15:26AM +0000, Xulei (Stone) wrote: > Hi, Kevin, > Can you tell how to reset/reboot this VM, if it goes to the handle_hwpic1() > on its booting procedure? I mean, usually, SeaBIOS would not go to > handle_hwpic routine. But in my test case, SeaBIOS calls handle_hwpic when > KVM injects a #UD expcetion (not irq) and SeaBIOS will loop to handle this > if KVM persistently injects exception. > > Now, i just wish to reset/reboot this VM if it is fall into handle_hwpic. I > tried follwing patch and it seems not work. What can i do to force reset/reboot? Call the reset() function. -Kevin

1 0

Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
by Wim Vervoorn Dec. 22, 2015

Dec. 22, 2015

Hello Stefan, I think it will work perfectly for the higher level functions like : tpm_smbios_measure(void) etc. Here you can easily implement tpm 1.2 and 2.0 handling. For the functions like tpm_add_measurement_to_log() I don't think it is that easy or useful. For those it's probably better to have a tpm 1.2 and a tpm 2.0 variant each with their own API but not with a wrapper. Please note I did not look into all details so I might be seeing problems that aren't there (or can be solved easily). Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervoorn(a)eltan.com W : http://www.eltan.com "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." From: Stefan Berger [mailto:stefanb@us.ibm.com] Sent: Tuesday, December 22, 2015 2:56 PM To: Wim Vervoorn <wvervoorn(a)eltan.com> Cc: Kevin O'Connor <kevin(a)koconnor.net>; seabios(a)seabios.org Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> wrote on 12/22/2015 08:43:54 AM: > > Hello Stefan, > > I have my doubts. This will work fine as long as the toplevel > function tpm_foo() in your example can be implemented to have a > single API independent of the required support. If the API differs > between the tpm 1.2 and tpm 2.0 case I think it will only be confusing things. > > Given the differences between tpm 1.2 and 2.0 do you think you will > be able to maintain this single API? The top level function tpm_foo() will be called by other SeaBIOS code for doing TPM initialization, measurements, the menu, S3 resume, and for the BIOS API. For the API we would support the same API for TPM 1.2 and for TPM 2. The difference between the tpm12_foo and tpm2_foo functions are mainly that different TPM commands are created and sent to the TIS. So far, this works fine. Do you have concrete concerns regarding this? How else would you do it ? Regards, Stefan > > > Best Regards, > Wim Vervoorn > > Eltan B.V. > Ambachtstraat 23 > 5481 SM Schijndel > The Netherlands > > T : +31-(0)73-594 46 64 > E : wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com> > W : http://www.eltan.com<http://www.eltan.com/> > "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE > INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS > STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, > PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 > OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." > > > > > From: Stefan Berger [mailto:stefanb@us.ibm.com] > Sent: Monday, December 21, 2015 5:50 PM > To: Kevin O'Connor <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> > Cc: seabios(a)seabios.org<mailto:seabios@seabios.org>; Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 > > "Kevin O'Connor" <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> wrote on 12/17/2015 05:22:56 PM: > > > > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote: > > > Hello, > > > > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS. > > > > > > All of this work is TPM 1.2 based. I was wondering if there are any > > > plans to support TPM 2.0 in the future. > > > > I'm not aware of any plans. > > We're working on it... > > > So maybe you have some comments to the following: > > There will be a patch for probing the TPM TIS hardware interface for > whether there's a TPM 1.2 or a TPM 2. > We then have a patch for prefixing all TPM 1.2 functions with tpm12_ > and then introduce functions like these ones here: > > static ... tpm12_foo() { ... } > static ... tpm2_foo() { ... } > > tpm_foo() > { > [...] > > switch (tpmversion) { > case TPM_VERSION_1_2: > tpm12_foo() > break; > case TPM_VERSION_2: > tpm2_foo(); > break; > } > > [...] > } > > That way the probing will lead us to use either TPM1.2 or TPM 2 > specific code. There will be multiple such constructs in tcgbios.c file. > > Stefan

2 1

Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
by Wim Vervoorn Dec. 22, 2015

Dec. 22, 2015

Hello Stefan, I have my doubts. This will work fine as long as the toplevel function tpm_foo() in your example can be implemented to have a single API independent of the required support. If the API differs between the tpm 1.2 and tpm 2.0 case I think it will only be confusing things. Given the differences between tpm 1.2 and 2.0 do you think you will be able to maintain this single API? Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervoorn(a)eltan.com W : http://www.eltan.com "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." From: Stefan Berger [mailto:stefanb@us.ibm.com] Sent: Monday, December 21, 2015 5:50 PM To: Kevin O'Connor <kevin(a)koconnor.net> Cc: seabios(a)seabios.org; Wim Vervoorn <wvervoorn(a)eltan.com> Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 "Kevin O'Connor" <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> wrote on 12/17/2015 05:22:56 PM: > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote: > > Hello, > > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS. > > > > All of this work is TPM 1.2 based. I was wondering if there are any > > plans to support TPM 2.0 in the future. > > I'm not aware of any plans. We're working on it... So maybe you have some comments to the following: There will be a patch for probing the TPM TIS hardware interface for whether there's a TPM 1.2 or a TPM 2. We then have a patch for prefixing all TPM 1.2 functions with tpm12_ and then introduce functions like these ones here: static ... tpm12_foo() { ... } static ... tpm2_foo() { ... } tpm_foo() { [...] switch (tpmversion) { case TPM_VERSION_1_2: tpm12_foo() break; case TPM_VERSION_2: tpm2_foo(); break; } [...] } That way the probing will lead us to use either TPM1.2 or TPM 2 specific code. There will be multiple such constructs in tcgbios.c file. Stefan

2 1

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
by Xulei (Stone) Dec. 21, 2015

Dec. 21, 2015

Hi, Kevin, Can you tell how to reset/reboot this VM, if it goes to the handle_hwpic1() on its booting procedure? I mean, usually, SeaBIOS would not go to handle_hwpic routine. But in my test case, SeaBIOS calls handle_hwpic when KVM injects a #UD expcetion (not irq) and SeaBIOS will loop to handle this if KVM persistently injects exception. Now, i just wish to reset/reboot this VM if it is fall into handle_hwpic. I tried follwing patch and it seems not work. What can i do to force reset/reboot? @@ -7,10 +7,11 @@ #include "biosvar.h" // SET_IVT #include "config.h" // CONFIG_* #include "output.h" // dprintf #include "pic.h" // pic_* + #include "hw/ps2port.h" u16 pic_irqmask_read(void) { if (!CONFIG_HARDWARE_IRQ) @@ -103,10 +104,11 @@ pic_isr2_read(void) void VISIBLE16 handle_hwpic1(struct bregs *regs) { dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=%x\n", pic_isr1_read()); pic_eoi1(); + i8042_reboot(); } useful information: kmod ftrace: <...>-31509 [035] 154753.180077: kvm_exit: reason EXCEPTION_NMI rip 0x3 info 0 80000306 <...>-31509 [035] 154753.180077: kvm_emulate_insn: 0:3:f0 53 (real) <...>-31509 [035] 154753.180077: kvm_inj_exception: #UD (0x0) <...>-31509 [035] 154753.180077: kvm_entry: vcpu 0 bad SeaBIOS log: [2015-12-17 12:37:30] In 32bit resume [2015-12-17 12:37:30] =====Attempting a hard reboot==== [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) [2015-12-17 12:37:30] No Xen hypervisor found. [2015-12-17 12:37:30] Running on QEMU (i440fx) [2015-12-17 12:37:30] Running on KVM [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) [2015-12-17 12:37:30] Found QEMU fw_cfg [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] [2015-12-17 12:37:30] Moving pm_base to 0x600 [2015-12-17 12:37:30] boot order: [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 [2015-12-17 12:37:30] 2: HALT [2015-12-17 12:37:30] maininit [2015-12-17 12:37:30] platform_hardware_setup [2015-12-17 12:37:30] init pic [2015-12-17 12:37:30] pic_setup [2015-12-17 12:37:30] pic_reset [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] CPU Mhz=3304 [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] === PCI bus & bridge init === [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 [2015-12-17 12:37:30] === PCI device probing === [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) [2015-12-17 12:37:30] === PCI new allocation pass #1 === [2015-12-17 12:37:30] PCI: check devices [2015-12-17 12:37:30] === PCI new allocation pass #2 === [2015-12-17 12:37:30] PCI: IO: c000 - c02f [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= everytime stuck, AP setup log seems abnormal! [2015-12-17 12:37:30] ièf[cf_^ifd_=f3 [2015-12-17 12:37:30] èf[f^f_f]fÃÍ^XË<90>Found 4 cpu(s) max supported 4 cpu(s) [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 [2015-12-17 12:37:31] Scan for VGA option rom [2015-12-17 12:37:31] Running option rom at c000:0003 [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) [2015-12-17 12:37:31] enter vga_post: [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 [2015-12-17 12:37:31] cirrus init [2015-12-17 12:37:31] cirrus init 2 [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 ... always hanle_hwpic1 irq=0, never ends anymore... >> -----Original Message----- >> From: Kevin O'Connor [mailto:kevin@koconnor.net] >> Sent: Tuesday, December 22, 2015 2:47 AM >> To: Gonglei (Arei) >> Cc: Xulei (Stone); Paolo Bonzini; qemu-devel; seabios(a)seabios.org; >> Huangweidong (C); kvm(a)vger.kernel.org; Radim Krcmar >> Subject: Re: [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy >> problem on qemu-kvm platform >> >> On Mon, Dec 21, 2015 at 09:41:32AM +0000, Gonglei (Arei) wrote: >> > When the gurb of OS is booting, then the softirq and C function >> > send_disk_op() may use extra stack of SeaBIOS. If we inject a NMI, >> > romlayout.S: irqentry_extrastack is invoked, and the extra stack will >> > be used again. And the stack of first calling will be broken, so that the >> SeaBIOS stuck. >> > >> > You can easily reproduce the problem. >> > >> > 1. start on guest >> > 2. reset the guest >> > 3. inject a NMI when the guest show the grub surface 4. then the guest >> > stuck >> >> Does the SeaBIOS patch below help? > >Sorry, it doesn't work. What's worse is we cannot stop SeaBIOS stuck by >Setting "CONFIG_ENTRY_EXTRASTACK=n" after applying this patch. > > >> I'm not familiar with how to "inject a >> NMI" - can you describe the process in more detail? >> > >1. Qemu Command line: > >#: /home/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4096 -smp 8 -name suse -vnc 0.0.0.0:10 \ >-device virtio-scsi-pci,id=scsi0 -drive file=/home/suse11_sp3_32_2,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native \ >-device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \ >-chardev file,id=seabios,path=/home/seabios.log -device isa-debugcon,iobase=0x402,chardev=seabios \ >-monitor stdio -qmp unix:/tmp/qmp,server,nowait > >2. Inject a NMI by QMP: > >#: /home/qemu/scripts/qmp # ./qmp-shell /tmp/qmp >Welcome to the QMP low-level shell! >Connected to QEMU 2.5.0 > >(QEMU) system_reset >{"return": {}} >(QEMU) inject-nmi >{"return": {}} >(QEMU) inject-nmi >{"return": {}} > > >Regards, >-Gonglei > >> -Kevin >> >> >> --- a/src/romlayout.S >> +++ b/src/romlayout.S >> @@ -548,7 +548,9 @@ entry_post: >> ENTRY_INTO32 _cfunc32flat_handle_post // Normal entry point >> >> ORG 0xe2c3 >> - IRQ_ENTRY 02 >> + .global entry_02 >> +entry_02: >> + ENTRY handle_02 // NMI handler does not switch onto extra >> +stack >> >> ORG 0xe3fe >> .global entry_13_official

1 0