We (Michael Fetterman, George Dunlap and I) have been working over the
last while on a full replacement for Xen''s shadow pagetable support.
This mail contains some design notes, below; a patch against
xen-unstable, giving a snapshot of the current state of the new shadow
code, is at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch
Comments on both are welcome, although the code is not finished -- in
particular there are both some optimizations and some tidying-up that
need to be done.
Cheers,
Tim.
----
The new shadow code (dubbed ''shadow2''), is designed as a
replacement for
the current shadow code. It''s been designed from the ground up to
support
the following capabilities:
* Work for both paravirtualized and HVM guests. Our focus is on Windows
under HVM, since Linux guests can use paravirtual mechanisms for faster
memory management.
* Xen may be running in 2-, 3-, or 4-level paging mode. While booting,
guests may be in direct-access mode (no paging), or any paging level less
than or equal to Xen''s current paging level. This means that we must
support 2-on-2, 2-on-3, 3-on-3, 3-on-4, and 4-on-4 paging modes.
* While bringing up secondary vcpus in an SMP system, the vcpus may all be
in different paging modes. We must support these simultaneously.
* Logdirty mode for live migration.
* We must work with paravirtualized drivers for HVM domains.
* We must work for guest superpages.
With this in mind, we have made several design choices:
* Do away with the "out-of-sync" mechanism to begin with. After a
page is
promoted, emulate all writes to it until it is demoted again. This makes the
logic a lot simpler, and also reduces the overhead of demand paging, which
is one of the most common Windows modes. (See below for more information
on demand paging.)
* In the case of a size mismatch between guest pagetable entries and host
pagetable entries (i.e., 2-on-3 or 2-on-4, where guest pagetable entries
are 32 bits and host pagetable entires are 64 bits), a single guest page
may need to be shadowed by multiple shadow pages. In this case, we always
shadow the entire guest pagetable, rather than shadowing only part at a
time. We also keep the multiple backing shadow pagetables physically
contiguous in memory using a "buddy" allocator. This allows us to use
only
one mfn value to designate the entire group of mfns.
* We allocate a fixed amount of shadow memory at domain creation. This is
shared by all vcpus. When we need more shadow pages, we begin to unshadow
pages to free up more memory in approximately an LRU fashion.
* We keep the p2m maps for HVM domains in a pagetable format, so that we
can use them as the pagetables fo HVM guests in paging-disabled mode.
So far, we have had several successes. Demand-paging accesses have been
sped up by doing emulated writes rather than using the out-of-sync
mechanism. The out-of-sync mechanism requires three page faults, two of
which entail relative expensive shadow operations: marking a page out of
sync, and bringing it back into sync. In the case of HVM guests, the
faults also cause three expensive vmexit/vmenter cycles. Our emulated
writes requires only two page faults, and each fault is less expensive.
Also, the overhead of many individual shadow operations is less in the newer
code than in the old code.
We have a number of potential optimizations in mind for the near future:
* Removing writable mappings. As with the old code, when a
guest pfn is promoted to be a pagetable, we need to find and remove all
writable mappings to it, so that we can detect changes. Following the
"start simple, then optimize" principle, our current code does a
brute-force search through the shadows. Our tests indicate that when a
page is promoted to a pagetable, it generally has exactly one writable
mapping outstanding. This is true both for Windows and for Linux. We plan
to use this fact to keep a back-pointer to the last writable shadow pte of
a page in the page_info struct of a page. The few exceptions to the rule
can still be handled using brute-force search.
* Fast-pathing some faults. By storing the guest present / writable flags
in some of the spare bits of the guest pagetable, we can fast-path certain
operations, such as propagating a fault to the guest or updating guest
dirty and accessed bits, without needing to map the guest pagetables. This
should speed up some common faults, as well as reduce cache footprint.
* Batch updates. There are times when guests do batch updates to
pagetables. At these times, it makes sense to give the guest write access
to the pagetables. At first this can be done simply by unshadowing the
page entirely. In the future, we can explore whether a a "mark out of
sync"
mechanism would speed things up. We may be able to have a more extreme
optimization for Linux fork(): when we detect Linux doing a fork(), we can
unshadow the entire user portion of the guest address space, to save having
to detect a "batch update" and unshadow each guest pagetable
individually.
* Full emulation of shadow page accesses. Currently, we allow read-only
access to guest pagetables. This requires us to emulate the dirty and
accessed bits of the guest pagetables, in turn requiring us to take page
faults. But how many of these dirty/accessed bits are actually read? It
may be more efficient, in certain circumstances, to emualte reads to guest
page tables as well as writes, taking the dirty and accessed bits from the
shadow pagetables.
* Teardown heuristics. If we can determine when a guest is destroying a
process, we can unshadow the whole address space at once. Failure to
detect when a process is being torn down will cause unnecessary overhead:
if the guest pagetables of the destroyed process are recycled as data
pages, all writes to the pages will be emulated (in a rather expensive
manner) until the page is unshadowed. Even if the guest pagetables are
re-used for new process pagetables, constructing the address space will be
faster if unshadowed.
**************
Code Structure
**************
Our code must deal differently with all the different combinations of
shadow modes. However, we expect that once a guest reaches its target
paging mode, it will stay in that mode for a long time; and the host will
never change its paging mode. Rather than having a whole string of ifs in
the code based on the current guest and host paging modes, we compile
different code to deal with each pair of modes (2-on-2, 2-on-3, 2-on-4,
3-on-3, 3-on-4, 4-on-4). (Direct mode is implemented as a special case of
m-on-m, where m is the host''s current paging level.) While increasing
the
size of the hypervisor overall, this should greatly decrease both the cache
footprint of the shadow code and reduce pipeline flushes from mispredicted
branches.
To keep from having to maintain duplicate logic across 6 different bits of
code, we use a single source code file, and compiler directives to specify
mode-specific code. This file is shadow2.c, and is built once with
GUEST_PAGING_LEVELS and SHADOW_PAGING_LEVELS set to the appropriate
combination. The compiler is set to redefine the functions from
sh2_[function_name]()
to
sh2_[function_name]__shadow_[m]_guest_[n]
for n-on-m mode.
At the end of shadow2.c is a structure containing function pointers for
each of the mode-specific functions; this is called shadow2_entry (and is
expanded by preprocessor directives using the __shadow_[m]_guest_[n] naming
convention). When a guest vcpu is put into a particular shadow mode, an
element of the vcpu struct is pointed to the appropriate shadow2_entry
struct. To call the appropriate function, one generally calls
shadow2_[function_name](v, [args]), which is generally implemented after
the following template:
[rettype] shadow2_[function_name](v, [args]) {
return v->arch.shadow2->[function_name](v, [args]);
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hello,
I noticed the addition of the unsigned long *mb parameter in
xc_shadow_control(). If you have time, could you say a word or two
about what this parameter is used for?
Thanks,
Ryan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tim Deegan
Sent: Friday, July 14, 2006 11:39 AM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [RFC] New shadow paging code
We (Michael Fetterman, George Dunlap and I) have been working over the
last while on a full replacement for Xen''s shadow pagetable support.
This mail contains some design notes, below; a patch against
xen-unstable, giving a snapshot of the current state of the new shadow
code, is at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch
Comments on both are welcome, although the code is not finished -- in
particular there are both some optimizations and some tidying-up that
need to be done.
Cheers,
Tim.
----
The new shadow code (dubbed ''shadow2''), is designed as a
replacement for
the current shadow code. It''s been designed from the ground up to
support the following capabilities:
* Work for both paravirtualized and HVM guests. Our focus is on
Windows under HVM, since Linux guests can use paravirtual mechanisms for
faster memory management.
* Xen may be running in 2-, 3-, or 4-level paging mode. While booting,
guests may be in direct-access mode (no paging), or any paging level
less than or equal to Xen''s current paging level. This means that we
must support 2-on-2, 2-on-3, 3-on-3, 3-on-4, and 4-on-4 paging modes.
* While bringing up secondary vcpus in an SMP system, the vcpus may all
be in different paging modes. We must support these simultaneously.
* Logdirty mode for live migration.
* We must work with paravirtualized drivers for HVM domains.
* We must work for guest superpages.
With this in mind, we have made several design choices:
* Do away with the "out-of-sync" mechanism to begin with. After a
page
is promoted, emulate all writes to it until it is demoted again. This
makes the logic a lot simpler, and also reduces the overhead of demand
paging, which is one of the most common Windows modes. (See below for
more information on demand paging.)
* In the case of a size mismatch between guest pagetable entries and
host pagetable entries (i.e., 2-on-3 or 2-on-4, where guest pagetable
entries are 32 bits and host pagetable entires are 64 bits), a single
guest page may need to be shadowed by multiple shadow pages. In this
case, we always shadow the entire guest pagetable, rather than shadowing
only part at a time. We also keep the multiple backing shadow
pagetables physically contiguous in memory using a "buddy" allocator.
This allows us to use only one mfn value to designate the entire group
of mfns.
* We allocate a fixed amount of shadow memory at domain creation. This
is shared by all vcpus. When we need more shadow pages, we begin to
unshadow pages to free up more memory in approximately an LRU fashion.
* We keep the p2m maps for HVM domains in a pagetable format, so that we
can use them as the pagetables fo HVM guests in paging-disabled mode.
So far, we have had several successes. Demand-paging accesses have been
sped up by doing emulated writes rather than using the out-of-sync
mechanism. The out-of-sync mechanism requires three page faults, two of
which entail relative expensive shadow operations: marking a page out of
sync, and bringing it back into sync. In the case of HVM guests, the
faults also cause three expensive vmexit/vmenter cycles. Our emulated
writes requires only two page faults, and each fault is less expensive.
Also, the overhead of many individual shadow operations is less in the
newer code than in the old code.
We have a number of potential optimizations in mind for the near future:
* Removing writable mappings. As with the old code, when a guest pfn is
promoted to be a pagetable, we need to find and remove all writable
mappings to it, so that we can detect changes. Following the "start
simple, then optimize" principle, our current code does a brute-force
search through the shadows. Our tests indicate that when a page is
promoted to a pagetable, it generally has exactly one writable mapping
outstanding. This is true both for Windows and for Linux. We plan to
use this fact to keep a back-pointer to the last writable shadow pte of
a page in the page_info struct of a page. The few exceptions to the
rule can still be handled using brute-force search.
* Fast-pathing some faults. By storing the guest present / writable
flags in some of the spare bits of the guest pagetable, we can fast-path
certain operations, such as propagating a fault to the guest or updating
guest dirty and accessed bits, without needing to map the guest
pagetables. This should speed up some common faults, as well as reduce
cache footprint.
* Batch updates. There are times when guests do batch updates to
pagetables. At these times, it makes sense to give the guest write
access to the pagetables. At first this can be done simply by
unshadowing the page entirely. In the future, we can explore whether a a
"mark out of sync"
mechanism would speed things up. We may be able to have a more extreme
optimization for Linux fork(): when we detect Linux doing a fork(), we
can unshadow the entire user portion of the guest address space, to save
having to detect a "batch update" and unshadow each guest pagetable
individually.
* Full emulation of shadow page accesses. Currently, we allow read-only
access to guest pagetables. This requires us to emulate the dirty and
accessed bits of the guest pagetables, in turn requiring us to take page
faults. But how many of these dirty/accessed bits are actually read?
It may be more efficient, in certain circumstances, to emualte reads to
guest page tables as well as writes, taking the dirty and accessed bits
from the shadow pagetables.
* Teardown heuristics. If we can determine when a guest is destroying a
process, we can unshadow the whole address space at once. Failure to
detect when a process is being torn down will cause unnecessary
overhead:
if the guest pagetables of the destroyed process are recycled as data
pages, all writes to the pages will be emulated (in a rather expensive
manner) until the page is unshadowed. Even if the guest pagetables are
re-used for new process pagetables, constructing the address space will
be faster if unshadowed.
**************
Code Structure
**************
Our code must deal differently with all the different combinations of
shadow modes. However, we expect that once a guest reaches its target
paging mode, it will stay in that mode for a long time; and the host
will never change its paging mode. Rather than having a whole string of
ifs in the code based on the current guest and host paging modes, we
compile different code to deal with each pair of modes (2-on-2, 2-on-3,
2-on-4, 3-on-3, 3-on-4, 4-on-4). (Direct mode is implemented as a
special case of m-on-m, where m is the host''s current paging level.)
While increasing the size of the hypervisor overall, this should greatly
decrease both the cache footprint of the shadow code and reduce pipeline
flushes from mispredicted branches.
To keep from having to maintain duplicate logic across 6 different bits
of code, we use a single source code file, and compiler directives to
specify mode-specific code. This file is shadow2.c, and is built once
with GUEST_PAGING_LEVELS and SHADOW_PAGING_LEVELS set to the
appropriate combination. The compiler is set to redefine the functions
from
sh2_[function_name]()
to
sh2_[function_name]__shadow_[m]_guest_[n]
for n-on-m mode.
At the end of shadow2.c is a structure containing function pointers for
each of the mode-specific functions; this is called shadow2_entry (and
is expanded by preprocessor directives using the __shadow_[m]_guest_[n]
naming convention). When a guest vcpu is put into a particular shadow
mode, an element of the vcpu struct is pointed to the appropriate
shadow2_entry struct. To call the appropriate function, one generally
calls shadow2_[function_name](v, [args]), which is generally implemented
after the following template:
[rettype] shadow2_[function_name](v, [args]) {
return v->arch.shadow2->[function_name](v, [args]); }
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
At 13:58 -0400 on 14 Jul (1152885502), Kurtz, Ryan M. wrote:> Hello, > > I noticed the addition of the unsigned long *mb parameter in > xc_shadow_control(). If you have time, could you say a word or two > about what this parameter is used for?This shadow code allocates a fixed pool of memory per domain for shadowing pagetables and building the phys-to-machine map (the old shadow code just allocated pages from domheap as it required them). The new parameter is used in shadow-control dom0 ops to set or get the size of this pool, and set to NULL for all other operations. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan wrote:> Our code must deal differently with all the different combinations of > shadow modes. However, we expect that once a guest reaches its target > paging mode, it will stay in that mode for a long time; and the host will > never change its paging mode. Rather than having a whole string of ifs in > the code based on the current guest and host paging modes, we compile > different code to deal with each pair of modes (2-on-2, 2-on-3, 2-on-4, > 3-on-3, 3-on-4, 4-on-4). (Direct mode is implemented as a special case of > m-on-m, where m is the host''s current paging level.) While increasing the > size of the hypervisor overall, this should greatly decrease both the cache > footprint of the shadow code and reduce pipeline flushes from mispredicted > branches.Can you explain how this works? It is not obvious to me from the patch. In shadow2.c there is in fact a whole string of #ifs. What mechanism causes the file to be multiply compiled? Or do I misunderstand how this works? Also, can you comment on the differences and similarities with the shadow code contributed by Ben Thomas? thanks, Mike Day _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 10:32 -0400 on 17 Jul (1153132328), Mike D. Day wrote:> Can you explain how this works? It is not obvious to me from the patch. > In shadow2.c there is in fact a whole string of #ifs. What mechanism > causes the file to be multiply compiled? Or do I misunderstand how this > works?It''s handled by the makefile runes that go into in xen/arch/x86/Makefile. For each type of host, a number of shadow2_gX_on_sY.o files are required, and the rule for shadow2_%.o compiles shadow2.c with the appropriate definitions for GUEST_PAGING_LEVELS and SHADOW_PAGING_LEVELS.> Also, can you comment on the differences and similarities with the > shadow code contributed by Ben Thomas?There are some similarities: for example both patches allocate a pool of shadow memory for each domain, rather than allocating from domheap on the fly. Also, we''re currently working on incorporating the idea of storing guest present/writable bits in the shadow pte for fast-path of "genuine" faults. The major difference in structure is that the XI patch keeps the "out-of-sync" algorithm of the old shadow code, letting guests write to their pagetables and re-syncing the shadow on a fault. This works well for linux''s fork()/exit() behaviour, but for Windows, which mostly does demand paging, it makes the cycle of fault-install-retry rather expensive. Instead, the shadow2 patch emulates all writes to pagetables, without ever letting the guest write to a shadowed page directly. XI also has a reverse-mapping mechanism for recording where all the pagetable entries are that reference each page; this doubles the memory cost of shadow mode, and adds some book-keeping, but avoids having to search through all the shadows when revoking write access to a guest page. We believe it''s possible to use heuristics to speed up the remove-all-writable-mappings process, without the memory overhead. For example, just looking in the kernel''s linear map works in 99.8% of cases for Windows 2003 Server. As for features, XI supports only HVM guests on 64-bit Xen; shadow2 supports 32-bit and PAE Xen as well, and PV guests. As I understand it, there is no plan to make XI support any other modes. XI supports shadowing superpages directly with superpages, which shadow2 does not (yet). Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, A new version of the shadow2 patch is now available at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch (md5: 20e56b90a32621ce3d1833a8d9fd769b shadow2.patch) This version is more complete, and contains some optimizations over the previous one, as well as various bug fixes. It is known to have problems on 64bit and AMD systems right now. We also intend to add support for log-dirty mode (PV migration) very soon, and benchmark to decide which optimizations to keep. Any feedback on this patch would be very welcome. Please have a play with it if you''re interested in shadow mode or HVM. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
A new version of the shadow2 patch is now available at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch (md5: 9a095c7467ab89eca48cad4e98d0b447) This fixes a bug with PAE PV domains, and has better-tuned optimizations. It applies to version 10870:2d2ed4d9b1c1 of -unstable. Once again, any feedback is appreciated. Cheers, Tim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
A new version of the shadow2 patch is now available at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch (md5: e84cba44970975623a0224ed33af3f60) This patch applies to version 0e32095a7b46 of -unstable. In this patch, we completely remove the old shadow code. Shadow2 now handles PV guests (for live migration) as well as HVM guests. We aim to check this in to -unstable soon, so do try it out if you''re interested in shadow pagetables or HVM. Any and all feedback appreciated. Cheers, Tim. .hgtags | 7 a/xen/arch/x86/audit.c | 984 ------ a/xen/arch/x86/shadow.c | 4199 ----------------------------- a/xen/arch/x86/shadow32.c | 3782 -------------------------- a/xen/arch/x86/shadow_guest32.c | 16 a/xen/arch/x86/shadow_guest32pae.c | 16 a/xen/arch/x86/shadow_public.c | 2138 -------------- a/xen/include/asm-x86/shadow_64.h | 587 ---- a/xen/include/asm-x86/shadow_ops.h | 138 a/xen/include/asm-x86/shadow_public.h | 61 b/xen/arch/x86/shadow2-common.c | 3353 +++++++++++++++++++++++ b/xen/arch/x86/shadow2.c | 4472 +++++++++++++++++++++++++++++++ b/xen/include/asm-x86/shadow2-multi.h | 116 b/xen/include/asm-x86/shadow2-private.h | 638 ++++ b/xen/include/asm-x86/shadow2-types.h | 705 ++++ b/xen/include/asm-x86/shadow2.h | 627 ++++ tools/examples/xend-config.sxp | 2 tools/examples/xmexample.hvm | 4 tools/libxc/xc_domain.c | 11 tools/libxc/xc_hvm_build.c | 13 tools/libxc/xc_linux_build.c | 2 tools/libxc/xc_linux_save.c | 18 tools/libxc/xenctrl.h | 2 tools/misc/xc_shadow.c | 2 tools/python/xen/lowlevel/xc/xc.c | 69 tools/python/xen/xend/XendDomain.py | 24 tools/python/xen/xend/XendDomainInfo.py | 40 tools/python/xen/xm/create.py | 9 tools/python/xen/xm/main.py | 12 xen/arch/x86/Makefile | 16 xen/arch/x86/dom0_ops.c | 2 xen/arch/x86/domain.c | 106 xen/arch/x86/domain_build.c | 13 xen/arch/x86/hvm/hvm.c | 23 xen/arch/x86/hvm/platform.c | 9 xen/arch/x86/hvm/svm/svm.c | 233 - xen/arch/x86/hvm/vlapic.c | 3 xen/arch/x86/hvm/vmx/vmcs.c | 15 xen/arch/x86/hvm/vmx/vmx.c | 227 - xen/arch/x86/mm.c | 557 +-- xen/arch/x86/setup.c | 2 xen/arch/x86/smpboot.c | 2 xen/arch/x86/traps.c | 32 xen/arch/x86/x86_32/domain_page.c | 33 xen/arch/x86/x86_32/mm.c | 3 xen/arch/x86/x86_64/mm.c | 3 xen/arch/x86/x86_64/traps.c | 14 xen/common/acm_ops.c | 1 xen/common/grant_table.c | 2 xen/common/keyhandler.c | 19 xen/common/memory.c | 11 xen/drivers/char/console.c | 50 xen/include/asm-x86/bitops.h | 18 xen/include/asm-x86/config.h | 22 xen/include/asm-x86/domain.h | 99 xen/include/asm-x86/grant_table.h | 2 xen/include/asm-x86/hvm/hvm.h | 14 xen/include/asm-x86/hvm/support.h | 11 xen/include/asm-x86/hvm/svm/svm.h | 2 xen/include/asm-x86/hvm/vcpu.h | 6 xen/include/asm-x86/hvm/vmx/vmcs.h | 1 xen/include/asm-x86/hvm/vmx/vmx.h | 41 xen/include/asm-x86/mm.h | 141 xen/include/asm-x86/msr.h | 4 xen/include/asm-x86/page-guest32.h | 7 xen/include/asm-x86/page.h | 37 xen/include/asm-x86/perfc_defn.h | 53 xen/include/asm-x86/processor.h | 1 xen/include/asm-x86/shadow.h | 1791 ------------ xen/include/asm-x86/x86_32/page-2level.h | 1 xen/include/asm-x86/x86_32/page-3level.h | 3 xen/include/asm-x86/x86_64/page.h | 5 xen/include/public/dom0_ops.h | 16 xen/include/xen/domain_page.h | 13 xen/include/xen/lib.h | 4 xen/include/xen/list.h | 10 xen/include/xen/sched.h | 5 77 files changed, 11124 insertions(+), 14606 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan wrote:> A new version of the shadow2 patch is now available at > http://www.cl.cam.ac.uk/~tjd21/shadow2.patch > (md5: e84cba44970975623a0224ed33af3f60) > This patch applies to version 0e32095a7b46 of -unstable. > > In this patch, we completely remove the old shadow code. Shadow2 > now handles PV guests (for live migration) as well as HVM guests. > > We aim to check this in to -unstable soon, so do try it out if you''re > interested in shadow pagetables or HVM. Any and all feedback > appreciated. > > Cheers, > > Tim.Tim, Hi The following are from the previous version, but you might want to test at least of them. Testing Issues ======================We observed issues in the testing, especially in SMP VMX. 1. In IA32e platform, UP VMX or SMP VMX could not be started with error info. # xm cr -f config.up Using config file "config.up". Error: (12, ''Cannot allocate memory'') See attached xend.log 2. In IA32 platform, when starting one SMP VMX and one UP VMX together, dom0 will reboot. See attached console log 3. In IA32 platform, when starting 4 UP VMX together, dom0 will reboot 4. In IA32 platform, when starting 2 UP VMX and 2 UP xenU, 2 xenU and one VMX could be started, and one VMX failed to boot. 5. In IA32pae platform, starting PAE enabled SMP VMX (vcpus=4), dom0 will reboot. See attached console log. 6. In IA32pae platform, starting PAE disabled SMP VMX (vcpus=4), dom0 will reboot. See attached console log. 7. In IA32pae platform, testing UP VMX from 128M to 3G with 128M step, dom0 reboots. 8. In IA32 platform, running "halt -p" in SMP VMX and VMX shows "Badness in send_IPI_mask_bitmask at arch/i386/kernel/smp.c:167" 9. In IA32pae platform, starting windows VMX cause xen0 reboot See attached console log Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 11 Aug 2006, Tim Deegan wrote:> We aim to check this in to -unstable soon, so do try it out if you''re > interested in shadow pagetables or HVM. Any and all feedback > appreciated.Have you considered using binary patching (similar to the paravirt_ops technique), so that the final shadow mode ops are invoked directly? - James -- James Morris <jmorris@redhat.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 15:48 -0400 on 11 Aug (1155311280), James Morris wrote:> Have you considered using binary patching (similar to the paravirt_ops > technique), so that the final shadow mode ops are invoked directly?I don''t think we would get very much benefit from it. In SMP HVM guests, different vcpus can be in different shadow modes, so there would still have to be a per-vcpu lookup to choose which mode to use. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh
2006-Aug-13 20:36 UTC
RE: [Xen-devel] [RFC] New shadow paging code
Tim, I tried out your patch on a 4-way x86_64 ES7000 with 32GB of RAM. I only tried it with an x86_64 hypervisor. I was only able to bring up UP x86_32 HVM domains. I used the following config. kernel = "/usr/lib/xen/boot/hvmloader" builder=''hvm'' memory = 256 shadow_memory = 8 name = "winxp" vif = [ ''type=ioemu, bridge=xenbr0'' ] disk = [ ''file:/mnt/xenlsg/xenimages/winxp.vmg,hda,w'' ] device_model = ''/usr/'' + arch_libdir + ''/xen/bin/qemu-dm'' sdl=0 vnc=1 serial=''pty'' I tried bringing up as many x86_32 UP WinXP domains as I could. I found that the qemu-dm process associated with each domain took up 50% cpu. So when I tried to bring up the 9th domain I go the following error: Error: Device 768 (vbd) could not be connected. Backend device not found. I have attached the output of top and xentop with 8 WinXP domains running. I also kept seeing a few "(XEN) spurious IRQ irq got=-1 messages." I was unable to bring up any SMP x86_32 domains. When I tried bringing up a Win2003 Server with vcpus=2, only one CPU showed up in the domain. I tried this with various combinations of acpi and apic. Bringing up a domain with pae=1 crashes the system. I have attached the output. I tried this with a Win2003 server image. I could not bring up any x86_64 domains. When I tried a SLES10 x86_64 image I got a message saying "Your CPU does not support long mode. Use a 32-bit distribution" So in a nutshell: x86_32 hvm domain boot: pass x86_32 pae hvm domain boot: fail x86_64 hvm domain boot: fail Please let me know if you need any more information. Thanks, Aravindh Puthiyaparambil Xen Development Team Unisys, Tredyffrin PA _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Jun. Thanks a lot for the test report; much appreciated. Issue 1 was an bug in Xend''s allocation of shadow memory; it is fixed now. I''ll get a new patch out as soon as I''ve investigated the two HVM SPM issues. Issues 2, 3, 6, 7 and 9 all look like the same issue, which was fixed in yesterday''s patch. Issue 4 I can''t reproduce. Cheers, Tim. At 10:56 -0700 on 11 Aug (1155293793), Nakajima, Jun wrote:> The following are from the previous version, but you might want to test > at least of them. > > Testing Issues > ======================> We observed issues in the testing, especially in SMP VMX. > 1. In IA32e platform, UP VMX or SMP VMX could not be started with error > info. > > # xm cr -f config.up > Using config file "config.up". > Error: (12, ''Cannot allocate memory'') > > See attached xend.log > > 2. In IA32 platform, when starting one SMP VMX and one UP VMX together, > dom0 will reboot. > See attached console log > > 3. In IA32 platform, when starting 4 UP VMX together, dom0 will reboot > > 4. In IA32 platform, when starting 2 UP VMX and 2 UP xenU, 2 xenU and > one VMX could be started, and one VMX failed to boot. > > 5. In IA32pae platform, starting PAE enabled SMP VMX (vcpus=4), dom0 > will reboot. > See attached console log. > > 6. In IA32pae platform, starting PAE disabled SMP VMX (vcpus=4), dom0 > will reboot. > See attached console log. > > 7. In IA32pae platform, testing UP VMX from 128M to 3G with 128M step, > dom0 reboots. > > 8. In IA32 platform, running "halt -p" in SMP VMX and VMX shows "Badness > in send_IPI_mask_bitmask at arch/i386/kernel/smp.c:167" > > 9. In IA32pae platform, starting windows VMX cause xen0 reboot > See attached console log > > Jun > --- > Intel Open Source Technology CenterContent-Description: issue02_console_log.txt> > [root@vt-px3 ~]# (XEN) vmx_do_launch(): GUEST_CR3<=8dc38000, HOST_CR3<=8dc39000 > (XEN) vmx_do_launch(): GUEST_CR3<=8dc31000, HOST_CR3<=8dc32000 > (XEN) (GUEST: 2) HVM Loader > (XEN) (GUEST: 2) Loading ROMBIOS ... > (XEN) (GUEST: 2) Creating MP tables ... > (XEN) (GUEST: 2) Loading Cirrus VGABIOS ... > (XEN) (GUEST: 2) Loading ACPI ... > (XEN) (GUEST: 2) Loading VMXAssist ... > (XEN) (GUEST: 2) VMX go ... > (XEN) (GUEST: 2) VMXAssist (Aug 8 2006) > (XEN) (GUEST: 2) Memory size 128 MB > (XEN) (GUEST: 2) E820 map: > (XEN) (GUEST: 2) 0000000000000000 - 000000000009F800 (RAM) > (XEN) (GUEST: 2) 000000000009F800 - 00000000000A0000 (Reserved) > (XEN) (GUEST: 2) 00000000000A0000 - 00000000000C0000 (Type 16) > (XEN) (GUEST: 2) 00000000000F0000 - 0000000000100000 (Reserved) > (XEN) (GUEST: 2) 0000000000100000 - 0000000007FFE000 (RAM) > (XEN) (GUEST: 2) 0000000007FFE000 - 0000000007FFF000 (Type 18) > (XEN) (GUEST: 2) 0000000007FFF000 - 0000000008000000 (Type 17) > (XEN) (GUEST: 2) 0000000008000000 - 0000000008003000 (ACPI NVS) > (XEN) (GUEST: 2) 0000000008003000 - 000000000800D000 (ACPI Data) > (XEN) (GUEST: 2) 00000000FEC00000 - 0000000100000000 (Type 16) > (XEN) (GUEST: 2) > (XEN) (GUEST: 2) Start BIOS ... > (XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=F000:FFF0 > (XEN) (GUEST: 2) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ > (XEN) (GUEST: 2) Remapping master: ICW2 0x8 -> 0x20 > (XEN) (GUEST: 2) Remapping slave: ICW2 0x70 -> 0x28 > (XEN) (GUEST: 2) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $ > (XEN) (GUEST: 2) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ > (XEN) (GUEST: 2) > (XEN) (GUEST: 2) ata0-0: PCHS=770/16/63 translation=none LCHS=770/16/63 > (XEN) (GUEST: 2) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (379 MBytes) > (XEN) (GUEST: 2) ata0 slave: Unknown device > (XEN) (GUEST: 2) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) (GUEST: 2) ata1 slave: Unknown device > (XEN) (GUEST: 2) > (XEN) (GUEST: 2) Booting from Hard Disk... > (XEN) (GUEST: 2) int13_harddisk: function 41, unmapped device for ELDL=81 > (XEN) (GUEST: 2) int13_harddisk: function 08, unmapped device for ELDL=81 > (XEN) (GUEST: 2) *** int 15h function AX=00C0, BX=0000 not yet supported! > (XEN) (GUEST: 2) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 2) KBD: unsupported int 16h function 03 > (XEN) (GUEST: 2) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) Local APIC Write to read-only register > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 1 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=8dc31000, HOST_CR3<=8cec8000 > (XEN) (GUEST: 2) Start AP 1 from 00002000 ... > (XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 2 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=8dc31000, HOST_CR3<=91f27000 > (XEN) (GUEST: 2) Start AP 2 from 00002000 ... > (XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 3 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=8dc31000, HOST_CR3<=91f26000 > (XEN) (GUEST: 2) Start AP 3 from 00002000 ... > (XEN) (GUEST: 2) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) vmx_do_launch(): GUEST_CR3<=981c4000, HOST_CR3<=981c5000 > (XEN) (GUEST: 3) HVM Loader > (XEN) (GUEST: 3) Loading ROMBIOS ... > (XEN) (GUEST: 3) Creating MP tables ... > (XEN) (GUEST: 3) Loading Cirrus VGABIOS ... > (XEN) (GUEST: 3) Loading ACPI ... > (XEN) (GUEST: 3) Loading VMXAssist ... > (XEN) (GUEST: 3) VMX go ... > (XEN) (GUEST: 3) VMXAssist (Aug 8 2006) > (XEN) (GUEST: 3) Memory size 128 MB > (XEN) (GUEST: 3) E820 map: > (XEN) (GUEST: 3) 0000000000000000 - 000000000009F800 (RAM) > (XEN) (GUEST: 3) 000000000009F800 - 00000000000A0000 (Reserved) > (XEN) (GUEST: 3) 00000000000A0000 - 00000000000C0000 (Type 16) > (XEN) (GUEST: 3) 00000000000F0000 - 0000000000100000 (Reserved) > (XEN) (GUEST: 3) 0000000000100000 - 0000000007FFE000 (RAM) > (XEN) (GUEST: 3) 0000000007FFE000 - 0000000007FFF000 (Type 18) > (XEN) (GUEST: 3) 0000000007FFF000 - 0000000008000000 (Type 17) > (XEN) (GUEST: 3) 0000000008000000 - 0000000008003000 (ACPI NVS) > (XEN) (GUEST: 3) 0000000008003000 - 000000000800D000 (ACPI Data) > (XEN) (GUEST: 3) 00000000FEC00000 - 0000000100000000 (Type 16) > (XEN) (GUEST: 3) > (XEN) (GUEST: 3) Start BIOS ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=F000:FFF0 > (XEN) (GUEST: 3) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ > (XEN) (GUEST: 3) Remapping master: ICW2 0x8 -> 0x20 > (XEN) (GUEST: 3) Remapping slave: ICW2 0x70 -> 0x28 > (XEN) (GUEST: 3) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $ > (XEN) (GUEST: 3) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ > (XEN) (GUEST: 3) > (XEN) (GUEST: 3) ata0-0: PCHS=770/16/63 translation=none LCHS=770/16/63 > (XEN) (GUEST: 3) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (379 MBytes) > (XEN) (GUEST: 3) ata0 slave: Unknown device > (XEN) (GUEST: 3) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) (GUEST: 3) ata1 slave: Unknown device > (XEN) (GUEST: 3) > (XEN) (GUEST: 3) Booting from Hard Disk... > (XEN) (GUEST: 3) int13_harddisk: function 41, unmapped device for ELDL=81 > (XEN) (GUEST: 3) int13_harddisk: function 08, unmapped device for ELDL=81 > (XEN) (GUEST: 3) *** int 15h function AX=00C0, BX=0000 not yet supported! > (XEN) (GUEST: 3) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 3) KBD: unsupported int 16h function 03 > (XEN) (GUEST: 3) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) Local APIC Write to read-only register > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 1 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=981c4000, HOST_CR3<=8ceec000 > (XEN) (GUEST: 3) Start AP 1 from 00002000 ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 2 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=981c4000, HOST_CR3<=8ceeb000 > (XEN) (GUEST: 3) Start AP 2 from 00002000 ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 3 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=981c4000, HOST_CR3<=8ceea000 > (XEN) (GUEST: 3) Start AP 3 from 00002000 ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > > [root@vt-px3 ~]# (XEN) vmx_do_launch(): GUEST_CR3<=95f40000, HOST_CR3<=95f41000 > (XEN) (GUEST: 4) HVM Loader > (XEN) (GUEST: 4) Loading ROMBIOS ... > (XEN) (GUEST: 4) Creating MP tables ... > (XEN) (GUEST: 4) Loading Cirrus VGABIOS ... > (XEN) (GUEST: 4) Loading ACPI ... > (XEN) (GUEST: 4) Loading VMXAssist ... > (XEN) (GUEST: 4) VMX go ... > (XEN) (GUEST: 4) VMXAssist (Aug 8 2006) > (XEN) (GUEST: 4) Memory size 128 MB > (XEN) (GUEST: 4) E820 map: > (XEN) (GUEST: 4) 0000000000000000 - 000000000009F800 (RAM) > (XEN) (GUEST: 4) 000000000009F800 - 00000000000A0000 (Reserved) > (XEN) (GUEST: 4) 00000000000A0000 - 00000000000C0000 (Type 16) > (XEN) (GUEST: 4) 00000000000F0000 - 0000000000100000 (Reserved) > (XEN) (GUEST: 4) 0000000000100000 - 0000000007FFE000 (RAM) > (XEN) (GUEST: 4) 0000000007FFE000 - 0000000007FFF000 (Type 18) > (XEN) (GUEST: 4) 0000000007FFF000 - 0000000008000000 (Type 17) > (XEN) (GUEST: 4) 0000000008000000 - 0000000008003000 (ACPI NVS) > (XEN) (GUEST: 4) 0000000008003000 - 000000000800D000 (ACPI Data) > (XEN) (GUEST: 4) 00000000FEC00000 - 0000000100000000 (Type 16) > (XEN) (GUEST: 4) > (XEN) (GUEST: 4) Start BIOS ... > (XEN) (GUEST: 4) Starting emulated 16-bit real-mode: ip=F000:FFF0 > (XEN) (GUEST: 4) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ > (XEN) (GUEST: 4) Remapping master: ICW2 0x8 -> 0x20 > (XEN) (GUEST: 4) Remapping slave: ICW2 0x70 -> 0x28 > (XEN) (GUEST: 4) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $ > (XEN) (GUEST: 4) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ > (XEN) (GUEST: 4) > (XEN) (GUEST: 4) ata0-0: PCHS=770/16/63 translation=none LCHS=770/16/63 > (XEN) (GUEST: 4) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (379 MBytes) > (XEN) (GUEST: 4) ata0 slave: Unknown device > (XEN) (GUEST: 4) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) (GUEST: 4) ata1 slave: Unknown device > (XEN) (GUEST: 4) > (XEN) (GUEST: 4) Booting from Hard Disk... > (XEN) (GUEST: 4) int13_harddisk: function 41, unmapped device for ELDL=81 > (XEN) (GUEST: 4) int13_harddisk: function 08, unmapped device for ELDL=81 > (XEN) (GUEST: 4) *** int 15h function AX=00C0, BX=0000 not yet supported! > (XEN) (GUEST: 4) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 4) KBD: unsupported int 16h function 03 > (XEN) (GUEST: 4) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) Local APIC Write to read-only register > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 1 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=95f40000, HOST_CR3<=986c4000 > (XEN) (GUEST: 4) Start AP 1 from 00002000 ... > (XEN) (GUEST: 4) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 2 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=95f40000, HOST_CR3<=986c3000 > (XEN) (GUEST: 4) Start AP 2 from 00002000 ... > (XEN) (GUEST: 4) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 3 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=95f40000, HOST_CR3<=986c2000 > (XEN) (GUEST: 4) Start AP 3 from 00002000 ... > (XEN) (GUEST: 4) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) vmx_do_launch(): GUEST_CR3<=90021000, HOST_CR3<=90022000 > (XEN) (GUEST: 5) HVM Loader > (XEN) (GUEST: 5) Loading ROMBIOS ... > (XEN) (GUEST: 5) Creating MP tables ... > (XEN) (GUEST: 5) Loading Cirrus VGABIOS ... > (XEN) (GUEST: 5) Loading ACPI ... > (XEN) (GUEST: 5) Loading VMXAssist ... > (XEN) (GUEST: 5) VMX go ... > (XEN) (GUEST: 5) VMXAssist (Aug 8 2006) > (XEN) (GUEST: 5) Memory size 128 MB > (XEN) (GUEST: 5) E820 map: > (XEN) (GUEST: 5) 0000000000000000 - 000000000009F800 (RAM) > (XEN) (GUEST: 5) 000000000009F800 - 00000000000A0000 (Reserved) > (XEN) (GUEST: 5) 00000000000A0000 - 00000000000C0000 (Type 16) > (XEN) (GUEST: 5) 00000000000F0000 - 0000000000100000 (Reserved) > (XEN) (GUEST: 5) 0000000000100000 - 0000000007FFE000 (RAM) > (XEN) (GUEST: 5) 0000000007FFE000 - 0000000007FFF000 (Type 18) > (XEN) (GUEST: 5) 0000000007FFF000 - 0000000008000000 (Type 17) > (XEN) (GUEST: 5) 0000000008000000 - 0000000008003000 (ACPI NVS) > (XEN) (GUEST: 5) 0000000008003000 - 000000000800D000 (ACPI Data) > (XEN) (GUEST: 5) 00000000FEC00000 - 0000000100000000 (Type 16) > (XEN) (GUEST: 5) > (XEN) (GUEST: 5) Start BIOS ... > (XEN) (GUEST: 5) Starting emulated 16-bit real-mode: ip=F000:FFF0 > (XEN) (GUEST: 5) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ > (XEN) (GUEST: 5) Remapping master: ICW2 0x8 -> 0x20 > (XEN) (GUEST: 5) Remapping slave: ICW2 0x70 -> 0x28 > (XEN) (GUEST: 5) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $ > (XEN) (GUEST: 5) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ > (XEN) (GUEST: 5) > (XEN) (GUEST: 5) ata0-0: PCHS=770/16/63 translation=none LCHS=770/16/63 > (XEN) (GUEST: 5) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (379 MBytes) > (XEN) (GUEST: 5) ata0 slave: Unknown device > (XEN) (GUEST: 5) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) (GUEST: 5) ata1 slave: Unknown device > (XEN) (GUEST: 5) > (XEN) (GUEST: 5) Booting from Hard Disk... > (XEN) (GUEST: 5) int13_harddisk: function 41, unmapped device for ELDL=81 > (XEN) (GUEST: 5) int13_harddisk: function 08, unmapped device for ELDL=81 > (XEN) (GUEST: 5) *** int 15h function AX=00C0, BX=0000 not yet supported! > (XEN) (GUEST: 5) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 5) KBD: unsupported int 16h function 03 > (XEN) (GUEST: 5) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) Local APIC Write to read-only register > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 1 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=90021000, HOST_CR3<=8cec1000 > (XEN) (GUEST: 5) Start AP 1 from 00002000 ... > (XEN) (GUEST: 5) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 2 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=90021000, HOST_CR3<=8cec0000 > (XEN) (GUEST: 5) Start AP 2 from 00002000 ... > (XEN) (GUEST: 5) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 3 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=90021000, HOST_CR3<=95f43000 > (XEN) (GUEST: 5) Start AP 3 from 00002000 ... > (XEN) (GUEST: 5) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) spurious IRQ irq got=-1 > (XEN) spurious IRQ irq got=-1 > (XEN) ----[ Xen-3.0-unstable Not tainted ]---- > (XEN) CPU: 1 > (XEN) EIP: e008:[<ff13bf28>] sh2_x86_emulate_write__shadow_2_guest_2+0x158/0x3d0 > (XEN) EFLAGS: 00010246 CONTEXT: hypervisor > (XEN) eax: 00000390 ebx: fec9d264 ecx: 0000009d edx: ff19e688 > (XEN) esi: ffbf3cdc edi: fec9d268 ebp: 00000004 esp: ffbf3c54 > (XEN) cr0: 8005003b cr3: 90022000 > (XEN) ds: e010 es: e010 fs: e010 gs: e010 ss: e010 cs: e008 > (XEN) Xen stack trace from esp=ffbf3c54: > (XEN) fec9d264 0000d9d1 fec9d264 00000004 ff19e514 00000400 ff19e498 0000d9d1 > (XEN) c7b12264 fffa8c78 00000000 07b12067 0000dd35 ffffffff 00000000 00000000 > (XEN) 00000000 ffbdc180 ffbdc180 00000000 c014ecff 00000000 00000000 ff136cd0 > (XEN) ffbdc180 c7b12264 ffbf3cd8 00000000 ffbf3ea4 00000000 00000000 ff12dcc7 > (XEN) c7b12264 07863025 00000004 ffbf3ea4 ffbdacbc 00000000 00000000 00000004 > (XEN) c014ecff 00000004 c7b12264 00000000 00000000 00000004 00000004 00000000 > (XEN) ffbda000 fee000b0 00000001 00000004 00000000 00000000 00000000 00000000 > (XEN) ffbf3dce ffbf3df4 00000004 ff14487e ffbf3e89 ffbdaca8 ffbdacbc ff15022a > (XEN) 00000086 ffbf3fb4 ff18d3c8 000001a5 ff1ab290 00000096 ffbef900 ffbef900 > (XEN) 00000080 ff1ab290 0000000b ff112eb9 00000007 0008cec0 0000000a 00000089 > (XEN) c10f0c60 00000025 00000000 c76b86fc c7b12264 c7569f1c 07863025 00f00003 > (XEN) c014ecff 00000060 00010246 c7569edc 00000068 0000007b 0000007b 00000000 > (XEN) 00000033 ffbf6080 000001a5 00000000 00000001 00000004 07863025 ff19e514 > (XEN) c7b12264 00000400 0000009a ffbf3f04 00000000 00000004 07863025 07863025 > (XEN) ffbf3dac 00000004 ff19e488 08099c09 ffbf3eb4 00000000 ffbdc180 ffbf3eb4 > (XEN) ffbdc180 00000040 0000d9d1 ff13b08b ffbf3ea4 ff1734e0 00000000 ff19f970 > (XEN) 00000246 ff19f7cc 0000002d ffc5d008 00000000 ffff262e ffbf3fb4 ff143cdf > (XEN) ffc5d008 ffffffff ff19e080 ff19f720 0008cdb9 fe3f9c78 fe71ec48 00000000 > (XEN) ff19e080 00000000 ffbdcdbc 00091f27 ffbf3eb4 c7b12264 00000004 ff150d3e > (XEN) c10f0c60 00000025 00000000 c76b86fc c7b12264 c7569f1c 07863025 00f00003 > (XEN) Xen call trace: > (XEN) [<ff13bf28>] sh2_x86_emulate_write__shadow_2_guest_2+0x158/0x3d0 > (XEN) [<ff136cd0>] sh2_x86_emulate_write_emulated+0x50/0x60 > (XEN) [<ff12dcc7>] x86_emulate_memop+0x1a17/0x2e90 > (XEN) [<ff14487e>] handle_mmio+0x76e/0x1590 > (XEN) [<ff15022a>] vmx_ctxt_switch_from+0x7a/0xf0 > (XEN) [<ff112eb9>] add_entry+0x49/0x100 > (XEN) [<ff13b08b>] sh2_page_fault__shadow_2_guest_2+0x67b/0xb40 > (XEN) [<ff143cdf>] send_pio_req+0x11f/0x210 > (XEN) [<ff150d3e>] vmx_io_instruction+0x21e/0x470 > (XEN) [<ff111759>] __enter_scheduler+0x189/0x2a0 > (XEN) [<ff153a23>] vmx_vmexit_handler+0xa03/0xde0 > (XEN) [<ff14e3cf>] cpu_has_pending_irq+0x3f/0x60 > (XEN) [<ff14e435>] vmx_intr_assist+0x45/0x380 > (XEN) [<ff11d6f6>] event_check_interrupt+0x46/0x50 > (XEN) [<ff111fd5>] do_softirq+0x25/0x40 > (XEN) [<ff153f4c>] vmx_asm_vmexit_handler+0x1c/0x30 > (XEN) > (XEN) Pagetable walk from fec9d264: > (XEN) L2 = 0019d063 55555555 > (XEN) L1 = 00000000 ffffffff > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 1: > (XEN) CPU1 FATAL PAGE FAULT > (XEN) [error_code=0000] > (XEN) Faulting linear address: fec9d264 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds...Content-Description: issue05_console.txt> > (XEN) vmx_do_launch(): GUEST_CR3<=00be0da0, HOST_CR3<=0a6b3000 > (XEN) (GUEST: 3) HVM Loader > (XEN) (GUEST: 3) Loading ROMBIOS ... > (XEN) (GUEST: 3) Creating MP tables ... > (XEN) (GUEST: 3) Loading Cirrus VGABIOS ... > (XEN) (GUEST: 3) Loading ACPI ... > (XEN) (GUEST: 3) Loading VMXAssist ... > (XEN) (GUEST: 3) VMX go ... > (XEN) (GUEST: 3) VMXAssist (Aug 8 2006) > (XEN) (GUEST: 3) Memory size 256 MB > (XEN) (GUEST: 3) E820 map: > (XEN) (GUEST: 3) 0000000000000000 - 000000000009F800 (RAM) > (XEN) (GUEST: 3) 000000000009F800 - 00000000000A0000 (Reserved) > (XEN) (GUEST: 3) 00000000000A0000 - 00000000000C0000 (Type 16) > (XEN) (GUEST: 3) 00000000000F0000 - 0000000000100000 (Reserved) > (XEN) (GUEST: 3) 0000000000100000 - 000000000FFFE000 (RAM) > (XEN) (GUEST: 3) 000000000FFFE000 - 000000000FFFF000 (Type 18) > (XEN) (GUEST: 3) 000000000FFFF000 - 0000000010000000 (Type 17) > (XEN) (GUEST: 3) 0000000010000000 - 0000000010003000 (ACPI NVS) > (XEN) (GUEST: 3) 0000000010003000 - 000000001000D000 (ACPI Data) > (XEN) (GUEST: 3) 00000000FEC00000 - 0000000100000000 (Type 16) > (XEN) (GUEST: 3) > (XEN) (GUEST: 3) Start BIOS ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=F000:FFF0 > (XEN) (GUEST: 3) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ > (XEN) (GUEST: 3) Remapping master: ICW2 0x8 -> 0x20 > (XEN) (GUEST: 3) Remapping slave: ICW2 0x70 -> 0x28 > (XEN) (GUEST: 3) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $(XEN) (GUEST: 3) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ > (XEN) (GUEST: 3) > (XEN) (GUEST: 3) ata0-0: PCHS=10240/16/63 translation=none LCHS=1024/16/63 > (XEN) (GUEST: 3) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (5040 MBytes) > (XEN) (GUEST: 3) ata0 slave: Unknown device > (XEN) (GUEST: 3) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) (GUEST: 3) ata1 slave: Unknown device > (XEN) (GUEST: 3) > (XEN) (GUEST: 3) Booting from Hard Disk... > (XEN) (GUEST: 3) int13_harddisk: function 41, unmapped device for ELDL=81 > (XEN) (GUEST: 3) int13_harddisk: function 08, unmapped device for ELDL=81 > (XEN) (GUEST: 3) *** int 15h function AX=00C0, BX=0000 not yet supported! > (XEN) (GUEST: 3) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 3) KBD: unsupported int 16h function 03 > (XEN) (GUEST: 3) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 3) *** int 15h function AX=E980, BX=E6F5 not yet supported! > (XEN) (GUEST: 3) int13_harddisk: function 02, unmapped device for ELDL=81 > (XEN) (GUEST: 3) int13_harddisk: function 41, unmapped device for ELDL=81 > (XEN) Local APIC Write to read-only register > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 1 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=001bfda0, HOST_CR3<=0a698000 > (XEN) (GUEST: 3) Start AP 1 from 00003000 ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=0300:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 2 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=001beda0, HOST_CR3<=0a695000 > (XEN) (GUEST: 3) Start AP 2 from 00003000 ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=0300:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 3 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=001bdda0, HOST_CR3<=0a693000 > (XEN) (GUEST: 3) Start AP 3 from 00003000 ... > (XEN) (GUEST: 3) Starting emulated 16-bit real-mode: ip=0300:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) sh2 error: sh2_remove_shadows(): can''t find all shadows of mfn 0aae6 (shadow2_flags=00000100) > (XEN) domain_crash called from shadow2-common.c:2227 > (XEN) Domain 3 (vcpu#2) crashed on cpu#0: > (XEN) ----[ Xen-3.0-unstable Not tainted ]---- > (XEN) CPU: 0 > (XEN) EIP: 0060:[<c01469a9>] > (XEN) EFLAGS: 00010006 CONTEXT: hvm > (XEN) eax: 00000020 ebx: c13a8000 ecx: cfc56000 edx: 00000021 > (XEN) esi: 0000000f edi: cfffbe08 ebp: cfffbd80 esp: cf99fe48 > (XEN) cr0: 8005003b cr3: 001beda0 > (XEN) ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068 cs: 0060 > (XEN) vmx_do_launch(): GUEST_CR3<=001b0da0, HOST_CR3<=1a6b3000Content-Description: issue06_console_log.txt> (XEN) (GUEST: 6) HVM Loader > (XEN) (GUEST: 6) Loading ROMBIOS ... > (XEN) (GUEST: 6) Creating MP tables ... > (XEN) (GUEST: 6) Loading Cirrus VGABIOS ... > (XEN) (GUEST: 6) Loading ACPI ... > (XEN) (GUEST: 6) Loading VMXAssist ... > (XEN) (GUEST: 6) VMX go ... > (XEN) (GUEST: 6) VMXAssist (Aug 8 2006) > (XEN) (GUEST: 6) Memory size 256 MB > (XEN) (GUEST: 6) E820 map: > (XEN) (GUEST: 6) 0000000000000000 - 000000000009F800 (RAM) > (XEN) (GUEST: 6) 000000000009F800 - 00000000000A0000 (Reserved) > (XEN) (GUEST: 6) 00000000000A0000 - 00000000000C0000 (Type 16) > (XEN) (GUEST: 6) 00000000000F0000 - 0000000000100000 (Reserved) > (XEN) (GUEST: 6) 0000000000100000 - 000000000FFFE000 (RAM) > (XEN) (GUEST: 6) 000000000FFFE000 - 000000000FFFF000 (Type 18) > (XEN) (GUEST: 6) 000000000FFFF000 - 0000000010000000 (Type 17) > (XEN) (GUEST: 6) 0000000010000000 - 0000000010003000 (ACPI NVS) > (XEN) (GUEST: 6) 0000000010003000 - 000000001000D000 (ACPI Data) > (XEN) (GUEST: 6) 00000000FEC00000 - 0000000100000000 (Type 16) > (XEN) (GUEST: 6) > (XEN) (GUEST: 6) Start BIOS ... > (XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=F000:FFF0 > (XEN) (GUEST: 6) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ > (XEN) (GUEST: 6) Remapping master: ICW2 0x8 -> 0x20 > (XEN) (GUEST: 6) Remapping slave: ICW2 0x70 -> 0x28 > (XEN) (GUEST: 6) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $(XEN) (GUEST: 6) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ > (XEN) (GUEST: 6) > (XEN) (GUEST: 6) ata0-0: PCHS=10240/16/63 translation=none LCHS=1024/16/63 > (XEN) (GUEST: 6) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (5040 MBytes) > (XEN) (GUEST: 6) ata0 slave: Unknown device > (XEN) (GUEST: 6) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) (GUEST: 6) ata1 slave: Unknown device > (XEN) (GUEST: 6) > (XEN) (GUEST: 6) Booting from Hard Disk... > (XEN) (GUEST: 6) int13_harddisk: function 41, unmapped device for ELDL=81 > (XEN) (GUEST: 6) int13_harddisk: function 08, unmapped device for ELDL=81 > (XEN) (GUEST: 6) *** int 15h function AX=00C0, BX=0000 not yet supported! > (XEN) (GUEST: 6) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 6) KBD: unsupported int 16h function 03 > (XEN) (GUEST: 6) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) Local APIC Write to read-only register > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 1 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=00befda0, HOST_CR3<=14695000 > (XEN) (GUEST: 6) Start AP 1 from 00002000 ... > (XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 2 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=00beeda0, HOST_CR3<=14693000 > (XEN) (GUEST: 6) Start AP 2 from 00002000 ... > (XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) This hvm_vlapic is for P4, no work for De-assert init > (XEN) AP 3 bringup suceeded. > (XEN) vmx_do_launch(): GUEST_CR3<=00bedda0, HOST_CR3<=14691000 > (XEN) (GUEST: 6) Start AP 3 from 00002000 ... > (XEN) (GUEST: 6) Starting emulated 16-bit real-mode: ip=0200:0000 > (XEN) ----[ Xen-3.0-unstable Not tainted ]---- > (XEN) CPU: 0 > (XEN) EIP: e008:[<ff157099>] sh2_x86_emulate_write__shadow_3_guest_2+0x1b9/0x430 > (XEN) EFLAGS: 00010246 CONTEXT: hypervisor > (XEN) eax: ff1b6000 ebx: fed8a39c ecx: 00015733 edx: 00000000 > (XEN) esi: ff1c7cac edi: fed8a3a0 ebp: 00000004 esp: ff1c7c14 > (XEN) cr0: 8005003b cr3: 146b3000 > (XEN) ds: e010 es: e010 fs: e010 gs: e010 ss: e010 cs: e008 > (XEN) Xen stack trace from esp=ff1c7c14: > (XEN) fed8a39c 00015733 fed8a39c 00000004 00015235 ff216490 ff1b6000 ff1b0080 > (XEN) fed89bf3 ff1c7d55 00000001 00015733 cf00939c fff6ccf0 00000000 0f009067 > (XEN) 00015235 ffffffff 00000000 ffffffff ff1b0080 ff1b0080 00000006 00000000 > (XEN) c014abf3 00000000 00000000 ff1510b0 ff1b0080 cf00939c ff1c7ca8 00000000 > (XEN) ff1c7ea4 00000000 00000000 ff130157 cf00939c 0f417067 00000004 ff1c7ea4 > (XEN) ff1b0d3c 00000000 000008fc 00000004 c014abf3 00000004 cf00939c 00000000 > (XEN) 00000000 00000004 00000004 00000000 f6a02c02 fee00300 00000001 fed60048 > (XEN) 00000000 15733667 00000000 00004382 157336ce 00000000 ff216080 000002a0 > (XEN) ff1b0089 ff216480 ff216514 ff216080 00000001 ff216490 ff1b6000 00000000 > (XEN) fed60048 00000009 00015733 ff156abe fed60000 00000000 00014472 ff15c91e > (XEN) 00000016 00202cc8 fed5f000 00000089 c11e82e0 cfa2090c 0f417067 cf00939c > (XEN) c11e012c c11ed860 0f417025 00b80003 c014abf3 00000060 00010202 cf813f04 > (XEN) 00000068 0000007b 0000007b 00000000 00000033 ff118eae ff216544 00000280 > (XEN) 00000001 00000004 0f417067 ff216514 cf00939c 00000400 00000188 00000001 > (XEN) 00000000 00000004 0f417067 0f417067 ff1c7d6c 00000004 ff1b6000 ff216080 > (XEN) ff1c7eb4 00000000 ff1b0080 ff1c7eb4 cf00939c 00000000 ff1b0080 ff155d9f > (XEN) ff1c7ea4 ff194ee0 00000000 00000002 fff10008 ff2177cc ff1b0080 00000202 > (XEN) ff217764 00000000 ff1c7fb4 ff1619e6 00000020 00000000 00000002 fffea8cc > (XEN) 00000265 00000000 ff216080 00015733 00000762 00000000 ff216080 000145fb > (XEN) fdff33c0 fe678048 00000000 00000006 00015733 ff216080 00000000 00000000 > (XEN) Xen call trace: > (XEN) [<ff157099>] sh2_x86_emulate_write__shadow_3_guest_2+0x1b9/0x430 > (XEN) [<ff1510b0>] sh2_x86_emulate_write_emulated+0x50/0x60 > (XEN) [<ff130157>] x86_emulate_memop+0x1a17/0x2e90 > (XEN) [<ff156abe>] sh2_remove_write_access__shadow_3_guest_2+0xbe/0x1a0 > (XEN) [<ff15c91e>] sh2_remove_write_access__shadow_3_guest_3+0xbe/0xd0 > (XEN) [<ff118eae>] __find_next_zero_bit+0x8e/0xa0 > (XEN) [<ff155d9f>] sh2_page_fault__shadow_3_guest_2+0x7bf/0xce0 > (XEN) [<ff1619e6>] pit_latch_count+0x16/0x30 > (XEN) [<ff12a84a>] smp_call_function_interrupt+0x5a/0xa0 > (XEN) [<ff171aa5>] __update_guest_eip+0x45/0x60 > (XEN) [<ff174b23>] vmx_vmexit_handler+0xa03/0xdf0 > (XEN) [<ff16f2cf>] cpu_has_pending_irq+0x3f/0x60 > (XEN) [<ff16f335>] vmx_intr_assist+0x45/0x380 > (XEN) [<ff1136ba>] timer_softirq_action+0x10a/0x140 > (XEN) [<ff17505c>] vmx_asm_vmexit_handler+0x1c/0x30 > (XEN) > (XEN) Pagetable walk from fed8a39c: > (XEN) L3 = 00000000146b2001 0000c08a > (XEN) L2 = 00000000001b6063 55555555 > (XEN) L1 = 0000000000000000 ffffffff > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) CPU0 FATAL PAGE FAULT > (XEN) [error_code=0000] > (XEN) Faulting linear address: fed8a39c > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds...Content-Description: issue09_console_log.txt> vt-gs1 login: (XEN) vmx_do_launch(): GUEST_CR3<=00bd6da0, HOST_CR3<=0c6af000 > (XEN) (GUEST: 9) HVM Loader > (XEN) (GUEST: 9) Loading ROMBIOS ... > (XEN) (GUEST: 9) Creating MP tables ... > (XEN) (GUEST: 9) Loading Cirrus VGABIOS ... > (XEN) (GUEST: 9) Loading ACPI ... > (XEN) (GUEST: 9) Loading VMXAssist ... > (XEN) (GUEST: 9) VMX go ... > (XEN) (GUEST: 9) VMXAssist (Aug 8 2006) > (XEN) (GUEST: 9) Memory size 256 MB > (XEN) (GUEST: 9) E820 map: > (XEN) (GUEST: 9) 0000000000000000 - 000000000009F800 (RAM) > (XEN) (GUEST: 9) 000000000009F800 - 00000000000A0000 (Reserved) > (XEN) (GUEST: 9) 00000000000A0000 - 00000000000C0000 (Type 16) > (XEN) (GUEST: 9) 00000000000F0000 - 0000000000100000 (Reserved) > (XEN) (GUEST: 9) 0000000000100000 - 000000000FFFE000 (RAM) > (XEN) (GUEST: 9) 000000000FFFE000 - 000000000FFFF000 (Type 18) > (XEN) (GUEST: 9) 000000000FFFF000 - 0000000010000000 (Type 17) > (XEN) (GUEST: 9) 0000000010000000 - 0000000010003000 (ACPI NVS) > (XEN) (GUEST: 9) 0000000010003000 - 000000001000D000 (ACPI Data) > (XEN) (GUEST: 9) 00000000FEC00000 - 0000000100000000 (Type 16) > (XEN) (GUEST: 9) > (XEN) (GUEST: 9) Start BIOS ... > (XEN) (GUEST: 9) Starting emulated 16-bit real-mode: ip=F000:FFF0 > (XEN) (GUEST: 9) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ > (XEN) (GUEST: 9) Remapping master: ICW2 0x8 -> 0x20 > (XEN) (GUEST: 9) Remapping slave: ICW2 0x70 -> 0x28 > (XEN) (GUEST: 9) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $(XEN) (GUEST: 9) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ > (XEN) (GUEST: 9) > (XEN) (GUEST: 9) ata0-0: PCHS=6243/16/63 translation=lba LCHS=780/128/63 > (XEN) (GUEST: 9) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (3073 MBytes) > (XEN) (GUEST: 9) ata0 slave: Unknown device > (XEN) (GUEST: 9) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) (GUEST: 9) ata1 slave: Unknown device > (XEN) (GUEST: 9) > (XEN) (GUEST: 9) Booting from Hard Disk... > (XEN) (GUEST: 9) unsupported PCI BIOS function 0x0E > (XEN) (GUEST: 9) int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) (GUEST: 9) *** int 15h function AX=E980, BX=00DA not yet supported! > (XEN) ----[ Xen-3.0-unstable Not tainted ]---- > (XEN) CPU: 1 > (XEN) EIP: e008:[<ff157099>] sh2_x86_emulate_write__shadow_3_guest_2+0x1b9/0x430 > (XEN) EFLAGS: 00010246 CONTEXT: hypervisor > (XEN) eax: ffbda000 ebx: fee323d4 ecx: 00034576 edx: 00000000 > (XEN) esi: ff20bcac edi: fee323d8 ebp: 00000004 esp: ff20bc14 > (XEN) cr0: 8005003b cr3: 0c6af000 > (XEN) ds: e010 es: e010 fs: e010 gs: e010 ss: e010 cs: e008 > (XEN) Xen stack trace from esp=ff20bc14: > (XEN) fee323d4 00034576 fee323d4 00000004 ff1ba514 ff1ba4b0 ffbda000 ffbd6080 > (XEN) fee313d8 ff20bdc0 00000004 00034576 c00093d4 ffcd7c00 fee29024 0e1fb067 > (XEN) 0000babe 0000babe 00000000 00000000 00000000 ffbd6080 ff11e0c6 00000000 > (XEN) 804f0c44 00000000 00000000 ff1510b0 ffbd6080 c00093d4 ff20bca8 00000000 > (XEN) ff20bea4 00000000 00000202 ff130157 c00093d4 fffff420 00000004 ff20bea4 > (XEN) ffbd6d3c 00000003 00000000 ff164acd 804f0c44 00000004 c00093d4 00000000 > (XEN) 00000000 00000004 00000004 00000000 f6ab8f01 000b8004 00000001 fedae920 > (XEN) ed2c3131 00000e9e 00000000 00002290 1383da4e ff20bd88 0000e215 00000006 > (XEN) 00000031 00000000 00000002 00000001 00000000 00034576 f6ce8310 ff122238 > (XEN) f6ce8310 00000000 00000080 fe600048 00000000 34576667 00000000 ff154382 > (XEN) 0000000e 00000000 ff1ba080 00000031 8163b020 000000a0 00000009 c00093d4 > (XEN) c0300024 f9511d4c 00000001 00f00003 804f0c44 00000008 00010282 f9511d1c > (XEN) 00000010 00000023 00000023 00000030 00000000 ff118eae ff1ba550 00000220 > (XEN) 00000001 00000004 fffff420 fffff480 c00093d4 00000400 00000229 00000001 > (XEN) 00000000 00000004 000000a0 000000a0 ff20bd68 0000babe 00000001 c00093d4 > (XEN) ff20beb4 00000000 ffbd6080 ff20beb4 c00093d4 fee29024 ffbd6080 ff155d9f > (XEN) ff20bea4 ff194ee0 00000000 00000006 ff1bb744 ff1bb7cc ff1bb7cc 00000246 > (XEN) ff1bb7cc 00000000 ff20bfb4 ff1bb744 00000020 00000000 00000002 fffcba89 > (XEN) 00000661 00000000 ff1ba080 0000babe 00000663 00000000 ff1ba080 0000c683 > (XEN) fdff3000 fe600048 00000000 00000006 00034576 ff1ba080 00000000 00000000 > (XEN) Xen call trace: > (XEN) [<ff157099>] sh2_x86_emulate_write__shadow_3_guest_2+0x1b9/0x430 > (XEN) [<ff11e0c6>] apic_timer_interrupt+0x46/0x50 > (XEN) [<ff1510b0>] sh2_x86_emulate_write_emulated+0x50/0x60 > (XEN) [<ff130157>] x86_emulate_memop+0x1a17/0x2e90 > (XEN) [<ff164acd>] hvm_wait_io+0x4d/0xc0 > (XEN) [<ff122238>] put_page_from_l1e+0x78/0x130 > (XEN) [<ff154382>] shadow_set_l1e+0x192/0x1c0 > (XEN) [<ff118eae>] __find_next_zero_bit+0x8e/0xa0 > (XEN) [<ff155d9f>] sh2_page_fault__shadow_3_guest_2+0x7bf/0xce0 > (XEN) [<ff171cde>] vmx_io_instruction+0x21e/0x470 > (XEN) [<ff174b23>] vmx_vmexit_handler+0xa03/0xdf0 > (XEN) [<ff16f2cf>] cpu_has_pending_irq+0x3f/0x60 > (XEN) [<ff16f335>] vmx_intr_assist+0x45/0x380 > (XEN) [<ff1136ba>] timer_softirq_action+0x10a/0x140 > (XEN) [<ff17505c>] vmx_asm_vmexit_handler+0x1c/0x30 > (XEN) > (XEN) Pagetable walk from fee323d4: > (XEN) L3 = 000000000c6ae001 0001188e > (XEN) L2 = 0000000000bdb063 55555555 > (XEN) L1 = 0000000000000000 ffffffff > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 1: > (XEN) CPU1 FATAL PAGE FAULT > (XEN) [error_code=0000] > (XEN) Faulting linear address: fee323d4 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds..._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, At 16:36 -0400 on 13 Aug (1155486984), Puthiyaparambil, Aravindh wrote:> I tried bringing up as many x86_32 UP WinXP domains as I could. I found > that the qemu-dm process associated with each domain took up 50% cpu.Are you auto-ballooing memory from dom0 for these domains? One failure mode of the memory allocation bug is that there is enough memory to start the domain but not enough for qemu-dm to allocate its video card. The domain then falls back to the much more cpu-intensive VGA support.> Bringing up a domain with pae=1 crashes the system. I have attached the > output. I tried this with a Win2003 server image.Thanks; this is a known bug but the fix didn''t make it into that patch. :(> I could not bring up any x86_64 domains. When I tried a SLES10 x86_64 > image I got a message saying "Your CPU does not support long mode. Use a > 32-bit distribution"I''ll look into that; sounds like the results of CPUID are confusing the linux kernel. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh
2006-Aug-15 13:29 UTC
RE: [Xen-devel] [RFC] New shadow paging code
> At 16:36 -0400 on 13 Aug (1155486984), Puthiyaparambil, Aravindhwrote:> > I tried bringing up as many x86_32 UP WinXP domains as I could. Ifound> > that the qemu-dm process associated with each domain took up 50%cpu.> > Are you auto-ballooing memory from dom0 for these domains? Onefailure> mode of the memory allocation bug is that there is enough memory to > start the domain but not enough for qemu-dm to allocate its videocard.> The domain then falls back to the much more cpu-intensive VGA support.I booted the system with dom0_mem=512M. So auto-ballooning does not take place. I noticed that the same thing happens with xen-unstable without the shadow2 patch. Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 14:24 +0100 on 15 Aug (1155651854), Tim Deegan wrote:> > I could not bring up any x86_64 domains. When I tried a SLES10 x86_64 > > image I got a message saying "Your CPU does not support long mode. Use a > > 32-bit distribution" > > I''ll look into that; sounds like the results of CPUID are confusing the > linux kernel.Since you were hitting a bug with pae=1, I assume that error happened with pae=0? In that case it''s not surprising: x86_64 linux requires PAE support (among other things) to boot, and "Your CPU does not support long mode" is its generic response to not finding a required feature. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh
2006-Aug-15 15:34 UTC
RE: [Xen-devel] [RFC] New shadow paging code
> > > > I''ll look into that; sounds like the results of CPUID are confusingthe> > linux kernel. > > Since you were hitting a bug with pae=1, I assume that error happened > with pae=0? In that case it''s not surprising: x86_64 linux requiresPAE> support (among other things) to boot, and "Your CPU does not support > long mode" is its generic response to not finding a required feature.Ah yes, I had not set pae=1 when trying the x86_64 boot. I did not realize that it was required. I thought all that I needed was ACPI=1 and APIC=1. Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
A new version of the shadow2 patch is now available at http://www.cl.cam.ac.uk/~tjd21/shadow2.patch (md5: 3a094d3eebf328db887f495c022bf651) This patch applies to version 0e32095a7b46 of -unstable. It should fix the issues that have been seen with memory allocation and with 64-bit HVM guests. SMP HVM guests may still have some problems. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh
2006-Aug-17 04:48 UTC
RE: [Xen-devel] [RFC] New shadow paging code
Tim, I tried the patch on a 4-way x86_64 ES7000 32GB RAM with an x86_64 hypervisor. I found that I am still unable to bring up domains with pae=1. I have attached the error that I am seeing (hvm_pae.txt) I then tried bringing up as many x86_32 WinXP domains as possible. The qemu-dm process associated with each domain takes up 50% CPU. So I am unable to bring up more than 8 (2 * NR_CPUS) domains. Let me know if you need any more info. Cheers, Aravindh> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Tim Deegan > Sent: Wednesday, August 16, 2006 6:35 AM > To: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [RFC] New shadow paging code > > A new version of the shadow2 patch is now available at > http://www.cl.cam.ac.uk/~tjd21/shadow2.patch > (md5: 3a094d3eebf328db887f495c022bf651) > This patch applies to version 0e32095a7b46 of -unstable. > > It should fix the issues that have been seen with memory allocationand> with 64-bit HVM guests. SMP HVM guests may still have some problems. > > Cheers, > > Tim. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh
2006-Aug-17 04:59 UTC
RE: [Xen-devel] [RFC] New shadow paging code
I also found that if I don''t bring up vncviewer, qemu-dm does not take up 50% CPU. But I still fail trying to bring up the 9th domain with the following error: Error: Device 768 (vbd) could not be connected. Backend device not found. Aravindh> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Puthiyaparambil, Aravindh > Sent: Thursday, August 17, 2006 12:48 AM > To: Tim Deegan; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] [RFC] New shadow paging code > > Tim, > > I tried the patch on a 4-way x86_64 ES7000 32GB RAM with an x86_64 > hypervisor. > > I found that I am still unable to bring up domains with pae=1. I have > attached the error that I am seeing (hvm_pae.txt) > > I then tried bringing up as many x86_32 WinXP domains as possible. The > qemu-dm process associated with each domain takes up 50% CPU. So I am > unable to bring up more than 8 (2 * NR_CPUS) domains. > > Let me know if you need any more info. > Cheers, > Aravindh > > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > > bounces@lists.xensource.com] On Behalf Of Tim Deegan > > Sent: Wednesday, August 16, 2006 6:35 AM > > To: xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] [RFC] New shadow paging code > > > > A new version of the shadow2 patch is now available at > > http://www.cl.cam.ac.uk/~tjd21/shadow2.patch > > (md5: 3a094d3eebf328db887f495c022bf651) > > This patch applies to version 0e32095a7b46 of -unstable. > > > > It should fix the issues that have been seen with memory allocation > and > > with 64-bit HVM guests. SMP HVM guests may still have someproblems.> > > > Cheers, > > > > Tim. > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh
2006-Aug-17 07:00 UTC
RE: [Xen-devel] [RFC] New shadow paging code
Ooops!!! I realized why I could not bring up more than 8 domains. I was using loopback devices for the winxp disks and max_loop was by default set to 8. So once I upped the max_loop number I was able to bring up more domains. What I did was, I brought up 20 WinXP x86_32 domains without launching their respective vncviewers. Once all the domains were up I launched 10 viewers and this caused qemu-dm of the 10 launched domains to hit 40-50% CPU. All the viewers were sluggish and no real work could be done. Aravindh> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Puthiyaparambil, Aravindh > Sent: Thursday, August 17, 2006 12:59 AM > To: Tim Deegan; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] [RFC] New shadow paging code > > I also found that if I don''t bring up vncviewer, qemu-dm does not take > up 50% CPU. But I still fail trying to bring up the 9th domain withthe> following error: > Error: Device 768 (vbd) could not be connected. Backend device not > found. > > Aravindh > > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > > bounces@lists.xensource.com] On Behalf Of Puthiyaparambil, Aravindh > > Sent: Thursday, August 17, 2006 12:48 AM > > To: Tim Deegan; xen-devel@lists.xensource.com > > Subject: RE: [Xen-devel] [RFC] New shadow paging code > > > > Tim, > > > > I tried the patch on a 4-way x86_64 ES7000 32GB RAM with an x86_64 > > hypervisor. > > > > I found that I am still unable to bring up domains with pae=1. Ihave> > attached the error that I am seeing (hvm_pae.txt) > > > > I then tried bringing up as many x86_32 WinXP domains as possible.The> > qemu-dm process associated with each domain takes up 50% CPU. So Iam> > unable to bring up more than 8 (2 * NR_CPUS) domains. > > > > Let me know if you need any more info. > > Cheers, > > Aravindh > > > > > -----Original Message----- > > > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > > > bounces@lists.xensource.com] On Behalf Of Tim Deegan > > > Sent: Wednesday, August 16, 2006 6:35 AM > > > To: xen-devel@lists.xensource.com > > > Subject: Re: [Xen-devel] [RFC] New shadow paging code > > > > > > A new version of the shadow2 patch is now available at > > > http://www.cl.cam.ac.uk/~tjd21/shadow2.patch > > > (md5: 3a094d3eebf328db887f495c022bf651) > > > This patch applies to version 0e32095a7b46 of -unstable. > > > > > > It should fix the issues that have been seen with memoryallocation> > and > > > with 64-bit HVM guests. SMP HVM guests may still have some > problems. > > > > > > Cheers, > > > > > > Tim. > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, At 00:48 -0400 on 17 Aug (1155775694), Puthiyaparambil, Aravindh wrote:> I found that I am still unable to bring up domains with pae=1. I have > attached the error that I am seeing (hvm_pae.txt)What guest OS were you using? How far through the boot process did it get? Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Puthiyaparambil, Aravindh
2006-Aug-17 15:02 UTC
RE: [Xen-devel] [RFC] New shadow paging code
> > I found that I am still unable to bring up domains with pae=1. Ihave> > attached the error that I am seeing (hvm_pae.txt) > > What guest OS were you using? How far through the boot process did it > get?I am using x86_64 SLES10. It got up to the point of "Booting the kernel" and then the crash happens. So it is very early in the boot. Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan <Tim.Deegan@xensource.com> wrote on 08/16/2006 05:34:40 AM:> A new version of the shadow2 patch is now available at > http://www.cl.cam.ac.uk/~tjd21/shadow2.patch > (md5: 3a094d3eebf328db887f495c022bf651) > This patch applies to version 0e32095a7b46 of -unstable. > > It should fix the issues that have been seen with memory allocation and > with 64-bit HVM guests. SMP HVM guests may still have some problems.Tim, I can''t get an HVM domU to finish booting. dom0 and domU are both running 64-bit SLES 10-beta10 with uniprocessor 2.6.16.13 kernels. The domU gets as far as running grub and loading the kernel and initrd but then hangs. xentop shows the domU running at 100% CPU. For what its worth, I have tried all combinations of the pae, acpi, and apic options. With pae=1 the domU dies (I assume qemu either exits or dies). With pae=0 the domU hangs as described regardless of the settings of acpi and apic. The machine has four sockets with Intel Xeon 7020 (2.66 GHz dual core with hyperthreading). Here is the config file for the domain: (See attached file: hvm1.cfg) Any other info you need? Anything I should examine or try? Steve D. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel