[PATCH 0/3] repair stubdoms

[PATCH 0/3] repair stubdoms

[Juergen Gross]

Adding support for HVMlite Mini-OS broke some stubdom functionality
as various parts of the stubdom code was built without specifying
any Mini-OS configuration defines. This led to inconsistencies when
those parts included Mini-OS headers now depending on the config of
Mini9-OS. Some of those cases did work just by pure luck.

Juergen Gross (3):
  mini-os: support newer xen interface
  mini-os: provide irq on/off/save/restore functions for Mini-OS apps
  mini-os: support "make config" for out-of-tree users

 .gitignore       |  1 +
 Config.mk        |  4 +++-
 Makefile         |  5 +++++
 arch/arm/mm.c    |  2 +-
 arch/x86/mm.c    |  2 +-
 arch/x86/sched.c | 28 ++++++++++++++++++++++++++++
 balloon.c        |  2 --
 gnttab.c         |  4 ++--
 include/gnttab.h |  2 +-
 include/x86/os.h | 13 +++++++++++++
 minios.mk        |  1 -
 11 files changed, 55 insertions(+), 9 deletions(-)

-- 
2.6.6


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

[PATCH 1/3] mini-os: support newer xen interface

[Juergen Gross]

Mini-OS is currently setting __XEN_INTERFACE_VERSION__ to a rather
ancient version.

To be able to use a more recent variant garnt_entry_t must be changed
to grant_entry_v1_t. In balloon.c we omit initializing elements of
struct xen_memory_reservation with 0 to avoid problems with different
named structure elements in different Xen interface versions.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/arm/mm.c    | 2 +-
 arch/x86/mm.c    | 2 +-
 balloon.c        | 2 --
 gnttab.c         | 4 ++--
 include/gnttab.h | 2 +-
 5 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mm.c b/arch/arm/mm.c
index 8c156c4..f806c9f 100644
--- a/arch/arm/mm.c
+++ b/arch/arm/mm.c
@@ -116,7 +116,7 @@ static paddr_t get_gnttab_base(void)
     return gnttab_base;
 }
 
-grant_entry_t *arch_init_gnttab(int nr_grant_frames)
+grant_entry_v1_t *arch_init_gnttab(int nr_grant_frames)
 {
     struct xen_add_to_physmap xatp;
     struct gnttab_setup_table setup;
diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index 8dd90b8..05ad029 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -890,7 +890,7 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned long* max_pfn_p)
 #endif
 }
 
-grant_entry_t *arch_init_gnttab(int nr_grant_frames)
+grant_entry_v1_t *arch_init_gnttab(int nr_grant_frames)
 {
     struct gnttab_setup_table setup;
     unsigned long frames[nr_grant_frames];
diff --git a/balloon.c b/balloon.c
index b0d0230..5676d3b 100644
--- a/balloon.c
+++ b/balloon.c
@@ -73,8 +73,6 @@ int balloon_up(unsigned long n_pages)
     unsigned long page, pfn;
     int rc;
     struct xen_memory_reservation reservation = {
-        .address_bits = 0,
-        .extent_order = 0,
         .domid        = DOMID_SELF
     };
 
diff --git a/gnttab.c b/gnttab.c
index f395d12..3f0e35f 100644
--- a/gnttab.c
+++ b/gnttab.c
@@ -24,9 +24,9 @@
 
 /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
 #define NR_GRANT_FRAMES 4
-#define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * PAGE_SIZE / sizeof(grant_entry_t))
+#define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * PAGE_SIZE / sizeof(grant_entry_v1_t))
 
-static grant_entry_t *gnttab_table;
+static grant_entry_v1_t *gnttab_table;
 static grant_ref_t gnttab_list[NR_GRANT_ENTRIES];
 #ifdef GNT_DEBUG
 static char inuse[NR_GRANT_ENTRIES];
diff --git a/include/gnttab.h b/include/gnttab.h
index c43ad42..a9d8e09 100644
--- a/include/gnttab.h
+++ b/include/gnttab.h
@@ -12,6 +12,6 @@ unsigned long gnttab_end_transfer(grant_ref_t gref);
 int gnttab_end_access(grant_ref_t ref);
 const char *gnttabop_error(int16_t status);
 void fini_gnttab(void);
-grant_entry_t *arch_init_gnttab(int nr_grant_frames);
+grant_entry_v1_t *arch_init_gnttab(int nr_grant_frames);
 
 #endif /* !__GNTTAB_H__ */
-- 
2.6.6


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

Re: [PATCH 1/3] mini-os: support newer xen interface

[Wei Liu]

On Tue, Aug 30, 2016 at 01:51:21PM +0200, Juergen Gross wrote:
> Mini-OS is currently setting __XEN_INTERFACE_VERSION__ to a rather
> ancient version.
> 
> To be able to use a more recent variant garnt_entry_t must be changed
> to grant_entry_v1_t. In balloon.c we omit initializing elements of
> struct xen_memory_reservation with 0 to avoid problems with different
> named structure elements in different Xen interface versions.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Wei Liu <wei.liu2@citrix.com>

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

Re: [PATCH 1/3] mini-os: support newer xen interface

[Samuel Thibault]

Wei Liu, on Tue 30 Aug 2016 14:53:10 +0100, wrote:
> On Tue, Aug 30, 2016 at 01:51:21PM +0200, Juergen Gross wrote:
> > Mini-OS is currently setting __XEN_INTERFACE_VERSION__ to a rather
> > ancient version.
> > 
> > To be able to use a more recent variant garnt_entry_t must be changed
> > to grant_entry_v1_t. In balloon.c we omit initializing elements of
> > struct xen_memory_reservation with 0 to avoid problems with different
> > named structure elements in different Xen interface versions.
> > 
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

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

[PATCH 2/3] mini-os: provide irq on/off/save/restore functions for Mini-OS apps

[Juergen Gross]

Provide non-inline variants of the local_irq_*() functions for Mini-OS
apps which should not depend on Mini-OS configuration.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/sched.c | 28 ++++++++++++++++++++++++++++
 include/x86/os.h | 13 +++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/arch/x86/sched.c b/arch/x86/sched.c
index ec13694..e7b6954 100644
--- a/arch/x86/sched.c
+++ b/arch/x86/sched.c
@@ -135,5 +135,33 @@ void run_idle_thread(void)
 #endif
 }
 
+unsigned long __local_irq_save(void)
+{
+    unsigned long flags;
 
+    local_irq_save(flags);
+    return flags;
+}
 
+void __local_irq_restore(unsigned long flags)
+{
+    local_irq_restore(flags);
+}
+
+unsigned long __local_save_flags(void)
+{
+    unsigned long flags;
+
+    local_save_flags(flags);
+    return flags;
+}
+
+void __local_irq_disable(void)
+{
+    local_irq_disable();
+}
+
+void __local_irq_enable(void)
+{
+    local_irq_enable();
+}
diff --git a/include/x86/os.h b/include/x86/os.h
index e118b91..90ab6e6 100644
--- a/include/x86/os.h
+++ b/include/x86/os.h
@@ -176,11 +176,24 @@ static inline int irqs_disabled(void)
 
 #endif
 
+#ifdef __INSIDE_MINIOS__
 #define local_irq_save(x)	__save_and_cli(x)
 #define local_irq_restore(x)	__restore_flags(x)
 #define local_save_flags(x)	__save_flags(x)
 #define local_irq_disable()	__cli()
 #define local_irq_enable()	__sti()
+#else
+unsigned long __local_irq_save(void);
+void __local_irq_restore(unsigned long flags);
+unsigned long __local_save_flags(void);
+void __local_irq_disable(void);
+void __local_irq_enable(void);
+#define local_irq_save(x)       x = __local_irq_save()
+#define local_irq_restore(x)    __local_irq_restore(x)
+#define local_save_flags(x)     x = __local_save_flags()
+#define local_irq_disable()     __local_irq_disable()
+#define local_irq_enable()      __local_irq_enable()
+#endif
 
 /* This is a barrier for the compiler only, NOT the processor! */
 #define barrier() __asm__ __volatile__("": : :"memory")
-- 
2.6.6


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

Re: [Minios-devel] [PATCH 2/3] mini-os: provide irq on/off/save/restore functions for Mini-OS apps

[Wei Liu]

On Tue, Aug 30, 2016 at 01:51:22PM +0200, Juergen Gross wrote:
> Provide non-inline variants of the local_irq_*() functions for Mini-OS
> apps which should not depend on Mini-OS configuration.
> 

I think it would be worth pointing out which apps need to access such
low level functionalities in commit message.

> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Wei Liu <wei.liu2@citrix.com>

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

Re: [Minios-devel] [PATCH 2/3] mini-os: provide irq on/off/save/restore functions for Mini-OS apps

[Juergen Gross]

On 30/08/16 15:54, Wei Liu wrote:
> On Tue, Aug 30, 2016 at 01:51:22PM +0200, Juergen Gross wrote:
>> Provide non-inline variants of the local_irq_*() functions for Mini-OS
>> apps which should not depend on Mini-OS configuration.
>>
> 
> I think it would be worth pointing out which apps need to access such
> low level functionalities in commit message.

I stumbled over it with ioemu-stubdom. Basically it could be any app
using e.g. wake_up() or wait_event() as those are macros fiddling with
irq on/off. xenevtchn_pending() is another candidate.

>> Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Thanks,

Juergen

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

Re: [Minios-devel] [PATCH 2/3] mini-os: provide irq on/off/save/restore functions for Mini-OS apps

[Samuel Thibault]

Juergen Gross, on Tue 30 Aug 2016 16:08:45 +0200, wrote:
> On 30/08/16 15:54, Wei Liu wrote:
> > On Tue, Aug 30, 2016 at 01:51:22PM +0200, Juergen Gross wrote:
> >> Provide non-inline variants of the local_irq_*() functions for Mini-OS
> >> apps which should not depend on Mini-OS configuration.
> >>
> > 
> > I think it would be worth pointing out which apps need to access such
> > low level functionalities in commit message.
> 
> I stumbled over it with ioemu-stubdom. Basically it could be any app
> using e.g. wake_up() or wait_event() as those are macros fiddling with
> irq on/off. xenevtchn_pending() is another candidate.

I was thinking that we should perhaps rather make wake_up/wait_event
non-inlined, instead of exposing irq on/off.  But then I see that
it's typically used in event handlers too (e.g. *front/back.c), and
applications may want to implement some such...

> >> Signed-off-by: Juergen Gross <jgross@suse.com>
> > 
> > Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

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

[PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Juergen Gross]

Mini-OS applications being compiled using Mini-OS headers without
being integrated in the make environment of Mini-OS need a way to set
CONFIG_* defines according to their Mini-OS configuration.

Add a new make target "config" for that purpose creating a Makefile
snipplet $(CONFIG_FILE) (defaults to ./minios-config.mk) containing
the needed information.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 .gitignore | 1 +
 Config.mk  | 4 +++-
 Makefile   | 5 +++++
 minios.mk  | 1 -
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index e55133d..d57c2bd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@ arch/x86/minios-x86*.lds
 include/list.h
 mini-os
 mini-os.gz
+minios-config.mk
diff --git a/Config.mk b/Config.mk
index aa36761..0e405bf 100644
--- a/Config.mk
+++ b/Config.mk
@@ -51,7 +51,7 @@ endif
 
 libc = $(stubdom)
 
-XEN_INTERFACE_VERSION := 0x00030205
+XEN_INTERFACE_VERSION ?= 0x00030205
 export XEN_INTERFACE_VERSION
 
 # Try to find out the architecture family TARGET_ARCH_FAM.
@@ -193,6 +193,8 @@ DEFINES-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT
 DEFINES-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 DEFINES-$(CONFIG_BALLOON) += -DCONFIG_BALLOON
 
+DEFINES-y += -D__XEN_INTERFACE_VERSION__=$(XEN_INTERFACE_VERSION)
+
 # Override settings for this OS
 PTHREAD_LIBS =
 nosharedlibs=y
diff --git a/Makefile b/Makefile
index 43dcbd6..8e8e56e 100644
--- a/Makefile
+++ b/Makefile
@@ -158,6 +158,11 @@ $(OBJ_DIR)/$(TARGET): $(OBJS) $(APP_O) arch_lib $(TARGET_ARCH_DIR)/minios-$(MINI
 	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
 	gzip -f -9 -c $@ >$@.gz
 
+.PHONY: config
+CONFIG_FILE ?= $(CURDIR)/minios-config.mk
+config:
+	echo "$(DEFINES-y)" >$(CONFIG_FILE)
+
 .PHONY: clean arch_clean
 
 arch_clean:
diff --git a/minios.mk b/minios.mk
index 9ff6bf7..ef4d2f9 100644
--- a/minios.mk
+++ b/minios.mk
@@ -10,7 +10,6 @@ DEF_CFLAGS += -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format -Wno-redu
 DEF_CFLAGS += $(call cc-option,$(CC),-fno-stack-protector,)
 DEF_CFLAGS += $(call cc-option,$(CC),-fgnu89-inline)
 DEF_CFLAGS += -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline
-DEF_CPPFLAGS += -D__XEN_INTERFACE_VERSION__=$(XEN_INTERFACE_VERSION)
 
 DEF_ASFLAGS += -D__ASSEMBLY__
 DEF_LDFLAGS +=
-- 
2.6.6


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

Re: [Minios-devel] [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Wei Liu]

On Tue, Aug 30, 2016 at 01:51:23PM +0200, Juergen Gross wrote:
> Mini-OS applications being compiled using Mini-OS headers without
> being integrated in the make environment of Mini-OS need a way to set
> CONFIG_* defines according to their Mini-OS configuration.
> 
> Add a new make target "config" for that purpose creating a Makefile
> snipplet $(CONFIG_FILE) (defaults to ./minios-config.mk) containing
> the needed information.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Wei Liu <wei.liu2@citrix.com>

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

Re: [Minios-devel] [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Samuel Thibault]

Wei Liu, on Tue 30 Aug 2016 14:57:50 +0100, wrote:
> On Tue, Aug 30, 2016 at 01:51:23PM +0200, Juergen Gross wrote:
> > Mini-OS applications being compiled using Mini-OS headers without
> > being integrated in the make environment of Mini-OS need a way to set
> > CONFIG_* defines according to their Mini-OS configuration.
> > 
> > Add a new make target "config" for that purpose creating a Makefile
> > snipplet $(CONFIG_FILE) (defaults to ./minios-config.mk) containing
> > the needed information.
> > 
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

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

Re: [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Samuel Thibault]

Hello,

Juergen Gross, on Tue 30 Aug 2016 13:51:23 +0200, wrote:
> @@ -51,7 +51,7 @@ endif
>  
>  libc = $(stubdom)
>  
> -XEN_INTERFACE_VERSION := 0x00030205
> +XEN_INTERFACE_VERSION ?= 0x00030205

Why making it overridable?  AIUI changing the version would change the
xen headers API, and thus the existing mini-os source would possibly not
even compile any more.  I also don't see the relation with the commit
log :)

Samuel

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

Re: [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Juergen Gross]

On 30/08/16 23:38, Samuel Thibault wrote:
> Hello,
> 
> Juergen Gross, on Tue 30 Aug 2016 13:51:23 +0200, wrote:
>> @@ -51,7 +51,7 @@ endif
>>  
>>  libc = $(stubdom)
>>  
>> -XEN_INTERFACE_VERSION := 0x00030205
>> +XEN_INTERFACE_VERSION ?= 0x00030205
> 
> Why making it overridable?  AIUI changing the version would change the
> xen headers API, and thus the existing mini-os source would possibly not
> even compile any more.  I also don't see the relation with the commit
> log :)

Hmm, I should have included more reasoning.

I stumbled over the problem with xenstore-stubdom: xenstore is using
__XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a
build error with Mini-OS (console_evtchn in include/console.h was
#define'd to console.domU.evtchn by include/xen/xen.h). It was pure
luck such a problem didn't occur before my recent changes.

I think it is much more reasonable to compile all parts of a stubdom
with the same Xen interface version instead of letting use the core of
Mini-OS an ancient version and the App using Mini-OS another one. So I
added XEN_INTERFACE_VERSION to be configurable.

This requires some adjustments in Mini-OS, of course. That is the
purpose of patch 1 of this series.


Juergen

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

Re: [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Samuel Thibault]

Hello,

Juergen Gross, on Thu 01 Sep 2016 08:21:33 +0200, wrote:
> I stumbled over the problem with xenstore-stubdom: xenstore is using
> __XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a
> build error with Mini-OS (console_evtchn in include/console.h was
> #define'd to console.domU.evtchn by include/xen/xen.h). It was pure
> luck such a problem didn't occur before my recent changes.
> 
> I think it is much more reasonable to compile all parts of a stubdom
> with the same Xen interface version instead of letting use the core of
> Mini-OS an ancient version and the App using Mini-OS another one.

Ok, I agree with that.

> So I added XEN_INTERFACE_VERSION to be configurable.
> This requires some adjustments in Mini-OS, of course. That is the
> purpose of patch 1 of this series.

Ok, now I better understand the issue, pros and cons, etc. It would be
better to clearly document and test it: AIUI,

- interface version compatibility is not so great: some features
are e.g. just *not* available when using interface version 0, so if
mini-os tries to use newer interfaces while stubdom asks for an older
interface version, it will fail to build, so it may need #ifs to check
for presence of the interface, and gracefully disable using the feature
instead of failing-to-build.

- mini-os happens not to be able to build with interface version 0,
basically because the current default is 0x00030205 and so nobody tests
with 0. Notably due to the console_evtchn #define, but also the use of
set_xen_guest_handle. Ideally we'd fix it, but I guess nobody will want
something older than that anyway, so we probably don't want to handle
the burden.

- to be able to let the stubdom application decide which interface
version it wants to build against, mini-os must be buildable standalone
with all versions from 0x00030205 to latest supported (which is what
patch 1 fixes). A not too bad approximation of this would be to be
able to build it with the minimum supported version and with latest
version. Perhaps we can declare that Config.mk's default interface
version is the minimum supported, so building standalone mini-os will
test that, and since as you say we already build the xenstore-stubdom
with latest version, building the xenstore-stubdom will test that.

- that way, stubdom applications can choose the level of compatibility
they wish from mini-os' minimum supported to mini-os' latest supported.

- whenever somebody would like to use an interface version which is
not supported by mini-os headers yet, we just need to update mini-os'
headers, and we have to fix the build with the minimum supported version
and with the latest supported version.


So if you agree with my reasoning, I'd say that the patch series
should document all that along the definition of XEN_INTERFACE_VERSION
in Config.mk: explaining that this default is the minimum supported
interface version, which the application can override up to the latest
supported by mini-os, and if a yet-newer interface is needed, one should
upgrade the headers, and before committing, try to build mini-os both
with the same minimum supported version for compatibility, and with the
latest version.

Samuel

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

Re: [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Juergen Gross]

On 02/09/16 03:21, Samuel Thibault wrote:
> Hello,
> 
> Juergen Gross, on Thu 01 Sep 2016 08:21:33 +0200, wrote:
>> I stumbled over the problem with xenstore-stubdom: xenstore is using
>> __XEN_LATEST_INTERFACE_VERSION__ when being compiled. This produced a
>> build error with Mini-OS (console_evtchn in include/console.h was
>> #define'd to console.domU.evtchn by include/xen/xen.h). It was pure
>> luck such a problem didn't occur before my recent changes.
>>
>> I think it is much more reasonable to compile all parts of a stubdom
>> with the same Xen interface version instead of letting use the core of
>> Mini-OS an ancient version and the App using Mini-OS another one.
> 
> Ok, I agree with that.

Very good.

>> So I added XEN_INTERFACE_VERSION to be configurable.
>> This requires some adjustments in Mini-OS, of course. That is the
>> purpose of patch 1 of this series.
> 
> Ok, now I better understand the issue, pros and cons, etc. It would be
> better to clearly document and test it: AIUI,
> 
> - interface version compatibility is not so great: some features
> are e.g. just *not* available when using interface version 0, so if
> mini-os tries to use newer interfaces while stubdom asks for an older
> interface version, it will fail to build, so it may need #ifs to check
> for presence of the interface, and gracefully disable using the feature
> instead of failing-to-build.
> 
> - mini-os happens not to be able to build with interface version 0,
> basically because the current default is 0x00030205 and so nobody tests
> with 0. Notably due to the console_evtchn #define, but also the use of
> set_xen_guest_handle. Ideally we'd fix it, but I guess nobody will want
> something older than that anyway, so we probably don't want to handle
> the burden.

I think 0x00030205 should be the minimum version Mini-OS has to support.

> - to be able to let the stubdom application decide which interface
> version it wants to build against, mini-os must be buildable standalone
> with all versions from 0x00030205 to latest supported (which is what
> patch 1 fixes). A not too bad approximation of this would be to be
> able to build it with the minimum supported version and with latest
> version. Perhaps we can declare that Config.mk's default interface
> version is the minimum supported, so building standalone mini-os will
> test that, and since as you say we already build the xenstore-stubdom
> with latest version, building the xenstore-stubdom will test that.

I think I'll add a new make target "test" which will test different
build configurations (PARAVIRT y/n, BALLOON y/n, 32/64 bit, Xen
interface versions, all/no frontends). This can be easily added to
OSStest.

> - that way, stubdom applications can choose the level of compatibility
> they wish from mini-os' minimum supported to mini-os' latest supported.
> 
> - whenever somebody would like to use an interface version which is
> not supported by mini-os headers yet, we just need to update mini-os'
> headers, and we have to fix the build with the minimum supported version
> and with the latest supported version.

Right.

> So if you agree with my reasoning, I'd say that the patch series
> should document all that along the definition of XEN_INTERFACE_VERSION
> in Config.mk: explaining that this default is the minimum supported
> interface version, which the application can override up to the latest
> supported by mini-os, and if a yet-newer interface is needed, one should
> upgrade the headers, and before committing, try to build mini-os both
> with the same minimum supported version for compatibility, and with the
> latest version.

Okay, I'll update the patch description and add some README contents.


Juergen

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

Re: [PATCH 3/3] mini-os: support "make config" for out-of-tree users

[Samuel Thibault]

Juergen Gross, on Fri 02 Sep 2016 07:42:36 +0200, wrote:
> I think I'll add a new make target "test" which will test different
> build configurations (PARAVIRT y/n, BALLOON y/n, 32/64 bit, Xen
> interface versions, all/no frontends). This can be easily added to
> OSStest.

Good, thanks.

Samuel

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

Re: [Minios-devel] [PATCH 0/3] repair stubdoms

[Wei Liu]

On Tue, Aug 30, 2016 at 01:51:20PM +0200, Juergen Gross wrote:
> Adding support for HVMlite Mini-OS broke some stubdom functionality
> as various parts of the stubdom code was built without specifying
> any Mini-OS configuration defines. This led to inconsistencies when
> those parts included Mini-OS headers now depending on the config of
> Mini9-OS. Some of those cases did work just by pure luck.
> 
> Juergen Gross (3):
>   mini-os: support newer xen interface
>   mini-os: provide irq on/off/save/restore functions for Mini-OS apps
>   mini-os: support "make config" for out-of-tree users
> 

Pushed.

I will update Xen's Config.mk soon-ish.

Wei.

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