There is a generic CPU type invalidation in machine_run_board_init()
and we needn't a same and private invalidation for hw/arm/virt machines.
This series intends to use the generic CPU type invalidation on the
hw/arm/virt machines.
PATCH[1] factors the CPU type invalidation logic in
There is a generic CPU type invalidation in machine_run_board_init()
and we needn't a same and private invalidation. Set mc->valid_cpu_types
to use the generic CPU type invalidation.
No functional change intended.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 21 +++--
1 file
The CPU type invalidation logic in machine_run_board_init() is
independent enough. Lets factor it out into helper validate_cpu_type().
Since we're here, the relevant comments are improved a bit.
No functional change intended.
Signed-off-by: Gavin Shan
---
hw/core/machine.c | 81
The CPU type 'host-arm-cpu' class won't be registered until KVM or
HVF is configured in target/arm/cpu64.c. Support the corresponding
CPU type only when KVM or HVF is configured.
Signed-off-by: Gavin Shan
---
hw/arm/virt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/arm/virt.c
On 7/11/2023 10:52 PM, Markus Armbruster wrote:
"Kim, Dongwon" writes:
On 7/10/2023 11:36 PM, Markus Armbruster wrote:
"Kim, Dongwon" writes:
On 7/9/2023 11:05 PM, Markus Armbruster wrote:
"Kim, Dongwon" writes:
On 7/7/2023 7:07 AM, Markus Armbruster wrote:
[...]
Old question not
Replace 'width' and 'height' in QemuDmaBuf with 'backing_widht'
and 'backing_height' as these commonly indicate the size of the
whole surface (e.g. guest's Xorg extended display). Then use
'width' and 'height' for sub region in there (e.g. guest's
scanouts).
Cc: Gerd Hoffmann
Cc: Marc-André
In preparation for the SysBus variant, we move common code styled
after the TPM TIS devices.
To maintain compatibility, we do not rename the existing tpm-crb
device.
Signed-off-by: Joelle van Dyne
---
docs/specs/tpm.rst | 1 +
hw/tpm/tpm_crb.h| 76 +++
hw/tpm/tpm_crb.c
This SysBus variant of the CRB interface supports dynamically locating
the MMIO interface so that Virt machines can use it. This interface
is currently the only one supported by QEMU that works on Windows 11
ARM64. We largely follow the TPM TIS SysBus device as a template.
Signed-off-by: Joelle
TPM needs to know its own base address in order to generate its DSDT
device entry.
Signed-off-by: Joelle van Dyne
---
hw/arm/virt.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 7d9dbc2663..432148ef47 100644
---
This reduces redundent code in different machine types with ACPI table
generation. Additionally, this will allow us to support multiple TPM
interfaces. Finally, this matches up with the TPM TIS ISA
implementation.
Ideally, we would be able to call `qbus_build_aml` and avoid any TPM
specific code
On Apple Silicon, when Windows performs a LDP on the CRB MMIO space,
the exception is not decoded by hardware and we cannot trap the MMIO
read. This led to the idea from @agraf to use the same mapping type as
ROM devices: namely that reads should be seen as memory type and
writes should trap as
Instead of calling `memory_region_add_subregion` directly, we defer to
the caller to do it. This allows us to re-use the code for a SysBus
device.
Signed-off-by: Joelle van Dyne
---
hw/tpm/tpm_ppi.h| 10 +++---
hw/tpm/tpm_crb.c| 4 ++--
hw/tpm/tpm_crb_common.c | 3 +++
TPM needs to know its own base address in order to generate its DSDT
device entry.
Signed-off-by: Joelle van Dyne
---
hw/loongarch/virt.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index
This logic is similar to TPM TIS ISA device.
Signed-off-by: Joelle van Dyne
---
hw/i386/acpi-build.c | 23 ---
hw/tpm/tpm_crb.c | 28
2 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
The register is actually 64-bits but in order to make this more clear
than the specification, we define two 32-bit registers:
CTRL_RSP_LADDR and CTRL_RSP_HADDR to match the CTRL_CMD_* naming. This
deviates from the specs but is way more clear.
Previously, the only CRB device uses a fixed system
Since this device is gated to only build for targets with the PC
configuration, we should use the ISA bus like with TPM TIS.
Signed-off-by: Joelle van Dyne
---
hw/tpm/tpm_crb.c | 52
hw/tpm/Kconfig | 2 +-
2 files changed, 27 insertions(+), 27
If 'ppi' property is set, then `tpm_ppi_reset` is called on reset
which SEGFAULTs because `tpmppi->buf` is not allocated.
Signed-off-by: Joelle van Dyne
---
hw/tpm/tpm_tis_sysbus.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/tpm/tpm_tis_sysbus.c b/hw/tpm/tpm_tis_sysbus.c
index
The impetus for this patch set is to get TPM 2.0 working on Windows 11 ARM64.
Windows' tpm.sys does not seem to work on a TPM TIS device (as verified with
VMWare's implementation). However, the current TPM CRB device uses a fixed
system bus address that is reserved for RAM in ARM64 Virt machines.
On 7/10/2023 4:57 AM, Marc-André Lureau wrote:
Hi
On Thu, Jul 6, 2023 at 3:10 AM Dongwon Kim wrote:
'backing_width' and 'backing_height' are commonly used to indicate
the size
of the whole backing region so it makes sense to use those terms for
VGAUDMABuf as well in place of
On Wed, Jul 12, 2023 at 12:15 PM Marc-André Lureau
wrote:
>
> Hi
>
> On Tue, Jul 11, 2023 at 6:57 AM Gurchetan Singh
> wrote:
>>
>> This adds initial support for gfxstream and cross-domain. Both
>> features rely on virtio-gpu blob resources and context types, which
>> are also implemented in
On Wed, Jul 12, 2023 at 2:40 PM Akihiko Odaki wrote:
>
> On 2023/07/11 11:56, Gurchetan Singh wrote:
> > This adds basic documentation for virtio-gpu.
>
> Thank you for adding documentation for other backends too. I have been
> asked how virtio-gpu works so many times and always had to explain by
Hi Salil,
On 7/4/23 19:58, Salil Mehta wrote:
Latest Qemu Prototype (Pre RFC V2) (Not in the final shape of the patches)
https://github.com/salil-mehta/qemu.git
virt-cpuhp-armv8/rfc-v1-port11052023.dev-1
should work against below kernel changes as confirmed by James,
Latest Kernel
On 2023/07/12 19:48, Philippe Mathieu-Daudé wrote:
Hi Cédric,
On 12/7/23 10:01, Cédric Le Goater wrote:
It is useful to extend the number of available PCIe devices to KVM guests
for passthrough scenarios and also to expose these models to a different
(big endian) architecture. Introduce a new
On Wed, Jul 12, 2023 at 06:39:28PM -0300, Daniel Henrique Barboza wrote:
> On 7/12/23 18:35, Conor Dooley wrote:
> > On Wed, Jul 12, 2023 at 06:09:10PM -0300, Daniel Henrique Barboza wrote:
> >
> > > It is intentional. Those default marchid/mimpid vals were derived from
> > > the current
> > >
On 2023/07/11 11:56, Gurchetan Singh wrote:
This adds basic documentation for virtio-gpu.
Thank you for adding documentation for other backends too. I have been
asked how virtio-gpu works so many times and always had to explain by
myself though Gerd does have a nice article.* This
On 7/12/23 18:35, Conor Dooley wrote:
On Wed, Jul 12, 2023 at 06:09:10PM -0300, Daniel Henrique Barboza wrote:
It is intentional. Those default marchid/mimpid vals were derived from the
current
QEMU version ID/build and didn't mean much.
It is still possible to set them via "-cpu
On Wed, Jul 12, 2023 at 06:09:10PM -0300, Daniel Henrique Barboza wrote:
> It is intentional. Those default marchid/mimpid vals were derived from the
> current
> QEMU version ID/build and didn't mean much.
>
> It is still possible to set them via "-cpu rv64,marchid=N,mimpid=N" if needed
> when
On 7/12/23 18:00, Conor Dooley wrote:
On Wed, Jul 12, 2023 at 05:30:41PM -0300, Daniel Henrique Barboza wrote:
On 7/12/23 16:22, Conor Dooley wrote:
On Wed, Jul 12, 2023 at 04:01:48PM -0300, Daniel Henrique Barboza wrote:
The 'max' CPU type is used by tooling to determine what's the most
On Wed, Jul 12, 2023 at 05:30:41PM -0300, Daniel Henrique Barboza wrote:
> On 7/12/23 16:22, Conor Dooley wrote:
> > On Wed, Jul 12, 2023 at 04:01:48PM -0300, Daniel Henrique Barboza wrote:
> > > The 'max' CPU type is used by tooling to determine what's the most
> > > capable CPU a current QEMU
Create a new riscv_cpu_experimental_exts[] to store the non-ratified
extensions properties. Once they are ratified we'll move them back to
riscv_cpu_extensions[].
Change riscv_cpu_add_user_properties to keep adding them to users.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c |
Add smoke tests to ensure that we'll not break the 'max' CPU type when
adding new ratified extensions to be enabled.
Signed-off-by: Daniel Henrique Barboza
---
tests/avocado/riscv_opensbi.py | 16
1 file changed, 16 insertions(+)
diff --git a/tests/avocado/riscv_opensbi.py
Hi,
This second version has smalls tweak in patch 6 that I found out
missing while chatting with Conor in the v1 review.
Changes from v1:
- patch 6:
- enable RVG, RVJ and RVV in riscv_init_max_cpu_extensions()
- Added the resulting 'riscv,isa' DT in the commit message
- v1 link:
The code inside riscv_cpu_add_user_properties() became quite repetitive
after recent changes. Add a macro to hide the repetition away.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git
The 'max' CPU type is used by tooling to determine what's the most
capable CPU a current QEMU version implements. Other archs such as ARM
implements this type. Let's add it to RISC-V.
What we consider "most capable CPU" in this context are related to
ratified, non-vendor extensions. This means
We'll add a new CPU type that will enable a considerable amount of
extensions. To make it easier for us we'll do a few cleanups in our
existing riscv_cpu_extensions[] array.
Start by splitting all CPU non-boolean options from it. Create a new
riscv_cpu_options[] array for them. Add all these
Our goal is to make riscv_cpu_extensions[] hold only ratified,
non-vendor extensions.
Create a new riscv_cpu_vendor_exts[] array for them, changing
riscv_cpu_add_user_properties() accordingly.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 34 --
After the introduction of riscv_cpu_options[] all properties in
riscv_cpu_extensions[] are booleans. This check is now obsolete.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/target/riscv/cpu.c
On 7/8/23 23:36, Helge Deller wrote:
On 7/8/23 19:26, Richard Henderson wrote:
On 7/6/23 12:34, Andreas Schwab wrote:
Fixes: 86f04735ac ("linux-user: Fix brk() to release pages")
Signed-off-by: Andreas Schwab
---
linux-user/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 7/12/23 16:22, Conor Dooley wrote:
On Wed, Jul 12, 2023 at 04:01:48PM -0300, Daniel Henrique Barboza wrote:
The 'max' CPU type is used by tooling to determine what's the most
capable CPU a current QEMU version implements. Other archs such as ARM
implements this type. Let's add it to
On 7/12/23 13:39, Sunil V L wrote:
Some macros and static function related to IMSIC are defined
in virt.c. They are required in virt-acpi-build.c. So, make them
public.
Signed-off-by: Sunil V L
---
Reviewed-by: Daniel Henrique Barboza
hw/riscv/virt.c | 25
On 7/12/23 13:39, Sunil V L wrote:
The PCI bus information is needed in RISCVVirtState so that other
files like virt-acpi-build.c can make use of it. Add new field in
RISCVVirtState so that ACPI code can use it.
Signed-off-by: Sunil V L
---
hw/riscv/virt.c | 6 --
On 12/07/2023 16.24, Pierre Morel wrote:
On 7/4/23 13:40, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
On interception of STSI(15.1.x) the System Information Block
(SYSIB) is built from the list of pre-ordered topology entries.
Signed-off-by: Pierre Morel
---
...
diff --git
On 12/07/2023 21.37, Nina Schoetterl-Glausch wrote:
On Wed, 2023-07-05 at 12:22 +0200, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
This test takes care to check the changes on different entitlements
when the guest requests a polarization change.
Signed-off-by: Pierre Morel
On Fri, 2023-06-30 at 11:17 +0200, Pierre Morel wrote:
> Introduction of the s390x cpu topology core functions and
> basic tests.
>
> We test the corelation between the command line and
corRelation
> the QMP results in query-cpus-fast for various CPU topology.
>
> Signed-off-by: Pierre Morel
On Wed, 2023-07-05 at 12:22 +0200, Thomas Huth wrote:
> On 30/06/2023 11.17, Pierre Morel wrote:
> > This test takes care to check the changes on different entitlements
> > when the guest requests a polarization change.
> >
> > Signed-off-by: Pierre Morel
> > ---
> >
The main loop thread can consume 100% CPU when using --device
virtio-blk-pci,iothread=. ppoll() constantly returns but
reading virtqueue host notifiers fails with EAGAIN. The file descriptors
are stale and remain registered with the AioContext because of bugs in
the virtio-blk dataplane start/stop
The following changes since commit 887cba855bb6ff4775256f7968409281350b568c:
configure: Fix cross-building for RISCV host (v5) (2023-07-11 17:56:09 +0100)
are available in the Git repository at:
https://gitlab.com/stefanha/qemu.git tags/block-pull-request
for you to fetch changes up to
On Wed, 12 Jul 2023 at 10:51, Hanna Czenczek wrote:
>
> On 12.07.23 16:15, Stefan Hajnoczi wrote:
> > On Wed, Jul 12, 2023 at 09:41:05AM +0200, Hanna Czenczek wrote:
> >> On 11.07.23 22:23, Stefan Hajnoczi wrote:
> >>> On Fri, Jun 09, 2023 at 10:33:16AM +0200, Hanna Czenczek wrote:
>
On Wed, Jul 12, 2023 at 04:01:48PM -0300, Daniel Henrique Barboza wrote:
> The 'max' CPU type is used by tooling to determine what's the most
> capable CPU a current QEMU version implements. Other archs such as ARM
> implements this type. Let's add it to RISC-V.
>
> What we consider "most capable
On Tue, Jul 04, 2023 at 05:15:27PM +0200, Stefan Hajnoczi wrote:
> The main loop thread can consume 100% CPU when using --device
> virtio-blk-pci,iothread=. ppoll() constantly returns but
> reading virtqueue host notifiers fails with EAGAIN. The file descriptors
> are stale and remain registered
blk_io_plug_call() is invoked outside a blk_io_plug()/blk_io_unplug()
section while opening the NVMe drive from:
nvme_file_open() ->
nvme_init() ->
nvme_identify() ->
nvme_admin_cmd_sync() ->
nvme_submit_command() ->
blk_io_plug_call()
blk_io_plug_call() immediately invokes the given
On Fri, Jul 07, 2023 at 04:25:22PM +0200, Paolo Bonzini wrote:
> On 7/6/23 21:40, John Allen wrote:
> > case 0x8007:
> > *eax = 0;
> > -*ebx = 0;
> > +*ebx = env->features[FEAT_8000_0007_EBX] |
> > CPUID_8000_0007_EBX_SUCCOR;
> > *ecx = 0;
> >
Hi
On Tue, Jul 11, 2023 at 6:57 AM Gurchetan Singh
wrote:
> This adds initial support for gfxstream and cross-domain. Both
> features rely on virtio-gpu blob resources and context types, which
> are also implemented in this patch.
>
> gfxstream has a long and illustrious history in Android
The following patch will make use of this function from within
migrate-helpers.c, so move it there.
Reviewed-by: Juan Quintela
Reviewed-by: Thomas Huth
Reviewed-by: Peter Xu
Signed-off-by: Fabiano Rosas
---
tests/qtest/migration-helpers.c | 11 +++
tests/qtest/migration-helpers.h |
Based-on:
[PATCH V4 0/2] migration file URI
https://lore.kernel.org/r/1688135108-316997-1-git-send-email-steven.sist...@oracle.com
Since v4:
- Implemented a separate version of test_precopy_common to be used
with the file transport (patch 6).
v4:
Add basic tests for file-based migration.
Note that we cannot use test_precopy_common because that routine
expects it to be possible to run the migration live. With the file
transport there is no live migration because we must wait for the
source to finish writing the migration data to the file
We are sending a migration event of MIGRATION_STATUS_SETUP at
qemu_start_incoming_migration but never actually setting the state.
This creates a window between qmp_migrate_incoming and
process_incoming_migration_co where the migration status is still
MIGRATION_STATUS_NONE. Calling query-migrate
file-based migration requires the target to initiate its migration after
the source has finished writing out the data in the file. Currently
there's no easy way to initiate 'migrate-incoming', allow this by
introducing migrate_incoming_qmp helper, similarly to migrate_qmp.
Also make sure
There is currently no way to write a test for errors that happened in
qmp_migrate before the migration has started.
Add a version of qmp_migrate that ensures an error happens. To make
use of it a test needs to set MigrateCommon.result as
MIG_TEST_QMP_ERROR.
Reviewed-by: Peter Xu
Signed-off-by:
On 7/12/23 13:39, Sunil V L wrote:
The functions which add fw_cfg and virtio to DSDT are same for ARM
and RISC-V. So, instead of duplicating in RISC-V, move them from
hw/arm/virt-acpi-build.c to common aml-build.c.
Nice.
Signed-off-by: Sunil V L
---
Reviewed-by: Daniel Henrique
Use the new migrate_incoming_qmp helper in the places that currently
open-code calling migrate-incoming.
Reviewed-by: Juan Quintela
Reviewed-by: Peter Xu
Signed-off-by: Fabiano Rosas
---
tests/qtest/meson.build | 1 +
tests/qtest/migration-test.c | 12 ++---
The 'max' CPU type is used by tooling to determine what's the most
capable CPU a current QEMU version implements. Other archs such as ARM
implements this type. Let's add it to RISC-V.
What we consider "most capable CPU" in this context are related to
ratified, non-vendor extensions. This means
Add smoke tests to ensure that we'll not break the 'max' CPU type when
adding new ratified extensions to be enabled.
Signed-off-by: Daniel Henrique Barboza
---
tests/avocado/riscv_opensbi.py | 16
1 file changed, 16 insertions(+)
diff --git a/tests/avocado/riscv_opensbi.py
After the introduction of riscv_cpu_options[] all properties in
riscv_cpu_extensions[] are booleans. This check is now obsolete.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/target/riscv/cpu.c
Our goal is to make riscv_cpu_extensions[] hold only ratified,
non-vendor extensions.
Create a new riscv_cpu_vendor_exts[] array for them, changing
riscv_cpu_add_user_properties() accordingly.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 34 --
Create a new riscv_cpu_experimental_exts[] to store the non-ratified
extensions properties. Once they are ratified we'll move them back to
riscv_cpu_extensions[].
Change riscv_cpu_add_user_properties to keep adding them to users.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c |
Hi,
Following the discussions made in [1] I decided to go ahead and implement
the 'max' CPU type.
It's a CPU that has (almost) all ratified non-vendor extensions enabled
by default. Tooling such as libvirt uses this kind of CPU to do capabilities
discovery. It's also used for testing purposes.
The code inside riscv_cpu_add_user_properties() became quite repetitive
after recent changes. Add a macro to hide the repetition away.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git
We'll add a new CPU type that will enable a considerable amount of
extensions. To make it easier for us we'll do a few cleanups in our
existing riscv_cpu_extensions[] array.
Start by splitting all CPU non-boolean options from it. Create a new
riscv_cpu_options[] array for them. Add all these
On Wed, Jul 12, 2023 at 5:07 AM Philippe Mathieu-Daudé
wrote:
> On 11/7/23 21:39, Warner Losh wrote:
> > On Tue, Jul 11, 2023 at 8:49 AM Philippe Mathieu-Daudé
> > mailto:phi...@linaro.org>> wrote:
> >
> > Add the generate_pkglist() helper to generate a list of packages
> > required by a
On 7/12/23 11:56 AM, Cédric Le Goater wrote:
> Hello Shawn,
>
> On 7/12/23 18:13, Shawn Anastasio wrote:
>> Change radix model to always generate a storage interrupt when the R/C
>> bits are not set appropriately in a PTE instead of setting the bits
>> itself. According to the ISA both behaviors
diff --git a/hw/s390x/Kconfig b/hw/s390x/Kconfig
index 454e0ff4b613..4c068d7960b9 100644
--- a/hw/s390x/Kconfig
+++ b/hw/s390x/Kconfig
@@ -5,7 +5,8 @@ config S390_CCW_VIRTIO
imply VFIO_AP
imply VFIO_CCW
imply WDT_DIAG288
- select PCI
+ imply PCIE_DEVICES
+ select
Hello Shawn,
On 7/12/23 18:13, Shawn Anastasio wrote:
Change radix model to always generate a storage interrupt when the R/C
bits are not set appropriately in a PTE instead of setting the bits
itself. According to the ISA both behaviors are valid, but in practice
this change more closely
The TLS handshake make take some time to complete, during which time an
I/O watch might be registered with the main loop. If the owner of the
I/O channel invokes qio_channel_close() while the handshake is waiting
to continue the I/O watch must be removed. Failing to remove it will
later trigger
The PCI bus information is needed in RISCVVirtState so that other
files like virt-acpi-build.c can make use of it. Add new field in
RISCVVirtState so that ACPI code can use it.
Signed-off-by: Sunil V L
---
hw/riscv/virt.c | 6 --
include/hw/riscv/virt.h | 1 +
2 files changed, 5
Some macros and static function related to IMSIC are defined
in virt.c. They are required in virt-acpi-build.c. So, make them
public.
Signed-off-by: Sunil V L
---
hw/riscv/virt.c | 25 +
include/hw/riscv/virt.h | 25 +
2 files changed, 26
Update the RINTC structure in MADT with AIA related fields.
Signed-off-by: Sunil V L
---
hw/riscv/virt-acpi-build.c | 66 +++---
1 file changed, 62 insertions(+), 4 deletions(-)
diff --git a/hw/riscv/virt-acpi-build.c b/hw/riscv/virt-acpi-build.c
index
Add APLIC structures for each socket in the MADT when
system is configured with APLIC as the external wired
interrupt controller.
Signed-off-by: Sunil V L
---
hw/riscv/virt-acpi-build.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git
MMU type information is available via MMU node in RHCT.
Add this node in RHCT.
Signed-off-by: Sunil V L
---
hw/riscv/virt-acpi-build.c | 36
1 file changed, 36 insertions(+)
diff --git a/hw/riscv/virt-acpi-build.c b/hw/riscv/virt-acpi-build.c
index
Add basic IO controllers and devices like PCI, VirtIO and UART
in the ACPI namespace.
Signed-off-by: Sunil V L
---
hw/riscv/Kconfig | 1 +
hw/riscv/virt-acpi-build.c | 87 ++
2 files changed, 88 insertions(+)
diff --git a/hw/riscv/Kconfig
Add IMSIC structure in MADT when IMSIC is configured.
Signed-off-by: Sunil V L
---
hw/riscv/virt-acpi-build.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/hw/riscv/virt-acpi-build.c b/hw/riscv/virt-acpi-build.c
index 12b8ef0352..ebdc3bffea 100644
---
The functions which add fw_cfg and virtio to DSDT are same for ARM
and RISC-V. So, instead of duplicating in RISC-V, move them from
hw/arm/virt-acpi-build.c to common aml-build.c.
Signed-off-by: Sunil V L
---
hw/acpi/aml-build.c | 41
When CMO related extensions like Zicboz, Zicbom and Zicbop
are enabled, the block size for those extensions need to be
communicated via CMO node in RHCT. Add CMO node in RHCT if
any of those CMO extensions are detected.
Signed-off-by: Sunil V L
---
hw/riscv/virt-acpi-build.c | 64
PCIe High MMIO base is actually dynamic and fixed at
run time based on the RAM configured. Currently, this is
not part of the memmap and kept in separate static variable
in virt.c. However, ACPI code also needs this information
to populate DSDT. So, once the base is discovered, merge
this into the
This series primarily enables AIA interrupt controllers in
ACPI tables for RISC-V virt platform. It also updates RHCT
with CMO and MMU related information.
Below ECRs for these changes are approved by ASWG and will be
available in next ACPI spec release.
1) MADT (AIA) -
On 7/12/23 15:43, Stefano Garzarella wrote:
Commit 1880ad4f4e ("virtio-scsi: Batched prepare for cmd reqs") split
calls to scsi_req_new() and scsi_req_enqueue() in the virtio-scsi device.
This had no drawback, until commit 8cc5583abe ("virtio-scsi: Send
More precisely, it was pretty hard to
On 7/5/23 10:41, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
Add some basic examples for the definition of cpu topology
in s390x.
Signed-off-by: Pierre Morel
---
MAINTAINERS | 2 +
docs/devel/index-internals.rst | 1 +
Change radix model to always generate a storage interrupt when the R/C
bits are not set appropriately in a PTE instead of setting the bits
itself. According to the ISA both behaviors are valid, but in practice
this change more closely matches behavior observed on the POWER9 CPU.
>From the POWER9
On 7/5/23 09:58, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
The query-cpu-polarization qmp command returns the current
CPU polarization of the machine.
Signed-off-by: Pierre Morel
---
qapi/machine-target.json | 29 +
hw/s390x/cpu-topology.c |
On 7/4/23 15:04, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
When the guest asks to change the polarization this change
is forwarded to the upper layer using QAPI.
The upper layer is supposed to take according decisions concerning
CPU provisioning.
Signed-off-by: Pierre Morel
On 7/12/23 09:17, David Hildenbrand wrote:
The following changes since commit 887cba855bb6ff4775256f7968409281350b568c:
configure: Fix cross-building for RISCV host (v5) (2023-07-11 17:56:09 +0100)
are available in the Git repository at:
https://github.com/davidhildenbrand/qemu.git
On 7/4/23 14:59, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
S390 topology adds books and drawers topology containers.
Let's add these to the HMP information for hotpluggable cpus.
Signed-off-by: Pierre Morel
Reviewed-by: Nina Schoetterl-Glausch
---
On 7/4/23 14:55, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
S390x provides two more topology attributes, entitlement and dedication.
Let's add these CPU attributes to the QAPI command query-cpu-fast.
Signed-off-by: Pierre Morel
---
qapi/machine.json | 9 -
Hi Cédric,
On 7/12/23 3:27 AM, Cédric Le Goater wrote:
> Hello Shawn,
>
> On 7/12/23 00:24, Shawn Anastasio wrote:
>> Change radix64_set_rc to always generate a storage interrupt when the
>> R/C bits are not set appropriately instead of setting the bits itself.
>> According to the ISA both
On Wed, Jul 12, 2023 at 2:57 PM Thomas Huth wrote:
> I think the patch is fine for now, but in the long run, I think we should
> make sure to mark PCIe-only devices only with PCIE_DEVICES, as Philippe
> suggested. So PCIe devices will then also not show up any more on targets
> that only provide
Phil,
This patch breaks the build for me. Applied on top of master:
FAILED: libqemu-riscv64-linux-user.fa.p/target_riscv_cpu.c.o
cc -m64 -mcx16 -Ilibqemu-riscv64-linux-user.fa.p -I. -I.. -Itarget/riscv -I../target/riscv
-I../common-user/host/x86_64 -I../linux-user/include/host/x86_64
On Wed, 12 Jul 2023 at 15:50, Hanna Czenczek wrote:
> There was and is no fix for the Coverity warning. I have mentioned that
> warning because the question as to why the code uses
> bdrv_check_qiov_request() came in the context of discussing it
>
On 7/11/23 01:39, Michael S. Tsirkin wrote:
On Mon, May 22, 2023 at 11:31:52PM +0700, Bui Quang Minh wrote:
Hi everyone,
This series implements x2APIC mode in userspace local APIC and the
RDMSR/WRMSR helper to access x2APIC registers in x2APIC mode. Intel iommu
and AMD iommu are adjusted to
On 12.07.23 16:15, Stefan Hajnoczi wrote:
On Wed, Jul 12, 2023 at 09:41:05AM +0200, Hanna Czenczek wrote:
On 11.07.23 22:23, Stefan Hajnoczi wrote:
On Fri, Jun 09, 2023 at 10:33:16AM +0200, Hanna Czenczek wrote:
bdrv_pad_request() relies on requests' lengths not to exceed SIZE_MAX,
which
On 7/4/23 14:53, Thomas Huth wrote:
On 30/06/2023 11.17, Pierre Morel wrote:
The modification of the CPU attributes are done through a monitor
command.
It allows to move the core inside the topology tree to optimize
the cache usage in the case the host's hypervisor previously
moved the CPU.
1 - 100 of 225 matches
Mail list logo
