Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp904906pxp; Wed, 16 Mar 2022 20:48:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEbbNA2RLfyY17rQPbwdJi0WU7mjy/8KVhOXPRY/rGbXceNtZRqrNQGegfLxRQr3d1fs6k X-Received: by 2002:a17:90b:1e47:b0:1bf:6d79:b1fd with SMTP id pi7-20020a17090b1e4700b001bf6d79b1fdmr13778534pjb.49.1647488880583; Wed, 16 Mar 2022 20:48:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647488880; cv=none; d=google.com; s=arc-20160816; b=PH9tNlIRwr23WD7c/yz6cqsMps79ltPxMW1Kz3LMNlAHK3h93tlVnHqa///1HXYDvm NWogpeKbTyRQlPfsuHBTnCkAKnLXduXa8WuG+VZ9GPZeCKN2xhB56HflIEW5eurumB55 8DLwhrtl5Giie4iLaMiAsguZqjh2rgMjG6YaqJRILlMs3PZMSJng/0i2EyvUFK2smtws L+VNs6UuRYgutheYSGQpS1tC3J2YHzEvAgIVZycIVDcarsVD1kDbUUeRzByzRnmBZ98K i45WdHT4tomEtmBhhXAgwwWh3Stz6CfmwTaTF8h+Ew5AkEAeeZ8en/XCjXBmHy+ddHv8 W63A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=+r4VOvJw2eWYfd03k9rqVM6zoe6yGjoATInronbTGa8=; b=uEQgNRpqVgPC2lqtSG4OIvMxIVPJ7M/8wBQ6x7SW41kQz4+bDswZTEphPUSznGpKlF hZWz87e3wS2K2Trxwtr8VAoXk82Bj2wjySfamJtga1k1/fg1wW1DwIQWinT2KrrV3ILQ KXbx3tdqR0i79kgLuh3tlIJg9MVpzytLzKjwcmj9vDMh97cTiiCYxBvIEpQVjhhemRdk aiGP/TgIKXfdOJ1Z0ZlKXwuFckgGPqv16IUgLP0tGVV4OUZZXb6yBZ+4QVsWFeqj/HnS l9Onsq50KwWMV30st77iApukb0GldRXOMbdpbuCApoooAytqD6w0+APtJW8ve4sd9xc7 Qx6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZAs8cRTG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id f33-20020a631f21000000b003816043eef9si961333pgf.238.2022.03.16.20.48.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 20:48:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZAs8cRTG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8E745647C; Wed, 16 Mar 2022 20:38:04 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355478AbiCPLwX (ORCPT + 99 others); Wed, 16 Mar 2022 07:52:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355413AbiCPLwV (ORCPT ); Wed, 16 Mar 2022 07:52:21 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F76963515; Wed, 16 Mar 2022 04:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647431468; x=1678967468; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=i/v3E4RJIm6gecB7pSj0ZbHHvH0XR3ySxeRDA6z9eYg=; b=ZAs8cRTG1ogBx1lqDOR5SXrsAWzkJObuD2vAhUYgmDM4Dr8RMPUt3YKp UkNd94+QQBz2Cd5L+MUJR0d5Gf7iavKvYXKGRGRpR3kQM4TMt9ZjDQrGD JTizY6OFCxnv0FKjTsWB1nLZVNme9FlMNvfmXjPDS8YVS9J7ot1YKCzaD MJE6Au912DrZqmoEEfMiykU2JKk02qhvwl2Z741wI5V9RtOmaPVSp0pI5 a5UjqT2y7fvJwPzB+IshH96cKb7hcl2Mo9SnySt46AM2mFjLsvrSTLFQU ar0j02qSqF96y3iWg8pn/icbao+VmJZFhNV0482YrBufMyz28iGRSC1kU w==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="255388249" X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="255388249" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2022 04:51:07 -0700 X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="557401762" Received: from gao-cwp.sh.intel.com (HELO gao-cwp) ([10.239.159.23]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2022 04:51:02 -0700 Date: Wed, 16 Mar 2022 19:50:59 +0800 From: Chao Gao To: Maxim Levitsky Cc: Zeng Guang , Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , "kvm@vger.kernel.org" , Dave Hansen , "Luck, Tony" , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , "Huang, Kai" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Hu, Robert" Subject: Re: [PATCH v6 6/9] KVM: x86: lapic: don't allow to change APIC ID unconditionally Message-ID: <20220316115057.GA22309@gao-cwp> References: <6dc7cff15812864ed14b5c014769488d80ce7f49.camel@redhat.com> <29c76393-4884-94a8-f224-08d313b73f71@intel.com> <01586c518de0c72ff3997d32654b8fa6e7df257d.camel@redhat.com> <2900660d947a878e583ebedf60e7332e74a1af5f.camel@redhat.com> <20220313135335.GA18405@gao-cwp> <20220315151033.GA6038@gao-cwp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.5 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=unavailable 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 Tue, Mar 15, 2022 at 05:30:32PM +0200, Maxim Levitsky wrote: >Yep, I have a patch for this ( which I hope to be accepted really soon >(KVM: x86: SVM: allow AVIC to co-exist with a nested guest running) > >I also implemented working support for nested AVIC, which includes support for IPI without vm exits >between L2's vCPUs. I had sent an RFC for that. > >With all patches applied both L1 and L2 switch hands on AVIC, L1's avic is inhibited >(only locally) on the vCPU which runs nested, and while it runs nested, L2 uses AVIC >to target other vCPUs which also run nested. > >I and Paolo talked about this, and we reached a very promising conclusion. > >I will add new KVM cap, say KVM_CAP_READ_ONLY_APIC, which userspace will set >prior to creating a vCPU, and which will make APIC ID fully readonly when set. Will KVM report violations to QEMU? then, QEMU can know the VM attempted to change APIC ID and report an error to admin. Then admin can relaunch the VM without setting this new cap. > >As a bonus, if you don't object, I will also make this cap, make APIC base read-only, >since this feature is also broken in kvm, optional in x86 spec, and not really >used by guests just like writable apic id. > >I hope to have patches in day or two for this. Great. And no objection to making APIC base read-only.