On Fri, Jun 21, 2024 at 12:15 PM Alistair Francis
wrote:
> On Sun, Jun 16, 2024 at 12:48 PM wrote:
> >
> > From: Frank Chang
> >
> > Introduce helpers to enable the extensions based on the implied rules.
> > The implied extensions are enabled recursively, so we don't have to
> > expand all of t
Hi Roman,
On 20/6/24 22:16, Roman Kiryanov wrote:
void* pointer arithmetic is a GCC extentension
which could not be available in other build
tools (e.g. C++). This changes removes this
assumption.
Google-Bug-Id: 331190993
Again [*] I'm trying to figure what this tag is, no hit on
https://issu
John Snow writes:
> Apologies, I meant to do this but forgot there were two cases and only
> nabbed one.
>
> Fixing.
No problem at all!
John Snow writes:
> On Thu, Jun 20, 2024, 11:07 AM Markus Armbruster wrote:
>
>> John Snow writes:
>>
>> > On Wed, Jun 19, 2024, 8:03 AM Markus Armbruster wrote:
>> >
>> >> John Snow writes:
>> >>
>> >> > Change get_doc_indented() to preserve indentation on all subsequent text
>> >> > lines,
On 19/6/24 02:04, Roman Kiryanov wrote:
void* pointer arithmetic is not in the
C standard. This change allows using
the QEMU headers with a C++ compiler.
Google-Bug-Id: 331190993
Change-Id: I5a064853429f627c17a9213910811dea4ced6174
Signed-off-by: Roman Kiryanov
---
v2: change `char*` into `char
Hi Patrick,
On 21/6/24 00:03, Patrick Leis wrote:
Corey and Peter,
My team builds lots of configurations for Qemu boards, and one pain
point has been that the qom path for a device depends on the device
insertion order, child[0], child[1] and the like. I noticed that the
qdev paths for devi
On Wed, Jun 12, 2024 at 1:25 PM Ethan Chen via wrote:
>
> If a requestor device is connected to the IOPMP device, its memory access will
> be checked by the IOPMP rule.
>
> - Add 'iopmp=on' option to add an iopmp device and make the Generic PCI
> Express
> Bridge connect to IOPMP.
I have only
On 6/20/24 4:02 PM, Zheyu Ma wrote:
ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
function. This issue occurred when reading beyond the bounds of the
reg_table.
To enhance the safety and maintainability of the Aspeed GPIO code, this commit
introduces a reg_table_count me
If we simply move the set_node_memory_tier() from memory_tier_init() to
late_initcall(), it will result in HMAT not registering the
mt_adistance_algorithm callback function, because set_node_memory_tier()
is not performed during the memory tiering initialization phase,
leading to a lack of correct
On Sun, Jun 9, 2024 at 3:32 PM Branislav Brzak wrote:
>
> helper_froundnx_h function mistakenly uses single percision nanbox
> check instead of the half percision one. This patch fixes the issue.
>
> Signed-off-by: Branislav Brzak
Thanks!
Applied to riscv-to-apply.next
Alistair
> ---
> targe
On 6/16/24 23:28, Gustavo Romero wrote:
Make the gdb_first_attached_cpu and gdb_hextomem non-internal so they
are not confined to use only in gdbstub.c.
Signed-off-by: Gustavo Romero
---
gdbstub/internals.h| 2 --
include/exec/gdbstub.h | 5 +
include/gdbstub/commands.h | 6 +
Richard Henderson 于2024年6月21日周五 12:21写道：
>
> On 6/20/24 16:46, YunQiang Su wrote:
> > @@ -4553,7 +4559,7 @@ static void gen_trap(DisasContext *ctx, uint32_t opc,
> > if (ctx->hflags != ctx->saved_hflags) {
> > tcg_gen_movi_i32(hflags, ctx->hflags);
> > }
> > -
On 6/16/24 23:28, Gustavo Romero wrote:
Factor out the code used for setting the MTE TCF0 field from the prctl
code into a convenient function. Other subsystems, like gdbstub, need to
set this field as well, so keep it as a separate function to avoid
duplication and ensure consistency in how this
On 6/16/24 23:28, Gustavo Romero wrote:
@@ -287,7 +256,7 @@ uint64_t HELPER(addsubg)(CPUARMState *env, uint64_t ptr,
return address_with_allocation_tag(ptr + offset, rtag);
}
-static int load_tag1(uint64_t ptr, uint8_t *mem)
+inline int load_tag1(uint64_t ptr, uint8_t *mem)
{
On 6/16/24 23:28, Gustavo Romero wrote:
If page in 'ptr_access' is inaccessible and probe is 'true'
allocation_tag_mem_probe should not throw an exception, but currently it
does, so fix it.
Signed-off-by: Gustavo Romero
Reviewed-by: Alex Bennée
---
target/arm/tcg/mte_helper.c | 3 +++
1 file
On 6/16/24 23:28, Gustavo Romero wrote:
+static char *extended_qsupported_features;
+void gdb_extend_qsupported_features(char *qsupported_features)
+{
+extended_qsupported_features = qsupported_features;
+}
Assert these functions aren't called twice.
That should be good enough until we need
On 6/8/24 14:45, Branislav Brzak wrote:
t/riscv/fpu_helper.c b/target/riscv/fpu_helper.c
index 871a70a316..91b1a56d10 100644
--- a/target/riscv/fpu_helper.c
+++ b/target/riscv/fpu_helper.c
@@ -676,7 +676,7 @@ uint64_t helper_fround_h(CPURISCVState *env, uint64_t rs1)
uint64_t helper_froundnx
On 6/20/24 16:46, YunQiang Su wrote:
@@ -4553,7 +4559,7 @@ static void gen_trap(DisasContext *ctx, uint32_t opc,
if (ctx->hflags != ctx->saved_hflags) {
tcg_gen_movi_i32(hflags, ctx->hflags);
}
-generate_exception(ctx, EXCP_TRAP);
+generate_except
On Sun, Jun 9, 2024 at 3:32 PM Branislav Brzak wrote:
>
> helper_froundnx_h function mistakenly uses single percision nanbox
> check instead of the half percision one. This patch fixes the issue.
>
> Signed-off-by: Branislav Brzak
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/f
On Sun, Jun 16, 2024 at 12:48 PM wrote:
>
> From: Frank Chang
>
> Introduce helpers to enable the extensions based on the implied rules.
> The implied extensions are enabled recursively, so we don't have to
> expand all of them manually. This also eliminates the old-fashioned
> ordering requireme
Hi, Jonathan,
Jonathan Cameron writes:
> v3: Thanks to Richard for help debugging BE issue and to Igor for
> finding a bunch of other thing to improve via the context in
> the fix patch.
>
> - Fix the big endian host/little endian guest issue in the HID being
> written to the Gene
Sorry for not replying earlier, I have been busy with other things.
> > Hi Igor, Daniel and all:
> >
> >
> > https://lore.kernel.org/all/20220422135101.65796...@redhat.com/t/#r831d589f243c24334a09995620b74408847a87a0
> >
> > This message discuss hotplug device to pxb bridge. At the end, Igor
>
On Thu, Jun 20, 2024 at 4:48 PM Sunil V L wrote:
>
> RISC-V virt is currently missing default type for block devices. Without
> this being set, proper backend is not created when option like -cdrom
> is used. So, make the virt board's default block device type be
> IF_VIRTIO similar to other archi
On Thu, Jun 20, 2024 at 4:48 PM Sunil V L wrote:
>
> RISC-V virt is currently missing default type for block devices. Without
> this being set, proper backend is not created when option like -cdrom
> is used. So, make the virt board's default block device type be
> IF_VIRTIO similar to other archi
Maciej W. Rozycki 于2024年6月21日周五 08:41写道：
>
> On Fri, 21 Jun 2024, YunQiang Su wrote:
>
> > Linux and We use the code of conditional trap instructions to emit
> > signals other than simple SIGTRAP. Currently, code 6 (overflow),
> > 7 (div by zero) are supported. It means that if code 7 is used wit
On 6/16/24 23:28, Gustavo Romero wrote:
Change 'process_string_cmd' to return true on success and false on
failure, instead of 0 and -1.
Signed-off-by: Gustavo Romero
Reviewed-by: Alex Bennée
---
gdbstub/gdbstub.c | 40
1 file changed, 20 insertions(+)
On Fri, 21 Jun 2024, YunQiang Su wrote:
> Linux and We use the code of conditional trap instructions to emit
> signals other than simple SIGTRAP. Currently, code 6 (overflow),
> 7 (div by zero) are supported. It means that if code 7 is used with
> a conditional trap instruction, a SIGFPE instead
On Thu, 2024-06-20 at 16:02 +0200, Zheyu Ma wrote:
> ASan detected a global-buffer-overflow error in the aspeed_gpio_read()
> function. This issue occurred when reading beyond the bounds of the
> reg_table.
>
> To enhance the safety and maintainability of the Aspeed GPIO code, this commit
> introd
Linux and We use the code of conditional trap instructions to emit
signals other than simple SIGTRAP. Currently, code 6 (overflow),
7 (div by zero) are supported. It means that if code 7 is used with
a conditional trap instruction, a SIGFPE instead of SIGTRAP will emit.
But when `gen_trap` we did
From: Dongwon Kim
Introducing new virtio-gpu param, 'render_sync' when guest scanout blob
is used (blob=true). The new param is used to specify when to start
rendering a guest scanout frame.
By default (and so far) rendering of the guest frame is started in
the draw event to make sure guest disp
From: Dongwon Kim
Draw (executing glBlitFramebuffer) immediately as soon as the frame
is flushed instead of getting it done in the next draw event if render_sync
flag is reset. With this, the fence will be signaled way ealier so the guest
can be working on the next frame right away.
Cc: Gerd Hof
From: Dongwon Kim
Introducing new virtio-gpu param, 'render_sync' when guest scanout blob
is used (blob=true). The new param is used to specify when to start
rendering a guest scanout frame.
By default (and so far) rendering of the guest frame is started in
the draw event to make sure guest disp
From: Dongwon Kim
Draw (executing glBlitFramebuffer) immediately as soon as the frame
is flushed instead of getting it done in the next draw event if render_sync
flag is reset. With this, the fence will be signaled way ealier so the guest
can be working on the next frame right away.
Cc: Marc-And
From: Dongwon Kim
There is no reason to split those two operations so combining
two functions - egl_dmabuf_create_sync and egl_dmabuf_create_fence.
Cc: Gerd Hoffmann
Cc: Marc-André Lureau
Cc: Vivek Kasireddy
Signed-off-by: Dongwon Kim
---
include/ui/egl-helpers.h | 3 +--
ui/egl-helpers.c
Corey and Peter,
My team builds lots of configurations for Qemu boards, and one pain point
has been that the qom path for a device depends on the device insertion
order, child[0], child[1] and the like. I noticed that the qdev paths for
devices also exist by their device id property. By default,
Hi folks,
First of all, apologies for the roughness of the series. I'm off for
the next couple of weeks and wanted to put something together early
for your consideration.
This series is a refactoring (based on an earlier, off-list
attempt[0]), aimed to remove the usage of the MultiFDPages_t type
We want to stop dereferencing 'pages' so it can be replaced by an
opaque pointer in the next patches.
Signed-off-by: Fabiano Rosas
---
migration/file.c| 3 ++-
migration/file.h| 2 +-
migration/multifd.c | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/migration/fil
The only two things the multifd client needs to access are the active
slot and the active slot size:
The active slot itself is obviously needed because it's where the data
is put.
The slot size is needed only by the ram pages code, because it does
not fill the data slot and sends it in one go, it
While we cannot yet disentangle the multifd packet from page data, we
can make the code a bit cleaner by setting the page-related fields in
a separate function.
Signed-off-by: Fabiano Rosas
---
migration/multifd.c | 104 +---
1 file changed, 68 insertions(
All references to pages are being removed from the multifd worker
threads in order to allow multifd to deal with different payload
types.
multifd_send_zero_page_detect() is called by all multifd migration
paths that deal with pages and is the last spot where zero pages and
normal page amounts are
We want multifd to be able to handle more types of data than just ram
pages. To start decoupling multifd from pages, replace p->pages
(MultiFDPages_t) with a new type MultiFDSendData that hides an opaque
pointer.
The general idea here is to isolate functions that *need* to handle
MultiFDPages_t an
I'm about to replace the p->pages pointer with an opaque pointer, so
do a cleanup now to reduce direct accesses to p->page, which makes the
next diffs cleaner.
Signed-off-by: Fabiano Rosas
---
migration/multifd-qpl.c | 8 +---
migration/multifd-uadk.c | 9 +
migration/multifd-zlib
Multifd currently has a simple scheduling mechanism that distributes
work to the various channels by providing the client (producer) with a
memory slot and swapping that slot with free slot from the next idle
channel (consumer). Or graphically:
[] <-- multifd_send_state->pages
[][][][] <-- c
在2024年6月20日六月 下午8:50，Philippe Mathieu-Daudé写道：
[...]
> Do you mind posting a patch fixing it?
I'll prepare a series tomorrow with your comments on this patch before.
Thanks
- Jiaxun
>
>> +hwaddr base = ((hwaddr)node << 44) + virt_memmap[VIRT_IPI].base;
>> +base += core
Hi Peter, thank you for looking.
On Thu, Jun 20, 2024 at 12:09 PM Peter Maydell wrote:
> I think this is the point where I would say "you're making the
> code worse for upstream and the only benefit is to your out-of-tree
> downstream code". If you want to build QEMU, use one of the compilers
> t
void* pointer arithmetic is a GCC extentension
which could not be available in other build
tools (e.g. C++). This changes removes this
assumption.
Google-Bug-Id: 331190993
Change-Id: I5a064853429f627c17a9213910811dea4ced6174
Signed-off-by: Roman Kiryanov
---
v2: renamed from "use char* for pointe
On 6/15/24 11:46 PM, frank.ch...@sifive.com wrote:
From: Frank Chang
Remove the old-fashioned extension auto-update check statements as
they are replaced by the extension implied rules.
Signed-off-by: Frank Chang
Reviewed-by: Jerry Zhang Jian
Tested-by: Max Chou
---
Reviewed-by: Danie
On 6/15/24 11:46 PM, frank.ch...@sifive.com wrote:
From: Frank Chang
Zc extension has special implied rules that need to be handled separately.
Signed-off-by: Frank Chang
Reviewed-by: Jerry Zhang Jian
Tested-by: Max Chou
---
Reviewed-by: Daniel Henrique Barboza
target/riscv/tcg/tc
On 6/15/24 11:46 PM, frank.ch...@sifive.com wrote:
From: Frank Chang
Add standard extension implied rules to enable the implied extensions of
the standard extension recursively.
Signed-off-by: Frank Chang
Reviewed-by: Jerry Zhang Jian
Tested-by: Max Chou
Acked-by: Alistair Francis
---
On 6/15/24 11:46 PM, frank.ch...@sifive.com wrote:
From: Frank Chang
Add MISA extension implied rules to enable the implied extensions
of MISA recursively.
Signed-off-by: Frank Chang
Reviewed-by: Jerry Zhang Jian
Tested-by: Max Chou
Reviewed-by: Alistair Francis
---
Reviewed-by: Danie
On 6/15/24 11:46 PM, frank.ch...@sifive.com wrote:
From: Frank Chang
Introduce helpers to enable the extensions based on the implied rules.
The implied extensions are enabled recursively, so we don't have to
expand all of them manually. This also eliminates the old-fashioned
ordering require
On 6/15/24 11:46 PM, frank.ch...@sifive.com wrote:
From: Frank Chang
RISCVCPUImpliedExtsRule is created to store the implied rules.
'is_misa' flag is used to distinguish whether the rule is derived
from the MISA or other extensions.
'ext' stores the MISA bit if 'is_misa' is true. Otherwise,
Hi Jiaxun,
On 18/6/24 18:00, Philippe Mathieu-Daudé wrote:
From: Jiaxun Yang
Wire up loongson_ipi device for loongson3_virt machine, so we
can have SMP support for TCG backend as well.
Signed-off-by: Jiaxun Yang
Acked-by: Song Gao
Reviewed-by: Philippe Mathieu-Daudé
Message-ID: <20240605-l
Il gio 20 giu 2024, 20:13 Manos Pitsidianakis <
manos.pitsidiana...@linaro.org> ha scritto:
> On Thu, 20 Jun 2024 16:21, Paolo Bonzini wrote:
> >On 6/19/24 22:13, Manos Pitsidianakis wrote:
> >> Add options for Rust in meson_options.txt, meson.build, configure to
> >> prepare for adding Rust code
On 6/20/24 08:22, Alex Bennée wrote:
If the plugin in controlling time there is some state that might be
missing from the plugin tracking it. Migration is unlikely to work in
this case so lets put a migration blocker in to let the user know if
they try.
Signed-off-by: Alex Bennée
Suggested-by:
Thanks for the answers, I could move forward a bit more. I'm going/I need
to to create a "virt" machine with designware PCI controller for simulation
purposes. Will get back with progress in case anyone is interested in
results. Thank you again for your time and support.
Arthur
On Thu, Jun 20, 202
On 6/20/24 11:36, Manos Pitsidianakis wrote:
On Thu, 20 Jun 2024 17:01, Richard Henderson
wrote:
On 6/19/24 13:13, Manos Pitsidianakis wrote:
+# FIXME: These are the latest stable versions, refine to actual minimum ones.
+msrv = {
+ 'rustc': '1.79.0',
+ 'cargo': '1.79.0',
+ 'bindgen': '0.6
On Thu, 20 Jun 2024 at 17:24, Roman Kiryanov wrote:
>
> Hi Daniel and Alex,
>
> On Thu, Jun 20, 2024 at 8:10 AM Alex Bennée wrote:
> >
> > Daniel P. Berrangé writes:
> > > NB, QEMU is explicitly *NOT* targetting the C standard, we are
> > > targetting the C dialect supported by GCC and CLang onl
On Thu, 20 Jun 2024 at 18:34, Thomas Huth wrote:
>
> On 20/06/2024 10.28, Arthur Tumanyan wrote:
> > From the other hand the device is declared as non pluggable:
> > dc->user_creatable = false;
>
> Well, that means that you cannot use those with "-device". They can only be
> instantiated via the
On Thu, 20 Jun 2024 at 14:56, Florian Lugou wrote:
>
> On Thu, Jun 20, 2024 at 11:43:17AM +0100, Peter Maydell wrote:
> > For this timer check, we're doing I think the same thing as the
> > pseudocode AArch64.CheckTimerConditions(), which does:
> >
> > if (IsFeatureImplemented(FEAT_RME) && ss IN
On Thu, 20 Jun 2024 at 12:16, Edgar E. Iglesias wrote:
>
> On Thu, Jun 20, 2024 at 12:25:51PM +0200, Philippe Mathieu-Daudé wrote:
> > On 20/6/24 12:10, Peter Maydell wrote:
> > > On Tue, 18 Jun 2024 at 15:51, Philippe Mathieu-Daudé
> > > wrote:
> > > >
> > > > On 18/6/24 16:40, Zheyu Ma wrote:
On 18/06/24, Richard Henderson wrote:
> On 6/13/24 02:50, Anton Johansson wrote:
> > On 24/01/24, Richard Henderson wrote:
> > > On 1/20/24 00:40, Anton Johansson wrote:
> > > > Makes translate-all.c independent of softmmu target by switching
> > > >
> > > > TARGET_LONG_BITS-> target
On Thu, Jun 20, 2024 at 11:46 AM John Snow wrote:
>
>
> On Thu, Jun 20, 2024, 9:35 AM Markus Armbruster wrote:
>
>> Markus Armbruster writes:
>>
>> > John Snow writes:
>>
>> [...]
>>
>> >> diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
>> >> index b3de1fb6b3a..57598331c5c 100644
>> >
On Thu, 20 Jun 2024 17:01, Richard Henderson
wrote:
On 6/19/24 13:13, Manos Pitsidianakis wrote:
+# FIXME: These are the latest stable versions, refine to actual minimum ones.
+msrv = {
+ 'rustc': '1.79.0',
+ 'cargo': '1.79.0',
+ 'bindgen': '0.69.4',
+}
A note for other rust newbies:
The
On Thu, Jun 20, 2024 at 7:56 PM Jonah Palmer wrote:
>
> The goal of these patches is to add support to a variety of virtio and
> vhost devices for the VIRTIO_F_IN_ORDER transport feature. This feature
> indicates that all buffers are used by the device in the same order in
> which they were made a
On 6/20/24 08:22, Alex Bennée wrote:
From: Max Chou
If there are not any QEMU plugin memory callback functions, checking
before calling the qemu_plugin_vcpu_mem_cb function can reduce the
function call overhead.
Signed-off-by: Max Chou
Reviewed-by: Richard Henderson
Reviewed-by: Frank Chang
On 6/20/24 01:38, Frédéric Pétrot wrote:
Register values are dumped as 'sz' chunks of two nibbles in the execlog
plugin, sz was 1 too big.
Signed-off-by: Frédéric Pétrot
---
contrib/plugins/execlog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/plugins/execlog.
On Thu, 20 Jun 2024 15:32, Alex Bennée wrote:
Manos Pitsidianakis writes:
Add mechanism to generate rust hw targets that depend on a custom
bindgen target for rust bindings to C.
This way bindings will be created before the rust crate is compiled.
The bindings will end up in BUILDDIR/{targe
On 6/20/24 06:57, Alexandre Iooss wrote:
Some people are wondering why they get an empty string as disassembly.
Most of the time, they configured QEMU without Capstone support.
Let's document this behaviour to help users.
Signed-off-by: Alexandre Iooss
---
docs/devel/tcg-plugins.rst | 4 +++-
On Thu, Jun 20, 2024 at 11:16 AM Paolo Bonzini wrote:
> > > Would it work instead to declare MemoryRegionCache's ptr field as char*?
> >
> > I prefer to use char* only where there are strings. For unstructured data
> > such as
> > MemoryRegionCache, void* is more appropriate.
>
> Or uint8_t*...
On Thu, 20 Jun 2024 15:34, Paolo Bonzini wrote:
On Thu, Jun 20, 2024 at 1:10 PM Alex Bennée wrote:
> +# FIXME: These are the latest stable versions, refine to actual minimum ones.
> +msrv = {
> + 'rustc': '1.79.0',
> + 'cargo': '1.79.0',
> + 'bindgen': '0.69.4',
> +}
So for Debian Bookworm
On 6/20/24 11:13, Gustavo Romero wrote:
@@ -1268,7 +1268,10 @@ void aarch64_max_tcg_initfn(Object *obj)
t = FIELD_DP64(t, ID_AA64SMFR0, FA64, 1); /* FEAT_SME_FA64 */
cpu->isar.id_aa64smfr0 = t;
-/* Replicate the same data to the 32-bit id registers. */
+/*
+ * Rep
On Thu, 20 Jun 2024 16:41, Alex Bennée wrote:
+summary_info += {'Rust support': with_rust}
+if with_rust and get_option('with_rust_target_triple') != ''
+ summary_info += {'Rust target': get_option('with_rust_target_triple')}
+endif
I wonder if we should display the auto-probed trip
On Thu, Jun 20, 2024 at 8:14 PM Richard Henderson
wrote:
>
> On 6/20/24 11:06, Paolo Bonzini wrote:
> > On 6/19/24 00:46, Roman Kiryanov wrote:
> >> void* pointer arithmetic is not in the
> >> C standard. This change allows using
> >> the QEMU headers with a C++ compiler.
> >>
> >> Google-Bug-Id:
Enable FEAT_Debugv8p8 on Arm 32 and 64-bit max CPUs.
Gustavo Romero (2):
target/arm: Move initialization of debug ID registers
target/arm: Enable FEAT_Debugv8p8 for -cpu max
target/arm/cpu.h | 2 ++
target/arm/tcg/cpu32.c | 34 +-
target/arm/tcg/cpu64.c
On 6/20/24 11:06, Paolo Bonzini wrote:
On 6/19/24 00:46, Roman Kiryanov wrote:
void* pointer arithmetic is not in the
C standard. This change allows using
the QEMU headers with a C++ compiler.
Google-Bug-Id: 331190993
Change-Id: I5a064853429f627c17a9213910811dea4ced6174
Signed-off-by: Roman Kir
Enable FEAT_Debugv8p8 for 32-bit and 64-bit max CPUs. This feature is
out of scope for QEMU since it concerns the external debug interface for
JTAG, but is mandatory in Armv8.8 implementations, hence it is reported
as supported in the ID registers.
Signed-off-by: Gustavo Romero
---
target/arm/tc
Move the initialization of the debug ID registers to aa32_max_features,
which is used to set the 32-bit ID registers for both 32-bit and 64-bit
max CPUs. This ensures that the debug ID registers are consistently set
for both max CPUs in a single place.
Signed-off-by: Gustavo Romero
---
target/ar
On Thu, 20 Jun 2024 16:21, Paolo Bonzini wrote:
On 6/19/24 22:13, Manos Pitsidianakis wrote:
Add options for Rust in meson_options.txt, meson.build, configure to
prepare for adding Rust code in the followup commits.
`rust` is a reserved meson name, so we have to use an alternative.
`with_rust`
On 6/19/24 00:46, Roman Kiryanov wrote:
void* pointer arithmetic is not in the
C standard. This change allows using
the QEMU headers with a C++ compiler.
Google-Bug-Id: 331190993
Change-Id: I5a064853429f627c17a9213910811dea4ced6174
Signed-off-by: Roman Kiryanov
Would it work instead to declar
On 6/19/24 00:45, Roman Kiryanov wrote:
to use the QEMU headers with a C++ compiler.
Google-Bug-Id: 331190993
Change-Id: Ic4e49b9c791616bb22c973922772b0494706092c
Signed-off-by: Roman Kiryanov
---
include/exec/memory.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/i
Add VIRTIO_F_IN_ORDER feature support for the virtqueue_fill operation.
The goal of the virtqueue_ordered_fill operation when the
VIRTIO_F_IN_ORDER feature has been negotiated is to search for this
now-used element, set its length, and mark the element as filled in
the VirtQueue's used_elems array
Add support for the VIRTIO_F_IN_ORDER feature across a variety of vhost
devices.
The inclusion of VIRTIO_F_IN_ORDER in the feature bits arrays for these
devices ensures that the backend is capable of offering and providing
support for this feature, and that it can be disabled if the backend
does n
Extend the virtio device property definitions to include the
VIRTIO_F_IN_ORDER feature.
The default state of this feature is disabled, allowing it to be
explicitly enabled where it's supported.
Acked-by: Eugenio Pérez
Signed-off-by: Jonah Palmer
---
include/hw/virtio/virtio.h | 4 +++-
1 file
The goal of these patches is to add support to a variety of virtio and
vhost devices for the VIRTIO_F_IN_ORDER transport feature. This feature
indicates that all buffers are used by the device in the same order in
which they were made available by the driver.
These patches attempt to implement a g
Add VIRTIO_F_IN_ORDER feature support in virtqueue_split_pop and
virtqueue_packed_pop.
VirtQueueElements popped from the available/descritpor ring are added to
the VirtQueue's used_elems array in-order and in the same fashion as
they would be added the used and descriptor rings, respectively.
Thi
Add VIRTIO_F_IN_ORDER feature support for the virtqueue_flush operation.
The goal of the virtqueue_ordered_flush operation when the
VIRTIO_F_IN_ORDER feature has been negotiated is to write elements to
the used/descriptor ring in-order and then update used_idx.
The function iterates through the V
Add the boolean 'in_order_filled' member to the VirtQueueElement structure.
The use of this boolean will signify whether the element has been processed
and is ready to be flushed (so long as the element is in-order). This
boolean is used to support the VIRTIO_F_IN_ORDER feature.
Reviewed-by: Eugen
On Thu, Jun 20, 2024 at 7:22 PM Richard Henderson
wrote:
> > I'm not sure this makes sense. The CONFIG_AVX* options are used only
> > to validate whether the toolchain has support for this. The QEMU
> > code then has a runtime, so it automagically uses AVX2/AVX512
> > if-and-only-if running on a s
On 6/19/24 20:37, Alex Bennée wrote:
> So I've been experimenting with Aarch64 TCG with an Intel backend like
> this:
>
> ./qemu-system-aarch64 \
>-M virt -cpu cortex-a76 \
>-device virtio-net-pci,netdev=unet \
>-netdev user,id=unet,hostfwd=tcp::-:22 \
>
On 20/06/2024 10.28, Arthur Tumanyan wrote:
Hi all,
My question may sound stupid, however...
Hi Arthur,
no worries, the question how to use which device in QEMU can be quite tricky ;-)
Currently I'm trying to make
available designware-root-{port,host} devices in linux when I run it in qem
On 6/20/24 08:01, Daniel P. Berrangé wrote:
On Thu, Jun 20, 2024 at 03:02:54PM +0200, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
---
meson.build | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meson.build b/meson.build
index 54e6b09f4fb..c5360fbd299 100644
--- a/meson.build
+++
On 20/06/2024 18.57, Daniel P. Berrangé wrote:
The new deprecation and deletion policy for versioned machine types is
being introduced in QEMU 9.1.0.
Under the new policy a number of old machine types (any prior to 2.12)
would be liable for immediate deletion which would be a violation of our
hi
On 6/20/24 06:02, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
---
meson.build | 41 ---
meson_options.txt | 3 +++
scripts/meson-buildoptions.sh | 3 +++
3 files changed, 39 insertions(+), 8 deletions(-)
Acked-by: Richar
On 20/06/2024 17.22, Alex Bennée wrote:
If the plugin in controlling time there is some state that might be
missing from the plugin tracking it. Migration is unlikely to work in
this case so lets put a migration blocker in to let the user know if
they try.
Signed-off-by: Alex Bennée
Suggested-b
On 6/20/24 06:02, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
---
meson.build | 13 -
meson_options.txt | 2 --
2 files changed, 15 deletions(-)
Reviewed-by: Richard Henderson
r~
On Wed, 19 Jun 2024 00:53:10 +0800
Shiyang Ruan wrote:
> Background:
> Since CXL device is a memory device, while CPU consumes a poison page of
> CXL device, it always triggers a MCE by interrupt (INT18), no matter
> which-First path is configured. This is the first report. Then
> currently,
This calls the MACHINE_VER_DELETION() macro in the machine type
registration method, so that when a versioned machine type reaches
the end of its life, it is no longer registered with QOM and thus
cannot be used.
The actual definition of the machine type should be deleted at
this point, but experi
This extends the deprecation policy to indicate that versioned machine
types will be marked deprecated after 3 years, and then subject to
removal after a further 3 years has passed.
Reviewed-by: Thomas Huth
Signed-off-by: Daniel P. Berrangé
---
docs/about/deprecated.rst | 13 +
1 fi
This changes the DEFINE_VIRT_MACHINE macro to use the common
helpers for constructing versioned symbol names and strings,
bringing greater consistency across targets.
A DEFINE_VIRT_MACHINE_AS_LATEST helper is added so that it
is not required to pass 'false' for every single historical
machine type
1 - 100 of 239 matches
Mail list logo
