At 20:03 +0800 on 11 Oct (1318363429), cc Luit wrote:
> 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?
I don't quite understand your English, but yes, you can let the guest
write to page tables and sync up the shadows afterwards. You need to
sync the shadows whenever real hardware would re-read pagetables. That
is, at least:
- When the guest executes INVLPG
- When the guest writes to CR3
- When the shadowing code adds a new l2e, l3e or l4e that points to an
existing shadow.
(and possibly some other cases I don;t remember right now).
> > 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.
Ah, I see - this is following on from the CloudVisor work, is it?
Why don't you just use EPT/NPT instead of shadow pagetables? That code
is a lot simpler and the end result is easier to validate than shadow
pagetables are. Is it particularly important to support shadow pagetables?
In either case, there are some instructions that Xen will always
emulate - for example:
- MMIO accesses to emulated hardware
- Some real-mode instructions on older Intel hardware
so even if you rewrote the shadow pagetable code not to emulate PT writes
you still have to handle those.
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home