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

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 07/23/2014 05:27 PM, Tamas Lengyel wrote:
>     > wrapped into an unlikely(). But isn't this a bit of an overkill at
>     every
>     > 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
>     domain.
> 
>     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.


Thanks,
Razvan Cojocaru