qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Aleksandar Markovic" <amarkovic@wavecomp.com>,
	"Aleksandar Rikalo" <arikalo@wavecomp.com>,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Andrzej Zaborowski" <balrogg@gmail.com>,
	"Anthony Green" <green@moxielogic.com>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Antony Pavlov" <antonynpavlov@gmail.com>,
	"Artyom Tarasenko" <atar4qemu@gmail.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"BALATON Zoltan" <balaton@eik.bme.hu>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Beniamino Galvani" <b.galvani@gmail.com>,
	"Chris Wulff" <crwulff@gmail.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"David Hildenbrand" <david@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Fabien Chouteau" <chouteau@adacore.com>,
	"Guan Xuetao" <gxt@mprc.pku.edu.cn>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Helge Deller" <deller@gmx.de>,
	"Igor Mitsyanko" <i.mitsyanko@gmail.com>,
	"Jan Kiszka" <jan.kiszka@web.de>,
	"Jean-Christophe Dubois" <jcd@tribudubois.net>,
	"Jia Liu" <proljc@gmail.com>, "Joel Stanley" <joel@jms.id.au>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Marek Vasut" <marex@denx.de>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Michael Walle" <michael@walle.cc>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Paul Burton" <pburton@wavecomp.com>,
	"Paul Durrant" <paul.durrant@citrix.com>,
	"Peter Chubb" <peter.chubb@nicta.com.au>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Richard Henderson" <rth@twiddle.net>,
	"Rob Herring" <robh@kernel.org>,
	"Sagar Karandikar" <sagark@eecs.berkeley.edu>,
	"Stafford Horne" <shorne@gmail.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Subbaraya Sundeep" <sundeep.lkml@gmail.com>,
	"Thomas Huth" <huth@tuxfamily.org>
Subject: Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!
Date: Mon, 15 Apr 2019 19:24:49 -0700	[thread overview]
Message-ID: <CAHQ1cqEDxNMeAGb5t4OrV9DWpq-VTn4GVhjQh4BePZv=JP8-Ow@mail.gmail.com> (raw)
In-Reply-To: <87d0mwatbu.fsf@dusky.pond.sub.org>

On Tue, Mar 12, 2019 at 10:36 AM Markus Armbruster <armbru@redhat.com> wrote:
>
> Dear board code maintainers,
>
> This is a (rather late) follow-up to the last QEMU summit.  Minutes[*]:
>
>  * Deprecating unmaintained features (devices, targets, backends) in QEMU
>
>    QEMU has a mechanism to deprecate features but there remains a lot of
>    old unmaintained code.  Refactoring is hindered by untested legacy
>    code, so there is a desire to deprecate unmaintained features more
>    often.
>
>    [...]
>
>    We should require at least a minimal test for each board; if nobody
>    cares enough to come up with one, that board should be deprecated.
>
>    [...]
>
>    Also see the qemu-devel discussion about deprecating code:
>    https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html.
>
> That's a link to "Minutes of KVM Forum BoF on deprecating stuff".
> Quote:
>
>  * One obvious class of candidates for removal is machines we don't know
>    how to boot, or can't boot, say because we lack required firmware
>    and/or OS.
>
>    Of course, "can boot" should be an automated test.  As a first step
>    towards that, we should at least document how to boot each machine.
>    We're going to ask machine maintainers to do that.
>
> Let's get going on this.
>
> I gathered the machine types, mapped them to source files, which I fed
> to get_maintainer.pl.  Results are appended.  If you're cc'ed,
> MAINTAINERS fingers you for at least one machine type's source file.
> Please tell us for all of them how to to a "meaningful" boot test.
>
> For now, what's "meaningful" is entirely up to you.  Booting Linux
> certainly is.
>
> Make sure to include a complete QEMU command line.  If your QEMU command
> line requires resources beyond the QEMU source tree and what we build
> from it, please detail them, and provide download URLs as far as
> possible.
>
> Goals for this exercise:
>
> * Gather information we need to cover more machines in our automated
>   testing.
>
>   Related work:
>   [PATCH v4 00/19] Acceptance Tests: target architecture support
>   Message-Id: <20190312121150.8638-1-crosa@redhat.com>
>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03881.html
>
> * Maybe identify a few machines we don't know how to boot anymore.
>
> Thanks in advance for your help!
>
>
>
> Machines with at least one maintainer:
>
>
>     = hw/arm/mcimx7d-sabre.c =
>     Peter Maydell <peter.maydell@linaro.org> (odd fixer:MCIMX7D SABRE / i...)
>     Andrey Smirnov <andrew.smirnov@gmail.com> (reviewer:MCIMX7D SABRE / i...)
>     qemu-arm@nongnu.org (open list:MCIMX7D SABRE / i...)
>

Sorry I am late to this party. I haven't used i.MX7 emulation in a
while and things didn't go smoothly out of the box, so I had to create
a number of fixes (submitted to the ML).

I use Linux kernel built using Buildroot for validation. Buildroot
should have a default i.MX7 Sabred SD configuration and that should
probably work. I usually change mine slightly to use compiled-in
rootfs to simplify storage setup.

In case this is helpful here's a number of commands I use to start my
test cases:

* PCIe (e1000 ethernet attached), USB (usb stick attached), SD:
arm-softmmu/qemu-system-arm -smp 2 -m 1024 -machine mcimx7d-sabre
-nographic -serial mon:stdio -kernel <path to zImage> -dtb <path to
DTB> -device e1000e,bus="dw-pcie",netdev=lan0 -netdev
tap,id=lan0,ifname=tap0,script=no,downscript=no -append
"console=ttymxc0,115200 noinitrd" -usb -drive
if=none,id=stick,file=<patch to USB stick image>,format=raw -device
usb-storage,bus=usb-bus.0,drive=stick -drive
id=sd1,if=sd,format=file,file=<path to SD1> -drive
id=sd2,if=sd,format=file,file=<path to SD2> -driv
eid=sd3,if=sd,format=file,file=<path to SD3>

* EHCI USB attached via PCIe with legacy interrupts, Ethernet
connected to built-in controller:
arm-softmmu/qemu-system-arm -smp 2 -m 1024 -machine mcimx7d-sabre
-nographic -serial mon:stdio -kernel <path to zImage> -dtb <path to
DTB> -device usb-ehci,id=ehci,bus="dw-pcie" -net
nic,model=imx.fec,netdev=lan0 -netdev
tap,id=lan0,ifname=tap0,script=no,downscript=no -append
"console=ttymxc0,115200 noinitrd pci=nomsi" -usb -drive
if=none,id=stick,file=<path to USB stick image>,format=raw

Also, I don't think anyone would try to do this, but just as a
warning, building QEMU with --enable-tcg-interpreter doesn't really
work that well (/init gets SIGKILLed every time), so I'd recommend
avoiding using that option.

Hopefully this is enough info, but if not, feel free to ask me more questions.

Thanks,
Andrey Smirnov

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Paul Burton" <pburton@wavecomp.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Sagar Karandikar" <sagark@eecs.berkeley.edu>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Anthony Green" <green@moxielogic.com>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Max Filippov" <jcmvbkbc@gmail.com>,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Guan Xuetao" <gxt@mprc.pku.edu.cn>,
	"Peter Chubb" <peter.chubb@nicta.com.au>,
	"Marek Vasut" <marex@denx.de>, "Rob Herring" <robh@kernel.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Jia Liu" <proljc@gmail.com>,
	"Aleksandar Rikalo" <arikalo@wavecomp.com>,
	"Helge Deller" <deller@gmx.de>,
	"David Hildenbrand" <david@redhat.com>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Antony Pavlov" <antonynpavlov@gmail.com>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Artyom Tarasenko" <atar4qemu@gmail.com>,
	"Joel Stanley" <joel@jms.id.au>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Fabien Chouteau" <chouteau@adacore.com>,
	"Beniamino Galvani" <b.galvani@gmail.com>,
	"Paul Durrant" <paul.durrant@citrix.com>,
	"Jan Kiszka" <jan.kiszka@web.de>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Stafford Horne" <shorne@gmail.com>,
	"Subbaraya Sundeep" <sundeep.lkml@gmail.com>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Chris Wulff" <crwulff@gmail.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
	"Jean-Christophe Dubois" <jcd@tribudubois.net>,
	"Igor Mitsyanko" <i.mitsyanko@gmail.com>,
	"Michael Walle" <michael@walle.cc>,
	"Thomas Huth" <huth@tuxfamily.org>,
	"Aleksandar Markovic" <amarkovic@wavecomp.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!
Date: Mon, 15 Apr 2019 19:24:49 -0700	[thread overview]
Message-ID: <CAHQ1cqEDxNMeAGb5t4OrV9DWpq-VTn4GVhjQh4BePZv=JP8-Ow@mail.gmail.com> (raw)
Message-ID: <20190416022449.vbAA71Qkrto7-_PfJKSTCwCrlZ2Gzgino5Y21uOLlzs@z> (raw)
In-Reply-To: <87d0mwatbu.fsf@dusky.pond.sub.org>

On Tue, Mar 12, 2019 at 10:36 AM Markus Armbruster <armbru@redhat.com> wrote:
>
> Dear board code maintainers,
>
> This is a (rather late) follow-up to the last QEMU summit.  Minutes[*]:
>
>  * Deprecating unmaintained features (devices, targets, backends) in QEMU
>
>    QEMU has a mechanism to deprecate features but there remains a lot of
>    old unmaintained code.  Refactoring is hindered by untested legacy
>    code, so there is a desire to deprecate unmaintained features more
>    often.
>
>    [...]
>
>    We should require at least a minimal test for each board; if nobody
>    cares enough to come up with one, that board should be deprecated.
>
>    [...]
>
>    Also see the qemu-devel discussion about deprecating code:
>    https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html.
>
> That's a link to "Minutes of KVM Forum BoF on deprecating stuff".
> Quote:
>
>  * One obvious class of candidates for removal is machines we don't know
>    how to boot, or can't boot, say because we lack required firmware
>    and/or OS.
>
>    Of course, "can boot" should be an automated test.  As a first step
>    towards that, we should at least document how to boot each machine.
>    We're going to ask machine maintainers to do that.
>
> Let's get going on this.
>
> I gathered the machine types, mapped them to source files, which I fed
> to get_maintainer.pl.  Results are appended.  If you're cc'ed,
> MAINTAINERS fingers you for at least one machine type's source file.
> Please tell us for all of them how to to a "meaningful" boot test.
>
> For now, what's "meaningful" is entirely up to you.  Booting Linux
> certainly is.
>
> Make sure to include a complete QEMU command line.  If your QEMU command
> line requires resources beyond the QEMU source tree and what we build
> from it, please detail them, and provide download URLs as far as
> possible.
>
> Goals for this exercise:
>
> * Gather information we need to cover more machines in our automated
>   testing.
>
>   Related work:
>   [PATCH v4 00/19] Acceptance Tests: target architecture support
>   Message-Id: <20190312121150.8638-1-crosa@redhat.com>
>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03881.html
>
> * Maybe identify a few machines we don't know how to boot anymore.
>
> Thanks in advance for your help!
>
>
>
> Machines with at least one maintainer:
>
>
>     = hw/arm/mcimx7d-sabre.c =
>     Peter Maydell <peter.maydell@linaro.org> (odd fixer:MCIMX7D SABRE / i...)
>     Andrey Smirnov <andrew.smirnov@gmail.com> (reviewer:MCIMX7D SABRE / i...)
>     qemu-arm@nongnu.org (open list:MCIMX7D SABRE / i...)
>

Sorry I am late to this party. I haven't used i.MX7 emulation in a
while and things didn't go smoothly out of the box, so I had to create
a number of fixes (submitted to the ML).

I use Linux kernel built using Buildroot for validation. Buildroot
should have a default i.MX7 Sabred SD configuration and that should
probably work. I usually change mine slightly to use compiled-in
rootfs to simplify storage setup.

In case this is helpful here's a number of commands I use to start my
test cases:

* PCIe (e1000 ethernet attached), USB (usb stick attached), SD:
arm-softmmu/qemu-system-arm -smp 2 -m 1024 -machine mcimx7d-sabre
-nographic -serial mon:stdio -kernel <path to zImage> -dtb <path to
DTB> -device e1000e,bus="dw-pcie",netdev=lan0 -netdev
tap,id=lan0,ifname=tap0,script=no,downscript=no -append
"console=ttymxc0,115200 noinitrd" -usb -drive
if=none,id=stick,file=<patch to USB stick image>,format=raw -device
usb-storage,bus=usb-bus.0,drive=stick -drive
id=sd1,if=sd,format=file,file=<path to SD1> -drive
id=sd2,if=sd,format=file,file=<path to SD2> -driv
eid=sd3,if=sd,format=file,file=<path to SD3>

* EHCI USB attached via PCIe with legacy interrupts, Ethernet
connected to built-in controller:
arm-softmmu/qemu-system-arm -smp 2 -m 1024 -machine mcimx7d-sabre
-nographic -serial mon:stdio -kernel <path to zImage> -dtb <path to
DTB> -device usb-ehci,id=ehci,bus="dw-pcie" -net
nic,model=imx.fec,netdev=lan0 -netdev
tap,id=lan0,ifname=tap0,script=no,downscript=no -append
"console=ttymxc0,115200 noinitrd pci=nomsi" -usb -drive
if=none,id=stick,file=<path to USB stick image>,format=raw

Also, I don't think anyone would try to do this, but just as a
warning, building QEMU with --enable-tcg-interpreter doesn't really
work that well (/init gets SIGKILLed every time), so I'd recommend
avoiding using that option.

Hopefully this is enough info, but if not, feel free to ask me more questions.

Thanks,
Andrey Smirnov


  parent reply	other threads:[~2019-04-16  2:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87d0mwatbu.fsf@dusky.pond.sub.org>
     [not found] ` <CAAdtpL6VCiXLbTWyJo4cbCNLjOCPr6KrH8KTqEq1V=CTMYKubQ@mail.gmail.com>
2019-04-12 11:11   ` [Qemu-devel] Maintainers, please tell us how to boot your machines! Thomas Huth
2019-04-12 11:11     ` Thomas Huth
2019-04-12 11:28     ` Philippe Mathieu-Daudé
2019-04-12 11:28       ` Philippe Mathieu-Daudé
2019-04-12 12:12       ` Thomas Huth
2019-04-12 12:12         ` Thomas Huth
2019-04-12 14:42         ` Thomas Huth
2019-04-12 14:42           ` Thomas Huth
2019-04-18  8:16   ` sundeep subbaraya
2019-04-18  8:16     ` sundeep subbaraya
2019-04-16  2:24 ` Andrey Smirnov [this message]
2019-04-16  2:24   ` Andrey Smirnov
2019-04-16  9:13 ` KONRAD Frederic
2019-04-16  9:13   ` KONRAD Frederic
2019-05-16 20:07 ` Philippe Mathieu-Daudé
2019-05-17 17:42   ` Markus Armbruster
2019-12-22 12:03     ` Philippe Mathieu-Daudé
2020-01-13 12:52       ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHQ1cqEDxNMeAGb5t4OrV9DWpq-VTn4GVhjQh4BePZv=JP8-Ow@mail.gmail.com' \
    --to=andrew.smirnov@gmail.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=Andrew.Baumann@microsoft.com \
    --cc=alistair@alistair23.me \
    --cc=amarkovic@wavecomp.com \
    --cc=andrew@aj.id.au \
    --cc=anthony.perard@citrix.com \
    --cc=antonynpavlov@gmail.com \
    --cc=arikalo@wavecomp.com \
    --cc=armbru@redhat.com \
    --cc=atar4qemu@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=b.galvani@gmail.com \
    --cc=balaton@eik.bme.hu \
    --cc=balrogg@gmail.com \
    --cc=borntraeger@de.ibm.com \
    --cc=chouteau@adacore.com \
    --cc=clg@kaod.org \
    --cc=cohuck@redhat.com \
    --cc=crwulff@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=deller@gmx.de \
    --cc=edgar.iglesias@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=green@moxielogic.com \
    --cc=gxt@mprc.pku.edu.cn \
    --cc=hpoussin@reactos.org \
    --cc=huth@tuxfamily.org \
    --cc=i.mitsyanko@gmail.com \
    --cc=jan.kiszka@web.de \
    --cc=jcd@tribudubois.net \
    --cc=jcmvbkbc@gmail.com \
    --cc=joel@jms.id.au \
    --cc=kbastian@mail.uni-paderborn.de \
    --cc=magnus.damm@gmail.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=marex@denx.de \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=michael@walle.cc \
    --cc=mst@redhat.com \
    --cc=palmer@sifive.com \
    --cc=pasic@linux.ibm.com \
    --cc=paul.durrant@citrix.com \
    --cc=pbonzini@redhat.com \
    --cc=pburton@wavecomp.com \
    --cc=peter.chubb@nicta.com.au \
    --cc=peter.maydell@linaro.org \
    --cc=proljc@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=robh@kernel.org \
    --cc=rth@twiddle.net \
    --cc=sagark@eecs.berkeley.edu \
    --cc=shorne@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=sundeep.lkml@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).