From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH V4 4/5] xen, libxc: Request page fault injection via libxc Date: Mon, 08 Sep 2014 19:21:39 +0300 Message-ID: <540DD793.9060101@bitdefender.com> References: <1409911297-3360-1-git-send-email-rcojocaru@bitdefender.com> <1409911297-3360-5-git-send-email-rcojocaru@bitdefender.com> <540DEB9702000078000322A5@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XR1hL-0005JM-OB for xen-devel@lists.xenproject.org; Mon, 08 Sep 2014 16:21:47 +0000 In-Reply-To: <540DEB9702000078000322A5@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, keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, eddie.dong@intel.com, tim@xen.org, jun.nakajima@intel.com, xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 09/08/14 18:47, Jan Beulich wrote: >>>> On 05.09.14 at 12:01, wrote: >> + { >> + hvm_inject_trap(&d->arch.hvm_domain.inject_trap); >> + d->arch.hvm_domain.inject_trap.vector = -1; >> + } > > And this is clearly lacking serialization (or a comment saying why > serialization isn't needed here). If I understood this correctly, this is what Kevin has recommended: that only one HVMOP_trap_request should be pending at a time. Or have I misunderstood your comment? >> --- a/xen/include/public/hvm/hvm_op.h >> +++ b/xen/include/public/hvm/hvm_op.h >> @@ -197,6 +197,13 @@ struct xen_hvm_inject_trap { >> uint32_t insn_len; >> /* CR2 for page faults */ >> uint64_aligned_t cr2; >> + /* >> + * Only used if vcpuid == ~0 (wildcard for any VCPU). >> + * In that case, injection data is set per-domain, and any VCPU >> + * running a process with matching CR3 in user mode will inject >> + * the trap. >> + */ >> + uint64_aligned_t cr3; > > The comment should say "Currently only used ...", and the code > should then check this (returning the usual -EOPNOTSUPP). Or > alternatively implement it right away (which may be the better > route taking into consideration the first of the comments above). I will gladly change the comment, but I'm not sure for what CR3 value I should return -EOPNOTSUPP. Should I enforce that cr3 == 0 for the VCPU-specific case and for traps that are not page faults? Could you please elaborate on what the alternative is? Thanks, Razvan Cojocaru