All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emre Can Sezer <ecsezer@ncsu.edu>
To: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: Two shadow page tables for HVM
Date: Mon, 26 Jan 2009 19:39:08 -0500	[thread overview]
Message-ID: <497E57AC.1090508@ncsu.edu> (raw)
In-Reply-To: <20090112094609.GN12729@york.uk.xensource.com>

Tim Deegan wrote:
> At 17:08 -0500 on 09 Jan (1231520939), Emre Can Sezer wrote:
>   
>> I finally got around to implementing two paging modes.  Everything works 
>> fine until I swap modes :)
>>
>> I get a shadow page fault with error_code 0.  This happens right after I 
>> swap the paging mode.  Any clues as to what might be the cause?
>>
>> I walked through the code that updates paging modes.  It appears that we 
>> simply make an *empty* top level shadow and install it as top level shadow 
>> page table.  If this is the case, shouldn't the first fault have a non-zero 
>> error code?
>>     
>
> The TLB will be empty when you return so the first fault will be an
> instruction fetch, presumably from kernel space (since that's when you
> want to switch modes).  If the guest has PAE or 64-bit pagetabels and
> EFER.NXE turned on, it should have error code 0x10; otherwise 0 is correct.
>   


Unfortunately I'm still stuck with the same problem.  When in normal
mode, I observe the instruction fetch error when execution is jumping to
a module.  The va and rip are the same.  I switch to "alternate" paging
mode.  Since the TLB is empty, I expect the guest to try to fetch the
instruction again.  At this point the root shadow page table is empty
(first time we ever switched to this mode), so I only expect to get a
page not present error, since the NX bit is not set.  Well, I don't see
either.  It faults with error code 0 and a va that is different from the
rip (rip is the same as before).  I'm using 64-bit PT's and as far as I
can tell EFER.NXE is turned on.  At least cpu_has_nx returns true and
that I get page faults with PFEC_instr_fetch error with both paging modes.

Here is the summary of page fault errors:
...
(XEN) sh_page_fault: d:v=1:0 va=0xffffffffa000f050 err=17,
rip=ffffffffa000f050
(XEN) <ECS> Switching to ALTERNATE paging mode
(XEN) <ECS-alt> sh_page_fault: d:v=1:0 va=0xffffffff8062cef0 err=0,
rip=ffffffffa000f050
(XEN) <ECS-alt> sh_page_fault: d:v=1:0 va=0xffffffff805d8010 err=0,
rip=ffffffffa000f050
(XEN) <ECS-alt> sh_page_fault: d:v=1:0 va=0xffffffff8020cea0 err=10,
rip=ffffffff8020cea0
(XEN) <ECS> Switching to NORMAL paging mode
(XEN) <ECS> Done
...

I'm also confused about the last page fault.  No page fault occurred
that propagated this page's pte from the guest (I turned off
prefetching). I'm inclined to think that I have some artifacts from the
initial paging mode.

The only thing I haven't fully ported to the alternate paging mode is
the super page handling.  But I'm not sure if that has anything to do
with the error code.

Any thoughts? Am I correct in thinking that when I first switch the
paging mode, the top level page table is empty and that we should at
least get a page not present error for ANY instruction?

Thanks,

John

>   

  reply	other threads:[~2009-01-27  0:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 23:06 Two shadow page tables for HVM Emre Can Sezer
2008-12-18  3:50 ` Sina Bahram
2008-12-18 11:32 ` Tim Deegan
2008-12-22 18:28   ` Emre Can Sezer
2008-12-23 12:03     ` Gianluca Guida
     [not found]   ` <494FC8C7.8030508@ncsu.edu>
     [not found]     ` <20081223161006.GB28336@york.uk.xensource.com>
2008-12-29 16:17       ` Emre Can Sezer
     [not found]       ` <4958F7E0.8050207@ncsu.edu>
     [not found]         ` <20081229165415.GB5734@york.uk.xensource.com>
2009-01-09 22:08           ` Emre Can Sezer
2009-01-12  9:46             ` Tim Deegan
2009-01-27  0:39               ` Emre Can Sezer [this message]
2009-01-27 10:34                 ` Tim Deegan
2009-01-27 19:07                   ` Emre Can Sezer
2009-01-28  9:25                     ` Tim Deegan
2009-01-30 16:15                   ` Emre Can Sezer

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=497E57AC.1090508@ncsu.edu \
    --to=ecsezer@ncsu.edu \
    --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.