Mailinglist Archive: opensuse-bugs (14787 mails)
| < Previous | Next > |
[Bug 214568] HVM Xen: Fully Virtualized openSUSE 10.2 guest will not install
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Tue, 21 Nov 2006 08:53:34 -0700 (MST)
- Message-id: <20061121155334.822C325C889@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=214568
jbeulich@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEEDINFO
Info Provider| |snwint@xxxxxxxxxx
------- Comment #17 from jbeulich@xxxxxxxxxx 2006-11-21 08:53 MST -------
We have this fixed now. However, it now hangs in what appears to be an endless
loop. To analyse this, we really need to understand what isolinux and the
gfxboot stuff are doing - dumping the VMCB I get a consistent value of
4004:6c1f for CS:IP that the boot process is sitting at (but that might just be
the place where the last intercept happened, e.g. the write to CR0 to re-enable
protected mode or the iret/sti that re-enabled interrupts). Sources and
knowledge how these map to specific addresses at run time would be rather
helpful in debugging this.
(I have a suspicion that the overhead of handling interrupts by reflecting them
to real mode may be so high that the process is live locking, but that would be
more likely on Intel than on AMD.)
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
jbeulich@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEEDINFO
Info Provider| |snwint@xxxxxxxxxx
------- Comment #17 from jbeulich@xxxxxxxxxx 2006-11-21 08:53 MST -------
We have this fixed now. However, it now hangs in what appears to be an endless
loop. To analyse this, we really need to understand what isolinux and the
gfxboot stuff are doing - dumping the VMCB I get a consistent value of
4004:6c1f for CS:IP that the boot process is sitting at (but that might just be
the place where the last intercept happened, e.g. the write to CR0 to re-enable
protected mode or the iret/sti that re-enabled interrupts). Sources and
knowledge how these map to specific addresses at run time would be rather
helpful in debugging this.
(I have a suspicion that the overhead of handling interrupts by reflecting them
to real mode may be so high that the process is live locking, but that would be
more likely on Intel than on AMD.)
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
| < Previous | Next > |