[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/18 V2]: PVH xen: introduce vmx_pvh.c and pvh.c
>>> On 02.04.13 at 02:08, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote: > On Mon, 18 Mar 2013 12:16:50 +0000 > "Jan Beulich" <JBeulich@xxxxxxxx> wrote: > >> >>> On 16.03.13 at 01:41, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> >> >>> wrote: >> > +static int pvh_grant_table_op( >> > + unsigned int cmd, XEN_GUEST_HANDLE(void) uop, >> > unsigned int count) +{ >> > + switch (cmd) >> > + { >> > + case GNTTABOP_map_grant_ref: >> > + case GNTTABOP_unmap_grant_ref: >> > + case GNTTABOP_setup_table: >> > + case GNTTABOP_copy: >> > + case GNTTABOP_query_size: >> > + case GNTTABOP_set_version: >> > + return do_grant_table_op(cmd, uop, count); >> >> While for HVM guests such white lists may be appropriate, for PVH >> this doesn't seem to be the case: The code would require updating >> whenever a new sub-hypercall gets added to any of the hypercalls >> dealt with like this. > > Right, these are verified for PVH. As they are added, they would need > to be verfied to make sure OK for PVH. We can remove this later. I can > ifdef DEBUG if you'd like. Yes, some sort of code mark would be nice - after all, such code has to go away before PVH can be declared production ready. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |