netdev - Re: [PATCH v4 00/12] remove msize limit in virtio transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7534209.h2h7kyIpJd@silver>
Date:   Thu, 07 Jul 2022 16:30:55 +0200
From:   Christian Schoenebeck <linux_oss@...debyte.com>
To:     Dominique Martinet <asmadeus@...ewreck.org>,
        Greg Kurz <groug@...d.org>
Cc:     v9fs-developer@...ts.sourceforge.net, netdev@...r.kernel.org,
        Eric Van Hensbergen <ericvh@...il.com>,
        Latchesar Ionkov <lucho@...kov.net>,
        Nikolay Kichukov <nikolay@...um.net>
Subject: Re: [PATCH v4 00/12] remove msize limit in virtio transport

On Donnerstag, 30. Dezember 2021 14:23:18 CEST Christian Schoenebeck wrote:
> This series aims to get get rid of the current 500k 'msize' limitation in
> the 9p virtio transport, which is currently a bottleneck for performance
> of 9p mounts.
[...]
> KNOWN LIMITATION:
> 
> With this series applied I can run
> 
>   QEMU host <-> 9P virtio <-> Linux guest
> 
> with up to slightly below 4 MB msize [4186112 = (1024-2) * 4096]. If I try
> to run it with exactly 4 MB (4194304) it currently hits a limitation on
> QEMU side:
> 
>   qemu-system-x86_64: virtio: too many write descriptors in indirect table
> 
> That's because QEMU currently has a hard coded limit of max. 1024 virtio
> descriptors per vring slot (i.e. per virtio message), see to do (1.) below.
> 
> 
> STILL TO DO:
> 
>   1. Negotiating virtio "Queue Indirect Size" (MANDATORY):
> 
>     The QEMU issue described above must be addressed by negotiating the
>     maximum length of virtio indirect descriptor tables on virtio device
>     initialization. This would not only avoid the QEMU error above, but
>     would also allow msize of >4MB in future. Before that change can be done
>     on Linux and QEMU sides though, it first requires a change to the virtio
>     specs. Work on that on the virtio specs is in progress:
> 
>     https://github.com/oasis-tcs/virtio-spec/issues/122
> 
>     This is not really an issue for testing this series. Just stick to max.
>     msize=4186112 as described above and you will be fine. However for the
>     final PR this should obviously be addressed in a clean way.

As there is no progress on virtio spec side in sight, I'm considering to 
handle this issue in upcoming v5 by simply assuming (hard coding) that 9p 
server supports exactly up to 1024 virtio descriptors (memory segments) per 
round trip message. That's maybe a bit unclean, but that's what other virtio 
drivers in the Linux kernel do for many years as well, so I am not expecting a 
negative issue in practice.

And I mean, when we talk about 9p + virtio, that actually implies QEMU being 
the 9p server, right? At least I am not aware of another 9p server 
implementation supporting virtio transport (nor any QEMU version that ever 
supported less than 1024 virtio descriptors). Maybe Microsoft WSL? Not sure.

Best regards,
Christian Schoenebeck