On Wed, 2015-03-04 at 09:42 +0000, Jan Beulich wrote: > >>> On 04.03.15 at 10:35, <ian.campb...@citrix.com> wrote: > > On Wed, 2015-03-04 at 08:58 +0000, Jan Beulich wrote: > >> >>> On 03.03.15 at 11:32, <jgr...@suse.com> wrote: > >> > On 03/03/2015 11:27 AM, Jan Beulich wrote: > >> >>>>> On 03.03.15 at 10:29, <"jgr...@suse.com".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 <jgr...@suse.com> > >> >>> --- > >> >>> 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". Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
