From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH V2 2/3] xen/vm_event: Support for guest-requested events Date: Fri, 26 Jun 2015 08:02:35 +0100 Message-ID: <558D152B0200007800089FD4@mail.emea.novell.com> References: <1434359007-9302-1-git-send-email-rcojocaru@bitdefender.com> <1434359007-9302-3-git-send-email-rcojocaru@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434359007-9302-3-git-send-email-rcojocaru@bitdefender.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Razvan Cojocaru 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, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org >>> On 15.06.15 at 11:03, wrote: > Added support for a new class of vm_events: VM_EVENT_REASON_REQUEST, > sent via HVMOP_request_vm_event. The guest can request that a > generic vm_event (containing only the vm_event-filled guest registers > as information) be sent to userspace by setting up the correct > registers and doing a VMCALL. For example, for a 64-bit guest, this > means: EAX = 34 (hvmop), EBX = 24 (HVMOP_request_vm_event). I suppose you mean a 32-bit guest here? Also I'm not sure it's a good idea to explicitly define a guest exposed hypercall to omit one of the arguments normally required for it (the interface structure pointer): Should there ever be a reason to allow the guest to control further aspects of the operation by passing a structure, you'd then have to define a new sub-op instead of being able to re-use the current one. I.e. I'd strongly recommend requiring NULL to be passed here, and checking this in the implementation of the handler. > --- a/xen/arch/x86/hvm/event.c > +++ b/xen/arch/x86/hvm/event.c > @@ -126,6 +126,20 @@ void hvm_event_msr(unsigned int msr, uint64_t value) > hvm_event_traps(1, &req); > } > > +void hvm_event_requested(void) > +{ > + struct vcpu *curr = current; > + struct arch_domain *currad = &curr->domain->arch; > + > + vm_event_request_t req = { Please avoid blank lines between declarations - a blank line following declaration is supposed to delimit them from statements. > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -6373,6 +6373,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) > break; > } > > + case HVMOP_request_vm_event: > + hvm_event_requested(); > + break; No XSM check here or in the handler? Shouldn't the admin controlling guest properties from the host perspective be permitted control here? Cc-ing Daniel for his input ... > --- a/xen/include/asm-x86/domain.h > +++ b/xen/include/asm-x86/domain.h > @@ -342,13 +342,15 @@ struct arch_domain > > /* Monitor options */ > struct { > - uint16_t write_ctrlreg_enabled : 4; > - uint16_t write_ctrlreg_sync : 4; > - uint16_t write_ctrlreg_onchangeonly : 4; > - uint16_t mov_to_msr_enabled : 1; > - uint16_t mov_to_msr_extended : 1; > - uint16_t singlestep_enabled : 1; > - uint16_t software_breakpoint_enabled : 1; > + uint32_t write_ctrlreg_enabled : 4; > + uint32_t write_ctrlreg_sync : 4; > + uint32_t write_ctrlreg_onchangeonly : 4; > + uint32_t mov_to_msr_enabled : 1; > + uint32_t mov_to_msr_extended : 1; > + uint32_t singlestep_enabled : 1; > + uint32_t software_breakpoint_enabled : 1; > + uint32_t request_enabled : 1; > + uint32_t request_sync : 1; Can you please switch to plain unsigned int if you already have to touch this? There's no reason I can see to use a fixed width integer type here. > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -389,6 +389,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_evtchn_upcall_vector_t); > > #endif /* defined(__i386__) || defined(__x86_64__) */ > > +#if defined(__XEN__) || defined(__XEN_TOOLS__) > +#define HVMOP_request_vm_event 24 > +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ Isn't this _specifically_ meant to be usable by a guest? Jan