On 2022/12/11 19:21, Marc Zyngier wrote:
On Sun, 11 Dec 2022 05:25:31 +0000,
Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote:
On 2022/12/04 23:57, Marc Zyngier wrote:
On Fri, 02 Dec 2022 09:55:24 +0000,
Akihiko Odaki <akihiko.odaki@xxxxxxxxx> wrote:
On 2022/12/02 18:40, Marc Zyngier wrote:
On Fri, 02 Dec 2022 05:17:12 +0000,
Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote:
On M2 MacBook Air, I have seen no other difference in standard ID
registers and CCSIDRs are exceptions. Perhaps Apple designed this way
so that macOS's Hypervisor can freely migrate vCPU, but I can't assure
that without more analysis. This is still enough to migrate vCPU
running Linux at least.
I guess that MacOS hides more of the underlying HW than KVM does. And
KVM definitely doesn't hide the MIDR_EL1 registers, which *are*
different between the two clusters.
It seems KVM stores a MIDR value of a CPU and reuse it as "invariant"
value for ioctls while it exposes the MIDR value each physical CPU
owns to vCPU.
This only affects the VMM though, and not the guest which sees the
MIDR of the CPU it runs on. The problem is that at short of pinning
the vcpus, you don't know where they will run. So any value is fair
game.
Yes, my concern is that VMM can be confused if it sees something
different from what the guest on the vCPU sees.
Well, this has been part of the ABI for about 10 years, since Rusty
introduced this notion of invariant, so userspace is already working
around it if that's an actual issue.
In that case, I think it is better to document that the interface is
not working properly and deprecated.
This means nothing. Deprecating an API doesn't mean we don't support
it and doesn't solve any issue for existing userspace.
I'd rather not change anything, TBH. Existing userspace already knows
how to deal with this,
This would be easily addressed though, and shouldn't result in any
issue. The following should do the trick (only lightly tested on an
M1).
This can be problematic when restoring vcpu state saved with the old
kernel. A possible solution is to allow the userspace to overwrite
MIDR_EL1 as proposed for CCSIDR_EL1.
That would break most guests for obvious reasons. At best what can be
done is to make the MIDR WI.
Making MIDR WI sounds good to me. Either keeping the current behavior or
making it WI, the behavior is better to be documented, I think. The
documentation obviously does not help running existing userspace code
but will be helpful when writing new userspace code or understanding how
existing userspace code works.
Regards,
Akihiko Odaki
M.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
