On Wed, May 15, 2024 at 06:15:48PM +0100, Daniel P. Berrangé wrote:
> On Wed, May 15, 2024 at 11:03:27AM -0600, Peter Xu wrote:
> > On Wed, May 15, 2024 at 05:03:44PM +0100, Daniel P. Berrangé wrote:
> > > Above all, I'm failing to see why there's a compelling reason
&g
e majority will still
be that the VMSD change is caused by a new feature, and exporting that
property might in most cases be wanted.
In all cases, for now I agree it's at least easier to stick with the simple
way.
Thanks,
--
Peter Xu
r saving/loading based on the machine version.
> > The VMSD.version is irrelevant now.
> >
> > Fixes: dfcf74fa ("virtio-gpu: fix scanout migration post-load")
> > Suggested-by: Peter Xu
> > Signed-off-by: Marc-André Lureau
>
> I don't get it. Our s
ssue first, then whenever we have that new helper later we simply
use the new helper to replace the old, alongside we can drop the new field
/ property too as long as it is declared with "x-". Might be easier to
backport too in this case. Marc-Andre, what do you think?
Thanks,
--
Peter Xu
On Tue, May 14, 2024 at 11:25:26AM +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, May 14, 2024 at 8:35 AM Peter Xu wrote:
> >
> > Hey, Marc-Andre,
> >
> > On Mon, May 13, 2024 at 11:19:04AM +0400, marcandre.lur...@redhat.com wrote:
> > > diff --git a/h
On Mon, 13 May 2024 at 11:36, Alistair Francis wrote:
>
> On Mon, May 13, 2024 at 4:32 PM Michael S. Tsirkin wrote:
> >
> > On Mon, May 13, 2024 at 01:55:50PM +1000, Alistair Francis wrote:
> > > On Tue, May 7, 2024 at 3:24 PM Sia Jee Heng
> > > wrote:
> > >
> > > Can you describe why you are
On Mon, 29 Apr 2024 at 20:29, Atish Patra wrote:
>
> This series contains few miscallenous fixes related to hpmcounters
> and related code. The first patch fixes an issue with cycle/instret
> counters overcouting while the remaining two are more for specification
> compliance.
I've noticed a
PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
> +DEFINE_PROP_UINT8("x-vmstate-version", VirtIOGPU, vmstate_version, 1),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> --
> 2.41.0.28.gd7d8841f67
>
--
Peter Xu
On Mon, May 13, 2024 at 11:19:03AM +0400, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Signed-off-by: Marc-André Lureau
Reviewed-by: Peter Xu
--
Peter Xu
On Thu, 9 May 2024 at 19:17, Cord Amfmgm wrote:
>
>
>
> On Thu, May 9, 2024 at 12:48 PM Peter Maydell
> wrote:
>>
>> On Wed, 8 May 2024 at 16:29, Cord Amfmgm wrote:
>> > On Wed, May 8, 2024 at 3:45 AM Thomas Huth wrote:
>> >>
>> &g
topic too.. so we can
address the immediate breakage first.
Thanks,
==8<==
>From a24ef99670fa7102da461d795aed4a957bad86b1 Mon Sep 17 00:00:00 2001
From: Peter Xu
Date: Fri, 10 May 2024 12:33:34 -0400
Subject: [PATCH] fix gpu
Signed-off-by: Peter Xu
---
include/hw/virtio/virtio-
On Wed, 8 May 2024 at 16:29, Cord Amfmgm wrote:
> On Wed, May 8, 2024 at 3:45 AM Thomas Huth wrote:
>>
>> Your Signed-off-by line does not match the From: line ... could you please
>> fix this? (see
>>
please check the whole thread discussion, it may help to understand
what we are looking for on rdma migrations [1]. Meanwhile please feel free
to sync with Jinpu's team and see how to move forward with such a project.
[1] https://lore.kernel.org/qemu-devel/87frwatp7n@suse.de/
Thanks,
--
Peter Xu
On Thu, May 09, 2024 at 11:31:06AM +0800, Li Zhijian via wrote:
> Make the code more tight.
>
> Cc: Michael Tokarev
> Signed-off-by: Li Zhijian
Reviewed-by: Peter Xu
> ---
> This change/comment suggested by "Michael Tokarev " came
> a bit late at that
COLO process will
> take over the remaining processes until COLO exits.
>
> Signed-off-by: Li Zhijian
Reviewed-by: Peter Xu
--
Peter Xu
On Thu, May 09, 2024 at 11:31:04AM +0800, Li Zhijian wrote:
> - Explicitly show the missing module name: replication
> - Fix capability name to x-colo
>
> Signed-off-by: Li Zhijian
Reviewed-by: Peter Xu
--
Peter Xu
On Wed, May 08, 2024 at 10:47:32AM +0800, Song Gao wrote:
> vmstate does not save kvm_state_conter,
> which can cause VM recovery from disk to fail.
>
> Signed-off-by: Song Gao
Acked-by: Peter Xu
--
Peter Xu
>
> Related to my thoughts in an earlier patch, where I say that use of fdsets
> ought to be transparent to QEMU code, I'm not a fan of having this logic
> in migration code.
>
> IIUC, the migration code will call qio_channel_file_new_path twice,
> once with O_DIRECT and once without. This should trigger two calls
> into monitor_fdset_dup_fd_add with different flags. If we're matching
> flags in that monitor_fdset_dup_fd_add(), then if only 1 FD was
> provided, are we not able to report an error there ?
Right, this sounds working.
For a real sanity check, we may want to somehow check the two fds returned
from qio_channel_file_new_path() to point to the same file underneath.
What mentioned in the other thread (kcmp with KCMP_FILE) might not work, as
the whole purpose of having two fds is to make sure they have different
struct file to back the fd (and only one of them has O_DIRECT). fstat()
might work in this case over the st_ino field, etc. maybe fstatfs() too but
perhaps that's over cautious. Just a pain to use two fds as a start..
Thanks,
--
Peter Xu
On Wed, 8 May 2024 at 15:13, Philippe Mathieu-Daudé wrote:
>
> Expose the clock frequency via the QOM 'freq-hz' property,
> as it might be useful for QTests.
>
> HMP example:
>
> $ qemu-system-mips -S -monitor stdio -M mipssim
> (qemu) qom-get /machine/cpu-refclk freq-hz
> 1200
>
>
want
to write changes, now we have to re-count characters to decide
if we need to increase the size of the array. The memory allocation
on the heap here is a tiny overhead that we only incur at startup.
The g_autofree approach is much better.
For this version of the patch:
Reviewed-by: Peter Maydell
thanks
-- PMM
On Wed, 8 May 2024 at 03:30, Song Gao wrote:
>
> The char pointer 'ramName' point to a block of memory, but never free it.
> Use a small fixed-size buffer for 'ramName'.
>
> Resolves: Coverity CID 1544773
>
> Fixes: 0cf1478d6 ("hw/loongarch: Add numa support")
> Signed-off-by: Song Gao
> ---
>
On Wed, May 08, 2024 at 09:02:16AM +0100, Daniel P. Berrangé wrote:
> On Fri, May 03, 2024 at 12:23:51PM -0400, Peter Xu wrote:
> > On Fri, Apr 26, 2024 at 11:20:35AM -0300, Fabiano Rosas wrote:
> > > When the migration using the "file:" URI was implemented, I don't
&
and the list of devices can start with a minumum; an
extreme case is we add one device only if something broke first with a
stable ABI.
Then if the ABI is stable, we need to go through the deprecation procedure,
and that takes two releases. We can drop the device in migration-test in
the release of when deprecation starts.
Thanks,
--
Peter Xu
ry
> and
> discussion, I am leaving this to be addressed in a separate patch.
I assume Jag will pick this up then.
Thanks,
--
Peter Xu
mutex_unlock calls by
> the WITH_QEMU_LOCK_GUARD() macro.
>
> Signed-off-by: Philippe Mathieu-Daudé
> Signed-off-by: Mattias Nissler
> Reviewed-by: Mattias Nissler
Reviewed-by: Peter Xu
--
Peter Xu
. The default limit is 4096 bytes, matching the previous
> maximum buffer size. A new x-max-bounce-buffer-size parameter is
> provided to configure the limit for PCI devices.
>
> Signed-off-by: Mattias Nissler
Acked-by: Peter Xu
--
Peter Xu
pp, struct virtio_gpu_scanout, 2),
VMSTATE_UINT32_V(fb.width, struct virtio_gpu_scanout, 2),
VMSTATE_UINT32_V(fb.height, struct virtio_gpu_scanout, 2),
VMSTATE_UINT32_V(fb.stride, struct virtio_gpu_scanout, 2),
VMSTATE_UINT32_V(fb.offset, struct virtio_gpu_scanout, 2),
Thanks,
--
Peter Xu
On Tue, May 07, 2024 at 01:50:43AM +, Gonglei (Arei) wrote:
> Hello,
>
> > -Original Message-
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Monday, May 6, 2024 11:18 PM
> > To: Gonglei (Arei)
> > Cc: Daniel P. Berrangé ; Markus Armbru
al more or less on allowing
concurrent vfio migrations, so it will be greatly helpful to have your
input / reviews, also making sure the ultimate solution will work for all
the use cases.
Thanks,
--
Peter Xu
On Tue, 7 May 2024 at 16:47, Peter Xu wrote:
>
> On Tue, May 07, 2024 at 04:12:34PM +0800, gaosong wrote:
> > Just remove CONIFG_KVM would be OK?
>
> You're the loongarch maintainer so I'd say your call. :)
>
> If you're not yet sure, IMHO we should go with the simplest,
as-is if maintainers are happy.
Thanks,
--
Peter Xu
On Tue, May 07, 2024 at 04:12:34PM +0800, gaosong wrote:
> Just remove CONIFG_KVM would be OK?
You're the loongarch maintainer so I'd say your call. :)
If you're not yet sure, IMHO we should go with the simplest, which is the
original oneliner patch.
Thanks,
--
Peter Xu
On Fri, 3 May 2024 at 13:43, Daniel Henrique Barboza
wrote:
>
> Hi,
>
> In this RFC I want to check with Gerd and others if it's ok to add a PCI
> id for the RISC-V IOMMU device. It's currently under review in [1]. The
> idea is to fold this patch into the RISC-V IOMMU series if we're all ok
>
On Tue, May 07, 2024 at 03:19:17PM +0400, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Signed-off-by: Marc-André Lureau
Reviewed-by: Peter Xu
--
Peter Xu
t; Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/audio/virtio-snd.c | 2 +-
> hw/rtc/ls7a_rtc.c | 2 +-
> target/i386/gdbstub.c | 2 +-
> tests/qtest/nvme-test.c | 2 +-
> tests/qtest/ufs-test.c | 2 +-
Reviewed-by: Peter Maydell
thanks
-- PMM
On Tue, 7 May 2024 at 11:50, Paolo Bonzini wrote:
>
> Ensure that they go through unmodified, instead of removing one layer
> of quoting.
Do you have an example of what goes wrong that we could
mention in the commit message ?
thanks
-- PMM
On Mon, 6 May 2024 at 07:20, Tanmay wrote:
>
> Hi,
>
> I have added a patch inline that fixes indentation and formatting for some
> files as listed in https://gitlab.com/qemu-project/qemu/-/issues/373.
>
> Thanks,
> Tanmay
Hi; thanks for this patch. Unfortunately there seem to be some
problems
On Mon, 6 May 2024 at 10:34, Philippe Mathieu-Daudé wrote:
>
> Hi,
>
> On 5/5/24 16:05, Inès Varhol wrote:
> > Signed-off-by: Inès Varhol
> > ---
> > hw/char/stm32l4x5_usart.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/hw/char/stm32l4x5_usart.c
On Sun, 5 May 2024 at 15:06, Inès Varhol wrote:
>
> Signed-off-by: Inès Varhol
In general you should try to avoid commits with no commit message.
Sometimes there really isn't anything to say beyond what the
subject line is, but that should be the exception rather than
the usual thing.
> ---
>
On Sun, 5 May 2024 at 15:16, Inès Varhol wrote:
>
> Signed-off-by: Arnaud Minier
> Signed-off-by: Inès Varhol
Applied to target-arm.next, thanks.
-- PMM
On Sat, 4 May 2024 at 15:17, Dorjoy Chowdhury wrote:
>
> The value of the mp-affinity property being set in npcm7xx_realize is
> always the same as the default value it would have when arm_cpu_realizefn
> is called if the property is not set here. So there is no need to set
> the property value
On Fri, 3 May 2024 at 16:35, Zenghui Yu wrote:
>
> We wrongly encoded ID_AA64PFR1_EL1 using {3,0,0,4,2} in hvf_sreg_match[] so
> we fail to get the expected ARMCPRegInfo from cp_regs hash table with the
> wrong key.
>
> Fix it with the correct encoding {3,0,0,4,1}. With that fixed, the Linux
>
On Mon, 6 May 2024 at 21:21, Richard Henderson
wrote:
>
> The host does not have the correct libraries installed for static pie,
> which causes host/guest address space interference for some tests.
> There's no real gain from linking statically, so drop it.
>
> Signed-off-by: Richard Henderson
>
On Tue, 7 May 2024 at 01:11, Salil Mehta wrote:
>
> > From: Peter Maydell
> > Sent: Monday, May 6, 2024 10:29 AM
> > To: Salil Mehta
> >
> > On Mon, 6 May 2024 at 10:06, Salil Mehta
> > wrote:
> > >
> > > Hi Peter,
> >
On Mon, May 06, 2024 at 06:26:46PM +0200, Maciej S. Szmigiero wrote:
> On 29.04.2024 17:09, Peter Xu wrote:
> > On Fri, Apr 26, 2024 at 07:34:09PM +0200, Maciej S. Szmigiero wrote:
> > > On 24.04.2024 00:35, Peter Xu wrote:
> > > > On Wed, Apr 24, 2024 at 12:25:0
On Mon, May 06, 2024 at 06:58:00AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> [...]
>
> > I also copied qemu-devel starting from now.
>
> My bad, I messed that up!
Het, do you want to send a patch?
Thanks,
--
Peter Xu
On Mon, May 06, 2024 at 12:08:43PM +0200, Jinpu Wang wrote:
> Hi Peter, hi Daniel,
Hi, Jinpu,
Thanks for sharing this test results. Sounds like a great news.
What's your plan next? Would it then be worthwhile / possible moving QEMU
into that direction? Would that greatly simplify rdma c
On Mon, May 06, 2024 at 02:06:28AM +, Gonglei (Arei) wrote:
> Hi, Peter
Hey, Lei,
Happy to see you around again after years.
> RDMA features high bandwidth, low latency (in non-blocking lossless
> network), and direct remote memory access by bypassing the CPU (As you
> know, C
On Mon, May 06, 2024 at 11:38:00AM -0300, Fabiano Rosas wrote:
> Markus Armbruster writes:
>
> > Peter, Fabiano, I'd like to hear your opinion on the issue discussed
> > below.
> >
> > Avihai Horon writes:
> >
> >> On 02/05/2024 13:22, Joao Mar
terx/qemu/-/jobs/6787790601
IIUC it should be the same for all 32bits systems that do not support 64bit
atomics. Perhaps the easiest fix is switching all *bounce_buffer_size to 32bit.
Thanks,
--
Peter Xu
On Mon, 6 May 2024 at 10:06, Salil Mehta wrote:
>
> Hi Peter,
>
> Thanks for the review.
>
> > From: Peter Maydell
> > When do we need to destroy a single address space in this way that means
> > we need to keep a count of how many ASes the CPU currently h
On Tue, 12 Mar 2024 at 02:02, Salil Mehta wrote:
>
> Virtual CPU Hot-unplug leads to unrealization of a CPU object. This also
> involves destruction of the CPU AddressSpace. Add common function to help
> destroy the CPU AddressSpace.
>
> Signed-off-by: Salil Mehta
> Tested-by: Vishnu Pajjuri
>
On Fri, 3 May 2024 at 19:14, Dorjoy Chowdhury wrote:
>
> On Fri, May 3, 2024 at 10:28 PM Peter Maydell
> wrote:
> > In the meantime, there is one tiny bit of this that we can
> > do now:
> >
> > > diff --git a/hw/arm/npcm7xx.c b/hw/arm/npcm7xx.c
>
On Fri, May 03, 2024 at 06:19:30PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Apr 26, 2024 at 11:20:40AM -0300, Fabiano Rosas wrote:
> >> We're about to enable the use of O_DIRECT in the migration code and
> >> due to the alignment restrictions
On Fri, May 03, 2024 at 06:31:06PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, May 03, 2024 at 04:56:08PM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> > On Fri, Apr 26, 2024 at 11:20:35AM -0300, Fabiano Rosas wrote:
> discussion[1] about it in the libvirt mailing list. Having direct-io
> even without multifd might still be useful for libvirt.
>
> 1-
> https://lists.libvirt.org/archives/list/de...@lists.libvirt.org/thread/K4BDDJDMJ22XMJEFAUE323H5S5E47VQX/
Ah that's fine then. Maybe add a comment somewhere for future readers? Or
a sentence in the commit log would work too.
--
Peter Xu
On Fri, May 03, 2024 at 05:54:28PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Apr 26, 2024 at 11:20:38AM -0300, Fabiano Rosas wrote:
> >> When multifd is used along with mapped-ram, we can take benefit of a
> >> filesystem that supports the O_DIRE
On Fri, May 03, 2024 at 05:49:32PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Apr 26, 2024 at 11:20:37AM -0300, Fabiano Rosas wrote:
> >> Add the direct-io migration parameter that tells the migration code to
> >> use O_DIRECT when opening the
On Fri, May 03, 2024 at 05:36:59PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Apr 26, 2024 at 11:20:36AM -0300, Fabiano Rosas wrote:
> >> When doing file migration, QEMU accepts an offset that should be
> >> skipped when writing the migration s
On Fri, May 03, 2024 at 04:56:08PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Apr 26, 2024 at 11:20:35AM -0300, Fabiano Rosas wrote:
> >> When the migration using the "file:" URI was implemented, I don't
> >> think any of us
ming. The
> > > monitor
> > > can be used to change settings (such as migration parameters)
> > > prior
> > > to issuing the migrate\_incoming to allow the migration to begin.
> > >
> > >I figure we should call it "the migration source" instead of "the URI"
> > >here.
> >
> > I think it's worse. We need a proper way to refer exclusively to "the
> > thing that the user passes as an argument to the migrate command".
>
> Agreed. My thoughts:
>
> "migration URI" -> "migration URI/channel"
> or
> "migration URI" -> "migration stream"
"stream" might imply more on the protocol itself to me, e.g. how the
migration headers are defined, rather than the entity / fabric we use to
send the data stream?
Maybe we can simply do s/URI/channel/? As "channel" can also imply the URI
in this case as yet another (old) format to specify the migration channels.
It's like we always use QIOChannels underneath whatever way we specify the
channels (either URI or the new "channels" API).
I also copied qemu-devel starting from now.
Thanks,
--
Peter Xu
code at all: we
dup(), then we try F_SETFL on all the possible flags got passed in.
However AFAICT due to the fact that dup()ed FDs will share "struct file" it
means mostly all flags will be shared, except close-on-exec. I don't ever
see anything protecting that F_SETFL to only touch close-on-exec, I think
it means it'll silently change file status flags for the other fd which we
dup()ed from. Does it mean that we have issue already with such dup() usage?
Thanks,
--
Peter Xu
On Fri, Apr 26, 2024 at 11:20:39AM -0300, Fabiano Rosas wrote:
> The tests are only allowed to run in systems that know about the
> O_DIRECT flag and in filesystems which support it.
>
> Signed-off-by: Fabiano Rosas
Mostly:
Reviewed-by: Peter Xu
Two trivial comments below.
&g
sport_compatible(MigrationAddress *addr,
> Error **errp)
> @@ -180,6 +196,13 @@
> migration_channels_and_transport_compatible(MigrationAddress *addr,
> return false;
> }
>
> +if (migration_needs_multiple_fds() &&
> +!transport_supports_multiple_fds(addr)) {
> +error_setg(errp,
> + "Migration requires a transport that allows for multiple
> fds (e.g. file)");
> +return false;
> +}
> +
> return true;
> }
>
> --
> 2.35.3
>
--
Peter Xu
res': [ 'unstable' ] },
> '*vcpu-dirty-limit': 'uint64',
> '*mode': 'MigMode',
> -'*zero-page-detection': 'ZeroPageDetection'} }
> +'*zero-page-detection': 'ZeroPageDetection',
> +'*direct-io': 'bool' } }
>
> ##
> # @query-migrate-parameters:
> diff --git a/util/osdep.c b/util/osdep.c
> index e996c4744a..d0227a60ab 100644
> --- a/util/osdep.c
> +++ b/util/osdep.c
> @@ -277,6 +277,15 @@ int qemu_lock_fd_test(int fd, int64_t start, int64_t
> len, bool exclusive)
> }
> #endif
>
> +bool qemu_has_direct_io(void)
> +{
> +#ifdef O_DIRECT
> +return true;
> +#else
> +return false;
> +#endif
> +}
> +
> static int qemu_open_cloexec(const char *name, int flags, mode_t mode)
> {
> int ret;
> --
> 2.35.3
>
--
Peter Xu
eCommon args = {
> .connect_uri = uri,
> .listen_uri = "defer",
> +.start_hook = file_offset_start_hook,
> .finish_hook = file_offset_finish_hook,
> };
>
> test_file_common(, false);
> }
> +#endif
>
> static void test_precopy_file_offset_bad(void)
> {
> @@ -3636,8 +3694,10 @@ int main(int argc, char **argv)
>
> migration_test_add("/migration/precopy/file",
> test_precopy_file);
> +#ifndef _WIN32
> migration_test_add("/migration/precopy/file/offset",
> test_precopy_file_offset);
> +#endif
> migration_test_add("/migration/precopy/file/offset/bad",
> test_precopy_file_offset_bad);
>
> --
> 2.35.3
>
--
Peter Xu
On Thu, 2 May 2024 at 15:16, Alexandra Diupina wrote:
>
> Add xlnx_dpdma_read_descriptor() and
> xlnx_dpdma_write_descriptor() functions.
> xlnx_dpdma_read_descriptor() combines reading a
> descriptor from desc_addr by calling dma_memory_read()
> and swapping the desc fields from guest memory
On Fri, 19 Apr 2024 at 19:31, Dorjoy Chowdhury wrote:
>
> Some ARM CPUs advertise themselves as SMT by having the MT[24] bit set
> to 1 in the MPIDR register. These CPUs have the thread id in Aff0[7:0]
> bits, CPU id in Aff1[15:8] bits and cluster id in Aff2[23:16] bits in
> MPIDR.
>
> On the
o
issues.
Thanks,
===
>From 2f6b6d1224486d8ee830a7afe34738a07003b863 Mon Sep 17 00:00:00 2001
From: Peter Xu
Date: Fri, 3 May 2024 11:27:20 -0400
Subject: [PATCH] monitor: Drop monitor_fdset_dup_fd_add()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bi
(_fdset->dup_fds) && mon_refcount == 0)) &&
> -runstate_is_running()) {
> +if (mon_fdset_fd->removed ||
> +(QLIST_EMPTY(_fdset->dup_fds) && mon_refcount == 0 &&
> + runstate_is_running())) {
> close(mon_fdset_fd->fd);
> g_free(mon_fdset_fd->opaque);
> QLIST_REMOVE(mon_fdset_fd, next);
> --
> 2.35.3
>
--
Peter Xu
Peter missed the Sphinx HMP document for the "resume/-r" flag in commit
7a4da28b26 ("qmp: hmp: add migrate "resume" option"). Add it.
When at it, slightly cleanup the lines around:
- Move "detach/-d" to a separate section rather than appending it at t
On Fri, May 03, 2024 at 04:08:45PM +0200, Markus Armbruster wrote:
> If there's still time, suggest to tweak the subject to
>
> hmp/migration: Fix "migrate" command's documentation
Yes there is. :)
>
> Peter Xu writes:
>
> > On Fri, May 03, 2024 at 0
sy task.
It'll be good to know whether Dan's suggestion would work first, without
rewritting everything yet so far. Not sure whether some perf test could
help with the rsocket APIs even without QEMU's involvements (or looking for
test data supporting / invalidate such conversions).
Thanks,
--
Peter Xu
On Fri, May 03, 2024 at 08:58:09AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > Peter missed the Sphinx HMP document for the "resume/-r" flag in commit
> > 7a4da28b26 ("qmp: hmp: add migrate "resume" option"). Add it. Avoid
>
On Fri, 16 Jun 2023 at 11:03, Song Gao wrote:
>
> From: Tianrui Zhao
>
> 1. Implement some functions for LoongArch numa support;
> 2. Implement fdt_add_memory_node() for fdt;
> 3. build_srat() fills node_id and adds build numa memory.
>
> Reviewed-by: Song Gao
> Signed-off-by: Tianrui Zhao
>
On Mon, 26 Jun 2023 at 13:28, Michael S. Tsirkin wrote:
>
> From: Jonathan Cameron
>
> Current implementation is very simple so many of the corner
> cases do not exist (e.g. fragmenting larger poison list entries)
Hi; Coverity has just spotted what looks like a bug in this
function (CID
On Mon, 15 May 2023 at 17:07, Stefan Hajnoczi wrote:
>
> From: Sam Li
>
> Add zoned device option to host_device BlockDriver. It will be presented only
> for zoned host block devices. By adding zone management operations to the
> host_block_device BlockDriver, users can use the new block layer
On Wed, 1 May 2024 at 19:28, Daniel P. Berrangé wrote:
> I wonder, however, whether we would benefit from changing how we
> update the VERSION file.
>
> eg instead of re-using the micro digit to indicate a dev or rc
> snapshot, represent those explicitly. eg "9.1.0-dev" and
> "9.1.0-rc1",
26==by 0x7A5777: select_machine (vl.c:1664)
> ==210026==by 0x7A5777: qemu_create_machine (vl.c:2104)
> ==210026==by 0x7A5777: qemu_init (vl.c:3667)
> ==210026== by 0x47E528: main (main.c:47)
>
> Cc: Arnaud Minier
> Cc: Inès Varhol
> Cc: Peter Maydell
> Si
SETFL, flags);
flags = fcntl(fd, F_GETFL);
printf("updated new flags: 0x%x\n", flags);
return 0;
}
$ make fcntl
cc fcntl.c -o fcntl
$ ./fcntl
old fd flags: 0x8002
new fd flags: 0x8002
updated new flags: 0xc002
8<
Perhaps I missed something important?
--
Peter Xu
rtially impl feature can already be consumed).
Thanks,
--
Peter Xu
On Thu, May 02, 2024 at 03:30:58PM +0200, Jinpu Wang wrote:
> Hi Michael, Hi Peter,
>
>
> On Thu, May 2, 2024 at 3:23 PM Michael Galaxy wrote:
> >
> > Yu Zhang / Jinpu,
> >
> > Any possibility (at your lesiure, and within the disclosure rules of
> > y
gt; Reviewed-by: Michael Galaxy
> Tested-by: Philippe Mathieu-Daudé
> Cc: Li Zhijian
> Cc: Peter Xu
> ---
> v2:
> - fixed an email address
> - added "Tested-by: "
> MAINTAINERS | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b
Peter missed the Sphinx HMP document for the "resume/-r" flag in commit
7a4da28b26 ("qmp: hmp: add migrate "resume" option"). Add it. Avoid
adding a Fixes to make life easier for the stable maintainer.
When at it, slightly cleanup the lines, move "detach/-d
On Thu, 2 May 2024 at 09:02, Daniel P. Berrangé wrote:
>
> On Wed, May 01, 2024 at 09:40:16PM -0700, Roman Kiryanov wrote:
> > Hi QEMU,
> >
> > I work in Android Studio Emulator and we would like to develop devices
> > in C++. Unfortunately, QEMU headers cannot be used with C++ as is
> > (e.g.
rget is v8.
https://lore.kernel.org/r/20240304100554.1143763-1-mniss...@rivosinc.com
Thanks,
--
Peter Xu
tion",
> > > + "\n\t\t\t -r to resume a paused migration",
> > > .cmd= hmp_migrate,
> > > },
> > >
> > >
> > > SRST
> > > -``migrate [-d] [-b]`` *uri*
> > > +``migrate [-d]`` *uri*
> > >Migrate to *uri* (using -d to not wait for completion).
> > > -
> > > - ``-b``
> > > -for migration with full copy of disk
> > > ERST
> >
> > Not this patch's fault, but here goes anyway: -r is undocumented here.
>
> Probably one for Peter I guess.
Yes, and I'll send a patch! :-D
--
Peter Xu
compatibility for
building on 10.12 and earlier versions.
Signed-off-by: Peter Maydell
---
ui/cocoa.m | 13 -
1 file changed, 13 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 25e0db9dd0b..981615a8b92 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -50,23 +50,10 @@
#include
On Thu, 2 May 2024 at 14:50, Marcin Juszkiewicz
wrote:
> Both hw/arm/sbsa-ref.c and hw/arm/virt.c build cpu information in
> DeviceTree using "arm_build_mp_afinnity()" function. So if firmware
> parses it then it gets wrong values.
What wrong values? The values in the dtb should match the
Aff*
On Thu, 2 May 2024 at 14:11, Marcin Juszkiewicz
wrote:
>
> W dniu 2.05.2024 o 15:04, Dorjoy Chowdhury pisze:
> >> Should "return" also have "(1 << 24) |" to have MT=1 set?
> >>
> >> Otherwise MPIDR_EL1 = 0x000100 can mean core0 in cluster1 or core1 in
> >> cluster0.
> >>
> >> Value 0x1000100
On Tue, 30 Apr 2024 at 21:01, Ryan Mamone
wrote:
>
> From 617b2d92085d03524dcf5c223568a4856cdff47f Mon Sep 17 00:00:00 2001
>
> From: Ryan Mamone
>
> Date: Tue, 30 Apr 2024 13:20:50 -0400
>
> Subject: [PATCH] hw/display: Add SSD1306 dot matrix display controller support
Hi; thanks for this
On Thu, 2 May 2024 at 08:42, Philippe Mathieu-Daudé wrote:
>
> Check the function index is not negative and use an unsigned
> variable to avoid the following warning with GCC 13.2.0:
>
> [666/5358] Compiling C object libcommon.fa.p/hw_input_tsc2005.c.o
> hw/input/tsc2005.c: In function
On Thu, 2 May 2024 at 11:56, Marcin Juszkiewicz
wrote:
>
> W dniu 2.05.2024 o 12:37, Peter Maydell pisze:
> >> * what are the constraints on the Aff* fields (eg that kernel
> >> commit suggests Aff0 shouldn't be > 15)?
>
> > This one is apparently re
On Thu, 2 May 2024 at 10:11, Peter Maydell wrote:
> On the QEMU side I guess we should strive to set up the MPIDR
> fields to something plausibly matching the topology as defined
> by the user on the command line. Unanswered questions:
>
> * I guess we need some kind of back-com
On Thu, 2 May 2024 at 06:12, Sia Jee Heng wrote:
>
> Update the SPCR table to accommodate the SPCR Table version 4 [1].
> The SPCR table has been modified to adhere to the version 4 format [2].
>
> Meanwhile, the virt SPCR golden reference files have been updated to
> accommodate the SPCR Table
On Wed, 1 May 2024 at 19:08, Marcin Juszkiewicz
wrote:
>
> W dniu 22.04.2024 o 17:21, Richard Henderson pisze:
> >>> For Arm's CPUs they fall into two categories:
> >>> * older ones don't set MT in their MPIDR, and the Aff0
> >>> field is effectively the CPU number
> >>> * newer ones do
payload over the network. If we want to send a large network
> payload and analyze throughput, this option is useful.
I didn't see this when quickly going through the series. It's even
mentioned in test results later. Is it removed?
Thanks,
--
Peter Xu
OrNull',
> +'*multifd-packet-size' : 'uint64'} }
>
> ##
> # @migrate-set-parameters:
> @@ -1373,6 +1383,10 @@
> # characters. Setting this string to an empty string means disabling
> # DSA accelerator offloading. Defaults to an empty string. (since 9.2)
> #
> +# @multifd-packet-size: Packet size in bytes used to migrate data.
> +# The value needs to be a multiple of guest VM's page size.
> +# The default value is 524288 and max value is 4190208. (Since 9.2)
> +#
> # Features:
> #
> # @deprecated: Member @block-incremental is deprecated. Use
> @@ -1425,7 +1439,8 @@
> '*vcpu-dirty-limit': 'uint64',
> '*mode': 'MigMode',
> '*zero-page-detection': 'ZeroPageDetection',
> -'*multifd-dsa-accel': 'str'} }
> +'*multifd-dsa-accel': 'str',
> +'*multifd-packet-size': 'uint64'} }
>
> ##
> # @query-migrate-parameters:
> --
> 2.30.2
>
>
--
Peter Xu
d a way to unify
send/recv, as IIUC they do work similarly, setup() some dsa stuff, do some
zero page detection, cleanup() some dsa stuff. They look all the same
irrelevant of src/dst. I think it's nice if we can merge them.
> +
> thread_count = migrate_multifd_channels();
> multifd_recv_state = g_malloc0(sizeof(*multifd_recv_state));
> multifd_recv_state->params = g_new0(MultiFDRecvParams, thread_count);
> @@ -1616,13 +1640,12 @@ int multifd_recv_setup(Error **errp)
>
> for (i = 0; i < thread_count; i++) {
> MultiFDRecvParams *p = _recv_state->params[i];
> -int ret;
> -
> ret = multifd_recv_state->ops->recv_setup(p, errp);
> if (ret) {
> return ret;
> }
> }
> +
> return 0;
> }
>
> diff --git a/migration/multifd.h b/migration/multifd.h
> index 16e27db5e9..b3717fae24 100644
> --- a/migration/multifd.h
> +++ b/migration/multifd.h
> @@ -14,6 +14,7 @@
> #define QEMU_MIGRATION_MULTIFD_H
>
> #include "ram.h"
> +#include "qemu/dsa.h"
>
> typedef struct MultiFDRecvData MultiFDRecvData;
>
> --
> 2.30.2
>
>
--
Peter Xu
* @param batch_size The number of zero page checking tasks in the batch.
> + * @return A pointer to the general batch task initialized.
> + */
> +struct batch_task *
> +batch_task_init(int batch_size)
> +{
> +struct batch_task *task = g_malloc0(sizeof(struct batch_task));
> +task->addr = g_new0(ram_addr_t, batch_size);
> +task->results = g_new0(bool, batch_size);
> +task->dsa_batch = qemu_memalign(64, sizeof(struct dsa_batch_task));
> +buffer_zero_batch_task_init(task->dsa_batch, task->results, batch_size);
> +
> +return task;
> +}
> +
> +/**
> + * @brief Destroys a general buffer zero batch task.
> + *
> + * @param task A pointer to the general batch task to destroy.
> + */
> +void
> +batch_task_destroy(struct batch_task *task)
> +{
> +g_free(task->addr);
> +g_free(task->results);
> +buffer_zero_batch_task_destroy(task->dsa_batch);
> +qemu_vfree(task->dsa_batch);
> +g_free(task);
> +}
> +
> #endif
>
> --
> 2.30.2
>
>
--
Peter Xu
1 - 100 of 69894 matches
Mail list logo
