| Message ID | 87obmmcxlh.fsf@blackfin.pond.sub.org |
|---|---|
| State | New |
| Headers | show |
Markus Armbruster <armbru@redhat.com> writes: > Very basic smoke test: start QEMU with -monitor stdio, quit immediately. > Wouldn't it be nice if that worked for all targets and machine types? > > Many targets have mandatory options (fun oxymoron), such as -kernel or > -pflash. Can't stop me, I just try a bunch until something works. > > Many targets expect various files to be present, and some of them need > to have the right size. Can't stop me, I hack up the file loaders until > it works (silly patch appended). To do this right, we'd need the > required files or suitable mock-ups in-tree. I attempted something similar in the past and ran into similar results. > > Test script: > > #!/bin/sh > for i in ../qemu/bld/*-softmmu/qemu-system-* > do > echo "= $i =" > for m in `$i -M help | sed -n '2,$s/ .*//gp'` > do > echo "== $m ==" > for k in "" "-kernel /dev/null" "-pflash /dev/null" "-pflash /dev/null -pflash /dev/null -kernel /dev/null" > do > echo "=== ${k:-(default)} ===" > if echo q | QEMU_AUDIO_DRV=none $i -S -vnc :0 -M $m $k -monitor stdio | fgrep -q '(qemu)' > then break > else false > fi > done > if [ $? -eq 0 ] > then echo "*** Success $k ***" > else echo '*** Fail' > fi > done > done > > Summary of results: > > * Bad unexplained > > qemu-system-arm lm3s811evb > qemu-system-arm lm3s6965evb > qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. > > qemu-system-ppc64 prep > qemu: hardware error: Unknown device 'i82378' for bus 'PCI' > > qemu-system-ppcemb ref405ep > qemu-system-ppcemb taihu > Unable to find PowerPC 405ep CPU definition > > qemu-system-ppcemb mac99 > qemu-system-ppcemb g3beige > qemu-system-ppcemb prep > Unable to find PowerPC CPU definition > > qemu-system-xtensaeb lx60 > qemu-system-xtensaeb lx200 > qemu-system-xtensaeb sim > Unable to find CPU definition > > I'm not saying these are all busted. If you know how to "start to > monitor" one of these, let us know. Perhaps we could add a QEMUMachine parameter that indicates that the machine doesn't start without special options. At least a handful of these machines cannot be run without the use of non-free binaries firmware :-( Regards, Anthony Liguori > > * Not easily testable for me > > qemu-system-i386 xenfv > qemu-system-i386 xenpv > qemu-system-x86_64 xenfv > qemu-system-x86_64 xenpv > failed to initialize Xen: Operation not permitted > No accelerator found! > > * Good > > qemu-system-alpha clipper > qemu-system-arm collie nuri smdkc210 connex verdex highbank > integratorcp kzm mainstone musicpal n800 n810 sx1 sx1-v1 cheetah > realview-eb realview-eb-mpcore realview-pb-a8 realview-pbx-a9 > akita spitz borzoi terrier tosa versatilepb versatileab > vexpress-a9 vexpress-a15 xilinx-zynq-a9 z2 > qemu-system-cris axis-dev88 > qemu-system-i386 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13 > pc-0.12 pc-0.11 pc-0.10 isapc > qemu-system-lm32 lm32-uclinux lm32-evr milkymist > qemu-system-m68k an5206 dummy mcf5208evb > qemu-system-microblaze petalogix-ml605 petalogix-s3adsp1800 > qemu-system-microblazeel petalogix-ml605 petalogix-s3adsp1800 > qemu-system-mips magnum pica61 malta mipssim mips > qemu-system-mips64 magnum pica61 malta mipssim mips > qemu-system-mips64el fulong2e magnum pica61 malta mipssim mips > qemu-system-mipsel magnum pica61 malta mipssim mips > qemu-system-or32 or32-sim > qemu-system-ppc ref405ep taihu bamboo mac99 g3beige prep virtex-ml507 > qemu-system-ppc64 ref405ep taihu bamboo mac99 g3beige virtex-ml507 > qemu-system-ppcemb bamboo virtex-ml507 > qemu-system-s390x s390 s390-virtio > qemu-system-sh4 r2d shix > qemu-system-sh4eb r2d shix > qemu-system-sparc leon3_generic SS-5 SS-10 SS-600MP SS-20 Voyager LX > SS-4 SPARCClassic SPARCbook SS-1000 SS-2000 SS-2 > qemu-system-sparc64 sun4u sun4v Niagara > qemu-system-x86_64 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13 > pc-0.12 pc-0.11 pc-0.10 isapc > qemu-system-xtensa lx60 lx200 sim > > > diff --git a/hw/loader.c b/hw/loader.c > index 33acc2f..e23af6c 100644 > --- a/hw/loader.c > +++ b/hw/loader.c > @@ -62,7 +62,7 @@ int get_image_size(const char *filename) > int fd, size; > fd = open(filename, O_RDONLY | O_BINARY); > if (fd < 0) > - return -1; > + return 0;//-1; > size = lseek(fd, 0, SEEK_END); > close(fd); > return size; > @@ -75,7 +75,7 @@ int load_image(const char *filename, uint8_t *addr) > int fd, size; > fd = open(filename, O_RDONLY | O_BINARY); > if (fd < 0) > - return -1; > + return 0;//-1; > size = lseek(fd, 0, SEEK_END); > lseek(fd, 0, SEEK_SET); > if (read(fd, addr, size) != size) { > @@ -108,6 +108,7 @@ int load_image_targphys(const char *filename, > int size; > > size = get_image_size(filename); > + if (size < 0) size = 0; > if (size > max_sz) { > return -1; > } > @@ -293,7 +294,7 @@ int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t), > fd = open(filename, O_RDONLY | O_BINARY); > if (fd < 0) { > perror(filename); > - return -1; > + return 0;//-1; > } > if (read(fd, e_ident, sizeof(e_ident)) != sizeof(e_ident)) > goto fail; > @@ -332,7 +333,7 @@ int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t), > > fail: > close(fd); > - return -1; > + return 0;//-1; > } > > static void bswap_uboot_header(uboot_image_header_t *hdr) > diff --git a/hw/pflash_cfi01.c b/hw/pflash_cfi01.c > index d1c7423..f4c20dd 100644 > --- a/hw/pflash_cfi01.c > +++ b/hw/pflash_cfi01.c > @@ -609,7 +609,7 @@ pflash_t *pflash_cfi01_register(target_phys_addr_t base, > pfl->storage = memory_region_get_ram_ptr(&pfl->mem); > memory_region_add_subregion(get_system_memory(), base, &pfl->mem); > > - pfl->bs = bs; > + pfl->bs = NULL;//bs; > if (pfl->bs) { > /* read the initial flash content */ > ret = bdrv_read(pfl->bs, 0, pfl->storage, total_len >> 9); > diff --git a/vl.c b/vl.c > index 9fea320..bcba96d 100644 > --- a/vl.c > +++ b/vl.c > @@ -1814,6 +1814,7 @@ char *qemu_find_file(int type, const char *name) > snprintf(buf, len, "%s/%s%s", data_dir, subdir, name); > if (access(buf, R_OK)) { > g_free(buf); > + return g_strdup("/dev/null"); > return NULL; > } > return buf;
On 7 August 2012 20:26, Markus Armbruster <armbru@redhat.com> wrote: > qemu-system-arm lm3s811evb > qemu-system-arm lm3s6965evb > qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. This is fixed by http://patchwork.ozlabs.org/patch/172820/ (which should be in my arm-devs.next queue, I just haven't got round to flushing it yet.) -- PMM
Anthony Liguori <anthony@codemonkey.ws> writes: > Markus Armbruster <armbru@redhat.com> writes: > >> Very basic smoke test: start QEMU with -monitor stdio, quit immediately. >> Wouldn't it be nice if that worked for all targets and machine types? >> >> Many targets have mandatory options (fun oxymoron), such as -kernel or >> -pflash. Can't stop me, I just try a bunch until something works. >> >> Many targets expect various files to be present, and some of them need >> to have the right size. Can't stop me, I hack up the file loaders until >> it works (silly patch appended). To do this right, we'd need the >> required files or suitable mock-ups in-tree. > > I attempted something similar in the past and ran into similar results. > >> >> Test script: >> >> #!/bin/sh >> for i in ../qemu/bld/*-softmmu/qemu-system-* >> do >> echo "= $i =" >> for m in `$i -M help | sed -n '2,$s/ .*//gp'` >> do >> echo "== $m ==" >> for k in "" "-kernel /dev/null" "-pflash /dev/null" "-pflash /dev/null -pflash /dev/null -kernel /dev/null" >> do >> echo "=== ${k:-(default)} ===" >> if echo q | QEMU_AUDIO_DRV=none $i -S -vnc :0 -M $m $k -monitor stdio | fgrep -q '(qemu)' >> then break >> else false >> fi >> done >> if [ $? -eq 0 ] >> then echo "*** Success $k ***" >> else echo '*** Fail' >> fi >> done >> done >> >> Summary of results: >> >> * Bad unexplained >> >> qemu-system-arm lm3s811evb >> qemu-system-arm lm3s6965evb >> qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. >> >> qemu-system-ppc64 prep >> qemu: hardware error: Unknown device 'i82378' for bus 'PCI' >> >> qemu-system-ppcemb ref405ep >> qemu-system-ppcemb taihu >> Unable to find PowerPC 405ep CPU definition >> >> qemu-system-ppcemb mac99 >> qemu-system-ppcemb g3beige >> qemu-system-ppcemb prep >> Unable to find PowerPC CPU definition >> >> qemu-system-xtensaeb lx60 >> qemu-system-xtensaeb lx200 >> qemu-system-xtensaeb sim >> Unable to find CPU definition >> >> I'm not saying these are all busted. If you know how to "start to >> monitor" one of these, let us know. > > Perhaps we could add a QEMUMachine parameter that indicates that the > machine doesn't start without special options. Recommend to make it a string that lists the mandatory options. > At least a handful of these machines cannot be run without the use of > non-free binaries firmware :-( Yes, and that's bad. However, my test isn't trying to execute any guest code. It *should* be possible to pull off with mocked-up firmware. The mock-ups could then serve as documentation on what firmware binaries are required.
On 7 August 2012 20:55, Markus Armbruster <armbru@redhat.com> wrote: > Anthony Liguori <anthony@codemonkey.ws> writes: >> Perhaps we could add a QEMUMachine parameter that indicates that the >> machine doesn't start without special options. > > Recommend to make it a string that lists the mandatory options. How are you going to say "need either option foo or option bar" ? I'm pretty sure we have some of those (eg "either you need to pass a flash image or a kernel"). -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 7 August 2012 20:55, Markus Armbruster <armbru@redhat.com> wrote: >> Anthony Liguori <anthony@codemonkey.ws> writes: >>> Perhaps we could add a QEMUMachine parameter that indicates that the >>> machine doesn't start without special options. >> >> Recommend to make it a string that lists the mandatory options. > > How are you going to say "need either option foo or option bar" ? I'm > pretty sure we have some of those (eg "either you need to pass a flash > image or a kernel"). Yes, we do. The string should be suitable for inserting into -help.
Am 07.08.2012 21:26, schrieb Markus Armbruster: > Very basic smoke test: start QEMU with -monitor stdio, quit immediately. [...] > Summary of results: > > * Bad unexplained [...] > qemu-system-ppc64 prep > qemu: hardware error: Unknown device 'i82378' for bus 'PCI' This is an untested configuration, none of the PReP machines I know are 64-bit. Alex wants all ppc machines in ppc64 for convenience though. It sounds like CONFIG_I82378=y in default-configs/ppc64-softmmu.mak would fix this. > qemu-system-ppcemb ref405ep > qemu-system-ppcemb taihu > Unable to find PowerPC 405ep CPU definition Alex? > qemu-system-ppcemb mac99 > qemu-system-ppcemb g3beige > qemu-system-ppcemb prep > Unable to find PowerPC CPU definition These three are not embedded CPUs so the error seems correct. Alex, should we suppress the desktop machines for ppcemb? Andreas
On 08/07/2012 02:30 PM, Markus Armbruster wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On 7 August 2012 20:55, Markus Armbruster <armbru@redhat.com> wrote: >>> Anthony Liguori <anthony@codemonkey.ws> writes: >>>> Perhaps we could add a QEMUMachine parameter that indicates that the >>>> machine doesn't start without special options. >>> >>> Recommend to make it a string that lists the mandatory options. >> >> How are you going to say "need either option foo or option bar" ? I'm >> pretty sure we have some of those (eg "either you need to pass a flash >> image or a kernel"). > > Yes, we do. > > The string should be suitable for inserting into -help. Convention in other programs' -help output is to express a mandatory selection from mutually exclusive options using {}, as in: { -foo | -bar } If both options can be used together, but cannot both be omitted, then this style works: { -foo [ -bar ] | -bar } Mutually exclusive options, but where omission is okay, would then be: [ { -foo | -bar } ] or even this variant, to express the default when both are omitted: { -foo | [ -bar ] } Using strings with metasyntax like that should be usable in qemu -help.
On Tue, Aug 7, 2012 at 7:26 PM, Markus Armbruster <armbru@redhat.com> wrote: > Very basic smoke test: start QEMU with -monitor stdio, quit immediately. > Wouldn't it be nice if that worked for all targets and machine types? > > Many targets have mandatory options (fun oxymoron), such as -kernel or > -pflash. Can't stop me, I just try a bunch until something works. > Funny, I tried pretty similar stuff earlier but with qtest: http://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg01880.html > Many targets expect various files to be present, and some of them need > to have the right size. Can't stop me, I hack up the file loaders until > it works (silly patch appended). To do this right, we'd need the > required files or suitable mock-ups in-tree. > > Test script: > > #!/bin/sh > for i in ../qemu/bld/*-softmmu/qemu-system-* > do > echo "= $i =" > for m in `$i -M help | sed -n '2,$s/ .*//gp'` > do > echo "== $m ==" > for k in "" "-kernel /dev/null" "-pflash /dev/null" "-pflash /dev/null -pflash /dev/null -kernel /dev/null" > do > echo "=== ${k:-(default)} ===" > if echo q | QEMU_AUDIO_DRV=none $i -S -vnc :0 -M $m $k -monitor stdio | fgrep -q '(qemu)' > then break > else false > fi > done > if [ $? -eq 0 ] > then echo "*** Success $k ***" > else echo '*** Fail' > fi > done > done > > Summary of results: > > * Bad unexplained > > qemu-system-arm lm3s811evb > qemu-system-arm lm3s6965evb > qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. > > qemu-system-ppc64 prep > qemu: hardware error: Unknown device 'i82378' for bus 'PCI' > > qemu-system-ppcemb ref405ep > qemu-system-ppcemb taihu > Unable to find PowerPC 405ep CPU definition > > qemu-system-ppcemb mac99 > qemu-system-ppcemb g3beige > qemu-system-ppcemb prep > Unable to find PowerPC CPU definition > > qemu-system-xtensaeb lx60 > qemu-system-xtensaeb lx200 > qemu-system-xtensaeb sim > Unable to find CPU definition > > I'm not saying these are all busted. If you know how to "start to > monitor" one of these, let us know. > > * Not easily testable for me > > qemu-system-i386 xenfv > qemu-system-i386 xenpv > qemu-system-x86_64 xenfv > qemu-system-x86_64 xenpv > failed to initialize Xen: Operation not permitted > No accelerator found! > > * Good > > qemu-system-alpha clipper > qemu-system-arm collie nuri smdkc210 connex verdex highbank > integratorcp kzm mainstone musicpal n800 n810 sx1 sx1-v1 cheetah > realview-eb realview-eb-mpcore realview-pb-a8 realview-pbx-a9 > akita spitz borzoi terrier tosa versatilepb versatileab > vexpress-a9 vexpress-a15 xilinx-zynq-a9 z2 > qemu-system-cris axis-dev88 > qemu-system-i386 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13 > pc-0.12 pc-0.11 pc-0.10 isapc > qemu-system-lm32 lm32-uclinux lm32-evr milkymist > qemu-system-m68k an5206 dummy mcf5208evb > qemu-system-microblaze petalogix-ml605 petalogix-s3adsp1800 > qemu-system-microblazeel petalogix-ml605 petalogix-s3adsp1800 > qemu-system-mips magnum pica61 malta mipssim mips > qemu-system-mips64 magnum pica61 malta mipssim mips > qemu-system-mips64el fulong2e magnum pica61 malta mipssim mips > qemu-system-mipsel magnum pica61 malta mipssim mips > qemu-system-or32 or32-sim > qemu-system-ppc ref405ep taihu bamboo mac99 g3beige prep virtex-ml507 > qemu-system-ppc64 ref405ep taihu bamboo mac99 g3beige virtex-ml507 > qemu-system-ppcemb bamboo virtex-ml507 > qemu-system-s390x s390 s390-virtio > qemu-system-sh4 r2d shix > qemu-system-sh4eb r2d shix > qemu-system-sparc leon3_generic SS-5 SS-10 SS-600MP SS-20 Voyager LX > SS-4 SPARCClassic SPARCbook SS-1000 SS-2000 SS-2 > qemu-system-sparc64 sun4u sun4v Niagara > qemu-system-x86_64 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13 > pc-0.12 pc-0.11 pc-0.10 isapc > qemu-system-xtensa lx60 lx200 sim > > > diff --git a/hw/loader.c b/hw/loader.c > index 33acc2f..e23af6c 100644 > --- a/hw/loader.c > +++ b/hw/loader.c > @@ -62,7 +62,7 @@ int get_image_size(const char *filename) > int fd, size; > fd = open(filename, O_RDONLY | O_BINARY); > if (fd < 0) > - return -1; > + return 0;//-1; > size = lseek(fd, 0, SEEK_END); > close(fd); > return size; > @@ -75,7 +75,7 @@ int load_image(const char *filename, uint8_t *addr) > int fd, size; > fd = open(filename, O_RDONLY | O_BINARY); > if (fd < 0) > - return -1; > + return 0;//-1; > size = lseek(fd, 0, SEEK_END); > lseek(fd, 0, SEEK_SET); > if (read(fd, addr, size) != size) { > @@ -108,6 +108,7 @@ int load_image_targphys(const char *filename, > int size; > > size = get_image_size(filename); > + if (size < 0) size = 0; > if (size > max_sz) { > return -1; > } > @@ -293,7 +294,7 @@ int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t), > fd = open(filename, O_RDONLY | O_BINARY); > if (fd < 0) { > perror(filename); > - return -1; > + return 0;//-1; > } > if (read(fd, e_ident, sizeof(e_ident)) != sizeof(e_ident)) > goto fail; > @@ -332,7 +333,7 @@ int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t), > > fail: > close(fd); > - return -1; > + return 0;//-1; > } > > static void bswap_uboot_header(uboot_image_header_t *hdr) > diff --git a/hw/pflash_cfi01.c b/hw/pflash_cfi01.c > index d1c7423..f4c20dd 100644 > --- a/hw/pflash_cfi01.c > +++ b/hw/pflash_cfi01.c > @@ -609,7 +609,7 @@ pflash_t *pflash_cfi01_register(target_phys_addr_t base, > pfl->storage = memory_region_get_ram_ptr(&pfl->mem); > memory_region_add_subregion(get_system_memory(), base, &pfl->mem); > > - pfl->bs = bs; > + pfl->bs = NULL;//bs; > if (pfl->bs) { > /* read the initial flash content */ > ret = bdrv_read(pfl->bs, 0, pfl->storage, total_len >> 9); > diff --git a/vl.c b/vl.c > index 9fea320..bcba96d 100644 > --- a/vl.c > +++ b/vl.c > @@ -1814,6 +1814,7 @@ char *qemu_find_file(int type, const char *name) > snprintf(buf, len, "%s/%s%s", data_dir, subdir, name); > if (access(buf, R_OK)) { > g_free(buf); > + return g_strdup("/dev/null"); > return NULL; > } > return buf; >
Peter Maydell <peter.maydell@linaro.org> writes: > On 7 August 2012 20:26, Markus Armbruster <armbru@redhat.com> wrote: >> qemu-system-arm lm3s811evb >> qemu-system-arm lm3s6965evb >> qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: >> qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. > > This is fixed by http://patchwork.ozlabs.org/patch/172820/ > (which should be in my arm-devs.next queue, I just haven't > got round to flushing it yet.) It does. Next bug: stellaris_init() passes kernel_filename via armv7_init() to load_elf(), even when it's null. load_elf() fails with the "helpful" error message "Bad address". $ QEMU_AUDIO_DRV=none ../qemu/bld/arm-softmmu/qemu-system-arm -vnc :0 -M lm3s6965evb -monitor stdio -pflash /dev/null -S Bad address QEMU 1.1.50 monitor - type 'help' for more information (qemu) q
Andreas Färber <afaerber@suse.de> writes: > Am 07.08.2012 21:26, schrieb Markus Armbruster: >> Very basic smoke test: start QEMU with -monitor stdio, quit immediately. > [...] >> Summary of results: >> >> * Bad unexplained > [...] >> qemu-system-ppc64 prep >> qemu: hardware error: Unknown device 'i82378' for bus 'PCI' > > This is an untested configuration, none of the PReP machines I know are > 64-bit. Alex wants all ppc machines in ppc64 for convenience though. If you want to have it, you get to test it :) > It sounds like CONFIG_I82378=y in default-configs/ppc64-softmmu.mak > would fix this. Make doesn't pick up that change. Makefiles defective? [...]
On Tue, Aug 7, 2012 at 11:26 PM, Markus Armbruster <armbru@redhat.com> wrote: > Very basic smoke test: start QEMU with -monitor stdio, quit immediately. > Wouldn't it be nice if that worked for all targets and machine types? > > Many targets have mandatory options (fun oxymoron), such as -kernel or > -pflash. Can't stop me, I just try a bunch until something works. > > Many targets expect various files to be present, and some of them need > to have the right size. Can't stop me, I hack up the file loaders until > it works (silly patch appended). To do this right, we'd need the > required files or suitable mock-ups in-tree. [...] > Summary of results: > > * Bad unexplained > qemu-system-xtensaeb lx60 > qemu-system-xtensaeb lx200 > qemu-system-xtensaeb sim > Unable to find CPU definition > > I'm not saying these are all busted. If you know how to "start to > monitor" one of these, let us know. For xtensa the default CPU name is the same for both big-endian and little-endian binaries, but actually it denotes little-endian CPU not supported by xtensaeb. It will start with the explicit -cpu fsf. I can post a patch to make fsf the default CPU type in big-endian case.
Blue Swirl <blauwirbel@gmail.com> writes: > On Tue, Aug 7, 2012 at 7:26 PM, Markus Armbruster <armbru@redhat.com> wrote: >> Very basic smoke test: start QEMU with -monitor stdio, quit immediately. >> Wouldn't it be nice if that worked for all targets and machine types? >> >> Many targets have mandatory options (fun oxymoron), such as -kernel or >> -pflash. Can't stop me, I just try a bunch until something works. >> > > Funny, I tried pretty similar stuff earlier but with qtest: > http://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg01880.html I'd like to see such a test in "make check", too. I missed your try, or I forgot it since, thanks for the pointer. I'd prefer providing mocked up images for the test over disabling ROM and kernel loading in many places (your patch), let alone butchering it (my hackery; clearly not committable).
Markus Armbruster <armbru@redhat.com> writes: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On 7 August 2012 20:55, Markus Armbruster <armbru@redhat.com> wrote: >>> Anthony Liguori <anthony@codemonkey.ws> writes: >>>> Perhaps we could add a QEMUMachine parameter that indicates that the >>>> machine doesn't start without special options. >>> >>> Recommend to make it a string that lists the mandatory options. >> >> How are you going to say "need either option foo or option bar" ? I'm >> pretty sure we have some of those (eg "either you need to pass a flash >> image or a kernel"). > > Yes, we do. > > The string should be suitable for inserting into -help. Sufficiently common cases can also be delegated to generic code: * Maximum number of CPUs Got that: QEMUMachine member max_cpus, main() enforces it. * Require -kernel Have a flag in QEMUMachine, enforce in main(). * Require certain drives Have QEMUMachine declare minimum and maximum number drives of each BlockInterfaceType?
On 8 August 2012 08:50, Markus Armbruster <armbru@redhat.com> wrote: > Markus Armbruster <armbru@redhat.com> writes: >> The string should be suitable for inserting into -help. > > Sufficiently common cases can also be delegated to generic code: > > * Maximum number of CPUs > > Got that: QEMUMachine member max_cpus, main() enforces it. > > * Require -kernel > > Have a flag in QEMUMachine, enforce in main(). > > * Require certain drives > > Have QEMUMachine declare minimum and maximum number drives of each > BlockInterfaceType? I'm not entirely sure what the aim here is? Allow some automated test program to programmatically determine required arguments for a smoke test? Make machines consistent about how they inform the user about required arguments etc? Let us print this info in --help? Something else? -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 8 August 2012 08:50, Markus Armbruster <armbru@redhat.com> wrote: >> Markus Armbruster <armbru@redhat.com> writes: >>> The string should be suitable for inserting into -help. >> >> Sufficiently common cases can also be delegated to generic code: >> >> * Maximum number of CPUs >> >> Got that: QEMUMachine member max_cpus, main() enforces it. >> >> * Require -kernel >> >> Have a flag in QEMUMachine, enforce in main(). >> >> * Require certain drives >> >> Have QEMUMachine declare minimum and maximum number drives of each >> BlockInterfaceType? > > I'm not entirely sure what the aim here is? Allow some automated test > program to programmatically determine required arguments for a > smoke test? Make machines consistent about how they inform the > user about required arguments etc? Let us print this info in --help? > Something else? I think each of the above would be nice to have, no more, no less.
Max Filippov <jcmvbkbc@gmail.com> writes: > On Tue, Aug 7, 2012 at 11:26 PM, Markus Armbruster <armbru@redhat.com> wrote: >> Very basic smoke test: start QEMU with -monitor stdio, quit immediately. >> Wouldn't it be nice if that worked for all targets and machine types? >> >> Many targets have mandatory options (fun oxymoron), such as -kernel or >> -pflash. Can't stop me, I just try a bunch until something works. >> >> Many targets expect various files to be present, and some of them need >> to have the right size. Can't stop me, I hack up the file loaders until >> it works (silly patch appended). To do this right, we'd need the >> required files or suitable mock-ups in-tree. > > [...] > >> Summary of results: >> >> * Bad unexplained > >> qemu-system-xtensaeb lx60 >> qemu-system-xtensaeb lx200 >> qemu-system-xtensaeb sim >> Unable to find CPU definition >> >> I'm not saying these are all busted. If you know how to "start to >> monitor" one of these, let us know. > > For xtensa the default CPU name is the same for both big-endian and > little-endian binaries, but actually it denotes little-endian CPU not supported > by xtensaeb. It will start with the explicit -cpu fsf. I can post a patch to > make fsf the default CPU type in big-endian case. Sounds worthwhile to me.
Markus Armbruster <armbru@redhat.com> writes: > Andreas Färber <afaerber@suse.de> writes: > >> Am 07.08.2012 21:26, schrieb Markus Armbruster: >>> Very basic smoke test: start QEMU with -monitor stdio, quit immediately. >> [...] >>> Summary of results: >>> >>> * Bad unexplained >> [...] >>> qemu-system-ppc64 prep >>> qemu: hardware error: Unknown device 'i82378' for bus 'PCI' >> >> This is an untested configuration, none of the PReP machines I know are >> 64-bit. Alex wants all ppc machines in ppc64 for convenience though. > > If you want to have it, you get to test it :) > >> It sounds like CONFIG_I82378=y in default-configs/ppc64-softmmu.mak >> would fix this. > > Make doesn't pick up that change. Makefiles defective? > > [...] Manual "touch ppc64-softmmu/config-target.h" did the trick. Two more are missing: CONFIG_I82374 and CONFIG_PCSPK. Result is identical to ppc-softmmy.mak, except for the comment on the first line.
On Wed, Aug 8, 2012 at 7:39 AM, Markus Armbruster <armbru@redhat.com> wrote: > Blue Swirl <blauwirbel@gmail.com> writes: > >> On Tue, Aug 7, 2012 at 7:26 PM, Markus Armbruster <armbru@redhat.com> wrote: >>> Very basic smoke test: start QEMU with -monitor stdio, quit immediately. >>> Wouldn't it be nice if that worked for all targets and machine types? >>> >>> Many targets have mandatory options (fun oxymoron), such as -kernel or >>> -pflash. Can't stop me, I just try a bunch until something works. >>> >> >> Funny, I tried pretty similar stuff earlier but with qtest: >> http://lists.nongnu.org/archive/html/qemu-devel/2012-04/msg01880.html > > I'd like to see such a test in "make check", too. > > I missed your try, or I forgot it since, thanks for the pointer. > > I'd prefer providing mocked up images for the test over disabling ROM > and kernel loading in many places (your patch), let alone butchering it > (my hackery; clearly not committable). Fake files could work. Since qtest does not execute any code, any ROMs, kernels or initrd files are somewhat useless. But since my approach was not acceptable, I'll let the ARM etc. people solve the need for those files how they want when they introduce qtests for their devices.
On Wed, Aug 8, 2012 at 5:22 PM, Markus Armbruster <armbru@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On 7 August 2012 20:26, Markus Armbruster <armbru@redhat.com> wrote: >>> qemu-system-arm lm3s811evb >>> qemu-system-arm lm3s6965evb >>> qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: >>> qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. >> >> This is fixed by http://patchwork.ozlabs.org/patch/172820/ >> (which should be in my arm-devs.next queue, I just haven't >> got round to flushing it yet.) > > It does. > > Next bug: stellaris_init() passes kernel_filename via armv7_init() to > load_elf(), even when it's null. load_elf() fails with the "helpful" > error message "Bad address". > Fix on list. > $ QEMU_AUDIO_DRV=none ../qemu/bld/arm-softmmu/qemu-system-arm -vnc :0 -M lm3s6965evb -monitor stdio -pflash /dev/null -S > Bad address > QEMU 1.1.50 monitor - type 'help' for more information > (qemu) q >
diff --git a/hw/loader.c b/hw/loader.c index 33acc2f..e23af6c 100644 --- a/hw/loader.c +++ b/hw/loader.c @@ -62,7 +62,7 @@ int get_image_size(const char *filename) int fd, size; fd = open(filename, O_RDONLY | O_BINARY); if (fd < 0) - return -1; + return 0;//-1; size = lseek(fd, 0, SEEK_END); close(fd); return size; @@ -75,7 +75,7 @@ int load_image(const char *filename, uint8_t *addr) int fd, size; fd = open(filename, O_RDONLY | O_BINARY); if (fd < 0) - return -1; + return 0;//-1; size = lseek(fd, 0, SEEK_END); lseek(fd, 0, SEEK_SET); if (read(fd, addr, size) != size) { @@ -108,6 +108,7 @@ int load_image_targphys(const char *filename, int size; size = get_image_size(filename); + if (size < 0) size = 0; if (size > max_sz) { return -1; } @@ -293,7 +294,7 @@ int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t), fd = open(filename, O_RDONLY | O_BINARY); if (fd < 0) { perror(filename); - return -1; + return 0;//-1; } if (read(fd, e_ident, sizeof(e_ident)) != sizeof(e_ident)) goto fail; @@ -332,7 +333,7 @@ int load_elf(const char *filename, uint64_t (*translate_fn)(void *, uint64_t), fail: close(fd); - return -1; + return 0;//-1; } static void bswap_uboot_header(uboot_image_header_t *hdr) diff --git a/hw/pflash_cfi01.c b/hw/pflash_cfi01.c index d1c7423..f4c20dd 100644 --- a/hw/pflash_cfi01.c +++ b/hw/pflash_cfi01.c @@ -609,7 +609,7 @@ pflash_t *pflash_cfi01_register(target_phys_addr_t base, pfl->storage = memory_region_get_ram_ptr(&pfl->mem); memory_region_add_subregion(get_system_memory(), base, &pfl->mem); - pfl->bs = bs; + pfl->bs = NULL;//bs; if (pfl->bs) { /* read the initial flash content */ ret = bdrv_read(pfl->bs, 0, pfl->storage, total_len >> 9); diff --git a/vl.c b/vl.c index 9fea320..bcba96d 100644 --- a/vl.c +++ b/vl.c @@ -1814,6 +1814,7 @@ char *qemu_find_file(int type, const char *name) snprintf(buf, len, "%s/%s%s", data_dir, subdir, name); if (access(buf, R_OK)) { g_free(buf); + return g_strdup("/dev/null"); return NULL; } return buf;
Very basic smoke test: start QEMU with -monitor stdio, quit immediately. Wouldn't it be nice if that worked for all targets and machine types? Many targets have mandatory options (fun oxymoron), such as -kernel or -pflash. Can't stop me, I just try a bunch until something works. Many targets expect various files to be present, and some of them need to have the right size. Can't stop me, I hack up the file loaders until it works (silly patch appended). To do this right, we'd need the required files or suitable mock-ups in-tree. Test script: #!/bin/sh for i in ../qemu/bld/*-softmmu/qemu-system-* do echo "= $i =" for m in `$i -M help | sed -n '2,$s/ .*//gp'` do echo "== $m ==" for k in "" "-kernel /dev/null" "-pflash /dev/null" "-pflash /dev/null -pflash /dev/null -kernel /dev/null" do echo "=== ${k:-(default)} ===" if echo q | QEMU_AUDIO_DRV=none $i -S -vnc :0 -M $m $k -monitor stdio | fgrep -q '(qemu)' then break else false fi done if [ $? -eq 0 ] then echo "*** Success $k ***" else echo '*** Fail' fi done done Summary of results: * Bad unexplained qemu-system-arm lm3s811evb qemu-system-arm lm3s6965evb qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: qdev_get_gpio_in: Assertion `n >= 0 && n < dev->num_gpio_in' failed. qemu-system-ppc64 prep qemu: hardware error: Unknown device 'i82378' for bus 'PCI' qemu-system-ppcemb ref405ep qemu-system-ppcemb taihu Unable to find PowerPC 405ep CPU definition qemu-system-ppcemb mac99 qemu-system-ppcemb g3beige qemu-system-ppcemb prep Unable to find PowerPC CPU definition qemu-system-xtensaeb lx60 qemu-system-xtensaeb lx200 qemu-system-xtensaeb sim Unable to find CPU definition I'm not saying these are all busted. If you know how to "start to monitor" one of these, let us know. * Not easily testable for me qemu-system-i386 xenfv qemu-system-i386 xenpv qemu-system-x86_64 xenfv qemu-system-x86_64 xenpv failed to initialize Xen: Operation not permitted No accelerator found! * Good qemu-system-alpha clipper qemu-system-arm collie nuri smdkc210 connex verdex highbank integratorcp kzm mainstone musicpal n800 n810 sx1 sx1-v1 cheetah realview-eb realview-eb-mpcore realview-pb-a8 realview-pbx-a9 akita spitz borzoi terrier tosa versatilepb versatileab vexpress-a9 vexpress-a15 xilinx-zynq-a9 z2 qemu-system-cris axis-dev88 qemu-system-i386 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13 pc-0.12 pc-0.11 pc-0.10 isapc qemu-system-lm32 lm32-uclinux lm32-evr milkymist qemu-system-m68k an5206 dummy mcf5208evb qemu-system-microblaze petalogix-ml605 petalogix-s3adsp1800 qemu-system-microblazeel petalogix-ml605 petalogix-s3adsp1800 qemu-system-mips magnum pica61 malta mipssim mips qemu-system-mips64 magnum pica61 malta mipssim mips qemu-system-mips64el fulong2e magnum pica61 malta mipssim mips qemu-system-mipsel magnum pica61 malta mipssim mips qemu-system-or32 or32-sim qemu-system-ppc ref405ep taihu bamboo mac99 g3beige prep virtex-ml507 qemu-system-ppc64 ref405ep taihu bamboo mac99 g3beige virtex-ml507 qemu-system-ppcemb bamboo virtex-ml507 qemu-system-s390x s390 s390-virtio qemu-system-sh4 r2d shix qemu-system-sh4eb r2d shix qemu-system-sparc leon3_generic SS-5 SS-10 SS-600MP SS-20 Voyager LX SS-4 SPARCClassic SPARCbook SS-1000 SS-2000 SS-2 qemu-system-sparc64 sun4u sun4v Niagara qemu-system-x86_64 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13 pc-0.12 pc-0.11 pc-0.10 isapc qemu-system-xtensa lx60 lx200 sim