Created attachment 1556789 [details]
vm dumpxml

Created attachment 1556790 [details]
ps aux

show the qemu command virt-manager issued to start the VM

Created attachment 1556791 [details]
journal excerpt

journalctl -f, and then turn on the VM (button with the play icon) this is everything recorded over 5 minutes of black screen

Curiously, this exact same machine was running virt-manager just fine with both Fedora 28 and Fedora 29 and each of those upgraded (dnf system-upgrade) to Fedora 30.

Only the clean install of Fedora 30 is failing to work.

Whenever I set memory to 2560, this happens. If I change it to 2048 or 3072 the problem doesn't happen. A value of 2560 works fine on a Fedora 29 Server.

Anyway, it's either a regression bug in qemu, I guess? Or if it's now the correct behavior, then it's a bug in virt-manager for letting me enter an invalid value.

Thanks for the report. Sounds strange indeed having a specific memory value tickling this. I'll try to reproduce

I can reproduce. It seems to be the combo of machine=q35 and edk2/uefi and the memory value. I tested both edk2-20190308stable-1.fc30 and older edk2-20180815gitcb5f4f45ce-5.fc30

With memory=2560, q35 + edk2 fails (no tianocore splash screen). q35+seabios and pc+edk2 work. With memory=2048 I don't see any failure. Other non-round memory values seem to tickle it too but I didn't investigate thoroughly

I was testing with qemu-4.0.0-0.4.rc1.fc30.x86_64 which is newer, so 3.1 and 4.0 are affected. VM config was roughly similar to what Chris posted above.

Laszlo have you heard of an issue like this?

Yes, this is a known issue, and as much as I dislike it, it is
unfixable. Please use memory sizes that work.

For details, please refer to bug 1666941 (up to and including
bug 1666941 comment 13). The short version is that there are two
problems with arbitrary memory sizes:
(a) PCIEXBAR placement disagreement between QEMU and OVMF,
(b) MTRR configuration.

Problem (a) is fixable (you can find the patches in
bug 1666941 comment 14), but fixing just (a) is insufficient, to remove
the symptom.

Problem (b) is unfixable (see bug 1666941 comment 13). If a small RAM
size is needed, please pick one that works, e.g. from the following
list:
-  512 MB
-  768 MB
- 1024 MB
- 1536 MB
- 2048 MB
- 3072 MB
- 4096 MB

My apologies.

Thanks Laszlo, that's interesting. If this is CANTFIX at the edk2 level then IMO we need to do something at a higher level, the failure scenario here of 'black screen VM that doesn't work' is horrible and going to generate lots of bug reports I imagine. Maybe libvirt or qemu can catch this situation and error for starters. I'll start a thread internally, I'm sure someone can come up with some clever idea.

https://bugzilla.redhat.com/show_bug.cgi?id=1666941#c20

Upstream commits:

$ git log --oneline --reverse 3b7a897cd8e3..39b9a5ffe661 | cat -n
     1  60e95bf5094f OvmfPkg/PlatformPei: assign PciSize on both i440fx/q35 branches explicitly
     2  9a2e8d7c65ef OvmfPkg/PlatformPei: hoist PciBase assignment above the i440fx/q35 branching
     3  75136b29541b OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR on q35
     4  39b9a5ffe661 OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits clear

Cole, Gerd, Paolo, in place of picking the above patches, you might want
to rebase edk2 to the upcoming edk2-stable201905 release.

  Date (00:00:00 UTC-8)  Description
  ---------------------  ------------------------
  2018-03-08 (12PM)      Beginning of development
  2019-05-17             Soft Feature Freeze
  2019-05-24             Hard Feature Freeze
  2019-05-31             Release

Whenever you rebase to edk2-stable201905, please remember that the
following "-D" build flags have been renamed:

- HTTP_BOOT_ENABLE --> NETWORK_HTTP_BOOT_ENABLE
- TLS_ENABLE       --> NETWORK_TLS_ENABLE

Due to <https://bugzilla.tianocore.org/show_bug.cgi?id=1293>.


Other upstream BZs fixed in this release that are important for
ArmVirtQemu and/or OVMF are listed below. (Note that the upstream list
of proposed BZs that I'm picking the below from is not final yet --
check at <https://github.com/tianocore/edk2/releases/> once the upstream
release has been cut.)

* Update OpenSSL version to upcoming 1.1.1
  https://bugzilla.tianocore.org/show_bug.cgi?id=1089

  Downstream TODO: use Fedora's "OpenSSL-1.1.1b".

  (This upstream BZ might not make the edk2-stable201905 release.)

* Replace BSD 2-Clause License with BSD + Patent Licence
  https://bugzilla.tianocore.org/show_bug.cgi?id=1373

  Downstream TODO: update License tags in the spec file. The short name
  "BSD" should be replaced with "BSD-2-Clause-Patent" -- see at
  <https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses>.
  Edk2 code covered by different licenses such as MIT is not affected by
  this re-licensing.

* Upstream the EnrollDefaultKeys application to OvmfPkg
  https://bugzilla.tianocore.org/show_bug.cgi?id=1747

  Downstream TODO:

  - Drop the downstream-only patch adding EnrollDefaultKeys.

  - Open a ticket with <secalert> so that they send you the
    self-signed X509 certificate for the following entity, in PEM
    format:

    "Red Hat Secure Boot (PK/KEK key 1)/emailAddress=secalert"
    SHA1: fdfc7f3c7ef3e05776add79878216c9be0e19597
    SHA256: 7f122fab825041c2b0c67696bb151db6f39fed7df2d1104107f5b892b354ef5c

    (I'm going to attach the same for convenience, but verify with
    ProdSec, just to be sure.)

    Package this certificate as another source file in the SRPM.

  - Refer to the "sed" command in
    <https://bugzilla.tianocore.org/show_bug.cgi?id=1747#c2> for
    extracting the raw base64 string from the PEM-encoded certificate,
    in the spec file.

  - Refer to <https://bugzilla.tianocore.org/show_bug.cgi?id=1747#c7>
    for passing the string to QEMU, when you launch
    "EnrollDefaultKeys.efi", also in the spec file.

Thanks.

Created attachment 1569795 [details]
"Red Hat Secure Boot (PK/KEK key 1)", for comment 12

Thanks for the work Laszlo! I'm fine with waiting for the stable release

(In reply to Laszlo Ersek from comment #12)

> * Upstream the EnrollDefaultKeys application to OvmfPkg
>   https://bugzilla.tianocore.org/show_bug.cgi?id=1747
> 
>   Downstream TODO:
> 
>   - Drop the downstream-only patch adding EnrollDefaultKeys.
> 
>   - Open a ticket with <secalert> so that they send you the
>     self-signed X509 certificate for the following entity, in PEM
>     format:
> 
>     "Red Hat Secure Boot (PK/KEK key 1)/emailAddress=secalert"
>     SHA1: fdfc7f3c7ef3e05776add79878216c9be0e19597
>     SHA256: 7f122fab825041c2b0c67696bb151db6f39fed7df2d1104107f5b892b354ef5c
> 
>     (I'm going to attach the same for convenience, but verify with
>     ProdSec, just to be sure.)
> 
>     Package this certificate as another source file in the SRPM.
> 
>   - Refer to the "sed" command in
>     <https://bugzilla.tianocore.org/show_bug.cgi?id=1747#c2> for
>     extracting the raw base64 string from the PEM-encoded certificate,
>     in the spec file.
> 
>   - Refer to <https://bugzilla.tianocore.org/show_bug.cgi?id=1747#c7>
>     for passing the string to QEMU, when you launch
>     "EnrollDefaultKeys.efi", also in the spec file.

It's also necessary to use qemu-ovmf-secureboot @ commit f158f12be754 ("Pass OEM Strings to the guest", 2019-05-21) or later, for this.

https://github.com/puiterwijk/qemu-ovmf-secureboot/commit/f158f12be75482489b64330f7c5ee8b8138f04c7

Thanks.

Another note on the rebase to edk2-stable201905: edk2 has gained a new git submodule, namely "SoftFloat" (<https://github.com/ucb-bar/berkeley-softfloat-3.git>). This should be added as another tarball (= source file) in the SRPM, most likely.

edk2-stable201905 has been released today.

https://github.com/tianocore/edk2/releases/tag/edk2-stable201905

FEDORA-2019-d47a9d4b8b has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d47a9d4b8b

edk2-20190501stable-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d47a9d4b8b

edk2-20190501stable-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.