Message ID | 1389360699-9183-2-git-send-email-armbru@redhat.com |
---|---|
State | New |
Headers | show |
armbru@redhat.com writes: > From: Markus Armbruster <armbru@redhat.com> > > Get available machines via QMP instead of hardcoding a list that's > perpetually out of date. > > A few machines don't work out of the box: > > * Several ppcemb machines can't initialize their CPU. Alex, any chance these could be fixed? ppce500 Unable to initialize CPU! mac99 Unable to find PowerPC CPU definition g3beige Unable to find PowerPC CPU definition mpc8544ds Unable to initialize CPU! ref405ep Unable to find PowerPC 405ep CPU definition taihu Unable to find PowerPC 405ep CPU definition prep le to find PowerPC CPU definition [...]
On 10.01.2014, at 14:42, Markus Armbruster <armbru@redhat.com> wrote: > armbru@redhat.com writes: > >> From: Markus Armbruster <armbru@redhat.com> >> >> Get available machines via QMP instead of hardcoding a list that's >> perpetually out of date. >> >> A few machines don't work out of the box: >> >> * Several ppcemb machines can't initialize their CPU. > > Alex, any chance these could be fixed? > > ppce500 Unable to initialize CPU! > mac99 Unable to find PowerPC CPU definition > g3beige Unable to find PowerPC CPU definition > mpc8544ds Unable to initialize CPU! > ref405ep Unable to find PowerPC 405ep CPU definition > taihu Unable to find PowerPC 405ep CPU definition > prep le to find PowerPC CPU definition The ppcemb flavor should only ever work with -M bamboo. If you have a good idea how to express that through #ifdef's I'm more than happy to hear about it :). Alex
Am 10.01.2014 14:42, schrieb Markus Armbruster: > armbru@redhat.com writes: > >> From: Markus Armbruster <armbru@redhat.com> >> >> Get available machines via QMP instead of hardcoding a list that's >> perpetually out of date. >> >> A few machines don't work out of the box: >> >> * Several ppcemb machines can't initialize their CPU. That's why we had the rather complicated ppc machine grouping: http://git.qemu.org/?p=qemu.git;a=commit;h=7c41f2177e280dec1f1d4c5cd72333c5c55943af > Alex, any chance these could be fixed? > > ppce500 Unable to initialize CPU! > mac99 Unable to find PowerPC CPU definition > g3beige Unable to find PowerPC CPU definition > mpc8544ds Unable to initialize CPU! => shouldn't be compiled into ppcemb easiest: add #ifndef TARGET_PPCEMB in machine registration functions better: use CONFIG_* in Makefile.objs and ppcemb-softmmu.mak > ref405ep Unable to find PowerPC 405ep CPU definition > taihu Unable to find PowerPC 405ep CPU definition http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg03697.html As per Alex, these should be made to work. How??? -> target-ppc/translate_init.c > prep le to find PowerPC CPU definition => shouldn't be compiled in, will look into this one as maintainer > > [...] Andreas
Am 10.01.2014 15:17, schrieb Andreas Färber: > Am 10.01.2014 14:42, schrieb Markus Armbruster: >> armbru@redhat.com writes: >> >>> From: Markus Armbruster <armbru@redhat.com> >>> >>> Get available machines via QMP instead of hardcoding a list that's >>> perpetually out of date. >>> >>> A few machines don't work out of the box: >>> >>> * Several ppcemb machines can't initialize their CPU. > > That's why we had the rather complicated ppc machine grouping: > > http://git.qemu.org/?p=qemu.git;a=commit;h=7c41f2177e280dec1f1d4c5cd72333c5c55943af > >> Alex, any chance these could be fixed? >> >> ppce500 Unable to initialize CPU! >> mac99 Unable to find PowerPC CPU definition >> g3beige Unable to find PowerPC CPU definition >> mpc8544ds Unable to initialize CPU! > > => shouldn't be compiled into ppcemb Still TBD, Alex has not volunteered :( > > easiest: add #ifndef TARGET_PPCEMB in machine registration functions > better: use CONFIG_* in Makefile.objs and ppcemb-softmmu.mak > >> ref405ep Unable to find PowerPC 405ep CPU definition >> taihu Unable to find PowerPC 405ep CPU definition > > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg03697.html > > As per Alex, these should be made to work. How??? Unanswered! > -> target-ppc/translate_init.c > >> prep le to find PowerPC CPU definition > > => shouldn't be compiled in, will look into this one as maintainer Done: http://patchwork.ozlabs.org/patch/313620/ TBD: Macs and ppc405 As indicated on IRC, I want to get those fixed before transforming one notation to another. Especially this patch is throwing them all in one bucket dropping any annotation hinting at why and how it may be fixed. Andreas
armbru@redhat.com writes: > From: Markus Armbruster <armbru@redhat.com> > > Get available machines via QMP instead of hardcoding a list that's > perpetually out of date. > > A few machines don't work out of the box: > > * Several ppcemb machines can't initialize their CPU. > > * Xen machines can work only when running under the Xen hypervisor. > > Blacklist them. On IRC, Andreas asked for a list of machines the test fails to cover before my patch. Added by the patch: /arm/qom/virt: OK /i386/qom/pc-0.10: OK /i386/qom/pc-0.11: OK /i386/qom/pc-0.12: OK /i386/qom/pc-0.13: OK /i386/qom/pc-0.14: OK /i386/qom/pc-0.15: OK /i386/qom/pc-1.0: OK /i386/qom/pc-1.1: OK /i386/qom/pc-1.2: OK /i386/qom/pc-1.3: OK /i386/qom/pc-i440fx-1.4: OK /i386/qom/pc-i440fx-1.5: OK /i386/qom/pc-i440fx-1.6: OK /i386/qom/pc-i440fx-1.7: OK /i386/qom/pc-q35-1.4: OK /i386/qom/pc-q35-1.5: OK /i386/qom/pc-q35-1.6: OK /i386/qom/pc-q35-1.7: OK /sparc/qom/Voyager: OK /x86_64/qom/pc-0.10: OK /x86_64/qom/pc-0.11: OK /x86_64/qom/pc-0.12: OK /x86_64/qom/pc-0.13: OK /x86_64/qom/pc-0.14: OK /x86_64/qom/pc-0.15: OK /x86_64/qom/pc-1.0: OK /x86_64/qom/pc-1.1: OK /x86_64/qom/pc-1.2: OK /x86_64/qom/pc-1.3: OK /x86_64/qom/pc-i440fx-1.4: OK /x86_64/qom/pc-i440fx-1.5: OK /x86_64/qom/pc-i440fx-1.6: OK /x86_64/qom/pc-i440fx-1.7: OK /x86_64/qom/pc-q35-1.4: OK /x86_64/qom/pc-q35-1.5: OK /x86_64/qom/pc-q35-1.6: OK /x86_64/qom/pc-q35-1.7: OK Ran under its real name rather than its alias: /i386/qom/pc-i440fx-2.0: OK /i386/qom/pc-q35-2.0: OK /x86_64/qom/pc-i440fx-2.0: OK /x86_64/qom/pc-q35-2.0: OK
On 23 January 2014 14:41, Andreas Färber <afaerber@suse.de> wrote: > As indicated on IRC, I want to get those fixed before transforming one > notation to another. Especially this patch is throwing them all in one > bucket dropping any annotation hinting at why and how it may be fixed. Would you accept a version where every item on the black list had a comment describing why it was there and what the required fix is? I think this patch is a vast improvement on the current whitelist setup and we shouldn't block it waiting for every obscure target to get fixed. thanks -- PMM
Am 23.01.2014 16:40, schrieb Peter Maydell: > On 23 January 2014 14:41, Andreas Färber <afaerber@suse.de> wrote: >> As indicated on IRC, I want to get those fixed before transforming one >> notation to another. Especially this patch is throwing them all in one >> bucket dropping any annotation hinting at why and how it may be fixed. > > Would you accept a version where every item on the black list > had a comment describing why it was there and what the required > fix is? I think this patch is a vast improvement on the current > whitelist setup and we shouldn't block it waiting for every > obscure target to get fixed. Like I said, I have already sent a patch for PReP, which Alex has queued. The intent is to rebase this series on it, obsoleting part of the blacklist. I have also now sent out a patch covering Macs and e500. So the answer is, I will accept a patch that has a reasonably small blacklist. The time you're arguing about this on IRC and here you could've spent actually helping investigate and fixing this... Even if I queued it and sent a pull, it would take days or weeks to go in, so I really don't see why I should rush this series into my tree. Andreas
On 23 January 2014 15:45, Andreas Färber <afaerber@suse.de> wrote: > I have also now sent out a patch covering Macs and e500. So the answer > is, I will accept a patch that has a reasonably small blacklist. The > time you're arguing about this on IRC and here you could've spent > actually helping investigate and fixing this... Even if I queued it and > sent a pull, it would take days or weeks to go in, so I really don't see > why I should rush this series into my tree. That's cool. I was only arguing because I was under the mistaken impression you didn't want to take this patch at all until everything was fixed. I'm working on a patch which improves tests/Makefile so it autogenerates the list of sysemu-supporting targets and adds qom-test to the test list for all of them, so we don't even have to update the makefile when we add new architectures. thanks -- PMM
Am 23.01.2014 17:00, schrieb Peter Maydell: > On 23 January 2014 15:45, Andreas Färber <afaerber@suse.de> wrote: >> I have also now sent out a patch covering Macs and e500. So the answer >> is, I will accept a patch that has a reasonably small blacklist. The >> time you're arguing about this on IRC and here you could've spent >> actually helping investigate and fixing this... Even if I queued it and >> sent a pull, it would take days or weeks to go in, so I really don't see >> why I should rush this series into my tree. > > That's cool. I was only arguing because I was under the mistaken > impression you didn't want to take this patch at all until > everything was fixed. Well, maybe "everything" is the misunderstanding here? The following 3 patches address all my requests, ... http://patchwork.ozlabs.org/patch/313620/ http://patchwork.ozlabs.org/patch/313642/ http://patchwork.ozlabs.org/patch/313659/ ... and the first two would've been really easy to contribute for anyone who cared about a proper white- or blacklist: introducing a new define and taking away devices as long as everything still passes make check. More cleanup would be possible (i8257) if we took away audio, too (sb16 etc.). ppc40x was more involved, but still less than an hour to figure out. Now waiting on Alex to review and send a pull or to ack for me to queue. Having had to write these fixes myself now, maybe one of you two can contribute the real QOM test of recursively walking properties via qom-list and qom-get? :) > I'm working on a patch which improves tests/Makefile so it > autogenerates the list of sysemu-supporting targets and > adds qom-test to the test list for all of them, so we don't > even have to update the makefile when we add new architectures. Appreciate it, Andreas
Am 10.01.2014 14:31, schrieb armbru@redhat.com: > From: Markus Armbruster <armbru@redhat.com> > > Get available machines via QMP instead of hardcoding a list that's > perpetually out of date. > > A few machines don't work out of the box: > > * Several ppcemb machines can't initialize their CPU. > > * Xen machines can work only when running under the Xen hypervisor. > > Blacklist them. > > Signed-off-by: Markus Armbruster <armbru@redhat.com> I've rebased this, queing it without the ppcemb blacklist (and adjusted commit message) while waiting for Alex' ppc pull. Thanks a lot, Andreas
Andreas Färber <afaerber@suse.de> writes: > Am 10.01.2014 14:31, schrieb armbru@redhat.com: >> From: Markus Armbruster <armbru@redhat.com> >> >> Get available machines via QMP instead of hardcoding a list that's >> perpetually out of date. >> >> A few machines don't work out of the box: >> >> * Several ppcemb machines can't initialize their CPU. >> >> * Xen machines can work only when running under the Xen hypervisor. >> >> Blacklist them. >> >> Signed-off-by: Markus Armbruster <armbru@redhat.com> > > I've rebased this, queing it without the ppcemb blacklist (and adjusted > commit message) while waiting for Alex' ppc pull. > > Thanks a lot, Where's your tree again? I'd like to have a look.
Andreas Färber <afaerber@suse.de> writes: > Am 10.01.2014 14:31, schrieb armbru@redhat.com: >> From: Markus Armbruster <armbru@redhat.com> >> >> Get available machines via QMP instead of hardcoding a list that's >> perpetually out of date. >> >> A few machines don't work out of the box: >> >> * Several ppcemb machines can't initialize their CPU. >> >> * Xen machines can work only when running under the Xen hypervisor. >> >> Blacklist them. >> >> Signed-off-by: Markus Armbruster <armbru@redhat.com> > > I've rebased this, queing it without the ppcemb blacklist (and adjusted > commit message) while waiting for Alex' ppc pull. Your rebase is fine. Thanks!
Stefano, Am 10.01.2014 14:31, schrieb armbru@redhat.com: > From: Markus Armbruster <armbru@redhat.com> > > Get available machines via QMP instead of hardcoding a list that's > perpetually out of date. > > A few machines don't work out of the box: [...] > * Xen machines can work only when running under the Xen hypervisor. > > Blacklist them. > > Signed-off-by: Markus Armbruster <armbru@redhat.com> > --- > tests/qom-test.c | 283 +++++++++++++------------------------------------------ > 1 file changed, 66 insertions(+), 217 deletions(-) > > diff --git a/tests/qom-test.c b/tests/qom-test.c > index 5e5af7a..3cbd480 100644 > --- a/tests/qom-test.c > +++ b/tests/qom-test.c > @@ -11,6 +11,42 @@ > #include <glib.h> > #include <string.h> > #include "qemu/osdep.h" > +#include "qapi/qmp/types.h" > + [...] > + > +static const char *blacklist_x86[] = { > + "xenfv", "xenpv", NULL > +}; [snip] I'm wondering if we could enable these machines conditional to CONFIG_XEN, so I've tried commenting out the two since I have the Xen libraries installed, but I get this: $ make check-qtest V=1 [...] /i386/qom/xenpv: xen be core: can't connect to xenstored xen_init_pv: xen backend core setup failed Broken pipe FAIL [...] /i386/qom/xenfv: Broken pipe FAIL [...] Have you checked whether you can make some code dependent on !qtest_enabled() to make your machines testable by non-Xen users? Regards, Andreas
On Wed, 5 Feb 2014, Andreas Färber wrote: > Stefano, > > Am 10.01.2014 14:31, schrieb armbru@redhat.com: > > From: Markus Armbruster <armbru@redhat.com> > > > > Get available machines via QMP instead of hardcoding a list that's > > perpetually out of date. > > > > A few machines don't work out of the box: > [...] > > * Xen machines can work only when running under the Xen hypervisor. > > > > Blacklist them. > > > > Signed-off-by: Markus Armbruster <armbru@redhat.com> > > --- > > tests/qom-test.c | 283 +++++++++++++------------------------------------------ > > 1 file changed, 66 insertions(+), 217 deletions(-) > > > > diff --git a/tests/qom-test.c b/tests/qom-test.c > > index 5e5af7a..3cbd480 100644 > > --- a/tests/qom-test.c > > +++ b/tests/qom-test.c > > @@ -11,6 +11,42 @@ > > #include <glib.h> > > #include <string.h> > > #include "qemu/osdep.h" > > +#include "qapi/qmp/types.h" > > + > [...] > > + > > +static const char *blacklist_x86[] = { > > + "xenfv", "xenpv", NULL > > +}; > [snip] > > I'm wondering if we could enable these machines conditional to > CONFIG_XEN, so I've tried commenting out the two since I have the Xen > libraries installed, but I get this: > > $ make check-qtest V=1 > [...] > /i386/qom/xenpv: > xen be core: can't connect to xenstored > xen_init_pv: xen backend core setup failed > Broken pipe > FAIL > [...] > /i386/qom/xenfv: > Broken pipe > FAIL > [...] > > Have you checked whether you can make some code dependent on > !qtest_enabled() to make your machines testable by non-Xen users? No, I haven't. I think that there is no way we could make xenpv work as it is too dependent on xenstore. However we should be able to make xenfv and pc,accel=xen work.
diff --git a/tests/qom-test.c b/tests/qom-test.c index 5e5af7a..3cbd480 100644 --- a/tests/qom-test.c +++ b/tests/qom-test.c @@ -11,6 +11,42 @@ #include <glib.h> #include <string.h> #include "qemu/osdep.h" +#include "qapi/qmp/types.h" + +static const char *blacklist_ppcemb[] = { + "g3beige", "mac99", "mpc8544ds", "ppce500", "prep", "ref405ep", "taihu", + NULL +}; + +static const char *blacklist_x86[] = { + "xenfv", "xenpv", NULL +}; + +static const struct { + const char *arch; + const char **machine; +} blacklists[] = { + { "i386", blacklist_x86 }, + { "ppcemb", blacklist_ppcemb }, + { "x86_64", blacklist_x86 }, +}; + +static bool is_blacklisted(const char *arch, const char *mach) +{ + int i; + const char **p; + + for (i = 0; i < ARRAY_SIZE(blacklists); i++) { + if (!strcmp(blacklists[i].arch, arch)) { + for (p = blacklists[i].machine; *p; p++) { + if (!strcmp(*p, mach)) { + return true; + } + } + } + } + return false; +} static void test_nop(gconstpointer data) { @@ -26,230 +62,43 @@ static void test_nop(gconstpointer data) g_free(args); } -static const char *x86_machines[] = { - "pc", - "isapc", - "q35", -}; - -static const char *alpha_machines[] = { - "clipper", -}; - -static const char *arm_machines[] = { - "integratorcp", - "versatilepb", - "versatileab", - "lm3s811evb", - "lm3s6965evb", - "collie", - "akita", - "spitz", - "borzoi", - "terrier", - "tosa", - "cheetah", - "sx1-v1", - "sx1", - "realview-eb", - "realview-eb-mpcore", - "realview-pb-a8", - "realview-pbx-a9", - "musicpal", - "mainstone", - "connex", - "verdex", - "z2", - "n800", - "n810", - "kzm", - "vexpress-a9", - "vexpress-a15", - "smdkc210", - "nuri", - "xilinx-zynq-a9", - "highbank", - "midway", - "canon-a1100", - "cubieboard", -}; - -static const char *cris_machines[] = { - "axis-dev88", -}; - -static const char *lm32_machines[] = { - "lm32-evr", - "lm32-uclinux", - "milkymist", -}; - -static const char *m68k_machines[] = { - "mcf5208evb", - "an5206", - "dummy", -}; - -static const char *microblaze_machines[] = { - "petalogix-ml605", - "petalogix-s3adsp1800", -}; - -static const char *mips_machines[] = { - "malta", - "magnum", - "mips", - "mipssim", - "pica61", -}; - -static const char *moxie_machines[] = { - "moxiesim", -}; - -static const char *openrisc_machines[] = { - "or32-sim", -}; - -static const char *ppc_machines[] = { - "g3beige", - "mac99", - "prep", - "mpc8544ds", - "ppce500", -}; - -static const char *ppc64_machines[] = { - "pseries", -}; - -static const char *ppc405_machines[] = { - "ref405ep", - "taihu", -}; - -static const char *ppc440_machines[] = { - "bamboo", - "virtex-ml507", -}; - -static const char *s390_machines[] = { - "s390-virtio", - "s390-ccw-virtio", -}; - -static const char *superh_machines[] = { - "r2d", - "shix", -}; - -static const char *sparc_machines[] = { - "SS-4", - "SS-5", - "SS-10", - "SS-20", - "SS-600MP", - "LX", - "SPARCClassic", - "SPARCbook", - "leon3_generic", -}; - -static const char *sparc64_machines[] = { - "sun4u", - "sun4v", - "Niagara", -}; - -static const char *unicore32_machines[] = { - "puv3", -}; - -static const char *xtensa_machines[] = { - "sim", - "lx60", - "lx200", -}; - -static void add_test_cases(const char *arch, const char *machine) +static void add_machine_test_cases(void) { - char *path; - path = g_strdup_printf("/%s/qom/%s", arch, machine); - g_test_add_data_func(path, machine, test_nop); + const char *arch = qtest_get_arch(); + QDict *response, *minfo; + QList *list; + const QListEntry *p; + QObject *qobj; + QString *qstr; + const char *mname, *path; + + qtest_start("-machine none"); + response = qmp("{ 'execute': 'query-machines' }"); + g_assert(response); + list = qdict_get_qlist(response, "return"); + g_assert(list); + + for (p = qlist_first(list); p; p = qlist_next(p)) { + minfo = qobject_to_qdict(qlist_entry_obj(p)); + g_assert(minfo); + qobj = qdict_get(minfo, "name"); + g_assert(qobj); + qstr = qobject_to_qstring(qobj); + g_assert(qstr); + mname = qstring_get_str(qstr); + if (!is_blacklisted(arch, mname)) { + path = g_strdup_printf("/%s/qom/%s", arch, mname); + g_test_add_data_func(path, mname, test_nop); + } + } + qtest_end(); } -#define ADD_MACHINE_TESTS(arch, array) do { \ - int i; \ - for (i = 0; i < ARRAY_SIZE(array); i++) { \ - add_test_cases((arch), (array)[i]); \ - } \ -} while (false) - int main(int argc, char **argv) { - const char *arch = qtest_get_arch(); - g_test_init(&argc, &argv, NULL); - add_test_cases(arch, "none"); - - if (strcmp(arch, "i386") == 0 || - strcmp(arch, "x86_64") == 0) { - ADD_MACHINE_TESTS(arch, x86_machines); - } else if (strcmp(arch, "alpha") == 0) { - ADD_MACHINE_TESTS(arch, alpha_machines); - } else if (strcmp(arch, "arm") == 0) { - ADD_MACHINE_TESTS(arch, arm_machines); - } else if (strcmp(arch, "cris") == 0) { - ADD_MACHINE_TESTS(arch, cris_machines); - } else if (strcmp(arch, "lm32") == 0) { - ADD_MACHINE_TESTS(arch, lm32_machines); - } else if (strcmp(arch, "m68k") == 0) { - ADD_MACHINE_TESTS(arch, m68k_machines); - } else if (strcmp(arch, "microblaze") == 0 || - strcmp(arch, "microblazeel") == 0) { - ADD_MACHINE_TESTS(arch, microblaze_machines); - } else if (strcmp(arch, "mips") == 0 || - strcmp(arch, "mipsel") == 0 || - strcmp(arch, "mips64") == 0) { - ADD_MACHINE_TESTS(arch, mips_machines); - } else if (strcmp(arch, "mips64el") == 0) { - ADD_MACHINE_TESTS(arch, mips_machines); - add_test_cases(arch, "fulong2e"); - } else if (strcmp(arch, "moxie") == 0) { - ADD_MACHINE_TESTS(arch, moxie_machines); - } else if (strcmp(arch, "or32") == 0) { - ADD_MACHINE_TESTS(arch, openrisc_machines); - } else if (strcmp(arch, "ppcemb") == 0) { -#if 0 - /* XXX Available in ppcemb but don't work */ - ADD_MACHINE_TESTS(arch, ppc405_machines); -#endif - ADD_MACHINE_TESTS(arch, ppc440_machines); - } else if (strcmp(arch, "ppc") == 0) { - ADD_MACHINE_TESTS(arch, ppc405_machines); - ADD_MACHINE_TESTS(arch, ppc440_machines); - ADD_MACHINE_TESTS(arch, ppc_machines); - } else if (strcmp(arch, "ppc64") == 0) { - ADD_MACHINE_TESTS(arch, ppc405_machines); - ADD_MACHINE_TESTS(arch, ppc440_machines); - ADD_MACHINE_TESTS(arch, ppc_machines); - ADD_MACHINE_TESTS(arch, ppc64_machines); - } else if (strcmp(arch, "s390x") == 0) { - ADD_MACHINE_TESTS(arch, s390_machines); - } else if (strcmp(arch, "sh4") == 0 || - strcmp(arch, "sh4eb") == 0) { - ADD_MACHINE_TESTS(arch, superh_machines); - } else if (strcmp(arch, "sparc") == 0) { - ADD_MACHINE_TESTS(arch, sparc_machines); - } else if (strcmp(arch, "sparc64") == 0) { - ADD_MACHINE_TESTS(arch, sparc64_machines); - } else if (strcmp(arch, "unicore32") == 0) { - ADD_MACHINE_TESTS(arch, unicore32_machines); - } else if (strcmp(arch, "xtensa") == 0 || - strcmp(arch, "xtensaeb") == 0) { - ADD_MACHINE_TESTS(arch, xtensa_machines); - } + add_machine_test_cases(); return g_test_run(); }