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 11:20 +0100, Juergen Gross wrote:
> On 03/04/2015 11:06 AM, Ian Campbell wrote:
> > 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".
> 
> I'd like to do an appropriate change in xl, but I've been told this
> would make sense only for migration protocol V2. OTOH I don't want to
> wait for an undefined amount of time until this will be posted, so I
> sent the ABI change first.
> 
> I could, of course, wait with the flag bit until xl is ready and post
> another kernel patch then. Unfortunately this would delay Linux support
> for automatically be able to run as a pv-domain >500GB further, so I
> strongly recommend accepting the interface change now.

Please at least sketch out a design/description of what this flag means
to the guest and/or tools and what eventual tools support you expect
will be needed, and perhaps some ideas regarding what that support might
look like.

Without this your proposed ABI change is just a random bit in a data
structure with no context.

Ian.


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