Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4722026pxv; Tue, 6 Jul 2021 07:40:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9h0YB8LFCq5Xq1bzHHRZ7GgBWA0xPZSVQHcECFyT1LgaqRixpIcLPbgfKA5XfrDvG7j12 X-Received: by 2002:a05:6402:134d:: with SMTP id y13mr23138122edw.216.1625582440847; Tue, 06 Jul 2021 07:40:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625582440; cv=none; d=google.com; s=arc-20160816; b=XPT6OtmH2NruJv31Q/vLyFoayXPpMTMat9nzKKTonNLjadSSnh/+aeVHlWwz0RFD4/ HPzdAbN2n7ZzORBzlYrFbivHQOdSN0ksZwnOgx8KueBCAoWAeYPllt9yjQVVn013g71D zjWkkgZsTZECI2cJbQNHucCad7lMEqq04CBKnP2s6MEicPD23jR2JK9V6pmMZddOZhNl 0oYHpziC0+HaPR7oWCe7ubHTT2cL51X/WUdtlfzX+DZTdSW8aiYdF+napPYI7YZyDMrD pVw09QGfwnqgtl5ZU2onl7SZeXKkNgU/krSlSbvuPSlVJwtSvM+Q9hB+wrfzBJK9+NAL tesw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=+TFQQRr4n0iTcvgZJfJSvRK8tc2ECNv5rYzqu0pkJ5A=; b=i8KS1SaNVcOW/Kmkkpl//itlYOnqITkBif9TdlyZ+xW3fm5l4tIDBcB6YlBSaNRQoI r4f54uSOr5jJQN0C6F/L7V0RGVwLXU/YuGPAhJ7IjHvlamXS5GMZDlSO15Gb0pmAxP4I ctDk3LWXgxJWoVslgnNrpgaOK4MV1htEKpOk+6uYme9BsdWsOneHCzHGAnCzXRKKnUR2 94pABeCSXC3EMbVangmOTg4NmieCfU6KEjIn065hS7K92+jkLEoP+R1xPHhY43E6nR2L VlaeQqnIKHg53ZZ0MQzcvIGXUv7IG+q+0KZ3TeuTHYjpvuXvpkoy15RfgUXYfDXxjb0e pLfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NxJvDVwc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gt34si10324206ejc.285.2021.07.06.07.40.17; Tue, 06 Jul 2021 07:40:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NxJvDVwc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232308AbhGFOgI (ORCPT + 99 others); Tue, 6 Jul 2021 10:36:08 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:54775 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232218AbhGFOgE (ORCPT ); Tue, 6 Jul 2021 10:36:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625582005; 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=+TFQQRr4n0iTcvgZJfJSvRK8tc2ECNv5rYzqu0pkJ5A=; b=NxJvDVwcxLzCmpjxm6F8L4eKIW2KFfW46HX8b110437LrQPCDjPea+/3ZsEXOLw3JdUmV9 qis35E/Qwxu1LOCiqHyAYCQYykx7IqjcZY7ShyUV+7etnvJEH721o6hxUvWfN3i2oehi6S VYTlYPoPEH06lnh9yWLLiFz0244kowE= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-149-P4OhN_qSMRes23dITwIzDg-1; Tue, 06 Jul 2021 10:03:13 -0400 X-MC-Unique: P4OhN_qSMRes23dITwIzDg-1 Received: by mail-ed1-f72.google.com with SMTP id i8-20020a50fc080000b02903989feb4920so5385891edr.1 for ; Tue, 06 Jul 2021 07:03: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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+TFQQRr4n0iTcvgZJfJSvRK8tc2ECNv5rYzqu0pkJ5A=; b=KubtNJB+WG5L5PTbMAlsfpoWDH22nUcb7b6TIV3rY8bwnrYDRmCl9tVQZNp99WWdO/ eQaYp+7fjQEP5ZgYBxaQVRZ9NFP9BlG38SxhP5a7K9A2j9h81GxLm3JYvzlTk4+Dcshq Rgp4G3m4K3mgsAkuvmDGkCe4Yve+v9+bt1I5c6rE2pUlkhTxRthGewd0nOK+betD/jFV zwpeWWWrTlqnAanGtZW/U+4eNhNYDQUhAhclJPmkMKH1UXkBhvMR7pFWDtGXYL7OXGQ5 ZsVztVCSi4jFy/oxQUYirqnUoxKjJWpUFFDo0CKM5bnwlz+0fAmfrOR4aJoiWR9LBUKx YwkQ== X-Gm-Message-State: AOAM530BFmpuvA13z9npGY2ogSqiaYBF8epSXU74mMGq/GOH7TYYtPqF sbF31Lv7/37bZUp2QLjpDJRU2UTYwUuFWcJbZoybvIcL8TgROlkiQqx7OMCw9i7GcAnwwaScL0q tToupuTQPUIu7NXBQH5xpTj6D X-Received: by 2002:a17:906:6047:: with SMTP id p7mr18568843ejj.206.1625580191678; Tue, 06 Jul 2021 07:03:11 -0700 (PDT) X-Received: by 2002:a17:906:6047:: with SMTP id p7mr18568797ejj.206.1625580191361; Tue, 06 Jul 2021 07:03:11 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id b5sm3300742ejz.122.2021.07.06.07.03.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 07:03:10 -0700 (PDT) Subject: Re: [RFC PATCH v2 28/69] KVM: Add per-VM flag to mark read-only memory as unsupported To: isaku.yamahata@intel.com, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , erdemaktas@google.com, Connor Kuehl , Sean Christopherson , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Brijesh Singh Cc: isaku.yamahata@gmail.com, Sean Christopherson References: <1eb584469b41775380ab0a5a5d31a64e344b1b95.1625186503.git.isaku.yamahata@intel.com> From: Paolo Bonzini Message-ID: <8c57204e-385e-1f54-cb15-760e174d122e@redhat.com> Date: Tue, 6 Jul 2021 16:03:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1eb584469b41775380ab0a5a5d31a64e344b1b95.1625186503.git.isaku.yamahata@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/21 00:04, isaku.yamahata@intel.com wrote: > From: Isaku Yamahata > > Add a flag for TDX to flag RO memory as unsupported and propagate it to > KVM_MEM_READONLY to allow reporting RO memory as unsupported on a per-VM > basis. TDX1 doesn't expose permission bits to the VMM in the SEPT > tables, i.e. doesn't support read-only private memory. > > Signed-off-by: Isaku Yamahata > Co-developed-by: Sean Christopherson > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/x86.c | 4 +++- > include/linux/kvm_host.h | 4 ++++ > virt/kvm/kvm_main.c | 8 +++++--- > 3 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index cd9407982366..87212d7563ae 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -3897,7 +3897,6 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ASYNC_PF_INT: > case KVM_CAP_GET_TSC_KHZ: > case KVM_CAP_KVMCLOCK_CTRL: > - case KVM_CAP_READONLY_MEM: > case KVM_CAP_HYPERV_TIME: > case KVM_CAP_IOAPIC_POLARITY_IGNORED: > case KVM_CAP_TSC_DEADLINE_TIMER: > @@ -4009,6 +4008,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > if (static_call(kvm_x86_is_vm_type_supported)(KVM_X86_TDX_VM)) > r |= BIT(KVM_X86_TDX_VM); > break; > + case KVM_CAP_READONLY_MEM: > + r = kvm && kvm->readonly_mem_unsupported ? 0 : 1; > + break; > default: > break; > } > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index ddd4d0f68cdf..7ee7104b4b59 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -597,6 +597,10 @@ struct kvm { > unsigned int max_halt_poll_ns; > u32 dirty_ring_size; > > +#ifdef __KVM_HAVE_READONLY_MEM > + bool readonly_mem_unsupported; > +#endif > + > bool vm_bugged; > }; > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 52d40ea75749..63d0c2833913 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -1258,12 +1258,14 @@ static void update_memslots(struct kvm_memslots *slots, > } > } > > -static int check_memory_region_flags(const struct kvm_userspace_memory_region *mem) > +static int check_memory_region_flags(struct kvm *kvm, > + const struct kvm_userspace_memory_region *mem) > { > u32 valid_flags = KVM_MEM_LOG_DIRTY_PAGES; > > #ifdef __KVM_HAVE_READONLY_MEM > - valid_flags |= KVM_MEM_READONLY; > + if (!kvm->readonly_mem_unsupported) > + valid_flags |= KVM_MEM_READONLY; > #endif > > if (mem->flags & ~valid_flags) > @@ -1436,7 +1438,7 @@ int __kvm_set_memory_region(struct kvm *kvm, > int as_id, id; > int r; > > - r = check_memory_region_flags(mem); > + r = check_memory_region_flags(kvm, mem); > if (r) > return r; > > For all these flags, which of these limitations will be common to SEV-ES and SEV-SNP (ExtINT injection, MCE injection, changing TSC, read-only memory, dirty logging)? Would it make sense to use vm_type instead of all of them? I guess this also guides the choice of whether to use a single vm-type for TDX and SEV-SNP or two. Probably two is better, and there can be static inline bool functions to derive the support flags from the vm-type. Paolo