From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCH 15/18] PVH xen: add hypercall support for PVH
Date: Wed, 26 Jun 2013 20:09:43 -0700
Message-ID: <20130626200943.71b6e399@mantra.us.oracle.com>
References: <1372118507-16864-1-git-send-email-mukesh.rathor@oracle.com>
	<1372118507-16864-16-git-send-email-mukesh.rathor@oracle.com>
	<51C9892902000078000E049F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <51C9892902000078000E049F@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Tue, 25 Jun 2013 11:12:25 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> > @@ -3777,7 +3815,7 @@ long do_hvm_op(unsigned long op,
> > XEN_GUEST_HANDLE_PARAM(void) arg) return -ESRCH;
> >  
> >          rc = -EINVAL;
> > -        if ( !is_hvm_domain(d) )
> > +        if ( is_pv_domain(d) )
> >              goto param_fail;
> >  
> >          rc = xsm_hvm_param(XSM_TARGET, d, op);
> > @@ -3949,7 +3987,7 @@ long do_hvm_op(unsigned long op,
> > XEN_GUEST_HANDLE_PARAM(void) arg) break;
> >              }
> >  
> > -            if ( rc == 0 ) 
> > +            if ( rc == 0 && !is_pvh_domain(d) )
> >              {
> >                  d->arch.hvm_domain.params[a.index] = a.value;
> >  
> 
> This last check I think you do because params[] points nowhere for
Correct.

> PVH guests. If so - why don't you just drop this and the earlier
> hunk? Or otherwise some of the case statements between need to

I don't understand, drop from where? You mean a totally separate function
for PVH (I had that in very earlier patches).

> also guard against accessing the unset pointer.

Correct, I'd need to do that. Originally, I had a white list of case
operations prohibited for PVH, but removed it.

-Mukesh