This patch includes:
- XVLD[X], XVST[X];
- XVLDREPL.{B/H/W/D};
- XVSTELM.{B/H/W/D}.
Signed-off-by: Song Gao
Reviewed-by: Richard Henderson
Message-Id: <20230914022645.1151356-56-gaos...@loongson.cn>
---
target/loongarch/insns.decode | 18 ++
target/loongarch/disas.c
On 9/20/2023 2:33 PM, Chen, Jiqian wrote:
Hi Lingshan,
On 2023/9/20 13:59, Zhu, Lingshan wrote:
On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote:
On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
When guest vm does S3, Qemu will reset and clear some things of virtio
devices, but
On 9/20/2023 2:58 PM, Parav Pandit wrote:
From: Chen, Jiqian
Sent: Wednesday, September 20, 2023 12:03 PM
If driver write 0 to reset device, can the SUSPEND bit be cleared?
It must as reset operation, resets everything else and so the suspend too.
(pci_pm_resume->virtio_pci_restore->virtio
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 12:37 PM
> > The problem to overcome in [1] is, resume operation needs to be synchronous
> as it involves large part of context to resume back, and hence just
> asynchronously setting DRIVER_OK is not enough.
> > The sw must verify back
Hi Alex,
On 9/19/23 17:44, Alex Williamson wrote:
> On Wed, 13 Sep 2023 10:01:38 +0200
> Eric Auger wrote:
>
>> Collect iova range information if VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE
>> capability is supported.
>>
>> This allows to propagate the information though the IOMMU MR
>> set_iova_ranges(
Hi Lingshan,
On 2023/9/20 14:58, Zhu, Lingshan wrote:
>
>
> On 9/20/2023 2:33 PM, Chen, Jiqian wrote:
>> Hi Lingshan,
>>
>> On 2023/9/20 13:59, Zhu, Lingshan wrote:
>>>
>>> On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote:
On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
> Whe
Hi Lingshan,
It seems you reply to the wrong email thread. They are not related to my patch.
On 2023/9/20 15:06, Zhu, Lingshan wrote:
>
>
> On 9/20/2023 2:58 PM, Parav Pandit wrote:
>>> From: Chen, Jiqian
>>> Sent: Wednesday, September 20, 2023 12:03 PM
>>> If driver write 0 to reset device, ca
Hi Alex,
On 9/19/23 18:29, Alex Williamson wrote:
> On Wed, 13 Sep 2023 10:01:41 +0200
> Eric Auger wrote:
>
>> This helper reverses an array of regions, turning original
>> regions into holes and original holes into actual regions,
>> covering the whole UINT64_MAX span.
>>
>> Signed-off-by: Eric
On 9/20/2023 3:10 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 12:37 PM
The problem to overcome in [1] is, resume operation needs to be synchronous
as it involves large part of context to resume back, and hence just
asynchronously setting DRIVER_OK is not
Hi Alex,
On 9/19/23 19:22, Alex Williamson wrote:
> On Wed, 13 Sep 2023 10:01:47 +0200
> Eric Auger wrote:
>
>> Now we retrieve the usable IOVA ranges from the host,
>> we now the physical IOMMU aperture and we can remove
>> the assumption of 64b IOVA space when calling
>> vfio_host_win_add().
>>
On 9/20/2023 3:24 PM, Chen, Jiqian wrote:
Hi Lingshan,
It seems you reply to the wrong email thread. They are not related to my patch.
These reply to Parva's comments.
@Parva, if you want to discuss more about live migration, please reply
in my thread, lets don't flood here.
On 2023/9/20 1
Xiaoyao Li writes:
> On 9/19/2023 5:46 PM, Markus Armbruster wrote:
>> Xiaoyao Li writes:
>>
>>> From: Isaku Yamahata
>>>
>>> Add a new property "private" to memory backends. When it's set to true,
>>> it indicates the RAMblock of the backend also requires kvm gmem.
>> Can you add a brief expl
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 12:58 PM
>
> On 9/20/2023 3:10 PM, Parav Pandit wrote:
> >> From: Zhu, Lingshan
> >> Sent: Wednesday, September 20, 2023 12:37 PM
> >>> The problem to overcome in [1] is, resume operation needs to be
> >>> synchronous
> >> as it invol
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 1:00 PM
>
> On 9/20/2023 3:24 PM, Chen, Jiqian wrote:
> > Hi Lingshan,
> > It seems you reply to the wrong email thread. They are not related to my
> patch.
> These reply to Parva's comments.
> @Parva, if you want to discuss more about
Hi Cédric,
On 9/13/23 14:55, Cédric Le Goater wrote:
> On 9/13/23 10:01, Eric Auger wrote:
>> Collect iova range information if VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE
>> capability is supported.
>>
>> This allows to propagate the information though the IOMMU MR
>> set_iova_ranges() callback so that
Hi Alex,
On 9/19/23 17:44, Alex Williamson wrote:
> On Wed, 13 Sep 2023 10:01:38 +0200
> Eric Auger wrote:
>
>> Collect iova range information if VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE
>> capability is supported.
>>
>> This allows to propagate the information though the IOMMU MR
>> set_iova_ranges(
Hi Cedric,
On 9/13/23 14:43, Cédric Le Goater wrote:
> On 9/13/23 10:01, Eric Auger wrote:
>> This helper will allow to convey information about valid
>> IOVA ranges to virtual IOMMUS.
>>
>> Signed-off-by: Eric Auger
>
>
> Reviewed-by: Cédric Le Goater
Thanks!
Eric
>
> Thanks,
>
> C.
>
>> ---
>
On 9/20/2023 3:17 PM, Chen, Jiqian wrote:
Hi Lingshan,
On 2023/9/20 14:58, Zhu, Lingshan wrote:
On 9/20/2023 2:33 PM, Chen, Jiqian wrote:
Hi Lingshan,
On 2023/9/20 13:59, Zhu, Lingshan wrote:
On 9/19/2023 8:31 PM, Michael S. Tsirkin wrote:
On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqia
On 9/20/2023 3:32 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 12:58 PM
On 9/20/2023 3:10 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 12:37 PM
The problem to overcome in [1] is, resume operation needs to be
synchrono
On 9/20/2023 3:35 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 1:00 PM
On 9/20/2023 3:24 PM, Chen, Jiqian wrote:
Hi Lingshan,
It seems you reply to the wrong email thread. They are not related to my
patch.
These reply to Parva's comments.
@Parva, if you w
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 1:16 PM
[..]
> > In my view, setting the DRIVER_OK is the signal regardless of hypervisor or
> physical device.
> > Hence the re-read is must.
> Yes, as I said below, should verify by re-read.
> >
Thanks.
Hi Stephen,
Like you have said the reason is as I wrote in the commit message,
without "fixing" the vaddr GDB is messing up mapping and working with
the generated core file.
This patch is almost 4 years old, perhaps some changes to GDB has been
introduced to resolve this, I have not checked
> From: Zhu, Lingshan
> Sent: Wednesday, September 20, 2023 1:17 PM
> > This is not live or device migration. This is restoring the device context
> initiated by the driver owning the device.
> restore the device context should be done by the hypervisor before setting
> DRIVER_OK and waking up t
Hi Lingshan,
Please reply to your own email thread, below are not related to my patches.
Thanks a lot.
On 2023/9/20 15:47, Zhu, Lingshan wrote:
>
>
> On 9/20/2023 3:35 PM, Parav Pandit wrote:
>>> From: Zhu, Lingshan
>>> Sent: Wednesday, September 20, 2023 1:00 PM
>>>
>>> On 9/20/2023 3:24 PM,
On Sat, Sep 16, 2023 at 12:48:14AM +0800, Akihiko Odaki wrote:
> On 2023/09/15 20:11, Huang Rui wrote:
> > From: Antonio Caggiano
> >
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map resource IDs to their
> > UUIDs.
>
On 9/20/2023 3:51 PM, Parav Pandit wrote:
From: Zhu, Lingshan
Sent: Wednesday, September 20, 2023 1:17 PM
This is not live or device migration. This is restoring the device context
initiated by the driver owning the device.
restore the device context should be done by the hypervisor before
Hi Jiquian,
> From: Chen, Jiqian
> Sent: Wednesday, September 20, 2023 1:24 PM
>
> Hi Lingshan,
> Please reply to your own email thread, below are not related to my patches.
> Thanks a lot.
They are related to your patch.
Both the patches have overlapping functionalities.
You probably missed
On Tue, Sep 19, 2023 at 04:17:43PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 6:16 PM Huang Rui wrote:
> >
> > Configure context init feature flag for virglrenderer.
> >
> > Originally-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> > V4 -> V5:
> > - In
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 already works for pci_dma_{read,write}, and pci_dma_map works
thanks to the ex
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
case is to hook up device models as PCIe endpoints to a hardware design. Th
Brings in assorted bug fixes. The following are of particular interest
with respect to message-based DMA support:
* bb308a2 "Fix address calculation for message-based DMA"
Corrects a bug in DMA address calculation.
* 1569a37 "Pass server->client command over a separate socket pair"
Adds suppo
Instead of using a single global bounce buffer, give each AddressSpace
its own bounce buffer. The MapClient callback mechanism moves to
AddressSpace accordingly.
This is in preparation for generalizing bounce buffer handling further
to allow multiple bounce buffers, with a total allocation limit
c
PCI config space is little-endian, so on a big-endian host we need to
perform byte swaps for values as they are passed to and received from
the generic PCI config space access machinery.
Signed-off-by: Mattias Nissler
---
hw/remote/vfio-user-obj.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
When DMA memory can't be directly accessed, as is the case when
running the device model in a separate process without shareable DMA
file descriptors, bounce buffering is used.
It is not uncommon for device models to request mapping of several DMA
regions at the same time. Examples include:
* net
On 2023/9/20 15:56, Parav Pandit wrote:
> Hi Jiquian,
>
>> From: Chen, Jiqian
>> Sent: Wednesday, September 20, 2023 1:24 PM
>>
>> Hi Lingshan,
>> Please reply to your own email thread, below are not related to my patches.
>> Thanks a lot.
>
> They are related to your patch.
> Both the patche
From: Marc-André Lureau
If the fwcfg is written several times (without surface being displayed
in the meantime), we may leak surfaces.
Signed-off-by: Marc-André Lureau
---
hw/display/ramfb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/display/ramfb.c b/hw/display/ramfb.c
index 4cd90
From: Marc-André Lureau
Implementing RAMFB migration seems quite straightforward. Unfortunately,
current QEMU didn't block migration when RAMFB was used.
Having an extra "ramfb" VMState doesn't seem to "break" migration
forward compatibility. Surprisingly, missing sections are being ignored?
Ba
On Tue, Sep 19, 2023 at 04:44:01PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 3:14 PM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Support BLOB resources creation, mapping and unmapping by calling the
> > new stable virglrenderer 0.10 interface. Only enabled when
>-Original Message-
>From: Cédric Le Goater
>Sent: Wednesday, September 20, 2023 1:24 AM
>Subject: Re: [PATCH v1 13/22] vfio: Add base container
>
>On 8/30/23 12:37, Zhenzhong Duan wrote:
>> From: Yi Liu
>>
>> Abstract the VFIOContainer to be a base object. It is supposed to be
>> embed
On 20/9/23 01:18, Akihiko Odaki wrote:
On 2023/09/19 23:21, Xenia Ragiadakou wrote:
On 19/9/23 13:44, Akihiko Odaki wrote:
On 2023/09/19 19:28, Xenia Ragiadakou wrote:
On 15/9/23 18:11, Akihiko Odaki wrote:
On 2023/09/15 20:11, Huang Rui wrote:
From: Xenia Ragiadakou
When the memory re
From: Li Zhijian
Previously, we got a confusion error that complains
the RDMAControlHeader.repeat:
qemu-system-x86_64: rdma: Too many requests in this message
(3638950032).Bailing.
Actually, it's caused by an unexpected RDMAControlHeader.type.
After this patch, error will become:
qemu-system-x8
From: Li Zhijian
Destination will fail with:
qemu-system-x86_64: rdma: Too many requests in this message
(3638950032).Bailing.
migrate with RDMA is different from tcp. RDMA has its own control
message, and all traffic between RDMA_CONTROL_REGISTER_REQUEST and
RDMA_CONTROL_REGISTER_FINISHED shou
On Wed, Sep 20, 2023 at 07:46:36AM +0300, Michael Tokarev wrote:
> Hi!
>
> I'm in somewhat doubt what to do with 8.1.1 release.
>
> There are 2 compelling issues, fixing one discovers the other.
>
> https://gitlab.com/qemu-project/qemu/-/issues/1864
> "x86 VM with TCG and SMP fails to start on 8
We should free opts allocated through qemu_opts_create() at the end.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/parallels.c b/block/parallels.c
index 428f72de1c..af7be427c9 100644
--- a/block/parall
Since
commit cfce1091d55322789582480798a891cbaf66924e
Author: Alexander Ivanov
Date: Tue Jul 18 12:44:29 2023 +0200
parallels: Image repairing in parallels_open()
there is a potential pit fall with calling
qemu-io -c "read"
The image is opened in read-write mode and thus coul
We do not need to perform any deallocation/cleanup if wrong format is
detected.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/parallels.c b/block/parallels.c
index ae006e7fc7..12f38cf
Replace 'space' representing the amount of data to preallocate with
'bytes'.
Rationale:
* 'space' at each place is converted to bytes
* the unit is more close to the variable name
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 13 +
1 file chang
This patch contains test which minimally tests write-zeroes on top of
working discard.
The following checks are added:
* write 2 clusters, write-zero to the first allocated cluster
* write 2 cluster, write-zero to the half the first allocated cluster
Signed-off-by: Denis V. Lunev
Reviewed-by: Al
We have only check through self-repair and that proven to be not enough.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
tests/qemu-iotests/tests/parallels-checks | 17 +
tests/qemu-iotests/tests/parallels-checks.out | 18 ++
2 files changed,
If the operation is failed, we need to check image consistency if the
problem is not about memory allocation.
Bitmap adjustments in allocate_cluster are not performed yet.
They worth to be separate. This was proven useful during debug of this
series. Kept as is for future bissecting.
It should be
The following changes since commit 4907644841e3200aea6475c0f72d3d987e9f3d93:
Merge tag 'mem-2023-09-19' of https://github.com/davidhildenbrand/qemu into
staging (2023-09-19 13:22:19 -0400)
are available in the Git repository at:
https://src.openvz.org/scm/~den/qemu.git tags/pull-parallels-2
The zero flag is missed in the Parallels format specification. We can
resort to discard if we have no backing file.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/block/parallels.c b/block/par
We should extend the bitmap if the file is extended and set the bit in
the image used bitmap once the cluster is allocated. Sanity check at
that moment also looks like a good idea.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 14 ++
1 file chan
Parallels driver indeed support Parallels Dirty Bitmap Feature in
read-only mode. The patch adds bdrv_supports_persistent_dirty_bitmap()
callback which always return 1 to indicate that.
This will allow to copy CBT from Parallels image with qemu-img.
Note: read-write support is signalled through
b
This functionality is used twice already and next patch will add more
code with it.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/block/parallels.c b/block
The test is quite similar with the original one for duplicated clusters.
There is the only difference in the operation which should fix the
image.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
tests/qemu-iotests/tests/parallels-checks | 36 +++
tests/qemu-i
Old code is ugly and contains tabulations. There are no functional
changes in this patch.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/block/parallels.
More conditions follows thus the check should be more scalable.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/block/parallels.c b/block/parallels.c
index bd26c8db63..a
Once we have repaired data_off field in the header we should update
s->data_start which is calculated on the base of it.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/parallels.c b/block/parallels.c
in
This patch contains test which minimally tests discard and new cluster
allocation logic.
The following checks are added:
* write 2 clusters, discard the first allocated
* write another cluster, check that the hole is filled
* write 2 clusters, discard the first allocated, write 1 cluster at
non-
At the beginning of the function we can return immediately until we
really allocate s->header.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/block/parallels.c b/block/parallels
This patch creates above mentioned helper and moves its usage to the
beginning of parallels_open(). This simplifies parallels_open() a bit.
The patch also ensures that we store prealloc_size on block driver state
always in sectors. This makes code cleaner and avoids wrong opinion at
the assignment
* Discarding with backing stores is not supported by the format.
* There is no buffering/queueing of the discard operation.
* Only operations aligned to the cluster are supported.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 46
Original check is broken as supposed reading from 2 different clusters
results in read from the same file offset twice. This is definitely
wrong.
We should be sure that
* the content of both clusters is correct after repair
* clusters are at the different offsets after repair
In order to check the
This would be useful in the next patch in allocate_clusters(). This
change would not imply serious performance drawbacks as usually image
is full of data or are at the end of the bitmap.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 18 ++
1
The access to the bitmap is not optimized completely.
Signed-off-by: Denis V. Lunev
Reviewed-by: Alexander Ivanov
---
block/parallels.c | 51 ---
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/block/parallels.c b/block/parallels.c
ind
On Tue, Sep 19, 2023 at 05:00:05PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 3:14 PM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map resourc
On 15/09/2023 19:31, William Roche wrote:
> On 9/15/23 05:13, Zhijian Li (Fujitsu) wrote:
>>
>>
>> I'm okay with "RDMA isn't touched".
>> BTW, could you share your reproducing program/hacking to poison the page, so
>> that
>> i am able to take a look the RDMA part later when i'm free.
>>
>> Not
On Tue, Sep 19, 2023 at 05:02:36PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Fri, Sep 15, 2023 at 3:14 PM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Add support for the Venus capset, which enables Vulkan support through
> > the Venus Vulkan driver for virtio-gpu.
> >
> > Signed-of
On 2023/09/20 17:57, Xenia Ragiadakou wrote:
On 20/9/23 01:18, Akihiko Odaki wrote:
On 2023/09/19 23:21, Xenia Ragiadakou wrote:
On 19/9/23 13:44, Akihiko Odaki wrote:
On 2023/09/19 19:28, Xenia Ragiadakou wrote:
On 15/9/23 18:11, Akihiko Odaki wrote:
On 2023/09/15 20:11, Huang Rui wrote:
Nina Schoetterl-Glausch writes:
> On Tue, 2023-09-19 at 14:47 +0200, Markus Armbruster wrote:
>> Nina Schoetterl-Glausch writes:
>>
>> > From: Pierre Morel
>> >
>> > S390 adds two new SMP levels, drawers and books to the CPU
>> > topology.
>> > S390 CPUs have specific topology features like d
On 9/15/23 05:02, Duan, Zhenzhong wrote:
> Hi Eric,
>
>> -Original Message-
>> From: Eric Auger
>> Sent: Thursday, September 14, 2023 10:46 PM
>> Subject: Re: [PATCH v1 02/22] Update linux-header to support iommufd cdev and
>> hwpt alloc
>>
>> Hi Zhenzhong,
>>
>> On 8/30/23 12:37, Zhenz
Nina Schoetterl-Glausch writes:
> From: Pierre Morel
>
> S390 adds two new SMP levels, drawers and books to the CPU
> topology.
> S390 CPUs have specific topology features like dedication and
> entitlement. These indicate to the guest information on host
> vCPU scheduling and help the guest make
On 18/09/2023 23:00, William Roche wrote:
> Hi John,
>
> I'd like to put the emphasis on the fact that ignoring the SRAO error
> for a VM is a real problem at least for a specific (rare) case I'm
> currently working on: The VM migration.
>
> Context:
>
> - In the case of a poisoned page in the V
Nina Schoetterl-Glausch writes:
> From: Pierre Morel
>
> 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
> Reviewed-by: Nina Schoetterl-Glausch
> Co-developed-by: Nina Schoetterl-Glau
>-Original Message-
>From: Eric Auger
>Sent: Wednesday, September 20, 2023 7:05 PM
>Subject: Re: [PATCH v1 02/22] Update linux-header to support iommufd cdev and
>hwpt alloc
>
>
>
>On 9/15/23 05:02, Duan, Zhenzhong wrote:
>> Hi Eric,
>>
>>> -Original Message-
>>> From: Eric Auger
We'll need to export these arrays to the accelerator classes in the next
patches. Mark them as 'const' now because they should not be modified at
runtime.
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_s
Move the remaining of riscv_tcg_ops now that we have a working realize()
implementation.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Andrew Jones
Reviewed-by: LIU Zhiwei
---
target/riscv/cpu.c | 58
targe
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 isa
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 f
This file is not needed for some time now. Both kvm_riscv_reset_vcpu()
and kvm_riscv_set_irq() have public declarations in kvm_riscv.h and are
wrapped in 'if kvm_enabled()' blocks that the compiler will rip it out
in non-KVM builds.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/kvm-stu
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
Reviewed-by: Andrew Jones
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 proper
This CPU only exists if we're compiling with KVM so move it to the kvm
specific file.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Andrew Jones
Reviewed-by: LIU Zhiwei
---
target/riscv/cpu.c | 15 ---
target/riscv/kvm.c | 21 +
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
Reviewed-by: Andrew Jones
---
target/riscv/cpu.c | 90 ---
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 finish it with an empty element since ARRAY_SIZE()
won't work outside of cpu.c.
We'll move riscv_init_max_cpu_extensions() to tcg-cpu.c in the next
patch and set_misa() needs to be usable from there.
Rename it to riscv_cpu_set_misa() and make it public.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Andrew Jones
---
target/riscv/c
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() a
Priv spec validation is TCG specific. Move it to the TCG accel class.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
---
target/riscv/cpu.c | 38 --
target/riscv/cpu.h | 2 --
target/riscv/tcg/tcg-cpu.c | 38
This function is used for both accelerators. Make it public, and call it
from kvm_riscv_cpu_add_kvm_properties(). This will make it easier to
split KVM specific code for the KVM accelerator class in the next patch.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Andrew Jones
Reviewed-by: LIU
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 CPU
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 riscv_cpu_add_misa_properties(
Hi Zhenzhong,
On 8/30/23 12:37, Zhenzhong Duan wrote:
> From: Eric Auger
>
> Introduce helper functions that isolate the code used for
> VFIO_SPAPR_TCE_v2_IOMMU. This code reliance is IOMMU backend
> specific whereas the rest of the code in the callers, ie.
this last sentence should be rephrased i
The array isn't marked as 'const' because we're initializing their
elements in riscv_cpu_add_misa_properties(), 'name' and 'description'
fields.
In a closer look we can see that we're not using these 2 fields after
creating the MISA properties. And we can create the properties by using
riscv_get_m
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. Ch
Hi,
In this version we changed patch 10 (remove kvm-stub.c) as suggested by
Phil to not include non-KVM stubs in kvm_riscv.h. A change in patch 05
requested by Zhiwei was also made.
Patches based on Alistair's riscv-to-apply.next.
Patches missing acks: patch 10
Changes from v2:
- patch 05:
-
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(). tcg_c
Nina Schoetterl-Glausch writes:
> From: Pierre Morel
>
> 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.
>
> The same c
On Wed, 20 Sep 2023 08:08:39 +0300
Michael Tokarev wrote:
> 19.09.2023 12:34, Jonathan Cameron via wrote:
> > Establishing that only register accesses of size 4 and 8 can occur
> > using these functions requires looking at their callers. Make it
> > easier to see that by using switch statements.
On 2023/08/29 9:36, 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 graphics
paravirtualization.
1 - 100 of 292 matches
Mail list logo
