From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH RFC V3 4/5] xen,
 libxc: Request page fault injection via libxc
Date: Thu, 24 Jul 2014 13:41:13 +0100
Message-ID: <53D0FEE9.90205@citrix.com>
References: <1406118884-16628-1-git-send-email-rcojocaru@bitdefender.com>	<1406118884-16628-4-git-send-email-rcojocaru@bitdefender.com>	<CAErYnsh8ub-J-LhCtG5rxNKxq28Tm+JgVQWT58iPswskG-0m0A@mail.gmail.com>	<53CFC1EB.8080308@bitdefender.com>	<CAErYnsjsrP_z5aNQ98b4SAujqES6F1B=w6d=c+NqdT07fsa5pw@mail.gmail.com>	<53CFD108.5020107@bitdefender.com>	<53D01874.80109@bitdefender.com>
	<21456.65069.187119.457145@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <21456.65069.187119.457145@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Andrei LUTAS <vlutas@bitdefender.com>
Cc: kevin.tian@intel.com, Ian Campbell <Ian.Campbell@citrix.com>, Razvan Cojocaru <rcojocaru@bitdefender.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Tamas Lengyel <tamas.lengyel@zentific.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
List-Id: xen-devel@lists.xenproject.org

On 24/07/14 13:38, Ian Jackson wrote:
> Andrei LUTAS writes ("Re: [Xen-devel] [PATCH RFC V3 4/5] xen, libxc: Request page fault injection via libxc"):
>> The logic with the #PF injection goes like this:
> Sorry, I didn't see this message when I sent my last one asking about
> the motivation.
>
>> - 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.)
> I don't understand why this needs additional hypervisor code.  Can
> this not be done by negotiating with the paging daemon ?
>
> Ian.

The purpose of this is to play with the paging algorithm inside the
guest OS, which can only be done from outside by providing pagefaults
when considered safe to do so.

This has nothing to do with xen-paging transparently playing with the
guest physical address space behind the guests back.

~Andrew