On Mon, Mar 25, 2024 at 11:50:41AM -0400, Stefan Hajnoczi wrote:
> On Mon, Mar 25, 2024 at 05:18:50PM +0800, zhuyangyang wrote:
> > If g_main_loop_run()/aio_poll() is called in the coroutine context,
> > the pending coroutine may be woken up repeatedly, and the co_queue_wakeup
> > may be
The field is marked as "the offset in the file (in clusters)", but it
was being used like this
`cluster_size*(nums)+mapping->info.file.offset`, which is incorrect.
Additionally, removed the `abort` when `first_mapping_index` does not
match, as this matches the case when adding new clusters for
These patches fix some bugs found when modifying files in vvfat.
First, there was a bug when writing to the second+ cluster of a file, it
will copy the cluster before it instead.
Another issue was modifying the clusters of a file and adding new
clusters, this showed 2 issues:
- If the new
Before this commit, the behavior when calling `commit_one_file` for
example with `offset=0x2000` (second cluster), what will happen is that
we won't fetch the next cluster from the fat, and instead use the first
cluster for the read operation.
This is due to off-by-one error here, where `i=0x2000
When reading with `read_cluster` we get the `mapping` with
`find_mapping_for_cluster` and then we call `open_file` for this
mapping.
The issue appear when its the same file, but a second cluster that is
not immediately after it, imagine clusters `500 -> 503`, this will give
us 2 mappings one has
Coverity complains that the check introduced in commit 3f934817 suggests
that qiov could be NULL and we dereference it before reaching the check.
In fact, all of the callers pass a non-NULL pointer, so just remove the
misleading check.
Resolves: Coverity CID 1542668
Signed-off-by: Kevin Wolf
---
Hi Fiona,
The Coverity static checker sent a report about commit 3f934817c82c
("block/io: accept NULL qiov in bdrv_pad_request").
Please take a look and send a follow-up patch, if necessary:
*** CID 1542668: Null pointer dereferences (REVERSE_INULL)
/builds/qemu-project/qemu/bloc
k/io.c: 1733
On Tue, Nov 14, 2023 at 03:38:12PM +0100, Philippe Mathieu-Daudé wrote:
> Commit eaab4d60d3 ("Introduce Xen PCI Passthrough, qdevice")
> introduced both xen_pt.[ch], but only added the license to
> xen_pt.c. Use the same license for xen_pt.h.
>
> Suggested-by: David Woodhouse
> Signed-off-by:
On Tue, Nov 14, 2023 at 03:38:11PM +0100, Philippe Mathieu-Daudé wrote:
> We rarely need to include "cpu.h" in headers. Including it
> 'taint' headers to be target-specific. Here only the i386/arm
> implementations requires "cpu.h", so include it there and
> remove from the
On Tue, Nov 14, 2023 at 03:38:09PM +0100, Philippe Mathieu-Daudé wrote:
> Per commit f17068c1c7 ("xen-hvm: reorganize xen-hvm and move common
> function to xen-hvm-common"), handle_ioreq() is expected to be
> target-agnostic. However it uses 'target_ulong', which is a target
> specific definition.
So I thought that for now we only support the "anonymous" mode, and if
in the future we have a use case where the user wants to specify the
name, we can add it later.
Okay, so for now you really only want an anonymous fd that behaves like
a memfd, got it.
Likely we should somehow fail if the
On Wed, Mar 27, 2024 at 12:51:51PM +0100, David Hildenbrand wrote:
On 27.03.24 11:23, Stefano Garzarella wrote:
On Tue, Mar 26, 2024 at 03:45:52PM +0100, David Hildenbrand wrote:
+mode = 0;
+oflag = O_RDWR | O_CREAT | O_EXCL;
+backend_name = host_memory_backend_get_name(backend);
+
Philippe Mathieu-Daudé writes:
> The whole RDMA subsystem was deprecated in commit e9a54265f5
> ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem")
> released in v8.2. Time to remove it.
>
> Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
> in old migration streams.
>
>
On Tue, Nov 14, 2023 at 03:38:08PM +0100, Philippe Mathieu-Daudé wrote:
> We don't need a target-specific header for common target-specific
> prototypes. Declare xen_arch_handle_ioreq() and xen_arch_set_memory()
> in "hw/xen/xen-hvm-common.h".
>
> Signed-off-by: Philippe Mathieu-Daudé
>
On Tue, Nov 14, 2023 at 03:38:07PM +0100, Philippe Mathieu-Daudé wrote:
> Use a common 'xen_arch_' prefix for architecture-specific functions.
> Rename xen_arch_set_memory() and xen_arch_handle_ioreq().
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: David Woodhouse
> Reviewed-by:
On 27 March 2024 13:31:52 GMT, Anthony PERARD wrote:
>On Tue, Nov 14, 2023 at 03:38:05PM +0100, Philippe Mathieu-Daudé wrote:
>> Except imported source files, QEMU code base uses
>> the QEMU_ALIGNED() macro to align its structures.
>
>This patch only convert the alignment, but discard pack. We
On Tue, Nov 14, 2023 at 03:38:05PM +0100, Philippe Mathieu-Daudé wrote:
> Except imported source files, QEMU code base uses
> the QEMU_ALIGNED() macro to align its structures.
This patch only convert the alignment, but discard pack. We need both or
the struct is changed.
> ---
>
On Tue, Nov 14, 2023 at 03:38:01PM +0100, Philippe Mathieu-Daudé wrote:
> Only call xen_register_framebuffer() when Xen is enabled.
>
> Signed-off-by: Philippe Mathieu-Daudé
I don't think this patch is very useful but it's fine, so:
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Tue, Nov 14, 2023 at 03:38:04PM +0100, Philippe Mathieu-Daudé wrote:
> All these stubs are protected by a 'if (xen_enabled())' check.
Are you sure? There's still nothing that prevent a compiler from wanting
those, I don't think.
Sure, often compilers will remove dead code in `if(0){...}`, but
On 27.03.24 11:23, Stefano Garzarella wrote:
On Tue, Mar 26, 2024 at 03:45:52PM +0100, David Hildenbrand wrote:
+mode = 0;
+oflag = O_RDWR | O_CREAT | O_EXCL;
+backend_name = host_memory_backend_get_name(backend);
+
+/*
+ * Some operating systems allow creating anonymous
On Tue, Mar 26, 2024 at 03:45:52PM +0100, David Hildenbrand wrote:
+mode = 0;
+oflag = O_RDWR | O_CREAT | O_EXCL;
+backend_name = host_memory_backend_get_name(backend);
+
+/*
+ * Some operating systems allow creating anonymous POSIX shared memory
+ * objects (e.g. FreeBSD
On Tue, Mar 26, 2024 at 09:40:12AM -0500, Eric Blake wrote:
On Tue, Mar 26, 2024 at 02:39:29PM +0100, Stefano Garzarella wrote:
In vhost-user-server we set all fd received from the other peer
in non-blocking mode. For some of them (e.g. memfd, shm_open, etc.)
if we fail, it's not really a
I was wondering if we could see some partial sendmsg()/write
succeeding. Meaning, we transferred some bytes but not all, and we'd
actually need to loop ...
Yep, true, but I would fix it in another patch/series if you agree.
Absolutely.
--
Cheers,
David / dhildenb
On Tue, Mar 26, 2024 at 09:36:54AM -0500, Eric Blake wrote:
On Tue, Mar 26, 2024 at 02:39:28PM +0100, Stefano Garzarella wrote:
libvhost-user will panic when receiving VHOST_USER_GET_INFLIGHT_FD
message if MFD_ALLOW_SEALING is not defined, since it's not able
to create a memfd.
On Tue, Mar 26, 2024 at 03:36:52PM +0100, David Hildenbrand wrote:
On 26.03.24 15:34, Eric Blake wrote:
On Tue, Mar 26, 2024 at 02:39:27PM +0100, Stefano Garzarella wrote:
In vu_message_write() we use sendmsg() to send the message header,
then a write() to send the payload.
If sendmsg() fails
25 matches
Mail list logo
