Avoid orphan memory regions being added in the /unattached QOM
container.
Note this change break the migration of the LM32 milkymist machine.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/input/milkymist-softusb.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/
On Sun, Feb 16, 2020 at 5:56 AM Bin Meng wrote:
>
> At present the board serial number is hard-coded to 1, and passed
> to OTP model during initialization. Firmware (FSBL, U-Boot) uses
> the serial number to generate a unique MAC address for the on-chip
> ethernet controller. When multiple QEMU 's
Avoid orphan memory regions being added in the /unattached QOM
container.
Note this change break the migration of the LM32 milkymist machine.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/net/milkymist-minimac2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/net/
On Mon, Feb 24, 2020 at 1:10 PM Philippe Mathieu-Daudé
wrote:
>
> memory_region_init_rom_nomigrate() has the same content than
> memory_region_init_ram_shared_nomigrate(), with setting the
> readonly mode. The code is easier to review as creating a
> readonly ram/shared/nomigrate region.
>
> Signe
Avoid orphan memory regions being added in the /unattached QOM
container.
Note this change break the migration of the nSeries machines.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/block/onenand.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/hw/block/onenand.c b/hw
On Mon, Feb 24, 2020 at 12:49 PM Philippe Mathieu-Daudé
wrote:
>
> Since memory region aliases are neither rom nor ram, they are
> described as i/o, which is often incorrect. Return instead the
> type of the original region we are aliasing.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by:
Patchew URL: https://patchew.org/QEMU/cover.1582576372.git.jag.ra...@oracle.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v5 00/50] Initial support for multi-process qemu
Message-id: cover.1582576372.git.jag.ra...@oracle.c
Patchew URL: https://patchew.org/QEMU/cover.1582576372.git.jag.ra...@oracle.com/
Hi,
This series failed the docker-mingw@fedora 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 ===
#
The old name, isar_feature_aa32_fpdp, does not reflect
that the test includes VFPv2. We will introduce another
feature tests for VFPv3.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 4 ++--
target/arm/translate-vfp.inc.c | 40 +++
This uses TYPE_PL011 when creating the serial port so that the code
looks cleaner.
Signed-off-by: Gavin Shan
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
---
v2: Improved changelog suggested by Phil
---
hw/arm/sbsa-ref.c| 3 ++-
hw/arm/virt.c| 3 ++-
hw/arm/xln
Use this in the places that were checking ARM_FEATURE_VFP, and
are obviously testing for the existance of the register set
as opposed to testing for some particular instruction extension.
Signed-off-by: Richard Henderson
---
target/arm/cpu.h| 9 +
hw/intc/armv7m_nvic.c | 20 ++
All remaining tests for VFP4 are for fused multiply-add insns.
Since the MVFR1 field is used for both VFP and NEON, move its adjustment
from the !has_neon block to the (!has_vfp && !has_neon) block.
Test for vfp of the appropraite width alongside the test for simdfmac
within translate-vfp.inc.c.
Sort this check to the start of a trans_* function.
Merge this with any existing test for fpdp_v2.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-vfp.inc.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/target/
Shuffle the order of the checks so that we test the ISA
before we test anything else, such as the register arguments.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-vfp.inc.c | 140 +
1 file changed, 71 insertions(+), 69 dele
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
---
v2: Fix !secure (pmm)
---
target/arm/vfp.decode | 2 ++
target/arm/translate-vfp.inc.c | 39 +
target/arm/tr
We now have proper ISA checks within each trans_* function.
Reviewed-by: Peter Maydell
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
index 0489e0cdaa..893911fca7 100644
--- a/tar
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.
Mirror the test sequence used in the linux kernel.
Signed-off-by:
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 eliminate all of the remaining tests vs ARM_FEATURE_VFP*
in favor of
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.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/vfp.decode | 17 +--
target/arm/tran
We have converted all tests against these features
to ISAR tests.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 3 ---
target/arm/cpu.c | 25 -
target/arm/cpu64.c | 3 ---
target/arm/kvm32.c | 5 -
target/arm/kvm64.c | 1 -
We will shortly use these to test for VFPv2 and VFPv3
in different situations.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 1e6eac0cd2..f7a90f512
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.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/vfp-
Patchew URL: https://patchew.org/QEMU/cover.1582576372.git.jag.ra...@oracle.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 ===
Those vfp instructions without extra opcode fields can
share a common @format for brevity.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/vfp.decode | 134 --
1 file changed, 52 insertions(+), 82 deletions(-)
diff --git a/targ
We cannot easily create "any" functions for these, because the
ID_AA64PFR0 fields for FP and SIMD signal "enabled" with zero.
Which means that an aarch32-only cpu will return incorrect results
when testing the aarch64 registers.
To use these, we must either have context or additionally test
vs ARM
On Fri, Feb 21, 2020 at 05:41:57PM +0100, David Hildenbrand wrote:
> We want to make use of ram_block_discard_range() in the RAM block resize
> callback when growing a RAM block, *before* used_length is changed.
> Let's relax the check. We always have a reserved mapping for the whole
> max_length,
When sanity checking id_aa64pfr0, use the raw FP and SIMD fields,
because the values must match. Delay the test until we've finished
modifying the id_aa64pfr0 register.
Signed-off-by: Richard Henderson
---
target/arm/cpu.c | 23 ---
1 file changed, 12 insertions(+), 11 delet
On 2/24/20 7:41 PM, Philippe Mathieu-Daudé wrote:
On 2/24/20 5:16 AM, Gavin Shan wrote:
This uses TYPE_PL011 when creating the serial port, to make the code
a bit more atomatic.
Do you mean aUtomatic? I'm not sure this automate the code, but using the TYPE
definition is definitively cleaner.
We will eventually remove the early ARM_FEATURE_VFP test,
so add a proper test for each trans_* that does not already
have another ISA test.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-vfp.inc.c | 78 ++
1 file changed, 69
Have the calls adjacent as an intermediate step toward
actually merging the decodes.
Signed-off-by: Richard Henderson
---
v2: Fix fallthrough in disas_arm_insn vs vfp insns.
---
target/arm/translate.c | 83 +++---
1 file changed, 29 insertions(+), 54 deletions
On Fri, Feb 21, 2020 at 05:42:01PM +0100, David Hildenbrand wrote:
[...]
> @@ -3160,7 +3160,13 @@ static int ram_load_postcopy(QEMUFile *f)
> break;
> }
>
> -if (!offset_in_ramblock(block, addr)) {
> +/*
> + * Relying on used_len
On Fri, Feb 21, 2020 at 05:41:56PM +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 precopy, t
On Fri, Feb 21, 2020 at 05:41:58PM +0100, David Hildenbrand wrote:
> In case we grow our RAM after ram_postcopy_incoming_init() (e.g., when
> synchronizing the RAM block state with the migration source), the resized
> part would not get discarded. Let's perform that when being notified
> about a re
On Mon, Feb 24, 2020 at 11:58:09AM -0600, Babu Moger wrote:
>
>
> On 2/24/20 11:19 AM, Igor Mammedov wrote:
> > On Thu, 13 Feb 2020 12:17:46 -0600
> > Babu Moger wrote:
> >
> >> Check and Load the apicid handlers from X86CPUDefinition if available.
> >> Update the calling convention for the api
On Fri, Feb 21, 2020 at 05:42:04PM +0100, David Hildenbrand wrote:
> When we partially change mappings (esp., mmap over parts of an existing
> mmap like qemu_ram_remap() does) where we have a userfaultfd handler
> registered, the handler will implicitly be unregistered from the parts that
> changed
On 2/24/20 10:26 AM, Peter Maydell wrote:
> The ARMv8.3-CCIDX extension makes the CCSIDR_EL1 system ID registers
> have a format that uses the full 64 bit width of the register, and
> adds a new CCSIDR2 register so AArch32 can get at the high 32 bits.
>
> QEMU doesn't implement caches, so we just
On 2/24/20 4:31 PM, Eduardo Habkost wrote:
> On Mon, Feb 24, 2020 at 11:58:09AM -0600, Babu Moger wrote:
>>
>>
>> On 2/24/20 11:19 AM, Igor Mammedov wrote:
>>> On Thu, 13 Feb 2020 12:17:46 -0600
>>> Babu Moger wrote:
>>>
Check and Load the apicid handlers from X86CPUDefinition if available
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
Signed-off-by: Alistair Francis
---
linux-user/riscv/syscall32_nr.h | 314
linux-user/riscv/syscall64_nr.h | 303 ++
linux-user/riscv/syscall_nr.h | 294 +-
3 files changed, 619 insertions(+), 292 deletions
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
Review
a4f30719a8cd, way back in 2007 noted that "PowerPC hypervisor mode is not
fundamentally available only for PowerPC 64" and added a 32-bit version
of the MSR[HV] bit.
But nothing was ever really done with that; there is no meaningful support
for 32-bit hypervisor mode 13 years later. Let's stop pr
The PowerPC 970 CPU was a cut-down POWER4, which had hypervisor capability.
However, it can be (and often was) strapped into "Apple mode", where the
hypervisor capabilities were disabled (essentially putting it always in
hypervisor mode).
That's actually the only mode of the 970 we support in qemu
POWER "book S" (server class) cpus have a concept of "real mode" where
MMU translation is disabled... sort of. In fact this can mean a bunch
of slightly different things when hypervisor mode and other
considerations are present.
We had some errors in edge cases here, so clean some things up and
c
Currently we create the Real Mode Offset Register (RMOR) on all Book3S cpus
from POWER7 onwards. However the translation mode which the RMOR controls
is no longer supported in POWER9, and so the register has been removed from
the architecture.
Remove it from our model on POWER9 and POWER10.
Sign
For the "pseries" machine, we use "virtual hypervisor" mode where we
only model the CPU in non-hypervisor privileged mode. This means that
we need guest physical addresses within the modelled cpu to be treated
as absolute physical addresses.
We used to do that by clearing LPCR[VPM0] and setting L
When running guests under a hypervisor, the hypervisor obviously needs to
be protected from guest accesses even if those are in what the guest
considers real mode (translation off). The POWER hardware provides two
ways of doing that: The old way has guest real mode accesses simply offset
and bound
The table of RMA limits based on the LPCR[RMLS] field is slightly wrong.
We're missing the RMLS == 0 => 256 GiB RMA option, which is available on
POWER8, so add that.
The comment that goes with the table is much more wrong. We *don't* filter
invalid RMLS values when writing the LPCR, and there's
On ppc we have the concept of virtual hypervisor ("vhyp") mode, where we
only model the non-hypervisor-privileged parts of the cpu. Essentially we
model the hypervisor's behaviour from the point of view of a guest OS, but
we don't model the hypervisor's execution.
In particular, in this mode, qem
MIN_RMA_SLOF records the minimum about of RMA that the SLOF firmware
requires. It lets us give a meaningful error if the RMA ends up too small,
rather than just letting SLOF crash.
It's currently stored as a number of megabytes, which is strange for global
constants. Move that megabyte scaling i
Currently, we construct the SLBE used for VRMA translations when the LPCR
is written (which controls some bits in the SLBE), then use it later for
translations.
This is a bit complex and confusing - simplify it by simply constructing
the SLBE directly from the LPCR when we need it.
Signed-off-by:
When the LPCR is written, we update the env->rmls field with the RMA limit
it implies. Simplify things by just calculating the value directly from
the LPCR value when we need it.
It's possible this is a little slower, but it's unlikely to be significant,
since this is only for real mode accesses
When we store the Logical Partitioning Control Register (LPCR) we have a
big switch statement to work out which are valid bits for the cpu model
we're emulating.
As well as being ugly, this isn't really conceptually correct, since it is
based on the mmu_model variable, whereas the LPCR isn't (only
Currently we use a big switch statement in ppc_hash64_update_rmls() to work
out what the right RMA limit is based on the LPCR[RMLS] field. There's no
formula for this - it's just an arbitrary mapping defined by the existing
CPU implementations - but we can make it a bit more readable by using a
lo
The Real Mode Area (RMA) needs to fit within the NUMA node owning memory
at address 0. That's usually node 0, but can be a later one if there are
some nodes which have no memory (only CPUs).
This is currently handled by the spapr_node0_size() helper. It has only
one caller, so there's not a lot
Move the calculation of the Real Mode Area (RMA) size into a helper
function. While we're there clean it up and correct it in a few ways:
* Add comments making it clearer where the various constraints come from
* Remove a pointless check that the RMA fits within Node 0 (we've just
clamped
The Real Mode Area (RMA) is the part of memory which a guest can access
when in real (MMU off) mode. Of course, for a guest under KVM, the MMU
isn't really turned off, it's just in a special translation mode - Virtual
Real Mode Area (VRMA) - which looks like real mode in guest mode.
The mechanics
This function calculates the maximum size of the RMA as implied by the
host's page size of structure of the VRMA (there are a number of other
constraints on the RMA size which will supersede this one in many
circumstances).
The current interface takes the current RMA size estimate, and clamps it
t
On 2020/2/25 0:04, Alex Williamson wrote:
> On Mon, 24 Feb 2020 14:42:17 +0800
> "Longpeng(Mike)" wrote:
>
>> From: Longpeng
>>
>> vfio_pci_load_rom() maybe failed and then the vdev->rom is NULL in
>> some situation (though I've not encountered yet), maybe we should
>> avoid the VM abort.
>>
In spapr_machine_init() we clamp the size of the RMA to 16GiB and the
comment saying why doesn't make a whole lot of sense. In fact, this was
done because the real mode handling code elsewhere limited the RMA in TCG
mode to the maximum value configurable in LPCR[RMLS], 16GiB.
But,
* Actually LPC
On Mon, Feb 24, 2020 at 9:05 AM Damien Hedde wrote:
>
> This object may be used to represent a clock inside a clock tree.
>
> A clock may be connected to another clock so that it receives update,
> through a callback, whenever the source/parent clock is updated.
>
> Although only the root clock of
David Gibson writes:
> When running guests under a hypervisor, the hypervisor obviously needs to
> be protected from guest accesses even if those are in what the guest
> considers real mode (translation off). The POWER hardware provides two
> ways of doing that: The old way has guest real mode a
On Mon, Feb 24, 2020 at 9:06 AM Damien Hedde wrote:
>
> Signed-off-by: Damien Hedde
> Reviewed-by: Peter Maydell
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Alistair
> --
>
> v7: remove leading underscores in macro args
> ---
> include/hw/clock.h | 9 +
On Mon, Feb 24, 2020 at 12:18:27PM +0100, Greg Kurz wrote:
> On Wed, 19 Feb 2020 10:21:05 +1100
> David Gibson wrote:
>
> > On Fri, Feb 14, 2020 at 07:19:00PM +0100, Greg Kurz wrote:
> > > On Fri, 14 Feb 2020 09:28:35 +1100
> > > David Gibson wrote:
> > >
> > > > On Thu, Feb 13, 2020 at 04:38:3
On Mon, Feb 24, 2020 at 09:55:11PM +0100, Philippe Mathieu-Daudé wrote:
> This commit was produced with the Coccinelle script
> scripts/coccinelle/memory-region-housekeeping.cocci.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: David Gibson
> ---
> hw/pci-host/prep.c | 5 ++---
> 1 file
On Mon, Feb 24, 2020 at 09:55:18PM +0100, Philippe Mathieu-Daudé wrote:
> The scripts/coccinelle/memory-region-housekeeping.cocci reported:
> * TODO
> [[view:./hw/ppc/ppc405_boards.c::face=ovl-face1::linb=195::colb=8::cole=30][potential
> use of memory_region_init_rom*() in ./hw/ppc/ppc405_board
On Mon, Feb 24, 2020 at 09:55:12PM +0100, Philippe Mathieu-Daudé wrote:
> This commit was produced with the Coccinelle script
> scripts/coccinelle/memory-region-housekeeping.cocci.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: David Gibson
> ---
> hw/ppc/mac_newworld.c | 3 +--
> hw/ppc
David Gibson writes:
> Currently, we construct the SLBE used for VRMA translations when the LPCR
> is written (which controls some bits in the SLBE), then use it later for
> translations.
>
> This is a bit complex and confusing - simplify it by simply constructing
> the SLBE directly from the LPC
This is a new job-creating command.
Signed-off-by: John Snow
---
qapi/block-core.json | 18 ++
qapi/transaction.json | 2 ++
blockdev.c| 78 +++
3 files changed, 98 insertions(+)
diff --git a/qapi/block-core.json b/qapi/block-core.js
Just a mild cleanup while I was here.
Signed-off-by: John Snow
---
tests/qemu-iotests/iotests.py | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 8815052eb5..5d2990a0e4 100644
--- a/tests/q
Signed-off-by: John Snow
---
tests/qemu-iotests/257| 110 +---
tests/qemu-iotests/bitmaps.py | 131 ++
2 files changed, 132 insertions(+), 109 deletions(-)
create mode 100644 tests/qemu-iotests/bitmaps.py
diff --git a/tests/qemu-io
Hi,
This is a new (very small) block job that writes a pattern into a
bitmap. The only pattern implemented is the top allocation information.
This can be used to "recover" an incremental bitmap chain if an external
snapshot was taken without creating a new bitmap first: any writes made
to the ima
This job copies the allocation map into a bitmap. It's a job because
there's no guarantee that allocation interrogation will be quick (or
won't hang), so it cannot be retrofit into block-dirty-bitmap-merge.
It was designed with different possible population patterns in mind,
but only top layer all
It's easier to work with than a list of tuples, because we can check the
keys for membership.
Signed-off-by: John Snow
---
python/qemu/machine.py| 10 +-
tests/qemu-iotests/040| 12 ++--
tests/qemu-iotests/260| 5 +++--
tests/qemu-iotests/iotests.py | 16
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Monday, February 24, 2020 11:19 PM
> To: Zhanghailiang ;
> qemu-devel@nongnu.org
> Cc: daniel...@qnap.com; dgilb...@redhat.com; quint...@redhat.com
> Subject: Re: [PATCH V2 7/8] COLO: Migrate dirty pages during th
On Mon, Feb 24, 2020 at 1:35 PM Stefan Ring wrote:
>
> [...]. As already stated in
> the original post, the problem only occurs with multiple parallel
> write requests happening.
Actually I did not state that. Anyway, the corruption does not happen
when I restrict the ZFS io scheduler to only 1 r
On Thu, Feb 20, 2020 at 10:19 AM Stefan Ring wrote:
>
> Hi,
>
> I have a very curious problem on an oVirt-like virtualization host
> whose storage lives on gluster (as qcow2).
>
> The problem is that of the writes done by ZFS, whose sizes according
> to blktrace are a mixture of 8, 16, 24, ... 256
On Mon, Feb 24, 2020 at 2:27 PM Kevin Wolf wrote:
> > > There are quite a few machines running on this host, and we have not
> > > experienced other problems so far. So right now, only ZFS is able to
> > > trigger this for some reason. The guest has 8 virtual cores. I also
> > > tried writing dire
On 2020/2/24 下午8:43, Paolo Bonzini wrote:
> On 22/02/20 13:25, Chen Gang wrote:
>> On 2020/2/22 下午3:37, Paolo Bonzini wrote:
>>> On 22/02/20 03:10, Chen Gang wrote:
Set C1 to 1 if stack overflow occurred; set to 0 otherwise".
In helper_fxam_ST0, I guess, we need "env->fpus |= 0x200"
/On Mon, Feb 24, 2020 at 9:12 AM Damien Hedde wrote
>
> Add functions to easily handle clocks with devices.
> Clock inputs and outputs should be used to handle clock propagation
> between devices.
> The API is very similar the GPIO API.
>
> This is based on the original work of Frederic Konrad.
>
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
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
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 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
> -Original Message-
> From: Daniel P. Berrangé [mailto:berra...@redhat.com]
> Sent: Monday, February 24, 2020 8:36 PM
> To: miaoyubo
> Cc: peter.mayd...@linaro.org; m...@redhat.com; qemu-devel@nongnu.org;
> Xiexiangyou ; shannon.zha...@gmail.com;
> imamm...@redhat.com
> Subject: Re: [RFC
From: Chen Qun
Clang static code analyzer show warning:
block/file-posix.c:891:9: warning: Value stored to 'op' is never read
op = RAW_PL_ABORT;
^
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-bl...@nongnu.org
---
From: Chen Qun
Hi all, our EulerRobot integrates clang static code analyzer tools and
found a lot of warnings. They are mainly redundant variable assignments.
This series fixes the warnings.
Chen Qun (13):
block/stream: Remove redundant statement in stream_run()
block/iscsi:Remove redundant
From: Chen Qun
Clang static code analyzer show warning:
hw/scsi/esp-pci.c:198:9: warning: Value stored to 'size' is never read
size = 4;
^ ~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Paolo Bonzini
Cc: Fam Zheng
---
hw/scsi/esp-pci.c | 1 -
1 file change
From: Chen Qun
The "ret" has been assigned in all branches. It didn't need to be
assigned separately.
Clang static code analyzer show warning:
migration/vmstate.c:365:17: warning: Value stored to 'ret' is never read
ret = 0;
^ ~
Reported-by: Euler Robot
S
From: Chen Qun
Clang static code analyzer show warning:
hw/display/exynos4210_fimd.c:1313:17: warning: Value stored to 'is_dirty' is
never read
is_dirty = false;
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Igor Mitsyanko
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
From: Chen Qun
The "again" assignment is meaningless before g_assert_not_reached.
In addition, the break statements no longer needs to be after
g_assert_not_reached.
Clang static code analyzer show warning:
hw/usb/hcd-ehci.c:2108:13: warning: Value stored to 'again' is never read
aga
From: Chen Qun
Clang static code analyzer show warning:
hw/display/pxa2xx_lcd.c:596:9: warning: Value stored to 'format' is never read
format = 0;
^~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Andrzej Zaborowski
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
From: Chen Qun
Clang static code analyzer show warning:
monitor/hmp-cmds.c:2867:17: warning: Value stored to 'set' is never read
set = true;
^
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: "Dr. David Alan Gilbert"
---
monitor/hmp-cmds.c | 1
From: Chen Qun
Clang static code analyzer show warning:
hw/dma/xlnx-zdma.c:399:13: warning: Value stored to 'dst_type' is never read
dst_type = FIELD_EX32(s->dsc_dst.words[3], ZDMA_CH_DST_DSCR_WORD3,
^ ~~~
Repor
From: Chen Qun
Clang static code analyzer show warning:
hw/display/blizzard.c:940:9: warning: Value stored to 'data' is never read
data >>= 5;
^~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Andrzej Zaborowski
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
---
From: Chen Qun
Clang static code analyzer show warning:
block/stream.c:186:9: warning: Value stored to 'ret' is never read
ret = 0;
^ ~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: John Snow
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-bl...@nongnu.org
---
block/s
From: Chen Qun
Clang static code analyzer show warning:
scsi/scsi-disk.c:1918:5: warning: Value stored to 'buflen' is never read
buflen = req->cmd.xfer;
^~
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Paolo Bonzini
Cc: Fam Zheng
---
hw/scsi/scsi-disk.
From: Chen Qun
Clang static code analyzer show warning:
block/iscsi.c:1920:9: warning: Value stored to 'flags' is never read
flags &= ~BDRV_O_RDWR;
^
Reported-by: Euler Robot
Signed-off-by: Chen Qun
---
Cc: Ronnie Sahlberg
Cc: Paolo Bonzini
Cc: Peter Lie
From: Chen Qun
Clang static code analyzer show warning:
hw/timer/exynos4210_mct.c:1370:9: warning: Value stored to 'index' is never read
index = GET_L_TIMER_CNT_REG_IDX(offset, lt_i);
^ ~
hw/timer/exynos4210_mct.c:1399:9: warning: Value st
Patchew URL: https://patchew.org/QEMU/20200225015026.940-1-miaoy...@huawei.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 Mon, Feb 24, 2020 at 08:23:43PM +0100, Greg Kurz wrote:
> If a hot plug or unplug request is pending at CAS, we currently trigger
> a CAS reboot, which severely increases the guest boot time. This is
> because SLOF doesn't handle hot plug events and we had no way to fix
> the FDT that gets prese
301 - 400 of 438 matches
Mail list logo
