Re: [PATCH v2 3/3] docs/about: Add the missing release record in the subject

t; > The "tls-creds" option should be used instead to point to a "tls-creds-x509" > object created using "-object". > -- > 2.19.1 > Reviewed-by: Andrew Jones

Re: [PATCH v2 2/3] docs/about: Unify the subject format

subject format in removed-features.rst to "removed in X.Y". > > Signed-off-by: Yanan Wang > Reviewed-by: Cornelia Huck > --- > docs/about/deprecated.rst | 56 - > docs/about/removed-features.rst | 28 ++++----- > 2 files changed, 42 insertions(+), 42 deletions(-) > Reviewed-by: Andrew Jones

Re: [PATCH v2 1/3] docs/about: Remove the duplicated doc

ets* * *cores* * *threads* = *maxcpus*. > - > ``-machine enforce-config-section=on|off`` (removed 5.2) > > > -- > 2.19.1 > Reviewed-by: Andrew Jones

Re: [PATCH 1/6] accel: Introduce 'query-accels' QMP command

On Fri, Mar 12, 2021 at 10:01:43AM +0100, Paolo Bonzini wrote: > On 12/03/21 09:48, Andrew Jones wrote: > > > I think we definitely need the additional data section here: For KVM on > > > POWER, it would be good to know whether it's KVM-HV or KVM-PR, for KVM on > > >

Re: [PATCH 1/6] accel: Introduce 'query-accels' QMP command

On Fri, Mar 12, 2021 at 09:52:33AM +0100, Claudio Fontana wrote: > On 3/12/21 9:48 AM, Andrew Jones wrote: > > On Fri, Mar 12, 2021 at 09:11:45AM +0100, Thomas Huth wrote: > >> On 12/03/2021 08.42, Marc-André Lureau wrote: > >>> > >>> > >>>

Re: [PATCH 1/6] accel: Introduce 'query-accels' QMP command

On Fri, Mar 12, 2021 at 09:11:45AM +0100, Thomas Huth wrote: > On 12/03/2021 08.42, Marc-André Lureau wrote: > > > > > > On Fri, Mar 12, 2021 at 3:14 AM Philippe Mathieu-Daudé > > mailto:phi...@redhat.com>> wrote: > > > [...] > > +## > > +# @AcceleratorInfo: > > +# > > +#

Re: [libvirt PATCH v2 3/8] conf: Introduce VIR_DOMAIN_TIMER_NAME_ARMVTIMER

On Thu, Feb 13, 2020 at 05:30:21PM +0100, Andrea Bolognani wrote: > On Thu, 2020-02-13 at 14:26 +0100, Ján Tomko wrote: > > On Fri, Feb 07, 2020 at 03:27:03PM +0100, Andrea Bolognani wrote: > > > +++ b/src/conf/domain_conf.c > > > @@ -1063,6 +1063,7 @@ VIR_ENUM_IMPL(virDomainTimerName, > > >

Re: [libvirt] [Qemu-devel] [PATCH v5 2/2] vl:c: make sure that sockets are calculated correctly in '-smp X' case

sockets = !sockets ? max_cpus / (cores * threads) : sockets; > } > } else if (cores == 0) { > threads = threads > 0 ? threads : 1; > -- > 2.7.4 > > Reviewed-by: Andrew Jones -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH v5 1/2] vl.c deprecate incorrect CPUs topology

ake sure that >[sockets * cores * threads] == [maxcpus] > > Signed-off-by: Igor Mammedov > --- > v5: > - extend deprecation doc, adding that maxcpus should be multiple of > present on CLI [sockets/cores/threads] options > (Eduardo Habkost ) > v4: > - mi

Re: [libvirt] [Qemu-devel] [PATCH v4] vl.c deprecate incorrect CPUs topology

ake sure that >[sockets * cores * threads] == [maxcpus] > > Signed-off-by: Igor Mammedov > --- > v4: > - missed dot comment, fix it with s/./,/ (Andrew Jones ) > v3: > - more spelling fixes (Andrew Jones ) > - place deprecation check after (sockets * cores * t

Re: [libvirt] [Qemu-devel] [PATCH v3] vl.c deprecate incorrect CPUs topology

ake sure that >[sockets * cores * threads] == [maxcpus] > > Signed-off-by: Igor Mammedov > --- > v3: > - more spelling fixes (Andrew Jones ) > - place deprecation check after (sockets * cores * threads > max_cpus) check > (Eduardo Habkost ) > v2: > - spelli

Re: [libvirt] [Qemu-devel] [PATCH v2] vl.c deprecate incorrect CPUs topology

ake sure that >[sockets * cores * threads] == [maxcpus] > > Signed-off-by: Igor Mammedov > --- > v2: > - spelling& fixes (Andrew Jones ) > --- > qemu-deprecated.texi | 11 +++ > vl.c | 6 ++ > 2 files changed, 17 insertions(+)

Re: [libvirt] [PATCH] vl.c deprecate incorrect CPUs topology

On Mon, Aug 27, 2018 at 01:56:08PM +0200, Igor Mammedov wrote: > -smp [cpus],sockets/cores/threads[,maxcpus] should describe topology > so that total number of logical CPUs [sockets * cores * threads] > would be equal to [maxcpus], however historically we didn't have > such check in QEMU and it is

Re: [libvirt] [Qemu-devel] dynamic DRAM base for ArmVirtQemu

On Fri, Oct 13, 2017 at 05:18:59PM +0100, Peter Maydell wrote: > On 13 October 2017 at 13:51, Laszlo Ersek wrote: > > Another idea is to move *the* system DRAM base to a different guest-phys > > address. (Likely using a different version of the "virt" machine type, > > or even

Re: [libvirt] [PATCH] qemu: Support chardevs with ARM virt machines

On Mon, Jun 26, 2017 at 10:10:55AM -0400, Cole Robinson wrote: > On 06/24/2017 10:07 PM, Andrea Bolognani wrote: > > On Sat, 2017-06-24 at 16:07 +0200, Christoffer Dall wrote: > >> At this point I'm a little confused about how to proceed here. Would > >> you like further evidence of an

Re: [libvirt] [PATCH] qemu: Support chardevs with ARM virt machines

On Sun, 2017-06-25 at 13:46 +0200, Christoffer Dall wrote: >>On Sun, Jun 25, 2017 at 4:07 AM, Andrea Bolognani wrote: >> On Sat, 2017-06-24 at 16:07 +0200, Christoffer Dall wrote: >>> > The way I see it, the bug is about libvirt being unable to >>> > launch guests which use the feature, and with

Re: [libvirt] [PATCH 3/3] qemu: use qemu-xhci USB controller by default for ppc64 and aarch64

On Thu, Apr 27, 2017 at 11:14:42AM +1000, David Gibson wrote: > On Wed, 26 Apr 2017 18:20:24 +0200 > Andrea Bolognani wrote: > > > [*actually* added David and Drew to CC smh] > > > > On Wed, 2017-04-26 at 18:13 +0200, Andrea Bolognani wrote: > > > The rest looks good, but

Re: [libvirt] [PATCH v3 8/8] conf: aggregate multiple pcie-root-ports onto a single slot

On Tue, Jan 10, 2017 at 03:51:21PM -0500, Laine Stump wrote: > On 12/19/2016 10:23 AM, Laine Stump wrote: > > Set the VIR_PCI_CONNECT_AGGREGATE_SLOT flag for pcie-root-ports so > > that they will be assigned to all the functions on a slot. > > > > Some qemu test case outputs had to be adjusted

Re: [libvirt] [PATCH] qemu: Don't use legacy USB for aarch64 mach-virt guests

On Fri, Jun 17, 2016 at 06:51:34PM +0200, Andrea Bolognani wrote: > On Fri, 2016-06-17 at 11:20 -0400, Laine Stump wrote: > > On 06/17/2016 09:20 AM, Andrea Bolognani wrote: > > > The '-usb' option doesn't have any effect for aarch64 mach-virt > > > guests, > >  > > Do you mean that having -usb on

Re: [libvirt] [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version

On Thu, Feb 18, 2016 at 12:40:56PM +0800, Peter Xu wrote: > On Mon, Feb 15, 2016 at 03:22:05PM +, Daniel P. Berrange wrote: > > On Mon, Feb 15, 2016 at 04:08:33PM +0100, Markus Armbruster wrote: > > > Peter Xu writes: > > > > > > > On Mon, Feb 15, 2016 at 10:52:01AM +0100,

Re: [libvirt] [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version

On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote: > Peter Maydell writes: > > > On 15 February 2016 at 15:08, Markus Armbruster wrote: > >> Peter Xu writes: > >>> On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus

Re: [libvirt] [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version

On Mon, Feb 15, 2016 at 09:41:57AM +, Peter Maydell wrote: > On 15 February 2016 at 09:35, Martin Kletzander wrote: > > So hardware itself supports some GIC version, let's say 3 for our case. > > Does that mean it can be triggered to do v2 as well? I mean is it > >

Re: [libvirt] [Qemu-devel] ARM KVM GICv3 Support

On Tue, Feb 02, 2016 at 03:05:28PM +0100, Christoffer Dall wrote: > On Tue, Feb 02, 2016 at 01:59:26PM +0100, Andrew Jones wrote: > > On Tue, Feb 02, 2016 at 12:10:10PM +, Daniel P. Berrange wrote: > > > On Tue, Feb 02, 2016 at 12:49:33PM +0100, Christoffer Dall wrote: >

Re: [libvirt] [Qemu-devel] ARM KVM GICv3 Support

On Tue, Feb 02, 2016 at 12:10:10PM +, Daniel P. Berrange wrote: > On Tue, Feb 02, 2016 at 12:49:33PM +0100, Christoffer Dall wrote: > > On Fri, Jan 22, 2016 at 02:44:32PM +, Daniel P. Berrange wrote: > > > On Wed, Jan 06, 2016 at 01:30:16PM +, Peter Maydell wrote: > > > > On 6 January

Re: [libvirt] [Qemu-devel] ARM KVM GICv3 Support

On Tue, Feb 02, 2016 at 01:15:49PM +, Peter Maydell wrote: > On 2 February 2016 at 12:59, Andrew Jones <drjo...@redhat.com> wrote: > > This actually doesn't matter for the v2 vs. v3 case. The gic-version > > property > > doesn't exist at all for v2-only QEMU. Alt

Re: [libvirt] ARM KVM GICv3 Support

On Tue, Jan 12, 2016 at 04:48:27PM +0100, Andrea Bolognani wrote: > Would providing a QMP command that returns the list of GIC versions > available on the current host for the current machine type be > acceptable from QEMU's point of view? > Adding qemu-devel. Peter any opinion on this? If it

Re: [libvirt] ARM KVM GICv3 Support

On Tue, Dec 15, 2015 at 04:03:13PM +, Peter Maydell wrote: > On 15 December 2015 at 14:12, Martin Kletzander wrote: > > On Tue, Dec 15, 2015 at 09:41:02AM +, Peter Maydell wrote: > >> > >> On 15 December 2015 at 09:36, Martin Kletzander > >>

Re: [libvirt] ARM KVM GICv3 Support

On Tue, Dec 15, 2015 at 05:53:43PM +0100, Andrea Bolognani wrote: > On Tue, 2015-12-15 at 10:35 -0600, Andrew Jones wrote: > > On Tue, Dec 15, 2015 at 04:03:13PM +, Peter Maydell wrote: > > > On 15 December 2015 at 14:12, Martin Kletzander <mklet...@redhat.com> >

Re: [libvirt] ARM KVM GICv3 Support

On Tue, Dec 15, 2015 at 04:42:13PM +, Peter Maydell wrote: > On 15 December 2015 at 16:35, Andrew Jones <drjo...@redhat.com> wrote: > > This is probably good for guests that happy with both. Guests that > > need/want a specific choice will put their integer there, and t

Re: [libvirt] ARM KVM GICv3 Support

On Mon, Dec 14, 2015 at 12:31:59PM +0100, Christoffer Dall wrote: > Hi all, > > I'm trying to figure out what the correct solution for libvirt support > for ARM KVM guests with GICv3 is. > > The challenge is that QEMU's virt machine model defaults to GICv2 unless > you specify an additional

Re: [libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended

- Original Message - On 08/23/2013 07:24 AM, Andrew Jones wrote: The comment in kvm_max_vcpus() states that it's using the recommended procedure from the kernel API documentation to get the max number of vcpus that kvm supports. It is, but by always returning the maximum number

Re: [libvirt] [Qemu-devel] [PATCH] kvm: warn if num cpus is greater than num recommended

- Original Message - Il 23/08/2013 13:33, Andrew Jones ha scritto: Does smp_cpus map to the current number of cpus, or to the number of possible cpus? If it maps to the number of possible cpus, then this is the right place. If the former, then I guess it'll take more thought

Re: [libvirt] [Qemu-devel] [PATCH] kvm: warn if num cpus is greater than num recommended

- Original Message - Am 22.08.2013 18:12, schrieb Eduardo Habkost: On 22/08/2013, at 12:39, Andrew Jones drjo...@redhat.com wrote: The comment in kvm_max_vcpus() states that it's using the recommended procedure from the kernel API documentation to get the max number

[libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended

for the fail case was slightly changed, 'exceeds max cpus' to 'exceeds the maximum cpus'. If this is unacceptable change for users like libvirt, then I'll need to spin a v3. Signed-off-by: Andrew Jones drjo...@redhat.com --- kvm-all.c | 69

Re: [libvirt] ivshmem server

Cam, ping Please let us know your opinion on integrating ivshmem-server into libvirt. Also, please confirm the licensing would allow it. Thanks, Drew - Original Message - - Original Message - On Tue, Nov 20, 2012 at 01:16:56PM -0500, Andrew Jones wrote: This mail

Re: [libvirt] ivshmem server

- Original Message - On Tue, Nov 20, 2012 at 01:16:56PM -0500, Andrew Jones wrote: This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list. ivshmem is an implementation of an inter-VM communication

[libvirt] ivshmem server

This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list. ivshmem is an implementation of an inter-VM communication channel. Support for this has been in qemu since v0.14.0 and libvirt patches have been recently posted[1].