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.
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.
> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home