| Message ID | 1502951113-4246-4-git-send-email-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 17 Aug 2017 08:25:10 +0200 Thomas Huth <thuth@redhat.com> wrote: > By using the "virtio-xxx" device name aliases instead of the > "virtio-xxx-pci" names, we can use this test on s390x, too, > to check that adding and deleting also works fine with the > virtio-ccw bus. I don't think we should leak the aliasing stuff into tests, but rather specify the transport on a per-architecture basis explicitly. (We might want to test virtio-pci on s390x in the future as well -- in addition to virtio-ccw, not replacing it.) Also, the same question as for the previous patch: Is this supposed to test virtio explicitly, or do we just want a reasonable device? > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > tests/Makefile.include | 1 + > tests/drive_del-test.c | 13 +++++++------ > 2 files changed, 8 insertions(+), 6 deletions(-)
On 17.08.2017 10:53, Cornelia Huck wrote: > On Thu, 17 Aug 2017 08:25:10 +0200 > Thomas Huth <thuth@redhat.com> wrote: > >> By using the "virtio-xxx" device name aliases instead of the >> "virtio-xxx-pci" names, we can use this test on s390x, too, >> to check that adding and deleting also works fine with the >> virtio-ccw bus. > > I don't think we should leak the aliasing stuff into tests, but rather > specify the transport on a per-architecture basis explicitly. (We might > want to test virtio-pci on s390x in the future as well -- in addition > to virtio-ccw, not replacing it.) I also remember that using virtio aliases should be avoided (e.g. we are not supposed to introduce new ones) > > Also, the same question as for the previous patch: Is this supposed to > test virtio explicitly, or do we just want a reasonable device?
On 17.08.2017 11:46, David Hildenbrand wrote: > On 17.08.2017 10:53, Cornelia Huck wrote: >> On Thu, 17 Aug 2017 08:25:10 +0200 >> Thomas Huth <thuth@redhat.com> wrote: >> >>> By using the "virtio-xxx" device name aliases instead of the >>> "virtio-xxx-pci" names, we can use this test on s390x, too, >>> to check that adding and deleting also works fine with the >>> virtio-ccw bus. >> >> I don't think we should leak the aliasing stuff into tests, but rather >> specify the transport on a per-architecture basis explicitly. (We might >> want to test virtio-pci on s390x in the future as well -- in addition >> to virtio-ccw, not replacing it.) > > I also remember that using virtio aliases should be avoided (e.g. we are > not supposed to introduce new ones) Hmm, maybe the right way is to use virtio-xxx-device and hook it up to the preferred virtio bus of the current architecture? ... I'll ponder about that a little bit ... >> >> Also, the same question as for the previous patch: Is this supposed to >> test virtio explicitly, or do we just want a reasonable device? I think this just needs a reasonable device - but since we've got the same problem with the virtio tests later in this series again, it's maybe best to fix this here in the same way, I guess. Thomas
On Thu, 17 Aug 2017 15:54:38 +0200 Thomas Huth <thuth@redhat.com> wrote: > On 17.08.2017 11:46, David Hildenbrand wrote: > > On 17.08.2017 10:53, Cornelia Huck wrote: > >> On Thu, 17 Aug 2017 08:25:10 +0200 > >> Thomas Huth <thuth@redhat.com> wrote: > >> > >>> By using the "virtio-xxx" device name aliases instead of the > >>> "virtio-xxx-pci" names, we can use this test on s390x, too, > >>> to check that adding and deleting also works fine with the > >>> virtio-ccw bus. > >> > >> I don't think we should leak the aliasing stuff into tests, but rather > >> specify the transport on a per-architecture basis explicitly. (We might > >> want to test virtio-pci on s390x in the future as well -- in addition > >> to virtio-ccw, not replacing it.) > > > > I also remember that using virtio aliases should be avoided (e.g. we are > > not supposed to introduce new ones) > > Hmm, maybe the right way is to use virtio-xxx-device and hook it up to > the preferred virtio bus of the current architecture? ... I'll ponder > about that a little bit ... What about defining a per-arch default virtio transport and pointing to that? This still allows us to explicitly test virtio-pci on s390x later. > > >> > >> Also, the same question as for the previous patch: Is this supposed to > >> test virtio explicitly, or do we just want a reasonable device? > > I think this just needs a reasonable device - but since we've got the > same problem with the virtio tests later in this series again, it's > maybe best to fix this here in the same way, I guess. Yes. virtio will probably fill the 'reasonable device' place quite well, in any case.
On 08/17/2017 02:25 AM, Thomas Huth wrote: > By using the "virtio-xxx" device name aliases instead of the > "virtio-xxx-pci" names, we can use this test on s390x, too, > to check that adding and deleting also works fine with the > virtio-ccw bus. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > tests/Makefile.include | 1 + > tests/drive_del-test.c | 13 +++++++------ > 2 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/tests/Makefile.include b/tests/Makefile.include > index 0bb18b3..ff2a551 100644 > --- a/tests/Makefile.include > +++ b/tests/Makefile.include > @@ -363,6 +363,7 @@ check-qtest-s390x-y = tests/boot-serial-test$(EXESUF) > check-qtest-s390x-$(CONFIG_SLIRP) += tests/test-netfilter$(EXESUF) > check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-mirror$(EXESUF) > check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-redirector$(EXESUF) > +check-qtest-s390x-y += tests/drive_del-test$(EXESUF) > > check-qtest-generic-y += tests/qom-test$(EXESUF) > check-qtest-generic-y += tests/test-hmp$(EXESUF) > diff --git a/tests/drive_del-test.c b/tests/drive_del-test.c > index 2175139..efceb31 100644 > --- a/tests/drive_del-test.c > +++ b/tests/drive_del-test.c > @@ -65,12 +65,12 @@ static void test_after_failed_device_add(void) > > qtest_start("-drive if=none,id=drive0"); > > - /* Make device_add fail. If this leaks the virtio-blk-pci device then a > + /* Make device_add fail. If this leaks the virtio-blk device then a > * reference to drive0 will also be held (via qdev properties). > */ > response = qmp("{'execute': 'device_add'," > " 'arguments': {" > - " 'driver': 'virtio-blk-pci'," > + " 'driver': 'virtio-blk'," > " 'drive': 'drive0'" > "}}"); > g_assert(response); > @@ -82,7 +82,7 @@ static void test_after_failed_device_add(void) > drive_del(); > > /* Try to re-add the drive. This fails with duplicate IDs if a leaked > - * virtio-blk-pci exists that holds a reference to the old drive0. > + * virtio-blk exists that holds a reference to the old drive0. > */ > drive_add(); > > @@ -93,7 +93,7 @@ static void test_drive_del_device_del(void) > { > /* Start with a drive used by a device that unplugs instantaneously */ > qtest_start("-drive if=none,id=drive0,file=null-co://,format=raw" > - " -device virtio-scsi-pci" > + " -device virtio-scsi" > " -device scsi-hd,drive=drive0,id=dev0"); > > /* > @@ -114,9 +114,10 @@ int main(int argc, char **argv) > > qtest_add_func("/drive_del/without-dev", test_drive_without_dev); > > - /* TODO I guess any arch with PCI would do */ > + /* TODO I guess any arch with a hot-pluggable virtio bus would do */ > if (!strcmp(arch, "i386") || !strcmp(arch, "x86_64") || > - !strcmp(arch, "ppc") || !strcmp(arch, "ppc64")) { > + !strcmp(arch, "ppc") || !strcmp(arch, "ppc64") || > + !strcmp(arch, "s390x")) { > qtest_add_func("/drive_del/after_failed_device_add", > test_after_failed_device_add); > qtest_add_func("/blockdev/drive_del_device_del", > I honestly can't comment on the device to be used on this test (as others have commented). Putting that aside, and given the fact that I went through the lengths of testing it on the s390x target: Tested-by: Cleber Rosa <crosa@redhat.com>
On Wed, 30 Aug 2017 17:41:01 -0400 Cleber Rosa <crosa@redhat.com> wrote: > On 08/17/2017 02:25 AM, Thomas Huth wrote: > > By using the "virtio-xxx" device name aliases instead of the > > "virtio-xxx-pci" names, we can use this test on s390x, too, > > to check that adding and deleting also works fine with the > > virtio-ccw bus. > > > > Signed-off-by: Thomas Huth <thuth@redhat.com> > > --- > > tests/Makefile.include | 1 + > > tests/drive_del-test.c | 13 +++++++------ > > 2 files changed, 8 insertions(+), 6 deletions(-) (...) > I honestly can't comment on the device to be used on this test (as > others have commented). Putting that aside, and given the fact that I > went through the lengths of testing it on the s390x target: > > Tested-by: Cleber Rosa <crosa@redhat.com> Do you want to test v2 of this patch as well? There's still time to add your tag :)
diff --git a/tests/Makefile.include b/tests/Makefile.include index 0bb18b3..ff2a551 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -363,6 +363,7 @@ check-qtest-s390x-y = tests/boot-serial-test$(EXESUF) check-qtest-s390x-$(CONFIG_SLIRP) += tests/test-netfilter$(EXESUF) check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-mirror$(EXESUF) check-qtest-s390x-$(CONFIG_POSIX) += tests/test-filter-redirector$(EXESUF) +check-qtest-s390x-y += tests/drive_del-test$(EXESUF) check-qtest-generic-y += tests/qom-test$(EXESUF) check-qtest-generic-y += tests/test-hmp$(EXESUF) diff --git a/tests/drive_del-test.c b/tests/drive_del-test.c index 2175139..efceb31 100644 --- a/tests/drive_del-test.c +++ b/tests/drive_del-test.c @@ -65,12 +65,12 @@ static void test_after_failed_device_add(void) qtest_start("-drive if=none,id=drive0"); - /* Make device_add fail. If this leaks the virtio-blk-pci device then a + /* Make device_add fail. If this leaks the virtio-blk device then a * reference to drive0 will also be held (via qdev properties). */ response = qmp("{'execute': 'device_add'," " 'arguments': {" - " 'driver': 'virtio-blk-pci'," + " 'driver': 'virtio-blk'," " 'drive': 'drive0'" "}}"); g_assert(response); @@ -82,7 +82,7 @@ static void test_after_failed_device_add(void) drive_del(); /* Try to re-add the drive. This fails with duplicate IDs if a leaked - * virtio-blk-pci exists that holds a reference to the old drive0. + * virtio-blk exists that holds a reference to the old drive0. */ drive_add(); @@ -93,7 +93,7 @@ static void test_drive_del_device_del(void) { /* Start with a drive used by a device that unplugs instantaneously */ qtest_start("-drive if=none,id=drive0,file=null-co://,format=raw" - " -device virtio-scsi-pci" + " -device virtio-scsi" " -device scsi-hd,drive=drive0,id=dev0"); /* @@ -114,9 +114,10 @@ int main(int argc, char **argv) qtest_add_func("/drive_del/without-dev", test_drive_without_dev); - /* TODO I guess any arch with PCI would do */ + /* TODO I guess any arch with a hot-pluggable virtio bus would do */ if (!strcmp(arch, "i386") || !strcmp(arch, "x86_64") || - !strcmp(arch, "ppc") || !strcmp(arch, "ppc64")) { + !strcmp(arch, "ppc") || !strcmp(arch, "ppc64") || + !strcmp(arch, "s390x")) { qtest_add_func("/drive_del/after_failed_device_add", test_after_failed_device_add); qtest_add_func("/blockdev/drive_del_device_del",
By using the "virtio-xxx" device name aliases instead of the "virtio-xxx-pci" names, we can use this test on s390x, too, to check that adding and deleting also works fine with the virtio-ccw bus. Signed-off-by: Thomas Huth <thuth@redhat.com> --- tests/Makefile.include | 1 + tests/drive_del-test.c | 13 +++++++------ 2 files changed, 8 insertions(+), 6 deletions(-)