On 9/27/23 04:12, Joel Stanley wrote:
On Fri, 22 Sept 2023 at 13:21, Cédric Le Goater wrote:
+t->start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+return calculate_time(t, MAX(MAX(t->match[0], t->match[1]), 0));
This MAX(MAX(x, y), 0) looks strange to me. Would you remember where it
"Zhijian Li (Fujitsu)" writes:
> On 26/09/2023 19:52, Markus Armbruster wrote:
>> "Zhijian Li (Fujitsu)" writes:
>>
>>> On 18/09/2023 22:42, Markus Armbruster wrote:
Functions that use an Error **errp parameter to return errors should
not also report them to the user, because
Hi Salil,
On 9/26/23 20:04, Salil Mehta wrote:
Factor out CPU properties code common for {hot,cold}-plugged CPUs. This allows
code reuse.
Signed-off-by: Salil Mehta
---
hw/arm/virt.c | 220 ++
include/hw/arm/virt.h | 4 +
2 files changed,
On 26/09/2023 21.25, Fabiano Rosas wrote:
Our linker script for optionroms specifies only the placement of the
.text section, leaving the linker free to place the remaining sections
at arbitrary places in the file.
Since at least binutils 2.39, the .note.gnu.build-id section is now
being placed
On Wed, Sep 27, 2023 at 5:35 AM Daniel Henrique Barboza
wrote:
>
> We'll introduce generic errors that will output a CPU type name via its
> RISCVCPU pointer. Create a helper for that.
>
> Use the helper in tcg_cpu_realizefn() instead of hardcoding the 'host'
> CPU name.
>
> Signed-off-by: Daniel
On Mon, Sep 25, 2023 at 12:28 PM Karim Taha
wrote:
> Upstream the implementation of the following mmap system calls, from the
> qemu-bsd-user fork:
>mmap(2), munmap(2),
>mprotect(2),
>msync(2),
>mlock(2), munlock(2), mlockall(2), munlockall(2), mincore(2),
>madvise(2),
>
On Mon, Sep 25, 2023 at 12:25 PM Karim Taha
wrote:
>
>
> Karim Taha (3):
> bsd-user: define TARGET_RFSPAWN for rfork to use vfork(2) semantics,
> and fix RLIM_INFINITY
> bsd-user: Implement get_filename_from_fd.
> bsd-user: Implement execve(2) and fexecve(2) system calls.
>
> Kyle
Hi Salil,
On 9/26/23 20:04, Salil Mehta wrote:
Adds various utility functions which might be required to fetch or check the
state of the possible vCPUs. This also introduces concept of *disabled* vCPUs,
which are part of the *possible* vCPUs but are not part of the *present* vCPU.
This state
On Fri, 22 Sept 2023 at 15:59, Cédric Le Goater wrote:
>
> Remove superfluous local 'data' variable and use the one define at the
> top of the routine. This fixes :
>
> ../hw/i2c/aspeed_i2c.c: In function ‘aspeed_i2c_bus_recv’:
> ../hw/i2c/aspeed_i2c.c:315:17: warning: declaration of ‘data’
Hi Salil Mehta:
Hi Xianglai,
From: xianglai li
Sent: Tuesday, September 26, 2023 10:55 AM
To: qemu-devel@nongnu.org
Cc: Bernhard Beschow ; Salil Mehta
; Salil Mehta ; Xiaojuan
Yang ; Song Gao ; Michael S.
Tsirkin ; Igor Mammedov ; Ani Sinha
; Paolo Bonzini ; Richard
Henderson ; Eduardo
Hi Salil Mehta:
From: Salil Mehta
Sent: Tuesday, September 26, 2023 12:21 PM
To: 'David Hildenbrand' ; lixianglai
; qemu-devel@nongnu.org
Cc: Salil Mehta ; Xiaojuan Yang
; Song Gao ; Michael S.
Tsirkin ; Igor Mammedov ; Ani Sinha
; Paolo Bonzini ; Richard
Henderson ; Eduardo Habkost
; Marcel
On Fri, 22 Sept 2023 at 13:21, Cédric Le Goater wrote:
> > +t->start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
> > +return calculate_time(t, MAX(MAX(t->match[0], t->match[1]), 0));
>
> This MAX(MAX(x, y), 0) looks strange to me. Would you remember where it comes
> from ? Thanks,
That
Hi Cédric,
>-Original Message-
>From: Duan, Zhenzhong
>Sent: Thursday, September 21, 2023 6:14 PM
>Subject: RE: [PATCH v1 04/22] vfio/common: Introduce
>vfio_container_add|del_section_window()
>
>Hi Cédric,
>
>>-Original Message-
>>From: Cédric Le Goater
>>Sent: Thursday,
On 26/09/2023 19:52, Markus Armbruster wrote:
> "Zhijian Li (Fujitsu)" writes:
>
>> On 18/09/2023 22:42, Markus Armbruster wrote:
>>> Functions that use an Error **errp parameter to return errors should
>>> not also report them to the user, because reporting is the caller's
>>> job. When the
Hi Salil,
On 9/26/23 20:04, Salil Mehta wrote:
This shall be used to store user specified topology{socket,cluster,core,thread}
and shall be converted to a unique 'vcpu-id' which is used as slot-index during
hot(un)plug of vCPU.
Note that we don't have 'vcpu-id' property. It's actually the
On Tue, Nov 22, 2022 at 05:12:59PM +, Anthony PERARD wrote:
> On Mon, Nov 14, 2022 at 08:20:10PM +0100, Marek Marczykowski-Górecki wrote:
> > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> > index 0ec7e52183..269bd26109 100644
> > --- a/hw/xen/xen_pt.c
> > +++ b/hw/xen/xen_pt.c
> > @@ -255,6
Move the definition of VhostUserProtocolFeature to
include/hw/virtio/vhost-user.h.
Remove previous definitions in hw/scsi/vhost-user-scsi.c,
hw/virtio/vhost-user.c, and hw/virtio/virtio-qmp.c.
Previously there were 3 separate definitions of this over 3 different
files. Now only 1 definition of
Add new vhost-user protocol feature to vhost-user protocol feature map
and enumeration:
- VHOST_USER_PROTOCOL_F_STATUS
Add new virtio device features for several virtio devices to their
respective feature mappings:
virtio-blk:
- VIRTIO_BLK_F_SECURE_ERASE
virtio-net:
- VIRTIO_NET_F_NOTF_COAL
These patches update a few things related to virtio introspection via.
QMP/HMP commands.
1. Remove 'virtio_list' and instead query the QOM composition tree to
find any active & realized virtio devices.
The 'virtio_list' was duplicating information about virtio devices that
was already available
The virtio_list duplicates information about virtio devices that already
exist in the QOM composition tree. Instead of creating this list of
realized virtio devices, search the QOM composition tree instead.
This patch modifies the QMP command qmp_x_query_virtio to instead
recursively search the
Hi Tong,
On [2023 Sep 21] Thu 23:50:10, Tong Ho wrote:
> Signed-off-by: Tong Ho
> ---
> tests/qtest/meson.build | 2 +-
> tests/qtest/xlnx-versal-trng-test.c | 490
> 2 files changed, 491 insertions(+), 1 deletion(-)
> create mode 100644
On 19.09.23 13:23, Daniil Tatianin wrote:
Same as with the x86 verison of this test, we relied on the contents of
all pages in RAM to be the same across the entire test range, which is
very fragile. Zero the first byte of each page before running the
increment loop to fix this.
Fixes:
On 19.09.23 13:23, Daniil Tatianin wrote:
The migration qtest all the way up to this point used to work by sheer
luck relying on the contents of all pages from 1MiB to 100MiB to contain
the same one value in the first byte initially.
This easily breaks if we reduce the amount of RAM for the
On 19.09.23 13:23, Daniil Tatianin wrote:
So that we have less magic numbers to deal with. This also allows us to
reuse these in the following commits.
Signed-off-by: Daniil Tatianin
Reviewed-by: Peter Xu
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
27.09.2023, 00:02, "Peter Xu" :On Thu, Sep 07, 2023 at 10:29:42PM +0300, Daniil Tatianin wrote: This series fixes an issue where the outcome of the migration qtest relies on the initial memory contents all being the same across the first 100MiB of RAM, which is a very fragile invariant. We fix
26.09.2023, 23:41, "Vladimir Sementsov-Ogievskiy" :On 07.09.23 22:29, Daniil Tatianin wrote: The migration qtest all the way up to this point used to work by sheer luck relying on the contents of all pages from 1MiB to 100MiB to contain the same one value in the first byte initially. This easily
27.09.2023, 00:02, "Peter Xu" :On Thu, Sep 07, 2023 at 10:29:42PM +0300, Daniil Tatianin wrote: This series fixes an issue where the outcome of the migration qtest relies on the initial memory contents all being the same across the first 100MiB of RAM, which is a very fragile invariant. We fix
On Thu, Sep 07, 2023 at 10:29:42PM +0300, Daniil Tatianin wrote:
> This series fixes an issue where the outcome of the migration qtest
> relies on the initial memory contents all being the same across the
> first 100MiB of RAM, which is a very fragile invariant.
>
> We fix this by making sure we
Warner Losh writes:
> On Tue, Sep 26, 2023 at 8:43 AM Markus Armbruster wrote:
>
>> Brian, Gerd, Jason, Marc-André, Michael, we need your help to enable
>> -Wshadow=local.
>>
>> Paolo, you already took care of several subsystems (thanks!), except you
>> left a few warnings in
[add Markus]
On 26.09.23 23:15, Vladimir Sementsov-Ogievskiy wrote:
local_err must be NULL before calling object_property_set_bool(), so we
must clear it on each iteration. Let's also use more convenient
error_reportf_err().
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Peter Xu writes:
> 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.
>
> Reviewed-by: Daniel P. Berrangé
> Signed-off-by: Peter Xu
The
On Tue, Sep 26, 2023 at 11:15:30PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> NVMeQueuePair::reqs has length NVME_NUM_REQS, which less than
> NVME_QUEUE_SIZE by 1.
>
> Fixes: 1086e95da17050 ("block/nvme: switch to a NVMeRequest freelist")
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
From: Eric Blake
Documenting that we should not add new lines to work around SPF
rewrites sounds foreboding; the intent is instead that new lines here
are okay, but indicate a second problem elsewhere in our build process
that we should also consider fixing at the same time, to keep the
section
Peter Xu writes:
> Quotting from Markus in his replies:
Quoting
Suggest something like "Markus recently wrote:"
> migrate-set-parameters sets migration parameters, and
> query-migrate-parameters gets them. Unsurprisingly, the former's
> argument type MigrateSetParameters is quite close
On 07.09.23 22:29, Daniil Tatianin wrote:
The migration qtest all the way up to this point used to work by sheer
luck relying on the contents of all pages from 1MiB to 100MiB to contain
the same one value in the first byte initially.
This easily breaks if we reduce the amount of RAM for the
I sent this reply to your question on the same day, but it got eaten by
malfunctioning servers, and I noticed only now after another failure
made me dig through my logs. Sorry for the inconvenience!
Chenyi Qiang writes:
> On 8/22/2023 4:24 PM, Daniel P. Berrangé wrote:
>> On Tue, Aug 22, 2023
On 07.09.23 22:29, Daniil Tatianin wrote:
So that we have less magic numbers to deal with. This also allows us to
reuse these in the following commits.
Signed-off-by: Daniil Tatianin
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
On Tue, 26 Sept 2023 at 21:16, Vladimir Sementsov-Ogievskiy
wrote:
>
> Coverity signals that variable as being used uninitialized. And really,
> when work with external APIs that's better to zero out the structure,
> where we set some fields by hand.
>
> Signed-off-by: Vladimir
On Tue, 26 Sept 2023 at 21:15, Vladimir Sementsov-Ogievskiy
wrote:
>
> set_time() function doesn't set all the fields, so it's better to
> initialize tm structure. And Coverity will be happier about it.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> hw/rtc/mc146818rtc.c | 2 +-
> 1
On Tue, 26 Sept 2023 at 21:15, Vladimir Sementsov-Ogievskiy
wrote:
>
> Prefer clear assertions instead of [im]possible array overflow.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> --
Reviewed-by: Peter Maydell
thanks
-- PMM
On Tue, 26 Sept 2023 at 21:15, Vladimir Sementsov-Ogievskiy
wrote:
>
> We support only 3- and 4-level page-tables, which is firstly checked in
> vtd_decide_config(), then setup in vtd_init(). Than level fields are
> checked by vtd_is_level_supported().
>
> So here we can't have level out from
On Tue, 26 Sept 2023 at 20:42, Eric Blake wrote:
>
> On Tue, Sep 26, 2023 at 02:46:44PM +0100, Peter Maydell wrote:
> > On Tue, 26 Sept 2023 at 14:40, Eric Blake wrote:
> > >
> > > On Tue, Sep 26, 2023 at 01:28:01PM +0300, andrey.drobys...@virtuozzo.com
> > > wrote:
> > > > From: Andrey
v2:
01: add explanations, new assert and avoid extra assignment
add CIDs [thx to Paolo]
02: add explanation, improve wording
04,07: s/{0}/{}
06,08: improve wording
Hi! Here are some improvements to handle issues found by Coverity (not
public Coverity site, so there are no CIDs).
Vladimir
Prefer clear assertions instead of [im]possible array overflow.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
util/filemonitor-inotify.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/util/filemonitor-inotify.c b/util/filemonitor-inotify.c
index
local_err must be NULL before calling object_property_set_bool(), so we
must clear it on each iteration. Let's also use more convenient
error_reportf_err().
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/pci/pcie_sriov.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff
We support only 3- and 4-level page-tables, which is firstly checked in
vtd_decide_config(), then setup in vtd_init(). Than level fields are
checked by vtd_is_level_supported().
So here we can't have level out from 1..4 inclusive range. Let's assert
it. That also explains Coverity that we are not
set_time() function doesn't set all the fields, so it's better to
initialize tm structure. And Coverity will be happier about it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/rtc/mc146818rtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rtc/mc146818rtc.c
Coverity signals that variable as being used uninitialized. And really,
when work with external APIs that's better to zero out the structure,
where we set some fields by hand.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
hw/core/loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
For SO_EE_ORIGIN_ZEROCOPY the 32-bit notification range is encoded
as [ee_info, ee_data] inclusively, so ee_info should be less or
equal to ee_data.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
io/channel-socket.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/io/channel-socket.c
Explain Coverity that we are not going to overflow vmsg->fds.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
subprojects/libvhost-user/libvhost-user.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/subprojects/libvhost-user/libvhost-user.c
b/subprojects/libvhost-user/libvhost-user.c
NVMeQueuePair::reqs has length NVME_NUM_REQS, which less than
NVME_QUEUE_SIZE by 1.
Fixes: 1086e95da17050 ("block/nvme: switch to a NVMeRequest freelist")
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Cc: stefa...@redhat.com
Cc: alex.c...@huawei.com
Cc: euler.ro...@huawei.com
Note, that
Hi Hanna,
I was thinking about how this could work without SUSPEND/RESUME. What
do you think of the following?
1. The front-end sends VHOST_USER_RESET_DEVICE (or
VHOST_USER_RESET_OWNER, when necessary) when the guest driver resets
the device but not on vhost_dev_start()/vhost_dev_stop().
2.
On 9/7/23 23:53, Denis V. Lunev wrote:
Unfortunately 271 IO test is broken if started in non-cached mode.
Commits
commit a6b257a08e3d72219f03e461a52152672fec0612
Author: Nir Soffer
Date: Tue Aug 13 21:21:03 2019 +0300
file-posix: Handle undetectable alignment
and
Peter Xu writes:
> On Mon, Sep 25, 2023 at 02:59:30PM +0200, Markus Armbruster wrote:
>> Peter, looks like you missed my review of v2.
>
> I definitely missed that if there is, but I didn't see any, and also
> nothing I spot on the list, either..
>
>
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().
Vendor CPUs can implement any profile they want as long as all required
extensions are being set in their respective cpu_init().
We do not enable extensions for vendor CPUs and that will still be true
with profile support. The idea then is to enable the profile option for
vendor CPUs and let
Based-on: 20230926183109.165878-1-dbarb...@ventanamicro.com
("[PATCH 0/2] riscv: add extension properties for all cpus")
Hi,
These patches implements the base profile support for qemu-riscv and the
first profile, RVA22U64.
As discussed in this thread [1] we're aiming for a flag that enables
zihpm is the Hardware Performance Counters extension described in
chapter 12 of the unprivileged spec. It describes support for 29
unprivileged performance counters, hpmcounter3-hpmcounter21.
As with zicntr, QEMU already implements zihpm before it was even an
extension. zihpm is also part of the
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
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
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
zicntr is the Base Counters and Timers extension described in chapter 12
of the unprivileged spec. It describes support for RDCYCLE, RDTIME and
RDINSTRET.
QEMU already implements it way before it was a discrete extension.
zicntr is part of the RVA22 profile, so let's add it to QEMU to make the
On Tue, Sep 26, 2023 at 02:46:44PM +0100, Peter Maydell wrote:
> On Tue, 26 Sept 2023 at 14:40, Eric Blake wrote:
> >
> > On Tue, Sep 26, 2023 at 01:28:01PM +0300, andrey.drobys...@virtuozzo.com
> > wrote:
> > > From: Andrey Drobyshev
> > >
> > > This fixes authorship of commits 2848289168,
On Tue, 26 Sept 2023 at 09:55, Hanna Czenczek wrote:
>
> On 25.09.23 21:15, Stefan Hajnoczi wrote:
> > On Fri, Sep 15, 2023 at 12:25:27PM +0200, Hanna Czenczek wrote:
> >> Currently, the vhost-user documentation says that rings are to be
> >> initialized in a disabled state when
Our linker script for optionroms specifies only the placement of the
.text section, leaving the linker free to place the remaining sections
at arbitrary places in the file.
Since at least binutils 2.39, the .note.gnu.build-id section is now
being placed at the start of the file, which causes
On Tue, Sep 26, 2023, 09:33 Hanna Czenczek wrote:
> On 25.09.23 22:48, Stefan Hajnoczi wrote:
> > On Fri, Sep 15, 2023 at 12:25:25PM +0200, Hanna Czenczek wrote:
> >> RFC:
> >> https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg04263.html
> >>
> >> v1:
> >>
On 26.09.23 21:59, Peter Maydell wrote:
On Tue, 26 Sept 2023 at 19:36, Vladimir Sementsov-Ogievskiy
wrote:
On 26.09.23 13:37, Peter Maydell wrote:
On Mon, 25 Sept 2023 at 20:41, Vladimir Sementsov-Ogievskiy
wrote:
Add a constant and clear assertion. The assertion also tells Coverity
that
On Tue, 26 Sep 2023 18:54:53 +0200
David Hildenbrand wrote:
> On 26.09.23 16:52, Ankit Agrawal wrote:
> > Good idea. Fundamentally the device should not be creating NUMA
> > nodes, the VM should be configured with NUMA nodes and the device
> > memory associated with those nodes.
>
On Wed, Sep 06, 2023 at 11:46:16AM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 06, 2023 at 12:14:54PM +0200, Philippe Mathieu-Daudé wrote:
> > On 6/9/23 11:00, Daniel P. Berrangé wrote:
> > > On Wed, Sep 06, 2023 at 06:42:16AM +0200, Philippe Mathieu-Daudé wrote:
> > > > On 5/9/23 18:23, Peter
It's cleaner and future-proof to just have other state that depends on the
bitmap state to be updated as soon as possible when restoring the bitmap.
So factor out informing RamDiscardListener into a functon and call it in
case of early migration right after we restored the bitmap.
Signed-off-by:
Let's add vhost_get_max_memslots().
Reviewed-by: Maciej S. Szmigiero
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 a/hw/virtio/vhost-stub.c
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
Let's prepare for a user that has to modify the VirtIOMEM device state.
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-mem.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
index da5b09cefc..0b0e6c5090 100644
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
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
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
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
On Tue, 26 Sept 2023 at 19:36, Vladimir Sementsov-Ogievskiy
wrote:
>
> On 26.09.23 13:37, Peter Maydell wrote:
> > On Mon, 25 Sept 2023 at 20:41, Vladimir Sementsov-Ogievskiy
> > wrote:
> >>
> >> Add a constant and clear assertion. The assertion also tells Coverity
> >> that we are not going to
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().
Reviewed-by: Maciej S. Szmigiero
Signed-off-by: David Hildenbrand
---
accel/kvm/kvm-all.c| 2 +-
accel/stubs/kvm-stub.c | 5 +
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
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 place non-qmp stubs in there, so let's rename it. While at
it, put it into the MAINTAINERS file under "Memory devices".
Reviewed-by: Maciej S. Szmigiero
Signed-off-by: David Hildenbrand
---
MAINTAINERS| 1 +
stubs/{qmp_memory_device.c =>
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
---
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
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 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.
This is a preparation for memory devices that consume multiple memslots.
Reviewed-by: Philippe Mathieu-Daudé
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.
Reviewed-by: Maciej S. Szmigiero
Signed-off-by: David Hildenbrand
Quoting from patch #16:
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
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
On 26.09.23 21:36, Vladimir Sementsov-Ogievskiy wrote:
On 26.09.23 13:37, Peter Maydell wrote:
On Mon, 25 Sept 2023 at 20:41, Vladimir Sementsov-Ogievskiy
wrote:
Add a constant and clear assertion. The assertion also tells Coverity
that we are not going to overflow the array.
Signed-off-by:
Use the recently added riscv_cpu_accelerator_compatible() to filter
unavailable CPUs for a given accelerator. At this moment this is the
case for a QEMU built with KVM and TCG support querying a binary running
with TCG:
qemu-system-riscv64 -S -M virt,accel=tcg -display none
-qmp
Add an API to check if a given CPU is compatible with the current
accelerator.
This will allow query-cpu-model-expansion to work properly in conditions
where QEMU supports both accelerators (TCG and KVM), QEMU is then
launched using TCG, and the API requests information about a KVM only
CPU (e.g.
Callers can add 'props' when querying for a cpu model expansion to see
if a given CPU model supports a certain criteria, and what's the
resulting CPU object.
If we have 'props' to handle, gather it in a QDict and use the new
riscv_cpuobj_validate_qdict_in() helper to validate it. This helper will
The query-cpu-model-expansion API is capable of passing extra properties
to a given CPU model and tell callers if this custom configuration is
valid.
The RISC-V version of the API is not quite there yet. The reason is the
realize() flow in the TCG driver, where most of the validation is done
in
Hi,
In this second version we stripped patches 1 and 2 from v1. They're now
being treated in separate in
"[PATCH 0/2] riscv: add extension properties for all cpus"
Note that we'll need these applied beforehand to see vendor CPU
properties with this new API.
This series implements
This API is used to inspect the characteristics of a given CPU model. It
also allows users to validate a CPU model with a certain configuration,
e.g. if "-cpu X,a=true,b=false" is a valid setup for a given QEMU
binary. We'll start implementing the first part. The second requires
more changes in
We got along without property getters in the KVM driver because we never
needed them. But the incoming query-cpu-model-expansion API will use
property getters and setters to retrieve the CPU characteristics.
Add the missing getters for the KVM driver for both MISA and
multi-letter extension
On 26.09.23 13:37, Peter Maydell wrote:
On Mon, 25 Sept 2023 at 20:41, Vladimir Sementsov-Ogievskiy
wrote:
Add a constant and clear assertion. The assertion also tells Coverity
that we are not going to overflow the array.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Hi,
At this moment we do not expose extension properties for vendor CPUs
because that would allow users to enable extensions in them. But that
comes at a cost: if we were to add an API that shows all CPU properties,
e.g. qmp-query-cpu-model-expansion, we won't be able to show the
extension state
At this moment we do not expose extension properties for vendor CPUs
because that would allow users to change them via command line. The
drawback is that if we were to add an API that shows all CPU properties,
e.g. qmp-query-cpu-model-expansion, we won't be able to show extensions
state of vendor
1 - 100 of 400 matches
Mail list logo
