- 26 4月, 2018 13 次提交
-
-
由 Peter Maydell 提交于
Following commit 12051d82, UART devices should handle being passed a NULL pointer chardev, so we don't need to create "null" backends in board code. Remove the code that does this and updates serial_hds[]. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NThomas Huth <thuth@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180420145249.32435-6-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Following commit 12051d82, UART devices should handle being passed a NULL pointer chardev, so we don't need to create "null" backends in board code. Remove the code that does this and updates serial_hds[]. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NThomas Huth <thuth@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180420145249.32435-5-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Following commit 12051d82, UART devices should handle being passed a NULL pointer chardev, so we don't need to create "null" backends in board code. Remove the code that does this and updates serial_hds[]. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NThomas Huth <thuth@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180420145249.32435-4-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Following commit 12051d82, UART devices should handle being passed a NULL pointer chardev, so we don't need to create "null" backends in board code. Remove the code that does this and updates serial_hds[]. (fsl-imx7.c was already written this way.) Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-id: 20180420145249.32435-3-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Currently the serial.c realize code has an explicit check that it is not connected to a disconnected backend (ie one with a NULL chardev). This isn't what we want -- you should be able to create a serial device even if it isn't attached to anything. Remove the check. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: NThomas Huth <thuth@redhat.com> Message-id: 20180420145249.32435-2-peter.maydell@linaro.org
-
由 Sai Pavan Boddu 提交于
SNOOP_NONE state handle is moved above in the if ladder, as it's same as SNOOP_STRIPPING during data cycles. Signed-off-by: NSai Pavan Boddu <saipava@xilinx.com> Reviewed-by: NFrancisco Iglesias <frasse.iglesias@gmail.com> Message-id: 1524119244-1240-1-git-send-email-saipava@xilinx.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Cédric Le Goater 提交于
commit 1d3e65aa ("hw/timer: Add value matching support to aspeed_timer") increased the vmstate version of aspeed.timer because the state had changed, but it also bumped the version of the VMSTATE_STRUCT_ARRAY under the aspeed.timerctrl which did not need to. Change back this version to fix migration. Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-id: 20180423101433.17759-1-clg@kaod.org Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
Currently we use vmstate_register_ram_global() for the SRAM; this is not a good idea for devices, because it means that you can only ever create one instance of the device, as the second instance would get a RAM block name clash. Instead, use memory_region_init_ram(), which automatically registers the RAM block with a local-to-the-device name. Note that this would be a cross-version migration compatibility break for the "palmetto-bmc", "ast2500-evb" and "romulus-bmc" machines, but migration is currently broken for them. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NCédric Le Goater <clg@kaod.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20180420124835.7268-4-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Currently we use memory_region_init_ram_nomigrate() to create the "aspeed.boot_rom" memory region, and we don't manually register it with vmstate_register_ram(). This currently means that its contents are migrated but as a ram block whose name is the empty string; in future it may mean they are not migrated at all. Use memory_region_init_ram() instead. Note that would be a cross-version migration compatibility break for the "palmetto-bmc", "ast2500-evb" and "romulus-bmc" machines, but migration is currently broken for them. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NCédric Le Goater <clg@kaod.org> Tested-by: NCédric Le Goater <clg@kaod.org> Message-id: 20180420124835.7268-3-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Currently we use memory_region_init_ram_nomigrate() to create the "highbank.sysram" memory region, and we don't manually register it with vmstate_register_ram(). This currently means that its contents are migrated but as a ram block whose name is the empty string; in future it may mean they are not migrated at all. Use memory_region_init_ram() instead. Note that this is a cross-version migration compatibility break for the "highbank" and "midway" machines. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 20180420124835.7268-2-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
In commit 210f4784, we changed the bcm2836 SoC object to always create a CPU of the correct type for that SoC model. This makes the default_cpu_type settings in the MachineClass structs for the raspi2 and raspi3 boards redundant. We didn't change those at the time because it would have meant a temporary regression in a corner case of error handling if the user requested a non-existing CPU type. The -cpu parse handling changes in 2278b939 mean that it no longer implicitly depends on default_cpu_type for this to work, so we can now delete the redundant default_cpu_type fields. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180420155547.9497-1-peter.maydell@linaro.org
-
由 Aaron Lindsay 提交于
This eliminates the need for fetching it from el_change_hook_opaque, and allows for supporting multiple el_change_hooks without having to hack something together to find the registered opaque belonging to GICv3. Signed-off-by: NAaron Lindsay <alindsay@codeaurora.org> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 1523997485-1905-6-git-send-email-alindsay@codeaurora.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Igor Mammedov 提交于
if arm_load_kernel() were passed non first_cpu, QEMU would end up with partially set do_cpu_reset() callback leaving some CPUs without it. Make sure that do_cpu_reset() is registered for all CPUs by enumerating CPUs from first_cpu. (In practice every board that we have was passing us the first CPU as the boot CPU, either directly or indirectly, so this wasn't causing incorrect behaviour.) Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> [PMM: added a note that this isn't a behaviour change] Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 17 4月, 2018 1 次提交
-
-
由 Jason Wang 提交于
When IOMMU is enabled, we store virtqueue metadata as iova (though it may has _phys suffix) and access them through dma helpers. Any translation failures could be reported by IOMMU. In this case, trying to validate iova against gpa won't work and will cause a false error reporting. So this patch bypasses the ring verification if IOMMU is enabled which is similar to the behavior before 0ca1fd2d that calls vhost_memory_map() which is a nop when IOMMU is enabled. Fixes: 0ca1fd2d ("vhost: Simplify ring verification checks") Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 12 4月, 2018 1 次提交
-
-
由 Peter Maydell 提交于
The CMSDK APB UART INTSTATUS register bits are all write-one-to-clear. We were getting this correct for the TXO and RXO bits (which need special casing because their state lives in the STATE register), but had forgotten to handle the normal bits for RX and TX which we do store in our s->intstatus field. Perform the W1C operation on the bits in s->intstatus too. Fixes: https://bugs.launchpad.net/qemu/+bug/1760262 Cc: qemu-stable@nongnu.org Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 20180410134203.17552-1-peter.maydell@linaro.org
-
- 11 4月, 2018 1 次提交
-
-
由 Pavel Dovgalyuk 提交于
In icount mode, instructions that access io memory spaces in the middle of the translation block invoke TB recompilation. After recompilation, such instructions become last in the TB and are allowed to access io memory spaces. When the code includes instruction like i386 'xchg eax, 0xffffd080' which accesses APIC, QEMU goes into an infinite loop of the recompilation. This instruction includes two memory accesses - one read and one write. After the first access, APIC calls cpu_report_tpr_access, which restores the CPU state to get the current eip. But cpu_restore_state_from_tb resets the cpu->can_do_io flag which makes the second memory access invalid. Therefore the second memory access causes a recompilation of the block. Then these operations repeat again and again. This patch moves resetting cpu->can_do_io flag from cpu_restore_state_from_tb to cpu_loop_exit* functions. It also adds a parameter for cpu_restore_state which controls restoring icount. There is no need to restore icount when we only query CPU state without breaking the TB. Restoring it in such cases leads to the incorrect flow of the virtual time. In most cases new parameter is true (icount should be recalculated). But there are two cases in i386 and openrisc when the CPU state is only queried without the need to break the TB. This patch fixes both of these cases. Signed-off-by: NPavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Message-Id: <20180409091320.12504.35329.stgit@pasha-VirtualBox> [rth: Make can_do_io setting unconditional; move from cpu_exec; make cpu_loop_exit_{noexc,restore} call cpu_loop_exit.] Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
-
- 10 4月, 2018 15 次提交
-
-
由 Philippe Mathieu-Daudé 提交于
ASAN reported: hw/block/pflash_cfi02.c:245:33: runtime error: index 82 out of bounds for type 'uint8_t [82]' Since the 'cfi_len' member is not used, remove it to keep the code safer. Cc: qemu-stable@nongnu.org Reported-by: AddressSanitizer Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Thomas Huth 提交于
QEMU currently exits unexpectedly when trying to introspect the fsl-imx6 and fsl-imx7 devices on systems with many SMP CPUs: $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'fsl,imx6'}}" \ | arm-softmmu/qemu-system-arm -M virt,accel=qtest -qmp stdio -smp 8 {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} fsl,imx6: Only 4 CPUs are supported (8 requested) And: $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'fsl,imx7'}}" \ | arm-softmmu/qemu-system-arm -M raspi2,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} fsl,imx7: Only 2 CPUs are supported (4 requested) This happens because these devices are doing an exit() from their instance_init function - which should never be done since instance_init can be called at any time for device introspection! Fix it by moving the deadly check into the realize() function instead. Signed-off-by: NThomas Huth <thuth@redhat.com> Message-id: 1522908551-14885-1-git-send-email-thuth@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Thomas Huth 提交于
The instance_init function of a device can be called at any time, even if the device is not going to be used (i.e. not going to be realized). So a instance_init function must not do things that could cause QEMU to exit, like calling qemu_check_nic_model(&nd_table[0], ...) for example. But this is what the instance_init function of the allwinner-a10 device is currently doing - and this causes QEMU to quit unexpectedly when you run the 'device-list-properties' QMP command for example: $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'allwinner-a10'}}" \ | arm-softmmu/qemu-system-arm -M mps2-an505,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} Unsupported NIC model: lan9118 ... and QEMU quits after printing the last line (which should not happen just because of running 'device-list-properties' here). And with the cubieboard, this even causes QEMU to abort(): $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'allwinner-a10'}}" \ | arm-softmmu/qemu-system-arm -M cubieboard,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} Unexpected error in error_set_from_qdev_prop_error() at hw/core/qdev-properties.c:1095: Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use Aborted (core dumped) To fix the problem we've got to move the offending code to the realize function instead. Signed-off-by: NThomas Huth <thuth@redhat.com> Message-id: 1522862420-7484-1-git-send-email-thuth@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
The Linux bcm2835_sdhost driver doesn't work on QEMU, because our model raises spurious data interrupts. Our function bcm2835_sdhost_fifo_run() will flag an interrupt any time it is called with s->datacnt == 0, even if the host hasn't actually issued a data read or write command yet. This means that the driver gets a spurious data interrupt as soon as it enables IRQs and then does something else that causes us to call the fifo_run routine, like writing to SDHCFG, and before it does the write to SDCMD to issue the read. The driver's IRQ handler then spins forever complaining that there's no data and the SD controller isn't in a state where there's going to be any data: [ 41.040738] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts 00000000 [ 41.042059] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts 00000000 (continues forever). Move the interrupt flag setting to more plausible places: * for BUSY, raise this as soon as a BUSYWAIT command has executed * for DATA, raise this when the FIFO has any space free (for a write) or any data in it (for a read) * for BLOCK, raise this when the data count is 0 and we've actually done some reading or writing This is pure guesswork since the documentation for this hardware is not public, but it is sufficient to get the Linux bcm2835_sdhost driver to work. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20180319161556.16446-3-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Add some tracepoints to the bcm2835_sdhost driver, to assist debugging. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20180319161556.16446-2-peter.maydell@linaro.org
-
由 Thomas Huth 提交于
An instance_init function must not fail - and might be called multiple times, e.g. during device introspection with the 'device-list-properties' QMP command. Since the integratorcm device ignores this rule, QEMU currently aborts in this case (though it really should not): echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ "'arguments':{'typename':'integrator_core'}}" \ | arm-softmmu/qemu-system-arm -M integratorcp,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} RAMBlock "integrator.flash" already registered, abort! Aborted (core dumped) Move the problematic code to the realize() function instead to fix this problem. Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NThomas Huth <thuth@redhat.com> Message-id: 1522906473-11252-1-git-send-email-thuth@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrey Smirnov 提交于
Change the code to avoid exiting QEMU if user provided DTB contains manually specified /psci node and skip any /psci related fixups instead. Fixes: 4cbca7d9 ("hw/arm: Move virt's PSCI DT fixup code to arm/boot.c") Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com> Reported-by: NMarc Zyngier <marc.zyngier@arm.com> Tested-by: NMarc Zyngier <marc.zyngier@arm.com> Message-id: 20180402205654.14572-1-andrew.smirnov@gmail.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Dr. David Alan Gilbert 提交于
When we're using the subsection we migrate both the 'props' and 'tso_props' data; when we're not using the subsection (to migrate to 2.11 or old machine types) we've got to choose what to migrate in the main structure. If we're using the subsection migrate 'props' in the main structure. If we're not using the subsection then migrate the last one that changed, which gives behaviour similar to the old behaviour. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
Swing the tx.props out via a temporary structure, so in future patches we can select what we're going to send. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
Wire the new subsection from the previous commit to a property so we can turn it off easily. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
Old QEMUs only had one set of offload data; when we only receive one lot, dupe the received data - that should give us about the same bug level as the old version. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
A bunch of new TSO fields were introduced by d62644b4 and this bumped the VMState version; however it's easier for those trying to keep backwards migration compatibility if these fields are added in a subsection instead. Move the new fields to a subsection. Since this was added after 2.11, this change will only affect compatbility with 2.12-rc0. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 BALATON Zoltan 提交于
We only emulate timer running at CPU frequency which is what most guests expect so set the frequency to match real hardware. This also allows setting clock multipliers which caused slowdown previously due to wrong timer frequency. Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Alexey Kardashevskiy 提交于
At the moment the device tree produced by the H_CAS handler has no reserved map initialized at all which is not correct as at least one empty record is required to be present as a marker of the end. This does not cause problems now as the only consumer is SLOF which does not look at the reserved map area. However when DTC's "Improve libfdt's memory safety" changeset hits the QEMU upstream, there will be errors reported and crashes observed. This fixes the problem by adding an empty entry to the reserved map, just like create_device_tree() does already. Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Thomas Huth 提交于
The macio-newworld device can currently be used to abort QEMU unexpectedly: $ ppc-softmmu/qemu-system-ppc -S -M ref405ep,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 50, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} { 'execute': 'qmp_capabilities' } {"return": {}} { 'execute': 'device-list-properties', 'arguments': {'typename': 'macio-newworld'}} Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:222: Device 'serial0' is in use Aborted (core dumped) qdev properties should be set during realize(), not during instance_init(), so move the related code there to fix this problem. Signed-off-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 09 4月, 2018 9 次提交
-
-
由 linzhecheng 提交于
Check device having the feature of VIRTIO_CONSOLE_F_EMERG_WRITE before get config->emerg_wr. It is neccessary because sizeof(virtio_console_config) is 8 byte if VirtIOSerial doesn't have the feature of VIRTIO_CONSOLE_F_EMERG_WRITE(see virtio_serial_device_realize), read/write emerg_wr will lead to heap-over-flow. Signed-off-by: Nlinzhecheng <linzhecheng@huawei.com> Message-Id: <20180328133435.20112-1-linzhecheng@huawei.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Michael Chapman 提交于
When migrating from a pre-2.9 QEMU, no clock_is_reliable flag is transferred. We should assume that the source host has an unreliable KVM_GET_CLOCK, rather than using whatever was determined locally, to ensure that any drift from the TSC-based value calculated by the guest is corrected. Signed-off-by: NMichael Chapman <mike@very.puzzling.org> Message-Id: <20180406053406.774-1-mike@very.puzzling.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
QEMU fails when used with the following command line: ./ppc64-softmmu/qemu-system-ppc64 -S -machine 40p -device i82374 qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion `!bus->dma[0] && !bus->dma[1]' failed. The 40p machine type already creates the device i82374. If specified in the command line, it will try to create it again, hence generating the error. The function isa_bus_dma() isn't supposed to be called twice for the same bus. Check the bus doesn't already have a DMA controller registered before creating the device. Fixes: https://bugs.launchpad.net/qemu/+bug/1721224Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180326153441.32641-2-f4bug@amsat.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Daniel Henrique Barboza 提交于
QEMU SCSI code makes assumptions about how the PROTECT and BYTCHK works in the protocol, denying support for PI (Protection Information) in case the guest OS requests it. However, in SCSI versions 2 and older, there is no PI concept in the protocol. This means that when dealing with such devices: - there is no PROTECT bit in byte 5 of the standard INQUIRY response. The whole byte is marked as "Reserved"; - there is no RDPROTECT in byte 2 of READ. We have 'Logical Unit Number' in this field instead; - there is no VRPROTECT in byte 2 of VERIFY. We have 'Logical Unit Number' in this field instead. This also means that the BYTCHK bit in this case is not related to PI. Since QEMU does not consider these changes, a SCSI passthrough using a SCSI-2 device will not work. It will mistake these fields with PI information and return Illegal Request SCSI SENSE thinking that the driver is asking for PI support. This patch fixes it by adding a new attribute called 'scsi_version' that is read from the standard INQUIRY response of passthrough devices. This allows for a version verification before applying conditions related to PI that doesn't apply for older versions. Reported-by: NDac Nguyen <dacng@us.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Message-Id: <20180327211451.14647-1-danielhb@linux.vnet.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
We would like to have different behavior for passthrough devices depending on the SCSI version they expose. To prepare for that, allow the user of emulated devices to specify the desired SCSI level, and adjust the emulation according to the property value. The next patch will set the level for scsi-block and scsi-generic devices. Based on a patch by Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Fam Zheng 提交于
Some backends report big max_io_sectors. Making min_io_size the same value in this case will make it impossible for guest to align memory, therefore the disk may not be usable at all. Do not enlarge them when they are zero. Reported-by: NDavid Gibson <dgibson@redhat.com> Signed-off-by: NFam Zheng <famz@redhat.com> Message-Id: <20180327164141.19075-1-famz@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 linzhecheng 提交于
Check device having the feature of VIRTIO_CONSOLE_F_EMERG_WRITE before get config->emerg_wr. It is neccessary because sizeof(virtio_console_config) is 8 byte if VirtIOSerial doesn't have the feature of VIRTIO_CONSOLE_F_EMERG_WRITE(see virtio_serial_device_realize), read/write emerg_wr will lead to heap-over-flow. Signed-off-by: Nlinzhecheng <linzhecheng@huawei.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
My rework of section adding combines overlapping or adjoining regions, but checks they're actually the same underlying RAM block. Fix the case where two blocks adjoin but don't overlap; that new region should get added (but not combined), but my previous patch was disallowing it. Fixes: c1ece84eReported-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Tested-by: NAlex Williamson <alex.williamson@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Maxime Coquelin 提交于
Without a dedicated protocol feature, QEMU cannot know whether the backend can handle VHOST_USER_SET_CONFIG and VHOST_USER_GET_CONFIG messages. This patch adds a protocol feature that is only advertised by QEMU if the device implements the config ops. Vhost user init fails if the device support the feature but the backend doesn't. The backend should only send VHOST_USER_SLAVE_CONFIG_CHANGE_MSG requests if the protocol feature has been negotiated. Signed-off-by: NMaxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NChangpeng Liu <changpeng.liu@intel.com>
-