From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Andrew Cooper <amc96@srcf.net>,
Oleksii Kurochko <oleksii.kurochko@gmail.com>,
Grygorii Strashko <grygorii_strashko@epam.com>
Subject: Re: [PATCH for-4.21??? 1/3] x86/vLAPIC: add indirection to LVT handling
Date: Fri, 10 Oct 2025 16:44:52 +0200 [thread overview]
Message-ID: <aOkb5HKVejs6QO5Z@Mac.lan> (raw)
In-Reply-To: <dd6b46f8-76f7-46d3-b3be-083b58781f32@suse.com>
On Wed, Oct 08, 2025 at 02:08:26PM +0200, Jan Beulich wrote:
> In preparation to add support for the CMCI LVT, which is discontiguous to
> the other LVTs, add a level of indirection. Rename the prior
> vlapic_lvt_mask[] while doing so (as subsequently a 2nd array will want
> adding, for use by guest_wrmsr_x2apic()).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> The new name (lvt_valid[]) reflects its present contents. When re-based on
> top of "x86/hvm: vlapic: fix RO bits emulation in LVTx regs", the name
> wants to change to lvt_writable[] (or the 2nd array be added right away,
> with lvt_valid[] then used by guest_wrmsr_x2apic()). Alternatively the
> order of patches may want changing.
>
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -32,7 +32,16 @@
> #include <public/hvm/params.h>
>
> #define VLAPIC_VERSION 0x00050014
> -#define VLAPIC_LVT_NUM 6
> +#define LVT_BIAS(reg) (((reg) - APIC_LVTT) >> 4)
> +
> +#define LVTS \
> + LVT(LVTT), LVT(LVTTHMR), LVT(LVTPC), LVT(LVT0), LVT(LVT1), LVT(LVTERR),
> +
> +static const unsigned int lvt_reg[] = {
> +#define LVT(which) APIC_ ## which
> + LVTS
> +#undef LVT
> +};
>
> #define LVT_MASK \
> (APIC_LVT_MASKED | APIC_SEND_PENDING | APIC_VECTOR_MASK)
> @@ -41,20 +50,21 @@
> (LVT_MASK | APIC_DM_MASK | APIC_INPUT_POLARITY |\
> APIC_LVT_REMOTE_IRR | APIC_LVT_LEVEL_TRIGGER)
>
> -static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =
> +static const unsigned int lvt_valid[] =
> {
> - /* LVTT */
> - LVT_MASK | APIC_TIMER_MODE_MASK,
> - /* LVTTHMR */
> - LVT_MASK | APIC_DM_MASK,
> - /* LVTPC */
> - LVT_MASK | APIC_DM_MASK,
> - /* LVT0-1 */
> - LINT_MASK, LINT_MASK,
> - /* LVTERR */
> - LVT_MASK
> +#define LVTT_VALID (LVT_MASK | APIC_TIMER_MODE_MASK)
> +#define LVTTHMR_VALID (LVT_MASK | APIC_DM_MASK)
> +#define LVTPC_VALID (LVT_MASK | APIC_DM_MASK)
> +#define LVT0_VALID LINT_MASK
> +#define LVT1_VALID LINT_MASK
> +#define LVTERR_VALID LVT_MASK
> +#define LVT(which) [LVT_BIAS(APIC_ ## which)] = which ## _VALID
> + LVTS
> +#undef LVT
> };
>
> +#undef LVTS
I've been thinking about this, as I agree with Grygorii here that the
construct seems to complex. What about using something like:
static const unsigned int lvt_regs[] = {
APIC_LVTT, APIC_LVTTHMR, APIC_LVTPC, APIC_LVT0, APIC_LVT1, APIC_LVTERR,
};
static unsigned int lvt_valid(unsigned int reg)
{
switch ( reg )
{
case APIC_LVTT:
return LVT_MASK | APIC_TIMER_MODE_MASK;
case APIC_LVTTHMR:
case APIC_LVTPC:
return LVT_MASK | APIC_DM_MASK;
case APIC_LVT0:
case APIC_LVT1:
return LINT_MASK;
case APIC_LVTERR:
return LVT_MASK;
}
ASSERT_UNREACHABLE();
return 0;
}
That uses a function instead of a directly indexed array, so it's
going to be slower. I think the compiler will possibly inline it,
plus the clarity is worth the cost.
Thanks, Roger.
next prev parent reply other threads:[~2025-10-10 14:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 12:07 [PATCH for-4.21??? 0/3] x86/vLAPIC: CMCI LVT handling Jan Beulich
2025-10-08 12:08 ` [PATCH for-4.21??? 1/3] x86/vLAPIC: add indirection to " Jan Beulich
2025-10-08 13:04 ` Andrew Cooper
2025-10-08 14:05 ` Jan Beulich
2025-10-08 14:22 ` Jan Beulich
2025-10-09 14:56 ` Grygorii Strashko
2025-10-09 15:31 ` Jan Beulich
2025-10-09 16:16 ` Grygorii Strashko
2025-10-10 5:32 ` Jan Beulich
2025-10-10 14:44 ` Roger Pau Monné [this message]
2025-10-13 6:31 ` Jan Beulich
2025-10-08 12:08 ` [PATCH for-4.21??? 2/3] x86/vLAPIC: drop VLAPIC_VERSION Jan Beulich
2025-10-08 16:23 ` Roger Pau Monné
2025-10-09 7:21 ` Jan Beulich
2025-10-10 13:52 ` Roger Pau Monné
2025-10-08 12:09 ` [PATCH for-4.21??? 3/3] x86/vLAPIC: properly support the CMCI LVT Jan Beulich
2025-10-09 15:08 ` Grygorii Strashko
2025-10-09 15:37 ` Jan Beulich
2025-10-14 14:12 ` Grygorii Strashko
2025-10-14 15:31 ` Jan Beulich
2025-10-14 19:36 ` Andrew Cooper
2025-10-15 6:30 ` Jan Beulich
2025-10-09 13:58 ` [PATCH for-4.21??? 0/3] x86/vLAPIC: CMCI LVT handling Oleksii Kurochko
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=aOkb5HKVejs6QO5Z@Mac.lan \
--to=roger.pau@citrix.com \
--cc=amc96@srcf.net \
--cc=andrew.cooper3@citrix.com \
--cc=grygorii_strashko@epam.com \
--cc=jbeulich@suse.com \
--cc=oleksii.kurochko@gmail.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.