| Message ID | 20241218105345.73472-1-shameerali.kolothum.thodi@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: arm64: Errata management for VM Live migration | expand |
Hi Shameer, On Wed, 18 Dec 2024 10:53:42 +0000, Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote: > > Hi, > > v3 --> v4(Minor updates) > https://lore.kernel.org/kvmarm/20241209115311.40496-1-shameerali.kolothum.thodi@huawei.com/ > > -Changed MIDR/REVIDR to 64 bits based on feedback from Connie > and Marc(Patch #3). > -Added R-by tags from Sebastian (Thanks!). Thanks again for putting this together. I think it would be really good to have a sample userspace implementation of this extension so that we can play with it for real before fully committing to it. I am also wondering is we should make it mandatory that a guest is presented with an MIDR_EL1.Implementer value set to 0, which denotes SW use, and would make it plain to the guest (and crucially, guest userspace) that we are going to play tricks. Thoughts? M.
On Thu, Dec 19, 2024 at 10:07:39AM +0000, Marc Zyngier wrote: > Hi Shameer, > > On Wed, 18 Dec 2024 10:53:42 +0000, > Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote: > > > > Hi, > > > > v3 --> v4(Minor updates) > > https://lore.kernel.org/kvmarm/20241209115311.40496-1-shameerali.kolothum.thodi@huawei.com/ > > > > -Changed MIDR/REVIDR to 64 bits based on feedback from Connie > > and Marc(Patch #3). > > -Added R-by tags from Sebastian (Thanks!). > > Thanks again for putting this together. > > I think it would be really good to have a sample userspace > implementation of this extension so that we can play with it for real > before fully committing to it. > > I am also wondering is we should make it mandatory that a guest is > presented with an MIDR_EL1.Implementer value set to 0, which denotes > SW use, and would make it plain to the guest (and crucially, guest > userspace) that we are going to play tricks. > > Thoughts? I see no issues with giving userspace the option of doing this, but I'd rather not enforce this to use the PV interface. At least in a cloud setting it seems highly likely that you'd be running a mix of guests on the same VM definition, some aware of the PV interface and others not. If we use a software MIDR, all old VMs will lose errata mitigations and whatever else userspace might key off of MIDR. Userspace can make the call whether or not a VM can be migrated onto a different implementation based on whether or not the guest used the hypercall interface. And maybe just terminate the VM if it didn't.
Hi, v3 --> v4(Minor updates) https://lore.kernel.org/kvmarm/20241209115311.40496-1-shameerali.kolothum.thodi@huawei.com/ -Changed MIDR/REVIDR to 64 bits based on feedback from Connie and Marc(Patch #3). -Added R-by tags from Sebastian (Thanks!). Thanks, Shameer RFC v2 --> v3 https://lore.kernel.org/kvmarm/20241024094012.29452-1-shameerali.kolothum.thodi@huawei.com/ -Addressed comments from Oliver(Thanks!). -Using implementation CPUs MIDR/REVIDR when it is set for _midr_range() functions(Patch 1 & 3) -New hypercall for retrieving implementation CPUs(Patch #2). -Dropped RFC. RFC v1 --> RFCv2: https://lore.kernel.org/kvmarm/20241011075053.80540-1-shameerali.kolothum.thodi@huawei.com/ -Introduced hypercalls to retrieve target CPUs info from user space VMM. see patch #1 for details. -Patch #2 uses the hypercall to retrieve the target CPU info if any. -Use the target CPUs MIDR/REVIDR in errata enablement. See patch #3. Background from v1: On ARM64 platforms most of the errata workarounds are based on CPU MIDR/REVIDR values and a number of these workarounds need to be implemented by the Guest kernel as well. This creates a problem when Guest needs to be migrated to a platform that differs in these MIDR/REVIDR values even if the VMM can come up with a common minimum feature list for the Guest using the recently introduced "Writable ID registers" support. (This is roughly based on a discussion I had with Marc and Oliver at KVM forum. Marc outlined his idea for a solution and this is an attempt to implement it. Thanks to both and I take all the blame if this is nowhere near what is intended/required) Shameer Kolothum (3): arm64: Modify _midr_range() functions to read MIDR/REVIDR internally KVM: arm64: Introduce hypercall support for retrieving target implementations arm64: paravirt: Enable errata based on implementation CPUs Documentation/virt/kvm/arm/hypercalls.rst | 30 +++++++++++++ arch/arm64/include/asm/cputype.h | 51 ++++++++++++++++------- arch/arm64/include/asm/mmu.h | 3 +- arch/arm64/include/asm/paravirt.h | 3 ++ arch/arm64/kernel/cpu_errata.c | 37 +++++++++++----- arch/arm64/kernel/cpufeature.c | 8 ++-- arch/arm64/kernel/image-vars.h | 2 + arch/arm64/kernel/paravirt.c | 31 ++++++++++++++ arch/arm64/kernel/proton-pack.c | 17 ++++---- arch/arm64/kvm/vgic/vgic-v3.c | 2 +- drivers/clocksource/arm_arch_timer.c | 2 +- include/linux/arm-smccc.h | 7 ++++ 12 files changed, 152 insertions(+), 41 deletions(-)