On Mon, Nov 15, 2021 at 12:52:00PM +0800, yadong...@intel.com wrote:
From: Yadong Qi
Add new virtio feature: VIRTIO_BLK_F_SECDISCARD.
Add new virtio command: VIRTIO_BLK_T_SECDISCARD.
Has a proposal been sent out yet to virtio-comment mailing list for
discussing these specification changes?
On Mon, Nov 15, 2021 at 12:52:00PM +0800, yadong...@intel.com wrote:
> From: Yadong Qi
>
> Add new virtio feature: VIRTIO_BLK_F_SECDISCARD.
> Add new virtio command: VIRTIO_BLK_T_SECDISCARD.
>
> This feature is disabled by default, it will check the backend
> bs->open_flags & BDRV_O_SECDISCARD,
Am 26.10.21 um 16:53 schrieb Peter Lieven:
Am 25.10.21 um 14:58 schrieb Kevin Wolf:
Am 25.10.2021 um 13:39 hat Peter Lieven geschrieben:
Am 16.09.21 um 14:34 schrieb Peter Lieven:
Am 09.07.21 um 12:21 schrieb Kevin Wolf:
Am 08.07.2021 um 20:23 hat Peter Lieven geschrieben:
Am 08.07.2021 um 1
On Thu, Nov 11, 2021 at 06:54:03PM +0100, Christian Schoenebeck wrote:
> On Donnerstag, 11. November 2021 17:31:52 CET Stefan Hajnoczi wrote:
> > On Wed, Nov 10, 2021 at 04:53:33PM +0100, Christian Schoenebeck wrote:
> > > On Mittwoch, 10. November 2021 16:14:19 CET Stefan Hajnoczi wrote:
> > > > O
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
Similar to the header split, also the function pointers in BlockDriver
can be split in I/O and global state.
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
include/block/block_int-common.h | 458
+/*
+ * I/O API functions. These functions are thread-safe, and therefore
+ * can run in any thread as long as the thread has called
+ * aio_context_acquire/release().
+ */
+
+int bdrv_replace_child_bs(BdrvChild *child, BlockDriverState *new_bs,
+ Error **errp);
Why is t
@@ -5958,6 +6043,7 @@ const char *bdrv_get_parent_name(const
BlockDriverState *bs)
/* TODO check what callers really want: bs->node_name or blk_name() */
const char *bdrv_get_device_name(const BlockDriverState *bs)
{
+ assert(qemu_in_main_thread());
return bdrv_get_parent_name(bs
Am 15.11.2021 um 05:51 hat yadong...@intel.com geschrieben:
> From: Yadong Qi
>
> Add a new option "secdiscard" for block drive. Parse it and
> record it in bs->open_flags as bit(BDRV_O_SECDISCARD).
>
> Add a new BDRV_REQ_SECDISCARD bit for secure discard request
> from virtual device.
>
> For
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
block.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/block.c b/block.c
index 94bff5c757..40c4729b8d 100644
--- a/block.c
+++ b/block.c
[
This is RFC because I'm unsure about the removal of
/* Reason: init() method uses drive_get_next() */
dc->user_creatable = false;
in PATCH 1. Both users appear to wire up some GPIO. If that's
necessary for the thing to work, we should just replace the comment.
Aside: there may be devic
drive_get_next() is basically a bad idea. It returns the "next" block
backend of a certain interface type. "Next" means bus=0,unit=N, where
subsequent calls count N up from zero, per interface type.
This lets you define unit numbers implicitly by execution order. If the
order changes, or new ca
ssi_sd_realize() creates an "sd-card" device. This is inappropriate,
and marked FIXME.
Move it to the boards that create these devices. Prior art: commit
eb4f566bbb for device "generic-sdhci", and commit 26c607b86b for
device "pl181".
Signed-off-by: Markus Armbruster
---
hw/arm/stellaris.c |
On 12.11.21 17:10, Vladimir Sementsov-Ogievskiy wrote:
11.11.2021 15:08, Hanna Reitz wrote:
In most of the block layer, especially when traversing down from other
BlockDriverStates, we assume that BdrvChild.bs can never be NULL. When
it becomes NULL, it is expected that the corresponding BdrvCh
Am 03.11.2021 um 23:01 hat Hao Wu geschrieben:
> 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.
Am 15.11.2021 um 06:31 hat Markus Armbruster geschrieben:
> Peter Maydell writes:
>
> > On Fri, 12 Nov 2021 at 13:34, Markus Armbruster wrote:
> >>
> >> Thomas Huth writes:
> >>
> >> > On 03/11/2021 09.41, Markus Armbruster wrote:
> >> >> Peter Maydell writes:
> >> >>
> >> >>> Does it make sen
On Mon, 15 Nov 2021 at 13:24, Kevin Wolf wrote:
> Same question as for Hao Wu's series: Wouldn't the proper solution be to
> add a drive property to the machine type?
>
> If you can't use -blockdev, it's not done right.
Is there an example of "doing it right" for built-in-to-the-machine
devices?
On Mon, 15 Nov 2021 at 12:55, Markus Armbruster wrote:
>
> drive_get_next() is basically a bad idea. It returns the "next" block
> backend of a certain interface type. "Next" means bus=0,unit=N, where
> subsequent calls count N up from zero, per interface type.
>
> This lets you define unit numb
On Mon, 15 Nov 2021 at 12:56, Markus Armbruster wrote:
>
> ssi_sd_realize() creates an "sd-card" device. This is inappropriate,
> and marked FIXME.
>
> Move it to the boards that create these devices. Prior art: commit
> eb4f566bbb for device "generic-sdhci", and commit 26c607b86b for
> device "
Peter Maydell writes:
> On Mon, 15 Nov 2021 at 12:55, Markus Armbruster wrote:
>>
>> drive_get_next() is basically a bad idea. It returns the "next" block
>> backend of a certain interface type. "Next" means bus=0,unit=N, where
>> subsequent calls count N up from zero, per interface type.
>>
>
Peter Maydell writes:
> On Mon, 15 Nov 2021 at 12:56, Markus Armbruster wrote:
>>
>> ssi_sd_realize() creates an "sd-card" device. This is inappropriate,
>> and marked FIXME.
>>
>> Move it to the boards that create these devices. Prior art: commit
>> eb4f566bbb for device "generic-sdhci", and
On 12.11.21 17:25, Vladimir Sementsov-Ogievskiy wrote:
11.11.2021 15:08, Hanna Reitz wrote:
See the comment for why this is necessary.
Signed-off-by: Hanna Reitz
---
tests/qemu-iotests/030 | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/030
On 11/15/21 13:55, Markus Armbruster wrote:
> drive_get_next() is basically a bad idea. It returns the "next" block
> backend of a certain interface type. "Next" means bus=0,unit=N, where
> subsequent calls count N up from zero, per interface type.
>
> This lets you define unit numbers implicitl
On Mon, 15 Nov 2021 at 12:55, Markus Armbruster wrote:
>
> This is RFC because I'm unsure about the removal of
>
> /* Reason: init() method uses drive_get_next() */
> dc->user_creatable = false;
>
> in PATCH 1. Both users appear to wire up some GPIO. If that's
> necessary for the thing t
On Mon, Nov 15, 2021 at 12:51:59PM +0800, yadong...@intel.com wrote:
> From: Yadong Qi
>
> Add a new option "secdiscard" for block drive. Parse it and
> record it in bs->open_flags as bit(BDRV_O_SECDISCARD).
>
> Add a new BDRV_REQ_SECDISCARD bit for secure discard request
> from virtual device.
On 15.11.21 13:48, Hanna Reitz wrote:
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
block.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/block.c b/block.c
index 94bff5c757..40c4729b8d
On Mon, Nov 15, 2021 at 12:52:00PM +0800, yadong...@intel.com wrote:
The Linux block layer shares the DISCARD queue limits with SECDISCARD.
That's different from BLKZEROOUT (QEMU's WRITE_ZEROES). This is a Linux
implementation detail but I guess virtio-blk can share the DISCARD
limits with SECDISC
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
include/block/block_int-common.h | 51
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/include/block/block_int-comm
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
block.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/block.c b/block.c
index 40c4729b8d..da80e89ad4 100644
--- a/block.c
+++ b/block.c
[...]
The following changes since commit 42f6c9179be4401974dd3a75ee72defd16b5092d:
Merge tag 'pull-ppc-2022' of https://github.com/legoater/qemu into
staging (2021-11-12 12:28:25 +0100)
are available in the Git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to fetch
From: Hanna Reitz
The children list is specific to BDS parents. We should not modify it
in the general children modification code, but let BDS parents deal with
it in their .attach() and .detach() methods.
This also has the advantage that a BdrvChild is removed from the
children list before its
From: Hanna Reitz
See the comment for why this is necessary.
Signed-off-by: Hanna Reitz
Message-Id: <2021120829.81329-11-hre...@redhat.com>
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/030 | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotes
From: Hanna Reitz
As of a future patch, bdrv_replace_child_tran() will take a BdrvChild **
pointer. Prepare for that by getting such a pointer and using it where
applicable, and (dereferenced) as a parameter for
bdrv_replace_child_tran().
Signed-off-by: Hanna Reitz
Message-Id: <2021120829.
From: Hanna Reitz
bdrv_cor_filter_drop() modifies the block graph. That means that other
parties can also modify the block graph before it returns. Therefore,
we cannot assume that the result of a graph traversal we did before
remains valid afterwards.
We should thus fetch `base` and `unfilter
From: Hanna Reitz
bdrv_attach_child_common_abort() restores the parent's AioContext. To
do so, the child (which was supposed to be attached, but is now detached
again by this abort handler) is added to the ignore list for the
AioContext changing functions.
However, since we modify a BDS's child
From: Stefan Hajnoczi
Reported by Coverity (CID 1465222).
Fixes: 4a1d937796de0fecd8b22d7dbebf87f38e8282fd ("softmmu/qdev-monitor: add
error handling in qdev_set_id")
Cc: Damien Hedde
Cc: Kevin Wolf
Cc: Michael S. Tsirkin
Signed-off-by: Stefan Hajnoczi
Message-Id: <20211102163342.31162-1-ste
From: Hanna Reitz
bdrv_replace_child_noperm() modifies BdrvChild.bs, and can potentially
set it to NULL. That is dangerous, because BDS parents generally assume
that their children's .bs pointer is never NULL. We therefore want to
let bdrv_replace_child_noperm() set the corresponding BdrvChild
From: Hanna Reitz
As of a future commit, bdrv_replace_child_noperm() will clear the
indirect BdrvChild pointer passed to it if the new child BDS is NULL.
bdrv_replace_child_tran() will want to let it do that, but revert this
change in its abort handler. For that, we need to have it receive a
Bdr
While introducing a non-QemuOpts code path for device creation for JSON
-device, we noticed that QMP device_add doesn't check its input
correctly (accepting arguments that should have been rejected), and that
users may be relying on this behaviour (libvirt did until it was fixed
recently).
Let's u
From: Hanna Reitz
Now that bdrv_remove_empty_child() no longer removes the child from the
parent's children list but only checks that it is not in such a list, it
is only a wrapper around bdrv_child_free() that checks that the child is
empty and unused. That should apply to all children that we
At the end of a reopen, we already call bdrv_refresh_limits(), which
should update bs->request_alignment according to the new file
descriptor. However, raw_probe_alignment() relies on s->needs_alignment
and just uses 1 if it isn't set. We neglected to update this field, so
starting with cache=write
From: Hanna Reitz
Invoke the transaction drivers' .clean() methods only after all
.commit() or .abort() handlers are done.
This makes it easier to have nested transactions where the top-level
transactions pass objects to lower transactions that the latter can
still use throughout their commit/ab
On Montag, 15. November 2021 12:54:32 CET Stefan Hajnoczi wrote:
> On Thu, Nov 11, 2021 at 06:54:03PM +0100, Christian Schoenebeck wrote:
> > On Donnerstag, 11. November 2021 17:31:52 CET Stefan Hajnoczi wrote:
> > > On Wed, Nov 10, 2021 at 04:53:33PM +0100, Christian Schoenebeck wrote:
> > > > On
From: Hanna Reitz
In most of the block layer, especially when traversing down from other
BlockDriverStates, we assume that BdrvChild.bs can never be NULL. When
it becomes NULL, it is expected that the corresponding BdrvChild pointer
also becomes NULL and the BdrvChild object is freed.
Therefore
Am 15.11.2021 um 14:31 hat Peter Maydell geschrieben:
> On Mon, 15 Nov 2021 at 13:24, Kevin Wolf wrote:
> > Same question as for Hao Wu's series: Wouldn't the proper solution be to
> > add a drive property to the machine type?
> >
> > If you can't use -blockdev, it's not done right.
>
> Is there
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
The job API will be handled separately in another serie.
Signed-off-by: Emanuele Giuseppe Esposito
Reviewed-by: Stefan Hajnoczi
---
include/qemu/job.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/qemu/job.
On 15.11.21 13:27, Emanuele Giuseppe Esposito wrote:
@@ -586,12 +589,14 @@ void bdrv_unapply_subtree_drain(BdrvChild
*child, BlockDriverState *old_parent)
void coroutine_fn bdrv_co_drain(BlockDriverState *bs)
{
assert(qemu_in_coroutine());
+ assert(qemu_in_main_thread());
bd
Peter Maydell writes:
> On Mon, 15 Nov 2021 at 13:24, Kevin Wolf wrote:
>> Same question as for Hao Wu's series: Wouldn't the proper solution be to
>> add a drive property to the machine type?
>>
>> If you can't use -blockdev, it's not done right.
>
> Is there an example of "doing it right" for
Kevin Wolf writes:
> Am 03.11.2021 um 23:01 hat Hao Wu geschrieben:
>> 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
>>p
Philippe Mathieu-Daudé writes:
> On 11/15/21 13:55, Markus Armbruster wrote:
>> drive_get_next() is basically a bad idea. It returns the "next" block
>> backend of a certain interface type. "Next" means bus=0,unit=N, where
>> subsequent calls count N up from zero, per interface type.
>>
>> Thi
Peter Maydell writes:
> On Mon, 15 Nov 2021 at 12:55, Markus Armbruster wrote:
>>
>> This is RFC because I'm unsure about the removal of
>>
>> /* Reason: init() method uses drive_get_next() */
>> dc->user_creatable = false;
>>
>> in PATCH 1. Both users appear to wire up some GPIO. If t
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
Currently, block layer APIs like block-backend.h contain a mix of
functions that are either running in the main loop and under the
BQL, or are thread-safe functions and run in iothreads performing I/O.
The functions running under BQL also take
On 15/11/2021 08.12, Alistair Francis wrote:
On Mon, Nov 15, 2021 at 3:32 PM Markus Armbruster wrote:
Peter Maydell writes:
On Fri, 12 Nov 2021 at 13:34, Markus Armbruster wrote:
Thomas Huth writes:
On 03/11/2021 09.41, Markus Armbruster wrote:
Peter Maydell writes:
Does it make s
On Mon, Nov 15, 2021 at 05:03:28PM +0100, Hanna Reitz wrote:
> On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote:
> > Currently, block layer APIs like block-backend.h contain a mix of
> > functions that are either running in the main loop and under the
> > BQL, or are thread-safe functions and ru
Hi; running a 'make check' on a clang sanitizer build one of
the iotests falls over due to a NULL pointer being passed to
memset():
TEST iotest-qcow2: nbd-qemu-allocation [fail]
QEMU --
"/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-clang/tests/qemu-iotests/../../qemu-system-a
On Sep 24 09:27, Klaus Jensen wrote:
> From: Klaus Jensen
>
> First patch from Hannes fixes the subsystem registration process such
> that shared (but non-detached) namespaces are automatically attached to
> hotplugged controllers.
>
> The second patch changes the default for 'shared' such that
From: "Richard W.M. Jones"
Under SELinux, Unix domain sockets have two labels. One is on the
disk and can be set with commands such as chcon(1). There is a
different label stored in memory (called the process label). This can
only be set by the process creating the socket. When using SELinux
On 11/15/21 3:53 PM, Kevin Wolf wrote:
The following changes since commit 42f6c9179be4401974dd3a75ee72defd16b5092d:
Merge tag 'pull-ppc-2022' of https://github.com/legoater/qemu into
staging (2021-11-12 12:28:25 +0100)
are available in the Git repository at:
git://repo.or.cz/qemu/ke
Hi Kevin,
On 11/15/21 15:53, Kevin Wolf wrote:
> The following changes since commit 42f6c9179be4401974dd3a75ee72defd16b5092d:
>
> Merge tag 'pull-ppc-2022' of https://github.com/legoater/qemu into
> staging (2021-11-12 12:28:25 +0100)
>
> are available in the Git repository at:
>
> git
On 11/15/21 16:57, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>> On 11/15/21 13:55, Markus Armbruster wrote:
>>> drive_get_next() is basically a bad idea. It returns the "next" block
>>> backend of a certain interface type. "Next" means bus=0,unit=N, where
>>> subsequent calls cou
On Mon, Nov 15, 2021 at 05:11:54PM +, Peter Maydell wrote:
> Hi; running a 'make check' on a clang sanitizer build one of
> the iotests falls over due to a NULL pointer being passed to
> memset():
>
>
> TEST iotest-qcow2: nbd-qemu-allocation [fail]
> +../../nbd/server.c:1027:16: runtime
clang's sanitizer is picky: memset(NULL, x, 0) is technically
undefined behavior, even though no sane implementation of memset()
deferences the NULL. Caught by the nbd-qemu-allocation iotest.
The alternative to checking before each memset is to instead force an
allocation of 1 element instead of
On 11/15/21 23:39, Eric Blake wrote:
> clang's sanitizer is picky: memset(NULL, x, 0) is technically
> undefined behavior, even though no sane implementation of memset()
> deferences the NULL. Caught by the nbd-qemu-allocation iotest.
>
> The alternative to checking before each memset is to inste
> >Add new virtio feature: VIRTIO_BLK_F_SECDISCARD.
> >Add new virtio command: VIRTIO_BLK_T_SECDISCARD.
>
> Has a proposal been sent out yet to virtio-comment mailing list for discussing
> these specification changes?
>
Not yet. I will draft a proposal to virtio-comment if no big concern of this
> On Mon, Nov 15, 2021 at 12:52:00PM +0800, yadong...@intel.com wrote:
> > From: Yadong Qi
> >
> > Add new virtio feature: VIRTIO_BLK_F_SECDISCARD.
> > Add new virtio command: VIRTIO_BLK_T_SECDISCARD.
> >
> > This feature is disabled by default, it will check the backend
> > bs->open_flags & BDRV_
>
> Notably absent: qapi/block-core.json. Without changing this, the option can't
> be
> available in -blockdev, which is the primary option to configure block device
> backends.
>
> This patch seems to contain multiple logical changes that should be split into
> separate patches:
>
> * Adding
> > Add a new option "secdiscard" for block drive. Parse it and record it
> > in bs->open_flags as bit(BDRV_O_SECDISCARD).
> >
> > Add a new BDRV_REQ_SECDISCARD bit for secure discard request from
> > virtual device.
> >
> > For host_device backend: implement by ioctl(BLKSECDISCARD) on real
> > hos
> The Linux block layer shares the DISCARD queue limits with SECDISCARD.
> That's different from BLKZEROOUT (QEMU's WRITE_ZEROES). This is a Linux
> implementation detail but I guess virtio-blk can share the DISCARD limits with
> SECDISCARD too...
>
> > @@ -622,6 +628,7 @@ static int virtio_blk_ha
On 15/11/2021 21.29, Eric Blake wrote:
From: "Richard W.M. Jones"
Under SELinux, Unix domain sockets have two labels. One is on the
disk and can be set with commands such as chcon(1). There is a
different label stored in memory (called the process label). This can
only be set by the process
Philippe Mathieu-Daudé writes:
> On 11/15/21 16:57, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>> On 11/15/21 13:55, Markus Armbruster wrote:
drive_get_next() is basically a bad idea. It returns the "next" block
backend of a certain interface type. "Next" means bus=0
69 matches
Mail list logo
