From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH V2 2/3] xen/vm_event: Support for guest-requested events Date: Thu, 25 Jun 2015 12:09:34 +0300 Message-ID: <558BC54E.30206@bitdefender.com> References: <1434359007-9302-1-git-send-email-rcojocaru@bitdefender.com> <1434359007-9302-3-git-send-email-rcojocaru@bitdefender.com> <558AC521.8090606@bitdefender.com> <558AE2CE020000780008903F@mail.emea.novell.com> <558BB3FF.5070504@bitdefender.com> <558BD9F10200007800089610@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <558BD9F10200007800089610@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: tim@xen.org, kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, jun.nakajima@intel.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, eddie.dong@intel.com, Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com, keir@xen.org, boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org On 06/25/2015 11:37 AM, Jan Beulich wrote: >>>> On 25.06.15 at 09:55, wrote: >> On 06/24/2015 06:03 PM, Jan Beulich wrote: >>>>>> On 24.06.15 at 16:56, wrote: >>>> Would it be fair to say that HVMOP_request_vm_event should be an >>>> exception to this rule (i.e. something along the lines of "if ( >>>> unlikely(r12 == HVMOP_request_vm_event) && orig_pc == regs->pc )", >>>> etc.)? Even in debug mode, a GUEST_REQUEST vm_event should keep the >>>> state of the guest intact. >>> >>> It's a hypercall, and hence should follow hypercall rules. If the >>> guest wants certain registers preserved, it should do so itself. >> >> Right, that's sensible, hypercalls should behave in a consistent manner. >> The only issue here is that (and I think this would prove useful for >> many future introspection clients), the trigger VMCALL doesn't often >> happen from an in-guest driver. >> >> From what I understand from our introspection logic team (maybe they'll >> chime in), VMCALLs are being used as markers in the code the OS is >> running: "now we've reached this function, check out the guest >> environment", "now we've reached this other function", etc. >> >> They seem to be doing this often by overwriting (from the dom0 >> application) the beginning of a function that needs hooked, and the >> larger this custom code becomes, the more problems arise. In the >> registers clobber scenario, both registers holding HVMOP and >> HVMOP_request_vm_event need to be saved and restored (pushed and >> popped), and now additionally, for safety, all the clobbered registers, >> so the necessary code has increased several times since the early days >> of "push eax, mov eax MAGIC_CONSTANT, vmcall, pop eax". >> >> Hence the request to at least not clobber the registers in this case, >> and a reason why this initally was not a hypercall although the code >> _almost_ acted like one. >> >> Any suggestions (other than to just live with the situation)? :) > > Even for the original code sequence you quote above it would be > less intrusive to the patched code if they just patched in a call. > Namely in Windows, with its reportedly pretty uniform function > prologues, there shouldn't be too many stub variants necessary > that such calls would target. That makes great sense, that's very likely going to be the way to go forward, so the patch can stay as it is. Thanks, Razvan