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, 27 Mar 2023 23:35:36 +0700	[thread overview]
Message-ID: <445928d9-4cd3-978d-ce76-9cd01457b6f0@gmail.com> (raw)
In-Reply-To: <3834475953c0f865e88251886f1e861d51c25a2b.camel@infradead.org>

On 3/27/23 23:22, David Woodhouse wrote:
> On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote:
>>
>>> Maybe I'm misreading the patch, but to me it looks that
>>> if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in
>>> x2apic mode? So delivering to the APIC with physical ID 255 will be
>>> misinterpreted as a broadcast?
>>
>> In case dest == 0xff the second argument to apic_get_broadcast_bitmask
>> is set to false which means this is xAPIC broadcast
> 
> Yeah, but it *isn't* xAPIC broadcast. It's X2APIC unicast to APIC#255.
> 
> I think you want (although you don't have 'dev') something like this:
> 
> 
> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
>                                        uint32_t dest, uint8_t dest_mode)
> {
>      APICCommonState *apic_iter;
>      int i;
> 
>      memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t));
> 
>      /* x2APIC broadcast id for both physical and logical (cluster) mode */
>      if (dest == 0xffffffff) {
>          apic_get_broadcast_bitmask(deliver_bitmask, true);
>          return;
>      }
> 
>      if (dest_mode == 0) {
>          apic_find_dest(deliver_bitmask, dest);
>          /* Broadcast to xAPIC mode apics */
> -        if (dest == 0xff) {
> +        if (dest == 0xff && is_x2apic_mode(dev)) {
>              apic_get_broadcast_bitmask(deliver_bitmask, false);
>          }
>      } else {
> 

Hmm, the unicast case is handled in apic_find_dest function, the logic 
inside the if (dest == 0xff) is for handling the broadcast case only. 
This is because when dest == 0xff, it can be both a x2APIC unicast and 
xAPIC broadcast in case we have some CPUs that are in xAPIC and others 
are in x2APIC. Do you think the code here is tricky and hard to read?


  reply	other threads:[~2023-03-27 16:36 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 [this message]
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
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=445928d9-4cd3-978d-ce76-9cd01457b6f0@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).