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.
crosvm uses KVM on big.LITTLE processors by pinning
vCPU to physical CPU, and it is a real-world application which needs
to be supported.
For an application like crosvm, you would expect the vCPU thread gets
the MIDR value of the physical CPU which the thread is pinned to when
it calls ioctl, but it can get one of another arbitrary CPU in
reality.
No. It will get the MIDR of the CPU it runs on. Check again. What you
describing above is solely for userspace.
By "ioctl", I meant the value the VMM gets for the vCPU thread. The
problem is that the guest on the vCPU and the VMM issuing ioctl on the
same thread can see different values, and it doesn't seem quite right.
...or we may just say the value of MPIDR_EL0 (and possibly other
I assume you meant MIDR_EL1 here, as MPIDR_EL1 is something else (and
it has no _EL0 equivalent).
Yes, I meant MIDR_EL1.
"invariant" registers) exposed via ioctl are useless and deprecated.
Useless? Not really. The all are meaningful to the guest, and a change
there will cause issues.
CTR_EL0 must, for example, be an invariant. Otherwise, you need to
trap all the CMOs when the {I,D}minLine values that are restored from
userspace are bigger than the ones the HW has. Even worse, when the
DIC/IDC bits are set from userspace while the HW has them cleared: you
cannot mitigate that one, and you'll end up with memory corruption.
I've been toying with the idea of exposing to guests the list of
MIDR/REVIDR the guest is allowed to run on, as a PV service. This
would allow that guest to enable all the mitigations it wants in one
go.
Not sure I have time for this at the moment, but that'd be something
to explore.
[...]
I meant that the values exposed to the VMM via ioctls does not seem
useful. They still need to be exposed to the guest as you say.
Regards,
Akihiko Odaki
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
