On 2/26/25 08:01, Thomas Huth wrote:
On 26/02/2025 07.54, Cédric Le Goater wrote:
The tests are using a now archived Fedora29 release. Switch to the
most recent Fedora41 release.
Signed-off-by: Cédric Le Goater
---
tests/functional/test_ppc64_powernv.py | 6 +++---
tests/functional/test_ppc
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
So it can be safety accessed from multiple threads.
This variable type needs to be changed to unsigned long since
32-bit host platforms lack the necessary addition atomics on 64-bit
variables.
Using 32-bit counters on 32
On 17/2/25 00:07, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
tcg/tcg.c| 4 +++
tcg/aarch64/tcg-target.c.inc | 31 +++-
tcg/arm/tcg-target.c.inc | 25 +++-
tcg/i386/tcg-target.c.inc| 27 --
Hi,
> > +# @data: variable value, encoded as hex string.
>
> I understand this is a blob. We commonly use base64 for that. Why not
> here?
It's an existing format already supported by other tools. Guess I
should add that to the preamble.
> > +# @digest: variable certificate digest. Used t
Daniel P. Berrangé writes:
> On Tue, Feb 25, 2025 at 01:31:56PM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé writes:
>>
>> > The 'qapi.backend.QAPIBackend' class defines an API contract for code
>> > generators. The current generator is put into a new class
>> > 'qapi.backend.QAPICBack
On 17/2/25 00:07, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
tcg/tcg.c| 4 +++
tcg/aarch64/tcg-target.c.inc | 31 -
tcg/arm/tcg-target.c.inc | 24
tcg/i386/tcg-target.c.inc| 25 +
John Snow writes:
> The pylint config is being left in place because the settings differ
> enough from the python/ directory settings that we need a chit-chat on
> how to merge them O:-)
>
> Everything else can go.
>
> Signed-off-by: John Snow
> ---
> scripts/qapi/.flake8| 3 ---
> scripts/
Markus Armbruster writes:
> John Snow writes:
>
>> The pylint config is being left in place because the settings differ
>> enough from the python/ directory settings that we need a chit-chat on
>> how to merge them O:-)
>>
>> Everything else can go.
>>
>> Signed-off-by: John Snow
>
> I tried to
On 7/2/25 17:20, Igor Mammedov wrote:
cpu_list_add() was doing 2 distinct things:
- assign some index to vCPU
- add unrealized (thus in inconsistent state) vCPU to &cpus_queue
Code using CPU_FOREACH() macro would iterate over possibly
unrealized vCPUs, often dealt with special casing.
Instead o
On 7/2/25 17:20, Igor Mammedov wrote:
Reseting vcpu before its thread is created, caused various issues in the past
for other targets. It doesn't cause issues for m68k at the moment but
to be consistent with the rest of targets, move reset during realize time
after qemu_init_vcpu().
That basical
On 7/2/25 17:20, Igor Mammedov wrote:
Reseting vcpu before its thread is created, caused various issues in the past
for other targets. It doesn't cause issues for loongarch at the moment but
to be consistent with the rest of targets, move reset during realize time
after qemu_init_vcpu().
That ba
On 26/02/2025 07.50, Cédric Le Goater wrote:
Replace the advent calendar test with a buildroot image built with
qemu_ppc64_e5500_defconfig.
When picking this up, I'll add a "Unlike the advent calendar image, this
newer buildroot image supports networking, too, so we can check whether it
gets
On 26/2/25 03:46, Patrick Venture wrote:
The reg isn't validated to be a possible register before
it's dereferenced for one case. The mmio space registered
for the gpio device is 4KiB but there aren't that many
registers in the struct.
Google-Bug-Id: 397469048
Change-Id: I2fb8d0d3d41422baab22e8
On 26/02/2025 07.54, Cédric Le Goater wrote:
The tests are using a now archived Fedora29 release. Switch to the
most recent Fedora41 release.
Signed-off-by: Cédric Le Goater
---
tests/functional/test_ppc64_powernv.py | 6 +++---
tests/functional/test_ppc64_pseries.py | 6 +++---
2 files cha
On 2/21/25 9:04 PM, Jonathan Cameron wrote:
On Fri, 21 Feb 2025 15:27:36 +1000
Gavin Shan wrote:
[...]
I would say #1 is the ideal model because the read_ack_register is the
bottleneck
and it should be scaled up to max_cpus. In that way, the bottleneck can be
avoided
from the bottom. An
The tests are using a now archived Fedora29 release. Switch to the
most recent Fedora41 release.
Signed-off-by: Cédric Le Goater
---
tests/functional/test_ppc64_powernv.py | 6 +++---
tests/functional/test_ppc64_pseries.py | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git
Replace the advent calendar test with a buildroot image built with
qemu_ppc64_e5500_defconfig. Boot a ppce500 machine from kernel and
disk, test network and poweroff. Add '-no-shutdown' to the command
line to avoid exiting from QEMU as it seems to bother the functional
framework.
Signed-off-by: Cé
On 25/02/2025 22.00, Thomas Huth wrote:
On 25/02/2025 21.35, Thomas Huth wrote:
On 25/02/2025 18.57, Daniel P. Berrangé wrote:
On Tue, Feb 25, 2025 at 06:52:43PM +0100, Thomas Huth wrote:
On 25/02/2025 18.44, Thomas Huth wrote:
On 25/02/2025 11.12, Kevin Wolf wrote:
Am 25.02.2025 um 08:20 ha
Hi Cedric,
>
> On 2/13/25 04:35, Jamin Lin wrote:
> > According to the design of the AST2600, it has a Silicon Revision ID
> > Register, specifically SCU004 and SCU014, to set the Revision ID for the
> AST2600.
> > For the AST2600 A3, SCU004 is set to 0x05030303 and SCU014 is set to
> 0x05030303
It's believed that RDMA + postcopy-ram has been broken for a while.
Rather than spending time re-enabling it, let's simply disable it as a
trade-off.
Reviewed-by: Peter Xu
Signed-off-by: Li Zhijian
---
V3:
- collect Reviewed tag
- reoder: 6th -> 3th
---
migration/options.c | 4
1 file
Am 25. Februar 2025 17:00:53 UTC schrieb Peter Maydell
:
>On Tue, 25 Feb 2025 at 15:42, Peter Maydell wrote:
>> The C compiler for the OpenSUSE CI job doesn't seem to like this:
>> https://gitlab.com/pm215/qemu/-/jobs/9239416833
>>
>> ../hw/arm/fsl-imx8mp.c: In function ‘fsl_imx8mp_realize’:
>
On 25/02/2025 22:48, Peter Xu wrote:
> On Tue, Feb 25, 2025 at 06:37:21AM +, Zhijian Li (Fujitsu) wrote:
>>
>>
>> On 25/02/2025 03:58, Peter Xu wrote:
>>> On Fri, Feb 21, 2025 at 02:36:09PM +0800, Li Zhijian wrote:
Similar to migration_channels_and_transport_compatible(), introduce a
>>>
Depending on the order of starting RDMA and setting capability,
the following scenarios can be categorized into the following scenarios:
Source:
S1: [set capabilities] -> [Start RDMA outgoing]
Destination:
D1: [set capabilities] -> [Start RDMA incoming]
D2: [Start RDMA incoming] -> [set capabili
- It fix the RDMA migration broken issue
- disable RDMA + postcopy
- some cleanups
- Add a qtest for RDMA at last
Changes since V3:
- check RDMA and capabilities are compatible on both sides # renamed from
previous V3's "migration: Add
migration_capabilities_and_transport_compatible()"
Changes
Since we have disabled RDMA + postcopy, it's safe to remove
the migration_in_postcopy() that follows the migrate_rdma().
Signed-off-by: Li Zhijian
---
V3:
reorder: 7th->4th
---
migration/rdma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/migration/rdma.c b/migrati
This qtest requires there is a RDMA(RoCE) link in the host.
In order to make the test work smoothly, introduce a
scripts/rdma-migration-helper.sh to
- setup a new Soft-RoCE(aka RXE) if it's root
- detect existing RoCE link
Test will be skipped if there is no available RoCE link.
# Start of rdma t
control_save_page() is for RDMA only, unfold it to make the code more
clear.
In addition:
- Similar to other branches style in ram_save_target_page(), involve RDMA
only if the condition 'migrate_rdma()' is true.
- Further simplify the code by removing the RAM_SAVE_CONTROL_NOT_SUPP.
Signed-off
Address an error in RDMA-based migration by ensuring RDMA is prioritized
when saving pages in `ram_save_target_page()`.
Previously, the RDMA protocol's page-saving step was placed after other
protocols due to a refactoring in commit bc38dc2f5f3. This led to migration
failures characterized by unkn
Gerd Hoffmann writes:
> Define qapi schema for the uefi variable store state.
>
> Use it and the generated visitor helper functions to store persistent
> (EFI_VARIABLE_NON_VOLATILE) variables in JSON format on disk.
>
> Signed-off-by: Gerd Hoffmann
[...]
> diff --git a/qapi/meson.build b/qapi/
On 2/25/25 9:19 PM, Igor Mammedov wrote:
On Fri, 21 Feb 2025 11:04:35 +
Jonathan Cameron wrote:
Ideally I'd like whatever we choose to look like what a bare metal machine
does - mostly because we are less likely to hit untested OS paths.
Ack for that but,
that would need someone from hw/
> 2025年2月25日 21:29，Marc-André Lureau 写道：
>
> Hi Haoqian
>
> On Tue, Feb 25, 2025 at 5:19 PM Haoqian He wrote:
>>
>> I use chardev to connect with a vhost-user target, the chardev backend type
>> is
>> socket, part of QEMU boot parameter:
>> -device vhost-user-blk-pci,chardev=my-vhost-blk-0
Hi Cedric,
> >> and the register array as:
> >>
> >> uint32_t regs[ASPEED_INTC_NR_REGS];
> >>
> >> The number of regs looks pretty big for me. Are the registers
> >> covering the whole MMIO aperture ?
> >>
> > According to the datasheet, the entire register address space size of
> > INTC (CPU
On Tue, Feb 25, 2025 at 7:28 AM Conor Dooley wrote:
>
> On Mon, Feb 24, 2025 at 03:14:00PM +1000, Alistair Francis wrote:
> > On Fri, Feb 21, 2025 at 4:31 AM Conor Dooley wrote:
> > >
> > > +cc qemu-riscv, Alistar.
> > >
> > > On Fri, Feb 14, 2025 at 07:24:37AM +0100, Sebastian Huber wrote:
> > >
The reg isn't validated to be a possible register before
it's dereferenced for one case. The mmio space registered
for the gpio device is 4KiB but there aren't that many
registers in the struct.
Google-Bug-Id: 397469048
Change-Id: I2fb8d0d3d41422baab22e8fc7e9fadd0f2ee7068
Signed-off-by: Patrick V
On Tue, Feb 25, 2025 at 5:13 AM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> In this version no major changes were made. Just a rebase with
> alistair/riscv-to-apply.next and acks from Alistair.
>
> All patches acked.
>
> v1 link:
> https://lore.kernel.org/qemu-riscv/20241205133003.184581-1-dbarb..
From: Weishi Li
Due to the fact that g->parent_obj.conf only adds
VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED setting when
VIRGL_VERSION_MAJOR >= 1, virgl_cmd_comtext_create()
will always return by error=VIRTIO_GPU_RESP_ERR_UNSPEC
when VIRGL_VERSION_MAJOR < 1, resulting in gl context
initialization fail
Since we have disabled RDMA + postcopy, it's safe to remove
the migration_in_postcopy() that follows the migrate_rdma().
Signed-off-by: Li Zhijian
---
V3:
reorder: 7th->4th
---
migration/rdma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/migration/rdma.c b/migrati
Address an error in RDMA-based migration by ensuring RDMA is prioritized
when saving pages in `ram_save_target_page()`.
Previously, the RDMA protocol's page-saving step was placed after other
protocols due to a refactoring in commit bc38dc2f5f3. This led to migration
failures characterized by unkn
Similar to migration_channels_and_transport_compatible(), introduce a
new helper migration_capabilities_and_transport_compatible() to check if
the capabilites is compatible with the transport.
Currently, only move the capabilities vs RDMA transport to this
function.
Reviewed-by: Peter Xu
Signed-
This qtest requires there is a RDMA(RoCE) link in the host.
In order to make the test work smoothly, introduce a
scripts/rdma-migration-helper.sh to
- setup a new Soft-RoCE(aka RXE) if it's root
- detect existing RoCE link
Test will be skipped if there is no available RoCE link.
# Start of rdma t
control_save_page() is for RDMA only, unfold it to make the code more
clear.
In addition:
- Similar to other branches style in ram_save_target_page(), involve RDMA
only if the condition 'migrate_rdma()' is true.
- Further simplify the code by removing the RAM_SAVE_CONTROL_NOT_SUPP.
Signed-off
- It fix the RDMA migration broken issue
- disable RDMA + postcopy
- some cleanups
- Add a qtest for RDMA at last
Chnages since V2:
- squash previous 2/3/4 to '[PATCH v3 5/6] migration: Unfold
control_save_page()'
- reorder the patch layout to prevent recently added code from being deleted
agai
It's believed that RDMA + postcopy-ram has been broken for a while.
Rather than spending time re-enabling it, let's simply disable it as a
trade-off.
Reviewed-by: Peter Xu
Signed-off-by: Li Zhijian
---
V3:
- collect Reviewed tag
- reoder: 6th -> 3th
---
migration/migration.c | 4
1 fil
Unlike cpr-reboot mode, cpr-transfer mode cannot save volatile ram blocks
in the migration stream file and recreate them later, because the physical
memory for the blocks is pinned and registered for vfio. Add a blocker
for volatile ram blocks.
Also add a blocker for RAM_GUEST_MEMFD. Preserving
On 22/02/2025 12:28, BALATON Zoltan wrote:
Add macio_gpio_read trace event and use that in macio_gpio_read()
instead of macio_gpio_write. Also change log message to match
macio_timer_{read,write}.
Signed-off-by: BALATON Zoltan
---
hw/misc/macio/gpio.c | 2 +-
hw/misc/macio/trace-event
On 24/02/2025 14:10, BALATON Zoltan wrote:
Add named constants for register bit values that should make it easier
to understand what these mean.
Signed-off-by: BALATON Zoltan
Reviewed-by: Philippe Mathieu-Daudé
---
hw/misc/macio/gpio.c | 19 ---
1 file changed, 12 insertion
The pm_cap on the PCIExpressDevice object can be distilled down
to the new instance on the PCIDevice object.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Reviewed-by: Michael S. Tsirkin
Reviewed-by: Zhenzhong Duan
Reviewed-by: Eric Auger
Signed-off-by: Alex Williamson
---
hw/pci-bridge/pcie_
This is now redundant to PCIDevice.pm_cap.
Cc: Cédric Le Goater
Reviewed-by: Zhenzhong Duan
Reviewed-by: Eric Auger
Signed-off-by: Alex Williamson
---
hw/vfio/pci.c | 9 -
hw/vfio/pci.h | 1 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
Switch callers directly initializing the PCI PM capability with
pci_add_capability() to use pci_pm_init().
Cc: Dmitry Fleytman
Cc: Akihiko Odaki
Cc: Jason Wang
Cc: Stefan Weil
Cc: Sriram Yagnaraman
Cc: Keith Busch
Cc: Klaus Jensen
Cc: Jesper Devantier
Cc: Michael S. Tsirkin
Cc: Marcel Apf
v2:
Eric noted in v1 that one of the drivers had a redundant wmask setting
since pci_pm_init() enabled writes to the power state field. This was
added because vfio-pci was not setting wmask for this capability but
is allowing writes to the PM state field through to the device. For
vfio-pci, QEMU
The memory and IO BARs for devices are only accessible in the D0 power
state. In other power states the PCI spec defines that the device
responds to TLPs and messages with an Unsupported Request response.
To approximate this behavior, consider the BARs as unmapped when the
device is not in the D0
We want the device in the D0 power state going into reset, but the
config write can enable the BARs in the address space, which are
then removed from the address space once we clear the memory enable
bit in the command register. Re-order to clear the command bit
first, so the power state change do
+/* Ram device is remapped in new QEMU */
+if (memory_region_is_ram_device(mr)) {
+return true;
+}
+
+/* Named files are remapped in new QEMU, same contents if shared (no COW)
*/
+if (qemu_ram_is_shared(rb) && qemu_ram_is_named_file(rb)) {
+return true;
+}
On 25.02.2025 18:16, Peter Xu wrote:
On Wed, Feb 19, 2025 at 09:33:49PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
All callers to migration_incoming_state_destroy() other than
postcopy_ram_listen_thread() do this call with BQL held.
Since migration_incoming_state_destroy()
On 25/02/2025 21.35, Thomas Huth wrote:
On 25/02/2025 18.57, Daniel P. Berrangé wrote:
On Tue, Feb 25, 2025 at 06:52:43PM +0100, Thomas Huth wrote:
On 25/02/2025 18.44, Thomas Huth wrote:
On 25/02/2025 11.12, Kevin Wolf wrote:
Am 25.02.2025 um 08:20 hat Thomas Huth geschrieben:
Hi!
I'm
On 2/25/25 05:41, Peter Maydell wrote:
On Mon, 24 Feb 2025 at 20:51, Pierrick Bouvier
wrote:
Regression introduced by cf76c4
(hw/misc: Add nr_regs and cold_reset_values to NPCM CLK)
cold_reset_values has a different size, depending on device used
(NPCM7xx vs NPCM8xx). However, s->regs has a f
On 25/02/2025 18.57, Daniel P. Berrangé wrote:
On Tue, Feb 25, 2025 at 06:52:43PM +0100, Thomas Huth wrote:
On 25/02/2025 18.44, Thomas Huth wrote:
On 25/02/2025 11.12, Kevin Wolf wrote:
Am 25.02.2025 um 08:20 hat Thomas Huth geschrieben:
Hi!
I'm facing a weird hang in iotest 233 on my F
On 25/02/2025 21.04, Daniel P. Berrangé wrote:
We deprecate versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the deprecated.rst document that always
has accurate version info.
Signed-off-by: Daniel P. Berrangé
---
docs/about/deprecated.rst | 7 +
On 25/02/2025 08.06, Thomas Huth wrote:
Test 162 recently started failing for me for no obvious reasons (I
did not spot any suspicious commits in this area), but looking in
the 162.out.bad log file, there was a suspicious message at the end:
qemu-nbd: Cannot lock pid file: Resource temporarily
On 25/2/25 20:25, Richard Henderson wrote:
On 2/25/25 10:40, Philippe Mathieu-Daudé wrote:
diff --git a/tcg/i386/tcg-target.c.inc b/tcg/i386/tcg-target.c.inc
index 1115d1e38d..01010dfdc0 100644
--- a/tcg/i386/tcg-target.c.inc
+++ b/tcg/i386/tcg-target.c.inc
+static void tgen_andi(TCGContext
On 25/2/25 20:20, Richard Henderson wrote:
On 2/25/25 10:17, Philippe Mathieu-Daudé wrote:
diff --git a/tcg/loongarch64/tcg-target.c.inc b/tcg/loongarch64/tcg-
target.c.inc
index a0f050ff9c..08106b6e4c 100644
--- a/tcg/loongarch64/tcg-target.c.inc
+++ b/tcg/loongarch64/tcg-target.c.inc
+sta
On 25/02/2025 21.04, Daniel P. Berrangé wrote:
If we change the deprecation logic in include/hw/boards.h, we must make
a corresponding change to docs/conf.py and docs/about/deprecated.rst.
Add comments to these files as a warning to future maintainers to keep
these files in sync.
Signed-off-by:
On 25/02/2025 21.04, Daniel P. Berrangé wrote:
We remove versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the removed-features.rst document that
always has accurate version info.
Signed-off-by: Daniel P. Berrangé
---
docs/about/removed-features.rst |
On 2/25/25 10:46, Alex Bennée wrote:
From: Igor Mammedov
that will enable assert_cpu_is_self when QEMU is configured with
--enable-debug
without need for manual patching DEBUG_TLB_GATE define.
Need to manually path DEBUG_TLB_GATE define to enable assert,
let regression caused by [1] creep
We remove versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the removed-features.rst document that
always has accurate version info.
Signed-off-by: Daniel P. Berrangé
---
docs/about/removed-features.rst | 10 ++
docs/conf.py|
We deprecate versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the deprecated.rst document that always
has accurate version info.
Signed-off-by: Daniel P. Berrangé
---
docs/about/deprecated.rst | 7 +++
docs/conf.py | 33 +++
On 2/25/25 12:02, Richard Henderson wrote:
Not checked here are any of the other reasons a flush might be ok:
(2) The system as a whole is stopped, on the way in from migration/vmload.
(3) The cpu is offline, on the way in from poweroff/reset.
(4) Running in round-robin mode, so there is *never
When VERSION is set to a development snapshot (micro >= 50), or a release
candidate (micro >= 90) we have an off-by-1 in determining deprecation
and deletion thresholds for versioned machine types. In such cases we need
to use the next major/minor version in threshold checks.
This adapts the depre
If we change the deprecation logic in include/hw/boards.h, we must make
a corresponding change to docs/conf.py and docs/about/deprecated.rst.
Add comments to these files as a warning to future maintainers to keep
these files in sync.
Signed-off-by: Daniel P. Berrangé
---
docs/conf.py| 4
Since we deprecate and remove versioned machine types on a fixed
schedule, we can automatically ensure that the docs reflect the
latest version info, rather than requiring manual updates on each
dev cycle.
The first patch in this series fixes the logic to ensure dev snapshots
and release candidate
On 2/25/25 10:46, Alex Bennée wrote:
The commit 30933c4fb4 (tcg/cputlb: remove other-cpu capability from
TLB flushing) introduced a regression that only shows up when
--enable-debug-tcg is used. The main use case of tlb_flush outside of
the current_cpu context is for handling reset and CPU creati
On 2/25/25 11:33, Richard Henderson wrote:
On 2/25/25 10:46, Alex Bennée wrote:
@@ -191,7 +199,7 @@ static void hppa_cpu_realizefn(DeviceState *dev, Error
**errp)
cpu->alarm_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
hppa_cpu_alarm_timer, cpu);
On 2/25/25 10:46, Alex Bennée wrote:
@@ -191,7 +199,7 @@ static void hppa_cpu_realizefn(DeviceState *dev, Error
**errp)
cpu->alarm_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
hppa_cpu_alarm_timer, cpu);
-hppa_ptlbe(&cpu->env);
+
Am 25. Februar 2025 14:43:32 UTC schrieb Peter Maydell
:
>On Sun, 23 Feb 2025 at 11:47, Bernhard Beschow wrote:
>>
>> This series adds a new aarch64 machine to QEMU: i.MX 8M Plus EVK [1]. It
>> allows
>> for running Linux distributions such as Buildroot
>> (freescale_imx8mpevk_defconfig) and
On 2/25/25 10:46, Alex Bennée wrote:
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 062a6e85fb..f987b75c4f 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -7242,9 +7242,6 @@ static void ppc_cpu_reset_hold(Object *obj, ResetType
type)
if (tcg_enabled()) {
Am 25. Februar 2025 14:29:15 UTC schrieb Peter Maydell
:
>On Sun, 23 Feb 2025 at 11:47, Bernhard Beschow wrote:
>>
>> On a real device, the boot ROM contains the very first instructions the CPU
>> executes. Also, U-Boot calls into the ROM to determine the boot device. While
>> we're not actual
On 2/25/25 10:40, Philippe Mathieu-Daudé wrote:
diff --git a/tcg/i386/tcg-target.c.inc b/tcg/i386/tcg-target.c.inc
index 1115d1e38d..01010dfdc0 100644
--- a/tcg/i386/tcg-target.c.inc
+++ b/tcg/i386/tcg-target.c.inc
+static void tgen_andi(TCGContext *s, TCGType type,
+ TCG
On 2/25/25 10:17, Philippe Mathieu-Daudé wrote:
diff --git a/tcg/loongarch64/tcg-target.c.inc b/tcg/loongarch64/tcg-target.c.inc
index a0f050ff9c..08106b6e4c 100644
--- a/tcg/loongarch64/tcg-target.c.inc
+++ b/tcg/loongarch64/tcg-target.c.inc
+static const TCGOutOpBinary outop_add = {
+ .b
Hi Alex,
On 2/25/25 03:08, Alex Bennée wrote:
As we move towards a more modular build this series converts both
loader and api to build once objects. For both objects the only real
difference is between user mode and system emulation so those bits
have been hived off into those source sets.
The
On 2/25/2025 11:36 AM, David Hildenbrand wrote:
+ * Return true if ram is compatible with CPR. Do not exclude rom,
+ * because the rom file could change in new QEMU.
+ */
+static bool ram_is_cpr_compatible(RAMBlock *rb)
+{
+ MemoryRegion *mr = rb->mr;
+
+ if (!mr || !memory_region_is_ram(m
Richard Henderson writes:
> Add infrastructure for more consolidated output of opcodes.
> The base structure allows for constraints to be either static
> or dynamic, and for the existence of those constraints to
> replace TCG_TARGET_HAS_* and the bulk of tcg_op_supported.
>
> Signed-off-by: Richa
The vCPU parent already triggers a tb_flush so this is un-needed:
#0 tlb_flush_other_cpu (cpu=0x56df8630) at ../../accel/tcg/cputlb.c:419
#1 0x55ee38c9 in tcg_cpu_reset_hold (cpu=0x56df8630) at
../../accel/tcg/tcg-accel-ops.c:88
#2 0x55bc29e5 in cpu_exec_reset_hol
Richard Henderson writes:
> On 2/25/25 03:08, Alex Bennée wrote:
>> To move the main api.c to a single build compilation object we need to
>> start splitting out user and system specific code. As we need to grob
>> around host headers we move these particular helpers into the *-user
>> mode direc
Since 30933c4fb4 (tcg/cputlb: remove other-cpu capability from TLB flushing)
we don't expect non-CPU callers to the tlb_flush() code. Normally I
would drop the call anyway as the common cpu_reset() code will call
tlb_flush anyway. However as the flush function does more than that,
and is called fro
From: Igor Mammedov
that will enable assert_cpu_is_self when QEMU is configured with
--enable-debug
without need for manual patching DEBUG_TLB_GATE define.
Need to manually path DEBUG_TLB_GATE define to enable assert,
let regression caused by [1] creep in unnoticed.
1) 30933c4fb4f3d ("tcg/cp
This is based on one of the fixes from Igor's series:
20250207162048.1890669-1-imamm...@redhat.com
Rather than reverting the patch I cleaned up a couple of cases where
we either didn't need to do a flush or we could trivially defer to
when the CPU started running. For the other cases I introduc
On 2/25/25 03:08, Alex Bennée wrote:
Now all the softmmu/user-mode stuff has been split out we can build
this compilation unit only once.
Signed-off-by: Alex Bennée
---
plugins/api.c | 11 ---
plugins/meson.build | 3 +--
2 files changed, 1 insertion(+), 13 deletions(-)
Revi
The commit 30933c4fb4 (tcg/cputlb: remove other-cpu capability from
TLB flushing) introduced a regression that only shows up when
--enable-debug-tcg is used. The main use case of tlb_flush outside of
the current_cpu context is for handling reset and CPU creation. Rather
than revert the commit intro
On 2/25/25 03:08, Alex Bennée wrote:
These are only usable in system mode where we control the timer. For
user-mode make them NOPs.
Signed-off-by: Alex Bennée
---
plugins/api-system.c | 34 ++
plugins/api-user.c | 17 +
plugins/api.c
On 2/25/25 03:08, Alex Bennée wrote:
These only work for system-mode and are NOPs for user-mode.
Signed-off-by: Alex Bennée
---
plugins/api-system.c | 58
plugins/api-user.c | 40 +
plugins/api.c| 70 -
On 17/2/25 00:07, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
tcg/tcg.c| 4 +++
tcg/aarch64/tcg-target.c.inc | 31 ++
tcg/arm/tcg-target.c.inc | 41 +---
tcg/i386/tcg-target.c.inc| 27
From: Bernhard Beschow
The i.MX 8M Plus SoC actually has two ethernet controllers, the usual ENET one
and a Designware one. There is no device model for the latter, so only add the
ENET one.
Reviewed-by: Peter Maydell
Signed-off-by: Bernhard Beschow
Message-id: 20250223114708.1780-15-shen...@g
On 2/25/25 03:08, Alex Bennée wrote:
To move the main api.c to a single build compilation object we need to
start splitting out user and system specific code. As we need to grob
around host headers we move these particular helpers into the *-user
mode directories.
The binary/start/end/entry help
On 2/25/25 03:08, Alex Bennée wrote:
There is very little in loader that is different between builds save
for a tiny user/system mode difference in the plugin_info structure.
Create two new files, user and system to hold mode specific helpers
and move loader into common_ss.
Signed-off-by: Alex B
On 17/2/25 00:07, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
tcg/sparc64/tcg-target-con-set.h | 1 +
tcg/tcg.c| 40 ++-
tcg/aarch64/tcg-target.c.inc | 51 +++---
tcg/arm/tcg-target.c.inc | 43
tcg/i386
Currently we have a compile-time shortcut where we return a hardcode
value from snan_bit_is_one() on everything except MIPS, because we
know that's the only target that needs to change
status->no_signaling_nans at runtime.
Remove the ifdef, so we always look at the status flag. This means
we must
Currently if the user requests via -machine dumpdtb=file.dtb that we
dump the DTB, but the machine doesn't have a DTB, we silently ignore
the option. This is confusing to users, and is a legacy of the old
board-specific implementation of the option, where if the execution
codepath didn't go via a
On 2/25/25 03:08, Alex Bennée wrote:
Headers should bring in what they need so don't rely on getting
queue.h by side effects. This will help with clean-ups in the
following patches.
Signed-off-by: Alex Bennée
---
plugins/plugin.h | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Richard He
On 2/25/25 03:08, Alex Bennée wrote:
Thanks to re-factoring and clean-up work (especially to exec-all) we
no longer need such broad headers for the api.
Signed-off-by: Alex Bennée
---
plugins/api.c | 3 ---
1 file changed, 3 deletions(-)
Reviewed-by: Richard Henderson
r~
The softfloat (i.e. TCG) specific handling for the FPCR
and FPSR is abstracted behind five functions:
arm_set_default_fp_behaviours
arm_set_ah_fp_behaviours
vfp_get_fpsr_from_host
vfp_clear_float_status_exc_flags
vfp_set_fpsr_to_host
Currently we rely on the first two calling softfloat functi
1 - 100 of 309 matches
Mail list logo
