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

[Juergen Gross <jgross@xxxxxxxx>]

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.


Juergen


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