Am 19.02.20 um 16:50 schrieb Justin Terry (SF):
> Ha yes. LGTM Thanks!
>
> Reviewed-by: Justin Terry (VM)
>
>> -Original Message-
>> From: Philippe Mathieu-Daudé
>> Sent: Wednesday, February 19, 2020 12:32 AM
>> To: Justin Terry (SF) ; Sunil Muthuswamy
>> ; Eduardo Habkost ;
>> Paolo Bon
Priority bits implemented in arm-gic can be 8 to 4, un-implemented bits
are read as zeros(RAZ).
Signed-off-by: Sai Pavan Boddu
---
hw/intc/arm_gic.c| 26 --
hw/intc/arm_gic_common.c | 1 +
include/hw/intc/arm_gic_common.h | 1 +
3 files changed,
ARM11MPCore GIC is implemented with 4 priority bits.
Signed-off-by: Sai Pavan Boddu
Suggested-by: Peter Maydell
---
hw/cpu/arm11mpcore.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/cpu/arm11mpcore.c b/hw/cpu/arm11mpcore.c
index 2e3e87c..ab9fadb 100644
--- a/hw/cpu/arm11mpcore.c
All A9 CPUs have a GIC with 5 bits of priority.
Signed-off-by: Sai Pavan Boddu
Suggested-by: Peter Maydell
---
hw/cpu/a9mpcore.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/cpu/a9mpcore.c b/hw/cpu/a9mpcore.c
index 1f8bc8a..b4f6a7e 100644
--- a/hw/cpu/a9mpcore.c
+++ b/hw/cpu/a9mpc
Vladimir Sementsov-Ogievskiy writes:
> Add functions to clean Error **errp: call corresponding Error *err
> cleaning function an set pointer to NULL.
>
> New functions:
> error_free_errp
> error_report_errp
> warn_report_errp
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> Reviewed-by: G
I just called _configure_loopback_interface in a qemu-aarch64 chroot,
and the error is not reproducible with qemu-4.2.0. Has it been fixed?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1857811
Title
All code in fuse.h and struct fuse_module are not used by virtiofsd
so removing them is safe.
Signed-off-by: Xiao Yang
---
tools/virtiofsd/fuse.h | 1229 --
tools/virtiofsd/fuse_i.h | 16 -
2 files changed, 1245 deletions(-)
delete mode 100644 tools/virti
The Linux libATA API documentation mentions that on some hardware,
reading the status register has the side effect of clearing the
interrupt condition. When emulating the generic Sun4u machine running
Solaris 10, the Solaris 10 CMD646 driver exits fatally because of this
emulated side effect. This
> -Original Message-
> From: Peter Xu [mailto:pet...@redhat.com]
> Sent: Friday, February 21, 2020 2:17 AM
> To: Ben Gardon
> Cc: Zhoujian (jay) ; Junaid Shahid
> ; k...@vger.kernel.org; qemu-devel@nongnu.org;
> pbonz...@redhat.com; dgilb...@redhat.com; quint...@redhat.com;
> Liujinsong
From: miaoyubo
Currently virt machine is not supported by pxb-pcie,
and only one main host bridge described in ACPI tables.
In this patch,PXB-PCIE is supproted by arm and certain
resource is allocated for each pxb-pcie in acpi table.
The resource for the main host bridge is also reallocated.
Sig
From: miaoyubo
Currently pxb-pcie is not supported by arm, the reason for it is
pxb-pcie is not described in DSDT table and only one main host bridge
is described in acpi tables, which means it is not impossible to
present different io numas for different devices, especially
host-passthrough devi
From: miaoyubo
Currently, pxb-pcie could be defined by the cmdline like
--device pxb-pcie,id=pci.9,bus_nr=128
However pxb-pcie is not described in acpi tables for arm.
The formal two patches support pxb-pcie for arm, escpcially the
specification for pxb-pcie in DSDT table.
Add a testcase to
From: miaoyubo
Extract two APIs acpi_dsdt_add_pci_route_table and
acpi_dsdt_add_pci_osc form acpi_dsdt_add_pci. The first
API is used to specify the pci route table and the second
API is used to declare the operation system capabilities.
These two APIs would be used to specify the pxb-pcie in DSD
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
[...]
>> Collecting several users before building infrastructure makes sense when
>> the design of the infrastructure isn't obvious, or when the need for it
>> is in doubt.
>>
>> Neither is the case for running QMP
Patchew URL: https://patchew.org/QEMU/20200221044908.266883-1-gs...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#
On Fri, Feb 21, 2020 at 8:08 AM Bin Meng wrote:
>
> Hi Philippe,
>
> On Fri, Feb 21, 2020 at 1:31 AM Philippe Mathieu-Daudé
> wrote:
> >
> > Hi Bin,
> >
> > On 2/20/20 3:42 PM, Bin Meng wrote:
> > > Although the real world SiFive HiFive Unleashed board is a 64-bit
> > > hardware configuration, wi
The depth of TxFIFO can be 1 or 16 depending on LCR[4]. The TxFIFO is
disabled when its depth is 1. It's nice to have TxFIFO enabled if
possible because more characters can be piled and transmitted at once,
which would have less overhead. Besides, we can be blocked because of
qemu_chr_fe_write_all(
Hi Peter and Marc,
On 2/20/20 9:10 PM, Peter Maydell wrote:
On Thu, 20 Feb 2020 at 09:10, Marc Zyngier wrote:
On 2020-02-20 06:01, Gavin Shan wrote:
This fixes the issue by using newly added API
qemu_chr_fe_try_write_all(),
which provides another type of service (best-effort). It's different
On 18/02/2020 16:48, Philippe Mathieu-Daudé wrote:
> On 2/17/20 11:46 PM, David Gibson wrote:
>> On Mon, Feb 17, 2020 at 11:24:11AM +0100, Philippe Mathieu-Daudé wrote:
>>> On 2/17/20 10:26 AM, Philippe Mathieu-Daudé wrote:
Hi Alexey,
On 2/17/20 3:12 AM, Alexey Kardashevskiy wrote
On Thu, Feb 20, 2020 at 5:53 AM Zhoujian (jay) wrote:
>
>
>
> > -Original Message-
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Thursday, February 20, 2020 1:19 AM
> > To: Zhoujian (jay)
> > Cc: k...@vger.kernel.org; qemu-devel@nongnu.org; pbonz...@redhat.com;
> > dgilb...@redh
FWIW, we currently do this eager splitting at Google for live
migration. When the log-dirty-memory flag is set on a memslot we
eagerly split all pages in the slot down to 4k granularity.
As Jay said, this does not cause crippling lock contention because the
vCPU page faults generated by write prote
Uff. Forgot to add that his replaces the update tagged as
qemu-slof-20200217, the difference from that is this fixes handling of
64bit ext4 and removes
"disk-label: Try ext2 filesystem when booting from GPT partition"
as it did not help with what I wanted to achieve (zImage loading into
slof from
The following changes since commit 438bafcac55308eef4f9029c94dbadd2c7ac3bb7:
hw/ppc/virtex_ml507:fix leak of fdevice tree blob (2020-02-21 09:15:04 +1100)
are available in the Git repository at:
g...@github.com:aik/qemu.git tags/qemu-slof-20200221
for you to fetch changes up to fcd350cb4646
From: Chen Gang
The fxam instruction also checks the register stack overflow, which can
be get by the following fstsw instruction. The related code is below, it
works well under real x86_64 hardware, but can not work under qemu-i386.
0006b63c <_CIsqrt>:
6b63c: 55 pu
On 2/21/2020 1:56 AM, Peter Maydell wrote:
> On Mon, 17 Feb 2020 at 03:22, wrote:
>>
>> From: Pan Nengyuan
>>
>> There are some memleaks when we call 'device_list_properties'. This patch
>> move timer_new from init into realize to fix it.
>> Meanwhile, do the null check in mos6522_reset() to
From: Pan Nengyuan
'fdt' forgot to clean both e500 and pnv when we call 'system_reset' on ppc,
this patch fix it. The leak stacks are as follow:
Direct leak of 4194304 byte(s) in 4 object(s) allocated from:
#0 0x7fafe37dd970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970)
#1 0x7faf
From: Greg Kurz
We already detect if a device is being hot plugged before CAS to trigger
a CAS reboot and during migration to migrate the state of the associated
DRC. But hot unplugging a device is also an asynchronous operation that
requires the guest to take action. This means that if the guest
From: BALATON Zoltan
Move fp_status and fpscr closer to other floating point and vector
related members in cpu env definition so they are in one group.
Signed-off-by: BALATON Zoltan
Message-Id:
<5b50e9e7eec2c383ae878b397d0b2927efc9ea43.158134.git.bala...@eik.bme.hu>
Signed-off-by: David Gi
From: Chen Qun
The device tree blob returned by load_device_tree is malloced.
We should free it after cpu_physical_memory_write().
Reported-by: Euler Robot
Signed-off-by: Chen Qun
Message-Id: <20200218091154.21696-3-kuhn.chen...@huawei.com>
Signed-off-by: David Gibson
---
hw/ppc/virtex_ml507
From: Greg Kurz
We currently don't support hotplug of devices between boot and CAS. If
this happens a CAS reboot is triggered. We detect this during CAS using
the spapr_drc_needed() function which is essentially a VMStateDescription
.needed callback. Even if the condition for CAS reboot happens t
From: Greg Kurz
As reported by Coverity defect CID 1419397, the 'j' variable goes up to
63 and shouldn't be used to left shift a 32-bit integer.
The result of the operation goes to a 64-bit integer : use a 64-bit
constant.
Reported-by: Coverity CID 1419397 Bad bit shift operation
Fixes: 9ae1329
From: BALATON Zoltan
The cpu env struct is quite complex but comments supposed to explain
it in its definition just make it harder to read. Reformat and reword
some comments to make it clearer and more readable.
Signed-off-by: BALATON Zoltan
Message-Id:
<8707144ab1ccf9c5c89a39c2d7a0b02307ca25d
From: Alexey Kardashevskiy
This allows moving the kernel in the guest memory. The option is useful
for step debugging (as Linux is linked at 0x0); it also allows loading
grub which is normally linked to run at 0x2.
This uses the existing kernel address by default.
Signed-off-by: Alexey Kard
From: Greg Kurz
We obviously don't want to print out an error message if addr points to
a valid register.
Reported-by: Coverity CID 1419391 Missing break in switch
Fixes: 9ae1329ee2fe "ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge"
Signed-off-by: Greg Kurz
Message-Id: <158153365202.32290
From: Greg Kurz
Obviously, we want to pass &local_err so that we can check it then
line below, not errp.
Reported-by: Coverity CID 1419395 'Constant' variable guards dead code
Fixes: 4f9924c4d4cf "ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge"
Signed-off-by: Greg Kurz
Message-Id: <158153
The following changes since commit 7afee874f1b27abc998b8b747d16b77cb6398716:
Merge remote-tracking branch
'remotes/vivier2/tags/trivial-branch-pull-request' into staging (2020-02-20
16:51:19 +)
are available in the Git repository at:
git://github.com/dgibson/qemu.git tags/ppc-for-5.0-2
From: BALATON Zoltan
"Deferred" was misspelled as "differed" in some comments, correct this
typo,
Signed-off-by: BALATON Zoltan
Message-Id: <20200214155748.0896b745...@zero.eik.bme.hu>
Signed-off-by: David Gibson
---
target/ppc/fpu_helper.c| 4 ++--
target/ppc/translate/fp-impl.in
From: BALATON Zoltan
Commit 74433bf083b added some includes but added them twice. Since
these are guarded against multiple inclusion including them once is
enough.
Signed-off-by: BALATON Zoltan
Message-Id: <20200212223207.5a375746...@zero.eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé
Signed-
From: Shivaprasad G Bhat
For ppc64, PAPR requires the nvdimm device to have UUID property
set in the device tree. Add an option to get it from the user.
Signed-off-by: Shivaprasad G Bhat
Reviewed-by: David Gibson
Reviewed-by: Igor Mammedov
Message-Id:
<158131056931.2897.14057087440721445976.
From: Shivaprasad G Bhat
Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm
device interface in QEMU to support virtual NVDIMM devices for Power.
Create the required DT entries for the device (some entries have
dummy values right now).
The patch creates the required DT node a
From: Laurent Vivier
When PHB4 bridge has been added, the dependencies to PCIE_PORT has been
added to XIVE_SPAPR and indirectly to PSERIES.
The build of the PowerNV machine is fine while we also build the PSERIES
machine.
If we disable the PSERIES machine, the PowerNV build fails because the
PCI
From: Shivaprasad G Bhat
This patch implements few of the necessary hcalls for the nvdimm support.
PAPR semantics is such that each NVDIMM device is comprising of multiple
SCM(Storage Class Memory) blocks. The guest requests the hypervisor to
bind each of the SCM blocks of the NVDIMM device usin
From: Shivaprasad G Bhat
nvdimm_device_list is required for parsing the list for devices
in subsequent patches. Move it to common utility area.
Signed-off-by: Shivaprasad G Bhat
Reviewed-by: Igor Mammedov
Reviewed-by: David Gibson
Message-Id:
<158131055857.2897.15658377276504711773.st...@lep
From: "Michael S. Tsirkin"
We are going to add more init for the latest machine, so move the setup
to a function so we don't have to change the DEFINE_SPAPR_MACHINE macro
each time.
Signed-off-by: Michael S. Tsirkin
Message-Id: <20200207064628.1196095-1-...@redhat.com>
Reviewed-by: Laurent Vivi
From: Alexey Kardashevskiy
The "ibm,os-term" RTAS call has a single parameter which is a pointer to
a message from the guest kernel about the termination cause; this prints
it.
Signed-off-by: Alexey Kardashevskiy
Message-Id: <20200203032044.118585-1-...@ozlabs.ru>
Reviewed-by: Daniel Henrique B
From: Laurent Vivier
qtest "rtas" command is only available with pseries not all ppc64 targets,
so if I try to compile only powernv machine, the build fails with:
/usr/bin/ld: qtest.o: in function `qtest_process_command':
.../qtest.c:645: undefined reference to `qtest_rtas_call'
We fix this
On Thu, Feb 20, 2020 at 02:05:47PM +0100, Philippe Mathieu-Daudé wrote:
> Use an explicit boolean type.
>
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/exec_rw_const.
>
> Signed-off-by: Philippe Mathieu-Daudé
ppc parts
Acked-by: David Gibson
> ---
> scr
Currently, if the bytes_dirty_period is more than the 50% of
bytes_xfer_period, we start or increase throttling.
If we make this percentage higher, then we can tolerate higher
dirty rate during migration, which means less impact on guest.
The side effect of higher percentage is longer migration ti
Hi Philippe,
On Fri, Feb 21, 2020 at 1:31 AM Philippe Mathieu-Daudé
wrote:
>
> Hi Bin,
>
> On 2/20/20 3:42 PM, Bin Meng wrote:
> > Although the real world SiFive HiFive Unleashed board is a 64-bit
> > hardware configuration, with QEMU it is possible to test 32-bit
> > configuration with the same
Recently when debugging an arm32 system on qemu, I found sometimes the
single-step command (stepi) is not working. This can be reproduced by
below steps:
1) start qemu-system-arm -s -S .. and wait for gdb connection.
2) start gdb and connect to qemu. In my case, gdb gets a wrong value
(0x60)
On 20/02/2020 21:01, Paolo Bonzini wrote:
> On 20/02/20 07:16, Alexey Kardashevskiy wrote:
>> This is another attempt to implement minimalistic
>> Open Firmware Client Interface in QEMU.
>>
>> With this thing, I can boot unmodified Ubuntu 18.04 and Fedora 30
>> directly from the disk without SLO
On Thu, Feb 20, 2020 at 06:47:26PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/20/20 4:58 PM, Changbin Du wrote:
> > Recently when debugging an arm32 system on qemu, I found sometimes the
> > single-step command (stepi) is not working. This can be reproduced by
> > below steps:
> > 1) start qemu-
On Thu, Feb 20, 2020 at 10:24:37PM +0100, Luc Michel wrote:
> Hi,
>
> On 2/20/20 4:58 PM, Changbin Du wrote:
> > Recently when debugging an arm32 system on qemu, I found sometimes the
> > single-step command (stepi) is not working. This can be reproduced by
> > below steps:
> > 1) start qemu-syst
Patchew URL:
https://patchew.org/QEMU/cover.1582240656.git.alistair.fran...@wdc.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v1 0/2] linux-user: generate syscall_nr.sh for RISC-V
Message-id: cover.1582240656.git.alistai
This seems to be due to the vfio-helper code assuming it can map an
arbitrarily large IOVA range starting at 64K base address. x86
processors typically have a reserved range near the top of the 32-bit
address space which is used for MSI support which is used by the
interrupt remapper where we cann
New y2038 safe 32-bit architectures (like RISC-V) don't support old
syscalls with a 32-bit time_t. The kernel defines new *_time64 versions
of these syscalls. Add some more #ifdefs to syscall.c in linux-user to
allow us to compile without these old syscalls.
Signed-off-by: Alistair Francis
---
l
Signed-off-by: Alistair Francis
---
linux-user/riscv/syscall_nr.h | 160 +-
1 file changed, 158 insertions(+), 2 deletions(-)
diff --git a/linux-user/riscv/syscall_nr.h b/linux-user/riscv/syscall_nr.h
index 5c87282209..b2b071969b 100644
--- a/linux-user/riscv/sysc
This series updates the RISC-V syscall_nr.sh based on the 5.5 kernel.
There are two parts to this. One is just adding the new syscalls, the
other part is updating the RV32 syscalls to match the fact that RV32 is
a 64-bit time_t architectures (y2038) safe.
we need to make some changes to syscall.c
Hi Peter,
On Thu, Feb 20, 2020 at 03:06:05PM +, Peter Maydell wrote:
> On Tue, 18 Feb 2020 at 20:10, Guenter Roeck wrote:
>
> I'll put this in via target-arm.next, since we don't really
> have a more active sh4-specific tree to send it via.
>
Thanks for picking up all my patches, and even
Hi,
On 2/20/20 4:58 PM, Changbin Du wrote:
> Recently when debugging an arm32 system on qemu, I found sometimes the
> single-step command (stepi) is not working. This can be reproduced by
> below steps:
> 1) start qemu-system-arm -s -S .. and wait for gdb connection.
> 2) start gdb and connect t
On Thu, 20 Feb 2020 at 18:52, Philippe Mathieu-Daudé wrote:
>
> On 2/20/20 6:56 PM, Peter Maydell wrote:
> > On Mon, 17 Feb 2020 at 03:22, wrote:
> >>
> >> From: Pan Nengyuan
> >>
> >> There are some memleaks when we call 'device_list_properties'. This patch
> >> move timer_new from init into r
On Thu, Feb 20, 2020 at 12:24:42PM +0100, David Hildenbrand wrote:
> On 19.02.20 17:17, David Hildenbrand wrote:
> > When we partially change mappings (e.g., mmap over parts of an existing
> > mmap) where we have a userfaultfd handler registered, the handler will
> > implicitly be unregistered from
On Wed, Feb 19, 2020 at 05:17:22PM +0100, David Hildenbrand wrote:
> Resizing while migrating is dangerous and does not work as expected.
> The whole migration code works on the usable_length of ram blocks and does
> not expect this to change at random points in time.
>
> In the case of postcopy,
On Thu, Feb 20, 2020 at 02:05:29PM +0100, Philippe Mathieu-Daudé wrote:
> When we use a Coccinelle semantic script to do automatic
> code modifications, it makes sense to look at the semantic
> patch first.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Michael S. Tsirkin
> ---
> scri
On Thursday, 2020-02-20 at 10:36:04 -06, Eric Blake wrote:
> On 2/20/20 10:06 AM, Max Reitz wrote:
>> From: David Edmondson
>>
>> In many cases the target of a convert operation is a newly provisioned
>> target that the user knows is blank (reads as zero). In this situation
>> there is no requir
On Thu, Feb 20, 2020 at 04:16:02PM +0100, David Hildenbrand wrote:
> On 19.02.20 17:17, David Hildenbrand wrote:
> > Resizing while migrating is dangerous and does not work as expected.
> > The whole migration code works on the usable_length of ram blocks and does
> > not expect this to change at r
On 2/18/20 9:10 AM, BALATON Zoltan wrote:
> void helper_reset_fpstatus(CPUPPCState *env)
> {
> -set_float_exception_flags(0, &env->fp_status);
> +set_float_exception_flags(env->default_fp_excpt_flags, &env->fp_status);
> }
What I don't like is the forced setting of inexact. I don't min
* Markus Armbruster (arm...@redhat.com) wrote:
> Cc: David for questions regarding the HMP core. David, please look for
> "Is HMP blocking the main loop a problem?"
>
> Marc-André Lureau writes:
>
> > Hi
> >
> > On Thu, Feb 20, 2020 at 8:49 AM Markus Armbruster wrote:
> >>
> >> Marc-André Lure
On Thu, Feb 20, 2020 at 01:49:40PM -0300, Wainer dos Santos Moschetta wrote:
> On 2/19/20 11:06 PM, Cleber Rosa wrote:
> > +
> > +def test_virt_tcg(self):
> > +"""
> > +:avocado: tags=accel:tcg
> > +:avocado: tags=cpu:cortex-a53
> > +"""
> > +if not tcg_a
* Daniel Cho (daniel...@qnap.com) wrote:
> Hi Hailiang,
>
> I have already patched the file to my branch, but there is a problem while
> doing migration.
> Here is the error message from SVM
> "qemu-system-x86_64: /root/download/qemu-4.1.0/memory.c:1079:
> memory_region_transaction_commit: Asserti
Hi Oksana,
On 2/14/20 12:52 PM, Oksana Vohchana wrote:
Provides param address in _get_free_port()
because by default it takes free port only on the localhost
Signed-off-by: Oksana Vohchana
---
tests/acceptance/migration.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
* David Hildenbrand (da...@redhat.com) wrote:
>
>
> > Am 19.02.2020 um 21:47 schrieb Peter Xu :
> >
> > On Wed, Feb 19, 2020 at 05:17:19PM +0100, David Hildenbrand wrote:
> >> It's always the same value.
> >
> > I guess not, because...
> >
> >>
> >> Cc: "Dr. David Alan Gilbert"
> >> Cc: Jua
On 2/20/20 6:56 PM, Peter Maydell wrote:
On Mon, 17 Feb 2020 at 03:22, wrote:
From: Pan Nengyuan
There are some memleaks when we call 'device_list_properties'. This patch move
timer_new from init into realize to fix it.
Meanwhile, do the null check in mos6522_reset() to avoid null deref if
On 2/20/20 7:06 PM, Laurent Vivier wrote:
Le 20/02/2020 à 18:47, Philippe Mathieu-Daudé a écrit :
On 2/20/20 4:58 PM, Changbin Du wrote:
Recently when debugging an arm32 system on qemu, I found sometimes the
single-step command (stepi) is not working. This can be reproduced by
below steps:
1
On Mon, Jan 20, 2020 at 9:43 PM Alistair Francis
wrote:
>
> As reported in: https://bugs.launchpad.net/qemu/+bug/1851939 we weren't
> correctly handling illegal instructions based on the value of MSTATUS_TSR
> and the current privledge level.
>
> This patch fixes the issue raised in the bug by rai
* Hailiang Zhang (zhang.zhanghaili...@huawei.com) wrote:
> This patch will reduce the downtime of VM for the initial process,
> Privously, we copied all these memory in preparing stage of COLO
> while we need to stop VM, which is a time-consuming process.
> Here we optimize it by a trick, back-up e
* Hailiang Zhang (zhang.zhanghaili...@huawei.com) wrote:
> Hi,
>
> This is an untested serial that tries to reduce VM's pause time
> while do checkpoint in COLO state.
>
> The second patch tries to reduce the total number of dirty pages
> while do checkpoint with VM been paused, instead of sendin
On Thu, Feb 20, 2020 at 09:34:52AM -0800, Ben Gardon wrote:
> On Thu, Feb 20, 2020 at 5:53 AM Zhoujian (jay)
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Peter Xu [mailto:pet...@redhat.com]
> > > Sent: Thursday, February 20, 2020 1:19 AM
> > > To: Zhoujian (jay)
> > > Cc: k.
Le 20/02/2020 à 18:47, Philippe Mathieu-Daudé a écrit :
> On 2/20/20 4:58 PM, Changbin Du wrote:
>> Recently when debugging an arm32 system on qemu, I found sometimes the
>> single-step command (stepi) is not working. This can be reproduced by
>> below steps:
>> 1) start qemu-system-arm -s -S ..
On Thu, 20 Feb 2020 at 15:59, Changbin Du wrote:
>
> Recently when debugging an arm32 system on qemu, I found sometimes the
> single-step command (stepi) is not working. This can be reproduced by
> below steps:
> 1) start qemu-system-arm -s -S .. and wait for gdb connection.
> 2) start gdb and c
On Mon, 17 Feb 2020 at 03:22, wrote:
>
> From: Pan Nengyuan
>
> There are some memleaks when we call 'device_list_properties'. This patch
> move timer_new from init into realize to fix it.
> Meanwhile, do the null check in mos6522_reset() to avoid null deref if we
> move timer_new into realize(
On 2/20/20 8:37 AM, Peter Maydell wrote:
> This is tricky, because the SIMDFMAC register
> field indicates "do we have fused-multiply-accumulate
> for either VFP or Neon", so in a VFP-no-Neon core or
> a Neon-no-VFP core it will be 1 but can't be used on its
> own as a gate on "should this insn be
On Fri, 14 Feb 2020 at 18:15, Richard Henderson
wrote:
>
> The main goal of the patchset is to move the ARM_FEATURE_VFP
> test from outside of the disas_vfp_insn() to inside each of
> the trans_* functions, so that we get the proper ISA check
> for each case.
>
> At the end of that, it is easy to
On 2/20/20 4:58 PM, Changbin Du wrote:
Recently when debugging an arm32 system on qemu, I found sometimes the
single-step command (stepi) is not working. This can be reproduced by
below steps:
1) start qemu-system-arm -s -S .. and wait for gdb connection.
2) start gdb and connect to qemu. In
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> Passing the raw op field from the manual is less instructive
> than it might be. Do the full decode and use the existing
> helpers to perform the expansion.
>
> Since these are v8 insns, VECLEN+VECSTRIDE are already RES0.
>
> Signed-off-b
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> Passing the raw o1 and o2 fields from the manual is less
> instructive than it might be. Do the full decode and let
> the trans_* functions pass in booleans to a helper.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/vfp.decode
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> Those vfp instructions without extra opcode fields can
> share a common @format for brevity.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/vfp.decode | 134 --
> 1 file changed, 52 insert
On Wed, 19 Feb 2020 at 10:16, Laurent Vivier wrote:
>
> The following changes since commit 6c599282f8ab382fe59f03a6cae755b89561a7b3:
>
> Merge remote-tracking branch
> 'remotes/armbru/tags/pull-monitor-2020-02-15-v2' into staging (2020-02-17
> 13:32:25 +)
>
> are available in the Git repos
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> We have converted all tests against these features
> to ISAR tests.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
Hi Bin,
On 2/20/20 3:42 PM, Bin Meng wrote:
Although the real world SiFive HiFive Unleashed board is a 64-bit
hardware configuration, with QEMU it is possible to test 32-bit
configuration with the same hardware features.
This updates the roms Makefile to add the build rules for creating
the 32-
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> Use isar feature tests instead of feature bit tests.
>
> Although none of QEMUs current cpus have VFPv3 without D32,
> replace the large comment explaining why with one line that
> sets ARM_HWCAP_ARM_VFPv3D16 under the correct conditions.
+Sunil Muthuswamy
LGTM. Thanks!
Reviewed-by: Justin Terry (VM)
> -Original Message-
> From: Dr. David Alan Gilbert
> Sent: Tuesday, February 18, 2020 2:00 AM
> To: Philippe Mathieu-Daudé
> Cc: qemu-devel@nongnu.org; Max Reitz ; Kevin Wolf
> ; Thomas Huth ; Fam Zheng
> ; Eduardo Habko
On 2/14/20 12:52 PM, Oksana Vohchana wrote:
Improves EXEC migration to run whole test stage
Signed-off-by: Oksana Vohchana
---
tests/acceptance/migration.py | 2 ++
1 file changed, 2 insertions(+)
Indeed, with this changes the migration is triggered.
Tested-by: Wainer dos Santos Moschet
On 22.12.19 12:36, Alberto Garcia wrote:
> This patch adds QCow2SubclusterType, which is the subcluster-level
> version of QCow2ClusterType. All QCOW2_SUBCLUSTER_* values have the
> the same meaning as their QCOW2_CLUSTER_* equivalents (when they
> exist). See below for details and caveats.
>
> In
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> We now have proper ISA checks within each trans_* function.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/target/arm/translate.c b/target/arm/translate.c
>
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> Have the calls adjacent as an intermediate step toward
> actually merging the decodes.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate.c | 80 +-
> 1 file changed, 24 insertions(+
On Fri, 2020-02-07 at 18:28 +, Dr. David Alan Gilbert wrote:
> * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > On Mon, 2020-02-03 at 19:57 +, Dr. David Alan Gilbert wrote:
> > > * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > > > This patch series is bunch of cleanups to the hmp monitor
On Thu, 20 Feb 2020 14:16:22 +0100
Christian Borntraeger wrote:
> There is a special quiesce PSW that we check for "shutdown". Otherwise
> disabled
> wait is detected as "crashed". Architecturally we must only check PSW bits
> 116-127. Fix this.
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: C
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> Now that we no longer have an early check for ARM_FEATURE_VFP,
> we can use the proper ISA check in trans_VLLDM_VLSTM.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/vfp.decode | 2 ++
> target/arm/translate-vfp.inc.c
Device unplug can be done asynchronously. Thus, sending the second
device_del before the previous unplug is complete may lead to
unexpected results. On PCIe devices, this cancels the hot-unplug
process.
Signed-off-by: Julia Suvorova
---
qdev-monitor.c | 6 ++
1 file changed, 6 insertions(+)
1 - 100 of 311 matches
Mail list logo
