Re: [PATCH v3 0/3] qapi & doc: deprecate drive-backup

2021-11-03 Thread Markus Armbruster
Vladimir Sementsov-Ogievskiy writes: > Hi all! > > See 03 commit message for details. 01-02 are preparation docs update. > > v3: wording fix-ups and improvements suggested by Kashyap > v2: add a lot of documentation changes > v1 was "[PATCH] qapi: deprecate drive-backup" > > > Note, that this ser

[PATCH v4 4/7] hw/adc: Make adci[*] R/W in NPCM7XX ADC

2021-11-03 Thread Hao Wu
Our sensor test requires both reading and writing from a sensor's QOM property. So we need to make the input of ADC module R/W instead of write only for that to work. Signed-off-by: Hao Wu Reviewed-by: Titus Rwantare Reviewed-by: Peter Maydell --- hw/adc/npcm7xx_adc.c | 2 +- 1 file changed, 1

[PATCH v4 5/7] blockdev: Add a new IF type IF_OTHER

2021-11-03 Thread Hao Wu
This type is used to represent block devs that are not suitable to be represented by other existing types. Signed-of-by: Hao Wu --- blockdev.c| 3 ++- include/sysemu/blockdev.h | 1 + meson | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a

[PATCH v4 7/7] hw/arm: quanta-gbs-bmc add i2c devices

2021-11-03 Thread Hao Wu
From: Patrick Venture Adds supported i2c devices to the quanta-gbc-bmc board. Signed-off-by: Patrick Venture Reviewed-by: Hao Wu --- hw/arm/npcm7xx_boards.c | 82 - 1 file changed, 49 insertions(+), 33 deletions(-) diff --git a/hw/arm/npcm7xx_boards.c

[PATCH v4 3/7] hw/adc: Fix CONV bit in NPCM7XX ADC CON register

2021-11-03 Thread Hao Wu
The correct bit for the CONV bit in NPCM7XX ADC is bit 13. This patch fixes that in the module, and also lower the IRQ when the guest is done handling an interrupt event from the ADC module. Signed-off-by: Hao Wu Reviewed-by: Patrick Venture Reviewed-by: Peter Maydell --- hw/adc/npcm7xx_adc.c

[PATCH v4 6/7] hw/nvram: Update at24c EEPROM init function in NPCM7xx boards

2021-11-03 Thread Hao Wu
We made 3 changes to the at24c_eeprom_init function in npcm7xx_boards.c: 1. We allow the function to take a I2CBus* as parameter. This allows us to attach an EEPROM device behind an I2C mux which is not possible with the old method. 2. We make at24c EEPROMs are backed by drives so that we c

[PATCH v4 2/7] hw/i2c: Read FIFO during RXF_CTL change in NPCM7XX SMBus

2021-11-03 Thread Hao Wu
Originally we read in from SMBus when RXF_STS is cleared. However, the driver clears RXF_STS before setting RXF_CTL, causing the SM bus module to read incorrect amount of bytes in FIFO mode when the number of bytes read changed. This patch fixes this issue. Signed-off-by: Hao Wu Reviewed-by: Titu

[PATCH v4 1/7] hw/i2c: Clear ACK bit in NPCM7xx SMBus module

2021-11-03 Thread Hao Wu
The ACK bit in NPCM7XX SMBus module should be cleared each time it sends out a NACK signal. This patch fixes the bug that it fails to do so. Signed-off-by: Hao Wu Reviewed-by: Titus Rwantare Reviewed-by: Peter Maydell --- hw/i2c/npcm7xx_smbus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

[PATCH v4 0/7] Misc NPCM7XX patches

2021-11-03 Thread Hao Wu
This patch set contains a few bug fixes and I2C devices for some NPCM7XX boards. Patch 1~2 fix a problem that causes the SMBus module to behave incorrectly when it's in FIFO mode and trying to receive more than 16 bytes at a time. Patch 3 fixes a error in a register for ADC module. Patch 4 makes

Re: [PATCH v1] job.c: add missing notifier initialization

2021-11-03 Thread Philippe Mathieu-Daudé
On 11/3/21 17:21, Emanuele Giuseppe Esposito wrote: > It seems that on_idle list is not properly initialized like > the other notifiers. > Cc: qemu-sta...@nongnu.org Fixes: 34dc97b9a0e ("blockjob: Wake up BDS when job becomes idle") > Signed-off-by: Emanuele Giuseppe Esposito > --- > job.c | 1

[PATCH v1] job.c: add missing notifier initialization

2021-11-03 Thread Emanuele Giuseppe Esposito
It seems that on_idle list is not properly initialized like the other notifiers. Signed-off-by: Emanuele Giuseppe Esposito --- job.c | 1 + 1 file changed, 1 insertion(+) diff --git a/job.c b/job.c index dbfa67bb0a..54db80df66 100644 --- a/job.c +++ b/job.c @@ -352,6 +352,7 @@ void *job_create(

Re: [RFC PATCH 11/15] jobs: remove aiocontext locks since the functions are under BQL

2021-11-03 Thread Emanuele Giuseppe Esposito
On 02/11/2021 13:41, Vladimir Sementsov-Ogievskiy wrote: Hmm. subject looks like it's safe to remove aiocontext locks from any qmp command? For example, commit 91005a495e228eb added aiocontext locks back to qmp bitmap add/remove commands because otherwise they crashed. So, I'm not sure th

[PATCH v3 2/3] docs/interop/bitmaps: use blockdev-backup

2021-11-03 Thread Vladimir Sementsov-Ogievskiy
We are going to deprecate drive-backup, so use modern interface here. In examples where target image creation is shown, show blockdev-add as well. If target creation omitted, omit blockdev-add as well. Reviewed-by: Kashyap Chamarthy Signed-off-by: Vladimir Sementsov-Ogievskiy --- docs/interop/b

[PATCH v3 3/3] qapi: deprecate drive-backup

2021-11-03 Thread Vladimir Sementsov-Ogievskiy
Modern way is using blockdev-add + blockdev-backup, which provides a lot more control on how target is opened. As example of drive-backup problems consider the following: User of drive-backup expects that target will be opened in the same cache and aio mode as source. Corresponding logic is in dr

[PATCH v3 0/3] qapi & doc: deprecate drive-backup

2021-11-03 Thread Vladimir Sementsov-Ogievskiy
Hi all! See 03 commit message for details. 01-02 are preparation docs update. v3: wording fix-ups and improvements suggested by Kashyap v2: add a lot of documentation changes v1 was "[PATCH] qapi: deprecate drive-backup" Note, that this series lack deprecating drive-backup transaction action. T

[PATCH v3 1/3] docs/block-replication: use blockdev-backup

2021-11-03 Thread Vladimir Sementsov-Ogievskiy
We are going to deprecate drive-backup, so don't mention it here. Moreover, blockdev-backup seems more correct in the context. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: John Snow --- docs/block-replication.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v3 00/17] iotests: support zstd

2021-11-03 Thread Vladimir Sementsov-Ogievskiy
02.11.2021 15:29, Kevin Wolf wrote: Am 17.09.2021 um 20:06 hat Vladimir Sementsov-Ogievskiy geschrieben: 17.09.2021 17:49, Hanna Reitz wrote: On 15.09.21 16:45, Hanna Reitz wrote: On 14.09.21 12:25, Vladimir Sementsov-Ogievskiy wrote: These series makes tests pass with     IMGOPTS='compress

Re: [PATCH 10/15] hw/nvme: Make max_ioqpairs and msix_qsize configurable in runtime

2021-11-03 Thread Klaus Jensen
On Oct 21 15:40, Łukasz Gieryk wrote: > On Wed, Oct 20, 2021 at 09:06:06PM +0200, Klaus Jensen wrote: > > On Oct 7 18:24, Lukasz Maniak wrote: > > > From: Łukasz Gieryk > > > > > > The Nvme device defines two properties: max_ioqpairs, msix_qsize. Having > > > them as constants is problematic for

Re: [PATCH 12/15] hw/nvme: Initialize capability structures for primary/secondary controllers

2021-11-03 Thread Klaus Jensen
On Oct 7 18:24, Lukasz Maniak wrote: > From: Łukasz Gieryk > > With two new properties (sriov_max_vi_per_vf, sriov_max_vq_per_vf) one > can configure the maximum number of virtual queues and interrupts > assignable to a single virtual device. The primary and secondary > controller capability str

Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

2021-11-03 Thread Stefan Hajnoczi
On Mon, Nov 01, 2021 at 09:29:26PM +0100, Christian Schoenebeck wrote: > On Donnerstag, 28. Oktober 2021 11:00:48 CET Stefan Hajnoczi wrote: > > On Mon, Oct 25, 2021 at 05:03:25PM +0200, Christian Schoenebeck wrote: > > > On Montag, 25. Oktober 2021 12:30:41 CEST Stefan Hajnoczi wrote: > > > > On T

Re: does drive_get_next(IF_NONE) make sense?

2021-11-03 Thread Thomas Huth
On 03/11/2021 09.41, Markus Armbruster wrote: Peter Maydell writes: Does it make sense for a device/board to do drive_get_next(IF_NONE) ? Short answer: hell, no! ;) Would it make sense to add an "assert(type != IF_NONE)" to drive_get() to avoid such mistakes in the future? Thomas

Re: does drive_get_next(IF_NONE) make sense?

2021-11-03 Thread Markus Armbruster
Peter Maydell writes: > Does it make sense for a device/board to do drive_get_next(IF_NONE) ? Short answer: hell, no! ;) Long answer below. > At the moment we have exactly one user of this, which is > hw/misc/sifive_u_otp.c. This is a model of a one-time-programmable > fuse, and the drive is