From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrei LUTAS Subject: Re: [PATCH RFC V3 4/5] xen, libxc: Request page fault injection via libxc Date: Wed, 23 Jul 2014 23:17:56 +0300 Message-ID: <53D01874.80109@bitdefender.com> References: <1406118884-16628-1-git-send-email-rcojocaru@bitdefender.com> <1406118884-16628-4-git-send-email-rcojocaru@bitdefender.com> <53CFC1EB.8080308@bitdefender.com> <53CFD108.5020107@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53CFD108.5020107@bitdefender.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Razvan Cojocaru , Tamas Lengyel Cc: kevin.tian@intel.com, Ian Campbell , Stefano Stabellini , Ian Jackson , eddie.dong@intel.com, "xen-devel@lists.xen.org" , Jan Beulich , Andres Lagar-Cavilla , jun.nakajima@intel.com, Andrew Cooper List-Id: xen-devel@lists.xenproject.org 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. Thanks! Andrei 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 >> 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 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >