Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp731476pxm; Fri, 25 Feb 2022 18:35:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJyOHjRZ6gezVi0B5LYIUs/KP3oyOLFB2v9LO6/UVHgCmEyTEbyUpu1gycLwlEJGrurlFIPf X-Received: by 2002:a17:90a:9408:b0:1b5:3908:d3d1 with SMTP id r8-20020a17090a940800b001b53908d3d1mr6012401pjo.188.1645842944609; Fri, 25 Feb 2022 18:35:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645842944; cv=none; d=google.com; s=arc-20160816; b=E9tA4BQIVSy8SPCCtFBWu2i5mZOjfORWWVksJVPjcGvLIrF3T0yZyHgrp+H393Mu9f 1t8bTNwm488KBt+FPENIXXQZo5h0PjdFeh1GSlC2rg/E8TkoCkBAXYX611V32azpFhkg Cl+klTIZbuz/XzJL5KrvpvChsW2nCtjXREU7AZlfA6WEQ8qN9TuAiWA+xYMVLi5Fu6rL kFvApD7HRSmQdzg0hrlyNp27+ZiS+v+Y1zBp+dTfSgbKxVL25Gy8oqH8rZdQZP8WhOn3 r52wgBBrR+VzBOkuI+hV6CGNIrk3ECqS4xsz2j1NL0Uct/+qSMYJbFgkNLRwtwdgkzbs Vdiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=38BODecDhesVl9jpdYIHZFI7lHOcsXVLQj6WlTlICL4=; b=CqyUjSl2IP6Qj4OExZOyud0MiqR1J+G6V3F+6gvVRXLoBNPeV1iFqai6NEBiOEMfpb twIMOaal1qp/QkvluoSm+V4lojgf/uGZwsObHi0ecnyGTBg/wT3AYXLDGWJ1nz3G05R9 d4x+8xQO3WE/Zr+1JlcgbNXVIlPHOiLG81soe4bji72o5jlzOK+0Z9hOy+NcVa+qFx4i 8cO4x+Jg9nDCa5nEDVSQrA+V84W1FUAAPlSjNjubARGWWxtWt02DfHFNWSeJica4jHzg FG5CNNNan03T4XIfok2LSVRvucFnfECvO3RHuXSXnVMHmCCm2iSAOtkWRb7LdA1uGwYl nadw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=deAWGU8x; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id v189-20020a622fc6000000b004f115743599si2837986pfv.314.2022.02.25.18.35.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 18:35:44 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=deAWGU8x; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5AB7E2F933F; Fri, 25 Feb 2022 18:01:30 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241827AbiBYOo7 (ORCPT + 99 others); Fri, 25 Feb 2022 09:44:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241711AbiBYOo4 (ORCPT ); Fri, 25 Feb 2022 09:44:56 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5B51A1FEDA9 for ; Fri, 25 Feb 2022 06:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645800263; 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=38BODecDhesVl9jpdYIHZFI7lHOcsXVLQj6WlTlICL4=; b=deAWGU8xd7L/88wEi/m46EFfj2tPa4988nzD/eWB118drvC6Zv/vZcebWY+seiK4V6sGdq NKEhXdQ4dSe7eMIFta9r1q+Rfqd9UIGc8+xy+l8SZTGZXZMaETt1BnMvieShFOXaQQD23P lmtZ8262VAr7x6lc6siSuXHbFcwP8+I= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-201-Oyt-b35CMfGP-7ElCxJH_w-1; Fri, 25 Feb 2022 09:44:18 -0500 X-MC-Unique: Oyt-b35CMfGP-7ElCxJH_w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6C57EFC80; Fri, 25 Feb 2022 14:44:15 +0000 (UTC) Received: from starship (unknown [10.40.195.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id 13DD927CC5; Fri, 25 Feb 2022 14:44:06 +0000 (UTC) Message-ID: <91235d07cad41a75282df7fc222514dc1e991118.camel@redhat.com> Subject: Re: [PATCH v6 5/9] KVM: x86: Add support for vICR APIC-write VM-Exits in x2APIC mode From: Maxim Levitsky To: Zeng Guang , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, Dave Hansen , Tony Luck , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , Kai Huang Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Robert Hu , Gao Chao Date: Fri, 25 Feb 2022 16:44:05 +0200 In-Reply-To: <20220225082223.18288-6-guang.zeng@intel.com> References: <20220225082223.18288-1-guang.zeng@intel.com> <20220225082223.18288-6-guang.zeng@intel.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.84 on 10.5.11.23 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-02-25 at 16:22 +0800, Zeng Guang wrote: > Upcoming Intel CPUs will support virtual x2APIC MSR writes to the vICR, > i.e. will trap and generate an APIC-write VM-Exit instead of intercepting > the WRMSR. Add support for handling "nodecode" x2APIC writes, which > were previously impossible. > > Note, x2APIC MSR writes are 64 bits wide. > > Signed-off-by: Zeng Guang > --- > arch/x86/kvm/lapic.c | 25 ++++++++++++++++++++++--- > 1 file changed, 22 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > index 629c116b0d3e..e4bcdab1fac0 100644 > --- a/arch/x86/kvm/lapic.c > +++ b/arch/x86/kvm/lapic.c > @@ -67,6 +67,7 @@ static bool lapic_timer_advance_dynamic __read_mostly; > #define LAPIC_TIMER_ADVANCE_NS_MAX 5000 > /* step-by-step approximation to mitigate fluctuation */ > #define LAPIC_TIMER_ADVANCE_ADJUST_STEP 8 > +static int kvm_lapic_msr_read(struct kvm_lapic *apic, u32 reg, u64 *data); > > static inline void __kvm_lapic_set_reg(char *regs, int reg_off, u32 val) > { > @@ -2227,10 +2228,28 @@ EXPORT_SYMBOL_GPL(kvm_lapic_set_eoi); > /* emulate APIC access in a trap manner */ > void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset) > { > - u32 val = kvm_lapic_get_reg(vcpu->arch.apic, offset); > + struct kvm_lapic *apic = vcpu->arch.apic; > + u64 val; > + > + if (apic_x2apic_mode(apic)) { > + /* > + * When guest APIC is in x2APIC mode and IPI virtualization > + * is enabled, accessing APIC_ICR may cause trap-like VM-exit > + * on Intel hardware. Other offsets are not possible. > + */ > + if (WARN_ON_ONCE(offset != APIC_ICR)) > + return; > > - /* TODO: optimize to just emulate side effect w/o one more write */ > - kvm_lapic_reg_write(vcpu->arch.apic, offset, val); > + kvm_lapic_msr_read(apic, offset, &val); > + if (val & APIC_ICR_BUSY) > + kvm_x2apic_icr_write(apic, val); > + else > + kvm_apic_send_ipi(apic, (u32)val, (u32)(val >> 32)); I don't fully understand the above code. First of where kvm_x2apic_icr_write is defined? Second, I thought that busy bit is not used in x2apic mode? At least in intel's SDM, section 10.12.9 'ICR Operation in x2APIC Mode' this bit is not defined. Best regards, Maxim Levitsky > + } else { > + val = kvm_lapic_get_reg(apic, offset); > + /* TODO: optimize to just emulate side effect w/o one more write */ > + kvm_lapic_reg_write(apic, offset, (u32)val); > + } > } > EXPORT_SYMBOL_GPL(kvm_apic_write_nodecode); >