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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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