Pre-Christmas meeting of Kevin, Markus, and me ==============================================
Hi,
As we have done in some other years before, Kevin, Markus, and me got
together before Christmas (Dec 12, to be exact) and talked about a
couple of things concerning the block layer. These are the notes we
took, maybe you find them useful.
(Kevin, Markus, of course, if you find something wrong or amiss,
please correct me :-))
The -drive story
----------------
We want deprecate it, or at least parts of it. How?
Markus made some analysis of the existing -drive options and their
replacements. A few parts could be deprecated now (including if=none,
which is probably the most irregular configuration compared to
-blockdev/-device).
We know that at least SD card support is still missing before we have
a full replacement of -drive.
Should we consider a file=backend:<node-name> syntax where -drive
configures only the frontend part that cannot be configured with
-device/-machine, but refers to a node-name created with -blockdev?
Might be simpler than actually converting all those boards we don’t
care about, but obviously would leave a stub -drive behind instead of
fully getting rid of it.
How much work is deprecating -drive actually worth? Or in other words:
How much does it get in the way when we want to do new things?
Apparently quite a bit, though removing it only partially would be a
daunting task, too. We might have to deprecate it fully and then
replace with something simpler.
qemu-storage-daemon
-------------------
Next steps:
1. Split off monitor changes that make sense on their own and send
them to Markus so they can be merged before the rest.
2. QAPIfy --monitor command line option: Trivial (turn the options
into a QAPI struct type, run a keyval visitor on the input to parse
it)
3. QAPIfy --object command line option: Not much to be done there
because we’re unlikely to ever get a schema for QOM things (in part
because it has dynamic properties), so we also don’t get QAPI C types.
Instead, just change object-add to accept flat input (in QDict
form) to make it nicely usable on the command line and then call
qmp_object_add() from the storage daemon’s command line parser.
4. QAPIfy --chardev command line option: This one requires probably
the most work because it’s complex, but actually described by a
schema. The existing chardev-add options are deeply nested and
nasty to use on the command line. Some flattening needed.
Markus is going to have a look at flattening simple unions, which
is a more general problem in existing QAPI interfaces, and will be
needed in more places for a fully QAPIfied QEMU command line
parser.
block-stream as concerned by the “Deal with filters” series
-----------------------------------------------------------
Our discussion was centered around what edges block-stream should
freeze and what base nodes actually make sense.
Using a filter as the base is fine, as long as the job then streams
from the first COW overlay on top (AFAIR this is what the series’s
current version does). Otherwise, everything would be copied from the
filter, and this includes all data allocated in the first non-filter
below the base (the filter). It then wouldn’t make sense to keep that
non-filter around.
All in all, what the series currently does is fine (i.e. freezing
everything directly above the base, even if that node above the base
is a filter, too). The actual problem is probably that the stream job
shouldn’t have taken a @base parameter, but @above-base instead (from
the start). Now the damage is done and we just need to document how
all of this works (i.e., that the job looks for the node directly
above @base, and that this node is then going to be the backing node
of @top when the job settles).
QOM
---
„Ganz schrecklich.“ (Very terrible.)
(Not least the situation regarding documentation and help.)
QemuOpts
--------
See →QOM.
Asynchronous execution of synchronous block QMP commands
--------------------------------------------------------
(like block_resize)
Block layer QMP commands often do I/O while holding the BQL,
potentially blocking the guest. This is a similar problem to what
Marc-André tried to solve with his async QMP commands (and which
Markus failed to review so far because it’s a too long series).
After discussion that executing stuff in a coroutine would solve the
problem for block layer commands almost automatically, I [Kevin]
hacked up a prototype to do just that. It seemed to do its job (though
it needs to be conditional because you can’t run everything in a
coroutine, so some work left to do) and looked much simpler than the
async QMP commands series. It should be easily usable for screendump
(Marc-André’s problem), too.
Asked Marc-André about the approach and he told me [Kevin] he’d look
into it.
Incomplete handling of inactive/unavailable nodes
-------------------------------------------------
1. How can be prevent execution of certain QMP commands on inactive
BDSs? Probably not at all, we may have to just have to check
INACTIVE everywhere (possibly with a new function checking that the
BDS is usable, including !INACTIVE).
Alternative ideas:
- Setting RO: Requires a reopen on switch-over, which may fail
- Unsharing the WRITE permission: Does not work, because the
permissions are enforced outside of the current qemu instance
through file locks. The source VM still has and needs a WRITE
permission, though, so we cannot let anything on the destination
unshare it.
2. We still have BDS.drv == NULL. We’ve wanted to add an “error”
driver for quite some time that returns -EIO to everything. (We’d
then replace all errored nodes (where BDS.drv = NULL is set) by
such an error node).
Query function situation
------------------------
Well, it kind of works right now. Perhaps we’d like a variant of
bdrv-query-named-nodes that just queries a single node and returns
something nicely structured (i.e. a BlockdevOptions object with
references to child nodes).
OTOH, as long as noone complains, is it really important?
Misc
----
The Wiki’s TODO list is horribly outdated. What should we do about
it? Maybe archive it and start a new one? (Most of the things on the
current list are either done or we don’t want to do anymore.)
signature.asc
Description: OpenPGP digital signature
