qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bui Quang Minh <minhquangbui99@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>, qemu-devel@nongnu.org
Cc: "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>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH v2 2/5] apic: add support for x2APIC mode
Date: Mon, 3 Apr 2023 23:38:15 +0700	[thread overview]
Message-ID: <a22bb5bc-b47f-0166-f922-a186e01221ee@gmail.com> (raw)
In-Reply-To: <6c74f2c83fdd7fcf61e468cb731c9af669fd0da2.camel@infradead.org>

On 4/3/23 17:27, David Woodhouse wrote:
> On Wed, 2023-03-29 at 22:30 +0700, Bui Quang Minh wrote:
>>
>>>
>>> I do some more testing on my hardware, your point is correct when dest
>>> == 0xffffffff, the interrupt is delivered to all APICs regardless of
>>> their mode.
>>
>> To be precisely, it only broadcasts to CPUs in xAPIC mode if the IPI
>> destination mode is physical. In case the destination mode is logical,
>> flat model/cluster model rule applies to determine if the xAPIC CPUs
>> accept the IPI. Wow, this is so complicated :)
> 
> So even if you send to *all* of the first 8 CPUs in a cluster (e.g.
> cluster 0x0001 giving a destination 0x000100FF, a CPU in xAPIC mode
> doesn't see that as a broadcast because it's logical mode?

I mean if the destination is 0xffffffff, the xAPIC CPU will see 
destination as 0xff. 0xff is broadcast in physical destination mode 
only, in logical destination, it may not be a broadcast. It may depend 
on the whether it is flat model or cluster model in logical destination 
mode.

In flat model, 8 bits are used as mask, so in theory, this model can 
only support 8 CPUs, each CPU reserves its own bit by setting the upper 
8 bits of APIC LDR register. In Intel SDM, it is said that 0xff can be 
interpreted as a broadcast, this is true in normal case, but I think if 
the CPU its APIC LDR to 0, the IPI should not deliver to this CPU. This 
also matches with the current flat model of logical destination mode 
implementation of userspace APIC in Qemu before my series. However, I 
see this seems like a corner case, I didn't test it on real hardware.

With cluster model, when writing the above paragraphs, I think that 0xff 
will be delivered to all APICs (mask = 0xf) of cluster 15 (0xf). 
However, reading the SDM more carefully, I see that the there are only 
15 clusters with address from 0 to 14 so there is no cluster with 
address 15. 0xff is interpreted as broadcast to all APICs in all 
clusters too.

In conclusion, IPI with destination 0xffffffff can be a broadcast to all 
xAPIC CPUs too if we just ignore the corner case in flat model of 
logical destination mode (we may need to test more)

> I would have assumed that a CPU in xAPIC mode would have looked at the
> low byte and interpreted it as xAPIC logical mode, with the cluster in
> the high nybble and the 4-bit mask in the low nybble?

Yes, this is the behavior in cluster model of logical destination mode 
(I try to stick with Intel SDM Section 10.6.2.2 Volume 3A when using 
those terminologies)


  reply	other threads:[~2023-04-03 16:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-26  5:20 [PATCH v2 0/5] Support x2APIC mode with TCG accelerator Bui Quang Minh
2023-03-26  5:20 ` [PATCH v2 1/5] i386/tcg: implement x2APIC registers MSR access Bui Quang Minh
2023-03-27 16:56   ` David Woodhouse
2023-03-28 16:33     ` Bui Quang Minh
2023-03-26  5:20 ` [PATCH v2 2/5] apic: add support for x2APIC mode Bui Quang Minh
2023-03-27 11:04   ` David Woodhouse
2023-03-27 15:33     ` Bui Quang Minh
2023-03-27 15:37       ` David Woodhouse
2023-03-27 15:45         ` Bui Quang Minh
2023-03-27 16:22           ` David Woodhouse
2023-03-27 16:35             ` Bui Quang Minh
2023-03-27 16:49               ` David Woodhouse
2023-03-28 15:58                 ` Bui Quang Minh
2023-03-29 14:53                   ` Bui Quang Minh
2023-03-29 15:30                     ` Bui Quang Minh
2023-03-30  8:28                       ` Igor Mammedov
2023-04-03 16:01                         ` Bui Quang Minh
2023-04-03 10:27                       ` David Woodhouse
2023-04-03 16:38                         ` Bui Quang Minh [this message]
2023-04-09 14:31                           ` Bui Quang Minh
2023-03-26  5:20 ` [PATCH v2 3/5] apic, i386/tcg: add x2apic transitions Bui Quang Minh
2023-03-26  5:20 ` [PATCH v2 4/5] intel_iommu: allow Extended Interrupt Mode when using userspace APIC Bui Quang Minh
2023-03-26  5:20 ` [PATCH v2 5/5] amd_iommu: report x2APIC support to the operating system Bui Quang Minh

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=a22bb5bc-b47f-0166-f922-a186e01221ee@gmail.com \
    --to=minhquangbui99@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=dwmw2@infradead.org \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@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).