Just to clarify, this is for 6.0.
On Tue, 1 Dec 2020 14:11:03 +0100
Greg Kurz wrote:
> This property has been deprecated since QEMU 5.0 by commit 22062e54bb68.
> We only kept a legacy hack that internally converts "compat" into the
> official "max-cpu-compat" pr
QEMU 5.2
already. Do it now ; since ppc_cpu_parse_featurestr() now just calls the
generic parent_parse_features handler, drop it as well.
Users are supposed to use the "max-cpu-compat" property of the pseries
machine type instead.
Signed-off-by: Greg Kurz
---
docs/system/deprecated.
On Mon, 27 Jul 2020 17:47:58 +0100
Daniel P. Berrangé wrote:
> On Mon, Jul 27, 2020 at 01:44:07PM -0300, Daniel Henrique Barboza wrote:
> >
> >
> > On 7/27/20 12:29 PM, Daniel P. Berrangé wrote:
> > > On Fri, Jun 19, 2020 at 06:04:33PM -0300, Daniel Henrique Barboza wrote:
> > > > PPC64 has
On Mon, 27 Jul 2020 16:29:20 +0100
Daniel P. Berrangé wrote:
> On Fri, Jun 19, 2020 at 06:04:33PM -0300, Daniel Henrique Barboza wrote:
> > PPC64 has two KVM modules: kvm_hv and kvm_pr. The official supported
> > module was always kvm_hv, while kvm_pr was used for internal testing
> > or for
5..7814e646e4 100644
> --- a/hw/core/numa.c
> +++ b/hw/core/numa.c
> @@ -117,6 +117,13 @@ static void parse_numa_node(MachineState *ms,
> NumaNodeOptions *node,
> }
>
> if (node->has_mem) {
> +if (!mc->numa_mem_supported) {
> +error_set
On Fri, 5 Jun 2020 12:03:21 -0400
Igor Mammedov wrote:
> Deprecation period is run out and it's a time to flip the switch
> introduced by cd5ff8333a. Disable legacy option for new machine
> types (since 5.1) and amend documentation.
>
> '-numa node,memdev' shall be used instead of disabled
On Wed, 12 Jul 2017 12:55:34 +0200
Andrea Bolognani <abolo...@redhat.com> wrote:
> [libvir-list added to the loop]
>
> On Tue, 2017-07-04 at 10:47 +0200, Greg Kurz wrote:
> > On Tue, 4 Jul 2017 17:29:01 +1000 David Gibson
> > <da...@gibson.dropbear.id.au> wr
On Thu, 23 Feb 2017 13:11:52 +1100
David Gibson <da...@gibson.dropbear.id.au> wrote:
> On Wed, Feb 22, 2017 at 12:08:25PM +0100, Greg Kurz wrote:
> > David,
> >
> > I don't see the "spapr_pci: Allow PCI-Express devices" patch in your
> > ppc-
David,
I don't see the "spapr_pci: Allow PCI-Express devices" patch in your
ppc-for-2.9 tree. Do you still consider merging it ?
Cheers.
--
Greg
On Fri, 13 Jan 2017 09:58:28 +0100
Greg Kurz <gr...@kaod.org> wrote:
> On Fri, 13 Jan 2017 15:48:31 +1100
On Fri, 13 Jan 2017 09:57:36 +1100
David Gibson wrote:
> On Thu, Jan 12, 2017 at 11:31:35AM +0100, Andrea Bolognani wrote:
> > On Mon, 2017-01-09 at 10:46 +1100, David Gibson wrote:
> > > > >* To allow for hotplugged devices, libvirt should also add a number
>
On Fri, 13 Jan 2017 15:48:31 +1100
David Gibson <da...@gibson.dropbear.id.au> wrote:
> On Thu, Jan 12, 2017 at 10:09:03AM +0100, Greg Kurz wrote:
> > On Thu, 12 Jan 2017 17:19:40 +1100
> > Alexey Kardashevskiy <a...@ozlabs.ru> wrote:
> >
> >
On Thu, 12 Jan 2017 17:19:40 +1100
Alexey Kardashevskiy <a...@ozlabs.ru> wrote:
> On 12/01/17 14:52, David Gibson wrote:
> > On Fri, Jan 06, 2017 at 12:57:58PM +0100, Greg Kurz wrote:
> >> On Thu, 5 Jan 2017 16:46:18 +1100
> >> David Gibson &l
Resending because of bad qemu-devel address...
On Thu, 5 Jan 2017 16:46:18 +1100
David Gibson wrote:
> There was a discussion back in November on the qemu list which spilled
> onto the libvirt list about how to add support for PCIe devices to
> POWER VMs,
On Thu, 5 Jan 2017 16:46:18 +1100
David Gibson wrote:
> There was a discussion back in November on the qemu list which spilled
> onto the libvirt list about how to add support for PCIe devices to
> POWER VMs, specifically 'pseries' machine type PAPR guests.
>
>
On Tue, 13 Dec 2016 14:25:44 +0200
Marcel Apfelbaum wrote:
> >> Now... from what Laine was saying it sounds like more of the
> >> differences between PCI-E placement and PCI placement may be
> >> implemented by libvirt than qemu than I realized. So possibly we do
> >> want to
15 matches
Mail list logo