All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Tamas Lengyel <tamas.lengyel@zentific.com>
Cc: kevin.tian@intel.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	eddie.dong@intel.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	jun.nakajima@intel.com, Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH RFC V3 4/5] xen, libxc: Request page fault injection via libxc
Date: Wed, 23 Jul 2014 17:08:43 +0300	[thread overview]
Message-ID: <53CFC1EB.8080308@bitdefender.com> (raw)
In-Reply-To: <CAErYnsh8ub-J-LhCtG5rxNKxq28Tm+JgVQWT58iPswskG-0m0A@mail.gmail.com>

On 07/23/2014 04:40 PM, Tamas Lengyel wrote:
> 
>     @@ -3137,6 +3172,8 @@ void vmx_vmenter_helper(const struct
>     cpu_user_regs *regs)
>          if ( unlikely(need_flush) )
>              vpid_sync_all();
> 
>     +    check_pf_injection();
> 
> 
> The function check_pf_injection isn't just 'checking', it does issue the
> page fault injection as well under the right circumstances, and as such
> the naming of the function is a bit misleading. Breaking it into two
> functions might be an improvement where the actual check itself could be

That's a good point. I'll split it into two functions (and add a vmx_
prefix to their names while I'm at it).

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

> Another question is, how do you know when the page fault had been
> handled and the page can be inspected? You would need some other trigger
> just at the right point in the execution of the VM or the page could be
> swapped out again before you had a chance to inspect it.

In our case, this always happens while the VCPU is paused waiting for a
mem_event reply, so it fits quite well.

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


Thanks,
Razvan Cojocaru

  reply	other threads:[~2014-07-23 14:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-23 12:34 [PATCH RFC V3 1/5] xen: Emulate with no writes Razvan Cojocaru
2014-07-23 12:34 ` [PATCH RFC V3 2/5] xen: Optimize introspection access to guest state Razvan Cojocaru
2014-07-24 15:07   ` Jan Beulich
2014-07-23 12:34 ` [PATCH RFC V3 3/5] xen: Force-enable relevant MSR events; optimize the number of sent MSR events Razvan Cojocaru
2014-07-24 15:14   ` Jan Beulich
2014-07-24 15:56     ` Razvan Cojocaru
2014-07-23 12:34 ` [PATCH RFC V3 4/5] xen, libxc: Request page fault injection via libxc Razvan Cojocaru
2014-07-23 13:40   ` Tamas Lengyel
2014-07-23 14:08     ` Razvan Cojocaru [this message]
2014-07-23 14:27       ` Tamas Lengyel
2014-07-23 15:13         ` Razvan Cojocaru
2014-07-23 20:17           ` Andrei LUTAS
2014-07-24 12:38             ` Ian Jackson
2014-07-24 12:41               ` Andrew Cooper
2014-07-24 12:44                 ` Razvan Cojocaru
2014-07-24 12:33   ` Ian Jackson
2014-07-24 15:27   ` Jan Beulich
2014-07-24 16:18     ` Razvan Cojocaru
2014-07-25  7:50       ` Jan Beulich
2014-07-23 12:34 ` [PATCH RFC V3 5/5] xen: Handle resumed instruction based on previous mem_event reply Razvan Cojocaru
2014-07-24 15:42   ` Jan Beulich
2014-07-24 16:29     ` Razvan Cojocaru
2014-07-25  7:52       ` Jan Beulich
2014-07-24 11:20 ` [PATCH RFC V3 1/5] xen: Emulate with no writes Tim Deegan
2014-07-24 11:40   ` Razvan Cojocaru
2014-07-25 13:52   ` Razvan Cojocaru
2014-07-25 14:07     ` Jan Beulich
2014-07-24 12:32 ` Ian Jackson
2014-07-24 12:36   ` Razvan Cojocaru
2014-07-24 12:37     ` Razvan Cojocaru
2014-07-24 17:25     ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53CFC1EB.8080308@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andres@lagarcavilla.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tamas.lengyel@zentific.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.