On 15/1/25 08:38, Thomas Huth wrote:
Now that the machine types that set the migration_enabled flag to
false are gone, we can remove it and the related code.
Signed-off-by: Thomas Huth
---
include/hw/s390x/s390_flic.h | 1 -
hw/intc/s390_flic.c | 14 --
2 files changed
On 15/1/25 08:38, Thomas Huth wrote:
Now that the machine types 2.11 and older have been removed, we
don't need the "allow_all_mask_sizes" compatibility handling code
anymore and can remove it now.
Signed-off-by: Thomas Huth
---
hw/s390x/event-facility.c | 37 +
On Wednesday, January 15, 2025 11:08:49 AM CET Greg Kurz wrote:
> I still review 9pfs changes from time to time but I'm definitely
> not able to do actual maintainer work. Drop my tree on the way
> as I'll obviously not use it anymore, and it has been left
> untouched since May 2020.
>
> Signed-of
As described at: ACPI 6.5 spec at:
18.3.2. ACPI Error Source
In particular at GHES/GHESv2 table:
Table 18.10 Generic Hardware Error Source Structure
HEST source ID is actually a 16-bit value.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
Reviewed-by: Igor M
On Wed, Jan 15, 2025 at 01:46:29PM +0900, Akihiko Odaki wrote:
> On 2025/01/15 2:02, Peter Xu wrote:
> > On Tue, Jan 14, 2025 at 05:43:09PM +0900, Akihiko Odaki wrote:
> > > memory_region_finalize() is not a function to tell the owner is leaving,
> > > but
> > > the memory region itself is being d
On Wed, 15 Jan 2025 15:58:34 +0800
Li Zhijian wrote:
> This assertion always happens when we sanitize the CXL memory device.
> $ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
>
> It is incorrect to register an MSIX number beyond the device's capability.
>
> Increase the device's MSIX num
> > I remember that this was your idea all along, and I'm not sure if you're
> > also referring to my previous patches about hybrid topology :-), which I'll
>
> I'm sorry, I've should've reviewed it long time ago.
> But it got lost in from my review queue, can you give me a pointer
> to the latest
ssu64xl is defined in RVA22 as:
"sstatus.UXL must be capable of holding the value 2 (i.e., UXLEN=64 must
be supported)."
This is always true in TCG and it's mandatory for RVA23, so claim
support for it.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
---
target/riscv/cpu.c
The current 'parent' mechanic for profiles allows for one profile to be
a child of a previous/older profile, enabling all its extensions (and
the parent profile itself) and sparing us from tediously listing all
extensions for every profile.
This works fine for u-mode profiles. For s-mode profiles
Add RVA23S64 as described in [1]. This profile inherits all mandatory
extensions of RVA23U64 and RVA22S64, making it a child of both profiles.
A new "rva23s64" profile CPU is also added. This is the generated
riscv,isa for it (taken via -M dumpdtb):
rv64imafdcbvh_zic64b_zicbom_zicbop_zicboz_zicca
Add RVA23U64 as described in [1]. Add it as a child of RVA22U64 since
all RVA22U64 mandatory extensions are also present in RVA23U64. What's
left then is to list the mandatory extensions that are RVA23 only.
A new "rva23u64" CPU is also added.
[1] https://github.com/riscv/riscv-profiles/blob/main
Hi,
In this new version we're now implementing u-mode and s-mode profile
dependencies, as suggested by Drew in v2. This makes implementing s-mode
profiles easier since those profiles usually inherits from both their
equivalent u-mode profiles and from a previous s-mode profile.
This is done in pa
On Wed, 15 Jan 2025 15:58:46 +0800
Li Zhijian wrote:
> Introduce the `CXL_T3_MSIX_VECTOR` enumeration to specify MSIX vector
> assignments specific to the Type 3 (T3) CXL device.
>
> The primary goal of this change is to encapsulate the MSIX vector uses
> that are unique to the T3 device within
The S profiles do a priv_ver check during validation to see if the
running priv_ver is compatible with it. This check is done by comparing
if the running priv_ver is equal to the priv_ver the profile specifies.
There is an universe where we added RVA23S64 support based on both
RVA23U64 and RVA22S6
Add support of VHOST_USER_PROTOCOL_F_DEVICE_STATE in virtio-net
with vhost-user backend.
Cc: Hanna Czenczek
Signed-off-by: Laurent Vivier
---
hw/net/virtio-net.c | 135
1 file changed, 112 insertions(+), 23 deletions(-)
diff --git a/hw/net/virtio-ne
Migration state transfer interface is only used by vhost-user-fs,
so the interface needs to be defined only when vhost is built.
But I need to use this interface with virtio-net and vhost is not always
enabled, and to avoid undefined reference error during build, define stub
functions for vhost_su
Add support of VHOST_USER_PROTOCOL_F_DEVICE_STATE in virtio-net
with vhost-user backend.
v2:
- Add stubs for the migration state transfer interface
Laurent Vivier (2):
vhost: Add stubs for the migration state transfer interface
virtio-net: vhost-user: Implement internal migration
include/
>From the time we added RVA22U64 until now the spec didn't declare 'RVB'
as a dependency, using zba/zbb/zbs instead. Since then the RVA22 spec
[1] added the following in the 'RVA22U64 Mandatory Extensions' section:
"B Bit-manipulation instructions
Note: The B extension comprises the Zba, Zbb, and
On Wed, 15 Jan 2025 11:22:14 +
Jonathan Cameron wrote:
> On Wed, 15 Jan 2025 07:48:59 +
> "Zhijian Li (Fujitsu)" wrote:
>
> > On 10/01/2025 23:44, Jonathan Cameron wrote:
> > > On Fri, 13 Dec 2024 17:36:02 +0800
> > > Li Zhijian wrote:
> > >
> > >> This assertion always happens
On Wed, 15 Jan 2025 at 14:05, Michael Tokarev wrote:
> 13.01.2025 00:00, Phil Dennis-Jordan wrote:
> > This patch set introduces a new ARM and macOS HVF specific machine type
> > called "vmapple". There are also some patches for fixing XHCI spec
> > compliance issues and adding a workaround to a
On 1/15/25 5:24 AM, Andrew Jones wrote:
On Tue, Jan 14, 2025 at 04:00:01PM -0300, Daniel Henrique Barboza wrote:
Add RVA23S64 as described in [1]. This profile inherits all mandatory
extensions of RVA23U64, making it a child of the U64 profile.
A new "rva23s64" profile CPU is also added. Thi
Hi Ani,
I made a mistake in sending my patchset and included one more patch
before my actual set starts.
I have resent the whole patch-set again
here.
https://lore.kernel.org/qemu-devel/20250114180611.353-1-alireza.san...@huawei.com/
Apologies for the confusion.
Thanks,
Alireza
On Wed, 15 Jan
I still review 9pfs changes from time to time but I'm definitely
not able to do actual maintainer work. Drop my tree on the way
as I'll obviously not use it anymore, and it has been left
untouched since May 2020.
Signed-off-by: Greg Kurz
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2
On Wed, Dec 18, 2024 at 03:34:53PM +0100, Laurent Vivier wrote:
> Add support of VHOST_USER_PROTOCOL_F_DEVICE_STATE in virtio-net
> with vhost-user backend.
>
> Cc: Hanna Czenczek
> Signed-off-by: Laurent Vivier
Breaks windows builds:
https://gitlab.com/mstredhat/qemu/-/jobs/8855973625
> ---
On Wed, Jan 15, 2025 at 11:51:05AM +0800, Huang Borong wrote:
> Remove the redundant masking of "hart_idx", as the same operation is
> performed later during address calculation.
>
> This change impacts the "hart_idx" value in the final qemu_log_mask()
> call. The original "hart_idx" parameter sho
g_spawn_check_exit_status() is renamed to g_spawn_check_wait_status()
in 2.70.
Signed-off-by: Akihiko Odaki
Tested-by: Lei Yang
---
include/glib-compat.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/glib-compat.h b/include/glib-compat.h
index 86be439ba0ef..a553ba13a3
g_spawn_sync() (for GLib < 2.68) or g_spawn_async_with_pipes_and_fds()
(for the newer) gives an informative message if it fails to execute
the script instead of reporting exiting status 1.
g_spawn_check_wait_status() also gives an message easier to understand
than the raw value returned by waitpid
g_spawn_async_with_pipes_and_fds() when available.
(Daniel P. Berrangé)
- Link to v3:
https://lore.kernel.org/r/20250115-glib-v3-0-bd3153344...@daynix.com
Changes in v3:
- Added GLIB_CHECK_VERSION(2, 70, 0) for patch "glib-compat: Define
g_spawn_check_wait_status()". (Daniel P
ui/cocoa used to have a conversion table from macOS keycode to QKeyCode.
It is an unnecessary redundancy as ui/input-keymap.c already has such a
table. Worse, I added an incorrect mapping of kVK_JIS_Eisu and
kVK_JIS_Kana with commit 708b72557ff5 ("ui/cocoa: Support unique keys of
JIS keyboards").
init_out_device may only commit some part of the result and leave the
state inconsistent when it encounters an error. Commit the result in
the end of the function so that it commits the result iff it sees no
error.
With this change, handle_voice_change can rely on core->outputDeviceID
to know whet
This series contains two fixes for coreaudio. See each one for details.
Signed-off-by: Akihiko Odaki
---
Akihiko Odaki (2):
coreaudio: Commit the result of init in the end
coreaudio: Initialize the buffer for device change
audio/audio_int.h | 2 ++
audio/audio.c | 24 ++
Reallocate buffers when the active device change as the required buffer
size may differ.
Signed-off-by: Akihiko Odaki
---
audio/audio_int.h | 2 ++
audio/audio.c | 24 ++--
audio/coreaudio.m | 1 +
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/audio/au
On Tue, Jan 14, 2025 at 08:39:37PM +0800, Xiaoyao Li wrote:
> On 12/17/2024 9:10 PM, Tony Lindgren wrote:
> > Hmm I don't think we should loop forever anywhere, the retries needed should
> > be only a few. Or what do you have in mind?
>
> "A few" seems not accurate. It depends on how heavy the RDR
Hi everyone,
There is a bug in this patch-set on loongarch (function signature of
build_pptt), that I will fix in the next version. Just wanted to point this
out. Anyhow I will allow time for hopefully some reviews first.
Thanks,
Alireza
-Original Message-
From: qemu-arm-bounces+alirez
The hardware error firmware is where HEST error structures are
stored. Those can be GHESv2, but they can also be other types.
Better name the location of the hardware error.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
Reviewed-by: Igor Mammedov
--
Now that we have also have a file to store HEST data location,
which is part of GHES, better name the file where CPER records
are stored.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Igor Mammedov
Reviewed-by: Jonathan Cameron
---
hw/acpi/ghes.c | 38 ++
The current function used to generate GHES data is specific for
memory errors. Give a better name for it, as we now have a generic
function as well.
Reviewed-by: Igor Mammedov
Reviewed-by: Jonathan Cameron
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/ghes-stub.c| 2 +-
hw/acpi/ghes.c
On Wed, Jan 15, 2025 at 10:12:45AM +0100, Jiri Denemark wrote:
> On Tue, Jan 14, 2025 at 18:07:30 -0500, Peter Xu wrote:
> > CI: https://gitlab.com/peterx/qemu/-/pipelines/1625266692
> > (note: warning is present on rust stuff, but shouldn't be relevant)
> >
> > This series refactors the migra
Igor Mammedov writes:
> On Mon, 13 Jan 2025 18:08:33 -0300
> Fabiano Rosas wrote:
>
>> Bug #2594 is about a failure during migration after a cpu hotplug. Add
>> a test that covers that scenario. Start the source with -smp 2 and
>> destination with -smp 3, plug one extra cpu to match and migrate.
Split the code into separate functions to allow using the
common CPER filling code by different error sources.
The generic code was moved to ghes_record_cper_errors(),
and ghes_gen_err_data_uncorrectable_recoverable() now contains
only a logic to fill the Generic Error Data part of the record,
as
This is just duplicating ACPI_GHES_ERROR_SOURCE_COUNT, which
has a better name. So, drop the duplication.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Igor Mammedov
Reviewed-by: Jonathan Cameron
---
hw/acpi/ghes.c | 7 ++-
include/hw/acpi/ghes.h | 3 ++-
2 files changed, 4 ins
28.12.2024 04:16, Gabriel Barrantes wrote:
From 532af9eecee4695abb02b40f2c18b711370aa7d2 Mon Sep 17 00:00:00 2001
From: Gabriel Barrantes
Date: Fri, 27 Dec 2024 18:02:32 -0600
Subject: [PATCH v2] backends/cryptodev-vhost-user: Fix local_error leaks
Do not propagate error to the upper, directly
On 15/1/25 13:53, Michael Tokarev wrote:
07.01.2025 11:43, Keoseong Park wrote:
In ufs_write_attr_value(), the value parameter is handled in the CPU's
endian format but provided in big-endian format by the caller. Thus, it
is converted to the CPU's endian format. The related test code is also
fi
13.01.2025 00:00, Phil Dennis-Jordan wrote:
This patch set introduces a new ARM and macOS HVF specific machine type
called "vmapple". There are also some patches for fixing XHCI spec
compliance issues and adding a workaround to a quirk in the macOS guest's
XHCI driver.
The vmapple machine type a
11.01.2025 21:36, Bernhard Beschow wrote:
In U-Boot, the fsl_esdhc[_imx] driver waits for both "transmit completed" and
"DMA" bits in esdhc_send_cmd_common() by means of DATA_COMPLETE constant. QEMU
currently misses to set the DMA bit which causes the driver to loop forever. Fix
that by setting t
On Tue, 14 Jan 2025 22:38:30 +0800
Zhao Liu wrote:
> > I this specific case, one basically replaces /machine/unattached
> > orphanage with explicit /machine one and many 'cpuN' children,
> > which ain't any better than device[N].
> >
> > and in future I can imagine that at least in x86 case vcpu
The GHES driver requires not only a HEST table, but also a
separate firmware file to store Error Structure records.
It can't do one without the other.
Simplify the caller logic for it to require one function.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Came
Extending to multiple sources require a BIOS pointer to the
beginning of the HEST table, which in turn requires a backward-compatible
code.
So, the current code supports only one source. Ensure that and simplify
the code.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
Review
While the spec defines a CPER size of 4KiB for each record,
currently it is set to 1KiB. Fix the documentation and add
a pointer to the macro name there, as this may help to keep
it updated.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
Reviewed-by: Igor Mammedov
---
docs/
Signed-off-by: Igor Mammedov
---
tests/qtest/bios-tables-test-allowed-diff.h | 40 +
1 file changed, 40 insertions(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..085dfa9ff4 100644
--- a/tests/qtest/
Em Wed, 15 Jan 2025 06:09:12 -0500
"Michael S. Tsirkin" escreveu:
> On Sat, Dec 07, 2024 at 09:54:06AM +0100, Mauro Carvalho Chehab wrote:
> > Hi Michael,
> >
> > Please ignore the patch series I sent yesterday:
> > https://lore.kernel.org/qemu-devel/20241207093922.1efa0...@foz.lan/T/#t
> >
subj causes PCI devices that do not have acpi-index assigned,
having bogus 'PCI Label Id = 0'.
The later triggers another Windows bug that leads to guest hang
in case of localized Windows versions [1].
Workaround is for QEMU to return invalid Package on _DSM(func=7) request
if acpi-index is not c
acpi_ghes_record_errors() has an assert() at the beginning
to ensure that source_id will be lower than
ACPI_GHES_ERROR_SOURCE_COUNT. Remove a duplicated check.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Igor Mammedov
Reviewed-by: Jonathan Cameron
---
hw/acpi/ghes.c | 4 +---
1 file chan
07.01.2025 11:43, Keoseong Park wrote:
In ufs_write_attr_value(), the value parameter is handled in the CPU's
endian format but provided in big-endian format by the caller. Thus, it
is converted to the CPU's endian format. The related test code is also
fixed to reflect this change.
Fixes: 7c8533
Make error handling within ghes_record_cper_errors() consistent,
i.e. instead abort just print a error in case ghes GED is not found.
Reviewed-by: Jonathan Cameron
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Igor Mammedov
---
hw/acpi/ghes.c | 5 -
1 file changed, 4 insertions(+), 1 d
Current versions of Windows call _DSM(func=7) regardless
of whether it is supported or not. It leads to NICs having bogus
'PCI Label Id = 0', where none should be set at all.
Also presence of 'PCI Label Id' triggers another Windows bug
on localized versions that leads to hangs. The later bug is fi
GHES has two fields that are stored on HEST error source
blocks associated with notifications:
- notification type, which is a number defined at the ACPI spec
containing several arch-specific synchronous and assynchronous
types;
- source id, which is a HW/FW defined number, used to distinguish
Reduce the ident of the function and prepares it for
the next changes.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Igor Mammedov
Reviewed-by: Jonathan Cameron
---
hw/acpi/ghes.c | 56 ++
1 file changed, 29 insertions
During the development of a patch series meant to allow GHESv2 error injections,
it was requested a change on how CPER offsets are calculated, by adding a new
BIOS pointer and reworking the GHES logic. See:
https://lore.kernel.org/qemu-devel/cover.1726293808.git.mchehab+hua...@kernel.org/
Such ch
The 'physical_address' value is a faulty page. As such, 0 is
as valid as any other value.
Suggested-by: Igor Mammedov
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Igor Mammedov
Reviewed-by: Jonathan Cameron
---
hw/acpi/ghes.c | 4
1 file changed, 4 deletions(-)
diff --git a/hw/acpi
Currently, CPER address location is calculated as an offset of
the hardware_errors table. It is also badly named, as the
offset actually used is the address where the CPER data starts,
and not the beginning of the error source.
Move the logic which calculates such offset to a separate
function, in
Align the header file with the actual implementation of
this function, as the first argument is source ID and not
notification type.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Cameron
Reviewed-by: Igor Mammedov
---
Changes from v8:
- Non-rename/cleanup changes merged altogethe
On Wed, Jan 15, 2025 at 02:39:55PM +1100, Alexey Kardashevskiy wrote:
> > The thread was talking about the built-in support in iommufd to split
> > mappings.
>
> Just to clarify - I am talking about splitting only "iommufd areas", not
> large pages.
In generality it is the same thing as you canno
On 1/8/25 07:45, Zhao Liu wrote:
#[macro_export]
macro_rules! vmstate_of {
-($struct_name:ty, $field_name:ident $([0 .. $num:ident $(* $factor:expr)?])?
$(,)?) => {
+($struct_name:ty, $field_name:ident $([0 .. $num:tt $(* $factor:expr)?])?
$(,)?) => {
Why change ident to tt?
Reb
_DSM function 7 AML should have followig change:
If ((Arg2 == 0x07))
{
-Local0 = Package (0x02)
-{
-Zero,
-""
-}
Local2 = AIDX (DerefOf
ping
On Mon, Jan 6, 2025 at 11:37 AM Konstantin Kostiuk
wrote:
> ping
>
> On Mon, Dec 16, 2024 at 5:47 PM Konstantin Kostiuk
> wrote:
>
>> Signed-off-by: Konstantin Kostiuk
>> ---
>> qga/commands-posix.c | 2 ++
>> qga/commands-win32.c | 3 +++
>> 2 files changed, 5 insertions(+)
>>
>> diff -
On Wed, Jan 15, 2025 at 11:33:10AM +0530, Ani Sinha wrote:
> On Thu, Dec 12, 2024 at 8:19 PM Ani Sinha wrote:
> >
> > commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
> > introduced 'default_cpu_version' for PCMachineClass. This created three
> > categories of CPU models:
> >
On Mon, Dec 16, 2024 at 05:45:52PM +0200, Konstantin Kostiuk wrote:
> Signed-off-by: Konstantin Kostiuk
> ---
> qga/commands-posix.c | 2 ++
> qga/commands-win32.c | 3 +++
> 2 files changed, 5 insertions(+)
Reviewed-by: Daniel P. Berrangé
With regards,
Daniel
--
|: https://berrange.com
On Tue, Jan 14, 2025 at 04:00:01PM -0300, Daniel Henrique Barboza wrote:
> Add RVA23S64 as described in [1]. This profile inherits all mandatory
> extensions of RVA23U64, making it a child of the U64 profile.
>
> A new "rva23s64" profile CPU is also added. This is the generated
> riscv,isa for it
On Tue, Jan 14, 2025 at 04:00:00PM -0300, Daniel Henrique Barboza wrote:
> Add RVA23U64 as described in [1]. Add it as a child of RVA22U64 since
> all RVA22U64 mandatory extensions are also present in RVA23U64. What's
> left then is to list the mandatory extensions that are RVA23 only.
>
> A new "
On Tue, Jan 14, 2025 at 03:59:59PM -0300, Daniel Henrique Barboza wrote:
> From the time we added RVA22U64 until now the spec didn't declare 'RVB'
> as a dependency, using zba/zbb/zbs instead. Since then the RVA22 spec
> [1] added the following in the 'RVA22U64 Mandatory Extensions' section:
>
> "
On Tue, Jan 14, 2025 at 03:59:58PM -0300, Daniel Henrique Barboza wrote:
> ssu64xl is defined in RVA22 as:
>
> "sstatus.UXL must be capable of holding the value 2 (i.e., UXLEN=64 must
> be supported)."
>
> This is always true in TCG and it's mandatory for RVA23, so claim
> support for it.
>
> Si
On Tue, Jan 14, 2025 at 18:07:30 -0500, Peter Xu wrote:
> CI: https://gitlab.com/peterx/qemu/-/pipelines/1625266692
> (note: warning is present on rust stuff, but shouldn't be relevant)
>
> This series refactors the migration switchover path quite a bit. I started
> this work initially to mea
Hi Reza,
On 16/12/24 17:31, Reza Arbab wrote:
Most virtio-pci devices allow MSI-X. Add it to virtio-balloon-pci, but
only enable it in new machine types, so we don't break migration of
existing machine types between different qemu versions.
This copies what was done for virtio-rng-pci in:
9ea02
Ilya Leoshkevich writes:
> On Tue, 2025-01-14 at 11:37 +, Alex Bennée wrote:
>> This started as a clean-up to properly pass a Error handler to the
>> gdbserver_start so we could do the right thing for command line and
>> HMP invocations.
>>
>> Now that we have cleaned up foreach_device_confi
On 15/01/2025 11:10, Michael S. Tsirkin wrote:
On Wed, Dec 18, 2024 at 03:34:53PM +0100, Laurent Vivier wrote:
Add support of VHOST_USER_PROTOCOL_F_DEVICE_STATE in virtio-net
with vhost-user backend.
Cc: Hanna Czenczek
Signed-off-by: Laurent Vivier
Breaks windows builds:
https://gitlab.co
On Sat, Dec 07, 2024 at 09:54:15AM +0100, Mauro Carvalho Chehab wrote:
> Split the code into separate functions to allow using the
> common CPER filling code by different error sources.
>
> The generic code was moved to ghes_record_cper_errors(),
> and ghes_gen_err_data_uncorrectable_recoverable()
On Sat, Dec 07, 2024 at 09:54:06AM +0100, Mauro Carvalho Chehab wrote:
> Hi Michael,
>
> Please ignore the patch series I sent yesterday:
> https://lore.kernel.org/qemu-devel/20241207093922.1efa0...@foz.lan/T/#t
>
> The git range was wrong, and it was supposed to be v6. This is the right on
On 15/1/25 08:38, Thomas Huth wrote:
Now that the machine types that set the migration_enabled flag to
false are gone, we can remove it and the related code.
Signed-off-by: Thomas Huth
---
include/hw/s390x/storage-attributes.h | 1 -
hw/s390x/s390-stattrib-kvm.c | 2 +-
hw/s390x/s3
On Wed, 15 Jan 2025 07:48:59 +
"Zhijian Li (Fujitsu)" wrote:
> On 10/01/2025 23:44, Jonathan Cameron wrote:
> > On Fri, 13 Dec 2024 17:36:02 +0800
> > Li Zhijian wrote:
> >
> >> This assertion always happens when we sanitize the CXL memory device.
> >> $ echo 1 > /sys/bus/cxl/devices/mem0
On 1/14/2025 4:37 PM, Steven Sistare wrote:
On 1/14/2025 4:14 PM, Steven Sistare wrote:
On 1/14/2025 3:29 PM, Fabiano Rosas wrote:
Hi Steve,
The CI shows some issues, please take a look:
https://gitlab.com/farosas/qemu/-/pipelines/1624984802
--
I will fix this bug in V7 tomo
On Fri, Jan 10, 2025 at 10:35:30AM +0100, Roger Pau Monne wrote:
> diff --git a/include/hw/xen/xen-bus-helper.h b/include/hw/xen/xen-bus-helper.h
> index d8dcc2f0107d..6478d25be5e6 100644
> --- a/include/hw/xen/xen-bus-helper.h
> +++ b/include/hw/xen/xen-bus-helper.h
> @@ -37,6 +37,10 @@ int xs_nod
On Wed, Jan 15, 2025 at 6:23 PM Igor Mammedov wrote:
>
> Signed-off-by: Igor Mammedov
Acked-by: Ani Sinha
> ---
> tests/qtest/bios-tables-test-allowed-diff.h | 40 +
> 1 file changed, 40 insertions(+)
>
> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
> b/tests/
This commit implements the SCLP event type Control-Program
Identification in QEMU. Control-program is an IBM term for
operating system. This event is used to send firmware
program identifiers from KVM guest to SCLP. The program
identifiers provide data about the guest OS. The program
identifiers ar
This commit adds the firmware control-program
identifiers received from a KVM guest via the
SCLP event type Control-Program Identification to QOM.
A timestamp in which the data is received is also
added to QOM.
Example:
virsh # qemu-monitor-command vm --pretty '{
"execute":"qom-get","arguments": {
This commit saves the state of CPI values in the guest and
transfers this state during live migration of the guest.
Signed-off-by: Shalini Chellathurai Saroja
---
hw/s390x/s390-virtio-ccw.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s39
Initially, the IOMMU would create a thread, but this thread was removed in
the merged version. The struct members for thread control should have been
removed as well, but they were not removed in commit 0c54acb8243
("hw/riscv: add RISC-V IOMMU base emulation").
Signed-off-by: Jason Chien
Reviewed
Simplify x86_cpu_realizefn() by passing an Error**
argument to x86_cpu_filter_features().
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/cpu.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 422276
These machines has been supported for a period of more than 6 years.
According to our versioned machine support policy (see commit
ce80c4fa6ff "docs: document special exception for machine type
deprecation & removal") they can now be removed.
Signed-off-by: Philippe Mathieu-Daudé
---
docs/about/
The versioned 'pc' and 'q35' machines up to 2.12 been marked
as deprecated two releases ago, and are older than 6 years,
so according to our support policy we can remove them.
This series only includes the 2.4 and 2.5 machines removal,
as it is a big enough number of LoC removed. Rest will
follow.
The X86CPU::check_cpuid boolean was only set in the
pc_compat_2_4[] array, via the 'check=off' property.
We removed all machines using that array, lets remove
that CPU property and simplify x86_cpu_realizefn().
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/cpu.h | 1 -
target/i386/cpu.c
VIRTIO_PCI_FLAG_MIGRATE_EXTRA was only used by the
hw_compat_2_4[] array, via the 'migrate-extra=true'
property. We removed all machines using that array,
lets remove all the code around VIRTIO_PCI_FLAG_MIGRATE_EXTRA.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/virtio/virtio-pci.h | 4
VIRTIO_PCI_FLAG_DISABLE_PCIE was only used by the
hw_compat_2_4[] array, via the 'x-disable-pcie=false'
property. We removed all machines using that array,
lets remove all the code around VIRTIO_PCI_FLAG_DISABLE_PCIE.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/virtio/virtio-pci.h | 4 -
The pc_compat_2_4[] array was only used by the pc-q35-2.4
and pc-i440fx-2.4 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 3 ---
hw/i386/pc.c | 19 ---
2 files changed, 22 deletions(-)
diff --git a/include/hw/i3
The hw_compat_2_4[] array was only used by the pc-q35-2.4 and
pc-i440fx-2.4 machines, which got removed. Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/boards.h | 3 ---
hw/core/machine.c | 9 -
2 files changed, 12 deletions(-)
diff --git a/include/hw/boards.h b/inclu
E1000_FLAG_MAC was only used by the hw_compat_2_4[] array,
via the 'extra_mac_registers=off' property. We removed all
machines using that array, lets remove all the code around
E1000_FLAG_MAC.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/net/e1000.c | 63 +
Simplify merging vmxnet3_realize() within vmxnet3_instance_init(),
removing the need for device_class_set_parent_realize().
Signed-off-by: Philippe Mathieu-Daudé
---
hw/net/vmxnet3.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmx
PVSCSI_COMPAT_OLD_PCI_CONFIGURATION was only used by the
hw_compat_2_5[] array, via the 'x-old-pci-configuration=on'
property. We removed all machines using that array, lets remove
all the code around PVSCSI_COMPAT_OLD_PCI_CONFIGURATION.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/scsi/vmw_pvsc
VMXNET3_COMPAT_FLAG_DISABLE_PCIE was only used by the
hw_compat_2_5[] array, via the 'x-disable-pcie=on' property.
We removed all machines using that array, lets remove all the
code around VMXNET3_COMPAT_FLAG_DISABLE_PCIE.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/net/vmxnet3.c | 11 +
We removed the implementations in commit 46a2bd52571
("hw/i386/pc: Remove deprecated pc-i440fx-2.3 machine")
but forgot to remove the declarations. Do it now.
Fixes: 46a2bd52571 ("hw/i386/pc: Remove deprecated pc-i440fx-2.3 machine")
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h
1 - 100 of 360 matches
Mail list logo
