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

Re: [PATCH] x86/vhpet: Fix sanitization of legacy IRQ route


  • To: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 24 Nov 2025 15:49:22 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 24 Nov 2025 14:49:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.11.2025 14:43, Tu Dinh wrote:
> When setting a timer's config register, timer_sanitize_int_route will
> always reset the IRQ route value to what's valid corresponding to the
> !HPET_CFG_LEGACY case. This is applied even if the HPET is set to
> HPET_CFG_LEGACY.
> 
> When some operating systems (e.g. Windows) try to write to a timer
> config, they will verify and rewrite the register if the values don't
> match what they expect. This causes an unnecessary write to HPET_Tn_CFG.
> 
> Note, the HPET specification states that for the Tn_INT_ROUTE_CNF field:
> 
> "If the value is not supported by this prarticular timer, then the value
> read back will not match what is written. [...] If the LegacyReplacement
> Route bit is set, then Timers 0 and 1 will have a different routing, and
> this bit field has no effect for those two timers."
> 
> Therefore, Xen should not reset timer_int_route if legacy mode is
> enabled, regardless of what's in there.

Fixes: ec40d3fe2147 ("x86/vhpet: check that the set interrupt route is valid")
(I think)

> Signed-off-by: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>
> ---
>  xen/arch/x86/hvm/hpet.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> --- a/xen/arch/x86/hvm/hpet.c
> +++ b/xen/arch/x86/hvm/hpet.c
> @@ -48,6 +48,8 @@
>  #define timer_is_32bit(h, n)     (timer_config(h, n) & HPET_TN_32BIT)
>  #define hpet_enabled(h)          ((h)->hpet.config & HPET_CFG_ENABLE)
>  #define timer_level(h, n)        (timer_config(h, n) & HPET_TN_LEVEL)
> +#define timer_is_legacy(h, n) \
> +    (((n) <= 1) && ((h)->hpet.config & HPET_CFG_LEGACY))
>  
>  #define timer_int_route(h, n)    MASK_EXTR(timer_config(h, n), HPET_TN_ROUTE)
>  
> @@ -244,7 +246,7 @@ static void hpet_set_timer(HPETState *h, unsigned int tn,
>           (timer_level(h, tn) && test_bit(tn, &h->hpet.isr)) )
>          return;
>  
> -    if ( !timer_int_route_valid(h, tn) )
> +    if ( !timer_is_legacy(h, tn) && !timer_int_route_valid(h, tn) )

Seeing this and the other use together with timer_int_route_valid(),
wouldn't timer_int_route_valid() better itself invoke the new macro?

> @@ -379,6 +381,9 @@ static int cf_check hpet_write(
>          h->hpet.config = hpet_fixup_reg(new_val, old_val,
>                                          HPET_CFG_ENABLE | HPET_CFG_LEGACY);
>  
> +        for ( i = 0; i < HPET_TIMER_NUM; i++ )
> +            timer_sanitize_int_route(h, i);

Strictly speaking this is needed only when HPET_CFG_LEGACY went from
1 to 0. Plus it's needed only on the first 2 channels, as it's only
there where timer_sanitize_int_route() changes behavior. I'm not going
to insist to limit it like this, but if you don't, then I'd like to ask
for a comment here clarifying that excess work is done for simplicity's
sake.

Jan



 


Rackspace

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