On Thu, Nov 25, 2021 at 12:08:16PM -0300, Daniel Henrique Barboza wrote:
> From: Gustavo Romero
>
> Following up the rfebb implementation, this patch adds the EBB exception
> support that are triggered by Performance Monitor alerts. This exception
> occurs when an enabled PMU condition or event h
On Thu, Nov 25, 2021 at 12:08:15PM -0300, Daniel Henrique Barboza wrote:
> An Event-Based Branch (EBB) allows applications to change the NIA when a
> event-based exception occurs. Event-based exceptions are enabled by
> setting the Branch Event Status and Control Register (BESCR). If the
> event-ba
On Thu, Nov 25, 2021 at 12:08:17PM -0300, Daniel Henrique Barboza wrote:
> The current logic is only considering event-based exceptions triggered
> by the performance monitor. This is true now, but we might want to add
> support for external event-based exceptions in the future.
>
> Let's make it
How to simulate a microcontroller whose ROM and RAM are the same address
space?
Some microcontrollers have a Haval architecture. ROM and RAM have separate
buses, which means they have the same address space, such as 0-0x100. How
do I set the memory region?
Thanks!
On Mon, Nov 29, 2021 at 06:09:41PM -0300, Daniel Henrique Barboza wrote:
>
>
> On 11/27/21 02:14, David Gibson wrote:
> > On Fri, Nov 26, 2021 at 06:51:38PM +0100, Cédric le Goater wrote:
> > > On 11/26/21 02:11, David Gibson wrote:
> > > > On Thu, Nov 25, 2021 at 07:42:02PM -0300, Daniel Henriqu
On Thu, Nov 25, 2021 at 12:08:14PM -0300, Daniel Henrique Barboza wrote:
> PM_RUN_INST_CMPL, instructions completed with the run latch set, is
> the architected PowerISA v3.1 event defined with PMC4SEL = 0xFA.
>
> Implement it by checking for the CTRL RUN bit before incrementing the
> counter. To
On Mon, Nov 29, 2021 at 03:57:51PM -0300, Leandro Lupori wrote:
> When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte
> offset, causing the first byte of the adjacent PTE to be corrupted.
> This caused a panic when booting FreeBSD, using the Hash MMU.
>
> Fixes: a2dd4e83e76b ("
This supports virtio-mem-pci device on "virt" platform, by simply
following the implementation on x86.
* The patch was written by David Hildenbrand
modified by Jonathan Cameron
* This implements the hotplug handlers to support virtio-mem-pci
device hot-add, while the hot-remove
This series supports virtio-mem-pci device, by simply following the
implementation on x86. The exception is the block size is 1GB on ARM64
instead of 128MB on x86.
The work was done by David Hildenbrand and then Jonathan Cameron. I'm
taking the patch and putting more efforts, which is all about te
Ditto - not for 6.2.
I'm happy with this once the vhost and vhost-user patches go in.
Looks like vhost-user-vgpu, vhost-user-input and vhost-user-vsock also
return -1 on vhost_user_*_handle_config_change, so presumably those
should be fixed too.
On Thu, Nov 11, 2021 at 06:33:54PM +0300, Roman Ka
As mst said, not for 6.2.
On Thu, Nov 11, 2021 at 06:33:45PM +0300, Roman Kagan wrote:
> vhost-user-blk realize only attempts to reconnect if the previous
> connection attempt failed on "a problem with the connection and not an
> error related to the content (which would fail again the same way in
> >
> > I see. I hadn't looked at the rest of the series yet because I ran out
> > of time, but now that I'm skimming them, I see quite a few places that
> > use non-EPROTO, but I wonder which of them actually should be
> > reconnected. So far all I saw were presumably persistent errors where a
>
Just a commit message nit. Otherwise I'm happy with this. OFC should not
be queued for 6.2.
On Fri, Nov 26, 2021 at 10:00:18AM +0800, Andy Pei wrote:
> Turn on pre-defined feature VIRTIO_BLK_F_SIZE_MAX virtio blk device
> to avoid guest DMA request size is too large to exceed hardware spec.
Gramm
Reconnect feature was never prepared to handle server options changed
on reconnect. Let's be stricter and check what exactly is changed. If
server capabilities just got richer don't worry. Otherwise fail and
drop the established connection.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
v2: by
On Sun, Nov 28, 2021 at 04:47:20PM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 11, 2021 at 06:33:44PM +0300, Roman Kagan wrote:
> > Error propagation between the generic vhost code and the specific backends
> > is
> > not quite consistent: some places follow "return -1 and set errno"
> > conve
On 11/27/21 02:14, David Gibson wrote:
On Fri, Nov 26, 2021 at 06:51:38PM +0100, Cédric le Goater wrote:
On 11/26/21 02:11, David Gibson wrote:
On Thu, Nov 25, 2021 at 07:42:02PM -0300, Daniel Henrique Barboza wrote:
If one tries to use -machine powernv9,accel=kvm in a Power9 host, a
crypti
On Mon, 29 Nov 2021 at 20:05, Peter Maydell wrote:
>
> qemu-common.h has a comment at the top:
>
> * This file is supposed to be included only by .c files. No header file
> should
> * depend on qemu-common.h, as this would easily lead to circular header
> * dependencies.
As a side note, that
softmmu/rtc.c defines two public functions: qemu_get_timedate() and
qemu_timedate_diff(). Currently we keep the prototypes for these in
qemu-common.h, but most files don't need them. Move them to their
own header, a new include/sysemu/rtc.h.
Since the C files using these two functions did not ne
The following changes since commit a0fd8a5492240379a07c0b39c8dae3b8341b458f:
Merge tag 'pull-for-6.2-291121-1' of https://github.com/stsquad/qemu into
staging (2021-11-29 18:58:06 +0100)
are available in the Git repository at:
https://github.com/legoater/qemu/ tags/pull-ppc-202
From: Leandro Lupori
When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte
offset, causing the first byte of the adjacent PTE to be corrupted.
This caused a panic when booting FreeBSD, using the Hash MMU.
Fixes: a2dd4e83e76b ("ppc/hash64: Rework R and C bit updates")
Signed-off
29.11.2021 22:16, Eric Blake wrote:
On Wed, Nov 24, 2021 at 03:09:51PM +0100, Vladimir Sementsov-Ogievskiy wrote:
Reconnect feature was never prepared to handle server options changed
on reconnect. Let's be stricter and check what exactly is changed. If
server capabilities just got richer don't
29.11.2021 20:34, Eric Blake wrote:
On Wed, Nov 24, 2021 at 03:09:51PM +0100, Vladimir Sementsov-Ogievskiy wrote:
Reconnect feature was never prepared to handle server options changed
on reconnect. Let's be stricter and check what exactly is changed. If
server capabilities just got richer don't
On Mon, 2021-11-29 at 20:55 +0100, Claudio Fontana wrote:
> On 11/29/21 8:19 PM, David Woodhouse wrote:
> > On Mon, 2021-11-29 at 20:10 +0100, Claudio Fontana wrote:
> > >
> > > Hmm I thought what you actually care for, for cpu "host", is just the
> > > kvm_enable_x2apic() call, not the kvm_defau
A lot of C files in hw/arm include qemu-common.h when they don't
need anything from it. Drop the include lines.
omap1.c, pxa2xx.c and strongarm.c retain the include because they
use it for the prototype of qemu_get_timedate().
Signed-off-by: Peter Maydell
---
hw/arm/boot.c | 1 -
hw/a
qemu-common.h has a comment at the top:
* This file is supposed to be included only by .c files. No header file should
* depend on qemu-common.h, as this would easily lead to circular header
* dependencies.
We still have a few .h files which include it, though. The first 3
patches in this ser
The qemu-common.h header is not supposed to be included from any
other header files, only from .c files (as documented in a comment at
the start of it).
Nothing actually relies on target/rx/cpu.h including it, so we can
just drop the include.
Signed-off-by: Peter Maydell
---
target/rx/cpu.h | 1
The qemu-common.h header is not supposed to be included from any
other header files, only from .c files (as documented in a comment at
the start of it).
include/hw/i386/x86.h and include/hw/i386/microvm.h break this rule.
In fact, the include is not required at all, so we can just drop it
from bot
The qemu-common.h header is not supposed to be included from any
other header files, only from .c files (as documented in a comment at
the start of it).
Move the include to linux-user/hexagon/cpu_loop.c, which needs it for
the declaration of cpu_exec_step_atomic().
Signed-off-by: Peter Maydell
-
Is there a generic event for observing VM state changes? I see we have a
lot of bespoke events like "STOP", "RESUME", "SHUTDOWN" and so forth, but I
can't quickly and at a glance determine if we have a 1:1 correlation for
every QAPI RunState to a QMP Event announcing that state.
I'm looking at e.g
* Markus Armbruster (arm...@redhat.com) wrote:
> Damien Hedde writes:
> > Patches 1, 3 and 5 miss a review.
> >
> > The series is organized as follow:
> >
> > + Patches 1 and 2 converts the MachinePhase enum to a qapi definition
> > and add the 'query-machine-phase'. It allows to introspect the
On 11/29/21 8:19 PM, David Woodhouse wrote:
> On Mon, 2021-11-29 at 20:10 +0100, Claudio Fontana wrote:
>>
>> Hmm I thought what you actually care for, for cpu "host", is just the
>> kvm_enable_x2apic() call, not the kvm_default_props.
>>
>>
>>
>> Do you also expect the kvm_default_prop "kvm-msi-e
On 11/29/21 6:14 PM, Alex Bennée wrote:
The following changes since commit e750c10167fa8ad3fcc98236a474c46e52e7c18c:
Merge tag 'pull-target-arm-20211129' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging (2021-11-29
11:56:07 +0100)
are available in the Git rep
On Mon, 2021-11-29 at 20:10 +0100, Claudio Fontana wrote:
>
> Hmm I thought what you actually care for, for cpu "host", is just the
> kvm_enable_x2apic() call, not the kvm_default_props.
>
>
>
> Do you also expect the kvm_default_prop "kvm-msi-ext-dest-id" to be switch to
> "on" and applied?
On Wed, Nov 24, 2021 at 03:09:51PM +0100, Vladimir Sementsov-Ogievskiy wrote:
> Reconnect feature was never prepared to handle server options changed
> on reconnect. Let's be stricter and check what exactly is changed. If
> server capabilities just got richer don't worry. Otherwise fail and
> drop
On Sat, Nov 27, 2021 at 08:29:09AM +0100, Eric Auger wrote:
> in old times the domain range was defined by a domain_bits le32.
> This was then converted into a domain_range struct. During the
> upgrade the original value of '32' (bits) has been kept while
> the end field now is the max value of the
On Sat, Nov 27, 2021 at 08:29:08AM +0100, Eric Auger wrote:
> Endianess is not properly handled when populating
> the returned config. Use the cpu_to_le* primitives
> for each separate field. Also, while at it, trace
> the domain range start.
>
> Signed-off-by: Eric Auger
> Reported-by: Thomas Hu
On 11/29/21 6:17 PM, David Woodhouse wrote:
> On Mon, 2021-11-29 at 17:57 +0100, Claudio Fontana wrote:
>> On 11/29/21 4:11 PM, David Woodhouse wrote:
>>> On Mon, 2021-11-29 at 15:14 +0100, Claudio Fontana wrote:
On 11/29/21 12:39 PM, Woodhouse, David wrote:
> On Fri, 2021-07-23 at 13:29 +
On Sat, Nov 27, 2021 at 08:29:07AM +0100, Eric Auger wrote:
> The spec says "the driver must not write to device configuration
> fields". So remove the set_config() callback which anyway did
> not do anything.
>
> Signed-off-by: Eric Auger
Removing this makes sense. For bypass, I'll add the func
When updating the R bit of a PTE, the Hash64 MMU was using a wrong byte
offset, causing the first byte of the adjacent PTE to be corrupted.
This caused a panic when booting FreeBSD, using the Hash MMU.
Fixes: a2dd4e83e76b ("ppc/hash64: Rework R and C bit updates")
Signed-off-by: Leandro Lupori
--
Ben Widawsky writes:
> On 21-11-26 12:08:08, Alex Bennée wrote:
>>
>> Ben Widawsky writes:
>>
>> > On 21-11-19 02:29:51, Shreyas Shah wrote:
>> >> Hi Ben
>> >>
>> >> Are you planning to add the CXL2.0 switch inside QEMU or already added in
>> >> one of the version?
>> >>
>> >
>> > From
* Juan Quintela (quint...@redhat.com) wrote:
> Until now, we wrote the packet header with write(), and the rest of the
> pages with writev(). Just increase the size of the iovec and do a
> single writev().
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration
"Dr. David Alan Gilbert" wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
>> Signed-off-by: Juan Quintela
>> ---
>> migration/multifd-zlib.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/migration/multifd-zlib.c b/migration/multifd-zlib.c
>> index da62
* Juan Quintela (quint...@redhat.com) wrote:
> Everything use now iov's.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/multifd.h | 2 --
> migration/multifd-zlib.c | 17 -
> migration/multifd-zstd.c | 17 -
> migra
* Juan Quintela (quint...@redhat.com) wrote:
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/multifd-zstd.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/migration/multifd-zstd.c b/migration/multifd-zstd.c
> index 2d5b611
On 11/29/21 3:04 PM, Laurent Vivier wrote:
The following changes since commit e750c10167fa8ad3fcc98236a474c46e52e7c18c:
Merge tag 'pull-target-arm-20211129' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging (2021-11-29
11:56:07 +0100)
are available in the Git rep
* Juan Quintela (quint...@redhat.com) wrote:
> Signed-off-by: Juan Quintela
> ---
> migration/multifd-zlib.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/migration/multifd-zlib.c b/migration/multifd-zlib.c
> index da6201704c..478a4af115 100644
> --- a/migratio
* Juan Quintela (quint...@redhat.com) wrote:
> This will allow us to reduce the number of system calls on the next patch.
>
> Signed-off-by: Juan Quintela
Leo: Does this make your zerocopy any harder?
Dave
> ---
> migration/multifd.h | 8 ++--
> migration/multifd.c | 34 +
On Wed, Nov 24, 2021 at 03:09:51PM +0100, Vladimir Sementsov-Ogievskiy wrote:
> Reconnect feature was never prepared to handle server options changed
> on reconnect. Let's be stricter and check what exactly is changed. If
> server capabilities just got richer don't worry. Otherwise fail and
> drop
On Tue, 9 Nov 2021 at 18:04, Shitalkumar Gandhi wrote:
>
> Hi SME's,
>
> Please see the attached patch, which has been added to the boot eMMC image
> for AST2600 machine on QEMU.
>
> qemu should be run as follows:
>
> ./qemu-system-arm -m 1G -M ast2600-evb -nographic -drive
> file=mmc-evb-ast2600
On Wed, 24 Nov 2021 at 10:16, Francisco Iglesias
wrote:
>
> Add an interface for controlling DMA models that are reused with other
> models. This allows a controlling model to start transfers through the
> DMA while reusing the DMA's handling of transfer state and completion
> signaling.
>
> Signe
Hello,
On 11/29/21 18:20, Peter Maydell wrote:
On Tue, 9 Nov 2021 at 18:04, Shitalkumar Gandhi wrote:
Hi SME's,
Please see the attached patch, which has been added to the boot eMMC image for
AST2600 machine on QEMU.
qemu should be run as follows:
./qemu-system-arm -m 1G -M ast2600-evb -no
On Wed, 24 Nov 2021 at 10:16, Francisco Iglesias
wrote:
>
> Connect Versal's PMC SLCR (system-level control registers) model.
>
> Signed-off-by: Francisco Iglesias
> Reviewed-by: Edgar E. Iglesias
> ---
> hw/arm/xlnx-versal.c | 18 ++
> include/hw/arm/xlnx-versal.h | 6
On Wed, 24 Nov 2021 at 10:16, Francisco Iglesias
wrote:
>
> Add in the missing includes in the header for being able to build the DMA
> model when reusing it.
>
> Signed-off-by: Francisco Iglesias
> ---
> include/hw/dma/xlnx_csu_dma.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a
* Juan Quintela (quint...@redhat.com) wrote:
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/multifd-zlib.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/migration/multifd-zlib.c b/migration/multifd-zlib.c
> ind
On 21-11-26 12:08:08, Alex Bennée wrote:
>
> Ben Widawsky writes:
>
> > On 21-11-19 02:29:51, Shreyas Shah wrote:
> >> Hi Ben
> >>
> >> Are you planning to add the CXL2.0 switch inside QEMU or already added in
> >> one of the version?
> >>
> >
> > From me, there are no plans for QEMU anythi
Am 22.11.21 um 12:29 schrieb Marc Hartmayer:
In the past s390 used a fixed command line length of 896 bytes. This has changed
with the Linux commit 5ecb2da660ab ("s390: support command lines longer than 896
bytes"). There is now a parm area indicating the maximum command line size. This
parm a
On Mon, 2021-11-29 at 17:57 +0100, Claudio Fontana wrote:
> On 11/29/21 4:11 PM, David Woodhouse wrote:
> > On Mon, 2021-11-29 at 15:14 +0100, Claudio Fontana wrote:
> > > On 11/29/21 12:39 PM, Woodhouse, David wrote:
> > > > On Fri, 2021-07-23 at 13:29 +0200, Claudio Fontana wrote:
> > > > > stat
* Juan Quintela (quint...@redhat.com) wrote:
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/multifd-zstd.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/migration/multifd-zstd.c b/migration/multifd-zstd.c
From: Juro Bystricky
Fix compiler warnings. The warnings can result in a broken build.
This patch fixes warnings such as:
In file included from /usr/include/glib-2.0/glib.h:111,
from ../tests/plugin/syscall.c:13:
../tests/plugin/syscall.c: In function ‘print_entry’:
/usr/include
When we set cpu->cflags_next_tb it is because we want to carefully
control the execution of the next TB. Currently there is a race that
causes the second stage of watchpoint handling to get ignored if an
IRQ is processed before we finish executing the instruction that
triggers the watchpoint. Use t
Signed-off-by: Alex Bennée
Tested-by: Stefan Weil
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/712
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20211129140932.4115115-5-alex.ben...@linaro.org>
diff --git a/plugins/meson.build b/plugins/meson.build
index aeb386ebae..b3de57853b 100644
From: Philippe Mathieu-Daudé
Add a MAINTAINERS section to cover the GitLab YAML config file
containing the jobs run on the custom runner sponsored by the
Works On Arm project [*].
[*] https://developer.arm.com/solutions/infrastructure/works-on-arm
Suggested-by: Thomas Huth
Signed-off-by: Phili
When we cleaned up argument handling the test was missed.
Fixes: 5ae589faad ("tests/plugins/mem: introduce "track" arg and make args not
positional")
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20211129140932.4115115-4-alex.ben...@
The following changes since commit e750c10167fa8ad3fcc98236a474c46e52e7c18c:
Merge tag 'pull-target-arm-20211129' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging (2021-11-29
11:56:07 +0100)
are available in the Git repository at:
https://github.com/stsquad/qem
From: Willian Rampazzo
Remove me as a reviewer for the Build and test automation and the
Integration Testing with the Avocado Framework and add Beraldo
Leal.
Signed-off-by: Willian Rampazzo
Reviewed-by: Beraldo Leal
Message-Id: <20211122191124.31620-1-willi...@redhat.com>
Signed-off-by: Alex B
When dealing with multi-threaded userspace programs there is a race
condition with the addition of cpu->opaque (aka TaskState). This is
due to cpu_copy calling cpu_create which updates the global vCPU list.
However the task state isn't set until later. This shouldn't be a
problem because the new th
Here we introduce a new compiler flag to disable the checking of exit
request (icount_decr.u32). This is useful when we want to ensure the
next block cannot be preempted by an asynchronous event.
Suggested-by: Richard Henderson
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Message-I
On 11/29/21 5:57 PM, Claudio Fontana wrote:
> On 11/29/21 4:11 PM, David Woodhouse wrote:
>> On Mon, 2021-11-29 at 15:14 +0100, Claudio Fontana wrote:
>>> On 11/29/21 12:39 PM, Woodhouse, David wrote:
On Fri, 2021-07-23 at 13:29 +0200, Claudio Fontana wrote:
> static void kvm_cpu_instance
On 11/29/21 4:11 PM, David Woodhouse wrote:
> On Mon, 2021-11-29 at 15:14 +0100, Claudio Fontana wrote:
>> On 11/29/21 12:39 PM, Woodhouse, David wrote:
>>> On Fri, 2021-07-23 at 13:29 +0200, Claudio Fontana wrote:
static void kvm_cpu_instance_init(CPUState *cs)
{
X86CPU *cpu
On 11/29/21 5:40 PM, Peter Maydell wrote:
+lw a2, 16(sp)
+lw a3, 20(sp)
+lw t4, 24(sp)
+lw t5, 28(sp)
+lw t6, 32(sp)
+lw t7, 40(sp)
+sw t4, 16(sp)
+sw t5, 20(sp)
+sw t6, 24(sp)
+
On 11/29/21 2:51 PM, Michael S. Tsirkin wrote:
The following changes since commit dd4b0de45965538f19bb40c7ddaaba384a8c613a:
Fix version for v6.2.0-rc2 release (2021-11-26 11:58:54 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_u
On Tue, 23 Nov 2021 at 17:44, Richard Henderson
wrote:
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/host/mips/hostdep.h | 3 +
> linux-user/host/mips/safe-syscall.inc.S | 123
> 2 files changed, 126 insertions(+)
> create mode 100644 linux-user/hos
If I understand correctly (I'm not a QEmu internals expert), yes this is
what happens.
Maybe stm32f2xx_usart_can_receive() is also called but since the
USART_SR_RXNE flag is reset before the USART_DR is read, it does not
prevent reading the next character.
Best regards,
Olivier Hériveaux
Le lun.
The ehabk...@redhat.com email address will stop working on
2021-12-01, change it to my personal email address.
Signed-off-by: Eduardo Habkost
---
Note: I will probably step down as maintainer of some areas, but
I will do this later because I will need a few weeks to figure
out how much time I wil
From: Hyman Huang(黄勇)
The patch [2/3] has not been touched so far. Any corrections and
suggetions are welcome.
Please review, thanks!
v7:
- rebase on master
- polish the comments and error message according to the
advices given by Markus
- introduce dirtylimit_enabled function to pre-check i
From: Hyman Huang(黄勇)
Impose dirty restraint on vCPU by kicking it and sleep
as the auto-converge does during migration, but just
kick the specified vCPU instead, not all vCPUs of vm.
Start a thread to track the dirtylimit status and adjust
the throttle pencentage dynamically depend on current
a
From: Hyman Huang(黄勇)
Introduce the third method GLOBAL_DIRTY_LIMIT of dirty
tracking for calculate dirtyrate periodly for dirty restraint.
Implement thread for calculate dirtyrate periodly, which will
be used for dirty restraint.
Add dirtylimit.h to introduce the util function for dirty
limit
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Mon, Nov 29, 2021 at 11:20:08AM +, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
> > > > When doing live migration with multifd channels 8
On 11/29/21 3:50 PM, Dr. David Alan Gilbert wrote:
* Li Zhang (lizh...@suse.de) wrote:
On 11/29/21 12:20 PM, Dr. David Alan Gilbert wrote:
* Daniel P. Berrangé (berra...@redhat.com) wrote:
On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
When doing live migration with multifd chann
Cédric Le Goater writes:
>>> Right. If we're doing this to say "I can boot a kernel with a 7450 cpu in
>>> QEMU" but
>>> the implementation is different from real hardware, then I'm not sure what
>>> the real
>>> value is. That effectively leaves option b) if someone is willing to do the
>>> w
On Mon, 2021-11-29 at 15:14 +0100, Claudio Fontana wrote:
> On 11/29/21 12:39 PM, Woodhouse, David wrote:
> > On Fri, 2021-07-23 at 13:29 +0200, Claudio Fontana wrote:
> > > static void kvm_cpu_instance_init(CPUState *cs)
> > > {
> > > X86CPU *cpu = X86_CPU(cs);
> > > +X86CPUClass *xcc =
On Mon, Nov 29, 2021 at 11:20:08AM +, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
> > > When doing live migration with multifd channels 8, 16 or larger number,
> > > the guest hangs in the presen
On Mon, Nov 29, 2021 at 2:43 PM Michael S. Tsirkin wrote:
>
> On Fri, Nov 26, 2021 at 10:54:32AM +0800, Jason Wang wrote:
> > On Thu, Nov 25, 2021 at 6:16 PM Eugenio Pérez wrote:
> > >
> > > The message has never been true in the case of non tap networking, so
> > > only tell that userland networ
fpunchhole_t was introduced in the macOS 10.12.4 SDK. For reference, see:
https://developer.apple.com/documentation/kernel/fpunchhole_t
Test the SDK version before attempting any fpunchhole_t-related logic.
Signed-off-by: Evan Miller
--- block/file-posix.c.orig
+++ block/file-posix.c
@@ -1830
* Li Zhang (lizh...@suse.de) wrote:
>
> On 11/29/21 12:20 PM, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Fri, Nov 26, 2021 at 04:31:53PM +0100, Li Zhang wrote:
> > > > When doing live migration with multifd channels 8, 16 or larger number,
> > > >
On 11/29/21 8:29 AM, Brijesh Singh wrote:
On 11/25/21 7:59 AM, Dov Murik wrote:
[+cc Tom, Brijesh]
On 25/11/2021 15:42, Daniel P. Berrangé wrote:
On Thu, Nov 25, 2021 at 02:44:51PM +0200, Dov Murik wrote:
[+cc jejb, tobin, jim, hubertus]
On 25/11/2021 9:14, Sergio Lopez wrote:
On Wed,
On 11/25/21 7:59 AM, Dov Murik wrote:
[+cc Tom, Brijesh]
On 25/11/2021 15:42, Daniel P. Berrangé wrote:
On Thu, Nov 25, 2021 at 02:44:51PM +0200, Dov Murik wrote:
[+cc jejb, tobin, jim, hubertus]
On 25/11/2021 9:14, Sergio Lopez wrote:
On Wed, Nov 24, 2021 at 06:29:07PM +, Dr. David
On 11/22/21 12:16, Richard Henderson wrote:
On 11/22/21 10:43 AM, Richard Henderson wrote:
On 11/21/21 6:47 PM, Cédric Le Goater wrote:
I am getting an error with this test. See below.
...
### Rounding to nearest
from single: f32(-nan:0xffa0)
- to double: f64(-nan:0x00fff4000
Le 29/11/2021 à 14:51, mwi...@suse.com a écrit :
From: Martin Wilck
qemu-binfmt-conf.sh should use "-F" as short option for "--qemu-suffix".
Fix the getopt call to make this work.
Signed-off-by: Martin Wilck
---
previous: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg03132.html
S
On 26/11/2021 10:09, Cédric Le Goater wrote:
On 11/16/21 18:01, Frederic Barrat wrote:
The PHB v4 found on POWER9 doesn't request any LSI, so let's clear the
Interrupt Pin register in the config space so that the model matches
the hardware.
If we don't, then we inherit from the default pcie
On 11/29/21 3:09 PM, Alex Bennée wrote:
When we set cpu->cflags_next_tb it is because we want to carefully
control the execution of the next TB. Currently there is a race that
causes the second stage of watchpoint handling to get ignored if an
IRQ is processed before we finish executing the instr
On 11/29/21 12:01 PM, Peter Maydell wrote:
On Tue, 23 Nov 2021 at 17:40, Richard Henderson
wrote:
We don't need a register that can live across the syscall;
we only need a register that can live until the syscall.
What about the case where:
* we execute the sc instruction (r11 trashed)
*
On 11/29/21 3:09 PM, Alex Bennée wrote:
From: Juro Bystricky
Fix compiler warnings. The warnings can result in a broken build.
This patch fixes warnings such as:
In file included from /usr/include/glib-2.0/glib.h:111,
from ../tests/plugin/syscall.c:13:
../tests/plugin/syscall
On 29/11/2021 11:07, Richard Henderson wrote:
On 11/28/21 2:57 PM, Frédéric Pétrot wrote:
--- /dev/null
+++ b/util/int128.c
@@ -0,0 +1,145 @@
+#include "qemu/osdep.h"
+#include "qemu/host-utils.h"
+#include "qemu/int128.h"
Missing file header and copyright boilerplate.
+#ifdef CONFIG_INT128
On 11/29/21 3:27 PM, Frédéric Pétrot wrote:
On 29/11/2021 11:07, Richard Henderson wrote:
On 11/28/21 2:57 PM, Frédéric Pétrot wrote:
--- /dev/null
+++ b/util/int128.c
@@ -0,0 +1,145 @@
+#include "qemu/osdep.h"
+#include "qemu/host-utils.h"
+#include "qemu/int128.h"
Missing file header and co
From: Juro Bystricky
Fix compiler warnings. The warnings can result in a broken build.
This patch fixes warnings such as:
In file included from /usr/include/glib-2.0/glib.h:111,
from ../tests/plugin/syscall.c:13:
../tests/plugin/syscall.c: In function ‘print_entry’:
/usr/include
When we set cpu->cflags_next_tb it is because we want to carefully
control the execution of the next TB. Currently there is a race that
causes the second stage of watchpoint handling to get ignored if an
IRQ is processed before we finish executing the instruction that
triggers the watchpoint. Use t
From: Willian Rampazzo
Remove me as a reviewer for the Build and test automation and the
Integration Testing with the Avocado Framework and add Beraldo
Leal.
Signed-off-by: Willian Rampazzo
Reviewed-by: Beraldo Leal
Message-Id: <20211122191124.31620-1-willi...@redhat.com>
Signed-off-by: Alex B
When we cleaned up argument handling the test was missed.
Fixes: 5ae589faad ("tests/plugins/mem: introduce "track" arg and make args not
positional")
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20211123205729.2205806-4-alex.ben...@
On Fri, 2021-07-23 at 13:29 +0200, Claudio Fontana wrote:
> static void kvm_cpu_instance_init(CPUState *cs)
> {
> X86CPU *cpu = X86_CPU(cs);
> +X86CPUClass *xcc = X86_CPU_GET_CLASS(cpu);
>
> host_cpu_instance_init(cpu);
>
> -if (!kvm_irqchip_in_kernel()) {
> -x86_cpu
1 - 100 of 159 matches
Mail list logo
