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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

Jan

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