On Wed, Jul 24, 2024, Jim Mattson wrote: > On Wed, Jul 24, 2024 at 11:13 AM Maxim Levitsky <mlevitsk@xxxxxxxxxx> wrote: > > What if we introduce a new KVM capability, say CAP_DISABLE_UNSUPPORTED_FEATURES, > > and when enabled, outright crash the guest when it attempts things like > > changing APIC base, APIC IDs, and other unsupported things like that? > > > > Then we can make qemu set it by default, and if users have to use an > > unsupported feature, they could always add a qemu flag that will disable > > this capability. > > Alternatively, why not devise a way to inform userspace that the guest > has exercised an unsupported feature? Unless you're a hobbyist working on > your desktop, kernel messages are a *terrible* mechanism for communicating > with the end user. A per-vCPU/VM stat would suffice in most cases, e.g. similar to the proposed auto-EOI stat[*]. But I honestly don't see the point for APIC base relocation and changing x2APIC IDs. We _know_ these things don't work. Having a flag might save a bit of triage when debugging a guest issue, but I fail to see what userspace would do with the information outside of a debug scenario. And for APIC base relocation, userspace already has the ability to detect this unuspported behavior. Trap writes to MSR_IA32_APICBASE via MSR filtering, then reflect the value back into KVM. Performance would suck, but writes to MSR_IA32_APICBASE should be very rare, especially if the host forces x2APIC via guest firmware. As for changing x2APIC IDs, that is the architectural behavior on Intel. If a kernel is trying to change x2APIC IDs, it's going to have a bad day regardless. So I guess the question is, what motivated this patch?
