ert
> "virtio-net: Copy received header to buffer""), with a fix in the
> superseded patch. It also renames identifiers according to the
> discussion with Antoine Damhet.
> ---
> Changes in v2:
> - Rewrote the message avoiding archeology as suggested by
> Michael
On Fri, Apr 11, 2025 at 05:01:01PM +0900, Akihiko Odaki wrote:
> On 2025/04/07 17:29, Antoine Damhet wrote:
> > On Sat, Apr 05, 2025 at 05:04:28PM +0900, Akihiko Odaki wrote:
> > > The goal of commit 7987d2be5a8b ("virtio-net: Copy received header to
> > > buffer&q
rest of the payload) producing an invalid one
and making guests fail to acquire a DHCP lease.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727
Cc: qemu-sta...@nongnu.org
Signed-off-by: Antoine Damhet
---
v2: Rebased on master due to conflict with c17ad4b11bd2 (
"virtio-net
>
> Fixes: 7987d2be5a8b ("virtio-net: Copy received header to buffer")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Akihiko Odaki
Tested-By: Antoine Damhet
> ---
> This patch aims to resolves the iss
rest of the payload) producing an invalid one
and making guests fail to acquire a DHCP lease.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2727
Cc: qemu-sta...@nongnu.org
Signed-off-by: Antoine Damhet
---
hw/net/virtio-net.c | 85 +
1 file
e done
> before sending bytes to a character device to see how much it can handle,
> so the s->max_size in tcp_chr_read() still contains the old value from the
> previous read. Let's make sure that we use the up-to-date value by calling
> tcp_chr_read_poll() again here.
>
> Fixes:
> The docs for `g_source_add_child_source(source, child_source)` says
> "source will hold a reference on child_source while child_source is
> attached to it." Therefore, we should unreference the child source at
> `qio_channel_tls_read_watch()` after attaching it to `source`. Wit
On Wed, Nov 16, 2022 at 10:52:20AM +, Daniel P. Berrangé wrote:
> On Tue, Nov 15, 2022 at 03:23:29PM +0100, antoine.dam...@shadow.tech wrote:
> > From: Antoine Damhet
> >
> > Since the TLS backend can read more data from the underlying QIOChannel
> > we introduce
From: Antoine Damhet
Since the TLS backend can read more data from the underlying QIOChannel
we introduce a minimal child GSource to notify if we still have more
data available to be read.
Signed-off-by: Antoine Damhet
Signed-off-by: Charles Frey
---
io/channel-tls.c | 66
From: Antoine Damhet
The new `qcrypto_tls_session_check_pending` function allows the caller
to know if data have already been consumed from the backend and is
already available.
Signed-off-by: Antoine Damhet
---
crypto/tlssession.c | 14 ++
include/crypto/tlssession.h | 11
From: Antoine Damhet
At least with the TCP backend the tls implementation can stall because
the current notification mechanism is based on the readyness status of
the underlying file descriptor but gnutls can read all the data
available while the consumer has only handled part (eg: the TCP
ing GLOBAL_STATE_CODE in IO_CODE is allowed, since GSC callers are
> allowed to call IO_CODE.
>
> Resolves: #1272
>
> Signed-off-by: Emanuele Giuseppe Esposito
Tested-by: Antoine Damhet
> ---
> block/block-backend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
--
Antoine 'xdbob' Damhet
signature.asc
Description: PGP signature
On Thu, Nov 26, 2020 at 12:09:13PM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> > > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
>
On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
>
On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wro
On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > > Hello,
> > >
> > > We recently found out that som
Hello,
We recently found out that some softwares are effectively crashing
when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
I see no reason not to expose the setting to the user/command-line. A
previous patch has been submitted in 2015[1] but did not get through
because (if I
on migration.
> Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.
>
> Reported-by: Antoine Damhet
> Suggested-by: Paolo Bonzini
> Signed-off-by: Vitaly Kuznetsov
Tested-by: Antoine Damhet
> ---
> hw/i386/kvm/clock.c| 7 +--
> hw/i386/microvm.c
On Thu, Sep 17, 2020 at 06:44:10PM +0100, Dr. David Alan Gilbert wrote:
[...]
> > >> >
> > >> > Shouldn't the old check used when machine type <= 5.1 in order to avoid
> > >> > migration incompatibility ?
> > >>
> > >> Hm, when the check fails we just don't create the device and no error is
> >
On Thu, Sep 17, 2020 at 03:42:37PM +0100, Dr. David Alan Gilbert wrote:
[...]
> > >
> > > Shouldn't the old check used when machine type <= 5.1 in order to avoid
> > > migration incompatibility ?
> >
> > Hm, when the check fails we just don't create the device and no error is
> > reported, so ev
onally, it seems
> to always make sense to call KVM_GET_CLOCK/KVM_SET_CLOCK on migration.
> Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.
>
> Reported-by: Antoine Damhet
> Suggested-by: Paolo Bonzini
> Signed-off-by: Vitaly Kuznetsov
> ---
> hw/i386/kvm/c
On Wed, Sep 16, 2020 at 02:50:56PM +0200, Vitaly Kuznetsov wrote:
[...]
> >>
> >
> >
> > Oh, I think I see what's going on. When you add 'kvm=off'
> > cpu->env.features[FEAT_KVM] is reset (see x86_cpu_expand_features()) so
> > kvmclock QEMU device is not created and nobody calls KVM_SET_CLOCK on
>
On Wed, Sep 16, 2020 at 01:59:43PM +0200, Vitaly Kuznetsov wrote:
> "Dr. David Alan Gilbert" writes:
>
> > cc'ing in Vitaly who knows about the hv stuff.
> >
>
> cc'ing Marcelo who knows about clocksources :-)
>
> > * Antoine D
On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote:
> cc'ing in Vitaly who knows about the hv stuff.
Thanks
>
> * Antoine Damhet (antoine.dam...@blade-group.com) wrote:
> > Hi,
> >
> > We are experiencing timestamp rollbacks during live-mi
Hi,
We are experiencing timestamp rollbacks during live-migration of
Windows 10 guests with the following qemu configuration (linux 5.4.46
and qemu master):
```
$ qemu-system-x86_64 -enable-kvm -cpu host,kvm=off,hv_time [...]
```
I have tracked the bug to the fact that `kvmclock` is not exposed a
On Mon, Jul 20, 2020 at 04:07:26PM +0200, Kevin Wolf wrote:
> Am 17.07.2020 um 15:56 hat antoine.dam...@blade-group.com geschrieben:
> > From: Antoine Damhet
> >
> > The `detect-zeroes=unmap` option may issue unaligned
> > `FALLOC_FL_PUNCH_HOLE` requests, raw block de
From: Antoine Damhet
The `detect-zeroes=unmap` option may issue unaligned
`FALLOC_FL_PUNCH_HOLE` requests, raw block devices can (and will) return
`EINVAL`, qemu should then write the zeroes to the blockdev instead of
issuing an `IO_ERROR`.
Signed-off-by: Antoine Damhet
---
block/file-posix.c
From: Antoine Damhet
The `detect-zeroes=unmap` option may issue unaligned
`FALLOC_FL_PUNCH_HOLE` requests, raw block devices can (and will) return
`EINVAL`, qemu should then write the zeroes to the blockdev instead of
issuing an `IO_ERROR`.
Signed-off-by: Antoine Damhet
---
I am resending
28 matches
Mail list logo
