Comment 32 for bug 1725560

Using the script from comment#30:

QEMU machine OVMF time from launch to
          type first install screen
-------- ------- --------------------- --------------------
v2.8.1.1 pc 704b71d7e11f 117 s
v2.8.1.1 pc 704b71d7e11f\6fb8ddd36bde 44 s

v2.8.1.1 q35 704b71d7e11f 9 s
v2.8.1.1 q35 704b71d7e11f\6fb8ddd36bde 9 s

v2.10.1 pc 704b71d7e11f 119 s
v2.10.1 pc 704b71d7e11f\6fb8ddd36bde 46 s

v2.10.1 q35 704b71d7e11f 10 s
v2.10.1 q35 704b71d7e11f\6fb8ddd36bde 9 s

Observe:

- The QEMU release plays no role

- on q35 the boot is generally much faster than i440fx

- q35 is unaffected by edk2 commit 6fb8ddd36bde

- on i440fx, reverting edk2 commit 6fb8ddd36bde on top of current master
  (704b71d7e11f) decreases the wall clock time from ~118s to ~45s.

To me this totally looks like a Windows bug; edk2 commit 6fb8ddd36bde does
the right thing. The patch disables PCI bus master DMA for the IDE/AHCI
controller in question at ExitBootServices(), i.e. when the OS gains control
of the system from the firmware. At that point ownership of the RAM is
transferred to the OS, and in-flight DMA has to be aborted (otherwise DMA
pending from the firmware could overwrite RAM that is now owned by the OS).
Whether a controller is passed -- from firmware to the OS -- with DMA
enabled vs. DMA disabled in the PCI command register, should have zero
consequence on how the OS drives the controller subsequently, with its own
native driver.

BTW, I've also noticed that a large chunk of the delay, with i440fx, is not
even spent loading data from the IDE CD-ROM. IDE emulation means host CPU
load, but in this case, Windows just sits there with the empty
purplish/bluish screen, and there is zero host CPU load -- nothing happens.
It's as if Windows was waiting for some timer to expire.