From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCH 08/18] PVH xen: tools changes to create PVH
 domain
Date: Wed, 28 Aug 2013 18:51:52 -0700
Message-ID: <20130828185152.0f7bcf8c@mantra.us.oracle.com>
References: <1369445137-19755-1-git-send-email-mukesh.rathor@oracle.com>
	<1369445137-19755-9-git-send-email-mukesh.rathor@oracle.com>
	<1371049088.24512.450.camel@zakaz.uk.xensource.com>
	<20130614171437.49f55cea@mantra.us.oracle.com>
	<1371467494.23802.49.camel@zakaz.uk.xensource.com>
	<20130730164716.10969419@mantra.us.oracle.com>
	<1375272057.7382.24.camel@kazak.uk.xensource.com>
	<20130731190213.0b57efd0@mantra.us.oracle.com>
	<1375344091.15681.41.camel@dagon.hellion.org.uk>
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: <1375344091.15681.41.camel@dagon.hellion.org.uk>
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: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Thu, 1 Aug 2013 09:01:31 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2013-07-31 at 19:02 -0700, Mukesh Rathor wrote:
> > On Wed, 31 Jul 2013 13:00:57 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Tue, 2013-07-30 at 16:47 -0700, Mukesh Rathor wrote:
> > > > On Mon, 17 Jun 2013 12:11:34 +0100
> > > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
...
> I think it is valid for a user to both request PVH mode and request
> some features of their own which they want to enable for this guest.
> The code should be set up to deal with  this, even if that currently
> means rejecting any user request for a feature not in the PVH set
> (although I'd prefer to see a stronger rationale for rejecting a
> requested feature than that).
> 
> >  I can juse use the existing 
> > xc_interface_core.flags? (would like to rename it to xc_flags so
> > one can easily find its usages please :)).
> 
> Pointless churn. You've made this argument countless times about
> various and been told no by several different people, please just
> drop it.
> 
> >  So:
> > 
> > xc_dom_allocate:
> > 
> >     if (xch->flags & PVH)
> >     {
> >         if (features)
> >         {
> >             error
> >             return NULL;
> 
> No, please handle the case of the user asking for features.
> 
> At the very least if they only ask for things in the set you are
> forcing then it is fine.
> 
> >         }
> >         features =
> > writable_descriptor_tables|auto_translated_physmap"
> > "|supervisor_mode_kernel|hvm_callback_vector;
> 
> Don't do this. Instead, drop this whole if and add below:
> 
> >     }
> >     if ( features )
> >         elf_xen_parse_features(features, dom->f_requested, NULL);
> 
> 	if ( xch->flags & PVH )
> 		elf_xen_parse_features("writable_desc...|etc",
> dom->f_requested, dom->f_required)

Hmm.. the problem I am running here now is setting of PVH flag in 
xch->flags from libxl? struct xch seems to be private to libxc. So
short of creating a new xc_ interface just to set it, since I can't
add any parameters to xc_dom_allocate(), I can't think of any other
way. Also, the time when xc_interface is allcoated, we have not parsed
the config file to set it right then.

thanks
mukesh