qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Sandesh Patel <sandesh.patel@nutanix.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Rob Scheepens <rob.scheepens@nutanix.com>,
	Prerna Saxena <confluence@nutanix.com>,
	Dexuan Cui <decui@microsoft.com>, Alexander Graf <alex@csgraf.de>
Subject: Re: More than 255 vcpus Windows VM setup without viommu ?
Date: Thu, 11 Jul 2024 12:23:50 +0100	[thread overview]
Message-ID: <2cffab2dc20f99ab0c0391bbf5076113cf74411b.camel@infradead.org> (raw)
In-Reply-To: <b37283824ff4b7c6cc3a0c51199e6aa9b4b658a3.camel@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

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.

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.

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)?


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]

  reply	other threads:[~2024-07-11 11:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-02  5:17 More than 255 vcpus Windows VM setup without viommu ? Sandesh Patel
2024-07-02  9:04 ` David Woodhouse
2024-07-03 16:01   ` Sandesh Patel
2024-07-08  9:13     ` David Woodhouse
2024-07-11  7:26       ` David Woodhouse
2024-07-11 11:23         ` David Woodhouse [this message]
2024-07-11 11:52           ` Sandesh Patel
2024-07-16  5:13             ` Sandesh Patel
2024-07-24  9:22               ` David Woodhouse
2024-08-01 10:28         ` Sandesh Patel
2024-09-28 14:59 ` David Woodhouse
2024-09-30 15:50   ` David Woodhouse
2024-10-02 11:33     ` Igor Mammedov
2024-10-02 15:30       ` David Woodhouse
2024-10-01 13:33   ` Daniel P. Berrangé
2024-10-01 16:37     ` David Woodhouse
  -- strict thread matches above, loose matches on Subject: below --
2024-07-02  7:20 Sandesh Patel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2cffab2dc20f99ab0c0391bbf5076113cf74411b.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=alex@csgraf.de \
    --cc=confluence@nutanix.com \
    --cc=decui@microsoft.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rob.scheepens@nutanix.com \
    --cc=sandesh.patel@nutanix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).