[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC V3 4/5] xen, libxc: Request page fault injection via libxc

Hello, everybody!

The logic with the #PF injection goes like this:
- The memory introspection engine wants to inspect (for whatever reason) a
  virtual page X insidevirtual address space Y(inside user-mode, although
with proper knowledge about the guest kernel,one can also inject #PF inside
  kernel-mode on Windows - proper IRQL, working set trim inactive, etc.)
- The memory introspection engine will write-protect (via EPT) the Page Table Entries responsible for thetranslation of X to the Guest Physical Address Z
- The memory introspection engine requests the #PF injection
- The memory introspection engine patiently waits until the PTE corresponding tothe virtualpage Xis written - this means that the page has been swapped
  in, either due to our synthetic #PF, orbecause the guest OS accessed it
- We now need to analyse the faulting instruction in order to extract the
  written value, which containsthe address of the guest-physical page
containing the datawe want to analyse - W - what X will translate to after
  the swap-in operation will be complete; we basically need to map W,
  without doing a new translation for X. No pause of the entire domain is
  normally needed for this.

Hopefully this covers in more detail the actual use-case of the #PF injection
and how it interacts with the introspection engine.


On 7/23/2014 6:13 PM, Razvan Cojocaru wrote:
On 07/23/2014 05:27 PM, Tamas Lengyel wrote:
     > wrapped into an unlikely(). But isn't this a bit of an overkill at
     > VMENTER for every domain? Surely there are less invasive mechanisms to
     > trigger a VMEXIT when you know your VM will be in a state where
     you can
     > inject your page fault, without incurring an overhead for every

     It's not much of an overhead, basically if
     d->arch.hvm_domain.fault_info.virtual_address == 0 (which is almost
     always the case), nothing happens.

Since the majority of the domains will never use it, even a tiny
overhead adds up, especially over time. It would be a lot cleaner to
trap the execution of the VM at the moment when it is safe to inject the
page fault instead. For example you could just mark the process' code
pages non-executable in the EPT, catch the violations, and if the
conditions are met inject your pagefault.
Ufortunately it's more complicated than that. Our application wants to
be able to inject page faults at process initialization time, for PEB,
etc., where we're not necessarily talking about a process executing code.

     > Also, it might make sense to perform some sanity checks on the
     vaddr and
     > address space before injection (ie. is the page really swapped out).
     > There is no guarantee that the page is still swapped out, even if you
     > checked before issuing xc_domain_set_pagefault_info, unless the domain
     > had been paused for both checking and setting.

     As said above, the particular VCPU is in our case paused and waiting for
     a mem_event reply. The assumption is that other clients will work under
     similar circumstances, however it's always a good idea to check
     everything that can be checked.

I don't think having just the VCPU paused is enough, another still
active VCPU might still swap the page back, so you would really need to
have the entire VM paused for this to be safe. Furthermore, if there are
any limitations/assumptions like this about the intended use of the
function, describing them in a comment in xenctrl.h would be appropriate.
A typical use case for this is:

1. the application figures out that it needs a swapped out page;
2. the application tries to bring it in (via the code in this patch);
3. the application maps the page.

Now, if the application fails step 3, it might go back to step 2 until
it succeeds, or it might give up after some retries. If, however, it
succeeds, the mapped page should be safe to use until unmapped via libxc.

I would add that in practice this problem never occured with any of the
HVM Windows guests we've used for testing. The OS doesn't seem likely to
immediately swap out a page that's just been brought in.

If this is a concern, maybe I could simply add a comment in xenctrl.h
that would say that the new function is only to be used while the domain
is paused. I seem to recall having seen such comments there for other
libxc functions.

Razvan Cojocaru

Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.