qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!


From: Andrew Jeffery
Subject: Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!
Date: Tue, 12 Mar 2019 19:19:04 -0400
User-agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5


On Wed, 13 Mar 2019, at 07:07, Cédric Le Goater wrote:
> On 3/12/19 6:36 PM, Markus Armbruster 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: <address@hidden>
> >   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/alpha/dp264.c =
> >     Richard Henderson <address@hidden> (maintainer:Alpha Machines)
> > 
> >     = hw/arm/aspeed.c =
> >     "Cédric Le Goater" <address@hidden> (maintainer:ASPEED BMCs)
> >     Peter Maydell <address@hidden> (maintainer:ASPEED BMCs)
> >     Andrew Jeffery <address@hidden> (reviewer:ASPEED BMCs)
> >     Joel Stanley <address@hidden> (reviewer:ASPEED BMCs)
> >     address@hidden (open list:ASPEED BMCs)
> 
> I have checked the URLs but they could change in the future :
> 
> * palmetto-bmc
> 
>   
> https://openpower.xyz/job/openbmc-build/lastSuccessfulBuild/distro=ubuntu,label=builder,target=palmetto/artifact/deploy/images/palmetto/flash-palmetto
> 
>   qemu-system-arm -m 512 -M palmetto-bmc -net 
> nic,macaddr=C0:FF:EE:00:00:01,model=ftgmac100 -net 
> user,id=netdev0,hostfwd=::2222-:22,hostname=ast1 -drive 
> file=flash-palmetto,format=raw,if=mtd -nographic
> 
> * romulus-bmc
> 
>   
> https://openpower.xyz/job/openbmc-build/lastSuccessfulBuild/distro=ubuntu,label=builder,target=romulus/artifact/deploy/images/romulus/flash-romulus
> 
>   qemu-system-arm -m 512 -M romulus-bmc -net 
> nic,macaddr=C0:FF:EE:00:00:01,model=ftgmac100 -net 
> user,id=netdev0,hostfwd=::2222-:22,hostname=ast1 -drive 
> file=flash-romulus,format=raw,if=mtd -nographic
> 
> * ast2500-evb
> 
>   
> https://openpower.xyz/job/openbmc-build/lastSuccessfulBuild/distro=ubuntu,label=builder,target=evb-ast2500/artifact/deploy/images/evb-ast2500/flash-evb-ast2500
> 
>   qemu-system-arm -m 512 -M ast2500-evb -net 
> nic,macaddr=C0:FF:EE:00:00:01,model=ftgmac100 -net 
> user,id=netdev0,hostfwd=::2222-:22,hostname=ast1 -drive 
> file=flash-evb-ast2500,format=raw,if=mtd -nographic
> 
> * witherspoon-bmc
> 
>   
> https://openpower.xyz/job/openbmc-build/lastSuccessfulBuild/distro=ubuntu,label=builder,target=witherspoon/artifact/deploy/images/witherspoon/obmc-phosphor-image-witherspoon.ubi.mtd
> 
>   qemu-system-arm -m 512 -M witherspoon-bmc -net 
> nic,macaddr=C0:FF:EE:00:00:01,model=ftgmac100 -net 
> user,id=netdev0,hostfwd=::2222-:22,hostname=ast1 -drive 
> file=obmc-phosphor-image-witherspoon.ubi.mtd,format=raw,if=mtd 
> -nographic

Currently these images are quite slow to boot; this is an issue with the ASPEED 
timer model not enforcing a minimum period (qemu ends up spending more time 
handling host timer interrupts and executing the timer model irq handler than 
executing guest code). I have some incomplete patches that implement the 
minimum support we need to boot mainline Linux without undue delay. I'll try to 
send them out today.

Andrew

> 
> [ ... ]
> 
> >     = hw/ppc/pnv.c =
> >     David Gibson <address@hidden> (maintainer:PowerPC)
> >     address@hidden (open list:PowerPC)
> 
> * POWER8 
> 
>   
> https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=palmetto/lastSuccessfulBuild/artifact/images/rootfs.cpio.xz
> 
>   
> https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=palmetto/lastSuccessfulBuild/artifact/images/zImage.epapr
> 
>   qemu-system-ppc64 -m 2G -machine powernv -cpu POWER8  -kernel 
> ./zImage.epapr -initrd ./rootfs.cpio.xz -nographic
> 
> * POWER9 
> 
>   needs a skiboot update.
> 
> Thanks, 
> 
> C.
> 
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]