[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.