Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp636647ybp; Wed, 9 Oct 2019 01:39:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqx5BePFeW+XBPzjk23nRcTK8D0xFbZ2k1mooCwj+u/y8JxNABx/3x5UJ/kMwyxceg7Ks2T5 X-Received: by 2002:aa7:d756:: with SMTP id a22mr1886129eds.198.1570610355570; Wed, 09 Oct 2019 01:39:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570610355; cv=none; d=google.com; s=arc-20160816; b=OhE2oK00GHrNr73KfcleTZza7WXDh+xyGepSTct8sFByTdOT6Oj9kN9jYJutZV0Bve YUYP9q7uQqdORL7VaYWrqpjTPGJOQXvWwApf8ylhsZ0rlb2C9P8gd0/t4IqQNokN+YOi +YceOyHP43OSzPzq2+vuy+cBZAwfNq8bv//gHU09rkvnuyNLofIgT+yeVmrCN9DNKLl7 rMiRkwxt8LhgWOEWsaUXcsBjsIeC+gl5cMjWKYrIJBuz/AG+9vo8CIuE9CoqgWRlsudN eVTGUfD61cBkPMtwRHymQ756MifnqeIEkK4GOgjeIcgn/qgGV0Qmxqn3RqDrQAwtszCx +GbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:openpgp:from:references:cc:to:subject; bh=6sCDH8nIKuAbvdBSReQkc1Tfo1aumnautyMnOnbULKw=; b=Fkm5ywAb5erAOGoc8CbU6S5YXIAjbmxTSGcDfnHDm2OsAcdi8njxoW2Kcx1ZBXyjwe GhGpfryWdXIFTBIKnIFHT7oZSVwP42m6vuaoDKkGNQfzcXEEnLxrhDSpHhpIt4y9QbpR XfmgHGrXDw8FfBFuuqVKt9UPOnPZYeRMQFzuzkKsUYBHcFB52idvOxQsM4Db+pGhnGfy Sm2gZG3W05mxh4Co8ba/xJANyYTu7OcmpLUt5d8nkujEANCw1vqtOdxIsielDvNgc801 b0mkOqpyafheEOMYX5KPKM/Cu1n33Ft3LD6Tuxc0LnTKJLq/rbLBgslkn8DqWQdKTLHR PBgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x19si791081eju.15.2019.10.09.01.38.51; Wed, 09 Oct 2019 01:39:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728054AbfJIIiN (ORCPT + 99 others); Wed, 9 Oct 2019 04:38:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54334 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725440AbfJIIiN (ORCPT ); Wed, 9 Oct 2019 04:38:13 -0400 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9565676531 for ; Wed, 9 Oct 2019 08:38:12 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id o10so750317wrm.22 for ; Wed, 09 Oct 2019 01:38:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6sCDH8nIKuAbvdBSReQkc1Tfo1aumnautyMnOnbULKw=; b=JV+bp7pssxGjS35MPdUq4xnhft1MPz6ykpQ3NPvqoJyDsQHazgaHhK5kl5tfyTRJIX A8cvMBJvZjo+3jTWPMY/i5seQx7+O9P9KIx9mPz7X7uXY+x7qPi92IFkUmjoHR+6uZVC Q262kFt2WN+WWi755qHxwkmlrJQKCpfWvkpH3uNSD0hpHqg23t39ZhLTr6wUqsBsYo3y Zk3+18qzx28P+253GSOmQq41JUJ0bS4RuFAewBQNB+WRrKmbBJGTwSwu+VGHvsu7uO31 wZP7YKfSlx9c8b0T+pZJIubRx5XMR9ndVyrU/aFIGyZe8KzotvlYl2SGDkATB4cekmXK wxkw== X-Gm-Message-State: APjAAAUEvLGEwHw7oYFTKAPNX6/WCsxHkc60ztpSFtdAMPC+tBNDs0J2 NSO6+H7gxavYANfJAVJrsXhm5eHXladxbb3gviXe5ySp+Bsu623qNFD7GAF1usGgDAwYNMMgc1o NxkBYgy3ALaw96evgwAJOQ5mr X-Received: by 2002:a1c:3884:: with SMTP id f126mr1648374wma.162.1570610291195; Wed, 09 Oct 2019 01:38:11 -0700 (PDT) X-Received: by 2002:a1c:3884:: with SMTP id f126mr1648349wma.162.1570610290915; Wed, 09 Oct 2019 01:38:10 -0700 (PDT) Received: from [192.168.10.150] ([93.56.166.5]) by smtp.gmail.com with ESMTPSA id q10sm3014658wrd.39.2019.10.09.01.38.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 01:38:10 -0700 (PDT) Subject: Re: [PATCH v3 04/16] kvm: x86: Add support for activate/de-activate APICv at runtime To: "Suthikulpanit, Suravee" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" Cc: "rkrcmar@redhat.com" , "joro@8bytes.org" , "vkuznets@redhat.com" , "graf@amazon.com" , "jschoenh@amazon.de" , "karahmed@amazon.de" , "rimasluk@amazon.com" , "Grimm, Jon" References: <1568401242-260374-1-git-send-email-suravee.suthikulpanit@amd.com> <1568401242-260374-5-git-send-email-suravee.suthikulpanit@amd.com> From: Paolo Bonzini Openpgp: preference=signencrypt Message-ID: <5a5b13e9-4efa-b35c-dc22-003ff3109b07@redhat.com> Date: Wed, 9 Oct 2019 10:38:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <1568401242-260374-5-git-send-email-suravee.suthikulpanit@amd.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/09/19 21:00, Suthikulpanit, Suravee wrote: > + kvm_for_each_vcpu(i, v, kvm) > + kvm_clear_request(KVM_REQ_APICV_DEACTIVATE, v); > + > + if (kvm_x86_ops->pre_update_apicv_exec_ctrl) > + kvm_x86_ops->pre_update_apicv_exec_ctrl(vcpu, true); > + > + kvm->arch.apicv_state = APICV_ACTIVATED; > + > + kvm_make_all_cpus_request(kvm, KVM_REQ_APICV_ACTIVATE); > + > + mutex_unlock(&kvm->arch.apicv_lock); I think a lot of this logic can be simplified. In particular, I would have: - a single KVM_REQ_APICV_TOGGLE request that unifies kvm_vcpu_activate_apicv and kvm_vcpu_deactivate_apicv. The invariant is that, at the end of the function, (vcpu->arch.apicv_active == (kvm->arch.apicv_state = APICV_ACTIVATED)). The apicv_lock then becomes an rwsem, so that kvm_activate_apic and kvm_deactivate_apic will down_write it, while the processing of KVM_REQ_APICV_TOGGLE can down_read it. - the srcu_read_unlock/srcu_read_lock should be hidden in svm_request_activate_avic/svm_request_deactivate_avic. Everything else should only take struct kvm*, following what you've started with patch 1. In particular kvm_vcpu_deactivate_apicv should be changed to take a struct kvm*, so that Hyper-V can do kvm_deactivate_apic(kvm, APIC_DISABLED). Hyper-V should not care about srcu_read_lock/srcu_read_unlock. avic_setup_access_page and avic_destroy_access_page also can be changed to take struct kvm*. Paolo