On Fri, Apr 14, 2023 at 15:44:10 +0200, Martin Kletzander wrote:
> On Fri, Mar 31, 2023 at 02:00:32PM +0200, Peter Krempa wrote:
> > Currently we allow configuring the 'poll-max-ns', 'poll-grow', and
> > 'poll-shrink' parameters of qemu iothreads only during runtime and they
> > are not persisted.
The document grew a bit too much explaining all the mistakes we've seen
the users do when configuring logging. Add a section distilling the
configuration of the most basic scenario which we can refer to when
upstream issues are reported. The scenario is for a runtime setting of
logging into a file
On Fri, Apr 14, 2023 at 03:14:49PM -0600, Jim Fehlig wrote:
> Signed-off-by: Jim Fehlig
> ---
> NEWS.rst | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/NEWS.rst b/NEWS.rst
> index 6bc5a59c0d..76a7e8de98 100644
> --- a/NEWS.rst
> +++ b/NEWS.rst
> @@ -19,6 +19,12 @@ v9.3.0
On Fri, Apr 14, 2023 at 03:14:48PM -0600, Jim Fehlig wrote:
> It's quite difficult, if not impossible, to create a working riscv64 VM
> using the current default machine type of 'spike_v1.10'. Change the
> default to the more appropriate and virtualization friendly 'virt'
> machine type.
>
>
On Fri, Apr 14, 2023 at 03:14:46PM -0600, Jim Fehlig wrote:
> On aarch64, the default CPU for machine type 'virt' is 'cortex-a15',
> which works fine for , but fails for type='kvm'
>
> 2023-04-14T21:03:03.392256Z qemu-system-aarch64: KVM is not supported for
> this guest CPU type
>
> Do we need
On Fri, Apr 14, 2023 at 03:14:47PM -0600, Jim Fehlig wrote:
> It's quite difficult, if not impossible, to create a working aarch64 VM
> using the current default machine type of 'integratorcp'. Change the
> default to the more appropriate and virtualization friendly 'virt'
> machine type.
>
>
From: Marc-André Lureau
meson wraps python scripts already on win32, so we end up with these
failing commands:
[1/359] "C:/msys64/ucrt64/bin/meson" "--internal" "exe" "--capture"
"src/util/virkeycodetable_atset1.h" "--" "sh"
"C:/msys64/home/marca/src/libvirt/scripts/meson-python.sh"
From: Marc-André Lureau
The function does not exist on win32.
Signed-off-by: Marc-André Lureau
Signed-off-by: Michal Privoznik
Reviewed-by: Michal Privoznik
---
src/rpc/virnetlibsshsession.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
From: Marc-André Lureau
Follow better meson build system conventions. This allows to find
keymap-gen or CSV without explicitly setting the paths.
Signed-off-by: Marc-André Lureau
---
.gitmodules | 2 +-
meson.build | 1 +
src/util/meson.build
From: Marc-André Lureau
Hi,
libvirt fails to compile on msys2/win32.
Also update keycodemapdb to fix CI build issues, and turn it into a
subproject(), as that makes things simpler for meson.
Fixes:
https://gitlab.com/libvirt/libvirt/-/issues/453
v2:
- update based on Michal version
-
From: Marc-André Lureau
Or meson will complain with:
../meson.build:770:2: ERROR: Search directory /sbin is not an absolute path.
Signed-off-by: Marc-André Lureau
Reviewed-by: Michal Privoznik
---
meson.build | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git
From: Marc-André Lureau
A number of changes, but notably python script shebang fixing build
issues in CI:
Daniel P. Berrangé (1):
Revert "Add local argparse for compat with python 2.6"
Dawid Dziurla (1):
Don't hardcode python3 path in shebang
Eli Schwartz (1):
make the
From: Marc-André Lureau
Use 'dirs' argument to locate the program.
Signed-off-by: Marc-André Lureau
---
src/util/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/meson.build b/src/util/meson.build
index 2fe6f7699e..f055079d0b 100644
---
On 4/15/23 15:48, wangjian (AN) wrote:
> Hi Guys,
>
>
>
> Currently qemu and spdk already support vhost-user-scsi, but there is no
> vhost-user-scsi configuration in libvirt.
>
> We hope that libvirt supports the following configurations to facilitate
> docking with qemu.
>
>
>
>
>
>
On 4/13/23 17:22, Ján Tomko wrote:
> On a Thursday in 2023, Michal Prívozník wrote:
>> On 3/22/23 11:07, Michal Prívozník wrote:
>>> On 3/17/23 15:59, Peter Krempa wrote:
On Thu, Mar 16, 2023 at 14:21:27 +0100, Ján Tomko wrote:
> If we don't have dnsmasq, it's pointless to try to find
Assume there's a dnsmasq running (because there's an active
virtual network that spawned it). Now, shut down the daemon,
remove the dnsmasq binary and start the daemon again. At this
point, networkUpdateState() is called, but dnsmasq_caps is NULL
(because networkStateInitialize() called earlier
*** BLURB HERE ***
Michal Prívozník (3):
networkUpdateState: do not assume dnsmasq_caps
conf: Initialize _virNetworkObj::dnsmasqPid to -1 in
virNetworkObjNew()
networkRefreshDhcpDaemon: Get dnsmasq's PID once
src/conf/virnetworkobj.c| 1 +
src/network/bridge_driver.c | 7 +--
Throughout all of our network driver code we assume that
dnsmasqPid of value -1 means the network has no dnsmasq process
running. There are plenty of calls to:
virNetworkObjSetDnsmasqPid(obj, -1);
or:
pid_t dnsmasqPid = virNetworkObjGetDnsmasqPid(obj);
if (dnsmasqPid > 0) ...;
Now, a
This is a relict of v3.7.0-rc1~132 when getter/setter APIs for
dnsmasq's PID were introduced. Previously, obj->dnsmasqPid was
accessed directly. But the aforementioned commit introduced two
calls to virNetworkObjGetDnsmasqPid() even though the result of
the first call is stored in a variable.
We are getting close to the next release of libvirt. To aim for the
release on May 02 I suggest entering the freeze on Tuesday Apr 25 and
tagging RC2 on Thursday Apr 27.
I hope this works for everyone.
Jirka
On 4/17/23 13:53, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Hi,
>
> libvirt fails to compile on msys2/win32.
>
> Also update keycodemapdb to fix CI build issues, and turn it into a
> subproject(), as that makes things simpler for meson.
>
> Fixes:
>
On 4/17/23 13:38, Peter Krempa wrote:
> The document grew a bit too much explaining all the mistakes we've seen
> the users do when configuring logging. Add a section distilling the
> configuration of the most basic scenario which we can refer to when
> upstream issues are reported. The scenario
On Mon, Apr 17, 2023 at 01:38:31PM +0200, Peter Krempa wrote:
> The document grew a bit too much explaining all the mistakes we've seen
> the users do when configuring logging. Add a section distilling the
> configuration of the most basic scenario which we can refer to when
> upstream issues are
On Mon, Apr 17, 2023 at 01:16:34PM +0200, Peter Krempa wrote:
On Fri, Apr 14, 2023 at 15:44:10 +0200, Martin Kletzander wrote:
On Fri, Mar 31, 2023 at 02:00:32PM +0200, Peter Krempa wrote:
> Currently we allow configuring the 'poll-max-ns', 'poll-grow', and
> 'poll-shrink' parameters of qemu
On Fri, Apr 14, 2023 at 4:23 PM Michal Privoznik
wrote:
> *** BLURB HERE ***
>
> Michal Prívozník (2):
> virsh: Introduce --xpath and --wrap to capabilities
> virsh: Introduce --xpath and --wrap to domcapabilities
>
> docs/manpages/virsh.rst | 17 ++-
> tools/virsh-host.c |
The command line option '-singlestep' and its HMP equivalent
the 'singlestep' command are very confusingly named, because
they have nothing to do with single-stepping the guest (either
via the gdb stub or by emulation of guest CPU architectural
debug facilities). What they actually do is put TCG
The HMP 'singlestep' command, the QMP 'query-status' command and the
HMP 'info status' command (which is just wrapping the QMP command
implementation) look at the 'singlestep' global variable. Make them
access the new TCG accelerator 'one-insn-per-tb' property instead.
This leaves the HMP and QMP
Currently we report whether the TCG accelerator is in
'one-insn-per-tb' mode in the 'info status' output. This is a pretty
minor piece of TCG specific information, and we want to deprecate the
'singlestep' field of the associated QMP command. Move the
'one-insn-per-tb' reporting to 'info jit'.
The '-singlestep' option is confusing, because it doesn't actually
have anything to do with single-stepping the CPU. What it does do
is force TCG emulation to put one guest instruction in each TB,
which can be useful in some situations.
Create a new command line argument -one-insn-per-tb, so we
The 'singlestep' HMP command is confusing, because it doesn't
actually have anything to do with single-stepping the CPU. What it
does do is force TCG emulation to put one guest instruction in each
TB, which can be useful in some situations.
Create a new HMP command 'one-insn-per-tb', so we can
This commit adds 'one-insn-per-tb' as a property on the TCG
accelerator object, so you can enable it with
-accel tcg,one-insn-per-tb=on
It has the same behaviour as the existing '-singlestep' command line
option. We use a different name because 'singlestep' has always been
a confusing choice,
The only place left that looks at the old 'singlestep' global
variable is the TCG curr_cflags() function. Replace the old global
with a new 'one_insn_per_tb' which is defined in tcg-all.c and
declared in accel/tcg/internal.h. This keeps it restricted to the
TCG code, unlike 'singlestep' which
The run-state.json file is missing a trailing newline; add it.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
---
Noticed this because my editor wanted to add the newline
when I touched the file for the following patch...
---
qapi/run-state.json | 2 +-
1 file changed, 1
The '-singlestep' option is confusing, because it doesn't actually
have anything to do with single-stepping the CPU. What it does do
is force TCG emulation to put one guest instruction in each TB,
which can be useful in some situations.
Create a new command line argument -one-insn-per-tb, so we
Document that the -singlestep command line option is now
deprecated, as it is replaced by either the TCG accelerator
property 'one-insn-per-tb' for system emulation or the new
'-one-insn-per-tb' option for usermode emulation, and remove
the only use of the deprecated syntax from a README.
The 'singlestep' member of StatusInfo has never done what the QMP
documentation claims it does. What it actually reports is whether
TCG is working in "one guest instruction per translation block" mode.
We no longer need this field for the HMP 'info status' command, as
we've moved that
It's quite difficult, if not impossible, to create a usable ARM VMs
using the current default machine type of 'integratorcp'. Change the
default to the more appropriate and virtualization friendly 'virt'
machine type.
Signed-off-by: Jim Fehlig
---
src/qemu/qemu_capabilities.c
It is difficult, if not impossible, to create usable ARM and RISC-V VMs
using the current default machine types of 'integratorcp' and 'spike_v1.10'.
Change the default to the more suitable 'virt' type. See the following
thread for more details
It's quite difficult, if not impossible, to create a working RISC-V VMs
using the current default machine type of 'spike_v1.10'. Change the
default to the more appropriate and virtualization friendly 'virt'
machine type.
Signed-off-by: Jim Fehlig
---
src/qemu/qemu_capabilities.c
Signed-off-by: Jim Fehlig
---
NEWS.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 6bc5a59c0d..33355cb74c 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -19,6 +19,12 @@ v9.3.0 (unreleased)
* **Improvements**
+* qemu: Change default machine type for ARM
On Mon, Apr 17, 2023 at 16:15:29 +0100, Daniel P. Berrangé wrote:
> On Mon, Apr 17, 2023 at 01:38:31PM +0200, Peter Krempa wrote:
> > The document grew a bit too much explaining all the mistakes we've seen
> > the users do when configuring logging. Add a section distilling the
> > configuration of
On 4/17/23 05:57, Andrea Bolognani wrote:
On Fri, Apr 14, 2023 at 03:14:46PM -0600, Jim Fehlig wrote:
On aarch64, the default CPU for machine type 'virt' is 'cortex-a15',
which works fine for , but fails for type='kvm'
2023-04-14T21:03:03.392256Z qemu-system-aarch64: KVM is not supported for
42 matches
Mail list logo
