From: "Ján Tomko" <jtomko@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org,
Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH 1/1] conf: qemu 9pfs: add 'multidevs' option
Date: Thu, 19 Mar 2020 14:10:26 +0100 [thread overview]
Message-ID: <20200319131026.GA2150275@lpt> (raw)
In-Reply-To: <E1jEFpL-00028n-Qj@lizzy.crudebyte.com>
[-- Attachment #1: Type: text/plain, Size: 4982 bytes --]
On a Tuesday in 2020, Christian Schoenebeck wrote:
>Introduce new 'multidevs' option for filesystem.
>
> <filesystem type='mount' accessmode='mapped' multidevs='remap'>
I don't like the 'multidevs' name, but cannot think of anything
beter.
'collisions' maybe?
> <source dir='/path'/>
> <target dir='mount_tag'>
> </filesystem>
>
>This option prevents misbheaviours on guest if a 9pfs export
>contains multiple devices, due to the potential file ID collisions
>this otherwise may cause.
>
>Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
>---
> docs/formatdomain.html.in | 47 ++++++++++++++++++++++++++++++++++-
> docs/schemas/domaincommon.rng | 10 ++++++++
> src/conf/domain_conf.c | 30 ++++++++++++++++++++++
> src/conf/domain_conf.h | 13 ++++++++++
> src/qemu/qemu_command.c | 7 ++++++
> 5 files changed, 106 insertions(+), 1 deletion(-)
Please split the XML changes from the qemu driver changes.
Also missing:
* qemu_capabilities addition
* qemuDomainDeviceDefValidateFS in qemu_domain.c - check for the capability,
reject this setting for virtiofs
* qemuxml2xmltest addition
* qemuxml2argvtest addition
(no changes required for virschematest - it checks all the XML files in
the directories used by the above tests against the schema)
>
>diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
>index 594146009d..13c506988b 100644
>--- a/docs/formatdomain.html.in
>+++ b/docs/formatdomain.html.in
>@@ -3967,7 +3967,7 @@
> <source name='my-vm-template'/>
> <target dir='/'/>
> </filesystem>
>- <filesystem type='mount' accessmode='passthrough'>
>+ <filesystem type='mount' accessmode='passthrough' multidevs='remap'>
> <driver type='path' wrpolicy='immediate'/>
> <source dir='/export/to/guest'/>
> <target dir='/import/from/host'/>
>@@ -4084,13 +4084,58 @@
> </dd>
> </dl>
>
>+ <p>
> <span class="since">Since 5.2.0</span>, the filesystem element
> has an optional attribute <code>model</code> with supported values
> "virtio-transitional", "virtio-non-transitional", or "virtio".
> See <a href="#elementsVirtioTransitional">Virtio transitional devices</a>
> for more details.
>+ </p>
>+
Unrelated change that can be split out.
>+ <p>
>+ The filesystem element has an optional attribute <code>multidevs</code>
>+ which specifies how to deal with a filesystem export containing more than
>+ one device, in order to avoid file ID collisions on guest when using 9pfs
>+ (<span class="since">since 6.2.0, requires QEMU 4.2</span>).
>+ This attribute is not available for virtiofs. The possible values are:
>+ </p>
>+
>+ <dl>
>+ <dt><code>default</code></dt>
>+ <dd>
>+ Use QEMU's default setting (which currently is <code>warn</code>).
>+ </dd>
>+ <dt><code>remap</code></dt>
>+ <dd>
>+ This setting allows guest to access multiple devices per export without
>+ encountering misbehaviours. Inode numbers from host are automatically
>+ remapped on guest to actively prevent file ID collisions if guest
>+ accesses one export containing multiple devices.
>+ </dd>
>+ <dt><code>forbid</code></dt>
>+ <dd>
>+ Only allow to access one device per export by guest. Attempts to access
>+ additional devices on the same export will cause the individual
>+ filesystem access by guest to fail with an error and being logged (once)
>+ as error on host side.
>+ </dd>
>+ <dt><code>warn</code></dt>
>+ <dd>
>+ This setting resembles the behaviour of 9pfs prior to QEMU 4.2, that is
>+ no action is performed to prevent any potential file ID collisions if an
>+ export contains multiple devices, with the only exception: a warning is
>+ logged (once) on host side now. This setting may lead to misbehaviours
>+ on guest side if more than one device is exported per export, due to the
>+ potential file ID collisions this may cause on guest side in that case.
>+ </dd>
>+ </dl>
>+
> </dd>
>
>+ <p>
>+ The <code>filesystem</code> element may contain the following subelements:
>+ </p>
>+
And so can this one.
> <dt><code>driver</code></dt>
> <dd>
> The optional driver element allows specifying further details
>@@ -25422,6 +25449,9 @@ virDomainFSDefFormat(virBufferPtr buf,
> virBufferAsprintf(buf, " model='%s'",
> virDomainFSModelTypeToString(def->model));
> }
>+ if (def->multidevs) {
>+ virBufferAsprintf(buf, " multidevs='%s'", multidevs);
>+ }
make syntax-check complains here:
Curly brackets around single-line body:
../src/conf/domain_conf.c:25452-25454:
if (def->multidevs) {
virBufferAsprintf(buf, " multidevs='%s'", multidevs);
}
Jano
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-03-19 13:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 16:38 [PATCH 0/1] add support for QEMU 9pfs 'multidevs' option Christian Schoenebeck
2020-03-17 13:59 ` [PATCH 1/1] conf: qemu 9pfs: add " Christian Schoenebeck
2020-03-19 13:10 ` Ján Tomko [this message]
2020-03-19 15:57 ` Christian Schoenebeck
2020-03-19 16:02 ` Daniel P. Berrangé
2020-03-19 16:19 ` Ján Tomko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200319131026.GA2150275@lpt \
--to=jtomko@redhat.com \
--cc=groug@kaod.org \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.