From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by mx.groups.io with SMTP id smtpd.web10.839.1585603379170658618 for ; Mon, 30 Mar 2020 14:22:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=n39mMy96; spf=pass (domain: linaro.org, ip: 209.85.221.68, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wr1-f68.google.com with SMTP id a25so23516309wrd.0 for ; Mon, 30 Mar 2020 14:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wlcviJLyjOi+kAwKbBP4hwSFHM1hBqnPtrq9BffUPU4=; b=n39mMy960txrleyEt4NgLyJDnkZkCbbH5ynuqYkvR/uqhnIdMBcjCScfnqEI57zgUB M18kCfUtjSylc6bzvzRO84Lk4AH8eGikp2pIOmqKaHIIrJOpBaY/MBzqoQ0zXSpmjBWb /V8QofIJhEg3+0hXktCikDu5Q/kYlI7HL66E/FdlbKFOYqxKwuGLO0T3pIeRKMQ8+F4K Nt9TNG0Uy8eTStSAL5XN5wV2jy2Pp1/4VFAwLvJzGoF38pXlKS5KY7wEMOxKWLWnBLOb 4L4PgHWwSN1tAIqm/PabtvIlomu52SWN4CNGYKp2rODxwx4mtG39vcnre4X79GJf3Y8z KpmQ== 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=wlcviJLyjOi+kAwKbBP4hwSFHM1hBqnPtrq9BffUPU4=; b=aIbiEXL3969onSaP6ywfrZf8VPHDQuNafdZdz5eFmtdg02gM8cnE2j8dDnQehnOI91 o1gJf9ZZW68oXpWE+6mxwa6tNh/AapPST+BiyG1/YZAT/9epFxF/e+1zWNfktsLUSXQD aeLON29FE/CeXct0wdzI9xHkUNzHv37CzB5Lzk1yEArI9e2VW1LZU+cp2+RGQnf8078X uM9fsW8zG2pspikuzWNUq9CiOVfNtdtqsQXqtT+ELMyWI1nSsuK0kL7fpaWPpO8LuSIq jzr0m0iTtqXTNZk+jhaiBj5qgevZzJ1D6RqB8kDVio7gATHv9/6ZffLsvAz/BLxAYX2C BGdA== X-Gm-Message-State: ANhLgQ0p9rtBaIKGSF0l8ESzqG4ptNIXEqVOUYvf76njfByPoh8fqrJH 2Q/7Z6/vYeIC1SJU7bJbD/Lv8tj3K13jfUXSght1KQ== X-Google-Smtp-Source: ADFU+vu/rOZTqX5oiTV2ZcWIS7F9PdYJG66gSvQFKHPhzLFb4vDig9wD/i5ZMMt7aVVICR8qkS3XZNBY2vK5RhRwHfI= X-Received: by 2002:a5d:4fcf:: with SMTP id h15mr16713553wrw.262.1585603377706; Mon, 30 Mar 2020 14:22:57 -0700 (PDT) MIME-Version: 1.0 References: <23240.1585588272916499438@groups.io> <593a3ebf-bf0b-5c69-69b4-04e652e2ebf8@redhat.com> In-Reply-To: <593a3ebf-bf0b-5c69-69b4-04e652e2ebf8@redhat.com> From: "Ard Biesheuvel" Date: Mon, 30 Mar 2020 23:22:46 +0200 Message-ID: Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg To: Laszlo Ersek Cc: edk2-devel-groups-io , Sean Brogan Content-Type: text/plain; charset="UTF-8" On Mon, 30 Mar 2020 at 22:56, Laszlo Ersek wrote: > > 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. > truncate should work on Linux, but I have no idea how to pad an image to a certain size on Windows, and I think the idea was to enable both? In any case, I don't feel as strongly about this as Laszlo does: even though -bios really shouldn't be used when you are actually installing an OS into the VM, I don't think it is inappropriate for booting into a shell and nothing else. Perhaps we could annotate the scripts in a way that discourages people from adopting it? Or if there is an easy way to make this work on both Windows and Linux using -pflash, I obviously wouldn't mind. I just don't feel it is essential.