, TCGv_i64 s)
> +{
> +tcg_gen_xori_i64(d, s, 1ull << 63);
> +}
These will get a bit more complicated when we get to
handling FEAT_AFP, where abs or neg on a NaN doesn't
change its sign bit. But I guess we'll cross that bridge
when we get to it.
Reviewed-by: Peter Maydell
thanks
-- PMM
/arm/tcg/vec_helper.c| 4 +
> 4 files changed, 113 insertions(+), 80 deletions(-)
Reviewed-by: Peter Maydell
thanks
-- PMM
translate-a64.c | 205 +
> target/arm/tcg/vec_helper.c| 4 +
> 5 files changed, 143 insertions(+), 102 deletions(-)
>
Reviewed-by: Peter Maydell
thanks
-- PMM
On Mon, 6 May 2024 at 02:05, Richard Henderson
wrote:
>
> Convert all forms (scalar, vector, scalar indexed, vector indexed),
> which allows us to remove switch table entries elsewhere.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
On Mon, 6 May 2024 at 02:06, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 13 +
> target/arm/tcg/translate-a64.c | 426 +++--
> 2 files changed, 152 insertions(+), 287 deletions(-)
>
On Mon, 6 May 2024 at 02:05, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 4
> target/arm/tcg/translate-a64.c | 43 +++---
> 2 files changed, 18 insertions(+), 29 deletions(-)
>
On Mon, 6 May 2024 at 02:04, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 10
> target/arm/tcg/translate-a64.c | 43 ++
> 2 files changed, 22 insertions(+), 31 deletions(-)
>
On Mon, 6 May 2024 at 02:05, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 8 ++
> target/arm/tcg/translate-a64.c | 132 +++--
> 2 files changed, 51 insertions(+), 89 deletions(-)
>
On Mon, 6 May 2024 at 02:16, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 5
> target/arm/tcg/translate-a64.c | 50 ++
> 2 files changed, 8 insertions(+), 47 deletions(-)
Reviewed
On Mon, 6 May 2024 at 02:05, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 11
> target/arm/tcg/translate-a64.c | 97 --
> 2 files changed, 32 insertions(+), 76 deletions(-)
Reviewed
On Mon, 6 May 2024 at 02:05, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 6
> target/arm/tcg/translate-a64.c | 54 +++---
> 2 files changed, 10 insertions(+), 50 deletions(-)
>
On Mon, 6 May 2024 at 02:05, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 11 +
> target/arm/tcg/translate-a64.c | 78 +-
> 2 files changed, 21 insertions(+), 68 deletions(-)
On Mon, 6 May 2024 at 02:06, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/tcg/a64.decode | 21 +++--
> target/arm/tcg/translate-a64.c | 86 +++---
> 2 files changed, 54 insertions(+), 53 deletions(-)
On Thu, 23 May 2024 at 09:04, Daniel P. Berrangé wrote:
>
> On Wed, May 22, 2024 at 10:30:16PM +0300, Artyom Kunakovsky wrote:
> > fix linker error if the project was configured by the './configure
> > --cpu=unknown --target-list=riscv64-softmmu' command
>
> Isn't this simply user error, with
accident in a previous refactoring of the code).
>
> Signed-off-by: Thomas Huth
Reviewed-by: Peter Xu
Irrelevant of this patch, when I was looking at cleaning of bootfile it
looks to me that we're leaking bootpath in the test loops.. maybe we need a
bootfile_delete() at the entry of boot
nalyze-script
> ...
>
> Let's better fail the test in case the child did not exit properly, too.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Peter Xu
--
Peter Xu
On Wed, 22 May 2024 at 12:47, Daniel P. Berrangé wrote:
>
> On Wed, May 22, 2024 at 12:35:23PM +0100, Peter Maydell wrote:
> > On Wed, 22 May 2024 at 11:49, Akihiko Odaki
> > wrote:
> > >
> > > This fixes LeakSanitizer complaints with xkbcommon 1.6.0.
>
On Wed, 22 May 2024 at 11:49, Akihiko Odaki wrote:
>
> This fixes LeakSanitizer complaints with xkbcommon 1.6.0.
>
> Signed-off-by: Akihiko Odaki
> ---
> qemu-keymap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/qemu-keymap.c b/qemu-keymap.c
> index 8c80f7a4ed65..7a9f38cf9863
On Mon, 6 May 2024 at 02:08, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/helper.h| 16 +
> target/arm/tcg/translate-a64.h | 6 ++
> target/arm/tcg/gengvec64.c | 106 +++
> target/arm/tcg/translate-a64.c |
u stable process (I'd say that's
because we have a good stable tree maintainer..).
So we need this in qemu 8.1, 8.2 and 9.0?
> Fixes: 53da8b5a99 ("virtio-net: Add support for USO features")
> Signed-off-by: Fiona Ebner
Reviewed-by: Peter Xu
> ---
> hw/core/machine.c | 6 +++--
On Fri, May 17, 2024 at 03:01:59PM +0200, Yu Zhang wrote:
> Hello Michael and Peter,
Hi,
>
> Exactly, not so compelling, as I did it first only on servers widely
> used for production in our data center. The network adapters are
>
> Ethernet controller: Broadcom Inc. and subs
On Mon, 6 May 2024 at 02:08, Richard Henderson
wrote:
>
> This eliminates the last uses of these neon helpers.
> Incorporate the MO_64 expanders as an option to the vector expander.
>
> Signed-off-by: Richard Henderson
> +/*
> + * Set @res to the correctly saturated result.
> + * Set @qc
On Mon, 6 May 2024 at 02:10, Richard Henderson
wrote:
>
> These are the last instructions within disas_simd_three_reg_same
> and disas_simd_scalar_three_reg_same, so remove them.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/helper.h| 10 ++
> target/arm/tcg/a64.decode
On Sat, 11 May 2024 at 12:54, Richard Henderson
wrote:
>
> Some of these have been sitting on a branch for a couple of years.
> Except perhaps the first, which I assume to be some sort of odd
> build error from the time, they still seem reasonable.
>
> There are some updates for SME1, but not yet
on't have makefile infrastructure for building
any of these "trivial test" test_foo.s files, so this is fine.
Reviewed-by: Peter Maydell
thanks
-- PMM
> 1 file changed, 21 insertions(+), 30 deletions(-)
Reviewed-by: Peter Maydell
thanks
-- PMM
Richard Henderson
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
e can be ignored. This leaves only
> XER and CCR as the only special registers to be copied.
>
> Signed-off-by: Richard Henderson
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Sat, 11 May 2024 at 12:54, Richard Henderson
wrote:
>
> Hoist the "master vs apprentice" label to apprentice(), since
> we will want different labels for dumping. Remove all of the
> "mismatch" text from reginfo_dump_mismatch -- just print "vs".
>
> Signed-off-by: Richard Henderson
> ---
>
On Mon, 6 May 2024 at 02:04, Richard Henderson
wrote:
>
> Split some routines out of translate-a64.c and translate-sve.c
> that are used by both.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
On Mon, 6 May 2024 at 02:05, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
:
> Steven Sistare writes:
>
> > Hi Peter, Hi Fabiano,
> >Will you have time to review the migration guts of this series any
> time soon?
> > In particular:
> >
> > [PATCH V1 05/26] migration: precreate vmstate
> > [PATCH V1 06/26] migration: p
On Wed, 15 May 2024 at 13:49, Philippe Mathieu-Daudé wrote:
>
> Hi Perry,
>
> On 14/5/24 01:33, Perry Hung wrote:
> > Writes from GDB to memory-mapped IO regions are currently silently
> > dropped. cpu_memory_rw_debug() calls address_space_write_rom(), which
> > calls
On Tue, 6 Feb 2024 at 13:25, Cord Amfmgm wrote:
>
> This changes the ohci validation to not assert if invalid
> data is fed to the ohci controller. The poc suggested in
> https://bugs.launchpad.net/qemu/+bug/1907042
> and then migrated to bug #303 does the following to
> feed it a SETUP pid and
w/usb/trace-events
> +++ b/hw/usb/trace-events
> @@ -28,6 +28,7 @@ usb_ohci_iso_td_data_overrun(int ret, ssize_t len)
> "DataOverrun %d > %zu"
> usb_ohci_iso_td_data_underrun(int ret) "DataUnderrun %d"
> usb_ohci_iso_td_nak(int ret) "got NAK/STALL %d"
&g
On Mon, 13 May 2024 at 12:35, Alex Bennée wrote:
>
> We actually had the stubs to implement this. The main pain is getting
> the binary name into the program so we can validate the result.
Could you write the commit message so that it makes sense
without reading the Subject line, please ?
>
On Mon, 13 May 2024 at 12:35, Alex Bennée wrote:
>
> We shouldn't use for our own implementation. Also the base
> types we need live in as doesn't exist for the
> bare metal compilers.
>
> Signed-off-by: Alex Bennée
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On Mon, 13 May 2024 at 12:35, Alex Bennée wrote:
>
> It's a pain when you come back to a code base you haven't touched in a
> while and realise whatever indent settings you were using having
> carried over. Add an editorconfig and be done with it.
>
> Signed-off-by: Alex Bennée
> ---
>
he clock frequency,
> and adds QTests checking that clock enable in RCC has the
> expected results.
>
> Philippe Mathieu-Daudé suggested the following :
> ".. We could add the clock properties
> directly in qdev_init_clock_in(). Seems useful for the QTest
> framework."
&g
On Wed, 8 May 2024 at 22:27, Philippe Mathieu-Daudé wrote:
>
> On 8/5/24 19:46, Peter Maydell wrote:
> > On Wed, 8 May 2024 at 15:13, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Expose the clock frequency via the QOM 'freq-hz' property,
> >> as
emented in QEMU).
> In order to connect USART devices to EXTI, this commit consolidates
> constants `EXTI_NUM_INTERRUPT_OUT_LINES` (40) and
> `EXTI_NUM_GPIO_EVENT_IN_LINES` (16) into `EXTI_NUM_LINES` (40).
>
> Signed-off-by: Inès Varhol
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
ts IRQs to the CPU.
> The existing QTest for the USART (tests/qtest/stm32l4x5_usart-test.c)
> checks that USART1_IRQ in the CPU is pending when expected so it
> confirms that the connection through the EXTI still works.
>
> Signed-off-by: Inès Varhol
Reviewed-by: Peter Maydell
thanks
-- PMM
On Sun, 12 May 2024 at 11:20, Inès Varhol wrote:
>
> The previous implementation for EXTI interrupts only handled
> "configurable" interrupts, like those originating from STM32L4x5 SYSCFG
> (the only device currently connected to the EXTI up until now).
> In order to connect STM32L4x5 USART to
On Sun, 12 May 2024 at 10:00, Rayhan Faizel wrote:
>
> None of the RPi boards have ADC on-board. In real life, an external ADC chip
> is required to operate on analog signals.
>
> Signed-off-by: Rayhan Faizel
Applied to target-arm.next, thanks.
-- PMM
t;
remains out-of-order, because this is not its own file
but is currently part of the aspeed.rst file.
Signed-off-by: Peter Maydell
---
docs/system/target-arm.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/system/target-arm.rst b/docs/system/target-arm
On Tue, 7 May 2024 at 14:04, Sebastian Huber
wrote:
>
> The Zynq 7000 SoCs contain two Arm Cortex-A9 MPCore (the Zynq 7000S have only
> one core). Add support for up to two simulated cores.
>
> Signed-off-by: Sebastian Huber
> ---
> hw/arm/xilinx_zynq.c | 42
On Tue, 7 May 2024 at 14:04, Sebastian Huber
wrote:
>
> The Zynq 7000 SoCs contain a CoreLink L2C-310 cache controller. Add the
> corresponding Qemu device to the xilinx-zynq-a9 machine.
>
> Signed-off-by: Sebastian Huber
> ---
> hw/arm/xilinx_zynq.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
On Tue, 7 May 2024 at 14:00, Sebastian Huber
wrote:
>
> According to the GICv2 specification section 4.3.12, "Interrupt Processor
> Targets Registers, GICD_ITARGETSRn":
>
> "Any change to a CPU targets field value:
> [...]
> * Has an effect on any pending interrupts. This means:
> - adding a
On Tue, 7 May 2024 at 14:00, Sebastian Huber
wrote:
>
> According to the GICv2 specification section 4.3.7, "Interrupt Set-Pending
> Registers, GICD_ISPENDRn":
>
> "In a multiprocessor implementation, GICD_ISPENDR0 is banked for each
> connected
> processor. This register holds the Set-pending
On Wed, 8 May 2024 at 09:15, Tanmay Patil wrote:
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/373
>
> Files changed:
> - hw/arm/boot.c
> - hw/char/omap_uart.c
> - hw/gpio/zaurus.c
> - hw/input/tsc2005.c
>
> Signed-off-by: Tanmay Patil
Thanks for
005.c: In function 'tsc2005_timer_tick':
> hw/input/tsc2005.c:416:26: warning: array subscript has type 'char'
> [-Wchar-subscripts]
> 416 | s->dav |= mode_regs[s->function];
> | ~^~
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
On Fri, 17 May 2024 at 09:31, Sebastian Huber
wrote:
>
> Hello,
>
> is the mailing list the right place for contributions like this?
Yes it is, and this is on my todo list to review. Sorry for
not getting back to you earlier, but I was on holiday last
week and at a conference this week. I hope
On Thu, 16 May 2024 at 18:34, Michael S. Tsirkin wrote:
>
> On Thu, May 16, 2024 at 06:29:39PM +0100, Peter Maydell wrote:
> > On Thu, 16 May 2024 at 17:22, Daniel P. Berrangé
> > wrote:
> > >
> > > Currently we have a short paragraph saying that patches mus
On Thu, 16 May 2024 at 18:20, Michael S. Tsirkin wrote:
>
> On Thu, May 16, 2024 at 05:22:27PM +0100, Daniel P. Berrangé wrote:
> > AFAICT at its current state of (im)maturity the question of licensing
> > of AI code generator output does not have a broadly accepted / settled
> > legal position.
bout
our approach to pseudonyms. I think we should probably say
something, but I don't know if we have an in-practice consensus
there, so maybe we should approach that as a separate change on
top of this patch.
So for this patch:
Reviewed-by: Peter Maydell
thanks
-- PMM
Looks good here, thanks.
On Thu, May 16, 2024, 2:40 a.m. wrote:
> From: Marc-André Lureau
>
> Hi,
>
> The aforementioned patch breaks virtio-gpu device migrations for versions
> pre-9.0/9.0, both forwards and backwards. Versioning of `VMS_STRUCT` is
> more
> complex than it may initially
On Thu, 16 May 2024 at 13:04, Gerd Hoffmann wrote:
>
> Remove myself from usb entries.
> Flip status to "Orphan" for entries which have nobody else listed.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f52e2912fc3..d81376f84746 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
Thanks for your
On Thu, 16 May 2024 at 10:12, Song Gao wrote:
>
> The following changes since commit 922582ace2df59572a671f5c0c5c6c5c706995e5:
>
> Merge tag 'pull-hppa-20240515' of https://gitlab.com/rth7680/qemu into
> staging (2024-05-15 11:46:58 +0200)
>
> are available in the Git repository at:
>
>
On Thu, 16 May 2024 at 10:12, Song Gao wrote:
>
> From: Bibo Mao
>
> Since migration test case requires compat machine type support,
> compat machine is added for qemu 9.1 here.
This is not a good justification for adding versioned machine types.
Adding versioned machine types is putting a
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
301 - 400 of 70253 matches
Mail list logo
