[Xen-devel] [PATCH v06 27/36] uapi xen/gntdev.h: include xen/privcmd.h and define grant_ref_t

2017-08-06 Thread Mikko Rapeli
Both are needed to compile  in userspace. Fixes these
userspace compile errors:

xen/gntdev.h:151:4: error: unknown type name ‘grant_ref_t’
grant_ref_t ref;
^
xen/gntdev.h:153:4: error: unknown type name ‘domid_t’
domid_t domid;
^

Signed-off-by: Mikko Rapeli 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-de...@lists.xenproject.org
---
 include/uapi/xen/gntdev.h   | 6 ++
 include/xen/interface/grant_table.h | 6 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index d0661977667e..f208706b07c9 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -34,6 +34,12 @@
 #define __LINUX_PUBLIC_GNTDEV_H__
 
 #include 
+#include 
+
+/*
+ * Reference to a grant entry in a specified domain's grant table.
+ */
+typedef __u32 grant_ref_t;
 
 struct ioctl_gntdev_grant_ref {
/* The domain ID of the grant to be mapped. */
diff --git a/include/xen/interface/grant_table.h 
b/include/xen/interface/grant_table.h
index 7fb7112d667c..29b3724aec2c 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -29,6 +29,7 @@
 #define __XEN_PUBLIC_GRANT_TABLE_H__
 
 #include 
+#include  /* for grant_ref_t */
 
 /***
  * GRANT TABLE REPRESENTATION
@@ -85,11 +86,6 @@
  */
 
 /*
- * Reference to a grant entry in a specified domain's grant table.
- */
-typedef uint32_t grant_ref_t;
-
-/*
  * A grant table comprises a packed array of grant entries in one or more
  * page frames shared between Xen and a guest.
  * [XEN]: This field is written by Xen and read by the sharing guest.
-- 
2.13.3


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


[Xen-devel] [PATCH v06 28/36] uapi xen/evtchn.h: include xen/privcmd.h

2017-08-06 Thread Mikko Rapeli
It has definition of domid_t. Fixes userspace compiler error when
xen/privcmd.h is compiled alone:

xen/evtchn.h:100:2: error: unknown type name ‘domid_t’
  domid_t domid;
  ^~~

Signed-off-by: Mikko Rapeli 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-de...@lists.xenproject.org
---
 include/uapi/xen/evtchn.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/xen/evtchn.h b/include/uapi/xen/evtchn.h
index cb4aa4bb905e..81df4b378938 100644
--- a/include/uapi/xen/evtchn.h
+++ b/include/uapi/xen/evtchn.h
@@ -33,6 +33,8 @@
 #ifndef __LINUX_PUBLIC_EVTCHN_H__
 #define __LINUX_PUBLIC_EVTCHN_H__
 
+#include 
+
 /*
  * Bind a fresh port to VIRQ @virq.
  * Return allocated port.
-- 
2.13.3


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


[Xen-devel] [PATCH v06 26/36] uapi xen/privcmd.h: fix compilation in userspace

2017-08-06 Thread Mikko Rapeli
xen/interface/xen.h is not exported from kernel headers so remove the
dependency and provide needed defines for domid_t and xen_pfn_t if they
are not already defined by some other e.g. Xen specific headers.

Suggested by Andrew Cooper  on lkml message
<5569f9c9.8000...@citrix.com>.

The ifdef for ARM is ugly but did not find better solutions for it.

Then use __kernel_size_t instead of size_t since that is available in
uapi headers in user space.

Fixes userspace compilation errors:

xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory
xen/privcmd.h:92:2: error: unknown type name ‘size_t’

Signed-off-by: Mikko Rapeli 
Cc: Paul Durrant 
Cc: David Vrabel 
Cc: Stefano Stabellini 
Cc: Russell King 
---
 include/uapi/xen/privcmd.h | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
index 63ee95c9dabb..565f3003741d 100644
--- a/include/uapi/xen/privcmd.h
+++ b/include/uapi/xen/privcmd.h
@@ -35,7 +35,17 @@
 
 #include 
 #include 
-#include 
+
+/* Defined by include/xen/interface/xen.h, but it is not part of Linux uapi */
+#ifndef __XEN_PUBLIC_XEN_H__
+typedef __u16 domid_t;
+
+#if (defined __ARMEL__ || defined __ARMEB__)
+typedef __u64 xen_pfn_t;
+#else
+typedef unsigned long xen_pfn_t;
+#endif /* (defined __ARMEL__ || defined __ARMEB__) */
+#endif /* __XEN_PUBLIC_XEN_H__ */
 
 struct privcmd_hypercall {
__u64 op;
@@ -79,7 +89,7 @@ struct privcmd_mmapbatch_v2 {
 
 struct privcmd_dm_op_buf {
void __user *uptr;
-   size_t size;
+   __kernel_size_t size;
 };
 
 struct privcmd_dm_op {
-- 
2.13.3


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


Re: [Xen-devel] [PATCH v05 54/72] include/uapi/xen/privcmd.h: fix compilation in userspace

2016-08-23 Thread Mikko Rapeli
On Tue, Aug 23, 2016 at 11:13:52AM -0700, Stefano Stabellini wrote:
> On Tue, 23 Aug 2016, Russell King - ARM Linux wrote:
> > On Mon, Aug 22, 2016 at 08:33:11PM +0200, Mikko Rapeli wrote:
> > > xen/interface/xen.h is not exported from kernel headers so remove the
> > > dependency and provide needed defines for domid_t and xen_pfn_t if they
> > > are not already defined by some other e.g. Xen specific headers.
> > 
> > I'm confused.  How did we end up with a 64-bit PFN number on ARM?  It's
> > insane - especially as the kernel uses "unsigned long" almost everywhere
> > for PFNs - we can't have physical addresses more than 44 bits (32 bit
> > pfn + 4k page size).
> 
> That's because xen_pfn_t is the type used to store pfns in structures
> passed to Xen via hypercalls. The Xen hypercall ABI is shared between
> ARM and ARM64. On x86_32 and x86_64 we have different sizes for pfn
> types in the hypercall ABI and it caused quite a bit of trouble in the
> past as it is possible to run 32bit domains on a 64bit hypervisor.
> Having a common type for pfns on ARM and ARM64 helped a lot in that
> respect.
> 
> 
> > > Suggested by Andrew Cooper  on lkml message
> > > <5569f9c9.8000...@citrix.com>.
> > > 
> > > The ifdef for ARM is ugly but did not find better solutions for it.
> > 
> > #ifdef __arm__
> > 
> > maybe?  Even if not, the unsightly parens are not necessary.
> 
> Yes, I think it should be:
> 
> #if defined(__arm__) || defined(__aarch64__)

Thanks, I will send a new version with this change.
 
> > diff --git a/arch/arm/include/asm/xen/interface.h 
> > b/arch/arm/include/asm/xen/interface.h
> > index 75d5968..6898ee1 100644
> > --- a/arch/arm/include/asm/xen/interface.h
> > +++ b/arch/arm/include/asm/xen/interface.h
> > @@ -38,7 +38,7 @@
> >   * fine since it simply wouldn't be able to create any sure pfns in
> >   * the first place.
> >   */
> > -typedef uint64_t xen_pfn_t;
> > +typedef __u64 xen_pfn_t;
> >  #define PRI_xen_pfn "llx"
> >  typedef uint64_t xen_ulong_t;
> >  #define PRI_xen_ulong "llx"
> 
> Why this change?

I will double check but I think the other fix exposed then the common
" definitions not available in userspace " and this
was needed to please the compiler. If so, I'll add this to commit message.

If you would prefer to include libc's  in userspace, well, join the
club. drm and fuse maintainers want the same but my patches with those fixes got
rejected in the past. Example: https://lkml.org/lkml/2015/6/1/160

-Mikko


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


[Xen-devel] [PATCH v05 56/72] include/uapi/xen/evtchn.h: include xen/privcmd.h

2016-08-22 Thread Mikko Rapeli
It has definition of domid_t. Fixes userspace compiler error when
xen/privcmd.h is compiled alone:

xen/evtchn.h:100:2: error: unknown type name ‘domid_t’
  domid_t domid;
  ^~~

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/evtchn.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/xen/evtchn.h b/include/uapi/xen/evtchn.h
index cb4aa4b..81df4b3 100644
--- a/include/uapi/xen/evtchn.h
+++ b/include/uapi/xen/evtchn.h
@@ -33,6 +33,8 @@
 #ifndef __LINUX_PUBLIC_EVTCHN_H__
 #define __LINUX_PUBLIC_EVTCHN_H__
 
+#include 
+
 /*
  * Bind a fresh port to VIRQ @virq.
  * Return allocated port.
-- 
2.8.1


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


[Xen-devel] [PATCH v05 54/72] include/uapi/xen/privcmd.h: fix compilation in userspace

2016-08-22 Thread Mikko Rapeli
xen/interface/xen.h is not exported from kernel headers so remove the
dependency and provide needed defines for domid_t and xen_pfn_t if they
are not already defined by some other e.g. Xen specific headers.

Suggested by Andrew Cooper  on lkml message
<5569f9c9.8000...@citrix.com>.

The ifdef for ARM is ugly but did not find better solutions for it.

Fixes userspace compilation error:

xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory

Signed-off-by: Mikko Rapeli 
Cc: David Vrabel 
---
 arch/arm/include/asm/xen/interface.h |  2 +-
 include/uapi/xen/privcmd.h   | 12 +++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 75d5968..6898ee1 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -38,7 +38,7 @@
  * fine since it simply wouldn't be able to create any sure pfns in
  * the first place.
  */
-typedef uint64_t xen_pfn_t;
+typedef __u64 xen_pfn_t;
 #define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
 #define PRI_xen_ulong "llx"
diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
index 7ddeeda..16c11f9 100644
--- a/include/uapi/xen/privcmd.h
+++ b/include/uapi/xen/privcmd.h
@@ -35,7 +35,17 @@
 
 #include 
 #include 
-#include 
+
+/* Defined by include/xen/interface/xen.h, but it is not part of Linux uapi */
+#ifndef __XEN_PUBLIC_XEN_H__
+typedef __u16 domid_t;
+
+#if (defined __ARMEL__ || defined __ARMEB__)
+typedef __u64 xen_pfn_t;
+#else
+typedef unsigned long xen_pfn_t;
+#endif /* (defined __ARMEL__ || defined __ARMEB__) */
+#endif /* __XEN_PUBLIC_XEN_H__ */
 
 struct privcmd_hypercall {
__u64 op;
-- 
2.8.1


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


[Xen-devel] [PATCH v05 55/72] include/uapi/xen/gntdev.h: include xen/privcmd.h and define grant_ref_t

2016-08-22 Thread Mikko Rapeli
Both are needed to compile  wihtout compiler warnings
in userspace. Fixes these userspace compile errors:

xen/gntdev.h:151:4: error: unknown type name ‘grant_ref_t’
grant_ref_t ref;
^
xen/gntdev.h:153:4: error: unknown type name ‘domid_t’
domid_t domid;
^

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntdev.h   | 6 ++
 include/xen/interface/grant_table.h | 6 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index d066197..f208706 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -34,6 +34,12 @@
 #define __LINUX_PUBLIC_GNTDEV_H__
 
 #include 
+#include 
+
+/*
+ * Reference to a grant entry in a specified domain's grant table.
+ */
+typedef __u32 grant_ref_t;
 
 struct ioctl_gntdev_grant_ref {
/* The domain ID of the grant to be mapped. */
diff --git a/include/xen/interface/grant_table.h 
b/include/xen/interface/grant_table.h
index 56806bc..7e064d6 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -29,6 +29,7 @@
 #define __XEN_PUBLIC_GRANT_TABLE_H__
 
 #include 
+#include  /* for grant_ref_t */
 
 /***
  * GRANT TABLE REPRESENTATION
@@ -85,11 +86,6 @@
  */
 
 /*
- * Reference to a grant entry in a specified domain's grant table.
- */
-typedef uint32_t grant_ref_t;
-
-/*
  * A grant table comprises a packed array of grant entries in one or more
  * page frames shared between Xen and a guest.
  * [XEN]: This field is written by Xen and read by the sharing guest.
-- 
2.8.1


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


Re: [Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

2015-10-15 Thread Mikko Rapeli
On Thu, Oct 15, 2015 at 12:24:39PM +0100, David Vrabel wrote:
> On 15/10/15 12:18, Mikko Rapeli wrote:
> > On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote:
> >> On 15/10/15 06:56, Mikko Rapeli wrote:
> >>> xen/interface/xen.h is not exported from kernel headers so remove the
> >>> dependency and provide needed defines for domid_t and xen_pfn_t if they
> >>> are not already defined by some other e.g. Xen specific headers.
> >>>
> >>> Suggested by Andrew Cooper  on lkml message
> >>> <5569f9c9.8000...@citrix.com>.
> >>>
> >>> The ifdef for ARM is ugly but did not find better solutions for it.
> >>>
> >>> Fixes userspace compilation error:
> >>>
> >>> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or 
> >>> directory
> >> [...]
> >>> --- a/include/uapi/xen/privcmd.h
> >>> +++ b/include/uapi/xen/privcmd.h
> >>> @@ -35,7 +35,19 @@
> >>>  
> >>>  #include 
> >>>  #include 
> >>> -#include 
> >>> +
> >>> +/* Might be defined by Xen specific headers, but if not */
> >>> +#ifndef domid_t
> >>> +typedef __u16 domid_t;
> >>> +#endif /* domid_t */
> >>
> >> As the kbuild bot points out, this does not work since the existence of
> >> a typedef cannot be checked with #ifdef.
> > 
> > Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes:
> > http://www.spinics.net/lists/linux-api/msg11048.html
> > 
> >> I'm not really sure what problem you're trying to solve.  A user space
> >> program making use of this interface gets the domid_t and xen_pfn_t etc
> >> typedefs from the headers provided as part of the libxenctrl library.
> > 
> > I'm trying to make sure that kernel headers in userspace compile with 
> > minimal
> > dependencies which are gcc and libc.
> > 
> > For me it is clear by now that many Linux API's and ABI's like Xen parts do
> > not live in the uapi header files and instead there's a separate userspace
> > library with needed headers and defines which have embedded copies of
> > the needed API and ABI definitions, like header files.
> > 
> > So how could this file be changed so that it compiles in userspace without
> > definitions from libxenctrl?
> 
> I don't think anything needs to be changed.
> 
> Instead I would make your compilation check of this header dependent on
> the existence of the xen/interface/xen.h header. Or you may exclude the
> check of this header entirely.

There are not many headers in uapi which require additional userspace
headers to compile (I'm not saying that uapi headers represent the full
API's/ABI's, it's clear they don't). If there are ~700 headers and just a
single one needs an exception and additional dependencies, I would try to
make it work without the dependency. I just need some advice and guidance
from maintainers how to do this.

Or we should start tracking these userspace library dependencies too,
at least at linux-headers package levels in distributions. This might
be a good idea anyway, but then we might as well move headers like this
directly to the userspace library and out of include/uapi.

Both would solve the non-compiling uapi header problem.

> > I guess I could copy the needed definitions for domid_t and xen_pfn_t from
> > xen/interface/xen.h of libxenctrl. That I should have done to begin with
> > instead of trying to hack something on my own.
> 
> I do not want definitions duplicated/copied from the hypervisor ABI
> headers.  This causes problems when support for new architectures is
> added (for example).

Understood.

-Mikko

> David

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


Re: [Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

2015-10-15 Thread Mikko Rapeli
On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote:
> On 15/10/15 06:56, Mikko Rapeli wrote:
> > xen/interface/xen.h is not exported from kernel headers so remove the
> > dependency and provide needed defines for domid_t and xen_pfn_t if they
> > are not already defined by some other e.g. Xen specific headers.
> > 
> > Suggested by Andrew Cooper  on lkml message
> > <5569f9c9.8000...@citrix.com>.
> >
> > The ifdef for ARM is ugly but did not find better solutions for it.
> > 
> > Fixes userspace compilation error:
> > 
> > xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or 
> > directory
> [...]
> > --- a/include/uapi/xen/privcmd.h
> > +++ b/include/uapi/xen/privcmd.h
> > @@ -35,7 +35,19 @@
> >  
> >  #include 
> >  #include 
> > -#include 
> > +
> > +/* Might be defined by Xen specific headers, but if not */
> > +#ifndef domid_t
> > +typedef __u16 domid_t;
> > +#endif /* domid_t */
> 
> As the kbuild bot points out, this does not work since the existence of
> a typedef cannot be checked with #ifdef.

Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes:
http://www.spinics.net/lists/linux-api/msg11048.html

> I'm not really sure what problem you're trying to solve.  A user space
> program making use of this interface gets the domid_t and xen_pfn_t etc
> typedefs from the headers provided as part of the libxenctrl library.

I'm trying to make sure that kernel headers in userspace compile with minimal
dependencies which are gcc and libc.

For me it is clear by now that many Linux API's and ABI's like Xen parts do
not live in the uapi header files and instead there's a separate userspace
library with needed headers and defines which have embedded copies of
the needed API and ABI definitions, like header files.

So how could this file be changed so that it compiles in userspace without
definitions from libxenctrl?

I guess I could copy the needed definitions for domid_t and xen_pfn_t from
xen/interface/xen.h of libxenctrl. That I should have done to begin with
instead of trying to hack something on my own.

-Mikko

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


[Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace

2015-10-14 Thread Mikko Rapeli
xen/interface/xen.h is not exported from kernel headers so remove the
dependency and provide needed defines for domid_t and xen_pfn_t if they
are not already defined by some other e.g. Xen specific headers.

Suggested by Andrew Cooper  on lkml message
<5569f9c9.8000...@citrix.com>.

The ifdef for ARM is ugly but did not find better solutions for it.

Fixes userspace compilation error:

xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory

Signed-off-by: Mikko Rapeli 
---
 arch/arm/include/asm/xen/interface.h |  2 +-
 include/uapi/xen/privcmd.h   | 14 +-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 5006600..68a9d99 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -36,7 +36,7 @@
  * fine since it simply wouldn't be able to create any sure pfns in
  * the first place.
  */
-typedef uint64_t xen_pfn_t;
+typedef __u64 xen_pfn_t;
 #define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
 #define PRI_xen_ulong "llx"
diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
index 7ddeeda..95b73a9 100644
--- a/include/uapi/xen/privcmd.h
+++ b/include/uapi/xen/privcmd.h
@@ -35,7 +35,19 @@
 
 #include 
 #include 
-#include 
+
+/* Might be defined by Xen specific headers, but if not */
+#ifndef domid_t
+typedef __u16 domid_t;
+#endif /* domid_t */
+
+#ifndef xen_pfn_t
+#if (defined __ARMEL__ || defined __ARMEB__)
+typedef __u64 xen_pfn_t;
+#else
+typedef unsigned long xen_pfn_t;
+#endif /* (defined __ARMEL__ || defined __ARMEB__) */
+#endif /* xen_pfn_t */
 
 struct privcmd_hypercall {
__u64 op;
-- 
2.5.0


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


[Xen-devel] [PATCH v4 29/79] gntalloc.h: use __u16, __u32 and __u64 from linux/types.h

2015-10-14 Thread Mikko Rapeli
Fixes userspace compilation errors like:

xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntalloc.h | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/xen/gntalloc.h
index 76bd580..48d2790 100644
--- a/include/uapi/xen/gntalloc.h
+++ b/include/uapi/xen/gntalloc.h
@@ -11,6 +11,8 @@
 #ifndef __LINUX_PUBLIC_GNTALLOC_H__
 #define __LINUX_PUBLIC_GNTALLOC_H__
 
+#include 
+
 /*
  * Allocates a new page and creates a new grant reference.
  */
@@ -19,17 +21,17 @@ _IOC(_IOC_NONE, 'G', 5, sizeof(struct 
ioctl_gntalloc_alloc_gref))
 struct ioctl_gntalloc_alloc_gref {
/* IN parameters */
/* The ID of the domain to be given access to the grants. */
-   uint16_t domid;
+   __u16 domid;
/* Flags for this mapping */
-   uint16_t flags;
+   __u16 flags;
/* Number of pages to map */
-   uint32_t count;
+   __u32 count;
/* OUT parameters */
/* The offset to be used on a subsequent call to mmap(). */
-   uint64_t index;
+   __u64 index;
/* The grant references of the newly created grant, one per page */
/* Variable size, depending on count */
-   uint32_t gref_ids[1];
+   __u32 gref_ids[1];
 };
 
 #define GNTALLOC_FLAG_WRITABLE 1
@@ -43,9 +45,9 @@ _IOC(_IOC_NONE, 'G', 6, sizeof(struct 
ioctl_gntalloc_dealloc_gref))
 struct ioctl_gntalloc_dealloc_gref {
/* IN parameters */
/* The offset returned in the map operation */
-   uint64_t index;
+   __u64 index;
/* Number of references to unmap */
-   uint32_t count;
+   __u32 count;
 };
 
 /*
@@ -67,11 +69,11 @@ struct ioctl_gntalloc_unmap_notify {
 * be cleared. Otherwise, it can be any byte in the page whose
 * notification we are adjusting.
 */
-   uint64_t index;
+   __u64 index;
/* Action(s) to take on unmap */
-   uint32_t action;
+   __u32 action;
/* Event channel to notify */
-   uint32_t event_channel_port;
+   __u32 event_channel_port;
 };
 
 /* Clear (set to zero) the byte specified by index */
-- 
2.5.0


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


[Xen-devel] [PATCH v4 30/79] gntdev.h: use __u32 and __u64 from linux/types.h

2015-10-14 Thread Mikko Rapeli
Fixes userspace compilation errors like:

xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntdev.h | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index 5304bd3..aa7610a 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -33,11 +33,13 @@
 #ifndef __LINUX_PUBLIC_GNTDEV_H__
 #define __LINUX_PUBLIC_GNTDEV_H__
 
+#include 
+
 struct ioctl_gntdev_grant_ref {
/* The domain ID of the grant to be mapped. */
-   uint32_t domid;
+   __u32 domid;
/* The grant reference of the grant to be mapped. */
-   uint32_t ref;
+   __u32 ref;
 };
 
 /*
@@ -50,11 +52,11 @@ _IOC(_IOC_NONE, 'G', 0, sizeof(struct 
ioctl_gntdev_map_grant_ref))
 struct ioctl_gntdev_map_grant_ref {
/* IN parameters */
/* The number of grants to be mapped. */
-   uint32_t count;
-   uint32_t pad;
+   __u32 count;
+   __u32 pad;
/* OUT parameters */
/* The offset to be used on a subsequent call to mmap(). */
-   uint64_t index;
+   __u64 index;
/* Variable IN parameter. */
/* Array of grant references, of size @count. */
struct ioctl_gntdev_grant_ref refs[1];
@@ -70,10 +72,10 @@ _IOC(_IOC_NONE, 'G', 1, sizeof(struct 
ioctl_gntdev_unmap_grant_ref))
 struct ioctl_gntdev_unmap_grant_ref {
/* IN parameters */
/* The offset was returned by the corresponding map operation. */
-   uint64_t index;
+   __u64 index;
/* The number of pages to be unmapped. */
-   uint32_t count;
-   uint32_t pad;
+   __u32 count;
+   __u32 pad;
 };
 
 /*
@@ -93,13 +95,13 @@ _IOC(_IOC_NONE, 'G', 2, sizeof(struct 
ioctl_gntdev_get_offset_for_vaddr))
 struct ioctl_gntdev_get_offset_for_vaddr {
/* IN parameters */
/* The virtual address of the first mapped page in a range. */
-   uint64_t vaddr;
+   __u64 vaddr;
/* OUT parameters */
/* The offset that was used in the initial mmap() operation. */
-   uint64_t offset;
+   __u64 offset;
/* The number of pages mapped in the VM area that begins at @vaddr. */
-   uint32_t count;
-   uint32_t pad;
+   __u32 count;
+   __u32 pad;
 };
 
 /*
@@ -113,7 +115,7 @@ _IOC(_IOC_NONE, 'G', 3, sizeof(struct 
ioctl_gntdev_set_max_grants))
 struct ioctl_gntdev_set_max_grants {
/* IN parameter */
/* The maximum number of grants that may be mapped at once. */
-   uint32_t count;
+   __u32 count;
 };
 
 /*
@@ -135,11 +137,11 @@ struct ioctl_gntdev_unmap_notify {
 * be cleared. Otherwise, it can be any byte in the page whose
 * notification we are adjusting.
 */
-   uint64_t index;
+   __u64 index;
/* Action(s) to take on unmap */
-   uint32_t action;
+   __u32 action;
/* Event channel to notify */
-   uint32_t event_channel_port;
+   __u32 event_channel_port;
 };
 
 /* Clear (set to zero) the byte specified by index */
-- 
2.5.0


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


Re: [Xen-devel] [PATCH 95/98] HACK: fix include/uapi/xen/privcmd.h compilation in userspace

2015-09-10 Thread Mikko Rapeli
On Sat, May 30, 2015 at 06:56:25PM +0100, Andrew Cooper wrote:
> On 30/05/15 16:39, Mikko Rapeli wrote:
> > privcmd.h depends on xen/interface/xen.h which is now exported to userspace.
> > xen/interface/xen.h then depends on asm/xen/interface.h which is now
> > exported to userspace together with its dependencies asm/xen/interface_32.h,
> > asm/xen/interface_64.h and asm/pvclock-abi.h on x86 architecture.
> >
> > Then all of these headers were fixed to use __u8 etc from linux/types.h
> > instead of custom types.
> >
> > Then define uint64_t and uint32_t if needed.
> >
> > After all these changes these header files now compile in userspace too
> > on x86.
> >
> > HACK since I have no idea if this is correct way to fix this.
> >
> > Signed-off-by: Mikko Rapeli 
> 
> Historical reasons expect xen/interface/xen.h to be a verbatim copy of
> the master version kept in the Xen repository.
> 
> The only things privcmd.h need from interface/xen.h are domid_t
> (uint16_t), and xen_pfn_t (unsigned long, or uint64_t in arm32 iirc),
> while the majority of the rest absolutely shouldn't be in Linux’s uapi.
> 
> It would probably be best to provide just these two types and nuke the
> "#include ".  Any user of privcmd needs to include
> the Xen interface themselves anyway, and will have a different copy
> which includes the toolstack half of the interface (missing from the
> kernel copy) which is the useful set of definitions for driving the
> privcmd ioctl()s.

Thanks! Doing this in the next series of the patches.

-Mikko

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


[Xen-devel] [PATCH 95/98] HACK: fix include/uapi/xen/privcmd.h compilation in userspace

2015-05-30 Thread Mikko Rapeli
privcmd.h depends on xen/interface/xen.h which is now exported to userspace.
xen/interface/xen.h then depends on asm/xen/interface.h which is now
exported to userspace together with its dependencies asm/xen/interface_32.h,
asm/xen/interface_64.h and asm/pvclock-abi.h on x86 architecture.

Then all of these headers were fixed to use __u8 etc from linux/types.h
instead of custom types.

Then define uint64_t and uint32_t if needed.

After all these changes these header files now compile in userspace too
on x86.

HACK since I have no idea if this is correct way to fix this.

Signed-off-by: Mikko Rapeli 
---
 arch/x86/include/asm/pvclock-abi.h   |  41 +-
 arch/x86/include/asm/xen/interface.h | 185 +--
 arch/x86/include/asm/xen/interface_32.h  |  98 +---
 arch/x86/include/asm/xen/interface_64.h  | 144 +
 arch/x86/include/uapi/asm/Kbuild |   2 +
 arch/x86/include/uapi/asm/pvclock-abi.h  |  47 ++
 arch/x86/include/uapi/asm/xen/Kbuild |   5 +
 arch/x86/include/uapi/asm/xen/interface.h| 198 +++
 arch/x86/include/uapi/asm/xen/interface_32.h | 103 
 arch/x86/include/uapi/asm/xen/interface_64.h | 150 ++
 include/uapi/xen/Kbuild  |   1 +
 include/uapi/xen/interface/Kbuild|   2 +
 include/uapi/xen/interface/xen.h | 759 +++
 include/xen/interface/xen.h  | 754 +-
 14 files changed, 1272 insertions(+), 1217 deletions(-)
 create mode 100644 arch/x86/include/uapi/asm/pvclock-abi.h
 create mode 100644 arch/x86/include/uapi/asm/xen/Kbuild
 create mode 100644 arch/x86/include/uapi/asm/xen/interface.h
 create mode 100644 arch/x86/include/uapi/asm/xen/interface_32.h
 create mode 100644 arch/x86/include/uapi/asm/xen/interface_64.h
 create mode 100644 include/uapi/xen/interface/Kbuild
 create mode 100644 include/uapi/xen/interface/xen.h

diff --git a/arch/x86/include/asm/pvclock-abi.h 
b/arch/x86/include/asm/pvclock-abi.h
index 6167fd7..20df65d 100644
--- a/arch/x86/include/asm/pvclock-abi.h
+++ b/arch/x86/include/asm/pvclock-abi.h
@@ -1,45 +1,6 @@
 #ifndef _ASM_X86_PVCLOCK_ABI_H
 #define _ASM_X86_PVCLOCK_ABI_H
-#ifndef __ASSEMBLY__
 
-/*
- * These structs MUST NOT be changed.
- * They are the ABI between hypervisor and guest OS.
- * Both Xen and KVM are using this.
- *
- * pvclock_vcpu_time_info holds the system time and the tsc timestamp
- * of the last update. So the guest can use the tsc delta to get a
- * more precise system time.  There is one per virtual cpu.
- *
- * pvclock_wall_clock references the point in time when the system
- * time was zero (usually boot time), thus the guest calculates the
- * current wall clock by adding the system time.
- *
- * Protocol for the "version" fields is: hypervisor raises it (making
- * it uneven) before it starts updating the fields and raises it again
- * (making it even) when it is done.  Thus the guest can make sure the
- * time values it got are consistent by checking the version before
- * and after reading them.
- */
+#include 
 
-struct pvclock_vcpu_time_info {
-   u32   version;
-   u32   pad0;
-   u64   tsc_timestamp;
-   u64   system_time;
-   u32   tsc_to_system_mul;
-   s8tsc_shift;
-   u8flags;
-   u8pad[2];
-} __attribute__((__packed__)); /* 32 bytes */
-
-struct pvclock_wall_clock {
-   u32   version;
-   u32   sec;
-   u32   nsec;
-} __attribute__((__packed__));
-
-#define PVCLOCK_TSC_STABLE_BIT (1 << 0)
-#define PVCLOCK_GUEST_STOPPED  (1 << 1)
-#endif /* __ASSEMBLY__ */
 #endif /* _ASM_X86_PVCLOCK_ABI_H */
diff --git a/arch/x86/include/asm/xen/interface.h 
b/arch/x86/include/asm/xen/interface.h
index 3400dba..a866bdf 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -1,189 +1,6 @@
-/**
- * arch-x86_32.h
- *
- * Guest OS interface to x86 Xen.
- *
- * Copyright (c) 2004, K A Fraser
- */
-
 #ifndef _ASM_X86_XEN_INTERFACE_H
 #define _ASM_X86_XEN_INTERFACE_H
 
-#ifdef __XEN__
-#define __DEFINE_GUEST_HANDLE(name, type) \
-typedef struct { type *p; } __guest_handle_ ## name
-#else
-#define __DEFINE_GUEST_HANDLE(name, type) \
-typedef type * __guest_handle_ ## name
-#endif
-
-#define DEFINE_GUEST_HANDLE_STRUCT(name) \
-   __DEFINE_GUEST_HANDLE(name, struct name)
-#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
-#define GUEST_HANDLE(name)__guest_handle_ ## name
-
-#ifdef __XEN__
-#if defined(__i386__)
-#define set_xen_guest_handle(hnd, val) \
-   do {\
-   if (sizeof(hnd) == 8)   \
-   *(uint64_t *)&(hnd) = 0;\
-   (hnd).p = val;  \
-   } while (0)
-#elif defined(__x86_64__)
-#define set_xen_guest_han

[Xen-devel] [PATCH 31/98] gntalloc.h: use __u16, __u32 and __u64 from linux/types.h

2015-05-30 Thread Mikko Rapeli
Fixes userspace compilation errors like:

xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntalloc.h | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/xen/gntalloc.h
index 76bd580..48d2790 100644
--- a/include/uapi/xen/gntalloc.h
+++ b/include/uapi/xen/gntalloc.h
@@ -11,6 +11,8 @@
 #ifndef __LINUX_PUBLIC_GNTALLOC_H__
 #define __LINUX_PUBLIC_GNTALLOC_H__
 
+#include 
+
 /*
  * Allocates a new page and creates a new grant reference.
  */
@@ -19,17 +21,17 @@ _IOC(_IOC_NONE, 'G', 5, sizeof(struct 
ioctl_gntalloc_alloc_gref))
 struct ioctl_gntalloc_alloc_gref {
/* IN parameters */
/* The ID of the domain to be given access to the grants. */
-   uint16_t domid;
+   __u16 domid;
/* Flags for this mapping */
-   uint16_t flags;
+   __u16 flags;
/* Number of pages to map */
-   uint32_t count;
+   __u32 count;
/* OUT parameters */
/* The offset to be used on a subsequent call to mmap(). */
-   uint64_t index;
+   __u64 index;
/* The grant references of the newly created grant, one per page */
/* Variable size, depending on count */
-   uint32_t gref_ids[1];
+   __u32 gref_ids[1];
 };
 
 #define GNTALLOC_FLAG_WRITABLE 1
@@ -43,9 +45,9 @@ _IOC(_IOC_NONE, 'G', 6, sizeof(struct 
ioctl_gntalloc_dealloc_gref))
 struct ioctl_gntalloc_dealloc_gref {
/* IN parameters */
/* The offset returned in the map operation */
-   uint64_t index;
+   __u64 index;
/* Number of references to unmap */
-   uint32_t count;
+   __u32 count;
 };
 
 /*
@@ -67,11 +69,11 @@ struct ioctl_gntalloc_unmap_notify {
 * be cleared. Otherwise, it can be any byte in the page whose
 * notification we are adjusting.
 */
-   uint64_t index;
+   __u64 index;
/* Action(s) to take on unmap */
-   uint32_t action;
+   __u32 action;
/* Event channel to notify */
-   uint32_t event_channel_port;
+   __u32 event_channel_port;
 };
 
 /* Clear (set to zero) the byte specified by index */
-- 
2.1.4


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


[Xen-devel] [PATCH 32/98] gntdev.h: use __u32 and __u64 from linux/types.h

2015-05-30 Thread Mikko Rapeli
Fixes userspace compilation errors like:

xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntdev.h | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index 5304bd3..aa7610a 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -33,11 +33,13 @@
 #ifndef __LINUX_PUBLIC_GNTDEV_H__
 #define __LINUX_PUBLIC_GNTDEV_H__
 
+#include 
+
 struct ioctl_gntdev_grant_ref {
/* The domain ID of the grant to be mapped. */
-   uint32_t domid;
+   __u32 domid;
/* The grant reference of the grant to be mapped. */
-   uint32_t ref;
+   __u32 ref;
 };
 
 /*
@@ -50,11 +52,11 @@ _IOC(_IOC_NONE, 'G', 0, sizeof(struct 
ioctl_gntdev_map_grant_ref))
 struct ioctl_gntdev_map_grant_ref {
/* IN parameters */
/* The number of grants to be mapped. */
-   uint32_t count;
-   uint32_t pad;
+   __u32 count;
+   __u32 pad;
/* OUT parameters */
/* The offset to be used on a subsequent call to mmap(). */
-   uint64_t index;
+   __u64 index;
/* Variable IN parameter. */
/* Array of grant references, of size @count. */
struct ioctl_gntdev_grant_ref refs[1];
@@ -70,10 +72,10 @@ _IOC(_IOC_NONE, 'G', 1, sizeof(struct 
ioctl_gntdev_unmap_grant_ref))
 struct ioctl_gntdev_unmap_grant_ref {
/* IN parameters */
/* The offset was returned by the corresponding map operation. */
-   uint64_t index;
+   __u64 index;
/* The number of pages to be unmapped. */
-   uint32_t count;
-   uint32_t pad;
+   __u32 count;
+   __u32 pad;
 };
 
 /*
@@ -93,13 +95,13 @@ _IOC(_IOC_NONE, 'G', 2, sizeof(struct 
ioctl_gntdev_get_offset_for_vaddr))
 struct ioctl_gntdev_get_offset_for_vaddr {
/* IN parameters */
/* The virtual address of the first mapped page in a range. */
-   uint64_t vaddr;
+   __u64 vaddr;
/* OUT parameters */
/* The offset that was used in the initial mmap() operation. */
-   uint64_t offset;
+   __u64 offset;
/* The number of pages mapped in the VM area that begins at @vaddr. */
-   uint32_t count;
-   uint32_t pad;
+   __u32 count;
+   __u32 pad;
 };
 
 /*
@@ -113,7 +115,7 @@ _IOC(_IOC_NONE, 'G', 3, sizeof(struct 
ioctl_gntdev_set_max_grants))
 struct ioctl_gntdev_set_max_grants {
/* IN parameter */
/* The maximum number of grants that may be mapped at once. */
-   uint32_t count;
+   __u32 count;
 };
 
 /*
@@ -135,11 +137,11 @@ struct ioctl_gntdev_unmap_notify {
 * be cleared. Otherwise, it can be any byte in the page whose
 * notification we are adjusting.
 */
-   uint64_t index;
+   __u64 index;
/* Action(s) to take on unmap */
-   uint32_t action;
+   __u32 action;
/* Event channel to notify */
-   uint32_t event_channel_port;
+   __u32 event_channel_port;
 };
 
 /* Clear (set to zero) the byte specified by index */
-- 
2.1.4


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


Re: [Xen-devel] [PATCH 25/45] gntalloc.h: include stdint.h in userspace

2015-03-10 Thread Mikko Rapeli
On Wed, Feb 18, 2015 at 11:53:22AM +, David Vrabel wrote:
> On 16/02/15 23:05, Mikko Rapeli wrote:
> > Fixes compilation error:
> > 
> > xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’
> > 
> > Signed-off-by: Mikko Rapeli 
> > ---
> >  include/uapi/xen/gntalloc.h | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/xen/gntalloc.h
> > index 76bd580..184df7e 100644
> > --- a/include/uapi/xen/gntalloc.h
> > +++ b/include/uapi/xen/gntalloc.h
> > @@ -11,6 +11,12 @@
> >  #ifndef __LINUX_PUBLIC_GNTALLOC_H__
> >  #define __LINUX_PUBLIC_GNTALLOC_H__
> >  
> > +#ifdef __KERNEL__
> > +#include 
> > +#else
> > +#include 
> > +#endif
> 
> I think it would be preferrable to #include  only and
> switch to using the __u32 etc. types (as others have suggested).

Yes, I'm changes the patches to these.

-Mikko

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


[Xen-devel] [PATCH 25/45] gntalloc.h: include stdint.h in userspace

2015-02-18 Thread Mikko Rapeli
Fixes compilation error:

xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntalloc.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/xen/gntalloc.h
index 76bd580..184df7e 100644
--- a/include/uapi/xen/gntalloc.h
+++ b/include/uapi/xen/gntalloc.h
@@ -11,6 +11,12 @@
 #ifndef __LINUX_PUBLIC_GNTALLOC_H__
 #define __LINUX_PUBLIC_GNTALLOC_H__
 
+#ifdef __KERNEL__
+#include 
+#else
+#include 
+#endif
+
 /*
  * Allocates a new page and creates a new grant reference.
  */
-- 
2.1.4


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


[Xen-devel] [PATCH 26/45] gntdev.h: include stdint.h in userspace

2015-02-18 Thread Mikko Rapeli
Fixes compilation error:

xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntdev.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index 5304bd3..f724f75 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -33,6 +33,12 @@
 #ifndef __LINUX_PUBLIC_GNTDEV_H__
 #define __LINUX_PUBLIC_GNTDEV_H__
 
+#ifdef __KERNEL__
+#include 
+#else
+#include 
+#endif
+
 struct ioctl_gntdev_grant_ref {
/* The domain ID of the grant to be mapped. */
uint32_t domid;
-- 
2.1.4


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