Xen project Mailing List

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

> 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.

> 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.

Cheers!

Tamas

_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel