Received: by 2002:ab2:b82:0:b0:1f3:401:3cfb with SMTP id 2csp131746lqh; Wed, 27 Mar 2024 17:58:43 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCU6DHVQKG9K0Mgi33mjaBP4xYJkinakB1PKu+UjSB10Plp/+f0P42w6qeF9peXd5t/Sg+UWF1HI80kkzJgyV46/xguFt8xOS+fFZB90xw== X-Google-Smtp-Source: AGHT+IHdWl0jT3V5qC0ttD7ZxVw40ojCeS/n8IAJor2V20No7epkdB3cZxE7O18QufNPpsZB5jNd X-Received: by 2002:a05:620a:2b94:b0:788:4891:53d0 with SMTP id dz20-20020a05620a2b9400b00788489153d0mr1375862qkb.30.1711587522848; Wed, 27 Mar 2024 17:58:42 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711587522; cv=pass; d=google.com; s=arc-20160816; b=h3oXHqTRKtHyr0nExY+xWnsimgOPCiBHzd0n4Ivx/cKj/gZUxow6Ghw19pIl4jbqOa lsv7c+nh7tPzCzhZ9ZB8UE47184q3MFufUOJDLldcUVjfo2q4lkmWnS8fe19Ry1iBabW FN3fYPzGyKM/7WXHxfqzw6hktDvs+aV6WuVvoZ1KFlK8lPY4vGS0w8M9AmJ+neYfpLxr /+qccAI85uYJYVisRZRBzF2w1iYseqDvA3L5xRTB0v0LyF/panruFf5GhjIT4x6uX9wH +/XYdJFCuy5A3U9n9wR8CvtlTSKswI5knjnWZ9gd0BypymxC4Jb+KJs8biFR5xBdn7mS fl9w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=owqYGDEhsmsMjtEMQNQtCdJQalbxD213rKjd87dYN3Y=; fh=gyfTbDhVtny5G8M4LsC5xfniL5xs27IO5eTRfRarmM0=; b=E2P5rU2bp8q4dB/yCqQ9vgodzX6tWv8ABB/xd5Yek18Dp4EdClU3+vgUpQn0J5+oDj Pn2oJiIwX7WmJkTRNldxBapjPBEfrz0kIhdcAlj5ibQwDsLcKDWEQheLjDnoQSK9w1Dd x3n9dOZ+5HgwP6ybAWhD6t2bhwUg4S5EzxsXyp/YM0Q/CDGXHoFK7VM0JsJG5IGT8cdR u7wXgtR6Vzv14DqjCv9ANTSiRPZKYBSp4WPkjKIarRbib6W5fOGFGw0Q4V1NTt9I4NV6 tnizTgEYaPLhnxtBJ2sV1eqoDzJoXzSD+Y9xD6Wj+jMiiC+PstMdNRhRQfPZ8ESWXkLZ VU7w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jIo4pkPm; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-122251-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-122251-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id pi31-20020a05620a379f00b0078a683dabf4si392206qkn.699.2024.03.27.17.58.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 17:58:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-122251-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jIo4pkPm; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-122251-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-122251-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 817651C3029F for ; Thu, 28 Mar 2024 00:58:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8B25B1BDEB; Thu, 28 Mar 2024 00:58:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jIo4pkPm" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C641A17758; Thu, 28 Mar 2024 00:58:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711587512; cv=none; b=S7dLyocJ76TqM5wgwZBlijbHapwmoNCmGVcSL5nzBnhy7XXw3UaZjRLH0IxfutRt2tMAuATI3v2BplkhkKPxA21TVL+RSLdJ/C0bpGQlbPZU6ZhNkGVLF6tUOR5TFpo4KzX6M24NUHgSemjXRTm3CKWbTSaGxMhg4Wp6tXR7RGw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711587512; c=relaxed/simple; bh=SaZQQW6MmOO+CINOodd7ihqukTJxZLgHrUGwNq9UnDw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EwpbNEE0ursg9GFMOfUhc9gIXaYf7S3AIg/Y4vN8B5Xqa9egyA+V/3dC2ygIj0C0vet2q/llJUZBM5R/PT0UQkll4U/3uUJAT7za36/5OHVOBXwNOTOJ4uTj8FYX5VTGmJ/4YSpUOYXH41Vvkty3+VKG4/CbHr/MC/h1rx3y4Fo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jIo4pkPm; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711587511; x=1743123511; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=SaZQQW6MmOO+CINOodd7ihqukTJxZLgHrUGwNq9UnDw=; b=jIo4pkPmMbd4ky5c9bsKO7zAlcnlcdF6ezcWyYHY3JBGMpDAyxiiNb/N gRMQAO51YSUT5DIaiNyuEoHSn/WxrID6fvkNezHQ22BUUZcUS+qqnkkDH W/mrR/GE/X/UOD1Usrx9AXRVq+Kaq2XsxFAY2QmiJieYJTZxkaPK2V729 cA1UMZW+RK/WUYsnGJv0Ih2qZVsOoFmLLIpd4lExje6nktWjyuupfdxY7 jqH+nora2lb27oZjf2vYGN85mUgAuMfJ2yLabxqHxsDA+I7J+LqpWDdV1 T884JbF4Rr2Nc2twlC9/wRrtpLn13n6egvHobQglf8mjoabGg5arYo9s5 g==; X-CSE-ConnectionGUID: WwrfVXMDTv2Csf98KF/4jQ== X-CSE-MsgGUID: WDtP6H45Qj2pz0td4s/u7g== X-IronPort-AV: E=McAfee;i="6600,9927,11026"; a="6835008" X-IronPort-AV: E=Sophos;i="6.07,160,1708416000"; d="scan'208";a="6835008" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2024 17:58:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,160,1708416000"; d="scan'208";a="21162930" Received: from xiaoyaol-hp-g830.ccr.corp.intel.com (HELO [10.124.224.7]) ([10.124.224.7]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2024 17:58:27 -0700 Message-ID: <5f07dd6c-b06a-49ed-ab16-24797c9f1bf7@intel.com> Date: Thu, 28 Mar 2024 08:58:23 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages for unsupported cases To: "Edgecombe, Rick P" , "Gao, Chao" , "Yamahata, Isaku" Cc: "Zhang, Tina" , "seanjc@google.com" , "Huang, Kai" , "pbonzini@redhat.com" , "Chen, Bo2" , "sagis@google.com" , "linux-kernel@vger.kernel.org" , "isaku.yamahata@linux.intel.com" , "Aktas, Erdem" , "sean.j.christopherson@intel.com" , "kvm@vger.kernel.org" , "Yuan, Hang" , "isaku.yamahata@gmail.com" References: <96fcb59cd53ece2c0d269f39c424d087876b3c73.camel@intel.com> <20240325190525.GG2357401@ls.amr.corp.intel.com> <5917c0ee26cf2bb82a4ff14d35e46c219b40a13f.camel@intel.com> <20240325221836.GO2357401@ls.amr.corp.intel.com> <20240325231058.GP2357401@ls.amr.corp.intel.com> <20240325233528.GQ2357401@ls.amr.corp.intel.com> <20db87741e356e22a72fadeda8ab982260f26705.camel@intel.com> <20240326174859.GB2444378@ls.amr.corp.intel.com> <481141ba-4bdf-40f3-9c32-585281c7aa6f@intel.com> <34ca8222fcfebf1d9b2ceb20e44582176d2cef24.camel@intel.com> <873263e8-371a-47a0-bba3-ed28fcc1fac0@intel.com> Content-Language: en-US From: Xiaoyao Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/28/2024 8:45 AM, Edgecombe, Rick P wrote: > On Thu, 2024-03-28 at 08:06 +0800, Xiaoyao Li wrote: >> >> TDX spec states that >> >>    18.2.1.4.1 Memory Type for Private and Opaque Access >> >>    The memory type for private and opaque access semantics, which use a >>    private HKID, is WB. >> >>    18.2.1.4.2 Memory Type for Shared Accesses >> >>    Intel SDM, Vol. 3, 28.2.7.2 Memory Type Used for Translated Guest- >>    Physical Addresses >> >>    The memory type for shared access semantics, which use a shared HKID, >>    is determined as described below. Note that this is different from the >>    way memory type is determined by the hardware during non-root mode >>    operation. Rather, it is a best-effort approximation that is designed >>    to still allow the host VMM some control over memory type. >>      • For shared access during host-side (SEAMCALL) flows, the memory >>        type is determined by MTRRs. >>      • For shared access during guest-side flows (VM exit from the guest >>        TD), the memory type is determined by a combination of the Shared >>        EPT and MTRRs. >>        o If the memory type determined during Shared EPT walk is WB, then >>          the effective memory type for the access is determined by MTRRs. >>        o Else, the effective memory type for the access is UC. >> >> My understanding is that guest MTRR doesn't affect the memory type for >> private memory. So we don't need to zap private memory mappings. > > Right, KVM can't zap the private side. > > But why does KVM have to support a "best effort" MTRR virtualization for TDs? Kai pointed me to this > today and I haven't looked through it in depth yet: > https://lore.kernel.org/kvm/20240309010929.1403984-1-seanjc@google.com/ > > An alternative could be to mirror that behavior, but normal VMs have to work with existing userspace > setup. KVM doesn't support any TDs yet, so we can take the opportunity to not introduce weird > things. Not to provide any MTRR support for TD is what I prefer. >> >>>>>> But guests won't accept memory again because no one >>>>>> currently requests guests to do this after writes to MTRR MSRs. In this case, >>>>>> guests may access unaccepted memory, causing infinite EPT violation loop >>>>>> (assume SEPT_VE_DISABLE is set). This won't impact other guests/workloads on >>>>>> the host. But I think it would be better if we can avoid wasting CPU resource >>>>>> on the useless EPT violation loop. >>>>> >>>>> Qemu is expected to do it correctly.  There are manyways for userspace to go >>>>> wrong.  This isn't specific to MTRR MSR. >>>> >>>> This seems incorrect. KVM shouldn't force userspace to filter some >>>> specific MSRs. The semantic of MSR filter is userspace configures it on >>>> its own will, not KVM requires to do so. >>> >>> I'm ok just always doing the exit to userspace on attempt to use MTRRs in a TD, and not rely on >>> the >>> MSR list. At least I don't see the problem. >> >> What is the exit reason in vcpu->run->exit_reason? >> KVM_EXIT_X86_RDMSR/WRMSR? If so, it breaks the ABI on >> KVM_EXIT_X86_RDMSR/WRMSR. > > How so? Userspace needs to learn to create a TD first. The current ABI of KVM_EXIT_X86_RDMSR/WRMSR is that userspace itself sets up MSR fitler at first, then it will get such EXIT_REASON when guest accesses the MSRs being filtered. If you want to use this EXIT reason, then you need to enforce userspace setting up the MSR filter. How to enforce? If not enforce, but exit with KVM_EXIT_X86_RDMSR/WRMSR no matter usersapce sets up MSR filter or not. Then you are trying to introduce divergent behavior in KVM.