Re: [PATCH 1/4] MAINTAINERS: drop audio maintainership
On Wednesday, May 22, 2024 2:54:51 PM CEST Thomas Huth wrote: > On 16/05/2024 14.03, Gerd Hoffmann wrote: [...] > > ALSA Audio backend > > -M: Gerd Hoffmann > > R: Christian Schoenebeck > > S: Odd Fixes > > F: audio/alsaaudio.c > > I'd also suggest that Christian either upgrade from R: to M: or that we > change the status to Orphan > > > JACK Audio Connection Kit backend > > -M: Gerd Hoffmann > > R: Christian Schoenebeck > > S: Odd Fixes > > F: audio/jackaudio.c > > dito Well, best I can offer is "I try", but no guarantee for latency or anything. On doubt put them on orphan. Best regards, Christian Schoenebeck
Re: [PATCH for-9.0 v3 2/2] qtest/virtio-9p-test.c: remove g_test_slow() gate
On Wednesday, April 17, 2024 1:16:02 AM CEST Daniel Henrique Barboza wrote: > > On 4/16/24 16:54, Michael Tokarev wrote: > > 27.03.2024 17:20, Daniel Henrique Barboza : > >> Commit 558f5c42ef gated the local tests with g_test_slow() to skip them > >> in 'make check'. The reported issue back then was this following CI > >> problem: > >> > >> https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html > >> > >> This problem ended up being fixed after it was detected with the > >> recently added risc-v machine nodes [1]. virtio-9p-test.c is now > >> creating and removing temporary dirs for each test run, instead of > >> creating a single dir for the entire qos-test scope. > >> > >> We're now able to run these tests with 'make check' in the CI, so let's > >> go ahead and re-enable them. > >> > >> This reverts commit 558f5c42efded3e0d0b20a90bce2a9a14580d824. > >> > >> [1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html > > > > This makes tests being unable to complete on a tmpfs. It looks like > > 9pfs tests needs another tweak here. > > > > # starting QEMU: exec ./qemu-system-x86_64 -qtest > > unix:/tmp/qtest-798502.sock -qtest-log /dev/null -chardev > > socket,path=/tmp/qtest-798502.qmp,id=char0 -mon chardev=char0,mode=control > > -display none -audio none -M pc -fsdev > > local,id=fsdev0,path='/tmp/q/master/qtest-9p-local-9LHRL2',security_model=mapped-xattr > > -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest > > Received response 7 (RLERROR) instead of 73 (RMKDIR) > > Rlerror has errno 95 (Operation not supported) > > ** > > ERROR:../../../build/qemu/master/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv: > > assertion failed (hdr.id == id): (7 == 73) > > > > This is when I build it on /tmp/ which is a tmpfs. When I build > > it on a real filesystem, it works fine. > > > > Apparently xattrs aren't supported on a tmpfs. > > Hmmm not sure how to proceed here since I'm not a 9p expert by any means. I'll > let Christian decide what to do. > > If we can't figure it out we might need to re-introduce the gate again. > Thanks, It's not that tmpfs exactly doesn't support xattrs. It supports the trusted.* and security.* namespaces since 2011, so tmpfs was limited to those two. For the 9p 'local' backend however we also need the user.* namespace which was just added in Linux 6.6 last year (commit 2daf18a). Unfortunately the respective kernel option TMPFS_XATTR is still off by default (linux/fs/Kconfig). Back then, when we added that 'slow' gate for the 9p 'local' tests, things were a bit different. They simply did not run in the gitlab pipeline (for reasons described above). Now they do. So obviously it would make sense to preserve these tests for the gitlab pipeline this time, e.g. by skipping these tests only if the underlying test directory does not support *.user xattrs. I'm just not sure yet where exactly such kind of *active* check would fit best into the glib test layout, as this can be a bit tricky with glib. /Christian
[PULL for-9.0 2/2] qtest/virtio-9p-test.c: remove g_test_slow() gate
From: Daniel Henrique Barboza
Commit 558f5c42ef gated the local tests with g_test_slow() to skip them
in 'make check'. The reported issue back then was this following CI
problem:
https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html
This problem ended up being fixed after it was detected with the
recently added risc-v machine nodes [1]. virtio-9p-test.c is now
creating and removing temporary dirs for each test run, instead of
creating a single dir for the entire qos-test scope.
We're now able to run these tests with 'make check' in the CI, so let's
go ahead and re-enable them.
This reverts commit 558f5c42efded3e0d0b20a90bce2a9a14580d824.
[1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20240327142011.805728-3-dbarb...@ventanamicro.com>
Reviewed-by: Greg Kurz
Reviewed-by: Christian Schoenebeck
Tested-by: Thomas Huth
Signed-off-by: Christian Schoenebeck
---
tests/qtest/virtio-9p-test.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 0179b3a394..3c8cd235cf 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -746,15 +746,6 @@ static void register_virtio_9p_test(void)
/* 9pfs test cases using the 'local' filesystem driver */
-
-/*
- * XXX: Until we are sure that these tests can run everywhere,
- * keep them as "slow" so that they aren't run with "make check".
- */
-if (!g_test_slow()) {
-return;
-}
-
opts.before = assign_9p_local_driver;
qos_add_test("local/config", "virtio-9p", pci_config, );
qos_add_test("local/create_dir", "virtio-9p", fs_create_dir, );
--
2.30.2
[PULL for-9.0 1/2] qtest/virtio-9p-test.c: create/remove temp dirs after each test
From: Daniel Henrique Barboza
The local 9p driver in virtio-9p-test.c its temporary dir right at the
start of qos-test (via virtio_9p_create_local_test_dir()) and only
deletes it after qos-test is finished (via
virtio_9p_remove_local_test_dir()).
This means that any qos-test machine that ends up running virtio-9p-test
local tests more than once will end up re-using the same temp dir. This
is what's happening in [1] after we introduced the riscv machine nodes:
if we enable slow tests with the '-m slow' flag using
qemu-system-riscv64, this is what happens:
- a temp dir is created;
- virtio-9p-device tests will run virtio-9p-test successfully;
- virtio-9p-pci tests will run virtio-9p-test, and fail right at the
first slow test at fs_create_dir() because the "01" file was already
created by fs_create_dir() test when running with the virtio-9p-device.
The root cause is that we're creating a single temporary dir, via the
construct/destruct callbacks, and this temp dir is kept for the entire
qos-test run.
We can change each test to clean after themselves. This approach would
make the 'create' tests obsolete since we would need to create and
delete dirs/files/symlinks for the cleanup, turning them into the
'unlinkat' tests that comes right after.
We chose a different approach that handles the root cause: do not use
constructor/destructor to create the temp dir. Create one temp dir for
each test, and remove it after the test is complete. This is the
approach taken for other qtests like vhost-user-test.c where each test
requires a setup() and a subsequent cleanup(), all of those instantiated
in the .before callback.
[1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html
Reported-by: Thomas Huth
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20240327142011.805728-2-dbarb...@ventanamicro.com>
Reviewed-by: Greg Kurz
Reviewed-by: Christian Schoenebeck
Tested-by: Thomas Huth
Signed-off-by: Christian Schoenebeck
---
tests/qtest/virtio-9p-test.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 65e69491e5..0179b3a394 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -693,9 +693,20 @@ static void fs_unlinkat_hardlink(void *obj, void *data,
g_assert(stat(real_file, _real) == 0);
}
+static void cleanup_9p_local_driver(void *data)
+{
+/* remove previously created test dir when test is completed */
+virtio_9p_remove_local_test_dir();
+}
+
static void *assign_9p_local_driver(GString *cmd_line, void *arg)
{
+/* make sure test dir for the 'local' tests exists */
+virtio_9p_create_local_test_dir();
+
virtio_9p_assign_local_driver(cmd_line, "security_model=mapped-xattr");
+
+g_test_queue_destroy(cleanup_9p_local_driver, NULL);
return arg;
}
@@ -759,15 +770,3 @@ static void register_virtio_9p_test(void)
}
libqos_init(register_virtio_9p_test);
-
-static void __attribute__((constructor)) construct_9p_test(void)
-{
-/* make sure test dir for the 'local' tests exists */
-virtio_9p_create_local_test_dir();
-}
-
-static void __attribute__((destructor)) destruct_9p_test(void)
-{
-/* remove previously created test dir when test suite completed */
-virtio_9p_remove_local_test_dir();
-}
--
2.30.2
[PULL for-9.0 0/2] 9p queue 2024-03-29
The following changes since commit 5012e522aca161be5c141596c66e5cc6082538a9: Update version for v9.0.0-rc1 release (2024-03-26 19:46:55 +) are available in the Git repository at: https://github.com/cschoenebeck/qemu.git tags/pull-9p-20240329 for you to fetch changes up to dcae75fba1084823d0fc87caa13f0ba6f32155f3: qtest/virtio-9p-test.c: remove g_test_slow() gate (2024-03-28 09:54:47 +0100) Changes for 9p tests only: * Fix 9p tests for riscv. * Re-enable 9p 'local' tests for running in CI pipelines. Daniel Henrique Barboza (2): qtest/virtio-9p-test.c: create/remove temp dirs after each test qtest/virtio-9p-test.c: remove g_test_slow() gate tests/qtest/virtio-9p-test.c | 32 +++- 1 file changed, 11 insertions(+), 21 deletions(-)
Re: [PATCH for-9.0 v3 0/2] qtest/virtio-9p-test.c: fix slow tests
On Wednesday, March 27, 2024 3:20:09 PM CET Daniel Henrique Barboza wrote: > Hi, > > In this new version we took a different approach after the discussions > we had in [1]. The tests are now untouched, and we're addressing the root > cause directly: the fact that we have a single temp dir for all the test > execution in qos-test. > > We're now creating and cleaning temp dirs for each individual test by > calling virtio_9p_create_local_test_dir() in the .before callback for > the local 9p tests (assign_9p_local_driver()). In this same callback we > queue the cleanup function that will erase the created temp dir. The > cleanup will run after the test ran successfully. > > This approach is similar to what other qtests do (in fact this design was > taken from vhost-user-test.c) so it's not like we're doing something > novel. > > I kept the revert of the slow test gate because Gitlab seems to approve > it: > > https://gitlab.com/danielhb/qemu/-/pipelines/1229836634 > > Feel free to take just patch 1 if we're not sure about re-enabling these > tests in Gitlab. > > > Changes from v3: > - patches 1 to 6: dropped > - patch 1 (new): > - create and remove temporary dirs on each test > - v2 link: https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg06335.html > > [1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg06400.html > > Daniel Henrique Barboza (2): > qtest/virtio-9p-test.c: create/remove temp dirs after each test > qtest/virtio-9p-test.c: remove g_test_slow() gate > > tests/qtest/virtio-9p-test.c | 32 +++- > 1 file changed, 11 insertions(+), 21 deletions(-) Queued on 9p.next: https://github.com/cschoenebeck/qemu/commits/9p.next Thanks! /Christian
Re: [PATCH for-9.0 v3 0/2] qtest/virtio-9p-test.c: fix slow tests
On Wednesday, March 27, 2024 3:20:09 PM CET Daniel Henrique Barboza wrote: > Hi, > > In this new version we took a different approach after the discussions > we had in [1]. The tests are now untouched, and we're addressing the root > cause directly: the fact that we have a single temp dir for all the test > execution in qos-test. > > We're now creating and cleaning temp dirs for each individual test by > calling virtio_9p_create_local_test_dir() in the .before callback for > the local 9p tests (assign_9p_local_driver()). In this same callback we > queue the cleanup function that will erase the created temp dir. The > cleanup will run after the test ran successfully. > > This approach is similar to what other qtests do (in fact this design was > taken from vhost-user-test.c) so it's not like we're doing something > novel. > > I kept the revert of the slow test gate because Gitlab seems to approve > it: > > https://gitlab.com/danielhb/qemu/-/pipelines/1229836634 > > Feel free to take just patch 1 if we're not sure about re-enabling these > tests in Gitlab. > > > Changes from v3: > - patches 1 to 6: dropped > - patch 1 (new): > - create and remove temporary dirs on each test > - v2 link: https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg06335.html > > [1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg06400.html > > Daniel Henrique Barboza (2): > qtest/virtio-9p-test.c: create/remove temp dirs after each test > qtest/virtio-9p-test.c: remove g_test_slow() gate > > tests/qtest/virtio-9p-test.c | 32 +++- > 1 file changed, 11 insertions(+), 21 deletions(-) > > Awesome! Reviewed-by: Christian Schoenebeck Are the riscv patches already on master? I.e. should I push those two patches through my queue? /Christian
Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests
On Wednesday, March 27, 2024 12:28:17 PM CET Daniel Henrique Barboza wrote: > On 3/27/24 07:14, Christian Schoenebeck wrote: > > On Wednesday, March 27, 2024 10:33:27 AM CET Daniel Henrique Barboza wrote: > >> On 3/27/24 05:47, Christian Schoenebeck wrote: > >>> On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote: > >>>> On 3/26/24 14:05, Greg Kurz wrote: > >>>>> On Tue, 26 Mar 2024 10:26:04 -0300 > >>>>> Daniel Henrique Barboza wrote: > >>>>> > >>>>>> The local 9p driver in virtio-9p-test.c its temporary dir right at the > >>>>>> start of qos-test (via virtio_9p_create_local_test_dir()) and only > >>>>>> deletes it after qos-test is finished (via > >>>>>> virtio_9p_remove_local_test_dir()). > >>>>>> > >>>>>> This means that any qos-test machine that ends up running > >>>>>> virtio-9p-test local > >>>>>> tests more than once will end up re-using the same temp dir. This is > >>>>>> what's happening in [1] after we introduced the riscv machine nodes: if > >>>>>> we enable slow tests with the '-m slow' flag using qemu-system-riscv64, > >>>>>> this is what happens: > >>>>>> > >>>>>> - a temp dir is created, e.g. qtest-9p-local-WZLDL2; > >>>>>> > >>>>>> - virtio-9p-device tests will run virtio-9p-test successfully; > >>>>>> > >>>>>> - virtio-9p-pci tests will run virtio-9p-test, and fail right at the > >>>>>> first slow test at fs_create_dir() because the "01" file was > >>>>>> already > >>>>>> created by fs_create_dir() test when running with the > >>>>>> virtio-9p-device. > >>>>>> > >>>>>> We can fix it by making every test clean up their changes in the > >>>>>> filesystem after they're done. But we don't need every test either: > >>>>>> what fs_create_file() does is already exercised in fs_unlinkat_dir(), > >>>>>> i.e. a dir is created, verified to be created, and then removed. Fixing > >>>>>> fs_create_file() would turn it into fs_unlikat_dir(), so we don't need > >>>>>> both. The same theme follows every test in virtio-9p-test.c, where the > >>>>>> 'unlikat' variant does the same thing the 'create' does but with some > >>>>>> cleaning in the end. > >>>>>> > >>>>>> Consolide some tests as follows: > >>>>>> > >>>>>> - fs_create_dir() is removed. fs_unlinkat_dir() is renamed to > >>>>>> fs_create_unlinkat_dir(); > >>>>>> > >>>>>> - fs_create_file() is removed. fs_unlinkat_file() is renamed to > >>>>>> fs_create_unlinkat_file(). The "04" dir it uses is now being > >>>>>> removed; > >>>>>> > >>>>>> - fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to > >>>>>> fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it > >>>>>> creates is now being removed. > >>>>>> > >>>>> > >>>>> The change looks good functionally but it breaks the legitimate > >>>>> assumption > >>>>> that files "06/*" come from test #6 and so on... I think you should > >>>>> consider > >>>>> renumbering to avoid confusion when debugging logs. > >>>>> > >>>>> Since this will bring more hunks, please split this in enough reviewable > >>>>> patches. > >>>> > >>>> Fair enough. Let me cook a v2. Thanks, > >>> > >>> Wouldn't it be much simpler to just change the name of the temporary > >>> directory, such that it contains the device name as well? Then these tests > >>> runs would run on independent directories and won't interfere with each > >>> other > >>> and that wouldn't need much changes I guess. > >> > >> That's true. If we were just trying to fix the issue then I would go with > >> this > >> approach since it's simpler. But given that we're also cutting half the > >> tests while > >> retai
Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests
On Wednesday, March 27, 2024 10:33:27 AM CET Daniel Henrique Barboza wrote: > On 3/27/24 05:47, Christian Schoenebeck wrote: > > On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote: > >> On 3/26/24 14:05, Greg Kurz wrote: > >>> On Tue, 26 Mar 2024 10:26:04 -0300 > >>> Daniel Henrique Barboza wrote: > >>> > >>>> The local 9p driver in virtio-9p-test.c its temporary dir right at the > >>>> start of qos-test (via virtio_9p_create_local_test_dir()) and only > >>>> deletes it after qos-test is finished (via > >>>> virtio_9p_remove_local_test_dir()). > >>>> > >>>> This means that any qos-test machine that ends up running virtio-9p-test > >>>> local > >>>> tests more than once will end up re-using the same temp dir. This is > >>>> what's happening in [1] after we introduced the riscv machine nodes: if > >>>> we enable slow tests with the '-m slow' flag using qemu-system-riscv64, > >>>> this is what happens: > >>>> > >>>> - a temp dir is created, e.g. qtest-9p-local-WZLDL2; > >>>> > >>>> - virtio-9p-device tests will run virtio-9p-test successfully; > >>>> > >>>> - virtio-9p-pci tests will run virtio-9p-test, and fail right at the > >>>> first slow test at fs_create_dir() because the "01" file was already > >>>> created by fs_create_dir() test when running with the > >>>> virtio-9p-device. > >>>> > >>>> We can fix it by making every test clean up their changes in the > >>>> filesystem after they're done. But we don't need every test either: > >>>> what fs_create_file() does is already exercised in fs_unlinkat_dir(), > >>>> i.e. a dir is created, verified to be created, and then removed. Fixing > >>>> fs_create_file() would turn it into fs_unlikat_dir(), so we don't need > >>>> both. The same theme follows every test in virtio-9p-test.c, where the > >>>> 'unlikat' variant does the same thing the 'create' does but with some > >>>> cleaning in the end. > >>>> > >>>> Consolide some tests as follows: > >>>> > >>>> - fs_create_dir() is removed. fs_unlinkat_dir() is renamed to > >>>> fs_create_unlinkat_dir(); > >>>> > >>>> - fs_create_file() is removed. fs_unlinkat_file() is renamed to > >>>> fs_create_unlinkat_file(). The "04" dir it uses is now being removed; > >>>> > >>>> - fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to > >>>> fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it > >>>> creates is now being removed. > >>>> > >>> > >>> The change looks good functionally but it breaks the legitimate > >>> assumption > >>> that files "06/*" come from test #6 and so on... I think you should > >>> consider > >>> renumbering to avoid confusion when debugging logs. > >>> > >>> Since this will bring more hunks, please split this in enough reviewable > >>> patches. > >> > >> Fair enough. Let me cook a v2. Thanks, > > > > Wouldn't it be much simpler to just change the name of the temporary > > directory, such that it contains the device name as well? Then these tests > > runs would run on independent directories and won't interfere with each > > other > > and that wouldn't need much changes I guess. > > That's true. If we were just trying to fix the issue then I would go with this > approach since it's simpler. But given that we're also cutting half the tests > while > retaining the coverage I think this approach is worth the extra code. Well, I am actually not so keen into all those changes. These tests were intentionally split, and yes with costs of a bit redundant (test case) code. But they were cleanly build up on each other, from fundamental requirements like whether it is possible to create a directory and file ... and then the subsequent tests would become more and more demanding. That way it was easier to review if somebody reports a test to fail, because you could immediately see whether the preceding fundamental tests succeeded. /Christian
Re: [PATCH for-9.0 0/3] qtest/virtio-9p-test.c: fix slow tests
On Tuesday, March 26, 2024 5:07:16 PM CET Daniel Henrique Barboza wrote:
>
> On 3/26/24 12:55, Greg Kurz wrote:
> > Bom dia Daniel !
>
> Bonne après-midi !
>
> >
> > On Tue, 26 Mar 2024 10:26:03 -0300
> > Daniel Henrique Barboza wrote:
> >
> >> Hi,
> >>
> >> Thomas reported in [1] a problem that happened with the RISC-V machine
> >> where some tests from virtio-9p-test.c were failing with '-m slow', i.e.
> >> enabling slow tests.
> >>
> >> In the end it wasn't a RISC-V specific problem. It just so happens that
> >> the recently added riscv machine nodes runs the tests from
> >> virtio-9p-test two times for each qos-test run: one with the
> >> virtio-9p-device device and another with the virtio-9p-pci. The temp dir
> >> for these tests is being created at the start of qos-test and removed
> >> only at the end of qos-test, and the tests are leaving dirs and files
> >> behind. virtio-9-device tests run first, creates stuff in the temp dir,
> >> then when virtio-9p-pci tests runs again it'll fail because the previous
> >> run left created dirs and files in the same temp dir. Here's a run that
> >> exemplifies the problem:
> >>
> >> $ MALLOC_PERTURB_=21 V=2 QTEST_QEMU_BINARY=./qemu-system-riscv64
> >> ./tests/qtest/qos-test -m slow
> >> (...)
> >> # starting QEMU: exec ./qemu-system-riscv64 -qtest
> >> unix:/tmp/qtest-621710.sock -qtest-log /dev/null -chardev
> >> socket,path=/tmp/qtest-621710.qmp,id=char0 -mon chardev=char0,mode=control
> >> -display none -audio none -M virt,aclint=on,aia=aplic-imsic -fsdev
> >> local,id=fsdev0,path='/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2',security_model=mapped-xattr
> >> -device virtio-9p-device,fsdev=fsdev0,mount_tag=qtest -accel qtest
> >> ( goes ok ...)
> >> # starting QEMU: exec ./qemu-system-riscv64 -qtest
> >> unix:/tmp/qtest-621710.sock -qtest-log /dev/null -chardev
> >> socket,path=/tmp/qtest-621710.qmp,id=char0 -mon chardev=char0,mode=control
> >> -display none -audio none -M virt,aclint=on,aia=aplic-imsic -fsdev
> >> local,id=fsdev0,path='/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2',security_model=mapped-xattr
> >> -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
> >> ok 168
> >> /riscv64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
> >> Received response 7 (RLERROR) instead of 73 (RMKDIR)
> >> Rlerror has errno 17 (File exists)
> >> **
> >> ERROR:../tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv:
> >> assertion failed (hdr.id == id): (7 == 73)
> >>
> >> As we can see we're running both 'virtio-9p-device' tests and
> >> 'virtio-9p-pci'
> >> tests using the same '/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2'
> >> temp dir.
> >>
> >
> >
> > Good catch ! I'll try to find some time to review.
> >
> >> The quick fix I came up with was to make each test clean themselves up
> >> after each run. The tests were also consolidated, i.e. fewer tests with the
> >> same coverage, because the 'unlikat' tests were doing the same thing the
> >> 'create' tests were doing but removing stuff after. Might as well keep just
> >> the 'unlikat' tests.
> >>
> >
> > As long as coverage is preserved, I'm fine with consolidation of the
> > checks. In any case, last call goes to Christian.
> >
> >> I also went ahead and reverted 558f5c42efd ("tests/9pfs: Mark "local"
> >> tests as "slow"") after realizing that the problem I was fixing is also
> >> the same problem that this patch was trying to working around with the
> >> skip [2]. I validated this change in this Gitlab pipeline:
> >>
> >
> > Are you sure with that ? Issues look very similar indeed but not
> > exactly the same.
>
> We can skip this revert if we're not sure about it. Gitlab passed with it but
> perhaps this isn't evidence enough. I'll let you guys decide.
I am a bit surprised because errnos were different (file exists vs. not
supported), but indeed, it did pass in your Gitlab pipeline. So I am fine with
bringing those tests back in on Gitlab.
/Christian
Re: [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests
On Tuesday, March 26, 2024 6:47:17 PM CET Daniel Henrique Barboza wrote: > On 3/26/24 14:05, Greg Kurz wrote: > > On Tue, 26 Mar 2024 10:26:04 -0300 > > Daniel Henrique Barboza wrote: > > > >> The local 9p driver in virtio-9p-test.c its temporary dir right at the > >> start of qos-test (via virtio_9p_create_local_test_dir()) and only > >> deletes it after qos-test is finished (via > >> virtio_9p_remove_local_test_dir()). > >> > >> This means that any qos-test machine that ends up running virtio-9p-test > >> local > >> tests more than once will end up re-using the same temp dir. This is > >> what's happening in [1] after we introduced the riscv machine nodes: if > >> we enable slow tests with the '-m slow' flag using qemu-system-riscv64, > >> this is what happens: > >> > >> - a temp dir is created, e.g. qtest-9p-local-WZLDL2; > >> > >> - virtio-9p-device tests will run virtio-9p-test successfully; > >> > >> - virtio-9p-pci tests will run virtio-9p-test, and fail right at the > >>first slow test at fs_create_dir() because the "01" file was already > >>created by fs_create_dir() test when running with the virtio-9p-device. > >> > >> We can fix it by making every test clean up their changes in the > >> filesystem after they're done. But we don't need every test either: > >> what fs_create_file() does is already exercised in fs_unlinkat_dir(), > >> i.e. a dir is created, verified to be created, and then removed. Fixing > >> fs_create_file() would turn it into fs_unlikat_dir(), so we don't need > >> both. The same theme follows every test in virtio-9p-test.c, where the > >> 'unlikat' variant does the same thing the 'create' does but with some > >> cleaning in the end. > >> > >> Consolide some tests as follows: > >> > >> - fs_create_dir() is removed. fs_unlinkat_dir() is renamed to > >>fs_create_unlinkat_dir(); > >> > >> - fs_create_file() is removed. fs_unlinkat_file() is renamed to > >>fs_create_unlinkat_file(). The "04" dir it uses is now being removed; > >> > >> - fs_symlink_file() is removed. fs_unlinkat_symlink() is renamed to > >>fs_create_unlinkat_symlink(). Both "real_file" and the "06" dir it > >>creates is now being removed. > >> > > > > The change looks good functionally but it breaks the legitimate assumption > > that files "06/*" come from test #6 and so on... I think you should consider > > renumbering to avoid confusion when debugging logs. > > > > Since this will bring more hunks, please split this in enough reviewable > > patches. > > Fair enough. Let me cook a v2. Thanks, Wouldn't it be much simpler to just change the name of the temporary directory, such that it contains the device name as well? Then these tests runs would run on independent directories and won't interfere with each other and that wouldn't need much changes I guess. /Christian
Re: [PULL 20/34] tests/libqos: add riscv/virt machine nodes
On Monday, March 25, 2024 1:35:52 PM CET Daniel Henrique Barboza wrote:
> On 3/25/24 06:20, Thomas Huth wrote:
> > On 08/03/2024 12.11, Alistair Francis wrote:
> >> From: Daniel Henrique Barboza
> >>
> >> Add a RISC-V 'virt' machine to the graph. This implementation is a
> >> modified copy of the existing arm machine in arm-virt-machine.c
> >>
> >> It contains a virtio-mmio and a generic-pcihost controller. The
> >> generic-pcihost controller hardcodes assumptions from the ARM 'virt'
> >> machine, like ecam and pio_base addresses, so we'll add an extra step to
> >> set its parameters after creating it.
> >>
> >> Our command line is incremented with 'aclint' parameters to allow the
> >> machine to run MSI tests.
> >>
> >> Signed-off-by: Daniel Henrique Barboza
> >> Acked-by: Alistair Francis
> >> Acked-by: Thomas Huth
> >> Message-ID: <20240217192607.32565-7-dbarb...@ventanamicro.com>
> >> Signed-off-by: Alistair Francis
> >> ---
> >
> > Hi!
> >
> > I noticed that "make check SPEED=slow" is now failing on the qos-test with
> > both, qemu-system-riscv32 and qemu-system-riscv64. Seems like it fails with
> > the virtio-9p test, when I run the qos-test manually, I get:
> >
> > $ MALLOC_PERTURB_=21 V=2 QTEST_QEMU_BINARY=./qemu-system-riscv64 \
> > tests/qtest/qos-test -m slow
> > ...
> > # Start of local tests
> > # starting QEMU: exec ./qemu-system-riscv64 -qtest
> > unix:/tmp/qtest-211303.sock -qtest-log /dev/null -chardev
> > socket,path=/tmp/qtest-211303.qmp,id=char0 -mon chardev=char0,mode=control
> > -display none -audio none -M virt,aclint=on,aia=aplic-imsic -fsdev
> > local,id=fsdev0,path='/home/thuth/tmp/qemu-build/qtest-9p-local-MBCML2',security_model=mapped-xattr
> > -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
> > ok 168
> > /riscv64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
> > Received response 7 (RLERROR) instead of 73 (RMKDIR)
> > Rlerror has errno 17 (File exists)
> > **
> > ERROR:../../devel/qemu/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv:
> > assertion failed (hdr.id == id): (7 == 73)
> > not ok
> > /riscv64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/create_dir
> > -
> > ERROR:../../devel/qemu/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv:
> > assertion failed (hdr.id == id): (7 == 73)
> > Bail out!
> > Aborted (core dumped)
> >
> > Could you please have a look? ... or if it is too cumbersome to fix, could
> > we please always skip the virtio-9p local tests on riscv ?
>
> I'll take a look.
>
> Do we run these slow tests in the Gitlab pipeline? I don't recall this
> particular test failing when I first introduced the riscv machine nodes.
No, the 'local' 9p tests were taken out by moving them to 'slow', because
these particular tests did not pass in the cloud and gitlab doesn't run
'slow':
commit 558f5c42efded3e0d0b20a90bce2a9a14580d824
Author: Greg Kurz
Date: Tue Nov 24 08:43:43 2020 +0100
tests/9pfs: Mark "local" tests as "slow"
The "local" tests can fail on some automated build systems as
reported here:
https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html
This will need to be investigated and addressed later. Let's go for a
workaround in the meantime : mark the "local" tests as "slow" so that
they aren't executed with a simple "make check" like in the case above.
Reported-by: Cole Robinson
Signed-off-by: Greg Kurz
Reviewed-by: Thomas Huth
Acked-by: Christian Schoenebeck
Message-Id: <160620382310.1423262.7364287092069513483.st...@bahia.lan>
Signed-off-by: Greg Kurz
Could be because the 'local' 9p backend needs xattr support which might not be
available with gitlab container's filesystem. But I haven't investigated.
The test that fails seems to be the same, just the errno is different in your
case.
Best regards,
Christian Schoenebeck
[PATCH 1/1] tests/9p: add 'use-after-unlink' test
After removing a file from the file system, we should still be able to
do I/O on the file if we already had it open before removal.
Signed-off-by: Christian Schoenebeck
---
OK, this was a bit surprising to me. I was expecting this test to fail,
but it works!
tests/qtest/virtio-9p-test.c | 41
1 file changed, 41 insertions(+)
diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
index 65e69491e5..7638c0a183 100644
--- a/tests/qtest/virtio-9p-test.c
+++ b/tests/qtest/virtio-9p-test.c
@@ -693,6 +693,45 @@ static void fs_unlinkat_hardlink(void *obj, void *data,
g_assert(stat(real_file, _real) == 0);
}
+static void fs_use_after_unlink(void *obj, void *data,
+QGuestAllocator *t_alloc)
+{
+QVirtio9P *v9p = obj;
+v9fs_set_allocator(t_alloc);
+static const uint32_t write_count = P9_MAX_SIZE / 2;
+g_autofree char *real_file = virtio_9p_test_path("09/doa_file");
+g_autofree char *buf = g_malloc0(write_count);
+struct stat st_file;
+uint32_t fid_file;
+uint32_t count;
+
+tattach({ .client = v9p });
+
+/* create a file "09/doa_file" and make sure it exists and is regular */
+tmkdir({ .client = v9p, .atPath = "/", .name = "09" });
+tlcreate({ .client = v9p, .atPath = "09", .name = "doa_file" });
+g_assert(stat(real_file, _file) == 0);
+g_assert((st_file.st_mode & S_IFMT) == S_IFREG);
+
+/* request a FID for that regular file that we can work with next */
+fid_file = twalk({
+.client = v9p, .fid = 0, .path = "09/doa_file"
+}).newfid;
+g_assert(fid_file != 0);
+
+/* now first open the file in write mode before ... */
+tlopen({ .client = v9p, .fid = fid_file, .flags = O_WRONLY });
+/* ... removing the file from file system */
+tunlinkat({ .client = v9p, .atPath = "09", .name = "doa_file" });
+
+/* file is removed, but we still have it open, so this should succeed */
+count = twrite({
+.client = v9p, .fid = fid_file, .offset = 0, .count = write_count,
+.data = buf
+}).count;
+g_assert_cmpint(count, ==, write_count);
+}
+
static void *assign_9p_local_driver(GString *cmd_line, void *arg)
{
virtio_9p_assign_local_driver(cmd_line, "security_model=mapped-xattr");
@@ -756,6 +795,8 @@ static void register_virtio_9p_test(void)
qos_add_test("local/hardlink_file", "virtio-9p", fs_hardlink_file, );
qos_add_test("local/unlinkat_hardlink", "virtio-9p", fs_unlinkat_hardlink,
);
+qos_add_test("local/use_after_unlink", "virtio-9p", fs_use_after_unlink,
+ );
}
libqos_init(register_virtio_9p_test);
--
2.30.2
Re: [PATCH 2/6] hw/9pfs/9p-synth: Use RCU_READ macro
On Wednesday, January 24, 2024 8:41:57 AM CET Philippe Mathieu-Daudé wrote:
> Replace the manual rcu_read_(un)lock calls by the
> WITH_RCU_READ_LOCK_GUARD macro (See commit ef46ae67ba
> "docs/style: call out the use of GUARD macros").
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Acked-by: Christian Schoenebeck
> hw/9pfs/9p-synth.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
> index 0ac79a500b..419ea69e3a 100644
> --- a/hw/9pfs/9p-synth.c
> +++ b/hw/9pfs/9p-synth.c
> @@ -241,15 +241,15 @@ static struct dirent *synth_get_dentry(V9fsSynthNode
> *dir,
> int i = 0;
> V9fsSynthNode *node;
>
> -rcu_read_lock();
> -QLIST_FOREACH(node, >child, sibling) {
> -/* This is the off child of the directory */
> -if (i == off) {
> -break;
> +WITH_RCU_READ_LOCK_GUARD() {
> +QLIST_FOREACH(node, >child, sibling) {
> +/* This is the off child of the directory */
> +if (i == off) {
> +break;
> +}
> +i++;
> }
> -i++;
> }
> -rcu_read_unlock();
> if (!node) {
> /* end of directory */
> return NULL;
> @@ -494,13 +494,13 @@ static int synth_name_to_path(FsContext *ctx, V9fsPath
> *dir_path,
> goto out;
> }
> /* search for the name in the children */
> -rcu_read_lock();
> -QLIST_FOREACH(node, _node->child, sibling) {
> -if (!strcmp(node->name, name)) {
> -break;
> +WITH_RCU_READ_LOCK_GUARD() {
> +QLIST_FOREACH(node, _node->child, sibling) {
> +if (!strcmp(node->name, name)) {
> +break;
> +}
> }
> }
> -rcu_read_unlock();
>
> if (!node) {
> errno = ENOENT;
>
Re: [PATCH 20/71] hw/9pfs: Constify VMState
On Monday, November 6, 2023 7:57:36 AM CET Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
Acked-by: Christian Schoenebeck
> hw/9pfs/virtio-9p-device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> index 5f522e68e9..efa41cfd73 100644
> --- a/hw/9pfs/virtio-9p-device.c
> +++ b/hw/9pfs/virtio-9p-device.c
> @@ -237,7 +237,7 @@ static const VMStateDescription vmstate_virtio_9p = {
> .name = "virtio-9p",
> .minimum_version_id = 1,
> .version_id = 1,
> -.fields = (VMStateField[]) {
> +.fields = (const VMStateField[]) {
> VMSTATE_VIRTIO_DEVICE,
> VMSTATE_END_OF_LIST()
> },
>
Re: [PATCH 2/2] audio/jackaudio: Avoid dynamic stack allocation in qjack_process()
On Friday, August 18, 2023 5:58:46 PM CEST Peter Maydell wrote:
> Avoid a dynamic stack allocation in qjack_process(). Since this
> function is a JACK process callback, we are not permitted to malloc()
> here, so we allocate a working buffer in qjack_client_init() instead.
>
> The codebase has very few VLAs, and if we can get rid of them all we
> can make the compiler error on new additions. This is a defensive
> measure against security bugs where an on-stack dynamic allocation
> isn't correctly size-checked (e.g. CVE-2021-3527).
>
> Signed-off-by: Peter Maydell
> ---
> This feels like we ought to be able to say "we know there are at most
> X channels, so allocate an array of size X on the stack", but I
> couldn't find anything in the audio subsystem from a quick look that
> set an obvious bound on the number of channels. Is there some
> straightforward constant MAX_CHANNELS somewhere?
> ---
The JACK API doesn't have an official limit on "ports", but AFAICS in QEMU
there is a limit of max. 16 audio channels for audio frontends.
The QEMU `channels` CL option is apparently not limited ATM, but it might make
sense to limit that option to 16 channels as well. I mean anything beyond 16th
channel was a dead channel anyway, right?
Probably a separate battle field though:
Reviewed-by: Christian Schoenebeck
> audio/jackaudio.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/audio/jackaudio.c b/audio/jackaudio.c
> index 7cb2a49f971..e1eaa3477dc 100644
> --- a/audio/jackaudio.c
> +++ b/audio/jackaudio.c
> @@ -70,6 +70,9 @@ typedef struct QJackClient {
> int buffersize;
> jack_port_t **port;
> QJackBuffer fifo;
> +
> +/* Used as workspace by qjack_process() */
> +float **process_buffers;
> }
> QJackClient;
>
> @@ -267,22 +270,21 @@ static int qjack_process(jack_nframes_t nframes, void
> *arg)
> }
>
> /* get the buffers for the ports */
> -float *buffers[c->nchannels];
> for (int i = 0; i < c->nchannels; ++i) {
> -buffers[i] = jack_port_get_buffer(c->port[i], nframes);
> +c->process_buffers[i] = jack_port_get_buffer(c->port[i], nframes);
> }
>
> if (c->out) {
> if (likely(c->enabled)) {
> -qjack_buffer_read_l(>fifo, buffers, nframes);
> +qjack_buffer_read_l(>fifo, c->process_buffers, nframes);
> } else {
> for (int i = 0; i < c->nchannels; ++i) {
> -memset(buffers[i], 0, nframes * sizeof(float));
> +memset(c->process_buffers[i], 0, nframes * sizeof(float));
> }
> }
> } else {
> if (likely(c->enabled)) {
> -qjack_buffer_write_l(>fifo, buffers, nframes);
> +qjack_buffer_write_l(>fifo, c->process_buffers, nframes);
> }
> }
>
> @@ -448,6 +450,9 @@ static int qjack_client_init(QJackClient *c)
>jack_get_client_name(c->client));
> }
>
> +/* Allocate working buffer for process callback */
> +c->process_buffers = g_new(float *, c->nchannels);
> +
> jack_set_process_callback(c->client, qjack_process , c);
> jack_set_port_registration_callback(c->client, qjack_port_registration,
> c);
> jack_set_xrun_callback(c->client, qjack_xrun, c);
> @@ -579,6 +584,7 @@ static void qjack_client_fini_locked(QJackClient *c)
>
> qjack_buffer_free(>fifo);
> g_free(c->port);
> +g_free(c->process_buffers);
>
> c->state = QJACK_STATE_DISCONNECTED;
> /* fallthrough */
>
Re: [PATCH 1/2] audio/jackaudio: Avoid dynamic stack allocation in qjack_client_init
On Friday, August 18, 2023 5:58:45 PM CEST Peter Maydell wrote:
> Avoid a dynamic stack allocation in qjack_client_init(), by using
> a g_autofree heap allocation instead.
>
> (We stick with allocate + snprintf() because the JACK API requires
> the name to be no more than its maximum size, so g_strdup_printf()
> would require an extra truncation step.)
>
> The codebase has very few VLAs, and if we can get rid of them all we
> can make the compiler error on new additions. This is a defensive
> measure against security bugs where an on-stack dynamic allocation
> isn't correctly size-checked (e.g. CVE-2021-3527).
Sounds good, what compiler flag will that be?
> Signed-off-by: Peter Maydell
> ---
> audio/jackaudio.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/audio/jackaudio.c b/audio/jackaudio.c
> index 5bdf3d7a78d..7cb2a49f971 100644
> --- a/audio/jackaudio.c
> +++ b/audio/jackaudio.c
> @@ -400,7 +400,8 @@ static void qjack_client_connect_ports(QJackClient *c)
> static int qjack_client_init(QJackClient *c)
> {
> jack_status_t status;
> -char client_name[jack_client_name_size()];
> +int client_name_len = jack_client_name_size(); /* includes NUL */
I would add `const` here.
> +g_autofree char *client_name = g_new(char, client_name_len);
> jack_options_t options = JackNullOption;
>
> if (c->state == QJACK_STATE_RUNNING) {
> @@ -409,7 +410,7 @@ static int qjack_client_init(QJackClient *c)
>
> c->connect_ports = true;
>
> -snprintf(client_name, sizeof(client_name), "%s-%s",
> +snprintf(client_name, client_name_len, "%s-%s",
> c->out ? "out" : "in",
> c->opt->client_name ? c->opt->client_name :
> audio_application_name());
Unrelated, but this could be shortened by Elvis operator BTW:
c->opt->client_name ?: audio_application_name()
Anyway:
Reviewed-by: Christian Schoenebeck
Best regards,
Christian Schoenebeck
Re: [PATCH, trivial 07/29] tree-wide spelling fixes in comments and some messages: hw/9pfs
On Friday, July 14, 2023 1:38:12 PM CEST Michael Tokarev wrote:
> Signed-off-by: Michael Tokarev
> ---
> hw/9pfs/9p-local.c | 8
> hw/9pfs/9p-proxy.c | 2 +-
> hw/9pfs/9p-synth.c | 2 +-
> hw/9pfs/9p-util.h | 2 +-
> hw/9pfs/9p.c | 4 ++--
> hw/9pfs/9p.h | 2 +-
> 6 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index 9d07620235..1b1f3b9ec8 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -626,3 +626,3 @@ static ssize_t local_pwritev(FsContext *ctx,
> V9fsFidOpenState *fs,
> * We want to ensure that we don't leave dirty pages in the cache
> - * after write when writeout=immediate is sepcified.
> + * after write when writeout=immediate is specified.
> */
> @@ -845,3 +845,3 @@ static int local_open2(FsContext *fs_ctx, V9fsPath
> *dir_path, const char *name,
> if (fs_ctx->export_flags & V9FS_SM_MAPPED) {
> -/* Set cleint credentials in xattr */
> +/* Set client credentials in xattr */
> err = local_set_xattrat(dirfd, name, credp);
> @@ -914,3 +914,3 @@ static int local_symlink(FsContext *fs_ctx, const char
> *oldpath,
> }
> -/* Set cleint credentials in symlink's xattr */
> +/* Set client credentials in symlink's xattr */
> credp->fc_mode = credp->fc_mode | S_IFLNK;
> @@ -1420,3 +1420,3 @@ static int local_ioc_getversion_init(FsContext *ctx,
> LocalData *data, Error **er
> /*
> - * use ioc_getversion only if the ioctl is definied
> + * use ioc_getversion only if the ioctl is defined
> */
> diff --git a/hw/9pfs/9p-proxy.c b/hw/9pfs/9p-proxy.c
> index 905cae6992..7aac49ad4a 100644
> --- a/hw/9pfs/9p-proxy.c
> +++ b/hw/9pfs/9p-proxy.c
> @@ -769,3 +769,3 @@ static ssize_t proxy_pwritev(FsContext *ctx,
> V9fsFidOpenState *fs,
> * We want to ensure that we don't leave dirty pages in the cache
> - * after write when writeout=immediate is sepcified.
> + * after write when writeout=immediate is specified.
> */
> diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
> index f62c40b639..0ac79a500b 100644
> --- a/hw/9pfs/9p-synth.c
> +++ b/hw/9pfs/9p-synth.c
> @@ -495,3 +495,3 @@ static int synth_name_to_path(FsContext *ctx, V9fsPath
> *dir_path,
> }
> -/* search for the name in the childern */
> +/* search for the name in the children */
> rcu_read_lock();
> diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> index df1b583a5e..51c94b0116 100644
> --- a/hw/9pfs/9p-util.h
> +++ b/hw/9pfs/9p-util.h
> @@ -50,3 +50,3 @@ static inline uint64_t makedev_dotl(uint32_t dev_major,
> uint32_t dev_minor)
> * device number format. As both the size of type dev_t and encoding of
> - * dev_t is system dependant, we have to convert them for Linux guests if
> + * dev_t is system dependent, we have to convert them for Linux guests if
> * host is not running Linux.
That particular one is American English vs. British English, but OK, patch
LGTM:
Reviewed-by: Christian Schoenebeck
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index 991645adca..323f042e65 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -646,3 +646,3 @@ static inline uint64_t mirror64bit(uint64_t value)
> /*
> - * Parameter k for the Exponential Golomb algorihm to be used.
> + * Parameter k for the Exponential Golomb algorithm to be used.
> *
> @@ -1041,3 +1041,3 @@ static void coroutine_fn pdu_complete(V9fsPDU *pdu,
> ssize_t len)
> * rather than a consequence of the cancellation. However, if
> - * the operation completed (succesfully or with an error other
> + * the operation completed (successfully or with an error other
> * than caused be cancellation), we do send out that reply, both
> diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> index 1b0d805b9c..a6f59abccb 100644
> --- a/hw/9pfs/9p.h
> +++ b/hw/9pfs/9p.h
> @@ -306,3 +306,3 @@ typedef struct VariLenAffix {
> /*
> - * Lenght of the affix, that is how many (of the lowest) bits of
> ``value``
> + * Length of the affix, that is how many (of the lowest) bits of
> ``value``
> * must be used for appending/prepending this affix to its final
> resulting,
>
[PULL 0/2] 9p queue 2023-07-06
The following changes since commit 0618e72d64e434dd6f1bc38b107670474c49fb86: Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2023-07-04 18:40:13 +0200) are available in the Git repository at: https://github.com/cschoenebeck/qemu.git tags/pull-9p-20230706 for you to fetch changes up to 3548fa01511b4d8d19d4b187d3989b7033b733d8: MAINTAINERS: raise status of 9p to 'Maintained' (2023-07-06 11:42:08 +0200) Administrative changes only: * Deprecate 9p 'proxy' backend. * Raise status of 9p to 'Maintained'. Christian Schoenebeck (2): 9pfs: deprecate 'proxy' backend MAINTAINERS: raise status of 9p to 'Maintained' MAINTAINERS| 11 +-- docs/about/deprecated.rst | 23 +++ docs/tools/virtfs-proxy-helper.rst | 3 +++ fsdev/qemu-fsdev.c | 8 fsdev/virtfs-proxy-helper.c| 9 + hw/9pfs/9p-proxy.c | 5 + hw/9pfs/9p-proxy.h | 5 + meson.build| 2 +- qemu-options.hx| 6 +- 9 files changed, 68 insertions(+), 4 deletions(-)
[PULL 2/2] MAINTAINERS: raise status of 9p to 'Maintained'
Change status of 9p from 'Odd Fixes' to 'Maintained', as this better reflects current situation. I already take care of 9p patches for a while, which included new features as well. Based-on: Signed-off-by: Christian Schoenebeck Reviewed-by: Greg Kurz Reviewed-by: Philippe Mathieu-Daudé Message-Id: --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 80934ad2c3..d422ce50e3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2120,7 +2120,7 @@ F: include/sysemu/balloon.h virtio-9p M: Greg Kurz M: Christian Schoenebeck -S: Odd Fixes +S: Maintained W: https://wiki.qemu.org/Documentation/9p F: hw/9pfs/ X: hw/9pfs/xen-9p* -- 2.30.2
[PULL 1/2] 9pfs: deprecate 'proxy' backend
As recent CVE-2023-2861 (fixed by f6b0de53fb) once again showed, the 9p
'proxy' fs driver is in bad shape. Using the 'proxy' backend was already
discouraged for safety reasons before and we recommended to use the
'local' backend (preferably in conjunction with its 'mapped' security
model) instead, but now it is time to officially deprecate the 'proxy'
backend.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Message-Id:
---
MAINTAINERS| 9 -
docs/about/deprecated.rst | 23 +++
docs/tools/virtfs-proxy-helper.rst | 3 +++
fsdev/qemu-fsdev.c | 8
fsdev/virtfs-proxy-helper.c| 9 +
hw/9pfs/9p-proxy.c | 5 +
hw/9pfs/9p-proxy.h | 5 +
meson.build| 2 +-
qemu-options.hx| 6 +-
9 files changed, 67 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7164cf55a1..80934ad2c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2124,13 +2124,20 @@ S: Odd Fixes
W: https://wiki.qemu.org/Documentation/9p
F: hw/9pfs/
X: hw/9pfs/xen-9p*
+X: hw/9pfs/9p-proxy*
F: fsdev/
-F: docs/tools/virtfs-proxy-helper.rst
+X: fsdev/virtfs-proxy-helper.c
F: tests/qtest/virtio-9p-test.c
F: tests/qtest/libqos/virtio-9p*
T: git https://gitlab.com/gkurz/qemu.git 9p-next
T: git https://github.com/cschoenebeck/qemu.git 9p.next
+virtio-9p-proxy
+F: hw/9pfs/9p-proxy*
+F: fsdev/virtfs-proxy-helper.c
+F: docs/tools/virtfs-proxy-helper.rst
+S: Obsolete
+
virtio-blk
M: Stefan Hajnoczi
L: qemu-bl...@nongnu.org
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..ddc1e48460 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -343,6 +343,29 @@ the addition of volatile memory support, it is now
necessary to distinguish
between persistent and volatile memory backends. As such, memdev is deprecated
in favor of persistent-memdev.
+``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
+^^
+
+The 9p ``proxy`` filesystem backend driver has been deprecated and will be
+removed (along with its proxy helper daemon) in a future version of QEMU.
Please
+use ``-fsdev local`` or ``-virtfs local`` for using the 9p ``local`` filesystem
+backend, or alternatively consider deploying virtiofsd instead.
+
+The 9p ``proxy`` backend was originally developed as an alternative to the 9p
+``local`` backend. The idea was to enhance security by dispatching actual low
+level filesystem operations from 9p server (QEMU process) over to a separate
+process (the virtfs-proxy-helper binary). However this alternative never gained
+momentum. The proxy backend is much slower than the local backend, hasn't seen
+any development in years, and showed to be less secure, especially due to the
+fact that its helper daemon must be run as root, whereas with the local backend
+QEMU is typically run as unprivileged user and allows to tighten behaviour by
+mapping permissions et al by using its 'mapped' security model option.
+
+Nowadays it would make sense to reimplement the ``proxy`` backend by using
+QEMU's ``vhost`` feature, which would eliminate the high latency costs under
+which the 9p ``proxy`` backend currently suffers. However as of to date nobody
+has indicated plans for such kind of reimplemention unfortunately.
+
Block device options
diff --git a/docs/tools/virtfs-proxy-helper.rst
b/docs/tools/virtfs-proxy-helper.rst
index 6cdeedf8e9..bd310ebb07 100644
--- a/docs/tools/virtfs-proxy-helper.rst
+++ b/docs/tools/virtfs-proxy-helper.rst
@@ -9,6 +9,9 @@ Synopsis
Description
---
+NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
+removed, along with this daemon, in a future version of QEMU!
+
Pass-through security model in QEMU 9p server needs root privilege to do
few file operations (like chown, chmod to any mode/uid:gid). There are two
issues in pass-through security model:
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 3da64e9f72..f5c953a710 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -133,6 +133,14 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
}
if (fsdriver) {
+if (strncmp(fsdriver, "proxy", 5) == 0) {
+warn_report(
+"'-fsdev proxy' and '-virtfs proxy' are deprecated, use "
+"'local' instead of 'proxy, or consider deploying virtiofsd "
+"as alternative to 9p"
+);
+}
+
for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
break;
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index d9511f429c..144aaf585a 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -9,6 +9,11 @@
*
Re: [PATCH] MAINTAINERS: raise status of 9p to 'Maintained'
On Monday, July 3, 2023 4:50:42 PM CEST Greg Kurz wrote: > On Mon, 3 Jul 2023 16:34:17 +0200 > Christian Schoenebeck wrote: > > > Change status of 9p from 'Odd Fixes' to 'Maintained', as this better > > reflects current situation. I already take care of 9p patches for a > > while, which included new features as well. > > > > Thanks for the good work ! :-) And I have to repay that tribute to you as well of course, thanks for taking care! :) Queued on 9p.next: https://github.com/cschoenebeck/qemu/commits/9p.next Thanks! Best regards, Christian Schoenebeck
[PATCH] MAINTAINERS: raise status of 9p to 'Maintained'
Change status of 9p from 'Odd Fixes' to 'Maintained', as this better reflects current situation. I already take care of 9p patches for a while, which included new features as well. Based-on: Signed-off-by: Christian Schoenebeck --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e8a3205eb4..71f2479ec5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2120,7 +2120,7 @@ F: include/sysemu/balloon.h virtio-9p M: Greg Kurz M: Christian Schoenebeck -S: Odd Fixes +S: Maintained W: https://wiki.qemu.org/Documentation/9p F: hw/9pfs/ X: hw/9pfs/xen-9p* -- 2.30.2
Re: [PATCH v5] 9pfs: deprecate 'proxy' backend
On Monday, June 26, 2023 1:49:06 PM CEST Christian Schoenebeck wrote: > As recent CVE-2023-2861 (fixed by f6b0de53fb) once again showed, the 9p > 'proxy' fs driver is in bad shape. Using the 'proxy' backend was already > discouraged for safety reasons before and we recommended to use the > 'local' backend (preferably in conjunction with its 'mapped' security > model) instead, but now it is time to officially deprecate the 'proxy' > backend. > > Signed-off-by: Christian Schoenebeck > Reviewed-by: Greg Kurz > --- > v4 -> v5: > - Eliminate repititve use of word 'instead' in text. > - Commit log: mention exact commit which fixed CVE-2023-2861. Queued on 9p.next: https://github.com/cschoenebeck/qemu/commits/9p.next Thanks! Best regards, Christian Schoenebeck
[PATCH v5] 9pfs: deprecate 'proxy' backend
As recent CVE-2023-2861 (fixed by f6b0de53fb) once again showed, the 9p
'proxy' fs driver is in bad shape. Using the 'proxy' backend was already
discouraged for safety reasons before and we recommended to use the
'local' backend (preferably in conjunction with its 'mapped' security
model) instead, but now it is time to officially deprecate the 'proxy'
backend.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
---
v4 -> v5:
- Eliminate repititve use of word 'instead' in text.
- Commit log: mention exact commit which fixed CVE-2023-2861.
MAINTAINERS| 9 -
docs/about/deprecated.rst | 23 +++
docs/tools/virtfs-proxy-helper.rst | 3 +++
fsdev/qemu-fsdev.c | 8
fsdev/virtfs-proxy-helper.c| 9 +
hw/9pfs/9p-proxy.c | 5 +
hw/9pfs/9p-proxy.h | 5 +
meson.build| 2 +-
qemu-options.hx| 6 +-
9 files changed, 67 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e07746ac7d..42f2897d5e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2124,13 +2124,20 @@ S: Odd Fixes
W: https://wiki.qemu.org/Documentation/9p
F: hw/9pfs/
X: hw/9pfs/xen-9p*
+X: hw/9pfs/9p-proxy*
F: fsdev/
-F: docs/tools/virtfs-proxy-helper.rst
+X: fsdev/virtfs-proxy-helper.c
F: tests/qtest/virtio-9p-test.c
F: tests/qtest/libqos/virtio-9p*
T: git https://gitlab.com/gkurz/qemu.git 9p-next
T: git https://github.com/cschoenebeck/qemu.git 9p.next
+virtio-9p-proxy
+F: hw/9pfs/9p-proxy*
+F: fsdev/virtfs-proxy-helper.c
+F: docs/tools/virtfs-proxy-helper.rst
+S: Obsolete
+
virtio-blk
M: Stefan Hajnoczi
L: qemu-bl...@nongnu.org
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..ddc1e48460 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -343,6 +343,29 @@ the addition of volatile memory support, it is now
necessary to distinguish
between persistent and volatile memory backends. As such, memdev is deprecated
in favor of persistent-memdev.
+``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
+^^
+
+The 9p ``proxy`` filesystem backend driver has been deprecated and will be
+removed (along with its proxy helper daemon) in a future version of QEMU.
Please
+use ``-fsdev local`` or ``-virtfs local`` for using the 9p ``local`` filesystem
+backend, or alternatively consider deploying virtiofsd instead.
+
+The 9p ``proxy`` backend was originally developed as an alternative to the 9p
+``local`` backend. The idea was to enhance security by dispatching actual low
+level filesystem operations from 9p server (QEMU process) over to a separate
+process (the virtfs-proxy-helper binary). However this alternative never gained
+momentum. The proxy backend is much slower than the local backend, hasn't seen
+any development in years, and showed to be less secure, especially due to the
+fact that its helper daemon must be run as root, whereas with the local backend
+QEMU is typically run as unprivileged user and allows to tighten behaviour by
+mapping permissions et al by using its 'mapped' security model option.
+
+Nowadays it would make sense to reimplement the ``proxy`` backend by using
+QEMU's ``vhost`` feature, which would eliminate the high latency costs under
+which the 9p ``proxy`` backend currently suffers. However as of to date nobody
+has indicated plans for such kind of reimplemention unfortunately.
+
Block device options
diff --git a/docs/tools/virtfs-proxy-helper.rst
b/docs/tools/virtfs-proxy-helper.rst
index 6cdeedf8e9..bd310ebb07 100644
--- a/docs/tools/virtfs-proxy-helper.rst
+++ b/docs/tools/virtfs-proxy-helper.rst
@@ -9,6 +9,9 @@ Synopsis
Description
---
+NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
+removed, along with this daemon, in a future version of QEMU!
+
Pass-through security model in QEMU 9p server needs root privilege to do
few file operations (like chown, chmod to any mode/uid:gid). There are two
issues in pass-through security model:
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 3da64e9f72..f5c953a710 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -133,6 +133,14 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
}
if (fsdriver) {
+if (strncmp(fsdriver, "proxy", 5) == 0) {
+warn_report(
+"'-fsdev proxy' and '-virtfs proxy' are deprecated, use "
+"'local' instead of 'proxy, or consider deploying virtiofsd "
+"as alternative to 9p"
+);
+}
+
for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
break;
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index d9511f42
Re: [PATCH v4] 9pfs: deprecate 'proxy' backend
On Monday, June 26, 2023 9:27:35 AM CEST Greg Kurz wrote: > On Fri, 23 Jun 2023 14:41:15 +0200 > Christian Schoenebeck wrote: > > > As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in > > bad shape. Using the 'proxy' backend was already discouraged for safety > > reasons before and we recommended to use the 'local' backend (preferably > > in conjunction with its 'mapped' security model) instead, but now it is > > time to officially deprecate the 'proxy' backend. > > > > Signed-off-by: Christian Schoenebeck > > --- > > v3 -> v4: > > - MAINTAINERS: also move virtfs-proxy-helper.rst to 'obsolete' section > > - deprecated.rst: suggest virtiofsd as alternative. > > - deprecated.rst: mention a considerable future reimplementation of > >'proxy' using 'vhost'. > > - QEMU runtime warning: merge deprecation warnings of '-virtfs proxy' and > >'-fsdev proxy' into a single deprecation warning and mention virtiofsd > >as alternative. > > - virtfs-proxy-helper daemon: print runtime deprecation warning here as > >well. > > - commit log: mention 'mapped' security model. > > > > MAINTAINERS| 9 - > > docs/about/deprecated.rst | 23 +++ > > docs/tools/virtfs-proxy-helper.rst | 3 +++ > > fsdev/qemu-fsdev.c | 8 > > fsdev/virtfs-proxy-helper.c| 9 + > > hw/9pfs/9p-proxy.c | 5 + > > hw/9pfs/9p-proxy.h | 5 + > > meson.build| 2 +- > > qemu-options.hx| 6 +- > > 9 files changed, 67 insertions(+), 3 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 436b3f0afe..3aa70b5c21 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -2118,13 +2118,20 @@ S: Odd Fixes > > W: https://wiki.qemu.org/Documentation/9p > > F: hw/9pfs/ > > X: hw/9pfs/xen-9p* > > +X: hw/9pfs/9p-proxy* > > F: fsdev/ > > -F: docs/tools/virtfs-proxy-helper.rst > > +X: fsdev/virtfs-proxy-helper.c > > F: tests/qtest/virtio-9p-test.c > > F: tests/qtest/libqos/virtio-9p* > > T: git https://gitlab.com/gkurz/qemu.git 9p-next > > T: git https://github.com/cschoenebeck/qemu.git 9p.next > > > > +virtio-9p-proxy > > +F: hw/9pfs/9p-proxy* > > +F: fsdev/virtfs-proxy-helper.c > > +F: docs/tools/virtfs-proxy-helper.rst > > +S: Obsolete > > + > > virtio-blk > > M: Stefan Hajnoczi > > L: qemu-bl...@nongnu.org > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst > > index 0743459862..4ce75722f3 100644 > > --- a/docs/about/deprecated.rst > > +++ b/docs/about/deprecated.rst > > @@ -343,6 +343,29 @@ the addition of volatile memory support, it is now > > necessary to distinguish > > between persistent and volatile memory backends. As such, memdev is > > deprecated > > in favor of persistent-memdev. > > > > +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1) > > +^^ > > + > > +The 9p ``proxy`` filesystem backend driver has been deprecated and will be > > +removed (along with its proxy helper daemon) in a future version of QEMU. > > Please > > +use ``-fsdev local`` or ``-virtfs local`` for using the 9p ``local`` > > filesystem > > +backend instead, or alternatively consider deploying virtiofsd instead. > > Maybe drop the first "instead" to avoid repetition ? Right, makes sense. > > + > > +The 9p ``proxy`` backend was originally developed as an alternative to the > > 9p > > +``local`` backend. The idea was to enhance security by dispatching actual > > low > > +level filesystem operations from 9p server (QEMU process) over to a > > separate > > +process (the virtfs-proxy-helper binary). However this alternative never > > gained > > +momentum. The proxy backend is much slower than the local backend, hasn't > > seen > > +any development in years, and showed to be less secure, especially due to > > the > > +fact that its helper daemon must be run as root, whereas with the local > > backend > > +QEMU is typically run as unprivileged user and allows to tighten behaviour > > by > > +mapping permissions et al by using its 'mapped' security model option. > > + > > +Nowadays it would make sense to reimplement the ``proxy`` backend by using > > +QEMU's ``vhost`` feature, which would eliminate the high latency costs > > unde
[PATCH v4] 9pfs: deprecate 'proxy' backend
As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in
bad shape. Using the 'proxy' backend was already discouraged for safety
reasons before and we recommended to use the 'local' backend (preferably
in conjunction with its 'mapped' security model) instead, but now it is
time to officially deprecate the 'proxy' backend.
Signed-off-by: Christian Schoenebeck
---
v3 -> v4:
- MAINTAINERS: also move virtfs-proxy-helper.rst to 'obsolete' section
- deprecated.rst: suggest virtiofsd as alternative.
- deprecated.rst: mention a considerable future reimplementation of
'proxy' using 'vhost'.
- QEMU runtime warning: merge deprecation warnings of '-virtfs proxy' and
'-fsdev proxy' into a single deprecation warning and mention virtiofsd
as alternative.
- virtfs-proxy-helper daemon: print runtime deprecation warning here as
well.
- commit log: mention 'mapped' security model.
MAINTAINERS| 9 -
docs/about/deprecated.rst | 23 +++
docs/tools/virtfs-proxy-helper.rst | 3 +++
fsdev/qemu-fsdev.c | 8
fsdev/virtfs-proxy-helper.c| 9 +
hw/9pfs/9p-proxy.c | 5 +
hw/9pfs/9p-proxy.h | 5 +
meson.build| 2 +-
qemu-options.hx| 6 +-
9 files changed, 67 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 436b3f0afe..3aa70b5c21 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2118,13 +2118,20 @@ S: Odd Fixes
W: https://wiki.qemu.org/Documentation/9p
F: hw/9pfs/
X: hw/9pfs/xen-9p*
+X: hw/9pfs/9p-proxy*
F: fsdev/
-F: docs/tools/virtfs-proxy-helper.rst
+X: fsdev/virtfs-proxy-helper.c
F: tests/qtest/virtio-9p-test.c
F: tests/qtest/libqos/virtio-9p*
T: git https://gitlab.com/gkurz/qemu.git 9p-next
T: git https://github.com/cschoenebeck/qemu.git 9p.next
+virtio-9p-proxy
+F: hw/9pfs/9p-proxy*
+F: fsdev/virtfs-proxy-helper.c
+F: docs/tools/virtfs-proxy-helper.rst
+S: Obsolete
+
virtio-blk
M: Stefan Hajnoczi
L: qemu-bl...@nongnu.org
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..4ce75722f3 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -343,6 +343,29 @@ the addition of volatile memory support, it is now
necessary to distinguish
between persistent and volatile memory backends. As such, memdev is deprecated
in favor of persistent-memdev.
+``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
+^^
+
+The 9p ``proxy`` filesystem backend driver has been deprecated and will be
+removed (along with its proxy helper daemon) in a future version of QEMU.
Please
+use ``-fsdev local`` or ``-virtfs local`` for using the 9p ``local`` filesystem
+backend instead, or alternatively consider deploying virtiofsd instead.
+
+The 9p ``proxy`` backend was originally developed as an alternative to the 9p
+``local`` backend. The idea was to enhance security by dispatching actual low
+level filesystem operations from 9p server (QEMU process) over to a separate
+process (the virtfs-proxy-helper binary). However this alternative never gained
+momentum. The proxy backend is much slower than the local backend, hasn't seen
+any development in years, and showed to be less secure, especially due to the
+fact that its helper daemon must be run as root, whereas with the local backend
+QEMU is typically run as unprivileged user and allows to tighten behaviour by
+mapping permissions et al by using its 'mapped' security model option.
+
+Nowadays it would make sense to reimplement the ``proxy`` backend by using
+QEMU's ``vhost`` feature, which would eliminate the high latency costs under
+which the 9p ``proxy`` backend currently suffers. However as of to date nobody
+has indicated plans for such kind of reimplemention unfortunately.
+
Block device options
diff --git a/docs/tools/virtfs-proxy-helper.rst
b/docs/tools/virtfs-proxy-helper.rst
index 6cdeedf8e9..bd310ebb07 100644
--- a/docs/tools/virtfs-proxy-helper.rst
+++ b/docs/tools/virtfs-proxy-helper.rst
@@ -9,6 +9,9 @@ Synopsis
Description
---
+NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
+removed, along with this daemon, in a future version of QEMU!
+
Pass-through security model in QEMU 9p server needs root privilege to do
few file operations (like chown, chmod to any mode/uid:gid). There are two
issues in pass-through security model:
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 3da64e9f72..9a50ee370b 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -133,6 +133,14 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
}
if (fsdriver) {
+if (strncmp(fsdriver, "proxy", 5) == 0) {
+warn_report(
+"'-fsdev proxy' and '-virtfs proxy' are deprecated, use "
+"'local' in
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend
On Wednesday, June 21, 2023 5:28:33 PM CEST Daniel P. Berrangé wrote:
[...]
> > > I'm fine with deprecating this. In terms of messaging wrt replacements,
> > > we should highlight both the 9p 'local' backend, and virtiofsd as the
> > > two alternatives. The latter is likely the better choice (on linux
> > > hosts) for many.
> >
> > OK, I can add that to the deprecation doc, but you don't want that to be
> > added to all the runtime warnings as well, do you?
>
> I'd suggest we could do mention it briefly as an option at rutime, eg
>
> warn_report("'-virtfs proxy' is deprecated, use '-virtfs local' or virtiofs
> instead");
I asked because with what Greg already suggested, it starts to become a long
runtime message, like:
"'-fsdev proxy' and '-virtfs proxy' are deprecated, use 'local' instead of
'proxy' or virtiofs"
And that's probably still ambiguous, becauses that might suggest people that
they could simply s/-virtfs proxy/-virtfs virtiofs/.
Low care rate on my end though.
Best regards,
Christian Schoenebeck
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend
On Wednesday, June 21, 2023 3:46:39 PM CEST Daniel P. Berrangé wrote: > On Sat, Jun 10, 2023 at 03:39:44PM +0200, Christian Schoenebeck wrote: > > +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1) > > +^^ > > + > > +The 9p ``proxy`` filesystem backend driver has been deprecated and will be > > +removed in a future version of QEMU. Please use ``-fsdev local`` or > > +``-virtfs local`` for using the ``local`` 9p filesystem backend instead. > > + > > +The 9p ``proxy`` backend was originally developed as an alternative to the > > 9p > > +``local`` backend. The idea was to enhance security by dispatching actual > > low > > +level filesystem operations from 9p server (QEMU process) over to a > > separate > > +process (the virtfs-proxy-helper binary). However this alternative never > > gained > > +momentum. The proxy backend is much slower than the local backend, hasn't > > seen > > +any development in years, and showed to be less secure, especially due to > > the > > +fact that its helper daemon must be run as root, whereas with the local > > backend > > +QEMU is typically run as unprivileged user and allows to tighten behaviour > > by > > +mapping permissions et al. > > The fact that the helper daemon runs as root was actually an intentional > design choice to improve security. When QEMU is running unprivileged, the > 'local' backend is limited in what it can serve to stuff that is readable/ > writable by the 'qemu' user account. > > Using the 'proxy' backend allowed that restriction to be lifted, such > that it can serve files owned by arbitrary users. > > Yes, the 'proxy' backend is less secure than the 'local' backend in an > unprivileged QEMU. It is massively more secure, however, than the 'local' > backend in a QEMU process running as root, which was the only option if > you need to serve files for many users. > > IOW, if someone is currently using the 'proxy' backend, the 'local' backend > is quite likely NOT a viable alternative. Depends. Some people just want to dump few files between host <-> guest, they should even be fine with unpriviliged 'passhthrough' security model with the 'local' backend. For more complex use cases, you would probably transition to 'mapped' security model with the 'local' backend. That's like transitioning from one file system to another, mounting the two, copying over once, that's it. > I'm fine with deprecating this. In terms of messaging wrt replacements, > we should highlight both the 9p 'local' backend, and virtiofsd as the > two alternatives. The latter is likely the better choice (on linux > hosts) for many. OK, I can add that to the deprecation doc, but you don't want that to be added to all the runtime warnings as well, do you? Best regards, Christian Schoenebeck
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend
On Wednesday, June 21, 2023 3:41:36 PM CEST Greg Kurz wrote: > On Wed, 21 Jun 2023 15:32:39 +0200 > Christian Schoenebeck wrote: > > > On Thursday, June 15, 2023 11:35:05 AM CEST Christian Schoenebeck wrote: > > > On Saturday, June 10, 2023 3:39:44 PM CEST Christian Schoenebeck wrote: > > > > As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in > > > > bad shape. Using the 'proxy' backend was already discouraged for safety > > > > reasons before and we recommended to use the 'local' backend instead, > > > > but now it is time to officially deprecate the 'proxy' backend. > > > > > > > > Signed-off-by: Christian Schoenebeck > > > > Ping > > > > It seems you missed the review I posted last week : > > https://patchew.org/QEMU/e1q7ytt-0005fl...@lizzy.crudebyte.com/ #20230612165742.ea08@bahia Oh, I never received your email. I'll check the logs what happened there. I'll send a v4 with your suggestions, they make sense. Do you want me to add your "for the records" comments as well in the deprecation notice? Best regards, Christian Schoenebeck
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend
On Thursday, June 15, 2023 11:35:05 AM CEST Christian Schoenebeck wrote: > On Saturday, June 10, 2023 3:39:44 PM CEST Christian Schoenebeck wrote: > > As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in > > bad shape. Using the 'proxy' backend was already discouraged for safety > > reasons before and we recommended to use the 'local' backend instead, > > but now it is time to officially deprecate the 'proxy' backend. > > > > Signed-off-by: Christian Schoenebeck Ping > > --- > > v2 -> v3: > > * Fix copy wasted typo (-> 'backend'). > > > > MAINTAINERS| 7 +++ > > docs/about/deprecated.rst | 17 + > > docs/tools/virtfs-proxy-helper.rst | 3 +++ > > fsdev/qemu-fsdev.c | 5 + > > fsdev/virtfs-proxy-helper.c| 5 + > > hw/9pfs/9p-proxy.c | 5 + > > hw/9pfs/9p-proxy.h | 5 + > > meson.build| 2 +- > > qemu-options.hx| 6 +- > > softmmu/vl.c | 5 + > > 10 files changed, 58 insertions(+), 2 deletions(-) > > Or would it be better to split this up, e.g. into 3 separate patches (runtime > messages, docs, MAINTAINERS)? > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 436b3f0afe..185d694b2e 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -2118,13 +2118,20 @@ S: Odd Fixes > > W: https://wiki.qemu.org/Documentation/9p > > F: hw/9pfs/ > > X: hw/9pfs/xen-9p* > > +X: hw/9pfs/9p-proxy* > > F: fsdev/ > > +X: fsdev/virtfs-proxy-helper.c > > F: docs/tools/virtfs-proxy-helper.rst > > I missed virtfs-proxy-helper.rst here. That should be moved to the new 'proxy' > section below as well. > > > F: tests/qtest/virtio-9p-test.c > > F: tests/qtest/libqos/virtio-9p* > > T: git https://gitlab.com/gkurz/qemu.git 9p-next > > T: git https://github.com/cschoenebeck/qemu.git 9p.next > > > > +virtio-9p-proxy > > +F: hw/9pfs/9p-proxy* > > +F: fsdev/virtfs-proxy-helper.c > > +S: Obsolete > > + > > virtio-blk > > M: Stefan Hajnoczi > > L: qemu-bl...@nongnu.org > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst > > index 0743459862..9b2c780365 100644 > > --- a/docs/about/deprecated.rst > > +++ b/docs/about/deprecated.rst > > @@ -343,6 +343,23 @@ the addition of volatile memory support, it is now > > necessary to distinguish > > between persistent and volatile memory backends. As such, memdev is > > deprecated > > in favor of persistent-memdev. > > > > +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1) > > +^^ > > + > > +The 9p ``proxy`` filesystem backend driver has been deprecated and will be > > +removed in a future version of QEMU. Please use ``-fsdev local`` or > > +``-virtfs local`` for using the ``local`` 9p filesystem backend instead. > > + > > +The 9p ``proxy`` backend was originally developed as an alternative to the > > 9p > > +``local`` backend. The idea was to enhance security by dispatching actual > > low > > +level filesystem operations from 9p server (QEMU process) over to a > > separate > > +process (the virtfs-proxy-helper binary). However this alternative never > > gained > > +momentum. The proxy backend is much slower than the local backend, hasn't > > seen > > +any development in years, and showed to be less secure, especially due to > > the > > +fact that its helper daemon must be run as root, whereas with the local > > backend > > +QEMU is typically run as unprivileged user and allows to tighten behaviour > > by > > +mapping permissions et al. > > + > > > > Block device options > > > > diff --git a/docs/tools/virtfs-proxy-helper.rst > > b/docs/tools/virtfs-proxy-helper.rst > > index 6cdeedf8e9..bd310ebb07 100644 > > --- a/docs/tools/virtfs-proxy-helper.rst > > +++ b/docs/tools/virtfs-proxy-helper.rst > > @@ -9,6 +9,9 @@ Synopsis > > Description > > --- > > > > +NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be > > +removed, along with this daemon, in a future version of QEMU! > > + > > Pass-through security model in QEMU 9p server needs root privilege to do > > few file operations (like chown, chmod to any mode/uid:gid). There are two > > issues in pass-through security model: > > diff -
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend
On Saturday, June 10, 2023 3:39:44 PM CEST Christian Schoenebeck wrote:
> As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in
> bad shape. Using the 'proxy' backend was already discouraged for safety
> reasons before and we recommended to use the 'local' backend instead,
> but now it is time to officially deprecate the 'proxy' backend.
>
> Signed-off-by: Christian Schoenebeck
> ---
> v2 -> v3:
> * Fix copy wasted typo (-> 'backend').
>
> MAINTAINERS| 7 +++
> docs/about/deprecated.rst | 17 +
> docs/tools/virtfs-proxy-helper.rst | 3 +++
> fsdev/qemu-fsdev.c | 5 +
> fsdev/virtfs-proxy-helper.c| 5 +
> hw/9pfs/9p-proxy.c | 5 +
> hw/9pfs/9p-proxy.h | 5 +
> meson.build| 2 +-
> qemu-options.hx| 6 +-
> softmmu/vl.c | 5 +
> 10 files changed, 58 insertions(+), 2 deletions(-)
Or would it be better to split this up, e.g. into 3 separate patches (runtime
messages, docs, MAINTAINERS)?
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 436b3f0afe..185d694b2e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2118,13 +2118,20 @@ S: Odd Fixes
> W: https://wiki.qemu.org/Documentation/9p
> F: hw/9pfs/
> X: hw/9pfs/xen-9p*
> +X: hw/9pfs/9p-proxy*
> F: fsdev/
> +X: fsdev/virtfs-proxy-helper.c
> F: docs/tools/virtfs-proxy-helper.rst
I missed virtfs-proxy-helper.rst here. That should be moved to the new 'proxy'
section below as well.
> F: tests/qtest/virtio-9p-test.c
> F: tests/qtest/libqos/virtio-9p*
> T: git https://gitlab.com/gkurz/qemu.git 9p-next
> T: git https://github.com/cschoenebeck/qemu.git 9p.next
>
> +virtio-9p-proxy
> +F: hw/9pfs/9p-proxy*
> +F: fsdev/virtfs-proxy-helper.c
> +S: Obsolete
> +
> virtio-blk
> M: Stefan Hajnoczi
> L: qemu-bl...@nongnu.org
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 0743459862..9b2c780365 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -343,6 +343,23 @@ the addition of volatile memory support, it is now
> necessary to distinguish
> between persistent and volatile memory backends. As such, memdev is
> deprecated
> in favor of persistent-memdev.
>
> +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
> +^^
> +
> +The 9p ``proxy`` filesystem backend driver has been deprecated and will be
> +removed in a future version of QEMU. Please use ``-fsdev local`` or
> +``-virtfs local`` for using the ``local`` 9p filesystem backend instead.
> +
> +The 9p ``proxy`` backend was originally developed as an alternative to the 9p
> +``local`` backend. The idea was to enhance security by dispatching actual low
> +level filesystem operations from 9p server (QEMU process) over to a separate
> +process (the virtfs-proxy-helper binary). However this alternative never
> gained
> +momentum. The proxy backend is much slower than the local backend, hasn't
> seen
> +any development in years, and showed to be less secure, especially due to the
> +fact that its helper daemon must be run as root, whereas with the local
> backend
> +QEMU is typically run as unprivileged user and allows to tighten behaviour by
> +mapping permissions et al.
> +
>
> Block device options
>
> diff --git a/docs/tools/virtfs-proxy-helper.rst
> b/docs/tools/virtfs-proxy-helper.rst
> index 6cdeedf8e9..bd310ebb07 100644
> --- a/docs/tools/virtfs-proxy-helper.rst
> +++ b/docs/tools/virtfs-proxy-helper.rst
> @@ -9,6 +9,9 @@ Synopsis
> Description
> ---
>
> +NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
> +removed, along with this daemon, in a future version of QEMU!
> +
> Pass-through security model in QEMU 9p server needs root privilege to do
> few file operations (like chown, chmod to any mode/uid:gid). There are two
> issues in pass-through security model:
> diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
> index 3da64e9f72..242f54ab49 100644
> --- a/fsdev/qemu-fsdev.c
> +++ b/fsdev/qemu-fsdev.c
> @@ -133,6 +133,11 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
> }
>
> if (fsdriver) {
> +if (strncmp(fsdriver, "proxy", 5) == 0) {
> +warn_report("'-fsdev proxy' is deprecated, use '-fsdev local' "
> +"instead");
> +}
> +
> for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
> if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
>
[PATCH v3] 9pfs: deprecate 'proxy' backend
As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in
bad shape. Using the 'proxy' backend was already discouraged for safety
reasons before and we recommended to use the 'local' backend instead,
but now it is time to officially deprecate the 'proxy' backend.
Signed-off-by: Christian Schoenebeck
---
v2 -> v3:
* Fix copy wasted typo (-> 'backend').
MAINTAINERS| 7 +++
docs/about/deprecated.rst | 17 +
docs/tools/virtfs-proxy-helper.rst | 3 +++
fsdev/qemu-fsdev.c | 5 +
fsdev/virtfs-proxy-helper.c| 5 +
hw/9pfs/9p-proxy.c | 5 +
hw/9pfs/9p-proxy.h | 5 +
meson.build| 2 +-
qemu-options.hx| 6 +-
softmmu/vl.c | 5 +
10 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 436b3f0afe..185d694b2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2118,13 +2118,20 @@ S: Odd Fixes
W: https://wiki.qemu.org/Documentation/9p
F: hw/9pfs/
X: hw/9pfs/xen-9p*
+X: hw/9pfs/9p-proxy*
F: fsdev/
+X: fsdev/virtfs-proxy-helper.c
F: docs/tools/virtfs-proxy-helper.rst
F: tests/qtest/virtio-9p-test.c
F: tests/qtest/libqos/virtio-9p*
T: git https://gitlab.com/gkurz/qemu.git 9p-next
T: git https://github.com/cschoenebeck/qemu.git 9p.next
+virtio-9p-proxy
+F: hw/9pfs/9p-proxy*
+F: fsdev/virtfs-proxy-helper.c
+S: Obsolete
+
virtio-blk
M: Stefan Hajnoczi
L: qemu-bl...@nongnu.org
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..9b2c780365 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -343,6 +343,23 @@ the addition of volatile memory support, it is now
necessary to distinguish
between persistent and volatile memory backends. As such, memdev is deprecated
in favor of persistent-memdev.
+``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
+^^
+
+The 9p ``proxy`` filesystem backend driver has been deprecated and will be
+removed in a future version of QEMU. Please use ``-fsdev local`` or
+``-virtfs local`` for using the ``local`` 9p filesystem backend instead.
+
+The 9p ``proxy`` backend was originally developed as an alternative to the 9p
+``local`` backend. The idea was to enhance security by dispatching actual low
+level filesystem operations from 9p server (QEMU process) over to a separate
+process (the virtfs-proxy-helper binary). However this alternative never gained
+momentum. The proxy backend is much slower than the local backend, hasn't seen
+any development in years, and showed to be less secure, especially due to the
+fact that its helper daemon must be run as root, whereas with the local backend
+QEMU is typically run as unprivileged user and allows to tighten behaviour by
+mapping permissions et al.
+
Block device options
diff --git a/docs/tools/virtfs-proxy-helper.rst
b/docs/tools/virtfs-proxy-helper.rst
index 6cdeedf8e9..bd310ebb07 100644
--- a/docs/tools/virtfs-proxy-helper.rst
+++ b/docs/tools/virtfs-proxy-helper.rst
@@ -9,6 +9,9 @@ Synopsis
Description
---
+NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
+removed, along with this daemon, in a future version of QEMU!
+
Pass-through security model in QEMU 9p server needs root privilege to do
few file operations (like chown, chmod to any mode/uid:gid). There are two
issues in pass-through security model:
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 3da64e9f72..242f54ab49 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -133,6 +133,11 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
}
if (fsdriver) {
+if (strncmp(fsdriver, "proxy", 5) == 0) {
+warn_report("'-fsdev proxy' is deprecated, use '-fsdev local' "
+"instead");
+}
+
for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
break;
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index d9511f429c..5dd5d99284 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -9,6 +9,11 @@
* the COPYING file in the top-level directory.
*/
+/*
+ * NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
+ * removed in a future version of QEMU!
+ */
+
#include "qemu/osdep.h"
#include
#include
diff --git a/hw/9pfs/9p-proxy.c b/hw/9pfs/9p-proxy.c
index 99d115ff0d..905cae6992 100644
--- a/hw/9pfs/9p-proxy.c
+++ b/hw/9pfs/9p-proxy.c
@@ -15,6 +15,11 @@
* https://wiki.qemu.org/Documentation/9p
*/
+/*
+ * NOTE: The 9p 'proxy' backend is deprecated (since QEMU 8.1) and will be
+ * removed in a future version of QEMU!
+ */
+
#include "qemu/osdep.h"
#include
#include
diff --git
Re: [PATCH v2] 9pfs: deprecate 'proxy' backend
On Saturday, June 10, 2023 1:07:27 PM CEST Christian Schoenebeck wrote:
> As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in
> bad shape. Using the 'proxy' backend was already discouraged for safety
> reasons before and we recommended to use the 'local' backend instead,
> but now it is time to officially deprecate the 'proxy' backend.
>
> Signed-off-by: Christian Schoenebeck
> ---
> v1 -> v2:
> * Add deprecation notice also to virtfs-proxy-helper.rst,
>qemu-options.hx and to the 'proxy' source files
>(virtfs-proxy-helper.c, 9p-proxy.c, 9p-proxy.h).
>
> MAINTAINERS| 7 +++
> docs/about/deprecated.rst | 17 +
> docs/tools/virtfs-proxy-helper.rst | 3 +++
> fsdev/qemu-fsdev.c | 5 +
> fsdev/virtfs-proxy-helper.c| 5 +
> hw/9pfs/9p-proxy.c | 5 +
> hw/9pfs/9p-proxy.h | 5 +
> meson.build| 2 +-
> qemu-options.hx| 6 +-
> softmmu/vl.c | 5 +
> 10 files changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 436b3f0afe..185d694b2e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2118,13 +2118,20 @@ S: Odd Fixes
> W: https://wiki.qemu.org/Documentation/9p
> F: hw/9pfs/
> X: hw/9pfs/xen-9p*
> +X: hw/9pfs/9p-proxy*
> F: fsdev/
> +X: fsdev/virtfs-proxy-helper.c
> F: docs/tools/virtfs-proxy-helper.rst
> F: tests/qtest/virtio-9p-test.c
> F: tests/qtest/libqos/virtio-9p*
> T: git https://gitlab.com/gkurz/qemu.git 9p-next
> T: git https://github.com/cschoenebeck/qemu.git 9p.next
>
> +virtio-9p-proxy
> +F: hw/9pfs/9p-proxy*
> +F: fsdev/virtfs-proxy-helper.c
> +S: Obsolete
> +
> virtio-blk
> M: Stefan Hajnoczi
> L: qemu-bl...@nongnu.org
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 0743459862..9b2c780365 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -343,6 +343,23 @@ the addition of volatile memory support, it is now
> necessary to distinguish
> between persistent and volatile memory backends. As such, memdev is
> deprecated
> in favor of persistent-memdev.
>
> +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
> +^^
> +
> +The 9p ``proxy`` filesystem backend driver has been deprecated and will be
> +removed in a future version of QEMU. Please use ``-fsdev local`` or
> +``-virtfs local`` for using the ``local`` 9p filesystem backend instead.
> +
> +The 9p ``proxy`` backend was originally developed as an alternative to the 9p
> +``local`` backend. The idea was to enhance security by dispatching actual low
> +level filesystem operations from 9p server (QEMU process) over to a separate
> +process (the virtfs-proxy-helper binary). However this alternative never
> gained
> +momentum. The proxy backend is much slower than the local backend, hasn't
> seen
> +any development in years, and showed to be less secure, especially due to the
> +fact that its helper daemon must be run as root, whereas with the local
> backend
> +QEMU is typically run as unprivileged user and allows to tighten behaviour by
> +mapping permissions et al.
> +
>
> Block device options
>
> diff --git a/docs/tools/virtfs-proxy-helper.rst
> b/docs/tools/virtfs-proxy-helper.rst
> index 6cdeedf8e9..f5051130e2 100644
> --- a/docs/tools/virtfs-proxy-helper.rst
> +++ b/docs/tools/virtfs-proxy-helper.rst
> @@ -9,6 +9,9 @@ Synopsis
> Description
> ---
>
> +NOTE: The 9p 'proxy' nackend is deprecated (since QEMU 8.1) and will be
> +removed, along with this daemon, in a future version of QEMU!
> +
> Pass-through security model in QEMU 9p server needs root privilege to do
> few file operations (like chown, chmod to any mode/uid:gid). There are two
> issues in pass-through security model:
> diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
> index 3da64e9f72..242f54ab49 100644
> --- a/fsdev/qemu-fsdev.c
> +++ b/fsdev/qemu-fsdev.c
> @@ -133,6 +133,11 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
> }
>
> if (fsdriver) {
> +if (strncmp(fsdriver, "proxy", 5) == 0) {
> +warn_report("'-fsdev proxy' is deprecated, use '-fsdev local' "
> +"instead");
> +}
> +
> for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
> if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
> break;
> diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
&g
[PATCH v2] 9pfs: deprecate 'proxy' backend
As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in
bad shape. Using the 'proxy' backend was already discouraged for safety
reasons before and we recommended to use the 'local' backend instead,
but now it is time to officially deprecate the 'proxy' backend.
Signed-off-by: Christian Schoenebeck
---
v1 -> v2:
* Add deprecation notice also to virtfs-proxy-helper.rst,
qemu-options.hx and to the 'proxy' source files
(virtfs-proxy-helper.c, 9p-proxy.c, 9p-proxy.h).
MAINTAINERS| 7 +++
docs/about/deprecated.rst | 17 +
docs/tools/virtfs-proxy-helper.rst | 3 +++
fsdev/qemu-fsdev.c | 5 +
fsdev/virtfs-proxy-helper.c| 5 +
hw/9pfs/9p-proxy.c | 5 +
hw/9pfs/9p-proxy.h | 5 +
meson.build| 2 +-
qemu-options.hx| 6 +-
softmmu/vl.c | 5 +
10 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 436b3f0afe..185d694b2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2118,13 +2118,20 @@ S: Odd Fixes
W: https://wiki.qemu.org/Documentation/9p
F: hw/9pfs/
X: hw/9pfs/xen-9p*
+X: hw/9pfs/9p-proxy*
F: fsdev/
+X: fsdev/virtfs-proxy-helper.c
F: docs/tools/virtfs-proxy-helper.rst
F: tests/qtest/virtio-9p-test.c
F: tests/qtest/libqos/virtio-9p*
T: git https://gitlab.com/gkurz/qemu.git 9p-next
T: git https://github.com/cschoenebeck/qemu.git 9p.next
+virtio-9p-proxy
+F: hw/9pfs/9p-proxy*
+F: fsdev/virtfs-proxy-helper.c
+S: Obsolete
+
virtio-blk
M: Stefan Hajnoczi
L: qemu-bl...@nongnu.org
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..9b2c780365 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -343,6 +343,23 @@ the addition of volatile memory support, it is now
necessary to distinguish
between persistent and volatile memory backends. As such, memdev is deprecated
in favor of persistent-memdev.
+``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
+^^
+
+The 9p ``proxy`` filesystem backend driver has been deprecated and will be
+removed in a future version of QEMU. Please use ``-fsdev local`` or
+``-virtfs local`` for using the ``local`` 9p filesystem backend instead.
+
+The 9p ``proxy`` backend was originally developed as an alternative to the 9p
+``local`` backend. The idea was to enhance security by dispatching actual low
+level filesystem operations from 9p server (QEMU process) over to a separate
+process (the virtfs-proxy-helper binary). However this alternative never gained
+momentum. The proxy backend is much slower than the local backend, hasn't seen
+any development in years, and showed to be less secure, especially due to the
+fact that its helper daemon must be run as root, whereas with the local backend
+QEMU is typically run as unprivileged user and allows to tighten behaviour by
+mapping permissions et al.
+
Block device options
diff --git a/docs/tools/virtfs-proxy-helper.rst
b/docs/tools/virtfs-proxy-helper.rst
index 6cdeedf8e9..f5051130e2 100644
--- a/docs/tools/virtfs-proxy-helper.rst
+++ b/docs/tools/virtfs-proxy-helper.rst
@@ -9,6 +9,9 @@ Synopsis
Description
---
+NOTE: The 9p 'proxy' nackend is deprecated (since QEMU 8.1) and will be
+removed, along with this daemon, in a future version of QEMU!
+
Pass-through security model in QEMU 9p server needs root privilege to do
few file operations (like chown, chmod to any mode/uid:gid). There are two
issues in pass-through security model:
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 3da64e9f72..242f54ab49 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -133,6 +133,11 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
}
if (fsdriver) {
+if (strncmp(fsdriver, "proxy", 5) == 0) {
+warn_report("'-fsdev proxy' is deprecated, use '-fsdev local' "
+"instead");
+}
+
for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
break;
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index d9511f429c..87e358376a 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -9,6 +9,11 @@
* the COPYING file in the top-level directory.
*/
+/*
+ * NOTE: The 9p 'proxy' nackend is deprecated (since QEMU 8.1) and will be
+ * removed in a future version of QEMU!
+ */
+
#include "qemu/osdep.h"
#include
#include
diff --git a/hw/9pfs/9p-proxy.c b/hw/9pfs/9p-proxy.c
index 99d115ff0d..ab489cdd40 100644
--- a/hw/9pfs/9p-proxy.c
+++ b/hw/9pfs/9p-proxy.c
@@ -15,6 +15,11 @@
* https://wiki.qemu.org/Documentation/9p
*/
+/*
+ * NOTE: The 9p 'proxy' nackend is deprecated (since QEMU 8.1) and w
[PATCH] 9pfs: deprecate 'proxy' backend
As recent CVE-2023-2861 once again showed, the 9p 'proxy' fs driver is in
bad shape. Using the 'proxy' backend was already discouraged for safety
reasons before and we recommended to use the 'local' backend instead,
but now it is time to officially deprecate the 'proxy' backend.
Signed-off-by: Christian Schoenebeck
---
MAINTAINERS | 7 +++
docs/about/deprecated.rst | 17 +
fsdev/qemu-fsdev.c| 5 +
meson.build | 2 +-
softmmu/vl.c | 5 +
5 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 436b3f0afe..185d694b2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2118,13 +2118,20 @@ S: Odd Fixes
W: https://wiki.qemu.org/Documentation/9p
F: hw/9pfs/
X: hw/9pfs/xen-9p*
+X: hw/9pfs/9p-proxy*
F: fsdev/
+X: fsdev/virtfs-proxy-helper.c
F: docs/tools/virtfs-proxy-helper.rst
F: tests/qtest/virtio-9p-test.c
F: tests/qtest/libqos/virtio-9p*
T: git https://gitlab.com/gkurz/qemu.git 9p-next
T: git https://github.com/cschoenebeck/qemu.git 9p.next
+virtio-9p-proxy
+F: hw/9pfs/9p-proxy*
+F: fsdev/virtfs-proxy-helper.c
+S: Obsolete
+
virtio-blk
M: Stefan Hajnoczi
L: qemu-bl...@nongnu.org
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 0743459862..9b2c780365 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -343,6 +343,23 @@ the addition of volatile memory support, it is now
necessary to distinguish
between persistent and volatile memory backends. As such, memdev is deprecated
in favor of persistent-memdev.
+``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
+^^
+
+The 9p ``proxy`` filesystem backend driver has been deprecated and will be
+removed in a future version of QEMU. Please use ``-fsdev local`` or
+``-virtfs local`` for using the ``local`` 9p filesystem backend instead.
+
+The 9p ``proxy`` backend was originally developed as an alternative to the 9p
+``local`` backend. The idea was to enhance security by dispatching actual low
+level filesystem operations from 9p server (QEMU process) over to a separate
+process (the virtfs-proxy-helper binary). However this alternative never gained
+momentum. The proxy backend is much slower than the local backend, hasn't seen
+any development in years, and showed to be less secure, especially due to the
+fact that its helper daemon must be run as root, whereas with the local backend
+QEMU is typically run as unprivileged user and allows to tighten behaviour by
+mapping permissions et al.
+
Block device options
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 3da64e9f72..242f54ab49 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -133,6 +133,11 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
}
if (fsdriver) {
+if (strncmp(fsdriver, "proxy", 5) == 0) {
+warn_report("'-fsdev proxy' is deprecated, use '-fsdev local' "
+"instead");
+}
+
for (i = 0; i < ARRAY_SIZE(FsDrivers); i++) {
if (strcmp(FsDrivers[i].name, fsdriver) == 0) {
break;
diff --git a/meson.build b/meson.build
index 34306a6205..05c01b72bb 100644
--- a/meson.build
+++ b/meson.build
@@ -4170,7 +4170,7 @@ if have_block
summary_info += {'Block whitelist (ro)':
get_option('block_drv_ro_whitelist')}
summary_info += {'Use block whitelist in tools':
get_option('block_drv_whitelist_in_tools')}
summary_info += {'VirtFS (9P) support':have_virtfs}
- summary_info += {'VirtFS (9P) Proxy Helper support':
have_virtfs_proxy_helper}
+ summary_info += {'VirtFS (9P) Proxy Helper support (deprecated)':
have_virtfs_proxy_helper}
summary_info += {'Live block migration':
config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
summary_info += {'replication support':
config_host_data.get('CONFIG_REPLICATION')}
summary_info += {'bochs support': get_option('bochs').allowed()}
diff --git a/softmmu/vl.c b/softmmu/vl.c
index b0b96f67fa..e60648b591 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -3102,6 +3102,11 @@ void qemu_init(int argc, char **argv)
error_report("Usage: -virtfs fsdriver,mount_tag=tag");
exit(1);
}
+if (strncmp(qemu_opt_get(opts, "fsdriver"), "proxy", 5) == 0) {
+warn_report("'-virtfs proxy' is deprecated, use "
+"'-virtfs local' instead");
+}
+
fsdev = qemu_opts_create(qemu_find_opts("fsdev"),
qemu_opts_id(opts) ?:
qemu_opt_get(opts, "mount_tag"),
--
2.30.2
[PULL 0/1] 9p security fix 2023-06-08
The following changes since commit 45ae97993a75f975f1a01d25564724c7e10a543f: Merge tag 'pull-tricore-20230607' of https://github.com/bkoppelmann/qemu into staging (2023-06-07 11:45:22 -0700) are available in the Git repository at: https://github.com/cschoenebeck/qemu.git tags/pull-9p-20230608 for you to fetch changes up to f6b0de53fb87ddefed348a39284c8e2f28dc4eda: 9pfs: prevent opening special files (CVE-2023-2861) (2023-06-08 17:04:58 +0200) * Fix for CVE-2023-2861. Christian Schoenebeck (1): 9pfs: prevent opening special files (CVE-2023-2861) fsdev/virtfs-proxy-helper.c | 27 +-- hw/9pfs/9p-util.h | 39 +++ 2 files changed, 64 insertions(+), 2 deletions(-)
[PULL 1/1] 9pfs: prevent opening special files (CVE-2023-2861)
The 9p protocol does not specifically define how server shall behave when
client tries to open a special file, however from security POV it does
make sense for 9p server to prohibit opening any special file on host side
in general. A sane Linux 9p client for instance would never attempt to
open a special file on host side, it would always handle those exclusively
on its guest side. A malicious client however could potentially escape
from the exported 9p tree by creating and opening a device file on host
side.
With QEMU this could only be exploited in the following unsafe setups:
- Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough'
security model.
or
- Using 9p 'proxy' fs driver (which is running its helper daemon as
root).
These setups were already discouraged for safety reasons before,
however for obvious reasons we are now tightening behaviour on this.
Fixes: CVE-2023-2861
Reported-by: Yanwu Shen
Reported-by: Jietao Xiao
Reported-by: Jinku Li
Reported-by: Wenbo Shen
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Reviewed-by: Michael Tokarev
Message-Id:
---
fsdev/virtfs-proxy-helper.c | 27 +++--
hw/9pfs/9p-util.h | 39 +
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index 5cafcd7703..d9511f429c 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -26,6 +26,7 @@
#include "qemu/xattr.h"
#include "9p-iov-marshal.h"
#include "hw/9pfs/9p-proxy.h"
+#include "hw/9pfs/9p-util.h"
#include "fsdev/9p-iov-marshal.h"
#define PROGNAME "virtfs-proxy-helper"
@@ -338,6 +339,28 @@ static void resetugid(int suid, int sgid)
}
}
+/*
+ * Open regular file or directory. Attempts to open any special file are
+ * rejected.
+ *
+ * returns file descriptor or -1 on error
+ */
+static int open_regular(const char *pathname, int flags, mode_t mode)
+{
+int fd;
+
+fd = open(pathname, flags, mode);
+if (fd < 0) {
+return fd;
+}
+
+if (close_if_special_file(fd) < 0) {
+return -1;
+}
+
+return fd;
+}
+
/*
* send response in two parts
* 1) ProxyHeader
@@ -682,7 +705,7 @@ static int do_create(struct iovec *iovec)
if (ret < 0) {
goto unmarshal_err_out;
}
-ret = open(path.data, flags, mode);
+ret = open_regular(path.data, flags, mode);
if (ret < 0) {
ret = -errno;
}
@@ -707,7 +730,7 @@ static int do_open(struct iovec *iovec)
if (ret < 0) {
goto err_out;
}
-ret = open(path.data, flags);
+ret = open_regular(path.data, flags, 0);
if (ret < 0) {
ret = -errno;
}
diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index c314cf381d..df1b583a5e 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,8 @@
#ifndef QEMU_9P_UTIL_H
#define QEMU_9P_UTIL_H
+#include "qemu/error-report.h"
+
#ifdef O_PATH
#define O_PATH_9P_UTIL O_PATH
#else
@@ -95,6 +97,7 @@ static inline int errno_to_dotl(int err) {
#endif
#define qemu_openat openat
+#define qemu_fstat fstat
#define qemu_fstatatfstatat
#define qemu_mkdiratmkdirat
#define qemu_renameat renameat
@@ -108,6 +111,38 @@ static inline void close_preserve_errno(int fd)
errno = serrno;
}
+/**
+ * close_if_special_file() - Close @fd if neither regular file nor directory.
+ *
+ * @fd: file descriptor of open file
+ * Return: 0 on regular file or directory, -1 otherwise
+ *
+ * CVE-2023-2861: Prohibit opening any special file directly on host
+ * (especially device files), as a compromised client could potentially gain
+ * access outside exported tree under certain, unsafe setups. We expect
+ * client to handle I/O on special files exclusively on guest side.
+ */
+static inline int close_if_special_file(int fd)
+{
+struct stat stbuf;
+
+if (qemu_fstat(fd, ) < 0) {
+close_preserve_errno(fd);
+return -1;
+}
+if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
+error_report_once(
+"9p: broken or compromised client detected; attempt to open "
+"special file (i.e. neither regular file, nor directory)"
+);
+close(fd);
+errno = ENXIO;
+return -1;
+}
+
+return 0;
+}
+
static inline int openat_dir(int dirfd, const char *name)
{
return qemu_openat(dirfd, name,
@@ -142,6 +177,10 @@ again:
return -1;
}
+if (close_if_special_file(fd) < 0) {
+return -1;
+}
+
serrno = errno;
/* O_NONBLOCK was only needed to open the file. Let's drop it. We don't
* do that with O_PATH since fcntl(F_SETFL) isn't supported, and openat()
--
2.30.2
[PATCH v4] 9pfs: prevent opening special files (CVE-2023-2861)
The 9p protocol does not specifically define how server shall behave when
client tries to open a special file, however from security POV it does
make sense for 9p server to prohibit opening any special file on host side
in general. A sane Linux 9p client for instance would never attempt to
open a special file on host side, it would always handle those exclusively
on its guest side. A malicious client however could potentially escape
from the exported 9p tree by creating and opening a device file on host
side.
With QEMU this could only be exploited in the following unsafe setups:
- Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough'
security model.
or
- Using 9p 'proxy' fs driver (which is running its helper daemon as
root).
These setups were already discouraged for safety reasons before,
however for obvious reasons we are now tightening behaviour on this.
Fixes: CVE-2023-2861
Reported-by: Yanwu Shen
Reported-by: Jietao Xiao
Reported-by: Jinku Li
Reported-by: Wenbo Shen
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
---
v3 -> v4:
- Rename function check_is_regular_file_or_dir() ->
close_if_special_file() and add detailed API comment.
- Minor code style fix on open_regular().
fsdev/virtfs-proxy-helper.c | 27 +++--
hw/9pfs/9p-util.h | 39 +
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index 5cafcd7703..d9511f429c 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -26,6 +26,7 @@
#include "qemu/xattr.h"
#include "9p-iov-marshal.h"
#include "hw/9pfs/9p-proxy.h"
+#include "hw/9pfs/9p-util.h"
#include "fsdev/9p-iov-marshal.h"
#define PROGNAME "virtfs-proxy-helper"
@@ -338,6 +339,28 @@ static void resetugid(int suid, int sgid)
}
}
+/*
+ * Open regular file or directory. Attempts to open any special file are
+ * rejected.
+ *
+ * returns file descriptor or -1 on error
+ */
+static int open_regular(const char *pathname, int flags, mode_t mode)
+{
+int fd;
+
+fd = open(pathname, flags, mode);
+if (fd < 0) {
+return fd;
+}
+
+if (close_if_special_file(fd) < 0) {
+return -1;
+}
+
+return fd;
+}
+
/*
* send response in two parts
* 1) ProxyHeader
@@ -682,7 +705,7 @@ static int do_create(struct iovec *iovec)
if (ret < 0) {
goto unmarshal_err_out;
}
-ret = open(path.data, flags, mode);
+ret = open_regular(path.data, flags, mode);
if (ret < 0) {
ret = -errno;
}
@@ -707,7 +730,7 @@ static int do_open(struct iovec *iovec)
if (ret < 0) {
goto err_out;
}
-ret = open(path.data, flags);
+ret = open_regular(path.data, flags, 0);
if (ret < 0) {
ret = -errno;
}
diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index c314cf381d..df1b583a5e 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,8 @@
#ifndef QEMU_9P_UTIL_H
#define QEMU_9P_UTIL_H
+#include "qemu/error-report.h"
+
#ifdef O_PATH
#define O_PATH_9P_UTIL O_PATH
#else
@@ -95,6 +97,7 @@ static inline int errno_to_dotl(int err) {
#endif
#define qemu_openat openat
+#define qemu_fstat fstat
#define qemu_fstatatfstatat
#define qemu_mkdiratmkdirat
#define qemu_renameat renameat
@@ -108,6 +111,38 @@ static inline void close_preserve_errno(int fd)
errno = serrno;
}
+/**
+ * close_if_special_file() - Close @fd if neither regular file nor directory.
+ *
+ * @fd: file descriptor of open file
+ * Return: 0 on regular file or directory, -1 otherwise
+ *
+ * CVE-2023-2861: Prohibit opening any special file directly on host
+ * (especially device files), as a compromised client could potentially gain
+ * access outside exported tree under certain, unsafe setups. We expect
+ * client to handle I/O on special files exclusively on guest side.
+ */
+static inline int close_if_special_file(int fd)
+{
+struct stat stbuf;
+
+if (qemu_fstat(fd, ) < 0) {
+close_preserve_errno(fd);
+return -1;
+}
+if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
+error_report_once(
+"9p: broken or compromised client detected; attempt to open "
+"special file (i.e. neither regular file, nor directory)"
+);
+close(fd);
+errno = ENXIO;
+return -1;
+}
+
+return 0;
+}
+
static inline int openat_dir(int dirfd, const char *name)
{
return qemu_openat(dirfd, name,
@@ -142,6 +177,10 @@ again:
return -1;
}
+if (close_if_special_file(fd) < 0) {
+return -1;
+}
+
serrno = errno;
/* O_NONBLOCK was only needed to open the file. Let's drop it. We don't
* do that with O_PATH since fcntl(F_SETFL) isn't supported, and openat()
--
2.30.2
[PATCH v3] 9pfs: prevent opening special files (CVE-2023-2861)
The 9p protocol does not specifically define how server shall behave when
client tries to open a special file, however from security POV it does
make sense for 9p server to prohibit opening any special file on host side
in general. A sane Linux 9p client for instance would never attempt to
open a special file on host side, it would always handle those exclusively
on its guest side. A malicious client however could potentially escape
from the exported 9p tree by creating and opening a device file on host
side.
With QEMU this could only be exploited in the following unsafe setups:
- Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough'
security model.
or
- Using 9p 'proxy' fs driver (which is running its helper daemon as
root).
These setups were already discouraged for safety reasons before,
however for obvious reasons we are now tightening behaviour on this.
Fixes: CVE-2023-2861
Reported-by: Yanwu Shen
Reported-by: Jietao Xiao
Reported-by: Jinku Li
Reported-by: Wenbo Shen
Signed-off-by: Christian Schoenebeck
---
v2 -> v3:
- Drop O_CREAT check and its comment.
- Eliminate code duplication.
fsdev/virtfs-proxy-helper.c | 26 --
hw/9pfs/9p-util.h | 33 +
2 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index 5cafcd7703..256d7bfcec 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -26,6 +26,7 @@
#include "qemu/xattr.h"
#include "9p-iov-marshal.h"
#include "hw/9pfs/9p-proxy.h"
+#include "hw/9pfs/9p-util.h"
#include "fsdev/9p-iov-marshal.h"
#define PROGNAME "virtfs-proxy-helper"
@@ -338,6 +339,27 @@ static void resetugid(int suid, int sgid)
}
}
+/*
+ * Open regular file or directory. Attempts to open any special file are
+ * rejected.
+ *
+ * returns file descriptor or -1 on error
+ */
+static int open_regular(const char *pathname, int flags, mode_t mode) {
+int fd;
+
+fd = open(pathname, flags, mode);
+if (fd < 0) {
+return fd;
+}
+
+if (check_is_regular_file_or_dir(fd) < 0) {
+return -1;
+}
+
+return fd;
+}
+
/*
* send response in two parts
* 1) ProxyHeader
@@ -682,7 +704,7 @@ static int do_create(struct iovec *iovec)
if (ret < 0) {
goto unmarshal_err_out;
}
-ret = open(path.data, flags, mode);
+ret = open_regular(path.data, flags, mode);
if (ret < 0) {
ret = -errno;
}
@@ -707,7 +729,7 @@ static int do_open(struct iovec *iovec)
if (ret < 0) {
goto err_out;
}
-ret = open(path.data, flags);
+ret = open_regular(path.data, flags, 0);
if (ret < 0) {
ret = -errno;
}
diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index c314cf381d..9b0a9e5878 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,8 @@
#ifndef QEMU_9P_UTIL_H
#define QEMU_9P_UTIL_H
+#include "qemu/error-report.h"
+
#ifdef O_PATH
#define O_PATH_9P_UTIL O_PATH
#else
@@ -95,6 +97,7 @@ static inline int errno_to_dotl(int err) {
#endif
#define qemu_openat openat
+#define qemu_fstat fstat
#define qemu_fstatatfstatat
#define qemu_mkdiratmkdirat
#define qemu_renameat renameat
@@ -108,6 +111,32 @@ static inline void close_preserve_errno(int fd)
errno = serrno;
}
+/* CVE-2023-2861: Prohibit opening any special file directly on host
+ * (especially device files), as a compromised client could potentially gain
+ * access outside exported tree under certain, unsafe setups. We expect
+ * client to handle I/O on special files exclusively on guest side.
+ */
+static inline int check_is_regular_file_or_dir(int fd)
+{
+struct stat stbuf;
+
+if (qemu_fstat(fd, ) < 0) {
+close_preserve_errno(fd);
+return -1;
+}
+if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
+error_report_once(
+"9p: broken or compromised client detected; attempt to open "
+"special file (i.e. neither regular file, nor directory)"
+);
+close(fd);
+errno = ENXIO;
+return -1;
+}
+
+return 0;
+}
+
static inline int openat_dir(int dirfd, const char *name)
{
return qemu_openat(dirfd, name,
@@ -142,6 +171,10 @@ again:
return -1;
}
+if (check_is_regular_file_or_dir(fd) < 0) {
+return -1;
+}
+
serrno = errno;
/* O_NONBLOCK was only needed to open the file. Let's drop it. We don't
* do that with O_PATH since fcntl(F_SETFL) isn't supported, and openat()
--
2.30.2
Re: [PATCH v2] 9pfs: prevent opening special files (CVE-2023-2861)
On Wednesday, June 7, 2023 1:02:17 PM CEST Christian Schoenebeck wrote:
> On Tuesday, June 6, 2023 6:00:28 PM CEST Greg Kurz wrote:
> > Hi Christian,
> >
> > On Tue, 06 Jun 2023 15:57:50 +0200
> > Christian Schoenebeck wrote:
> >
> > > The 9p protocol does not specifically define how server shall behave when
> > > client tries to open a special file, however from security POV it does
> > > make sense for 9p server to prohibit opening any special file on host side
> > > in general. A sane Linux 9p client for instance would never attempt to
> > > open a special file on host side, it would always handle those exclusively
> > > on its guest side. A malicious client however could potentially escape
> > > from the exported 9p tree by creating and opening a device file on host
> > > side.
> > >
> > > With QEMU this could only be exploited in the following unsafe setups:
> > >
> > > - Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough'
> > > security model.
> > >
> > > or
> > >
> > > - Using 9p 'proxy' fs driver (which is running its helper daemon as
> > > root).
> > >
> > > These setups were already discouraged for safety reasons before,
> > > however for obvious reasons we are now tightening behaviour on this.
> > >
> > > Fixes: CVE-2023-2861
> > > Reported-by: Yanwu Shen
> > > Reported-by: Jietao Xiao
> > > Reported-by: Jinku Li
> > > Reported-by: Wenbo Shen
> > > Signed-off-by: Christian Schoenebeck
> > > ---
> > > v1 -> v2:
> > > - Add equivalent fix for 'proxy' fs driver.
> > > - Minor adjustments on commit log.
> > >
> >
> > Note that this might be a bit confusing for reviewers since
> > v1 was never posted to qemu-devel. Technically, this should
> > have been posted without the v2 tag.
>
> I felt it wouldn't make it any better, as it might otherwise confuse those who
> already got the previous two patch emails.
>
> > > fsdev/virtfs-proxy-helper.c | 48 +++--
> > > hw/9pfs/9p-util.h | 29 ++
> > > 2 files changed, 75 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
> > > index 5cafcd7703..f311519fa3 100644
> > > --- a/fsdev/virtfs-proxy-helper.c
> > > +++ b/fsdev/virtfs-proxy-helper.c
> > > @@ -26,6 +26,7 @@
> > > #include "qemu/xattr.h"
> > > #include "9p-iov-marshal.h"
> > > #include "hw/9pfs/9p-proxy.h"
> > > +#include "hw/9pfs/9p-util.h"
> > > #include "fsdev/9p-iov-marshal.h"
> > >
> > > #define PROGNAME "virtfs-proxy-helper"
> > > @@ -338,6 +339,49 @@ static void resetugid(int suid, int sgid)
> > > }
> > > }
> > >
> > > +/*
> > > + * Open regular file or directory. Attempts to open any special file are
> > > + * rejected.
> > > + *
> > > + * returns file descriptor or -1 on error
> > > + */
> > > +static int open_regular(const char *pathname, int flags, mode_t mode) {
> > > +int fd;
> > > +struct stat stbuf;
> > > +
> > > +fd = open(pathname, flags, mode);
> > > +if (fd < 0) {
> > > +return fd;
> > > +}
> > > +
> > > +/* CVE-2023-2861: Prohibit opening any special file directly on host
> > > + * (especially device files), as a compromised client could
> > > potentially
> > > + * gain access outside exported tree under certain, unsafe setups. We
> > > + * expect client to handle I/O on special files exclusively on guest
> > > side.
> > > + */
> > > +if (qemu_fstat(fd, ) < 0) {
> > > +close_preserve_errno(fd);
> > > +return -1;
> > > +}
> > > +if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
> > > +/* Tcreate and Tlcreate 9p messages mandate to immediately open
> > > the
> > > + * created file for I/O. So this is not (necessarily) due to a
> > > broken
> > > + * client, and hence no error message is to be reported in this
> > > case.
> > > + */
> > > +if (!(flags & O_CREAT)) {
> >
> > Tlcreate is explicitly about creating regular files only
Re: [PATCH v2] 9pfs: prevent opening special files (CVE-2023-2861)
On Tuesday, June 6, 2023 8:48:49 PM CEST Michael Tokarev wrote:
> 06.06.2023 16:57, Christian Schoenebeck wrote:
[...]
> > +/* CVE-2023-2861: Prohibit opening any special file directly on host
> > + * (especially device files), as a compromised client could potentially
> > + * gain access outside exported tree under certain, unsafe setups. We
> > + * expect client to handle I/O on special files exclusively on guest
> > side.
> > + */
> > +if (qemu_fstat(fd, ) < 0) {
> > +close_preserve_errno(fd);
> > +return -1;
> > +}
> > +if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
> > +/* Tcreate and Tlcreate 9p messages mandate to immediately open the
> > + * created file for I/O. So this is not (necessarily) due to a
> > broken
> > + * client, and hence no error message is to be reported in this
> > case.
> > + */
> > +if (!(flags & O_CREAT)) {
> > +error_report_once(
> > +"9p: broken or compromised client detected; attempt to
> > open "
> > +"special file (i.e. neither regular file, nor directory)"
> > +);
> > +}
> > +close(fd);
> > +errno = ENXIO;
> > +return -1;
> > +}
> > +
>
> can't we re-use this same code used in two places, placing it into an inline
> function, such as is_file_regular_or_dir(fd) ? It smells like a very good
> candidate for implementing it in a single place..
Yeah, my plan was to officially deprecate 9p proxy subsequently, so I didn't
care too much about code duplication, but I guess you are right, it is simple
enough to do it right.
Best regards,
Christian Schoenebeck
Re: [PATCH v2] 9pfs: prevent opening special files (CVE-2023-2861)
On Tuesday, June 6, 2023 6:00:28 PM CEST Greg Kurz wrote:
> Hi Christian,
>
> On Tue, 06 Jun 2023 15:57:50 +0200
> Christian Schoenebeck wrote:
>
> > The 9p protocol does not specifically define how server shall behave when
> > client tries to open a special file, however from security POV it does
> > make sense for 9p server to prohibit opening any special file on host side
> > in general. A sane Linux 9p client for instance would never attempt to
> > open a special file on host side, it would always handle those exclusively
> > on its guest side. A malicious client however could potentially escape
> > from the exported 9p tree by creating and opening a device file on host
> > side.
> >
> > With QEMU this could only be exploited in the following unsafe setups:
> >
> > - Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough'
> > security model.
> >
> > or
> >
> > - Using 9p 'proxy' fs driver (which is running its helper daemon as
> > root).
> >
> > These setups were already discouraged for safety reasons before,
> > however for obvious reasons we are now tightening behaviour on this.
> >
> > Fixes: CVE-2023-2861
> > Reported-by: Yanwu Shen
> > Reported-by: Jietao Xiao
> > Reported-by: Jinku Li
> > Reported-by: Wenbo Shen
> > Signed-off-by: Christian Schoenebeck
> > ---
> > v1 -> v2:
> > - Add equivalent fix for 'proxy' fs driver.
> > - Minor adjustments on commit log.
> >
>
> Note that this might be a bit confusing for reviewers since
> v1 was never posted to qemu-devel. Technically, this should
> have been posted without the v2 tag.
I felt it wouldn't make it any better, as it might otherwise confuse those who
already got the previous two patch emails.
> > fsdev/virtfs-proxy-helper.c | 48 +++--
> > hw/9pfs/9p-util.h | 29 ++
> > 2 files changed, 75 insertions(+), 2 deletions(-)
> >
> > diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
> > index 5cafcd7703..f311519fa3 100644
> > --- a/fsdev/virtfs-proxy-helper.c
> > +++ b/fsdev/virtfs-proxy-helper.c
> > @@ -26,6 +26,7 @@
> > #include "qemu/xattr.h"
> > #include "9p-iov-marshal.h"
> > #include "hw/9pfs/9p-proxy.h"
> > +#include "hw/9pfs/9p-util.h"
> > #include "fsdev/9p-iov-marshal.h"
> >
> > #define PROGNAME "virtfs-proxy-helper"
> > @@ -338,6 +339,49 @@ static void resetugid(int suid, int sgid)
> > }
> > }
> >
> > +/*
> > + * Open regular file or directory. Attempts to open any special file are
> > + * rejected.
> > + *
> > + * returns file descriptor or -1 on error
> > + */
> > +static int open_regular(const char *pathname, int flags, mode_t mode) {
> > +int fd;
> > +struct stat stbuf;
> > +
> > +fd = open(pathname, flags, mode);
> > +if (fd < 0) {
> > +return fd;
> > +}
> > +
> > +/* CVE-2023-2861: Prohibit opening any special file directly on host
> > + * (especially device files), as a compromised client could potentially
> > + * gain access outside exported tree under certain, unsafe setups. We
> > + * expect client to handle I/O on special files exclusively on guest
> > side.
> > + */
> > +if (qemu_fstat(fd, ) < 0) {
> > +close_preserve_errno(fd);
> > +return -1;
> > +}
> > +if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
> > +/* Tcreate and Tlcreate 9p messages mandate to immediately open the
> > + * created file for I/O. So this is not (necessarily) due to a
> > broken
> > + * client, and hence no error message is to be reported in this
> > case.
> > + */
> > +if (!(flags & O_CREAT)) {
>
> Tlcreate is explicitly about creating regular files only (see [1] and
> v9fs_lcreate()) and I don't quite see how open() could successfully
> create a regular file and the resulting fd is fstat'ed as something
> else.
>
> Tcreate seems to cover more types but again only regular files (with O_CREAT)
> or directories (without O_CREAT) are expected here (see v9fs_create()).
>
> Unless I'm missing something, it seems that the comment and the O_CREAT
> check should be removed.
>
> [1]
> https://github.com/chaos/diod/blob/master/protocol.md#lcreatecreate-regular-file
You are right about Tlcreate, but for Tcreate 9p2
[PATCH v2] 9pfs: prevent opening special files (CVE-2023-2861)
The 9p protocol does not specifically define how server shall behave when
client tries to open a special file, however from security POV it does
make sense for 9p server to prohibit opening any special file on host side
in general. A sane Linux 9p client for instance would never attempt to
open a special file on host side, it would always handle those exclusively
on its guest side. A malicious client however could potentially escape
from the exported 9p tree by creating and opening a device file on host
side.
With QEMU this could only be exploited in the following unsafe setups:
- Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough'
security model.
or
- Using 9p 'proxy' fs driver (which is running its helper daemon as
root).
These setups were already discouraged for safety reasons before,
however for obvious reasons we are now tightening behaviour on this.
Fixes: CVE-2023-2861
Reported-by: Yanwu Shen
Reported-by: Jietao Xiao
Reported-by: Jinku Li
Reported-by: Wenbo Shen
Signed-off-by: Christian Schoenebeck
---
v1 -> v2:
- Add equivalent fix for 'proxy' fs driver.
- Minor adjustments on commit log.
fsdev/virtfs-proxy-helper.c | 48 +++--
hw/9pfs/9p-util.h | 29 ++
2 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index 5cafcd7703..f311519fa3 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -26,6 +26,7 @@
#include "qemu/xattr.h"
#include "9p-iov-marshal.h"
#include "hw/9pfs/9p-proxy.h"
+#include "hw/9pfs/9p-util.h"
#include "fsdev/9p-iov-marshal.h"
#define PROGNAME "virtfs-proxy-helper"
@@ -338,6 +339,49 @@ static void resetugid(int suid, int sgid)
}
}
+/*
+ * Open regular file or directory. Attempts to open any special file are
+ * rejected.
+ *
+ * returns file descriptor or -1 on error
+ */
+static int open_regular(const char *pathname, int flags, mode_t mode) {
+int fd;
+struct stat stbuf;
+
+fd = open(pathname, flags, mode);
+if (fd < 0) {
+return fd;
+}
+
+/* CVE-2023-2861: Prohibit opening any special file directly on host
+ * (especially device files), as a compromised client could potentially
+ * gain access outside exported tree under certain, unsafe setups. We
+ * expect client to handle I/O on special files exclusively on guest side.
+ */
+if (qemu_fstat(fd, ) < 0) {
+close_preserve_errno(fd);
+return -1;
+}
+if (!S_ISREG(stbuf.st_mode) && !S_ISDIR(stbuf.st_mode)) {
+/* Tcreate and Tlcreate 9p messages mandate to immediately open the
+ * created file for I/O. So this is not (necessarily) due to a broken
+ * client, and hence no error message is to be reported in this case.
+ */
+if (!(flags & O_CREAT)) {
+error_report_once(
+"9p: broken or compromised client detected; attempt to open "
+"special file (i.e. neither regular file, nor directory)"
+);
+}
+close(fd);
+errno = ENXIO;
+return -1;
+}
+
+return fd;
+}
+
/*
* send response in two parts
* 1) ProxyHeader
@@ -682,7 +726,7 @@ static int do_create(struct iovec *iovec)
if (ret < 0) {
goto unmarshal_err_out;
}
-ret = open(path.data, flags, mode);
+ret = open_regular(path.data, flags, mode);
if (ret < 0) {
ret = -errno;
}
@@ -707,7 +751,7 @@ static int do_open(struct iovec *iovec)
if (ret < 0) {
goto err_out;
}
-ret = open(path.data, flags);
+ret = open_regular(path.data, flags, 0);
if (ret < 0) {
ret = -errno;
}
diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index c314cf381d..9da1a0538d 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -13,6 +13,8 @@
#ifndef QEMU_9P_UTIL_H
#define QEMU_9P_UTIL_H
+#include "qemu/error-report.h"
+
#ifdef O_PATH
#define O_PATH_9P_UTIL O_PATH
#else
@@ -95,6 +97,7 @@ static inline int errno_to_dotl(int err) {
#endif
#define qemu_openat openat
+#define qemu_fstat fstat
#define qemu_fstatatfstatat
#define qemu_mkdiratmkdirat
#define qemu_renameat renameat
@@ -118,6 +121,7 @@ static inline int openat_file(int dirfd, const char *name,
int flags,
mode_t mode)
{
int fd, serrno, ret;
+struct stat stbuf;
#ifndef CONFIG_DARWIN
again:
@@ -142,6 +146,31 @@ again:
return -1;
}
+/* CVE-2023-2861: Prohibit opening any special file directly on host
+ * (especially device files), as a compromised client could potentially
+ * gain access outside exported tree under certain, unsafe setups. We
+ * expect client to handle I/O on special files exclusively on guest side
[PULL 1/4] Don't require libcap-ng for virtfs support
From: Peter Foley
It's only required for the proxy helper.
Add a new option for the proxy helper rather than enabling it
implicitly.
Change-Id: I95b73fca625529e99d16b0a64e01c65c0c1d43f2
Signed-off-by: Peter Foley
Message-Id: <20230503130757.863824-1-pefo...@google.com>
[C.S.: - Resolve merge conflict. ]
Signed-off-by: Christian Schoenebeck
---
meson.build | 12 +---
meson_options.txt | 2 ++
scripts/meson-buildoptions.sh | 4
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build
index 25a4b9f2c1..c6b05149e9 100644
--- a/meson.build
+++ b/meson.build
@@ -1766,12 +1766,17 @@ have_virtfs = get_option('virtfs') \
error_message: 'virtio-9p (virtfs) requires Linux or macOS') \
.require(targetos == 'linux' or cc.has_function('pthread_fchdir_np'),
error_message: 'virtio-9p (virtfs) on macOS requires the presence
of pthread_fchdir_np') \
-.require(targetos == 'darwin' or (libattr.found() and libcap_ng.found()),
- error_message: 'virtio-9p (virtfs) on Linux requires
libcap-ng-devel and libattr-devel') \
+.require(targetos == 'darwin' or libattr.found(),
+ error_message: 'virtio-9p (virtfs) on Linux requires
libattr-devel') \
.disable_auto_if(not have_tools and not have_system) \
.allowed()
-have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and have_tools
+have_virtfs_proxy_helper = get_option('virtfs_proxy_helper') \
+.require(targetos != 'darwin', error_message: 'the virtfs proxy helper is
incompatible with macOS') \
+.require(have_virtfs, error_message: 'the virtfs proxy helper requires
that virtfs is enabled') \
+.disable_auto_if(not have_tools) \
+.require(libcap_ng.found(), error_message: 'the virtfs proxy helper
requires libcap-ng') \
+.allowed()
if get_option('block_drv_ro_whitelist') == ''
config_host_data.set('CONFIG_BDRV_RO_WHITELIST', '')
@@ -3926,6 +3931,7 @@ if have_block
summary_info += {'Block whitelist (ro)':
get_option('block_drv_ro_whitelist')}
summary_info += {'Use block whitelist in tools':
get_option('block_drv_whitelist_in_tools')}
summary_info += {'VirtFS support':have_virtfs}
+ summary_info += {'VirtFS Proxy Helper support': have_virtfs_proxy_helper}
summary_info += {'Live block migration':
config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
summary_info += {'replication support':
config_host_data.get('CONFIG_REPLICATION')}
summary_info += {'bochs support': get_option('bochs').allowed()}
diff --git a/meson_options.txt b/meson_options.txt
index d8330a1f71..11aec2a441 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -274,6 +274,8 @@ option('vhost_user_blk_server', type: 'feature', value:
'auto',
description: 'build vhost-user-blk server')
option('virtfs', type: 'feature', value: 'auto',
description: 'virtio-9p support')
+option('virtfs_proxy_helper', type: 'feature', value: 'auto',
+ description: 'virtio-9p proxy helper support')
option('libvduse', type: 'feature', value: 'auto',
description: 'build VDUSE Library')
option('vduse_blk_export', type: 'feature', value: 'auto',
diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
index 2805d1c145..52fb079a60 100644
--- a/scripts/meson-buildoptions.sh
+++ b/scripts/meson-buildoptions.sh
@@ -181,6 +181,8 @@ meson_options_help() {
printf "%s\n" ' vhost-vdpa vhost-vdpa kernel backend support'
printf "%s\n" ' virglrenderer virgl rendering support'
printf "%s\n" ' virtfs virtio-9p support'
+ printf "%s\n" ' virtfs-proxy-helper'
+ printf "%s\n" ' virtio-9p proxy helper support'
printf "%s\n" ' vmdkvmdk image format support'
printf "%s\n" ' vmnet vmnet.framework network backend support'
printf "%s\n" ' vnc VNC server'
@@ -474,6 +476,8 @@ _meson_option_parse() {
--disable-virglrenderer) printf "%s" -Dvirglrenderer=disabled ;;
--enable-virtfs) printf "%s" -Dvirtfs=enabled ;;
--disable-virtfs) printf "%s" -Dvirtfs=disabled ;;
+--enable-virtfs-proxy-helper) printf "%s" -Dvirtfs_proxy_helper=enabled ;;
+--disable-virtfs-proxy-helper) printf "%s" -Dvirtfs_proxy_helper=disabled
;;
--enable-vmdk) printf "%s" -Dvmdk=enabled ;;
--disable-vmdk) printf "%s" -Dvmdk=disabled ;;
--enable-vmnet) printf "%s" -Dvmnet=enabled ;;
--
2.30.2
[PULL 3/4] 9pfs/xen: Fix segfault on shutdown
From: Jason Andryuk
xen_9pfs_free can't use gnttabdev since it is already closed and NULL-ed
out when free is called. Do the teardown in _disconnect(). This
matches the setup done in _connect().
trace-events are also added for the XenDevOps functions.
Signed-off-by: Jason Andryuk
Reviewed-by: Stefano Stabellini
Message-Id: <20230502143722.15613-1-jandr...@gmail.com>
[C.S.: - Remove redundant return in xen_9pfs_free().
- Add comment to trace-events. ]
Signed-off-by: Christian Schoenebeck
---
hw/9pfs/trace-events | 6 ++
hw/9pfs/xen-9p-backend.c | 35 ++-
2 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/hw/9pfs/trace-events b/hw/9pfs/trace-events
index 6c77966c0b..a12e55c165 100644
--- a/hw/9pfs/trace-events
+++ b/hw/9pfs/trace-events
@@ -48,3 +48,9 @@ v9fs_readlink(uint16_t tag, uint8_t id, int32_t fid) "tag %d
id %d fid %d"
v9fs_readlink_return(uint16_t tag, uint8_t id, char* target) "tag %d id %d
name %s"
v9fs_setattr(uint16_t tag, uint8_t id, int32_t fid, int32_t valid, int32_t
mode, int32_t uid, int32_t gid, int64_t size, int64_t atime_sec, int64_t
mtime_sec) "tag %u id %u fid %d iattr={valid %d mode %d uid %d gid %d size
%"PRId64" atime=%"PRId64" mtime=%"PRId64" }"
v9fs_setattr_return(uint16_t tag, uint8_t id) "tag %u id %u"
+
+# xen-9p-backend.c
+xen_9pfs_alloc(char *name) "name %s"
+xen_9pfs_connect(char *name) "name %s"
+xen_9pfs_disconnect(char *name) "name %s"
+xen_9pfs_free(char *name) "name %s"
diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 0e266c552b..4aa9c8c736 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -25,6 +25,8 @@
#include "qemu/iov.h"
#include "fsdev/qemu-fsdev.h"
+#include "trace.h"
+
#define VERSIONS "1"
#define MAX_RINGS 8
#define MAX_RING_ORDER 9
@@ -337,6 +339,8 @@ static void xen_9pfs_disconnect(struct XenLegacyDevice
*xendev)
Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
int i;
+trace_xen_9pfs_disconnect(xendev->name);
+
for (i = 0; i < xen_9pdev->num_rings; i++) {
if (xen_9pdev->rings[i].evtchndev != NULL) {
qemu_set_fd_handler(qemu_xen_evtchn_fd(xen_9pdev->rings[i].evtchndev),
@@ -345,40 +349,41 @@ static void xen_9pfs_disconnect(struct XenLegacyDevice
*xendev)
xen_9pdev->rings[i].local_port);
xen_9pdev->rings[i].evtchndev = NULL;
}
-}
-}
-
-static int xen_9pfs_free(struct XenLegacyDevice *xendev)
-{
-Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
-int i;
-
-if (xen_9pdev->rings[0].evtchndev != NULL) {
-xen_9pfs_disconnect(xendev);
-}
-
-for (i = 0; i < xen_9pdev->num_rings; i++) {
if (xen_9pdev->rings[i].data != NULL) {
xen_be_unmap_grant_refs(_9pdev->xendev,
xen_9pdev->rings[i].data,
xen_9pdev->rings[i].intf->ref,
(1 << xen_9pdev->rings[i].ring_order));
+xen_9pdev->rings[i].data = NULL;
}
if (xen_9pdev->rings[i].intf != NULL) {
xen_be_unmap_grant_ref(_9pdev->xendev,
xen_9pdev->rings[i].intf,
xen_9pdev->rings[i].ref);
+xen_9pdev->rings[i].intf = NULL;
}
if (xen_9pdev->rings[i].bh != NULL) {
qemu_bh_delete(xen_9pdev->rings[i].bh);
+xen_9pdev->rings[i].bh = NULL;
}
}
g_free(xen_9pdev->id);
+xen_9pdev->id = NULL;
g_free(xen_9pdev->tag);
+xen_9pdev->tag = NULL;
g_free(xen_9pdev->path);
+xen_9pdev->path = NULL;
g_free(xen_9pdev->security_model);
+xen_9pdev->security_model = NULL;
g_free(xen_9pdev->rings);
+xen_9pdev->rings = NULL;
+}
+
+static int xen_9pfs_free(struct XenLegacyDevice *xendev)
+{
+trace_xen_9pfs_free(xendev->name);
+
return 0;
}
@@ -390,6 +395,8 @@ static int xen_9pfs_connect(struct XenLegacyDevice *xendev)
V9fsState *s = _9pdev->state;
QemuOpts *fsdev;
+trace_xen_9pfs_connect(xendev->name);
+
if (xenstore_read_fe_int(_9pdev->xendev, "num-rings",
_9pdev->num_rings) == -1 ||
xen_9pdev->num_rings > MAX_RINGS || xen_9pdev->num_rings < 1) {
@@ -499,6 +506,8 @@ out:
static void xen_9pfs_alloc(struct XenLegacyDevice *xendev)
{
+trace_xen_9pfs_alloc(xendev->name);
+
xenstore_write_be_str(xendev, "versions", VERSIONS);
xenstore_write_be_int(xendev, "max-rings", MAX_RINGS);
xenstore_write_be_int(xendev, "max-ring-page-order", MAX_RING_ORDER);
--
2.30.2
[PULL 2/4] tests/9p: fix potential leak in v9fs_rreaddir()
Free allocated directory entries in v9fs_rreaddir() if argument
`entries` was passed as NULL, to avoid a memory leak. It is
explicitly allowed by design for `entries` to be NULL. [1]
[1] https://lore.kernel.org/all/1690923.g4PEXVpXuU@silver
Reported-by: Coverity (CID 1487558)
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Message-Id:
---
tests/qtest/libqos/virtio-9p-client.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/qtest/libqos/virtio-9p-client.c
b/tests/qtest/libqos/virtio-9p-client.c
index e4a368e036..b8adc8d4b9 100644
--- a/tests/qtest/libqos/virtio-9p-client.c
+++ b/tests/qtest/libqos/virtio-9p-client.c
@@ -594,6 +594,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
*nentries,
{
uint32_t local_count;
struct V9fsDirent *e = NULL;
+/* only used to avoid a leak if entries was NULL */
+struct V9fsDirent *unused_entries = NULL;
uint16_t slen;
uint32_t n = 0;
@@ -612,6 +614,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
*nentries,
e = g_new(struct V9fsDirent, 1);
if (entries) {
*entries = e;
+} else {
+unused_entries = e;
}
} else {
e = e->next = g_new(struct V9fsDirent, 1);
@@ -628,6 +632,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
*nentries,
*nentries = n;
}
+v9fs_free_dirents(unused_entries);
v9fs_req_free(req);
}
--
2.30.2
[PULL 0/4] 9p queue 2023-05-16
The following changes since commit ab4c44d657aeca7e1da6d6dcb1741c8e7d357b8b: Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2023-05-15 13:54:33 -0700) are available in the Git repository at: https://github.com/cschoenebeck/qemu.git tags/pull-9p-20230516 for you to fetch changes up to 3887702e5f8995638c98f9d9326b4913fb107be7: configure: make clear that VirtFS is 9p (2023-05-16 16:21:54 +0200) 9pfs: fixes * Fixes for Xen, configure and a theoretical leak. Christian Schoenebeck (2): tests/9p: fix potential leak in v9fs_rreaddir() configure: make clear that VirtFS is 9p Jason Andryuk (1): 9pfs/xen: Fix segfault on shutdown Peter Foley (1): Don't require libcap-ng for virtfs support hw/9pfs/trace-events | 6 ++ hw/9pfs/xen-9p-backend.c | 35 ++- meson.build | 14 ++ meson_options.txt | 2 ++ scripts/meson-buildoptions.sh | 4 tests/qtest/libqos/virtio-9p-client.c | 5 + 6 files changed, 49 insertions(+), 17 deletions(-)
[PULL 4/4] configure: make clear that VirtFS is 9p
Add '9P' to the summary output section of 'VirtFS' to avoid being
confused with virtiofs.
Based-on: <20230503130757.863824-1-pefo...@google.com>
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Reviewed-by: Thomas Huth
Message-Id:
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index c6b05149e9..5e2807ea7c 100644
--- a/meson.build
+++ b/meson.build
@@ -3930,8 +3930,8 @@ if have_block
summary_info += {'Block whitelist (rw)':
get_option('block_drv_rw_whitelist')}
summary_info += {'Block whitelist (ro)':
get_option('block_drv_ro_whitelist')}
summary_info += {'Use block whitelist in tools':
get_option('block_drv_whitelist_in_tools')}
- summary_info += {'VirtFS support':have_virtfs}
- summary_info += {'VirtFS Proxy Helper support': have_virtfs_proxy_helper}
+ summary_info += {'VirtFS (9P) support':have_virtfs}
+ summary_info += {'VirtFS (9P) Proxy Helper support':
have_virtfs_proxy_helper}
summary_info += {'Live block migration':
config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
summary_info += {'replication support':
config_host_data.get('CONFIG_REPLICATION')}
summary_info += {'bochs support': get_option('bochs').allowed()}
--
2.30.2
Re: [PATCH] configure: make clear that VirtFS is 9p
On Thursday, May 11, 2023 4:12:34 PM CEST Christian Schoenebeck wrote:
> Add '9P' to the summary output section of 'VirtFS' to avoid being
> confused with virtiofs.
>
> Based-on: <20230503130757.863824-1-pefo...@google.com>
> Signed-off-by: Christian Schoenebeck
> ---
> meson.build | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next
Thanks!
Best regards,
Christian Schoenebeck
> diff --git a/meson.build b/meson.build
> index 5d8373b608..5d65f53fec 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -3922,8 +3922,8 @@ if have_block
>summary_info += {'Block whitelist (rw)':
> get_option('block_drv_rw_whitelist')}
>summary_info += {'Block whitelist (ro)':
> get_option('block_drv_ro_whitelist')}
>summary_info += {'Use block whitelist in tools':
> get_option('block_drv_whitelist_in_tools')}
> - summary_info += {'VirtFS support':have_virtfs}
> - summary_info += {'VirtFS Proxy Helper support': have_virtfs_proxy_helper}
> + summary_info += {'VirtFS (9P) support':have_virtfs}
> + summary_info += {'VirtFS (9P) Proxy Helper support':
> have_virtfs_proxy_helper}
>summary_info += {'Live block migration':
> config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
>summary_info += {'replication support':
> config_host_data.get('CONFIG_REPLICATION')}
>summary_info += {'bochs support': get_option('bochs').allowed()}
>
Re: [PATCH] 9pfs/xen: Fix segfault on shutdown
On Tuesday, May 2, 2023 4:37:22 PM CEST Jason Andryuk wrote: > xen_9pfs_free can't use gnttabdev since it is already closed and NULL-ed > out when free is called. Do the teardown in _disconnect(). This > matches the setup done in _connect(). > > trace-events are also added for the XenDevOps functions. > > Signed-off-by: Jason Andryuk > --- > hw/9pfs/trace-events | 5 + > hw/9pfs/xen-9p-backend.c | 36 +++- > 2 files changed, 28 insertions(+), 13 deletions(-) With aforementioned 2 minor changes, queued on 9p.next: https://github.com/cschoenebeck/qemu/commits/9p.next Thanks! Best regards, Christian Schoenebeck
[PATCH] configure: make clear that VirtFS is 9p
Add '9P' to the summary output section of 'VirtFS' to avoid being
confused with virtiofs.
Based-on: <20230503130757.863824-1-pefo...@google.com>
Signed-off-by: Christian Schoenebeck
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 5d8373b608..5d65f53fec 100644
--- a/meson.build
+++ b/meson.build
@@ -3922,8 +3922,8 @@ if have_block
summary_info += {'Block whitelist (rw)':
get_option('block_drv_rw_whitelist')}
summary_info += {'Block whitelist (ro)':
get_option('block_drv_ro_whitelist')}
summary_info += {'Use block whitelist in tools':
get_option('block_drv_whitelist_in_tools')}
- summary_info += {'VirtFS support':have_virtfs}
- summary_info += {'VirtFS Proxy Helper support': have_virtfs_proxy_helper}
+ summary_info += {'VirtFS (9P) support':have_virtfs}
+ summary_info += {'VirtFS (9P) Proxy Helper support':
have_virtfs_proxy_helper}
summary_info += {'Live block migration':
config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
summary_info += {'replication support':
config_host_data.get('CONFIG_REPLICATION')}
summary_info += {'bochs support': get_option('bochs').allowed()}
--
2.30.2
Re: [PATCH] 9pfs/xen: Fix segfault on shutdown
Hi Jason,
as this is a Xen specific change, I would like Stefano or another Xen
developer to take a look at it, just few things from my side ...
On Tuesday, May 2, 2023 4:37:22 PM CEST Jason Andryuk wrote:
> xen_9pfs_free can't use gnttabdev since it is already closed and NULL-ed
Where exactly does it do that access? A backtrace or another detailed commit
log description would help.
> out when free is called. Do the teardown in _disconnect(). This
> matches the setup done in _connect().
>
> trace-events are also added for the XenDevOps functions.
>
> Signed-off-by: Jason Andryuk
> ---
> hw/9pfs/trace-events | 5 +
> hw/9pfs/xen-9p-backend.c | 36 +++-
> 2 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/hw/9pfs/trace-events b/hw/9pfs/trace-events
> index 6c77966c0b..7b5b0b5a48 100644
> --- a/hw/9pfs/trace-events
> +++ b/hw/9pfs/trace-events
> @@ -48,3 +48,8 @@ v9fs_readlink(uint16_t tag, uint8_t id, int32_t fid) "tag
> %d id %d fid %d"
> v9fs_readlink_return(uint16_t tag, uint8_t id, char* target) "tag %d id %d
> name %s"
> v9fs_setattr(uint16_t tag, uint8_t id, int32_t fid, int32_t valid, int32_t
> mode, int32_t uid, int32_t gid, int64_t size, int64_t atime_sec, int64_t
> mtime_sec) "tag %u id %u fid %d iattr={valid %d mode %d uid %d gid %d size
> %"PRId64" atime=%"PRId64" mtime=%"PRId64" }"
> v9fs_setattr_return(uint16_t tag, uint8_t id) "tag %u id %u"
> +
Nit-picking; missing leading comment:
# xen-9p-backend.c
> +xen_9pfs_alloc(char *name) "name %s"
> +xen_9pfs_connect(char *name) "name %s"
> +xen_9pfs_disconnect(char *name) "name %s"
> +xen_9pfs_free(char *name) "name %s"
> diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
> index 0e266c552b..c646a0b3d1 100644
> --- a/hw/9pfs/xen-9p-backend.c
> +++ b/hw/9pfs/xen-9p-backend.c
> @@ -25,6 +25,8 @@
> #include "qemu/iov.h"
> #include "fsdev/qemu-fsdev.h"
>
> +#include "trace.h"
> +
> #define VERSIONS "1"
> #define MAX_RINGS 8
> #define MAX_RING_ORDER 9
> @@ -337,6 +339,8 @@ static void xen_9pfs_disconnect(struct XenLegacyDevice
> *xendev)
> Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
> int i;
>
> +trace_xen_9pfs_disconnect(xendev->name);
> +
> for (i = 0; i < xen_9pdev->num_rings; i++) {
> if (xen_9pdev->rings[i].evtchndev != NULL) {
>
> qemu_set_fd_handler(qemu_xen_evtchn_fd(xen_9pdev->rings[i].evtchndev),
> @@ -345,40 +349,42 @@ static void xen_9pfs_disconnect(struct XenLegacyDevice
> *xendev)
> xen_9pdev->rings[i].local_port);
> xen_9pdev->rings[i].evtchndev = NULL;
> }
> -}
> -}
> -
> -static int xen_9pfs_free(struct XenLegacyDevice *xendev)
> -{
> -Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
> -int i;
> -
> -if (xen_9pdev->rings[0].evtchndev != NULL) {
> -xen_9pfs_disconnect(xendev);
> -}
> -
> -for (i = 0; i < xen_9pdev->num_rings; i++) {
> if (xen_9pdev->rings[i].data != NULL) {
> xen_be_unmap_grant_refs(_9pdev->xendev,
> xen_9pdev->rings[i].data,
> xen_9pdev->rings[i].intf->ref,
> (1 << xen_9pdev->rings[i].ring_order));
> +xen_9pdev->rings[i].data = NULL;
> }
> if (xen_9pdev->rings[i].intf != NULL) {
> xen_be_unmap_grant_ref(_9pdev->xendev,
> xen_9pdev->rings[i].intf,
> xen_9pdev->rings[i].ref);
> +xen_9pdev->rings[i].intf = NULL;
> }
> if (xen_9pdev->rings[i].bh != NULL) {
> qemu_bh_delete(xen_9pdev->rings[i].bh);
> +xen_9pdev->rings[i].bh = NULL;
> }
> }
>
> g_free(xen_9pdev->id);
> +xen_9pdev->id = NULL;
> g_free(xen_9pdev->tag);
> +xen_9pdev->tag = NULL;
> g_free(xen_9pdev->path);
> +xen_9pdev->path = NULL;
> g_free(xen_9pdev->security_model);
> +xen_9pdev->security_model = NULL;
> g_free(xen_9pdev->rings);
> +xen_9pdev->rings = NULL;
> +return;
> +}
> +
> +static int xen_9pfs_free(struct XenLegacyDevice *xendev)
> +{
> +trace_xen_9pfs_free(xendev->name);
> +
> return 0;
> }
xen_9pfs_free() doing nothing, that doesn't look right to me. Wouldn't it make
sense to turn xen_9pfs_free() idempotent instead?
>
> @@ -390,6 +396,8 @@ static int xen_9pfs_connect(struct XenLegacyDevice
> *xendev)
> V9fsState *s = _9pdev->state;
> QemuOpts *fsdev;
>
> +trace_xen_9pfs_connect(xendev->name);
> +
> if (xenstore_read_fe_int(_9pdev->xendev, "num-rings",
> _9pdev->num_rings) == -1 ||
> xen_9pdev->num_rings > MAX_RINGS || xen_9pdev->num_rings < 1) {
> @@ -499,6 +507,8 @@ out:
>
> static void xen_9pfs_alloc(struct XenLegacyDevice *xendev)
> {
> +
Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
On Saturday, April 29, 2023 11:25:33 AM CEST Christian Schoenebeck wrote:
> Free allocated directory entries in v9fs_rreaddir() if argument
> `entries` was passed as NULL, to avoid a memory leak. It is
> explicitly allowed by design for `entries` to be NULL. [1]
>
> [1] https://lore.kernel.org/all/1690923.g4PEXVpXuU@silver
>
> Reported-by: Coverity (CID 1487558)
> Signed-off-by: Christian Schoenebeck
> ---
Queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next
Thanks!
Best regards,
Christian Schoenebeck
> tests/qtest/libqos/virtio-9p-client.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tests/qtest/libqos/virtio-9p-client.c
> b/tests/qtest/libqos/virtio-9p-client.c
> index e4a368e036..b8adc8d4b9 100644
> --- a/tests/qtest/libqos/virtio-9p-client.c
> +++ b/tests/qtest/libqos/virtio-9p-client.c
> @@ -594,6 +594,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
> *nentries,
> {
> uint32_t local_count;
> struct V9fsDirent *e = NULL;
> +/* only used to avoid a leak if entries was NULL */
> +struct V9fsDirent *unused_entries = NULL;
> uint16_t slen;
> uint32_t n = 0;
>
> @@ -612,6 +614,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
> *nentries,
> e = g_new(struct V9fsDirent, 1);
> if (entries) {
> *entries = e;
> +} else {
> +unused_entries = e;
> }
> } else {
> e = e->next = g_new(struct V9fsDirent, 1);
> @@ -628,6 +632,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
> *nentries,
> *nentries = n;
> }
>
> +v9fs_free_dirents(unused_entries);
> v9fs_req_free(req);
> }
>
>
Re: [PATCH v3] Don't require libcap-ng for virtfs support
On Wednesday, May 3, 2023 3:07:56 PM CEST Peter Foley wrote:
> It's only required for the proxy helper.
>
> Add a new option for the proxy helper rather than enabling it
> implicitly.
>
> Change-Id: I95b73fca625529e99d16b0a64e01c65c0c1d43f2
> Signed-off-by: Peter Foley
> ---
LGTM now, queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next
Thanks!
Best regards,
Christian Schoenebeck
> meson.build | 12 +---
> meson_options.txt | 2 ++
> scripts/meson-buildoptions.sh | 4
> 3 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 77d42898c8..a46bc67cdb 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1759,12 +1759,17 @@ have_virtfs = get_option('virtfs') \
> error_message: 'virtio-9p (virtfs) requires Linux or macOS') \
> .require(targetos == 'linux' or cc.has_function('pthread_fchdir_np'),
> error_message: 'virtio-9p (virtfs) on macOS requires the
> presence of pthread_fchdir_np') \
> -.require(targetos == 'darwin' or (libattr.found() and libcap_ng.found()),
> - error_message: 'virtio-9p (virtfs) on Linux requires
> libcap-ng-devel and libattr-devel') \
> +.require(targetos == 'darwin' or libattr.found(),
> + error_message: 'virtio-9p (virtfs) on Linux requires
> libattr-devel') \
> .disable_auto_if(not have_tools and not have_system) \
> .allowed()
>
> -have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and
> have_tools
> +have_virtfs_proxy_helper = get_option('virtfs_proxy_helper') \
> +.require(targetos != 'darwin', error_message: 'the virtfs proxy helper
> is incompatible with macOS') \
> +.require(have_virtfs, error_message: 'the virtfs proxy helper requires
> that virtfs is enabled') \
> +.disable_auto_if(not have_tools) \
> +.require(libcap_ng.found(), error_message: 'the virtfs proxy helper
> requires libcap-ng') \
> +.allowed()
>
> if get_option('block_drv_ro_whitelist') == ''
>config_host_data.set('CONFIG_BDRV_RO_WHITELIST', '')
> @@ -3911,6 +3916,7 @@ if have_block
>summary_info += {'Block whitelist (ro)':
> get_option('block_drv_ro_whitelist')}
>summary_info += {'Use block whitelist in tools':
> get_option('block_drv_whitelist_in_tools')}
>summary_info += {'VirtFS support':have_virtfs}
> + summary_info += {'VirtFS Proxy Helper support': have_virtfs_proxy_helper}
>summary_info += {'Live block migration':
> config_host_data.get('CONFIG_LIVE_BLOCK_MIGRATION')}
>summary_info += {'replication support':
> config_host_data.get('CONFIG_REPLICATION')}
>summary_info += {'bochs support': get_option('bochs').allowed()}
> diff --git a/meson_options.txt b/meson_options.txt
> index 2471dd02da..908b4b7fd9 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -272,6 +272,8 @@ option('vhost_user_blk_server', type: 'feature', value:
> 'auto',
> description: 'build vhost-user-blk server')
> option('virtfs', type: 'feature', value: 'auto',
> description: 'virtio-9p support')
> +option('virtfs_proxy_helper', type: 'feature', value: 'auto',
> + description: 'virtio-9p proxy helper support')
> option('libvduse', type: 'feature', value: 'auto',
> description: 'build VDUSE Library')
> option('vduse_blk_export', type: 'feature', value: 'auto',
> diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
> index d4369a3ad8..3bb9dd3504 100644
> --- a/scripts/meson-buildoptions.sh
> +++ b/scripts/meson-buildoptions.sh
> @@ -176,6 +176,8 @@ meson_options_help() {
>printf "%s\n" ' vhost-vdpa vhost-vdpa kernel backend support'
>printf "%s\n" ' virglrenderer virgl rendering support'
>printf "%s\n" ' virtfs virtio-9p support'
> + printf "%s\n" ' virtfs-proxy-helper'
> + printf "%s\n" ' virtio-9p proxy helper support'
>printf "%s\n" ' vmnet vmnet.framework network backend support'
>printf "%s\n" ' vnc VNC server'
>printf "%s\n" ' vnc-jpegJPEG lossy compression for VNC server'
> @@ -461,6 +463,8 @@ _meson_option_parse() {
> --disable-virglrenderer) printf "%s" -Dvirglrenderer=disabled ;;
> --enable-virtfs) printf "%s" -Dvirtfs=enabled ;;
> --disable-virtfs) printf "%s" -Dvirtfs=disabled ;;
> +--enable-virtfs-proxy-helper) printf "%s" -Dvirtfs_proxy_helper=enabled
> ;;
> +--disable-virtfs-proxy-helper) printf "%s"
> -Dvirtfs_proxy_helper=disabled ;;
> --enable-vmnet) printf "%s" -Dvmnet=enabled ;;
> --disable-vmnet) printf "%s" -Dvmnet=disabled ;;
> --enable-vnc) printf "%s" -Dvnc=enabled ;;
>
Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
On Saturday, April 29, 2023 2:04:30 PM CEST Greg Kurz wrote:
> Hi Christian !
Hi there, it's been a while! :)
> On Sat, 29 Apr 2023 11:25:33 +0200
> Christian Schoenebeck wrote:
>
> > Free allocated directory entries in v9fs_rreaddir() if argument
> > `entries` was passed as NULL, to avoid a memory leak. It is
> > explicitly allowed by design for `entries` to be NULL. [1]
> >
> > [1] https://lore.kernel.org/all/1690923.g4PEXVpXuU@silver
> >
> > Reported-by: Coverity (CID 1487558)
> > Signed-off-by: Christian Schoenebeck
> > ---
>
> Good catch Coverity ! :-)
Yeah, this Coverity report is actually from March and I ignored it so far,
because the reported leak could never happen with current test code. But Paolo
brought it up this week, so ...
> Reviewed-by: Greg Kurz
>
> I still have a suggestion. See below.
>
> > tests/qtest/libqos/virtio-9p-client.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/tests/qtest/libqos/virtio-9p-client.c
> > b/tests/qtest/libqos/virtio-9p-client.c
> > index e4a368e036..b8adc8d4b9 100644
> > --- a/tests/qtest/libqos/virtio-9p-client.c
> > +++ b/tests/qtest/libqos/virtio-9p-client.c
> > @@ -594,6 +594,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count,
> > uint32_t *nentries,
> > {
> > uint32_t local_count;
> > struct V9fsDirent *e = NULL;
> > +/* only used to avoid a leak if entries was NULL */
> > +struct V9fsDirent *unused_entries = NULL;
> > uint16_t slen;
> > uint32_t n = 0;
> >
> > @@ -612,6 +614,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count,
> > uint32_t *nentries,
> > e = g_new(struct V9fsDirent, 1);
> > if (entries) {
> > *entries = e;
> > +} else {
> > +unused_entries = e;
> > }
> > } else {
> > e = e->next = g_new(struct V9fsDirent, 1);
>
> This is always allocating and chaining a new entry even
> though it isn't needed in the entries == NULL case.
>
> > @@ -628,6 +632,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count,
> > uint32_t *nentries,
> > *nentries = n;
> > }
> >
> > +v9fs_free_dirents(unused_entries);
>
> This is going to loop again on all entries to free them.
>
> > v9fs_req_free(req);
> > }
> >
>
> If this function is to be called one day with an enormous
> number of entries and entries == NULL case, this might
> not scale well.
>
> What about only allocating a single entry in this case ?
>
> E.g.
>
> @@ -593,7 +593,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
> *nentries,
> struct V9fsDirent **entries)
> {
> uint32_t local_count;
> -struct V9fsDirent *e = NULL;
> +g_autofree struct V9fsDirent *e = NULL;
> uint16_t slen;
> uint32_t n = 0;
>
> @@ -611,10 +611,12 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count,
> uint32_t *nentries,
> if (!e) {
> e = g_new(struct V9fsDirent, 1);
> if (entries) {
> -*entries = e;
> +*entries = g_steal_pointer(e);
g_steal_pointer(e) just sets `e` to NULL and returns its old value, so ...
> }
> } else {
> -e = e->next = g_new(struct V9fsDirent, 1);
> +if (entries) {
> +e = e->next = g_new(struct V9fsDirent, 1);
> +}
... this `else` block would never be reached and no list assembled.
> }
> e->next = NULL;
> /* qid[13] offset[8] type[1] name[s] */
And even if above's issue was fixed, then it would cause a use-after-free for
the last element in the list if entries != NULL and caller trying to access
the last element afterwards. So you would still need a separate g_autofree
pointer instead of tagging `e` directly, or something like this after loop
end:
if (entries)
g_steal_pointer(e);
Which would somehow defeat the purpose of using g_autofree though.
I mean, yes this could be addressed, but is it worth it? I don't know. Even
this reported leak is a purely theoretical one, but I understand if people
want to silence a warning.
Best regards,
Christian Schoenebeck
[PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
Free allocated directory entries in v9fs_rreaddir() if argument
`entries` was passed as NULL, to avoid a memory leak. It is
explicitly allowed by design for `entries` to be NULL. [1]
[1] https://lore.kernel.org/all/1690923.g4PEXVpXuU@silver
Reported-by: Coverity (CID 1487558)
Signed-off-by: Christian Schoenebeck
---
tests/qtest/libqos/virtio-9p-client.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/qtest/libqos/virtio-9p-client.c
b/tests/qtest/libqos/virtio-9p-client.c
index e4a368e036..b8adc8d4b9 100644
--- a/tests/qtest/libqos/virtio-9p-client.c
+++ b/tests/qtest/libqos/virtio-9p-client.c
@@ -594,6 +594,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
*nentries,
{
uint32_t local_count;
struct V9fsDirent *e = NULL;
+/* only used to avoid a leak if entries was NULL */
+struct V9fsDirent *unused_entries = NULL;
uint16_t slen;
uint32_t n = 0;
@@ -612,6 +614,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
*nentries,
e = g_new(struct V9fsDirent, 1);
if (entries) {
*entries = e;
+} else {
+unused_entries = e;
}
} else {
e = e->next = g_new(struct V9fsDirent, 1);
@@ -628,6 +632,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
*nentries,
*nentries = n;
}
+v9fs_free_dirents(unused_entries);
v9fs_req_free(req);
}
--
2.30.2
Re: [PATCH] tests: virtio-9p-client: Rreaddir fields are all mandatory
On Thursday, April 27, 2023 3:10:23 PM CEST Paolo Bonzini wrote:
> If rreaddir.entries is NULL, the resulting dirent list is leaked.
> Check that the rreaddir case is filled correctly in the caller
> when treaddir succeeds; this then makes it possible to remove
> the conditionals is v9fs_rreaddir.
>
> Reported by Coverity.
That's an old defects report, right? I remember I saw something like this last
year and ignored it as being purely theoretical.
> Cc: Christian Schoenebeck
> Signed-off-by: Paolo Bonzini
> ---
> tests/qtest/libqos/virtio-9p-client.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/tests/qtest/libqos/virtio-9p-client.c
> b/tests/qtest/libqos/virtio-9p-client.c
> index e4a368e03660..17125e78deae 100644
> --- a/tests/qtest/libqos/virtio-9p-client.c
> +++ b/tests/qtest/libqos/virtio-9p-client.c
> @@ -579,6 +579,7 @@ TReadDirRes v9fs_treaddir(TReadDirOpt opt)
> v9fs_rlerror(req, );
> g_assert_cmpint(err, ==, opt.expectErr);
> } else {
> +g_assert(opt.rreaddir.count && opt.rreaddir.nentries &&
> opt.rreaddir.entries);
That would be the opposite of what recent test code restructuring was about:
it reduced overall 9p test code complexity by relaxing how the actual 9p unit
tests (virtio-9p-test.c) shall call the underlying 9p client functions
(virtio-9p-client.c):
https://lore.kernel.org/all/cover.1664917004.git.qemu_...@crudebyte.com/
>From virtio-9p-client.h:
/* options for 'Treaddir' 9p request */
typedef struct TReadDirOpt {
/* 9P client being used (mandatory) */
QVirtio9P *client;
/* user supplied tag number being returned with response (optional) */
uint16_t tag;
/* file ID of directory whose entries shall be retrieved (required) */
uint32_t fid;
/* offset in entries stream, i.e. for multiple requests (optional) */
uint64_t offset;
/* maximum bytes to be returned by server (required) */
uint32_t count;
/* data being received from 9p server as 'Rreaddir' response (optional) */
struct {
uint32_t *count;
uint32_t *nentries;
struct V9fsDirent **entries;
} rreaddir;
/* only send Treaddir request but not wait for a reply? (optional) */
bool requestOnly;
/* do we expect an Rlerror response, if yes which error code? (optional) */
uint32_t expectErr;
} TReadDirOpt;
So the burden to deal with the individual use cases was moved from the 9p unit
tests down to the client code. Because that's easier to read and maintain than
having to let each unit test deal with all sorts of requirements that it has no
use for in the first place.
> v9fs_rreaddir(req, opt.rreaddir.count, opt.rreaddir.nentries,
>opt.rreaddir.entries);
> }
> @@ -600,9 +601,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
> *nentries,
> v9fs_req_recv(req, P9_RREADDIR);
> v9fs_uint32_read(req, _count);
>
> -if (count) {
> -*count = local_count;
> -}
> +*count = local_count;
>
> for (int32_t togo = (int32_t)local_count;
> togo >= 13 + 8 + 1 + 2;
> @@ -610,9 +609,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
> *nentries,
> {
> if (!e) {
> e = g_new(struct V9fsDirent, 1);
> -if (entries) {
> -*entries = e;
> -}
> +*entries = e;
I would just add a local auto free pointer in this function that is assigned
to in case argument `entries` was passed as NULL, and not change overall
behaviour and requirements.
> } else {
> e = e->next = g_new(struct V9fsDirent, 1);
> }
> @@ -624,10 +621,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t
> *nentries,
> v9fs_string_read(req, , >name);
> }
>
> -if (nentries) {
> -*nentries = n;
> -}
> -
> +*nentries = n;
> v9fs_req_free(req);
> }
>
>
Re: [PATCH] Don't require libcap-ng for virtfs support
On Friday, April 21, 2023 3:53:27 PM CEST Peter Foley wrote:
> It's only required for the proxy helper.
>
> Signed-off-by: Peter Foley
> ---
> meson.build | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index c44d05a13f..1d4888b1c0 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1759,12 +1759,12 @@ have_virtfs = get_option('virtfs') \
> error_message: 'virtio-9p (virtfs) requires Linux or macOS') \
> .require(targetos == 'linux' or cc.has_function('pthread_fchdir_np'),
> error_message: 'virtio-9p (virtfs) on macOS requires the
> presence of pthread_fchdir_np') \
> -.require(targetos == 'darwin' or (libattr.found() and libcap_ng.found()),
> - error_message: 'virtio-9p (virtfs) on Linux requires
> libcap-ng-devel and libattr-devel') \
> +.require(targetos == 'darwin' or libattr.found(),
> + error_message: 'virtio-9p (virtfs) on Linux requires
> libattr-devel') \
> .disable_auto_if(not have_tools and not have_system) \
> .allowed()
>
> -have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and
> have_tools
> +have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and
> have_tools and libcap_ng.found()
Well, I don't know how many people actually use the 9p proxy, if at all, but
don't you think there should be at least a warning or some kind of output e.g.
in the configure summary that QEMU would build without 9p proxy support just
because of a missing lib, instead of silently disabling it?
For macOS hosts we didn't care so far, because proxy is not implemented there
and probably never will.
>
> if get_option('block_drv_ro_whitelist') == ''
>config_host_data.set('CONFIG_BDRV_RO_WHITELIST', '')
>
Re: [PATCH 09/10] hw/9pfs: use qemu_xxhash4
On Thursday, April 20, 2023 5:00:08 PM CEST Alex Bennée wrote:
> No need to pass zeros as we have helpers that do that for us.
>
> Signed-off-by: Alex Bennée
> ---
> hw/9pfs/9p.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index 9621ec1341..9bf502c45f 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -741,12 +741,12 @@ static VariLenAffix affixForIndex(uint64_t index)
> /* creative abuse of tb_hash_func7, which is based on xxhash */
I guess this old comment could be dropped then.
Except of that:
Reviewed-by: Christian Schoenebeck
> static uint32_t qpp_hash(QppEntry e)
> {
> -return qemu_xxhash7(e.ino_prefix, e.dev, 0, 0, 0);
> +return qemu_xxhash4(e.ino_prefix, e.dev);
> }
>
> static uint32_t qpf_hash(QpfEntry e)
> {
> -return qemu_xxhash7(e.ino, e.dev, 0, 0, 0);
> +return qemu_xxhash4(e.ino, e.dev);
> }
>
> static bool qpd_cmp_func(const void *obj, const void *userp)
>
Re: [PATCH v5 04/16] hw/9pfs: Implement Windows specific xxxdir() APIs
On Friday, March 17, 2023 5:36:37 AM CET Shi, Guohuai wrote:
[...]
> > > > > > +do {
> > > > > > +full_dir_entry = get_full_path_win32(hDir,
> > > > > > + dd_data.name);
> > > > > > +
> > > > > > +if (full_dir_entry == NULL) {
> > > > > > +err = ENOMEM;
> > > > > > +break;
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Open every entry and get the file informations.
> > > > > > + *
> > > > > > + * Skip symbolic links during reading directory.
> > > > > > + */
> > > > > > +hDirEntry = CreateFile(full_dir_entry,
> > > > > > + GENERIC_READ,
> > > > > > + FILE_SHARE_READ | FILE_SHARE_WRITE
> > > > > > + | FILE_SHARE_DELETE,
> > > > > > + NULL,
> > > > > > + OPEN_EXISTING,
> > > > > > + FILE_FLAG_BACKUP_SEMANTICS
> > > > > > + | FILE_FLAG_OPEN_REPARSE_POINT,
> > > > > > + NULL);
> > > > > > +
> > > > > > +if (hDirEntry != INVALID_HANDLE_VALUE) {
> > > > > > +if (GetFileInformationByHandle(hDirEntry,
> > > > > > + ) == TRUE) {
> > > > > > +attribute = FileInfo.dwFileAttributes;
> > > > > > +
> > > > > > +/* only save validate entries */
> > > > > > +if ((attribute & FILE_ATTRIBUTE_REPARSE_POINT) ==
> > > > > > 0) {
> > > > > > +if (index >= list_count) {
> > > > > > +list_count = list_count + 16;
> > > > >
> > > > > Magic number 16 again.
> > > > >
> > > > > > +file_id_list = g_realloc(file_id_list,
> > > > > > + sizeof(uint64_t)
> > > > > > + * list_count);
> > > > >
> > > > > OK, so here we are finally at the point where you chose the
> > > > > overall behaviour for this that we discussed before.
> > > > >
> > > > > So you are constantly appending 16 entry chunks to the end of the
> > > > > array, periodically reallocate the entire array, and potentially
> > > > > end up with one giant dense array with *all* file IDs of the
> > > > > directory.
> > > > >
> > > > > That's not really what I had in mind, as it still has the
> > > > > potential to easily crash QEMU if there are large directories on host.
> > > > > Theoretically a Windows directory might then consume up to 16 GB
> > > > > of RAM for looking up only one single directory.
> > > > >
> > > > > So is this the implementation that you said was very slow, or did
> > > > > you test a different one? Remember, my orgiginal idea (as starting
> > > > > point for Windows) was to only cache *one* file ID (the last being
> > > > > looked up). That's it. Not a list of file IDs.
> > > >
> > > > If only cache one file ID, that means for every read directory
> > > > operation.
> > > > we need to look up whole directory to find out the next ID larger
> > > > than last
> > > cached one.
> > > >
> > > > I provided some performance test in last patch:
> > > > Run test for read directory with 100, 1000, 1 entries #1, For
> > > > file name cache solution, the time cost is: 2, 9, 44 (in ms).
> > > > #2, For file id cache solution, the time cost: 3, 438, 4338 (in ms).
> > > > This
> > > is current solution.
> > > > #3, for cache one id solution, I just tested it: 4, 4788, more than
> > > > one minutes (in ms)
> > > >
> > > > I think it is not a good idea to cache one file id, it would be very
> > > > bad performance
> > >
> > > Yes, the performce would be lousy, but at least we would have a basis
> > > that just works^TM. Correct behaviour always comes before performance.
> > > And from there you could add additional patches on top to address
> > > performance improvements. Because the point is: your implementation is
> > > also suboptimal, and more importantly: prone to crashes like we discussed
> > before.
> > >
> > > Regarding performance: for instance you are re-allocating an entire
> > > dense buffer on every 16 new entries. That will slow down things
> > > extremely. Please use a container from glib, because these are
> > > handling resize operations more smoothly for you out of the box, i.e.
> > > typically by doubling the container capacity instead of re-allocating
> > frequently with small chunks like you did.
> > >
> > > However I am still not convinced that allocating a huge dense buffer
> > > with
> > > *all* file IDs of a directory makes sense.
> > >
> > > On the long-term it would make sense to do it like other implementations:
> > > store a snapshot of the directory temporarily on disk. That way it
> > > would not matter how huge the directory is. But that's a complex
> > > implementation, so not something that I would do in this series already.
> > >
> > > On the
Re: [PATCH v5 04/16] hw/9pfs: Implement Windows specific xxxdir() APIs
On Wednesday, March 15, 2023 8:05:34 PM CET Shi, Guohuai wrote:
>
> > -Original Message-
> > From: Christian Schoenebeck
> > Sent: Wednesday, March 15, 2023 00:06
> > To: Greg Kurz ; qemu-devel@nongnu.org
> > Cc: Shi, Guohuai ; Meng, Bin
> >
> > Subject: Re: [PATCH v5 04/16] hw/9pfs: Implement Windows specific xxxdir()
> > APIs
> >
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and
> > know the content is safe.
> >
> > On Monday, February 20, 2023 11:08:03 AM CET Bin Meng wrote:
> > > From: Guohuai Shi
> > >
> > > This commit implements Windows specific xxxdir() APIs for safety
> > > directory access.
> >
> > That comment is seriously too short for this patch.
> >
> > 1. You should describe the behaviour implementation that you have chosen and
> > why you have chosen it.
> >
> > 2. Like already said in the previous version of the patch, you should place
> > a
> > link to the discussion we had on this issue.
> >
> > > Signed-off-by: Guohuai Shi
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > hw/9pfs/9p-util.h | 6 +
> > > hw/9pfs/9p-util-win32.c | 443
> > >
> > > 2 files changed, 449 insertions(+)
> > >
> > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h index
> > > 0f159fb4ce..c1c251fbd1 100644
> > > --- a/hw/9pfs/9p-util.h
> > > +++ b/hw/9pfs/9p-util.h
> > > @@ -141,6 +141,12 @@ int unlinkat_win32(int dirfd, const char
> > > *pathname, int flags); int statfs_win32(const char *root_path, struct
> > > statfs *stbuf); int openat_dir(int dirfd, const char *name); int
> > > openat_file(int dirfd, const char *name, int flags, mode_t mode);
> > > +DIR *opendir_win32(const char *full_file_name); int
> > > +closedir_win32(DIR *pDir); struct dirent *readdir_win32(DIR *pDir);
> > > +void rewinddir_win32(DIR *pDir); void seekdir_win32(DIR *pDir, long
> > > +pos); long telldir_win32(DIR *pDir);
> > > #endif
> > >
> > > static inline void close_preserve_errno(int fd) diff --git
> > > a/hw/9pfs/9p-util-win32.c b/hw/9pfs/9p-util-win32.c index
> > > a99d579a06..e9408f3c45 100644
> > > --- a/hw/9pfs/9p-util-win32.c
> > > +++ b/hw/9pfs/9p-util-win32.c
> > > @@ -37,6 +37,16 @@
> > > *Windows does not support opendir, the directory fd is created by
> > > *CreateFile and convert to fd by _open_osfhandle(). Keep the fd open
> > will
> > > *lock and protect the directory (can not be modified or replaced)
> > > + *
> > > + * 5. Neither Windows native APIs, nor MinGW provide a POSIX compatible
> > API for
> > > + *acquiring directory entries in a safe way. Calling those APIs
> > (native
> > > + *_findfirst() and _findnext() or MinGW's readdir(), seekdir() and
> > > + *telldir()) directly can lead to an inconsistent state if directory
> > is
> > > + *modified in between, e.g. the same directory appearing more than
> > once
> > > + *in output, or directories not appearing at all in output even
> > > though
> > they
> > > + *were neither newly created nor deleted. POSIX does not define what
> > happens
> > > + *with deleted or newly created directories in between, but it
> > guarantees a
> > > + *consistent state.
> > > */
> > >
> > > #include "qemu/osdep.h"
> > > @@ -51,6 +61,25 @@
> > >
> > > #define V9FS_MAGIC 0x53465039 /* string "9PFS" */
> > >
> > > +/*
> > > + * MinGW and Windows does not provide a safe way to seek directory
> > > +while other
> > > + * thread is modifying the same directory.
> > > + *
> > > + * This structure is used to store sorted file id and ensure
> > > +directory seek
> > > + * consistency.
> > > + */
> > > +struct dir_win32 {
> > > +struct dirent dd_dir;
> > > +uint32_t offset;
> > > +uint32_t total_entries;
> > > +HANDLE hDir;
> > > +uint32_t dir_name_len;
> > > +uint64_t dot_id;
> > > +uint64_t dot_dot_id;
> > > +uint64_t *file_id_list;
> > > +char dd_name[1];
> > > +};
> > > +
> > > /*
> > > * win32_error_to_posix - convert Win32 erro
Re: [PATCH v5 04/16] hw/9pfs: Implement Windows specific xxxdir() APIs
On Monday, February 20, 2023 11:08:03 AM CET Bin Meng wrote:
> From: Guohuai Shi
>
> This commit implements Windows specific xxxdir() APIs for safety
> directory access.
That comment is seriously too short for this patch.
1. You should describe the behaviour implementation that you have chosen and
why you have chosen it.
2. Like already said in the previous version of the patch, you should place a
link to the discussion we had on this issue.
> Signed-off-by: Guohuai Shi
> Signed-off-by: Bin Meng
> ---
>
> hw/9pfs/9p-util.h | 6 +
> hw/9pfs/9p-util-win32.c | 443
> 2 files changed, 449 insertions(+)
>
> diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> index 0f159fb4ce..c1c251fbd1 100644
> --- a/hw/9pfs/9p-util.h
> +++ b/hw/9pfs/9p-util.h
> @@ -141,6 +141,12 @@ int unlinkat_win32(int dirfd, const char *pathname, int
> flags);
> int statfs_win32(const char *root_path, struct statfs *stbuf);
> int openat_dir(int dirfd, const char *name);
> int openat_file(int dirfd, const char *name, int flags, mode_t mode);
> +DIR *opendir_win32(const char *full_file_name);
> +int closedir_win32(DIR *pDir);
> +struct dirent *readdir_win32(DIR *pDir);
> +void rewinddir_win32(DIR *pDir);
> +void seekdir_win32(DIR *pDir, long pos);
> +long telldir_win32(DIR *pDir);
> #endif
>
> static inline void close_preserve_errno(int fd)
> diff --git a/hw/9pfs/9p-util-win32.c b/hw/9pfs/9p-util-win32.c
> index a99d579a06..e9408f3c45 100644
> --- a/hw/9pfs/9p-util-win32.c
> +++ b/hw/9pfs/9p-util-win32.c
> @@ -37,6 +37,16 @@
> *Windows does not support opendir, the directory fd is created by
> *CreateFile and convert to fd by _open_osfhandle(). Keep the fd open
> will
> *lock and protect the directory (can not be modified or replaced)
> + *
> + * 5. Neither Windows native APIs, nor MinGW provide a POSIX compatible API
> for
> + *acquiring directory entries in a safe way. Calling those APIs (native
> + *_findfirst() and _findnext() or MinGW's readdir(), seekdir() and
> + *telldir()) directly can lead to an inconsistent state if directory is
> + *modified in between, e.g. the same directory appearing more than once
> + *in output, or directories not appearing at all in output even though
> they
> + *were neither newly created nor deleted. POSIX does not define what
> happens
> + *with deleted or newly created directories in between, but it
> guarantees a
> + *consistent state.
> */
>
> #include "qemu/osdep.h"
> @@ -51,6 +61,25 @@
>
> #define V9FS_MAGIC 0x53465039 /* string "9PFS" */
>
> +/*
> + * MinGW and Windows does not provide a safe way to seek directory while
> other
> + * thread is modifying the same directory.
> + *
> + * This structure is used to store sorted file id and ensure directory seek
> + * consistency.
> + */
> +struct dir_win32 {
> +struct dirent dd_dir;
> +uint32_t offset;
> +uint32_t total_entries;
> +HANDLE hDir;
> +uint32_t dir_name_len;
> +uint64_t dot_id;
> +uint64_t dot_dot_id;
> +uint64_t *file_id_list;
> +char dd_name[1];
> +};
> +
> /*
> * win32_error_to_posix - convert Win32 error to POSIX error number
> *
> @@ -977,3 +1006,417 @@ int qemu_mknodat(int dirfd, const char *filename,
> mode_t mode, dev_t dev)
> errno = ENOTSUP;
> return -1;
> }
> +
> +static int file_id_compare(const void *id_ptr1, const void *id_ptr2)
> +{
> +uint64_t id[2];
> +
> +id[0] = *(uint64_t *)id_ptr1;
> +id[1] = *(uint64_t *)id_ptr2;
> +
> +if (id[0] > id[1]) {
> +return 1;
> +} else if (id[0] < id[1]) {
> +return -1;
> +} else {
> +return 0;
> +}
> +}
> +
> +static int get_next_entry(struct dir_win32 *stream)
> +{
> +HANDLE hDirEntry = INVALID_HANDLE_VALUE;
> +char *entry_name;
> +char *entry_start;
> +FILE_ID_DESCRIPTOR fid;
> +DWORD attribute;
> +
> +if (stream->file_id_list[stream->offset] == stream->dot_id) {
> +strcpy(stream->dd_dir.d_name, ".");
> +return 0;
> +}
> +
> +if (stream->file_id_list[stream->offset] == stream->dot_dot_id) {
> +strcpy(stream->dd_dir.d_name, "..");
> +return 0;
> +}
> +
> +fid.dwSize = sizeof(fid);
> +fid.Type = FileIdType;
> +
> +fid.FileId.QuadPart = stream->file_id_list[stream->offset];
> +
> +hDirEntry = OpenFileById(stream->hDir, , GENERIC_READ,
> + FILE_SHARE_READ | FILE_SHARE_WRITE
> + | FILE_SHARE_DELETE,
> + NULL,
> + FILE_FLAG_BACKUP_SEMANTICS
> + | FILE_FLAG_OPEN_REPARSE_POINT);
What's the purpose of FILE_FLAG_OPEN_REPARSE_POINT here? As it's apparently
not obvious, please add a comment.
> +
> +if (hDirEntry == INVALID_HANDLE_VALUE) {
> +/*
> + * Not open it successfully, it may be deleted.
Wrong English. "Open
Re: [PATCH v7] audio/pwaudio.c: Add Pipewire audio backend for QEMU
On Monday, March 13, 2023 8:06:15 PM CET Dorinda Bassey wrote:
> >
> > Are you sure about sizeof(n_bytes) here? That's 4. ;-)
> >
> my bad!
>
> >
> > Volker's point was that "silence" is the center of the wave range. With
> > signed
> > range that's zero, yes, but with unsigned range that's 2^(bitdepth) / 2.
> >
> > So you need to memset() the correct value to generate "silence".
> >
> I understand now, Thanks. I guess it should work for signed range, so I
> would do:
>
> @@ -117,7 +117,9 @@ playback_on_process(void *data)
> }
>
> if (avail == 0) {
> -memset(p, 0, n_bytes);
> +memset(p, 0, (int32_t) n_bytes);
No, that would not fix anything. You are actually making several false
assumptions here.
Anyway, in audio/audio.c there is a function which does it correctly:
audio_pcm_info_clear_buf(struct audio_pcm_info *info, void *buf, int len)
So you probably just want to call this function instead to generate silence
correctly. Keep in mind though that it's `len` argument is in sample points,
not in bytes.
Re: [PATCH] ui/cocoa: user friendly characters for release mouse
On Monday, March 13, 2023 2:42:36 PM CET BALATON Zoltan wrote: > On Mon, 13 Mar 2023, Christian Schoenebeck wrote: > > On Monday, February 27, 2023 12:28:02 PM CET Christian Schoenebeck wrote: > >> On Tuesday, December 27, 2022 5:15:31 PM CET Christian Schoenebeck wrote: > >>> While mouse is grabbed, window title contains a hint for the user what > >>> keyboard keys to press to release the mouse. Make that hint text a bit > >>> more user friendly for a Mac user: > >>> > >>> - Replace "Ctrl" and "Alt" by appropriate symbols for those keyboard > >>>keys typically displayed for them on a Mac (encode those symbols by > >>>using UTF-8 characters). > >>> > >>> - Drop " + " in between the keys, as that's not common on macOS for > >>>documenting keyboard shortcuts. > >>> > >>> - Convert lower case "g" to upper case "G", as that's common on macOS. > >>> > >>> - Add one additional space at start and end of key stroke set, to > >>>visually separate the key strokes from the rest of the text. > >>> > >>> Signed-off-by: Christian Schoenebeck > >>> --- > >> > >> Ping > > > > Gerd, > > > > given that I got a RB and TB from Philippe, would you queue this minor macOS > > patch please? > > Isn't this already merged as 23bdd0de97a18 ? Ah yes, thanks! Sorry for the noise! Best regards, Christian Schoenebeck
Re: [PATCH v7] audio/pwaudio.c: Add Pipewire audio backend for QEMU
On Monday, March 13, 2023 2:11:11 PM CET Dorinda Bassey wrote:
> Hi Volker,
>
>
> > To hear this,
> > start QEMU with qemu-system-x86_64 -machine pcspk-audiodev=audio0
> > -device ich9-intel-hda -device hda-duplex,audiodev=audio0 -audiodev
> > pipewire,id=audio0,out.mixing-engine=off ...
> >
> I hear the clipped audio stream with these options. IMO, I don't think
> memset is responsible for that behaviour, I still hear the harsh sound with
> "-audiodev pa". I also tried using an alternative like:
>
> @@ -117,7 +118,7 @@ playback_on_process(void *data)
> }
>
> if (avail == 0) {
> -memset(p, 0, n_bytes);
> +p = g_malloc0(sizeof(n_bytes));
> } else {
>
> The clipped audio issue is still persistent.
Are you sure about sizeof(n_bytes) here? That's 4. ;-)
Volker's point was that "silence" is the center of the wave range. With signed
range that's zero, yes, but with unsigned range that's 2^(bitdepth) / 2.
So you need to memset() the correct value to generate "silence".
Best regards,
Christian Schoenebeck
Re: [PATCH v5 16/16] meson.build: Turn on virtfs for Windows
On Monday, February 20, 2023 11:08:15 AM CET Bin Meng wrote:
> From: Guohuai Shi
>
> Enable virtfs configuration option for Windows host.
>
> Signed-off-by: Guohuai Shi
> Signed-off-by: Bin Meng
> ---
>
> meson.build | 10 +-
> fsdev/meson.build | 1 +
> hw/9pfs/meson.build | 8 +---
> 3 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index a76c855312..9ddf254e78 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1755,16 +1755,16 @@ dbus_display = get_option('dbus_display') \
>.allowed()
>
> have_virtfs = get_option('virtfs') \
> -.require(targetos == 'linux' or targetos == 'darwin',
> - error_message: 'virtio-9p (virtfs) requires Linux or macOS') \
> -.require(targetos == 'linux' or cc.has_function('pthread_fchdir_np'),
> +.require(targetos == 'linux' or targetos == 'darwin' or targetos ==
> 'windows',
> + error_message: 'virtio-9p (virtfs) requires Linux or macOS or
> Windows') \
> +.require(targetos == 'linux' or targetos == 'windows' or
> cc.has_function('pthread_fchdir_np'),
> error_message: 'virtio-9p (virtfs) on macOS requires the
> presence of pthread_fchdir_np') \
> -.require(targetos == 'darwin' or (libattr.found() and libcap_ng.found()),
> +.require(targetos == 'darwin' or targetos == 'windows' or
> (libattr.found() and libcap_ng.found()),
> error_message: 'virtio-9p (virtfs) on Linux requires
> libcap-ng-devel and libattr-devel') \
> .disable_auto_if(not have_tools and not have_system) \
> .allowed()
>
> -have_virtfs_proxy_helper = targetos != 'darwin' and have_virtfs and
> have_tools
> +have_virtfs_proxy_helper = targetos != 'darwin' and targetos != 'windows'
> and have_virtfs and have_tools
>
> if get_option('block_drv_ro_whitelist') == ''
>config_host_data.set('CONFIG_BDRV_RO_WHITELIST', '')
> diff --git a/fsdev/meson.build b/fsdev/meson.build
> index b632b66348..2aad081aef 100644
> --- a/fsdev/meson.build
> +++ b/fsdev/meson.build
> @@ -8,6 +8,7 @@ fsdev_ss.add(when: ['CONFIG_FSDEV_9P'], if_true: files(
> ), if_false: files('qemu-fsdev-dummy.c'))
> softmmu_ss.add_all(when: 'CONFIG_LINUX', if_true: fsdev_ss)
> softmmu_ss.add_all(when: 'CONFIG_DARWIN', if_true: fsdev_ss)
> +softmmu_ss.add_all(when: 'CONFIG_WIN32', if_true: fsdev_ss)
>
> if have_virtfs_proxy_helper
>executable('virtfs-proxy-helper',
> diff --git a/hw/9pfs/meson.build b/hw/9pfs/meson.build
> index 12443b6ad5..aaa50e71f7 100644
> --- a/hw/9pfs/meson.build
> +++ b/hw/9pfs/meson.build
> @@ -2,7 +2,6 @@ fs_ss = ss.source_set()
> fs_ss.add(files(
>'9p-local.c',
>'9p-posix-acl.c',
> - '9p-proxy.c',
>'9p-synth.c',
>'9p-xattr-user.c',
>'9p-xattr.c',
> @@ -13,8 +12,11 @@ fs_ss.add(files(
>'coth.c',
>'coxattr.c',
> ))
> -fs_ss.add(when: 'CONFIG_LINUX', if_true: files('9p-util-linux.c'))
> -fs_ss.add(when: 'CONFIG_DARWIN', if_true: files('9p-util-darwin.c'))
> +fs_ss.add(when: 'CONFIG_LINUX', if_true: files('9p-proxy.c',
> + '9p-util-linux.c'))
> +fs_ss.add(when: 'CONFIG_DARWIN', if_true: files('9p-proxy.c',
> +'9p-util-darwin.c'))
> +fs_ss.add(when: 'CONFIG_WIN32', if_true: files('9p-util-win32.c'))
> fs_ss.add(when: 'CONFIG_XEN', if_true: files('xen-9p-backend.c'))
This no longer applies on master because CONFIG_XEN has been renamed to
CONFIG_XEN_BUS.
> softmmu_ss.add_all(when: 'CONFIG_FSDEV_9P', if_true: fs_ss)
>
>
Re: [PATCH] ui/cocoa: user friendly characters for release mouse
On Monday, February 27, 2023 12:28:02 PM CET Christian Schoenebeck wrote:
> On Tuesday, December 27, 2022 5:15:31 PM CET Christian Schoenebeck wrote:
> > While mouse is grabbed, window title contains a hint for the user what
> > keyboard keys to press to release the mouse. Make that hint text a bit
> > more user friendly for a Mac user:
> >
> > - Replace "Ctrl" and "Alt" by appropriate symbols for those keyboard
> >keys typically displayed for them on a Mac (encode those symbols by
> >using UTF-8 characters).
> >
> > - Drop " + " in between the keys, as that's not common on macOS for
> >documenting keyboard shortcuts.
> >
> > - Convert lower case "g" to upper case "G", as that's common on macOS.
> >
> > - Add one additional space at start and end of key stroke set, to
> >visually separate the key strokes from the rest of the text.
> >
> > Signed-off-by: Christian Schoenebeck
> > ---
>
> Ping
Gerd,
given that I got a RB and TB from Philippe, would you queue this minor macOS
patch please?
Best regards,
Christian Schoenebeck
> > ui/cocoa.m | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/ui/cocoa.m b/ui/cocoa.m
> > index e915c344a8..289a2b193e 100644
> > --- a/ui/cocoa.m
> > +++ b/ui/cocoa.m
> > @@ -72,6 +72,9 @@
> >
> > #define cgrect(nsrect) (*(CGRect *)&(nsrect))
> >
> > +#define UC_CTRL_KEY "\xe2\x8c\x83"
> > +#define UC_ALT_KEY "\xe2\x8c\xa5"
> > +
> > typedef struct {
> > int width;
> > int height;
> > @@ -1135,9 +1138,9 @@ - (void) grabMouse
> >
> > if (!isFullscreen) {
> > if (qemu_name)
> > -[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
> > (Press ctrl + alt + g to release Mouse)", qemu_name]];
> > +[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
> > (Press " UC_CTRL_KEY " " UC_ALT_KEY " G to release Mouse)", qemu_name]];
> > else
> > -[normalWindow setTitle:@"QEMU - (Press ctrl + alt + g to
> > release Mouse)"];
> > +[normalWindow setTitle:@"QEMU - (Press " UC_CTRL_KEY " "
> > UC_ALT_KEY " G to release Mouse)"];
> > }
> > [self hideCursor];
> > CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
> >
>
>
>
>
Re: [PATCH 5/9] 9pfs: mark more coroutine_fns
On Thursday, March 9, 2023 9:44:52 AM CET Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
> ---
> hw/9pfs/9p.h| 4 ++--
> hw/9pfs/codir.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> index 2fce4140d1e9..1b0d805b9c12 100644
> --- a/hw/9pfs/9p.h
> +++ b/hw/9pfs/9p.h
> @@ -203,7 +203,7 @@ typedef struct V9fsDir {
> QemuMutex readdir_mutex_L;
> } V9fsDir;
>
> -static inline void v9fs_readdir_lock(V9fsDir *dir)
> +static inline void coroutine_fn v9fs_readdir_lock(V9fsDir *dir)
> {
> if (dir->proto_version == V9FS_PROTO_2000U) {
> qemu_co_mutex_lock(>readdir_mutex_u);
> @@ -212,7 +212,7 @@ static inline void v9fs_readdir_lock(V9fsDir *dir)
> }
> }
>
> -static inline void v9fs_readdir_unlock(V9fsDir *dir)
> +static inline void coroutine_fn v9fs_readdir_unlock(V9fsDir *dir)
> {
> if (dir->proto_version == V9FS_PROTO_2000U) {
> qemu_co_mutex_unlock(>readdir_mutex_u);
> diff --git a/hw/9pfs/codir.c b/hw/9pfs/codir.c
> index 7ba63be489e7..0d0ffa1d2ba8 100644
> --- a/hw/9pfs/codir.c
> +++ b/hw/9pfs/codir.c
> @@ -68,9 +68,9 @@ int coroutine_fn v9fs_co_readdir(V9fsPDU *pdu, V9fsFidState
> *fidp,
> *
> * See v9fs_co_readdir_many() (as its only user) below for details.
> */
> -static int do_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
> - struct V9fsDirEnt **entries, off_t offset,
> - int32_t maxsize, bool dostat)
> +static int coroutine_fn do_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
> +struct V9fsDirEnt **entries, off_t
> offset,
> +int32_t maxsize, bool dostat)
You should probably fix wrapping here, as the line exceeds 80 characters.
Except of that:
Reviewed-by: Christian Schoenebeck
> {
> V9fsState *s = pdu->s;
> V9fsString name;
>
Re: [PATCH v5 00/16] hw/9pfs: Add 9pfs support for Windows
On Monday, March 6, 2023 3:56:49 PM CET Bin Meng wrote: > On Mon, Mar 6, 2023 at 10:15 PM Christian Schoenebeck > wrote: > > > > On Monday, February 20, 2023 11:07:59 AM CET Bin Meng wrote: > > > At present there is no Windows support for 9p file system. > > > This series adds initial Windows support for 9p file system. > > > > > > 'local' file system backend driver is supported on Windows, > > > including open, read, write, close, rename, remove, etc. > > > All security models are supported. The mapped (mapped-xattr) > > > security model is implemented using NTFS Alternate Data Stream > > > (ADS) so the 9p export path shall be on an NTFS partition. > > > > > > 'synth' driver is adapted for Windows too so that we can now > > > run qtests on Windows for 9p related regression testing. > > > > > > Example command line to test: > > > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device > > virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > > > > > Changes in v5: > > > - rework Windows specific xxxdir() APIs implementation > > > > I didn't have the chance to look at this v5 yet. > > > > In general it would help for review to point out in the cover letter which > > patch(es) have changed, what decisions you have made and why. > > > > In this case I guess that's patch 4. > > > > Yes, it's patch 4, and v5 is reworked following your comments > regarding patch 4 of v4. :) The point was we only discussed suboptimal individual options (each one with pros and cons), not one compelling solution. Never mind, I'll look at your code changes. Best regards, Christian Schoenebeck
Re: [PATCH v5 00/16] hw/9pfs: Add 9pfs support for Windows
On Monday, February 20, 2023 11:07:59 AM CET Bin Meng wrote: > At present there is no Windows support for 9p file system. > This series adds initial Windows support for 9p file system. > > 'local' file system backend driver is supported on Windows, > including open, read, write, close, rename, remove, etc. > All security models are supported. The mapped (mapped-xattr) > security model is implemented using NTFS Alternate Data Stream > (ADS) so the 9p export path shall be on an NTFS partition. > > 'synth' driver is adapted for Windows too so that we can now > run qtests on Windows for 9p related regression testing. > > Example command line to test: > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > Changes in v5: > - rework Windows specific xxxdir() APIs implementation I didn't have the chance to look at this v5 yet. In general it would help for review to point out in the cover letter which patch(es) have changed, what decisions you have made and why. In this case I guess that's patch 4. Best regards, Christian Schoenebeck > Bin Meng (2): > hw/9pfs: Update helper qemu_stat_rdev() > hw/9pfs: Add a helper qemu_stat_blksize() > > Guohuai Shi (14): > hw/9pfs: Add missing definitions for Windows > hw/9pfs: Implement Windows specific utilities functions for 9pfs > hw/9pfs: Replace the direct call to xxxdir() APIs with a wrapper > hw/9pfs: Implement Windows specific xxxdir() APIs > hw/9pfs: Update the local fs driver to support Windows > hw/9pfs: Support getting current directory offset for Windows > hw/9pfs: Disable unsupported flags and features for Windows > hw/9pfs: Update v9fs_set_fd_limit() for Windows > hw/9pfs: Add Linux error number definition > hw/9pfs: Translate Windows errno to Linux value > fsdev: Disable proxy fs driver on Windows > hw/9pfs: Update synth fs driver for Windows > tests/qtest: virtio-9p-test: Adapt the case for win32 > meson.build: Turn on virtfs for Windows > > meson.build | 10 +- > fsdev/file-op-9p.h| 33 + > hw/9pfs/9p-linux-errno.h | 151 +++ > hw/9pfs/9p-local.h|8 + > hw/9pfs/9p-util.h | 139 ++- > hw/9pfs/9p.h | 43 + > tests/qtest/libqos/virtio-9p-client.h |7 + > fsdev/qemu-fsdev.c|2 + > hw/9pfs/9p-local.c| 269 - > hw/9pfs/9p-synth.c|5 +- > hw/9pfs/9p-util-win32.c | 1452 + > hw/9pfs/9p.c | 90 +- > hw/9pfs/codir.c |2 +- > fsdev/meson.build |1 + > hw/9pfs/meson.build |8 +- > 15 files changed, 2155 insertions(+), 65 deletions(-) > create mode 100644 hw/9pfs/9p-linux-errno.h > create mode 100644 hw/9pfs/9p-util-win32.c
Re: [PATCH] ui/cocoa: user friendly characters for release mouse
On Tuesday, December 27, 2022 5:15:31 PM CET Christian Schoenebeck wrote:
> While mouse is grabbed, window title contains a hint for the user what
> keyboard keys to press to release the mouse. Make that hint text a bit
> more user friendly for a Mac user:
>
> - Replace "Ctrl" and "Alt" by appropriate symbols for those keyboard
>keys typically displayed for them on a Mac (encode those symbols by
>using UTF-8 characters).
>
> - Drop " + " in between the keys, as that's not common on macOS for
>documenting keyboard shortcuts.
>
> - Convert lower case "g" to upper case "G", as that's common on macOS.
>
> - Add one additional space at start and end of key stroke set, to
>visually separate the key strokes from the rest of the text.
>
> Signed-off-by: Christian Schoenebeck
> ---
Ping
> ui/cocoa.m | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index e915c344a8..289a2b193e 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -72,6 +72,9 @@
>
> #define cgrect(nsrect) (*(CGRect *)&(nsrect))
>
> +#define UC_CTRL_KEY "\xe2\x8c\x83"
> +#define UC_ALT_KEY "\xe2\x8c\xa5"
> +
> typedef struct {
> int width;
> int height;
> @@ -1135,9 +1138,9 @@ - (void) grabMouse
>
> if (!isFullscreen) {
> if (qemu_name)
> -[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
> (Press ctrl + alt + g to release Mouse)", qemu_name]];
> +[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
> (Press " UC_CTRL_KEY " " UC_ALT_KEY " G to release Mouse)", qemu_name]];
> else
> -[normalWindow setTitle:@"QEMU - (Press ctrl + alt + g to release
> Mouse)"];
> +[normalWindow setTitle:@"QEMU - (Press " UC_CTRL_KEY " "
> UC_ALT_KEY " G to release Mouse)"];
> }
> [self hideCursor];
> CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
>
Re: [PATCH v4] audio/pwaudio.c: Add Pipewire audio backend for QEMU
On Friday, February 17, 2023 6:07:32 PM CET Dorinda Bassey wrote: > This commit adds a new audiodev backend to allow QEMU to use Pipewire as > both an audio sink and source. This backend is available on most systems > > Add Pipewire entry points for QEMU Pipewire audio backend > Add wrappers for QEMU Pipewire audio backend in qpw_pcm_ops() > qpw_write function returns the current state of the stream to pwaudio > and Writes some data to the server for playback streams using pipewire > spa_ringbuffer implementation. > qpw_read function returns the current state of the stream to pwaudio and > reads some data from the server for capture streams using pipewire > spa_ringbuffer implementation. These functions qpw_write and qpw_read > are called during playback and capture. > Added some functions that convert pw audio formats to QEMU audio format > and vice versa which would be needed in the pipewire audio sink and > source functions qpw_init_in() & qpw_init_out(). > These methods that implement playback and recording will create streams > for playback and capture that will start processing and will result in > the on_process callbacks to be called. > Built a connection to the Pipewire sound system server in the > qpw_audio_init() method. > > Signed-off-by: Dorinda Bassey Acked-by: Christian Schoenebeck > --- > fix typo > raise version dependency > > audio/audio.c | 3 + > audio/audio_template.h| 4 + > audio/meson.build | 1 + > audio/pwaudio.c | 827 ++ > meson.build | 8 + > meson_options.txt | 4 +- > qapi/audio.json | 45 ++ > qemu-options.hx | 17 + > scripts/meson-buildoptions.sh | 8 +- > 9 files changed, 914 insertions(+), 3 deletions(-) > create mode 100644 audio/pwaudio.c
Re: [PATCH v3] audio/pwaudio.c: Add Pipewire audio backend for QEMU
On Friday, February 17, 2023 8:11:43 AM CET Dorinda Bassey wrote:
> This commit adds a new audiodev backend to allow QEMU to use Pipewire as
> both an audio sink and source. This backend is available on most systems
>
> Add Pipewire entry points for QEMU Pipewire audio backend
> Add wrappers for QEMU Pipewire audio backend in qpw_pcm_ops()
> qpw_write function returns the current state of the stream to pwaudio
> and Writes some data to the server for playback streams using pipewire
> spa_ringbuffer implementation.
> qpw_read function returns the current state of the stream to pwaudio and
> reads some data from the server for capture streams using pipewire
> spa_ringbuffer implementation. These functions qpw_write and qpw_read
> are called during playback and capture.
> Added some functions that convert pw audio formats to QEMU audio format
> and vice versa which would be needed in the pipewire audio sink and
> source functions qpw_init_in() & qpw_init_out().
> These methods that implement playback and recording will create streams
> for playback and capture that will start processing and will result in
> the on_process callbacks to be called.
> Built a connection to the Pipewire sound system server in the
> qpw_audio_init() method.
>
> Signed-off-by: Dorinda Bassey
> ---
> v3:
> Wrap commit log
> add checks for v->stream
> use constants instead of literals
> fix typo error
>
> audio/audio.c | 3 +
> audio/audio_template.h| 4 +
> audio/meson.build | 1 +
> audio/pwaudio.c | 827 ++
> meson.build | 7 +
> meson_options.txt | 4 +-
> qapi/audio.json | 45 ++
> qemu-options.hx | 17 +
> scripts/meson-buildoptions.sh | 8 +-
> 9 files changed, 913 insertions(+), 3 deletions(-)
> create mode 100644 audio/pwaudio.c
>
> diff --git a/audio/audio.c b/audio/audio.c
> index 4290309d18..aa55e41ad8 100644
> --- a/audio/audio.c
> +++ b/audio/audio.c
> @@ -2069,6 +2069,9 @@ void audio_create_pdos(Audiodev *dev)
> #ifdef CONFIG_AUDIO_PA
> CASE(PA, pa, Pa);
> #endif
> +#ifdef CONFIG_AUDIO_PIPEWIRE
> +CASE(PIPEWIRE, pipewire, Pipewire);
> +#endif
> #ifdef CONFIG_AUDIO_SDL
> CASE(SDL, sdl, Sdl);
> #endif
> diff --git a/audio/audio_template.h b/audio/audio_template.h
> index 42b4712acb..0f02afb921 100644
> --- a/audio/audio_template.h
> +++ b/audio/audio_template.h
> @@ -355,6 +355,10 @@ AudiodevPerDirectionOptions *glue(audio_get_pdo_,
> TYPE)(Audiodev *dev)
> case AUDIODEV_DRIVER_PA:
> return qapi_AudiodevPaPerDirectionOptions_base(dev->u.pa.TYPE);
> #endif
> +#ifdef CONFIG_AUDIO_PIPEWIRE
> +case AUDIODEV_DRIVER_PIPEWIRE:
> +return
> qapi_AudiodevPipewirePerDirectionOptions_base(dev->u.pipewire.TYPE);
> +#endif
> #ifdef CONFIG_AUDIO_SDL
> case AUDIODEV_DRIVER_SDL:
> return qapi_AudiodevSdlPerDirectionOptions_base(dev->u.sdl.TYPE);
> diff --git a/audio/meson.build b/audio/meson.build
> index 074ba9..65a49c1a10 100644
> --- a/audio/meson.build
> +++ b/audio/meson.build
> @@ -19,6 +19,7 @@ foreach m : [
>['sdl', sdl, files('sdlaudio.c')],
>['jack', jack, files('jackaudio.c')],
>['sndio', sndio, files('sndioaudio.c')],
> + ['pipewire', pipewire, files('pwaudio.c')],
>['spice', spice, files('spiceaudio.c')]
> ]
>if m[1].found()
> diff --git a/audio/pwaudio.c b/audio/pwaudio.c
> new file mode 100644
> index 00..05a00b0859
> --- /dev/null
> +++ b/audio/pwaudio.c
> @@ -0,0 +1,827 @@
> +/*
> + * QEMU Pipewire audio driver
> + *
> + * Copyright (c) 2023 Red Hat Inc.
> + *
> + * Author: Dorinda Bassey
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/module.h"
> +#include "audio.h"
> +#include
> +#include
> +#include
> +#include
> +
>
Re: [PATCH] audio/pwaudio.c: Add Pipewire audio backend for QEMU
On Wednesday, February 15, 2023 4:59:47 PM CET Daniel P. Berrangé wrote: > On Wed, Feb 15, 2023 at 05:18:50PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Wed, Feb 15, 2023 at 12:51 PM Dorinda Bassey wrote: > > > > > > This commit adds a new audiodev backend to allow QEMU to use Pipewire as > > > both an audio sink and source. This backend is available on most systems. > > > > > > > Hmm, I would rather have less audio (and ui) backends in QEMU. (for > > audio, if I could introduce and keep only one, that would be > > GStreamer: to remove the others..) > > Even if we take this patch, and don't have a gstreamer impl, > it feels like we've scope for cutting down the backends. > > The 'oss' driver for example ? On Linux that's long obsolete, > with alsa or one of the higher level APIs available. OSS was > also use on freebsd, but IIUC, sndio is better choice there > now too ? Deprecate (and later remove) 'oss' now ? There is indeed little reason to still use OSS nowadays IMO. At least marking OSS as deprecated would not hurt. > The 'sdl' driver is setup in meson.build as our lowest priority > impl, we'll pick any other driver ahead of sdl. Is there any > compelling reason why we must give users the option of 'sdl' > for audio when we have soo many other choices available ? > Even if using SDL for graphics, it seems like we can use any > other backend for audio. Deprecate (and later remove) 'sdl' > for audio ? > > IIUC, pipewire is positioned to replace pulseaudio. So if we > take a pipewire backend, once pipewire is available in enough > distros we could deprecate the pulseaudio backend and eventually > remove it. Maybe the same applies for 'jack' ? AFAIK Pipewire is Linux only, whereas PulseAudio and JACK are available for Windows and macOS, too. And in it's current version (provided QEMU Pipewire patch), I don't see it as a full replacement for the JACK driver yet. > IOW, could we get to > > - Windows: dsound > - MacOS: coreaudio > - (Open|Net|Free)BSD: sndio > - Linux: alsa/pipewire > > ? > > With regards, > Daniel >
Re: [PATCH v2] audio/pwaudio.c: Add Pipewire audio backend for QEMU
On Thursday, February 16, 2023 9:25:44 AM CET Dorinda Bassey wrote:
> This commit adds a new audiodev backend to allow QEMU to use Pipewire as both
> an audio sink and source.
>
Please wrap commit log.
> Signed-off-by: Dorinda Bassey
> ---
> v2:
> * Shorten commit message
> * fix copyright ownership and authour
> * use QEMU standard of 4 space indentation
> * verbose use of pipewire instead pf pw
>
> audio/audio.c | 3 +
> audio/audio_template.h| 4 +
> audio/meson.build | 1 +
> audio/pwaudio.c | 818 ++
> meson.build | 7 +
> meson_options.txt | 4 +-
> qapi/audio.json | 45 ++
> qemu-options.hx | 17 +
> scripts/meson-buildoptions.sh | 8 +-
> 9 files changed, 904 insertions(+), 3 deletions(-)
> create mode 100644 audio/pwaudio.c
>
> diff --git a/audio/audio.c b/audio/audio.c
> index 4290309d18..aa55e41ad8 100644
> --- a/audio/audio.c
> +++ b/audio/audio.c
> @@ -2069,6 +2069,9 @@ void audio_create_pdos(Audiodev *dev)
> #ifdef CONFIG_AUDIO_PA
> CASE(PA, pa, Pa);
> #endif
> +#ifdef CONFIG_AUDIO_PIPEWIRE
> +CASE(PIPEWIRE, pipewire, Pipewire);
> +#endif
> #ifdef CONFIG_AUDIO_SDL
> CASE(SDL, sdl, Sdl);
> #endif
> diff --git a/audio/audio_template.h b/audio/audio_template.h
> index 42b4712acb..0f02afb921 100644
> --- a/audio/audio_template.h
> +++ b/audio/audio_template.h
> @@ -355,6 +355,10 @@ AudiodevPerDirectionOptions *glue(audio_get_pdo_,
> TYPE)(Audiodev *dev)
> case AUDIODEV_DRIVER_PA:
> return qapi_AudiodevPaPerDirectionOptions_base(dev->u.pa.TYPE);
> #endif
> +#ifdef CONFIG_AUDIO_PIPEWIRE
> +case AUDIODEV_DRIVER_PIPEWIRE:
> +return
> qapi_AudiodevPipewirePerDirectionOptions_base(dev->u.pipewire.TYPE);
> +#endif
> #ifdef CONFIG_AUDIO_SDL
> case AUDIODEV_DRIVER_SDL:
> return qapi_AudiodevSdlPerDirectionOptions_base(dev->u.sdl.TYPE);
> diff --git a/audio/meson.build b/audio/meson.build
> index 074ba9..65a49c1a10 100644
> --- a/audio/meson.build
> +++ b/audio/meson.build
> @@ -19,6 +19,7 @@ foreach m : [
>['sdl', sdl, files('sdlaudio.c')],
>['jack', jack, files('jackaudio.c')],
>['sndio', sndio, files('sndioaudio.c')],
> + ['pipewire', pipewire, files('pwaudio.c')],
>['spice', spice, files('spiceaudio.c')]
> ]
>if m[1].found()
> diff --git a/audio/pwaudio.c b/audio/pwaudio.c
> new file mode 100644
> index 00..bb25133414
> --- /dev/null
> +++ b/audio/pwaudio.c
> @@ -0,0 +1,818 @@
> +/*
> + * QEMU Pipewire audio driver
> + *
> + * Copyright (c) 2023 Red Hat Inc.
> + *
> + * Author: Dorinda Bassey
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/module.h"
> +#include "audio.h"
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define AUDIO_CAP "pipewire"
> +#define RINGBUFFER_SIZE(1u << 22)
> +#define RINGBUFFER_MASK(RINGBUFFER_SIZE - 1)
> +#define BUFFER_SAMPLES128
BUFFER_SAMPLES is not used anywhere, and in code you are using 512 as literals
instead.
> +
> +#include "audio_int.h"
> +
> +enum {
> +MODE_SINK,
> +MODE_SOURCE
> +};
> +
> +typedef struct pwaudio {
> +Audiodev *dev;
> +struct pw_thread_loop *thread_loop;
> +struct pw_context *context;
> +
> +struct pw_core *core;
> +struct spa_hook core_listener;
> +int seq;
> +} pwaudio;
> +
> +typedef struct PWVoice {
> +pwaudio *g;
> +bool enabled;
> +struct pw_stream *stream;
> +struct spa_hook stream_listener;
> +struct spa_audio_info_raw info;
> +uint32_t frame_size;
> +struct spa_ringbuffer ring;
> +uint8_t buffer[RINGBUFFER_SIZE];
s/buffer/ringbuffer/ maybe?
> +
> +uint32_t mode;
> +struct pw_properties *props;
> +} PWVoice;
> +
> +typedef
Re: [PATCH] audio/pwaudio.c: Add Pipewire audio backend for QEMU
On Wednesday, February 15, 2023 2:18:50 PM CET Marc-André Lureau wrote: > Hi > > On Wed, Feb 15, 2023 at 12:51 PM Dorinda Bassey wrote: > > > > This commit adds a new audiodev backend to allow QEMU to use Pipewire as both an audio sink and source. This backend is available on most systems. > > > > Hmm, I would rather have less audio (and ui) backends in QEMU. (for > audio, if I could introduce and keep only one, that would be > GStreamer: to remove the others..) > > What is the main advantage compared to using the ALSA backend? (I > assume pipewire depends on ALSA anyway on Linux) I think it does make sense to add Pipewire. Apparently it gains popularity. The main advantage of Pipewire is its interoperability: It allows you to connect apps with each other that only support a specific audio system. Say one app that only supports JACK, another app that only supports PulseAudio, another that only supports ALSA and so on. So it tries to provide a universal plug on a system for all. Best regards, Christian Schoenebeck
Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific xxxdir() APIs
On Monday, February 6, 2023 6:37:16 AM CET Shi, Guohuai wrote:
[...]
> > I know, it's an n-square performance issue and what I already wrote in the
> > summary of the linked original suggestion [1] in v3 before, quote:
> >
> > + Relatively straight-forward to implement.
> >
> > + No (major) changes in 9pfs code base required.
> >
> > - Still n-square performance issue (neglectable to land Windows host
> > support
> > IMO).
> >
> > o Consistency assured for "most" cases, except one: if hardlinks are
> > inserted in between then it might fail
>
> readdir() on Linux host may also return the deleted entries.
> And POSIX specification does not mention about the consistency issue.
POSIX explicitly specifies that 1. new and 2. deleted entries may or may not
appear in result and leaves that implementation specific. That was never our
concern.
And yes, POSIX does not explicitly discuss consistency concerning entries that
have neither been added or removed, but this expectation is implied. In
practice double entries are probably less of an issue, client might be able to
handle that without misbehaviour (haven't checked this at all yet), but if the
implementation would lead to chances that entries may *never* appear to
clients at all, even after refreshing periodically, I mean how could you work
with a file system like that?
> NTFS file id is the $MFT index id. It will keen unique until file is deleted.
> But the index id may be reuse if delete and re-create many files.
>
> Saving file id instead of name will make consistency better, but may not
> cover all status.
> Because read directory is not a "atomic" operation.
I don't see an issue with that, because these are entries that were either
added or removed, we don't care about them. And their file IDs would not
affect fetching the other directory entries that have not been touched in
between.
And we are also not questioning atomicity here, but consistency.
> > [1] https://lore.kernel.org/qemu-devel/2468168.SvRIHAoRfs@silver/
> >
> > The idea was to use that just as a starting point to land Windows host
> > support
> > ASAP, slower on large dirs compared to other solutions, yes, but with
> > guaranteed correct and deterministic behaviour. And then on the long run
> > we would of course replace that with a more performant solution.
> >
> > I mean, this is really simple to implement, so I would at least test it. If
> > it really
> > runs horribly slow we could still discuss faster solutions, which are
> > however
> > all much more tricky.
> >
>
> I did a basic test on Windows host, here is the code:
>
> st = clock();
> pDir = opendir_win32(TEST_DIR);
>
> if (pDir == NULL)
> return -1;
>
> while ((pEnt = readdir_win32(pDir)) != NULL)
> {
> totals++;
> }
> closedir_win32(pDir);
> ed = clock();
>
> printf("total = %d clocks = %d %d\n", totals, ed - st, CLOCKS_PER_SEC);
>
> My local storage is SSD disk.
>
> Run this test for 100, 1000, 1 entries.
> For file name cache solution, the time cost is: 2, 9, 44 (in ms).
> For file id cache solution, the time cost: 3, 438, 4338 (in ms).
> I already used OpenFileById() to make it faster instead of CreateFile(). If I
> use CreateFile, it need more than 80 seconds.
>
> The performance looks like not good.
> And actually, it would be worse in 9pfs.
> Because in current design, 9pfs may seek forward and seek back several times
> during reading directory, which may cause the performance worse.
Poor performance, yes, probably a bit worse than I would have expected.
So it is about choosing your poison (potential crash vs. poor performance).
I mean, I am not keen into suggesting any kind of bike shredding for you on
this issue, but if this is merged, then people expect it to behave reliably
and not allowing a guest to crash QEMU host process by simply creating a large
number of directory entries on guest.
I was also considering to make it a QEMU option, but OTOH, this is a temporary
situation and those options would be wiped once we have an oppropriate
solution a bit later.
I am open for suggestions. Could we probably just mark Windows host support as
experimental for now, is that even allowed by QEMU policies?
> > > So I think store all name entries would be better than store all file ID.
> >
> > As already discussed, NTFS allows up to (2^32 - 1) = 4,294,967,295 entries
> > per
> > directory. So caching only one directory (entirely) in RAM can already
> > exceed
> > the available RAM, which would crash QEMU. Multiplied by an expected
> > amount of directory lookups by client and we even get into much higher
> > categories, even with much smaller individual directory sizes.
> >
>
> Windows file id structure is 24 bytes, which is not a small structure.
> If you think the performance is acceptable, I can rework this commit based on
> file id.
Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific xxxdir() APIs
On Friday, February 3, 2023 5:30:35 PM CET Shi, Guohuai wrote: > > > -Original Message- > > From: Christian Schoenebeck > > Sent: Friday, February 3, 2023 22:41 > > To: Greg Kurz ; qemu-devel@nongnu.org > > Cc: Meng, Bin ; Marc-André Lureau > > ; Daniel P. Berrangé ; > > Shi, > > Guohuai > > Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific xxxdir() > > APIs > > > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and > > know the content is safe. > > > > On Friday, February 3, 2023 2:34:13 PM CET Shi, Guohuai wrote: > > > > > > > -Original Message- > > > > From: Christian Schoenebeck > > > > Sent: Friday, February 3, 2023 20:25 > > > > To: Greg Kurz ; qemu-devel@nongnu.org > > > > Cc: Shi, Guohuai ; Meng, Bin > > > > ; Marc-André Lureau > > > > ; Daniel P. Berrangé > > > > > > > > Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific > > > > xxxdir() APIs > > > > > > > > CAUTION: This email comes from a non Wind River email account! > > > > Do not click links or open attachments unless you recognize the > > > > sender and know the content is safe. > > > > > > > > On Monday, January 30, 2023 10:51:50 AM CET Bin Meng wrote: > > > > > From: Guohuai Shi > > > > > > > > > > This commit implements Windows specific xxxdir() APIs for safety > > > > > directory access. > > > > > > > > > > > > > This issue deserves a link to either the previous discussion > > > > > > > > Link: https://lore.kernel.org/qemu-devel/2830993.GtbaR8S6b6@silver/ > > > > > > > > and/or a link to this continuation of the discussion here, as it's > > > > not a trivial issue, with pros and cons been discussed for the > > > > individual, possible solutions. > > > > > > > > > Signed-off-by: Guohuai Shi > > > > > Signed-off-by: Bin Meng > > > > > --- > > > > > > > > > > hw/9pfs/9p-util.h | 6 + > > > > > hw/9pfs/9p-util-win32.c | 296 > > > > > > > > > > 2 files changed, 302 insertions(+) > > > > > > > > > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h index > > > > > 0f159fb4ce..c1c251fbd1 100644 > > > > > --- a/hw/9pfs/9p-util.h > > > > > +++ b/hw/9pfs/9p-util.h > > > > > @@ -141,6 +141,12 @@ int unlinkat_win32(int dirfd, const char > > > > > *pathname, int flags); int statfs_win32(const char *root_path, > > > > > struct statfs *stbuf); int openat_dir(int dirfd, const char > > > > > *name); int openat_file(int dirfd, const char *name, int flags, > > > > > mode_t mode); > > > > > +DIR *opendir_win32(const char *full_file_name); int > > > > > +closedir_win32(DIR *pDir); struct dirent *readdir_win32(DIR > > > > > +*pDir); void rewinddir_win32(DIR *pDir); void seekdir_win32(DIR > > > > > +*pDir, long pos); long telldir_win32(DIR *pDir); > > > > > #endif > > > > > > > > > > static inline void close_preserve_errno(int fd) diff --git > > > > > a/hw/9pfs/9p-util-win32.c b/hw/9pfs/9p-util-win32.c index > > > > > a99d579a06..5503199300 100644 > > > > > --- a/hw/9pfs/9p-util-win32.c > > > > > +++ b/hw/9pfs/9p-util-win32.c > > > > > @@ -37,6 +37,13 @@ > > > > > *Windows does not support opendir, the directory fd is created > > > > > by > > > > > *CreateFile and convert to fd by _open_osfhandle(). Keep the fd > > open > > > > will > > > > > *lock and protect the directory (can not be modified or > > > > > replaced) > > > > > + * > > > > > + * 5. Windows and MinGW does not provide safety directory > > > > > + accessing > > > > functions. > > > > > + *readdir(), seekdir() and telldir() may get or set wrong value > > > > because > > > > > + *directory entry data is not protected. > > > > > > > > I would rephrase that sentence, as it doesn't cover the root problem > > > > adequately. Maybe
Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific xxxdir() APIs
On Friday, February 3, 2023 2:34:13 PM CET Shi, Guohuai wrote: > > > -Original Message- > > From: Christian Schoenebeck > > Sent: Friday, February 3, 2023 20:25 > > To: Greg Kurz ; qemu-devel@nongnu.org > > Cc: Shi, Guohuai ; Meng, Bin > > ; Marc-André Lureau ; > > Daniel P. Berrangé > > Subject: Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific xxxdir() > > APIs > > > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and > > know the content is safe. > > > > On Monday, January 30, 2023 10:51:50 AM CET Bin Meng wrote: > > > From: Guohuai Shi > > > > > > This commit implements Windows specific xxxdir() APIs for safety > > > directory access. > > > > > > > This issue deserves a link to either the previous discussion > > > > Link: https://lore.kernel.org/qemu-devel/2830993.GtbaR8S6b6@silver/ > > > > and/or a link to this continuation of the discussion here, as it's not a > > trivial issue, with pros and cons been discussed for the individual, > > possible > > solutions. > > > > > Signed-off-by: Guohuai Shi > > > Signed-off-by: Bin Meng > > > --- > > > > > > hw/9pfs/9p-util.h | 6 + > > > hw/9pfs/9p-util-win32.c | 296 > > > > > > 2 files changed, 302 insertions(+) > > > > > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h index > > > 0f159fb4ce..c1c251fbd1 100644 > > > --- a/hw/9pfs/9p-util.h > > > +++ b/hw/9pfs/9p-util.h > > > @@ -141,6 +141,12 @@ int unlinkat_win32(int dirfd, const char > > > *pathname, int flags); int statfs_win32(const char *root_path, struct > > > statfs *stbuf); int openat_dir(int dirfd, const char *name); int > > > openat_file(int dirfd, const char *name, int flags, mode_t mode); > > > +DIR *opendir_win32(const char *full_file_name); int > > > +closedir_win32(DIR *pDir); struct dirent *readdir_win32(DIR *pDir); > > > +void rewinddir_win32(DIR *pDir); void seekdir_win32(DIR *pDir, long > > > +pos); long telldir_win32(DIR *pDir); > > > #endif > > > > > > static inline void close_preserve_errno(int fd) diff --git > > > a/hw/9pfs/9p-util-win32.c b/hw/9pfs/9p-util-win32.c index > > > a99d579a06..5503199300 100644 > > > --- a/hw/9pfs/9p-util-win32.c > > > +++ b/hw/9pfs/9p-util-win32.c > > > @@ -37,6 +37,13 @@ > > > *Windows does not support opendir, the directory fd is created by > > > *CreateFile and convert to fd by _open_osfhandle(). Keep the fd open > > will > > > *lock and protect the directory (can not be modified or replaced) > > > + * > > > + * 5. Windows and MinGW does not provide safety directory accessing > > functions. > > > + *readdir(), seekdir() and telldir() may get or set wrong value > > because > > > + *directory entry data is not protected. > > > > I would rephrase that sentence, as it doesn't cover the root problem > > adequately. Maybe something like this: > > > > 5. Neither Windows native APIs, nor MinGW provide a POSIX compatible API for > > acquiring directory entries in a safe way. Calling those APIs (native > > _findfirst() and _findnext() or MinGW's readdir(), seekdir() and telldir()) > > directly can lead to an inconsistent state if directory is modified in > > between, e.g. the same directory appearing more than once in output, or > > directories not appearing at all in output even though they were neither > > newly created nor deleted. POSIX does not define what happens with deleted > > or > > newly created directories in between, but it guarantees a consistent state. > > > > > + * > > > + *This file re-write POSIX directory accessing functions and cache > > > all > > > + *directory entries during opening. > > > */ > > > > > > #include "qemu/osdep.h" > > > @@ -51,6 +58,27 @@ > > > > > > #define V9FS_MAGIC 0x53465039 /* string "9PFS" */ > > > > > > +/* > > > + * MinGW and Windows does not provide safety way to seek directory > > > +while other > > > + * thread is modifying same directory. > > > + * > > > + * The two structures are used to cache all directory entries when > > > opening > > it. > > > + * Cached entries are always r
Re: [PATCH v4 04/16] hw/9pfs: Implement Windows specific xxxdir() APIs
On Monday, January 30, 2023 10:51:50 AM CET Bin Meng wrote:
> From: Guohuai Shi
>
> This commit implements Windows specific xxxdir() APIs for safety
> directory access.
>
This issue deserves a link to either the previous discussion
Link: https://lore.kernel.org/qemu-devel/2830993.GtbaR8S6b6@silver/
and/or a link to this continuation of the discussion here, as it's not a
trivial issue, with pros and cons been discussed for the individual, possible
solutions.
> Signed-off-by: Guohuai Shi
> Signed-off-by: Bin Meng
> ---
>
> hw/9pfs/9p-util.h | 6 +
> hw/9pfs/9p-util-win32.c | 296
> 2 files changed, 302 insertions(+)
>
> diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> index 0f159fb4ce..c1c251fbd1 100644
> --- a/hw/9pfs/9p-util.h
> +++ b/hw/9pfs/9p-util.h
> @@ -141,6 +141,12 @@ int unlinkat_win32(int dirfd, const char *pathname, int
> flags);
> int statfs_win32(const char *root_path, struct statfs *stbuf);
> int openat_dir(int dirfd, const char *name);
> int openat_file(int dirfd, const char *name, int flags, mode_t mode);
> +DIR *opendir_win32(const char *full_file_name);
> +int closedir_win32(DIR *pDir);
> +struct dirent *readdir_win32(DIR *pDir);
> +void rewinddir_win32(DIR *pDir);
> +void seekdir_win32(DIR *pDir, long pos);
> +long telldir_win32(DIR *pDir);
> #endif
>
> static inline void close_preserve_errno(int fd)
> diff --git a/hw/9pfs/9p-util-win32.c b/hw/9pfs/9p-util-win32.c
> index a99d579a06..5503199300 100644
> --- a/hw/9pfs/9p-util-win32.c
> +++ b/hw/9pfs/9p-util-win32.c
> @@ -37,6 +37,13 @@
> *Windows does not support opendir, the directory fd is created by
> *CreateFile and convert to fd by _open_osfhandle(). Keep the fd open
> will
> *lock and protect the directory (can not be modified or replaced)
> + *
> + * 5. Windows and MinGW does not provide safety directory accessing
> functions.
> + *readdir(), seekdir() and telldir() may get or set wrong value because
> + *directory entry data is not protected.
I would rephrase that sentence, as it doesn't cover the root problem
adequately. Maybe something like this:
5. Neither Windows native APIs, nor MinGW provide a POSIX compatible API for
acquiring directory entries in a safe way. Calling those APIs (native
_findfirst() and _findnext() or MinGW's readdir(), seekdir() and telldir())
directly can lead to an inconsistent state if directory is modified in
between, e.g. the same directory appearing more than once in output, or
directories not appearing at all in output even though they were neither newly
created nor deleted. POSIX does not define what happens with deleted or newly
created directories in between, but it guarantees a consistent state.
> + *
> + *This file re-write POSIX directory accessing functions and cache all
> + *directory entries during opening.
> */
>
> #include "qemu/osdep.h"
> @@ -51,6 +58,27 @@
>
> #define V9FS_MAGIC 0x53465039 /* string "9PFS" */
>
> +/*
> + * MinGW and Windows does not provide safety way to seek directory while
> other
> + * thread is modifying same directory.
> + *
> + * The two structures are used to cache all directory entries when opening
> it.
> + * Cached entries are always returned for read or seek.
> + */
> +struct dir_win32_entry {
> +QSLIST_ENTRY(dir_win32_entry) node;
> +struct _finddata_t dd_data;
> +};
> +
> +struct dir_win32 {
> +struct dirent dd_dir;
> +uint32_t offset;
> +uint32_t total_entries;
> +QSLIST_HEAD(, dir_win32_entry) head;
> +struct dir_win32_entry *current;
> +char dd_name[1];
> +};
> +
> /*
> * win32_error_to_posix - convert Win32 error to POSIX error number
> *
> @@ -977,3 +1005,271 @@ int qemu_mknodat(int dirfd, const char *filename,
> mode_t mode, dev_t dev)
> errno = ENOTSUP;
> return -1;
> }
> +
> +/*
> + * opendir_win32 - open a directory
> + *
> + * This function opens a directory and caches all directory entries.
> + */
> +DIR *opendir_win32(const char *full_file_name)
> +{
> +HANDLE hDir = INVALID_HANDLE_VALUE;
> +DWORD attribute;
> +intptr_t dd_handle = -1;
> +struct _finddata_t dd_data;
> +
> +struct dir_win32 *stream = NULL;
> +struct dir_win32_entry *dir_entry;
> +struct dir_win32_entry *prev;
> +struct dir_win32_entry *next;
> +
> +int err = 0;
> +int find_status;
> +uint32_t index;
> +
> +/* open directory to prevent it being removed */
> +
> +hDir = CreateFile(full_file_name, GENERIC_READ,
> + FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
> + NULL,
> + OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL);
> +
> +if (hDir == INVALID_HANDLE_VALUE) {
> +err = win32_error_to_posix(GetLastError());
> +goto out;
> +}
> +
> +attribute = GetFileAttributes(full_file_name);
> +
> +/* symlink is not allow */
> +if (attribute ==
Re: [PATCH v4 17/19] Don't include headers already included by qemu/osdep.h
On Thursday, January 19, 2023 7:59:57 AM CET Markus Armbruster wrote: > This commit was created with scripts/clean-includes. > > Signed-off-by: Markus Armbruster > --- For 9p changes: Acked-by: Christian Schoenebeck > backends/tpm/tpm_ioctl.h | 2 -- > fsdev/p9array.h | 2 -- > include/hw/misc/aspeed_lpc.h | 2 -- > include/hw/pci/pcie_doe.h | 1 - > include/qemu/async-teardown.h | 2 -- > include/qemu/dbus.h | 1 - > include/qemu/host-utils.h | 1 - > include/sysemu/event-loop-base.h | 1 - > accel/tcg/cpu-exec.c | 1 - > hw/9pfs/9p.c | 2 -- > hw/display/virtio-gpu-udmabuf.c | 1 - > hw/i2c/pmbus_device.c | 1 - > hw/remote/proxy-memory-listener.c | 1 - > hw/sensor/adm1272.c | 1 - > hw/usb/dev-storage-bot.c | 1 - > hw/usb/dev-storage-classic.c | 1 - > softmmu/vl.c | 2 -- > tcg/tci.c | 1 - > tests/unit/test-seccomp.c | 1 - > ui/udmabuf.c | 1 - > util/main-loop.c | 1 - > util/oslib-posix.c| 2 -- > 22 files changed, 29 deletions(-) > > diff --git a/backends/tpm/tpm_ioctl.h b/backends/tpm/tpm_ioctl.h > index e506ef5160..b1d31768a6 100644 > --- a/backends/tpm/tpm_ioctl.h > +++ b/backends/tpm/tpm_ioctl.h > @@ -12,8 +12,6 @@ > # define __USE_LINUX_IOCTL_DEFS > #endif > > -#include > -#include > #ifndef _WIN32 > #include > #include > diff --git a/fsdev/p9array.h b/fsdev/p9array.h > index 90e83a7c7b..50a1b15fe9 100644 > --- a/fsdev/p9array.h > +++ b/fsdev/p9array.h > @@ -27,8 +27,6 @@ > #ifndef QEMU_P9ARRAY_H > #define QEMU_P9ARRAY_H > > -#include "qemu/compiler.h" > - > /** > * P9Array provides a mechanism to access arrays in common C-style (e.g. by > * square bracket [] operator) in conjunction with reference variables that > diff --git a/include/hw/misc/aspeed_lpc.h b/include/hw/misc/aspeed_lpc.h > index fd228731d2..fa398959af 100644 > --- a/include/hw/misc/aspeed_lpc.h > +++ b/include/hw/misc/aspeed_lpc.h > @@ -12,8 +12,6 @@ > > #include "hw/sysbus.h" > > -#include > - > #define TYPE_ASPEED_LPC "aspeed.lpc" > #define ASPEED_LPC(obj) OBJECT_CHECK(AspeedLPCState, (obj), TYPE_ASPEED_LPC) > > diff --git a/include/hw/pci/pcie_doe.h b/include/hw/pci/pcie_doe.h > index ba4d8b03bd..87dc17dcef 100644 > --- a/include/hw/pci/pcie_doe.h > +++ b/include/hw/pci/pcie_doe.h > @@ -11,7 +11,6 @@ > #define PCIE_DOE_H > > #include "qemu/range.h" > -#include "qemu/typedefs.h" > #include "hw/register.h" > > /* > diff --git a/include/qemu/async-teardown.h b/include/qemu/async-teardown.h > index 092e7a37e7..b281da005b 100644 > --- a/include/qemu/async-teardown.h > +++ b/include/qemu/async-teardown.h > @@ -13,8 +13,6 @@ > #ifndef QEMU_ASYNC_TEARDOWN_H > #define QEMU_ASYNC_TEARDOWN_H > > -#include "config-host.h" > - > #ifdef CONFIG_LINUX > void init_async_teardown(void); > #endif > diff --git a/include/qemu/dbus.h b/include/qemu/dbus.h > index 08f00dfd53..81d3de8a5a 100644 > --- a/include/qemu/dbus.h > +++ b/include/qemu/dbus.h > @@ -15,7 +15,6 @@ > #include "qom/object.h" > #include "chardev/char.h" > #include "qemu/notify.h" > -#include "qemu/typedefs.h" > > /* glib/gio 2.68 */ > #define DBUS_METHOD_INVOCATION_HANDLED TRUE > diff --git a/include/qemu/host-utils.h b/include/qemu/host-utils.h > index 88d476161c..3ce62bf4a5 100644 > --- a/include/qemu/host-utils.h > +++ b/include/qemu/host-utils.h > @@ -30,7 +30,6 @@ > #ifndef HOST_UTILS_H > #define HOST_UTILS_H > > -#include "qemu/compiler.h" > #include "qemu/bswap.h" > #include "qemu/int128.h" > > diff --git a/include/sysemu/event-loop-base.h > b/include/sysemu/event-loop-base.h > index 2748bf6ae1..a6c24f1351 100644 > --- a/include/sysemu/event-loop-base.h > +++ b/include/sysemu/event-loop-base.h > @@ -14,7 +14,6 @@ > > #include "qom/object.h" > #include "block/aio.h" > -#include "qemu/typedefs.h" > > #define TYPE_EVENT_LOOP_BASE "event-loop-base" > OBJECT_DECLARE_TYPE(EventLoopBase, EventLoopBaseClass, > diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c > index 8927092537..dd8f54a415 100644 > --- a/accel/tcg/cpu-exec.c > +++ b/accel/tcg/cpu-exec.c > @@ -28,7 +28,6 @@ > #include "exec/exec-all.h" > #include "tcg/tcg.h" > #in
Re: [PATCH v4 18/19] 9p: Drop superfluous include of linux/limits.h
On Thursday, January 19, 2023 11:37:00 AM CET Markus Armbruster wrote: > Christian Schoenebeck writes: > > > On Thursday, January 19, 2023 7:59:58 AM CET Markus Armbruster wrote: > >> Signed-off-by: Markus Armbruster > >> --- > >> hw/9pfs/9p.c | 3 --- > >> 1 file changed, 3 deletions(-) > >> > >> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > >> index 9621ec1341..aa736af380 100644 > >> --- a/hw/9pfs/9p.c > >> +++ b/hw/9pfs/9p.c > >> @@ -17,9 +17,6 @@ > >> */ > >> > >> #include "qemu/osdep.h" > >> -#ifdef CONFIG_LINUX > >> -#include > >> -#endif > >> #include > >> #include "hw/virtio/virtio.h" > >> #include "qapi/error.h" > >> > > > > Where did that base version come from? I don't see it anywhere in history. > > Last relevant change in context was a136d17590a. > > Current master (7ec8aeb6048) has > > #include "qemu/osdep.h" > #ifdef CONFIG_LINUX > #include > #else > #include > #endif > #include > > The previous commit changes it to > > #include "qemu/osdep.h" > #ifdef CONFIG_LINUX > #include > #endif > #include > > because "qemu/osdep.h" already includes . > > Clearer now? Ah, right I missed that in your previous patch. Thanks! Reviewed-by: Christian Schoenebeck Best regards, Christian Schoenebeck
Re: [PATCH v4 18/19] 9p: Drop superfluous include of linux/limits.h
On Thursday, January 19, 2023 7:59:58 AM CET Markus Armbruster wrote: > Signed-off-by: Markus Armbruster > --- > hw/9pfs/9p.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > index 9621ec1341..aa736af380 100644 > --- a/hw/9pfs/9p.c > +++ b/hw/9pfs/9p.c > @@ -17,9 +17,6 @@ > */ > > #include "qemu/osdep.h" > -#ifdef CONFIG_LINUX > -#include > -#endif > #include > #include "hw/virtio/virtio.h" > #include "qapi/error.h" > Where did that base version come from? I don't see it anywhere in history. Last relevant change in context was a136d17590a. Best regards, Christian Schoenebeck
Re: [PATCH 10/11] alsaaudio: change default playback settings
On Friday, December 30, 2022 10:01:47 AM CET Volker Rümelin wrote: > Am 28.12.22 um 14:52 schrieb Christian Schoenebeck: > > On Monday, December 26, 2022 4:08:37 PM CET Volker Rümelin wrote: > >> Am 21.12.22 um 12:03 schrieb Christian Schoenebeck: > >>> On Sunday, December 18, 2022 6:15:38 PM CET Volker Rümelin wrote: > >>>> The currently used default playback settings in the ALSA audio > >>>> backend are a bit unfortunate. With a few emulated audio devices, > >>>> audio playback does not work properly. Here is a short part of > >>>> the debug log while audio is playing (elapsed time in seconds). > >>> Which emulated devices are these? > >> The hda device and sb16. When I wrote this patch two months ago ac97 > >> also had occasional dropouts, but at the moment ac97 works without issues. > >> > >>>> audio: Elapsed since last alsa run (running): 0.046244 > >>>> audio: Elapsed since last alsa run (running): 0.023137 > >>>> audio: Elapsed since last alsa run (running): 0.023170 > >>>> audio: Elapsed since last alsa run (running): 0.023650 > >>>> audio: Elapsed since last alsa run (running): 0.060802 > >>>> audio: Elapsed since last alsa run (running): 0.031931 > >>>> > >>>> For some audio devices the time of more than 23ms between updates > >>>> is too long. > >>>> > >>>> Set the period time to 5.8ms so that the maximum time between > >>>> two updates typically does not exceed 11ms. This roughly matches > >>>> the 10ms period time when doing playback with the audio timer. > >>>> After this patch the debug log looks like this. > >>> And what about dynamically adapting that value instead of reducing period > >>> time > >>> for everyone by default? > >> It seems this would be only needed for the ALSA backend. All other > >> backends with the exception of OSS are fine with a 10ms period, and the > >> ALSA audio backend also uses 10ms with -audiodev > >> alsa,out.try-poll=off,in.try-poll=off. > > OK, but all it would need was adjusting dev->timer_period appropriately > > either > > in audio_validate_opts() [audio/audio.c, line 2126] to handle it generalized > > or at the end of alsa_audio_init() [audio/alsaaudio.c, line 944] if > > specifically for ALSA only, no? > > I think this should be the other way around. If period-length wasn't > specified on the command line, it should be calculated from > timer-period. With timer based playback or recording, the guest should > be able to write or read new audio frames every timer-period > microseconds. To have a high probability that the guest can write or > read new frames every timer-period, the asynchronous updates of the > audio backend have to be faster than timer-period e.g. 75-80% of > timer-period. But that's a different patch. Probably in both directions, depending on what the user supplied. I still have this feeling that this patch might just move the problem to other users (dropouts) until properly addressed, but anyway, for the time being: Acked-by: Christian Schoenebeck > >>> 23ms is usually a good trade off between low latency, CPU load and > >>> potential > >>> for audio dropouts. > >> Quite often it's longer than 23ms. For the rest of the audio backends a > >> timer period of 10ms was selected as a good trade off between CPU load > >> and audio dropouts. But you are right, this patch increases the CPU load. > >> > >> On my system the CPU load is increased by 0.9%. This was measured with a > >> Linux guest using rhythmbox for audio playback. The guest was configured > >> to use pulseaudio as sound server. The measurement was done with top -b > >> -d 10 -n 14 over a period of two minutes. The first and last measurement > >> was dropped. The average QEMU CPU load was 10.7% with and 9.8% without > >> this patch. > >> > >> I would prefer a system with a 0.9% increased CPU load where audio just > >> works over a system where you have to fine tune audio parameters. > >>
Re: [PATCH] ui/cocoa: user friendly characters for release mouse
On Thursday, December 29, 2022 1:31:09 PM CET Philippe Mathieu-Daudé wrote:
> On 27/12/22 17:15, Christian Schoenebeck wrote:
> > While mouse is grabbed, window title contains a hint for the user what
> > keyboard keys to press to release the mouse. Make that hint text a bit
> > more user friendly for a Mac user:
> >
> > - Replace "Ctrl" and "Alt" by appropriate symbols for those keyboard
> > keys typically displayed for them on a Mac (encode those symbols by
> > using UTF-8 characters).
> >
> > - Drop " + " in between the keys, as that's not common on macOS for
> > documenting keyboard shortcuts.
> >
> > - Convert lower case "g" to upper case "G", as that's common on macOS.
> >
> > - Add one additional space at start and end of key stroke set, to
> > visually separate the key strokes from the rest of the text.
> >
> > Signed-off-by: Christian Schoenebeck
> > ---
> > ui/cocoa.m | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/ui/cocoa.m b/ui/cocoa.m
> > index e915c344a8..289a2b193e 100644
> > --- a/ui/cocoa.m
> > +++ b/ui/cocoa.m
> > @@ -72,6 +72,9 @@
> >
> > #define cgrect(nsrect) (*(CGRect *)&(nsrect))
> >
> > +#define UC_CTRL_KEY "\xe2\x8c\x83"
> > +#define UC_ALT_KEY "\xe2\x8c\xa5"
> > +
> > typedef struct {
> > int width;
> > int height;
> > @@ -1135,9 +1138,9 @@ - (void) grabMouse
> >
> > if (!isFullscreen) {
> > if (qemu_name)
> > -[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
> > (Press ctrl + alt + g to release Mouse)", qemu_name]];
> > +[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
> > (Press " UC_CTRL_KEY " " UC_ALT_KEY " G to release Mouse)", qemu_name]];
>
> I was a bit confused by the control symbol at first and tough
> I had to press '^'; thus I'm not sure keeping 'ctrl' wouldn't
> be clearer. The UC_ALT_KEY symbol certainly is. Anyhow,
It _should_ be clear to Mac users that "^" == "control" key on a Mac keyboard,
as that's how it is presented for keyboard shortcuts in all Mac menus. But if
it's really irritating then we can also revert that to either "Ctrl" or
"control". It's a quick change.
I just got itched by the "Alt" hint actually, which is not printed on any Mac
keyboard.
> Tested-by: Philippe Mathieu-Daudé
> Reviewed-by: Philippe Mathieu-Daudé
Thanks!
> > else
> > -[normalWindow setTitle:@"QEMU - (Press ctrl + alt + g to
> > release Mouse)"];
> > +[normalWindow setTitle:@"QEMU - (Press " UC_CTRL_KEY " "
> > UC_ALT_KEY " G to release Mouse)"];
> > }
> > [self hideCursor];
> > CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
>
>
>
Re: [PATCH v3 07/17] hw/9pfs: Support getting current directory offset for Windows
On Thursday, December 29, 2022 7:03:54 AM CET Shi, Guohuai wrote:
>
> > -Original Message-
> > From: Christian Schoenebeck
> > Sent: Wednesday, December 28, 2022 19:51
> > To: Greg Kurz ; qemu-devel@nongnu.org
> > Cc: Meng, Bin ; Shi, Guohuai
> >
> > Subject: Re: [PATCH v3 07/17] hw/9pfs: Support getting current directory
> > offset for Windows
> >
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and
> > know the content is safe.
> >
> > On Wednesday, December 21, 2022 7:02:43 PM CET Shi, Guohuai wrote:
> > >
> > > > -Original Message-
> > > > From: Christian Schoenebeck
> > > > Sent: Wednesday, December 21, 2022 22:48
> > > > To: Greg Kurz ; qemu-devel@nongnu.org
> > > > Cc: Shi, Guohuai ; Meng, Bin
> > > >
> > > > Subject: Re: [PATCH v3 07/17] hw/9pfs: Support getting current
> > > > directory offset for Windows
> > > >
> > > > CAUTION: This email comes from a non Wind River email account!
> > > > Do not click links or open attachments unless you recognize the
> > > > sender and know the content is safe.
> > > >
> > > > On Monday, December 19, 2022 11:20:11 AM CET Bin Meng wrote:
> > > > > From: Guohuai Shi
> > > > >
> > > > > On Windows 'struct dirent' does not have current directory offset.
> > > > > Update qemu_dirent_off() to support Windows.
> > > > >
> > > > > While we are here, add a build time check to error out if a new
> > > > > host does not implement this helper.
> > > > >
> > > > > Signed-off-by: Guohuai Shi
> > > > > Signed-off-by: Bin Meng
> > > > > ---
> > > > >
> > > > > (no changes since v1)
> > > > >
> > > > > hw/9pfs/9p-util.h | 11 ---
> > > > > hw/9pfs/9p-util-win32.c | 7 +++
> > > > > hw/9pfs/9p.c| 4 ++--
> > > > > hw/9pfs/codir.c | 2 +-
> > > > > 4 files changed, 18 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h index
> > > > > 90420a7578..e395936b30 100644
> > > > > --- a/hw/9pfs/9p-util.h
> > > > > +++ b/hw/9pfs/9p-util.h
> > > > > @@ -127,6 +127,7 @@ int unlinkat_win32(int dirfd, const char
> > > > > *pathname, int flags); int statfs_win32(const char *root_path,
> > > > > struct statfs *stbuf); int openat_dir(int dirfd, const char
> > > > > *name); int openat_file(int dirfd, const char *name, int flags,
> > > > > mode_t mode);
> > > > > +off_t qemu_dirent_off_win32(void *s, void *fs);
> > > > > #endif
> > > > >
> > > > > static inline void close_preserve_errno(int fd) @@ -200,12
> > > > > +201,16 @@ ssize_t fremovexattrat_nofollow(int dirfd, const char
> > *filename,
> > > > > * so ensure it is manually injected earlier and call here when
> > > > > * needed.
> > > > > */
> > > > > -static inline off_t qemu_dirent_off(struct dirent *dent)
> > > > > +static inline off_t qemu_dirent_off(struct dirent *dent, void *s,
> > > > > +void *fs)
> > > > > {
> > > >
> > > > Not sure why you chose void* here.
> > >
> > > It is "V9fsState *" here, but 9p-util.h may be included by some other
> > source file which is not have definition of "V9fsState".
> > > So change it to "void *" to prevent unnecessary type declarations.
> >
> > You can anonymously declare the struct to avoid cyclic dependencies (e.g.
> > like in 9p.h):
> >
> > typedef struct V9fsState V9fsState;
> >
> > Avoid the void.
> >
>
> Got it, understood.
>
> > > >
> > > > > -#ifdef CONFIG_DARWIN
> > > > > +#if defined(CONFIG_DARWIN)
> > > > > return dent->d_seekoff;
> > > > > -#else
> > > > > +#elif defined(CONFIG_LINUX)
> > > > > return dent->d_off;
> > > > > +#elif defined(CONFIG_WIN32)
> > > > > +return qemu_dirent_off_win32(s, fs); #else #error Missing
> > > > > +qemu_dirent_off() implementation for this host system
>
Re: [PATCH 10/11] alsaaudio: change default playback settings
On Monday, December 26, 2022 4:08:37 PM CET Volker Rümelin wrote:
> Am 21.12.22 um 12:03 schrieb Christian Schoenebeck:
> > On Sunday, December 18, 2022 6:15:38 PM CET Volker Rümelin wrote:
> >> The currently used default playback settings in the ALSA audio
> >> backend are a bit unfortunate. With a few emulated audio devices,
> >> audio playback does not work properly. Here is a short part of
> >> the debug log while audio is playing (elapsed time in seconds).
> > Which emulated devices are these?
>
> The hda device and sb16. When I wrote this patch two months ago ac97
> also had occasional dropouts, but at the moment ac97 works without issues.
>
> >> audio: Elapsed since last alsa run (running): 0.046244
> >> audio: Elapsed since last alsa run (running): 0.023137
> >> audio: Elapsed since last alsa run (running): 0.023170
> >> audio: Elapsed since last alsa run (running): 0.023650
> >> audio: Elapsed since last alsa run (running): 0.060802
> >> audio: Elapsed since last alsa run (running): 0.031931
> >>
> >> For some audio devices the time of more than 23ms between updates
> >> is too long.
> >>
> >> Set the period time to 5.8ms so that the maximum time between
> >> two updates typically does not exceed 11ms. This roughly matches
> >> the 10ms period time when doing playback with the audio timer.
> >> After this patch the debug log looks like this.
> > And what about dynamically adapting that value instead of reducing period
> > time
> > for everyone by default?
>
> It seems this would be only needed for the ALSA backend. All other
> backends with the exception of OSS are fine with a 10ms period, and the
> ALSA audio backend also uses 10ms with -audiodev
> alsa,out.try-poll=off,in.try-poll=off.
OK, but all it would need was adjusting dev->timer_period appropriately either
in audio_validate_opts() [audio/audio.c, line 2126] to handle it generalized
or at the end of alsa_audio_init() [audio/alsaaudio.c, line 944] if
specifically for ALSA only, no?
> > 23ms is usually a good trade off between low latency, CPU load and potential
> > for audio dropouts.
>
> Quite often it's longer than 23ms. For the rest of the audio backends a
> timer period of 10ms was selected as a good trade off between CPU load
> and audio dropouts. But you are right, this patch increases the CPU load.
>
> On my system the CPU load is increased by 0.9%. This was measured with a
> Linux guest using rhythmbox for audio playback. The guest was configured
> to use pulseaudio as sound server. The measurement was done with top -b
> -d 10 -n 14 over a period of two minutes. The first and last measurement
> was dropped. The average QEMU CPU load was 10.7% with and 9.8% without
> this patch.
>
> I would prefer a system with a 0.9% increased CPU load where audio just
> works over a system where you have to fine tune audio parameters.
>
> >> audio: Elapsed since last alsa run (running): 0.011919
> >> audio: Elapsed since last alsa run (running): 0.005788
> >> audio: Elapsed since last alsa run (running): 0.005995
> >> audio: Elapsed since last alsa run (running): 0.011069
> >> audio: Elapsed since last alsa run (running): 0.005901
> >> audio: Elapsed since last alsa run (running): 0.006084
> >>
> >> Signed-off-by: Volker Rümelin
> >> ---
> >> audio/alsaaudio.c | 11 ---
> >> 1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> >> index 5f50dfa0bf..0cc982e61f 100644
> >> --- a/audio/alsaaudio.c
> >> +++ b/audio/alsaaudio.c
> >> @@ -913,17 +913,14 @@ static void *alsa_audio_init(Audiodev *dev)
> >> alsa_init_per_direction(aopts->in);
> >> alsa_init_per_direction(aopts->out);
> >>
> >> -/*
> >> - * need to define them, as otherwise alsa produces no sound
> >> - * doesn't set has_* so alsa_open can identify it wasn't set by the
> >> user
> >> - */
> >> +/* don't set has_* so alsa_open can identify it wasn't set by the
> >> user */
> >> if (!dev->u.alsa.out->has_period_length) {
> >> -/* 1024 frames assuming 44100Hz */
> >> -dev->u.alsa.out->period_length = 1024 * 100 / 44100;
> >> +/* 256 frames assuming 44100Hz */
> >> +dev->u.alsa.out->period_length = 5805;
> >> }
> >> if (!dev->u.alsa.out->has_buffer_length) {
> >> /* 4096 frames assum
Re: [PATCH v3 07/17] hw/9pfs: Support getting current directory offset for Windows
On Wednesday, December 21, 2022 7:02:43 PM CET Shi, Guohuai wrote:
>
> > -Original Message-
> > From: Christian Schoenebeck
> > Sent: Wednesday, December 21, 2022 22:48
> > To: Greg Kurz ; qemu-devel@nongnu.org
> > Cc: Shi, Guohuai ; Meng, Bin
> >
> > Subject: Re: [PATCH v3 07/17] hw/9pfs: Support getting current directory
> > offset for Windows
> >
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and
> > know the content is safe.
> >
> > On Monday, December 19, 2022 11:20:11 AM CET Bin Meng wrote:
> > > From: Guohuai Shi
> > >
> > > On Windows 'struct dirent' does not have current directory offset.
> > > Update qemu_dirent_off() to support Windows.
> > >
> > > While we are here, add a build time check to error out if a new host
> > > does not implement this helper.
> > >
> > > Signed-off-by: Guohuai Shi
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > hw/9pfs/9p-util.h | 11 ---
> > > hw/9pfs/9p-util-win32.c | 7 +++
> > > hw/9pfs/9p.c| 4 ++--
> > > hw/9pfs/codir.c | 2 +-
> > > 4 files changed, 18 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h index
> > > 90420a7578..e395936b30 100644
> > > --- a/hw/9pfs/9p-util.h
> > > +++ b/hw/9pfs/9p-util.h
> > > @@ -127,6 +127,7 @@ int unlinkat_win32(int dirfd, const char
> > > *pathname, int flags); int statfs_win32(const char *root_path, struct
> > > statfs *stbuf); int openat_dir(int dirfd, const char *name); int
> > > openat_file(int dirfd, const char *name, int flags, mode_t mode);
> > > +off_t qemu_dirent_off_win32(void *s, void *fs);
> > > #endif
> > >
> > > static inline void close_preserve_errno(int fd) @@ -200,12 +201,16 @@
> > > ssize_t fremovexattrat_nofollow(int dirfd, const char *filename,
> > > * so ensure it is manually injected earlier and call here when
> > > * needed.
> > > */
> > > -static inline off_t qemu_dirent_off(struct dirent *dent)
> > > +static inline off_t qemu_dirent_off(struct dirent *dent, void *s,
> > > +void *fs)
> > > {
> >
> > Not sure why you chose void* here.
>
> It is "V9fsState *" here, but 9p-util.h may be included by some other source
> file which is not have definition of "V9fsState".
> So change it to "void *" to prevent unnecessary type declarations.
You can anonymously declare the struct to avoid cyclic dependencies (e.g. like
in 9p.h):
typedef struct V9fsState V9fsState;
Avoid the void.
> >
> > > -#ifdef CONFIG_DARWIN
> > > +#if defined(CONFIG_DARWIN)
> > > return dent->d_seekoff;
> > > -#else
> > > +#elif defined(CONFIG_LINUX)
> > > return dent->d_off;
> > > +#elif defined(CONFIG_WIN32)
> > > +return qemu_dirent_off_win32(s, fs); #else #error Missing
> > > +qemu_dirent_off() implementation for this host system
> > > #endif
> > > }
> > >
> > > diff --git a/hw/9pfs/9p-util-win32.c b/hw/9pfs/9p-util-win32.c index
> > > 7a270a7bd5..3592e057ce 100644
> > > --- a/hw/9pfs/9p-util-win32.c
> > > +++ b/hw/9pfs/9p-util-win32.c
> > > @@ -929,3 +929,10 @@ int qemu_mknodat(int dirfd, const char *filename,
> > mode_t mode, dev_t dev)
> > > errno = ENOTSUP;
> > > return -1;
> > > }
> > > +
> > > +off_t qemu_dirent_off_win32(void *s, void *fs) {
> > > +V9fsState *v9fs = s;
> > > +
> > > +return v9fs->ops->telldir(>ctx, (V9fsFidOpenState *)fs); }
> >
> > That's a bit tricky. So far (i.e. for Linux host, macOS host) we are storing
> > the directory offset directly to the dirent struct. We are not using
> > telldir() as the stream might have mutated in the meantime, hence calling
> > telldir() might return a value that does no longer correlate to dirent in
> > question.
> >
> > Hence my idea was to use the same hack for Windows as we did for macOS,
> > where
> > we simply misuse a dirent field known to be not used, on macOS that's
> > d_seekoff which we are misusing for that purpose.
> >
> > Looking at the mingw dirent.h header though, there is not much we can choose
> > from. d_reclen is not used, but too short, d_ino is not us
[PATCH] ui/cocoa: user friendly characters for release mouse
While mouse is grabbed, window title contains a hint for the user what
keyboard keys to press to release the mouse. Make that hint text a bit
more user friendly for a Mac user:
- Replace "Ctrl" and "Alt" by appropriate symbols for those keyboard
keys typically displayed for them on a Mac (encode those symbols by
using UTF-8 characters).
- Drop " + " in between the keys, as that's not common on macOS for
documenting keyboard shortcuts.
- Convert lower case "g" to upper case "G", as that's common on macOS.
- Add one additional space at start and end of key stroke set, to
visually separate the key strokes from the rest of the text.
Signed-off-by: Christian Schoenebeck
---
ui/cocoa.m | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index e915c344a8..289a2b193e 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -72,6 +72,9 @@
#define cgrect(nsrect) (*(CGRect *)&(nsrect))
+#define UC_CTRL_KEY "\xe2\x8c\x83"
+#define UC_ALT_KEY "\xe2\x8c\xa5"
+
typedef struct {
int width;
int height;
@@ -1135,9 +1138,9 @@ - (void) grabMouse
if (!isFullscreen) {
if (qemu_name)
-[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
(Press ctrl + alt + g to release Mouse)", qemu_name]];
+[normalWindow setTitle:[NSString stringWithFormat:@"QEMU %s -
(Press " UC_CTRL_KEY " " UC_ALT_KEY " G to release Mouse)", qemu_name]];
else
-[normalWindow setTitle:@"QEMU - (Press ctrl + alt + g to release
Mouse)"];
+[normalWindow setTitle:@"QEMU - (Press " UC_CTRL_KEY " "
UC_ALT_KEY " G to release Mouse)"];
}
[self hideCursor];
CGAssociateMouseAndMouseCursorPosition(isAbsoluteEnabled);
--
2.32.0 (Apple Git-132)
Re: [PATCH] hw/audio/c97: fix abort in audio_calloc()
On Sunday, December 25, 2022 1:13:57 PM CET Qiang Liu wrote:
> Section 5.10.2 of the AC97 specification
> (https://hands.com/~lkcl/ac97_r23.pdf)
> shows the feasibility to support for rates other than 48kHZ. Specifically,
> AC97_PCM_Front_DAC_Rate (reg 2Ch) should be from 8kHZ to 48kHZ.
>
> Before Volker Rümelin fixed it in 12f4abf6a245 and 0cbc8bd4694f, an adversary
> could leverage this to crash QEMU.
>
> Fixes: e5c9a13e2670 ("PCI AC97 emulation by malc.")
> Reported-by: Volker Rümelin
> Reported-by: Qiang Liu
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1393
> Signed-off-by: Qiang Liu
> ---
> hw/audio/ac97.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/hw/audio/ac97.c b/hw/audio/ac97.c
> index be2dd701a4..826411e462 100644
> --- a/hw/audio/ac97.c
> +++ b/hw/audio/ac97.c
> @@ -625,9 +625,14 @@ static void nam_writew(void *opaque, uint32_t addr,
> uint32_t val)
> break;
> case AC97_PCM_Front_DAC_Rate:
> if (mixer_load(s, AC97_Extended_Audio_Ctrl_Stat) & EACS_VRA) {
> -mixer_store(s, addr, val);
> -dolog("Set front DAC rate to %d\n", val);
> -open_voice(s, PO_INDEX, val);
> +if (val >= 8000 && val <= 48000) {
> +mixer_store(s, addr, val);
> +dolog("Set front DAC rate to %d\n", val);
> +open_voice(s, PO_INDEX, val);
> +} else {
> +dolog("Attempt to set front DAC rate to %d, but valid is"
> + "8-48kHZ\n", val);
> +}
Missing space between "is" and "8-48kHz" and it is "Hz" (lower z). Except of
that:
Reviewed-by: Christian Schoenebeck
> } else {
> dolog("Attempt to set front DAC rate to %d, but VRA is not
> set\n",
>val);
>
[PULL 4/5] hw/9pfs: Drop unnecessary *xattr wrapper API declarations
From: Bin Meng
These are not used anywhere in the source tree. Drop them.
Signed-off-by: Bin Meng
Reviewed-by: Greg Kurz
Message-Id: <20221219102022.2167736-3-bin.m...@windriver.com>
Signed-off-by: Christian Schoenebeck
---
hw/9pfs/9p-util.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
index c3526144c9..ccfc8b1cb3 100644
--- a/hw/9pfs/9p-util.h
+++ b/hw/9pfs/9p-util.h
@@ -90,19 +90,8 @@ static inline int errno_to_dotl(int err) {
#ifdef CONFIG_DARWIN
#define qemu_fgetxattr(...) fgetxattr(__VA_ARGS__, 0, 0)
-#define qemu_lgetxattr(...) getxattr(__VA_ARGS__, 0, XATTR_NOFOLLOW)
-#define qemu_llistxattr(...) listxattr(__VA_ARGS__, XATTR_NOFOLLOW)
-#define qemu_lremovexattr(...) removexattr(__VA_ARGS__, XATTR_NOFOLLOW)
-static inline int qemu_lsetxattr(const char *path, const char *name,
- const void *value, size_t size, int flags) {
-return setxattr(path, name, value, size, 0, flags | XATTR_NOFOLLOW);
-}
#else
#define qemu_fgetxattr fgetxattr
-#define qemu_lgetxattr lgetxattr
-#define qemu_llistxattr llistxattr
-#define qemu_lremovexattr lremovexattr
-#define qemu_lsetxattr lsetxattr
#endif
static inline void close_preserve_errno(int fd)
--
2.30.2
[PULL 5/5] hw/9pfs: Replace the direct call to xxxat() APIs with a wrapper
From: Bin Meng
xxxat() APIs are only available on POSIX platforms. For future
extension to Windows, let's replace the direct call to xxxat()
APIs with a wrapper.
Signed-off-by: Bin Meng
Message-Id: <20221219102022.2167736-4-bin.m...@windriver.com>
Signed-off-by: Christian Schoenebeck
---
hw/9pfs/9p-local.c | 32
hw/9pfs/9p-util.h | 15 +++
2 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index d42ce6d8b8..d2246a3d7e 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -103,14 +103,14 @@ static void renameat_preserve_errno(int odirfd, const
char *opath, int ndirfd,
const char *npath)
{
int serrno = errno;
-renameat(odirfd, opath, ndirfd, npath);
+qemu_renameat(odirfd, opath, ndirfd, npath);
errno = serrno;
}
static void unlinkat_preserve_errno(int dirfd, const char *path, int flags)
{
int serrno = errno;
-unlinkat(dirfd, path, flags);
+qemu_unlinkat(dirfd, path, flags);
errno = serrno;
}
@@ -194,7 +194,7 @@ static int local_lstat(FsContext *fs_ctx, V9fsPath
*fs_path, struct stat *stbuf)
goto out;
}
-err = fstatat(dirfd, name, stbuf, AT_SYMLINK_NOFOLLOW);
+err = qemu_fstatat(dirfd, name, stbuf, AT_SYMLINK_NOFOLLOW);
if (err) {
goto err_out;
}
@@ -253,7 +253,7 @@ static int local_set_mapped_file_attrat(int dirfd, const
char *name,
}
}
} else {
-ret = mkdirat(dirfd, VIRTFS_META_DIR, 0700);
+ret = qemu_mkdirat(dirfd, VIRTFS_META_DIR, 0700);
if (ret < 0 && errno != EEXIST) {
return -1;
}
@@ -349,7 +349,7 @@ static int fchmodat_nofollow(int dirfd, const char *name,
mode_t mode)
*/
/* First, we clear non-racing symlinks out of the way. */
-if (fstatat(dirfd, name, , AT_SYMLINK_NOFOLLOW)) {
+if (qemu_fstatat(dirfd, name, , AT_SYMLINK_NOFOLLOW)) {
return -1;
}
if (S_ISLNK(stbuf.st_mode)) {
@@ -734,7 +734,7 @@ static int local_mkdir(FsContext *fs_ctx, V9fsPath
*dir_path,
if (fs_ctx->export_flags & V9FS_SM_MAPPED ||
fs_ctx->export_flags & V9FS_SM_MAPPED_FILE) {
-err = mkdirat(dirfd, name, fs_ctx->dmode);
+err = qemu_mkdirat(dirfd, name, fs_ctx->dmode);
if (err == -1) {
goto out;
}
@@ -750,7 +750,7 @@ static int local_mkdir(FsContext *fs_ctx, V9fsPath
*dir_path,
}
} else if (fs_ctx->export_flags & V9FS_SM_PASSTHROUGH ||
fs_ctx->export_flags & V9FS_SM_NONE) {
-err = mkdirat(dirfd, name, credp->fc_mode);
+err = qemu_mkdirat(dirfd, name, credp->fc_mode);
if (err == -1) {
goto out;
}
@@ -990,7 +990,7 @@ static int local_link(FsContext *ctx, V9fsPath *oldpath,
if (ctx->export_flags & V9FS_SM_MAPPED_FILE) {
int omap_dirfd, nmap_dirfd;
-ret = mkdirat(ndirfd, VIRTFS_META_DIR, 0700);
+ret = qemu_mkdirat(ndirfd, VIRTFS_META_DIR, 0700);
if (ret < 0 && errno != EEXIST) {
goto err_undo_link;
}
@@ -1085,7 +1085,7 @@ static int local_utimensat(FsContext *s, V9fsPath
*fs_path,
goto out;
}
-ret = utimensat(dirfd, name, buf, AT_SYMLINK_NOFOLLOW);
+ret = qemu_utimensat(dirfd, name, buf, AT_SYMLINK_NOFOLLOW);
close_preserve_errno(dirfd);
out:
g_free(dirpath);
@@ -1116,7 +1116,7 @@ static int local_unlinkat_common(FsContext *ctx, int
dirfd, const char *name,
if (fd == -1) {
return -1;
}
-ret = unlinkat(fd, VIRTFS_META_DIR, AT_REMOVEDIR);
+ret = qemu_unlinkat(fd, VIRTFS_META_DIR, AT_REMOVEDIR);
close_preserve_errno(fd);
if (ret < 0 && errno != ENOENT) {
return -1;
@@ -1124,7 +1124,7 @@ static int local_unlinkat_common(FsContext *ctx, int
dirfd, const char *name,
}
map_dirfd = openat_dir(dirfd, VIRTFS_META_DIR);
if (map_dirfd != -1) {
-ret = unlinkat(map_dirfd, name, 0);
+ret = qemu_unlinkat(map_dirfd, name, 0);
close_preserve_errno(map_dirfd);
if (ret < 0 && errno != ENOENT) {
return -1;
@@ -1134,7 +1134,7 @@ static int local_unlinkat_common(FsContext *ctx, int
dirfd, const char *name,
}
}
-return unlinkat(dirfd, name, flags);
+return qemu_unlinkat(dirfd, name, flags);
}
static int local_remove(FsContext *ctx, const char *path)
@@ -1151,7 +1151,7 @@ static int local_remove(FsContext *ctx, const char *path)
goto out;
}
-if (fstatat(dirfd, name, , AT_SYMLINK_NOFOLLOW) < 0) {
+if (qemu_fstatat(dirfd, name, , AT_SYMLINK_NOFOLLOW) < 0) {
goto err_out;
}
@@ -1296,7 +1296,7 @@ static
[PULL 3/5] qemu/xattr.h: Exclude for Windows
From: Bin Meng Windows does not have . Signed-off-by: Bin Meng Message-Id: <20221219102022.2167736-2-bin.m...@windriver.com> Signed-off-by: Christian Schoenebeck --- include/qemu/xattr.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/qemu/xattr.h b/include/qemu/xattr.h index f1d0f7be74..b08a934acc 100644 --- a/include/qemu/xattr.h +++ b/include/qemu/xattr.h @@ -25,7 +25,9 @@ # if !defined(ENOATTR) #define ENOATTR ENODATA # endif -# include +# ifndef CONFIG_WIN32 +#include +# endif #endif #endif -- 2.30.2
[PULL 0/5] 9p queue 2022-12-23
The following changes since commit 222059a0fccf4af3be776fe35a5ea2d6a68f9a0b: Merge tag 'pull-ppc-20221221' of https://gitlab.com/danielhb/qemu into staging (2022-12-21 18:08:09 +) are available in the Git repository at: https://github.com/cschoenebeck/qemu.git tags/pull-9p-20221223 for you to fetch changes up to 6ca60cd7a388a776d72739e5a404e65c19460511: hw/9pfs: Replace the direct call to xxxat() APIs with a wrapper (2022-12-23 11:48:13 +0100) 9pfs: Windows host prep, cleanup * Next preparatory patches for upcoming Windows host support. * Cleanup patches. Bin Meng (3): qemu/xattr.h: Exclude for Windows hw/9pfs: Drop unnecessary *xattr wrapper API declarations hw/9pfs: Replace the direct call to xxxat() APIs with a wrapper Christian Schoenebeck (1): MAINTAINERS: Add 9p test client to section "virtio-9p" Greg Kurz (1): 9pfs: Fix some return statements in the synth backend MAINTAINERS | 1 + hw/9pfs/9p-local.c | 32 hw/9pfs/9p-synth.c | 12 ++-- hw/9pfs/9p-util.h| 26 +++--- include/qemu/xattr.h | 4 +++- 5 files changed, 37 insertions(+), 38 deletions(-)
[PULL 1/5] 9pfs: Fix some return statements in the synth backend
From: Greg Kurz
The qemu_v9fs_synth_mkdir() and qemu_v9fs_synth_add_file() functions
currently return a positive errno value on failure. This causes
checkpatch.pl to spit several errors like the one below:
ERROR: return of an errno should typically be -ve (return -EAGAIN)
+return EAGAIN;
Simply change the sign. This has no consequence since callers
assert() the returned value to be equal to 0.
Reported-by: Markus Armbruster
Signed-off-by: Greg Kurz
Message-Id: <166930551818.827792.10663674346122681963.stgit@bahia>
[C.S.: - Resolve conflict with 66997c42e02c. ]
Signed-off-by: Christian Schoenebeck
---
hw/9pfs/9p-synth.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
index 38d787f494..f62c40b639 100644
--- a/hw/9pfs/9p-synth.c
+++ b/hw/9pfs/9p-synth.c
@@ -75,10 +75,10 @@ int qemu_v9fs_synth_mkdir(V9fsSynthNode *parent, int mode,
V9fsSynthNode *node, *tmp;
if (!synth_fs) {
-return EAGAIN;
+return -EAGAIN;
}
if (!name || (strlen(name) >= NAME_MAX)) {
-return EINVAL;
+return -EINVAL;
}
if (!parent) {
parent = _root;
@@ -86,7 +86,7 @@ int qemu_v9fs_synth_mkdir(V9fsSynthNode *parent, int mode,
QEMU_LOCK_GUARD(_mutex);
QLIST_FOREACH(tmp, >child, sibling) {
if (!strcmp(tmp->name, name)) {
-return EEXIST;
+return -EEXIST;
}
}
/* Add the name */
@@ -106,10 +106,10 @@ int qemu_v9fs_synth_add_file(V9fsSynthNode *parent, int
mode,
V9fsSynthNode *node, *tmp;
if (!synth_fs) {
-return EAGAIN;
+return -EAGAIN;
}
if (!name || (strlen(name) >= NAME_MAX)) {
-return EINVAL;
+return -EINVAL;
}
if (!parent) {
parent = _root;
@@ -118,7 +118,7 @@ int qemu_v9fs_synth_add_file(V9fsSynthNode *parent, int
mode,
QEMU_LOCK_GUARD(_mutex);
QLIST_FOREACH(tmp, >child, sibling) {
if (!strcmp(tmp->name, name)) {
-return EEXIST;
+return -EEXIST;
}
}
/* Add file type and remove write bits */
--
2.30.2
[PULL 2/5] MAINTAINERS: Add 9p test client to section "virtio-9p"
The 9p test cases use a dedicated, lite-weight 9p client implementation (using virtio transport) under tests/qtest/libqos/ to communicate with QEMU's 9p server. It's already there for a long time. Let's officially assign it to 9p maintainers. Signed-off-by: Christian Schoenebeck Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Greg Kurz Reviewed-by: Wilfred Mallawa Message-Id: --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index b270eb8e5b..b0091d2ad8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2053,6 +2053,7 @@ X: hw/9pfs/xen-9p* F: fsdev/ F: docs/tools/virtfs-proxy-helper.rst F: tests/qtest/virtio-9p-test.c +F: tests/qtest/libqos/virtio-9p* T: git https://gitlab.com/gkurz/qemu.git 9p-next T: git https://github.com/cschoenebeck/qemu.git 9p.next -- 2.30.2
Re: [PATCH v3 07/17] hw/9pfs: Support getting current directory offset for Windows
On Monday, December 19, 2022 11:20:11 AM CET Bin Meng wrote:
> From: Guohuai Shi
>
> On Windows 'struct dirent' does not have current directory offset.
> Update qemu_dirent_off() to support Windows.
>
> While we are here, add a build time check to error out if a new
> host does not implement this helper.
>
> Signed-off-by: Guohuai Shi
> Signed-off-by: Bin Meng
> ---
>
> (no changes since v1)
>
> hw/9pfs/9p-util.h | 11 ---
> hw/9pfs/9p-util-win32.c | 7 +++
> hw/9pfs/9p.c| 4 ++--
> hw/9pfs/codir.c | 2 +-
> 4 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> index 90420a7578..e395936b30 100644
> --- a/hw/9pfs/9p-util.h
> +++ b/hw/9pfs/9p-util.h
> @@ -127,6 +127,7 @@ int unlinkat_win32(int dirfd, const char *pathname, int
> flags);
> int statfs_win32(const char *root_path, struct statfs *stbuf);
> int openat_dir(int dirfd, const char *name);
> int openat_file(int dirfd, const char *name, int flags, mode_t mode);
> +off_t qemu_dirent_off_win32(void *s, void *fs);
> #endif
>
> static inline void close_preserve_errno(int fd)
> @@ -200,12 +201,16 @@ ssize_t fremovexattrat_nofollow(int dirfd, const char
> *filename,
> * so ensure it is manually injected earlier and call here when
> * needed.
> */
> -static inline off_t qemu_dirent_off(struct dirent *dent)
> +static inline off_t qemu_dirent_off(struct dirent *dent, void *s, void *fs)
> {
Not sure why you chose void* here.
> -#ifdef CONFIG_DARWIN
> +#if defined(CONFIG_DARWIN)
> return dent->d_seekoff;
> -#else
> +#elif defined(CONFIG_LINUX)
> return dent->d_off;
> +#elif defined(CONFIG_WIN32)
> +return qemu_dirent_off_win32(s, fs);
> +#else
> +#error Missing qemu_dirent_off() implementation for this host system
> #endif
> }
>
> diff --git a/hw/9pfs/9p-util-win32.c b/hw/9pfs/9p-util-win32.c
> index 7a270a7bd5..3592e057ce 100644
> --- a/hw/9pfs/9p-util-win32.c
> +++ b/hw/9pfs/9p-util-win32.c
> @@ -929,3 +929,10 @@ int qemu_mknodat(int dirfd, const char *filename, mode_t
> mode, dev_t dev)
> errno = ENOTSUP;
> return -1;
> }
> +
> +off_t qemu_dirent_off_win32(void *s, void *fs)
> +{
> +V9fsState *v9fs = s;
> +
> +return v9fs->ops->telldir(>ctx, (V9fsFidOpenState *)fs);
> +}
That's a bit tricky. So far (i.e. for Linux host, macOS host) we are storing
the directory offset directly to the dirent struct. We are not using telldir()
as the stream might have mutated in the meantime, hence calling telldir()
might return a value that does no longer correlate to dirent in question.
Hence my idea was to use the same hack for Windows as we did for macOS, where
we simply misuse a dirent field known to be not used, on macOS that's
d_seekoff which we are misusing for that purpose.
Looking at the mingw dirent.h header though, there is not much we can choose
from. d_reclen is not used, but too short, d_ino is not used by mingw, but
currently we actually read this field in server common code to assemble a file
ID for guest. I mean it is always zero on Windows, so we could still misuse
it, but we would need to inject more hacks there. :/
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index 072cf67956..be247eeb30 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -2336,7 +2336,7 @@ static int coroutine_fn
> v9fs_do_readdir_with_stat(V9fsPDU *pdu,
> count += len;
> v9fs_stat_free();
> v9fs_path_free();
> -saved_dir_pos = qemu_dirent_off(dent);
> +saved_dir_pos = qemu_dirent_off(dent, pdu->s, >fs);
> }
>
> v9fs_readdir_unlock(>fs.dir);
> @@ -2537,7 +2537,7 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU *pdu,
> V9fsFidState *fidp,
> qid.version = 0;
> }
>
> -off = qemu_dirent_off(dent);
> +off = qemu_dirent_off(dent, pdu->s, >fs);
> v9fs_string_init();
> v9fs_string_sprintf(, "%s", dent->d_name);
>
> diff --git a/hw/9pfs/codir.c b/hw/9pfs/codir.c
> index 93ba44fb75..d40515a607 100644
> --- a/hw/9pfs/codir.c
> +++ b/hw/9pfs/codir.c
> @@ -168,7 +168,7 @@ static int do_readdir_many(V9fsPDU *pdu, V9fsFidState
> *fidp,
> }
>
> size += len;
> -saved_dir_pos = qemu_dirent_off(dent);
> +saved_dir_pos = qemu_dirent_off(dent, s, >fs);
> }
>
> /* restore (last) saved position */
>
Re: [PATCH v3 00/17] hw/9pfs: Add 9pfs support for Windows
On Monday, December 19, 2022 11:20:04 AM CET Bin Meng wrote: > At present there is no Windows support for 9p file system. > This series adds initial Windows support for 9p file system. > > 'local' file system backend driver is supported on Windows, > including open, read, write, close, rename, remove, etc. > All security models are supported. The mapped (mapped-xattr) > security model is implemented using NTFS Alternate Data Stream > (ADS) so the 9p export path shall be on an NTFS partition. > > 'synth' driver is adapted for Windows too so that we can now > run qtests on Windows for 9p related regression testing. > > Example command line to test: > > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > Base-commit: 562d4af32ec2213061f844b3838223fd7711b56a Queued patches 1..3 for now on 9p.next: https://github.com/cschoenebeck/qemu/commits/9p.next Thanks! Best regards, Christian Schoenebeck
Re: [PATCH 10/11] alsaaudio: change default playback settings
On Sunday, December 18, 2022 6:15:38 PM CET Volker Rümelin wrote:
> The currently used default playback settings in the ALSA audio
> backend are a bit unfortunate. With a few emulated audio devices,
> audio playback does not work properly. Here is a short part of
> the debug log while audio is playing (elapsed time in seconds).
Which emulated devices are these?
> audio: Elapsed since last alsa run (running): 0.046244
> audio: Elapsed since last alsa run (running): 0.023137
> audio: Elapsed since last alsa run (running): 0.023170
> audio: Elapsed since last alsa run (running): 0.023650
> audio: Elapsed since last alsa run (running): 0.060802
> audio: Elapsed since last alsa run (running): 0.031931
>
> For some audio devices the time of more than 23ms between updates
> is too long.
>
> Set the period time to 5.8ms so that the maximum time between
> two updates typically does not exceed 11ms. This roughly matches
> the 10ms period time when doing playback with the audio timer.
> After this patch the debug log looks like this.
And what about dynamically adapting that value instead of reducing period time
for everyone by default?
23ms is usually a good trade off between low latency, CPU load and potential
for audio dropouts.
> audio: Elapsed since last alsa run (running): 0.011919
> audio: Elapsed since last alsa run (running): 0.005788
> audio: Elapsed since last alsa run (running): 0.005995
> audio: Elapsed since last alsa run (running): 0.011069
> audio: Elapsed since last alsa run (running): 0.005901
> audio: Elapsed since last alsa run (running): 0.006084
>
> Signed-off-by: Volker Rümelin
> ---
> audio/alsaaudio.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
> index 5f50dfa0bf..0cc982e61f 100644
> --- a/audio/alsaaudio.c
> +++ b/audio/alsaaudio.c
> @@ -913,17 +913,14 @@ static void *alsa_audio_init(Audiodev *dev)
> alsa_init_per_direction(aopts->in);
> alsa_init_per_direction(aopts->out);
>
> -/*
> - * need to define them, as otherwise alsa produces no sound
> - * doesn't set has_* so alsa_open can identify it wasn't set by the user
> - */
> +/* don't set has_* so alsa_open can identify it wasn't set by the user */
> if (!dev->u.alsa.out->has_period_length) {
> -/* 1024 frames assuming 44100Hz */
> -dev->u.alsa.out->period_length = 1024 * 100 / 44100;
> +/* 256 frames assuming 44100Hz */
> +dev->u.alsa.out->period_length = 5805;
> }
> if (!dev->u.alsa.out->has_buffer_length) {
> /* 4096 frames assuming 44100Hz */
> -dev->u.alsa.out->buffer_length = 4096ll * 100 / 44100;
> +dev->u.alsa.out->buffer_length = 92880;
Not a big fan of magic numbers, as it makes code less readable.
> }
>
> /*
>
