On Wed, 2024-10-02 at 13:33 +0200, Igor Mammedov wrote: > > It's interesting as an experiment, to prove that Windows is riddled with bugs. > (well, and it could serve as starting point to report issue to MS) > But I'd rather Microsoft fix bugs on their side, instead of putting hacks in > QEMU.
Absolutely. I would very prefer Microsoft to fix the bugs, and to support the 15-bit destination ID enlightenment that KVM, Xen and even Hyper-V all define — instead of randomly putting high bits into the address which ought to cause it to miss the APIC and scribble over memory. The 15-bit extension supports I/O APIC and HPET interrupts too. But I'd like to at least understand the current behaviour and whether there's anything we can do to work around it. > PS: > Given it's AMD cpu, I doubt very much that using intel_iommu would be > accepted by Microsoft as valid complaint though. Well, that argument only makes a little bit more sense than refusing to support an Intel NIC with an AMD CPU. The IOMMU just isn't that tied to the CPU ID. But hey, it's Microsoft. However egregious their deviations from both standards and from common sense, they usually like to claim it's "Working as Designed". But to actually *initialise* the Intel IOMMU and put it into remapping mode, and then to send MSIs formatted for an AMD IOMMU which wasn't actually present in the system, would be a new low even for Microsoft. At *best* they could make a tenuous argument for not supporting the Intel NIC (sorry, I mean the Intel IOMMU) at *all* when running on an AMD CPU.
smime.p7s
Description: S/MIME cryptographic signature
