On Mon, 16 Oct 2017 16:31:07 +0200
Igor Mammedov wrote:
> On Mon, 16 Oct 2017 13:24:20 +0200
> Greg Kurz wrote:
>
> > On Mon, 16 Oct 2017 10:41:39 +0200
> > Igor Mammedov wrote:
> >
> > > On Fri, 13 Oct 2017 13:47:51 +0200
> > > Greg Kurz wrote:
> > >
> > > [...]
> > >
> > > > Note t
On Mon, 16 Oct 2017 13:24:20 +0200
Greg Kurz wrote:
> On Mon, 16 Oct 2017 10:41:39 +0200
> Igor Mammedov wrote:
>
> > On Fri, 13 Oct 2017 13:47:51 +0200
> > Greg Kurz wrote:
> >
> > [...]
> >
> > > Note that the resolution should really return a CPU object, otherwise
> > > we have a bug. T
On Mon, 16 Oct 2017 10:41:39 +0200
Igor Mammedov wrote:
> On Fri, 13 Oct 2017 13:47:51 +0200
> Greg Kurz wrote:
>
> [...]
>
> > Note that the resolution should really return a CPU object, otherwise
> > we have a bug. This is achieved by relying on object_resolve_path()
> > and CPU() instead of
On Fri, 13 Oct 2017 13:47:51 +0200
Greg Kurz wrote:
[...]
> Note that the resolution should really return a CPU object, otherwise
> we have a bug. This is achieved by relying on object_resolve_path()
> and CPU() instead of calling object_resolve_path_type(path, TYPE_CPU).
I'm not sure what you a
On Fri, 13 Oct 2017 13:47:51 +0200
Greg Kurz wrote:
> If a CPU selected with the "cpu" command is hot-unplugged then "info cpus"
> causes QEMU to exit:
>
> (qemu) device_del cpu1
> (qemu) info cpus
> qemu:qemu_cpu_kick_thread: No such process
>
> This happens because "cpu" stores the pointer to
If a CPU selected with the "cpu" command is hot-unplugged then "info cpus"
causes QEMU to exit:
(qemu) device_del cpu1
(qemu) info cpus
qemu:qemu_cpu_kick_thread: No such process
This happens because "cpu" stores the pointer to the selected CPU into
the monitor structure. When the CPU is hot-unpl
