- 15 5月, 2018 2 次提交
-
-
由 Geoffrey McRae 提交于
This fixes an issue by adding bounds checking to multi-byte packets where the PS/2 mouse data stream may become corrupted due to data being discarded when the PS/2 ringbuffer is full. Interrupts for Multi-byte responses are postponed until the final byte has been queued. These changes fix a bug where windows guests drop the mouse device entirely requring the guest to be restarted. Signed-off-by: NGeoffrey McRae <geoff@hostfission.com> Message-Id: <20180507150310.2FEA0381924@moya.office.hostfission.com> [ kraxel: codestyle fixes ] Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Geoffrey McRae 提交于
This allows guest's to correctly reinitialize and identify the mouse should the guest decide to re-scan or reset during mouse input events. When the guest sends the "Identify" command, due to the PC's hardware architecutre it is impossible to reliably determine the response from the command amongst other streaming data, such as mouse or keyboard events. Standard practice is for the guest to disable the device and then issue the identify command, so this must be obeyed. Signed-off-by: NGeoffrey McRae <geoff@hostfission.com> Message-Id: <20180507150303.7486B381924@moya.office.hostfission.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 14 5月, 2018 5 次提交
-
-
由 David Hildenbrand 提交于
Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might not be the best idea. As pause_all_vcpus() temporarily drops the qemu mutex, two parallel calls to pause_all_vcpus() can be active at a time, resulting in a deadlock. (either by two VCPUs or by the main thread and a VCPU) Let's handle it via the main loop instead, as suggested by Paolo. If we would have two parallel reset requests by two different VCPUs at the same time, the last one would win. We use the existing ipl device to handle it. The nice side effect is that we can get rid of reipl_requested. This change implies that all reset handling now goes via the common path, so "no-reboot" handling is now active for all kinds of reboots. Let's execute any CPU initialization code on the target CPU using run_on_cpu. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180424101859.10239-1-david@redhat.com> Acked-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
Thomas reported that the subchannel for a 3270 device that ended up in a broken state (status pending even though not enabled) did not get out of that state even after a reboot (which involves a subsytem reset). The reason for this is that the 3270 device did not define a reset handler. Let's fix this by introducing a base reset handler (set up for all ccw devices) that resets the subchannel and have virtio-ccw call its virtio-specific reset procedure in addition to that. CC: qemu-stable@nongnu.org Reported-by: NThomas Huth <thuth@redhat.com> Suggested-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Tested-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NHalil Pasic <pasic@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
All the different virtio ccw devices use the same reset handler, so let's move setting it into the base virtio ccw device class. CC: qemu-stable@nongnu.org Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NHalil Pasic <pasic@linux.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
The 3270 code will try to post an attention interrupt when the 3270 emulator (e.g. x3270) attaches. If the guest has not yet enabled the subchannel for the 3270 device, we will present a spurious cc 1 (status pending) when it uses msch on it later on, e.g. when trying to enable the subchannel. To fix this, just don't do anything in css_conditional_io_interrupt() if the subchannel is not enabled. The 3270 code will work fine with that, and the other user of this function (virtio-ccw) never attempts to post an interrupt for a disabled device to begin with. CC: qemu-stable@nongnu.org Reported-by: NThomas Huth <thuth@redhat.com> Tested-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NHalil Pasic <pasic@linux.ibm.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Thomas Huth 提交于
It's been marked as deprecated since QEMU v2.9.0, so that should have been enough time for everybody to either just drop unnecessary "vlan=0" parameters, to switch to the modern -device + -netdev syntax for connecting guest NICs with host network backends, or to switch to the "hubport" netdev in case hubs are really wanted instead. Buglink: https://bugs.launchpad.net/qemu/+bug/658904Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
- 11 5月, 2018 6 次提交
-
-
由 David Hildenbrand 提交于
If no slots were defined we try to allocate an empty bitmap, which fails. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-Id: <20180427120515.24067-1-david@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Igor Mammedov 提交于
Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1525691524-32265-5-git-send-email-imammedo@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Igor Mammedov 提交于
load_dtb() depends on arm_load_kernel() to figure out place in RAM where it should be loaded, but it's not required for arm_load_kernel() to work. Sometimes it's neccesary for devices added with -device/device_add to be enumerated in DTB as well, which's lead to [1] and surrounding commits to add 2 more machine_done notifiers with non obvious ordering to make dynamic sysbus devices initialization happen in the right order. However instead of moving whole arm_load_kernel() in to machine_done, it's sufficient to move only load_dtb() into virt_machine_done() notifier and remove ArmLoadKernelNotifier/ /PlatformBusFDTNotifierParams notifiers, which saves us ~90LOC and simplifies code flow quite a bit. Later would allow to consolidate DTB generation within one function for 'mach-virt' board and make it reentrant so it could generate updated DTB in device hotplug secenarios. While at it rename load_dtb() to arm_load_dtb() since it's public now. Add additional field skip_dtb_autoload to struct arm_boot_info to allow manual DTB load later in mach-virt and to avoid touching all other boards to explicitly call arm_load_dtb(). 1) (ac9d32e3 hw/arm/boot: arm_load_kernel implemented as a machine init done notifier) Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-id: 1525691524-32265-4-git-send-email-imammedo@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Igor Mammedov 提交于
platform-bus were using machine_done notifier to get and map (assign irq/mmio resources) dynamically added sysbus devices after all '-device' options had been processed. That however creates non obvious dependencies on ordering of machine_done notifiers and requires carefull line juggling to keep it working. For example see comment above create_platform_bus() and 'straitforward' arm_load_kernel() had to converted to machine_done notifier and that lead to yet another machine_done notifier to keep it working arm_register_platform_bus_fdt_creator(). Instead of hiding resource assignment in platform-bus-device to magically initialize sysbus devices, use device plug callback and assign resources explicitly at board level at the moment each -device option is being processed. That adds a bunch of machine declaration boiler plate to e500plat board, similar to ARM/x86 but gets rid of hidden machine_done notifier and would allow to remove the dependent notifiers in ARM code simplifying it and making code flow easier to follow. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-id: 1525691524-32265-3-git-send-email-imammedo@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Igor Mammedov 提交于
By default MachineClass::get_hotplug_handler is NULL and concrete board should set it to it's own handler. Considering there isn't any default handler, drop saving empty MachineClass::get_hotplug_handler in child class and make PC code consistent with spapr/s390x boards. We can bring this back when actual usecase surfaces and do it consistently across boards that use get_hotplug_handler(). Suggested-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Message-id: 1525691524-32265-2-git-send-email-imammedo@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
Coverity (CID1390573) spots that we forgot to free the gpioname strings in a loop in the iotkit realize function. Correct the error. This isn't a significant leak, because this function only ever runs once. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NPeter Xu <peterx@redhat.com> Message-id: 20180427110137.19304-1-peter.maydell@linaro.org
-
- 09 5月, 2018 3 次提交
-
-
由 Daniel P. Berrangé 提交于
The existing QemuOpts parsing code uses a fixed size 1024 byte buffer for storing the option values. If a value exceeded this size it was silently truncated and no error reported to the user. Long option values is not a common scenario, but it is conceivable that they will happen. eg if the user has a very deeply nested filesystem it would be possible to come up with a disk path that was > 1024 bytes. Most of the time if such data was silently truncated, the user would get an error about opening a non-existant disk. If they're unlucky though, QEMU might use a completely different disk image from another VM, which could be considered a security issue. Another example program was in using the -smbios command line arg with very large data blobs. In this case the silent truncation will be providing semantically incorrect data to the guest OS for SMBIOS tables. If the operating system didn't limit the user's argv when spawning QEMU, the code should honour whatever length arguments were given without imposing its own length restrictions. This patch thus changes the code to use a heap allocated buffer for storing the values during parsing, lifting the arbitrary length restriction. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Message-Id: <20180416111743.8473-4-berrange@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 KONRAD Frederic 提交于
The htif device is supposed to be mapped over an other subregion. So increase its priority to one to avoid any conflict. Here is the output of info mtree: Before: (qemu) info mtree address-space: memory 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-000000000000000f (prio 0, i/o): riscv.htif.uart 0000000000000000-0000000000011fff (prio 0, ram): riscv.spike.bootrom 0000000002000000-000000000200ffff (prio 0, i/o): riscv.sifive.clint 0000000080000000-0000000087ffffff (prio 0, ram): riscv.spike.ram address-space: I/O 0000000000000000-000000000000ffff (prio 0, i/o): io address-space: cpu-memory-0 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-000000000000000f (prio 0, i/o): riscv.htif.uart 0000000000000000-0000000000011fff (prio 0, ram): riscv.spike.bootrom 0000000002000000-000000000200ffff (prio 0, i/o): riscv.sifive.clint 0000000080000000-0000000087ffffff (prio 0, ram): riscv.spike.ram After: (qemu) info mtree address-space: memory 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-000000000000000f (prio 1, i/o): riscv.htif.uart 0000000000000000-0000000000011fff (prio 0, ram): riscv.spike.bootrom 0000000002000000-000000000200ffff (prio 0, i/o): riscv.sifive.clint 0000000080000000-0000000087ffffff (prio 0, ram): riscv.spike.ram address-space: I/O 0000000000000000-000000000000ffff (prio 0, i/o): io address-space: cpu-memory-0 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-000000000000000f (prio 1, i/o): riscv.htif.uart 0000000000000000-0000000000011fff (prio 0, ram): riscv.spike.bootrom 0000000002000000-000000000200ffff (prio 0, i/o): riscv.sifive.clint 0000000080000000-0000000087ffffff (prio 0, ram): riscv.spike.ram Reviewed-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NKONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: NMichael Clark <mjc@sifive.com> Message-Id: <1525360636-18229-3-git-send-email-frederic.konrad@adacore.com>
-
由 KONRAD Frederic 提交于
The sanity check on base doesn't allow htif to be mapped @0. Check if the symbol exists instead so we can map it where we want. Reviewed-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NKONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: NMichael Clark <mjc@sifive.com> Message-Id: <1525360636-18229-2-git-send-email-frederic.konrad@adacore.com>
-
- 08 5月, 2018 1 次提交
-
-
由 Greg Kurz 提交于
qemu-system-ppc fails to build with GCC 8.0.1: /home/hsp/src/qemu-master/hw/ppc/e500.c: In function ‘ppce500_load_device_tree’: /home/hsp/src/qemu-master/hw/ppc/e500.c:442:37: error: ‘/pic@’ directive output may be truncated writing 5 bytes into a region of size between 1 and 128 [-Werror=format-truncation=] snprintf(mpic, sizeof(mpic), "%s/pic@%llx", soc, MPC8544_MPIC_REGS_OFFSET); ^~~~~ In file included from /usr/include/stdio.h:862, from /home/hsp/src/qemu-master/include/qemu/osdep.h:68, from /home/hsp/src/qemu-master/hw/ppc/e500.c:17: /usr/include/bits/stdio2.h:64:10: note: ‘__builtin___snprintf_chk’ output between 11 and 138 bytes into a destination of size 128 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/hsp/src/qemu-master/hw/ppc/e500.c:470:39: error: ‘/global-utilities@’ directive output may be truncated writing 18 bytes into a region of size between 1 and 128 [-Werror=format-truncation=] snprintf(gutil, sizeof(gutil), "%s/global-utilities@%llx", soc, ^~~~~~~~~~~~~~~~~~ In file included from /usr/include/stdio.h:862, from /home/hsp/src/qemu-master/include/qemu/osdep.h:68, from /home/hsp/src/qemu-master/hw/ppc/e500.c:17: /usr/include/bits/stdio2.h:64:10: note: ‘__builtin___snprintf_chk’ output between 24 and 151 bytes into a destination of size 128 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/hsp/src/qemu-master/hw/ppc/e500.c:477:36: error: ‘/msi@’ directive output may be truncated writing 5 bytes into a region of size between 0 and 127 [-Werror=format-truncation=] snprintf(msi, sizeof(msi), "/%s/msi@%llx", soc, MPC8544_MSI_REGS_OFFSET); ^~~~~ In file included from /usr/include/stdio.h:862, from /home/hsp/src/qemu-master/include/qemu/osdep.h:68, from /home/hsp/src/qemu-master/hw/ppc/e500.c:17: /usr/include/bits/stdio2.h:64:10: note: ‘__builtin___snprintf_chk’ output between 12 and 139 bytes into a destination of size 128 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by converting e500 to use g_strdup_printf()+g_free() instead of snprintf(). This is done globally, even for call sites that don't break build, since this is the preferred practice in QEMU. Reported-by: NHoward Spoelstra <hsp.cat7@gmail.com> Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NEric Blake <eblake@redhat.com> Message-id: 152568372989.443627.900708381919207053.stgit@bahia.lan Cc: qemu-stable@nongnu.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 07 5月, 2018 14 次提交
-
-
由 David Hildenbrand 提交于
Let's make it clear at relevant places that we are dealing with device memory. That it can be used for memory hotplug is just a special case. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-11-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> [ehabkost: rebased series, solved conflicts at spapr.c] Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
Let's make it clear that we are dealing with device memory. That it can be used for memory hotplug is just a special case. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-10-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
Rename it to better match the new terminology. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-9-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
Registering the memory region for migration has do be done by the owner. There could be cases, where we don't want to migrate the memory. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-8-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
Move the checks into memory_device_get_free_addr(). This will check before doing any calculations if we have KVM/vhost slots left and if the total region size would be exceeded. Of course, while at it, make it independent of pc-dimm code. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-7-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
This mainly moves code, but does a handfull of optimizations: - We pass the machine instead of the address space properties - We check the hinted address directly and handle fragmented memory better - We make the search independent of pc-dimm Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-6-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
We use the machine internally either way, so let's just pass it in then. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-5-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
We can just query it ourselves. When unplugging, we should always be able to the region (as it was previously plugged). E.g. PPC already assumed that and used &error_abort. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-4-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
Let's allow to query the MemoryHotplugState directly from the machine. If the pointer is NULL, the machine does not support memory devices. If the pointer is !NULL, the machine supports memory devices and the data structure contains information about the applicable physical guest address space region. This allows us to generically detect if a certain machine has support for memory devices, and to generically manage it (find free address range, plug/unplug a memory region). We will rename "MemoryHotplugState" to something more meaningful ("DeviceMemory") after we completed factoring out the pc-dimm code into MemoryDevice code. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-3-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> [ehabkost: rebased series, solved conflicts at spapr.c] [ehabkost: squashed fix to use g_malloc0()] Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 David Hildenbrand 提交于
On the qmp level, we already have the concept of memory devices: "query-memory-devices" Right now, we only support NVDIMM and PCDIMM. We want to map other devices later into the address space of the guest. Such device could e.g. be virtio devices. These devices will have a guest memory range assigned but won't be exposed via e.g. ACPI. We want to make them look like memory device, but not glued to pc-dimm. Especially, it will not always be possible to have TYPE_PC_DIMM as a parent class (e.g. virtio devices). Let's use an interface instead. As a first part, convert handling of - qmp_pc_dimm_device_list - get_plugged_memory_size to our new model. plug/unplug stuff etc. will follow later. A memory device will have to provide the following functions: - get_addr(): Necessary, as the property "addr" can e.g. not be used for virtio devices (already defined). - get_plugged_size(): The amount this device offers to the guest as of now. - get_region_size(): Because this can later on be bigger than the plugged size. - fill_device_info(): Fill MemoryDeviceInfo, e.g. for qmp. Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20180423165126.15441-2-david@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Gerd Hoffmann 提交于
Make sure we only ask the spice local renderer for display updates in case we have a valid primary surface. Without that spice is confused and throws errors in case a display update request (triggered by screendump for example) happens in parallel to a mode switch and hits the race window where the old primary surface is gone and the new isn't establisted yet. Cc: qemu-stable@nongnu.org Fixes: https://bugzilla.redhat.com//show_bug.cgi?id=1567733Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20180427115528.345-1-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
usb-host emulates a device unplug after live migration, because the device state is unknown and unplug/replug makes sure the guest re-initializes the device into a working state. This can't be done in post-load though, so post-load just schedules a bottom half which executes after vmload is complete. It can happen that the device autoscan timer hits the race window between scheduling and running the bottom half, which in turn can triggers an assert(). Fix that issue by just ignoring the usb_host_open() call in case the bottom half didn't execute yet. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1572851Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20180503062932.17233-1-kraxel@redhat.com
-
由 Bandan Das 提交于
Currently, it's only being checked if desc is NULL and so write support breaks upon specifying desc Signed-off-by: NBandan Das <bsd@redhat.com> Message-id: 20180503192028.14353-3-bsd@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Bandan Das 提交于
CID 1390578: In usb_mtp_write_metadata, parent can never be NULL but just in case, add an assert CID 1390592: Check for o->format only if o !=NULL CID 1390604: Check s->data_out != NULL in usb_mtp_handle_data Signed-off-by: NBandan Das <bsd@redhat.com> Message-id: 20180503192028.14353-2-bsd@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 06 5月, 2018 7 次提交
-
-
由 Michael Clark 提交于
The sifive_u machine already marks its ROM readonly however it has the wrong base address for its mask ROM. This patch fixes the sifive_u mask ROM base address. This commit makes all other boards consistently use mask_rom as the variable name for their ROMs. Boards that use device tree now check that that the device tree fits in the assigned ROM space using the new qemu_fdt_totalsize(void *fdt) interface, adding a bounds check and error message. This can detect truncation. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Alistair Francis <Alistair.Francis@wdc.com> Signed-off-by: NMichael Clark <mjc@sifive.com> Reviewed-by: NAlistair Francis <Alistair.Francis@wdc.com>
-
由 Michael Clark 提交于
Pointless indirection. Other ports use EM_ constants directly. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
-
由 Michael Clark 提交于
Removes a whole lot of unnecessary boilerplate code. Machines don't need to be objects. The expansion of the SOC object model for the RISC-V machines will happen in the future as SiFive plans to add their FE310 and FU540 SOCs to QEMU. However, it seems that this present boilerplate is complete unnecessary. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
-
由 Michael Clark 提交于
When load_elf is called with NULL as an argument to the address translate callback, it does an identity translation. This commit removes the redundant identity_translate callback. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
-
由 Michael Clark 提交于
Another case of replacing hard coded constants, this time referring to the definition in the virt machine's memmap. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
-
由 Michael Clark 提交于
This makes 'qemu-system-riscv64 -machine help' output more tidy and consistent. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
-
由 Michael Clark 提交于
The RISC-V device-tree code has a number of hard-coded constants and this change moves them into header enums. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: NMichael Clark <mjc@sifive.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com>
-
- 05 5月, 2018 2 次提交
-
-
由 Eric Auger 提交于
ARM virt machine now exposes a new "iommu" option. The SMMUv3 IOMMU is instantiated using -machine virt,iommu=smmuv3. Signed-off-by: NEric Auger <eric.auger@redhat.com> Signed-off-by: NPrem Mallappa <prem.mallappa@broadcom.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 1524665762-31355-15-git-send-email-eric.auger@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Prem Mallappa 提交于
This patch builds the smmuv3 node in the ACPI IORT table. The RID space of the root complex, which spans 0x0-0x10000 maps to streamid space 0x0-0x10000 in smmuv3, which in turn maps to deviceid space 0x0-0x10000 in the ITS group. The guest must feature the IOMMU probe deferral series (https://lkml.org/lkml/2017/4/10/214) which fixes streamid multiple lookup. This bug is not related to the SMMU emulation. Signed-off-by: NPrem Mallappa <prem.mallappa@broadcom.com> Signed-off-by: NEric Auger <eric.auger@redhat.com> Reviewed-by: NShannon Zhao <zhaoshenglong@huawei.com> Message-id: 1524665762-31355-14-git-send-email-eric.auger@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-