linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/7] KVM: arm: vgic-new: improve compatibility with 32-bit
Date: Mon, 5 Sep 2016 13:29:04 +0200	[thread overview]
Message-ID: <20160905112904.GH26366@cbox> (raw)
In-Reply-To: <1471344418-19568-4-git-send-email-vladimir.murzin@arm.com>

Hi Vladimir,

I think commit title is too vague, can you be more specific?

On Tue, Aug 16, 2016 at 11:46:54AM +0100, Vladimir Murzin wrote:
> We have couple of 64-bit register defined in GICv3 architecture, so

'a couple',  'registers' (plural)

> "unsigned long" kind of accessors wouldn't work for 32-bit. However,

'wouldn't work for 32-bit' is kind of generic as well.  Perhaps you mean
that unsigned long accesses to these registers will only access a single
32-bit work of that register.

> these registers can't be access as 64-bit in a one go if we run 32-bit

'accessed', 's/in one go/with a single instruction/' ?

'a 32-bit host'

> host simply because KVM doesn't support multiple load/store on MMIO

by 'multiple load/store' you mean the 'load/store multiple' instructions
specifically, right?  Not a sequence of multiple loads and stores.  I
think you should be more specific here as well, for example, I think
ldrd and strd are problematic as well.

> space.
> 
> It means that 32-bit guest access these registers in 32-bit chunks, so

'a 32-bit guest', 'accesses'

> the only thing we need to do is to ensure that extract_bytes() always
> takes 64-bit data.
> 
> Since we are here fix couple of other width related issues by using
> ULL variants over UL.
> 
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
>  virt/kvm/arm/vgic/vgic-mmio-v3.c |    6 +++---
>  virt/kvm/arm/vgic/vgic-mmio.h    |    2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> index ff668e0..cc20b60 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -23,7 +23,7 @@
>  #include "vgic-mmio.h"
>  
>  /* extract @num bytes at @offset bytes offset in data */
> -unsigned long extract_bytes(unsigned long data, unsigned int offset,
> +unsigned long extract_bytes(u64 data, unsigned int offset,
>  			    unsigned int num)
>  {
>  	return (data >> (offset * 8)) & GENMASK_ULL(num * 8 - 1, 0);
> @@ -179,7 +179,7 @@ static unsigned long vgic_mmio_read_v3r_typer(struct kvm_vcpu *vcpu,
>  	int target_vcpu_id = vcpu->vcpu_id;
>  	u64 value;
>  
> -	value = (mpidr & GENMASK(23, 0)) << 32;
> +	value = (mpidr & GENMASK_ULL(23, 0)) << 32;

why does this make a difference when mpidr is an unsigned long?

>  	value |= ((target_vcpu_id & 0xffff) << 8);
>  	if (target_vcpu_id == atomic_read(&vcpu->kvm->online_vcpus) - 1)
>  		value |= GICR_TYPER_LAST;
> @@ -603,7 +603,7 @@ void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg)
>  	bool broadcast;
>  
>  	sgi = (reg & ICC_SGI1R_SGI_ID_MASK) >> ICC_SGI1R_SGI_ID_SHIFT;
> -	broadcast = reg & BIT(ICC_SGI1R_IRQ_ROUTING_MODE_BIT);
> +	broadcast = reg & BIT_ULL(ICC_SGI1R_IRQ_ROUTING_MODE_BIT);
>  	target_cpus = (reg & ICC_SGI1R_TARGET_LIST_MASK) >> ICC_SGI1R_TARGET_LIST_SHIFT;
>  	mpidr = SGI_AFFINITY_LEVEL(reg, 3);
>  	mpidr |= SGI_AFFINITY_LEVEL(reg, 2);
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
> index 0b3ecf9..80f92ce 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.h
> +++ b/virt/kvm/arm/vgic/vgic-mmio.h
> @@ -96,7 +96,7 @@ unsigned long vgic_data_mmio_bus_to_host(const void *val, unsigned int len);
>  void vgic_data_host_to_mmio_bus(void *buf, unsigned int len,
>  				unsigned long data);
>  
> -unsigned long extract_bytes(unsigned long data, unsigned int offset,
> +unsigned long extract_bytes(u64 data, unsigned int offset,
>  			    unsigned int num);
>  
>  u64 update_64bit_reg(u64 reg, unsigned int offset, unsigned int len,
> -- 
> 1.7.9.5
> 

  reply	other threads:[~2016-09-05 11:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 10:46 [PATCH v2 0/7] ARM: KVM: Support for vgic-v3 Vladimir Murzin
2016-08-16 10:46 ` [PATCH v2 1/7] arm64: KVM: Move GIC accessors to arch_gicv3.h Vladimir Murzin
2016-09-05 11:28   ` Christoffer Dall
2016-09-06 12:33     ` Vladimir Murzin
2016-08-16 10:46 ` [PATCH v2 2/7] arm64: KVM: Move vgic-v3 save/restore to virt/kvm/arm/hyp Vladimir Murzin
2016-08-16 10:46 ` [PATCH v2 3/7] KVM: arm: vgic-new: improve compatibility with 32-bit Vladimir Murzin
2016-09-05 11:29   ` Christoffer Dall [this message]
2016-09-06 12:41     ` Vladimir Murzin
2016-09-06 13:22       ` Christoffer Dall
2016-09-06 13:54         ` Vladimir Murzin
2016-09-06 16:31           ` Christoffer Dall
2016-09-07  9:06             ` Vladimir Murzin
2016-09-07  9:43               ` Christoffer Dall
2016-08-16 10:46 ` [PATCH v2 4/7] ARM: update MPIDR accessors macro Vladimir Murzin
2016-09-05 11:29   ` Christoffer Dall
2016-09-06 12:42     ` Vladimir Murzin
2016-08-16 10:46 ` [PATCH v2 5/7] ARM: move system register accessors to asm/cp15.h Vladimir Murzin
2016-09-05 11:29   ` Christoffer Dall
2016-09-06 13:05     ` Vladimir Murzin
2016-09-06 16:34       ` Christoffer Dall
2016-08-16 10:46 ` [PATCH v2 6/7] ARM: KVM: Get ready to use vgic-v3 Vladimir Murzin
2016-09-05 11:29   ` Christoffer Dall
2016-09-06 13:12     ` Vladimir Murzin
2016-09-06 16:49       ` Christoffer Dall
2016-08-16 10:46 ` [PATCH v2 7/7] ARM: KVM: Unlock vgic-v3 support Vladimir Murzin
2016-09-05 11:29   ` Christoffer Dall
2016-09-06 13:08     ` Marc Zyngier
2016-09-06 13:18     ` Vladimir Murzin
2016-09-06 16:52       ` Christoffer Dall
2016-09-06 13:23     ` Vladimir Murzin
2016-09-06 16:55       ` Christoffer Dall
2016-09-07 10:48         ` Vladimir Murzin
2016-09-07 12:58           ` Christoffer Dall
2016-09-07 14:20             ` Peter Maydell
2016-09-07 14:47               ` Christoffer Dall
2016-09-05 11:28 ` [PATCH v2 0/7] ARM: KVM: Support for vgic-v3 Christoffer Dall
2016-09-06 12:32   ` Vladimir Murzin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160905112904.GH26366@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).