All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Alejandro Vallejo <alejandro.vallejo@cloud.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/hvm: Add APIC IDs to the per-vLAPIC save area
Date: Wed, 26 Feb 2025 18:33:47 +0100	[thread overview]
Message-ID: <Z79Qe3kMS18P6JNQ@macbook.local> (raw)
In-Reply-To: <1de43f95-5ed1-46c1-a157-094ceb84ac83@suse.com>

On Wed, Feb 26, 2025 at 02:11:23PM +0100, Jan Beulich wrote:
> On 18.02.2025 15:22, Alejandro Vallejo wrote:
> > Today, Xen hardcodes apic_id = vcpu_id * 2, but this is unwise and
> > interferes with providing accurate topology information to the guest.
> > 
> > Introduce a new x2apic_id field into hvm_hw_lapic.  This is immutable
> > state from the guest's point of view, but it will allow the toolstack to
> > eventually configure the value, and for the value to move on migrate.
> > 
> > For backwards compatibility, the patch rebuilds the old-style APIC IDs
> > from migration streams lacking them when they aren't present.
> 
> Nit: "when they aren't present" looks to duplicate "lacking them"?
> 
> > Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
> > ---
> > I've split this one from the rest of the topology series as it's independent
> > and entangled with another patch from Andrew.
> 
> Albeit I think meanwhile we've settled that the entangling isn't quite as
> problematic.
> 
> > @@ -1621,6 +1624,14 @@ static int cf_check lapic_load_hidden(struct domain *d, hvm_domain_context_t *h)
> >          return -EINVAL;
> >      }
> >  
> > +    /*
> > +     * Xen 4.20 and earlier had no x2APIC ID in the migration stream and
> > +     * hard-coded "vcpu_id * 2". Default back to this if we have a
> > +     * zero-extended record.
> > +     */
> > +    if ( h->size <= offsetof(struct hvm_hw_lapic, x2apic_id) )
> > +        s->hw.x2apic_id = v->vcpu_id * 2;
> 
> While we better wouldn't get to see such input, it is in principle possible
> to have an input stream with, say, half the field. Imo the condition ought
> to be such that we'd make the adjustment when less than the full field is
> available.

I would add an additional check to ensure _rsvd0 remains 0, to avoid
further additions from attempting to reuse that padding space.

if ( s->hw._rsvd0 )
    return -EINVAL;

In fact I would be tempted to overwrite the ID if the stream size
doesn't match the expected one, ie:

if ( h->size < (offsetof(struct hvm_hw_lapic, _rsvd0) +
                sizeof(s->hw._rsvd0)) )
    s->hw.x2apic_id = v->vcpu_id * 2;

Regards, Roger.


  reply	other threads:[~2025-02-26 17:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18 14:22 [PATCH] x86/hvm: Add APIC IDs to the per-vLAPIC save area Alejandro Vallejo
2025-02-26 13:11 ` Jan Beulich
2025-02-26 17:33   ` Roger Pau Monné [this message]
2025-02-27  7:29     ` Jan Beulich
2025-02-27 14:16       ` Alejandro Vallejo
2025-02-27 14:12     ` Alejandro Vallejo
2025-02-28  9:48       ` Roger Pau Monné
2025-02-27 14:15   ` Alejandro Vallejo

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=Z79Qe3kMS18P6JNQ@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=alejandro.vallejo@cloud.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.