Additional info, I also find that I fail to delete VM (under Comment 0 configuration) on virt-manager.

VM's xml configuration:
...
 <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-rhel8.3.0">hvm</type>
    <boot dev="hd"/>
  </os>
...

When guest in shutoff status, then try to delete it:

Error deleting virtual machine 'rhel8.2-juzhou': Requested operation is not valid: cannot undefine domain with nvram

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1303, in delete
    self._backend.undefineFlags(flags)
  File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2925, in undefineFlags
    if ret == -1: raise libvirtError ('virDomainUndefineFlags() failed', dom=self)
libvirt.libvirtError: Requested operation is not valid: cannot undefine domain with nvram

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/delete.py", line 191, in _async_delete
    vm.delete()
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1307, in delete
    self._backend.undefine()
  File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2889, in undefine
    if ret == -1: raise libvirtError ('virDomainUndefine() failed', dom=self)
libvirt.libvirtError: Requested operation is not valid: cannot undefine domain with nvram


Additionally, there were errors removing certain storage devices: 


-------------------------------------------
The VM can be deleted by # virsh undefine $vm --nvram command, so please fix it together, thanks.

As for the issue from comment 0, this should be fixed upstream already by commit:

commit 15a9502b7b7a263c4d66ff2b3f31c209f58fe0b4
Author:     Lin Ma <lma>
AuthorDate: Wed Jan 15 10:34:12 2020 +0800
Commit:     Cole Robinson <crobinso>
CommitDate: Wed Jan 15 10:21:46 2020 -0500

    details: Fix showing the firmware type in case of firmware auto selection
    
    For a shutoff VM, If user select uefi firmware auto selection, e.g.
    <os firmware='efi'>
    ...
    </os>
    
    Its firmware information is set to 'BIOS' in details, This is incorrect.
    This fixes it.
    
    Reviewed-by: Cole Robinson <crobinso>
    Signed-off-by: Lin Ma <lma>

v2.2.1-157-g15a9502b

For the issue from Comment 0 there is additional patch required from upstream:

commit e8bf16b983558010cc9645e09eb36117e9e4fba4
Author: Pavel Hrdina <phrdina>
Date:   Tue Jul 21 12:33:56 2020 +0200

    details: fix detection of firmware auto-selection

For the issue from Comment 1 please create a new BZ. Both issues are related to firmware autoselection but they are different issues.

(In reply to Pavel Hrdina from comment #4)
> For the issue from Comment 1 please create a new BZ. Both issues are related
> to firmware autoselection but they are different issues.

Thanks Pavel.
I have filed Bug 1869135 to track Comment 1 issue, thanks very much.

I can reproduce this issue with package:
virt-install-2.2.1-3.el8.noarch
virt-manager-common-2.2.1-3.el8.noarch

Steps as Comment 0.

Then try to verify this bug with new build:
virt-manager-common-2.2.1-4.el8.noarch
virt-install-2.2.1-4.el8.noarch
libvirt-6.0.0-30.module+el8.4.0+8705+34397d87.x86_64
qemu-kvm-4.2.0-37.module+el8.4.0+8837+c89bcfe6.x86_64
kernel-4.18.0-249.el8.x86_64

Steps:
1. Prepare a uefi vm with below xml and firmware shows 'UEFI x86_64: /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd' in virt-manager
# virsh dumpxml rhel8.3
....
  <os>
    <type arch='x86_64' machine='pc-q35-rhel8.2.0'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/rhel8.3_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
....

2. Power off vm and add "firmware='efi'" to vm's xml, then check the firmware type via virt-manager.
 

Hypervisor Details
Hypervisor: KVM
Architecture: x86_64
Chipset: Q35
Firmware: UEFI

Result: Firmware shows UEFI correctly.

3. Power on vm to ensure the vm can boot up successfully.
Result: vm can start successfully

3.1 Check guest xml in virt-manger: 
...
  <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-rhel8.2.0">hvm</type>
    <boot dev="hd"/>
  </os>
...

3.2 Check guest xml by virsh edit:
...
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-rhel8.2.0'>hvm</type>
    <boot dev='hd'/>
  </os>

...

3.3 Check guest xml by virsh dumpxml:
...
  <os>
    <type arch='x86_64' machine='pc-q35-rhel8.2.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader>
    <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd'>/var/lib/libvirt/qemu/nvram/rhel8.3_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
...

4. Navigate to "Show virtual hardware details" page, then check the information of Overview tab.

Hypervisor Details
Hypervisor: KVM
Architecture: x86_64
Chipset: Q35
Firmware: /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd

Result: Firmware changes to "/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd" correctly in virt-manager.


So I move this bug from ON_QA to VERIFIED status based on above testing.

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 (virt-manager bug fix and enhancement update), 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-2021:1843