Re: [PATCH] KVM: arm: get rid of unused arg in cpu_init_hyp_mode()

>From: Miaohe Lin > >As arg dummy is not really needed, there's no need to pass NULL when calling >cpu_init_hyp_mode(). So clean it up. > >Signed-off-by: Miaohe Lin >--- > virt/kvm/arm/arm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/virt/kvm/arm/arm.c b/virt/kvm/

Re: [PATCH] kvm/arm64: change gicv3_cpuif to static likely branch

On 2019/11/30 14:39, Marc Zyngier wrote: On Sat, 30 Nov 2019 03:14:43 +, Heyi Guo wrote: Platforms running hypervisor nowadays are normally powerful servers which at least support GICv3, so it should be better to switch kvm_vgic_global_state.gicv3_cpuif to static likely branch, which can

Re: [PATCH] kvm/arm64: change gicv3_cpuif to static likely branch

On Sat, 30 Nov 2019 03:14:43 +, Heyi Guo wrote: > > Platforms running hypervisor nowadays are normally powerful servers > which at least support GICv3, so it should be better to switch > kvm_vgic_global_state.gicv3_cpuif to static likely branch, which can > reduce two "b" instructions to a si

[PATCH] trivial: kvm/arm: merge cases to reduce code lines

It seems a little confusing for KVM_CAP_ARM_SET_DEVICE_ADDR to have a separate branch while it doesn't have any difference with the above cases. So we merge it to the above cases, which can also save 2 lines. Signed-off-by: Heyi Guo Cc: Marc Zyngier Cc: James Morse Cc: Julien Thierry Cc: Suzu

[PATCH] kvm/arm64: change gicv3_cpuif to static likely branch

Platforms running hypervisor nowadays are normally powerful servers which at least support GICv3, so it should be better to switch kvm_vgic_global_state.gicv3_cpuif to static likely branch, which can reduce two "b" instructions to a single "nop" for GICv3 branches. We don't update arm32 specific c

[PATCH v3] KVM: vgic: Use wrapper function to lock/unlock all vcpus in kvm_vgic_create()

From: Miaohe Lin Use wrapper function lock_all_vcpus()/unlock_all_vcpus() in kvm_vgic_create() to remove duplicated code dealing with locking and unlocking all vcpus in a vm. Reviewed-by: Eric Auger Reviewed-by: Steven Price Signed-off-by: Miaohe Lin --- -v2: Fix some spelling mistake

Re: [PATCH 3/3] target/arm: Handle trapping to EL2 of AArch32 VMRS instructions

On Fri, 29 Nov 2019 at 09:45, Edgar E. Iglesias wrote: > IIRC, the current EL was always known at translation time but I've > not been tracking recent changes. Yes, it's known at translate time, in dc->current_el. (The code is structured to make it difficult to accidentally use info that's not kn

Re: [PATCH 3/3] target/arm: Handle trapping to EL2 of AArch32 VMRS instructions

On Fri, Nov 29, 2019 at 09:24:37AM +, Marc Zyngier wrote: > On 2019-11-29 08:28, Edgar E. Iglesias wrote: > > On Thu, Nov 28, 2019 at 04:17:18PM +, Marc Zyngier wrote: > > > HCR_EL2.TID3 requires that AArch32 reads of MVFR[012] are trapped to > > > EL2, and that HCR_EL2.TID0 does the same f

Re: [PATCH 3/3] target/arm: Handle trapping to EL2 of AArch32 VMRS instructions

On 2019-11-29 08:28, Edgar E. Iglesias wrote: On Thu, Nov 28, 2019 at 04:17:18PM +, Marc Zyngier wrote: HCR_EL2.TID3 requires that AArch32 reads of MVFR[012] are trapped to EL2, and that HCR_EL2.TID0 does the same for reads of FPSID. In order to handle this, introduce a new TCG helper functi

Re: [PATCH 3/3] target/arm: Handle trapping to EL2 of AArch32 VMRS instructions

On Thu, Nov 28, 2019 at 04:17:18PM +, Marc Zyngier wrote: > HCR_EL2.TID3 requires that AArch32 reads of MVFR[012] are trapped to > EL2, and that HCR_EL2.TID0 does the same for reads of FPSID. > In order to handle this, introduce a new TCG helper function that > checks for these control bits bef

Re: [PATCH 2/3] target/arm: Honor HCR_EL2.TID1 trapping requirements

On Thu, Nov 28, 2019 at 04:17:17PM +, Marc Zyngier wrote: > HCR_EL2.TID1 mandates that access from EL1 to REVIDR_EL1, AIDR_EL1 > (and their 32bit equivalents) as well as TCMTR, TLBTR are trapped > to EL2. QEMU ignores it, naking it harder for a hypervisor to Typo: "making it harder" > virtua