Re: [PATCH v5 0/7] KVM: arm64: Implement API for vGICv3 live migration

On 12 October 2015 at 09:29, Pavel Fedin wrote: > This patchset adds necessary userspace API in order to support vGICv3 live > migration. GICv3 registers are accessed using device attribute ioctls, > similar to GICv2. > > Whoever wants to test it, please note that this

[PATCH v4 6/7] vfio: platform: use list of registered reset function

Remove the static lookup table and use the dynamic list of registered reset functions instead. Also load the reset module through its alias. The reset struct module pointer is stored in vfio_platform_device. We also remove the useless struct device pointer parameter in vfio_platform_get_reset.

[PATCH v4 4/7] vfio: platform: reset: calxedaxgmac: add reset function registration

This patch adds the reset function registration/unregistration. This is handled through the module_vfio_reset_handler macro. This latter also defines a MODULE_ALIAS which simplifies the load from vfio-platform. Signed-off-by: Eric Auger Reviewed-by: Arnd Bergmann

[PATCH v4 5/7] vfio: platform: add compat in vfio_platform_device

Let's retrieve the compatibility string on probe and store it in the vfio_platform_device struct Signed-off-by: Eric Auger --- v2 -> v3: - populate compat after vdev check --- drivers/vfio/platform/vfio_platform_common.c | 15 ---

[PATCH v4 1/7] vfio: platform: introduce vfio-platform-base module

To prepare for vfio platform reset rework let's build vfio_platform_common.c and vfio_platform_irq.c in a separate module from vfio-platform and vfio-amba. This makes possible to have separate module inits and works around a race between platform driver init and vfio reset module init: that way we

[PATCH v4 7/7] vfio: platform: add dev_info on device reset

It might be helpful for the end-user to check the device reset function was found by the vfio platform reset framework. Lets store a pointer to the struct device in vfio_platform_device and trace when the reset function is called or not found. Signed-off-by: Eric Auger

[PATCH v4 2/7] vfio: platform: add capability to register a reset function

In preparation for subsequent changes in reset function lookup, lets introduce a dynamic list of reset combos (compat string, reset module, reset function). The list can be populated/voided with vfio_platform_register/unregister_reset. Those are not yet used in this patch. Signed-off-by: Eric

[PATCH v4 3/7] vfio: platform: introduce module_vfio_reset_handler macro

The module_vfio_reset_handler macro - define a module alias - implement module init/exit function which respectively registers and unregisters the reset function. Signed-off-by: Eric Auger --- v3 -> v4: - pass reset to vfio_platform_unregister_reset v2 -> v3: - use

Re: [PATCH v4 3/7] vfio: platform: introduce module_vfio_reset_handler macro

On Friday 23 October 2015 17:47:21 Eric Auger wrote: > The module_vfio_reset_handler macro > - define a module alias > - implement module init/exit function which respectively registers > and unregisters the reset function. > > Signed-off-by: Eric Auger > Reviewed-by:

[PATCH v3] VFIO: platform: reset: AMD xgbe reset module

This patch introduces a module that registers and implements a low-level reset function for the AMD XGBE device. it performs the following actions: - reset the PHY - disable auto-negotiation - disable & clear auto-negotiation IRQ - soft-reset the MAC Those tiny pieces of code are inherited from

Re: [PATCH v3] VFIO: platform: reset: AMD xgbe reset module

On Friday 23 October 2015 17:58:33 Eric Auger wrote: > This patch introduces a module that registers and implements a low-level > reset function for the AMD XGBE device. > > it performs the following actions: > - reset the PHY > - disable auto-negotiation > - disable & clear auto-negotiation IRQ

Re: [PATCH v4 2/7] vfio: platform: add capability to register a reset function

On Friday 23 October 2015 17:47:20 Eric Auger wrote: > In preparation for subsequent changes in reset function lookup, > lets introduce a dynamic list of reset combos (compat string, > reset module, reset function). The list can be populated/voided with > vfio_platform_register/unregister_reset.

[PATCH v2 1/3] KVM: arm/arm64: Optimize away redundant LR tracking

Currently we use vgic_irq_lr_map in order to track which LRs hold which IRQs, and lr_used bitmap in order to track which LRs are used or free. vgic_irq_lr_map is actually used only for piggy-back optimization, and can be easily replaced by iteration over lr_used. This is good because in future,

[PATCH v2 3/3] KVM: arm/arm64: Refactor vgic_retire_lr()

1. Remove unnecessary 'irq' argument, because irq number can be retrieved from the LR. 2. vgic_retire_lr() is always accompanied by vgic_irq_clear_queued(). Since it already does more than just clearing the LR, move vgic_irq_clear_queued() inside of it. Signed-off-by: Pavel Fedin

[PATCH v2 2/3] KVM: arm/arm64: Merge vgic_set_lr() and vgic_sync_lr_elrsr()

Now we see that vgic_set_lr() and vgic_sync_lr_elrsr() are always used together. Merge them into one function, saving from second vgic_ops dereferencing every time. Additionally, remove unnecessary vgic_set_lr() and LR_STATE_PENDING check in vgic_unqueue_irqs(), because all these things are now

[PATCH v2 0/3] KVM: arm/arm64: Clean up some obsolete code

Current KVM code has lots of old redundancies, which can be cleaned up. This patchset is actually a better alternative to http://www.spinics.net/lists/arm-kernel/msg430726.html, which allows to keep piggy-backed LRs. The idea is based on the fact that our code also maintains LR state in elrsr, and

Re: [PATCH v3 2/7] vfio: platform: add capability to register a reset function

On Friday 23 October 2015 14:37:10 Eric Auger wrote: > + > +void vfio_platform_unregister_reset(const char *compat) > +{ > + struct vfio_platform_reset_node *iter, *temp; > + > + mutex_lock(_lock); > + list_for_each_entry_safe(iter, temp, _list, link) { > + if

Re: [PATCH v3 3/7] vfio: platform: introduce module_vfio_reset_handler macro

Hi Arnd, On 10/23/2015 03:09 PM, Arnd Bergmann wrote: > On Friday 23 October 2015 14:37:11 Eric Auger wrote: >> +static int __init reset ## _module_init(void) \ >> +{ \ >> + vfio_platform_register_reset(compat,

Re: [PATCH v2] VFIO: platform: reset: AMD xgbe reset module

On Friday 23 October 2015 14:44:13 Eric Auger wrote: > This patch introduces a module that registers and implements a low-level > reset function for the AMD XGBE device. > > it performs the following actions: > - reset the PHY > - disable auto-negotiation > - disable & clear auto-negotiation IRQ

Re: [PATCH v3 1/7] vfio: platform: introduce vfio-platform-base module

On Friday 23 October 2015 14:37:09 Eric Auger wrote: > To prepare for vfio platform reset rework let's build > vfio_platform_common.c and vfio_platform_irq.c in a separate > module from vfio-platform and vfio-amba. This makes possible > to have separate module inits and works around a race between

Re: [PATCH v3 6/7] vfio: platform: use list of registered reset function

Hi Arnd, On 10/23/2015 03:12 PM, Arnd Bergmann wrote: > On Friday 23 October 2015 14:37:14 Eric Auger wrote: >> Remove the static lookup table and use the dynamic list of registered >> reset functions instead. Also load the reset module through its alias. >> The reset struct module pointer is

[PATCH v3 1/7] vfio: platform: introduce vfio-platform-base module

To prepare for vfio platform reset rework let's build vfio_platform_common.c and vfio_platform_irq.c in a separate module from vfio-platform and vfio-amba. This makes possible to have separate module inits and works around a race between platform driver init and vfio reset module init: that way we

[PATCH v3 7/7] vfio: platform: add dev_info on device reset

It might be helpful for the end-user to check the device reset function was found by the vfio platform reset framework. Lets store a pointer to the struct device in vfio_platform_device and trace when the reset function is called or not found. Signed-off-by: Eric Auger

[PATCH v3 2/7] vfio: platform: add capability to register a reset function

In preparation for subsequent changes in reset function lookup, lets introduce a dynamic list of reset combos (compat string, reset module, reset function). The list can be populated/voided with two new functions, vfio_platform_register/unregister_reset. Those are not yet used in this patch.

[PATCH v3 4/7] vfio: platform: reset: calxedaxgmac: add reset function registration

This patch adds the reset function registration/unregistration. This is handled through the module_vfio_reset_handler macro. This latter also defines a MODULE_ALIAS which simplifies the load from vfio-platform. Signed-off-by: Eric Auger --- v2 -> v3: - do not include

[PATCH v3 0/7] VFIO platform reset module rework

This series fixes the current implementation by getting rid of the usage of __symbol_get which caused a compilation issue with CONFIG_MODULES disabled. On top of this, the usage of MODULE_ALIAS makes possible to add a new reset module without being obliged to update the framework. The new

[PATCH v3 5/7] vfio: platform: add compat in vfio_platform_device

Let's retrieve the compatibility string on probe and store it in the vfio_platform_device struct Signed-off-by: Eric Auger --- v2 -> v3: - populate compat after vdev check --- drivers/vfio/platform/vfio_platform_common.c | 15 ---

[PATCH v3 3/7] vfio: platform: introduce module_vfio_reset_handler macro

The module_vfio_reset_handler macro - define a module alias - implement module init/exit function which respectively registers and unregisters the reset function. Signed-off-by: Eric Auger --- v2 -> v3: - use vfio_platform_register_reset macro v1 -> v2: - remove

Re: [PATCH v3 6/7] vfio: platform: use list of registered reset function

On 10/23/2015 04:23 PM, Arnd Bergmann wrote: > On Friday 23 October 2015 16:11:08 Eric Auger wrote: >> Hi Arnd, >> On 10/23/2015 03:12 PM, Arnd Bergmann wrote: >>> On Friday 23 October 2015 14:37:14 Eric Auger wrote: Remove the static lookup table and use the dynamic list of registered

RE: [PATCH 1/2] KVM: arm/arm64: Optimize away redundant LR tracking

Hello! > -Original Message- > From: Christoffer Dall [mailto:christoffer.d...@linaro.org] > Sent: Friday, October 23, 2015 12:43 AM > To: Pavel Fedin > Cc: kvmarm@lists.cs.columbia.edu; k...@vger.kernel.org; Marc Zyngier; Andre > Przywara > Subject: Re: [PATCH 1/2] KVM: arm/arm64: