Re: [SeaBIOS] (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] (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
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
