On 8/25/23 03:45, Yeqi Fu wrote:
This commit implements tcg opcodes and helpers for native library
calls. A table is used to store the parameter types and return value
types for each native library function. In terms of types, only three
types are of real concern: the two base sizes int and
On 8/25/23 03:20, Yeqi Fu wrote:
+#if defined(CONFIG_NATIVE_CALL)
+/* Set the library for native bypass */
+if (native_lib_path) {
+if (g_file_test(native_lib_path, G_FILE_TEST_IS_REGULAR)) {
+GString *lib = g_string_new(native_lib_path);
+lib =
On 8/25/23 03:20, Yeqi Fu wrote:
This commit implements a shared library, where native functions are
rewritten as special instructions. At runtime, user programs load
the shared library, and special instructions are executed when
native functions are called.
Signed-off-by: Yeqi Fu
...
diff
From: Oleksandr Tyshchenko
In order to use virtio backends we need to initialize RAM for the
xen-mapcache (which is responsible for mapping guest memory using foreign
mapping) to work. Calculate and add hi/low memory regions based on
machine->ram_size.
Use the constants defined in public header
From: Oleksandr Tyshchenko
In order to use virtio backends we need to allocate virtio-mmio
parameters (irq and base) and register corresponding buses.
Use the constants defined in public header arch-arm.h to be
aligned with the toolstack. So the number of current supported
virtio-mmio devices
Hi,
We added virtio-mmio support in xenpvh machine. Now, it can support upto
10 virtio mmio.
Changelog:
v2->v3:
Define GUEST_VIRTIO_*, GUEST_RAM* and xendevicemodel_set_irq() manually
for old xen version. This was done to avoid build failures in gitlab-ci
v1->v2:
On 8/25/23 10:51, Thomas Huth wrote:
There is an easier way to get a value that can be used to decide
whether the target is big endian or not: Simply use the
target_words_bigendian() function instead.
Signed-off-by: Thomas Huth
---
hw/mips/jazz.c | 10 ++
1 file changed, 2
On Fri, Aug 25, 2023 at 07:33:23PM +0200, Thomas Huth wrote:
> On 25/08/2023 19.15, Peter Xu wrote:
> > Add a test for StrOrNull parameters (tls-*).
> >
> > Reviewed-by: Fabiano Rosas
> > Signed-off-by: Peter Xu
> > ---
> > tests/qtest/migration-test.c | 21 +
> > 1 file
This is a part of patchset where IBM's Flexible Service Interface is
introduced.
The Common FRU Access Macro (CFAM), an address space containing
various "engines" that drive accesses on busses internal and external
to the POWER chip. Examples include the SBEFIFO and I2C masters. The
engines hang
Hello,
Please review the patch-set.
This is a first step towards introducing model for IBM's Flexible
Service Interface. The full functionality will be implemented over the
time.
Ninad Palsule (7):
hw/fsi: Introduce IBM's Local bus
hw/fsi: Introduce IBM's scratchpad
hw/fsi: Introduce
This is a part of patchset where IBM's Flexible Service Interface is
introduced.
The LBUS device is embeded inside the scratchpad. The scratchpad
provides a non-functional registers. There is a 1-1 relation between
scratchpad and LBUS devices. Each LBUS device has 1K memory mapped in
the LBUS.
This is a part of patchset where IBM's Flexible Service Interface is
introduced.
This commit models the FSI bus. CFAM is hanging out of FSI bus. The bus
is model such a way that it is embeded inside the FSI master which is a
bus controller.
The FSI master: A controller in the platform service
This patchset introduces IBM's Flexible Service Interface(FSI).
Time for some fun with inter-processor buses. FSI allows a service
processor access to the internal buses of a host POWER processor to
perform configuration or debugging.
FSI has long existed in POWER processes and so comes with
This is a part of patchset where IBM's Flexible Service Interface is
introduced.
The On-Chip Peripheral Bus (OPB): A low-speed bus typically found in
POWER processors. This now makes an appearance in the ASPEED SoC due
to tight integration of the FSI master IP with the OPB, mainly the
existence
This is a part of patchset where IBM's Flexible Service Interface is
introduced.
The LBUS is modelled to maintain the qdev bus hierarchy and to take
advantage of the object model to automatically generate the CFAM
configuration block. The configuration block presents engines in the
order they are
This is a part of patchset where IBM's Flexible Service Interface is
introduced.
An APB-to-OPB bridge enabling access to the OPB from the ARM core in
the AST2600. Hardware limitations prevent the OPB from being directly
mapped into APB, so all accesses are indirect through the bridge.
Closing stderr earlier is good for daemonized qemu-nbd under ssh
earlier, but breaks the case where -v is being used to track what is
happening in the server, as in iotest 233.
When we know we are verbose, we should preserve original stderr and
restore it once the setup stage is done. This commit
On 8/24/23 22:03, Eric Blake wrote:
Closing stderr earlier is good for daemonized qemu-nbd under ssh
earlier, but breaks the case where -v is being used to track what is
happening in the server, as in iotest 233.
When we know we are verbose, we do NOT want qemu_daemon to close
stderr. For
Alyssa Ross writes:
> Gurchetan Singh writes:
>
>> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross wrote:
>>
>>> Gurchetan Singh writes:
>>>
>>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross wrote:
>>> >
>>> >> Gurchetan Singh writes:
>>> >>
>>> >> > - Official "release commits" issued for
Gurchetan Singh writes:
> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross wrote:
>
>> Gurchetan Singh writes:
>>
>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross wrote:
>> >
>> >> Gurchetan Singh writes:
>> >>
>> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
>> >> >
Closing stderr earlier is good for daemonized qemu-nbd under ssh
earlier, but breaks the case where -v is being used to track what is
happening in the server, as in iotest 233.
When we know we are verbose, we should preserve original stderr and
restore it once the setup stage is done. This commit
Closing stderr earlier is good for daemonized qemu-nbd under ssh
earlier, but breaks the case where -v is being used to track what is
happening in the server, as in iotest 233.
When we know we are verbose, we should preserve original stderr and
restore it once the setup stage is done. This commit
On Thu, Aug 24, 2023 at 9:53 PM Akihiko Odaki
wrote:
> On 2023/08/25 8:40, Gurchetan Singh wrote:
> > From: Gurchetan Singh
> >
> > Prior versions:
> >
> > Changes since v11:
> > - Incorporated review feedback
> >
> > How to build both rutabaga and gfxstream guest/host libs:
> >
> >
On Fri, Aug 25, 2023 at 6:55 AM Antonio Caggiano
wrote:
> Hi Gurchetan,
>
> Thank you for this series and for including some of my patches :)
>
> On 25/08/2023 01:40, Gurchetan Singh wrote:
> > This change enables rutabaga to receive virtio-gpu-3d hypercalls
> > when it is active.
> >
> >
On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross wrote:
> Gurchetan Singh writes:
>
> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross wrote:
> >
> >> Gurchetan Singh writes:
> >>
> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
> >> > gfxstream, aemu-base. For example, see
On 8/25/2023 11:07 AM, Peter Xu wrote:
> On Fri, Aug 25, 2023 at 09:28:28AM -0400, Steven Sistare wrote:
>> On 8/24/2023 5:09 PM, Steven Sistare wrote:
>>> On 8/17/2023 2:23 PM, Peter Xu wrote:
On Mon, Aug 14, 2023 at 11:54:26AM -0700, Steve Sistare wrote:
> Migration of a guest in the
The for-loop does not make much sense here - it is always left after
the first iteration, so we can also check for nb_nics == 1 instead
which is way easier to understand.
Also, the checks for nd->model are superfluous since the code in
mips_jazz_init_net() calls qemu_check_nic_model() that
The mips_jazz_init() function is already quite big, so moving
away some code here can help to make it more understandable.
Additionally, by moving this code into a separate function, the
next patch (that will refactor the for-loop around the NIC init
code) will be much shorter and easier to
The NIC init code of the jazz machines is rather cumbersome, with
a for-loop around it that is always left after the first iteration.
This patch series reworks this a little bit to make the code more
readable and shorter.
Thomas Huth (3):
hw/mips/jazz: Remove the big_endian variable
There is an easier way to get a value that can be used to decide
whether the target is big endian or not: Simply use the
target_words_bigendian() function instead.
Signed-off-by: Thomas Huth
---
hw/mips/jazz.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
On 25/08/2023 19.15, Peter Xu wrote:
Add a test for StrOrNull parameters (tls-*).
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
tests/qtest/migration-test.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/tests/qtest/migration-test.c
v2:
- Collected R-bs
- Patch 3: convert to use StrOrNull rather than str for the tls_fields
(it contains a lot of changes, I'll skip listing details, but please
refer to the commit message)
Patch 1 fixes the tls-authz crashing when someone specifies "null"
parameter for tls-authz.
Patch 2
Drop the enum in qapi because it is never used in QMP APIs. Instead making
it an internal definition for QEMU so that we can decouple it from QAPI,
and also we can deduplicate the QAPI documentations.
Signed-off-by: Peter Xu
---
qapi/migration.json| 179
Add a test for StrOrNull parameters (tls-*).
Reviewed-by: Fabiano Rosas
Signed-off-by: Peter Xu
---
tests/qtest/migration-test.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index 62d3f37021..64efee8b04
Quotting from Markus in his replies:
migrate-set-parameters sets migration parameters, and
query-migrate-parameters gets them. Unsurprisingly, the former's
argument type MigrateSetParameters is quite close to the latter's
return type MigrationParameters. The differences are subtle:
QEMU will crash if anyone tries to set tls-authz (which is a type
StrOrNull) with 'null' value. Fix it in the easy way by converting it to
qstring just like the other two tls parameters.
Cc: qemu-sta...@nongnu.org # v4.0+
Fixes: d2f1d29b95 ("migration: add support for a "tls-authz" migration
On Mon, Aug 14, 2023 at 06:19:46PM -0400, Peter Xu wrote:
> Here to deduplicate the two objects, logically it'll be safe only if we use
> "StrOrNull" to replace "str" type, not vice versa. However we may face
> difficulty using StrOrNull as part of MigrationState.parameters [1] when
> replacing
We do not need the most up to date number of heads, we only want to
know if there is at least one.
Use shadow variable as long as it is not equal to the last available
index checked. This avoids expensive qatomic dereference of the
RCU-protected memory region cache as well as the memory access
It was supposed to be a compiler barrier and it was a compiler barrier
initially called 'wmb' (??) when virtio core support was introduced.
Later all the instances of 'wmb' were switched to smp_wmb to fix memory
ordering issues on non-x86 platforms. However, this one doesn't need
to be an actual
On Fri, Aug 25, 2023 at 12:42:56PM +0100, Jonathan Cameron wrote:
> On Thu, 24 Aug 2023 13:49:00 -0700
> Fan Ni wrote:
>
> > On Mon, Aug 07, 2023 at 09:53:42AM +0100, Jonathan Cameron wrote:
> > > On Tue, 25 Jul 2023 18:39:56 +
> > > Fan Ni wrote:
> > >
> > > > From: Fan Ni
> > > >
> > > >
On 25/08/2023 17.59, Markus Armbruster wrote:
docs/multi-thread-compression.txt uses parameter names with
underscores instead of dashes. Wrong since day one.
docs/rdma.txt, tests/qemu-iotests/181, and tests/qtest/test-hmp.c are
wrong the same way since commit cbde7be900d2 (v6.0.0). Hard to
On Thu, 2023-08-24 at 17:12 +0200, Philippe Mathieu-Daudé wrote:
> On 24/8/23 15:57, Tim Wiederhake wrote:
> > The mistake became apparent as there were two features with the
> > same name
> > in this cpuid leaf. The names are now in line with the
> > documentation from
> >
On 25/08/2023 17.59, Markus Armbruster wrote:
The command always fails with "Error: Parameter 'xbzrle_cache_size'
expects a power of two no less than the target page size". The test
passes anyway. Change the argument from 1 to 64k to make the test a
bit more useful.
Signed-off-by: Markus
The command always fails with "Error: Parameter 'xbzrle_cache_size'
expects a power of two no less than the target page size". The test
passes anyway. Change the argument from 1 to 64k to make the test a
bit more useful.
Signed-off-by: Markus Armbruster
---
tests/qtest/test-hmp.c | 2 +-
1
I spotted a bad use of migrate_set_parameter in test-hmp.c, and looked
for more.
I also looked for more failing HMP commands in test-hmp.c. I found
some, but they fail only on some machines, which feels okay. They
are:
* device_add usb-mouse,id=mouse1
device_del mouse1
Fail when the
docs/multi-thread-compression.txt uses parameter names with
underscores instead of dashes. Wrong since day one.
docs/rdma.txt, tests/qemu-iotests/181, and tests/qtest/test-hmp.c are
wrong the same way since commit cbde7be900d2 (v6.0.0). Hard to see,
as test-hmp doesn't check whether the
On Fri, Aug 25, 2023 at 08:16:51PM +0800, LIU Zhiwei wrote:
> This make the cpu works the similar way like the -device option.
>
> For device option,
> """
> ./qemu-system-riscv64 -device e1000,help
> e1000 options:
> acpi-index=- (default: 0)
> addr= - Slot and optional
On 01.06.23 21:28, Andrey Drobyshev via wrote:
The test cases considered so far:
1. Check that compression mode isn't compatible with "-f raw" (raw
format doesn't support compression).
2. Check that rebasing an image onto no backing file preserves the data
and writes the copied clusters
On 01.06.23 21:28, Andrey Drobyshev via wrote:
If we rebase an image whose backing file has compressed clusters, we
might end up wasting disk space since the copied clusters are now
uncompressed. In order to have better control over this, let's add
"--compress" option to the "qemu-img rebase"
On Fri, Aug 25, 2023 at 09:28:28AM -0400, Steven Sistare wrote:
> On 8/24/2023 5:09 PM, Steven Sistare wrote:
> > On 8/17/2023 2:23 PM, Peter Xu wrote:
> >> On Mon, Aug 14, 2023 at 11:54:26AM -0700, Steve Sistare wrote:
> >>> Migration of a guest in the suspended runstate is broken. The incoming
On 01.06.23 21:28, Andrey Drobyshev via wrote:
When rebasing an image from one backing file to another, we need to
compare data from old and new backings. If the diff between that data
happens to be unaligned to the target cluster size, we might end up
doing partial writes, which would lead to
On 01.06.23 21:28, Andrey Drobyshev via wrote:
Before previous commit, rebase was getting infitely stuck in case of
rebasing within the same backing chain and when overlay_size > backing_size.
Let's add this case to the rebasing test 024 to make sure it doesn't
break again.
Signed-off-by:
On 01.06.23 21:28, Andrey Drobyshev via wrote:
Since commit bb1c05973cf ("qemu-img: Use qemu_blockalign"), buffers for
the data read from the old and new backing files are aligned using
BlockDriverState (or BlockBackend later on) referring to the target image.
However, this isn't quite right,
On 01.06.23 21:28, Andrey Drobyshev via wrote:
In case when we're rebasing within one backing chain, and when target image
is larger than old backing file, bdrv_is_allocated_above() ends up setting
*pnum = 0. As a result, target offset isn't getting incremented, and we
get stuck in an infinite
Hi Zhiwei! I have two observations:
- this API doesn't play well with KVM as is. In a KVM environment, asking for
the
enabled extensions of the 'host' CPU returns:
$ ./mnt/qemu/bin/qemu-system-riscv64 -cpu host,help
Enable extension:
On 06.07.23 18:30, Andrey Drobyshev wrote:
Functions qcow2_get_host_offset(), get_cluster_offset(),
vmdk_co_block_status() explicitly report compressed cluster types when data
is compressed. However, this information is never passed further. Let's
make use of it by adding new
On 06.07.23 18:30, Andrey Drobyshev wrote:
Right now "qemu-img map" reports compressed blocks as containing data
but having no host offset. This is not very informative. Instead,
let's add another boolean field named "compressed" in case JSON output
mode is specified. This is achieved by
Hi Gurchetan,
Thank you for this series and for including some of my patches :)
On 25/08/2023 01:40, Gurchetan Singh wrote:
This change enables rutabaga to receive virtio-gpu-3d hypercalls
when it is active.
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Emmanouil
On 8/25/23 09:16, LIU Zhiwei wrote:
This API used for output current configuration for one specified CPU.
Currently only RISC-V frontend implements this API.
Signed-off-by: LIU Zhiwei
---
cpu.c | 8
include/exec/cpu-common.h | 1 +
target/riscv/cpu.c
On 8/24/2023 5:09 PM, Steven Sistare wrote:
> On 8/17/2023 2:23 PM, Peter Xu wrote:
>> On Mon, Aug 14, 2023 at 11:54:26AM -0700, Steve Sistare wrote:
>>> Migration of a guest in the suspended runstate is broken. The incoming
>>> migration code automatically tries to wake the guest, which is
On 28.07.23 04:19, zhenwei pi wrote:
[...]
Zhenwei Pi (9):
throttle: introduce enum ThrottleDirection
test-throttle: use enum ThrottleDirection
throttle: support read-only and write-only
test-throttle: test read only and write only
cryptodev: use NULL throttle timer cb for read
Let's fixup the documentation (e.g., removing traces of the ram_addr
parameter that no longer exists) and move it to the header file while at
it.
Suggested-by: Igor Mammedov
Acked-by: Igor Mammedov
Reviewed-by: Peter Xu
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: David Hildenbrand
---
Let's mark the memslot alias memory regions as unmergable, such that
flatview and vhost won't merge adjacent memory region aliases and we can
atomically map/unmap individual aliases without affecting adjacent
alias memory regions.
This handles vhost and vfio in multiple-memslot mode correctly
We want to support memory devices that can automatically decide how many
memslots they will use. In the worst case, they have to use a single
memslot.
The target use cases are virtio-mem and the hyper-v balloon.
Let's calculate a reasonable limit such a memory device may use, and
instruct the
We'll need the stub soon from memory device context.
While at it, use "unsigned int" as return value and place the
declaration next to kvm_get_free_memslots().
Signed-off-by: David Hildenbrand
---
accel/kvm/kvm-all.c| 2 +-
accel/stubs/kvm-stub.c | 5 +
include/sysemu/kvm.h | 2 +-
3
Let's add vhost_get_max_memslots(), to perform a similar task as
kvm_get_max_memslots().
Signed-off-by: David Hildenbrand
---
hw/virtio/vhost-stub.c| 5 +
hw/virtio/vhost.c | 11 +++
include/hw/virtio/vhost.h | 1 +
3 files changed, 17 insertions(+)
diff --git
We want to support memory devices that have a dynamically managed memory
region container as device memory region. This device memory region maps
multiple RAM memory subregions (e.g., aliases to the same RAM memory
region), whereby these subregions can be (un)mapped on demand.
Each RAM subregion
We want to support memory devices that have a memory region container as
device memory region that maps multiple RAM memory regions. Let's start
by supporting memory devices that statically map multiple RAM memory
regions and, thereby, consume multiple memslots.
We already have one device that
Having large virtio-mem devices that only expose little memory to a VM
is currently a problem: we map the whole sparse memory region into the
guest using a single memslot, resulting in one gigantic memslot in KVM.
KVM allocates metadata for the whole memslot, which can result in quite
some memory
Let's return the number of free slots instead of only checking if there
is a free slot. Required to support memory devices that consume multiple
memslots.
This is a preparation for memory devices that consume multiple memslots.
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c| 2
Let's return the number of free slots instead of only checking if there
is a free slot. While at it, check all address spaces, which will also
consider SMM under x86 correctly.
Make the stub return UINT_MAX, such that we can call the function
unconditionally.
This is a preparation for memory
We want to place non-qmp stubs in there, so let's rename it. While at
it, put it into the MAINTAINERS file under "Memory devices".
Signed-off-by: David Hildenbrand
---
MAINTAINERS| 1 +
stubs/{qmp_memory_device.c => memory_device.c} | 0
stubs/meson.build
Checking whether the memory regions are equal is sufficient: if they are
equal, then most certainly the contained fd is equal.
The whole vhost-user memslot handling is suboptimal and overly
complicated. We shouldn't have to lookup a RAM memory regions we got
notified about in
We really only care about the RAM memory region not being mapped into
an address space yet as long as we're still setting up the
RamDiscardManager. Once mapped into an address space, memory notifiers
would get notified about such a region and any attempts to modify the
RamDiscardManager would be
Quoting from patch #14:
Having large virtio-mem devices that only expose little memory to a VM
is currently a problem: we map the whole sparse memory region into the
guest using a single memslot, resulting in one gigantic memslot in KVM.
KVM allocates metadata for the whole
Let's track how many memslots are required by plugged memory devices and
how many are currently actually getting used by plugged memory
devices.
"required - used" is the number of reserved memslots. For now, the number
of used and required memslots is always equal, and there are no
reservations.
Let's allow for marking memory regions unmergeable, to teach
flatview code and vhost to not merge adjacent aliases to the same memory
region into a larger memory section; instead, we want separate aliases to
stay separate such that we can atomically map/unmap aliases without
affecting other
Having multiple vhost devices, some filtering out fd-less memslots and
some not, can mess up the "used_memslot" accounting. Consequently our
"free memslot" checks become unreliable and we might run out of free
memslots at runtime later.
An example sequence which can trigger a potential issue that
This array will be read by the TCG accel class, allowing it to handle
priv spec verifications on its own. The array will remain here in cpu.c
because it's also used by the riscv,isa string function.
To export it we'll make it constant and finish it with an empty element
since ARRAY_SIZE() won't
This CPU only exists if we're compiling with KVM so move it to the kvm
specific file. While we're at it, change its class_init() to enable the
user_extensions_flag class property, sparing us from having to execute
riscv_cpu_add_user_properties() by hand and letting the post_init() hook
do the
We want to use a post_init hook to call the cpu_instance_init callback
from each accelerator, moving repetitive code from the cpu_init()
functions to be handled by the accelerator class. But first we need to
ensure that we don't change behavior - vendor CPUs shouldn't expose user
properties,
tcg_cpu_instance_init() will be the 'cpu_instance_init' impl for the TCG
accelerator. It'll be called from within riscv_cpu_post_init(), via
accel_cpu_instance_init(), similar to what happens with KVM. In fact, to
preserve behavior, the implementation will be similar to what
riscv_cpu_post_init()
All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU
calls riscv_init_max_cpu_extensions(). Both can be moved to a common
instance_post_init() callback, implemented in riscv_cpu_post_init(),
called by all CPUs. The call order then becomes:
riscv_cpu_init() -> cpu_init() of each
We'll introduce the KVM accelerator class with a 'cpu_instance_init'
implementation that is going to be invoked during the common
riscv_cpu_post_init() (via accel_cpu_instance_init()). This
instance_init will execute KVM exclusive code that TCG doesn't care
about, such as adding KVM specific
This follows the same idea of 'tcg_support' property added in the
previous patch. Note that we're now implementing the 'cpu_realizefn' for
the KVMAccel class since this verification is done in realize() time.
Supporting vendor CPUs with KVM is not possible. We rely on the
extension support of the
Priv spec validation is TCG specific. Move it to the TCG accel class.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 39 --
target/riscv/cpu.h | 2 --
target/riscv/tcg/tcg-cpu.c | 39 ++
3
This function is the core of the RISC-V validations for TCG CPUs, and it
has a lot going on.
Functions in cpu.c were made public to allow them to be used by the KVM
accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably
hard to move it to another file due to its dependency with
On 25.08.2023 12:29, Dmitry Frolov wrote:
> It is true, that there is no problem during runtime
> from the first sight, because the memmory is lost just
> before qemu exits. Nevertheless, this change is necessary,
> because AddressSanitizer is not able to recognize this
> situation and produces
riscv_cpu_add_misa_properties() is being used to fill the missing KVM
MISA properties but it is a TCG helper that was adapted to do so. We'll
move it to tcg-cpu.c in the next patches, meaning that KVM needs to fill
the remaining MISA properties on its own.
Do not use
All code related to MISA TCG properties is also moved.
At this point, all TCG properties handling is done in tcg-cpu.c, all KVM
properties handling is done in kvm-cpu.c.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 89 --
target/riscv/cpu.c needs to handle all possible accelerators (TCG and
KVM at this moment) during both init() and realize() time. This forces
us to resort to a lot of "if tcg" and "if kvm" throughout the code,
which isn't wrong, but can get cluttered over time. Splitting
acceleration specific code
Add a KVM accelerator class like we did with TCG. The difference is
that, at least for now, we won't be using a realize() implementation for
this accelerator.
We'll start by assiging kvm_riscv_cpu_add_kvm_properties(), renamed to
kvm_cpu_instance_init(), as a 'cpu_instance_init' implementation.
This property indicates if a CPU supports TCG acceleration. All CPUs but
the 'host' CPU supports it.
The error in tcg_cpu_realizefn() can now be made generic in case more
non-TCG CPUs are added in the future.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu-qom.h | 1 +
Move the files to a 'kvm' dir to promote more code separation between
accelerators and making our lives easier supporting build options such
as --disable-tcg.
Rename kvm.c to kvm-cpu.c to keep it in line with its TCG counterpart.
Signed-off-by: Daniel Henrique Barboza
---
hw/riscv/virt.c
Move the remaining of riscv_tcg_ops now that we have a working realize()
implementation.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 58 -
target/riscv/cpu.h | 4 ---
target/riscv/tcg/tcg-cpu.c | 59
The function is doing way more than just init user properties. We would
also like to use the 'user_extension_properties' class property, as the
TCG driver is already using, to decide whether KVM should expose user
properties or not.
Rename kvm_riscv_init_user_properties() to
riscv_cpu_realize_tcg() was added to allow TCG cpus to have a different
realize() path during the common riscv_cpu_realize(), making it a good
choice to start moving TCG exclusive code to tcg-cpu.c.
Rename it to tcg_cpu_realizefn() and assign it as a implementation of
accel::cpu_realizefn().
The 'max' CPU type is being configured during init() time by enabling
all relevant extensions.
Instead of checking for 'max' CPU to enable all extensions, add a new
CPU cfg flag 'max_features' that can be used by any CPU during its
cpu_init() function. We'll check for it during post_init() time
We'll need to export these arrays to the accelerator classes in the next
patches. Mark them as 'const' now to minimize changes in the future.
Note that 'riscv_cpu_options' will also be exported, but can't be marked
as 'const', because the properties are changed via
qdev_property_add_static().
Based-on: 20230824221440.484675-1-dbarb...@ventanamicro.com
("[PATCH RESEND v8 00/20] riscv: 'max' CPU, detect user choice in TCG")
Hi,
The idea of this work was hinted at during a review [1] where Phil
mentioned that we should handle TCG specific constraints in
AccelCPUClass::cpu_realizefn().
1 - 100 of 173 matches
Mail list logo
