Xen devel - May 2006 - XENFEAT_writable_pagetables vs VMASST_TYPE_writable_pagetables

hi,

(this is on xen-3.0.testing.hg),

I am trying to figure out what the difference is between calling
vm-assist to enable writable page tables, and what the xen-feature
with the same name does. The former is enabled, while the latter
returns false. This has the effect that the various checks from
changeset 9243:f00e257d200c fail and pages are still pinned/unpinned,
but things still seem to work. This is with my own domain builder
using libxc.

So what is the story when combining VMASST_ and XENFEAT_?

Jacob

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

On 31 May 2006, at 15:22, Jacob Gorm Hansen wrote:
> I am trying to figure out what the difference is between calling
> vm-assist to enable writable page tables, and what the xen-feature
> with the same name does. The former is enabled, while the latter
> returns false. This has the effect that the various checks from
> changeset 9243:f00e257d200c fail and pages are still pinned/unpinned,
> but things still seem to work. This is with my own domain builder
> using libxc.
>
> So what is the story when combining VMASST_ and XENFEAT_?
It''s a case of really bad naming: XENFEAT_writable_pagetables means 
that none of the pagetables need to be write-protected or pinned 
(presumably because you are permanently on shadow page tables). Whereas 
the vmassist simply means that you can attempt to directly write to 
your bottom-level PTEs, but page tables must generally be pinned and 
write-protected.

  -- Keir


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

On 5/31/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
> It''s a case of really bad naming: XENFEAT_writable_pagetables
means
> that none of the pagetables need to be write-protected or pinned
> (presumably because you are permanently on shadow page tables). Whereas
> the vmassist simply means that you can attempt to directly write to
> your bottom-level PTEs, but page tables must generally be pinned and
> write-protected.
Thanks for clearing this up. The problem I have is that I am trying to
prevent writable mappings inside the linux guest, by (among other
measures) moving _PAGE_RW to _PAGE_AVAIL2 in
HYPERVISOR_update_va_mapping() before performing the hypercall to Xen.

This works everywhere, except the call at the bottom of pgd_walk()
when called from __pgd_unpin(). If the pgd is not writable after
unpin, weird stuff starts to happen --- the next call to pmd_clear()
from free_pte_range() fails in Xen, citing incorrect page types.

Can you tell me why linux/xen/the wrpt implementation cannot handle
the unpinned pgd being mapped read-only like this?

Thanks,
Jacob

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

On 31 May 2006, at 16:09, Jacob Gorm Hansen wrote:
> This works everywhere, except the call at the bottom of pgd_walk()
> when called from __pgd_unpin(). If the pgd is not writable after
> unpin, weird stuff starts to happen --- the next call to pmd_clear()
> from free_pte_range() fails in Xen, citing incorrect page types.
>
> Can you tell me why linux/xen/the wrpt implementation cannot handle
> the unpinned pgd being mapped read-only like this?
I''ll need to see a backtrace, or at least the particular error message 
from Xen.

  -- Keir


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

On 5/31/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
> I''ll need to see a backtrace, or at least the particular error
message
> from Xen.
It is here:

(XEN) DOM66: (file=mm.c, line=1522) Bad type (saw f0000001 != exp
20200000) for mfn e41 (pfn 75a)
(XEN) DOM66: (file=mm.c, line=428) Attempt to create linear p.t. with
write perms
(XEN) DOM66: (file=mm.c, line=868) Failure in alloc_l2_table: entry 32
(XEN) DOM66: (file=mm.c, line=1567) Error while validating mfn e40
(pfn 75b) for type 40000000: caf=80000003 taf=40000001
<0>------------[ cut here ]------------
<0>kernel BUG at arch/i386/mm/hypervisor.c:74!
<0>invalid opcode: 0000 [#1]
Modules linked in:
<0>CPU:    0
EIP:    0061:[<c010dcc5>]    Not tainted VLI
EFLAGS: 00010282   (2.6.16-xen #438)
<0>EIP is at xen_l2_entry_update+0x6a/0x8e
<0>eax: ffffffea   ebx: c0c5beb0   ecx: 00000001   edx: 00000000
<0>esi: 00007ff0   edi: 0000075b   ebp: 08151000   esp: c0c5beb0
<0>ds: 007b   es: 007b   ss: 0069
<0>Process find (pid: 19, threadinfo=c0c5a000 task=c0c58a30)
<0>Stack: <0>00e40080 00000000 00000000 00000000 0000eb40 08000000
bfc00000 c013184b
<0>       c075b080 00000000 c075b080 08151000 c0003000 c021fa98
08150fff c0c4a124
<0>       c0c4a124 c0c4a124 08048000 c013195a c0c5bf58 08048000
08151000 00000000
<0>Call Trace:
<0> [<c013184b>] free_pgd_range+0xed/0x19c
<0> [<c013195a>] free_pgtables+0x60/0x6c
<0> [<c0134c39>] exit_mmap+0x6c/0xb8
<0> [<c0110285>] mmput+0x1c/0x51
<0> [<c0112da8>] exit_mm+0xe7/0xec
<0> [<c0113810>] do_exit+0x173/0x642
<0> [<c0113d54>] sys_exit_group+0x0/0x11
<0> [<c0104345>] syscall_call+0x7/0xb
<0>Code: be f0 7f 00 00 89 04 24 8b 44 24 24 31 d2 c7 44 24 04 00 00
00 00 c7 44 24 0c 00 00 00 00 89 44 24 08 e8 5f 33 ff ff 85 c0 79 08
<0f> 0b 4a 00 df 85 1c c0 a1 f0 19 23 c0 85 c0 74 0c 83 38 00 74

Thanks,
Jacob

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

On 31 May 2006, at 16:24, Jacob Gorm Hansen wrote:
> (XEN) DOM66: (file=mm.c, line=1522) Bad type (saw f0000001 != exp
> 20200000) for mfn e41 (pfn 75a)
> (XEN) DOM66: (file=mm.c, line=428) Attempt to create linear p.t. with
> write perms
> (XEN) DOM66: (file=mm.c, line=868) Failure in alloc_l2_table: entry 32
> (XEN) DOM66: (file=mm.c, line=1567) Error while validating mfn e40
> (pfn 75b) for type 40000000: caf=80000003 taf=40000001
This doesn''t look like the result of a pmd_clear() call. Looks like a 
L2 (pgd) is being allocated -- perhaps due to pinning or changing %cr3. 
It''s failing because one of the L1 pages it references is writable by 
the guest (ie. the guest has a writable mapping of that L1 page 
somewhere).

  -- Keir



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

On 5/31/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
> This doesn''t look like the result of a pmd_clear() call. Looks
like a
> L2 (pgd) is being allocated -- perhaps due to pinning or changing %cr3.
> It''s failing because one of the L1 pages it references is writable
by
> the guest (ie. the guest has a writable mapping of that L1 page
> somewhere).
Hmm it _does_ happen on pmd_clear (which is a macro that turns into a
xen mmu update call). The funny thing is how giving val=0 can end up
as an alloc_l2_page.

Jacob

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

On 1 Jun 2006, at 08:42, Jacob Gorm Hansen wrote:
>> This doesn''t look like the result of a pmd_clear() call. Looks
like a
>> L2 (pgd) is being allocated -- perhaps due to pinning or changing 
>> %cr3.
>> It''s failing because one of the L1 pages it references is
writable by
>> the guest (ie. the guest has a writable mapping of that L1 page
>> somewhere).
>
> Hmm it _does_ happen on pmd_clear (which is a macro that turns into a
> xen mmu update call). The funny thing is how giving val=0 can end up
> as an alloc_l2_page.
Ah, ok I see the path. I need to fix up the logic in the mmu_update 
hypercall a little.

  -- Keir


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