summary refs log tree commit diff stats
path: root/scripts/qapi/source.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2021-09-10ps2: use a separate keyboard command reply queueVolker Rümelin1-31/+84
A PS/2 keyboard has a separate command reply queue that is independent of the key queue. This prevents that command replies and keyboard input mix. Keyboard command replies take precedence over queued keystrokes. A new keyboard command removes any remaining command replies from the command reply queue. Implement a separate keyboard command reply queue and clear the command reply queue before command execution. This brings the PS/2 keyboard emulation much closer to a real PS/2 keyboard. The command reply queue is located in a few free bytes directly in front of the scancode queue. Because the scancode queue has a maximum length of 16 bytes there are 240 bytes available for the command reply queue. At the moment only a maximum of 3 bytes are required. For compatibility reasons rptr, wptr and count kept their function. rptr is the start, wptr is the end and count is the length of the entire keyboard queue. The new variable cwptr is the end of the command reply queue or -1 if the queue is empty. To write to the command reply queue, rptr is moved backward by the number of required bytes and the command replies are written to the buffer starting at the new rptr position. After writing, cwptr is at the old rptr position. Copying cwptr to rptr clears the command reply queue. The command reply queue can't overflow because each new keyboard command clears the command reply queue. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/501 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/502 Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20210810133258.8231-2-vr_qemu@t-online.de> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-10ps2: use the whole ps2 buffer but keep queue sizeVolker Rümelin1-49/+20
Extend the used ps2 buffer size to the available buffer size but keep the maximum ps2 queue size. The next patch needs a few bytes of the larger buffer size. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20210810133258.8231-1-vr_qemu@t-online.de> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-09-08mac_via: add qdev gpios for nubus slot interrupts to VIA2Mark Cave-Ayland2-0/+33
These will soon be required to enable nubus devices to support interrupts. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-13-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: rename VIA2_IRQ_SLOT_BIT to VIA2_IRQ_NUBUS_BITMark Cave-Ayland1-11/+11
Also improve the alignment of the shifted constants. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-12-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: remove explicit viaN prefix from VIA IRQ gpiosMark Cave-Ayland2-12/+7
Now that q800 VIA1 and VIA2 are completely separate devices there is no need to add a specific device prefix to ensure that the IRQ lines remain separate. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210830102447.10806-11-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: remove mac_via deviceMark Cave-Ayland3-97/+36
Remove the mac_via device and wire up both q800 VIA1 and VIA2 directly for the m68k q800 machine. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-10-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: move VIA1 realize logic from mac_via_realize() to ↵Mark Cave-Ayland1-42/+44
mos6522_q800_via1_realize() Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-9-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: move VIA1 reset logic from mac_via_reset() to mos6522_q800_via1_reset()Mark Cave-Ayland1-14/+8
After this change mac_via_reset() is now empty and can be removed. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210830102447.10806-8-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: move q800 VIA1 timer variables to q800 VIA1 VMStateDescriptionMark Cave-Ayland1-15/+5
These variables are already present in MOS6522Q800VIA1State and so it is just the VMStateDescription move that is needed. With this change the mac_via VMStateDescription is now empty and can be removed completely. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-7-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: move ADB variables to MOS6522Q800VIA1StateMark Cave-Ayland3-99/+96
The ADB is accessed using clock and data pins on q800 VIA1 port B and so can be moved to MOS6522Q800VIA1State. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210830102447.10806-6-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: move PRAM/RTC variables to MOS6522Q800VIA1StateMark Cave-Ayland2-79/+77
The PRAM/RTC is accessed using clock and data pins on q800 VIA1 port B and so can be moved to MOS6522Q800VIA1State. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210830102447.10806-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: move PRAM contents and block backend to MOS6522Q800VIA1StateMark Cave-Ayland2-32/+34
The PRAM contents are accessed using clock and data pins on q800 VIA1 port B and so can be moved to MOS6522Q800VIA1State. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: move last_b variable into q800 VIA1 VMStateDescriptionMark Cave-Ayland1-1/+1
This variable is already present in MOS6522Q800VIA1State and can be moved immediately into the q800 VIA1 VMStateDescription. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08mac_via: introduce new VMStateDescription for q800 VIA1 and VIA2Mark Cave-Ayland1-4/+24
Move the parent mos6522 objects from vmstate_mac_via into the new VMStateDescription structures to begin the process of splitting MacVIAState into separate VIA1 and VIA2 devices. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210830102447.10806-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-08escc: fix STATUS_SYNC bit in R_STATUS registerMark Cave-Ayland1-1/+8
After an SDLC "Enter hunt" command has been sent the STATUS_SYNC bit should remain high until the flag byte has been detected. Whilst the ESCC device doesn't yet implement SDLC mode, without this change the active low STATUS_SYNC is constantly asserted causing the MacOS OpenTransport extension to hang on startup as it thinks it is constantly receiving LocalTalk responses during its initial negotiation phase. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-10-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: re-use escc_reset_chn() for soft resetMark Cave-Ayland1-7/+2
This removes duplication of the internal device state initialisation between device reset and soft reset. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-9-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: remove register changes from escc_reset_chn()Mark Cave-Ayland1-25/+0
Now that register values at reset are handled elsewhere for all of device reset, soft reset and hard reset, escc_reset_chn() only needs to handle initialisation of internal device state. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-8-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: implement hard reset as described in the datasheetMark Cave-Ayland1-28/+13
The hardware reset differs from a device reset in that it only changes the contents of specific registers. Remove the code that resets all the registers to zero during hardware reset and implement the default values using the existing soft reset code with the additional changes listed in the table in the "Z85C30 Reset" section. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-7-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: implement soft reset as described in the datasheetMark Cave-Ayland1-17/+31
The software reset differs from a device reset in that it only changes the contents of specific registers. Remove the code that resets all the registers to zero during soft reset and implement the default values listed in the table in the "Z85C30 Reset" section. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-6-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: introduce escc_hard_reset_chn() for hardware resetMark Cave-Ayland2-1/+38
This new hardware reset function is to be called for both channels when the hardware reset bit is written to register WR9. Its initial implementation is the same as the existing escc_reset_chn() function used for device reset. Add a new trace event when the guest initiates a hard reset via the WR9 register to help diagnose guest reset issues. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: introduce escc_soft_reset_chn() for software resetMark Cave-Ayland2-2/+39
This new software reset function is to be called when the appropriate channel software reset bit is written to register WR9. Its initial implementation is the same as the existing escc_reset_chn() function used for device reset. Add a new trace event when the guest initiates a soft reset via the WR9 register to help diagnose guest reset issues. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: reset register values to zero in escc_reset()Mark Cave-Ayland1-2/+17
This is to ensure that a device reset always returns the ESCC to a known state. Note that this is currently redundant with the same code in escc_reset_chn() but that will change shortly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08escc: checkpatch fixesMark Cave-Ayland1-65/+97
Also fix a couple of spelling mistakes in comments. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210903113223.19551-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08sun4m: fix setting CPU id when more than one CPU is presentMark Cave-Ayland1-1/+1
Commit 24f675cd3b ("sparc/sun4m: Use start-powered-off CPUState property") changed the sun4m CPU reset code to use the start-powered-off property and so split the creation of the CPU into separate instantiation and realization phases to enable the new start-powered-off property to be set. This accidentally broke sun4m machines with more than one CPU present since sparc_cpu_realizefn() sets a default CPU id, and now that realization occurs after calling cpu_sparc_set_id() in cpu_devinit() the CPU id gets reset back to the default instead of being uniquely encoded based upon the CPU number. As soon as another CPU is brought online, the OS gets confused between them and promptly panics. Resolve the issue by moving the cpu_sparc_set_id() call in cpu_devinit() to after the point where the CPU device has been realized as before. Fixes: 24f675cd3b ("sparc/sun4m: Use start-powered-off CPUState property") Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210825095100.20180-1-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08tcg: Drop gen_io_end()Peter Maydell2-20/+10
Now we have removed all the uses of gen_io_end() from target frontends, the only callsite is inside gen_tb_start(). Inline the code there, and remove the reference to it from the documentation. While we are inlining the code, switch it to use tcg_constant_i32() so we don't have to manually create and destroy a TCG temporary. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210724134902.7785-3-peter.maydell@linaro.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08target/sparc: Drop use of gen_io_end()Peter Maydell1-15/+10
The gen_io_end() function is obsolete (as documented in docs/devel/tcg-icount.rst). Where an instruction is an I/O operation, the translator frontend should call gen_io_start() before generating the code which does the I/O, and then end the TB immediately after this insn. Remove the calls to gen_io_end() in the SPARC frontend, and ensure that the insns which were calling it end the TB if they didn't do so already. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210724134902.7785-2-peter.maydell@linaro.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-08Update OpenBIOS images to d657b653 built from submodule.Mark Cave-Ayland4-0/+0
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-09-07s390x/cpumodel: Add more feature to gen16 default modelChristian Borntraeger2-1/+12
Add the new gen16 features to the default model and fence them for machine version 6.1 and earlier. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20210907101017.27126-1-borntraeger@de.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-07block/nvme: Only report VFIO error on failed retryPhilippe Mathieu-Daudé1-1/+7
We expect the first qemu_vfio_dma_map() to fail (indicating DMA mappings exhaustion, see commit 15a730e7a3a). Do not report the first failure as error, since we are going to flush the mappings and retry. This removes spurious error message displayed on the monitor: (qemu) c (qemu) qemu-kvm: VFIO_MAP_DMA failed: No space left on device (qemu) info status VM status: running Reported-by: Tingting Mao <timao@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-12-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Let qemu_vfio_do_mapping() propagate ErrorPhilippe Mathieu-Daudé1-4/+4
Pass qemu_vfio_do_mapping() an Error* argument so it can propagate any error to callers. Replace error_report() which only report to the monitor by the more generic error_setg_errno(). Reviewed-by: Fam Zheng <fam@euphon.net> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-11-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Simplify qemu_vfio_dma_map() returning directlyPhilippe Mathieu-Daudé1-13/+10
To simplify qemu_vfio_dma_map(): - reduce 'ret' (returned value) scope by returning errno directly, - remove the goto 'out' label. Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-10-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Use error_setg in qemu_vfio_find_[fixed/temp]_iovaPhilippe Mathieu-Daudé1-10/+14
Both qemu_vfio_find_fixed_iova() and qemu_vfio_find_temp_iova() return an errno which is unused (or overwritten). Have them propagate eventual errors to callers, returning a boolean (which is what the Error API recommends, see commit e3fe3988d78 "error: Document Error API usage rules" for rationale). Suggested-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-9-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Extract qemu_vfio_water_mark_reached()Philippe Mathieu-Daudé1-1/+16
Extract qemu_vfio_water_mark_reached() for readability, and have it provide an error hint it its Error* handle. Suggested-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-8-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Pass Error handle to qemu_vfio_dma_map()Philippe Mathieu-Daudé3-16/+18
Currently qemu_vfio_dma_map() displays errors on stderr. When using management interface, this information is simply lost. Pass qemu_vfio_dma_map() an Error** handle so it can propagate the error to callers. Reviewed-by: Fam Zheng <fam@euphon.net> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-7-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07block/nvme: Have nvme_create_queue_pair() report errors consistentlyPhilippe Mathieu-Daudé1-0/+3
nvme_create_queue_pair() does not return a boolean value (indicating eventual error) but a pointer, and is inconsistent in how it fills the error handler. To fulfill callers expectations, always set an error message on failure. Reported-by: Auger Eric <eric.auger@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-6-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Remove unreachable code in qemu_vfio_dma_map()Philippe Mathieu-Daudé1-4/+0
qemu_vfio_add_mapping() returns a pointer to an indexed entry in pre-allocated QEMUVFIOState::mappings[], thus can not be NULL. Remove the pointless check. Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-5-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Replace qemu_mutex_lock() calls with QEMU_LOCK_GUARDPhilippe Mathieu-Daudé1-6/+3
Simplify qemu_vfio_dma_[un]map() handlers by replacing a pair of qemu_mutex_lock/qemu_mutex_unlock calls by the WITH_QEMU_LOCK_GUARD macro. Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-4-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07util/vfio-helpers: Let qemu_vfio_verify_mappings() use error_report()Philippe Mathieu-Daudé1-2/+2
Instead of displaying the error on stderr, use error_report() which also report to the monitor. Reviewed-by: Fam Zheng <fam@euphon.net> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-3-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-07block/nvme: Use safer trace format stringPhilippe Mathieu-Daudé1-1/+1
Fix when building with -Wshorten-64-to-32: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32] Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210902070025.197072-2-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2021-09-06s390x: Replace PAGE_SIZE, PAGE_SHIFT and PAGE_MASKThomas Huth4-14/+11
The PAGE_SIZE macro is causing trouble on Alpine Linux since it clashes with a macro from a system header there. We already have the TARGET_PAGE_SIZE, TARGET_PAGE_MASK and TARGET_PAGE_BITS macros in QEMU anyway, so let's simply replace the PAGE_SIZE, PAGE_MASK and PAGE_SHIFT macro with their TARGET_* counterparts. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/572 Message-Id: <20210901125800.611183-1-thuth@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06hw/s390x/s390-skeys: lazy storage key enablement under TCGDavid Hildenbrand4-14/+131
Let's enable storage keys lazily under TCG, just as we do under KVM. Only fairly old Linux versions actually make use of storage keys, so it can be kind of wasteful to allocate quite some memory and track changes and references if nobody cares. We have to make sure to flush the TLB when enabling storage keys after the VM was already running: otherwise it might happen that we don't catch references or modifications afterwards. Add proper documentation to all callbacks. The kvm-unit-tests skey tests keeps on working with this change. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-14-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06hw/s390x/s390-skeys: rename skeys_enabled to skeys_are_enabledDavid Hildenbrand3-9/+9
... and make it return a bool instead. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-13-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06hw/s390x/s390-skeys: check if an address is valid before dumping the keyDavid Hildenbrand1-5/+8
Let's validate the given address and report a proper error in case it's not. All call paths now properly check the validity of the given GFN. Remove the TODO. The errors inside the getter and setter should only trigger if something really goes wrong now, for example, with a broken migration stream. Or when we forget to update the storage key allocation with memory hotplug. Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-12-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06hw/s390x/s390-skeys: use memory mapping to detect which storage keys to dumpDavid Hildenbrand1-20/+30
Handle it similar to migration. Assert that we're holding the BQL, to make sure we don't see concurrent modifications. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-11-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06hw/s390x/s390-skeys: use memory mapping to detect which storage keys to migrateDavid Hildenbrand1-27/+43
Let's use the guest_phys_blocks API to get physical memory regions that are well defined inside our physical address space and migrate the storage keys of these. This is a preparation for having memory besides initial ram defined in the guest physical address space, for example, via memory devices. We get rid of the ms->ram_size dependency. Please note that we will usually have very little (--> 1) physical ranges. With virtio-mem might have significantly more ranges in the future. If that turns out to be a problem (e.g., total memory footprint of the list), we could look into a memory mapping API that avoids creation of a list and instead triggers a callback for each range. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-10-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06s390x/mmu_helper: avoid setting the storage key if nothing changedDavid Hildenbrand1-4/+7
Avoid setting the key if nothing changed. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-9-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06s390x/mmu_helper: move address validation into mmu_translate*()David Hildenbrand4-29/+24
Let's move address validation into mmu_translate() and mmu_translate_real(). This allows for checking whether an absolute address is valid before looking up the storage key. We can now get rid of the ram_size check. Interestingly, we're already handling LOAD REAL ADDRESS wrong, because a) We're not supposed to touch storage keys b) We're not supposed to convert to an absolute address Let's use a fake, negative MMUAccessType to teach mmu_translate() to fix that handling and to not perform address validation. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-8-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06s390x/mmu_helper: fixup mmu_translate() documentationDavid Hildenbrand1-1/+2
Looks like we forgot to adjust documentation of one parameter. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-7-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06s390x/mmu_helper: no need to pass access type to mmu_translate_asce()David Hildenbrand1-2/+2
The access type is unused since commit 81d7e3bc45 ("s390x/mmu: Inject DAT exceptions from a single place"). Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-6-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-09-06s390x/tcg: check for addressing exceptions for RRBE, SSKE and ISKEDavid Hildenbrand4-16/+35
Let's replace the ram_size check by a proper physical address space check (for example, to prepare for memory hotplug), trigger addressing exceptions and trace the return value of the storage key getter/setter. Provide an helper mmu_absolute_addr_valid() to be used in other context soon. Always test for "read" instead of "write" as we are not actually modifying the page itself. Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210903155514.44772-5-david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>