- Sep 24, 2019
-
-
Eric Blake authored
When iothreads are in use, the failure to grab the aio context results in an assertion failure when trying to unlock things during blk_unref, when trying to unlock a mutex that was not locked. In short, all calls to nbd_export_put need to done while within the correct aio context. But since nbd_export_put can recursively reach itself via nbd_export_close, and recursively grabbing the context would deadlock, we can't do the context grab directly in those functions, but must do so in their callers. Hoist the use of the correct aio_context from nbd_export_new() to its caller qmp_nbd_server_add(). Then tweak qmp_nbd_server_remove(), nbd_eject_notifier(), and nbd_esport_close_all() to grab the right context, so that all callers during qemu now own the context before nbd_export_put() can call blk_unref(). Remaining uses in qemu-nbd don't matter (since that use case does not support iothreads). Suggested-by:
Kevin Wolf <kwolf@redhat.com> Signed-off-by:
Eric Blake <eblake@redhat.com> Message-Id: <20190917023917.32226-1-eblake@redhat.com> Reviewed-by:
Sergio Lopez <slp@redhat.com>
-
Sergio Lopez authored
On creation, the export's AioContext is set to the same one as the BlockBackend, while the AioContext in the client QIOChannel is left untouched. As a result, when using data-plane, nbd_client_receive_next_request() schedules coroutines in the IOThread AioContext, while the client's QIOChannel is serviced from the main_loop, potentially triggering the assertion at qio_channel_restart_[read|write]. To fix this, as soon we have the export corresponding to the client, we call qio_channel_attach_aio_context() to attach the QIOChannel context to the export's AioContext. This matches with the logic at blk_aio_attached(). RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1748253 Signed-off-by:
Sergio Lopez <slp@redhat.com> Message-Id: <20190912110032.26395-1-slp@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Signed-off-by:
Eric Blake <eblake@redhat.com>
-
Eric Blake authored
I received an off-list report of failure to connect to an NBD server expecting an x509 certificate, when the client was attempting something similar to this command line: $ ./x86_64-softmmu/qemu-system-x86_64 -name 'blah' -machine q35 -nodefaults \ -object tls-creds-x509,id=tls0,endpoint=client,dir=$path_to_certs \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie.0,addr=0x6 \ -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=raw,file=nbd:localhost:9000,werror=stop,rerror=stop,tls-creds=tls0 \ -device scsi-hd,id=image1,drive=drive_image1,bootindex=0 qemu-system-x86_64: -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=raw,file=nbd:localhost:9000,werror=stop,rerror=stop,tls-creds=tls0: TLS negotiation required before option 7 (go) server reported: Option 0x7 not permitted before TLS The problem? As specified, -drive is trying to pass tls-creds to the raw format driver instead of the nbd protocol driver, but before we get to the point where we can detect that raw doesn't know what to do with tls-creds, the nbd driver has already failed because the server complained. The fix to the broken command line? Pass '...,file.tls-creds=tls0' to ensure the tls-creds option is handed to nbd, not raw. But since the error message was rather cryptic, I'm trying to improve the error message. With this patch, the error message adds a line: qemu-system-x86_64: -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=raw,file=nbd:localhost:9000,werror=stop,rerror=stop,tls-creds=tls0: TLS negotiation required before option 7 (go) Did you forget a valid tls-creds? server reported: Option 0x7 not permitted before TLS And with luck, someone grepping for that error message will find this commit message and figure out their command line mistake. Sadly, the only mention of file.tls-creds in our docs relates to an --image-opts use of PSK encryption with qemu-img as the client, rather than x509 certificate encryption with qemu-kvm as the client. CC: Tingting Mao <timao@redhat.com> CC: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by:
Eric Blake <eblake@redhat.com> Message-Id: <20190907172055.26870-1-eblake@redhat.com> [eblake: squash in iotest 233 fix] Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com>
-
- Sep 23, 2019
-
-
Peter Maydell authored
Fix a bunch of BUGs in the mem-helpers (including the MVC instruction), especially, to make them behave correctly on faults. # gpg: Signature made Mon 23 Sep 2019 09:01:21 BST # gpg: using RSA key 1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A # gpg: issuer "david@redhat.com" # gpg: Good signature from "David Hildenbrand <david@redhat.com>" [unknown] # gpg: aka "David Hildenbrand <davidhildenbrand@gmail.com>" [full] # Primary key fingerprint: 1BD9 CAAD 735C 4C3A 460D FCCA 4DDE 10F7 00FF 835A * remotes/davidhildenbrand/tags/s390x-tcg-2019-09-23: (30 commits) tests/tcg: target/s390x: Test MVC tests/tcg: target/s390x: Test MVO s390x/tcg: MVO: Fault-safe handling s390x/tcg: MVST: Fault-safe handling s390x/tcg: MVZ: Fault-safe handling s390x/tcg: MVN: Fault-safe handling s390x/tcg: MVCIN: Fault-safe handling s390x/tcg: NC: Fault-safe handling s390x/tcg: XC: Fault-safe handling s390x/tcg: OC: Fault-safe handling s390x/tcg: MVCLU: Fault-safe handling s390x/tcg: MVC: Fault-safe handling on destructive overlaps s390x/tcg: MVCS/MVCP: Use access_memmove() s390x/tcg: Fault-safe memmove s390x/tcg: Fault-safe memset s390x/tcg: Always use MMU_USER_IDX for CONFIG_USER_ONLY s390x/tcg: MVST: Fix storing back the addresses to registers s390x/tcg: MVST: Check for specification exceptions s390x/tcg: MVCS/MVCP: Properly wrap the length s390x/tcg: MVCOS: Lengths are 32 bit in 24/31-bit mode ... Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
Peter Maydell authored
- bugfixes in ccw bios - gen15a is called z15 - officially require a 3.15 kernel or later for kvm # gpg: Signature made Mon 23 Sep 2019 08:18:32 BST # gpg: using RSA key 117BBC80B5A61C7C # gpg: Good signature from "Christian Borntraeger (IBM) <borntraeger@de.ibm.com>" [full] # Primary key fingerprint: F922 9381 A334 08F9 DBAB FBCA 117B BC80 B5A6 1C7C * remotes/borntraeger/tags/s390x-20190923: s390x/cpumodel: Add the z15 name to the description of gen15a s390x/kvm: Officially require at least kernel 3.15 pc-bios/s390-ccw: Rebuild the s390-netboot.img firmware image pc-bios/s390-ccw/net: fix a possible memory leak in get_uuid() pc-bios/s390-ccw: Do not pre-initialize empty array Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
Peter Maydell authored
ipmi: Some bug fixes and new interfaces Some bug fixes for the watchdog and hopeful the BT tests. Change the IPMI UUID handling to give the user the ability to set it or not have it. Add a PCI interface. Add an SMBus interfaces. -corey # gpg: Signature made Fri 20 Sep 2019 20:11:21 BST # gpg: using RSA key FD0D5CE67CE0F59A6688268661F38C90919BFF81 # gpg: Good signature from "Corey Minyard <cminyard@mvista.com>" [unknown] # gpg: aka "Corey Minyard <minyard@acm.org>" [unknown] # gpg: aka "Corey Minyard <corey@minyard.net>" [unknown] # gpg: aka "Corey Minyard <minyard@mvista.com>" [unknown] # 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: FD0D 5CE6 7CE0 F59A 6688 2686 61F3 8C90 919B FF81 * remotes/cminyard/tags/ipmi-for-release-2019-09-20: pc: Add an SMB0 ACPI device to q35 ipmi: Fix SSIF ACPI handling to use the right CRS acpi: Add i2c serial bus CRS handling ipmi: Add an SMBus IPMI interface ipmi: Add PCI IPMI interfaces smbios:ipmi: Ignore IPMI devices with no fwinfo function ipmi: Allow a size value to be passed for I/O space ipmi: Split out BT-specific code from ISA BT code ipmi: Split out KCS-specific code from ISA KCS code ipmi: Add a UUID device property qdev: Add a no default uuid property tests:ipmi: Fix IPMI BT tests ipmi: Generate an interrupt on watchdog pretimeout expiry ipmi: Fix the get watchdog command ipmi: Fix watchdog NMI handling Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
David Hildenbrand authored
Let's add a test that especially verifies that no data will be touched in case we cross page boundaries and one page access triggers a fault. Before the fault-safe handling fixes, the test failes with: TEST mvc on s390x data modified during a fault make[2]: *** [../Makefile.target:116: run-mvc] Error 1 Acked-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Let's add the simple test based on the example from the PoP. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Each operand can have a maximum length of 16. Make sure to prepare all reads/writes before writing. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Access at most single pages and document why. Using the access helpers might over-indicate watchpoints within the same page, I guess we can live with that. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We can process a maximum of 256 bytes, crossing two pages. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We can process a maximum of 256 bytes, crossing two pages. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We can process a maximum of 256 bytes, crossing two pages. Calculate the accessed range upfront - src is accessed right-to-left. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We can process a maximum of 256 bytes, crossing two pages. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We can process a maximum of 256 bytes, crossing two pages. While at it, increment the length once. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We can process a maximum of 256 bytes, crossing two pages. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
The last remaining bit is padding with two bytes. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
The last remaining bit for MVC is handling destructive overlaps in a fault-safe way. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
As we are moving between address spaces, we can use access_memmove() without checking for destructive overlaps (especially of real storage locations): "Each storage operand is processed left to right. The storage-operand-consistency rules are the same as for MOVE (MVC), except that when the operands overlap in real storage, the use of the common real- storage locations is not necessarily recognized." Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Replace fast_memmove() variants by access_memmove() variants, that first try to probe access to all affected pages (maximum is two pages). Introduce access_get_byte()/access_set_byte(). We might be able to speed up memmove in special cases even further (do single-byte access, use memmove() for remaining bytes in page), however, we'll skip that for now. In MVCOS, simply always call access_memmove_as() and drop the TODO about LAP. LAP is already handled in the MMU. Get rid of adj_len_to_page(), which is now unused. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Replace fast_memset() by access_memset(), that first tries to probe access to all affected pages (maximum is two). We'll use the same mechanism for other types of accesses soon. Only in very rare cases (especially TLB_NOTDIRTY), we'll have to fallback to ld/st helpers. Try to speed up that case as suggested by Richard. We'll rework most involved handlers soon to do all accesses via new fault-safe helpers, especially MVC. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Although we basically ignore the index all the time for CONFIG_USER_ONLY, let's simply skip all the checks and always return MMU_USER_IDX in cpu_mmu_index() and get_mem_index(). Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
24 and 31-bit address space handling is wrong when it comes to storing back the addresses to the register. While at it, read gprs 0 implicitly. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Bit position 32-55 of general register 0 must be zero. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
... and don't perform any move in case the length is zero. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Triggered by a review comment from Richard, also MVCOS has a 32-bit length in 24/31-bit addressing mode. Add a new helper. Rename wrap_length() to wrap_length31(). Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Let's perform the documented checks. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Let's stay within single pages. ... and indicate cc=3 in case there is work remaining. Keep unicode padding simple. While reworking, properly wrap the addresses. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We have to mask of any unused bits. While at it, document what exactly is missing. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Perform the checks documented in the PoP. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Let's use the new helper, that also detects destructive overlaps when wrapping. We'll make the remaining code (e.g., fast_memmove()) aware of wrapping later. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Let's increment the length once. While at it, cleanup the comment. The memset() example is given as a programming note in the PoP, so drop the description. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
Process max 4k bytes at a time, writing back registers between the accesses. The instruction is interruptible. "For operands longer than 2K bytes, access exceptions are not recognized for locations more than 2K bytes beyond the current location being processed." Note that on z/Architecture, 2k vs. 4k access cannot get differentiated as long as pages are not crossed. This seems to be a leftover from ESA/390. Simply stay within single pages. MVCL handling is quite different than MVCLE/MVCLU handling, so split up the handlers. Defer interrupt handling, as that will require more thought, add a TODO for that. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We'll have to zero-out unused bit positions, so make sure to write the addresses back. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We have to zero out unused bits in 24 and 31-bit addressing mode. Provide a new helper. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
David Hildenbrand authored
We use the marker "-1" for "no exception". s390_cpu_do_interrupt() might get confused by that. Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
David Hildenbrand <david@redhat.com>
-
Christian Borntraeger authored
We now know that gen15a is called z15. Reviewed-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Thomas Huth authored
Since QEMU v2.10, the KVM acceleration does not work on older kernels anymore since the code accidentally requires the KVM_CAP_DEVICE_CTRL capability now - it should have been optional instead. Instead of fixing the bug, we asked in the ChangeLog of QEMU 2.11 - 3.0 that people should speak up if they still need support of QEMU running with KVM on older kernels, but seems like nobody really complained. Thus let's make this official now and turn it into a proper error message, telling the users to use at least kernel 3.15 now. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <20190913091443.27565-1-thuth@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
-
- Sep 20, 2019
-
-
Corey Minyard authored
This is so I2C devices can be found in the ACPI namespace. Currently that's only IPMI, but devices can be easily added now. Adding the devices required some PCI information, and the bus itself to be added to the PCMachineState structure. Note that this only works on Q35, the ACPI for PIIX4 is not capable of handling an SMBus device. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com>
-