On Mon, Feb 03, 2025 at 07:07:36PM +0100, Pavel Hrdina wrote:
> Fedora and Alpine updated to latest versions.
Technically the latest version of Alpine is 3.21, we just haven't
updated lcitool to support it yet ;)
> -.fedora-39-upstream-qemu-tests:
> +.fedora-41-upstream-qemu-tests:
>extends:
On 3/2/25 15:50, Daniel P. Berrangé wrote:
On Mon, Feb 03, 2025 at 02:45:06PM +, Peter Maydell wrote:
On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé wrote:
On Mon, Feb 03, 2025 at 02:29:49PM +, Alex Bennée wrote:
Peter Maydell writes:
On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan
Full rewrite of v1 [1], addressing Zoltan & Peter suggestion.
Introduce a generic 'raspi' machine, which takes a 'model'
and 'revision' properties, and any memory size. The 'board_rev'
register is filled appropriately.
Before, merge raspi4b.c within raspi.c (more is planned here
with the MPCore r
Except we alter the device tree blob, the 4B
is just another raspi model.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 114 -
hw/arm/raspi4b.c | 136 -
hw/arm/meson.build | 2 +-
3 files changed
We shouldn't access a QOM parent object directly.
Use the appropriate type-cast macro.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 2 +-
hw/arm/raspi4b.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index a7a662f40db..508
Merge Raspi4bMachineState within RaspiMachineState by
using an unnamed union.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 3fa382d62ce..ef94d57dab5 100644
Raspberry Pi 'B' models have an ethernet chipset (the LAN9512).
Since we don't yet model it, add a /* TODO */ comment.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 1a6a1f8ff22..6
Expand the current type2model array to include the processor id.
Since the BCM2838 is indistinctly used as BCM2711 (within the
Linux community), add it as alias in RaspiProcessorId.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 33 +++--
1 file changed,
Since callers already have reference to the RaspiBaseMachineClass,
directly pass 'board_rev' as argument to raspi_base_machine_init().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/raspi_platform.h | 2 +-
hw/arm/raspi.c | 8 +++-
2 files changed, 4 insertions(+),
The generic 'raspi' machine takes a 'model' argument and
create the machine associated with the model, with the
RAM size requested (or default to the minimum of 256MB
if not precised).
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2797
Signed-off-by: Philippe Mathieu-Daudé
---
include/
Add a property to specify the board revision. This allows to
create a Raspberry Pi 2B with BCM2836 SoC (rev 1.0 and 1.1)
or BCM2837 (rev 1.2 up to 1.5).
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 39 +++
1 file changed, 39 insertions(+)
diff -
All the following models can be created (with different RAM size):
$ qemu-system-aarch64 -M raspi
qemu-system-aarch64: Missing model, try -M raspi,model=help
$ qemu-system-aarch64 -M raspi,model=help
Available models (processor):
- A (BCM2835)
- B (BCM2835)
- A+
All previous raspi machines can be created using the
generic machine. Deprecate the old names to maintain
a single one. Update the tests.
Signed-off-by: Philippe Mathieu-Daudé
---
QOM HMP introspection test fails because without the 'model'
argument set, no machine is created...
$ qemu-system-
Allow to create the following machines:
- Zero2W
- 400
- CM4 and CM4S
Fill the arrays with the BCM2712-based machines (raspi5),
but since we don't model the SoC, these machines can't
be created (and aren't listed in the 'help' output).
List taken from:
https://github.com/raspberrypi/docume
Add the 'max_ramsize' field to the soc_property[] array,
corresponding to the maximum DRAM size a SoC can map.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/raspi.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index
On Mon, Feb 03, 2025 at 01:26:26PM -0600, Andrea Bolognani wrote:
> On Mon, Feb 03, 2025 at 07:07:36PM +0100, Pavel Hrdina wrote:
> > Fedora and Alpine updated to latest versions.
>
> Technically the latest version of Alpine is 3.21, we just haven't
> updated lcitool to support it yet ;)
Oh well
On Mon, 3 Feb 2025, Philippe Mathieu-Daudé wrote:
On 3/2/25 15:50, Daniel P. Berrangé wrote:
On Mon, Feb 03, 2025 at 02:45:06PM +, Peter Maydell wrote:
On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé
wrote:
On Mon, Feb 03, 2025 at 02:29:49PM +, Alex Bennée wrote:
Peter Maydell writ
On Mon, Feb 03, 2025 at 09:07:59PM +0100, Pavel Hrdina wrote:
> On Mon, Feb 03, 2025 at 01:26:26PM -0600, Andrea Bolognani wrote:
> > Has the Fedora 41 environment for integration tests actually been
> > created? Because this won't work otherwise.
>
> Most likely not, still don't have access to the
Alexander Shursha wrote:
> Sponsored by: Future Crew, LLC
> Signed-off-by: Alexander Shursha
> ---
> src/bhyve/bhyve_command.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
> index bc287307c8..16986c9d53
There are basically two differences between virtio-mem-ccw and
virtio-mem-pci. s390 doesn't allow mixing different page sizes
and there's no NUMA support in QEMU.
Signed-off-by: Michal Privoznik
Reviewed-by: Boris Fiuczynski
---
src/qemu/qemu_validate.c | 35 ---
After previous commits, we can allow virtio-mem to live on CCW
channel.
Signed-off-by: Michal Privoznik
Reviewed-by: Boris Fiuczynski
---
src/qemu/qemu_domain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 6554b992f0
This is similar to emuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
except the explicit placement of virtio-mem onto a PCI bus is removed.
This results in virtio-mem being placed onto CCW "bus" this demonstrating
previous commits working as expected.
Signed-off-by: Michal Privoznik
---
...
As of v9.2.0-1413-gd77ae821e8 QEMU supports virtio-mem-pci on
s390 too. Let's add a test case for that.
Signed-off-by: Michal Privoznik
---
...lug-virtio-mem-pci-s390x.s390x-latest.args | 41 +++
...plug-virtio-mem-pci-s390x.s390x-latest.xml | 71 +++
.../memory-hotplug-v
This capability tracks whether QEMU supports virtio-mem-ccw
device. Introduced in QEMU commit v9.2.0-492-gaa910c20ec only
upcoming release of QEMU supports the device.
Signed-off-by: Michal Privoznik
Reviewed-by: Boris Fiuczynski
---
src/qemu/qemu_capabilities.c | 2 ++
src/
In some cases, we might automatically add a NUMA node. But this
doesn't work for s390 really, because in its commit
v2.12.0-rc0~41^2~6 QEMU forbade specifying NUMA nodes for s390.
Suppress automatic adding of NUMA node on our side.
Signed-off-by: Michal Privoznik
Reviewed-by: David Hildenbrand
R
Both, virtio-mem and virtio-pmem devices follow traditional QEMU
naming convention: their suffix determines what bus they live on.
For instance, virtio-mem-pci, virtio-mem-ccw, virtio-pmem-pci.
We already have a function that constructs device name following
this convention: qemuBuildVirtioDevGetCo
On Mon, Feb 03, 2025 at 10:52:23 +0100, Peter Krempa wrote:
> On Wed, Jan 08, 2025 at 19:42:54 +, Daniel P. Berrangé wrote:
> > Currently the remote daemon code is responsible for calling virStateStop
> > in a background thread. The virNetDaemon code wants to synchronize with
> > this during sh
On Wed, Jan 08, 2025 at 19:42:55 +, Daniel P. Berrangé wrote:
> The call to preserve state (ie running VMs) is triggered in response to
> the desktop session dbus terminating (session daemon), or logind sending
> a "PrepareForShutdown" signal. In the case of the latter, daemons
> should only sa
On Wed, Jan 08, 2025 at 19:42:54 +, Daniel P. Berrangé wrote:
> Currently the remote daemon code is responsible for calling virStateStop
> in a background thread. The virNetDaemon code wants to synchronize with
> this during shutdown, however, so the virThreadPtr must be passed over.
>
> Even
v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KA2DGRIY7DAMNMYM4MBKLOJCB7YYEUKU/
diff to v1:
- Previously, virtio-mem-pci wasn't supported (in fact QEMU errored
out), but this changed in QEMU upstream, so this limitation is lifted.
- Added a test case for virtio-m
Signed-off-by: Michal Privoznik
Reviewed-by: Boris Fiuczynski
---
NEWS.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 20bf01c8d7..4b60cf0060 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -38,6 +38,11 @@ v11.1.0 (unreleased)
etc. Libvirt will now read these
On Mon, Feb 03, 2025 at 09:29:52 -, Harikumar Rajkumar wrote:
> > On Mon, Nov 18, 2024 at 19:24:24 +0530, Harikumar R wrote:
> > This will most likely need to be reimplemented by querying the data from
> > the XML as the API itself IMO doesn't make too much sense to exist as it
> > simply queri
On Wed, Jan 08, 2025 at 19:42:56 +, Daniel P. Berrangé wrote:
> The preserving of state (ie running VMs) requires a fully functional
> daemon and hypervisor driver. If any part has started shutting down
> then saving state may fail, or worse, hang.
>
> The current shutdown sequence does not gu
Peter Maydell writes:
> On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan wrote:
>>
>> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
>> > - Deprecate the 'raspi4b' machine name, renaming it as
>> > 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g' otherwise.
>> > - Add the 'raspi4b-4g' and 'raspi4b-8g'
On Mon, Feb 03, 2025 at 02:29:49PM +, Alex Bennée wrote:
> Peter Maydell writes:
>
> > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan wrote:
> >>
> >> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
> >> > - Deprecate the 'raspi4b' machine name, renaming it as
> >> > 'raspi4b-1g' on 32-bit h
(Somehow I never received the original of this message into my libvirt
folder. Possibly my email client mistakenly decided it was spam...)
On 2/3/25 8:36 AM, Martin Kletzander wrote:
On Tue, Dec 24, 2024 at 05:26:29PM +0800, Xuda Zhang wrote:
Dear Team,
Hi, not sure if this is still relevan
On Wed, Jan 08, 2025 at 19:42:57 +, Daniel P. Berrangé wrote:
> The daemons are wired up to shutdown in responsible to UNIX process
> signals, as well as in response to login1 dbus signals, or loss of
> desktop session. The latter two options can optionally preserve state
> (ie running VMs).
>
On Wed, Jan 08, 2025 at 19:42:58 +, Daniel P. Berrangé wrote:
> The service unit "TimeoutStopSec" setting controls how long systemd
> waits for a service to stop before aggressively killing it, defaulting
> to 30 seconds if not set.
>
> When we're processing shutdown of VMs in response to OS s
The variable holds the amount of disks to roll back the snapshot for.
The value must be set before the code jumps to the 'rollback:' label so
the best situation is to not initialize it and let the compiler catch
errors rather than initialize the unsigned variable to -1 and let it
crash.
Signed-off
Peter Krempa (3):
qemuSnapshotForEachQcow2: Don't initialize 'nrollback'
qemu: process: Export qemuPrepareNVRAM for use in snapshot code
qemu: snapshot: Ensure that NVRAM image exists when taking inactive
internal snapshot
src/qemu/qemu_process.c | 26 ++
src/qe
Export qemuPrepareNVRAM so that it doesn't require the VM object. The
snapshot code needs in the corner case of creating a snapshot of a
freshly defined VM ensure that the nvram image exists in order to
snapshot it.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_process.c | 26 ++-
Attempting to take an internal snapshot of a freshly defined VM with
qcow2 backed NVRAM results in failure as the NVRAM image doesn't get
populated until the VM is started for the first time.
Fix this by invoking qemuPrepareNVRAM() when qcow2 nvram is defined.
Resolves: https://issues.redhat.com/
Reviewed-by: Boris Fiuczynski
On 2/3/25 10:55, Michal Privoznik wrote:
This is similar to emuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
except the explicit placement of virtio-mem onto a PCI bus is removed.
This results in virtio-mem being placed onto CCW "bus" this demonstrating
previ
Reviewed-by: Boris Fiuczynski
On 2/3/25 10:55, Michal Privoznik wrote:
As of v9.2.0-1413-gd77ae821e8 QEMU supports virtio-mem-pci on
s390 too. Let's add a test case for that.
Signed-off-by: Michal Privoznik
---
...lug-virtio-mem-pci-s390x.s390x-latest.args | 41 +++
...plug-virtio-m
On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé wrote:
>
> On Mon, Feb 03, 2025 at 02:29:49PM +, Alex Bennée wrote:
> > Peter Maydell writes:
> >
> > > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan wrote:
> > >>
> > >> On Sat, 1 Feb 2025, Philippe Mathieu-Daudé wrote:
> > >> > - Deprecate the
On Mon, Feb 03, 2025 at 02:45:06PM +, Peter Maydell wrote:
> On Mon, 3 Feb 2025 at 14:33, Daniel P. Berrangé wrote:
> >
> > On Mon, Feb 03, 2025 at 02:29:49PM +, Alex Bennée wrote:
> > > Peter Maydell writes:
> > >
> > > > On Sat, 1 Feb 2025 at 12:57, BALATON Zoltan wrote:
> > > >>
> > >
'qemuDomainSupportsCheckpointsBlockjobs()' should really be used only
with active VMs based on the scope of interlocking it does.
This means that the inactive snapshot code path needs to do the
interlocking based on what's supported:
- external snapshot support was not implemented yet
(bitmap
Fixes: cf32953f5b6ec30386f71b40cf458467752a6dca
Signed-off-by: Pavel Hrdina
---
Pushed
libvirt.spec.in | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index be91fa6bb4..cb41ea1de1 100644
--- a/libvirt.spec.in
+++ b/lib
Fedora and Alpine updated to latest versions.
Signed-off-by: Pavel Hrdina
---
ci/buildenv/{alpine-319.sh => alpine-320.sh} | 0
ci/buildenv/debian-11-cross-aarch64.sh| 2 +-
ci/buildenv/debian-11-cross-armv6l.sh | 2 +-
ci/buildenv/debian-11-cross-armv7l.sh | 2 +-
c
On Wed, Jan 08, 2025 at 19:42:33 +, Daniel P. Berrangé wrote:
This series really deserves a NEWS entry where you can explain how to
use this instead of libvirt-guests so that users are motivated to
switch.
On Wed, Jan 08, 2025 at 19:42:59 +, Daniel P. Berrangé wrote:
> Since processing running VMs on OS shutdown can take a while, it is
> beneficial to send systemd status messages about the progress.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> src/hypervisor/domain_driver.c | 15 +
On Tue, Dec 24, 2024 at 05:26:29PM +0800, Xuda Zhang wrote:
Dear Team,
Hi, not sure if this is still relevant, but ...
I am reaching out regarding an issue I encountered with libvirt and MAC
address conflicts. Below is a summary of the situation:
1. Initially, the vNIC's MAC address was d
On Thu, Jan 30, 2025 at 06:21:07PM +0100, Peter Krempa wrote:
> On Wed, Jan 08, 2025 at 19:42:44 +, Daniel P. Berrangé wrote:
> > Currently automatic VM managed save is only performed in session
> > daemons, on desktop session close, or host OS shutdown request.
> >
> > With this change it is
On Fri, Jan 31, 2025 at 10:20:23AM +0100, Peter Krempa wrote:
> On Wed, Jan 08, 2025 at 19:42:45 +, Daniel P. Berrangé wrote:
> > Currently the session daemon will try a managed save on all VMs,
> > leaving them running if that fails.
> >
> > This limits the managed save just to persistent VMs
On Mon, 3 Feb 2025 at 14:50, Daniel P. Berrangé wrote:
>
> On Mon, Feb 03, 2025 at 02:45:06PM +, Peter Maydell wrote:
> > For Arm embedded boards we mostly tend to "restrict the user
> > to what you can actually do", except for older boards where
> > we tended not to write any kind of sanity c
On Wed, Jan 08, 2025 at 19:42:42 +, Daniel P. Berrangé wrote:
> The auto shutdown code can currently only perform managed save,
> which may fail in some cases, for example when PCI devices are
> assigned. On failure, shutdown inhibitors remain in place which
> may be undesirable.
>
> This expa
> On Mon, Nov 18, 2024 at 19:24:24 +0530, Harikumar R wrote:
> This will most likely need to be reimplemented by querying the data from
> the XML as the API itself IMO doesn't make too much sense to exist as it
> simply queries what we've set.
are you suggesting to use qemuDomainGetXMLDesc() to ge
On Wed, Jan 08, 2025 at 19:42:54 +, Daniel P. Berrangé wrote:
> Currently the remote daemon code is responsible for calling virStateStop
> in a background thread. The virNetDaemon code wants to synchronize with
> this during shutdown, however, so the virThreadPtr must be passed over.
>
> Even
Alexander Shursha wrote:
> Linux gets the list via sysfs. FreeBSD can get the list through
> ioctl
>
> Sponsored by: Future Crew, LLC
> Signed-off-by: Alexander Shursha
> ---
> src/bhyve/bhyve_capabilities.c | 2 +-
> src/conf/node_device_conf.c | 2 +-
> src/node_device/no
59 matches
Mail list logo
