Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-03-04 at 09:42 +0000, Jan Beulich wrote:
> >>> On 04.03.15 at 10:35, <ian.campbell@xxxxxxxxxx> wrote:
> > On Wed, 2015-03-04 at 08:58 +0000, Jan Beulich wrote:
> >> >>> On 03.03.15 at 11:32, <JGross@xxxxxxxx> wrote:
> >> > On 03/03/2015 11:27 AM, Jan Beulich wrote:
> >> >>>>> On 03.03.15 at 10:29, <"jgross@xxxxxxxx".non-mime.internet> wrote:
> >> >>> In order to indicate the Xen tools capability to support the virtual
> >> >>> mapped linear p2m list instead the 3 level mfn tree add a flag to the
> >> >>> start_info page.
> >> >>>
> >> >>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> >> >>> ---
> >> >>>   xen/include/public/xen.h | 2 ++
> >> >>>   1 file changed, 2 insertions(+)
> >> >>>
> >> >>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> >> >>> index 3703c39..36c6d62 100644
> >> >>> --- a/xen/include/public/xen.h
> >> >>> +++ b/xen/include/public/xen.h
> >> >>> @@ -777,6 +777,8 @@ typedef struct start_info start_info_t;
> >> >>>   #define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control 
> >> >>> domain? */
> >> >>>   #define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot 
> >> >>> module? */
> >> >>>   #define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
> >> >>> +#define SIF_VIRT_P2M      (1<<4)  /* Does Xen understand a virt. 
> >> >>> mapped P->M 
> >> > */
> >> >>> +                                  /* making the 3 level tree 
> >> >>> obsolete?     
> >  
> >> >  */
> >> >>>   #define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm 
> >> >>> options */
> >> >>>
> >> >>>   /*
> >> >>
> >> >> Is there any reason why this can't be part of the tools patch (series)
> >> >> actually going to make use of it?
> >> > 
> >> > The main reason is I want to make use of it in the related kernel
> >> > series first. And this requires the Xen header implementation.
> >> 
> >> I was about to apply v3, but I'm still unconvinced: How would you
> >> test those kernel side changes without having anything to set the
> >> flag?
> > 
> > It does seem odd to be committing to an ABI with no xen.git side
> > implementation having been posted yet. Normally we ask that things go
> > into xen.git first before any guests start using them.
> 
> Your reply seems ambiguous to me: If it was sent to JÃrgen (with
> me Cc-ed) I'd read it as supporting my earlier statement. Since,
> however, it was sent to me (with JÃrgen Cc-ed), I could also read
> it as supporting the public header change alone to go in (even if in
> slight collision with the word "implementation" in there). Could you
> clarify?

Sorry, I was in support of you (Jan) here.

Sometime an ABI header change might be all which is needed before guests
start using things (e.g. an io protocol change), but I think in this
case we really need to at least have seen the complete solution (so any
relevant Xen/tools changes) before we commit to an ABI.

It _might_ be sufficient if this patch included some documentation about
what this flag actually means, but best would be to see the actual tools
side (or even a design, sorry if I've missed this somewhere along the
line).

What I don't want to happen is for me to request a change during tools
review only to be told "kernels in the field already do it this way".

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel