[PATCH] .azurepipelines: Enable CI for OvmfPkg and EmulatorPkg


Zhang, Shenglei
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2570
OvmfPkg and EmulatorPkg are mostly used by the developers, so add
them to target list.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
---
.azurepipelines/templates/pr-gate-build-job.yml | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml b/.azurepipelines/templates/pr-gate-build-job.yml
index 61868554d43c..34f03745cc70 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -44,6 +44,12 @@ jobs:
TARGET_SECURITY:
Build.Pkgs: 'SecurityPkg'
Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_OVMF:
+ Build.Pkgs: 'OvmfPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_EMULATOR:
+ Build.Pkgs: 'EmulatorPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'

workspace:
clean: all
--
2.18.0.windows.1


Rebecca Cran
 

On 3/26/20 1:04 AM, Zhang, Shenglei wrote:

Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_OVMF:
+ Build.Pkgs: 'OvmfPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_EMULATOR:
+ Build.Pkgs: 'EmulatorPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
workspace:
clean: all
Should we build the NOOPT target as well?


--

Rebecca Cran


Ard Biesheuvel
 

(+ Laszlo)

On Thu, 26 Mar 2020 at 08:04, Zhang, Shenglei <shenglei.zhang@intel.com> wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2570
OvmfPkg and EmulatorPkg are mostly used by the developers, so add
them to target list.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Could we add ArmVirtPkg as well please? Also, which .DSCs are built
inside OvmfPkg/ with this change?

---
.azurepipelines/templates/pr-gate-build-job.yml | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml b/.azurepipelines/templates/pr-gate-build-job.yml
index 61868554d43c..34f03745cc70 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -44,6 +44,12 @@ jobs:
TARGET_SECURITY:
Build.Pkgs: 'SecurityPkg'
Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_OVMF:
+ Build.Pkgs: 'OvmfPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_EMULATOR:
+ Build.Pkgs: 'EmulatorPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'

workspace:
clean: all
--
2.18.0.windows.1




Zhang, Shenglei
 

Hi Mike,

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Thursday, March 26, 2020 4:43 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Zhang, Shenglei
<shenglei.zhang@intel.com>; Laszlo Ersek <lersek@redhat.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>; Bret Barkelew
<Bret.Barkelew@microsoft.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2-devel] [PATCH] .azurepipelines: Enable CI for OvmfPkg
and EmulatorPkg

(+ Laszlo)

On Thu, 26 Mar 2020 at 08:04, Zhang, Shenglei <shenglei.zhang@intel.com>
wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2570
OvmfPkg and EmulatorPkg are mostly used by the developers, so add
them to target list.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Could we add ArmVirtPkg as well please? Also, which .DSCs are built
inside OvmfPkg/ with this change?
Could you help answer this question?
I only see interfaces to include package level things.

Thanks,
Shenglei


---
.azurepipelines/templates/pr-gate-build-job.yml | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml
b/.azurepipelines/templates/pr-gate-build-job.yml
index 61868554d43c..34f03745cc70 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -44,6 +44,12 @@ jobs:
TARGET_SECURITY:
Build.Pkgs: 'SecurityPkg'
Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_OVMF:
+ Build.Pkgs: 'OvmfPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'
+ TARGET_EMULATOR:
+ Build.Pkgs: 'EmulatorPkg'
+ Build.Targets: 'DEBUG,RELEASE,NO-TARGET'

workspace:
clean: all
--
2.18.0.windows.1




Laszlo Ersek
 

(+Phil, +Anthony)

On 03/26/20 09:43, Ard Biesheuvel wrote:
(+ Laszlo)

On Thu, 26 Mar 2020 at 08:04, Zhang, Shenglei <shenglei.zhang@intel.com> wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2570
OvmfPkg and EmulatorPkg are mostly used by the developers, so add
them to target list.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Could we add ArmVirtPkg as well please? Also, which .DSCs are built
inside OvmfPkg/ with this change?
Thanks for the CC.

(1) Having learned that Sean and probably others do not benefit from
OvmfPkg, I do not wish to slow down PR gating for them, by making OVMF
builds a mandatory part of CI -- as long as the PR does not have a patch
that modifies OvmfPkg itself.

(I'm unsure if the above behavior is already ensured by the CI system --
if it is, then I'm sorry about the noise.)

Same applies (from my perspective) to ArmVirtPkg.

Obviously, I would definitely *like* if ArmVirtPkg / OvmfPkg builds were
a constant, mandatory part of CI, but I totally realize it would put an
unjustified burden on contributors that do not care about those
platforms at all -- especially given that the core package(s) being
patched -- such as NetworkPkg -- *are* test-built by CI in isolation anyway.


(2) In case the PR does modify OvmfPkg, and so the platform builds are
required, I would like the builds to cover more ground:

(2a) DEBUG, RELEASE and NOOPT should all be covered,

(2b) Ia32, Ia32X64, and X64 should all be covered.

(I've CC'd Anthony so he can speak to the "OvmfXen.dsc" build configs.)

(2c) For each of the three platforms I mention in (2b), there should be
a "bare bones" (default) build, but also a reasonably "full-blown" build.

- Bare-bones build:

-D FD_SIZE_2MB

(This is so that the default (bare-bones) configuration continue to fit
in the (arguably legacy) 2MB FD.)

- Full-blown build:

-D SECURE_BOOT_ENABLE \
-D SMM_REQUIRE \
-D TPM_ENABLE \
-D TPM_CONFIG_ENABLE \
-D NETWORK_TLS_ENABLE \
-D NETWORK_IP6_ENABLE \
-D NETWORK_HTTP_BOOT_ENABLE

Note that this will require the OpenSSL submodule to be initialized.

This means 3 * 3 * 2 = 18 builds thus far.


(3) ArmVirtPkg platforms should be built if either OvmfPkg or ArmVirtPkg
is modified.

Personally I'd like the ArmVirtQemu platform to be built, but Ard and
Anthony will likely ask for more.

For ArmVirtQemu, because we have no (i) different FD sizes, nor (b) an
SMM stack that makes some drivers strictly exclusive with other drivers,
I think we should simply aim at the most comprehensive build:

(3a) DEBUG, RELEASE and NOOPT,

(3b) Options:

-D SECURE_BOOT_ENABLE \
-D TPM2_ENABLE \
-D TPM2_CONFIG_ENABLE \
-D NETWORK_IP6_ENABLE \
-D NETWORK_HTTP_BOOT_ENABLE \
-D NETWORK_TLS_ENABLE

This means +3 builds (21 builds in total) from my perspective.

Thanks
Laszlo


Laszlo Ersek
 

On 03/27/20 15:36, Laszlo Ersek wrote:
(+Phil, +Anthony)

On 03/26/20 09:43, Ard Biesheuvel wrote:
(+ Laszlo)

On Thu, 26 Mar 2020 at 08:04, Zhang, Shenglei <shenglei.zhang@intel.com> wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2570
OvmfPkg and EmulatorPkg are mostly used by the developers, so add
them to target list.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Could we add ArmVirtPkg as well please? Also, which .DSCs are built
inside OvmfPkg/ with this change?
Thanks for the CC.

(1) Having learned that Sean and probably others do not benefit from
OvmfPkg, I do not wish to slow down PR gating for them, by making OVMF
builds a mandatory part of CI -- as long as the PR does not have a patch
that modifies OvmfPkg itself.

(I'm unsure if the above behavior is already ensured by the CI system --
if it is, then I'm sorry about the noise.)

Same applies (from my perspective) to ArmVirtPkg.

Obviously, I would definitely *like* if ArmVirtPkg / OvmfPkg builds were
a constant, mandatory part of CI, but I totally realize it would put an
unjustified burden on contributors that do not care about those
platforms at all -- especially given that the core package(s) being
patched -- such as NetworkPkg -- *are* test-built by CI in isolation anyway.


(2) In case the PR does modify OvmfPkg, and so the platform builds are
required, I would like the builds to cover more ground:

(2a) DEBUG, RELEASE and NOOPT should all be covered,

(2b) Ia32, Ia32X64, and X64 should all be covered.

(I've CC'd Anthony so he can speak to the "OvmfXen.dsc" build configs.)

(2c) For each of the three platforms I mention in (2b), there should be
a "bare bones" (default) build, but also a reasonably "full-blown" build.

- Bare-bones build:

-D FD_SIZE_2MB

(This is so that the default (bare-bones) configuration continue to fit
in the (arguably legacy) 2MB FD.)

- Full-blown build:

-D SECURE_BOOT_ENABLE \
-D SMM_REQUIRE \
-D TPM_ENABLE \
-D TPM_CONFIG_ENABLE \
-D NETWORK_TLS_ENABLE \
-D NETWORK_IP6_ENABLE \
-D NETWORK_HTTP_BOOT_ENABLE

Note that this will require the OpenSSL submodule to be initialized.

This means 3 * 3 * 2 = 18 builds thus far.


(3) ArmVirtPkg platforms should be built if either OvmfPkg or ArmVirtPkg
is modified.

Personally I'd like the ArmVirtQemu platform to be built, but Ard and
Anthony will likely ask for more.

For ArmVirtQemu, because we have no (i) different FD sizes, nor (b) an
SMM stack that makes some drivers strictly exclusive with other drivers,
I think we should simply aim at the most comprehensive build:

(3a) DEBUG, RELEASE and NOOPT,

(3b) Options:

-D SECURE_BOOT_ENABLE \
-D TPM2_ENABLE \
-D TPM2_CONFIG_ENABLE \
-D NETWORK_IP6_ENABLE \
-D NETWORK_HTTP_BOOT_ENABLE \
-D NETWORK_TLS_ENABLE

This means +3 builds (21 builds in total) from my perspective.
... to be clear: the above is my "wish list".

If, at the moment, we can enable OvmfPkg and ArmVirtPkg builds in any
shape or form whatsoever, that's already an improvement! So my comments
are not to be taken as disagreement with the currently proposed patch.
I'm just describing how I believe we should do these builds eventually.

Thanks
Laszlo


Sean
 

There are two parts of this I think should be discussed. 
1. Core-Ci for emulator, ovmf, armvirt packages. 
  a. I think there is some value here for those package maintainers.  The core ci does spell checks, char encoding checks, lib class declaration, etc.  Those seem valuable to help keep the package clean.    
  B. The core ci works on an assumption that the DSC builds every module within the package and for that I think you would want to create new DSC file in those packages that included every module in the package and used NULL libs to resolve as many dependencies as possible. That DSC would be only for Core CI.  

2. Platform Ci for emulator, ovmf, armvirt packages. 
  a. I think this is what we want long term.  It would compile the platform and ideally do boot testing and checks.  
  b. Platform Ci should scale out to all sorts of platforms (open and closed src) that want to register for CI and are willing to keep their platform current. 
  c. Should be a signal into the PR process.  I don't think it should block by policy, but reviewers should use the results to evaluate the impact of the PR. 
  d. I have setup a branch here with Platform CI.
       1. Code changes to enable pytool to build of OVMF and EmulatorPkg.  https://github.com/spbrogan/edk2/tree/ci-for-ovmf
       2. 4 pipelines here: https://dev.azure.com/tianocore/edk2-ci-play/_build?treeState=XEVtdWxhdG9yUGtnJFxPVk1G&view=folders
       3. OVMF GCC5: 8 builds.  see the matrix here https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4915&view=results and https://github.com/spbrogan/edk2/blob/ci-for-ovmf/.azurepipelines/platforms/Ovmf/Ubuntu-GCC5.yml#L22 .  This worked without issue.
      4.  OVMF VS2019: Same 8 builds.  Results here: https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4916&view=results and matrix file here https://github.com/spbrogan/edk2/blob/ci-for-ovmf/.azurepipelines/platforms/Ovmf/Windows-VS2019.yml#L22 .  The full build fails 2 of the "flavors".  See https://bugzilla.tianocore.org/show_bug.cgi?id=2636
      5. EmulatorPkg GCC: 2 builds.  https://dev.azure.com/tianocore/edk2-ci-play/_build?definitionId=39&_a=summary  IA32 fails so it currently only builds X64
      6. EmulatorPkg VS2019: 2 builds  https://dev.azure.com/tianocore/edk2-ci-play/_build?definitionId=40&_a=summary  IA32 fails so it currently only builds X64.  

Feedback wanted.   Happy to add more if there is some agreement that you like this direction.  

Also if you have ideas how to run the images and then exit from the shell with a status so we can tell success/failure that would be great.  

Thanks
Sean


Rebecca Cran
 

On 3/27/20 8:29 PM, Sean via Groups.Io wrote:


Feedback wanted.   Happy to add more if there is some agreement that you like this direction.

I see the OVMF build is running for example: /opt/hostedtoolcache/Python/3.8.2/x64/bin/stuart_build -c OvmfPkg/PlatformBuild.py TOOL_CHAIN_TAG=GCC5 TARGET=DEBUG -a X64


Can't it just run "build" (or, OvmfPkg/build.sh) directly without going through another script? I'm not sure the added complexity is worthwhile.


--
Rebecca Cran


Sean
 

"Stuart" gives the system a lot of structure and flexibility.  It lets us maintain the build process consistently in a cross platform way and allows platforms to use python instead of shell scripting.  This takes advantage of our investments in dependency management, optimized submodule management, logging, plugins, etc.  OVMF is a pretty simple "platformbuild" but it still get many advantages (from my pov). 

We have talked about Stuart a few times at design meetings (so you can see some of the slides that have been uploaded) and willing to discuss more if you have specific questions.  

Thanks
Sean


Sean
 

Added support for EmulatorPkg running to UEFI shell.  
Segmentation fault on GCC / Ubuntu x64.  Works on Windows.  

Could very easily be user error.
https://bugzilla.tianocore.org/show_bug.cgi?id=2639

Laszlo - can you point me to any docs, scripts, examples of how i would do the same thing with OVMF (just don't want to re-invent the wheel)? 

Thanks
Sean


Ard Biesheuvel
 

On Sat, 28 Mar 2020 at 20:29, Sean via Groups.Io
<sean.brogan=microsoft.com@groups.io> wrote:

Added support for EmulatorPkg running to UEFI shell.
Segmentation fault on GCC / Ubuntu x64. Works on Windows.

Could very easily be user error.
https://bugzilla.tianocore.org/show_bug.cgi?id=2639

Laszlo - can you point me to any docs, scripts, examples of how i would do the same thing with OVMF (just don't want to re-invent the wheel)?
Hello Sean,

Thanks a lot for taking the time to work on this. IMO, having a CI
smoke test that boots, say, an X64 as well as a AARCH64 virtual
platform to the UEFI shell is extremely valuable, and given how little
time it should take to run this test after doing the build, I would
argue for it to be incorporated as a pre-commit check. (Background:
the situation is much better than it was, but for a long time, being a
maintainer of the ARM pieces in EDK2 was no fun, given how often the
build got broken by people working on [and limiting their testing to]
X64 platforms)


Sean
 

Ard,
I agree.  How would we do this with AARCH64?  I don't believe azure devops pipelines has a native AARCH64 platform available.  I briefly looked over ArmVirtPkg but not sure where to start. OVMF readme only talks about ia32/x64.  I could also see a scenario for a self hosted agent that is aarch64 but that would require learning that aspect of devops (on the list but not at the top yet).  Anyway look forward to ideas and discussion.  

Thanks
Sean


Ard Biesheuvel
 

On Sat, 28 Mar 2020 at 22:47, Sean via Groups.Io
<sean.brogan=microsoft.com@groups.io> wrote:

Ard,
I agree. How would we do this with AARCH64? I don't believe azure devops pipelines has a native AARCH64 platform available. I briefly looked over ArmVirtPkg but not sure where to start. OVMF readme only talks about ia32/x64. I could also see a scenario for a self hosted agent that is aarch64 but that would require learning that aspect of devops (on the list but not at the top yet). Anyway look forward to ideas and discussion.
OVMF and ArmVirtQemu are very similar, in this regard: they require a
matching version of QEMU: qemu-system-x86_64 for OVMF, and
qemu-system-aarch64 for ArmVirtQemu, and I would expect most distros
that carry either to carry both. Note that this will not require a
native host - QEMU will use emulation if KVM acceleration is not
available.

*If* a native host is available that supports KVM, running the smoke
test with KVM acceleration would definitely be preferred, especially
on AARCH64, for reasons I pointed out earlier in this thread: the QEMU
emulator is less strict than bare metal, and so issues related to
cache maintenance or unaligned accesses to device mappings will only
be caught when using KVM. KVM is also significantly faster, although I
wouldn't expect that to matter for a boot-to-shell smoke test.

I also think that having the EmulatorPkg based smoke test is already a
huge step up from the current situation. But for changes to ArmPkg and
ArmPlatformPkg, we need something on top of that, given that
EmulatorPkg does not cover those at all.


Sean
 

Ard/Laszlo or anyone familiar with QEMU.

I read up on the ovmf readme and the qemu wiki but still have a few issues i am hoping for quick/easy answers. 

1. How do i programmatically exit the emulator.   Seems like uefi shell > reset just reboots.  Other ideas?  
2. Is there an easy way to map a local file system so that i can setup a startup.nsh?  

Thanks
Sean


Andrew Fish
 



On Mar 29, 2020, at 4:16 PM, Sean via Groups.Io <sean.brogan@...> wrote:

Ard/Laszlo or anyone familiar with QEMU.

I read up on the ovmf readme and the qemu wiki but still have a few issues i am hoping for quick/easy answers. 

1. How do i programmatically exit the emulator.   Seems like uefi shell > reset just reboots.  Other ideas?  

I'd like to know the answer to this too. I've ended up using gdb/lldb to kill it. Can you just kill the process after the test completes from the thread that is processing test results? 

2. Is there an easy way to map a local file system so that i can setup a startup.nsh?  


I think you can mount a dir as a FAT32 disk by passing this to QEMU `-drive file=fat:rw:c:\Exchange,format=raw,media=disk`

Thanks,

Andrew Fish

Thanks
Sean


Ard Biesheuvel
 

On Mon, 30 Mar 2020 at 01:16, Sean via Groups.Io
<sean.brogan=microsoft.com@groups.io> wrote:

Ard/Laszlo or anyone familiar with QEMU.

I read up on the ovmf readme and the qemu wiki but still have a few issues i am hoping for quick/easy answers.

1. How do i programmatically exit the emulator. Seems like uefi shell > reset just reboots. Other ideas?
'reset' is supposed to do that. Use 'reset -s' to kill the VM

2. Is there an easy way to map a local file system so that i can setup a startup.nsh?
As Andrew points out, use '-hda fat:<path>' and it will be exposed to
the VM as a FAT formatted block device.


Sean
 

Thanks.  I was missing the "-s" and Andrew you solution worked for the filesystem. 

OVMF: Windows builds and Linux builds and boot to shell. IA32, X64 and IA32x64 - https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4950&view=results 
Emulator: Windows and linux builds and boots to shell.  https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4922&view=results https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4921&view=results 

Src: Needs commit cleanup but its all here. https://github.com/spbrogan/edk2/tree/ci-for-ovmf 

Still have a few loose ends on Windows pipeline
1. Windows isn't able to find the QEMU i installed so it is failing to run the emulator.


Ard Biesheuvel
 

On Mon, 30 Mar 2020 at 11:31, Sean via Groups.Io
<sean.brogan=microsoft.com@groups.io> wrote:

Thanks. I was missing the "-s" and Andrew you solution worked for the filesystem.

OVMF: Windows builds and Linux builds and boot to shell. IA32, X64 and IA32x64 - https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4950&view=results
Emulator: Windows and linux builds and boots to shell. https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4922&view=results https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4921&view=results

Src: Needs commit cleanup but its all here. https://github.com/spbrogan/edk2/tree/ci-for-ovmf

Still have a few loose ends on Windows pipeline
1. Windows isn't able to find the QEMU i installed so it is failing to run the emulator.

Excellent!

It should be trivial to extend this to ARM, using TCG emulation.

One question though: what happens if the boot does not make it to the
shell, and crashes for some reason? The QEMU process will hang, so I'd
assume some kind of timeout should be applied?


Sean
 

On Mon, Mar 30, 2020 at 02:36 AM, Ard Biesheuvel wrote:
It should be trivial to extend this to ARM, using TCG emulation.

One question though: what happens if the boot does not make it to the
shell, and crashes for some reason? The QEMU process will hang, so I'd
assume some kind of timeout should be applied?
It has a 1 minute timeout and then the build will kill the process.  

The bootlog is uploaded in all cases so you can then look at the log.  
Here is an example where i didn't configure QEMU right: https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4942&view=logs&j=6fb09fdb-58e7-5b12-0698-873f788bd2e9&t=e63402bd-99b5-5ddd-38f9-868e9402ecc0

And the last lines in the bootlog.txt show

MaxCpuCountInitialization: BootCpuCount=1 mMaxCpuCount=1
Q35BoardVerification: no TSEG (SMRAM) on host bridge DID=0x1237; only DID=0x29C0 (Q35) is supported
ASSERT /home/vsts/work/1/s/OvmfPkg/PlatformPei/Platform.c(564): ((BOOLEAN)(0==1))





Ard Biesheuvel
 

On Mon, 30 Mar 2020 at 19:01, Sean via Groups.Io
<sean.brogan=microsoft.com@groups.io> wrote:

On Mon, Mar 30, 2020 at 02:36 AM, Ard Biesheuvel wrote:

It should be trivial to extend this to ARM, using TCG emulation.

One question though: what happens if the boot does not make it to the
shell, and crashes for some reason? The QEMU process will hang, so I'd
assume some kind of timeout should be applied?

It has a 1 minute timeout and then the build will kill the process.

The bootlog is uploaded in all cases so you can then look at the log.
Here is an example where i didn't configure QEMU right: https://dev.azure.com/tianocore/edk2-ci-play/_build/results?buildId=4942&view=logs&j=6fb09fdb-58e7-5b12-0698-873f788bd2e9&t=e63402bd-99b5-5ddd-38f9-868e9402ecc0

And the last lines in the bootlog.txt show

MaxCpuCountInitialization: BootCpuCount=1 mMaxCpuCount=1
Q35BoardVerification: no TSEG (SMRAM) on host bridge DID=0x1237; only DID=0x29C0 (Q35) is supported
ASSERT /home/vsts/work/1/s/OvmfPkg/PlatformPei/Platform.c(564): ((BOOLEAN)(0==1))
OK, great. So we're all set :-)

Is there any way I could contribute ArmVirtQemu to this? Or would it
be easier if I provided comments/instructions?