Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote: I give up. Thanks for the help sorry about spamming three lists. I've managed to reproduce this on a clean F18 system. This is the stock qemu 1.2.2-6.fc18 on kernel 3.7.6-201.fc18.x86_64 with a newly-installed Fedora 18 VM in the guest. qemu-system-x86_64 -enable-kvm -cdrom F18boot.iso -serial mon:stdio -bios OVMF.fd On my laptop where I'd been doing most of my testing, even after running 'yum distro-sync qemu\*' to get back to the stock qemu, I still can't reproduce the issue. They are both running the *same* kernel. I'll try reverting a whole bunch of other stuff that ought to be irrelevant to the stock distro packages, and see if/when it breaks... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
(removing edk2-devel, adding Jan) On 02/15/13 08:19, Michael Tokarev wrote: 15.02.2013 07:43, Kevin O'Connor wrote: On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote: On 02/15/13 02:22, Kevin O'Connor wrote: On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote: By chance, are you using an older version of kvm? There was a bug in kvm that caused changes to memory mapped at 0xe-0xf to also be reflected in the rom image at 0xfffe-0x. It was my understand that this bug was fixed though. You are great! Disabling KVM for the guest (/domain/@type='qemu') made the reboot work on both the RHEL-6 devel version of qemu and on upstream 1.3.1. (I didn't try suspend/resume yet.) Do you recall the precise commit that fixed the reflection? I've been eyeballing kvm commit messages for a few ten minutes now, but of course in vain. (CC'ing Gleb and Marcelo.) I found this email thread: http://kerneltrap.org/mailarchive/linux-kvm/2010/9/21/6267744 and: http://marc.info/?l=kvm-commitsm=128576215909532 I confirm RHEL-6 qemu-kvm lacks that patch; we still have the FIXME and the return statement that depend on kvm_enabled() in i440fx_update_memory_mappings(). This patch is more than 2 years old and is applied to all more or less recent qemu versions. This does not tell us why disabling kvm (with this patch applied!) makes a difference. I just retested on v1.3.1 + kvm, the problem is still there indeed. (Note that neither Gleb's patch, aa85bd8b support piix PAM registers in KVM, nor the patch that it partially undid: commit d03f4d2defd76f35f46f5418979f3e6d14a11183 Author: Jan Kiszka jan.kis...@web.de Date: Wed Sep 10 21:34:44 2008 +0200 I440fx: do change ISA mappings under KVM As long as KVM does not support remapping or protection state changes of guest memory, do not fiddle with the ISA mappings that QEMU see, confusing both the monitor and the gdbstub. Signed-off-by: Jan Kiszka jan.kis...@web.de Signed-off-by: Avi Kivity a...@qumranet.com made it ever to qemu; these are qemu-kvm commits.) So there must be another (maybe similar) bug somewhere... Maybe there was a concurrent or slightly earlier change to KVM that enabled the userspace fix too?... IOW the KVM fix could be necessary but not sufficient, the KVM fix + the qemu-kvm fix together are sufficient. If I disable KVM, i440fx_update_memory_mappings() probably does the same thing in RHEL-6 qemu-kvm as in upstream qemu v1.3.1. If I enable KVM, then RHEL-6 qemu-kvm breaks immediately in userspace, while upstream 1.3.1 might want to rely on KVM, but runs into a bug (?) on the RHEL-6 host kernel. Thanks, Laszlo
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On 02/14/13 23:24, David Woodhouse wrote: On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote: I noticed that under OVMF + SeaBIOS CSM + your related patches for both, reset requested by the guest doesn't work as expected. The behavior is an infinite loop, with the following debug fragment repeated by the CSM-ized SeaBIOS: In resume (status=0) In 32bit resume Attempting a hard reboot i8042_wait_write Hmm. My build from http://david.woodhou.se/OVMF.fd works fine. I did a legacy boot into (Ubuntu Oneiric's) Grub, then issued the 'reboot' command... This appears to be the case for qemu 1.2.0 and 1.3.0, both with and without KVM. I retested: - on a pristine v3.0.0 host kernel, and - a pristine v1.3.1 qemu build (+ KVM enabled), and - using your OVMF.fd from the above link (which of course includes your build of the CSM-ized SeaBIOS). Same infinite loop, alas... (i) What is your host kernel exactly? (ii) And when you say you did a legacy boot, does that mean you installed the guest OS as a traditional one? Is that grub or grub-efi? In my case the guest is a full UEFI installation of RHEL-6: I perform an UEFI boot from an emulated IDE disk to load grub-efi (which is thus pointed to by a non-BBS-devpath). The only thing I'm using the CSM for is the GOP based on vgabios-cirrus.bin (iii) Can vgabios.bin make a difference? Could you please upload your build? I gather you use stdvga; I also tried that, makes no difference, same loop. Comparing our logs, --- dwmw2.log 2013-02-15 18:47:39.654360652 +0100 +++ lersek.log 2013-02-15 18:49:18.061364128 +0100 @@ -1,18 +1,12 @@ -enter handle_13: - a=4200 b=0801 c=003f d=0080 ds=6000 es= ss= - si=fe00 di= bp=1ff0 sp=1ff2 cs= ip=9157 f=0202 -disk_op d=0xdb20 lba=9269505 buf=0x00068000 count=63 cmd=2 -pmtimer: 2:15494096 -pmtimer: 2:15494211 +enter handle_15: + a=2401 b=4118 c= d=0003 ds= es=4000 ss=4000 + si= di=4380 bp= sp=ffc6 cs=4f00 ip=0030 f=3002 +Trying to allocate 971 pages for VMLINUZ +[Linux-EFI, setup=0x10fa, size=0x3ca030] + [Initrd, addr=0x3c089000, size=0xf68cb9] +\u02d9Changing serial settings was 0/0 now 3/0 In resume (status=0) In 32bit resume Attempting a hard reboot i8042_wait_write -pmtimer: 2:15501497 -pmtimer: 2:15501593 -pmtimer: 2:15501750 -SecCoreStartupWithStack(0xFFFE6000, 0x8) -File-Type: 0xB -Section-Type: 0x2 -Section-Type: 0x19 -Section-Type (0x19) != SectionType (0x17) +Changing serial settings was 0/0 now 3/0 [...] Thanks Laszlo
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On Fri, 2013-02-15 at 19:54 +0100, Laszlo Ersek wrote: Same infinite loop, alas... (i) What is your host kernel exactly? 3.7.5-201.fc18.x86_64 (booted from EFI on a MacBookPro 8,3). (ii) And when you say you did a legacy boot, does that mean you installed the guest OS as a traditional one? Is that grub or grub-efi? That one was a traditional install. I've just now tested an EFI install of Fedora 17, which also reboots fine; both from grub and the installed kernel. It *doesn't* seem to hit the SeaBIOS CSM on the way back, but reboots directly into OVMF. I have two versions of qemu; the Fedora 18 one (1.2.0) and a locally-rebuilt copy of the Fedora rawhide 1.3.0, which I installed because OVMF's native video driver doesn't work in 1.2.0. Not that that matters any more since I've disabled that and I'm using the VGA BIOS. There's also a current build from qemu git. They all behave the same way, both with and without KVM. (iii) Can vgabios.bin make a difference? Could you please upload your build? I gather you use stdvga; I also tried that, makes no difference, same loop. This shouldn't make a difference. For the old vgabios, I only have the alignment fix, and no video would work if you didn't have that. http://david.woodhou.se/vgabios-cirrus.bin -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On 02/15/13 21:57, David Woodhouse wrote: On Fri, 2013-02-15 at 19:54 +0100, Laszlo Ersek wrote: Same infinite loop, alas... (i) What is your host kernel exactly? 3.7.5-201.fc18.x86_64 (booted from EFI on a MacBookPro 8,3). - host CPU: Xeon W3550 (family/model/stepping = 6/26/5) - host kernel: 3.7.8; config attached - md5sums of firmware binaries (both from you): 61daae4d085f646093e31df2b13b13e8 OVMF-david.fd 3a6a829c55cbd4e27db745326a5fed44 vgabios-cirrus-david.bin - qemu: upstream v1.3.1; configs attached ./configure --target-list=x86_64-softmmu --prefix=/opt/qemu-upstream \ --enable-debug - libvirt XML: attached; emulator refers to qemu wrapper script - qemu command line (from ps -f): /opt/qemu-upstream/bin/qemu-system-x86_64 \ -name fw-mixed.g-f18xfce2012121716.e-upstream \ -S \ -M pc-1.3 \ -enable-kvm \ -bios /root/OVMF-david.fd \ -m 1024 \ -smp 4,sockets=4,cores=1,threads=1 \ -uuid 0865a1c1-6474-249b-5e84-81171c4e1d0c \ -no-user-config \ -nodefaults \ -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fw-mixed.g-f18xfce2012121716.e-upstream.monitor,server,nowait \ -mon chardev=charmonitor,id=monitor,mode=control \ -rtc base=utc \ -no-shutdown \ -boot c \ -drive file=/var/lib/libvirt/images/fw-mixed.g-f18xfce2012121716.e-upstream.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none \ -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 \ -drive file=/filestore/isos/f18/Fedora-18-Nightly-20121217.16-x86_64-Live-xfce.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw \ -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ -chardev pty,id=charserial0 \ -device isa-serial,chardev=charserial0,id=serial0 \ -usb \ -vnc 127.0.0.1:0 \ -vga cirrus \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ -debugcon file:/tmp/fw-mixed.g-f18xfce2012121716.e-upstream.debug \ -global isa-debugcon.iobase=0x402 \ -global PIIX4_PM.disable_s3=0 \ -global PIIX4_PM.disable_s4=0 - guest: F18 XFCE nightly, UEFI installed, UEFI booted - serial output: attached - result: infinite loop at guest reset I give up. Thanks for the help sorry about spamming three lists. Laszlo 3.7.8.config.gz Description: GNU Zip compressed data config-host.h.gz Description: GNU Zip compressed data config-target.h.gz Description: GNU Zip compressed data fw-mixed.g-f18xfce2012121716.e-upstream.xml.gz Description: GNU Zip compressed data screen.log.gz Description: GNU Zip compressed data
[Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
Hi,
I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment repeated by the
CSM-ized SeaBIOS:
In resume (status=0)
In 32bit resume
Attempting a hard reboot
i8042_wait_write
The corresponding call chain seems to be:
reset_vector() [src/romlayout.S]
entry_post()
entry_resume()
handle_resume() [src/resume.c]
prints In resume
handle_resume32()
prints In 32bit resume
tryReboot()
prints Attempting a hard reboot
i8042_reboot() [src/ps2port.c]
i8042_wait_write()
prints i8042_wait_write
outb(0xfe, PORT_PS2_STATUS)
(The entry_post - entry_resume jump occurs because HaveRunPost has been
set to 1 by csm_maininit() -- interface_init() -- ivt_init().)
At this point kbd_write_command() in qemu-kvm's hw/pckbd.c, case
KBD_CCMD_RESET, requests a system reset. Soon the reset handlers run,
among them cpu_reset() (which was registered by
pc_init1() [hw/pc.c]
pc_new_cpu()
). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
the exact address of... reset_vector() in SeaBIOS.
Of course OVMF should be re-run instead of SeaBIOS. When qemu-kvm
starts, OVMF.fd is installed as ROM, such that the last address it
occupies is all-bits-one, independently of its size (below a limit of
course):
pc_init1() [hw/pc.c]
rom_add_file_fixed() []
open() / read() /close()
rom_insert()
some calls to inform KVM
I think when OVMF runs SeaBIOS as CSM, OVMF shadows the original ROM
(containing the OVMF binary itself) with the SeaBIOS code + static data
(I'm peeking at
http://en.wikipedia.org/wiki/Shadow_RAM#Shadow_RAM...). This should
render SeaBIOS visible / executable / writeable in the top 16-bit
segment, and leave OVMF in a permanently unusable state (in RAM at least).
My guess at the relevant edk2 function is ShadowAndStartLegacy16()
[IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c]. The
LegacyRegion-UnLock() call should be instrumental (implemented in
OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c with PAM (Programmable
Attribute Map) registers?)
Hence I *presume* qemu-kvm should un-shadow the ROM at reset time (ie.
make OVMF visible again as ROM) not later than allowing the VCPU to
continue at f000:fff0 again. Normally that address should be occupied by
OVMF code from (I guess) UefiCpuPkg/ResetVector/Vtf0.
Does this make any sense? Is qemu-kvm forgetting to reset the PAMs? Or
would that be the responsibility of tryReboot() in SeaBIOS?
... Aah! qemu_prep_reset() in SeaBIOS [src/shadow.c] goes like:
void
qemu_prep_reset(void)
{
if (!CONFIG_QEMU)
return;
// QEMU doesn't map 0xc-0xf back to the original rom on a
// reset, so do that manually before invoking a hard reset.
make_bios_writable();
extern u8 code32flat_start[], code32flat_end[];
memcpy(code32flat_start, code32flat_start + BIOS_SRC_OFFSET
, code32flat_end - code32flat_start);
if (HaveRunPost)
// Memory copy failed to work - try to halt the machine.
apm_shutdown();
}
and this function is actually called inside the infinite loop (I ignored
it before):
tryReboot()
prints Attempting a hard reboot
qemu_prep_reset() [src/shadow.c] -- here
i8042_reboot() [src/ps2port.c]
i8042_wait_write()
prints i8042_wait_write
outb(0xfe, PORT_PS2_STATUS)
but of course it doesn't do anything with CONFIG_CSM (since that implies
!CONFIG_QEMU). What's more, qemu_prep_reset() and
make_bios_writable_intel() seem to exploit SeaBIOS characteristics
(code32flat_*, HaveRunPost etc.) that probably make no sense when the
data being restored is a different (= OVMF) image.
Can we dumb down ^W^W generalize this code? :) Or maybe should qemu
introduce a reset handler for PAMs?
(I realize I've been reading all the time about PAMs, in the Writeable
files in fw_cfg thread, in the discussion about unlocking the 0xE
segment for stack purposes... Didn't understand a single word before,
sorry. Downloaded my copy of the i440FX spec just today; I finally have
a remote idea how shadowing / write-protecting works.)
Thanks!
Laszlo
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote: Can we dumb down ^W^W generalize this code? :) Or maybe should qemu introduce a reset handler for PAMs? In the UEFI+CSM model, I believe the handling of PAM stuff is left *entirely* to the UEFI side and the CSM is supposed to be hardware-agnostic. So actually bashing on the PAM registers from the CSM side would be my last resort. It's why it's important to fix the UmbStart/UmbEnd thing correctly, too. Other people might have been happy to hack up something machine-specific, given that they control both UEFI and CSM sides of it and they're shipping their own proprietary version where nobody can see what they're doing. But when the CSM spec is the interface between two entirely *separate* projects (OVMF and SeaBIOS), I think it's important that we *follow* the spec and don't have nasty hacks. So, if real hardware would reset the PAMs on reset and avoid the need for SeaBIOS to do so, I think we should be doing the same in qemu too. Thanks for testing this, btw. Are you looking at suspend/resume too? :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On 02/14/13 21:55, David Woodhouse wrote: So, if real hardware would reset the PAMs on reset and avoid the need for SeaBIOS to do so, I think we should be doing the same in qemu too. That's what I couldn't figure out from the i440FX spec, but I believe one could argue that reset should in fact re-set the state that was observable at VM startup. Thanks for testing this, btw. Are you looking at suspend/resume too? :) I'm either not looking, or not admitting it! :) In earnest: I approached Platform Initialization S3 resume cautiously, then fled in a panic. See Chapter 8 in Volume 5 -- Jordan convinced me that this scripting language was in fact reasonable, but the work needed to follow through OVMF PI, make it S3 resume compliant, and record everything into a script at cold boot looks very threatening. Regarding S3 in SeaBIOS CSM: I haven't tried it yet, but I can press the button in guests if you want me to. Laszlo
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote: I noticed that under OVMF + SeaBIOS CSM + your related patches for both, reset requested by the guest doesn't work as expected. The behavior is an infinite loop, with the following debug fragment repeated by the CSM-ized SeaBIOS: In resume (status=0) In 32bit resume Attempting a hard reboot i8042_wait_write Hmm. My build from http://david.woodhou.se/OVMF.fd works fine. I did a legacy boot into (Ubuntu Oneiric's) Grub, then issued the 'reboot' command... This appears to be the case for qemu 1.2.0 and 1.3.0, both with and without KVM. enter handle_13: a=4200 b=0801 c=003f d=0080 ds=6000 es= ss= si=fe00 di= bp=1ff0 sp=1ff2 cs= ip=9157 f=0202 disk_op d=0xdb20 lba=9269505 buf=0x00068000 count=63 cmd=2 pmtimer: 2:15494096 pmtimer: 2:15494211 In resume (status=0) In 32bit resume Attempting a hard reboot i8042_wait_write pmtimer: 2:15501497 pmtimer: 2:15501593 pmtimer: 2:15501750 SecCoreStartupWithStack(0xFFFE6000, 0x8) File-Type: 0xB Section-Type: 0x2 Section-Type: 0x19 Section-Type (0x19) != SectionType (0x17) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On 02/14/13 21:55, David Woodhouse wrote: Thanks for testing this, btw. Are you looking at suspend/resume too? :) Entering S3 seemed OK (except the screen was not cleared; using Cirrus). I woke up the guest with # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \ --hmp --cmd system_wakeup Trailing portion of the log: In resume (status=254) In 32bit resume rsdp=0x No resume vector set! Attempting a hard reboot i8042_wait_write In resume (status=0) In 32bit resume Attempting a hard reboot [...] I can see the following CSM calls earlier: - Legacy16InitializeYourself - Legacy16GetTableAddress - Legacy16DispatchOprom - Legacy16UpdateBbs No calls to PrepareToBoot (which could set RsdpAddr); this is an UEFI guest. (The CSM is used for the GOP only.) Laszlo
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote: On 02/14/13 21:55, David Woodhouse wrote: Thanks for testing this, btw. Are you looking at suspend/resume too? :) Entering S3 seemed OK (except the screen was not cleared; using Cirrus). I woke up the guest with # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \ --hmp --cmd system_wakeup Trailing portion of the log: In resume (status=254) In 32bit resume rsdp=0x No resume vector set! That is strange. As noted elsewhere, on a resume or reboot the cpu should have started execution at 0xfff0 which is OVMF and not SeaBIOS. I don't understand why/how SeaBIOS would be involved in the resume code path at all. -Kevin
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote: On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote: On 02/14/13 21:55, David Woodhouse wrote: Thanks for testing this, btw. Are you looking at suspend/resume too? :) Entering S3 seemed OK (except the screen was not cleared; using Cirrus). I woke up the guest with # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \ --hmp --cmd system_wakeup Trailing portion of the log: In resume (status=254) In 32bit resume rsdp=0x No resume vector set! That is strange. As noted elsewhere, on a resume or reboot the cpu should have started execution at 0xfff0 which is OVMF and not SeaBIOS. I don't understand why/how SeaBIOS would be involved in the resume code path at all. By chance, are you using an older version of kvm? There was a bug in kvm that caused changes to memory mapped at 0xe-0xf to also be reflected in the rom image at 0xfffe-0x. It was my understand that this bug was fixed though. -Kevin
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On 02/15/13 02:22, Kevin O'Connor wrote: On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote: On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote: On 02/14/13 21:55, David Woodhouse wrote: Thanks for testing this, btw. Are you looking at suspend/resume too? :) Entering S3 seemed OK (except the screen was not cleared; using Cirrus). I woke up the guest with # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \ --hmp --cmd system_wakeup Trailing portion of the log: In resume (status=254) In 32bit resume rsdp=0x No resume vector set! That is strange. As noted elsewhere, on a resume or reboot the cpu should have started execution at 0xfff0 which is OVMF and not SeaBIOS. I don't understand why/how SeaBIOS would be involved in the resume code path at all. By chance, are you using an older version of kvm? There was a bug in kvm that caused changes to memory mapped at 0xe-0xf to also be reflected in the rom image at 0xfffe-0x. It was my understand that this bug was fixed though. You are great! Disabling KVM for the guest (/domain/@type='qemu') made the reboot work on both the RHEL-6 devel version of qemu and on upstream 1.3.1. (I didn't try suspend/resume yet.) Do you recall the precise commit that fixed the reflection? I've been eyeballing kvm commit messages for a few ten minutes now, but of course in vain. (CC'ing Gleb and Marcelo.) Thank you, Laszlo
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote: On 02/15/13 02:22, Kevin O'Connor wrote: On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote: By chance, are you using an older version of kvm? There was a bug in kvm that caused changes to memory mapped at 0xe-0xf to also be reflected in the rom image at 0xfffe-0x. It was my understand that this bug was fixed though. You are great! Disabling KVM for the guest (/domain/@type='qemu') made the reboot work on both the RHEL-6 devel version of qemu and on upstream 1.3.1. (I didn't try suspend/resume yet.) Do you recall the precise commit that fixed the reflection? I've been eyeballing kvm commit messages for a few ten minutes now, but of course in vain. (CC'ing Gleb and Marcelo.) I found this email thread: http://kerneltrap.org/mailarchive/linux-kvm/2010/9/21/6267744 and: http://marc.info/?l=kvm-commitsm=128576215909532 -Kevin
Re: [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
15.02.2013 07:43, Kevin O'Connor wrote: On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote: On 02/15/13 02:22, Kevin O'Connor wrote: On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote: By chance, are you using an older version of kvm? There was a bug in kvm that caused changes to memory mapped at 0xe-0xf to also be reflected in the rom image at 0xfffe-0x. It was my understand that this bug was fixed though. You are great! Disabling KVM for the guest (/domain/@type='qemu') made the reboot work on both the RHEL-6 devel version of qemu and on upstream 1.3.1. (I didn't try suspend/resume yet.) Do you recall the precise commit that fixed the reflection? I've been eyeballing kvm commit messages for a few ten minutes now, but of course in vain. (CC'ing Gleb and Marcelo.) I found this email thread: http://kerneltrap.org/mailarchive/linux-kvm/2010/9/21/6267744 and: http://marc.info/?l=kvm-commitsm=128576215909532 This patch is more than 2 years old and is applied to all more or less recent qemu versions. This does not tell us why disabling kvm (with this patch applied!) makes a difference. So there must be another (maybe similar) bug somewhere... /mjt
