search for: domain_crash

...ce time. So we did some investigation on its usage in current XEN. Also we have some discussion with Keir. The following writeup logged down them. It might be useful to those who have interest in XEN''s error handling. [Current error handler in XEN] We have five error handlers in XEN. 1) domain_crash 2) panic 3) BUG_ON 4) ASSERT 5) BUG domain_crash only impact the crashed domain, while other four handlers will cause whole system/machine halt/reboot. Panic/BUG_ON/ASSERT/BUG has slight differences: 1) ASSERT only takes effect when DEBUG=y while other three handlers takes effect even if DEBUG=y...

...- vcpu_set_affinity(d->vcpu[0], cpumask_of(cpu)); - vcpu_kick(d->vcpu[0]); - } - else - { - mce_printk(MCE_VERBOSE, - "MCE: Kill PV guest with No MCE handler\n"); - domain_crash(d); - } + mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n", + d->domain_id, v->vcpu_id); + return -1; } } - else - { - /* new vMCE comes while first one has not been injected yet, -...

Hello All, I''m contemplating ways to avoid the domain_crash() in mm.c line ~615 without requiring new OS hooks. This crash occurs when the operating system writes a zero to the PTE for a grant mapping without an explicit Xen call to unmap. In hacking around, it seems the problem is this: When the mapping PTE gets squashed, Xen''s cleanup_writable...

I was trying to install Ubuntu 7.10 on an HVM domain, when when the install kept hanging at a particular point. xm dmesg shows the following : (XEN) realmode.c:132:d28 Failed to emulate insn. (XEN) realmode.c:174:d28 Real-mode emulation failed @ 0000:00007f34: 0f 2c 06 08 6b 04 (XEN) domain_crash called from realmode.c:175 (XEN) Domain 28 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-3.4-unstable x86_32p debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) EIP: 0000:[<00007f34>] (XEN) EFLAGS: 00000206 CONTEXT: hvm guest (XEN) eax: 00001680 ebx: 00007bff ecx: 00000001 edx: 000001...

I''ve been working form the netfront.c in the testing tree and using SLES 10 RC1 for i386 on a SMP box. When I stress the network using iperf in a domU, domU acting as client on a gigabit network, I occasionally get a panic at the dev_kfree_skb_irq(skb); line. This is the same panic as reported in http://lists.xensource.com/archives/html/xen-devel/2006-05/msg00919.html The trace

The patch ''mem_event: use wait queue when ring is full'' I just sent out makes use of the waitqueue feature. There are two issues I get with the change applied: I think I got the logic right, and in my testing vcpu->pause_count drops to zero in p2m_mem_paging_resume(). But for some reason the vcpu does not make progress after the first wakeup. In my debugging there is one

...39;'t make any > difference to the behaviour, while 11160 is fairly obviously > irrelevant to this kind of thing. > > With or without 11161, I see guests crashing with > > (XEN) sh error: sh_page_fault__shadow_3_guest_2(): disabled-APIC access: > not supported > (XEN) .domain_crash called from multi.c:3197 > (XEN) Domain 3 (vcpu#0) crashed on cpu#1: > (XEN) ----[ Xen-3.0-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 1 > (XEN) RIP: 0008:[<000000008081d1ac>] > (XEN) RFLAGS: 0000000000010086 CONTEXT: hvm > (XEN) rax: 00000000ffd01000...

This patch series includes a series of bugs related to p2m, ept, and PoD code which were found as part of our XenServer product testing. Each of these fixes actual bugs, and the 3.4-based version of the patch has been tested thoroughly. (There may be bugs in porting the patches, but most of them are simple enough as to make it unlikely.) Each patch is conceptually independent, so they can each

Hi Steven, I still saw this bug when booting a win2003 server with 5G memory on changeset 11655. (XEN) sh error: sh_remove_shadows(): can''t find all shadows of mfn 1f2cdf (shadow_flags=00000100) (XEN) domain_crash called from common.c:2197 (XEN) Domain 4 (vcpu#0) crashed on cpu#2: (XEN) ----[ Xen-3.0-unstable x86_64 debug=n Not tainted ]---- (XEN) CPU: 2 (XEN) RIP: 0008:[<0000000080867bd5>] (XEN) RFLAGS: 0000000000010246 CONTEXT: hvm (XEN) rax: 00000000ee604801 rbx: 0000000000000000 rcx:...

...des(struc "this HVM vcpu''s (d=%u v=%u) paging mode!\n", current->domain->domain_id, current->vcpu_id, v->domain->domain_id, v->vcpu_id); - domain_crash(v->domain); - return; } old_mfn = pagetable_get_mfn(v->arch.monitor_table); @@ -2590,7 +2588,8 @@ static void sh_update_paging_modes(struc * pull it down! Switch CR3, and warn the HVM code that * its h...

...og this looks most interesting:(XEN) AMD-Vi: Setup I/O page table: device id = 0x0200, root table = 0x284120000, domain = 3, paging mode = 2(XEN) AMD-Vi: Re-assign 02:00.0 from domain 0 to domain 3(XEN) AMD-Vi: Cannot allocate I/O page table(XEN) AMD-Vi: Invalid IO pagetable entry gfn = 13ec00(XEN) domain_crash called from iommu_map.c:585 But I''ve no idea what might cause this and how to fix it... System summary:mainboard: Gigabyte GA-990FXA-UD3 rev. 1.2 (modified bios by gigabyte to get pci passthrough working in the first place)Cpu: AMD FX8350RAM: 16GBGPU''s: 2x AMD HD5870 + nVidia GTS4...

...0800 on 30 Sep (1159621646), Li, Xin B wrote: >> After applying this patch, while booting a 2 vCPUs PAE SMP >Windows 2003 server in VMX, I got: >> >> (XEN) sh error: sh_remove_shadows(): can''t find all shadows >of mfn 23ecf7 (shadow_flags=80000008) >> (XEN) domain_crash called from common.c:2197 >> (XEN) Domain 1 (vcpu#0) crashed on cpu#3: >> (XEN) ----[ Xen-3.0-unstable x86_64 debug=n Not tainted ]---- >> (XEN) CPU: 3 >> (XEN) RIP: 0008:[<000000008086bf9b>] >> (XEN) RFLAGS: 0000000000010283 CONTEXT: hvm >> (XEN...

...!writable_page_tables" .ascii "|!auto_translated_physmap" to .ascii ",FEATURES= writable_page_tables" .ascii "| auto_translated_physmap" Then booting Xen succeeds for Xen-unstable and hangs when booting Linux and reports the following message: (XEN) domain_crash called from mm.c:1783 (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-3.0-unstable Not tainted ]---- (XEN) CPU: 0 (XEN) EIP: e019:[<c02ce06a>] (XEN) EFLAGS: 00010287 CONTEXT: guest (XEN) eax: 002f7000 ebx: 00000000 ecx: c02f7fb8 edx: c02f7fbc (XEN) esi: 00000000 e...

Hi Stefan, The problem is cause by the VBD/VNIF PCI device in DM checked in changeset 11160: PCI Device ID: 5853(Xen),class:ff80 (unknown) ACPI Window does not understand this device and can not find device driver associate with it. To verify this just revert the patches of changset 11161/11160 We are working on the fix now, revert patch is not the solution anyway... Thanks, Winston

...fo=80000301 errcode=00000400 ilen=00000000 (XEN) reason=80000021 qualification=00000000 (XEN) IDTVectoring: info=00000000 errcode=00000000 (XEN) TPR Threshold = 0x00 (XEN) EPT pointer = 0x0000000000000000 (XEN) Virtual processor ID = 0x0000 (XEN) ************************************** (XEN) domain_crash called from vmx.c:2207 (XEN) Domain 14 (vcpu#0) crashed on cpu#0: Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...enter(v); + + vmx_vmcs_save(v, data); + + vmx_vmcs_exit(v); + +} + +void vmx_load_vmcs_ctxt(struct vcpu *v, struct hvmcpu_context *ctxt) +{ + vmx_load_cpu_state(v, ctxt); + + if (vmx_vmcs_restore(v, &ctxt->data)) { + printk("vmx_vmcs restore failed!\n"); + domain_crash(v->domain); + } + + /* only load vmcs once */ + ctxt->valid = 0; + +} + /* * The VMX spec (section 4.3.1.2, Checks on Guest Segment * Registers) says that virtual-8086 mode guests'' segment @@ -750,6 +1043,9 @@ static void vmx_setup_hvm_funcs(void) hvm_funcs.store...

Patrick, there following patches fix xenpaging for me. Granttable handling is incomplete. If a page is gone, a GNTST_eagain should be returned to the caller to inidcate the hypercall has to be retried after a while, until the page is available again. Please review. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hi Keir: These two patches remove the need for netloop by performing the copying in netback and only if it is necessary. The rationale is that most packets will be processed without delay allowing them to be freed without copying at all. So instead of copying every packet destined to dom0 we''ll only copy those that linger longer than a specified amount of time (currently 0.5s). As it

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

A character device for accessing (in user-space) pages that have been granted by other domains. Signed-off-by: Derek Murray <Derek.Murray@cl.cam.ac.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel