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

[Juergen Gross <jgross@xxxxxxxx>]

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.

> Also I'm not particularly happy with the name, as it suggests to be
> a statement about the initial P2M the guest gets handed - yet that
> is always virtually mapped. SIF_PERMANENT_VIRT_P2M is getting a
> little long I'm afraid, so I'm looking for better suggestions.
SIF_VIRT_KERNEL_P2M?
SIF_FLAT_P2M?


Juergen


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