From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH RFC V2 4/6] xen: Support for VMCALL mem_events Date: Tue, 17 Mar 2015 16:33:17 +0200 Message-ID: <55083B2D.3060600@bitdefender.com> References: <1405093418-23481-1-git-send-email-rcojocaru@bitdefender.com> <1405093418-23481-4-git-send-email-rcojocaru@bitdefender.com> <53C01D85.3010205@citrix.com> <5508313C.3060004@bitdefender.com> <5508410F020000780006AE09@mail.emea.novell.com> <5508351E.1050808@bitdefender.com> <55084646020000780006AE58@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55084646020000780006AE58@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: Andrew Cooper , mdontu@bitdefender.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/17/2015 04:20 PM, Jan Beulich wrote: >>>> On 17.03.15 at 15:07, wrote: >> Yes, but Andrew's idea (which I think is very neat) is that instead of >> the trickery I used to do in the original patch (create a specific >> VMCALL vm_event and compare eax to a magic constant on VMCALL-based >> VMEXITS, to figure out if all I wanted to do was send out the event), >> that I should instead have the guest set up rax, rdi and rsi and execute >> vmcall, which would then be translated to a real hypercall that sends >> out a vm_event. > > If you think about a bare HVM guest OS (i.e. without any PV > drivers), then of course you should provide such hypercall > wrappers for code to use instead of open coding it in potentially > many places. > >> In this case, the (HVM) guest does need to concern itself with what >> registers it should set up for that purpose. I suppose a workaround >> could be to write the subop in both ebx and rdi, though without any >> testing I don't know at this point what, if anything, might be broken >> that way. > > Guest code ought to know what mode it runs in. And introspection > code (in case this is about injection of such code) ought to also > know which mode the monitored guest is in. Yes, we'll try to handle this, I was mainly asking because based on Andrew's suggestion (which only mentioned rdi, not ebx) I wanted to make sure that this is not someting that people might prefer to change at Xen source code level. Thanks for the clarification, Razvan