ср, 28 окт. 2020 г., 5:19 Chen Qun :
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed
> warning:
> target/sparc/win_helper.c: In function ‘get_gregset’:
> target/sparc/win_helper.c:304:9: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 304 | t
On 27/10/20 21:42, Daniele Buono wrote:
> Ok, no problem. I can definitely disable the check on GCC.
>
> Paolo, would you like me to disable checks on AR/linker for lto too?
> If so, should I add some of this information on a document, perhaps
> docs/devel/lto.rst, so it is written somewhere for f
ср, 28 окт. 2020 г., 5:19 Chen Qun :
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed
> warning:
> target/sparc/translate.c: In function ‘gen_st_asi’:
> target/sparc/translate.c:2320:12: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 2320 | if
On 27/10/2020 23.38, John Snow wrote:
> Try using pytest to manage our various tests; even though right now
> they're only invoking binaries and not really running any python-native
> code.
>
> Create tests/, and add test_lint.py which calls out to mypy, flake8,
> pylint and isort to enforce the s
On Wed, Oct 28, 2020 at 01:51:07PM +0800, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> ../target/ppc/excp_helper.c: In function ‘powerpc_excp’:
> ../target/ppc/excp_helper.c:529:13: warning: this statement may fall through
> [-Wimplicit-fallthro
On 27/10/2020 11.21, Philippe Mathieu-Daudé wrote:
> From: Alexander von Gluck IV
>
> Signed-off-by: Alexander von Gluck IV
> [PMD: Avoid recreating the image each time]
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/keys/vagrant| 27 +
> tests/keys/vagrant.pub| 1
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
../target/ppc/excp_helper.c: In function ‘powerpc_excp’:
../target/ppc/excp_helper.c:529:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
529 | msr |= env->error_code;
|
On 24/10/2020 13.24, Christian Schoenebeck wrote:
> On Samstag, 24. Oktober 2020 08:04:20 CEST Thomas Huth wrote:
>> On 08/10/2020 20.34, Christian Schoenebeck wrote:
>>> This new function is purely for debugging purposes. It prints the
>>> current qos graph to stdout and allows to identify problem
We want missing symbols fail module load right away instead of having
qemu abort later on in case lazy binding fails. Can happen -- for
example -- when trying to load a module for a pci device
(virtio-gpu-pci) into a qemu without pci support (qemu-system-avr).
Signed-off-by: Gerd Hoffmann
---
u
> -Original Message-
> From: David Gibson [mailto:da...@gibson.dropbear.id.au]
> Sent: Wednesday, October 28, 2020 12:28 PM
> To: Chenqun (kuhn)
> Cc: qemu-devel@nongnu.org; qemu-triv...@nongnu.org; c...@kaod.org;
> Zhanghailiang ; ganqixin
> ; Euler Robot
> Subject: Re: [PATCH] target/pp
From: Bin Meng
This creates a minimum model for Microchip PolarFire SoC SYSREG
module. It only implements the ENVM_CR register to tell guest
software that eNVM is running at the configured divider rate.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
(no changes since v1)
MAINTAIN
From: Bin Meng
Somehow HSS needs to access address 0 [1] for the DDR calibration data
which is in the chipset's reserved memory. Let's map it.
[1] See the config_copy() calls in various places in ddr_setup() in
the HSS source codes.
Signed-off-by: Bin Meng
---
Changes in v2:
- change to
From: Bin Meng
When system memory is larger than 1 GiB (high memory), PolarFire SoC
maps it at address 0x10__. Address 0xC000_ and above is
aliased to the same 1 GiB low memory with different cache attributes.
At present QEMU maps the system memory contiguously from 0x8000_.
This
From: Bin Meng
Previously IOSCB_CFG was created as an unimplemented device. With
the new IOSCB model, its memory range is already covered by the
IOSCB hence remove the previous unimplemented device creation in
the SoC codes.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
(no change
From: Bin Meng
This creates a model for PolarFire SoC IOSCB [1] module. It actually
contains lots of sub-modules like various PLLs to control different
peripherals. Only the mininum capabilities are emulated to make the
HSS DDR memory initialization codes happy. Lots of sub-modules are
created as
From: Bin Meng
Connect DDR SGMII PHY module and CFG module to the PolarFire SoC.
Signed-off-by: Bin Meng
---
(no changes since v1)
hw/riscv/Kconfig | 1 +
hw/riscv/microchip_pfsoc.c | 18 ++
include/hw/riscv/microchip_pfsoc.h | 5 +
3 files cha
From: Bin Meng
The latest SD card image [1] released by Microchip ships a Linux
kernel with built-in PolarFire SoC I2C driver support. The device
tree file includes the description for the I2C1 node hence kernel
tries to probe the I2C1 device during boot.
It is enough to create an unimplemented
From: Bin Meng
Previously SYSREG was created as an unimplemented device. Now that
we have a simple SYSREG module, connect it.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
(no changes since v1)
hw/riscv/Kconfig | 1 +
hw/riscv/microchip_pfsoc.c | 9
From: Bin Meng
At present the DDR memory controller is not modeled, hence the factory
HSS firmware does not boot out of the box on QEMU. A modified HSS is
required per the instructions on [1].
This series adds the missing DDR memory controller support to PolarFire
SoC, as well as adding various
From: Bin Meng
The PolarFire SoC DDR Memory Controller mainly includes 2 modules,
called SGMII PHY module and the CFG module, as documented in the
chipset datasheet.
This creates a single file that groups these 2 modules, providing
the minimum functionalities that make the HSS DDR initialization
From: Bin Meng
It is not easy to find out the memory map for a specific component
in the PolarFire SoC as the information is scattered in different
documents. Add some comments so that people can know where to get
such information from the Microchip website.
Signed-off-by: Bin Meng
---
Change
On Wed, Oct 28, 2020 at 12:18:18PM +0800, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> target/ppc/mmu_helper.c: In function ‘dump_mmu’:
> target/ppc/mmu_helper.c:1351:12: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 13
On Wed, Oct 28, 2020 at 12:16:20PM +0800, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> ../target/ppc/excp_helper.c: In function ‘powerpc_excp’:
> ../target/ppc/excp_helper.c:529:13: warning: this statement may fall through
> [-Wimplicit-fallthro
Hi,
Need some help on a qemu crash we are facing.
We hit asserts on below line
"tcg/tcg.c"
336 static void set_jmp_reset_offset(TCGContext *s, int which)
337 {
338 size_t off = tcg_current_code_size(s);
339 s->tb_jmp_reset_offset[which] = off;
Update MIPS machine documentation to add Loongson-3 based machine description.
Signed-off-by: Huacai Chen
---
docs/system/target-mips.rst | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/system/target-mips.rst b/docs/system/target-mips.rst
index cd2a931..138441b 100644
--- a/
Add Loongson-3 based machine support, it use liointc as the interrupt
controler and use GPEX as the pci controller. Currently it can work with
both TCG and KVM.
As the machine model is not based on any exiting physical hardware, the
name of the machine is "loongson3-virt". It may be superseded in
On Wed, Oct 28, 2020 at 12:18:17PM +0800, Chen Qun wrote:
> When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
> hw/ppc/ppc.c: In function ‘ppc6xx_set_irq’:
> hw/ppc/ppc.c:118:16: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> 118 |
Preparing to add Loongson-3 machine support, add Loongson-3's LEFI (a
UEFI-like interface for BIOS-Kernel boot parameters) helpers first.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Huacai Chen
Co-developed-by: Jiaxun Yang
Signed-off-by: Jiaxun Yang
---
hw/mips/loongson3_bootp.c | 165
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
hw/ppc/ppc.c: In function ‘ppc6xx_set_irq’:
hw/ppc/ppc.c:118:16: warning: this statement may fall through
[-Wimplicit-fallthrough=]
118 | if (level) {
|^
hw/ppc/ppc.c:123:9: note: here
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
linux-user/mips/cpu_loop.c: In function ‘cpu_loop’:
linux-user/mips/cpu_loop.c:104:24: warning: this statement may fall through
[-Wimplicit-fallthrough=]
104 | if ((ret = get_user_ual(arg8, sp_reg +
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
target/ppc/mmu_helper.c: In function ‘dump_mmu’:
target/ppc/mmu_helper.c:1351:12: warning: this statement may fall through
[-Wimplicit-fallthrough=]
1351 | if (ppc64_v3_radix(env_archcpu(env))) {
|
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
../hw/timer/renesas_tmr.c: In function ‘tmr_read’:
../hw/timer/renesas_tmr.c:221:19: warning: this statement may fall through
[-Wimplicit-fallthrough=]
221 | } else if (ch == 0) {i
| ^
.
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
../accel/tcg/user-exec.c: In function ‘handle_cpu_signal’:
../accel/tcg/user-exec.c:169:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
169 | cpu_exit_tb_from_sighandler(cpu, old_set)
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
target/sparc/win_helper.c: In function ‘get_gregset’:
target/sparc/win_helper.c:304:9: warning: this statement may fall through
[-Wimplicit-fallthrough=]
304 | trace_win_helper_gregset_error(pstate);
|
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
target/sparc/translate.c: In function ‘gen_st_asi’:
target/sparc/translate.c:2320:12: warning: this statement may fall through
[-Wimplicit-fallthrough=]
2320 | if (!(dc->def->features & CPU_FEATURE_HYPV)) {
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
hw/intc/arm_gicv3_kvm.c: In function ‘kvm_arm_gicv3_put’:
hw/intc/arm_gicv3_kvm.c:484:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
kvm_gicc_access(s, ICC_AP0R_EL1(1), ncpu, ®64, tru
The current "#ifdef TARGET_X86_64" statement affects
the compiler's determination of fall through.
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
target/i386/translate.c: In function ‘gen_shiftd_rm_T1’:
target/i386/translate.c:1773:12: warning: this statement may fal
MIPSR6 (not only MIPS32R6) processors support unaligned access in
hardware, so set MO_UNALN in their default_tcg_memop_mask. Btw, new
Loongson-3 (such as Loongson-3A4000) also support unaligned access,
since both old and new Loongson-3 use the same binaries, we can simply
set MO_UNALN for all Loong
Hi all,
When building with GCC9 using CFLAG -Wimplicit-fallthrough=2 we get a
lot of warning. Some problems may be missing break statements which
I have submitted the patch separately.
This series is all add the corresponding "fall through" comment to fix them.
Chen Qun (9):
target/i386: sil
Implement fw_cfg_arch_key_name(), which returns the name of a
mips-specific key.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Huacai Chen
Co-developed-by: Jiaxun Yang
Signed-off-by: Jiaxun Yang
---
hw/mips/fw_cfg.c| 35 +++
hw/mips/fw_cfg.h| 19 ++
Loongson-3 CPU family include Loongson-3A R1/R2/R3/R4 and Loongson-3B
R1/R2. Loongson-3A R1 is the oldest and its ISA is the smallest, while
Loongson-3A R4 is the newest and its ISA is almost the superset of all
others. To reduce complexity, in QEMU we just define two CPU types:
1, "Loongson-3A100
From: Jiaxun Yang
Our current code assumed the target page size is always 4k
when handling PageMask and VPN2, however, variable page size
was just added to mips target and that's no longer true.
Fixes: ee3863b9d414 ("target/mips: Support variable page size")
Signed-off-by: Jiaxun Yang
Signed-of
When using -Wimplicit-fallthrough in our CFLAGS, the compiler showed warning:
../target/ppc/excp_helper.c: In function ‘powerpc_excp’:
../target/ppc/excp_helper.c:529:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
529 | msr |= env->error_code;
|
These lock types are unsupported by Linux since v2.2[0][1] and
always return EINVAL (except on SPARC up until v2.6, which just
warned).
musl libc does not define these constants, so just remove them from
the translation cases.
[0] https://github.com/mpe/linux-fullhistory/blob/v2.2.0/fs/locks.c#L3
In both cases, we can sink the write-back and perform
the accumulate into the normal destination temps.
Signed-off-by: Richard Henderson
---
target/arm/translate-neon.c.inc | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/target/arm/translate-neon.c.in
The only uses of this function are for loading VFP
double-precision values, and nothing to do with NEON.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 8 ++--
target/arm/translate-vfp.c.inc | 84 +-
2 files changed, 46 insertions(+), 46 de
On Tue, 27 Oct 2020 09:02:06 -0400
"Michael S. Tsirkin" wrote:
> On Tue, Oct 27, 2020 at 01:54:26PM +0100, Igor Mammedov wrote:
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> [...]
> > I have more questions wrt the suggestion/wor
Model these off the aa64 read/write_vec_element functions.
Use it within translate-neon.c.inc. The new functions do
not allocate or free temps, so this rearranges the calling
code a bit.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 26
target/arm/translate-neon.c
The only uses of this function are for loading VFP
single-precision values, and nothing to do with NEON.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 4 +-
target/arm/translate-vfp.c.inc | 184 -
2 files changed, 94 insertions(+), 94 del
On Tue, 27 Oct 2020 13:54:26 +0100
Igor Mammedov wrote:
> On Tue, 27 Oct 2020 07:26:44 -0400
> "Michael S. Tsirkin" wrote:
>
> [...]
> [...]
> [...]
> [...]
> [...]
> > >
> > > It certainly shouldn't wait an unbounded time. But a wait with timeout
> > > seems worth investigating t
This seems a bit more readable than using offsetof CPU_DoubleU.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 88a926d1df..88ded4ac2c 100644
--- a/
We can then use this to improve VMOV (scalar to gp) and
VMOV (gp to scalar) so that we simply perform the memory
operation that we wanted, rather than inserting or
extracting from a 32-bit quantity.
These were the last uses of neon_load/store_reg, so remove them.
Signed-off-by: Richard Henderson
We can use proper widening loads to extend 32-bit inputs,
and skip the "widenfn" step.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 6 +++
target/arm/translate-neon.c.inc | 66 ++---
2 files changed, 43 insertions(+), 29 deletions(-)
diff -
This function makes it clear that we're talking about the whole
register, and not the 32-bit piece at index 0. This fixes a bug
when running on a big-endian host.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 8 ++
target/arm/translate-neon.c.inc | 44 +
These are the only users of neon_reg_offset, so remove that.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index bf0b5cac61..88a926d1df 100644
--- a/t
Replace all uses of neon_load/store_reg64 within translate-neon.c.inc.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 26 +
target/arm/translate-neon.c.inc | 94 -
2 files changed, 73 insertions(+), 47 deletions(-)
diff --git a/tar
This will shortly have users outside of translate-neon.c.inc.
Signed-off-by: Richard Henderson
---
target/arm/translate.c | 20
target/arm/translate-neon.c.inc | 19 ---
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/target/arm/tran
Much of the existing usage of neon_reg_offset is broken for
big-endian hosts, as it computes the offset of the first
32-bit unit, not the offset of the entire vector register.
Fix this by separating out the different usages. Make the
whole thing look a bit more like the aarch64 code.
r~
Richa
A future libslirp update will use libresolv on Darwin systems, so we add the
flags in QEMU build now.
Signed-off-by: Joelle van Dyne
---
meson.build | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meson.build b/meson.build
index 0beb199303..2b45b9434d 100644
--- a/meson.build
+++ b/meson.b
macOS 11/iOS 14 added preadv/pwritev APIs. Due to weak linking, configure
will succeed with CONFIG_PREADV even when targeting a lower OS version. We
therefore need to check at run time if we can actually use these APIs.
Signed-off-by: Joelle van Dyne
---
block/file-posix.c | 12
1 f
The iOS toolchain does not use the host prefix naming convention. So we need
to enable cross-compile options while allowing the PREFIX to be blank.
Signed-off-by: Joelle van Dyne
---
configure | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 4
iOS does not support ucontext natively for aarch64 and the sigaltstack is
also unsupported (even worse, it fails silently, see:
https://openradar.appspot.com/13002712 )
As a workaround we include a library implementation of ucontext and add it
as a build option.
Signed-off-by: Joelle van Dyne
--
This introduces support for building for iOS hosts. When the correct Xcode
toolchain is used, iOS host will be detected automatically.
block: disable features not supported by iOS sandbox
slirp: disable SMB features for iOS
target: disable system() calls for iOS
tcg: use sys_icache_invalidate() in
Based-on: 20201026191540.12434-...@getutm.app
([PATCH RESEND 0/4] Mirror map JIT memory for TCG)
These set of changes brings QEMU TCG to iOS devices and future Apple Silicon
devices. They were originally developed last year and have been working in the
UTM app. Recently, we ported the changes to m
On iOS, we cannot allocate RWX pages without special entitlements. As a
workaround, we can allocate a RX region and then mirror map it to a separate
RX region. Then we can write to one region and execute from the other one.
When entitlements are available (macOS or jailbroken iOS), a hardware
feat
Some hosts (iOS) have a sandboxed filesystem and do not provide low-level
APIs for interfacing with host block devices.
Signed-off-by: Joelle van Dyne
---
configure | 4
meson.build| 1 +
block/file-posix.c | 8 +++-
3 files changed, 12 insertions(+), 1 deletion(-)
dif
On 2020/10/26 下午5:59, Peter Maydell wrote:
On Wed, 21 Oct 2020 at 10:23, P J P wrote:
+-- On Wed, 21 Oct 2020, Jason Wang wrote --+
| It should not be a guest error, since guest is allowed to send a packet
| other than IPV4(6).
* Ah...sigh! :(
* I very hesitantly used guest_error mask, sinc
This reverts the following commits due to their basis on a bogus
linux kernel header update:
c93a656f7b65 ("tests/acceptance: Add virtiofs_submounts.py")
45ced7ca2f27 ("tests/acceptance/boot_linux: Accept SSH pubkey")
08dce386e77e ("virtiofsd: Announce sub-mount points")
eba8b096c17c ("virtiofsd:
Hi Alistair,
On Wed, Oct 28, 2020 at 1:42 AM Alistair Francis wrote:
>
> On Tue, Oct 27, 2020 at 7:53 AM Bin Meng wrote:
> >
> > From: Bin Meng
> >
> > Somehow HSS needs to access address 0 [1] for the DDR calibration data
> > which is in the chipset's debug memory. Let's map the debug memory.
Hi Alistair,
On Wed, Oct 28, 2020 at 5:07 AM Alistair Francis wrote:
>
> On Tue, Oct 27, 2020 at 7:48 AM Bin Meng wrote:
> >
> > From: Bin Meng
> >
> > When system memory is larger than 1 GiB (high memory), PolarFire SoC
> > maps it at address 0x10__. Address 0xC000_ and above is
>
On Tue, 27 Oct 2020 23:42:57 +
Peter Maydell wrote:
> On Mon, 26 Oct 2020 at 19:39, Alex Williamson
> wrote:
> >
> > VFIO update 2020-10-26
> >
> > * Migration support (Kirti Wankhede)
> > * s390 DMA limiting (Matthew Rosato)
Hi Alistair,
On Wed, Oct 28, 2020 at 1:49 AM Alistair Francis wrote:
>
> On Tue, Oct 27, 2020 at 7:46 AM Bin Meng wrote:
> >
> > From: Bin Meng
> >
> > Connect DDR SGMII PHY module and CFG module to the PolarFire SoC.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > hw/riscv/Kconfig
Hi Niek,
On Wed, Oct 28, 2020 at 3:55 AM Niek Linnenbank
wrote:
>
> Hello Philippe, Bin,
>
> Thanks for your support on this. I've just tried this patch and unfortunately
> it doesn't seem to
> resolve the issue, at least on my machine. This is the output that I get when
> running the avocado t
Peter Maydell writes:
>> arm_ss.add(when: 'CONFIG_TCG', if_true: files ('common-semi.c'))
>> riscv_ss.add(files('common-semi.c'))
>>
>> This appears to work in my testing (building arm, risc-v and x86_64
>> configs).
>
> I'm not a kconfig expert but it might be preferable to have
Changelog:
v1 -> v2
- 1/2: Change function name to be more accurate
- 2/2: Dropped
Hi all,
The series fixes the behavior of the dummy cycle register for Numonyx flashes so
it's closer to how hardware behaves.
On hardware, the dummy cycles for fast read commands are set to a specific value
(8 o
Numonyx chips determine the number of cycles to wait based on bits 7:4 in the
volatile configuration register.
However, if these bits are 0x0 or 0xF, the number of dummy cycles to wait is
10 on a QIOR or QIOR4 command, or 8 on any other currently supported
fast read command. [1]
[1] https://www.m
On Mon, 26 Oct 2020 at 19:39, Alex Williamson
wrote:
>
> VFIO update 2020-10-26
>
> * Migration support (Kirti Wankhede)
> * s390 DMA limiting (Matthew Rosato)
> * zPCI hardware info (Matthew Rosato)
> * Lock guard (Amey Narkhede
On Tue, 27 Oct 2020 at 21:56, Keith Packard wrote:
>
> Peter Maydell writes:
>
> >> +specific_ss.add(when: 'CONFIG_TCG', if_true: files ('common-semi.c'))
> >
> > I think this adds this file to the compilation for all TCG targets;
> > you only want it for targets which have Arm-semihosting-ABI co
On Mon, 26 Oct 2020 at 19:09, Philippe Mathieu-Daudé wrote:
>
> The following changes since commit a46e72710566eea0f90f9c673a0f02da0064acce:
>
> Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201026' into stag=
> ing (2020-10-26 14:50:03 +)
>
> are available in the Git repository
Hi Francisco,
Comments marked with [Joe]
-Original Message-
From: Francisco Iglesias
Sent: Tuesday, October 20, 2020 6:50 AM
To: Joe Komlodi
Cc: qemu-devel@nongnu.org; alist...@alistair23.me; kw...@redhat.com;
mre...@redhat.com; qemu-bl...@nongnu.org
Subject: Re: [PATCH 1/2] hw/block/
Add python3.6 to the fedora container image: we need it to run the
linters against that explicit version to make sure we don't break our
minimum version promise. Add pipenv, too.
Signed-off-by: John Snow
---
.gitlab-ci.yml | 10 ++
tests/docker/dockerfiles/fedora.
Ignore build and package output (build, dist, qemu.egg-info);
effectively these are "in-tree" builds of a kind.
Ignore miscellaneous cached python confetti (__pycache__, *.pyc,
.mypy_cache).
Ignore .idea (pycharm) and .venv (pipenv et al).
Signed-off-by: John Snow
---
python/.gitignore | 9 +++
Try using pytest to manage our various tests; even though right now
they're only invoking binaries and not really running any python-native
code.
Create tests/, and add test_lint.py which calls out to mypy, flake8,
pylint and isort to enforce the standards in this directory.
Add pytest to the set
Following patches make obvious that we ought to ignore certain
directories to avoid wildly erroneous flake8 output.
Signed-off-by: John Snow
---
python/setup.cfg | 2 ++
1 file changed, 2 insertions(+)
diff --git a/python/setup.cfg b/python/setup.cfg
index cb696291ba38..d0ad683b5148 100644
---
based-on: <20201020193555.1493936-1-js...@redhat.com>
[PATCH v3 00/15] python: create installable package
This series serves as an addendum to the python package series; it adds
easy invocations for running the linters with the correct options for
the purposes of preventing regressions i
Add "make venv" to create the pipenv-managed virtual environment that
contains our explicitly pinned dependencies.
Add "make check" to run the python linters [in the host execution
environment].
Add "make venv-check" which combines the above two: create/update the
venv, then run the linters in th
On Fri, Oct 23, 2020 at 05:33:14PM +0200, Igor Mammedov wrote:
> On Wed, 21 Oct 2020 09:30:41 -0400
> Eduardo Habkost wrote:
[...]
> > I don't love object*_property_add_*_ptr() either. I consider the
> > qdev property API better. But we need a reasonable alternative,
> > because the qdev API can
When checking for allocation across a chain, it's already easy to
count the depth within the chain at which the allocation is found.
Instead of throwing that information away, return it to the caller.
Existing callers only cared about allocated/non-allocated, but having
a depth available will be us
'qemu-img map' provides a way to determine which extents of an image
come from the top layer vs. inherited from a backing chain. This is
useful information worth exposing over NBD. There is a proposal to
add a QMP command block-dirty-bitmap-populate which can create a dirty
bitmap that reflects a
Each dirty bitmap already knows its name; by reducing the scope of the
places where we construct "qemu:dirty-bitmap:NAME" strings, tracking
the name is more localized, and there are fewer per-export fields to
worry about. This in turn will make it easier for an upcoming patch
to export more than o
Ping O:-)
Looking for feedback from at least Cleber and Eduardo before I barge
ahead and send a PR to include this on master. Additional packaging and
versioning feedback from Dan would be nice.
(I know we have a very busy two weeks here; I will continue pinging, but
I have every intention o
Rather than open-code the count of negotiated contexts at several
sites, embed it directly into the struct. This will make it easier
for upcoming commits to support even more simultaneous contexts.
Signed-off-by: Eric Blake
Message-Id: <20201027050556.269064-7-ebl...@redhat.com>
Reviewed-by: Vla
block.c has a useful macro QAPI_LIST_ADD() for inserting at the front
of any QAPI-generated list; move it from block.c to qapi/util.h so
more places can use it, including one earlier place in block.c, and
rename it to something more obvious (since we also have a lot of
places that append, rather th
From: Max Reitz
nbd_server_start_unix_socket() includes an implicit nbd_server_stop(),
but we still need an explicit one at the end of the test (where there
follows no next nbd_server_start_unix_socket()), or qemu-nbd will linger
until the test exits.
This will become important when enabling thi
Since 'block-export-add' is new to 5.2, we can still tweak the
interface; there, allowing 'bitmaps':['str'] is nicer than
'bitmap':'str'. This wires up the qapi and qemu-nbd changes to permit
passing multiple bitmaps as distinct metadata contexts that the NBD
client may request, but the actual sup
Allow the server to expose an additional metacontext to be requested
by savvy clients. qemu-nbd adds a new option -A to expose the
qemu:allocation-depth metacontext through NBD_CMD_BLOCK_STATUS; this
can also be set via QMP when using block-export-add.
qemu as client is hacked into viewing the ke
From: Max Reitz
We need to let _img_info emit the format-specific information so we get
the list of bitmaps we want, but we do not need anything but the
bitmaps. So filter out everything that is irrelevant to us. (Ideally,
this would be a generalized function in common.filters that takes a list
Rather than open-coding the translation from the deprecated
NbdServerAddOptions type to the preferred BlockExportOptionsNbd, it's
better to utilize QAPI_CLONE_MEMBERS. This solves a couple of issues:
first, if we do any more refactoring of the base type (which an
upcoming patch plans to do), we do
With this, 'qemu-nbd -B b0 -B b1 -f qcow2 img.qcow2' can let you sniff
out multiple bitmaps from one server. qemu-img as client can still
only read one bitmap per client connection, but other NBD clients
(hello libnbd) can now read multiple bitmaps in a single pass.
Signed-off-by: Eric Blake
Rev
There is no need to rely on the verbosity of the gcc/clang compiler
extension of g_new(typeof(X), 1) when we can instead use the standard
g_malloc(sizeof(X)). In general, we like g_new over g_malloc for
returning type X rather than void* to let the compiler catch more
potential typing mistakes, bu
1 - 100 of 592 matches
Mail list logo
