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
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
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
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 theGuest> 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
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
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