[Bug 1918917] Re: synchronous abort on accessing unused I/O ports on aarch64

** Summary changed: - synchronous about on accessing unused I/O ports on aarch64 + synchronous abort on accessing unused I/O ports on aarch64 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1918917

[Bug 1685526] Re: UEFI firmware can't write to "fake" FAT hard disk

Out of scope; please see my (independent, more recent) replies here: [edk2-devel] OVMF/QEMU shell based unit tests and writing to a virtual disk https://edk2.groups.io/g/devel/message/66655 https://edk2.groups.io/g/devel/message/66656 (alternative links:

[Bug 1852196] Re: update edk2 submodule & binaries to edk2-stable202008

** Description changed: - edk2-stable202005 has been tagged: + Consume the following upstream edk2 releases: -   https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release- - Planning + https://github.com/tianocore/edk2/releases/tag/edk2-stable201908 +

[Bug 1852196] Re: update edk2 submodule & binaries to edk2-stable202008

Posted * [qemu-devel] [PATCH 00/10] edk2: adopt the edk2-stable202008 release 20200908072939.30178-1-lersek@redhat.com">http://mid.mail-archive.com/20200908072939.30178-1-lersek@redhat.com -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

[Bug 1852196] Re: update edk2 submodule & binaries to edk2-stable202005

** Changed in: qemu Assignee: Philippe Mathieu-Daudé (philmd) => Laszlo Ersek (Red Hat) (lersek) ** Summary changed: - update edk2 submodule & binaries to edk2-stable202005 + update edk2 submodule & binaries to edk2-stable202008 -- You received this bug notification

[Bug 1813165] Re: KVM internal error. Suberror: 1 emulation failure

According to comment #12, the bug underlying this LP ticket was fixed in Linux kernel commit ad7dc69aeb23 ("x86/kvm/mmu: fix switch between root and guest MMUs", 2019-02-22), released in v5.0. ** Project changed: qemu => linux ** Changed in: linux Status: New => Fix Released -- You

[Bug 1723927] Re: Linux or windows guest boot failed by uefi on CPU of Intel Xeon X5675

Closing due to almost 3 years of inactivity. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1723927 Title: Linux or windows guest boot failed by

[Bug 1778350] Re: Android-x86 4.4-r5 won't boot on QEMU since v2.11.0-rc2

No feedback for almost two years, closing. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1778350 Title: Android-x86 4.4-r5 won't boot on QEMU

[Bug 1217339] Re: SIGQUIT to send ACPI-shutdown to Guest

The discussion noted in comment#4 petered out in March 2017. Closing this ticket as "Invalid" (only because LP does not let me use the "Won't Fix" resolution -- the report / feature request may very well have had merit, but apparently a good enough design could not be found). ** Changed in: qemu

[Bug 1529449] Re: serial is required for -device nvme

No new developments for 4+ years, closing as invalid (I'd prefer "wontfix due to lack of resources", but I'm unable to pick that resolution). ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed

[Bug 893208] Re: qemu on ARM hosts can't boot i386 image

The qemu-linaro project seems to have been discontinued; the wiki and git repo links at don't work, and the latest release seems to be "qemu-linaro-1.7.0-2014.01.tar.gz". Marking this ticket as "invalid" for the qemu-linaro project. ** Changed in: qemu-linaro

[Bug 1886602] Re: Windows 10 very slow with OVMF

** Changed in: qemu Status: Incomplete => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886602 Title: Windows 10 very slow with OVMF Status in QEMU: Invalid Bug description:

[Bug 1658634] Re: Can't get correct display with latest QEMU and OVMF BIOS

Fixed in commit 3ef0c573d37b ("console: fix console resize", 2017-01-31), released in v2.9.0. ** Changed in: qemu Status: Confirmed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1826200] Re: RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files

We'll probably never have resources for this -- nice to have feature, but has not become critical in ~1.5 years. LP doesn't allow me to close the ticket as "Won't Fix", so I'll have to go with "Invalid". (The report is not invalid at all, but the ticket status should *somehow* reflect that we have

[Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

No need to keep this open any longer (no activity for 19 months). Please follow the links captured above to the past discussions. There's nothing new to add wrt. the situation. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Can we close this ticket now? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest filesystem after new vm install Status in QEMU: New Bug description:

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Commit 5e9785505210 was released in v4.2.0; closing this ticket. ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1846427 Title:

[Bug 1858814] Re: 'make -C roms efi' does not update edk2 submodules

Symptom persists as of v5.1.0, but I don't think it really matters. We should close the ticket as wontfix. ** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1888971] Re: SMI trigger causes hang with multiple cores

Inactive for ~two weeks, closing. ** Changed in: qemu Status: New => Incomplete ** Changed in: qemu Status: Incomplete => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1888971

[Bug 1886602] Re: Windows 10 very slow with OVMF

Inactive for more than a month, significant amount of info was not provided. Closing. ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886602

[Bug 1888971] Re: SMI trigger causes hang with multiple cores

> I guess fundamentally th issue is writing 0xXX in IO port 0xB2 should > trigger SMI handler in all possible core but instead it triggers SMI > only in Core#0. For that, the guest needs to negotiate the "broadcast SMI" feature with QEMU. See commit range 57bb40c9db40..b8bab8eb6934. -- You

[Bug 1888971] Re: SMI trigger causes hang with multiple cores

Does coreboot do anything to set up an SMI handler? Does it relocate SMBASE for all processors? Misbehavior upon raising an SMI is fully expected, unless the guest (usually the guest firmware) sets up SMI handling properly. The bug report currently includes only two bits of information about

[Bug 1886602] Re: Windows 10 very slow with OVMF

Sorry, no input from me. OVMF is apparently from November 2018, and QEMU is version 3.1. Please try to reproduce with recent upstream components (build both OVMF and QEMU from source), and if the issue persists, please provide the complete QEMU command line, capture the OVMF debug log (see

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

Hi Vlad, the ipxe-qemu package in Ubuntu (1.0.0+git-20190109.133f4c4-0ubuntu3) is built with DOWNLOAD_PROTO_HTTPS enabled (in "src/config/general.h"). According to the Ubuntu changelog, this is a new feature added in "1.0.0+git-20190109.133f4c4-0ubuntu1". With DOWNLOAD_PROTO_HTTPS enabled, I can

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

(From the UEFI executable name "82540em.efi" in the log, I initially suspected an assigned physical NIC with a buggy flashed-on oprom. But grepping the iPXE tree for "82540em" yields a match, and QEMU loads the iPXE oproms by default into the emulated NICs' ROM BARs.) -- You received this bug

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

Vladislav, The OVMF debug log ends like this (with UEFI protocol GUIDs decoded as their textual identifiers in edk2): > [Security] 3rd party image[6D19D18] can be loaded after EndOfDxe: > PciRoot(0x0)/Pci(0x3,0x0)/Offset(0x16400,0x4B1FF). > InstallProtocolInterface: [EfiLoadedImageProtocol]

[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios

Please add -debugcon file:debug.log -global isa-debugcon.iobase=0x402 to the QEMU cmdline, and attach "debug.log". Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882671 Title:

[Bug 1852196] Re: update edk2 submodule & binaries to edk2-stable201911

Yes, I do have a reason for delaying this LP until after 4.2.0 is out. When I filed this ticket (on 2019-Nov-12), QEMU had already entered the 4.2.0 soft feature freeze (on 2019-Oct-29). Despite possible appearances, this LP is actually a feature addition -- that's why I also set "Tags:

[Bug 1852196] [NEW] update edk2 submodule & binaries to edk2-stable201911

Hat) (lersek) Status: New ** Tags: feature-request ** Changed in: qemu Assignee: (unassigned) => Laszlo Ersek (Red Hat) (lersek) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1852

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

My understanding is that Kevin has fixed this bug in (as yet unreleased) commit 5e9785505210 ("qcow2: Fix corruption bug in qcow2_detect_metadata_preallocation()", 2019-10-25). The patch had been posted as a part of the following sets: [PATCH 0/3] qcow2: Fix image corruption bug in 4.1

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

In reply to : > Is it possible that we're talking about some kind of miscompilation > here, maybe because gcc-9.2.0 is just that tiny bit too spanking > current? I'm riding the trailing edge here (gcc-4.8 in RHEL7) :) [...] -- You

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

In reply to Kevin's comment#13: > I find Laszlo's case with a preallocated image particularly surprising > because the behaviour isn't supposed to have changed at all for > preallocated images, at least if the heuristics still detects them as > such. But isn't that "if" at the core of this

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

(See also / possible duplicate: .) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1846427 Title: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Hi Max, from my : I've seen corruption on ext4. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

After reading the message of commit 69f47505ee66 ("block: avoid recursive block_status call if possible", 2019-06-04), I'm none the wiser. But, I can at least confirm that all my qcow2 images are pre-allocated, as a norm. I create them with the following command: qemu-img create \ -f qcow2 \

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

I haven't done any sort of "narrowing down", but recent QEMUs (built from the master branch, post-v4.1) have corrupted at least two VM disk images (qcow2) for me as well. I had to reinstall both VMs. I didn't make any noise because I was sure that, if I wasn't seeing ghosts, then others must have

[Qemu-devel] [Bug 1838703] Re: Makefile BUG in edk2 firmware install 4.1.0-rc3

Fixed in commit 177cd674d620 ("Makefile: remove DESTDIR from firmware file content", 2019-08-03), part of v4.1.0-rc4. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1838703] Re: Makefile BUG in edk2 firmware install 4.1.0-rc3

The same issue was reported and patched on qemu-devel by Olaf Hering two months ago. The patch received three Reviewed-by tags, but nobody bothered to queue it. [Qemu-devel] [PATCH v1] Makefile: remove DESTDIR from firmware file cont The thread is split over two months, hence two links below,

[Qemu-devel] [Bug 1831477] Re: update edk2 submodule & binaries to edk2-stable201905

Merged in commit 53defa05701b ("Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-06-14' into staging", 2019-06-17). ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1831477] Re: update edk2 submodule & binaries to edk2-stable201905

[PULL 0/6] update edk2 submodule & binaries to edk2-stable201905 20190614202333.19355-1-lersek@redhat.com">http://mid.mail-archive.com/20190614202333.19355-1-lersek@redhat.com -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1831477] Re: update edk2 submodule & binaries to edk2-stable201905

Posted [PATCH 0/6] update edk2 submodule & binaries to edk2-stable201905 20190606133110.13754-1-lersek@redhat.com">http://mid.mail-archive.com/20190606133110.13754-1-lersek@redhat.com ** Changed in: qemu Status: New => In Progress -- You received this bug notification because you are a

[Qemu-devel] [Bug 1830872] Re: [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

(+Igor) On 06/03/19 17:01, Alex Bennée wrote: > When running on 32 bit TCG backends a wide unaligned load ends up > truncating data before returning to the guest. We specifically have > the return type as uint64_t to avoid any premature truncation so we > should use the same for the interim

[Qemu-devel] [Bug 1831477] Re: update edk2 submodule & binaries to edk2-stable201905

Some rebase notes can be seen at . ** Bug watch added: Red Hat Bugzilla #1701710 https://bugzilla.redhat.com/show_bug.cgi?id=1701710 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed

[Qemu-devel] [Bug 1831477] [NEW] update edk2 submodule & binaries to edk2-stable201905

/releases/tag/edk2-stable201905 [upcoming link] ** Affects: qemu Importance: Undecided Assignee: Laszlo Ersek (Red Hat) (lersek) Status: New ** Tags: feature-request ** Changed in: qemu Assignee: (unassigned) => Laszlo Ersek (Red Hat) (lersek) -- You received this

[Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG

Sorry the patch in comment #5 wasn't visible when I wrote what would end up as comment #6. I'll test the patch later. Thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1830872 Title: AARCH64

[Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG

I confirm that QEMU works fine (for the use case originally reported in this LP ticket) when built at commit a6ae23831b, i.e. at the parent of eed5664238ea. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG

Possibly related: [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64 https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when QEMU is built for i686) Note to self: try to reprodouce the present issue

[Qemu-devel] [Bug 1831115] Re: qemu 4.0.0 on aarch64: uefi firmware oversize

This is a bug in the debian package that you mention. The 2MB firmware executable (QEMU_EFI.fd) and the 768KB varstore template (QEMU_VARS.fd) that the edk2 ArmVirtQemu platform build produces cannot be passed directly to QEMU. Both files have to be padded to 64MB first. The padding is generally

[Qemu-devel] [Bug 1830872] [NEW] AARCH64 to ARMv7 mistranslation in TCG

Public bug reported: The following guest code: https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI Development Kit II) library function.

[Qemu-devel] [Bug 1830864] [NEW] Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(_->isar); })' failed

Public bug reported: The following assertion: assert(no_aa32 || cpu_isar_feature(arm_div, cpu)); introduced in commit 0f8d06f16c9d ("target/arm: Conditionalize some asserts on aarch32 support", 2018-11-02), fails for me. I intended to launch a 32-bit ARM guest (with KVM acceleration) on my

[Qemu-devel] [Bug 1821884] Re: Extend uefi-test-tools to report SMBIOS location

Fixed in commit range 8482ff2eb3bb..24496b8d27d9. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1821884 Title: Extend

[Qemu-devel] [Bug 1821884] Re: Extend uefi-test-tools to report SMBIOS location

Posted [PULL 0/2] tests/uefi-test-tools: report the SMBIOS entry point structures 20190503093118.15700-1-lersek@redhat.com">http://mid.mail-archive.com/20190503093118.15700-1-lersek@redhat.com -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed

[Qemu-devel] [Bug 1821884] Re: Extend uefi-test-tools to report SMBIOS location

Posted [PATCH 0/2] tests/uefi-test-tools: report the SMBIOS entry point structures http://mid.mail-archive.com/20190425104326.12835-1-lersek@redhat.com ** Changed in: qemu Status: Confirmed => In Progress -- You received this bug notification because you are a member of qemu- devel-ml,

[Qemu-devel] [Bug 1826200] Re: RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files

See also: https://github.com/puiterwijk/qemu-ovmf-secureboot/issues/25 ** Bug watch added: github.com/puiterwijk/qemu-ovmf-secureboot/issues #25 https://github.com/puiterwijk/qemu-ovmf-secureboot/issues/25 -- You received this bug notification because you are a member of qemu- devel-ml,

[Qemu-devel] [Bug 1826200] Re: RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files

See also: https://bugzilla.tianocore.org/show_bug.cgi?id=1747 ** Bug watch added: bugzilla.tianocore.org/ #1747 https://bugzilla.tianocore.org/show_bug.cgi?id=1747 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1826200] [NEW] RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files

Public bug reported: The feature added in https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd and exposed by libvirt as https://libvirt.org/formatdomain.html#elementsSysinfo allows the user to specify up to 255 strings in the unofmatted area of the Type

[Qemu-devel] [Bug 1818367] Re: Initialization of device cfi.pflash01 failed: Block node is read-only

(more precisely, the nvram element will be auto-generated when you exit "virsh edit", and the nvram file will be created (copied) from the varstore template when you launch the domain) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1818367] Re: Initialization of device cfi.pflash01 failed: Block node is read-only

Hi José, your domain XML is bogus with regard to the firmware configuration. You have: /var/lib/libvirt/qemu/nvram/os-1-ovmf.fd and no element, and you write that "os-1-ovmf.fd" is a copy of "OVMF_VARS.fd". The element, with @type='pflash', no other attributes, and then no sibling

[Qemu-devel] [Bug 1825207] Re: fw_cfg_machine_reset destroys user bootorder setting

This bug report is invalid, for a less important reason and for a more important reason. (1) The less important reason is that "/pci@i0cf8/*@6" is a string that would never be generated by QEMU, as a bootorder entry. QEMU places specific OpenFirmware device paths into the "bootorder" fw_cfg file.

[Qemu-devel] [Bug 1818207] Re: [aarch64] VM status remains "running" after it's suspended

In order for the guest kernel to expose ACPI S3 suspend to a privileged guest user, the guest kernel first checks if the platform (hardware and firmware) support ACPI S3. This in turn depends on whether the DSDT offers a package called _S3. For example, on the "pc" machine type, S3 can be

[Qemu-devel] [Bug 1821884] Re: Extend uefi-test-tools to report SMBIOS location

21113408.19929-1-lersek@redhat.com https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html ) ** Changed in: qemu Assignee: (unassigned) => Laszlo Ersek (Red Hat) (lersek) ** Changed in: qemu Status: New => Confirmed -- You received this bug notification because yo

[Qemu-devel] [Bug 1685242] Re: ovmf hangs at efi with virtio-net memory hotplug

Last night I remembered another tidbit: In OVMF, you can entirely disable the 64-bit MMIO aperture. -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=0 If you use the above switch, the firmware log should contain the following message: > GetFirstNonAddress: disabling 64-bit PCI host aperture This

[Qemu-devel] [Bug 1685242] Re: ovmf hangs at efi with virtio-net memory hotplug

* From "debug-nonworking.log": > GetFirstNonAddress: Pci64Base=0x88 Pci64Size=0x8 > [...] > PublishPeiMemory: mPhysMemAddressWidth=40 PeiMemoryCap=69644 KB > [...] > Type = Mem64; Base = 0x88; Length = 0x10; Alignment = > 0xF > Base = 0x88; Length

[Qemu-devel] [Bug 1685242] Re: ovmf hangs at efi with virtio-net memory hotplug

The reason why it behaves differently with machine types <= 2.4 is that - up to and including qemu-2.4, the calculation of the DIMM hotplug area was incorrect, - in 2.5, the calculation was fixed, - but for the migration compatibility of machine types <= 2.4, the old calculation was preserved

[Qemu-devel] [Bug 1685242] Re: ovmf hangs at efi with virtio-net memory hotplug

OVMF places the 64-bit PCI MMIO aperture after the memory hotplug area. If you specify `-m maxmem=1024G`, then accessing 64-bit MMIO BARs of PCI(e) devices, allocated from the aperture, will require at least 41 address bits. If you use KVM, and nested paging (EPT on Intel, NPT on AMD) is enabled,

[Qemu-devel] [Bug 1813165] Re: KVM internal error. Suberror: 1 emulation failure

This is related to SMM usage in SeaBIOS. The QEMU register dump states SMM=1, plus "<0f> aa" from the dumped code stands for the RSM instruction (0F AA -- RSM—Resume from System Management Mode, see it in the Intel SDM.) In RHEL7 downstream, we disabled SMM usage in SeaBIOS. -

[Qemu-devel] [Bug 1778350] Re: Android-x86 4.4-r5 won't boot on QEMU since v2.11.0-rc2

@navicrej -- can you please apply the series [Qemu-devel] [PATCH 0/2] hw/pci-host/x86: extend the 64-bit PCI hole relative to the fw-assigned base https://patchew.org/QEMU/20180924221346.16733-1-ler...@redhat.com/ on your end, and see if it makes a difference? (I don't expect it to, for the

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

@Andrew: are you implying that you successfully rebuilt the virtio guest drivers for ARM64 Windows? If that's the case, could you please share specifics about the build setup? I'm not the one working on the virtio GPU driver for Windows, but I assume your aarch64 build steps would apply to that

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

(1) See also . (2) One idea is (a) letting Windows use VirtioGpuDxe's GOP (blt only) until it calls ExitBootServices() -- which I have already confirmed to work with an ARM64 Windows Server variant that I was legally given access to --, and (b) once

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

Sigh, in bullet (1) of comment #10, I obviously didn't mean to link this same LP entry. Instead I meant . Sorry. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

See also LP#1725560. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1715700 Title: Windows 7 guest won't boot on qemu 2.10 (works on 2.9) Status in QEMU: Fix Committed Bug description: Qemu

[Qemu-devel] [Bug 1714331] Re: Virtual machines not working anymore on 2.10

See also LP#1725560. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1714331 Title: Virtual machines not working anymore on 2.10 Status in QEMU: New Bug description: Using 2.10, my virtual

[Qemu-devel] [Bug 1723927] Re: Linux or windows guest boot failed by uefi on CPU of Intel Xeon X5675

"-bios /usr/share/qemu-kvm/OVMF_CODE.fd" is *never* a correct option to boot OVMF. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1723927 Title: Linux or windows guest boot failed by uefi on CPU

Re: [Qemu-devel] [Bug 1723927] [NEW] Linux or windows guest boot failed by uefi on CPU of Intel Xeon X5675

On 10/16/17 13:26, chan wrote: > Public bug reported: > > Hi, > > I started windows server 2012 DC or redhat7.0, but boot failed by UEFI, and > start process stop on > "TianoCore" image by looking at VNCviewer. > > VM using the command:(redhat7.0) > /usr/bin/kvm -name

[Qemu-devel] [Bug 1721221] Re: PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with "kvm_set_phys_mem: error registering slot: Invalid argument"

There's another bug report / discussion thread on qemu-devel about the same commit: 1505913885.24609.8.camel@redhat.com">http://mid.mail-archive.com/1505913885.24609.8.camel@redhat.com I'll add a note to that thread about this LP report too. -- You received this bug notification because you

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

edk2 commit range: b68c793144e8..947f3737abf6. ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1715700 Title: Windows 7 guest won't boot on

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

Posted: [edk2] [PATCH 0/3] OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly https://lists.01.org/pipermail/edk2-devel/2017-September/014898.html I CC'd Aleksei on the series, but testing is welcome from anyone. (The cover letter at the link contains a git fetch URL.) -- You

Re: [Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

On 09/19/17 14:38, Gerd Hoffmann wrote: >> (2) Build the SeaBIOS CSM (CONFIG_CSM=y), and embed it into OVMF, >> like described above. Then, boot Windows 7 in *UEFI Mode*. > >> Option #1 and option #2 no longer work because the CSM infrastructure >> in edk2 needs to be able to write 0xc. > >

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

Ahh, wait, now I remember something -- the PAM registers are at a different location on Q35!!! If that's what's wrong, then it is indeed an OVMF bug. Let me see if I can write a patch. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

Re: [Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

On 09/19/17 13:49, Gerd Hoffmann wrote: > ovmf seems to not touch pam configuration, so rom remains mapped. I don't understand; the code that I quoted above -- and that LaunchPad messed up -- explicitly changes the PAM registers: // // Put the shim in place first. // Pam1Address =

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

Indeed the CSM platform support had the same error one and half years ago, see: https://github.com/tianocore/edk2/commit/db27e9f3d8f0 Thank you, Gerd, for the hint! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

Re: comment 14, "is there a way to fix vbeshim instead of reverting RO limitation that commit introduced?": I don't think so; please see my earlier comments 15 and 17. To elaborate: If a user wants to boot Windows 7 on OVMF, they have *three* options: (1) Build the SeaBIOS CSM (CONFIG_CSM=y),

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

What I mentioned earlier was not that SeaBIOS would break. Instead, I said that building OVMF, with the SeaBIOS CSM (Compatibility Support Module) embedded into it, would break, exactly the same way as the VBE Shim. Quoting the CSM Spec from Intel: "The CSM provides compatibility support between

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

I'd also like to mention that, when we originally worked on the VBE Shim, I tried to put it elsewhere. Obviously it has to be pointed-to by a real mode interrupt vector, which limits quite a bit where it can go at all; the point is that I tried to put it into low *RAM* (under 640KB). It didn't

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

I'm not sure if I mentioned this before, but launchpad is an *abomination*. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1715700 Title: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

[Qemu-devel] [Bug 1715700] Re: Windows 7 guest won't boot on qemu 2.10 (works on 2.9)

Thanks, Gerd, for the CC -- I agree, this commit (208fa0e43645) almost certainly breaks the VBE Shim. Displaying the patch with a bit larger context, > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > index 22e16031b03b..59435390ba62 100644 > --- a/hw/i386/pc.c > +++ b/hw/i386/pc.c > @@ -1442,8

Re: [Qemu-devel] [Bug 1658634] [PATCH] console: fix console resize

On 01/24/17 11:37, elmarco wrote: > Hi > > On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <1658...@bugs.launchpad.net> > wrote: > >> Only skip surface reallocation in case the old surface was created using >> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we >> might end up

[Qemu-devel] [Bug 1658634] Re: Can't get correct display with latest QEMU and OVMF BIOS

I downloaded "ubuntu-16.04.1-desktop-amd64.iso" (MD5: 17643c29e3c4609818f26becf76d29a3), and I can reproduce the issue -- the grub2 display is corrupt. (I didn't even look further than that.) I also confirm that it works fine with the same firmware, but using QEMU 2.7. Here's the result of the

[Qemu-devel] [Bug 1658634] Re: Can't get correct display with latest QEMU and OVMF BIOS

For reference, this is my script: ISO=ubuntu-16.04.1-desktop-amd64.iso CODE=OVMF_CODE.fd TMPL=OVMF_VARS.fd cp $TMPL vars.fd qemu-system-x86_64 \ -m 1024 \ -M pc,accel=kvm \ -device VGA \ -drive if=pflash,readonly,format=raw,file=$CODE \ -drive if=pflash,format=raw,file=vars.fd \

[Qemu-devel] [Bug 1658634] Re: Can't get correct display with latest QEMU and OVMF BIOS

Added Marc-André and Gerd to the CC list. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1658634 Title: Can't get correct display with latest QEMU and OVMF BIOS Status in QEMU: Confirmed Bug

[Qemu-devel] [Bug 1658634] Re: Can't get correct display with latest QEMU and OVMF BIOS

(1) What phase of the guest do you get invalid video output in? Do you see the TianoCore splash screen? Does the grub2 menu appear? (2) I cannot reproduce the issue (with a different guest OS anyway); I just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at 7cf59c854f35), with stdvga;

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

Fixed in: commit 423f7cf233fe262c777db7f87db3e9fac29e02d1 Author: Gerd Hoffmann Date: Wed Nov 9 09:48:44 2016 +0100 ipxe: update to 20161108 snapshot ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

The iPXE patches are now upstream (a big "thank you" to the iPXE maintainer!); QEMU 2.8 -- with Gerd willing -- should bundle iPXE binaries containing that fix. http://lists.ipxe.org/pipermail/ipxe-devel/2016-November/005244.html ** Changed in: qemu Status: New => Confirmed ** Changed

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

Thanks. It's indeed the same issue, you have unrestricted_guest=N and emulate_invalid_guest_state=Y. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1623276 Title: qemu 2.7 / iPXE crash Status in

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

Some more reports on ipxe-devel: http://lists.ipxe.org/pipermail/ipxe-devel/2016-October/005203.html http://lists.ipxe.org/pipermail/ipxe-devel/2016-October/005210.html Radim just posted the KVM feature patches: [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

BTW, this bug can be easily reproduced on hosts that do feature unrestricted_guest, just reload the kvm_intel module with unrestricted_guest=N. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1623276

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

(In other news, Launchpad continues to suck incredibly. Did you see how it broke up "unrestricted_guest" in my previous comment?) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1623276 Title: qemu

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

(--> the rebuilt binaries should go into v2.7.1, if we agree) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1623276 Title: qemu 2.7 / iPXE crash Status in QEMU: New Bug description: I am

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

Gerd, do you think we should rebuild the iPXE binaries bundled with QEMU with the offending iPXE commit (71560d185475) reverted, at least until KVM gets FXSAVE emulation in big real mode? I think this would be reasonable, as that iPXE commit works around a bug in the IBM Tivoli Provisioning

[Qemu-devel] [Bug 1623276] Re: qemu 2.7 / iPXE crash

We could also try changing upstream iPXE so that the FXSAVE trick is not active for CONFIG=qemu. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1623276 Title: qemu 2.7 / iPXE crash Status in QEMU:

  1   2   >