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;
Subject: Re: [PATCH v2] KVM: SVM: Override default MMIO mask if memory
 encryption is enabled
From:   Tom Lendacky <thomas.lendacky@amd.com>
To:     Sean Christopherson <sean.j.christopherson@intel.com>
Cc:     kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        Brijesh Singh <brijesh.singh@amd.com>
References: <d741b3a58769749b7873fea703c027a68b8e2e3d.1577462279.git.thomas.lendacky@amd.com>
 <20200106224931.GB12879@linux.intel.com>
 <f5c2e60c-536f-e0cd-98b9-86e6da82e48f@amd.com>
 <20200106233846.GC12879@linux.intel.com>
 <a4fb7657-59b6-2a3f-1765-037a9a9cd03a@amd.com>
 <20200107222813.GB16987@linux.intel.com>
 <298352c6-7670-2929-9621-1124775bfaed@amd.com>
 <20200107233102.GC16987@linux.intel.com>
 <c60d15f2-ca10-678c-30aa-5369cf3864c7@amd.com>
 <20200108000412.GE16987@linux.intel.com>
 <e2b183a8-ffea-2df4-2929-a7f67cba8a81@amd.com>
Message-ID: <ac5e2a0b-10dc-9750-061c-2b2e44f7d820@amd.com>
Date:   Wed, 8 Jan 2020 12:41:01 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
In-Reply-To: <e2b183a8-ffea-2df4-2929-a7f67cba8a81@amd.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
X-MS-Exchange-CrossTenant-Network-Message-Id: 14b43a1a-e11a-40b2-af32-08d7946a5075
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2020 18:41:03.6736
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Gq765lgufZm3zZ/73EgU+MhnCNGGj4+aHFBeQvuOuLqaN/I+TJdP2JvWhDVTz9XCmp45zcnhbbFNK+RWKBzkGQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3179
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/8/20 7:57 AM, Tom Lendacky wrote:
> On 1/7/20 6:04 PM, Sean Christopherson wrote:
>> On Tue, Jan 07, 2020 at 05:51:51PM -0600, Tom Lendacky wrote:
>>> On 1/7/20 5:31 PM, Sean Christopherson wrote:
>>>> AIUI, using phys_bits=48, then the standard scenario is Cbit=47 and some
>>>> additional bits 46:M are reserved.  Applying that logic to phys_bits=52,
>>>> then Cbit=51 and bits 50:M are reserved, so there's a collision but it's
>>>
>>> There's no requirement that the C-bit correspond to phys_bits. So, for
>>> example, you can have C-bit=51 and phys_bits=48 and so 47:M are reserved.
>>
>> But then using blindly using x86_phys_bits would break if the PA bits
>> aren't reduced, e.g. C-bit=47 and phys_bits=47. AFAICT, there's no
>> requirement that there be reduced PA bits when there is a C-bit.  I'm
>> guessing there aren't plans to ship such CPUs, but I don't see anything
>> in the APM to prevent such a scenario.
> 
> I can add in extra checks to see if C-bit == phys_bits, etc. and adjust
> with appropriate limit checking. It's in the init path, so the extra
> checks aren't a big deal.

Just sent V3 of the patch. I believe I have all the areas we discussed
covered. I also went back to using rsvd_bits() as was used before the
L1TF changes. Let me know what you think.

Thanks,
Tom

> 
> Thanks,
> Tom
> 
>>
>> Maybe the least painful approach would be to go with a version of this
>> patch and add a check that there are indeeded reserved/reduced bits?
>> Probably with a WARN_ON_ONCE if the check fails.
>>