At 19:37 -0400 on 23 Apr (1366745856), Cutter 409 wrote:> Thanks, that clears up a few things.
>
> I''m not sure I understand why I''d have to handle
emulation. My assumption
> was that the process is like this:
>
> page_fault()
> {
> ...
>
> if the guest pagetables aren''t the cause, then
> if regs->error_code indicates a violation of p2m access settings
> send the mem_event and return, letting the guest try again.
Sure, but in a few cases we emulate instuctions (e.g. the guest writing
to a shadowed pagtetable) and that emulation ought to obey the p2m
access permissions too -- all the more because a guest might modify its
own code so that the instruction that gets emulated != the instruction
that caused the fault.
> ...
> }
>
> The Dom0 listener sets the p2m permissions back to rwx, and when the guest
> retries the instruction, everything is okay (or the existing fault handler
> code would run and do it''s thing).
>
> Also, why do we have both hvmmem_access_t and p2m_access_t? It looks like
> the domctl sets the former, but the mem_access EPT API uses the latter.
One is part of the public ABI, the other is internal and subject to change.
Cheers,
Tim.
> Thanks again!
>
> On Tue, Apr 23, 2013 at 4:49 AM, Tim Deegan <tim@xen.org> wrote:
>
> > Hi,
> >
> > At 17:56 -0400 on 22 Apr (1366653364), Cutter 409 wrote:
> > > I''m finally to a point where I can start looking at this
more closely.
> > I''m
> > > trying to wrap my head around the shadow code to figure out the
right
> > > course of action.
> > >
> > > I''d want HVMOP_set_mem_access to work with both shadow
and EPT, so I''d
> > want
> > > things to work via p2m somehow. I think I understand this part.
> > >
> > > * HVMOP_set_mem_access is used to change the p2m_access_t for the
target
> > > page(s). This should already be implemented I think?
> >
> > Yep. The shadow code uses the same p2m implementataion as NPT, so
that
> > should all be fine.
> >
> > > * During propagation, I''ll check the p2m map to see if I
should mask off
> > > any permission bits.
> >
> > Yep. You''ll already be doing a p2m lookup to get the MFN, so
you just
> > need to look at the p2ma as well.
> >
> > > * On a shadow paging fault, I''ll check if the fault was
caused by p2m
> > > permissions, somehow integrating that with the code for read-only
guest
> > > page tables safely.
> >
> > Yes. The common case will be handled in _sh_propagate, which is where
> > the shadow PTE is constructed. For the rest you''ll need to
look at the
> > places where the shadow fault handler calls the emulator and DTRT
> > (either before the call or in the callbacks that the emulator uses to
> > access guest memory).
> >
> > > Questions:
> > >
> > > * Just for background, am I correct in my understanding that the
> > log_dirty
> > > code is used to track which gfns have been written to by the
guest, in
> > > order to speed up migration?
> >
> > That''s right. It''s also used to track which parts
of an emulated
> > framebuffer have been updated, to make VNC connections more efficient.
> >
> > > * Are multiple shadow tables maintained per domain? Is there one
per
> > VCPU?
> > > One shadow table per guest page table? Is it blown away every
time the
> > > guest changes CR3? I''m having some trouble tracking this
down.
> >
> > There''s one set of shadows per domain, shared among all
VCPUs. A given
> > page of memory may have multiple shadows though, e.g. if it''s
seen both
> > as a top-level pagetables and a leaf pagetable.
> >
> > Shadows are kept around until:
> > - it looks like the page is no longer a pagetable;
> > - the guest explicitly tells us it''s no longer a pagetable;
or
> > - we need the memory to shadow some other page.
> >
> > Mostly, a pages''s shadow(s) are kept in sync with any changes
the guest
> > makes to the page, by trapping and emulating all writes. For
> > performance, we allow some l1 pagetables to be ''out of
sync'' (''oos'' in
> > the code), letting the guest write to the page directly. On guest CR3
> > writes (and other TLB-flush-related activity) we make sure any OOS
> > shadows are brought up to date.
> >
> > > * How should I clear/update existing shadow entries after
changing the
> > > p2m_access_t? Can I clear the shadow tables somehow and force
everything
> > to
> > > be repopulated? Is that insane?
> >
> > It depends how often you''re changing the access permissions.
> > sh_remove_all_mappings() and sh_remove_write_access() will try to
flush
> > mappings of a single MFN from the shadows, but they can be expensive
> > (e.g. involving a brute-force scan of all shadows) so if
you''re going to
> > do a lot of them it may be worth considering batching them up and
> > calling shadow_blow_tables() once instead.
> >
> > Cheers,
> >
> > Tim.
> >
> >