From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH RFC V7 4/5] xen,
 libxc: Request page fault injection via libxc
Date: Tue, 26 Aug 2014 15:44:04 +0100
Message-ID: <53FCB954020000780002DB08@mail.emea.novell.com>
References: <1407943689-9249-1-git-send-email-rcojocaru@bitdefender.com>
	<1407943689-9249-4-git-send-email-rcojocaru@bitdefender.com>
	<53FCB226020000780002DA7B@mail.emea.novell.com>
	<53FC98AD.6010104@bitdefender.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: <53FC98AD.6010104@bitdefender.com>
Content-Disposition: inline
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: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, eddie.dong@intel.com, xen-devel@lists.xen.org, jun.nakajima@intel.com, ian.jackson@eu.citrix.com
List-Id: xen-devel@lists.xenproject.org

>>> On 26.08.14 at 16:24, <rcojocaru@bitdefender.com> wrote:
> On 08/26/2014 05:13 PM, Jan Beulich wrote:
>>>>> On 13.08.14 at 17:28, <rcojocaru@bitdefender.com> wrote:
>>> --- a/xen/include/asm-x86/hvm/domain.h
>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>> @@ -141,6 +141,14 @@ struct hvm_domain {
>>>       */
>>>      uint64_t sync_tsc;
>>>  
>>> +    /* Memory introspection page fault injection data. */
>>> +    struct {
>>> +        uint64_t address_space;
>>> +        uint64_t virtual_address;
>>> +        uint32_t errcode;
>>> +        bool_t valid;
>>> +    } fault_info;
>> 
>> Sorry for noticing this only now, but how can this be a per-domain
>> thing rather than a per-vCPU one?
> 
> The requirement for our introspection application has simply been to
> bring back in a swapped-out page, regardless of what VCPU ends up
> actually doing it.

But please remember that what you add to the public code base
shouldn't be tied to specific needs of your application, it should
be coded in a generally useful way.

Furthermore, how would this work if you have 2 vCPU-s hit such
a condition, and you need to bring in 2 pages in parallel?

Jan