[PATCH-for-11.0?] target/i386: Mandate monitor 'info lapic' take a vCPU ID argument

[PATCH-for-11.0?] target/i386: Mandate monitor 'info lapic' take a vCPU ID argument

[Philippe Mathieu-Daudé]

With SMP configurations, using the 'current vCPU' under the
monitor isn't recommended, as it changes during runtime. Better
to specify which vCPU we want to monitor by its index. Deprecate
the default of 'info lapic', mentioning an argument is expected,
so we can remove this unpredictable behavior one day.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
The other command with this unpredictable behavior is 'info tlb'
which we'll deal with differently, after the v11.0 release.
---
 docs/about/deprecated.rst | 6 ++++++
 target/i386/cpu-apic.c    | 2 ++
 hmp-commands-info.hx      | 3 +--
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index a6d6a713265..a62da93259a 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -169,6 +169,12 @@ The ``stopcapture`` command is deprecated and will be removed in a future releas
 
 The ``info capture`` command is deprecated and will be removed in a future release.
 
+``info lapic`` without ``apic-id`` argument (since 11.0)
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+When no APIC ID is provided, ``info lapic`` defaults to the current vCPU.
+This behavior is now deprecated, the ID will be mandatory in a future release.
+
 Host Architectures
 ------------------
 
diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
index eaa10ad2a3d..9ca569f62b8 100644
--- a/target/i386/cpu-apic.c
+++ b/target/i386/cpu-apic.c
@@ -97,6 +97,8 @@ void hmp_info_local_apic(Monitor *mon, const QDict *qdict)
             cpu_synchronize_state(cs);
         }
     } else {
+        monitor_printf(mon, "Not specifying the local apic id is deprecated"
+                       " (using the current CPU one)\n");
         cs = mon_get_cpu(mon);
     }
 
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index 74c741f80e2..e4206d329fc 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -118,8 +118,7 @@ ERST
         .name       = "lapic",
         .args_type  = "apic-id:i?",
         .params     = "[apic-id]",
-        .help       = "show local apic state (apic-id: local apic to read, default is which of current CPU)",
-
+        .help       = "show local apic state (apic-id: local apic to read)",
         .cmd        = hmp_info_local_apic,
     },
 #endif
-- 
2.53.0

Re: [PATCH-for-11.0?] target/i386: Mandate monitor 'info lapic' take a vCPU ID argument

[Daniel P. Berrangé]

On Mon, Apr 13, 2026 at 03:07:48PM +0200, Philippe Mathieu-Daudé wrote:
> With SMP configurations, using the 'current vCPU' under the
> monitor isn't recommended, as it changes during runtime. Better
> to specify which vCPU we want to monitor by its index. Deprecate
> the default of 'info lapic', mentioning an argument is expected,
> so we can remove this unpredictable behavior one day.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
> The other command with this unpredictable behavior is 'info tlb'
> which we'll deal with differently, after the v11.0 release.

Aren't there quite a few more commands that rely on the HMP
"current" vCPU concept besides these two ?

info registers  comes to mind, 

There are others whic call mon_get_cpu(), which are not
directly caring about a specific CPU, eg 'info mem',
'memory_dump'

Why the rush to get lapic deprecated in 11.0 but not the
otherrs ?


> ---
>  docs/about/deprecated.rst | 6 ++++++
>  target/i386/cpu-apic.c    | 2 ++
>  hmp-commands-info.hx      | 3 +--
>  3 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index a6d6a713265..a62da93259a 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -169,6 +169,12 @@ The ``stopcapture`` command is deprecated and will be removed in a future releas
>  
>  The ``info capture`` command is deprecated and will be removed in a future release.
>  
> +``info lapic`` without ``apic-id`` argument (since 11.0)
> +''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +When no APIC ID is provided, ``info lapic`` defaults to the current vCPU.
> +This behavior is now deprecated, the ID will be mandatory in a future release.
> +
>  Host Architectures
>  ------------------
>  
> diff --git a/target/i386/cpu-apic.c b/target/i386/cpu-apic.c
> index eaa10ad2a3d..9ca569f62b8 100644
> --- a/target/i386/cpu-apic.c
> +++ b/target/i386/cpu-apic.c
> @@ -97,6 +97,8 @@ void hmp_info_local_apic(Monitor *mon, const QDict *qdict)
>              cpu_synchronize_state(cs);
>          }
>      } else {
> +        monitor_printf(mon, "Not specifying the local apic id is deprecated"
> +                       " (using the current CPU one)\n");
>          cs = mon_get_cpu(mon);
>      }
>  
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 74c741f80e2..e4206d329fc 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -118,8 +118,7 @@ ERST
>          .name       = "lapic",
>          .args_type  = "apic-id:i?",
>          .params     = "[apic-id]",
> -        .help       = "show local apic state (apic-id: local apic to read, default is which of current CPU)",
> -
> +        .help       = "show local apic state (apic-id: local apic to read)",
>          .cmd        = hmp_info_local_apic,
>      },
>  #endif
> -- 
> 2.53.0
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH-for-11.0?] target/i386: Mandate monitor 'info lapic' take a vCPU ID argument

[Philippe Mathieu-Daudé]

On 13/4/26 15:19, Daniel P. Berrangé wrote:
> On Mon, Apr 13, 2026 at 03:07:48PM +0200, Philippe Mathieu-Daudé wrote:
>> With SMP configurations, using the 'current vCPU' under the
>> monitor isn't recommended, as it changes during runtime. Better
>> to specify which vCPU we want to monitor by its index. Deprecate
>> the default of 'info lapic', mentioning an argument is expected,
>> so we can remove this unpredictable behavior one day.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> ---
>> The other command with this unpredictable behavior is 'info tlb'
>> which we'll deal with differently, after the v11.0 release.
> 
> Aren't there quite a few more commands that rely on the HMP
> "current" vCPU concept besides these two ?
> 
> info registers  comes to mind,
> 
> There are others whic call mon_get_cpu(), which are not
> directly caring about a specific CPU, eg 'info mem',
> 'memory_dump'
> 
> Why the rush to get lapic deprecated in 11.0 but not the
> otherrs ?

Reading the "Arm OABI and NWFPE" deprecation patch triggered
"oh it is still possible to get deprecation message merged"
and I took that first patch of a bigger branch. Not a smart
move because no rush indeed.

>> ---
>>   docs/about/deprecated.rst | 6 ++++++
>>   target/i386/cpu-apic.c    | 2 ++
>>   hmp-commands-info.hx      | 3 +--
>>   3 files changed, 9 insertions(+), 2 deletions(-)

Re: [PATCH-for-11.0?] target/i386: Mandate monitor 'info lapic' take a vCPU ID argument

[Peter Maydell]

On Mon, 13 Apr 2026 at 14:08, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> With SMP configurations, using the 'current vCPU' under the
> monitor isn't recommended, as it changes during runtime. Better
> to specify which vCPU we want to monitor by its index. Deprecate
> the default of 'info lapic', mentioning an argument is expected,
> so we can remove this unpredictable behavior one day.

Is this really "unpredictable" ? This isn't the "current CPU" in
the sense of "whatever is currently running", it's the "current CPU"
in the sense of "whatever the user has set via the 'cpu' HMP command".

You can certainly argue that a UI where you set the CPU via one
command and then that's an implicit argument to various other
commands is not ideal, but it's not unpredictable. The
only time the CPU will change without user interaction is if
they have set the monitor's current-CPU to one that is hot-unplugged
(in which case it will reset to the first CPU), but the user is
also likely to be in control of hot-unplug events anyway.

-- PMM