-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cortex-M3 patch #2
base: master
Are you sure you want to change the base?
Conversation
Thanks Ryos! Could you please add a Signed-off-by line on the commit message and also add a comment in the code describing what the bit masking/unmasking is actually doing? Thanks again! |
Signed-off-by: Ryos Suzuki <ryos@sinby.com>
Hi, Here is the patch. Is it OK?
diff --git a/target-arm/helper.c b/target-arm/helper.c
|
On Wed, Jul 11, 2012 at 09:38:25PM -0700, Ryos Suzuki wrote:
Hi, Sorry for the delay. The patch looks OK. I'm currently traveling thanks,
|
On Wed, Jul 11, 2012 at 09:38:25PM -0700, Ryos Suzuki wrote:
Hi, Sorry for the delays, I've been travelling for a while. Thanks for the updated patch. An easy way to check for patch style correctness is to use git show | ./scripts/checkpatch.pl - I've comitted the following: commit 234773d
diff --git a/target-arm/helper.c b/target-arm/helper.c
|
The comment is wrong, we have to do something in the setdata callback. Changing the framebuffer backing storage (happens when the guest pans the display) renders the whole screen content invalid. Trigger #1: cirrus vga + 32bit linux guest + vesafb with ypan enabled. Trigger edgarigl#2: std vga + http://patchwork.ozlabs.org/patch/145479/ Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Step edgarigl#2 (separate for better bisectability): renumber so the silly '-1' goes away. Pick a range which doesn't overlap the old values. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit 4be2393 makes ehci instantly zap any unlinked queue heads when the guest rings the doorbell. While hacking up uas support this turned out to be a problem. The linux kernel can unlink and instantly relink the very same queue head, thereby killing any async packets in flight. That alone isn't an issue yet, the packet will canceled and resubmitted and everything is fine. We'll run into trouble though in case the async packet is completed already, so we can't cancel it any more. The transaction is simply lost then. usb_ehci_qh_ptrs q (nil) - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000 usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0 usb_ehci_qh_ptrs q 0x7f95feba90a0 - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000 usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0 usb_ehci_qh_ptrs q 0x7f95fe515210 - QH @ 39c4f120: next 39c4f0c2 qtds 29dbce40,29dbc4e0,00000009 usb_ehci_qh_fields QH @ 39c4f120 - rl 4, mplen 512, eps 2, ep 1, dev 2 usb_ehci_packet_action q 0x7f95fe515210 p 0x7f95fdec32a0: alloc usb_packet_state_change bus 0, port 2, ep 1, packet 0x7f95fdec32e0, state undef -> setup usb_ehci_packet_action q 0x7f95fe515210 p 0x7f95fdec32a0: process usb_uas_command dev 2, tag 0x2, lun 0, lun64 00000000-00000000 scsi_req_parsed target 0 lun 0 tag 2 command 42 dir 2 length 16384 scsi_req_parsed_lba target 0 lun 0 tag 2 command 42 lba 5933312 scsi_req_alloc target 0 lun 0 tag 2 scsi_req_continue target 0 lun 0 tag 2 scsi_req_data target 0 lun 0 tag 2 len 16384 usb_uas_scsi_data dev 2, tag 0x2, bytes 16384 usb_uas_write_ready dev 2, tag 0x2 usb_packet_state_change bus 0, port 2, ep 1, packet 0x7f95fdec32e0, state setup -> complete usb_ehci_packet_action q 0x7f95fe515210 p 0x7f95fdec32a0: free usb_ehci_qh_ptrs q 0x7f95fdec3210 - QH @ 39c4f0c0: next 39c4f002 qtds 29dbce40,00000001,00000009 usb_ehci_qh_fields QH @ 39c4f0c0 - rl 4, mplen 512, eps 2, ep 2, dev 2 usb_ehci_queue_action q 0x7f95fe5152a0: free usb_packet_state_change bus 0, port 2, ep 2, packet 0x7f95feba9170, state async -> complete ^^^ async packets completes. usb_ehci_packet_action q 0x7f95fdec3210 p 0x7f95feba9130: wakeup usb_ehci_qh_ptrs q (nil) - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000 usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0 usb_ehci_qh_ptrs q 0x7f95feba90a0 - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000 usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0 usb_ehci_qh_ptrs q 0x7f95fe515210 - QH @ 39c4f120: next 39c4f002 qtds 29dbc4e0,29dbc8a0,00000009 usb_ehci_qh_fields QH @ 39c4f120 - rl 4, mplen 512, eps 2, ep 1, dev 2 usb_ehci_queue_action q 0x7f95fdec3210: free usb_ehci_packet_action q 0x7f95fdec3210 p 0x7f95feba9130: free ^^^ endpoint edgarigl#2 queue head removed from schedule, doorbell makes ehci zap the queue, the (completed) usb packet is freed too and gets lost. usb_ehci_qh_ptrs q (nil) - QH @ 39c4f000: next 39c4f0c2 qtds 00000000,00000001,39c50000 usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0 usb_ehci_qh_ptrs q 0x7f95feba90a0 - QH @ 39c4f000: next 39c4f0c2 qtds 00000000,00000001,39c50000 usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0 usb_ehci_queue_action q 0x7f9600dff570: alloc usb_ehci_qh_ptrs q 0x7f9600dff570 - QH @ 39c4f0c0: next 39c4f122 qtds 29dbce40,00000001,00000009 usb_ehci_qh_fields QH @ 39c4f0c0 - rl 4, mplen 512, eps 2, ep 2, dev 2 usb_ehci_packet_action q 0x7f9600dff570 p 0x7f95feba9130: alloc usb_packet_state_change bus 0, port 2, ep 2, packet 0x7f95feba9170, state undef -> setup usb_ehci_packet_action q 0x7f9600dff570 p 0x7f95feba9130: process usb_packet_state_change bus 0, port 2, ep 2, packet 0x7f95feba9170, state setup -> async usb_ehci_packet_action q 0x7f9600dff570 p 0x7f95feba9130: async ^^^ linux kernel relinked the queue head, ehci creates a new usb packet, but we should have delivered the completed one instead. usb_ehci_qh_ptrs q 0x7f95fe515210 - QH @ 39c4f120: next 39c4f002 qtds 29dbc4e0,29dbc8a0,00000009 usb_ehci_qh_fields QH @ 39c4f120 - rl 4, mplen 512, eps 2, ep 1, dev 2 So instead of instantly zapping the queue we'll set a flag that the queue needs revalidation in case we'll see it again in the schedule. ehci then checks that the queue head fields addressing / describing the endpoint and the qtd pointer match the cached content before reusing it. Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
$ ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -drive if=none,id=drive0,cache=none,aio=native,format=raw,file=/root/Image/centos-6.4.raw -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on # make dataplane fail to initialize qemu-system-x86_64: -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on: device is incompatible with x-data-plane, use config-wce=off *** glibc detected *** /root/usr/bin/qemu-system-x86_64: free(): invalid pointer: 0x00007f001fef12f8 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7d776)[0x7f00153a5776] /root/usr/bin/qemu-system-x86_64(+0x2c34ec)[0x7f001cf5b4ec] /root/usr/bin/qemu-system-x86_64(+0x342f9a)[0x7f001cfdaf9a] /root/usr/bin/qemu-system-x86_64(+0x33694e)[0x7f001cfce94e] .................... (gdb) bt #0 0x00007f3bf3a12015 in raise () from /lib64/libc.so.6 #1 0x00007f3bf3a1348b in abort () from /lib64/libc.so.6 #2 0x00007f3bf3a51a4e in __libc_message () from /lib64/libc.so.6 #3 0x00007f3bf3a57776 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007f3bfb60d4ec in free_and_trace (mem=0x7f3bfe0129f8) at vl.c:2786 #5 0x00007f3bfb68cf9a in virtio_cleanup (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:900 #6 0x00007f3bfb68094e in virtio_blk_device_init (vdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio-blk.c:666 #7 0x00007f3bfb68dadf in virtio_device_init (qdev=0x7f3bfe0129f8) at /root/Develop/QEMU/qemu/hw/virtio.c:1092 #8 0x00007f3bfb50da46 in device_realize (dev=0x7f3bfe0129f8, err=0x7fff479c9258) at hw/qdev.c:176 ............................. In virtio_blk_device_init(), the memory which vdev point to is a static member of "struct VirtIOBlkPCI", not heap memory, and it does not get freed. So we shoule use virtio_common_cleanup() to clean this VirtIODevice rather than virtio_cleanup(), which attempts to free the vdev. This error was introduced by commit 05ff686 recently. Signed-off-by: Dunrong Huang <huangdr@cloud-times.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Use of a flash memory device for the BIOS was added in series "[PATCH v10 0/8] PC system flash support", commit 4732dca..1b89faf, v1.1. Flash vs. ROM is a guest-visible difference. Thus, flash use had to be suppressed for machine types pc-1.0 and older. This was accomplished by adding a dummy device "pc-sysfw" with property "rom_only": * Non-zero rom_only means "use ROM". Default for pc-1.0 and older. * Zero rom_only means "maybe use flash". Default for newer machines. Not only is the dummy device ugly, it was also retroactively added to the older machine types! Fortunately, it's not guest-visible (thus no immediate guest ABI breakage), and has no vmstate (thus no immediate migration breakage). Breakage occurs only if the user unwisely enables flash by setting rom_only to zero. Patch review FAIL #1. Why "maybe use flash"? Flash didn't (and still doesn't) work with KVM. Therefore, rom_only=0 really means "use flash, except when KVM is enabled, use ROM". This is a Bad Idea, because it makes enabling/ disabling KVM guest-visible. Patch review FAIL #2. Aside: it also precludes migrating between KVM on and off, but that's not possible for other reasons anyway. Fix as follows: 1. Change the meaning of rom_only=0 to mean "use flash, no ifs, buts, or maybes" for pc-i440fx-1.5 and pc-q35-1.5. Don't change anything for older machines (to remain bug-compatible). 2. Change the default value from 0 to 1 for these machines. Necessary, because 0 doesn't work with KVM. Once it does, we can flip the default back to 0. 3. Don't revert the retroactive addition of device "pc-sysfw" to older machine types. Seems not worth the trouble. 4. Add a TODO comment asking for device "pc-sysfw" to be dropped once flash works with KVM. Net effect is that you get a BIOS ROM again even when KVM is disabled, just like for machines predating the introduction of flash. To get flash instead, use "--global pc-sysfw.rom_only=0". Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-id: 1365780303-26398-4-git-send-email-armbru@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Fix the CBAR initialisation by using the newly defined static property. CBAR is now set before realization, so the intended value is now actually used. So I have kind of tested this. I booted an ARM kernel on Highbank with the stock Highbank DTB. It doesn't boot (and I will be doing something wrong), but before this patch I got this: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at /workspaces/pcrost/public/linux2.git/arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0x180/0x198() CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.13.0-rc1-next-20131126-dirty #2 [<c0015164>] (unwind_backtrace) from [<c00118c0>] (show_stack+0x10/0x14) [<c00118c0>] (show_stack) from [<c02bd5fc>] (dump_stack+0x78/0x90) [<c02bd5fc>] (dump_stack) from [<c001f110>] (warn_slowpath_common+0x68/0x84) [<c001f110>] (warn_slowpath_common) from [<c001f1f4>] (warn_slowpath_null+0x1c/0x24) [<c001f1f4>] (warn_slowpath_null) from [<c0017c6c>] (__arm_ioremap_pfn_caller+0x180/0x198) [<c0017c6c>] (__arm_ioremap_pfn_caller) from [<c0017cd8>] (__arm_ioremap_caller+0x54/0x5c) [<c0017cd8>] (__arm_ioremap_caller) from [<c0017d10>] (__arm_ioremap+0x18/0x1c) [<c0017d10>] (__arm_ioremap) from [<c03913c0>] (highbank_init_irq+0x34/0x8c) [<c03913c0>] (highbank_init_irq) from [<c038c228>] (init_IRQ+0x28/0x2c) [<c038c228>] (init_IRQ) from [<c03899ec>] (start_kernel+0x234/0x398) [<c03899ec>] (start_kernel) from [<00008074>] (0x8074) ---[ end trace 3406ff24bd97382f ]--- Which disappears with this patch. Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: fedec366aaa512d75093635f523d1dbcb3358361.1387160489.git.peter.crosthwaite@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The trace-events "disable" keyword turns an event into a nop at compile-time. This is important for high-frequency events that can impact performance. The "disable" keyword is currently broken in the simple trace backend. This patch fixes the problem as follows: Trace events are identified by their TraceEventID number. When events are disabled there are two options for assigning TraceEventID numbers: 1. Skip disabled events and don't assign them a number. 2. Assign numbers for all events regardless of the disabled keyword. The simple trace backend and its binary file format uses approach #1. The tracetool infrastructure has been using approach #2 for a while. The result is that the numbers used in simple trace files do not correspond with TraceEventIDs. In trace/simple.c we assumed that they are identical and therefore emitted bogus numbers. This patch fixes the bug by using TraceEventID for trace_event_id() while sticking to approach #1 for simple trace file numbers. This preserves simple trace file format compatibility. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
As reported in http://article.gmane.org/gmane.comp.emulators.qemu/253987 Mac OSX actually requires describing all occupied slots in ACPI - even if hotplug isn't enabled. I didn't expect this so I dropped description of all non hotpluggable slots from ACPI. As a result: before commit 99fd437 (enable hotplug for pci bridges), PCI cards show up in the "device tree" of OS X (System Information). E.g., on MountainLion users have: Hardware -> PCI Cards: Card Type Driver Installed Slot *ethernet Ethernet Controller Yes PCI Slot 2 pci8086,2934 USB UHC Yes PCI Slot 29 ethernet: Type: Ethernet Controller Driver Installed: Yes MSI: No Bus: PCI Slot PCI Slot 2 Vendor ID: 0x8086 Device ID: 0x100e Subsystem Vendor ID: 0x1af4 Subsystem ID: 0x1100 Revision ID: 0x0003 Hardware -> Ethernet Cards ethernet: Type: Ethernet Controller Bus: PCI Slot PCI Slot 2 Vendor ID: 0x8086 Device ID: 0x100e Subsystem Vendor ID: 0x1af4 Subsystem ID: 0x1100 Revision ID: 0x0003 BSD name: en0 Kext name: AppleIntel8254XEthernet.kext Location: /System/Library/Extensions/... Version: 3.1.1b1 After commit 99fd437, users get: Hardware -> PCI Cards: This computer doesn't contain any PCI cards. If you installed PCI cards, make sure they're properly installed. Hardware -> Ethernet Cards ethernet: Type: Ethernet Controller Bus: PCI Vendor ID: 0x8086 Device ID: 0x100e Subsystem Vendor ID: 0x1af4 Subsystem ID: 0x1100 Revision ID: 0x0003 BSD name: en0 Kext name: AppleIntel8254XEthernet.kext Location: /System/Library/Extensions/... Version: 3.1.1b1 Ethernet still works, but it's not showing up on the PCI bus, and it no longer thinks it's plugged in to slot #2, as it used to before the change. To fix, append description for all occupied non hotpluggable PCI slots. One need to be careful when doing this: VGA devices are now described in SSDT, so we need to drop description from DSDT. And ISA devices are used in DSDT so drop them from SSDT. Reported-by: Gabriel L. Somlo <gsomlo@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Also update generated dsdt and pcihp hex dump files. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There are currently three types of object_property_add_link() callers: 1. The link property may be set at any time. 2. The link property of a DeviceState instance may only be set before realize. 3. The link property may never be set, it is read-only. Something similar can already be achieved with object_property_add_str()'s set() argument. Follow its example and add a check() argument to object_property_add_link(). Also provide default check() functions for case #1 and #2. Case #3 is covered by passing a NULL function pointer. Cc: Peter Crosthwaite <peter.crosthwaite@petalogix.com> Cc: Alexander Graf <agraf@suse.de> Cc: Anthony Liguori <aliguori@amazon.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> [AF: Tweaked documentation comment] Signed-off-by: Andreas Färber <afaerber@suse.de>
Otherwise, the index of an input device like a usb-kbd is silently accepted. (qemu) info mice Mouse #2: QEMU PS/2 Mouse * Mouse #3: QEMU HID Mouse (qemu) mouse_set 1 (qemu) info mice Mouse #2: QEMU PS/2 Mouse * Mouse #3: QEMU HID Mouse Also replace monitor_printf() call in do_mouse_set() with error_report() and adjust error message. Signed-off-by: Hani Benhabiles <hani@linux.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
A few more cleanups for .gitignore file. The final goal is to have only files in there which are generated during build. Things like .orig or .gdbinit are definitely not generated during build. Also, anchor a few more build-time directories. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
…4-28' into staging trivial patches for 2014-04-28 # gpg: Signature made Mon 28 Apr 2014 05:56:01 BST using RSA key ID A4C3D7DB # gpg: Good signature from "Michael Tokarev <mjt@tls.msk.ru>" # gpg: aka "Michael Tokarev <mjt@corpit.ru>" # gpg: aka "Michael Tokarev <mjt@debian.org>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 # Subkey fingerprint: 6F67 E18E 7C91 C5B1 5514 66A7 BEE5 9D74 A4C3 D7DB * remotes/mjt/tags/trivial-patches-2014-04-28: slirp/smb: Move ncalrpc directory to tmp po: add proper Language: tags to .po files po/Makefile: fix $SRC_PATH reference init_paths: fix minor memory leak virtfs-proxy-helper: fix call to accept net/net.c: remove unnecessary semicolon Add QEMU logo (SVG file) vl: avoid closing stdout with 'writeconfig' xilinx: Fix typo in comment (Marvel -> Marvell) vl: Eliminate a superfluous local variable vl: Remove useless 'continue' gitignore: cleanups #2 tests/.gitignore: Ignore test-rfifolock move test-* from .gitignore to tests/.gitignore configure: Improve help behavior vl: convert -m to QemuOpts qemu-option: introduce qemu_find_opts_singleton misc: Use cpu_physical_memory_read and cpu_physical_memory_write Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The docs for glfs_init suggest that the function sets errno on every failure. In fact it doesn't. As other functions such as qemu_gluster_open() in the gluster block code report their errors based on this fact we need to make sure that errno is set on each failure. This fixes a crash of qemu-img/qemu when a gluster brick isn't accessible from given host while the server serving the volume description is. Thread 1 (Thread 0x7ffff7fba740 (LWP 203880)): #0 0x00007ffff77673f8 in glfs_lseek () from /usr/lib64/libgfapi.so.0 #1 0x0000555555574a68 in qemu_gluster_getlength () #2 0x0000555555565742 in refresh_total_sectors () #3 0x000055555556914f in bdrv_open_common () #4 0x000055555556e8e8 in bdrv_open () #5 0x000055555556f02f in bdrv_open_image () #6 0x000055555556e5f6 in bdrv_open () #7 0x00005555555c5775 in bdrv_new_open () #8 0x00005555555c5b91 in img_info () #9 0x00007ffff62c9c05 in __libc_start_main () from /lib64/libc.so.6 #10 0x00005555555648ad in _start () Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
If libusb_get_device_list() fails, the uninitialized local variable libusb_device would be passed to libusb_free_device_list(), that will cause a crash, like: (gdb) bt #0 0x00007fbbb4bafc10 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00007fbbb233e653 in libusb_unref_device (dev=0x6275682d627375) at core.c:902 #2 0x00007fbbb233e739 in libusb_free_device_list (list=0x7fbbb6e8436e, unref_devices=<optimized out>) at core.c:653 #3 0x00007fbbb6cd80a4 in usb_host_auto_check (unused=unused@entry=0x0) at hw/usb/host-libusb.c:1446 #4 0x00007fbbb6cd8525 in usb_host_initfn (udev=0x7fbbbd3c5670) at hw/usb/host-libusb.c:912 #5 0x00007fbbb6cc123b in usb_device_init (dev=0x7fbbbd3c5670) at hw/usb/bus.c:106 ... So initialize libusb_device at the begin time. Signed-off-by: Jincheng Miao <jmiao@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
VirtIOBlockReq is freed later by virtio_blk_free_request() in hw/block/virtio-blk.c. Remove this extraneous g_slice_free(). This patch fixes the following segfault: 0x00005555556373af in virtio_blk_rw_complete (opaque=0x5555565ff5e0, ret=0) at hw/block/virtio-blk.c:99 99 bdrv_acct_done(req->dev->bs, &req->acct); (gdb) print req $1 = (VirtIOBlockReq *) 0x5555565ff5e0 (gdb) print req->dev $2 = (VirtIOBlock *) 0x0 (gdb) bt #0 0x00005555556373af in virtio_blk_rw_complete (opaque=0x5555565ff5e0, ret=0) at hw/block/virtio-blk.c:99 #1 0x0000555555840ebe in bdrv_co_em_bh (opaque=0x5555566152d0) at block.c:4675 #2 0x000055555583de77 in aio_bh_poll (ctx=ctx@entry=0x5555563a8150) at async.c:81 #3 0x000055555584b7a7 in aio_poll (ctx=0x5555563a8150, blocking=blocking@entry=true) at aio-posix.c:188 #4 0x00005555556e520e in iothread_run (opaque=0x5555563a7fd8) at iothread.c:41 #5 0x00007ffff42ba124 in start_thread () from /usr/lib/libpthread.so.0 #6 0x00007ffff16d14bd in clone () from /usr/lib/libc.so.6 Reported-by: Max Reitz <mreitz@redhat.com> Cc: Fam Zheng <famz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
If the pci bridge enters in error flow as part of init process it will only delete the shpc mmio subregion but not remove it from the properties list, resulting in segmentation fault when the bridge runs the exit function. Example: add a pci bridge without specifing the chassis number: <qemu-bin> ... -device pci-bridge,id=p1 Result: (qemu) qemu-system-x86_64: -device pci-bridge,id=p1: Bridge chassis not specified. Each bridge is required to be assigned a unique chassis id > 0. qemu-system-x86_64: -device pci-bridge,id=p1: Device initialization failed. Segmentation fault (core dumped) if (child->class->unparent) { #0 0x00005555558d629b in object_finalize_child_property (obj=0x555556d2e830, name=0x555556d30630 "shpc-mmio[0]", opaque=0x555556a42fc8) at qom/object.c:1078 #1 0x00005555558d4b1f in object_property_del_all (obj=0x555556d2e830) at qom/object.c:367 #2 0x00005555558d4ca1 in object_finalize (data=0x555556d2e830) at qom/object.c:412 #3 0x00005555558d55a1 in object_unref (obj=0x555556d2e830) at qom/object.c:720 #4 0x000055555572c907 in qdev_device_add (opts=0x5555563544f0) at qdev-monitor.c:566 #5 0x0000555555744f16 in device_init_func (opts=0x5555563544f0, opaque=0x0) at vl.c:2213 #6 0x00005555559cf5f0 in qemu_opts_foreach (list=0x555555e0f8e0 <qemu_device_opts>, func=0x555555744efa <device_init_func>, opaque=0x0, abort_on_failure=1) at util/qemu-option.c:1057 #7 0x000055555574a11b in main (argc=16, argv=0x7fffffffdde8, envp=0x7fffffffde70) at vl.c:423 Unparent the shpc mmio region as part of shpc cleanup. Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Amos Kong <akong@redhat.com>
Hi,
This is Cortex-M3 patch for tlmu/QEMU.