Re: [RFC PATCH 0/4] KVM: arm64: Improve efficiency of stage2 page table

On 2021/2/25 1:20, Alexandru Elisei wrote: Hi, On 2/24/21 2:35 AM, wangyanan (Y) wrote: Hi Alex, On 2021/2/23 23:55, Alexandru Elisei wrote: Hi Yanan, I wanted to review the patches, but unfortunately I get an error when trying to apply the first patch in the series: Applying: KVM: arm64:

[PATCH kvmtool v2 22/22] hw/rtc: ARM/arm64: Use MMIO at higher addresses

Using the RTC device at its legacy I/O address as set by IBM in 1981 was a kludge we used for simplicity on ARM platforms as well. However this imposes problems due to their missing alignment and overlap with the PCI I/O address space. Now that we can switch a device easily between using ioports a

[PATCH kvmtool v2 21/22] hw/serial: ARM/arm64: Use MMIO at higher addresses

Using the UART devices at their legacy I/O addresses as set by IBM in 1981 was a kludge we used for simplicity on ARM platforms as well. However this imposes problems due to their missing alignment and overlap with the PCI I/O address space. Now that we can switch a device easily between using iop

[PATCH kvmtool v2 20/22] arm: Reorganise and document memory map

The hardcoded memory map we expose to a guest is currently described using a series of partially interconnected preprocessor constants, which is hard to read and follow. In preparation for moving the UART and RTC to some different MMIO region, document the current map with some ASCII art, and clea

[PATCH kvmtool v2 19/22] Remove ioport specific routines

Now that all users of the dedicated ioport trap handler interface are gone, we can retire the code associated with it. This removes ioport.c and ioport.h, along with removing prototypes from other header files. This also transfers the responsibility for port I/O trap handling entirely into the ne

[PATCH kvmtool v2 18/22] pci: Switch trap handling to use MMIO handler

With the planned retirement of the special ioport emulation code, we need to provide an emulation function compatible with the MMIO prototype. Merge the existing _in and _out handlers to adhere to that MMIO interface, and register these using the new registration function. Signed-off-by: Andre Pr

[PATCH kvmtool v2 17/22] virtio: Switch trap handling to use MMIO handler

With the planned retirement of the special ioport emulation code, we need to provide an emulation function compatible with the MMIO prototype. Adjust the existing MMIO callback routine to automatically determine the region this trap came through, and call the existing I/O handlers. Register the io

[PATCH kvmtool v2 16/22] vfio: Switch to new ioport trap handlers

Now that the vfio device has a trap handler adhering to the MMIO fault handler prototype, let's switch over to the joint registration routine. This allows us to get rid of the ioport shim routines. Signed-off-by: Andre Przywara Reviewed-by: Alexandru Elisei --- vfio/core.c | 37 ++-

[PATCH kvmtool v2 14/22] hw/serial: Switch to new trap handlers

Now that the serial device has a trap handler adhering to the MMIO fault handler prototype, let's switch over to the joint registration routine. This allows us to get rid of the ioport shim routines. Signed-off-by: Andre Przywara Reviewed-by: Alexandru Elisei --- hw/serial.c | 31 +++--

[PATCH kvmtool v2 15/22] vfio: Refactor ioport trap handler

With the planned retirement of the special ioport emulation code, we need to provide an emulation function compatible with the MMIO prototype. Adjust the I/O port trap handler to use that new function, and provide shims to implement the old ioport interface, for now. Signed-off-by: Andre Przywara

[PATCH kvmtool v2 13/22] hw/serial: Refactor trap handler

With the planned retirement of the special ioport emulation code, we need to provide an emulation function compatible with the MMIO prototype. Adjust the trap handler to use that new function, and provide shims to implement the old ioport interface, for now. We drop the usage of ioport__read8/wri

[PATCH kvmtool v2 12/22] hw/vesa: Switch trap handling to use MMIO handler

To be able to use the VESA device with the new generic I/O trap handler, we need to use the different MMIO handler callback routine. Replace the existing dummy in and out handlers with a joint dummy MMIO handler, and register this using the new registration function. Signed-off-by: Andre Przywara

[PATCH kvmtool v2 11/22] hw/rtc: Switch to new trap handler

Now that the RTC device has a trap handler adhering to the MMIO fault handler prototype, let's switch over to the joint registration routine. This allows us to get rid of the ioport shim routines. Signed-off-by: Andre Przywara Reviewed-by: Alexandru Elisei --- hw/rtc.c | 21 ++-

[PATCH kvmtool v2 10/22] hw/rtc: Refactor trap handlers

With the planned retirement of the special ioport emulation code, we need to provide emulation functions compatible with the MMIO prototype. Merge the two different trap handlers into one function, checking for read/write and data/index register inside. Adjust the trap handlers to use that new fun

[PATCH kvmtool v2 09/22] x86/ioport: Switch to new trap handlers

Now that the x86 I/O ports have trap handlers adhering to the MMIO fault handler prototype, let's switch over to the joint registration routine. This allows us to get rid of the ioport shim routines. Since the debug output was done in ioport.c, we would lose this functionality when moving over to

[PATCH kvmtool v2 08/22] x86/ioport: Refactor trap handlers

With the planned retirement of the special ioport emulation code, we need to provide emulation functions compatible with the MMIO prototype. Adjust the trap handlers to use that new function, and provide shims to implement the old ioport interface, for now. Signed-off-by: Andre Przywara Reviewed

[PATCH kvmtool v2 07/22] hw/i8042: Switch to new trap handlers

Now that the PC keyboard has a trap handler adhering to the MMIO fault handler prototype, let's switch over to the joint registration routine. This allows us to get rid of the ioport shim routines. Make the kbd_init() function static on the way. Signed-off-by: Andre Przywara --- hw/i8042.c

[PATCH kvmtool v2 06/22] hw/i8042: Refactor trap handler

With the planned retirement of the special ioport emulation code, we need to provide an emulation function compatible with the MMIO prototype. Adjust the trap handler to use that new function, and provide shims to implement the old ioport interface, for now. Signed-off-by: Andre Przywara --- hw

[PATCH kvmtool v2 05/22] hw/i8042: Clean up data types

The i8042 is clearly an 8-bit era device, so there is little room for 32-bit registers. Clean up the data types used. Signed-off-by: Andre Przywara Reviewed-by: Alexandru Elisei --- hw/i8042.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/hw/i8

[PATCH kvmtool v2 04/22] mmio: Extend handling to include ioport emulation

In their core functionality MMIO and I/O port traps are not really different, yet we still have two totally separate code paths for handling them. Devices need to decide on one conduit or need to provide different handler functions for each of them. Extend the existing MMIO emulation to also cover

[PATCH kvmtool v2 03/22] ioport: Retire .generate_fdt_node functionality

The ioport routines support a special way of registering FDT node generator functions. There is no reason to have this separate from the already existing way via the device header. Now that the only user of this special ioport variety has been transferred, we can retire this code, to simplify iopo

[PATCH kvmtool v2 02/22] hw/serial: Use device abstraction for FDT generator function

At the moment we use the .generate_fdt_node member of the ioport ops structure to store the function pointer for the FDT node generator function. ioport__register() will then put a wrapper and this pointer into the device header. The serial device is the only device making use of this special iopor

[PATCH kvmtool v2 01/22] ioport: Remove ioport__setup_arch()

Since x86 had a special need for registering tons of special I/O ports, we had an ioport__setup_arch() callback, to allow each architecture to do the same. As it turns out no one uses it beside x86, so we remove that unnecessary abstraction. The generic function was registered via a device_base_in

[PATCH kvmtool v2 00/22] Unify I/O port and MMIO trap handling

Compared to v1 this has a few fixes, as suggested by Alex. There is a new patch 20/22, which cleans up the ARM memory map definition and adds some chart to make it more obvious what is going on. For a changelog, see below. == At the moment we use two separate code paths to handle exit

Re: [RFC PATCH 1/4] KVM: arm64: Move the clean of dcache to the map handler

On Wed, 24 Feb 2021 17:21:22 +, Alexandru Elisei wrote: > > Hello, > > On 2/8/21 11:22 AM, Yanan Wang wrote: > > We currently uniformly clean dcache in user_mem_abort() before calling the > > fault handlers, if we take a translation fault and the pfn is cacheable. > > But if there are concur

Re: [RFC PATCH 1/4] KVM: arm64: Move the clean of dcache to the map handler

Hello, On 2/8/21 11:22 AM, Yanan Wang wrote: > We currently uniformly clean dcache in user_mem_abort() before calling the > fault handlers, if we take a translation fault and the pfn is cacheable. > But if there are concurrent translation faults on the same page or block, > clean of dcache for the

Re: [RFC PATCH 0/4] KVM: arm64: Improve efficiency of stage2 page table

Hi, On 2/24/21 2:35 AM, wangyanan (Y) wrote: > Hi Alex, > > On 2021/2/23 23:55, Alexandru Elisei wrote: >> Hi Yanan, >> >> I wanted to review the patches, but unfortunately I get an error when trying >> to >> apply the first patch in the series: >> >> Applying: KVM: arm64: Move the clean of dcac

Re: [PATCH kvmtool 13/21] hw/serial: Refactor trap handler

On Mon, 22 Feb 2021 17:40:36 + Alexandru Elisei wrote: Hi Alex, > On 2/18/21 2:41 PM, Andre Przywara wrote: > > On Tue, 16 Feb 2021 14:22:05 + > > Alexandru Elisei wrote: > > > >> Hi Andre, > >> > >> Patch looks good, nitpicks below. > >> > >> On 12/10/20 2:29 PM, Andre Przywara wrote