From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:49760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGDmT-0006Kj-UB for qemu-devel@nongnu.org; Mon, 15 Apr 2019 22:25:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGDmR-0008AH-SB for qemu-devel@nongnu.org; Mon, 15 Apr 2019 22:25:05 -0400 Received: from mail-it1-x142.google.com ([2607:f8b0:4864:20::142]:35044) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hGDmR-00089s-EZ for qemu-devel@nongnu.org; Mon, 15 Apr 2019 22:25:03 -0400 Received: by mail-it1-x142.google.com with SMTP id w15so30166384itc.0 for ; Mon, 15 Apr 2019 19:25:02 -0700 (PDT) MIME-Version: 1.0 References: <87d0mwatbu.fsf@dusky.pond.sub.org> In-Reply-To: <87d0mwatbu.fsf@dusky.pond.sub.org> From: Andrey Smirnov Date: Mon, 15 Apr 2019 19:24:49 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] Maintainers, please tell us how to boot your machines! List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: QEMU Developers , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , "Edgar E. Iglesias" , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , "Michael S. Tsirkin" , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Aleksandar Markovic , Aleksandar Rikalo , Alistair Francis , Alistair Francis , Andrew Baumann , Andrew Jeffery , Andrzej Zaborowski , Anthony Green , Anthony Perard , Antony Pavlov , Artyom Tarasenko , Aurelien Jarno , BALATON Zoltan , Bastian Koppelmann , Beniamino Galvani , Chris Wulff , Christian Borntraeger , Cornelia Huck , David Gibson , David Hildenbrand , Eduardo Habkost , Fabien Chouteau , Guan Xuetao , Halil Pasic , Helge Deller , Igor Mitsyanko , Jan Kiszka , Jean-Christophe Dubois , Jia Liu , Joel Stanley , Magnus Damm , Marcel Apfelbaum , Marek Vasut , Mark Cave-Ayland , Max Filippov , Michael Walle , Palmer Dabbelt , Paolo Bonzini , Paul Burton , Paul Durrant , Peter Chubb , Peter Maydell , Richard Henderson , Rob Herring , Sagar Karandikar , Stafford Horne , Stefano Stabellini , Subbaraya Sundeep , Thomas Huth On Tue, Mar 12, 2019 at 10:36 AM 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: <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 (odd fixer:MCIMX7D SABRE / i...) > Andrey Smirnov (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 -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=,format=raw -device usb-storage,bus=usb-bus.0,drive=stick -drive id=sd1,if=sd,format=file,file= -drive id=sd2,if=sd,format=file,file= -driv eid=sd3,if=sd,format=file,file= * 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 -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=,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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C6FAC10F0E for ; Tue, 16 Apr 2019 02:25:56 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 01CA720656 for ; Tue, 16 Apr 2019 02:25:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LjcMQaWw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01CA720656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([127.0.0.1]:58189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGDnG-0006jY-Po for qemu-devel@archiver.kernel.org; Mon, 15 Apr 2019 22:25:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGDmT-0006Kj-UB for qemu-devel@nongnu.org; Mon, 15 Apr 2019 22:25:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGDmR-0008AH-SB for qemu-devel@nongnu.org; Mon, 15 Apr 2019 22:25:05 -0400 Received: from mail-it1-x142.google.com ([2607:f8b0:4864:20::142]:35044) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hGDmR-00089s-EZ for qemu-devel@nongnu.org; Mon, 15 Apr 2019 22:25:03 -0400 Received: by mail-it1-x142.google.com with SMTP id w15so30166384itc.0 for ; Mon, 15 Apr 2019 19:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C4WY4+KH/Y32pUCUPCiLn9hS/Qlg5fDihtSALcM/5tY=; b=LjcMQaWwOGLYa6jiE+OOmmAMWq+xgLSSuhwM4JUf5nI4TaAILyZY34fJi1v+VTV0s9 BbAbDwUVL7F5wbPHzSzWKFczeYBcZZtnmrzB9lWlfIDxqEqZCxEP95pO+WBEvfnqHqLo bzAvWkIDHMV+0E7G9+RiinOaKMzd5tR/IA5YgMiWaK6QtRqcJJT1qDSOsaxEeuAfzqzO W7ORK4CtFNSiMshCPFlFXFjy0JhInku8veCx4nzXRINBWgbdYZJCz1GmZySCYhZjIyij X20np6rP75NNMnCzZoYqMqUhB+OXx/KhkbUs68K641te1oekSk/Gxoj7hmXMgZuxjfai MpYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C4WY4+KH/Y32pUCUPCiLn9hS/Qlg5fDihtSALcM/5tY=; b=YBGSOnN4Z6+qG4NWPJEBqd/aJDVXd5uhtSPABqMVIsy+eEVcMoKVH3G0i+Gc5fRSOB sKkMOHMvQnSqJPwv3vB8t3mrqA7PSysykffQQwrb6IShIMAknAUcMBcYu4Nb7En/EHjf cq7jnke/47D3JU9Adw2T6dipI1CWNWkjJ1xxdrIrXAf+vXKZPSr4bm1/BNkIQ4jjzzRl 38jJ4QgQ7nNFKXChgJLaIhLdyYwNFx6RH9lEBDd41EYPwqMPkmHUUWYtcoG6Rn2aDcrk EqsXiPb6SsjsH48/POdgHFg9SJ64SQxMuHOcPUeC12vu0lsFWfePJ+VSbdbxIcEGzL4Z iTCQ== X-Gm-Message-State: APjAAAUbcZFj8bniXtIb0fNAAI4hEbF9CosDOavoviRM2ZJT/RH/CywU cUEOg6pKUiLW951h1aV8u/Sdv039/IqAhA+UTT8= X-Google-Smtp-Source: APXvYqwDn3sdxFbCqbjkKGdlJutJqi9r6LYvsorY3AwS3DQDX1gRhFIGyPCkt0xOha7HCrRh+bN8EPqXVnT7iWfuWKM= X-Received: by 2002:a24:9a86:: with SMTP id l128mr26394790ite.126.1555381501407; Mon, 15 Apr 2019 19:25:01 -0700 (PDT) MIME-Version: 1.0 References: <87d0mwatbu.fsf@dusky.pond.sub.org> In-Reply-To: <87d0mwatbu.fsf@dusky.pond.sub.org> From: Andrey Smirnov Date: Mon, 15 Apr 2019 19:24:49 -0700 Message-ID: To: Markus Armbruster Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::142 Subject: Re: [Qemu-devel] Maintainers, please tell us how to boot your machines! X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paul Burton , Cornelia Huck , Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Anthony Green , Palmer Dabbelt , Mark Cave-Ayland , QEMU Developers , Max Filippov , Alistair Francis , "Edgar E. Iglesias" , Guan Xuetao , Peter Chubb , Marek Vasut , Rob Herring , Stefano Stabellini , Jia Liu , Aleksandar Rikalo , Helge Deller , David Hildenbrand , Magnus Damm , Halil Pasic , Christian Borntraeger , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Antony Pavlov , Anthony Perard , Richard Henderson , Artyom Tarasenko , Joel Stanley , Eduardo Habkost , Alistair Francis , Fabien Chouteau , Beniamino Galvani , Paul Durrant , Jan Kiszka , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Stafford Horne , Subbaraya Sundeep , David Gibson , Andrew Jeffery , Bastian Koppelmann , Chris Wulff , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Andrew Baumann , Jean-Christophe Dubois , Igor Mitsyanko , Michael Walle , Thomas Huth , Aleksandar Markovic , Paolo Bonzini , Aurelien Jarno Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20190416022449.vbAA71Qkrto7-_PfJKSTCwCrlZ2Gzgino5Y21uOLlzs@z> On Tue, Mar 12, 2019 at 10:36 AM 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: <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 (odd fixer:MCIMX7D SABRE / i...) > Andrey Smirnov (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 -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=,format=raw -device usb-storage,bus=usb-bus.0,drive=stick -drive id=sd1,if=sd,format=file,file= -drive id=sd2,if=sd,format=file,file= -driv eid=sd3,if=sd,format=file,file= * 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 -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=,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