Messages in this thread |  | | Date | Sun, 11 Dec 2022 19:44:38 +0900 | Subject | Re: [PATCH 0/3] KVM: arm64: Handle CCSIDR associativity mismatches | From | Akihiko Odaki <> |
| |
On 2022/12/11 19:21, Marc Zyngier wrote: > On Sun, 11 Dec 2022 05:25:31 +0000, > Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >> >> On 2022/12/04 23:57, Marc Zyngier wrote: >>> On Fri, 02 Dec 2022 09:55:24 +0000, >>> Akihiko Odaki <akihiko.odaki@gmail.com> wrote: >>>> >>>> On 2022/12/02 18:40, Marc Zyngier wrote: >>>>> On Fri, 02 Dec 2022 05:17:12 +0000, >>>>> Akihiko Odaki <akihiko.odaki@daynix.com> 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. >
|  |