qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Igor Mammedov <imammedo@redhat.com>,
	Bui Quang Minh <minhquangbui99@gmail.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Subject: Re: [PATCH 1/4] apic: add support for x2APIC mode
Date: Mon, 06 Mar 2023 15:51:45 +0000	[thread overview]
Message-ID: <96f1f670d576dbb1969055353b9e7b5a8632a4c8.camel@infradead.org> (raw)
In-Reply-To: <20230306114331.531c9cd2@imammedo.users.ipa.redhat.com>

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

On Mon, 2023-03-06 at 11:43 +0100, Igor Mammedov wrote:
> > However, there are still problems while trying to extending support to 
> > APIC ID larger than 255 because there are many places assume APIC ID is 
> > 8-bit long.
>
> that's what I was concerned about (i.e. just enabling x2apic without fixing
> with all code that just assumes 8bit apicid).

Even before you extend the physical APIC IDs past 254 or 255, there's
still the issue that 255 isn't a broadcast in X2APIC mode. And that
*logical* addressing will use more than 8 bits even when the physical
IDs are lower.

> > One of that is interrupt remapping which returns 32-bit 
> > destination ID but uses MSI (which has 8-bit destination) to send to 
> > APIC. I will look more into this.

The translated 'output' from the interrupt remapping doesn't "use MSI",
in the sense of a write transaction which happens to go to addresses in
the 0x00000000FEExxxxx range. The *input* to interrupt remapping comes
from that intercept.

The output is already "known" to be an MSI message, with a full 64-bit
address and 32-bit data, and the KVM API puts the high 24 bits of the
target APIC ID into the high word of the address.

If you look at the "generic" x86_iommu_irq_to_msi_message() in
hw/intc/x86-iommu.c you'll see it's also using the same trick:

    msg.__addr_hi = irq->dest & 0xffffff00;


That hack isn't guest-visible. There *is* a trick which is guest-
visible, implemented by both Hyper-V and KVM, which is to recognise
that actually there was an 'Extended Destination ID' field in bits 4-11
of the actual 32-bit MSI. Intel eventually used the low bit as the
selector for 'Remappable Format' MSI messages, but we've used the other
seven to extend the APIC ID to 15 bits even in a guest-visible way,
allowing up to 32768 CPUs without having to expose a virtual IOMMU.

But that should get translated to the KVM format with the high bits in
the top 32 bits of the address, fairly much transparently. All you need
to do is ensure that the TCG X2APIC support takes that KVM format, and
that it all enabled in the right circumstances.

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

  reply	other threads:[~2023-03-06 15:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21 16:04 [PATCH 0/4] Support x2APIC mode with TCG accelerator Bui Quang Minh
2023-02-21 16:04 ` [PATCH 1/4] apic: add support for x2APIC mode Bui Quang Minh
2023-02-24 14:29   ` Igor Mammedov
2023-02-25 10:15     ` Bui Quang Minh
2023-02-27 16:07       ` Igor Mammedov
2023-02-28 14:34         ` Bui Quang Minh
2023-02-28 16:39           ` Igor Mammedov
2023-03-04 14:10             ` Bui Quang Minh
2023-03-06 10:43               ` Igor Mammedov
2023-03-06 15:51                 ` David Woodhouse [this message]
2023-03-06 16:39                   ` Bui Quang Minh
2023-03-06 16:50                     ` David Woodhouse
2023-03-07 11:34                       ` Igor Mammedov
2023-03-07 11:25                   ` Igor Mammedov
2023-03-06 16:01   ` David Woodhouse
2023-02-21 16:04 ` [PATCH 2/4] i386/tcg: implement x2APIC registers MSR access Bui Quang Minh
2023-02-21 16:04 ` [PATCH 3/4] intel_iommu: allow Extended Interrupt Mode when using userspace local APIC Bui Quang Minh
2023-02-21 16:05 ` [PATCH 4/4] test/avocado: test Linux boot up in x2APIC with " Bui Quang Minh
2023-03-06 19:51   ` David Woodhouse
2023-03-07  7:22   ` Alex Bennée
2023-03-07 11:39   ` Igor Mammedov
2023-03-06 17:55 ` [PATCH 0/4] Support x2APIC mode with TCG accelerator David Woodhouse

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=96f1f670d576dbb1969055353b9e7b5a8632a4c8.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=minhquangbui99@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /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).