On 20/07/2023 22.47, Olaf Hering wrote:
This is going on since a few weeks. I guess there is no check in CI to see if
qemu.git#master compiles in Tumbleweed.
We only have a check for openSUSE leap ...
Which compiler version is causing trouble for you?
Since the switch to meson submodules, be
Am 17.07.23 um 14:45 schrieb marcandre.lur...@redhat.com:
From: Dongwon Kim
Setting scanout mode is better to be done very last minute
right because the mode can be reset anytime after it is set in
dpy_gl_scanout_texture by any asynchronouse dpy_refresh call,
which eventually cancels drawing of
On Thu, Jul 20, 2023 at 8:15 PM Eugenio Pérez wrote:
>
> At this moment the migration of net features that depends on CVQ is not
> possible, as there is no reliable way to restore the device state like mac
> address, number of enabled queues, etc to the destination. This is mainly
> caused becaus
On 21/07/2023 08.06, Bastian Koppelmann wrote:
this name is used by capstone and will lead to a build failure of QEMU,
when capstone is enabled. So we rename it to tricore_has_feature(), to
match has_feature() in translate.c.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1774
Signed-of
libvirt uses "none" machine type to test KVM availability. Before this
change, QEMU used to pass 0 as machine type when calling KVM_CREATE_VM.
The kernel documentation says:
> On arm64, the physical address size for a VM (IPA Size limit) is
> limited to 40bits by default. The limit can be configur
this name is used by capstone and will lead to a build failure of QEMU,
when capstone is enabled. So we rename it to tricore_has_feature(), to
match has_feature() in translate.c.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1774
Signed-off-by: Bastian Koppelmann
---
target/tricore/cpu
> On 11-Jul-2023, at 12:33 PM, Ani Sinha wrote:
>
> This change is cosmetic. A comment is added explaining why we need to check
> for
> the availability of function 0 when we hotplug a device.
>
> CC: m...@redhat.com
> CC: m...@tls.msk.ru
> Signed-off-by: Ani Sinha
Can we merge this while
The ASDR register was introduced in ISA v3.0. It has not been
implemented for HPT. With HPT, ASDR is the format of the slbmte RS
operand (containing VSID), which matches the ppc_slb_t field.
Signed-off-by: Nicholas Piggin
---
target/ppc/mmu-hash64.c | 27 ---
1 file chang
Until v2.07s, the VRMA page size (L||LP) was encoded in LPCR[VRMASD].
In v3.0 that moved to the partition table PS field.
Signed-off-by: Nicholas Piggin
---
target/ppc/mmu-hash64.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/targ
This fixes a couple of deficiencies in the v3.0 and later (POWER9, 10)
HPT MMU implementation. With these fixes, KVM is unable to boot hash
guests on powernv9/10 machines. Bare metal hash or pseries machine with
hash works, because VRMA is only used when a real hypervisor is
virtualizing a hash gue
Did this fall through the cracks?
On Thu Jul 13, 2023 at 3:35 AM AEST, Shawn Anastasio wrote:
> 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 inst
On 2023/7/20 21:24, Daniel Henrique Barboza wrote:
The cpu->cfg.epmp extension is still experimental, but it already has a
'smepmp' riscv,isa string. Add it.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Weiwei Li
Weiwei Li
target/riscv/cpu.c | 1 +
1 file changed, 1 insert
On 2023/7/20 21:24, Daniel Henrique Barboza wrote:
zmmul was promoted from experimental to ratified in commit 6d00ffad4e95.
Add a riscv,isa string for it.
Fixes: 6d00ffad4e95 ("target/riscv: move zmmul out of the experimental
properties")
Signed-off-by: Daniel Henrique Barboza
---
Reviewed
On 2023/7/21 01:19, Daniel Henrique Barboza wrote:
Use a macro in riscv_cpu_add_kvm_properties() to eliminate some of its
code repetition, similar to what we're already doing with
ADD_CPU_QDEV_PROPERTIES_ARRAY().
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Weiwei Li
Weiwei Li
On 2023/7/21 01:19, Daniel Henrique Barboza wrote:
This last blank element is used by the 'for' loop to check if a property
has a valid name.
Remove it and use ARRAY_SIZE() instead like riscv_cpu_options is already
using. All future arrays will also do the same and we'll able to
encapsulate mo
On 2023/7/21 01:19, Daniel Henrique Barboza wrote:
Future patches will split the existing Property arrays even further, and
the existing code in riscv_cpu_add_user_properties() will start to scale
bad with it because it's dealing with KVM constraints mixed in with TCG
constraints. We're going t
Hi Kevin, Hanna,
Patch 1 -> patch 5 of this series are already reviewed by Alberto(these
affects throttle framework only), the patch 6 affects qemu block layer,
would you please review this(in the further step, merge this series if
this is acceptable)?
On 7/13/23 14:41, zhenwei pi wrote:
v2
On 2023/7/21 01:19, Daniel Henrique Barboza wrote:
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
This commit adds support for ufs logical unit.
The LU handles processing for the SCSI command,
unit descriptor query request.
This commit enables the UFS device to process
IO requests.
Signed-off-by: Jeuk Kim
---
hw/ufs/lu.c | 1439 ++
hw/ufs/mes
Universal Flash Storage (UFS) is a high-performance mass storage device
with a serial interface. It is primarily used as a high-performance
data storage device for embedded applications.
This commit contains code for UFS device to be recognized
as a UFS PCI device.
Patches to handle UFS logical un
Since v5:
- Fix to print an error message instead of a segmentation fault
when no drive property is specified for a ufs-lu device
Since v4:
Addressed review comment from Stefan Hajnoczi. The fixes are as
follows.
- Keep u->reg fields in host endian (Removed little-endian helper
functions from
This commit makes the UFS device support query
and nop out transfer requests.
The next patch would be support for UFS logical
unit and scsi command transfer request.
Signed-off-by: Jeuk Kim
---
hw/ufs/trace-events | 1 +
hw/ufs/ufs.c| 980 +++-
On 7/21/2023 3:49 AM, Stefan Hajnoczi wrote:
Hi,
I'm ready to merge this but encountered a bug when testing:
$ qemu-system-x86_64 --device ufs --device ufs-lu
Segmentation fault (core dumped)
Please ensure there is an error message like with SCSI disks:
$ qemu-system-x86_64 --device v
On Thu, Jul 20, 2023 at 3:00 AM Bin Meng wrote:
>
> Upgrade OpenSBI from v1.3 to v1.3.1 and the pre-built bios images
> which fixes the boot failure seen when using QEMU to do a direct
> kernel boot with Microchip Icicle Kit board machine.
>
> The v1.3.1 release includes the following commits:
>
>
On Thu, Jul 20, 2023 at 05:31:03PM -0400, Stefan Hajnoczi wrote:
> On Thu, 20 Jul 2023 at 17:15, Michael S. Tsirkin wrote:
> >
> > On Thu, Jul 20, 2023 at 03:58:37PM -0400, Stefan Hajnoczi wrote:
> > > On Thu, Jul 06, 2023 at 12:48:20PM -0400, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 04, 2023
Hello,
On behalf of the QEMU Team, I'd like to announce the availability of the
first release candidate for the QEMU 8.1 release. This release is meant
for testing purposes and should not be used in a production environment.
http://download.qemu.org/qemu-8.1.0-rc0.tar.xz
http://download.qemu.
Stefan,
I hope you had a great vacation!
Thanks for updating the mirror and your review. Your comments all make
sense, and I will address your input when I find time - just a quick
ack now since I'm travelling next week and will be on vacation the
first half of August, so it might be a while.
Th
On Thu, 20 Jul 2023 at 17:15, Michael S. Tsirkin wrote:
>
> On Thu, Jul 20, 2023 at 03:58:37PM -0400, Stefan Hajnoczi wrote:
> > On Thu, Jul 06, 2023 at 12:48:20PM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Bennée wrote:
> > > > Currently QEMU has to know
On Thu, Jul 20, 2023 at 03:58:37PM -0400, Stefan Hajnoczi wrote:
> On Thu, Jul 06, 2023 at 12:48:20PM -0400, Michael S. Tsirkin wrote:
> > On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Bennée wrote:
> > > Currently QEMU has to know some details about the back-end to be able
> > > to setup the gues
This is going on since a few weeks. I guess there is no check in CI to see if
qemu.git#master compiles in Tumbleweed.
Since the switch to meson submodules, berkeley-testfloat-3 became mandatory. I
think in the past I was able to ignore this submodule and not export it, so the
following error di
From: Fan Ni
The patch series provides dynamic capacity device (DCD) emulation in Qemu.
More specifically, it provides the following functionalities:
1. Extended type3 memory device to support DC regions and extents.
2. Implemented DCD related mailbox command support in CXL r3.0: 8.2.9.8.9.
3. AD
On Mon, Jul 17, 2023 at 11:29:56PM +0700, Bui Quang Minh wrote:
> On 7/17/23 17:47, Joao Martins wrote:
> > +Peter, +Jason (intel-iommu maintainer/reviewer)
Thanks for copying me, Joan.
> >
> > On 15/07/2023 16:22, Bui Quang Minh wrote:
> > > As userspace APIC now supports x2APIC, intel interrup
From: Fan Ni
Add dynamic capacity extent list representative to the definition of
CXLType3Dev and add get DC extent list mailbox command per
CXL.spec.3.0:.8.2.9.8.9.2.
Signed-off-by: Fan Ni
---
hw/cxl/cxl-mailbox-utils.c | 71 +
hw/mem/cxl_type3.c
From: Fan Ni
Per CXL spec 3.0, two mailbox commands are implemented:
Add Dynamic Capacity Response (Opcode 4802h) 8.2.9.8.9.3, and
Release Dynamic Capacity (Opcode 4803h) 8.2.9.8.9.4.
Signed-off-by: Fan Ni
---
hw/cxl/cxl-mailbox-utils.c | 253
include/hw/c
From: Fan Ni
With the change, when setting up memory for type3 memory device, we can
create DC regions
A property 'num-dc-regions' is added to ct3_props to allow users to pass the
number of DC regions to create. To make it easier, other region parameters
like region base, length, and block size a
From: Fan Ni
Rename mem_size as static_mem_size for type3 memdev to cover static RAM and
pmem capacity, preparing for the introduction of dynamic capacity to support
dynamic capacity devices.
Signed-off-by: Fan Ni
---
hw/cxl/cxl-mailbox-utils.c | 5 +++--
hw/mem/cxl_type3.c | 8 -
From: Fan Ni
Since fabric manager emulation is not supported yet, the change implements
the functions to add/release dynamic capacity extents as QMP interfaces.
1. Add dynamic capacity extents:
For example, the command to add two continuous extents (each is 128MB long)
to region 0 (starting at
From: Fan Ni
Not all dpa range in the dc regions is valid to access until an extent
covering the range has been added. Add a bitmap for each region to
record whether a dc block in the region has been backed by dc extent.
For the bitmap, a bit in the bitmap represents a dc block. When a dc
extent
From: Fan Ni
Per cxl spec 3.0, add dynamic capacity region representative based on
Table 8-126 and extend the cxl type3 device definition to include dc region
information. Also, based on info in 8.2.9.8.9.1, add 'Get Dynamic Capacity
Configuration' mailbox support.
Signed-off-by: Fan Ni
---
hw
From: Fan Ni
Add (file/memory backed) host backend, all the dynamic capacity regions
will share a single, large enough host backend. Set up address space for
DC regions to support read/write operations to dynamic capacity for DCD.
With the change, following supports are added:
1. add a new prope
From: Fan Ni
Based on CXL spec 3.0 Table 8-94 (Identify Memory Device Output
Payload), dynamic capacity event log size should be part of
output of the Identify command.
Add dc_event_log_size to the output payload for the host to get the info.
Signed-off-by: Fan Ni
---
hw/cxl/cxl-mailbox-utils.
On Tue, Jul 18, 2023 at 01:25:12PM +, Wang, Wei W wrote:
> On Tuesday, July 18, 2023 1:44 PM, Isaku Yamahata wrote:
> > > --- a/migration/migration.c
> > > +++ b/migration/migration.c
> > > @@ -2058,6 +2058,21 @@ static int
> > await_return_path_close_on_source(MigrationState *ms)
> > > re
This enables wrapper devices to customize the base device's CCI
(for example, with custom commands outside the specification)
without the need to change the base device.
The also enabled the base device to dispatch those commands without
requiring additional driver support.
Signed-off-by: Gregory
This allows devices to have fully customized CCIs, along with complex
devices where wrapper devices can override or add additional CCI
commands without having to replicate full command structures or
pollute a base device with every command that might ever be used.
Signed-off-by: Gregory Price
--
On Thu, Jul 06, 2023 at 12:48:20PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Bennée wrote:
> > Currently QEMU has to know some details about the back-end to be able
> > to setup the guest. While various parts of the setup can be delegated
> > to the backend (
This is on top of the proposed CCI changes by Jonathan.
Base repo: https://gitlab.com/jic23/qemu
Base branch: cxl-2023-07-17
A proposal to make the CCI cmd sets full members of their device,
and copy the const struct entries instead of referencing them.
This would allow child devices to inherit
On Thu, Jul 20, 2023 at 01:18:33PM +0100, Jonathan Cameron wrote:
> On Wed, 19 Jul 2023 14:49:07 -0400
> Gregory Price wrote:
>
> >
> > Maybe a dangerous suggestion. Right now the CCI's are static:
> >
> > static const struct cxl_cmd cxl_cmd_set[256][256]
>
> That's defined by the ID space fo
On Fri, Jul 07, 2023 at 12:27:39PM +0200, Stefano Garzarella wrote:
> On Tue, Jul 04, 2023 at 04:02:42PM +0100, Alex Bennée wrote:
> >
> > Stefano Garzarella writes:
> >
> > > On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Bennée wrote:
> > > > diff --git a/docs/interop/vhost-user.rst b/docs/int
On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Bennée wrote:
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index c4e0cbd702..28b021d5d3 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -202,6 +202,13 @@ typedef struct VhostUserInflight {
> uint16_t q
On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Bennée wrote:
> Currently QEMU has to know some details about the back-end to be able
> to setup the guest. While various parts of the setup can be delegated
> to the backend (for example config handling) this is a very piecemeal
> approach.
>
> This
Hi,
I'm ready to merge this but encountered a bug when testing:
$ qemu-system-x86_64 --device ufs --device ufs-lu
Segmentation fault (core dumped)
Please ensure there is an error message like with SCSI disks:
$ qemu-system-x86_64 --device virtio-scsi-pci --device scsi-hd
qemu-system-x86_
On Tue, Jul 04, 2023 at 01:06:24AM -0700, Mattias Nissler wrote:
> This series adds basic support for message-based DMA in qemu's vfio-user
> server. This is useful for cases where the client does not provide file
> descriptors for accessing system memory via memory mappings. My motivating use
> ca
On Tue, Jul 04, 2023 at 01:06:27AM -0700, Mattias Nissler wrote:
> Wire up support for DMA for the case where the vfio-user client does not
> provide mmap()-able file descriptors, but DMA requests must be performed
> via the VFIO-user protocol. This installs an indirect memory region,
> which alrea
Some dynamic state of a virtio-net vDPA devices is restored from CVQ in
the event of a live migration. However, dataplane needs to be disabled
so the NIC does not receive buffers in the invalid ring.
As a default method to achieve it, let's offer a shadow vring with 0
avail idx. As a fallback me
Split out vq restart operation in its own function, as it may be called
with ring reset.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 24
1 file changed, 24 insertions(+)
diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
index 7248072989..7b24fa3
This is needed to let CVQ restore at the beginning.
Not properly tested with actual guest ring reset, only with the reset
from qemu. For this to be included, more test is needed, but this series
is a good start for it.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-shadow-virtqueue.c | 1 +
1
At this moment the migration of net features that depends on CVQ is not
possible, as there is no reliable way to restore the device state like mac
address, number of enabled queues, etc to the destination. This is mainly
caused because the device must only read CVQ, and process all the commands
be
So different vhost backends can perform custom actions at queue restart.
Signed-off-by: Eugenio Pérez
---
include/hw/virtio/vhost-backend.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/hw/virtio/vhost-backend.h
b/include/hw/virtio/vhost-backend.h
index 37e05fa1f9..651402af10 1
To split each SVQ stop in its own stop routine let's us to reset a VQ
individually, and to keep future vhost_vdpa_reset_queue symmetrical
with vhost_vdpa_reset_queue.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(
Prefer the ring reset approach against the late enable, as it is more
aligned with the standard.
Signed-off-by: Eugenio Pérez
---
net/vhost-vdpa.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index 52415d7e0c..af83de92f8 100644
--- a/net/vhost-vdp
Split out vq reset operation in its own function, as it may be called
with ring reset.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
index 6ae276ccde..df2515a247 100644
Reset a virtqueue reuses this call with .num = 0, so let's make it
possible to use that way.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 12 +---
hw/virtio/trace-events | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/virtio/vhost-vdpa.c b/hw/virt
To split each SVQ in its own initialization routine let's us to restart
a VQ individually, and to keep future vhost_vdpa_restart_queue
symmetrical with vhost_vdpa_reset_queue.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 67 ++
1 file changed,
Actually use vhost_reset_queue operation at queue reset.
Signed-off-by: Eugenio Pérez
---
hw/net/vhost_net.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index 416b7d8132..5516b7a5aa 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vh
Actually use vhost_restart_queue operation at restart.
Signed-off-by: Eugenio Pérez
---
hw/net/vhost_net.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index 6b958d6363..416b7d8132 100644
--- a/hw/net/vhost_net.c
+++ b/h
So different vhost backends can perform custom actions at queue reset.
Signed-off-by: Eugenio Pérez
---
include/hw/virtio/vhost-backend.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/hw/virtio/vhost-backend.h
b/include/hw/virtio/vhost-backend.h
index 31a251a9f5..37e05fa1f9 100
On Tue, Jul 04, 2023 at 01:06:25AM -0700, Mattias Nissler wrote:
> +if (qatomic_dec_fetch(&bounce_buffers_in_use) == 1) {
> +cpu_notify_map_clients();
> }
About my comment regarding removing this API: I see the next patch does
that.
Stefan
signature.asc
Description:
On Tue, Jul 04, 2023 at 01:06:26AM -0700, Mattias Nissler wrote:
> According to old commit messages, this was introduced to retry a DMA
> operation at a later point in case the single bounce buffer is found to
> be busy. This was never used widely - only the dma-helpers code made use
> of it, but t
On Tue, Jul 04, 2023 at 01:06:25AM -0700, Mattias Nissler wrote:
> It is not uncommon for device models to request mapping of several DMA
> regions at the same time. An example is igb (and probably other net
> devices as well) when a packet is spread across multiple descriptors.
>
> In order to su
On 7/14/23 03:09, Joelle van Dyne wrote:
TPM needs to know its own base address in order to generate its DSDT
device entry.
Signed-off-by: Joelle van Dyne
It would be great to also cover the crb-device with tests:
from tests/qtest/meson.build:
(config_all.has_key('CONFIG_TCG') and
c
The test in tests/avocado/machine_loongarch.py is currently failing
on big endian hosts like s390x. By comparing the traces between running
the QEMU_EFI.fd bios on a s390x and on a x86 host, it's quickly obvious
that the CSRRD instruction for the CPUID is behaving differently. And
indeed: The code
Use a macro in riscv_cpu_add_kvm_properties() to eliminate some of its
code repetition, similar to what we're already doing with
ADD_CPU_QDEV_PROPERTIES_ARRAY().
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 22 ++
1 file changed, 10 insertions(+), 12 deleti
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 tha
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 b/te
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
Reviewed-by: Weiwei Li
---
target/riscv/cpu.c | 26 +++---
1 file changed, 11 insertions(+), 15 delet
This last blank element is used by the 'for' loop to check if a property
has a valid name.
Remove it and use ARRAY_SIZE() instead like riscv_cpu_options is already
using. All future arrays will also do the same and we'll able to
encapsulate more repetitions in macros later on.
Signed-off-by: Dani
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() and riscv_cpu_add_kvm_properties()
accordingly.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Alistair Francis
Hi,
I'm sending this new version based on another observation I made during
another follow-up work (I'll post it shortly).
'mmu' and 'pmp' aren't really extensions in the most tradicional sense,
they're more like features. So, in patch 1, I moved both to the new
riscv_cpu_options array.
This was
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
Reviewed-by: Alistair Francis
---
target/riscv/cpu.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
dif
The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU
Core Definition"), being around since the beginning. It's not an easy
CPU to use: it's undocumented and its name doesn't tell users much about
what the CPU is supposed to bring. 'git log' doesn't help us either in
knowing what w
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[].
riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are
changed to keep adding non-ratified properties to users.
Signed
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 prope
Future patches will split the existing Property arrays even further, and
the existing code in riscv_cpu_add_user_properties() will start to scale
bad with it because it's dealing with KVM constraints mixed in with TCG
constraints. We're going to pay a high price to share a couple of common
lines of
On Thu, Jul 20, 2023 at 07:05:40PM +0300, Yuri Benditovich wrote:
>
>
> On Thu, Jul 20, 2023 at 3:37 AM Akihiko Odaki
> wrote:
>
> On 2023/07/20 0:21, Yuri Benditovich wrote:
> > virtio-net can suggest USO features TX, RX v4 and RX v6,
> > depending on kernel TUN ability to support
On Wed, 19 Jul 2023 at 16:56, Jean-Philippe Brucker
wrote:
>
> When FEAT_RME is implemented, these bits override the value of
> CNT[VP]_CTL_EL0.IMASK in Realm and Root state.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> target/arm/helper.c | 21 +++--
> 1 file changed, 19 ins
On Wed, 19 Jul 2023 at 16:56, Jean-Philippe Brucker
wrote:
>
> At the moment we only handle Secure and Nonsecure security spaces for
> the AT instructions. Add support for Realm and Root.
>
> For AArch64, arm_security_space() gives the desired space. ARM DDI0487J
> says (R_NYXTL):
>
> If EL3 is
On Thu, Jul 20, 2023 at 04:00:24PM +0200, Hanna Czenczek wrote:
> For image creation code, we have central fallback code for protocols
> that do not support creating new images (like NBD or iscsi). So for
> them, you can only specify existing paths/exports that are overwritten
> to make clean new
On 7/20/23 18:45, Peter Maydell wrote:
On Thu, 20 Jul 2023 at 17:42, Cédric Le Goater wrote:
On 7/20/23 17:59, Peter Maydell wrote:
In the aspeed_rtc device we store a difference between two time_t
values in an 'int'. This is not really correct when time_t could
be 64 bits. Enlarge the field
On Thu, 20 Jul 2023 at 17:39, Peter Maydell wrote:
>
> On Wed, 19 Jul 2023 at 16:56, Jean-Philippe Brucker
> wrote:
> >
> > GPC checks are not performed on the output address for AT instructions,
> > as stated by ARM DDI 0487J in D8.12.2:
> >
> > When populating PAR_EL1 with the result of an ad
On Thu, 20 Jul 2023 at 17:42, Cédric Le Goater wrote:
>
> On 7/20/23 17:59, Peter Maydell wrote:
> > In the aspeed_rtc device we store a difference between two time_t
> > values in an 'int'. This is not really correct when time_t could
> > be 64 bits. Enlarge the field to 'int64_t'.
> >
> > This i
On 7/20/23 17:59, Peter Maydell wrote:
In the aspeed_rtc device we store a difference between two time_t
values in an 'int'. This is not really correct when time_t could
be 64 bits. Enlarge the field to 'int64_t'.
This is a migration compatibility break for the aspeed boards.
While we are changi
On Wed, 19 Jul 2023 at 16:56, Jean-Philippe Brucker
wrote:
>
> GPC checks are not performed on the output address for AT instructions,
> as stated by ARM DDI 0487J in D8.12.2:
>
> When populating PAR_EL1 with the result of an address translation
> instruction, granule protection checks are not
On Wed, 19 Jul 2023 at 16:56, Jean-Philippe Brucker
wrote:
>
> When HCR_EL2.E2H is enabled, TLB entries are formed using the EL2&0
> translation regime, instead of the EL2 translation regime. The TLB VAE2*
> instructions invalidate the regime that corresponds to the current value
> of HCR_EL2.E2H.
On Wed, 19 Jul 2023 at 16:56, Jean-Philippe Brucker
wrote:
>
> In realm state, stage-2 translation tables are fetched from the realm
> physical address space (R_PGRQD).
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> target/arm/ptw.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
From: Hyman Huang(黄勇)
Add migration dirty-limit capability test if kernel support
dirty ring.
Migration dirty-limit capability introduce dirty limit
capability, two parameters: x-vcpu-dirty-limit-period and
vcpu-dirty-limit are introduced to implement the live
migration with dirty limit.
The te
From: Hyman Huang(黄勇)
Check if block migration is running before throttling
guest down in auto-converge way.
Note that this modification is kind of like code clean,
because block migration does not depend on auto-converge
capability, so the order of checks can be adjusted.
Signed-off-by: Hyman
From: Hyman Huang(黄勇)
Extend query-migrate to provide throttle time and estimated
ring full time with dirty-limit capability enabled, through which
we can observe if dirty limit take effect during live migration.
Signed-off-by: Hyman Huang(黄勇)
Reviewed-by: Markus Armbruster
Reviewed-by: Juan Q
From: Hyman Huang(黄勇)
Introduce migration dirty-limit capability, which can
be turned on before live migration and limit dirty
page rate durty live migration.
Introduce migrate_dirty_limit function to help check
if dirty-limit capability enabled during live migration.
Meanwhile, refactor vcpu_d
From: Hyman Huang(黄勇)
Introduce "vcpu-dirty-limit" migration parameter used
to limit dirty page rate during live migration.
"vcpu-dirty-limit" and "x-vcpu-dirty-limit-period" are
two dirty-limit-related migration parameters, which can
be set before and during live migration by qmp
migrate-set-pa
1 - 100 of 227 matches
Mail list logo
