From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A70AC4338F for ; Mon, 9 Aug 2021 09:40:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E95EA60D07 for ; Mon, 9 Aug 2021 09:40:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234685AbhHIJlC (ORCPT ); Mon, 9 Aug 2021 05:41:02 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:28479 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234498AbhHIJk7 (ORCPT ); Mon, 9 Aug 2021 05:40:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628502038; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CtWshAOO+UWfSciG+cfJh+KGwRIb+TkaEybWSY8y0ZY=; b=ObxSSFlOUo8TGVTGNoTRIb/FvgA6rVJqm0o2ZgGPdV9y1usNqpAdzThhbhJQTbYifaU9xU M/TICdvpylBbI1N+iDRRPr3w+fBjanM6lwN2J89cnphoW07wCHsK7fbQj7fURZhIQQ5Toa pLLZrX7hR20kean1Zvu/WSCVPK/xYcQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-517-ZRl7GWxIPMaQPSrG5KvEEw-1; Mon, 09 Aug 2021 05:40:37 -0400 X-MC-Unique: ZRl7GWxIPMaQPSrG5KvEEw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8860ADF8A5; Mon, 9 Aug 2021 09:40:35 +0000 (UTC) Received: from starship (unknown [10.35.206.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2135781F75; Mon, 9 Aug 2021 09:40:29 +0000 (UTC) Message-ID: <5f991ac11006ae890961a76d35a63b7c9c56b47c.camel@redhat.com> Subject: Re: KVM's support for non default APIC base From: Maxim Levitsky To: Sean Christopherson Cc: kvm@vger.kernel.org, "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Jim Mattson , Joerg Roedel , Borislav Petkov , Vitaly Kuznetsov , Wanpeng Li , Paolo Bonzini , Thomas Gleixner , "H. Peter Anvin" , Ingo Molnar , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Date: Mon, 09 Aug 2021 12:40:29 +0300 In-Reply-To: References: <20210713142023.106183-1-mlevitsk@redhat.com> <20210713142023.106183-9-mlevitsk@redhat.com> <564fd4461c73a4ec08d68e2364401db981ecba3a.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2021-08-06 at 21:55 +0000, Sean Christopherson wrote: > On Thu, Jul 22, 2021, Maxim Levitsky wrote: > > On Mon, 2021-07-19 at 18:49 +0000, Sean Christopherson wrote: > > > On Sun, Jul 18, 2021, Maxim Levitsky wrote: > > -> APIC MMIO area has to be MMIO for 'apic_mmio_write' to be called, > > thus must contain no guest memslots. > > If the guest relocates the APIC base somewhere where we have a memslot, > > memslot will take priority, while on real hardware, LAPIC is likely to > > take priority. > > Yep. The thing that really bites us is that other vCPUs should still be able to > access the memory defined by the memslot, e.g. to make it work we'd have to run > the vCPU with a completely different MMU root. That is something I haven't took in the account. Complexity of supporting this indeed isn't worth it. > > > As far as I know the only good reason to relocate APIC base is to access it > > from the real mode which is not something that is done these days by modern > > BIOSes. > > > > I vote to make it read only (#GP on MSR_IA32_APICBASE write when non default > > base is set and apic enabled) and remove all remains of the support for > > variable APIC base. > > Making up our own behavior is almost never the right approach. E.g. _best_ case > scenario for an unexpected #GP is the guest immediately terminates. Worst case > scenario is the guest eats the #GP and continues on, which is basically the status > quo, except it's guaranteed to now work, whereas todays behavior can at least let > the guest function, for some definitions of "function". Well, at least the Intel's PRM does state that APIC base relocation is not guaranteed to work on all CPUs, so giving the guest a #GP is like telling it that current CPU doesn't support it. In theory, a very well behaving guest can catch the exception and fail back to the default base. I don't understand what do you mean by 'guaranteed to now work'. If the guest ignores this #GP and still thinks that APIC base relocation worked, it is its fault. A well behaving guest should never assume that a msr write that failed with #GP worked. > > I think the only viable "solution" is to exit to userspace on the guilty WRMSR. > Whether or not we can do that without breaking userspace is probably the big > question. Fully emulating APIC base relocation would be a tremendous amount of > effort and complexity for practically zero benefit. I have nothing against this as well although I kind of like the #GP approach a bit more, and knowing that there are barely any reasons to relocate the APIC base, and that it doesn't work well, there is a good chance that no one does it anyway (except our kvm unit tests, but that isn't an issue). > > > (we already have a warning when APIC base is set to non default value) > > FWIW, that warning is worthless because it's _once(), i.e. won't help detect a > misbehaving guest unless it's the first guest to misbehave on a particular > instantiation of KVM. _ratelimited() would improve the situation, but not > completely eliminate the possibility of a misbehaving guest going unnoticed. > Anything else isn't an option becuase it's obviously guest triggerable. 100% agree. I'll say I would first make it _ratelimited() for few KVM versions, and then if nobody complains, make it a KVM internal error / #GP, and remove all the leftovers from the code that pretend that it can work. And add a comment explaining *why* as you explained, supporting APIC base relocation isn't worth it. Best regards, Maxim Levitsky >