Leonardo Bras Soares Passos wrote:
> On Fri, May 26, 2023 at 5:04 AM Juan Quintela wrote:
>> > Maybe too much?
>>
>> I dropped this patch for two reasons:
>>
>> - reviewers gave me a bad time with it O:-)
>> - it was there only so if anyone was meassuring that new counters are
>> the same that
On Fri, May 26, 2023 at 5:04 AM Juan Quintela wrote:
>
> Leonardo Brás wrote:
> > On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
> >> We forget several places to add to trasferred amount of data. With
> >> this fixes I get:
> >>
> >>qemu_file_transferred() + multifd_bytes == transfe
Leonardo Brás wrote:
> On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
>> We forget several places to add to trasferred amount of data. With
>> this fixes I get:
>>
>>qemu_file_transferred() + multifd_bytes == transferred
>>
>> The only place whrer this is not true is during devices
On Mon, 2023-05-15 at 21:56 +0200, Juan Quintela wrote:
> We forget several places to add to trasferred amount of data. With
> this fixes I get:
>
>qemu_file_transferred() + multifd_bytes == transferred
>
> The only place whrer this is not true is during devices sending. But
> going all thr
Juan Quintela writes:
> We forget several places to add to trasferred amount of data. With
"transferred".
> this fixes I get:
>
>qemu_file_transferred() + multifd_bytes == transferred
>
> The only place whrer this is not true is during devices sending. But
"where"
> going all through th
We forget several places to add to trasferred amount of data. With
this fixes I get:
qemu_file_transferred() + multifd_bytes == transferred
The only place whrer this is not true is during devices sending. But
going all through the full tree searching for devices that use
QEMUFile directly is
