Description of problem: My RHEL 5.5 HVM guest boots into failure if domain is configured that maxmem is greater than memory. I tested these situations: 1. CPU that does not support HAP: The guest boots fine, and could be ballooned up and down. this bug does not apply. 2. AMD Phenom(tm) 9600B that supports RVI/NPT: The guest boots into a crashed state at 'GRUB loading stage 2'. # xm list Name ID Mem VCPUs State Time(s) Domain-0 0 7264 4 r----- 719.5 hvm1 5 512 1 ----c- 0.4 3. Intel i5 M520 CPU that supports EPT: The guest stops at "Booting 'Red Hat Enterprise Linux Server (2.6.18-194.el5)'", then turns into non-state. # xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1354 4 r----- 708.8 hvm1 6 512 1 ------ 4.7 Version-Release number of selected component (if applicable): xen-3.4.3-2.fc13.x86_64 kernel-2.6.32.23-170.xendom0.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. On a host that has a HAP-capable CPU, setup a RHEL 5 HVM guest image, create domain using the attached test.cfg. # xm create test.cfg Additional Info: Does the PoD code in this version of Xen support HAP?
Created attachment 454768 [details] test.cfg
Created attachment 454769 [details] xm dmesg for AMD
Created attachment 454770 [details] xm dmesg for Intel
This is a Fedora bug, so CCing Pasi.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Not sure it reproduces on F15. I'm currently unable to test it.
I've tried with: - FC15 kernel 2.6.38 => dom0 boots but unable to create domUs due to lack of blkback support. - rawhide kernel 2.6.39 => dom0 boots and by reading mail-lists supposed to work with userspace implementation of blkback in xen-4.1. However it fails with the same symptoms as 2.6.38 kernel. - found custom build dom0 kernel (kernel-2.6.38-1.xendom0.fc15.x86_64) -> fails to boot - dom0 crashes with jeremy's xen/stable-2.6.32.x - kernel-3.0-rc1 dom0 boost but unable to create domUs with following errors: (XEN) io.c:194:d4 MMIO emulation failed @ 0018:9ffff: 00 ae 1a 80 c4 82 (XEN) hvm.c:1099:d4 Triple fault on VCPU0 - invoking HVM system reset.
Hey. Did you try specifying dom0_mem=2G or so in grub? If that doesn't help, please post the full serial console logs to xen-devel mailinglist so those boot crash issues can be investigated. Also the issue with Linux 3.0-rc1 should be reported to xen-devel. Thanks!
Hi Pasi, Do you mean jeremy's kernel?
Hello. I think you should report the issue with Jeremy's xen/stable-2.6.32.x, and also the issue with Linux 3.0-rc1. Both would be good to sort out. If you can please post/link the console (crash) log with 2.6.32.x here, I can take a look if it looks familiar.. The issue with 3.0-rc1 should be probably reported straight to xen-devel mailinglist.
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.