;'''''''''''''''''''''''''''
> +``-vnc ...,tls=...``, ``-vnc ...,x509=...`` & ``-vnc ...,x509verify=...``
> (removed in 3.1)
> +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>
> 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
the 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
ch could lead to an incorrect topology enumeration by the guest.
> -Support for invalid topologies is removed, the user must ensure
> -topologies described with -smp include all possible cpus, i.e.
> -*sockets* * *cores* * *threads* = *maxcpus*.
> -
> ``-machine enforce-config-section=on|off`` (removed 5.2)
> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>
> --
> 2.19.1
>
Reviewed-by: Andrew Jones
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
> >
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:
> >>>
> >>>
> >>>
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:
> > +#
> > +# Acceler
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,
> > >
uot;, cpus);
> +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
to make 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:
>
to make 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 * core
to make 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:
> -
to make sure that
>[sockets * cores * threads] == [maxcpus]
>
> Signed-off-by: Igor Mammedov
> ---
> v2:
> - spelling&&co fixes (Andrew Jones )
> ---
> qemu-deprecated.texi | 11 +++
> vl.c | 6 ++
> 2 files changed, 17 inser
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
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 a different machine
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 environment
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
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 I'd like to make sure c
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 due
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
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, Markus Armbruster w
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 Armbruster wrote:
> Peter Xu writes:
> Adding ad hoc qu
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
> > possible that HW supports m
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:
>
On Tue, Feb 02, 2016 at 01:15:49PM +, Peter Maydell wrote:
> On 2 February 2016 at 12:59, Andrew Jones 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. Although mayb
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 2
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 soun
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
> > > wrote:
> >
On Tue, Dec 15, 2015 at 04:42:13PM +, Peter Maydell wrote:
> On 15 December 2015 at 16:35, Andrew Jones wrote:
> > This is probably good for guests that happy with both. Guests that
> > need/want a specific choice will put their integer there, and then
> > we need a way
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
> >> wrote:
> >>>
> >>> We do pass some options, for
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 "-mac
- 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, b
- 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 gues
r
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
---
kvm-all.c | 69 -
- Original Message -
> Am 22.08.2013 18:12, schrieb Eduardo Habkost:
> >
> > On 22/08/2013, at 12:39, Andrew Jones wrote:
> >
> >> The comment in kvm_max_vcpus() states that it's using the recommended
> >> procedure from the kernel API docum
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, And
- 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.
> >
> >
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]. What'
37 matches
Mail list logo
