Thanks David for all the analysis.

> On 11 Jul 2024, at 4:53 PM, David Woodhouse <dw...@infradead.org> wrote:
> 
> On Thu, 2024-07-11 at 08:26 +0100, David Woodhouse wrote:
>> 
>> I used identical command lines on both, and on each host I got the same
>> result with all of '-cpu host', '-cpu EPYC' and -cpu Skylake-Server'.
>> It's the *host* that makes the difference, not the CPUID presented to
>> the guest.
> 
> Actually... it turns out QEMU isn't really advertising the CPUID we ask
> it to. Leaf zero still does say 'AuthenticAMD' vs. GenuineIntel'
> according to the *host* it's running on, regardless of the -cpu option.
> 
that undermines advertised  cpu model.

> And it is indeed *just* that which seems to trigger the Windows bug,
> setting IRQ2 to point somewhere bogus:
> 
> vtd_ir_remap_msi_req addr 0xfee00004 data 0x0 sid 0xffff do_fault 0
> vtd_ir_remap_msi (addr 0xfee00004, data 0x0) -> (addr 0xfee00004, data 0x0)
> kvm_irqchip_update_msi_route Updating MSI route virq=2
> 
> While in the happy case it does use a remappable format MSI message.
> Not direct to vector 209 on CPU0 as I said before; I think that's IRTE
> entry #209 which maps to vector 209 on CPU1.
> 
> vtd_ir_remap_msi_req addr 0xfee00010 data 0xd1 sid 0xffff do_fault 0
> vtd_ir_irte_get index 0 low 0x0 high 0x100d10005
> vtd_ir_remap index 0 trigger 0 vector 209 deliver 0 dest 0x1 mode 1
> vtd_ir_remap_type IOAPIC
> vtd_ir_remap_msi (addr 0xfee00010, data 0xd1) -> (addr 0xfee01004, data 
> 0x40d1)
> 
> So it looks like Windows doesn't actually cope with Intel IRQ remapping
> when it sees and AMD CPU, which is suboptimal.
> 
Makes sense.

> So to support >255 vCPUs on AMD without having to also do *DMA*
> translation, either we need to come up with a trick like the "no
> supported address widths" we use for dma-translation=off on Intel, or
> we see if we can persuade Windows to use the 15-bit MSI support.
> 
> 
> Looking at the Linux guest support, it seems to look just at the HyperV
> CPUID leaves 0x40000081 and 0x40000082. QEMU knows of those only for
> SYNDBG; Sandesh do you want to try setting the
> HYPERV_VS_PROPERTIES_EAX_EXTENDED_IOAPIC_RTE bit that Linux looks for,
> and see how that affects Windows guests (with no emulated IOMMU)?
> 

Sure I would try that, I would need some reading time however.

Regards,
Sandesh

Reply via email to