*** Bug 1419983 has been marked as a duplicate of this bug. ***

Upstream patches:
https://www.redhat.com/archives/virt-tools-list/2017-May/msg00138.html

Upstream commits:

commit f38c56c971d8b04bdee41ecba96f3f6d921a4aa7
Author: Pavel Hrdina <phrdina>
Date:   Thu Jan 26 15:08:36 2017 +0100

    virt-install: add support for SMM feature
    
commit 24f9d05329a485c21325fc2e93a283b832359d05
Author: Pavel Hrdina <phrdina>
Date:   Thu Jan 26 16:11:31 2017 +0100

    virt-install: add support for loader secure attribute

commit 4f8e795c6a7158b3da48f65322cabfae1d110cae
Author: Pavel Hrdina <phrdina>
Date:   Mon Feb 6 13:46:06 2017 +0100

    virtinst: if required by UEFI enable SMM feature and set q35 machine type

I can reproduce this bug with package:
virt-manager-1.4.1-5.el7.noarch

Steps:
1. with --boot uefi 
# virt-install --name test --memory 2048 --disk /var/lib/libvirt/images/test,size=8 --boot uefi,loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash -l http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa --graphics vnc

Result:
Cannot connect to guest installation page with console shows: Guest has not initialized the display (yet).

2. without --boot uefi
# virt-install --name test --memory 2048 --disk /var/lib/libvirt/images/test,size=8 --boot loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash -l http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa --graphics vnc

Result: Guest console is black.


Then try to verify this bug with new build:
virt-manager-1.4.1-6.el7.noarch
virt-install-1.4.1-6.el7.noarch
libvirt-3.2.0-7.el7.x86_64
qemu-kvm-rhev-2.9.0-7.el7.x86_64
OVMF-20170228-5.gitc325e41585e3.el7.noarch

Steps:
1. Check virt-install manual page change.
# man virt-install
...
           --features smm=on
               This enables System Management Mode of hypervisor. Some UEFI firmwares may require this feature to be present. (QEMU
               supports SMM only with q35 machine type.)
           --boot loader=/.../OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/.../OVMF_VARS.fd,loader_secure=no
               Specify that the virtual machine use the custom OVMF binary as boot firmware, mapped as a virtual flash chip. In
               addition, request that libvirt instantiate the VM-specific UEFI varstore from the custom "/.../OVMF_VARS.fd" varstore
               template. This is the recommended UEFI setup, and should be used if --boot uefi doesn't know about your UEFI binaries. If
               your UEFI firmware supports Secure boot feature you can enable it via loader_secure.


Result: add support for SMM feature and loader secure attribute.

2. Install a guest with Q35 machine type.

Scenario-1: Use default loader file path.

# virt-install --name test --memory 2048 --disk /var/lib/libvirt/images/test,size=8 --boot uefi  -l http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa --graphics vnc

2.1.1. Check guest xml file.
# virsh dumpxml test
<domain type='kvm' id='76'>
  <name>test</name>
..
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/test_VARS.fd</nvram>
    <kernel>/var/lib/libvirt/boot/virtinst-vmlinuz.7tdn3_</kernel>
    <initrd>/var/lib/libvirt/boot/virtinst-initrd.img.W_WXUf</initrd>
    <cmdline>inst.repo=http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/</cmdline>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <smm state='on'/>
  </features>

Scenario-2: with setting 'loader_secure=no'

# virt-install --name test --memory 2048 --disk /var/lib/libvirt/images/test,size=8 --boot uefi,loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash -l http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa --graphics vnc


2.2.2 Check guest xml file:
# virsh dumpxml test
<domain type='kvm' id='82'>
  <name>test</name>
  <uuid>4fcdcff2-a915-4b8e-ae4f-c25074b71ef1</uuid>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' secure='no' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/test_VARS.fd</nvram>
    <kernel>/var/lib/libvirt/boot/virtinst-vmlinuz.iVrv_O</kernel>
    <initrd>/var/lib/libvirt/boot/virtinst-initrd.img.WMMFUv</initrd>
    <cmdline>inst.repo=http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/</cmdline>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <smm state='on'/>
  </features>

Result:
I. Show guest console successfully and installation finished without error.
II. 'SMM' will be enabled when machine type is Q35.
III. virt-install works well with 'loader_secure=no' attribute.

3. Testing for not specify '--boot uefi' but enable/disable 'loader_secure' attribute.

3.1 loader_ro=yes
# virt-install --name test --memory 2048 --disk /var/lib/libvirt/images/test,size=8 --boot loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash,loader_secure=yes -l http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa 

 Starting install...
 Retrieving file vmlinuz...                                                                                           | 5.6 MB  00:00:00     
 Retrieving file initrd.img...                                                                                        |  48 MB  00:00:00     
 Allocating 'test'                                                                                                    | 8.0 GB  00:00:00     
 ERROR    unsupported configuration: Secure boot is supported with q35 machine types only
 Removing disk 'test'                                                                                                 |    0 B  00:00:00     
 Domain installation does not appear to have been successful.
 If it was, you can restart your domain by running:
   virsh --connect qemu:///system start test
   otherwise, please restart your installation.

Result: Installation failed with error "Secure boot is supported with q35 machine types only" when secure boot enabled.

3.2 loader_ro=no
#  virt-install --name test --memory 2048 --disk /var/lib/libvirt/images/test,size=8 --boot loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash,loader_secure=no -l http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa 

Result: Guest console is 'Black' as Comment 0.


So Pavel, do you think above steps is enough to veirfy this bug, and how about result for step3.2, is it expected? 
Thanks.

(In reply to zhoujunqin from comment #13)
> I can reproduce this bug with package:
> virt-manager-1.4.1-5.el7.noarch
> 
> Steps:
> 1. with --boot uefi 
> # virt-install --name test --memory 2048 --disk
> /var/lib/libvirt/images/test,size=8 --boot
> uefi,loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,
> loader_type=pflash -l
> http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/
> compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa
> --graphics vnc
> 
> Result:
> Cannot connect to guest installation page with console shows: Guest has not
> initialized the display (yet).
> 
> 2. without --boot uefi
> # virt-install --name test --memory 2048 --disk
> /var/lib/libvirt/images/test,size=8 --boot
> loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash
> -l
> http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/
> compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa
> --graphics vnc
> 
> Result: Guest console is black.
> 
> 
> Then try to verify this bug with new build:
> virt-manager-1.4.1-6.el7.noarch
> virt-install-1.4.1-6.el7.noarch
> libvirt-3.2.0-7.el7.x86_64
> qemu-kvm-rhev-2.9.0-7.el7.x86_64
> OVMF-20170228-5.gitc325e41585e3.el7.noarch
> 
> Steps:
> 1. Check virt-install manual page change.
> # man virt-install
> ...
>            --features smm=on
>                This enables System Management Mode of hypervisor. Some UEFI
> firmwares may require this feature to be present. (QEMU
>                supports SMM only with q35 machine type.)
>            --boot
> loader=/.../OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/...
> /OVMF_VARS.fd,loader_secure=no
>                Specify that the virtual machine use the custom OVMF binary
> as boot firmware, mapped as a virtual flash chip. In
>                addition, request that libvirt instantiate the VM-specific
> UEFI varstore from the custom "/.../OVMF_VARS.fd" varstore
>                template. This is the recommended UEFI setup, and should be
> used if --boot uefi doesn't know about your UEFI binaries. If
>                your UEFI firmware supports Secure boot feature you can
> enable it via loader_secure.
> 
> 
> Result: add support for SMM feature and loader secure attribute.
> 
> 2. Install a guest with Q35 machine type.
> 
> Scenario-1: Use default loader file path.
> 
> # virt-install --name test --memory 2048 --disk
> /var/lib/libvirt/images/test,size=8 --boot uefi  -l
> http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/
> compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa
> --graphics vnc
> 
> 2.1.1. Check guest xml file.
> # virsh dumpxml test
> <domain type='kvm' id='76'>
>   <name>test</name>
> ..
>   <os>
>     <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
>     <loader readonly='yes'
> type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
>     <nvram>/var/lib/libvirt/qemu/nvram/test_VARS.fd</nvram>
>     <kernel>/var/lib/libvirt/boot/virtinst-vmlinuz.7tdn3_</kernel>
>     <initrd>/var/lib/libvirt/boot/virtinst-initrd.img.W_WXUf</initrd>
>    
> <cmdline>inst.repo=http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-
> 7.4-20170601.0/compose/Server/x86_64/os/</cmdline>
>     <boot dev='hd'/>
>   </os>
>   <features>
>     <acpi/>
>     <apic/>
>     <smm state='on'/>
>   </features>
> 
> Scenario-2: with setting 'loader_secure=no'
> 
> # virt-install --name test --memory 2048 --disk
> /var/lib/libvirt/images/test,size=8 --boot
> uefi,loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,
> loader_type=pflash -l
> http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/
> compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa
> --graphics vnc

In this scenario you claim that it tests 'loader_secure=no' but the command line doesn't contain it, that seems to be wrong.

> 
> 
> 2.2.2 Check guest xml file:
> # virsh dumpxml test
> <domain type='kvm' id='82'>
>   <name>test</name>
>   <uuid>4fcdcff2-a915-4b8e-ae4f-c25074b71ef1</uuid>
>   <memory unit='KiB'>2097152</memory>
>   <currentMemory unit='KiB'>2097152</currentMemory>
>   <vcpu placement='static'>1</vcpu>
>   <resource>
>     <partition>/machine</partition>
>   </resource>
>   <os>
>     <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
>     <loader readonly='yes' secure='no'
> type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
>     <nvram>/var/lib/libvirt/qemu/nvram/test_VARS.fd</nvram>
>     <kernel>/var/lib/libvirt/boot/virtinst-vmlinuz.iVrv_O</kernel>
>     <initrd>/var/lib/libvirt/boot/virtinst-initrd.img.WMMFUv</initrd>
>    
> <cmdline>inst.repo=http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-
> 7.4-20170601.0/compose/Server/x86_64/os/</cmdline>
>     <boot dev='hd'/>
>   </os>
>   <features>
>     <acpi/>
>     <apic/>
>     <smm state='on'/>
>   </features>
> 
> Result:
> I. Show guest console successfully and installation finished without error.
> II. 'SMM' will be enabled when machine type is Q35.
> III. virt-install works well with 'loader_secure=no' attribute.
> 
> 3. Testing for not specify '--boot uefi' but enable/disable 'loader_secure'
> attribute.
> 
> 3.1 loader_ro=yes

You've probably meant loader_secure=yes

> # virt-install --name test --memory 2048 --disk
> /var/lib/libvirt/images/test,size=8 --boot
> loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash,
> loader_secure=yes -l
> http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/
> compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa 
> 
>  Starting install...
>  Retrieving file vmlinuz...                                                 
> | 5.6 MB  00:00:00     
>  Retrieving file initrd.img...                                              
> |  48 MB  00:00:00     
>  Allocating 'test'                                                          
> | 8.0 GB  00:00:00     
>  ERROR    unsupported configuration: Secure boot is supported with q35
> machine types only
>  Removing disk 'test'                                                       
> |    0 B  00:00:00     
>  Domain installation does not appear to have been successful.
>  If it was, you can restart your domain by running:
>    virsh --connect qemu:///system start test
>    otherwise, please restart your installation.
> 
> Result: Installation failed with error "Secure boot is supported with q35
> machine types only" when secure boot enabled.
> 
> 3.2 loader_ro=no

and loader_secure=no.

> #  virt-install --name test --memory 2048 --disk
> /var/lib/libvirt/images/test,size=8 --boot
> loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash,
> loader_secure=no -l
> http://download.eng.pek2.redhat.com/pub/rhel/rel-eng/RHEL-7.4-20170601.0/
> compose/Server/x86_64/os/ --network type=direct,source=eno1,source_mode=vepa 
> 
> Result: Guest console is 'Black' as Comment 0. 

This is expected, you didn't specified "uefi" or --feature smm=on.

> 
> So Pavel, do you think above steps is enough to veirfy this bug, and how
> about result for step3.2, is it expected? 
> Thanks.

(click "Unwrap comments" near the top)

I started composing this comment before Pavel responded in comment 14. FWIW
I'm going to add this comment anyway, for clarification. So here goes:


Zhoujunqin,

I'm a bit confused by your test steps. The idea is that you *either* use the

(1) --boot uefi

shorthand, and expect it to do all the necessary firmware-related
configuration for you,

*or* else you use the full form

(2)
  --machine ... \
  --features ... \
  --boot loader=...,loader_ro=...,loader_type=...,nvram_template=...,loader_secure=...

Mixing the two forms does not make much sense to me.

If you use (1), then you rely on the logic in virt-install and the libvirt
daemon configuration to select the right firmware binary for you, and to
adapt the rest of the settings correctly.

If you use (2), that means you want to control every single config knob
around firmware / UEFI.

So, on a RHEL-7.4 host specifically, the following test cases should be
checked:

(1) --boot uefi

This should simply do the right thing.

(2) If you want to spell out all the config knobs, this is what should be
used (breaking it up to multiple lines for readability):

  BOOT="loader=/usr/share/OVMF/OVMF_CODE.secboot.fd"
  BOOT="$BOOT,loader_ro=yes"
  BOOT="$BOOT,loader_type=pflash"
  BOOT="$BOOT,nvram_template=/usr/share/OVMF/OVMF_VARS.fd"
  BOOT="$BOOT,loader_secure=yes"

  virt-install \
    --machine q35 \
    --features smm=on \
    --boot "$BOOT" \
    ...

****

Using the following components:
- libvirt: 3.2.0-4.el7.x86_64
- virt-install: 1.4.1-6.el7.noarch

and the default "/etc/libvirt/qemu.conf" file from the
"libvirt-daemon-driver-qemu" package, which has the following "nvram" stanza
(note that it's all commented out):

#nvram = [
#   "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd",
#   "/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd",
#   "/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_VARS.fd"
#]

I actually tested the above scenarios, (1) and (2), as root:

(1) Shorthand command line:

  virt-install --name test-1 --memory 2048 --disk none \
    --location https://da.gd/F25-WS-X64 \
    \
    --boot uefi

In this case, the generated domain XML was (extract from "virsh edit"):

  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/test-1_VARS.fd</nvram>
    ...
  </os>
  <features>
    ...
    <smm state='on'/>
  </features>

This is almost correct; there is one problem: the @secure='yes' attribute is
missing from the <loader> element. That attribute is necessary for QEMU to
actually enforce the protection of the pflash chips (restrict write accesses
to code running in SMM).

This should be fixed.

(2) Full command line:

  BOOT="loader=/usr/share/OVMF/OVMF_CODE.secboot.fd"
  BOOT="$BOOT,loader_ro=yes"
  BOOT="$BOOT,loader_type=pflash"
  BOOT="$BOOT,nvram_template=/usr/share/OVMF/OVMF_VARS.fd"
  BOOT="$BOOT,loader_secure=yes"

  virt-install --name test-2 --memory 2048 --disk none \
    --location https://da.gd/F25-WS-X64 \
    \
    --machine q35 \
    --features smm=on \
    --boot "$BOOT"

This produces the correct domain XML:

  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/test-2_VARS.fd</nvram>
    ...
  </os>
  <features>
    ...
    <smm state='on'/>
  </features>


Summary:

* I think this bug is not fixed yet, because the "--boot uefi" shorthand
  does not automatically set "loader_secure=yes" (even though
  "OVMF_CODE.secboot.fd" is selected correctly). I suggest moving this BZ
  back to ASSIGNED -- I hope that's OK with you, Pavel.

* Zhoujunqin, When verifying the fix, it is enough to check cases (1) and
  (2) listed in this comment.

Thanks,
Laszlo

Upstream patch posted:

https://www.redhat.com/archives/virt-tools-list/2017-June/msg00028.html

Upstream commit:

commit b690908aa47ea4040a0b232328a7b79ff99ceabc
Author: Pavel Hrdina <phrdina>
Date:   Wed Jun 7 20:47:59 2017 +0200

    virtinst: enable secure feature together with smm for UEFI

Try to verify this bug with build:

OVMF-20170228-5.gitc325e41585e3.el7.noarch
virt-manager-1.4.1-7.el7.noarch
virt-install-1.4.1-7.el7.noarch
libvirt-3.2.0-9.el7.x86_64

Steps:
1. Check virt-install manual page change.
# man virt-install
...
           --features smm=on
               This enables System Management Mode of hypervisor. Some UEFI firmwares may require this feature to be present. (QEMU supports SMM only with q35 machine type.)
...
           --boot loader=/.../OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/.../OVMF_VARS.fd,loader_secure=no
               Specify that the virtual machine use the custom OVMF binary as boot firmware, mapped as a virtual flash chip. In addition, request that libvirt instantiate the VM-specific UEFI varstore from
               the custom "/.../OVMF_VARS.fd" varstore template. This is the recommended UEFI setup, and should be used if --boot uefi doesn't know about your UEFI binaries. If your UEFI firmware supports
               Secure boot feature you can enable it via loader_secure.

Result: add support for SMM feature and loader secure attribute.

2. Test guest installation.

2.1 Shorthand command line:

# virt-install  --name test-1 --memory 2048 \
    --disk /var/lib/libvirt/images/test-1.img,size=9 \
    --location http://download.eng.pek2.redhat.com/pub/rhel/released/RHEL-7/7.3/Server/x86_64/os/  \
    --boot uefi


2.1.1 Check the generated domain XML.
# virsh edit test-1
...
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/test-1_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
  <features>
...
    <smm state='on'/>
  </features>


2.2 Full command line:

# BOOT="loader=/usr/share/OVMF/OVMF_CODE.secboot.fd"
# BOOT="$BOOT,loader_ro=yes"
# BOOT="$BOOT,loader_type=pflash"
# BOOT="$BOOT,nvram_template=/usr/share/OVMF/OVMF_VARS.fd"
# BOOT="$BOOT,loader_secure=yes"
# echo $BOOT
loader=/usr/share/OVMF/OVMF_CODE.secboot.fd,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/OVMF/OVMF_VARS.fd,loader_secure=yes

# virt-install --name test-2 --memory 2048 \
   --disk /var/lib/libvirt/images/test-2.img,size=9 \
   --location http://download.eng.pek2.redhat.com/pub/rhel/released/RHEL-7/7.3/Server/x86_64/os/  \
  --machine q35 \
  --features smm=on \
  --boot $BOOT

2.2.1 This produces the correct domain XML:
#virsh edit test-2

...
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/test-2_VARS.fd</nvram>
...
  </os>
  <features>
...
    <smm state='on'/>
  </features>

Summary:
I. the "--boot uefi" shorthand can automatically set "loader_secure=yes" and enable smm features.
II. No black console displays and installation finished successfully.

III. @Pavel, i also tried install a UEFI guest on virt-manager GUI with select
Firmware: UEFI x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd
Chipset: Q35

but i can't find "loader_secure=yes" setting generated in domain xml file, do you think it should be fixed together in this bug, or file a separated bug to track GUI issue, thanks.

  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/rhel7.3-ovmf-normal_VARS.fd</nvram>
...
  </os>
  <features>
...
    <smm state='on'/>
  </features>

@Junqin: that is strange, I've done the GUI installation right now and the
"secure" attribute is set to "yes" in the XML.  Try to run virt-manager with
--debug and when you choose the UEFI Firmware and click apply you should see
what was updated.

(In reply to Pavel Hrdina from comment #28)
> @Junqin: that is strange, I've done the GUI installation right now and the
> "secure" attribute is set to "yes" in the XML.  Try to run virt-manager with
> --debug and when you choose the UEFI Firmware and click apply you should see
> what was updated.

Hi Pavel,
Yes, 'secure=yes' is included in domain xml.
--- Original XML
+++ New XML
@@ -5,12 +5,14 @@
   <currentMemory>1048576</currentMemory>
   <vcpu>1</vcpu>
   <os>
-    <type arch="x86_64">hvm</type>
+    <type arch="x86_64" machine="q35">hvm</type>
+    <loader readonly="yes" type="pflash" secure="yes">/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
   </os>
   <features>
     <acpi/>
     <apic/>
     <vmport state="off"/>
+    <smm state="on"/>
   </features>
   <cpu mode="custom" match="exact">
     <model>Nehalem</model>


I guessed when i verify this bug, i tested it on local and 'ssh root@$ip -X' connections, i forget to restart virt-manager in local when i change virt-manager version.

Sorry for my mistake and thanks for your help.

So I move this bug from ON_QA to VERIFIED.

Created attachment 1289965 [details]
virt-manager debug  info

In order to confirm whether the issue reported in comment 30 is a duplicate of bug 1348092, please capture the OVMF debug log. Thanks!

Created attachment 1290020 [details]
OMVF debug log

OMVF debug log file attached.

(In reply to Laszlo Ersek from comment #33)
> In order to confirm whether the issue reported in comment 30 is a duplicate
> of bug 1348092, please capture the OVMF debug log. Thanks!

Hi,Laszlo

Thanks for your quick reply,I attached ovmf debug log on comment 34.
When I met this problem,the guest is always showed as running when execute "virsh list" which is different from bug 1348092.

Hi Tingting,

(In reply to tingting zheng from comment #35)
> (In reply to Laszlo Ersek from comment #33)
> > In order to confirm whether the issue reported in comment 30 is a duplicate
> > of bug 1348092, please capture the OVMF debug log. Thanks!
> 
> Hi,Laszlo
> 
> Thanks for your quick reply,I attached ovmf debug log on comment 34.

based on the log you uploaded in comment 34, I confirm that you have encountered the same issue that I described in bug 1348092 comment 24.

> When I met this problem,the guest is always showed as running when execute
> "virsh list" which is different from bug 1348092.

That's not necessarily the case in bug 1348092.

* The guest can run into an emulation failure immediately (and then it is displayed as crashed or paused by "virsh list"),
* or else it can crash and reboot a few times before hitting an emulation failure,
* or else it can be stuck in the reboot loop infinitely, in which case "virsh list" will always display it as "running". This is the symptom that you and I both experience when triggering this bug. (See again bug 1348092 comment 24 -- I wrote "in my case it even seems infinite".)

Thanks.

(In reply to Laszlo Ersek from comment #36)
> Hi Tingting,
> 
> (In reply to tingting zheng from comment #35)
> > (In reply to Laszlo Ersek from comment #33)
> > > In order to confirm whether the issue reported in comment 30 is a duplicate
> > > of bug 1348092, please capture the OVMF debug log. Thanks!
> > 
> > Hi,Laszlo
> > 
> > Thanks for your quick reply,I attached ovmf debug log on comment 34.
> 
> based on the log you uploaded in comment 34, I confirm that you have
> encountered the same issue that I described in bug 1348092 comment 24.
> 
> > When I met this problem,the guest is always showed as running when execute
> > "virsh list" which is different from bug 1348092.
> 
> That's not necessarily the case in bug 1348092.
> 
> * The guest can run into an emulation failure immediately (and then it is
> displayed as crashed or paused by "virsh list"),
> * or else it can crash and reboot a few times before hitting an emulation
> failure,
> * or else it can be stuck in the reboot loop infinitely, in which case
> "virsh list" will always display it as "running". This is the symptom that
> you and I both experience when triggering this bug. (See again bug 1348092
> comment 24 -- I wrote "in my case it even seems infinite".)

Thanks for your clear explaination,let's use bug 1348092 to track the issue,thanks again for your help.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2072