This is v7 of a proposed patch set for fixing file ID collisions with 9pfs.

v6->v7:

  * Rebased to https://github.com/gkurz/qemu/commits/9p-next
    (SHA1 7fc4c49e91).

  * Be pedantic and abort with error on wrong value for new command line
    argument 'multidevs'.

  * Adjusted patches to qemu code style guidelines.

  * Fixed potential crash in qp_table_destroy() on error path.

  * Use dedicated hash table init functions (qpd_table_init(),
    qpf_table_init(), qpp_table_init()):
    https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00144.html

  * Use warn_report_once() instead of error_report_once() for issues
    interpreted merely as being warnings, not errors.

  * Simplified hash table destruction (due to simplified error path
    introduced by SHA1 7fc4c49e91).

  * Dropped capturing root_ino for now:
    https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00146.html

  * Don't update proxy docs, since new command line argument 'multidevs' is
    limited to the local backend for now.

  * Mention in docs that readdir() is currently not blocked by
    'multidevs=forbid'.

  * Rename qid_path_prefixmap() -> qid_path_suffixmap() in patch 3
    (due to the semantic change of that function by that patch).

Christian Schoenebeck (3):
  9p: Added virtfs option 'multidevs=remap|forbid|warn'
  9p: stat_to_qid: implement slow path
  9p: Use variable length suffixes for inode remapping

 fsdev/file-op-9p.h      |   5 +
 fsdev/qemu-fsdev-opts.c |   7 +-
 fsdev/qemu-fsdev.c      |  17 ++
 hw/9pfs/9p.c            | 456 ++++++++++++++++++++++++++++++++++++++--
 hw/9pfs/9p.h            |  59 ++++++
 qemu-options.hx         |  26 ++-
 vl.c                    |   7 +-
 7 files changed, 552 insertions(+), 25 deletions(-)

-- 
2.20.1

On Thu, 5 Sep 2019 12:42:01 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> This is v7 of a proposed patch set for fixing file ID collisions with 9pfs.
> 

So I did some changes in 1/3 and pushed everything to 9p-next. I'll do some
more manual testing and issue a PR when I'm confident enough.

It would be nice to have some sort of automated test for that in 'make check'.
My first thought is to simulate a cross-device setup with the synth backend,
because it might be difficult to do this on a real filesystem without requiring
elevated privileges.

> v6->v7:
> 
>   * Rebased to https://github.com/gkurz/qemu/commits/9p-next
>     (SHA1 7fc4c49e91).
> 
>   * Be pedantic and abort with error on wrong value for new command line
>     argument 'multidevs'.
> 
>   * Adjusted patches to qemu code style guidelines.
> 
>   * Fixed potential crash in qp_table_destroy() on error path.
> 
>   * Use dedicated hash table init functions (qpd_table_init(),
>     qpf_table_init(), qpp_table_init()):
>     https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00144.html
> 
>   * Use warn_report_once() instead of error_report_once() for issues
>     interpreted merely as being warnings, not errors.
> 
>   * Simplified hash table destruction (due to simplified error path
>     introduced by SHA1 7fc4c49e91).
> 
>   * Dropped capturing root_ino for now:
>     https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00146.html
> 
>   * Don't update proxy docs, since new command line argument 'multidevs' is
>     limited to the local backend for now.
> 
>   * Mention in docs that readdir() is currently not blocked by
>     'multidevs=forbid'.
> 
>   * Rename qid_path_prefixmap() -> qid_path_suffixmap() in patch 3
>     (due to the semantic change of that function by that patch).
> 
> Christian Schoenebeck (3):
>   9p: Added virtfs option 'multidevs=remap|forbid|warn'
>   9p: stat_to_qid: implement slow path
>   9p: Use variable length suffixes for inode remapping
> 
>  fsdev/file-op-9p.h      |   5 +
>  fsdev/qemu-fsdev-opts.c |   7 +-
>  fsdev/qemu-fsdev.c      |  17 ++
>  hw/9pfs/9p.c            | 456 ++++++++++++++++++++++++++++++++++++++--
>  hw/9pfs/9p.h            |  59 ++++++
>  qemu-options.hx         |  26 ++-
>  vl.c                    |   7 +-
>  7 files changed, 552 insertions(+), 25 deletions(-)
> 

On Freitag, 13. September 2019 19:01:57 CEST Greg Kurz wrote:
> So I did some changes in 1/3 and pushed everything to 9p-next. 

I've reviewed your changes. Some notes:

Patch 1:
https://github.com/gkurz/qemu/commit/9295011c5a961603959b966c8aa6ad9840fe6db2

* Typo 1:

	error_append_hint(&local_err, "Valide options are: multidevs="

	Valide -> Valid

* Typo 2 in log comment:

	[groug: - Moved "multidevs" parsing the local backend.
	->
	[groug: - Moved "multidevs" parsing to the local backend.

> I'll do some
> more manual testing and issue a PR when I'm confident enough.

That would be highly appreciated! So far I am the only one ever having tested 
this patch set at all!

> It would be nice to have some sort of automated test for that in 'make
> check'. My first thought is to simulate a cross-device setup with the synth
> backend, because it might be difficult to do this on a real filesystem
> without requiring elevated privileges.

Hmm, since I neither haven't used the synth backend before, nor added qemu 
test cases so far, I am yet missing the complete picture here. My initial 
suggested approach would have been using loopback devices for simulating two 
file systems, but yes that's probably not viable due to required permissions. 
How would the synth backend help here? I mean you would need to simulate 
specific inode numbers and device numbers in some way for the test cases.

On Mon, 23 Sep 2019 11:50:46 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Freitag, 13. September 2019 19:01:57 CEST Greg Kurz wrote:
> > So I did some changes in 1/3 and pushed everything to 9p-next. 
> 
> I've reviewed your changes. Some notes:
> 
> Patch 1:
> https://github.com/gkurz/qemu/commit/9295011c5a961603959b966c8aa6ad9840fe6db2
> 
> * Typo 1:
> 
> 	error_append_hint(&local_err, "Valide options are: multidevs="
> 
> 	Valide -> Valid
> 
> * Typo 2 in log comment:
> 
> 	[groug: - Moved "multidevs" parsing the local backend.
> 	->
> 	[groug: - Moved "multidevs" parsing to the local backend.
> 

Fixed.

> > I'll do some
> > more manual testing and issue a PR when I'm confident enough.
> 
> That would be highly appreciated! So far I am the only one ever having tested 
> this patch set at all!
> 

Just to clarify, I won't thoroughly test it. My main concern is that it
doesn't break things. I usually rely on this:

https://www.tuxera.com/community/posix-test-suite/

> > It would be nice to have some sort of automated test for that in 'make
> > check'. My first thought is to simulate a cross-device setup with the synth
> > backend, because it might be difficult to do this on a real filesystem
> > without requiring elevated privileges.
> 
> Hmm, since I neither haven't used the synth backend before, nor added qemu 
> test cases so far, I am yet missing the complete picture here. My initial 
> suggested approach would have been using loopback devices for simulating two 
> file systems, but yes that's probably not viable due to required permissions. 
> How would the synth backend help here? I mean you would need to simulate 
> specific inode numbers and device numbers in some way for the test cases.
> 


The synth backend allows to simulate anything you want, provided you
code it of course :)

It is currently used to run some 9p protocol conformance tests. Have a
look at the backend code to get the idea.

hw/9pfs/9p-synth.h
hw/9pfs/9p-synth.c

and the test program:

tests/virtio-9p-test.c

It currently doesn't care for st_dev/st_ino at all, but I guess
it shouldn't be that hard to add the necessary bits.

> 
> 

On Montag, 23. September 2019 14:56:11 CEST Greg Kurz wrote:
> On Mon, 23 Sep 2019 11:50:46 +0200
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Freitag, 13. September 2019 19:01:57 CEST Greg Kurz wrote:
> > > So I did some changes in 1/3 and pushed everything to 9p-next.
> > 
> > I've reviewed your changes. Some notes:
> > 
> > Patch 1:
> > https://github.com/gkurz/qemu/commit/9295011c5a961603959b966c8aa6ad9840fe6
> > db2> 
> > * Typo 1:
> > 	error_append_hint(&local_err, "Valide options are: multidevs="
> > 	
> > 	Valide -> Valid
> > 
> > * Typo 2 in log comment:
> > 	[groug: - Moved "multidevs" parsing the local backend.
> > 	->
> > 	[groug: - Moved "multidevs" parsing to the local backend.
> 
> Fixed.

Thanks! Saw it, looks fine now.

> > > I'll do some
> > > more manual testing and issue a PR when I'm confident enough.
> > 
> > That would be highly appreciated! So far I am the only one ever having
> > tested this patch set at all!
> 
> Just to clarify, I won't thoroughly test it. My main concern is that it
> doesn't break things. 

So in other words you are only going to test the default behaviour
--multidevs=warn?

If yes, and since that would mean I was the only person ever having tested the 
actual fix, shouldn't --multidevs=remap|forbid better be marked as 
experimental (docs and runtime warning) for now? Maybe that would also 
anticipate receiving feedback from people actually using it later on.

> I usually rely on this:
> 
> https://www.tuxera.com/community/posix-test-suite/

Well, that website is far from being too verbose of what that test suite 
actually encompasses.

> > > It would be nice to have some sort of automated test for that in 'make
> > > check'. My first thought is to simulate a cross-device setup with the
> > > synth
> > > backend, because it might be difficult to do this on a real filesystem
> > > without requiring elevated privileges.
> > 
> > Hmm, since I neither haven't used the synth backend before, nor added qemu
> > test cases so far, I am yet missing the complete picture here. My initial
> > suggested approach would have been using loopback devices for simulating
> > two file systems, but yes that's probably not viable due to required
> > permissions. How would the synth backend help here? I mean you would need
> > to simulate specific inode numbers and device numbers in some way for the
> > test cases.
> The synth backend allows to simulate anything you want, provided you
> code it of course :)
> 
> It is currently used to run some 9p protocol conformance tests. Have a
> look at the backend code to get the idea.
> 
> hw/9pfs/9p-synth.h
> hw/9pfs/9p-synth.c
> 
> and the test program:
> 
> tests/virtio-9p-test.c
> 
> It currently doesn't care for st_dev/st_ino at all, but I guess
> it shouldn't be that hard to add the necessary bits.

I see. Well, I will look at it, but that will definitely not be one of my 
current high priority tasks that would happen in the next few weeks (simply 
due to my work load).

On Mon, 23 Sep 2019 16:06:13 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Montag, 23. September 2019 14:56:11 CEST Greg Kurz wrote:
> > On Mon, 23 Sep 2019 11:50:46 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > On Freitag, 13. September 2019 19:01:57 CEST Greg Kurz wrote:
> > > > So I did some changes in 1/3 and pushed everything to 9p-next.
> > > 
> > > I've reviewed your changes. Some notes:
> > > 
> > > Patch 1:
> > > https://github.com/gkurz/qemu/commit/9295011c5a961603959b966c8aa6ad9840fe6
> > > db2> 
> > > * Typo 1:
> > > 	error_append_hint(&local_err, "Valide options are: multidevs="
> > > 	
> > > 	Valide -> Valid
> > > 
> > > * Typo 2 in log comment:
> > > 	[groug: - Moved "multidevs" parsing the local backend.
> > > 	->
> > > 	[groug: - Moved "multidevs" parsing to the local backend.
> > 
> > Fixed.
> 
> Thanks! Saw it, looks fine now.
> 
> > > > I'll do some
> > > > more manual testing and issue a PR when I'm confident enough.
> > > 
> > > That would be highly appreciated! So far I am the only one ever having
> > > tested this patch set at all!
> > 
> > Just to clarify, I won't thoroughly test it. My main concern is that it
> > doesn't break things. 
> 
> So in other words you are only going to test the default behaviour
> --multidevs=warn?
> 

This I've already done, along with multidevs=forbid.

Now I plan to run the PJD test suite from Tuxera with a simple
cross-device setup and --multidevs=remap. And that's it.

> If yes, and since that would mean I was the only person ever having tested the 
> actual fix, shouldn't --multidevs=remap|forbid better be marked as 
> experimental (docs and runtime warning) for now? Maybe that would also 
> anticipate receiving feedback from people actually using it later on.
> 

Makes sense. I don't think it is worth having a runtime warning,
but I'll turn remap to x-remap and amend the docs.

> > I usually rely on this:
> > 
> > https://www.tuxera.com/community/posix-test-suite/
> 
> Well, that website is far from being too verbose of what that test suite 
> actually encompasses.
> 

Yeah... this does a variety of tests I've never had time to
audit, but it exercices many paths of the 9pfs code.

> > > > It would be nice to have some sort of automated test for that in 'make
> > > > check'. My first thought is to simulate a cross-device setup with the
> > > > synth
> > > > backend, because it might be difficult to do this on a real filesystem
> > > > without requiring elevated privileges.
> > > 
> > > Hmm, since I neither haven't used the synth backend before, nor added qemu
> > > test cases so far, I am yet missing the complete picture here. My initial
> > > suggested approach would have been using loopback devices for simulating
> > > two file systems, but yes that's probably not viable due to required
> > > permissions. How would the synth backend help here? I mean you would need
> > > to simulate specific inode numbers and device numbers in some way for the
> > > test cases.
> > The synth backend allows to simulate anything you want, provided you
> > code it of course :)
> > 
> > It is currently used to run some 9p protocol conformance tests. Have a
> > look at the backend code to get the idea.
> > 
> > hw/9pfs/9p-synth.h
> > hw/9pfs/9p-synth.c
> > 
> > and the test program:
> > 
> > tests/virtio-9p-test.c
> > 
> > It currently doesn't care for st_dev/st_ino at all, but I guess
> > it shouldn't be that hard to add the necessary bits.
> 
> I see. Well, I will look at it, but that will definitely not be one of my 
> current high priority tasks that would happen in the next few weeks (simply 
> due to my work load).
> 

Same here :)

On Montag, 23. September 2019 16:46:53 CEST Greg Kurz wrote:
> > > > > I'll do some
> > > > > more manual testing and issue a PR when I'm confident enough.
> > > > 
> > > > That would be highly appreciated! So far I am the only one ever having
> > > > tested this patch set at all!
> > > 
> > > Just to clarify, I won't thoroughly test it. My main concern is that it
> > > doesn't break things.
> > 
> > So in other words you are only going to test the default behaviour
> > --multidevs=warn?
> 
> This I've already done, along with multidevs=forbid.
> 
> Now I plan to run the PJD test suite from Tuxera with a simple
> cross-device setup and --multidevs=remap. And that's it.

Well, Ok then, however at least some simple, manual, final "ls -i" of the 
inode numbers on guest would not hurt though. ;-)

> > If yes, and since that would mean I was the only person ever having tested
> > the actual fix, shouldn't --multidevs=remap|forbid better be marked as
> > experimental (docs and runtime warning) for now? Maybe that would also
> > anticipate receiving feedback from people actually using it later on.
> Makes sense. I don't think it is worth having a runtime warning,
> but I'll turn remap to x-remap and amend the docs.

Mwa, I would like to veto against your "x-remap" plan though. Keep in mind I 
also have to send out a patch for libvirt for this fix. Even I would not have 
read "x" to stand for "experimental". So I would definitely favor a runtime 
warning instead of renaming that parameter.

I can send a patch on top for docs and warning if you want.

On Mon, 23 Sep 2019 17:03:23 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Montag, 23. September 2019 16:46:53 CEST Greg Kurz wrote:
> > > > > > I'll do some
> > > > > > more manual testing and issue a PR when I'm confident enough.
> > > > > 
> > > > > That would be highly appreciated! So far I am the only one ever having
> > > > > tested this patch set at all!
> > > > 
> > > > Just to clarify, I won't thoroughly test it. My main concern is that it
> > > > doesn't break things.
> > > 
> > > So in other words you are only going to test the default behaviour
> > > --multidevs=warn?
> > 
> > This I've already done, along with multidevs=forbid.
> > 
> > Now I plan to run the PJD test suite from Tuxera with a simple
> > cross-device setup and --multidevs=remap. And that's it.
> 
> Well, Ok then, however at least some simple, manual, final "ls -i" of the 
> inode numbers on guest would not hurt though. ;-)
> 
> > > If yes, and since that would mean I was the only person ever having tested
> > > the actual fix, shouldn't --multidevs=remap|forbid better be marked as
> > > experimental (docs and runtime warning) for now? Maybe that would also
> > > anticipate receiving feedback from people actually using it later on.
> > Makes sense. I don't think it is worth having a runtime warning,
> > but I'll turn remap to x-remap and amend the docs.
> 
> Mwa, I would like to veto against your "x-remap" plan though. Keep in mind I 
> also have to send out a patch for libvirt for this fix. Even I would not have 
> read "x" to stand for "experimental". So I would definitely favor a runtime 
> warning instead of renaming that parameter.
> 

Hmmm... I don't see the point in adding a warning for a feature that
is only active if the user explicitly asks for it. And, anyway, this
still is an experimental feature, right ? Not sure it is time to have
libvirt to support it yet.

Maybe Daniel can comment on libvirt adoption of new features ?

> I can send a patch on top for docs and warning if you want.
> 
> 

On Montag, 23. September 2019 18:50:12 CEST Greg Kurz wrote:
> > > > If yes, and since that would mean I was the only person ever having
> > > > tested
> > > > the actual fix, shouldn't --multidevs=remap|forbid better be marked as
> > > > experimental (docs and runtime warning) for now? Maybe that would also
> > > > anticipate receiving feedback from people actually using it later on.
> > > 
> > > Makes sense. I don't think it is worth having a runtime warning,
> > > but I'll turn remap to x-remap and amend the docs.
> > 
> > Mwa, I would like to veto against your "x-remap" plan though. Keep in mind
> > I also have to send out a patch for libvirt for this fix. Even I would
> > not have read "x" to stand for "experimental". So I would definitely
> > favor a runtime warning instead of renaming that parameter.
> 
> Hmmm... I don't see the point in adding a warning for a feature that
> is only active if the user explicitly asks for it. 

Because many people might be using this option without ever reading the docs, 
e.g. because of being suggested by copy & paste tutorials or any stack*.com 
forum.

> And, anyway, this
> still is an experimental feature, right ? 

No, it is not a feature. It is still a fix. :) I cannot use 9p without this 
fix at all, so it is not some optional "feature" for me.

x-remap would just make things unnecessarily more complicated without adding 
anything useful.

A warning/info log could be used to motivate people providing feedback and 
make them clearly aware about their current version still being an 
experimental fix in their specific qemu version. That warning/info is just a 
one line change that can easily be dropped at some point in future after this 
qid fix proofed to be reliable (i.e. from users' feedback and test cases).

> Not sure it is time to have
> libvirt to support it yet.

Most people are using libvirt xml configs instead of calling qemu directly 
with command line options. So of course I will suggest a libvirt patch as soon 
as this patch set is pulled on qemu side.

On Tue, 24 Sep 2019 11:31:06 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Montag, 23. September 2019 18:50:12 CEST Greg Kurz wrote:
> > > > > If yes, and since that would mean I was the only person ever having
> > > > > tested
> > > > > the actual fix, shouldn't --multidevs=remap|forbid better be marked as
> > > > > experimental (docs and runtime warning) for now? Maybe that would also
> > > > > anticipate receiving feedback from people actually using it later on.
> > > > 
> > > > Makes sense. I don't think it is worth having a runtime warning,
> > > > but I'll turn remap to x-remap and amend the docs.
> > > 
> > > Mwa, I would like to veto against your "x-remap" plan though. Keep in mind
> > > I also have to send out a patch for libvirt for this fix. Even I would
> > > not have read "x" to stand for "experimental". So I would definitely
> > > favor a runtime warning instead of renaming that parameter.
> > 
> > Hmmm... I don't see the point in adding a warning for a feature that
> > is only active if the user explicitly asks for it. 
> 
> Because many people might be using this option without ever reading the docs, 
> e.g. because of being suggested by copy & paste tutorials or any stack*.com 
> forum.
> 
> > And, anyway, this
> > still is an experimental feature, right ? 
> 
> No, it is not a feature. It is still a fix. :) I cannot use 9p without this 
> fix at all, so it is not some optional "feature" for me.
> 

I understand your need but this is still arguable. The 9p device has
a limitation with cross-device setups. The actual bug is to silently
cause inode number collisions in the guest. This is partly fixed by the
"9p: Treat multiple devices on one export as an error" patch. Thinking
again, it would even make sense to move "remap" from "9p: Added virtfs
option 'multidevs=remap|forbid|warn'" to its own patch. We could then
consider that the bug is fully fixed with "multidevs=forbid|warn".

Then comes the "remap" feature which is expected to lift the limitation
with cross-device setups, with a "not yet determined" performance cost
and light reviewing of the code.

> x-remap would just make things unnecessarily more complicated without adding 
> anything useful.
> 

Not really. This gives a crucial information to the user about the
level of confidence we have in this feature.

> A warning/info log could be used to motivate people providing feedback and 
> make them clearly aware about their current version still being an 
> experimental fix in their specific qemu version. That warning/info is just a 
> one line change that can easily be dropped at some point in future after this 
> qid fix proofed to be reliable (i.e. from users' feedback and test cases).
> 

The overwhelming majority of feedbacks I had on 9p the last few years
are CVEs. Antonios and you are the only users who ever seemed to care
for cross-device setups. So I don't expect much feedback on that area
and I don't buy the "motivate people" argument, especially since "remap"
won't be the default.

> > Not sure it is time to have
> > libvirt to support it yet.
> 
> Most people are using libvirt xml configs instead of calling qemu directly 
> with command line options. So of course I will suggest a libvirt patch as soon 
> as this patch set is pulled on qemu side.
> 

Yes and before a feature has a chance to be officially supported
in libvirt, people usually rely on the <qemu:commandline> domain
XML tag to pass extra arguments to QEMU.

https://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html

With the current fsdev implementation, we can only pass properties
to the -fsdev command line option. So this would require to not
use the <filesystem type='mount'> XML tag and manually _open-code_
the needed QEMU arguments:

<qemu:commandline>
  <qemu:arg value='-fsdev'/>
  <qemu:arg value='local,id=fsdev0,path=/var/tmp/virtfs,security_model=passthrough,multidevs=remap'/>
  <qemu:arg value='-device'/>
  <qemu:arg value='virtio-9p,id=virtio-9p0,mount_tag=host,fsdev=fsdev0'/>
</qemu:commandline>

And if fsdev is converted to be a proper QEMU device, it would as
easy as:

<qemu:commandline>
  <qemu:arg value='-set'/>
  <qemu:arg value='device.fsdev0.multidevs=remap'/>
</qemu:commandline>

This is unrelated but it would also allow to drop a lot
of code in fsdev that mimics what qdev would give us
for free. :)

> 
> 

Also, I strongly recommend you try out "virtio-fs" which is
going to be soon the production grade way of sharing files
between host and guest.

https://www.mail-archive.com/libvir-list@redhat.com/msg182457.html

Cheers,

--
Greg

On Dienstag, 8. Oktober 2019 11:14:59 CEST Greg Kurz wrote:
> > No, it is not a feature. It is still a fix. :) I cannot use 9p without
> > this
> > fix at all, so it is not some optional "feature" for me.
> 
> I understand your need but this is still arguable. The 9p device has
> a limitation with cross-device setups. The actual bug is to silently
> cause inode number collisions in the guest. This is partly fixed by the
> "9p: Treat multiple devices on one export as an error" patch. Thinking
> again, it would even make sense to move "remap" from "9p: Added virtfs
> option 'multidevs=remap|forbid|warn'" to its own patch. We could then
> consider that the bug is fully fixed with "multidevs=forbid|warn".
> 
> Then comes the "remap" feature which is expected to lift the limitation
> with cross-device setups, with a "not yet determined" performance cost
> and light reviewing of the code.

Are these patch transfer requests addressed at me to be done?

> Also, I strongly recommend you try out "virtio-fs" which is
> going to be soon the production grade way of sharing files
> between host and guest.
> 
> https://www.mail-archive.com/libvir-list@redhat.com/msg182457.html

Yes I know, I am following the development of virtio-fs already of course. 
However for me it is far too early to actually use it in a production 
environment. It e.g. seems to require bleeding edge kernel versions. And the 
real argument for switching from 9p to virtio-fs would be a significant 
performance increase. However so far (correct me if I am wrong) I have not 
seen benchmarks that would show that this was already the case (yet).

I wonder though whether virtio-fs suffers from the same file ID collisions 
problem when sharing multiple file systems.

What is your long-term plan for 9p? Will it be dropped completely after 
virtio-fs became stable?

Best regards,
Christian Schoenebeck

On Tue, 08 Oct 2019 14:05:28 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> 
> I wonder though whether virtio-fs suffers from the same file ID collisions 
> problem when sharing multiple file systems.
> 

I gave a try and it seems that virtio-fs might expose the inode numbers from
different devices in the host, unvirtualized AND with the same device in the
guest:

# mkdir -p /var/tmp/virtio-fs/proc
# mount --bind /proc /var/tmp/virtio-fs/proc
# virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/var/tmp/virtio-fs -o cache=always

and then started QEMU with:

-chardev socket,id=char0,path=/tmp/vhostqemu \
-device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \
-m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
-numa node,memdev=mem

In the host:

$ stat /var/tmp/virtio-fs
  File: /var/tmp/virtio-fs
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 787796      Links: 4
Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2019-10-15 11:08:52.070080922 +0200
Modify: 2019-10-15 11:02:09.887404446 +0200
Change: 2019-10-15 11:02:09.887404446 +0200
 Birth: 2019-10-13 19:13:04.009699354 +0200
[greg@bahia ~]$ stat /var/tmp/virtio-fs/FOO
  File: /var/tmp/virtio-fs/FOO
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d    Inode: 790740      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2019-10-15 11:02:09.888404448 +0200
Modify: 2019-10-15 11:02:09.888404448 +0200
Change: 2019-10-15 11:02:09.888404448 +0200
 Birth: 2019-10-15 11:02:09.887404446 +0200
[greg@bahia ~]$ stat /var/tmp/virtio-fs/proc/fs
  File: /var/tmp/virtio-fs/proc/fs
  Size: 0               Blocks: 0          IO Block: 1024   directory
Device: 4h/4d   Inode: 4026531845  Links: 5
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:proc_t:s0
Access: 2019-10-01 14:50:09.223233901 +0200
Modify: 2019-10-01 14:50:09.223233901 +0200
Change: 2019-10-01 14:50:09.223233901 +0200
 Birth: -

In the guest:

[greg@localhost ~]$ stat /mnt
  File: /mnt
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 2dh/45d Inode: 787796      Links: 4
Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
Context: system_u:object_r:unlabeled_t:s0
Access: 2019-10-15 11:08:52.070080922 +0200
Modify: 2019-10-15 11:02:09.887404446 +0200
Change: 2019-10-15 11:02:09.887404446 +0200
 Birth: -
[greg@localhost ~]$ stat /mnt/FOO
  File: /mnt/FOO
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 2dh/45d Inode: 790740      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
Context: system_u:object_r:unlabeled_t:s0
Access: 2019-10-15 11:02:09.888404448 +0200
Modify: 2019-10-15 11:02:09.888404448 +0200
Change: 2019-10-15 11:02:09.888404448 +0200
 Birth: -
[greg@localhost ~]$ stat /mnt/proc/fs
  File: /mnt/proc/fs
  Size: 0               Blocks: 0          IO Block: 1024   directory
Device: 2dh/45d Inode: 4026531845  Links: 5
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:unlabeled_t:s0
Access: 2019-10-01 14:50:09.223233901 +0200
Modify: 2019-10-01 14:50:09.223233901 +0200
Change: 2019-10-01 14:50:09.223233901 +0200
 Birth: -

Unless I'm missing something, it seems that "virtio-fs" has the same
issue we had on 9pfs before Christian's patches... :-\

--
Greg

On Dienstag, 15. Oktober 2019 11:20:39 CEST Greg Kurz wrote:
> On Tue, 08 Oct 2019 14:05:28 +0200
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > I wonder though whether virtio-fs suffers from the same file ID collisions
> > problem when sharing multiple file systems.
> 
> I gave a try and it seems that virtio-fs might expose the inode numbers from
> different devices in the host, unvirtualized AND with the same device in
> the guest:
> 
> # mkdir -p /var/tmp/virtio-fs/proc
> # mount --bind /proc /var/tmp/virtio-fs/proc
> # virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/var/tmp/virtio-fs
> -o cache=always
> 
> and then started QEMU with:
> 
> -chardev socket,id=char0,path=/tmp/vhostqemu \
> -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \
> -m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on
> \ -numa node,memdev=mem
> 
> In the host:
> 
> $ stat /var/tmp/virtio-fs
>   File: /var/tmp/virtio-fs
>   Size: 4096            Blocks: 8          IO Block: 4096   directory
> Device: fd00h/64768d    Inode: 787796      Links: 4
> Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> Context: unconfined_u:object_r:user_tmp_t:s0
> Access: 2019-10-15 11:08:52.070080922 +0200
> Modify: 2019-10-15 11:02:09.887404446 +0200
> Change: 2019-10-15 11:02:09.887404446 +0200
>  Birth: 2019-10-13 19:13:04.009699354 +0200
> [greg@bahia ~]$ stat /var/tmp/virtio-fs/FOO
>   File: /var/tmp/virtio-fs/FOO
>   Size: 0               Blocks: 0          IO Block: 4096   regular empty
> file Device: fd00h/64768d    Inode: 790740      Links: 1
> Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> Context: unconfined_u:object_r:user_tmp_t:s0
> Access: 2019-10-15 11:02:09.888404448 +0200
> Modify: 2019-10-15 11:02:09.888404448 +0200
> Change: 2019-10-15 11:02:09.888404448 +0200
>  Birth: 2019-10-15 11:02:09.887404446 +0200
> [greg@bahia ~]$ stat /var/tmp/virtio-fs/proc/fs
>   File: /var/tmp/virtio-fs/proc/fs
>   Size: 0               Blocks: 0          IO Block: 1024   directory
> Device: 4h/4d   Inode: 4026531845  Links: 5
> Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: system_u:object_r:proc_t:s0
> Access: 2019-10-01 14:50:09.223233901 +0200
> Modify: 2019-10-01 14:50:09.223233901 +0200
> Change: 2019-10-01 14:50:09.223233901 +0200
>  Birth: -
> 
> In the guest:
> 
> [greg@localhost ~]$ stat /mnt
>   File: /mnt
>   Size: 4096            Blocks: 8          IO Block: 4096   directory
> Device: 2dh/45d Inode: 787796      Links: 4
> Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> Context: system_u:object_r:unlabeled_t:s0
> Access: 2019-10-15 11:08:52.070080922 +0200
> Modify: 2019-10-15 11:02:09.887404446 +0200
> Change: 2019-10-15 11:02:09.887404446 +0200
>  Birth: -
> [greg@localhost ~]$ stat /mnt/FOO
>   File: /mnt/FOO
>   Size: 0               Blocks: 0          IO Block: 4096   regular empty
> file Device: 2dh/45d Inode: 790740      Links: 1
> Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> Context: system_u:object_r:unlabeled_t:s0
> Access: 2019-10-15 11:02:09.888404448 +0200
> Modify: 2019-10-15 11:02:09.888404448 +0200
> Change: 2019-10-15 11:02:09.888404448 +0200
>  Birth: -
> [greg@localhost ~]$ stat /mnt/proc/fs
>   File: /mnt/proc/fs
>   Size: 0               Blocks: 0          IO Block: 1024   directory
> Device: 2dh/45d Inode: 4026531845  Links: 5
> Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: system_u:object_r:unlabeled_t:s0
> Access: 2019-10-01 14:50:09.223233901 +0200
> Modify: 2019-10-01 14:50:09.223233901 +0200
> Change: 2019-10-01 14:50:09.223233901 +0200
>  Birth: -
> 
> Unless I'm missing something, it seems that "virtio-fs" has the same
> issue we had on 9pfs before Christian's patches... :-\

Is a fix for this desired for virtio-fs?

Greg, did you have to update kernel version on either host or guest side to 
get virtio-fs running? Or were the discussed kernel changes just for optional 
acceleration purposes (i.e. DAX)?

Best regards,
Christian Schoenebeck

* Christian Schoenebeck (qemu_oss@crudebyte.com) wrote:
> On Dienstag, 15. Oktober 2019 11:20:39 CEST Greg Kurz wrote:
> > On Tue, 08 Oct 2019 14:05:28 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > I wonder though whether virtio-fs suffers from the same file ID collisions
> > > problem when sharing multiple file systems.
> > 
> > I gave a try and it seems that virtio-fs might expose the inode numbers from
> > different devices in the host, unvirtualized AND with the same device in
> > the guest:
> > 
> > # mkdir -p /var/tmp/virtio-fs/proc
> > # mount --bind /proc /var/tmp/virtio-fs/proc
> > # virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/var/tmp/virtio-fs
> > -o cache=always
> > 
> > and then started QEMU with:
> > 
> > -chardev socket,id=char0,path=/tmp/vhostqemu \
> > -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \
> > -m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on
> > \ -numa node,memdev=mem
> > 
> > In the host:
> > 
> > $ stat /var/tmp/virtio-fs
> >   File: /var/tmp/virtio-fs
> >   Size: 4096            Blocks: 8          IO Block: 4096   directory
> > Device: fd00h/64768d    Inode: 787796      Links: 4
> > Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: unconfined_u:object_r:user_tmp_t:s0
> > Access: 2019-10-15 11:08:52.070080922 +0200
> > Modify: 2019-10-15 11:02:09.887404446 +0200
> > Change: 2019-10-15 11:02:09.887404446 +0200
> >  Birth: 2019-10-13 19:13:04.009699354 +0200
> > [greg@bahia ~]$ stat /var/tmp/virtio-fs/FOO
> >   File: /var/tmp/virtio-fs/FOO
> >   Size: 0               Blocks: 0          IO Block: 4096   regular empty
> > file Device: fd00h/64768d    Inode: 790740      Links: 1
> > Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: unconfined_u:object_r:user_tmp_t:s0
> > Access: 2019-10-15 11:02:09.888404448 +0200
> > Modify: 2019-10-15 11:02:09.888404448 +0200
> > Change: 2019-10-15 11:02:09.888404448 +0200
> >  Birth: 2019-10-15 11:02:09.887404446 +0200
> > [greg@bahia ~]$ stat /var/tmp/virtio-fs/proc/fs
> >   File: /var/tmp/virtio-fs/proc/fs
> >   Size: 0               Blocks: 0          IO Block: 1024   directory
> > Device: 4h/4d   Inode: 4026531845  Links: 5
> > Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> > Context: system_u:object_r:proc_t:s0
> > Access: 2019-10-01 14:50:09.223233901 +0200
> > Modify: 2019-10-01 14:50:09.223233901 +0200
> > Change: 2019-10-01 14:50:09.223233901 +0200
> >  Birth: -
> > 
> > In the guest:
> > 
> > [greg@localhost ~]$ stat /mnt
> >   File: /mnt
> >   Size: 4096            Blocks: 8          IO Block: 4096   directory
> > Device: 2dh/45d Inode: 787796      Links: 4
> > Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: system_u:object_r:unlabeled_t:s0
> > Access: 2019-10-15 11:08:52.070080922 +0200
> > Modify: 2019-10-15 11:02:09.887404446 +0200
> > Change: 2019-10-15 11:02:09.887404446 +0200
> >  Birth: -
> > [greg@localhost ~]$ stat /mnt/FOO
> >   File: /mnt/FOO
> >   Size: 0               Blocks: 0          IO Block: 4096   regular empty
> > file Device: 2dh/45d Inode: 790740      Links: 1
> > Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: system_u:object_r:unlabeled_t:s0
> > Access: 2019-10-15 11:02:09.888404448 +0200
> > Modify: 2019-10-15 11:02:09.888404448 +0200
> > Change: 2019-10-15 11:02:09.888404448 +0200
> >  Birth: -
> > [greg@localhost ~]$ stat /mnt/proc/fs
> >   File: /mnt/proc/fs
> >   Size: 0               Blocks: 0          IO Block: 1024   directory
> > Device: 2dh/45d Inode: 4026531845  Links: 5
> > Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> > Context: system_u:object_r:unlabeled_t:s0
> > Access: 2019-10-01 14:50:09.223233901 +0200
> > Modify: 2019-10-01 14:50:09.223233901 +0200
> > Change: 2019-10-01 14:50:09.223233901 +0200
> >  Birth: -
> > 
> > Unless I'm missing something, it seems that "virtio-fs" has the same
> > issue we had on 9pfs before Christian's patches... :-\
> 
> Is a fix for this desired for virtio-fs?

Yes I think so;  we had originally thought we were hiding the host inode
numbers; but that's not true - since we pass both a device and inode
number in virtiofs, unlike 9p, it seems we can probably get away with
only remapping device IDs rather than inode numbers; but that requires
some understanding of how multiple block device IDs are supposed to look
like to the guest kernel.

Dave

> Greg, did you have to update kernel version on either host or guest side to 
> get virtio-fs running? Or were the discussed kernel changes just for optional 
> acceleration purposes (i.e. DAX)?
> 
> Best regards,
> Christian Schoenebeck
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

On Mittwoch, 16. Oktober 2019 15:44:09 CEST Dr. David Alan Gilbert wrote:
> > > Unless I'm missing something, it seems that "virtio-fs" has the same
> > > issue we had on 9pfs before Christian's patches... :-\
> > 
> > Is a fix for this desired for virtio-fs?
> 
> Yes I think so;  we had originally thought we were hiding the host inode
> numbers; but that's not true - since we pass both a device and inode
> number in virtiofs, unlike 9p, it seems we can probably get away with
> only remapping device IDs rather than inode numbers; but that requires
> some understanding of how multiple block device IDs are supposed to look
> like to the guest kernel.

Postponed on my side then. My original idea was simply sharing the existing 
inode remapping code from 9p. But remapping/adding device ids on guest side 
like you suggested is cleaner; takes more time though to lookup the required 
kernel interfaces to achieve that.

Best regards,
Christian Schoenebeck

On Wed, 16 Oct 2019 11:42:52 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Dienstag, 15. Oktober 2019 11:20:39 CEST Greg Kurz wrote:
> > On Tue, 08 Oct 2019 14:05:28 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > I wonder though whether virtio-fs suffers from the same file ID collisions
> > > problem when sharing multiple file systems.
> > 
> > I gave a try and it seems that virtio-fs might expose the inode numbers from
> > different devices in the host, unvirtualized AND with the same device in
> > the guest:
> > 
> > # mkdir -p /var/tmp/virtio-fs/proc
> > # mount --bind /proc /var/tmp/virtio-fs/proc
> > # virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/var/tmp/virtio-fs
> > -o cache=always
> > 
> > and then started QEMU with:
> > 
> > -chardev socket,id=char0,path=/tmp/vhostqemu \
> > -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs \
> > -m 4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on
> > \ -numa node,memdev=mem
> > 
> > In the host:
> > 
> > $ stat /var/tmp/virtio-fs
> >   File: /var/tmp/virtio-fs
> >   Size: 4096            Blocks: 8          IO Block: 4096   directory
> > Device: fd00h/64768d    Inode: 787796      Links: 4
> > Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: unconfined_u:object_r:user_tmp_t:s0
> > Access: 2019-10-15 11:08:52.070080922 +0200
> > Modify: 2019-10-15 11:02:09.887404446 +0200
> > Change: 2019-10-15 11:02:09.887404446 +0200
> >  Birth: 2019-10-13 19:13:04.009699354 +0200
> > [greg@bahia ~]$ stat /var/tmp/virtio-fs/FOO
> >   File: /var/tmp/virtio-fs/FOO
> >   Size: 0               Blocks: 0          IO Block: 4096   regular empty
> > file Device: fd00h/64768d    Inode: 790740      Links: 1
> > Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: unconfined_u:object_r:user_tmp_t:s0
> > Access: 2019-10-15 11:02:09.888404448 +0200
> > Modify: 2019-10-15 11:02:09.888404448 +0200
> > Change: 2019-10-15 11:02:09.888404448 +0200
> >  Birth: 2019-10-15 11:02:09.887404446 +0200
> > [greg@bahia ~]$ stat /var/tmp/virtio-fs/proc/fs
> >   File: /var/tmp/virtio-fs/proc/fs
> >   Size: 0               Blocks: 0          IO Block: 1024   directory
> > Device: 4h/4d   Inode: 4026531845  Links: 5
> > Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> > Context: system_u:object_r:proc_t:s0
> > Access: 2019-10-01 14:50:09.223233901 +0200
> > Modify: 2019-10-01 14:50:09.223233901 +0200
> > Change: 2019-10-01 14:50:09.223233901 +0200
> >  Birth: -
> > 
> > In the guest:
> > 
> > [greg@localhost ~]$ stat /mnt
> >   File: /mnt
> >   Size: 4096            Blocks: 8          IO Block: 4096   directory
> > Device: 2dh/45d Inode: 787796      Links: 4
> > Access: (0775/drwxrwxr-x)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: system_u:object_r:unlabeled_t:s0
> > Access: 2019-10-15 11:08:52.070080922 +0200
> > Modify: 2019-10-15 11:02:09.887404446 +0200
> > Change: 2019-10-15 11:02:09.887404446 +0200
> >  Birth: -
> > [greg@localhost ~]$ stat /mnt/FOO
> >   File: /mnt/FOO
> >   Size: 0               Blocks: 0          IO Block: 4096   regular empty
> > file Device: 2dh/45d Inode: 790740      Links: 1
> > Access: (0664/-rw-rw-r--)  Uid: ( 1000/    greg)   Gid: ( 1000/    greg)
> > Context: system_u:object_r:unlabeled_t:s0
> > Access: 2019-10-15 11:02:09.888404448 +0200
> > Modify: 2019-10-15 11:02:09.888404448 +0200
> > Change: 2019-10-15 11:02:09.888404448 +0200
> >  Birth: -
> > [greg@localhost ~]$ stat /mnt/proc/fs
> >   File: /mnt/proc/fs
> >   Size: 0               Blocks: 0          IO Block: 1024   directory
> > Device: 2dh/45d Inode: 4026531845  Links: 5
> > Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> > Context: system_u:object_r:unlabeled_t:s0
> > Access: 2019-10-01 14:50:09.223233901 +0200
> > Modify: 2019-10-01 14:50:09.223233901 +0200
> > Change: 2019-10-01 14:50:09.223233901 +0200
> >  Birth: -
> > 
> > Unless I'm missing something, it seems that "virtio-fs" has the same
> > issue we had on 9pfs before Christian's patches... :-\
> 
> Is a fix for this desired for virtio-fs?
> 

Probably. Dave and/or Stefan should know what is needed.

> Greg, did you have to update kernel version on either host or guest side to 

I didn't change the kernel on the host (5.2.17-200.fc30.x86_64) but the 
victim guest was running upstream kernel (SHA1 5bc52f64e8841).

> get virtio-fs running? Or were the discussed kernel changes just for optional 
> acceleration purposes (i.e. DAX)?
> 
> Best regards,
> Christian Schoenebeck
> 
> 

On Tue, 08 Oct 2019 14:05:28 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Dienstag, 8. Oktober 2019 11:14:59 CEST Greg Kurz wrote:
> > > No, it is not a feature. It is still a fix. :) I cannot use 9p without
> > > this
> > > fix at all, so it is not some optional "feature" for me.
> > 
> > I understand your need but this is still arguable. The 9p device has
> > a limitation with cross-device setups. The actual bug is to silently
> > cause inode number collisions in the guest. This is partly fixed by the
> > "9p: Treat multiple devices on one export as an error" patch. Thinking
> > again, it would even make sense to move "remap" from "9p: Added virtfs
> > option 'multidevs=remap|forbid|warn'" to its own patch. We could then
> > consider that the bug is fully fixed with "multidevs=forbid|warn".
> > 
> > Then comes the "remap" feature which is expected to lift the limitation
> > with cross-device setups, with a "not yet determined" performance cost
> > and light reviewing of the code.
> 
> Are these patch transfer requests addressed at me to be done?
> 

It would certainly be appreciated :) and if it happens to be done
before 2019-10-29, it can even be shipped with QEMU 4.2.

> > Also, I strongly recommend you try out "virtio-fs" which is
> > going to be soon the production grade way of sharing files
> > between host and guest.
> > 
> > https://www.mail-archive.com/libvir-list@redhat.com/msg182457.html
> 
> Yes I know, I am following the development of virtio-fs already of course. 
> However for me it is far too early to actually use it in a production 
> environment. It e.g. seems to require bleeding edge kernel versions. And the 
> real argument for switching from 9p to virtio-fs would be a significant 
> performance increase. However so far (correct me if I am wrong) I have not 
> seen benchmarks that would show that this was already the case (yet).
> 
> I wonder though whether virtio-fs suffers from the same file ID collisions 
> problem when sharing multiple file systems.
> 

I don't know.

> What is your long-term plan for 9p? Will it be dropped completely after 
> virtio-fs became stable?
> 

No, 9p will survive. The local backend has an advantage despite its various
limitations: it is really easy to use. No extra command needed. I also want
to keep the synth backend around for testing, but I'll gladly drop the
proxy backend which is clearly superseded by virtio-fs.

Cheers,

--
Greg

> Best regards,
> Christian Schoenebeck
> 
> 

On Dienstag, 8. Oktober 2019 15:47:29 CEST Greg Kurz wrote:
> On Tue, 08 Oct 2019 14:05:28 +0200
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Dienstag, 8. Oktober 2019 11:14:59 CEST Greg Kurz wrote:
> > > > No, it is not a feature. It is still a fix. :) I cannot use 9p without
> > > > this
> > > > fix at all, so it is not some optional "feature" for me.
> > > 
> > > I understand your need but this is still arguable. The 9p device has
> > > a limitation with cross-device setups. The actual bug is to silently
> > > cause inode number collisions in the guest. This is partly fixed by the
> > > "9p: Treat multiple devices on one export as an error" patch. Thinking
> > > again, it would even make sense to move "remap" from "9p: Added virtfs
> > > option 'multidevs=remap|forbid|warn'" to its own patch. We could then
> > > consider that the bug is fully fixed with "multidevs=forbid|warn".
> > > 
> > > Then comes the "remap" feature which is expected to lift the limitation
> > > with cross-device setups, with a "not yet determined" performance cost
> > > and light reviewing of the code.
> > 
> > Are these patch transfer requests addressed at me to be done?
> 
> It would certainly be appreciated :) and if it happens to be done
> before 2019-10-29, it can even be shipped with QEMU 4.2.

Just to avoid any misapprehension, since today's comments of yours made me 
sceptical: that would be

a) PR for QEMU 4.2 for *all* QID patches up to and including remapping with 
variable suffix (e.g. as -multidevs=x-remap)?

or is your current plan rather 

b) to ship the discussed 9p patches for QEMU 4.2 only up to a certain patch 
like multidevs=warn|forbid and all subsequent patches "might" then be merged 
to master somewhere in distant future?

Best regards,
Christian Schoenebeck

On Tue, 08 Oct 2019 16:25:48 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Dienstag, 8. Oktober 2019 15:47:29 CEST Greg Kurz wrote:
> > On Tue, 08 Oct 2019 14:05:28 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > On Dienstag, 8. Oktober 2019 11:14:59 CEST Greg Kurz wrote:
> > > > > No, it is not a feature. It is still a fix. :) I cannot use 9p without
> > > > > this
> > > > > fix at all, so it is not some optional "feature" for me.
> > > > 
> > > > I understand your need but this is still arguable. The 9p device has
> > > > a limitation with cross-device setups. The actual bug is to silently
> > > > cause inode number collisions in the guest. This is partly fixed by the
> > > > "9p: Treat multiple devices on one export as an error" patch. Thinking
> > > > again, it would even make sense to move "remap" from "9p: Added virtfs
> > > > option 'multidevs=remap|forbid|warn'" to its own patch. We could then
> > > > consider that the bug is fully fixed with "multidevs=forbid|warn".
> > > > 
> > > > Then comes the "remap" feature which is expected to lift the limitation
> > > > with cross-device setups, with a "not yet determined" performance cost
> > > > and light reviewing of the code.
> > > 
> > > Are these patch transfer requests addressed at me to be done?
> > 
> > It would certainly be appreciated :) and if it happens to be done
> > before 2019-10-29, it can even be shipped with QEMU 4.2.
> 
> Just to avoid any misapprehension, since today's comments of yours made me 
> sceptical: that would be
> 
> a) PR for QEMU 4.2 for *all* QID patches up to and including remapping with 
> variable suffix (e.g. as -multidevs=x-remap)?
> 
> or is your current plan rather 
> 
> b) to ship the discussed 9p patches for QEMU 4.2 only up to a certain patch 
> like multidevs=warn|forbid and all subsequent patches "might" then be merged 
> to master somewhere in distant future?
> 

Rather b) but I guess other patches could be merged as soon as the 4.3
development phase begins (mid December), and I'll continue to push patches
to my 9p-next branch during the freeze period anyway.

> Best regards,
> Christian Schoenebeck
> 
>