On 11/24/23 07:39, Nicholas Piggin wrote:
One of the functions of the ChipTOD is to transfer TOD to the Core
(aka PC - Pervasive Core) timebase facility.
The ChipTOD can be programmed with a target address to send the TOD
value to. The hardware implementation seems to perform this by
sending
On 11/24/23 07:39, Nicholas Piggin wrote:
The ChipTOD (for Time-Of-Day) is a chip pervasive facility that keeps a
time of day clock, and can synchronise that clock to other chips, and
can synchronize that clock to the timebase facility in each core.
This model implements basic status and error
On 11/24/23 07:39, Nicholas Piggin wrote:
The timebase in ppc started out with the mftb instruction which is like
mfspr but addressed timebase registers (TBRs) rather than SPRs. These
instructions could be used to read TB and TBU at 268 and 269. Timebase
could be written via the TBL and TBU SPRs
On 11/24/23 07:39, Nicholas Piggin wrote:
The ChipTOD (for Time-Of-Day) is a chip pervasive facility that keeps a
time of day clock, and can synchronise that clock to other chips, and
can synchronize that clock to the timebase facility in each core.
This model implements basic status and error
On 11/24/23 07:39, Nicholas Piggin wrote:
The move-to timebase registers TBU and TBL can not be read, and they
can not be written in supervisor mode on hypervisor-capable CPUs.
Signed-off-by: Nicholas Piggin
Reviewed-by: Cédric Le Goater
Thanks,
C.
---
target/ppc/helper_regs.c | 31
On 11/24/23 07:39, Nicholas Piggin wrote:
From the earliest PowerPC ISA, TBR (later SPR) 268 has been called TB
and accessed with mftb instruction. The problem is that TB is the name
of the 64-bit register, and 32-bit implementations can only read the
lower half with one instruction, so 268 has
On Fri Nov 24, 2023 at 4:39 PM AEST, Nicholas Piggin wrote:
> The ChipTOD (for Time-Of-Day) is a chip pervasive facility that keeps a
> time of day clock, and can synchronise that clock to other chips, and
> can synchronize that clock to the timebase facility in each core.
>
> This model
This implements the core timebase state machine, which is the core side
of the time-of-day system in POWER processors. This facility is operated
by control fields in the TFMR register, which also contains status
fields.
The core timebase interacts with the chiptod hardware, primarily to
receive
>From the earliest PowerPC ISA, TBR (later SPR) 268 has been called TB
and accessed with mftb instruction. The problem is that TB is the name
of the 64-bit register, and 32-bit implementations can only read the
lower half with one instruction, so 268 has also been called TBL and
it does only read
The ChipTOD (for Time-Of-Day) is a chip pervasive facility that keeps a
time of day clock, and can synchronise that clock to other chips, and
can synchronize that clock to the timebase facility in each core.
This model implements basic status and error registers, and XXX
emulation of chiptod
The TB, VTB, PURR, HDEC SPRs are per-LPAR registers, and the TFMR is a
per-core register. Add the necessary SMT helpers.
The TFMR can only drive the timebase state machine via thread 0 of the
core, which is almost certainly not right, but it is enough for skiboot
and other proprietary firmware.
One of the functions of the ChipTOD is to transfer TOD to the Core
(aka PC - Pervasive Core) timebase facility.
The ChipTOD can be programmed with a target address to send the TOD
value to. The hardware implementation seems to perform this by
sending the TOD value to a SCOM address.
This
The timebase in ppc started out with the mftb instruction which is like
mfspr but addressed timebase registers (TBRs) rather than SPRs. These
instructions could be used to read TB and TBU at 268 and 269. Timebase
could be written via the TBL and TBU SPRs at 284 and 285.
The ISA changed around
The move-to timebase registers TBU and TBL can not be read, and they
can not be written in supervisor mode on hypervisor-capable CPUs.
Signed-off-by: Nicholas Piggin
---
target/ppc/helper_regs.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git
The chiptod/TFMR/state machine is not really tied to the other
time register fixes, but they touch some of the same code, and
logically same facility.
Changes since v1 of chiptod patches:
- Split hackish ChipTOD<->TFMR/TBST interface into its own patch
- Fix multi-socket addressing on P9 / chip
On Fri Nov 24, 2023 at 4:34 AM AEST, Cédric Le Goater wrote:
> On 11/23/23 11:30, Nicholas Piggin wrote:
> > One of the functions of the ChipTOD is to transfer TOD to the Core
> > (aka PC - Pervasive Core) timebase facility.
> >
> > The ChipTOD can be programmed with a target address to send the
11.11.2023 13:40, Volker Rümelin wrote:
Commit 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing
scanout") introduced a regression when QEMU is running with a
virtio-gpu-gl-device on a host under X11. After the guest has
initialized the virtio-gpu-gl-device, the guest screen only
shows
On Fri Nov 24, 2023 at 3:49 AM AEST, Cédric Le Goater wrote:
> On 11/23/23 11:30, Nicholas Piggin wrote:
> > The ChipTOD (for Time-Of-Day) is a pervasive facility that keeps the
> > clocks on multiple chips consistent which can keep TOD (time-of-day),
> > synchronise it across multiple chips, and
On Fri Nov 24, 2023 at 3:09 AM AEST, Cédric Le Goater wrote:
> On 11/23/23 11:30, Nicholas Piggin wrote:
> > The chiptod/TFMR/state machine is not really tied to the other
> > time register fixes, but they touch some of the same code, and
> > logically same facility.
> >
> > Changes since v1 of
On Thu Nov 23, 2023 at 5:33 PM AEST, Cédric Le Goater wrote:
> On 11/23/23 07:01, Zhenzhong Duan wrote:
> > VFIO is not a required subsystem for the pseries machine but it's
> > force enabled currently. When --without-default-devices is used
> > to drop some default devices including vfio-pci,
v1 -> v2
- Replace snprintf() to g_strdup_printf() to avoid memory problems.
- Remove the parameter 'char ipAddress[16]' in function 'char
*hexToIPAddress()'.
- Add a piece of logic to skip traversing the first line of the file
Dehan Meng (1):
qga/linux: Add new api 'guest-network-get-route'
The Route information of the Linux VM needs to be used
by administrators and users when debugging network problems
and troubleshooting.
Signed-off-by: Dehan Meng
---
qga/commands-posix.c | 78 ++
qga/commands-win32.c | 6
qga/qapi-schema.json | 80
Hi Zhao Liu and QEMU/KVM Community,
I hope this email finds you well. I am writing to follow up on the
conversation we had a month ago regarding my patch submission for
refining the VMX controls setting for backward compatibility on
QEMU-KVM.
On October 27, I responded to the feedback and
This was the only failure preventing `make check` from passing with sanitizers
enabled on my configuration.
Signed-off-by: Daniel Hoffman
---
hw/core/qdev-properties.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index
On Tue, Nov 14, 2023 at 4:12 PM Stefan Berger wrote:
>
>
>
> On 11/14/23 16:05, Stefan Berger wrote:
> >
> >
> > On 11/14/23 13:03, Stefan Berger wrote:
> >>
> >>
> >> On 11/14/23 04:36, Marc-André Lureau wrote:
> >>> Hi
> >>>
> >>> On Tue, Nov 14, 2023 at 6:12 AM Joelle van Dyne wrote:
>
>
Hi David,
David Woodhouse writes:
> On 23 November 2023 12:17:57 GMT, Volodymyr Babchuk
> wrote:
>>
>>Hi David,
>>
>>David Woodhouse writes:
>>> Which PV backends do you care about? We already have net, block and console
>>> converted.
>>
>>Well, this is all what we need, actually. Even
On Thu, Nov 23, 2023 at 05:08:46PM +, Daniel P. Berrangé wrote:
> On Thu, Nov 23, 2023 at 12:58:18PM +0100, Philippe Mathieu-Daudé wrote:
> > On 23/11/23 12:40, Daniel P. Berrangé wrote:
> > > Currently we have a short paragraph saying that patches must include
> > > a Signed-off-by line, and
On Thu, Nov 23, 2023 at 05:46:16PM +, Daniel P. Berrangé wrote:
> On Thu, Nov 23, 2023 at 12:57:42PM +, Alex Bennée wrote:
> > Daniel P. Berrangé writes:
> >
> > > There has been an explosion of interest in so called "AI" (LLM)
> > > code generators in the past year or so. Thus far
On Thu, Nov 23, 2023 at 06:37:47PM +0100, Michal Suchánek wrote:
> If you could erase the copyright on anything by feeding it into a
> statistical model and pulling it back out there
> Would be some big
> content license holders objecting so it's very unlikely to happen.
I won't venture a guess
On Thu, Nov 23, 2023 at 05:58:45PM +, Daniel P. Berrangé wrote:
> The license of a code generation tool itself is usually considered
> to be not a factor in the license of its output.
Really? I would find it very surprising if a code generation tool that
is not a language model and so is not
On Wednesday, November 22nd, 2023 at 13:49, Javier Martinez Canillas
wrote:
> Any objections to merge the series ?
No objections from me :)
This file is the only one involved in the compilation process which
still uses the /bin/bash path.
Signed-off-by: Samuel Tardieu
---
target/hexagon/idef-parser/prepare | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/hexagon/idef-parser/prepare
On 23/11/23 22:15, Samuel Tardieu wrote:
This file is the only one involved in the compilation process which
still uses the /bin/bash path.
Signed-off-by: Samuel Tardieu
---
target/hexagon/idef-parser/prepare | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe
On 11/23/23 15:12, Christoph Muellner wrote:
From: Christoph Müllner
Upstream Linux recently added RISC-V Zicboz support to the hwprobe API.
This patch introduces this for QEMU's user space emulator.
Signed-off-by: Christoph Müllner
---
Reviewed-by: Daniel Henrique Barboza
On Thu, Nov 23, 2023 at 02:49:27PM -0500, Stefan Hajnoczi wrote:
> The SCSI subsystem uses the AioContext lock to protect internal state. This is
> necessary because the main loop and the IOThread can access SCSI state in
> parallel. This inter-thread access happens during
blk_aio_*() doesn't require the AioContext lock and the SCSI subsystem's
internal state also does not anymore.
Signed-off-by: Stefan Hajnoczi
---
hw/scsi/scsi-disk.c| 23 ---
hw/scsi/scsi-generic.c | 20 +++-
2 files changed, 3 insertions(+), 40
Commit abfcd2760b3e ("dma-helpers: prevent dma_blk_cb() vs
dma_aio_cancel() race") acquired the AioContext lock inside dma_blk_cb()
to avoid a race with scsi_device_purge_requests() running in the main
loop thread.
The SCSI code no longer calls dma_aio_cancel() from the main loop thread
while I/O
virtio_queue_aio_attach_host_notifier() does not require the AioContext
lock. Stop taking the lock and remember add an explicit smp_wmb()
because we were relying on the implicit barrier in the AioContext lock
before.
Signed-off-by: Stefan Hajnoczi
---
hw/scsi/virtio-scsi-dataplane.c | 8
The SCSI subsystem uses the AioContext lock to protect internal state. This is
necessary because the main loop and the IOThread can access SCSI state in
parallel. This inter-thread access happens during scsi_device_purge_requests()
and scsi_dma_restart_cb().
This patch series modifies the code so
Stop depending on the AioContext lock and instead access
SCSIDevice->requests from only one thread at a time:
- When the VM is running only the BlockBackend's AioContext may access
the requests list.
- When the VM is stopped only the main loop may access the requests
list.
These constraints
Add a new profile CPU 'rva22s64' to work as an alias of
-cpu rv64i,rva22s64
Like the existing rva22u64 CPU already does with the RVA22U64 profile.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu-qom.h | 1 +
target/riscv/cpu.c | 8
2 files changed, 9 insertions(+)
Some profiles, like RVA22S64, has a priv_spec requirement.
Make this requirement explicit for all profiles. We'll validate this
requirement finalize() time and, in case the user chooses an
incompatible priv_spec while activating a profile, a warning will be
shown.
Signed-off-by: Daniel Henrique
Profiles will need to validate satp_mode during their own finalize
methods. This will occur inside riscv_tcg_cpu_finalize_features() for
TCG. Given that satp_mode does not have any pre-req from the accelerator
finalize() method, it's safe to finalize it ealier.
Signed-off-by: Daniel Henrique
Next patch will need to retrieve if a given RISCVCPU is 32 or 64 bit.
The existing helper riscv_is_32bit() (hw/riscv/boot.c) will always check
the first CPU of a given hart array, not any given CPU.
Create a helper to retrieve the info for any given CPU, not the first
CPU of the hart array. The
'satp_mode' is a requirement for supervisor profiles like RVA22S64.
User-mode/application profiles like RVA22U64 doesn't care.
Add 'satp_mode' to the profile description. If a profile requires it,
set it during cpu_set_profile(). We'll also check it during finalize()
to validate if the running
The RVA22S64 profile consists of the following:
- all mandatory extensions of RVA22U64;
- priv spec v1.12.0;
- satp mode sv39;
- Ssccptr, a cache related named feature that we're assuming always
enable since we don't implement a cache;
- Other named features already implemented: Sstvecd,
Based-on: 20231123185122.1100436-1-dbarb...@ventanamicro.com
("[PATCH for-9.0 v11 00/18] rv64i and rva22u64 CPUs, RVA22U64 profile support")
Hi,
This series builds upon the RVA22U64 support to add the supervisor mode
profile RVA22S64 [1].
Patch 1 adds a new named feature called 'svade', which
'svade' is a RVA22S64 profile requirement, a profile we're going to add
shortly. It is a named feature (i.e. not a formal extension, not defined
in riscv,isa DT at this moment) defined in [1] as:
"Page-fault exceptions are raised when a page is accessed when A bit is
clear, or written when D bit
On 23/11/23 18:40, Philippe Mathieu-Daudé wrote:
On 23/11/23 05:41, Richard Henderson wrote:
This is primarily concerned with merging kvm64.c with kvm.c
and then unexporting everything that is not required outside.
target/arm/kvm_arm.h | 203 --
Unrelated to this series goal, but
The profile support is handling multi-letter extensions only. Let's add
support for MISA bits as well.
We'll go through every known MISA bit. If the profile doesn't declare
the bit as mandatory, ignore it. Otherwise, set the bit in env->misa_ext
and env->misa_ext_mask.
Now that we're setting
The rva22U64 profile, described in:
https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles
Contains a set of CPU extensions aimed for 64-bit userspace
applications. Enabling this set to be enabled via a single user flag
makes it convenient to enable a predictable set of
KVM does not have the means to support enabling the rva22u64 profile.
The main reasons are:
- we're missing support for some mandatory rva22u64 extensions in the
KVM module;
- we can't make promises about enabling a profile since it all depends
on host support in the end.
We'll revisit this
Named features (zic64b the sole example at this moment) aren't expose to
users, thus we need another way to expose them.
Go through each named feature, get its boolean value, do the needed
conversions (bool to qbool, qbool to QObject) and add it to output dict.
Another adjustment is needed:
The TCG emulation implements all the extensions described in the
RVA22U64 profile, both mandatory and optional. The mandatory extensions
will be enabled via the profile flag. We'll leave the optional
extensions to be enabled by hand.
Given that this is the first profile we're implementing in TCG
RVG behaves like a profile: a single flag enables a set of bits. Right
now we're considering user choice when handling RVG and zicsr/zifencei
and ignoring user choice on MISA bits.
We'll add user warnings for profiles when the user disables its
mandatory extensions in the next patch. We'll do the
We already track user choice for multi-letter extensions because we
needed to honor user choice when enabling/disabling extensions during
realize(). We refrained from adding the same mechanism for MISA
extensions since we didn't need it.
Profile support requires tne need to check for user choice
Expose all profile flags for all CPUs when executing
query-cpu-model-expansion. This will allow callers to quickly determine
if a certain profile is implemented by a given CPU. This includes vendor
CPUs - the fact that they don't have profile user flags doesn't mean
that they don't implement the
Our current logic in get/setters of MISA and multi-letter extensions
works because we have only 2 CPU types, generic and vendor, and by using
"!generic" we're implying that we're talking about vendor CPUs. When adding
a third CPU type this logic will break so let's handle it beforehand.
In
Previous patches added several g_hash_table_insert() patterns. Add two
helpers, one for each user hash, to make the code cleaner.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
---
target/riscv/tcg/tcg-cpu.c | 28
1 file changed, 16 insertions(+),
We'll add a new bare CPU type that won't have any default priv_ver. This
means that the CPU will default to priv_ver = 0, i.e. 1.10.0.
At the same we'll allow these CPUs to enable extensions at will, but
then, if the extension has a priv_ver newer than 1.10, we'll end up
disabling it. Users will
We have two instances of the setting/clearing a MISA bit from
env->misa_ext and env->misa_ext_mask pattern. And the next patch will
end up adding one more.
Create a helper to avoid code repetition.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Reviewed-by: LIU Zhiwei
Enabling a profile and then disabling some of its mandatory extensions
is a valid use. It can be useful for debugging and testing. But the
common expected use of enabling a profile is to enable all its mandatory
extensions.
Add an user warning when mandatory extensions from an enabled profile
are
QEMU already implements zicbom (Cache Block Management Operations) and
zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv:
add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for
what would be the instructions for zicbop (Cache Block Prefetch
Operations), which
We don't have any form of a 'bare bones' CPU. rv64, our default CPUs,
comes with a lot of defaults. This is fine for most regular uses but
it's not suitable when more control of what is actually loaded in the
CPU is required.
A bare-bones CPU would be annoying to deal with if not by profile
This CPU was suggested by Alistair [1] and others during the profile
design discussions. It consists of the bare 'rv64i' CPU with rva22u64
enabled by default, like an alias of '-cpu rv64i,rva22u64=true'.
Users now have an even easier way of consuming this user-mode profile by
doing '-cpu
zic64b is defined in the RVA22U64 profile [1] as a named feature for
"Cache blocks must be 64 bytes in size, naturally aligned in the address
space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64
profile mandates this feature, meaning that applications using this
profile expects 64
We want to add a new CPU type for bare CPUs that will inherit specific
traits of the 2 existing types:
- it will allow for extensions to be enabled/disabled, like generic
CPUs;
- it will NOT inherit defaults, like vendor CPUs.
We can make this conditions met by adding an explicit type for the
Hi,
In this new version we added a new function, riscv_cpu_enable_named_feat(),
to allow profiles to enable named features.
This doesn't have much of an impact for this current work - the only
named feature we're using here is zic64b and the default block size
values already satisfies it.
The
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm_arm.h | 4 ++--
target/arm/cpu.c | 2 +-
target/arm/kvm.c |
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm_arm.h | 6 +++---
target/arm/cpu64.c | 2 +-
target/arm/kvm.c
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm_arm.h | 6 +++---
hw/arm/virt.c| 5 +++--
target/arm/kvm.c
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 23 ++-
1 file changed, 10 insertions(+),
Both MemoryRegion and Error types are forward declared
in "qemu/typedefs.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm_arm.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h
index 2037b2d7ea..50967f4ae9 100644
---
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm_arm.h | 4 ++--
hw/arm/virt.c| 2 +-
target/arm/kvm.c |
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm.c | 12 ++--
1 file changed, 6 insertions(+), 6
Unify the "kvm_arm.h" API: All functions related to ARM vCPUs
take a ARMCPU* argument. Use the CPU() QOM cast macro When
calling the generic vCPU API from "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/kvm_arm.h | 4 ++--
hw/arm/virt.c| 2 +-
target/arm/kvm.c |
On 11/23/23 11:30, Nicholas Piggin wrote:
One of the functions of the ChipTOD is to transfer TOD to the Core
(aka PC - Pervasive Core) timebase facility.
The ChipTOD can be programmed with a target address to send the TOD
value to. The hardware implementation seems to perform this by
sending
kvm_arm_its_reset_hold() calls warn_report(), itself declared
in "qemu/error-report.h".
Signed-off-by: Philippe Mathieu-Daudé
---
hw/intc/arm_gicv3_its_kvm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/intc/arm_gicv3_its_kvm.c b/hw/intc/arm_gicv3_its_kvm.c
index
Half of the API takes CPUState, the other ARMCPU...
$ git grep -F 'CPUState *' target/arm/kvm_arm.h | wc -l
16
$ git grep -F 'ARMCPU *' target/arm/kvm_arm.h | wc -l
14
Since this is ARM specific, have it always take ARMCPU, and
call the generic KVM API casting with the CPU() macro.
From: Christoph Müllner
Upstream Linux recently added RISC-V Zicboz support to the hwprobe API.
This patch introduces this for QEMU's user space emulator.
Signed-off-by: Christoph Müllner
---
linux-user/syscall.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/syscall.c
On Thu, 23 Nov 2023 at 18:02, Daniel P. Berrangé wrote:
>
> On Thu, Nov 23, 2023 at 04:56:28PM +0200, Manos Pitsidianakis wrote:
> > On Thu, 23 Nov 2023 16:35, "Michael S. Tsirkin" wrote:
> > > On Thu, Nov 23, 2023 at 11:40:26AM +, Daniel P. Berrangé wrote:
> > > > +Examples of tools
On Thu, Nov 23, 2023 at 06:29:38PM +0100, Michal Suchánek wrote:
> On Thu, Nov 23, 2023 at 12:06:59PM -0500, Michael S. Tsirkin wrote:
> > On Thu, Nov 23, 2023 at 04:29:52PM +0100, Philippe Mathieu-Daudé wrote:
> > > This document targets all contributors. Contributions can be typo
> > > fix,
On Thu, Nov 23, 2023 at 7:01 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> Upstream Linux recently added RISC-V Zicboz support to the hwprobe API.
> This patch introduces this for QEMU's user space emulator.
>
> Signed-off-by: Christoph Müllner
> ---
> linux-user/syscall.c | 3
I went ahead and wrote a clang-tidy pass that attempts to find other
cases of this behavior (i.e. compile-time short-circuit behavior that
could lead to undefined references). All of these cases should also be
caught by `-Wunreachable-code`, but that uncovers a lot and I'd like a
green light
On Thu, Nov 23, 2023 at 04:56:28PM +0200, Manos Pitsidianakis wrote:
> On Thu, 23 Nov 2023 16:35, "Michael S. Tsirkin" wrote:
> > On Thu, Nov 23, 2023 at 11:40:26AM +, Daniel P. Berrangé wrote:
> > > There has been an explosion of interest in so called "AI" (LLM)
> > > code generators in the
From: Christoph Müllner
Upstream Linux recently added RISC-V Zicboz support to the hwprobe API.
This patch introduces this for QEMU's user space emulator.
Signed-off-by: Christoph Müllner
---
linux-user/syscall.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/syscall.c
On Thu, Nov 23, 2023 at 09:35:43AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 23, 2023 at 11:40:26AM +, Daniel P. Berrangé wrote:
> > There has been an explosion of interest in so called "AI" (LLM)
> > code generators in the past year or so. Thus far though, this is
> > has not been
On 11/23/23 11:30, Nicholas Piggin wrote:
The ChipTOD (for Time-Of-Day) is a pervasive facility that keeps the
clocks on multiple chips consistent which can keep TOD (time-of-day),
synchronise it across multiple chips, and can move that TOD to or from
the core timebase units.
May be rephrase a
On Thu, Nov 23, 2023 at 12:57:42PM +, Alex Bennée wrote:
> Daniel P. Berrangé writes:
>
> > There has been an explosion of interest in so called "AI" (LLM)
> > code generators in the past year or so. Thus far though, this is
> > has not been matched by a broadly accepted legal interpretation
On 23/11/23 05:41, Richard Henderson wrote:
This is primarily concerned with merging kvm64.c with kvm.c
and then unexporting everything that is not required outside.
target/arm/kvm_arm.h | 203 --
Unrelated to this series goal, but I notice half of the API takes
CPUState, the other
On Thu, Nov 23, 2023 at 12:57:42PM +, Alex Bennée wrote:
> Daniel P. Berrangé writes:
>
> > There has been an explosion of interest in so called "AI" (LLM)
> > code generators in the past year or so. Thus far though, this is
> > has not been matched by a broadly accepted legal interpretation
On 23/11/23 05:42, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
target/arm/kvm_arm.h | 20
target/arm/kvm.c | 20 ++--
2 files changed, 18 insertions(+), 22 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On 23/11/23 05:42, Richard Henderson wrote:
Signed-off-by: Richard Henderson
---
target/arm/kvm_arm.h | 12
target/arm/kvm.c | 10 --
2 files changed, 8 insertions(+), 14 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
1 - 100 of 212 matches
Mail list logo
