| Message ID | 265f5d9a0fb10ce5e782455839d1baf678dbac48.1601203436.git.qemu_oss@crudebyte.com |
|---|---|
| State | New |
| Headers | show |
| Series | 9pfs: add tests using local fs driver | expand |
On 27/09/20 12:40, Christian Schoenebeck wrote:
> + qos_node_produces("virtio-9p-device-synth", "virtio-synth");
This is wrong, since it disables the generic virtio device tests (right
now there is only one in virtio-test.c).
Paolo
On 27/09/20 12:40, Christian Schoenebeck wrote: > + qos_node_consumes("virtio-9p-device-local", "virtio-bus", &opts); > + qos_node_produces("virtio-9p-device-local", "virtio-local"); This should produce "virtio", similar to what I remarked in the previous patch. > + qos_node_produces("virtio-9p-device-local", "virtio-9p-local"); > + > + /* virtio-9p-pci-local */ > + opts.extra_device_opts = local_str_addr; > + add_qpci_address(&opts, &addr); > + qos_node_create_driver_named("virtio-9p-pci-local", "virtio-9p-pci", > + virtio_9p_pci_create); > + qos_node_consumes("virtio-9p-pci-local", "pci-bus", &opts); > + qos_node_produces("virtio-9p-pci-local", "pci-device"); > + qos_node_produces("virtio-9p-pci-local", "virtio-local"); > + qos_node_produces("virtio-9p-pci-local", "virtio-9p-local"); > } The implementation in patches 1 and 2 is reasonable, but what is the advantage of this as opposed to specifying the fsdev in the edge options for the test (similar to virtio-net)? I was expecting both virtio-9p-device-synth and virtio-9p-device-local to produce virtio-9p, so that the existing tests would be reused automatically by the qos graph walk. As things stand, I don't see any reason to have separate devices for different backends. Paolo
On Montag, 28. September 2020 10:37:52 CEST Paolo Bonzini wrote: > On 27/09/20 12:40, Christian Schoenebeck wrote: > > + qos_node_consumes("virtio-9p-device-local", "virtio-bus", &opts); > > + qos_node_produces("virtio-9p-device-local", "virtio-local"); > > This should produce "virtio", similar to what I remarked in the previous > patch. You're right, I missed that implied virtio test. That should be in the end: index 599b73a9d7..1df3da18e9 100644 --- a/tests/qtest/libqos/virtio-9p.c +++ b/tests/qtest/libqos/virtio-9p.c @@ -140,8 +140,7 @@ static void *virtio_9p_get_driver(QVirtio9P *v_9p, { return v_9p; } - if (!g_strcmp0(interface, "virtio-synth") || - !g_strcmp0(interface, "virtio-local")) + if (!g_strcmp0(interface, "virtio")) { return v_9p->vdev; } @@ -248,7 +247,7 @@ static void virtio_9p_register_nodes(void) qos_node_create_driver_named("virtio-9p-device-synth", "virtio-9p- device", virtio_9p_device_create); qos_node_consumes("virtio-9p-device-synth", "virtio-bus", &opts); - qos_node_produces("virtio-9p-device-synth", "virtio-synth"); + qos_node_produces("virtio-9p-device-synth", "virtio"); qos_node_produces("virtio-9p-device-synth", "virtio-9p-synth"); /* virtio-9p-pci-synth */ @@ -258,7 +257,7 @@ static void virtio_9p_register_nodes(void) virtio_9p_pci_create); qos_node_consumes("virtio-9p-pci-synth", "pci-bus", &opts); qos_node_produces("virtio-9p-pci-synth", "pci-device"); - qos_node_produces("virtio-9p-pci-synth", "virtio-synth"); + qos_node_produces("virtio-9p-pci-synth", "virtio"); qos_node_produces("virtio-9p-pci-synth", "virtio-9p-synth"); @@ -280,7 +279,7 @@ static void virtio_9p_register_nodes(void) qos_node_create_driver_named("virtio-9p-device-local", "virtio-9p- device", virtio_9p_device_create); qos_node_consumes("virtio-9p-device-local", "virtio-bus", &opts); - qos_node_produces("virtio-9p-device-local", "virtio-local"); + qos_node_produces("virtio-9p-device-local", "virtio"); qos_node_produces("virtio-9p-device-local", "virtio-9p-local"); /* virtio-9p-pci-local */ @@ -290,7 +289,7 @@ static void virtio_9p_register_nodes(void) virtio_9p_pci_create); qos_node_consumes("virtio-9p-pci-local", "pci-bus", &opts); qos_node_produces("virtio-9p-pci-local", "pci-device"); - qos_node_produces("virtio-9p-pci-local", "virtio-local"); + qos_node_produces("virtio-9p-pci-local", "virtio"); qos_node_produces("virtio-9p-pci-local", "virtio-9p-local"); } I already tested that. Both the implied "virtio" test and the 9p 'synth' and 'local' tests work as expected then. > > + qos_node_produces("virtio-9p-device-local", "virtio-9p-local"); > > + > > + /* virtio-9p-pci-local */ > > + opts.extra_device_opts = local_str_addr; > > + add_qpci_address(&opts, &addr); > > + qos_node_create_driver_named("virtio-9p-pci-local", "virtio-9p-pci", > > + virtio_9p_pci_create); > > + qos_node_consumes("virtio-9p-pci-local", "pci-bus", &opts); > > + qos_node_produces("virtio-9p-pci-local", "pci-device"); > > + qos_node_produces("virtio-9p-pci-local", "virtio-local"); > > + qos_node_produces("virtio-9p-pci-local", "virtio-9p-local"); > > > > } > > The implementation in patches 1 and 2 is reasonable, but what is the > advantage of this as opposed to specifying the fsdev in the edge options > for the test (similar to virtio-net)? I was expecting both > virtio-9p-device-synth and virtio-9p-device-local to produce virtio-9p, > so that the existing tests would be reused automatically by the qos > graph walk. > > As things stand, I don't see any reason to have separate devices for > different backends. I thought to fix the problem at its root, by removing that singular device limitation in qos. That would also allow to cleanly separate tests suites that are not related to each other instead of having to depend on each other, taking care about other one's command line skeleton and more. Plus I just tried what you suggested as alternative: -Subproject commit 85e5d839847af54efab170f2b1331b2a6421e647 +Subproject commit 88f18909db731a627456f26d779445f84e449536 diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c index c45c706d4f..7f588a9a92 100644 --- a/tests/qtest/virtio-9p-test.c +++ b/tests/qtest/virtio-9p-test.c @@ -1035,12 +1035,22 @@ static void fs_create_dir(void *obj, void *data, QGuestAllocator *t_alloc) g_free(root_path); } +static void *modifycmdline(GString *cmd_line, void *arg) +{ + fprintf(stderr, "\n\nbefore modifycmdline(): '%s'\n\n", cmd_line->str); + g_string_append(cmd_line, "MODIFYCMDLINE "); + return arg; +} static void register_virtio_9p_test(void) { /* selects the 9pfs 'synth' filesystem driver for the respective test */ const char *synth_driver = "virtio-9p-synth"; + QOSGraphTestOptions opts = { + //.before = modifycmdline, + }; + qos_add_test("config", synth_driver, pci_config, NULL); qos_add_test("fs/version/basic", synth_driver, fs_version, NULL); qos_add_test("fs/attach/basic", synth_driver, fs_attach, NULL); @@ -1064,8 +1074,13 @@ static void register_virtio_9p_test(void) /* selects the 9pfs 'local' filesystem driver for the respective test */ const char *local_driver = "virtio-9p-local"; - qos_add_test("config", local_driver, pci_config, NULL); - qos_add_test("fs/create_dir", local_driver, fs_create_dir, NULL); + opts.before = modifycmdline, + opts.edge.extra_device_opts = "EXTRADEVICEOPTS"; + opts.edge.before_cmd_line = "BEFORECMDLINE"; + opts.edge.after_cmd_line = "AFTERCMDLINE"; + + qos_add_test("config", local_driver, pci_config, &opts); + qos_add_test("fs/create_dir", local_driver, fs_create_dir, &opts); } Output: QTEST_DEBUG=1 tests/qtest/qos-test ... /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci-local/virtio-9p- local/virtio-9p-local-tests/config: before modifycmdline(): '-M pc -fsdev local,id=fsdev1,path='/home/me/git/ qemu/build/qtest-9p-local',security_model=mapped-xattr -device virtio-9p- pci,fsdev=fsdev1,addr=04.1,mount_tag=qtest-local BEFORECMDLINE,EXTRADEVICEOPTS AFTERCMDLINE' run QEMU with: '-M pc -fsdev local,id=fsdev1,path='/home/me/git/qemu/build/ qtest-9p-local',security_model=mapped-xattr -device virtio-9p- pci,fsdev=fsdev1,addr=04.1,mount_tag=qtest-local BEFORECMDLINE,EXTRADEVICEOPTS AFTERCMDLINEMODIFYCMDLINE ' So your suggested solution is fine for appending extra arguments past the command line. However I would not be able to prepend something (easily) in front of '-device virtio-9p-pci'. So I would be forced to parse the existing command line in modifycmdline() callback and then insert the required arguments appropriately. I would not find that very clean. I mean yes, you might do hacks for making this patch set work without qos patches 1 and 2, however somewhere in future you are probably back at square one when facing this single device limitation again. So I still think this qos change (patch 1 & 2) make sense. Best regards, Christian Schoenebeck
On 28/09/20 13:56, Christian Schoenebeck wrote: >> The implementation in patches 1 and 2 is reasonable, but what is the >> advantage of this as opposed to specifying the fsdev in the edge options >> for the test (similar to virtio-net)? I was expecting both >> virtio-9p-device-synth and virtio-9p-device-local to produce virtio-9p, >> so that the existing tests would be reused automatically by the qos >> graph walk. >> >> As things stand, I don't see any reason to have separate devices for >> different backends. > > I thought to fix the problem at its root, by removing that singular device > limitation in qos. That would also allow to cleanly separate tests suites that > are not related to each other instead of having to depend on each other, > taking care about other one's command line skeleton and more. As I said, the first two patches make total sense. They would be useful for testing both packed and split virtqueues, for example. However, I think the (useful) feature is being misused here. > So your suggested solution is fine for appending extra arguments past the > command line. However I would not be able to prepend something (easily) in > front of '-device virtio-9p-pci'. > > So I would be forced to parse the existing command line in modifycmdline() > callback and then insert the required arguments appropriately. I would not > find that very clean. IIRC -fsdev can be added to the end of the command line and it still works. But if you think that is ugly, you can also use g_string_prepend. Also, looking at future plans for qgraph, adding a generic "plug/socket" mechanism to QOSGraph was an idea that we couldn't do in time for GSoC. With that model, virtio-9p would provide a "socket" of type fsdev and the tests would have to provide a "plug" of the same type. Likewise there would be sockets of type disk or network. QOSGraphEdgeOpts fits better with that plan, compared to duplicating the devices. Paolo
On Montag, 28. September 2020 14:42:48 CEST Paolo Bonzini wrote: > On 28/09/20 13:56, Christian Schoenebeck wrote: > >> The implementation in patches 1 and 2 is reasonable, but what is the > >> advantage of this as opposed to specifying the fsdev in the edge options > >> for the test (similar to virtio-net)? I was expecting both > >> virtio-9p-device-synth and virtio-9p-device-local to produce virtio-9p, > >> so that the existing tests would be reused automatically by the qos > >> graph walk. > >> > >> As things stand, I don't see any reason to have separate devices for > >> different backends. > > > > I thought to fix the problem at its root, by removing that singular device > > limitation in qos. That would also allow to cleanly separate tests suites > > that are not related to each other instead of having to depend on each > > other, taking care about other one's command line skeleton and more. > > As I said, the first two patches make total sense. They would be useful > for testing both packed and split virtqueues, for example. However, I > think the (useful) feature is being misused here. I haven't understood why my suggested mult-device use case imposes a misusage, but okay, unless I hear different opinions, I'll prepare a v2 with that (IMO hackish) CL fiddling instead in couple days or so. @Greg: If that's the way to go, then I probably change the test names, e.g. "fs/version/basic" -> "synth/version/basic" ... "fs/create_dir" -> "local/create_dir" to be able to easily distinguish 'synth' driver tests from 'local' driver tests, as they would then popup with the same device name in v2, unlike in this v1 where they have separate device names. > > So your suggested solution is fine for appending extra arguments past the > > command line. However I would not be able to prepend something (easily) in > > front of '-device virtio-9p-pci'. > > > > So I would be forced to parse the existing command line in modifycmdline() > > callback and then insert the required arguments appropriately. I would not > > find that very clean. > > IIRC -fsdev can be added to the end of the command line and it still > works. But if you think that is ugly, you can also use g_string_prepend. Yes, "-fsdev ..." and "-device ..." sequence could theoretically be flipped, qemu would accept it that is. > Also, looking at future plans for qgraph, adding a generic "plug/socket" > mechanism to QOSGraph was an idea that we couldn't do in time for GSoC. > With that model, virtio-9p would provide a "socket" of type fsdev and > the tests would have to provide a "plug" of the same type. Likewise > there would be sockets of type disk or network. QOSGraphEdgeOpts fits > better with that plan, compared to duplicating the devices. Sounds like that would require huge changes for all existing qtests on initial thought at least. I find the suggested multi-device approach much simpler, as it does not require changes to existing tests, nor people having to get used to a new qtest model. Best regards, Christian Schoenebeck
On 28/09/20 15:35, Christian Schoenebeck wrote: >> As I said, the first two patches make total sense. They would be useful >> for testing both packed and split virtqueues, for example. However, I >> think the (useful) feature is being misused here. > > I haven't understood why my suggested mult-device use case imposes a misusage, > but okay, unless I hear different opinions, I'll prepare a v2 with that (IMO > hackish) CL fiddling instead in couple days or so. Because in my opinion the backend in use is a property of the test rather than a property of the device. > @Greg: If that's the way to go, then I probably change the test names, e.g. > > "fs/version/basic" -> "synth/version/basic" > ... > "fs/create_dir" -> "local/create_dir" > > to be able to easily distinguish 'synth' driver tests from 'local' driver > tests, as they would then popup with the same device name in v2, unlike in > this v1 where they have separate device names. Right. >> Also, looking at future plans for qgraph, adding a generic "plug/socket" >> mechanism to QOSGraph was an idea that we couldn't do in time for GSoC. >> With that model, virtio-9p would provide a "socket" of type fsdev and >> the tests would have to provide a "plug" of the same type. Likewise >> there would be sockets of type disk or network. QOSGraphEdgeOpts fits >> better with that plan, compared to duplicating the devices. > > Sounds like that would require huge changes for all existing qtests on initial > thought at least. Not huge, but yeah many tests would require changes. Paolo
On Montag, 28. September 2020 18:38:00 CEST Paolo Bonzini wrote: > On 28/09/20 15:35, Christian Schoenebeck wrote: > >> As I said, the first two patches make total sense. They would be useful > >> for testing both packed and split virtqueues, for example. However, I > >> think the (useful) feature is being misused here. > > > > I haven't understood why my suggested mult-device use case imposes a > > misusage, but okay, unless I hear different opinions, I'll prepare a v2 > > with that (IMO hackish) CL fiddling instead in couple days or so. > > Because in my opinion the backend in use is a property of the test > rather than a property of the device. Paolo, I'm back at square one after changing to single-device model as you suggested: GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/pci- device/pci-device-tests/nop Run QEMU with: '-M pc -device virtio-9p-pci' (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/ qtest-18032.sock -qtest-log /dev/null -chardev socket,path=/tmp/ qtest-18032.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc -device virtio-9p-pci -accel qtest) qemu-system-x86_64: -device virtio-9p-pci: 9pfs device couldn't find fsdev with the id = NULL Broken pipe This fundamental virtio-9p-pci test obviously needs a complete 9p command line, that is either a 'synth' driver one, or a 'local' one. But simply either picking one or another is inappropriate here. This test should run once for 'synth' and once for 'local'. Still not convinced that the multi-device route is the way to go? Best regards, Christian Schoenebeck
On 01/10/20 13:34, Christian Schoenebeck wrote: > Paolo, I'm back at square one after changing to single-device model as you > suggested: > > GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/pci- > device/pci-device-tests/nop > Run QEMU with: '-M pc -device virtio-9p-pci' > (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/ > qtest-18032.sock -qtest-log /dev/null -chardev socket,path=/tmp/ > qtest-18032.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc > -device virtio-9p-pci -accel qtest) > qemu-system-x86_64: -device virtio-9p-pci: 9pfs device couldn't find fsdev > with the id = NULL > Broken pipe > > This fundamental virtio-9p-pci test obviously needs a complete 9p command > line, that is either a 'synth' driver one, or a 'local' one. But simply either > picking one or another is inappropriate here. This test should run once for > 'synth' and once for 'local'. You're right, this is in fact also a problem for virtio-blk and virtio-net: /* FIXME: every test using these two nodes needs to setup a * -drive,id=drive0 otherwise QEMU is not going to start. * Therefore, we do not include "produces" edge for virtio * and pci-device yet. */ /* FIXME: every test using these nodes needs to setup a * -netdev socket,id=hs0 otherwise QEMU is not going to start. * Therefore, we do not include "produces" edge for virtio * and pci-device yet. */ I still think we should do it like this, because it's closer to the way that libqos will work long term. Paolo
On Donnerstag, 1. Oktober 2020 13:56:42 CEST Paolo Bonzini wrote: > On 01/10/20 13:34, Christian Schoenebeck wrote: > > Paolo, I'm back at square one after changing to single-device model as you > > suggested: > > > > GTest: run: > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/pci- > > device/pci-device-tests/nop > > Run QEMU with: '-M pc -device virtio-9p-pci' > > (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest > > unix:/tmp/ qtest-18032.sock -qtest-log /dev/null -chardev > > socket,path=/tmp/ > > qtest-18032.qmp,id=char0 -mon chardev=char0,mode=control -display none -M > > pc -device virtio-9p-pci -accel qtest) > > qemu-system-x86_64: -device virtio-9p-pci: 9pfs device couldn't find fsdev > > with the id = NULL > > Broken pipe > > > > This fundamental virtio-9p-pci test obviously needs a complete 9p command > > line, that is either a 'synth' driver one, or a 'local' one. But simply > > either picking one or another is inappropriate here. This test should run > > once for 'synth' and once for 'local'. > > You're right, this is in fact also a problem for virtio-blk and virtio-net: > > /* FIXME: every test using these two nodes needs to setup a > * -drive,id=drive0 otherwise QEMU is not going to start. > * Therefore, we do not include "produces" edge for virtio > * and pci-device yet. > */ > > /* FIXME: every test using these nodes needs to setup a > * -netdev socket,id=hs0 otherwise QEMU is not going to start. > * Therefore, we do not include "produces" edge for virtio > * and pci-device yet. > */ > > I still think we should do it like this, because it's closer to the way > that libqos will work long term. Could you please elaborate why that long term plan bites with the working solution I provided? [patches 1 and 2] I mean, the solution I suggested is simple and working. I don't see a reason why that should be incompatible with future plans. IMO it makes sense to use the suggested solution instead of dropping tests just because of potential qos changes somewhere in far future that might happen or not. It is still a qos design limitation after all that must be addressed sooner or later. So also a future qos design must deal with this in some way. Best regards, Christian Schoenebeck
On 01/10/20 14:15, Christian Schoenebeck wrote: > On Donnerstag, 1. Oktober 2020 13:56:42 CEST Paolo Bonzini wrote: >> On 01/10/20 13:34, Christian Schoenebeck wrote: >>> Paolo, I'm back at square one after changing to single-device model as you >>> suggested: >>> >>> GTest: run: >>> /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/pci- >>> device/pci-device-tests/nop >>> Run QEMU with: '-M pc -device virtio-9p-pci' >>> (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest >>> unix:/tmp/ qtest-18032.sock -qtest-log /dev/null -chardev >>> socket,path=/tmp/ >>> qtest-18032.qmp,id=char0 -mon chardev=char0,mode=control -display none -M >>> pc -device virtio-9p-pci -accel qtest) >>> qemu-system-x86_64: -device virtio-9p-pci: 9pfs device couldn't find fsdev >>> with the id = NULL >>> Broken pipe >>> >>> This fundamental virtio-9p-pci test obviously needs a complete 9p command >>> line, that is either a 'synth' driver one, or a 'local' one. But simply >>> either picking one or another is inappropriate here. This test should run >>> once for 'synth' and once for 'local'. >> >> You're right, this is in fact also a problem for virtio-blk and virtio-net: >> >> /* FIXME: every test using these two nodes needs to setup a >> * -drive,id=drive0 otherwise QEMU is not going to start. >> * Therefore, we do not include "produces" edge for virtio >> * and pci-device yet. >> */ >> >> /* FIXME: every test using these nodes needs to setup a >> * -netdev socket,id=hs0 otherwise QEMU is not going to start. >> * Therefore, we do not include "produces" edge for virtio >> * and pci-device yet. >> */ >> >> I still think we should do it like this, because it's closer to the way >> that libqos will work long term. > > Could you please elaborate why that long term plan bites with the working > solution I provided? [patches 1 and 2] Because the long term plan is to have a socket/plug mechanism for backends where the device can provide a default backend to plug. The suggested solution is all good for *a different use case*, namely to test the same device with different options. It is just wrong for the purpose of selecting a frontend. It occurred to me that you could also add a default backend to the command line with "-fsdev" (in the libqos driver), and use -set in the test to override it. This is ugly (-set is ugly!) but it would let you keep the tests, so it would probably be the best solution. Paolo
On Donnerstag, 1. Oktober 2020 16:04:39 CEST Paolo Bonzini wrote: > >> You're right, this is in fact also a problem for virtio-blk and virtio- net: > >> /* FIXME: every test using these two nodes needs to setup a > >> > >> * -drive,id=drive0 otherwise QEMU is not going to start. > >> * Therefore, we do not include "produces" edge for virtio > >> * and pci-device yet. > >> > >> */ > >> > >> /* FIXME: every test using these nodes needs to setup a > >> > >> * -netdev socket,id=hs0 otherwise QEMU is not going to start. > >> * Therefore, we do not include "produces" edge for virtio > >> * and pci-device yet. > >> */ > >> > >> I still think we should do it like this, because it's closer to the way > >> that libqos will work long term. > > > > Could you please elaborate why that long term plan bites with the working > > solution I provided? [patches 1 and 2] > > Because the long term plan is to have a socket/plug mechanism for > backends where the device can provide a default backend to plug. Ok, obviously I don't know the details of that future socket/plug plan, but what I could also imagine for the long-term: allowing to optionally define 'config' nodes as subnodes of devices. Maybe that's similar to what you had in mind with that socket/plug model. > The suggested solution is all good for *a different use case*, namely to > test the same device with different options. It is just wrong for the > purpose of selecting a frontend. > > It occurred to me that you could also add a default backend to the > command line with "-fsdev" (in the libqos driver), and use -set in the > test to override it. This is ugly (-set is ugly!) but it would let you > keep the tests, so it would probably be the best solution. Ok, I'll have a look at that '*-set' alternative tomorrow. But on doubt: I will simply disable those the implied pci and virtio tests for the time being. I need the 'local' backend tests and have to move on; they are of much more value than those 2 implied pci and virtio tests. Best regards, Christian Schoenebeck
diff --git a/tests/qtest/libqos/virtio-9p.c b/tests/qtest/libqos/virtio-9p.c index 9f099737f9..1bda5403ff 100644 --- a/tests/qtest/libqos/virtio-9p.c +++ b/tests/qtest/libqos/virtio-9p.c @@ -62,10 +62,10 @@ static void virtio_9p_device_start_hw(QOSGraphObject *obj) static void *virtio_9p_get_driver(QVirtio9P *v_9p, const char *interface) { - if (!g_strcmp0(interface, "virtio-9p")) { + if (!g_strcmp0(interface, "virtio-9p-synth")) { return v_9p; } - if (!g_strcmp0(interface, "virtio")) { + if (!g_strcmp0(interface, "virtio-synth")) { return v_9p->vdev; } @@ -159,22 +159,23 @@ static void virtio_9p_register_nodes(void) .before_cmd_line = "-fsdev synth,id=fsdev0", }; - /* virtio-9p-device */ + /* virtio-9p-device-synth */ opts.extra_device_opts = str_simple, - qos_node_create_driver("virtio-9p-device", virtio_9p_device_create); - qos_node_consumes("virtio-9p-device", "virtio-bus", &opts); - qos_node_produces("virtio-9p-device", "virtio"); - qos_node_produces("virtio-9p-device", "virtio-9p"); + qos_node_create_driver_named("virtio-9p-device-synth", "virtio-9p-device", + virtio_9p_device_create); + qos_node_consumes("virtio-9p-device-synth", "virtio-bus", &opts); + qos_node_produces("virtio-9p-device-synth", "virtio-synth"); + qos_node_produces("virtio-9p-device-synth", "virtio-9p-synth"); - /* virtio-9p-pci */ + /* virtio-9p-pci-synth */ opts.extra_device_opts = str_addr; add_qpci_address(&opts, &addr); - qos_node_create_driver("virtio-9p-pci", virtio_9p_pci_create); - qos_node_consumes("virtio-9p-pci", "pci-bus", &opts); - qos_node_produces("virtio-9p-pci", "pci-device"); - qos_node_produces("virtio-9p-pci", "virtio"); - qos_node_produces("virtio-9p-pci", "virtio-9p"); - + qos_node_create_driver_named("virtio-9p-pci-synth", "virtio-9p-pci", + virtio_9p_pci_create); + qos_node_consumes("virtio-9p-pci-synth", "pci-bus", &opts); + qos_node_produces("virtio-9p-pci-synth", "pci-device"); + qos_node_produces("virtio-9p-pci-synth", "virtio-synth"); + qos_node_produces("virtio-9p-pci-synth", "virtio-9p-synth"); } libqos_init(virtio_9p_register_nodes); diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c index f7505396f3..d46d675309 100644 --- a/tests/qtest/virtio-9p-test.c +++ b/tests/qtest/virtio-9p-test.c @@ -897,27 +897,27 @@ static void fs_readdir_split_512(void *obj, void *data, static void register_virtio_9p_test(void) { - qos_add_test("config", "virtio-9p", pci_config, NULL); - qos_add_test("fs/version/basic", "virtio-9p", fs_version, NULL); - qos_add_test("fs/attach/basic", "virtio-9p", fs_attach, NULL); - qos_add_test("fs/walk/basic", "virtio-9p", fs_walk, NULL); - qos_add_test("fs/walk/no_slash", "virtio-9p", fs_walk_no_slash, + /* selects the 9pfs 'synth' filesystem driver for the respective test */ + const char *synth_driver = "virtio-9p-synth"; + + qos_add_test("config", synth_driver, pci_config, NULL); + qos_add_test("fs/version/basic", synth_driver, fs_version, NULL); + qos_add_test("fs/attach/basic", synth_driver, fs_attach, NULL); + qos_add_test("fs/walk/basic", synth_driver, fs_walk, NULL); + qos_add_test("fs/walk/no_slash", synth_driver, fs_walk_no_slash, NULL); + qos_add_test("fs/walk/dotdot_from_root", synth_driver, fs_walk_dotdot, NULL); - qos_add_test("fs/walk/dotdot_from_root", "virtio-9p", - fs_walk_dotdot, NULL); - qos_add_test("fs/lopen/basic", "virtio-9p", fs_lopen, NULL); - qos_add_test("fs/write/basic", "virtio-9p", fs_write, NULL); - qos_add_test("fs/flush/success", "virtio-9p", fs_flush_success, + qos_add_test("fs/lopen/basic", synth_driver, fs_lopen, NULL); + qos_add_test("fs/write/basic", synth_driver, fs_write, NULL); + qos_add_test("fs/flush/success", synth_driver, fs_flush_success, NULL); + qos_add_test("fs/flush/ignored", synth_driver, fs_flush_ignored, NULL); + qos_add_test("fs/readdir/basic", synth_driver, fs_readdir, NULL); + qos_add_test("fs/readdir/split_512", synth_driver, fs_readdir_split_512, NULL); - qos_add_test("fs/flush/ignored", "virtio-9p", fs_flush_ignored, + qos_add_test("fs/readdir/split_256", synth_driver, fs_readdir_split_256, + NULL); + qos_add_test("fs/readdir/split_128", synth_driver, fs_readdir_split_128, NULL); - qos_add_test("fs/readdir/basic", "virtio-9p", fs_readdir, NULL); - qos_add_test("fs/readdir/split_512", "virtio-9p", - fs_readdir_split_512, NULL); - qos_add_test("fs/readdir/split_256", "virtio-9p", - fs_readdir_split_256, NULL); - qos_add_test("fs/readdir/split_128", "virtio-9p", - fs_readdir_split_128, NULL); } libqos_init(register_virtio_9p_test);
Rename all 9pfs tests and devices they create for running their tests from 'virtio*' -> 'virtio*-synth'. In order for the tests still to work after this renaming, use the newly added function qos_node_create_driver_named() instead of qos_node_create_driver(). That new function allows to assign a name to a device that differs from the actual QEMU driver it's using. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> --- tests/qtest/libqos/virtio-9p.c | 29 ++++++++++++++------------- tests/qtest/virtio-9p-test.c | 36 +++++++++++++++++----------------- 2 files changed, 33 insertions(+), 32 deletions(-)