On Mon, Feb 07, 2022 at 10:36:42 +0100, Peter Krempa wrote:
> On Mon, Feb 07, 2022 at 10:18:43 +0100, Igor Mammedov wrote:
> > On Mon, 7 Feb 2022 09:14:37 +0100
> > Igor Mammedov wrote:
[...]
> Even if we change it in libvirt right away, changing qemu will break
> forward compatibility. While we
On Mon, Feb 07, 2022 at 10:18:43 +0100, Igor Mammedov wrote:
> On Mon, 7 Feb 2022 09:14:37 +0100
> Igor Mammedov wrote:
>
> > On Sat, 5 Feb 2022 13:45:24 +0100
> > Philippe Mathieu-Daudé wrote:
> >
> > > Previously CPUs were exposed in the QOM tree at a path
> > >
> > > /machine/unattached/
On Mon, 7 Feb 2022 09:14:37 +0100
Igor Mammedov wrote:
> On Sat, 5 Feb 2022 13:45:24 +0100
> Philippe Mathieu-Daudé wrote:
>
> > Previously CPUs were exposed in the QOM tree at a path
> >
> > /machine/unattached/device[nn]
> >
> > where the 'nn' of the first CPU is usually zero, but can
>
On 12/01/2022 12.27, Alex Bennée wrote:
From: Thomas Huth
It's likely broken, and nobody cared for picking it up again
during the deprecation phase, so let's remove this now.
Since this is the last entry in deprecated_targets_list, remove
the related code in the configure script, too.
Signed-
On Sat, 5 Feb 2022 13:45:24 +0100
Philippe Mathieu-Daudé wrote:
> Previously CPUs were exposed in the QOM tree at a path
>
> /machine/unattached/device[nn]
>
> where the 'nn' of the first CPU is usually zero, but can
> vary depending on what devices were already created.
>
> With this chang
