On Thu, Sep 07, 2023 at 10:35:38AM +1000, Gavin Shan wrote:
> For target/tricore, the CPU type name is always the combination of the
> CPU model name and suffix. The CPU model names have been correctly
> shown in tricore_cpu_list_entry().
>
> Use generic helper cpu_model_from_type() to show the
On Fri, Aug 25, 2023 at 12:31 AM Sunil V L wrote:
>
> RISC-V also needs to create the virtio in DSDT in the same way as ARM. So,
> instead of duplicating the code, move this function to the device specific
> file which is common across architectures.
>
> Suggested-by: Igor Mammedov
>
On Fri, Aug 25, 2023 at 12:30 AM Sunil V L wrote:
>
> RISC-V also needs to use the same code to create fw_cfg in DSDT. So, avoid
> code duplication by moving the code in arm and riscv to a device specific
> file.
>
> Suggested-by: Igor Mammedov
> Signed-off-by: Sunil V L
Reviewed-by: Alistair
On 9/6/23 21:57, Stefan Hajnoczi wrote:
On Wed, 6 Sept 2023 at 09:07, Hao Xu wrote:
On 5/18/23 00:26, Stefan Hajnoczi wrote:
On Wed, 17 May 2023 at 11:54, Alex Bennée wrote:
Hi Alex,
There were two unresolved issues:
1. How to inject SIGBUS when the guest accesses a page that's beyond
the
On Sat, Sep 2, 2023 at 5:48 AM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> This new version contains suggestions made by Andrew Jones in v8.
>
> Most notable change is the removal of the opensbi.py test in patch 11,
> which was replaced by a TuxBoot test. It's more suitable to test the
> integrity
On Sat, Sep 2, 2023 at 5:49 AM Daniel Henrique Barboza
wrote:
>
> During realize() time we're activating a lot of extensions based on some
> criteria, e.g.:
>
> if (cpu->cfg.ext_zk) {
> cpu->cfg.ext_zkn = true;
> cpu->cfg.ext_zkr = true;
> cpu->cfg.ext_zkt = true;
>
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> Adding initial documentation about Nested PAPR API to describe the set
> of APIs and its usage. Also talks about the Guest State Buffer elements
> and it's format which is used between L0/L1 to communicate L2 state.
I would move this
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> Once the L1 has created a nested guest and its associated VCPU, it can
> request for the execution of nested guest by setting its initial state
> which can be done either using the h_guest_set_state or using the input
> buffers along
On Sat, Sep 2, 2023 at 5:51 AM Daniel Henrique Barboza
wrote:
>
> Add smoke tests to ensure that we'll not break the 'max' CPU type when
> adding new frozen/ratified RISC-V extensions.
>
> Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Alistair
> ---
>
I guess the last time I sent IDE patches was for 6.2 and that tag got
stuck in my git-publish invocation, oops. I am not suggesting we break
the laws of causality to merge these patches.
On Wed, Sep 6, 2023 at 11:42 PM John Snow wrote:
>
> The following changes since commit
From: Niklas Cassel
According to AHCI 1.3.1 definition of PxSACT:
This field is cleared when PxCMD.ST is written from a '1' to a '0' by
software. This field is not cleared by a COMRESET or a software reset.
According to AHCI 1.3.1 definition of PxCI:
This field is also cleared when PxCMD.ST is
From: Niklas Cassel
When there is an error, we need to raise a TFES error irq, see AHCI 1.3.1,
5.3.13.1 SDB:Entry.
If ERR_STAT is set, we jump to state ERR:FatalTaskfile, which will raise
a TFES IRQ unconditionally, regardless if the I bit is set in the FIS or
not.
Thus, we should never raise
From: Niklas Cassel
When encountering an NCQ error, you should not write the NCQ tag to the
SError register. This is completely wrong.
The SError register has a clear definition, where each bit represents a
different error, see PxSERR definition in AHCI 1.3.1.
If we write a random value (like
The following changes since commit c152379422a204109f34ca2b43ecc538c7d738ae:
Merge tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu into
staging (2023-09-06 11:16:01 -0400)
are available in the Git repository at:
https://gitlab.com/jsnow/qemu.git tags/ide-pull-request
for
From: Niklas Cassel
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
Successfully means ERR_STAT, BUSY and DRQ are all cleared.
A command that has ERR_STAT set, does not get to clear PxCI.
See AHCI 1.3.1, section 5.3.8,
From: Niklas Cassel
The AHCI spec states that:
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
(A non-NCQ command that completes with error does not clear PxCI.)
The current QEMU implementation either clears PxCI in
From: Niklas Cassel
The way that BUSY + PxCI is cleared for NCQ (FPDMA QUEUED) commands is
described in SATA 3.5a Gold:
11.15 FPDMA QUEUED command protocol
DFPDMAQ2: ClearInterfaceBsy
"Transmit Register Device to Host FIS with the BSY bit cleared to zero
and the DRQ bit cleared to zero and
From: Niklas Cassel
Currently, the first time sending an unsupported command
(e.g. READ LOG DMA EXT) will not have ERR_STAT set in the completion.
Sending the unsupported command again, will correctly have ERR_STAT set.
When ide_cmd_permitted() returns false, it calls ide_abort_command().
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> L1 can reuest to get/set state of any of the supported Guest State
> Buffer (GSB) elements using h_guest_[get|set]_state hcalls.
> These hcalls needs to do some necessary validation check for each
> get/set request based on the flags
On Thu, Aug 3, 2023 at 10:47 AM Wu, Fei wrote:
>
> On 8/1/2023 6:46 AM, Daniel Henrique Barboza wrote:
> >
> >
> > On 7/30/23 22:53, Fei Wu wrote:
> >> riscv virt platform's memory started at 0x8000 and
> >> straddled the 4GiB boundary. Curiously enough, this choice
> >> of a memory layout
On Wed, Jul 26, 2023 at 10:08 PM Andrew Jones wrote:
>
> Add instructions for how to cross-compile QEMU for RISC-V. The
> file is named generically because there's no reason not to collect
> other architectures steps into the same file, especially because
> several subsections like those for
On Tue, Sep 5, 2023 at 2:30 AM Alvin Chang wrote:
>
> Current checks on writing pmpcfg for ePMP follows ePMP version 0.9.1.
> However, ePMP specification has already been ratified, and there are
> some differences between version 0.9.1 and 1.0. In this commit we update
> the checks of writing
On Tue, Aug 8, 2023 at 7:10 PM Nikita Shubin wrote:
>
> From: Nikita Shubin
>
> As per ISA:
>
> "For CSRRWI, if rd=x0, then the instruction shall not read the CSR and
> shall not cause any of the side effects that might occur on a CSR read."
>
> trans_csrrwi() and trans_csrrw() call do_csrw() if
Might be good to add a common nested: prefix to all patches actually.
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This is a first step towards enabling support for nested PAPR hcalls for
> providing the get/set of various Guest State Buffer (GSB) elements via
>
On Tue, Aug 8, 2023 at 7:10 PM Nikita Shubin wrote:
>
> From: Nikita Shubin
>
> As per ISA:
>
> "For CSRRWI, if rd=x0, then the instruction shall not read the CSR and
> shall not cause any of the side effects that might occur on a CSR read."
>
> trans_csrrwi() and trans_csrrw() call do_csrw() if
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This patch implements support for hcall H_GUEST_CREATE_VCPU which is
> used to instantiate a new VCPU for a previously created nested guest.
> The L1 provide the guest-id (returned by L0 during call to
> H_GUEST_CREATE) and an
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This hcall is used by L1 to delete a guest entry in L0 or can also be
> used to delete all guests if needed (usually in shutdown scenarios).
I'd squash with at least the create hcall.
>
> Signed-off-by: Michael Neuling
>
On Wed, Aug 16, 2023 at 4:18 PM Tommy Wu wrote:
>
> According to the new spec, when vsiselect has a reserved value, attempts
> from M-mode or HS-mode to access vsireg, or from VS-mode to access
> sireg, should preferably raise an illegal instruction exception.
>
> Signed-off-by: Tommy Wu
>
On Wed, Jul 26, 2023 at 10:08 PM Andrew Jones wrote:
>
> Add instructions for how to cross-compile QEMU for RISC-V. The
> file is named generically because there's no reason not to collect
> other architectures steps into the same file, especially because
> several subsections like those for
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This hcall is used by L1 to indicate to L0 that a new nested guest needs
> to be created and therefore necessary resource allocation shall be made.
> The L0 uses a hash table for nested guest specific resource management.
> This data
>-Original Message-
>From: Jason Gunthorpe
>Sent: Thursday, September 7, 2023 9:11 AM
>To: Alex Williamson
>Subject: Re: [PATCH v1 21/22] vfio/pci: Allow the selection of a given iommu
>backend
>
>On Wed, Sep 06, 2023 at 01:09:26PM -0600, Alex Williamson wrote:
>> On Wed, 6 Sep 2023
On Wed, Jul 26, 2023 at 10:08 PM Andrew Jones wrote:
>
> Add instructions for how to cross-compile QEMU for RISC-V. The
> file is named generically because there's no reason not to collect
> other architectures steps into the same file, especially because
> several subsections like those for
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This patch implements nested PAPR hcall H_GUEST_SET_CAPABILITIES.
> This is used by L1 to set capabilities of the nested guest being
> created. The capabilities being set are subset of the capabilities
> returned from the previous
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This patch implements nested PAPR hcall H_GUEST_GET_CAPABILITIES and
> also enables registration of nested PAPR hcalls whenever an L0 is
> launched with cap-nested-papr=true. The common registration routine
> shall be used by future
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This patch introduces a new cmd line option cap-nested-papr to enable
> support for nested PAPR API by setting the nested.api version accordingly.
> It requires the user to launch the L0 Qemu in TCG mode and then L1 Linux
> can then
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This patch introduces a new cmd line option cap-nested-papr to enable
> support for nested PAPR API by setting the nested.api version accordingly.
> It requires the user to launch the L0 Qemu in TCG mode and then L1 Linux
> can then
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> With this patch, isolating kvm-hv nested api code to be executed only
> when cap-nested-hv is set. This helps keeping api specific logic
> mutually exclusive.
Changelog needs a bit of improvement. Emphasis on "why" for changelogs.
If
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> Use nested guest state specific struct for storing related info.
So this is the patch I would introduce the SpaprMachineStateNested
struct, with just the .ptrc member. Add other members to it as they
are used in later patches.
>
>
On Wed, Sep 06, 2023 at 01:09:26PM -0600, Alex Williamson wrote:
> On Wed, 6 Sep 2023 15:10:39 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Aug 30, 2023 at 06:37:53PM +0800, Zhenzhong Duan wrote:
> > > Note the /dev/iommu device may have been pre-opened by a
> > > management tool such as
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> This patch introduces new data structures to be used with Nested PAPR
> API. Also extends kvmppc_hv_guest_state with additional set of registers
> supported with nested PAPR API.
>
> Signed-off-by: Michael Neuling
> Signed-off-by:
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> Coroutine HMP commands currently run to completion in a nested event
> loop with the Big QEMU Lock (BQL) held. The call_rcu thread also uses
> the BQL and cannot process work while the coroutine monitor command is
> running. A deadlock occurs when
Set mc->valid_cpu_types so that the user specified CPU type can
be validated in machine_run_board_init(). We needn't to do it
by ourselves.
Signed-off-by: Gavin Shan
---
hw/riscv/shakti_c.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/hw/riscv/shakti_c.c
Set mc->valid_cpu_types so that the user specified CPU type can
be validated in machine_run_board_init(). We needn't to do it by
ourselves.
Signed-off-by: Gavin Shan
---
hw/arm/bananapi_m2u.c | 12 ++--
hw/arm/cubieboard.c | 12 ++--
hw/arm/mps2-tz.c| 20
The 'host' CPU model isn't available until KVM or HVF is enabled.
For example, the following error messages are seen when the guest
is started with option '-cpu cortex-a8' on tcg.
qemu-system-aarch64: Invalid CPU type: cortex-a8
The valid types are: cortex-a7, cortex-a15, cortex-a35,
The names of supported CPU models instead of CPU types should be
printed when the user specified CPU type isn't supported, to be
consistent with the output from '-cpu ?'.
Correct the error messages to print CPU model names instead of CPU
type names.
Signed-off-by: Gavin Shan
---
Set mc->valid_cpu_types so that the user specified CPU type can
be validated in machine_run_board_init(). We needn't to do it
by ourselves.
Signed-off-by: Gavin Shan
---
hw/arm/sbsa-ref.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git
Set mc->valid_cpu_types so that the user specified CPU type can be
validated in machine_run_board_init(). We needn't to do the check
by ourselves.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/hw/arm/virt.c
QEMU will be terminated if the specified CPU type isn't supported
in machine_run_board_init(). The list of supported CPU type names
is tracked by mc->valid_cpu_types.
The error handling can be used to propagate error messages, to be
consistent how the errors are handled for other situations in
The logic, to check if the specified CPU type is supported in
machine_run_board_init(), is independent enough. Factor it out
into helper is_cpu_type_supported(). With this, machine_run_board_init()
looks a bit clean. Since we're here, @machine_class is renamed to
@mc to avoid multiple line
Constify MachineClass::valid_cpu_types[i], as suggested by Richard
Henderson.
Suggested-by: Richard Henderson
Signed-off-by: Gavin Shan
---
hw/m68k/q800.c | 2 +-
include/hw/boards.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
Remove the false conditions and comments since cpu_list() has been
supported on all targets.
Signed-off-by: Gavin Shan
---
bsd-user/main.c | 3 ---
cpu.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/bsd-user/main.c b/bsd-user/main.c
index f913cb55a7..3a2d84f14b 100644
---
Implement nios2_cpu_list() to support cpu_list(). With this applied,
the available CPU model names, same to the CPU type names, are shown
as below.
$ ./build/qemu-system-nios2 -cpu ?
Available CPUs:
nios2-cpu
Signed-off-by: Gavin Shan
---
target/nios2/cpu.c | 20
Implement microblaze_cpu_list() to support cpu_list(). With this applied,
the available CPU model names, same to the CPU type names, are shown
as below.
$ ./build/qemu-system-hppa -cpu ?
Available CPUs:
microblaze-cpu
Signed-off-by: Gavin Shan
---
target/microblaze/cpu.c | 20
Implement hppa_cpu_list() to support cpu_list(). With this applied,
the available CPU model names, same to the CPU type names, are shown
as below.
$ ./build/qemu-system-hppa -cpu ?
Available CPUs:
hppa-cpu
Signed-off-by: Gavin Shan
---
target/hppa/cpu.c | 19 +++
Improve xtensa_cpu_class_by_name() by merging the condition of
'@oc == NULL' to object_class_dynamic_cast().
Signed-off-by: Gavin Shan
---
target/xtensa/cpu.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/target/xtensa/cpu.c b/target/xtensa/cpu.c
index
For target/tricore, the CPU type name is always the combination of the
CPU model name and suffix. The CPU model names have been correctly
shown in tricore_cpu_list_entry().
Use generic helper cpu_model_from_type() to show the CPU model names
in the above function. tricore_cpu_class_by_name() is
Improve sparc_cpu_class_by_name() by validating @oc, to ensure it's
child of TYPE_SPARC_CPU since it's possible for other types of classes
to have TYPE_SPARC_CPU as the suffix of their type names.
Signed-off-by: Gavin Shan
---
target/sparc/cpu.c | 7 ++-
1 file changed, 6 insertions(+), 1
For target/sh4, the CPU type name can be: (1) the combination of the
CPU model name and suffix; (2) TYPE_SH7750R_CPU when the CPU model
name is "any". The CPU model names have been correctly shown in
superh_cpu_list_entry().
Use generic helper cpu_model_from_type() to show the CPU model name
in
For target/s390x, the CPU type name is always the combination of the
CPU modle name and suffix. The CPU model names have been correctly
shown in s390_print_cpu_model_list_entry() and create_cpu_model_list().
Use generic helper cpu_model_from_type() to show the CPU model names
in the above two
For target/rx, the CPU type name can be: (1) the combination of the
CPU model name and suffix; (2) same to the CPU model name. The CPU
type names have been shown in rx_cpu_list_entry().
Use generic helper cpu_model_from_type() to show the CPU model names
in rx_cpu_list_entry(). Besides,
For target/riscv, the CPU type name is always the combination of the
CPU model name and suffix. The CPU model names have been correctly
shown in riscv_cpu_list_entry() and riscv_cpu_add_definition()
Use generic helper cpu_mdoel_from_type() to show the CPU model names
in the above two functions,
For target/ppc, the CPU type name can be: (1) The combination of
the CPU model name and suffix; (2) the type name of the class whose
PVR matches with the specified one; (3) alias of the CPU model, plus
suffix; (4) MachineClass::default_cpu_type when the CPU model name
is "max". All the possible
For target/openrisc, the CPU type name is always the combination of
the CPU model name and suffix. The CPU model names have been correctly
shown in openrisc_cpu_list_entry().
Use generic helper cpu_model_from_type() to show the CPU model names
in openrisc_cpu_list_entry(), and @name is renamed to
For target/mips, the CPU type name is always the combination of the
CPU model name and suffix. The CPU model names have been shown
correctly in mips_cpu_list(), which fetches the CPU model names from
the pre-defined array. It's different from other targets and lack
of flexibility.
Implement
For target/m68k, the CPU type name is always the combination of the
CPU model name and suffix. The CPU model names have been shown
correctly in m68k_cpu_list_entry().
Use generic helper cpu_model_from_type() to show the CPU model name
in m68k_cpu_list_entry(), rename @name to @model since it's
For target/loongarch, the CPU type name can be: (1) the combination of
the CPU model name and suffix; (2) same to the CPU model name. The CPU
model names have been shown correctly in loongarch_cpu_list_entry()
and loongarch_cpu_add_definition() by following (1).
Use generic helper
For target/i386, the CPU type name is always the combination of the
CPU model name and suffix. The CPU model names have been shown
correctly in x86_cpu_list_entry().
Use generic helper cpu_model_from_type() to get the CPU model name
from the CPU type name in x86_cpu_class_get_model_name(), and
For target/hexagon, the CPU type name is always the combination of
the CPU model name and suffix. The CPU model names have been shown
correctly in hexagon_cpu_list_entry().
Use generic helper cpu_model_from_type() to show the CPU model names
in hexagon_cpu_list_entry(), and rename @name to @model
For target/alpha, the CPU type name can be: (1) the combination of
the CPU model name and suffix; (2) same to the CPU model name; (3)
pre-defined aliases. It's correct to show the CPU model name for (1)
or the CPU type name for (2) in cpu_list() because both of them can
be resolved by
For target/arm, the CPU type name can be: (1) the combination of
the CPU model name and suffix; (2) alias "any" corresponding to
"max-arm-cpu" when CONFIG_USER_ONLY is enabled. The CPU model names
have been already shown in cpu_list() and query_cpu_definitions()
by following (1).
Use generic
For target/avr, the CPU model name is resolved as same to the CPU
type name in avr_cpu_class_by_name(). Actually, the CPU model name
is the combination of the CPU model name and suffix.
Support the resolution from the combination of CPU model name and
suffix to the CPU type name in
For target/cris, the CPU type name can be: (1) the combination of
the CPU model name and suffix; (2) alias "any" corresponding to
"crisv32-cris-cpu". The CPU model names have been shown correctly
by following (1).
Use generic helper cpu_model_from_type() to show the CPU model
names in
There are two places where the user specified CPU type is checked to see
if it's supported or allowed by the board: machine_run_board_init() and
mc->init(). We don't have to maintain two duplicate sets of logic. This
series intends to move the check to machine_run_board_init().
PATCH[01]Adds
Add helper cpu_model_from_type() to extract the CPU model name from
the CPU type name in two circumstances: (1) The CPU type name is the
combination of the CPU model name and suffix. (2) The CPU type name
is same to the CPU model name.
The helper will be used in the subsequent patches to conver
For multi-headed type 3 devices, this command reports logical device
mappings for each head. Implement a callback which can be
initialized by MHD devices to field these commands.
Reports "unsupported" if the command is called but the callback is
not implemented.
Signed-off-by: Gregory Price
On Wed Sep 6, 2023 at 2:33 PM AEST, Harsh Prateek Bora wrote:
> Adding new macros for the new hypercall op-codes, their return codes,
> Guest State Buffer (GSB) element IDs and few registers which shall be
> used in following patches to support Nested PAPR API.
>
> Signed-off-by: Michael Neuling
When memory accesses are made, some MHSLD's would validate the address
is within the scope of allocated sections. To do this, the base device
must call an optional function set by inherited devices.
Signed-off-by: Gregory Price
---
hw/mem/cxl_type3.c | 15 +++
Create a new device to emulate the SK hynix Niagara MHSLD platform.
This device has custom CCI commands that allow for applying isolation
to each memory block between hosts. This enables an early form of
dynamic capacity, whereby the NUMA node maps the entire region, but
the host is responsible
For devices built on top of ct3, we need the init, realize, and
exit functions exposed to correctly start up and tear down.
Signed-off-by: Gregory Price
---
hw/mem/cxl_type3.c | 6 +++---
include/hw/cxl/cxl_device.h | 4
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git
Preparation for allowing devices to define their own CCI commands
Signed-off-by: Gregory Price
---
hw/cxl/cxl-mailbox-utils.c | 30 +-
include/hw/cxl/cxl_mailbox.h | 18 ++
2 files changed, 31 insertions(+), 17 deletions(-)
create mode 100644
Call CXL_TYPE3 once at top of function to avoid multiple invocations.
Signed-off-by: Gregory Price
---
hw/mem/cxl_type3.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
index fd9d134d46..80d596ee10 100644
---
v3:
- 6 patch series, first 5 are pull-aheads that can be merged separately
- cci: added MHD back into main mailbox, but implemented a callback
pattern. type-3 devices leave the callback null by default and
report unsupported if nothing implements it.
- cleanup and formatting
v2:
-
On 9/6/23 17:16, Peter Xu wrote:
Just a note..
Probably fine for now to reuse block page size, but IIUC the right thing to
do is to fetch it from the signal info (in QEMU's sigbus_handler()) of
kernel_siginfo.si_addr_lsb.
At least for x86 I think that stores the "shift" of covered poisoned
In the event that a guest process attempts to access memory that has
been poisoned in response to a deferred uncorrected MCE, an AMD system
will currently generate a SIGBUS error which will result in the entire
guest being shutdown. Ideally, we only want to kill the guest process
that accessed
For the most part, AMD hosts can use the same MCE injection code as Intel but,
there are instances where the qemu implementation is Intel specific. First, MCE
deliviery works differently on AMD and does not support broadcast. Second,
kvm_mce_inject generates MCEs that include a number of Intel
From: William Roche
AMD guests can't currently deal with BUS_MCEERR_AO MCE injection
as it panics the VM kernel. We filter this event and provide a
warning message.
Signed-off-by: William Roche
---
v3:
- New patch
---
target/i386/kvm/kvm.c | 13 ++---
1 file changed, 10
Add cpuid bit definition for the SUCCOR feature. This cpuid bit is required to
be exposed to guests to allow them to handle machine check exceptions on AMD
hosts.
Reported-by: William Roche
Reviewed-by: Joao Martins
Signed-off-by: John Allen
v2:
- Add "succor" feature word.
- Add case
Hi,
I noticed why the chardev socket backend disconnects, and I would like to
make this a RFC to see how I should fix it.
Current scenario after boot-up:
1. tcp_chr_read_poll keeps polling the slirp_socket_can_recv, and
slirp_socket_can_recv returns 0 since slirp_find_ctl_socket couldn't
For both save/load we actually share the logic on deciding whether a field
should exist. Merge the checks into a helper and use it for both save and
load. When doing so, add documentations and reformat the code to make it
much easier to read.
The real benefit here (besides code cleanups) is we
On Mon, Aug 28, 2023 at 11:09:52PM +0800, Sam Li wrote:
> Add the specs for the zoned format feature of the qcow2 driver.
> The qcow2 file can be taken as zoned device and passed through by
> virtio-blk device or NVMe ZNS device to the guest given zoned
> information.
>
> Signed-off-by: Sam Li
>
Hi John,
On 9/5/2023 10:01 AM, John Allen wrote:
On Fri, Sep 01, 2023 at 11:30:53AM +0100, Joao Martins wrote:
On 26/07/2023 21:41, John Allen wrote:
Add cpuid bit definition for the SUCCOR feature. This cpuid bit is required to
be exposed to guests to allow them to handle machine check
On Wed, 6 Sep 2023 15:10:39 -0300
Jason Gunthorpe wrote:
> On Wed, Aug 30, 2023 at 06:37:53PM +0800, Zhenzhong Duan wrote:
> > Note the /dev/iommu device may have been pre-opened by a
> > management tool such as libvirt. This mode is no more considered
> > for the legacy backend. So let's remove
Coroutine HMP commands currently run to completion in a nested event
loop with the Big QEMU Lock (BQL) held. The call_rcu thread also uses
the BQL and cannot process work while the coroutine monitor command is
running. A deadlock occurs when monitor commands attempt to wait for
call_rcu work to
call_drain_rcu() has limitations that make it unsuitable for use in
qmp_device_add(). Introduce a new coroutine version of drain_call_rcu()
with the same functionality but that does not drop the BQL. The next
patch will use it to fix qmp_device_add().
Signed-off-by: Stefan Hajnoczi
---
It is not safe to call drain_call_rcu() from qmp_device_add() because
some call stacks are not prepared for drain_call_rcu() to drop the Big
QEMU Lock (BQL).
For example, device emulation code is protected by the BQL but when it
calls aio_poll() -> ... -> qmp_device_add() -> drain_call_rcu() then
It is not safe to call drain_call_rcu() from qmp_device_add() because
some call stacks are not prepared for drain_call_rcu() to drop the Big
QEMU Lock (BQL).
For example, device emulation code is protected by the BQL but when it
calls aio_poll() -> ... -> qmp_device_add() -> drain_call_rcu() then
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any
user-visible changes.
signature.asc
Description: PGP signature
On Wed, Aug 30, 2023 at 06:37:53PM +0800, Zhenzhong Duan wrote:
> Note the /dev/iommu device may have been pre-opened by a
> management tool such as libvirt. This mode is no more considered
> for the legacy backend. So let's remove the "TODO" comment.
Can you show an example of that syntax too?
1 - 100 of 286 matches
Mail list logo
