From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Fri, 26 Apr 2019 14:26:06 -0700 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7CC9A30BC135; Fri, 26 Apr 2019 21:26:05 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-104.rdu2.redhat.com [10.10.121.104]) by smtp.corp.redhat.com (Postfix) with ESMTP id 513B15C221; Fri, 26 Apr 2019 21:26:03 +0000 (UTC) Subject: Re: [edk2-devel] reg : UEFI Secure Boot is stuck with Black Screen To: devel@edk2.groups.io, pavankumar_a@accelerite.com References: From: "Laszlo Ersek" Message-ID: Date: Fri, 26 Apr 2019 23:26:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Fri, 26 Apr 2019 21:26:05 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Pavan, On 04/25/19 12:37, Pavan Kumar Aravapalli wrote: > Hi > > I am new to this and i am trying to perform Windows Server 2016 [Guest VM] UEFI secure boot mode on KVM(Hypervisor) Host using edk2.git-ovmf-x64-0-20190308.1017.g0eccea3fbe.noarch.I am looking for support documents which helps me in assessing the same. > > > Environment Details > > KVM Host :RHEL 7.3 > > Guest VM : Windows Server 2016 > > Qemu Version : qemu-kvm-ev-2.9.0-16.el7_4.13.1 This environment appears a bit mixed-up to me. Here's why: - the "edk2.git" package is neither from RHEL nor from CentOS. It's from . - you list the KVM host as RHEL 7.3, but your QEMU version is from CentOS -- what's more, the version number in the RPM indicates it is a package from 7.4 Z-Stream. If you have access to RHEL7 (or CentOS), I'd suggest using everything from RHEL-7.6 (or equivalent CentOS). [...] > Libvirt Domain XML > > (Side hint: when using "virsh dumpxml" on an active domain, it's usually good to include "--inactive". Runtime details just muddy the picture, most of the time.) > > wus > > 97777f3a-089c-4dae-b192-070a5c676084 > > 2097152 > > 2097152 > > 2 > > > > /machine > > > > > > hvm > > /usr/share/OVMF/OVMF_CODE.secboot.fd The domain XML looks OK thus far, but this firmware binary is certainly not from "edk2.git-ovmf-x64-0-20190308.1017.g0eccea3fbe.noarch". It's from an "OVMF" RPM. > > /var/lib/libvirt/qemu/nvram/wus_VARS.fd Regarding the domain XML, this looks good again. And now I can also tell that you are using "OVMF-20180508-2.gitee3198e672e2.el7.noarch" from RHEL-7.6 (or later), because we added the "/usr/share/OVMF/OVMF_VARS.secboot.fd" varstore template under . > > > > > > > > > > > > Looks good too. > > > > > Penryn > Yes, I'm fairly sure this is the problem. Presumably, you chose the Penryn VCPU model because your host CPU is a Penryn too. Unfortunately, that physical CPU does not support EPT (nested paging), and KVM currently fails to emulate SMM on Intel CPUs without nested paging (EPT). And, the OVMF image we ship in RHEL7 requires SMM. Please refer to the following RHBZ comment: https://bugzilla.redhat.com/show_bug.cgi?id=1531373#c2 and that RHBZ is a duplicate of the host kernel issue https://bugzilla.redhat.com/show_bug.cgi?id=1348092 Your domain XML looks good to me, otherwise (i.e., apart from Penryn).Thus, I suggest retrying (a) on an Intel host that has "ept" in "/proc/cpuinfo", or (b) on an AMD host. (IIRC, KVM doesn't need nested paging for SMM emulation on AMD, although nested paging certainly helps with performance on AMD too -- look for "npt" in "/proc/cpuinfo" on AMD). Don't forget to refresh the VCPU model in the domain XML too. Thanks, Laszlo