RedHat discovered issues in Hii feature

[Douglas-Farley]

Internal testing of this branch has uncovered the following problems:

1. With empty OVMF_VARS.fd I found out that only the first configuration gets saved properly. When entering EFI Setup and trying to save changes for the second time, random values get lost. I was e.g. unable to save changes to the DHCP or SubsysNQN options in my boot attempt. Is this a known issue?

2. I was having trouble saving some other non-NBFT settings like the framebuffer resolution. Anyway, made it working once configured fully on a first try.

3. Endianness conversion problem of the hostnqn. Consult this with the attached screenshot:

# nvme nbft show --output-format=json
...
    "host":{
      "nqn":"nqn.2014-08.org.nvmexpress:uuid:12345678-abcd-abcd-abcd-
123456789012",
      "id":"78563412-cdab-cdab-abcd-123456789012",
    },
...

# cat /sys/class/nvme-fabrics/ctl/nvme0/hostnqn
nqn.2014-08.org.nvmexpress:uuid:12345678-abcd-abcd-abcd-123456789012
# cat /sys/class/nvme-fabrics/ctl/nvme0/hostid
78563412-cdab-cdab-abcd-123456789012

Originally posted by @johnmeneghini in https://github.com/timberland-sig/edk2/issues/20#issuecomment-1714299674

[tbzatek]

Detailed testing of the nvmeof_hii-timberland_1.0_final-verified branch (#24) - using Build/OvmfX64/DEBUG_GCC5/FV/OVMF_CODE.fd with clean Build/OvmfX64/DEBUG_GCC5/FV/OVMF_VARS.fd:

• Device Manager -> OVMF Platform Configuration -> Preferred Resolution: changes can't be saved. This works on the master branch (commit 28eb51dd54217d). That's usually a first step I do on a clean efi vars and essentially a random non-Timberland related stuff but it also serves as a sanity check.
• Configure an NVMe-oF attempt, fill in HostNQN, HostID. Save, no error. Reboot and everything works, Linux boots from NBFT. So far so good.
• Enter EFI Setup again, you may see the connected namespace in the Boot Manager menu. Enter previous Attempt configuration and deactivate the Enable DHCP option. Enter IP address, Gateway and Subnet Mask. Hit F10=Save changes, no error. Hit Escape to go to the previous menu, enter the Attempt submenu again and observe that the Enable DHCP option is back active. The three IP addresses are saved though. Same issue with the Subsystem info from DHCP option - changes to that option are ignored after F10 Save. What works is to explicitly select the Save Changes option at the bottom of the form. Usability issue it seems, I always prefer to hit F10 here.
• The HostID endianness issue persists.

[trevor-cockrell]

Thanks @tbzatek , @johnmeneghini,

1. Are subsequent configuration attempts being saved using F10? It looks like this bug might exist in iSCSI's HII and has ended up propagating into NVMeoF's HII due to mimicry. I've identified where this might be fixed, TBD pending testing.

2. It looks like the resolution configuration also fails to save on fff6d81270 (edk2-stable202211) -- pre-timberland. Can you please confirm?

3. In testing with qemu, I did not notice any endianness issues when configuring the system UUID... Can you provide a dmidecode dump for the UUID?

[tbzatek]

1. Are subsequent configuration attempts being saved using F10? It looks like this bug might exist in iSCSI's HII and has ended up propagating into NVMeoF's HII due to mimicry. I've identified where this might be fixed, TBD pending testing.

Retested on timberland_1.0_final (post #24 merge). Starting with clean efivars and pressing F10 only (i.e. no "Save Changes" menu item), going up to the main menu, I don't get any warning about unsaved data. Only half of the attempt information get saved - "Subsystem info" are saved, however the "Enable DHCP" switch is not. Repeated saving by F10 makes no difference. "Subsystem info" gets saved always, "Enable DHCP" switch doesn't. The "Host IP address" in the DHCP section (switch unchecked) seems to get saved as well. The "Network Device" doesn't get saved by F10 either. Neither the "NVM Subsystem" switch on the top.

Only saving via the "Save Changes" menu item works as expected.

2. It looks like the resolution configuration also fails to save on fff6d81270 (edk2-stable202211) -- pre-timberland. Can you please confirm?

Confirming, reproducible on upstream tag edk2-stable202211. Alright, let's forget about this one.

3. In testing with qemu, I did not notice any endianness issues when configuring the system UUID... Can you provide a dmidecode dump for the UUID?

There's no machine UUID supplied on qemu commandline for my VM and also not available in the DMI. dmidecode output attached: dmidecode.txt

Also, this is a value parsed out of the ACPI NBFT table by dracut scripts - is there a direct relation to DMI UUID elsewhere in the code? (apart from what should be the best practice following the official specification - testing a corner case here)