From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by mx.groups.io with SMTP id smtpd.web11.253.1585601813697291999 for ; Mon, 30 Mar 2020 13:56:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=G48tO9In; spf=pass (domain: redhat.com, ip: 63.128.21.74, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585601812; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l1MCCt5/eXOi4NlXgQNEgYciBMfZCRddgEwkz1YyHZs=; b=G48tO9InEFPAJEXEhwwxqX1cFZqFBZMpotp+RzMlhjJ+c9/hfRDMzHvBwPHdhAUoCeWw3a BL+WOmftpeWOB/tG9zTuD8WY7LGE41zX9OLE+gF2wmfYa6IhJ3lYms8+xHnBZHv1IPiOAH 0yTenP6m9AIvJx5vsflsSP3ay+rXthM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-396-V-xfKB3JPrKSndvkr_oYrA-1; Mon, 30 Mar 2020 16:56:48 -0400 X-MC-Unique: V-xfKB3JPrKSndvkr_oYrA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 24E03107ACC7; Mon, 30 Mar 2020 20:56:47 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-191.ams2.redhat.com [10.36.112.191]) by smtp.corp.redhat.com (Postfix) with ESMTP id 552C85DA60; Mon, 30 Mar 2020 20:56:46 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg To: devel@edk2.groups.io, ard.biesheuvel@linaro.org, Sean Brogan References: <23240.1585588272916499438@groups.io> From: "Laszlo Ersek" Message-ID: <593a3ebf-bf0b-5c69-69b4-04e652e2ebf8@redhat.com> Date: Mon, 30 Mar 2020 22:56:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/30/20 19:44, Ard Biesheuvel wrote: > On Mon, 30 Mar 2020 at 19:11, Sean via Groups.Io > wrote: >> >> On Mon, Mar 30, 2020 at 10:04 AM, Ard Biesheuvel wrote: >> >> Is there any way I could contribute ArmVirtQemu to this? Or would it >> be easier if I provided comments/instructions? >> >> Either way. >> Any instructions you provide would be great. I was going to hack something up for feedback but happy for someone else to do it. Let me know. > > OK, so the typical invocation would be > > qemu-system-aarch64 -M virt -cpu cortex-a57 -m 1024 -net none > -nographic -bios .../path/to/QEMU_EFI.fd -hda > fat:rw:.../path/to/startup.nsh > > The only complication compared to OVMF is that there is no separate > serial port for debug output vs console output, so everything is going > to come out of the same pipe, and grep'ing the console output for > meaningful strings may easily result in false positives. (-pflash > could be used as well, but doesn't really add anything in this case, > and QEMU for ARM has a quirk where pflash images must be exactly 64 MB > in size) I'm begging you not to introduce instances of "-bios" anywhere near edk2. Please? :) We need to educate QEMU users, and we need to keep our sanity when facing bug reports. Let's not set bad examples anywhere, if we can manage. I think truncate(1) can do what we need for padding, without actually allocating those MBs. Thanks! Laszlo