From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH 3/5] xen/vm_event: Support for guest-requested events Date: Tue, 09 Jun 2015 15:44:53 +0300 Message-ID: <5576DFC5.1080801@bitdefender.com> References: <1430932352-4289-1-git-send-email-rcojocaru@bitdefender.com> <1430932352-4289-4-git-send-email-rcojocaru@bitdefender.com> <554CE959.8090701@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <554CE959.8090701@citrix.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: Andrew Cooper , xen-devel@lists.xen.org Cc: kevin.tian@intel.com, keir@xen.org, jun.nakajima@intel.com, stefano.stabellini@eu.citrix.com, eddie.dong@intel.com, ian.jackson@eu.citrix.com, tim@xen.org, Aravind.Gopalakrishnan@amd.com, jbeulich@suse.com, wei.liu2@citrix.com, boris.ostrovsky@oracle.com, suravee.suthikulpanit@amd.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 05/08/2015 07:50 PM, Andrew Cooper wrote: > On 06/05/15 18:12, Razvan Cojocaru wrote: >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >> index 86f9885..8ad03c6 100644 >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -6267,6 +6267,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) >> break; >> } >> >> + case HVMOP_request_vm_event: >> + hvm_event_requested(); >> + break; >> + > > This is much better than the previous version, but there is nothing > HVM-specific about having an arbitrary signal to the vm_event subsystem. > > It might be better to chose a different hypercall to hang a subop off. > On the other hand, we already have things like HVMOP_xentrace, and there > is nothing actually preventing PV domains issuing a > HVMOP_request_vm_event. Perhaps it doesn't matter too much. Working on this again, I'm fine with changing the hypercall but looking at xen.h none of the others strike me as particularly more intuitive than __HYPERVISOR_hvm_op. Could you please suggest one that you think fits the bill? Thanks, Razvan