Xen project Mailing List

On Tue, Oct 11, 2011 at 7:29 PM, Tim Deegan <tim@xxxxxxx> wrote:

At 18:14 +0800 on 11 Oct (1318356859), cc Luit wrote:
> On Tue, Oct 11, 2011 at 4:18 PM, Tim Deegan <tim@xxxxxxx> wrote:
>
> > At 09:39 +0800 on 11 Oct (1318325957), cc Luit 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?
> >
> > > In the shadow pagetable code, we keep the shadows up-to-date by:
> > > 1 - making all shadowed pagetables read-only;
> > > 2 - intercepting the page faults when the guest writes to them; and
> > > 3 - updating the guest pagetable and the shadow at the same time,
> > > with whatever change the guest was making.
> >
> > > For step 3 we need to emulate the instruction that caused the pagefault
> > > so that we can tell what was being written.
> >
> > > There are other reasons for the emulator to be called (emulating MMIO
> > > instructions, emulating real-mode &c) but that's why the shadow
> > > pagetable code uses it.
> >
> > Thanks first of all, I know now it is the Eager mode that SPT is sync up
> with GPT when guest want to change the page table using the instructions
> emulator, but if for some reason I don't want xen to emulate such an
> instruction, but just VMEntry to HVM to retry, is there any feasibility
> problems?

> The emulation can be avoided - in fact the current shadow pagetable
> sometimes lets guests write to shadowed pages and fixes up the shadows
> afterwards (this is called out-of-sync or oos in the code).

> But if you just return to the guest and retry, the guest will take the
> same fault again unless you have done something to change that. If you
> _have_ done something to make it OK, then just returning
> EXCRET_fault_fixed from sh_page_fault will return to the guest and
> retry the instruction.

I've read a slide said that in Lazy mode:

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,

I'm not sure if this can work?

> Why do you want to avoid calling the emulator? What is your overall goal?
> It might be that tinkering in the shadow pagetables isn't the best way
> to acheive it.

because we're doing some research of security aspect about xen, what's our goal is avoid xen to access the HVM's memory in the page fault situation, it's hard to say it out in short words, we have thought a lot of ways but there is no a simpler one than avoiding the emulation in page_fault.

Thanks

> in other words, in the old time, the shadow page is the Lazy mode,
> that xen will not emulate, and the GPT and SPT is out of sync for some time,
> besides the lose in performance, is there other problems?

No, it was really about the performance cost of syncing up all the
shadows on a TLB flush. In retrospect, having fixed some nasty bugs in
the OOS code, I suspect the old shadow code was also incorrect in some
ways but that was an implementation detail, noit architectural.

Tim.

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