From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <brijesh.ksingh@gmail.com> Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2F1128034C for <edk2-devel@ml01.01.org>; Thu, 23 Mar 2017 09:48:40 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id p22so45625039qka.3 for <edk2-devel@ml01.01.org>; Thu, 23 Mar 2017 09:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8NIlks5kMbE9ujbW/l5YhgpkhtwfnlJXVMuGqUqaeeg=; b=rkYDE/GWoOneZCmKJeL5WNwWlfyOAEM2fMKViy/gS/v3SkAwjKAvD29pKDevZGmm75 A4NuPsxW/E7LaMYXCdd3M1DRwlob1AZWpKjMAfzV54r03843l8eLi6bh9dx1H6Xh+wm4 Uw5lT0zKnUxBYLzutR96lCuRKIrMNaMmUnMPJBIjLdugm37Na7AXZiWZf3eUQUojSsN4 FY/D0V5ndBV4zHTQC7+7vX6PIf8j+Qam+MPEu32/QsHUUkHTW8Hu8GD5cl3pDNrTE9IH UD9JpVV2CR6IseuF5vsB8p65hwo0LW1L+1VEJ50hSr73DNntNDsjL0E72Gmaa0j5aHNk 9x+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8NIlks5kMbE9ujbW/l5YhgpkhtwfnlJXVMuGqUqaeeg=; b=rr9aLwFyOuGlbwjDXIrIycpBYNbs0T1CYqQo5bUeXWsSGssc2+O3WGmBfz7enAN5I1 O41LRHmuGTUASGjiJtpVlwTsK/Xq+rUV1+L+d6mhwKQgT2YTTNh5HO4v+MTMujO5FXtC CJU71PNYgB/D4HvSsaJPbXN8ivLmFRFPRp5bBleC+urEup/vRuNMtZb6JX1z/gzkIF0+ LNPBPmZ1Zje3vKn3+I+eBIzjBsldM7FqB0OBMrTVfFmaU2I/xk2P0tudSt1WI7H26Hcq pJA2o21CQjwTddiTmSuKH5pGmXgo3flPLDxuZnPhV8bgRw9qGLiZEWukf8P6UCiCKvG0 HnlQ== X-Gm-Message-State: AFeK/H3g6knWIpG8aQ3RMrXsOcpXMXe3wihSEWUaQbne6hcrw2WLwhrW6p5dKW+DY/K4TTzjeYtomLw8wC1p/g== X-Received: by 10.55.47.69 with SMTP id v66mr3056330qkh.222.1490287719269; Thu, 23 Mar 2017 09:48:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.182.65 with HTTP; Thu, 23 Mar 2017 09:48:38 -0700 (PDT) In-Reply-To: <cd6f3a99-6080-f68d-1ed9-02822785a492@redhat.com> References: <149013076154.27235.10725020825643505862.stgit@brijesh-build-machine> <149013077498.27235.15379321048646409782.stgit@brijesh-build-machine> <15681e6f-dd58-957a-067f-f1036b31c62d@redhat.com> <CA+HCGMZy4Dc8VxABqeZ_aCQi6EXHHdLCDD-cQfFP6JGsvC9bzw@mail.gmail.com> <cd6f3a99-6080-f68d-1ed9-02822785a492@redhat.com> From: Brijesh Singh <brijesh.ksingh@gmail.com> Date: Thu, 23 Mar 2017 11:48:38 -0500 Message-ID: <CA+HCGMbPRHg18xhJ--jQKMHO-09yqFDiP_7n9_KdSmS56DBVzg@mail.gmail.com> To: Laszlo Ersek <lersek@redhat.com> Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>, "Justen, Jordan L" <jordan.l.justen@intel.com>, edk2-devel@ml01.01.org, "Gao, Liming" <liming.gao@intel.com>, brijesh.singh@amd.com, Leo Duran <leo.duran@amd.com>, Tom Lendacky <Thomas.Lendacky@amd.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [RFC PATCH v2 02/10] OvmfPkg/ResetVector: add memory encryption mask when SEV is enabled X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development <edk2-devel.lists.01.org> List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>, <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe> List-Archive: <http://lists.01.org/pipermail/edk2-devel/> List-Post: <mailto:edk2-devel@lists.01.org> List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help> List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>, <mailto:edk2-devel-request@lists.01.org?subject=subscribe> X-List-Received-Date: Thu, 23 Mar 2017 16:48:40 -0000 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 23, 2017 at 11:16 AM, Laszlo Ersek <lersek@redhat.com> wrote: > On 03/23/17 16:05, Brijesh Singh wrote: > > On Wed, Mar 22, 2017 at 3:20 PM, Laszlo Ersek <lersek@redhat.com> wrote: > > >> In the below logic, which branch exactly (to NoSev) will be taken on > >> Intel processors? > >> > >> > > The below check should branch to NoSev on Intel processor > > (please note that 0x8000_001F is new leaf and may not exist on older AMD > > processor hence we will also branch to NoSev on AMD processor which does > > not support this leaf) > > > > *; Check if we have a valid (0x8000_001F) CPUID leaf > > **mov eax, 0x80000000 > > **cpuid > > **cmp eax, 0x8000001f > > **jl NoSev* > > Yes, I figured that maybe this "highest supported cpuid leaf" check > would catch Intel processors. > > But, what prevents a future Intel processor from exposing such a high > CPUID leaf, for a completely different purpose? Should we not perform > some kind of vendor-id check? (I'm quite unfamiliar with CPUID, as you > can tell, I just seem to recall a comment (from Liming perhaps?) for one > of your MdeModulePkg patches, where he said that directly using a > software-defined CPUID leaf (?) would not be portable across all CPU > vendors, or some such.) > > I had similar question in my mind. Before creating the patch I checked with AMD architecture team. The response was, CPUID 0x8000_001F definition is fixed for x86 architecture. So, if Intel ever decides to report this CPUID leaf then it will comply to exact same definition. I think vendor check is weak, e.g user could change the vendor string through the qemu property which will break this loop. Because of this, I wanted to avoid any kind of vendor string or hypervisor defined CPUID checks inside the code. BTW, in my previous patches I was using KVM software defined CPUID leaf and I got rid of it because hypervisor's are flexiable to define that CPUID in whatever way they want. -Brijesh