Hi Marc,
On Wednesday 22 Jan 2020 at 18:56:38 (+0000), Marc Zyngier wrote:
> But maybe this is the reason we've all been waiting for, for which we
> sacrifice 32bit KVM host on the altar of progress, and finally move along.
>
> Will and I are the only known users, and that'd be a good incentive to
> experience some if this 64bit goodness... ;-)
Jumping in this discussion a bit randomly, but I just wanted to share
some thoughts that hopefully are relevant to this discussion and can be
of interest to the community.
Context: we have a use-case where guests would need some degree of memory
protection from the host for confidentiality reasons. We're currently
looking at extending KVM to support this feature by enabling the stage
2 translation for the host (in the NVHE case) so we can prevent it from
accessing private guest memory, in addition to many other changes
required to make this work properly. We're currently at the prototyping
stage, but hopefully we'll be able to share patches soon.
I'm bringing this up now because this particular use-case doesn't seem
relevant in the arm32 world -- all our potential users are on arm64.
However, because of the current structure of the arm/arm64 KVM host
code, making significant arm64-specific changes turns out to be really
hard.
We're currently left with three options:
1. move code from virt/kvm/arm and duplicate it in the arch/arm and
arch/arm64 folders so the arm64 version can diverge. I can imagine
this duplication isn't exactly an appealing solution from a
maintainer's perspective ...
2. do changes in the virt/kvm/arm folder directly, but these must be
met with matching changes in the respective arch/ folders. The
code added to arch/arm, however, would be practically dead code,
largely un-used and un-tested as there will be no real arm32 users
of this feature.
3. have lots of kvm_arm_* callbacks stubbed for arm32, but this tends
to be really hard to apply to this use-case as some of the changes
are really quite intrusive.
Obviously, details matter for all of this, and lots of discussions will
be needed once the patches are on the list.
But the point I'm trying to make here is the following: regardless of
the option we end up choosing (most likely a mix of all three), the sole
fact that we have to deal with this is clearly slowing down development
of the feature.
This would a be perfectly reasonable and acceptable overhead if this had
to be done to keep 32bit KVM host support for a real user community, but
since it doesn't seem to exist (?), fighting with the above options
feels like a lot of wasted efforts. (Note: I am not implying that Will
and you are not real persons, but well, you see what I mean ;-)).
So, this is the end of my daily rant. But hopefully this other example
of a real-world feature that's being held back by the 32bit KVM host
code will be useful background when/if we go ahead and finally decide
stop supporting it.
Thanks,
Quentin
