[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 07/14] target/arm/cpu64: max cpu: Introduce s
From: |
Andrew Jones |
Subject: |
Re: [Qemu-devel] [PATCH v2 07/14] target/arm/cpu64: max cpu: Introduce sve<vl-bits> properties |
Date: |
Wed, 17 Jul 2019 10:13:54 +0200 |
User-agent: |
NeoMutt/20180716 |
On Sat, Jun 29, 2019 at 02:10:28AM +0200, Richard Henderson wrote:
> On 6/28/19 9:27 AM, Andrew Jones wrote:
> > Also, while it's true we can always
> > get the max vq with next-smaller(ARM_MAX_VQ + 1), having it cached in
> > cpu->sve_max_vq is convenient. That said, I think we'd rather keep it.
>
> When is it convenient, and for what?
It's used for the upper boundary in several loops in target/arm/kvm64.c
>
> Certainly the only thing that we check after boot is the largest enabled vq
> not
> larger than x. And for that I don't see that sve_max_vq is relevant at all.
>
> Oh, something that we should also think about is -cpu foo, where foo is one of
> the Fujitsu thingumies. We should be able to default sve_vq_map to that which
> a real bit of hw actually supports. I, for one, welcome our typedef long
> overlords. ;-)
I don't think we need to implement an A64FX cpu model with this series,
although that's a nice idea for people that focus on TCG to do as a
follow-up series. This series fully enables the guest to use SVE on the
A64FX when KVM is enabled, without the need to special case it in any way.
Thanks,
drew
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [PATCH v2 07/14] target/arm/cpu64: max cpu: Introduce sve<vl-bits> properties,
Andrew Jones <=