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

Re: [Xen-devel] HVM page table management

> Hi,
> At 17:38 -0400 on 20 Oct (1224524336), Emre Can Sezer wrote:
>> For each LKM (guest kernel), I have a list of pages that belong to the
>> LKM.  I pass this information to Xen with the pfn's of the pages.  So in
>> Xen context these should be gfn's I guess. Is there an easy way to find
>> the pte in the shadow page table associated with this guest page and
>> modify it?
> In general, no.  The shadow code uses some heuristics to guess at the
> locations of PTEs for similar reasons but:
>  - they are mostly based on the virtual address of a page fault; and
>  - even if they work they only find _one_ such PTE.
> You would probably need to add some further mechanism for tracking these
> frames, because the fallback (brute-force search of all shadow L1
> tables) is expensive.
> In addition, unless you modify the typecounting mechanism or add some
> other reference count, you can't tell how many executable mappings there
> are (except that the total number of all mappings is an upper bound).

Ok, I see the problem.  There can be many virtual addresses mapped to a
page and we don't have an easy way of finding all these mappings.  The
pages I'm dealing with are module code+data and some dynamically allocated
memory regions (pages + caches).  I'll take a look at their ref count,
which I think must be 2, one for the module and the other because the
memory is also directly mapped from ffff810000000000.  Hopefully, the
modules aren't doing anything crazy in terms of sharing pages.

> Isn't this something that could be done more easily inside the guest
> kernel, where you have more information available?

I keep thinking that also but there are other things that I have to do in
Xen so having everything on one side seemed like a better approach.  I'm
also trying to minimize the necessary changes to the guest side.

>> Is there an easy way to tell whether a virtual address is in guest
>> kernel
>> or user space?  It seems like guest_kernel_mode(v,r) in
>> include/asm-x86/x86_64/regs.h is meant for PV guests and not for HVM.
> guest_kernel_mode() doesn't even take an address. :)

DUH! Quite embarrassing :) I blame the late hour of 5pm.

> The easiest way in
> the shadow code is probably to call guest_walk_tables() with a pfec
> argument of PFEC_page_present|PFEC_user_mode.
>> Is it possible to change permissions at lvl 2 page tables while keeping
>> the lvl 1's intact?
>> Do the permissions propagate from lvl 2 to lvl 1?
>> Finally, what's the lowest level I can set permissions on?  Does the
>> hardware check for permissions at lvl 4 or lvl 3?
> Yes; yes; only in 64 bit mode.  You should probably read the relevant
> bits of the Intel PRMs (vol 3A, chapters 3 and 4) or the AMD APMs (vol
> 2, chaper 5) before delving too deep into shadow pagetables.



> Cheers,
> Tim.
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, Citrix Systems (R&D) Ltd.
> [Company #02300071, SL9 0DZ, UK.]

Xen-devel mailing list



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