All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: kvmarm@lists.cs.columbia.edu, kvm <kvm@vger.kernel.org>
Subject: Re: KVM works on RPi4
Date: Sat, 29 Jun 2019 23:42:32 +0100	[thread overview]
Message-ID: <20190629234232.484ca3c0@why> (raw)
In-Reply-To: <1d1198c2-f362-840d-cb14-9a6d74da745c@web.de>

On Sat, 29 Jun 2019 19:09:37 +0200
Jan Kiszka <jan.kiszka@web.de> wrote:

Hi Jan,

> Hi all,
> 
> just got KVM running on the Raspberry Pi4. Seems they now embedded all
> required logic into that new SoC.

Yeah, someone saw the light and decided to enter the 21st century by
attaching a GICv2 to the thing. Who knows, they may plug a GICv3 and a
SMMU in 2050 at that rate! ;-)

> However, as the Raspberry kernel is not yet ready for 64-bit (and
> upstream is not in sight), I had to use legacy 32-bit mode. And there we
> stumble over the core detection. This little patch made it work, though:
> 
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index 2b8de885b2bf..01606aad73cc 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -290,6 +290,7 @@ int __attribute_const__ kvm_target_cpu(void)
>  	case ARM_CPU_PART_CORTEX_A7:
>  		return KVM_ARM_TARGET_CORTEX_A7;
>  	case ARM_CPU_PART_CORTEX_A15:
> +	case ARM_CPU_PART_CORTEX_A72:
>  		return KVM_ARM_TARGET_CORTEX_A15;
>  	default:
>  		return -EINVAL;
> 
> That raises the question if this is hack or a valid change and if there
> is general interest in mapping 64-bit cores on 32-bit if they happen to
> run in 32-bit mode.

The real thing to do here would be to move to a generic target, much
like we did on the 64bit side. Could you investigate that instead? It
would also allow KVM to be used on other 32bit cores such as
A12/A17/A32.

Although some would argue that the *real* real thing to do would be "rm
-rf arch/arm/kvm" and be done with it, but that's a discussion for next
week... ;-)

> Jan
> 
> PS: The RPi device tree lacks description of the GICH maintenance
> interrupts. Seems KVM is fine without that - because it has the
> information hard-coded or because it can live without that interrupt?

Nah, it really should have an interrupt here. You can end-up in
situation where new virtual interrupts are delayed until the next
natural exit if you don't get a maintenance interrupt. Feels like a bug.

Anyway, if you know of any effort to get a 64bit kernel on that thing,
I'm interested in helping. I bought one on Monday, but didn't get a
change to do any hacking on it just yet...

Thanks,

	M.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: kvmarm@lists.cs.columbia.edu, kvm <kvm@vger.kernel.org>,
	Christoffer Dall <christoffer.dall@arm.com>
Subject: Re: KVM works on RPi4
Date: Sat, 29 Jun 2019 23:42:32 +0100	[thread overview]
Message-ID: <20190629234232.484ca3c0@why> (raw)
In-Reply-To: <1d1198c2-f362-840d-cb14-9a6d74da745c@web.de>

On Sat, 29 Jun 2019 19:09:37 +0200
Jan Kiszka <jan.kiszka@web.de> wrote:

Hi Jan,

> Hi all,
> 
> just got KVM running on the Raspberry Pi4. Seems they now embedded all
> required logic into that new SoC.

Yeah, someone saw the light and decided to enter the 21st century by
attaching a GICv2 to the thing. Who knows, they may plug a GICv3 and a
SMMU in 2050 at that rate! ;-)

> However, as the Raspberry kernel is not yet ready for 64-bit (and
> upstream is not in sight), I had to use legacy 32-bit mode. And there we
> stumble over the core detection. This little patch made it work, though:
> 
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index 2b8de885b2bf..01606aad73cc 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -290,6 +290,7 @@ int __attribute_const__ kvm_target_cpu(void)
>  	case ARM_CPU_PART_CORTEX_A7:
>  		return KVM_ARM_TARGET_CORTEX_A7;
>  	case ARM_CPU_PART_CORTEX_A15:
> +	case ARM_CPU_PART_CORTEX_A72:
>  		return KVM_ARM_TARGET_CORTEX_A15;
>  	default:
>  		return -EINVAL;
> 
> That raises the question if this is hack or a valid change and if there
> is general interest in mapping 64-bit cores on 32-bit if they happen to
> run in 32-bit mode.

The real thing to do here would be to move to a generic target, much
like we did on the 64bit side. Could you investigate that instead? It
would also allow KVM to be used on other 32bit cores such as
A12/A17/A32.

Although some would argue that the *real* real thing to do would be "rm
-rf arch/arm/kvm" and be done with it, but that's a discussion for next
week... ;-)

> Jan
> 
> PS: The RPi device tree lacks description of the GICH maintenance
> interrupts. Seems KVM is fine without that - because it has the
> information hard-coded or because it can live without that interrupt?

Nah, it really should have an interrupt here. You can end-up in
situation where new virtual interrupts are delayed until the next
natural exit if you don't get a maintenance interrupt. Feels like a bug.

Anyway, if you know of any effort to get a 64bit kernel on that thing,
I'm interested in helping. I bought one on Monday, but didn't get a
change to do any hacking on it just yet...

Thanks,

	M.

  reply	other threads:[~2019-06-29 22:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-29 17:09 KVM works on RPi4 Jan Kiszka
2019-06-29 17:09 ` Jan Kiszka
2019-06-29 22:42 ` Marc Zyngier [this message]
2019-06-29 22:42   ` Marc Zyngier
2019-06-30  9:34   ` Jan Kiszka
2019-06-30  9:34     ` Jan Kiszka
2019-06-30 10:18     ` Jan Kiszka
2019-06-30 10:18       ` Jan Kiszka
2019-06-30 10:49       ` Jan Kiszka
2019-06-30 10:49         ` Jan Kiszka
2019-07-01  8:18         ` Vladimir Murzin
2019-07-01  8:18           ` Vladimir Murzin
2019-08-26  8:38       ` Christoffer Dall
2019-08-26  8:38         ` Christoffer Dall
2019-08-26 12:00         ` Peter Maydell
2019-08-26 12:00           ` Peter Maydell

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=20190629234232.484ca3c0@why \
    --to=marc.zyngier@arm.com \
    --cc=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.