thr3ads.net - Xen devel - Re: [Xen-devel] why xen use x86_emulat ion() in page

If this information is useful, please help other people find it:
Share via:

George Dunlap

2011-Oct-11 09:27 UTC

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

The comments in xen/arch/mm/shadow/multi.c:sh_page_fault() about emulation say:
    /* Need to emulate accesses to page tables */
and
    /* In HVM guests, we force CR0.WP always to be set, so that the
     * pagetables are always write-protected.  If the guest thinks
     * CR0.WP is clear, we must emulate faulting supervisor writes to
     * allow the guest to write through read-only PTEs.  Emulate if the
     * fault was a non-user write to a present page.  */

Do you have some question about these?

Regarding NPT/EPT, as far as I know, the only reason to do emulation
is when the guest is doing MMIO.  The whole point of MMIO is to
emulate access to devices.

 -George

On Tue, Oct 11, 2011 at 2:58 AM, cc Luit <universalbillow@gmail.com>
wrote:> Hi, everyone, I have a question,
> in the shadow_page_fault or ept mechanism, xen will use the x86_emulation
> for some instructions, I''m wondering why it must use it, if after
we fix the
> SPT or EPT table, just VMEntry to HVM to re-excute this instruction  but
not
> emulate in xen, is there some problems?
>
> can sb. tell me why?
> thanks:)
> --
> - Luit @ Parallel Processing Institute, Fudan University
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

cc Luit

2011-Oct-11 10:12 UTC

head link

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

Sorry about that:-)
Yeah, I''ve seen this comments, I understand what it says in the before
part,
but not the last sentence, what does it mean by "non-user write"? and
what''s
more, in the code following is:
    if ( is_hvm_domain(d)
         && unlikely(!hvm_wp_enabled(v))
         && regs->error_code == (PFEC_write_access|PFEC_page_present)
         && mfn_valid(gmfn) )
    {
        perfc_incr(shadow_fault_emulate_wp);
        goto emulate;
    }

there is not opinion show that the guest is to write through read-only PTEs,
but just a hvm_wp_enabled but mfn_valid address, does it because only the
PTE is hvm_wp_enabled?

another question is that if for some reasons I want to design that the Guest
PTE is not read-only, which means in the page_fault situation I don''t
want
xen to emulate, is there any functionability or feasibility problems?

thanks for your answer:)

On Tue, Oct 11, 2011 at 5:27 PM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:
> The comments in xen/arch/mm/shadow/multi.c:sh_page_fault() about emulation
> say:
>    /* Need to emulate accesses to page tables */
> and
>    /* In HVM guests, we force CR0.WP always to be set, so that the
>     * pagetables are always write-protected.  If the guest thinks
>     * CR0.WP is clear, we must emulate faulting supervisor writes to
>     * allow the guest to write through read-only PTEs.  Emulate if the
>     * fault was a non-user write to a present page.  */
>
> Do you have some question about these?
>
> Regarding NPT/EPT, as far as I know, the only reason to do emulation
> is when the guest is doing MMIO.  The whole point of MMIO is to
> emulate access to devices.
>
>  -George
>
> On Tue, Oct 11, 2011 at 2:58 AM, cc Luit <universalbillow@gmail.com>
> wrote:
> > Hi, everyone, I have a question,
> > in the shadow_page_fault or ept mechanism, xen will use the
x86_emulation
> > for some instructions, I''m wondering why it must use it, if
after we fix
> the
> > SPT or EPT table, just VMEntry to HVM to re-excute this instruction 
but
> not
> > emulate in xen, is there some problems?
> >
> > can sb. tell me why?
> > thanks:)
> > --
> > - Luit @ Parallel Processing Institute, Fudan University
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> >
>


-- 
- Luit @ Parallel Processing Institute, Fudan University


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

George Dunlap

2011-Oct-11 11:39 UTC

head link

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

On Tue, Oct 11, 2011 at 11:12 AM, cc Luit <universalbillow@gmail.com>
wrote:> Yeah, I''ve seen this comments, I understand what it says in the
before part,
> but not the last sentence, what does it mean by "non-user write"?
As you know, pagetables have a write-protect bit, such that writes to
that virtual address will cause a fault.

But there''s an option in CR0 that can make the WP bit only work in
user mode, and not kernel mode.

So if the guest has CR0.WP clear, and the guest PTE is read-only, the
guest needs to see this:
1. In user mode, writes cause a page fault
2. In kernel mode, writes do not cause a page fault

But Xen needs to protect pagetables to detect changes to them.  So
what Xen needs is this:
1. In user mode, writes cause a page fault to be delivered to the guest
2. In kernel mode, writes to non-PTs do not cause a page fault to be
delivered to the guest
3. In kernel mode, writes to PTs cause a trap to xen, but do not cause
a page fault to be delivered to the guest

Unfortunately, there''s no way to cause traps to xen in the case of #3
without also causing traps to Xen in case #2.  So the if statement is
designed to handle case #2.
> another question is that if for some reasons I want to design that the
Guest
> PTE is not read-only, which means in the page_fault situation I
don''t want
> xen to emulate, is there any functionability or feasibility problems?
The basic problem is that in shadow mode, changes to the guest''s
pagetables need to be propagated into the shadow pagetables.  If you
can figure out how to make that happen without trapping to Xen and
emulating, all the better. :-)
> thanks for your answer:)
bu ke qi! ;-)

 -George

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

cc Luit

2011-Oct-11 12:57 UTC

head link

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

On Tue, Oct 11, 2011 at 7:39 PM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:
> On Tue, Oct 11, 2011 at 11:12 AM, cc Luit <universalbillow@gmail.com>
> wrote:
> > Yeah, I''ve seen this comments, I understand what it says in
the before
> part,
> > but not the last sentence, what does it mean by "non-user
write"?
>
> > As you know, pagetables have a write-protect bit, such that writes to
> > that virtual address will cause a fault.
>
> > But there''s an option in CR0 that can make the WP bit only
work in
> > user mode, and not kernel mode.
>
> > So if the guest has CR0.WP clear, and the guest PTE is read-only, the
> > guest needs to see this:
> 1. In user mode, writes cause a page fault
> > 2. In kernel mode, writes do not cause a page fault
> > But Xen needs to protect pagetables to detect changes to them.  So
> > what Xen needs is this:
> > 1. In user mode, writes cause a page fault to be delivered to the
guest
> > 2. In kernel mode, writes to non-PTs do not cause a page fault to be
> > delivered to the guest
> > 3. In kernel mode, writes to PTs cause a trap to xen, but do not cause
> > a page fault to be delivered to the guest
>
> > Unfortunately, there''s no way to cause traps to xen in the
case of #3
> > without also causing traps to Xen in case #2.  So the if statement is
> > designed to handle case #2.
>
> another question is that if for some reasons I want to design that the
Guest> PTE is not read-only, which means in the page_fault situation I
don''t want
> xen to emulate, is there any functionability or feasibility problems?
> The basic problem is that in shadow mode, changes to the guest''s
> > pagetables need to be propagated into the shadow pagetables.  If you
> > can figure out how to make that happen without trapping to Xen and
> > emulating, all the better. :-)
>appreciate your explanation so much, that''s really detail and helpfull!
but I think for the propagate from GPT to SPT, it''s not always need the
sync
all the time, I know in the early version of xen there is not need to do
that, but just the Lazy mode, which means (just what I understand, but not
sure):
 when guest os modify the GPT, do not emulate (there is no write-protected
PTE, so guest can directly modify it)
 1) when the access right ascension, the guest OS will INVLPG to shootdown
TLB, so hypervisor can catch the INPLPG inst to sync  up the SPT/GPT
 2) when access right down, when guest OS access this page it will trap to
xen, xen will catch #PF to sync up SPT/GPT,

have you ever heard of that before, I''m not sure if it is right,
what''s your
opinion?


>
> > thanks for your answer:)
>
> > bu ke qi! ;-)
>feel kind and amazed to see the Chinese Pinyin, really feel kind of you:-)
>
>  -George
>


-- 
- Luit @ Parallel Processing Institute, Fudan University


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

George Dunlap

2011-Oct-11 13:20 UTC

head link

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

On Tue, Oct 11, 2011 at 1:57 PM, cc Luit <universalbillow@gmail.com>
wrote:> appreciate your explanation so much, that''s really detail and
helpfull!
> but I think for the propagate from GPT to SPT, it''s not always
need the sync
> all the time, I know in the early version of xen there is not need to do
> that, but just the Lazy mode, which means (just what I understand, but not
> sure):
>  when guest os modify the GPT, do not emulate (there is no write-protected
> PTE, so guest can directly modify it)
>  1) when the access right ascension, the guest OS will INVLPG to shootdown
> TLB, so hypervisor can catch the INPLPG inst to sync  up the SPT/GPT
>  2) when access right down, when guest OS access this page it will trap to
> xen, xen will catch #PF to sync up SPT/GPT,
We already do something like this for L1 pages; search for
"SHOPT_OUT_OF_SYNC".

But when you start to do this for higher-level pages (L2 and above),
then you get into a lot of very tricky corner-cases.  Because changes
to higher-level PTs are less common, we went with the simpler route of
simply emulating all accesses to them.

It could be done -- IIRC, version 1 of the shadow code did this
(because there was very limited hypervisor emulation).  But to get it
correct *and* working quickly will be kind of difficult.
>> > bu ke qi! ;-)
>
> feel kind and amazed to see the Chinese Pinyin, really feel kind of you:-)
我学了中文学了两年。我常常要用那个! :-)

 -George

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

cc Luit

2011-Oct-11 13:38 UTC

head link

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

On Tue, Oct 11, 2011 at 9:20 PM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:
> On Tue, Oct 11, 2011 at 1:57 PM, cc Luit <universalbillow@gmail.com>
> wrote:
> > appreciate your explanation so much, that''s really detail and
helpfull!
> > but I think for the propagate from GPT to SPT, it''s not
always need the
> sync
> > all the time, I know in the early version of xen there is not need to
do
> > that, but just the Lazy mode, which means (just what I understand, but
> not
> > sure):
> >  when guest os modify the GPT, do not emulate (there is no
> write-protected
> > PTE, so guest can directly modify it)
> >  1) when the access right ascension, the guest OS will INVLPG to
> shootdown
> > TLB, so hypervisor can catch the INPLPG inst to sync  up the SPT/GPT
> >  2) when access right down, when guest OS access this page it will
trap
> to
> > xen, xen will catch #PF to sync up SPT/GPT,
>
> > We already do something like this for L1 pages; search for
> "SHOPT_OUT_OF_SYNC".
>
> > But when you start to do this for higher-level pages (L2 and above),
> > then you get into a lot of very tricky corner-cases.  Because changes
> > to higher-level PTs are less common, we went with the simpler route of
> > simply emulating all accesses to them.
>
> > It could be done -- IIRC, version 1 of the shadow code did this
> > (because there was very limited hypervisor emulation).  But to get it
> > correct *and* working quickly will be kind of difficult.
>
Yeah, I see~
>
> >> > bu ke qi! ;-)
> >
> > feel kind and amazed to see the Chinese Pinyin, really feel kind of
> you:-)
>
> 我学了中文学了两年。我常常要用那个! :-)
>haha~你竟然会用到中文，第一次在Xen-devel上看到中文好兴奋啊。。。
>
>  -George
>


-- 
- Luit @ Parallel Processing Institute, Fudan University


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

Xen devel - Oct 2011 - Re: why xen use x86_emulat ion() in page_fault

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault

Re: [Xen-devel] why xen use x86_emulat ion() in page_fault