We must not steal ownership from the Gen 2 UEFI firmware, since doing so will cause an immediate system crash (most likely in the form of a reboot). This problem was masked before commit a0f6e75 ("[hyperv] Do not fail if guest OS ID MSR is already set"), since prior to that commit we would always fail if we found any non-zero guest OS identity. We now accept a non-zero previous guest OS identity in order to allow for situations such as chainloading from iPXE to another iPXE, and as a prerequisite for commit b91cc98 ("[hyperv] Cope with Windows Server 2016 enlightenments"). A proper fix would be to reverse engineer the UEFI protocols exposed within the Hyper-V Gen 2 firmware and use these to bind to the VMBus device representing the network connection, (with the native Hyper-V driver moved to become a BIOS-only feature). As an interim solution, fail to initialise the native Hyper-V driver if we detect the guest OS identity known to be used by the Gen 2 UEFI firmware. This will cause the standard all-drivers build (ipxe.efi) to fall back to using the SNP driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>tags/v1.20.1
|
|
||
220 |
|
220 |
|
221 |
|
221 |
|
222 |
|
222 |
|
|
223 |
|
|
|
224 |
|
|
|
225 |
|
|
|
226 |
|
|
|
227 |
|
|
|
228 |
|
|
|
229 |
|
|
|
230 |
|
|
|
231 |
|
|
|
232 |
|
|
|
233 |
|
|
|
234 |
|
|
|
235 |
|
|
|
236 |
|
|
|
237 |
|
|
|
238 |
|
|
|
239 |
|
|
|
240 |
|
|
|
241 |
|
|
|
242 |
|
|
|
243 |
|
|
|
244 |
|
|
|
245 |
|
|
223 |
|
246 |
|
224 |
|
247 |
|
225 |
|
248 |
|
|
|
||
556 |
|
579 |
|
557 |
|
580 |
|
558 |
|
581 |
|
|
582 |
|
|
|
583 |
|
|
|
584 |
|
|
|
585 |
|
|
559 |
|
586 |
|
560 |
|
587 |
|
561 |
|
588 |
|
|
|
||
587 |
|
614 |
|
588 |
|
615 |
|
589 |
|
616 |
|
|
617 |
|
|
590 |
|
618 |
|
591 |
|
619 |
|
592 |
|
620 |
|
|
|
||
37 |
|
37 |
|
38 |
|
38 |
|
39 |
|
39 |
|
|
40 |
|
|
|
41 |
|
|
|
42 |
|
|
|
43 |
|
|
|
44 |
|
|
|
45 |
|
|
|
46 |
|
|
40 |
|
47 |
|
41 |
|
48 |
|
42 |
|
49 |
|