Re: [PATCH v5 1/2] arm/arm64: KVM: Detect vGIC presence at runtime

On 21 April 2016 at 23:35, Alexander Graf wrote: > It might make sense to have a generic "system register couldn't get > handled" exit code anyway. If nothing else, at least to display > unhandled registers in the qemu context where they appear rather than in > the kernel log

Re: [PATCH v5 1/2] arm/arm64: KVM: Detect vGIC presence at runtime

On 22.04.16 00:04, Peter Maydell wrote: > On 21 April 2016 at 22:41, Alexander Graf wrote: >> So effectively all we'd need is to set CNTHCTL_EL2.EL1PCEN to 0 for >> guests that have no in-kernel irqchip, no? We should then trap on all >> timer accesses and be able to emulate them

Re: [PATCH v5 1/2] arm/arm64: KVM: Detect vGIC presence at runtime

On 21 April 2016 at 22:41, Alexander Graf wrote: > So effectively all we'd need is to set CNTHCTL_EL2.EL1PCEN to 0 for > guests that have no in-kernel irqchip, no? We should then trap on all > timer accesses and be able to emulate them in user space where we can > inject IRQs into

Re: [PATCH v7 1/6] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 21 April 2016 at 19:30, Christoffer Dall wrote: > So I agree about the latch state, that should be exported, if nothing > else so that a VM can't use this particular change to detect a > migration, for example. > > However, for the input level, I really do see this

Re: [PATCH 5/7] KVM: arm/arm64: Remove the IRQ field from struct irq_phys_map

On Thu, Apr 21, 2016 at 07:41:01PM +0200, Eric Auger wrote: > Hi Andre, > On 04/15/2016 04:04 PM, Andre Przywara wrote: > > From: Christoffer Dall > > > > The communication of a Linux IRQ number from outside the VGIC to the > > vgic was a leftover from the day when

Re: [PATCH v7 1/6] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On Wed, Apr 20, 2016 at 02:28:05PM +0100, Peter Maydell wrote: > On 20 April 2016 at 11:59, Christoffer Dall > wrote: > > On Friday, 15 April 2016, Peter Maydell wrote: > >> Nothing in here describes a mechanism for reading or writing the >

Re: [PATCH 7/7] KVM: arm/arm64: remove irq_phys_map pointer from kvm_vgic_map_phys_irq()

On 04/15/2016 04:04 PM, Andre Przywara wrote: > Now that the virtual arch timer does not care about the irq_phys_map > anymore, let's rework kvm_vgic_map_phys_irq() to return an error > value instead. Any reference to thap mapping can later be done by > passing the correct combination of VCPU and

Re: [PATCH 6/7] KVM: arm/arm64: remove irq_phys_map from the arch timer

On 04/15/2016 04:04 PM, Andre Przywara wrote: > Now that the interface between the arch timer and the VGIC does not > require passing the irq_phys_map entry pointer anymore, let's remove > it from the virtual arch timer and use the virtual IRQ number instead > directly. > The remaining pointer

Re: [PATCH 5/7] KVM: arm/arm64: Remove the IRQ field from struct irq_phys_map

Hi Andre, On 04/15/2016 04:04 PM, Andre Przywara wrote: > From: Christoffer Dall > > The communication of a Linux IRQ number from outside the VGIC to the > vgic was a leftover from the day when the vgic code cared about how a > particular device injects virtual

Re: [PATCH 4/7] KVM: arm/arm64: directly pass virtual IRQ number on kvm_vgic_unmap_phys_irq()

Reviewed-by: Eric Auger Eric On 04/15/2016 04:04 PM, Andre Przywara wrote: > kvm_vgic_unmap_phys_irq() only needs the virtual IRQ number, so let's > just pass that between the arch timer and the VGIC to get rid of > the irq_phys_map pointer. > > Signed-off-by: Andre

Re: [PATCH 2/7] KVM: arm/arm64: directly pass virtual IRQ number on injecting mapped IRQ

Hi Andre, On 04/15/2016 04:04 PM, Andre Przywara wrote: > When we want to inject a hardware mapped IRQ into a guest, we actually > only need the virtual IRQ number from the irq_phys_map. > So let's pass this number directly from the arch timer to the VGIC > to avoid using the map as a parameter. >

Re: [PATCH 3/7] KVM: arm/arm64: directly pass virtual IRQ number on kvm_vgic_map_is_active()

Hi Andre, On 04/15/2016 04:04 PM, Andre Przywara wrote: > For getting the active state of a mapped IRQ, we actually only need > the virtual IRQ number, not the pointer to the mapping entry. > Pass the virtual IRQ number from the arch timer to the VGIC directly. > > Signed-off-by: Andre Przywara

Re: [PATCH 1/7] KVM: arm/arm64: remove unneeded map parameter for vgic_update_irq_pending()

Reviewed-by: Eric Auger Eric On 04/15/2016 04:04 PM, Andre Przywara wrote: > We actually don't use the irq_phys_map parameter in > vgic_update_irq_pending(), so let's just remove it. > > Signed-off-by: Andre Przywara > --- > virt/kvm/arm/vgic.c |

Re: [PATCH v4 7/7] KVM: arm: enable KVM_SIGNAL_MSI and MSI routing

On 04/14/2016 02:12 PM, Christoffer Dall wrote: > On Mon, Apr 04, 2016 at 10:47:37AM +0200, Eric Auger wrote: >> If the ITS modality is not available, let's simply support MSI >> injection by transforming the MSI.data into an SPI ID. >> >> This becomes possible to use KVM_SIGNAL_MSI ioctl and MSI

Re: [RFC PATCH] arm64: Fix EL1/EL2 early init inconsistencies with VHE

Hi Dave, On 18/04/16 18:57, Dave Martin wrote: > When using the Virtualisation Host Extensions, EL1 is not used in > the host and requires no separate configuration. > > In addition, with VHE enabled, non-hyp-specific EL2 configuration > that does not need to be done early will be done anyway in

Re: [RFC v4 0/7] KVM: arm/arm64: gsi routing support

Hi Christoffer, On 04/14/2016 02:04 PM, Christoffer Dall wrote: > On Mon, Apr 04, 2016 at 10:47:30AM +0200, Eric Auger wrote: >> With the advent of GICv3 ITS in-kernel emulation, KVM MSI routing >> becomes mandated for proper VIRTIO-PCI vhost integration. >> >> In QEMU, when the VIRTIO-PCI device

Re: [PATCH v4 1/7] KVM: api: pass the devid in the msi routing entry

Christoffer, On 04/14/2016 02:04 PM, Christoffer Dall wrote: > On Mon, Apr 04, 2016 at 10:47:31AM +0200, Eric Auger wrote: >> On ARM, the MSI msg (address and data) comes along with >> out-of-band device ID information. The device ID encodes the >> device that writes the MSI msg. Let's convey the

Re: [RFC PATCH] arm64: KVM: Allow userspace to configure guest MPIDR_EL1

On Thu, Apr 21, 2016 at 11:56:03AM +0200, Andrew Jones wrote: > On Thu, Apr 21, 2016 at 10:25:24AM +0100, Marc Zyngier wrote: > > Hey Andrew, > > > > On 21/04/16 08:04, Andrew Jones wrote: > > > On Wed, Apr 20, 2016 at 06:33:54PM +0100, Marc Zyngier wrote: > > >> On Wed, 20 Apr 2016 07:08:39

Re: [RFC PATCH] arm64: KVM: Allow userspace to configure guest MPIDR_EL1

On Thu, Apr 21, 2016 at 10:25:24AM +0100, Marc Zyngier wrote: > Hey Andrew, > > On 21/04/16 08:04, Andrew Jones wrote: > > On Wed, Apr 20, 2016 at 06:33:54PM +0100, Marc Zyngier wrote: > >> On Wed, 20 Apr 2016 07:08:39 -0700 > >> Ashok Kumar wrote: > >> > >>> For guests with

Re: [RFC PATCH] arm64: KVM: Allow userspace to configure guest MPIDR_EL1

Hey Andrew, On 21/04/16 08:04, Andrew Jones wrote: > On Wed, Apr 20, 2016 at 06:33:54PM +0100, Marc Zyngier wrote: >> On Wed, 20 Apr 2016 07:08:39 -0700 >> Ashok Kumar wrote: >> >>> For guests with NUMA configuration, Node ID needs to >>> be recorded in the respective

Re: [RFC PATCH] arm64: KVM: Allow userspace to configure guest MPIDR_EL1

On Wed, Apr 20, 2016 at 06:33:54PM +0100, Marc Zyngier wrote: > On Wed, 20 Apr 2016 07:08:39 -0700 > Ashok Kumar wrote: > > > For guests with NUMA configuration, Node ID needs to > > be recorded in the respective affinity byte of MPIDR_EL1. > > As others have said before,