From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc Date: Tue, 02 Sep 2014 12:44:10 +0300 Message-ID: <5405916A.9000103@bitdefender.com> References: <1409226482-12657-1-git-send-email-rcojocaru@bitdefender.com> <1409226482-12657-4-git-send-email-rcojocaru@bitdefender.com> <53FF36A1020000780002EAED@mail.emea.novell.com> <53FF1BD8.5010401@bitdefender.com> <53FF38A6020000780002EB2B@mail.emea.novell.com> <54002F43.4070802@bitdefender.com> <5400638A020000780002EFD6@mail.emea.novell.com> <540421E1.9020505@bitdefender.com> <540453C8020000780002F59C@mail.emea.novell.com> <54045E7C.50604@bitdefender.com> <54047D1D020000780002F73A@mail.emea.novell.com> <54058B4E.9060001@bitdefender.com> <5405AAF5020000780002FC6C@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XOkdV-0001lI-43 for xen-devel@lists.xenproject.org; Tue, 02 Sep 2014 09:44:25 +0000 In-Reply-To: <5405AAF5020000780002FC6C@mail.emea.novell.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: Jan Beulich Cc: kevin.tian@intel.com, eddie.dong@intel.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, tim@xen.org, jun.nakajima@intel.com, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 09/02/2014 12:33 PM, Jan Beulich wrote: >>>> On 02.09.14 at 11:18, wrote: >> While we need to set the data per-domain and have whatever VCPU inject >> the page fault - _but_only_if_ it's in usermode and its CR3 points to >> something interesting. > > Right - but none of this is an argument against adding a wildcard > specifier for the vCPU passed in the existing interface and - > assuming this is a tools only interface - add the additional qualifiers > (and perhaps even make the code obey to them when used in a > vCPU-centric invocation). But adding a wildcard for the VCPU would effectively mean that this part of the HVMOP_inject_trap case handling code would need to be modified to use per-domain data instead of per-VCPU data (which with a wildcard would not make sense): rc = -ENOENT; if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid]) == NULL ) goto param_fail8; if ( v->arch.hvm_vcpu.inject_trap.vector != -1 ) rc = -EBUSY; else { v->arch.hvm_vcpu.inject_trap.vector = tr.vector; v->arch.hvm_vcpu.inject_trap.type = tr.type; v->arch.hvm_vcpu.inject_trap.error_code = tr.error_code; v->arch.hvm_vcpu.inject_trap.insn_len = tr.insn_len; v->arch.hvm_vcpu.inject_trap.cr2 = tr.cr2; rc = 0; } The alternative would be to set the data to _all_ of the VCPUs for the wildcard case, but that could potentially trigger a page fault for every VCPU. While I can't possibly have any technical arguments against using a wildcard for the VCPU (-1 looks like a likely candidate) and adding a bool_t usermode and an unsigned long cr3 parameter / member, those changes might somewhat warp the design of HVMOP_inject_trap. Thanks, Razvan Cojocaru