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
