Cc: Phil, because we're now discusing qemu-system-any.
Daniel P. Berrangé writes:
> On Fri, Dec 06, 2024 at 09:25:54AM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé writes:
>>
>> > On Wed, Dec 04, 2024 at 12:07:58PM +0100, Markus Armbruster wrote:
>> >> To be fair, object_new() was not
Thanks Daniel.
Let's wait for about a week or so for other suggestions to the patches and
then I'll send a new updated series.
сб, 7 дек. 2024 г. в 00:08, Daniel Henrique Barboza <
dbarb...@ventanamicro.com>:
>
>
> On 12/5/24 8:23 AM, baturo.ale...@gmail.com wrote:
> > From: Alexey Baturo
> >
>
Another subject line that suggests this isn't fully baked. Respin to
reduce confusion?
Ani Sinha writes:
> On Fri, Dec 6, 2024 at 10:51 PM Mauro Carvalho Chehab
> wrote:
>>
>> Signed-off-by: Mauro Carvalho Chehab
>> ---
>> hw/acpi/ghes.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
>> index abca351b18de..1fe4c536611a 100644
>> ---
Markus Armbruster writes:
> This is v10, right?
Scratch that, the cover letter explains: "As agreed duing v10 review,
I'll be splitting the big patch series into separate pull requests,
starting with the cleanup series. This is the first patch set,
containing only such preparation patches."
Ho
This is v10, right?
On Fri, Dec 6, 2024 at 10:51 PM Mauro Carvalho Chehab
wrote:
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> hw/acpi/ghes.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
> index abca351b18de..1fe4c536611a 100644
> --- a/hw/acpi/ghes.c
> +++ b/hw/acpi
On 2024/12/6 21:36, Richard Henderson wrote:
On 12/5/24 22:39, LIU Zhiwei wrote:
Both zcmt and zcmp are not compatible with Zcd, as they reuse some
encodings from c.fsdsp.
Ok, fair. A comment about conflicts at that point may help.
Ok.
Zimop or Zcmop also overlap with other isa exten
>> +++ b/tests/tcg/plugins/inject.c
>
> Could we find a better name?
For sure, maybe "hypercalls.c" since that's really what it's mostly about.
>> @@ -0,0 +1,206 @@
>> +/*
>> + * Copyright (C) 2024, Rowan Hart
>> + *
>> + * License: GNU GPL, version 2 or later.
>> + * See the COPYING file in
> I am personally in favor to adding such features in upstream QEMU, but we
> should discuss it with the maintainers, because it would allow to change the
> state of execution, which is something qemu plugins actively didn't try to
> do. It's a real paradigm shift for plugins.
>
> By writing to
Src QEMU sets block_inactive=true very early before the invalidation takes
place. It means if something wrong happened during setting the flag but
before reaching qemu_savevm_state_complete_precopy_non_iterable() where it
did the invalidation work, it'll make block_inactive flag inconsistent.
For
In 99% cases, after QEMU migrates to dest host, it tries to detect the
target VM runstate using global_state_get_runstate().
There's one outlier so far which is Xen that won't send global state.
That's the major reason why global_state_received() check was always there
together with global_state_g
As the comment says, the activation of disks is for the case where
migration has completed, rather than when QEMU is still during
migration (RUN_STATE_INMIGRATE).
Move the code over to reflect what the comment is describing.
Cc: Kevin Wolf
Cc: Markus Armbruster
Signed-off-by: Peter Xu
---
mon
This patch proposes a flag to maintain disk activation status globally. It
mostly rewrites disk activation mgmt for QEMU, including COLO and QMP
command xen_save_devices_state.
Backgrounds
===
We have two problems on disk activations, one resolved, one not.
Problem 1: disk activation re
CI: https://gitlab.com/peterx/qemu/-/pipelines/1577280033
(note: it's a pipeline of two patchsets, to save CI credits and time)
v1: https://lore.kernel.org/r/20241204005138.702289-1-pet...@redhat.com
This is v2 of the series, removing RFC tag, because my goal is to have them
(or some newer versi
Postcopy never cared about late-block-active. However there's no mention
in the capability that it doesn't apply to postcopy.
Considering that we _assumed_ late activation is always good, do that too
for postcopy unconditionally, just like precopy. After this patch, we
should have unified the be
Migration capability 'late-block-active' controls when the block drives
will be activated. If enabled, block drives will only be activated until
VM starts, either src runstate was "live" (RUNNING, or SUSPENDED), or it'll
be postponed until qmp_cont().
Let's do this unconditionally. There's no ha
Firstly, we're going to use the multifd flag soon in multifd code, so ram.c
isn't gonna work.
Secondly, we have a separate RDMA flag dangling around, which is definitely
not obvious. There's one comment that helps, but not too much.
Put all RAM save flags altogether, so nothing will get overlook
On 12/6/24 14:40, Pierrick Bouvier wrote:
Do we have an architecture agnostic pc representation, or do we have to add this for every
target in {arch}_cpu_exec_interrupt?
We have CPUClass.get_pc, which is almost certainly what you want.
The call to TCGCPUOps.cpu_exec_interrupt is only a hint th
It's not straightforward to see why src QEMU needs to sync multifd during
setup() phase. After all, there's no page queued at that point.
For old QEMUs, there's a solid reason: EOS requires it to work. While it's
clueless on the new QEMUs which do not take EOS message as sync requests.
One will
Multifd never worked with postcopy, at least yet so far.
Remove the sync processing there, because it's confusing, and they should
never appear. Now if RAM_SAVE_FLAG_MULTIFD_FLUSH is observed, we fail hard
instead of trying to invoke multifd code.
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter
CI: https://gitlab.com/peterx/qemu/-/pipelines/1577280033
(note: it's a pipeline of two patchsets, to save CI credits and time)
v1: https://lore.kernel.org/r/20241205185303.897010-1-pet...@redhat.com
v2: https://lore.kernel.org/r/20241206005834.1050905-1-pet...@redhat.com
v3 changelog:
- R-bs co
Commit 637280aeb2 ("migration/multifd: Avoid the final FLUSH in
complete()") stopped sending the RAM_SAVE_FLAG_MULTIFD_FLUSH flag at
ram_save_complete(), because the sync on the destination side is not
needed due to the last iteration of find_dirty_block() having already
done it.
However, that com
The src flush condition check is over complicated, and it's getting more
out of control if postcopy will be involved.
In general, we have two modes to do the sync: legacy or modern ways.
Legacy uses per-section flush, modern uses per-round flush.
Mapped-ram always uses the modern, which is per-ro
Teach multifd_send_sync_main() to sync with threads only.
We already have such requests, which is when mapped-ram is enabled with
multifd. In that case, no SYNC messages will be pushed to the stream when
multifd syncs the sender threads because there's no destination threads
waiting for that. Th
RAM_SAVE_FLAG_MULTIFD_FLUSH message should always be correlated to a sync
request on src. Unify such message into one place, and conditionally send
the message only if necessary.
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
migration/multifd.h| 2 +-
migration/multifd-nocomp
On 12/6/24 13:28, Pierrick Bouvier wrote:
Pierrick Bouvier (6):
docs/devel: remove dead video link for sourcehut submit process
docs/devel: add git-publish for patch submitting
docs/devel: add b4 for patch retrieval
docs/devel: add information on how to setup build environments
doc
On Fri, Dec 06, 2024 at 07:03:36PM +0100, Maciej S. Szmigiero wrote:
> On 4.12.2024 20:10, Peter Xu wrote:
> > On Sun, Nov 17, 2024 at 08:19:55PM +0100, Maciej S. Szmigiero wrote:
> > > Important note:
> > > 4 VF benchmarks were done with commit 5504a8126115
> > > ("KVM: Dynamic sized kvm memslots
On Fri, Dec 06, 2024 at 07:24:58PM +0100, Maciej S. Szmigiero wrote:
> On 5.12.2024 20:46, Zhang Chen wrote:
> > On Thu, Dec 5, 2024 at 5:30 AM Peter Xu wrote:
> > >
> > > On Sun, Nov 17, 2024 at 08:20:00PM +0100, Maciej S. Szmigiero wrote:
> > > > diff --git a/migration/colo.c b/migration/colo.c
On Fri, Dec 06, 2024 at 07:40:19PM +0100, Maciej S. Szmigiero wrote:
> On 4.12.2024 22:38, Peter Xu wrote:
> > On Sun, Nov 17, 2024 at 08:20:02PM +0100, Maciej S. Szmigiero wrote:
> > > From: "Maciej S. Szmigiero"
> > >
> > > Some of these SaveVMHandlers were missing the BQL behavior annotation,
On Fri, Dec 06, 2024 at 10:12:27PM +0100, Maciej S. Szmigiero wrote:
> Same here :) - the sender sent us possibly wrong packet or packet of
> incompatible version, we should handle this gracefully rather than
> assert()/abort() QEMU.
Ah, sure. Feel free to keep them. My R-b can keep.
--
Peter
On 5.12.2024 17:17, Peter Xu wrote:
On Sun, Nov 17, 2024 at 08:20:06PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
multifd_send() function is currently not thread safe, make it thread safe
by holding a lock during its execution.
This way it will be possible to safely call it
On 5.12.2024 17:06, Peter Xu wrote:
On Sun, Nov 17, 2024 at 08:20:05PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Add a basic support for receiving device state via multifd channels -
channels that are shared with RAM transfers.
Depending whether MULTIFD_FLAG_DEVICE_STATE f
On 4.12.2024 22:32, Peter Xu wrote:
On Sun, Nov 17, 2024 at 08:20:01PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
qemu_loadvm_load_state_buffer() and its load_state_buffer
SaveVMHandler allow providing device state buffer to explicitly
specified device via its idstr and inst
On 4.12.2024 20:24, Peter Xu wrote:
On Sun, Nov 17, 2024 at 08:19:57PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This function name conflicts with one used by a future generic thread pool
function and it was only used by one test anyway.
Update the trace event name in thre
On 12/5/24 8:22 AM, baturo.ale...@gmail.com wrote:
From: Alexey Baturo
Signed-off-by: Alexey Baturo
---
Reviewed-by: Daniel Henrique Barboza
target/riscv/cpu.h | 8
target/riscv/cpu_bits.h | 4
target/riscv/cpu_cfg.h | 3 +++
target/riscv/csr.c | 31 ++
On 12/5/24 8:23 AM, baturo.ale...@gmail.com wrote:
From: Alexey Baturo
Signed-off-by: Alexey Baturo
---
target/riscv/cpu.h| 5 +++
target/riscv/cpu_helper.c | 74 +++
2 files changed, 79 insertions(+)
diff --git a/target/riscv/cpu.h b/target
On 12/6/24 11:42, Richard Henderson wrote:
On 12/6/24 13:02, Pierrick Bouvier wrote:
On 12/6/24 00:42, Julian Ganz wrote:
Hi Pierrick,
December 5, 2024 at 11:28 PM, "Pierrick Bouvier" wrote:
On 12/5/24 13:22, Julian Ganz wrote:
December 5, 2024 at 6:30 PM, "Pierrick Bouvier" wrote:
We ca
On 12/6/24 02:26, Rowan Hart wrote:
From: novafacing
---
tests/tcg/plugins/inject.c | 206 +++
tests/tcg/plugins/meson.build| 2 +-
tests/tcg/x86_64/Makefile.target | 1 +
tests/tcg/x86_64/inject-target.c | 27
4 files changed, 235 insertion
Hi Rowan,
thanks for this submission!
On 12/6/24 02:26, Rowan Hart wrote:
This patch set follows a previous patch which added the
qemu_plugin_read_memory_vaddr function and adds a set of similar
functions to read and write registers, virtual memory, and
physical memory.
The use case I have in
On 12/6/24 13:02, Pierrick Bouvier wrote:
On 12/6/24 00:42, Julian Ganz wrote:
Hi Pierrick,
December 5, 2024 at 11:28 PM, "Pierrick Bouvier" wrote:
On 12/5/24 13:22, Julian Ganz wrote:
December 5, 2024 at 6:30 PM, "Pierrick Bouvier" wrote:
We can store the next_expected pc for each instruct
Signed-off-by: Pierrick Bouvier
---
docs/devel/control-flow-integrity.rst | 2 +
docs/devel/multi-thread-tcg.rst | 2 +
docs/glossary.rst | 280 ++
docs/index.rst| 1 +
docs/system/arm/virt.rst | 2 +
d
Present the various parts of QEMU and organization of codebase.
Signed-off-by: Pierrick Bouvier
---
docs/about/emulation.rst | 2 +
docs/devel/codebase.rst| 218 +
docs/devel/decodetree.rst | 2 +
docs/devel/ebpf_rss.rst
MacOS and Linux are straightforward, but Windows needs a bit more
details.
Signed-off-by: Pierrick Bouvier
---
docs/about/build-platforms.rst | 4 +-
docs/devel/build-environment.rst | 118 +++
docs/devel/index-build.rst | 1 +
3 files changed, 122 inserti
Signed-off-by: Pierrick Bouvier
---
docs/devel/submitting-a-patch.rst | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/devel/submitting-a-patch.rst
b/docs/devel/submitting-a-patch.rst
index 69df7682c5e..1ef7d137320 100644
--- a/docs/devel/submitting-a-patch.rst
+++ b/docs/dev
This series extends our documentation with new pages to help developers
onboarding on QEMU. It focuses on providing a big picture of QEMU (to a
modest extend).
As such, it was written to be simple, short, easy to understand, and pointing to
more details. It provides another way to dive into detail
Signed-off-by: Pierrick Bouvier
---
docs/devel/submitting-a-patch.rst | 25 +
1 file changed, 25 insertions(+)
diff --git a/docs/devel/submitting-a-patch.rst
b/docs/devel/submitting-a-patch.rst
index 03b2ac298aa..69df7682c5e 100644
--- a/docs/devel/submitting-a-patch.rst
Reviewed-by: Thomas Huth
Signed-off-by: Pierrick Bouvier
---
docs/devel/submitting-a-patch.rst | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/docs/devel/submitting-a-patch.rst
b/docs/devel/submitting-a-patch.rst
index 10b062eec26..03b2ac298aa 100644
--- a/docs/devel/sub
On 12/6/24 03:43, Peter Maydell wrote:
On Fri, 6 Dec 2024 at 11:32, Daniel P. Berrangé wrote:
On Thu, Dec 05, 2024 at 02:22:37PM -0800, Pierrick Bouvier wrote:
Signed-off-by: Pierrick Bouvier
---
docs/devel/submitting-a-patch.rst | 19 +++
1 file changed, 19 insertions(+)
这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。
Reviewed-by: Cédric Le Goater
Signed-off-by: Pierrick Bouvier
---
docs/system/arm/fby35.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/docs/system/arm/fby35.rst b/docs/system/arm/fby35.rst
index bf6da6baa2a..e19274e75c8 100644
--- a/docs/system/arm/fby35.rst
+++ b/docs/system/arm/f
Signed-off-by: Pierrick Bouvier
---
docs/system/arm/xlnx-versal-virt.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/docs/system/arm/xlnx-versal-virt.rst
b/docs/system/arm/xlnx-versal-virt.rst
index 0bafc76469d..c5f35f28e4f 100644
--- a/docs/system/arm/xlnx-versal-virt.rst
+++ b/docs/
Reviewed following things:
- system/arm/cpu-features (options)
- system/arm/virt (options)
- boards documented and listed with -machine help (arm and aarch64)
- grep object_class_property_set_description hw/arm: ensure all options are
documented
- reviewed boards description
- reviewed all Arm fe
Signed-off-by: Pierrick Bouvier
---
docs/system/arm/virt.rst | 16
1 file changed, 16 insertions(+)
diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index 11ceb898264..d25275c27ce 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -169,10 +16
www.orangepi.org does not support https, it's expected to stick to http.
Reviewed-by: Niek Linnenbank
Signed-off-by: Pierrick Bouvier
---
docs/system/arm/orangepi.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/system/arm/orangepi.rst b/docs/system/arm/orangepi.
Il ven 6 dic 2024, 09:42 Peter Maydell ha
scritto:
> On Fri, 6 Dec 2024 at 14:28, Paolo Bonzini wrote:
> > Yes, hence "decently" packed. But I think in both cases it's passed in
> registers, and for 64-bit machine that shouldn't change anything.
>
> True. Though it does mean we go from "space to
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/timer/hpet.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/timer/hpet.h b/include/hw/timer/hpet.h
index 2a95799a679..d11cdff0347 100644
--- a/include/hw/timer/hpet.h
+++ b/include/hw/timer/hpet.h
@@ -64,7 +64,7
No need to have an external hpet_cfg[] array accessed
outside of hpet.c. Move it in the class state.
Philippe Mathieu-Daudé (4):
hw/timer/hpet: Introduce hpet_add_fw_cfg_bytes()
hw/timer/hpet: Reduce hpet_cfg[] scope
hw/timer/hpet: Have hpet_find() return an Object
hw/timer/hpet: Hold fw_c
Now than hpet_cfg[] is only accessed within hpet.c, make
it static. No need to expose the hpet_fw_entry/hpet_fw_config
structure declarations outside of it, so move them in the
source too.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/timer/hpet.h | 16
hw/timer/hpet.c
We maintain one hpet_cfg[] state for all HPET instances.
Move it to a new HPET class.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/timer/hpet.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
index 849cb3e66
Introduce hpet_add_fw_cfg_bytes() to restrict accesses
to hpet_cfg[] within hw/timer/hpet.c.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/timer/hpet.h | 2 ++
hw/i386/fw_cfg.c| 5 ++---
hw/timer/hpet.c | 10 ++
3 files changed, 14 insertions(+), 3 deletions(-)
On 12/6/24 00:42, Julian Ganz wrote:
Hi Pierrick,
December 5, 2024 at 11:28 PM, "Pierrick Bouvier" wrote:
On 12/5/24 13:22, Julian Ganz wrote:
December 5, 2024 at 6:30 PM, "Pierrick Bouvier" wrote:
We can store the next_expected pc for each instruction (from
current_instruction + insn_leng
On 12/6/24 00:58, Julian Ganz wrote:
Hi Pierrick,
December 6, 2024 at 12:03 AM, "Pierrick Bouvier" wrote:
On 12/5/24 13:50, Julian Ganz wrote:
If you cannot rely on an input being a sensible value, doesn't that
render the input useless?
I agree. If for a specific event it's impossible to
On Fri, 2024-12-06 at 10:42 +0800, Xiaoyao Li wrote:
> # Interaction with TDX_FEATURES0.VE_REDUCTION
>
> TDX introduces a new feature VE_REDUCTION[2]. From the perspective of
> host VMM, VE_REDUCTION turns several CPUID bits from fixed1 to
> configurable, e.g., MTRR, MCA, MCE, etc. However, from
On 5.12.2024 22:27, Cédric Le Goater wrote:
On 11/17/24 20:19, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This is an updated v3 patch series of the v2 series located here:
https://lore.kernel.org/qemu-devel/cover.1724701542.git.maciej.szmigi...@oracle.com/
Changes from v2:
* Rewor
On 4.12.2024 22:38, Peter Xu wrote:
On Sun, Nov 17, 2024 at 08:20:02PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Some of these SaveVMHandlers were missing the BQL behavior annotation,
making people wonder what it exactly is.
Signed-off-by: Maciej S. Szmigiero
---
includ
On 5.12.2024 20:46, Zhang Chen wrote:
On Thu, Dec 5, 2024 at 5:30 AM Peter Xu wrote:
On Sun, Nov 17, 2024 at 08:20:00PM +0100, Maciej S. Szmigiero wrote:
diff --git a/migration/colo.c b/migration/colo.c
index 9590f281d0f1..a75c2c41b464 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -
这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。
On 12/3/24 16:00, David Hildenbrand wrote:
On 03.12.24 15:39, William Roche wrote:
[...]
Our new Qemu code is testing first the fallocate+MADV_DONTNEED procedure
for standard sized pages (in ram_block_discard_range()) and only folds
back to the mmap() use if it fails. So maybe my proposal to imp
Convert the intel_iommu test to the new functional framework.
This test needs some changes since we neither support the old 'LinuxTest'
class in the functional framework yet, nor a way to use SSH for running
commands in the guest. So we now directly download a Fedora kernel and
initrd and set up th
The FW_CFG_DATA_GENERATOR allows any object to produce
blob of data consumable by the fw_cfg device. Implement
that for PCI bus objects.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci/pci.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/hw/pci/pci.c
Now that all uses of fw_cfg_add_extra_pci_roots() have been
converted to the newer pci_bus_add_fw_cfg_extra_pci_roots(),
we can remove that bogus method. hw/nvram/fw_cfg must
stay generic. Device specific entries have to be implemented
using TYPE_FW_CFG_DATA_GENERATOR_INTERFACE.
This mostly revert
On 12/6/24 10:27, Peter Maydell wrote:
On Sun, 1 Dec 2024 at 15:12, Richard Henderson
wrote:
Remove disas_simd_scalar_shift_imm as these were the
last insns decoded by that function.
Signed-off-by: Richard Henderson
---
target/arm/tcg/translate-a64.c | 47 --
We want to remove fw_cfg_add_extra_pci_roots() which introduced
PCI bus knowledge within the generic hw/nvram/fw_cfg.c file.
Replace the calls by the pci_bus_add_fw_cfg_extra_pci_roots()
which is a 1:1 equivalent, but using correct API.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/virt.c
Currently fw_cfg_add_file_from_generator() is restricted
to command line created objects which reside in the
'/objects' QOM container. In order to extend to other
types of containers, pass the QOM parent by argument.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/nvram/fw_cfg.h | 10 ++
pci_bus_add_fw_cfg_extra_pci_roots() calls the fw_cfg
API with PCI bus specific arguments.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/pci/pci.h | 3 +++
hw/pci/pci.c | 16
2 files changed, 19 insertions(+)
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pc
In order to keep fw_cfg device model clean, remove the PCI
bus specific code. Instead, the equivalent functionality is
implemented within the PCI_BUS object in hw/pci/,
implementing TYPE_FW_CFG_DATA_GENERATOR_INTERFACE.
Philippe Mathieu-Daudé (6):
hw/nvram/fw_cfg: Rename fw_cfg_add_[file]_from_g
fw_cfg_add_from_generator() is adding a 'file' entry,
so rename as fw_cfg_add_file_from_generator() for
clarity. Besides, we might introduce generators for
other entry types.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/nvram/fw_cfg.h | 6 +++---
hw/nvram/fw_cfg.c | 4 ++--
syste
On 12/6/24 10:23, Peter Maydell wrote:
On Sun, 1 Dec 2024 at 15:21, Richard Henderson
wrote:
Arm silliness with naming, the scalar insns described
as part of the vector instructions, as separate from
the "regular" scalar insns which output to general registers.
Signed-off-by: Richard Henderso
On 4.12.2024 20:10, Peter Xu wrote:
On Sun, Nov 17, 2024 at 08:19:55PM +0100, Maciej S. Szmigiero wrote:
Important note:
4 VF benchmarks were done with commit 5504a8126115
("KVM: Dynamic sized kvm memslots array") and its revert-dependencies
reverted since this seems to improve performance in th
[AMD Official Use Only - AMD Internal Distribution Only]
Hi David,
Thanks for your comments.
Let me give you some background for this patch.
I am currently engaged in a project that requires to pass the EFI_MEMORY_SP
(Special Purpose Memory) type memory from host to a virtual machine within
QEM
Accurately injecting an ARM Processor error ACPI/APEI GHES
error record requires the value of the ARM Multiprocessor
Affinity Register (mpidr).
While ARM implements it, this is currently not visible.
Add a field at CPU storing it, and place it at arm_cpu_properties
as experimental, thus allowing
Some error injection notify methods are async, like GPIO
notify. Add a notifier to be used when the error record is
ready to be sent to the guest OS.
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/ghes.c | 5 -
include/hw/acpi/ghes.h | 3 +++
2 files changed, 7 insertions(+), 1 del
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
Adds a generic error device to handle generic hardware error
events as specified at ACPI 6.5 specification at 18.3.2.7.2:
https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html#event-notification-for-generic-error-sources
using HID PNP0C33.
The PNP0C33 device is used to report hardware
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
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/
Using the QMP GHESv2 API requires preparing a raw data array
containing a CPER record.
Add a helper script with subcommands to prepare such data.
Currently, only ARM Processor error CPER record is supported.
Signed-off-by: Mauro Carvalho Chehab
---
MAINTAINERS| 3 +
scrip
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
Adds support to ARM virtualization to allow handling
generic error ACPI Event via GED & error source device.
It is aligned with Linux Kernel patch:
https://lore.kernel.org/lkml/1272350481-27951-8-git-send-email-ying.hu...@intel.com/
Co-authored-by: Jonathan Cameron
Signed-off-by: Jonathan Camero
Add support to retrieve mpidr value via qom-get.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/arm_processor_error.py | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/scripts/arm_processor_error.py b/scripts/arm_processor_error.py
index 62e0c5
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.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Igor Mammedov
Reviewed-by: Jonathan Cameron
---
hw/acpi/ghes-stub.c| 2 +-
hw/acpi/ghes.c
The etc/hardware_errors fw_cfg file is where the HEST error
source structures store registers pointed by Generic Address
Structures, as defined at:
https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html#generic-error-data-entry
and
https://uefi.org/specs/ACPI/6.5/18_
The current code is actually dependent on having just one error
structure with a single source.
As the number of sources should be arch-dependent, as it will depend on
what kind of synchronous/assynchronous notifications will exist, change
the logic to dynamically build the table.
Yet, for a prop
This reverts commit 692373fc8838a6450ff5b5a8708646a673b693dd.
Signed-off-by: Mauro Carvalho Chehab
---
hw/arm/virt-acpi-build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 31f2db01458d..55d12562e83e 100644
--- a/hw
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
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
Create a new property (x-has-hest-addr) and use it to detect if
the GHES table offsets can be calculated from the HEST address
(qemu 9.2 and upper) or via the legacy way via an offset obtained
from the hardware_errors firmware file.
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Jonathan Camer
Signed-off-by: Mauro Carvalho Chehab
---
hw/acpi/ghes.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
index 1fe4c536611a..856551df2103 100644
--- a/hw/acpi/ghes.c
+++ b/hw/acpi/ghes.c
@@ -211,6 +211,12 @@ ghes_gen_err_data_u
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
1 - 100 of 304 matches
Mail list logo
