[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v1 1/1] x86/vlapic: match broadcasts for logical destination mode


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 15 Jan 2026 15:34:12 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sPzH/zU1VTKlM+wBOU58Q2pAmfy/+9lepNcKezU2nlU=; b=Dh1sejNf3D8h8vfJDU+vgNPDAUNolgzbnCvAa9nr1B/EKxEz0AHEaaa1wCLg4r4/iBriWGYmwt8bFP3v0piuwqsFLgiRRfD56fYlfLp4uMyP77UkBA1aYlWa1JSG/OSGOT+/0ZprLng3W9J7r15p3PAbhJrM9XeTYn0+DzzYsiQ+CJStFSqeqNIvpxADtciV6gFQlX2TlNnWzoJFaoFPLI6CEIVduap8HkaNzA4rlCpCS/KTK8HAGb/j/cWVz5UKDEF6nKpVhrVTR/nMjQqD3EN/knEPaKhPBWk7h2jNZ4aOoQokuUL7xJlKe/LZbH8E4aDty8qd4R6lfsdpwHgryQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WmyOFijCw253KWOe91WaGAJye5leSYS3NoE3VAvJ/1tJVo54w1BB0rPtVrqoLWGwfJJPqtk5jbZUpCnvBNFX51Qh/JHRR9gk6hyFfKDl0QPgzJOJy2DGIQnK32wgEonvGWKR441kaefER/EzW4q+Y1iq95K6u/HzHGPMPEQPCWp8kNZwA1yujD9xCGlI+4E0MWU0tm2RNsdZSQDgdnrHhYZcW5xiJDYXTIVN+QES6a3ChuB9knQCmHFI+d76T2hdjN1u7QNewt1iQEaqi7TMtt5VL3MJREunEhcwVdWmZchYQp/ClJmmlPAHh8/lROvJMIH0bg1nDyd+RII+34Jh1w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Victor Lira <victorm.lira@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Alejandro Vallejo <Alejandro.GarciaVallejo@xxxxxxx>
  • Delivery-date: Thu, 15 Jan 2026 14:34:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Jan 15, 2026 at 02:01:12AM +0000, Andrew Cooper wrote:
> On 14/01/2026 11:55 pm, Victor Lira wrote:
> > amd64 vol 3
> > 16.6.1: "In both the flat model and the cluster model, if the
> > destination field = FFh, the interrupt is accepted by all local APICs."
> > 16.14: "A DEST value of FFFF_FFFFh in the ICR is used to broadcast
> > IPIs to all local APICs."
> >
> > intel 64 vol 3
> > 12.6.2.2: "Broadcast to all local APICs is achieved by setting all
> > destination bits to one."
> > 12.12.9: "A destination ID value of FFFF_FFFFH is used
> > for broadcast of interrupts in both logical destination and physical
> > destination modes."
> 
> The formatting here really needs some work.
> 
> >
> > The specs say 0xFFFFFFFF/0xFF should be a broadcast to all APICs in
> > logical destination mode but it is matched only for cluster 0xFFFF/0xFF
> > (or as flat mode in xAPIC).
> >
> > Add a check in vlapic_match_dest similar to what is done for physical
> > destination mode.
> >

This possibly needs a "Fixes:" tag, I think:

Fixes: 7429bfd50dd7 ("This patch provide local APIC support for vmx guest.")

It's been broken since it was introduced.

> > Signed-off-by: Victor Lira <victorm.lira@xxxxxxx>
> > ---
> >  xen/arch/x86/hvm/vlapic.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> > index 79697487ba..1208cd21f0 100644
> > --- a/xen/arch/x86/hvm/vlapic.c
> > +++ b/xen/arch/x86/hvm/vlapic.c
> > @@ -248,7 +248,8 @@ bool vlapic_match_dest(
> >      {
> >      case APIC_DEST_NOSHORT:
> >          if ( dest_mode )
> > -            return vlapic_match_logical_addr(target, dest);
> > +            return (dest == _VLAPIC_ID(target, 0xffffffffU)) ||
> > +                   vlapic_match_logical_addr(target, dest);
> >          return (dest == _VLAPIC_ID(target, 0xffffffffU)) ||
> >                 (dest == VLAPIC_ID(target));
> 
> The SDM/APM quotes are clear, but I think this logic has more bugs than
> just this.
> 
> First, you've got a common expression that the compiler cannot optimise
> because of the function calls hidden in VLAPIC_ID().  The appropriate
> rearrangement would be:
> 
>     case APIC_DEST_NOSHORT:
>         return (dest == _VLAPIC_ID(target, 0xffffffffU) ||
>                 dest_mode ? vlapic_match_logical_addr(target, dest)
>                           : dest == VLAPIC_ID(target));
> 
> 
> However, the first clause looking for the broadcast ID is surely wrong.
> 
> Surely it needs checking against the source LAPIC, not the target. 

That would be:

Fixes: f9e0cccf7b35 ("x86/HVM: fix ID handling of x2APIC emulation")

> Whether 0xff or 0xffffffff is the broadcast address depends on the xAPIC
> vs x2APIC mode of the sending LAPIC only, and it's surely buggy to fail
> to match targets just because they're in the opposite mode.  So, I think
> the correct code is:
> 
>     case APIC_DEST_NOSHORT:
>         return (dest == _VLAPIC_ID(source, 0xffffffffU) ||
>                 dest_mode ? vlapic_match_logical_addr(target, dest)
>                           : dest == VLAPIC_ID(target));
> 
> 
> Thoughts?

LGTM.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.