(1) While the guest is shutdown, attach the UEFI shell ISO as a CD-ROM:

      $ virsh attach-disk f26-ovmf-vm2 \
          /usr/share/edk2/ovmf/UefiShell.iso vdc --type cdrom \
          --mode readonly --config --targetbus virtio
      Disk attached successfully

(2) Change the boot order of the devices so that the CD-ROM with
    'UefiShell.iso' is the first device (boot order starts from '1')
    that the guest boots into:

      $ virsh edit f26-ovmf-vm2
      [...]

    So that the fragment looks as below:

      <disk type='file' device='cdrom'>
        <driver name='qemu' type='raw'/>
        <source file='/usr/share/edk2/ovmf/UefiShell.iso'/>
        <target dev='vdc' bus='virtio'/>
        <readonly/>
      <boot order='1'/>

(3) Start the guest on Serial console:

      [root@taroxhost ~]# virsh start f26-ovmf-vm2 --console
      Domain f26-ovmf-vm2 started
      Connected to domain f26-ovmf-vm2
      Escape character is ^]
      UEFI Interactive Shell v2.1
      EDK II
      UEFI v2.60 (EDK II, 0x00010000)
      Mapping table
            FS0: Alias(s):HD0b:;BLK1:
                PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/HD(1,GPT,C76241E2-7F41-406E-8A6E-A73274B6DE1F,0x800,0x64000)
            FS1: Alias(s):CD1a:;BLK5:
                PciRoot(0x0)/Pci(0x1,0x5)/Pci(0x0,0x0)/CDROM(0x0)
           BLK0: Alias(s):
                PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)
           BLK2: Alias(s):
                PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/HD(2,GPT,E17A8175-6CE8-4E21-801E-4D4D81D00B40,0x64800,0x200000)
           BLK3: Alias(s):
                PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/HD(3,GPT,8712A3D6-2835-49D0-BA37-41F05C14FBD2,0x264800,0x759B000)
           BLK4: Alias(s):
                PciRoot(0x0)/Pci(0x1,0x5)/Pci(0x0,0x0)



      Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
      Shell>

(4) At the UEFI shell prompt, following the instructions from here [*],
    run the following commands ("fs0" -- change into the first device;
    "EnrollDefaultKeys.efi" -- which installs the Microsoft's KEK; and
    "reset" -- UEFI's way of saying reboot):

      [...]
      Shell> fs0:
      FS0:\> EnrollDefaultKeys.efi
      info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
      info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
      FS0:\> reset

(4.a)

    NOTE: If the UEFI Shell doesn't return cleanly after running
    "EnrollDefaultKeys.efi", just force power-off and power-on the guest
    from another shell.  E.g. to force power-off the guest, and start it
    again:

      $ sudo virsh destroy f26-ovmf-vm2
      $ sudo virsh start f26-ovmf-vm2 --console

      [This time boot into the Fedora 26 OS.]

    And on the guest serial console, you see Secure Boot enabled for
    *real*:

      ...
      EFI stub: UEFI Secure Boot is enabled.  
      ...
      [    0.000000] Secure boot enabled and kernel locked down

(5) To double-confirm, inside the guest, run `dmesg`:

      [root@f26-ovmf-vm2 ~]# dmesg | grep -i secure
      [    0.000000] Secure boot enabled and kernel locked down
      [    3.261277] EFI: Loaded cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to '.builtin_trusted_keys'


    * * *

Guest serial console log, QEMU command-line, and resulting libvirt guest XML:

    https://kashyapc.fedorapeople.org/virt/ovmf-sb-smm/secure-boot-for-real/Secure-Boot-enabled-OVMF-guest-serial-console.txt
    https://kashyapc.fedorapeople.org/virt/ovmf-sb-smm/secure-boot-for-real/QEMU-command-line.txt
    https://kashyapc.fedorapeople.org/virt/ovmf-sb-smm/secure-boot-for-real/SB-OVMF-UEFI-Keys-Enrolled-F26-guest.xml