[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH V3 2/3] xen/vm_event: Support for guest-requested events
- To: Jan Beulich <JBeulich@xxxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
- From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
- Date: Tue, 07 Jul 2015 10:26:45 -0400
- Cc: kevin.tian@xxxxxxxxx, wei.liu2@xxxxxxxxxx, ian.campbell@xxxxxxxxxx, stefano.stabellini@xxxxxxxxxxxxx, george.dunlap@xxxxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, ian.jackson@xxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxx, eddie.dong@xxxxxxxxx, Aravind.Gopalakrishnan@xxxxxxx, jun.nakajima@xxxxxxxxx, tlengyel@xxxxxxxxxxx, keir@xxxxxxx, boris.ostrovsky@xxxxxxxxxx, suravee.suthikulpanit@xxxxxxx
- Delivery-date: Tue, 07 Jul 2015 14:27:24 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 07/07/2015 09:30 AM, Jan Beulich wrote:
On 06.07.15 at 17:51, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
@@ -6388,6 +6387,13 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
}
+ case HVMOP_guest_request_vm_event:
+ if ( guest_handle_is_null(arg) )
+ hvm_event_guest_request();
+ else
+ rc = -EINVAL;
+ break;
Pending Daniel's confirmation that not having an XSM check here
is okay,
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
I don't think an XSM check is needed here, if only because the events are
being added to an existing channel from the guest to the monitor. The
best way to control this communication is probably when the shared page is
mapped by the monitor, but this is an existing mechanism which appears to
be covered by the ability to map any page in the target domain.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
