ide: include WRITE_DMA_FUA_EXT in enlightened 48-bit LBA setup

[juantian8seattle]

The enlightened HDD path in enlightened_hdd_command() programs high LBA/sector-count registers only for READ_DMA_EXT and WRITE_DMA_EXT. WRITE_DMA_FUA_EXT (0x3D) is also a 48-bit command but was missing from the check, so its high LBA bytes would not be written to the drive registers -- the drive would use stale values.

Add WRITE_DMA_FUA_EXT to the 48-bit LBA branch condition.

Fixes #3061

[Copilot]

Pull request overview

This PR fixes a correctness issue in the IDE enlightened INT13 HDD path by ensuring 48-bit LBA register programming also occurs for WRITE_DMA_FUA_EXT, preventing stale high-LBA / sector-count register values from being used during that command.

Changes:

• Extend the 48-bit LBA command check in enlightened_hdd_command() to include WRITE_DMA_FUA_EXT.

---

You can also share your feedback on Copilot code review. Take the survey.

[jstarks]

Our BIOS never sends this command, does it?

[jstarks]

see comment

[juantian8seattle]

handle_command in hard_drive.rs already accepts FUA_EXT as a 48-bit DMA command (use_48bit_lba: true), and the enlightened path dispatches through it after setting up registers. So if FUA_EXT comes in via the enlightened port, handle_command reads the 48-bit register FIFOs -- but the enlightened path never wrote the high bytes into them. The drive gets stale register values.

This just makes the enlightened register setup consistent with what handle_command already expects.

[juantian8seattle]

Our BIOS never sends this command, does it?

@jstarks -- Good question. I haven't actually audited what our BIOS sends today, so I can't say for sure either way. That's worth investigating separately.

The scope of this PR is narrower though: handle_command() already treats WRITE_DMA_FUA_EXT as a 48-bit DMA command and reads the high-byte register FIFOs. The enlightened path calls into handle_command() after setting up those registers, but skips writing the high bytes for FUA_EXT. So the two code paths disagree on which commands are 48-bit. This one-liner just makes them consistent.

For the broader question -- what does the BIOS actually issue, and should the enlightened path only accept those specific commands vs. covering everything the protocol allows -- I think that deserves its own issue with proper investigation. Happy to file that. Would you be ok merging this consistency fix as-is and tracking the scope question separately?

[juantian8seattle]

@jstarks — Agreed, worth verifying. I don't have access to the BIOS source yet, so filed #3133 to track the audit separately.

This PR remains a narrow consistency fix: \handle_command()\ already treats \WRITE_DMA_FUA_EXT\ as a 48-bit DMA command and reads the high-byte register FIFOs, but the enlightened path skips writing them. The one-liner just makes the two paths agree.