[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] mmu_update doesn't work well in writable page table mode??


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Hwandori <hwandori@xxxxxxxxx>
  • Date: Wed, 28 Feb 2007 20:39:51 +0900
  • Delivery-date: Wed, 28 Feb 2007 03:39:19 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Ubr3ha99oK//ZUn5YsB/VxqLo9daSXN7+7gUlK78fJc3iUqskDt3R5sJ11vzD4mTQNDqkk/avUiTv6dumm3+Zyq5ILsuwFFsYtTgL4U4ShatDdUnJfkYzYcU4w93FGoLoR1M9cCQxptmSBI3DYPZbZPBnNVd9hRfJLZmu/CsSjE=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Current Xen takes the writable page table mode as a default, and I tried to modify the page table mapping(V-M) using the mmu_update hypercall(or update_va_mapping).

As a result of searching the related maling list archives, I get know about conflicts of combining the writable page table and mmu_update hypercall.

What I have done are updating guest's page table mapping(V-M) , physical to machine table, and machine to physical table(also using mmu_update).

Problem occurs during the mount of root filesystem, in detail , it occurs while pinning the page directory(L2 table) with calling xen_pgd_pin function.

I found the things related about l2 or l1 table pinning , writable page table , and updating mapping via hypercall, but I don't know the solutions of this problem..

To help to understand, I posted the error message at guest kernel below.
-------------------------------------------------------------------------------------------------------------------------------------------------------
kernel BUG at arch/i386/mm/hypervisor.c:186!
invalid opcode: 0000 [#1]
Modules linked in: ide_generic processor xenblk
CPU:    0
EIP:    0061:[<c0114365>]    Not tainted VLI
EFLAGS: 00010282   (2.6.16.33-xen #31)
EIP is at xen_pgd_pin+0x55/0x60
eax: ffffffea   ebx: c0059ef8   ecx: 00000001   edx: 00000000
esi: 00007ff0   edi: 00000000   ebp: 01200011   esp: c0059ef8
ds: 007b   es: 007b   ss: 0069
Process init (pid: 1, threadinfo=c0058000 task=c11fda90)
Stack: <0>00000001 0002384b 00000000 00019460 00000000 c0111174 c738bb74 c0117fb0
       c738ba84 c037b4ec c037fe40 c722e030 c037fe74 c037f934 c722e0e4 c0059fbc
       bf9903a8 00000000 c722e030 c037f900 c738bb80 c738bb94 c738bb8c 00000000
Call Trace:
 [<c0111174>] __pgd_pin+0x24/0x30
 [<c0117fb0>] copy_process+0x1080/0x1120
 [<c011830e>] do_fork+0x6e/0x1e0
 [<c01158f0>] default_wake_function+0x0/0x10
 [<c0103362>] sys_clone+0x32/0x40
 [<c01051a1>] syscall_call+0x7/0xb
-----------------------------------------------------------------------------------------------------------------------------------------------------

And the following log is from 'xm dmesg'
-----------------------------------------------------------------------------------------------------------------------------------------------------
(XEN) mm.c:1664:d1 Bad type (saw e8000001 != exp 20000000) for mfn 2c300 (pfn fb4)
(XEN) mm.c:505:d1 Attempt to create linear p.t. with write perms
(XEN) mm.c:976:d1 Failure in alloc_l2_table: entry 766
(XEN) mm.c:1685:d1 Error while validating mfn 2384b (pfn ca3) for type 40000000: caf=80000003 taf=40000001
(XEN) mm.c:1962:d1 Error while pinning mfn 2384
-----------------------------------------------------------------------------------------------------------------------------------------------------

At the first line, mfn 2c300 is the mfn that I updated, so I don't know why this mfn is regarded as l1 page table, in spite of the fact that this mfn is of writable page(not page table).

I'd like to know the problems when updating the memory mappings via hypercall(mmu_update) at the writable page table mode, and the solutions about it.

thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.