Re: [PATCH v2 0/6] hw/southbridge: QOM'ify vt82c686 as VT82C686B_SOUTHBRIDGE

2021-05-15 Thread BALATON Zoltan
On Sat, 15 May 2021, Philippe Mathieu-Daudé wrote: On 5/15/21 4:37 PM, BALATON Zoltan wrote: On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: On 5/13/21 1:54 PM, BALATON Zoltan wrote: On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: On 5/11/21 3:09 PM, BALATON Zoltan wrote: On Tue, 11 Ma

Re: [PATCH 6/7] linux-user: use GDateTime for formatting timestamp for core file

2021-05-15 Thread Laurent Vivier
Le 05/05/2021 à 12:37, Daniel P. Berrangé a écrit : > The GDateTime APIs provided by GLib avoid portability pitfalls, such > as some platforms where 'struct timeval.tv_sec' field is still 'long' > instead of 'time_t'. When combined with automatic cleanup, GDateTime > often results in simpler code t

Re: [PATCH v2 0/6] hw/southbridge: QOM'ify vt82c686 as VT82C686B_SOUTHBRIDGE

2021-05-15 Thread Philippe Mathieu-Daudé
On 5/15/21 4:37 PM, BALATON Zoltan wrote: > On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: >> On 5/13/21 1:54 PM, BALATON Zoltan wrote: >>> On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: On 5/11/21 3:09 PM, BALATON Zoltan wrote: > On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote:

[PATCH v2 02/12] hw/ide/Kconfig: Add missing dependency PCI -> IDE_QDEV

2021-05-15 Thread Philippe Mathieu-Daudé
The pci_ide_create_devs() function is declared i hw/ide/qdev.c: $ git grep ide_create_drive hw/ide/pci.c:491:ide_create_drive(d->bus + bus[i], unit[i], hd_table[i]); hw/ide/qdev.c:127:IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive) include/hw/ide/internal.h:6

Re: [PATCH v2 0/6] hw/southbridge: QOM'ify vt82c686 as VT82C686B_SOUTHBRIDGE

2021-05-15 Thread BALATON Zoltan
On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: On 5/13/21 1:54 PM, BALATON Zoltan wrote: On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote: On 5/11/21 3:09 PM, BALATON Zoltan wrote: On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote: Hi Zoltan, On 5/11/21 1:28 PM, BALATON Zoltan wrote: O

Re: [PATCH v5 0/9] Allow changing bs->file on reopen

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
15.05.2021 16:46, Vladimir Sementsov-Ogievskiy wrote: Hi all! Alberto, I'm sorry for not consulting with you about sending this. Actually, I wanted only one patch "block: Allow changing bs->file on reopen", as I'm going to send another series based on it. Haha. Actually I need instead a way t

[PATCH v5 1/9] block: introduce bdrv_remove_file_or_backing_child()

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
To be used for reopen in future commit. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/block.c b/block.c index 9ad725d205..75565ce4d4 100644 --- a/block.c +++ b/block.c @@ -4770,16 +4770,14 @@

[PATCH v5 9/9] iotests: Test replacing files with x-blockdev-reopen

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
From: Alberto Garcia This patch adds new tests in which we use x-blockdev-reopen to change bs->file Signed-off-by: Alberto Garcia --- tests/qemu-iotests/245 | 109 - tests/qemu-iotests/245.out | 11 +++- 2 files changed, 117 insertions(+), 3 deletions(-

[PATCH v5 4/9] block: bdrv_reopen_parse_backing(): don't check frozen child

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
bdrv_set_backing_noperm() takes care of it (actual check is in bdrv_set_file_or_backing_noperm()), so we don't need to check it here. While being here, improve error message a bit. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block.c| 14 +- tests/qemu-iotests/245

[PATCH v5 8/9] block: Allow changing bs->file on reopen

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
From: Alberto Garcia When the x-blockdev-reopen was added it allowed reconfiguring the graph by replacing backing files, but changing the 'file' option was forbidden. Because of this restriction some operations are not possible, notably inserting and removing block filters. This patch adds suppo

[PATCH v5 3/9] block: bdrv_reopen_parse_backing(): don't check aio context

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
We don't need this check: bdrv_set_backing_noperm() will do it anyway (actually in bdrv_attach_child_common()). Signed-off-by: Vladimir Sementsov-Ogievskiy --- block.c | 33 - 1 file changed, 33 deletions(-) diff --git a/block.c b/block.c index 5141c04815..4e18bc

[PATCH v5 6/9] block: move supports_backing check to bdrv_set_file_or_backing_noperm()

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
Move supports_backing check of bdrv_reopen_parse_backing to called (through bdrv_set_backing_noperm()) bdrv_set_file_or_backing_noperm() function. The check applies to general case, so it's appropriate for bdrv_set_file_or_backing_noperm(). We have to declare backing support for two test drivers,

[PATCH v5 7/9] block: BDRVReopenState: drop replace_backing_bs field

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
It's used only in bdrv_reopen_commit(). "backing" is covered by the loop through all children except for case when we removed backing child during reopen. Make it more obvious and drop extra boolean field: qdict_del will not fail if there is no such entry. Signed-off-by: Vladimir Sementsov-Ogievs

[PATCH v5 5/9] block: bdrv_reopen_parse_backing(): simplify handling implicit filters

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
The logic around finding overlay here is not obvious. Actually it does two simple things: 1. If new bs is already in backing chain, split from parent bs by several implicit filters we are done, do nothing. 2. Otherwise, don't try to replace implicit filter. Let's rewrite this in more obvious

[PATCH v5 2/9] block: introduce bdrv_set_file_or_backing_noperm()

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
To be used for reopen in future commit. Notes: - It seems OK to update inherits_from if new bs is recursively inherits from parent bs. Let's just not check for backing_chain_contains, to support file child of non-filters. - Simply check child->frozen instead of bdrv_is_backing_chain_frozen

[PATCH v5 0/9] Allow changing bs->file on reopen

2021-05-15 Thread Vladimir Sementsov-Ogievskiy
Hi all! Alberto, I'm sorry for not consulting with you about sending this. Actually, I wanted only one patch "block: Allow changing bs->file on reopen", as I'm going to send another series based on it. I started to work on updating this one patch it and it turned into a refactoring series below.

Re: [PATCH] fdc: check drive block device before usage (CVE-2021-20196)

2021-05-15 Thread Philippe Mathieu-Daudé
On 5/14/21 9:26 PM, John Snow wrote: > On 5/14/21 3:23 PM, Thomas Huth wrote: >> On 23/01/2021 11.03, P J P wrote: >>> From: Prasad J Pandit >>> >>> While processing ioport command in 'fdctrl_write_dor', device >>> controller may select a drive which is not initialised with a >>> block device. Thi

Re: [PATCH 5/6] co-shared-resource: protect with a mutex

2021-05-15 Thread Vladimir Sementsov-Ogievskiy via
15.05.2021 00:53, Emanuele Giuseppe Esposito wrote: we want to get from shres here, after possible call to block_copy_task_shrink(), as task->bytes may be reduced. Ah right, I missed that. So I guess if we want the caller to protect co-shared-resource, get_from_shres stays where it is, and