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: Thu, 28 Aug 2014 15:23:20 +0300 Message-ID: <53FF1F38.9000603@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XMykM-0000T4-2o for xen-devel@lists.xenproject.org; Thu, 28 Aug 2014 12:24:10 +0000 In-Reply-To: <53FF38A6020000780002EB2B@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 08/28/2014 03:11 PM, Jan Beulich wrote: >>>> On 28.08.14 at 14:08, wrote: >> On 08/28/2014 03:03 PM, Jan Beulich wrote: >>>>>> On 28.08.14 at 13:48, wrote: >>>> + case XEN_DOMCTL_request_pagefault: >>>> + { >>>> + unsigned int vcpu = op->u.vcpucontext.vcpu; >>> >>> So you're using two different structures of the union - how can >>> that possibly work? You've got a 32-bi padding field, which you can >>> easily use to indicate the desired vCPU. Apart from that I'm not >>> seeing how your intended "any vCPU" is now getting handled. >> >> Sorry about that, started from a copy / paste bug from another domctl >> case. I'll add the vcpu field to our struct and use that. >> >> Not sure I follow the second part of your comment. Assuming the union >> problem is fixed, is this not what you meant about handling the page >> fault injection VCPU-based vs domain-based? > > It is, but you said you want an "I don't care on which vCPU" > special case. In fact with your previous explanations I could > see you getting into trouble if on a large guest you'd have to > wait for one particular CPU to get to carry out the desired > swap-in. I do, the code simply uses VCPU 0 for this now. The delay might indeed be a problem (though not a huge one, I'll have to check), but I'm not sure how else to strike a balance between the special case we need (which is fine for a mem_event-based application) and the general case (where there might not be any restrictions on the client). Thanks, Razvan Cojocaru