All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Ropert <mro@adviseo.fr>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>, xen-devel@lists.xensource.com
Subject: Re: [RESEND] Question about recursive mappings
Date: Tue, 23 May 2006 14:22:15 +0200	[thread overview]
Message-ID: <4472FE77.1050401@adviseo.fr> (raw)
In-Reply-To: <9e623acb8c30c70453a9b82b8b9a63b7@cl.cam.ac.uk>

Keir Fraser wrote:

>
> On 23 May 2006, at 10:41, Ian Pratt wrote:
>
>> Can you explain the pagtable structure a little better please. Does the
>> L3 contain an entry point at itself (recursive), or at another L3
>> (foreign)?
>>
>> I've never come across non-root pagetable linear mappings other than in
>> the crock that is PAE (3 level) where you have to use 4 entries in an L2
>> to point to all the L2s due to the limited address space.
>
>
> And that's something we don't currently support. A slightly more 
> generic linear pagetable logic that would permit us to support linear 
> pagetables on PAE would be a good thing.
>
>  -- Keir
>

A bit more explanation:
- All my L4 tables (kernel and user) have one of their entries pointing 
on themselves.
- As I can't use the same tables in kernel and user mode on x86_64, the 
kernel table is always the same, and sometimes needs to map a user L4 to 
modify.
- In order to do that, i set an entry of the kernel L4 to the machine 
address of the wanted L4 user table. So my L4 user recursive entry is 
used as a L3 one in kernel tables.
- When i want to access a user table in kernel mode, i do 2 mmu updates:
1/ Set a L4 kernel table entry with the machine address of the L4 user 
table i want to change. This step currently works.
2/ Set the L4 user table recursive as valid (i clear the valid bit when 
i'm done with my changes, don't want the user to be able to read his 
page tables). This is where Xen refuse to update the tables.

About the possible fix, won't something like trying a 
get_linear_pagetable() at all level works? Will it cause too much overhead?
Generally speaking, is allowing a R/O mapping of another table the 
domain own (whichever level it is) safe? At first thought, i don't see 
any way of exploiting it.

Regards,
Mathieu

  reply	other threads:[~2006-05-23 12:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-23  9:41 [RESEND] Question about recursive mappings Ian Pratt
2006-05-23  9:52 ` Keir Fraser
2006-05-23 12:22   ` Mathieu Ropert [this message]
2006-07-27 22:14   ` Bruce Rogers
  -- strict thread matches above, loose matches on Subject: below --
2006-05-24  9:34 Ian Pratt
2006-05-24 20:12 ` Mathieu Ropert
2006-05-24 20:16   ` Keir Fraser
2006-05-26  9:27     ` Mathieu Ropert
2006-05-29 11:43     ` Mathieu Ropert
2006-05-22  9:15 Mathieu Ropert
2006-05-22 15:18 ` Mathieu Ropert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4472FE77.1050401@adviseo.fr \
    --to=mro@adviseo.fr \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.