[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > >
-- - Luit @ Parallel Processing Institute, Fudan University
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|