Re: [PATCH -v5 5/5] x86,smp: limit spinlock delay on virtual machines

[Stefano Stabellini]

On Wed, 6 Feb 2013, Rik van Riel wrote:
> Modern Intel and AMD CPUs will trap to the host when the guest
> is spinning on a spinlock, allowing the host to schedule in
> something else.
> 
> This effectively means the host is taking care of spinlock
> backoff for virtual machines. It also means that doing the
> spinlock backoff in the guest anyway can lead to totally
> unpredictable results, extremely large backoffs, and
> performance regressions.
> 
> To prevent those problems, we limit the spinlock backoff
> delay, when running in a virtual machine, to a small value.
> 
> Signed-off-by: Rik van Riel 
> ---
>  arch/x86/include/asm/processor.h |2 ++
>  arch/x86/kernel/cpu/hypervisor.c |2 ++
>  arch/x86/kernel/smp.c|   21 +++--
>  3 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 888184b..4118fd8 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -997,6 +997,8 @@ extern bool cpu_has_amd_erratum(const int *);
>  extern unsigned long arch_align_stack(unsigned long sp);
>  extern void free_init_pages(char *what, unsigned long begin, unsigned long 
> end);
>  
> +extern void init_guest_spinlock_delay(void);
> +
>  void default_idle(void);
>  bool set_pm_idle_to_default(void);
>  
> diff --git a/arch/x86/kernel/cpu/hypervisor.c 
> b/arch/x86/kernel/cpu/hypervisor.c
> index a8f8fa9..4a53724 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -76,6 +76,8 @@ void __init init_hypervisor_platform(void)
>  
>   init_hypervisor(&boot_cpu_data);
>  
> + init_guest_spinlock_delay();
> +
>   if (x86_hyper->init_platform)
>   x86_hyper->init_platform();
>  }
> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> index 64e33ef..fbc5ff3 100644
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -116,8 +116,25 @@ static bool smp_no_nmi_ipi = false;
>  #define DELAY_SHIFT  8
>  #define DELAY_FIXED_1(1<  #define MIN_SPINLOCK_DELAY   (1 * DELAY_FIXED_1)
> -#define MAX_SPINLOCK_DELAY   (16000 * DELAY_FIXED_1)
> +#define MAX_SPINLOCK_DELAY_NATIVE(16000 * DELAY_FIXED_1)
> +#define MAX_SPINLOCK_DELAY_GUEST (16 * DELAY_FIXED_1)
>  #define DELAY_HASH_SHIFT 6
> +
> +/*
> + * Modern Intel and AMD CPUs tell the hypervisor when a guest is
> + * spinning excessively on a spinlock. The hypervisor will then
> + * schedule something else, effectively taking care of the backoff
> + * for us. Doing our own backoff on top of the hypervisor's pause
> + * loop exit handling can lead to excessively long delays, and
> + * performance degradations. Limit the spinlock delay in virtual
> + * machines to a smaller value. Called from init_hypervisor_platform 
> + */
> +static int __read_mostly max_spinlock_delay = MAX_SPINLOCK_DELAY_NATIVE;
> +void __init init_guest_spinlock_delay(void)
> +{
> + max_spinlock_delay = MAX_SPINLOCK_DELAY_GUEST;
> +}
> +

Same comment as last time:

"""
Before reducing max_spinlock_delay, shouldn't we check that PAUSE-loop
exiting is available? What if we are running on an older x86 machine
that doesn't support it?
"""
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup

[Stefano Stabellini]

On Mon, 1 Apr 2013, Nicolas Pitre wrote:
> On Mon, 1 Apr 2013, Stefano Stabellini wrote:
> 
> > On Fri, 29 Mar 2013, Rob Herring wrote:
> > > On 03/29/2013 12:53 PM, Nicolas Pitre wrote:
> > > > On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > > > 
> > > >> On Fri, 29 Mar 2013, Nicolas Pitre wrote:
> > > >>> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> > > >>>
> > > >>>> If PSCI initializes correctly and PSCI SMP operations are available, 
> > > >>>> use them.
> > > >>>> This is required for SMP support in Dom0 on Xen.
> > > >>>>
> > > >>>> Signed-off-by: Stefano Stabellini 
> > > >>>> CC: will.dea...@arm.com
> > > >>>> CC: a...@arndb.de
> > > >>>> CC: marc.zyng...@arm.com
> > > >>>> CC: li...@arm.linux.org.uk
> > > >>>> CC: n...@linaro.org
> > > >>>
> > > >>> I'd suggest you also include in your series the patch I posted 
> > > >>> earlier 
> > > >>> providing a runtime mdesc->smp_init method as well.
> > > >>
> > > >> OK.
> > > >>
> > > >>
> > > >>> This way the 
> > > >>> priority order would be:
> > > >>>
> > > >>> - If mdesc->smp_init is non null then use that.
> > > >>>
> > > >>> - Otherwise, if PSCI is available then use that.
> > > >>>
> > > >>> - Otherwise use mdesc->smp.
> > > >>>
> > > >>> This way, if the PSCI default has to be overriden (like in the MCPM 
> > > >>> case 
> > > >>> because it needs to wrap PSCI itself, or to cover Rob's concern) then 
> > > >>> this can be achieved at run time on a per mdesc basis.
> > > >>
> > > >> Actually that's not a bad idea, it could make everybody happy.
> > > >> What about the following, in this precise order:
> > > >>
> > > >> - if a xen hypervisor node is present on device tree, use PSCI;
> > > >> - otherwise if mdesc->smp_init is non null then use it;
> > > >> - otherwise if PSCI is available then use it;
> > > >> - otherwise use mdesc->smp.
> > > >>
> > > >> It's the most practical solution to satisfy everybody's needs.
> > > > 
> > > > Maybe I'm missing something obvious, but why can't xen declare a mdesc 
> > > > of its own?  Given it is going to tweak the DT passed to the kernel 
> > > > anyway that shouldn't be a problem.
> > > 
> > > Xen does have it's own mdesc. It is (or will be) mach-virt, but that is
> > > only for DomU guests. For Dom0, you still need all the platform specific
> > > code except smp_ops. However, I'm doubtful this would work without other
> > > changes on more complicated platforms like OMAP.
> > > 
> > > I would say wait to add this until you have platforms that actually need
> > > the first case.
> > 
> > OK, that is not unreasonable.
> > 
> > What are the platforms that are going to use smp_init? Do we know how do
> > they intend to use it?
> 
> VExpress for one.  When booting on a big.LITTLE system such as TC2 on 
> VExpress, the MCPM layer needs to arbitrate power management operations 
> on a per cluster basis.  In that case there is a MCPM specific set of 
> SMP ops to be used, even if it may end up calling into PSCI.
> 
> But the important point is that we don't know beforehand what to use, 
> especially with a kernel that can boot on multiple different VExpress 
> configurations.  The decision has to be made at run time, and therefore 
> a static default or mdesc->smp ops doesn't cut it.

I certainly like the principle and I am in favor of anything that moves
the decisions at runtime. I have pulled the patch in the series, it's
going to be in the next version.

However I am concerned that these platform specific operations won't
work with Xen at all.
I am getting increasingly certain that we need a Xen specific check in
setup_arch to bump up of the priority of PSCI over anything else if Xen
is running. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/2] arm: introduce psci_smp_ops

[Stefano Stabellini]

On Tue, 2 Apr 2013, Will Deacon wrote:
> > diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> > index ce0dbe7..4134dda 100644
> > --- a/arch/arm/include/asm/psci.h
> > +++ b/arch/arm/include/asm/psci.h
> > @@ -32,5 +32,14 @@ struct psci_operations {
> >  };
> >  
> >  extern struct psci_operations psci_ops;
> > +extern struct smp_operations psci_smp_ops;
> >  
> > +#ifdef CONFIG_ARM_PSCI
> > +int psci_init(void);
> > +bool psci_smp_available(void);
> > +#else
> > +static inline int psci_init(void) { return -ENODEV; }
> > +static inline bool psci_smp_available(void) { return false; }
> 
> You can probably make psci_init return void now that it's no longer an
> initcall (you're not checking it's return value anyway).

Sure.


> > diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> > new file mode 100644
> > index 000..66b0f77
> > --- /dev/null
> > +++ b/arch/arm/kernel/psci_smp.c
> > @@ -0,0 +1,67 @@
> > +/*
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * Copyright (C) 2012 ARM Limited
> > + *
> > + * Author: Will Deacon 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +extern void secondary_startup(void);
> > +
> > +static int __cpuinit psci_boot_secondary(unsigned int cpu,
> > +struct task_struct *idle)
> > +{
> > +   if (psci_ops.cpu_on)
> > +   return psci_ops.cpu_on(cpu_logical_map(cpu),
> > +  __pa(secondary_startup));
> > +   return -ENODEV;
> > +}
> 
> Since this code is now likely to be shared, it could be worth a comment
> before each function to describe the expected semantics (e.g. mpidr is used
> as the CPUID, additional power state information is zero).

OK. I'll document psci_operations in psci.h.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3 v5] arm: introduce psci_smp_ops and use them on Xen

[Stefano Stabellini]

Hi all,
this is the fifth version of the patch series to move virt_smp_ops out of
mach-virt and make it a generic set of reusable PSCI based smp_ops.
I added a patch to introduce smp_init to this series.
In the last patch I am using smp_init to switch to psci_smp_ops if Xen
is detected on the platform.


Jon Medhurst (1):
  ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (2):
  arm: introduce psci_smp_ops
  xen/arm: introduce xen_early_init, use PSCI on xen

 arch/arm/Kconfig  |1 +
 arch/arm/include/asm/mach/arch.h  |3 +
 arch/arm/include/asm/psci.h   |   29 ++
 arch/arm/include/asm/xen/hypervisor.h |6 +++
 arch/arm/kernel/Makefile  |5 ++-
 arch/arm/kernel/psci.c|7 +--
 arch/arm/kernel/psci_smp.c|   67 +
 arch/arm/kernel/setup.c   |   12 +-
 arch/arm/mach-virt/Makefile   |1 -
 arch/arm/mach-virt/platsmp.c  |   58 
 arch/arm/mach-virt/virt.c |3 -
 arch/arm/xen/enlighten.c  |   27 ++---
 12 files changed, 144 insertions(+), 75 deletions(-)


A branch based on "xen/arm: move to mach-virt and support SMP" and
3.9-rc3 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.9-rc3-smp-5


Cheers,

Stefano
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 2/3] ARM: Enable selection of SMP operations at boot time

[Stefano Stabellini]

From: Jon Medhurst 

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.

Signed-off-by: Jon Medhurst 
Signed-off-by: Nicolas Pitre 
Reviewed-by: Santosh Shilimkar 
---
 arch/arm/include/asm/mach/arch.h |3 +++
 arch/arm/kernel/setup.c  |4 +++-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..c01bf53 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (void (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,7 @@ struct machine_desc {
unsigned char   reserve_lp2 :1; /* never has lp2*/
charrestart_mode;   /* default restart mode */
struct smp_operations   *smp;   /* SMP operations   */
+   void(*smp_init)(void);
void(*fixup)(struct tag *, char **,
 struct meminfo *);
void(*reserve)(void);/* reserve mem blocks  */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 341efaa..7e193df 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,7 +770,9 @@ void __init setup_arch(char **cmdline_p)
psci_init();
 #ifdef CONFIG_SMP
if (is_smp()) {
-   if (mdesc->smp)
+   if (mdesc->smp_init)
+   (*mdesc->smp_init)();
+   else if (mdesc->smp)
smp_set_ops(mdesc->smp);
else if (psci_smp_available())
smp_set_ops(&psci_smp_ops);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

Split xen_guest_init in two functions, one of them (xen_early_init) is
going to be called very early from setup_arch.

Change machine_desc->smp_init to xen_smp_init if Xen is present on the
platform. xen_smp_init just sets smp_ops to psci_smp_ops.

Introduce a dependency for ARM_PSCI in XEN.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/Kconfig  |1 +
 arch/arm/include/asm/xen/hypervisor.h |6 ++
 arch/arm/kernel/setup.c   |3 +++
 arch/arm/xen/enlighten.c  |   27 ---
 4 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..66658d3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1891,6 +1891,7 @@ config XEN
bool "Xen guest support on ARM (EXPERIMENTAL)"
depends on ARM && AEABI && OF
depends on CPU_V7 && !CPU_V6
+   depends on ARM_PSCI
depends on !GENERIC_ATOMIC64
help
  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
diff --git a/arch/arm/include/asm/xen/hypervisor.h 
b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode 
paravirt_get_lazy_mode(void)
return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 7e193df..67d911f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -55,6 +55,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "atags.h"
 #include "tcm.h"
@@ -768,6 +770,7 @@ void __init setup_arch(char **cmdline_p)
 
arm_dt_init_cpu_maps();
psci_init();
+   xen_early_init();
 #ifdef CONFIG_SMP
if (is_smp()) {
if (mdesc->smp_init)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index b002822..ee09357 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
return 0;
 }
 
+static void __init xen_smp_init(void)
+{
+   if (psci_smp_available())
+   smp_set_ops(&psci_smp_ops);
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
-static int __init xen_guest_init(void)
+void __init xen_early_init(void)
 {
-   struct xen_add_to_physmap xatp;
-   static struct shared_info *shared_info_page = 0;
struct device_node *node;
int len;
const char *s = NULL;
const char *version = NULL;
const char *xen_prefix = "xen,xen-";
struct resource res;
-   int i;
 
node = of_find_compatible_node(NULL, NULL, "xen,xen");
if (!node) {
pr_debug("No Xen support\n");
-   return 0;
+   return;
}
s = of_get_property(node, "compatible", &len);
if (strlen(xen_prefix) + 3  < len &&
@@ -204,15 +209,23 @@ static int __init xen_guest_init(void)
version = s + strlen(xen_prefix);
if (version == NULL) {
pr_debug("Xen version not found\n");
-   return 0;
+   return;
}
if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-   return 0;
+   return;
xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
xen_events_irq = irq_of_parse_and_map(node, 0);
pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
version, xen_events_irq, xen_hvm_resume_frames);
xen_domain_type = XEN_HVM_DOMAIN;
+   machine_desc->smp_init = xen_smp_init;
+}
+
+static int __init xen_guest_init(void)
+{
+   struct xen_add_to_physmap xatp;
+   static struct shared_info *shared_info_page = 0;
+   int i;
 
xen_setup_features();
if (xen_feature(XENFEAT_dom0))
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/3] arm: introduce psci_smp_ops

[Stefano Stabellini]

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.
Use psci_smp_ops if the platform doesn't provide its own smp_ops.


Changes in v5:
- document psci_operations;
- psci_init returns NULL.


Signed-off-by: Stefano Stabellini 
Acked-by: Nicolas Pitre 
Acked-by: Rob Herring 

CC: will.dea...@arm.com
CC: a...@arndb.de
CC: marc.zyng...@arm.com
CC: li...@arm.linux.org.uk
CC: n...@linaro.org
---
 arch/arm/include/asm/psci.h  |   29 ++
 arch/arm/kernel/Makefile |5 ++-
 arch/arm/kernel/psci.c   |7 ++--
 arch/arm/kernel/psci_smp.c   |   67 ++
 arch/arm/kernel/setup.c  |7 -
 arch/arm/mach-virt/Makefile  |1 -
 arch/arm/mach-virt/platsmp.c |   58 
 arch/arm/mach-virt/virt.c|3 --
 8 files changed, 109 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..fd94ce2 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -23,6 +23,26 @@ struct psci_power_state {
u8  affinity_level;
 };
 
+/*
+ * cpu_suspend   Suspend the execution on a CPU
+ * @statewe don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off   Power down a CPU
+ * @statewe don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_onPower up a CPU
+ * @cpuidcpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate   Migrate the context to a different CPU
+ * @cpuidcpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
 struct psci_operations {
int (*cpu_suspend)(struct psci_power_state state,
   unsigned long entry_point);
@@ -32,5 +52,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { return -ENODEV; }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)+= debug.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT) += hyp-stub.o
-obj-$(CONFIG_ARM_PSCI) += psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y  += psci.o
+obj-$(CONFIG_SMP)  += psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] 
__initconst = {
{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
struct device_node *np;
const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
np = of_find_matching_node(NULL, psci_of_match);
if (!np)
-   return 0;
+   return;
 
pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
of_node_put(np);
-   return 0;
+   return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 000..66b0f77
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,67 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+extern void secondary_startup(void);
+
+static int __cpuinit psci_boot_secondary(unsigned int cpu,
+struct task_struct *idle)
+{
+   if (psci_

Re: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> 
> > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > going to be called very early from setup_arch.
> > 
> > Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> > platform. xen_smp_init just sets smp_ops to psci_smp_ops.
> > 
> > Introduce a dependency for ARM_PSCI in XEN.
> 
> The Kconfig stuff should be more understandable to "normal" users 
> configuring the kernel.  Hence it might make more sense for Xen to 
> select PSCI rather than making it a prerequisite.

You are right, I'll do that.


> [...]
> > @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int cpu)
> > return 0;
> >  }
> >  
> > +static void __init xen_smp_init(void)
> > +{
> > +   if (psci_smp_available())
> > +   smp_set_ops(&psci_smp_ops);
> > +}
> > +
> 
> I still don't understand why you need to do this.  Why can't you just 
> rely on the next priority which is to set PSCI ops by default if 
> available?  Using this hook for Xen doesn't look justified. As it is, 
> you break MCPM.
> 
> As I explained to you, MCPM will end up using PSCI as well when 
> available, which I think should be sufficient for your concern.

The smp_init hook is not limited to MCPM or the versatile express
platform. It's a generic hook that can be used by any platform and can
override the platform smp_ops or the psci_smp_ops depending on platform
specific configurations.

Configurations that I am pretty sure won't be available on Xen anyway,
while I am certain that using psci_smp_ops would work.

It seems to me that relying on the fact that only versatile express and
only MCPM use smp_init, even though it might work today, it's very
fragile and could break tomorrow without any of us noticing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/3] arm: introduce psci_smp_ops

[Stefano Stabellini]

On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> 
> > Rename virt_smp_ops to psci_smp_ops and move them to 
> > arch/arm/kernel/psci_smp.c.
> > Remove mach-virt/platsmp.c, now unused.
> > Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
> > 
> > Add a cpu_die smp_op based on psci_ops.cpu_off.
> > 
> > Initialize PSCI before setting smp_ops in setup_arch.
> > Use psci_smp_ops if the platform doesn't provide its own smp_ops.
> 
> [...]
> 
> > @@ -766,9 +767,13 @@ void __init setup_arch(char **cmdline_p)
> > unflatten_device_tree();
> >  
> > arm_dt_init_cpu_maps();
> > +   psci_init();
> >  #ifdef CONFIG_SMP
> > if (is_smp()) {
> > -   smp_set_ops(mdesc->smp);
> > +   if (mdesc->smp)
> > +   smp_set_ops(mdesc->smp);
> > +   else if (psci_smp_available())
> > +   smp_set_ops(&psci_smp_ops);
> 
> Didn't we agree to do this the other way around, i.e. 
> 
>   if (psci_smp_available())
>   smp_set_ops(&psci_smp_ops);
>   else if (mdesc->smp)
>   smp_set_ops(mdesc->smp);
> 
> ?

Yes, we agreed about it.
However that change was in a separate patch that I have dropped from
this version of the series, that is why it is missing.

I'll add back the change but I'll keep it in a separate patch to leave
the original one, now acked twice and reviewed once, untouched.


> This way you won't need the ->smp_init for Xen and that won't conflict 
> with MCPM.

See my other reply on the subject.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

On Wed, 3 Apr 2013, Nicolas Pitre wrote:
> On Wed, 3 Apr 2013, Stefano Stabellini wrote:
> 
> > On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> > > On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> > > 
> > > > @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int 
> > > > cpu)
> > > > return 0;
> > > >  }
> > > >  
> > > > +static void __init xen_smp_init(void)
> > > > +{
> > > > +   if (psci_smp_available())
> > > > +   smp_set_ops(&psci_smp_ops);
> > > > +}
> > > > +
> > > 
> > > I still don't understand why you need to do this.  Why can't you just 
> > > rely on the next priority which is to set PSCI ops by default if 
> > > available?  Using this hook for Xen doesn't look justified. As it is, 
> > > you break MCPM.
> > > 
> > > As I explained to you, MCPM will end up using PSCI as well when 
> > > available, which I think should be sufficient for your concern.
> > 
> > The smp_init hook is not limited to MCPM or the versatile express
> > platform. It's a generic hook that can be used by any platform and can
> > override the platform smp_ops or the psci_smp_ops depending on platform
> > specific configurations.
> > 
> > Configurations that I am pretty sure won't be available on Xen anyway,
> > while I am certain that using psci_smp_ops would work.
> > 
> > It seems to me that relying on the fact that only versatile express and
> > only MCPM use smp_init, even though it might work today, it's very
> > fragile and could break tomorrow without any of us noticing.
> 
> I claim: this breaks MCPM today.
>
> You claim: the alternative _could_ break with Xen tomorrow.
> 
> Could we please wait until there is an actual problem with Xen before 
> being overly defensive in the code?

Sorry, I realized that I should have explained myself better.

The smp_init patch together with the MCPM patch series
(http://marc.info/?l=linux-arm-kernel&m=136004188122492) breaks Xen Dom0
SMP support on versatile express *today* (ifndef CONFIG_CLUSTER_PM):
smp_init is not NULL on versatile express anymore therefore smp_init is
going to be called, causing vexpress_smp_ops to be selected even if psci
is on device tree.

On the other hand if this patch was applied, xen_smp_init would override
smp_init making sure that psci_smp_ops is used on Xen and everything
would work as expected.


So as it stands today, we need this patch for regular Xen Dom0 SMP
support.


BTW I have actually tried it on my versatile express machine to make
sure that it is correct :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen: drop tracking of IRQ vector

[Stefano Stabellini]

On Wed, 3 Apr 2013, Jan Beulich wrote:
> For quite a few Xen versions, this wasn't the IRQ vector anymore
> anyway, and it is not being used by the kernel for anything. Hence
> drop the field from struct irq_info, and respective function
> parameters.
> 
> Signed-off-by: Jan Beulich 
> Cc: Stefano Stabellini 


Acked-by: Stefano Stabellini 

> ---
>  arch/x86/pci/xen.c   |6 +++---
>  drivers/xen/events.c |   13 -
>  include/xen/events.h |3 +--
>  3 files changed, 8 insertions(+), 14 deletions(-)
> 
> --- 3.9-rc5/arch/x86/pci/xen.c
> +++ 3.9-rc5-xen-irq-no-vector/arch/x86/pci/xen.c
> @@ -177,7 +177,7 @@ static int xen_setup_msi_irqs(struct pci
>   goto error;
>   i = 0;
>   list_for_each_entry(msidesc, &dev->msi_list, list) {
> - irq = xen_bind_pirq_msi_to_irq(dev, msidesc, v[i], 0,
> + irq = xen_bind_pirq_msi_to_irq(dev, msidesc, v[i],
>  (type == PCI_CAP_ID_MSIX) ?
>  "pcifront-msi-x" :
>  "pcifront-msi",
> @@ -244,7 +244,7 @@ static int xen_hvm_setup_msi_irqs(struct
>   dev_dbg(&dev->dev,
>   "xen: msi already bound to pirq=%d\n", pirq);
>   }
> - irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq, 0,
> + irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
>  (type == PCI_CAP_ID_MSIX) ?
>  "msi-x" : "msi",
>  DOMID_SELF);
> @@ -326,7 +326,7 @@ static int xen_initdom_setup_msi_irqs(st
>   }
>  
>   ret = xen_bind_pirq_msi_to_irq(dev, msidesc,
> -map_irq.pirq, map_irq.index,
> +map_irq.pirq,
>  (type == PCI_CAP_ID_MSIX) ?
>  "msi-x" : "msi",
>   domid);
> --- 3.9-rc5/drivers/xen/events.c
> +++ 3.9-rc5-xen-irq-no-vector/drivers/xen/events.c
> @@ -85,8 +85,7 @@ enum xen_irq_type {
>   * event channel - irq->event channel mapping
>   * cpu - cpu this event channel is bound to
>   * index - type-specific information:
> - *PIRQ - vector, with MSB being "needs EIO", or physical IRQ of the HVM
> - *   guest, or GSI (real passthrough IRQ) of the device.
> + *PIRQ - physical IRQ, GSI, flags, and owner domain
>   *VIRQ - virq number
>   *IPI - IPI vector
>   *EVTCHN -
> @@ -105,7 +104,6 @@ struct irq_info {
>   struct {
>   unsigned short pirq;
>   unsigned short gsi;
> - unsigned char vector;
>   unsigned char flags;
>   uint16_t domid;
>   } pirq;
> @@ -211,7 +209,6 @@ static void xen_irq_info_pirq_init(unsig
>  unsigned short evtchn,
>  unsigned short pirq,
>  unsigned short gsi,
> -unsigned short vector,
>  uint16_t domid,
>  unsigned char flags)
>  {
> @@ -221,7 +218,6 @@ static void xen_irq_info_pirq_init(unsig
>  
>   info->u.pirq.pirq = pirq;
>   info->u.pirq.gsi = gsi;
> - info->u.pirq.vector = vector;
>   info->u.pirq.domid = domid;
>   info->u.pirq.flags = flags;
>  }
> @@ -714,7 +710,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gs
>   goto out;
>   }
>  
> - xen_irq_info_pirq_init(irq, 0, pirq, gsi, irq_op.vector, DOMID_SELF,
> + xen_irq_info_pirq_init(irq, 0, pirq, gsi, DOMID_SELF,
>  shareable ? PIRQ_SHAREABLE : 0);
>  
>   pirq_query_unmask(irq);
> @@ -762,8 +758,7 @@ int xen_allocate_pirq_msi(struct pci_dev
>  }
>  
>  int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
> -  int pirq, int vector, const char *name,
> -  domid_t domid)
> +  int pirq, const char *name, domid_t domid)
>  {
>   int irq, ret;
>  
> @@ -776,7 +771,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_
>   irq_set_chip_and_handler_name(irq, &xen_pirq_chip, handle_edge_irq,
>   name);
>  
> - xen_irq_info_pirq_init(irq, 0, pirq, 0, vect

[PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen

[Stefano Stabellini]

Hi all,
this is the sixth version of the patch series to move virt_smp_ops out of
mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops.
I added a patch to introduce smp_init to this series.
In the last patch I am using smp_init to switch to psci_smp_ops if Xen
is detected on the platform.


Jon Medhurst (1):
  ARM: Enable selection of SMP operations at boot time

Stefano Stabellini (3):
  arm: introduce psci_smp_ops
  arm: prefer psci_smp_ops over mdesc->smp
  xen/arm: introduce xen_early_init, use PSCI on xen

 arch/arm/Kconfig  |1 +
 arch/arm/include/asm/mach/arch.h  |3 +
 arch/arm/include/asm/psci.h   |   29 ++
 arch/arm/include/asm/xen/hypervisor.h |6 +++
 arch/arm/kernel/Makefile  |5 ++-
 arch/arm/kernel/psci.c|7 +--
 arch/arm/kernel/psci_smp.c|   67 +
 arch/arm/kernel/setup.c   |   12 +-
 arch/arm/mach-virt/Makefile   |1 -
 arch/arm/mach-virt/platsmp.c  |   58 
 arch/arm/mach-virt/virt.c |3 -
 arch/arm/xen/enlighten.c  |   36 ++
 12 files changed, 152 insertions(+), 76 deletions(-)


git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.9-rc3-smp-6


Cheers,

Stefano
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 2/4] arm: prefer psci_smp_ops over mdesc->smp

[Stefano Stabellini]

If PSCI is available on the platform, prefer psci_smp_ops over the
platform smp_ops.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/kernel/setup.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 341efaa..dad3048 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,10 +770,10 @@ void __init setup_arch(char **cmdline_p)
psci_init();
 #ifdef CONFIG_SMP
if (is_smp()) {
-   if (mdesc->smp)
-   smp_set_ops(mdesc->smp);
-   else if (psci_smp_available())
+   if (psci_smp_available())
smp_set_ops(&psci_smp_ops);
+   else if (mdesc->smp)
+   smp_set_ops(mdesc->smp);
smp_init_cpus();
}
 #endif
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 1/4] arm: introduce psci_smp_ops

[Stefano Stabellini]

Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.

Add a cpu_die smp_op based on psci_ops.cpu_off.

Initialize PSCI before setting smp_ops in setup_arch.
Use psci_smp_ops if the platform doesn't provide its own smp_ops.

Changes in v6:
- fixed return values for psci_smp_available and psci_init ifndef
CONFIG_ARM_PSCI.

Changes in v5:
- document psci_operations;
- psci_init returns NULL.

Signed-off-by: Stefano Stabellini 
Acked-by: Nicolas Pitre 
Acked-by: Rob Herring 
Reviewed-by: Will Deacon 

CC: will.dea...@arm.com
CC: a...@arndb.de
CC: marc.zyng...@arm.com
CC: li...@arm.linux.org.uk
CC: n...@linaro.org
---
 arch/arm/include/asm/psci.h  |   29 ++
 arch/arm/kernel/Makefile |5 ++-
 arch/arm/kernel/psci.c   |7 ++--
 arch/arm/kernel/psci_smp.c   |   67 ++
 arch/arm/kernel/setup.c  |7 -
 arch/arm/mach-virt/Makefile  |1 -
 arch/arm/mach-virt/platsmp.c |   58 
 arch/arm/mach-virt/virt.c|3 --
 8 files changed, 109 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/kernel/psci_smp.c
 delete mode 100644 arch/arm/mach-virt/platsmp.c

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ce0dbe7..fa44417 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -23,6 +23,26 @@ struct psci_power_state {
u8  affinity_level;
 };
 
+/*
+ * cpu_suspend   Suspend the execution on a CPU
+ * @statewe don't currently describe affinity levels, so just pass 0.
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * cpu_off   Power down a CPU
+ * @statewe don't currently describe affinity levels, so just pass 0.
+ * no return on successful call
+ *
+ * cpu_onPower up a CPU
+ * @cpuidcpuid of target CPU, as from MPIDR
+ * @entry_point  the first instruction to be executed on return
+ * returns 0  success, < 0 on failure
+ *
+ * migrate   Migrate the context to a different CPU
+ * @cpuidcpuid of target CPU, as from MPIDR
+ * returns 0  success, < 0 on failure
+ *
+ */
 struct psci_operations {
int (*cpu_suspend)(struct psci_power_state state,
   unsigned long entry_point);
@@ -32,5 +52,14 @@ struct psci_operations {
 };
 
 extern struct psci_operations psci_ops;
+extern struct smp_operations psci_smp_ops;
+
+#ifdef CONFIG_ARM_PSCI
+void psci_init(void);
+bool psci_smp_available(void);
+#else
+static inline void psci_init(void) { }
+static inline bool psci_smp_available(void) { return false; }
+#endif
 
 #endif /* __ASM_ARM_PSCI_H */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 5f3338e..dd9d90a 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -82,6 +82,9 @@ obj-$(CONFIG_DEBUG_LL)+= debug.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT) += hyp-stub.o
-obj-$(CONFIG_ARM_PSCI) += psci.o
+ifeq ($(CONFIG_ARM_PSCI),y)
+obj-y  += psci.o
+obj-$(CONFIG_SMP)  += psci_smp.o
+endif
 
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 3653164..4693188 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -158,7 +158,7 @@ static const struct of_device_id psci_of_match[] 
__initconst = {
{},
 };
 
-static int __init psci_init(void)
+void __init psci_init(void)
 {
struct device_node *np;
const char *method;
@@ -166,7 +166,7 @@ static int __init psci_init(void)
 
np = of_find_matching_node(NULL, psci_of_match);
if (!np)
-   return 0;
+   return;
 
pr_info("probing function IDs from device-tree\n");
 
@@ -206,6 +206,5 @@ static int __init psci_init(void)
 
 out_put_node:
of_node_put(np);
-   return 0;
+   return;
 }
-early_initcall(psci_init);
diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
new file mode 100644
index 000..66b0f77
--- /dev/null
+++ b/arch/arm/kernel/psci_smp.c
@@ -0,0 +1,67 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ *
+ * Author: Will Deacon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+extern void secondary_startup(void);
+
+static int __cpuinit ps

[PATCH v6 3/4] ARM: Enable selection of SMP operations at boot time

[Stefano Stabellini]

From: Jon Medhurst 

Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.

If smp_init is set, use it instead of psci_smp_ops or mdesc->smp.

Signed-off-by: Jon Medhurst 
Signed-off-by: Nicolas Pitre 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Santosh Shilimkar 
---
 arch/arm/include/asm/mach/arch.h |3 +++
 arch/arm/kernel/setup.c  |4 +++-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..c01bf53 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -16,8 +16,10 @@ struct pt_regs;
 struct smp_operations;
 #ifdef CONFIG_SMP
 #define smp_ops(ops) (&(ops))
+#define smp_init_ops(ops) (&(ops))
 #else
 #define smp_ops(ops) (struct smp_operations *)NULL
+#define smp_init_ops(ops) (void (*)(void))NULL
 #endif
 
 struct machine_desc {
@@ -41,6 +43,7 @@ struct machine_desc {
unsigned char   reserve_lp2 :1; /* never has lp2*/
charrestart_mode;   /* default restart mode */
struct smp_operations   *smp;   /* SMP operations   */
+   void(*smp_init)(void);
void(*fixup)(struct tag *, char **,
 struct meminfo *);
void(*reserve)(void);/* reserve mem blocks  */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index dad3048..2f738cb 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -770,7 +770,9 @@ void __init setup_arch(char **cmdline_p)
psci_init();
 #ifdef CONFIG_SMP
if (is_smp()) {
-   if (psci_smp_available())
+   if (mdesc->smp_init)
+   (*mdesc->smp_init)();
+   else if (psci_smp_available())
smp_set_ops(&psci_smp_ops);
else if (mdesc->smp)
smp_set_ops(mdesc->smp);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

Split xen_guest_init in two functions, one of them (xen_early_init) is
going to be called very early from setup_arch.

Change machine_desc->smp_init to xen_smp_init if Xen is present on the
platform. xen_smp_init just sets smp_ops to psci_smp_ops.

XEN selects ARM_PSCI.

Changes in v6:
- xen_smp_init: call smp_set_ops only ifdef CONFIG_SMP;
- move more of the initialization to xen_guest_init;
- select ARM_PSCI if XEN.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/Kconfig  |1 +
 arch/arm/include/asm/xen/hypervisor.h |6 +
 arch/arm/kernel/setup.c   |3 ++
 arch/arm/xen/enlighten.c  |   36 +---
 4 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c3bdce..344e299 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1892,6 +1892,7 @@ config XEN
depends on ARM && AEABI && OF
depends on CPU_V7 && !CPU_V6
depends on !GENERIC_ATOMIC64
+   select ARM_PSCI
help
  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/arch/arm/include/asm/xen/hypervisor.h 
b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode 
paravirt_get_lazy_mode(void)
return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 2f738cb..336305e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -55,6 +55,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "atags.h"
 #include "tcm.h"
@@ -768,6 +770,7 @@ void __init setup_arch(char **cmdline_p)
 
arm_dt_init_cpu_maps();
psci_init();
+   xen_early_init();
 #ifdef CONFIG_SMP
if (is_smp()) {
if (mdesc->smp_init)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index b002822..fc1bc2a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -176,11 +178,33 @@ static int __init xen_secondary_init(unsigned int cpu)
return 0;
 }
 
+static void __init xen_smp_init(void)
+{
+#ifdef CONFIG_SMP
+   if (psci_smp_available())
+   smp_set_ops(&psci_smp_ops);
+#endif
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
+void __init xen_early_init(void)
+{
+   struct device_node *node;
+
+   node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!node) {
+   pr_debug("No Xen support\n");
+   return;
+   }
+
+   xen_domain_type = XEN_HVM_DOMAIN;
+   machine_desc->smp_init = xen_smp_init;
+}
+
 static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
@@ -194,25 +218,21 @@ static int __init xen_guest_init(void)
int i;
 
node = of_find_compatible_node(NULL, NULL, "xen,xen");
-   if (!node) {
-   pr_debug("No Xen support\n");
-   return 0;
-   }
+
s = of_get_property(node, "compatible", &len);
if (strlen(xen_prefix) + 3  < len &&
!strncmp(xen_prefix, s, strlen(xen_prefix)))
version = s + strlen(xen_prefix);
if (version == NULL) {
-   pr_debug("Xen version not found\n");
-   return 0;
+   pr_warn("Xen version not found\n");
+   return -EINVAL;
}
if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-   return 0;
+   return -EINVAL;
xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
xen_events_irq = irq_of_parse_and_map(node, 0);
pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
version, xen_events_irq, xen_hvm_resume_frames);
-   xen_domain_type = XEN_HVM_DOMAIN;
 
xen_setup_features();
if (xen_feature(XENFEAT_dom0))
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4 v6] arm: introduce psci_smp_ops and use them on Xen

[Stefano Stabellini]

Russell,
sorry for not CC'ing you explicitly since v1 of this series, there have
been quite few lengthy discussions on this topic.

Do you have any opinions on this?
Do you feel that this work belong to your tree, or do you want me to go
via arm-soc?



On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> Hi all,
> this is the sixth version of the patch series to move virt_smp_ops out of
> mach-virt and make it a generic set of reusable PSCI based smp_ops.
> psci_smp_ops are preferred over the platform smp_ops.
> I added a patch to introduce smp_init to this series.
> In the last patch I am using smp_init to switch to psci_smp_ops if Xen
> is detected on the platform.
> 
> 
> Jon Medhurst (1):
>   ARM: Enable selection of SMP operations at boot time
> 
> Stefano Stabellini (3):
>   arm: introduce psci_smp_ops
>   arm: prefer psci_smp_ops over mdesc->smp
>   xen/arm: introduce xen_early_init, use PSCI on xen
> 
>  arch/arm/Kconfig  |1 +
>  arch/arm/include/asm/mach/arch.h  |3 +
>  arch/arm/include/asm/psci.h   |   29 ++
>  arch/arm/include/asm/xen/hypervisor.h |6 +++
>  arch/arm/kernel/Makefile  |5 ++-
>  arch/arm/kernel/psci.c|7 +--
>  arch/arm/kernel/psci_smp.c|   67 
> +
>  arch/arm/kernel/setup.c   |   12 +-
>  arch/arm/mach-virt/Makefile   |1 -
>  arch/arm/mach-virt/platsmp.c  |   58 
>  arch/arm/mach-virt/virt.c |3 -
>  arch/arm/xen/enlighten.c  |   36 ++
>  12 files changed, 152 insertions(+), 76 deletions(-)
> 
> 
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.9-rc3-smp-6
> 
> 
> Cheers,
> 
> Stefano
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> 
> > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > going to be called very early from setup_arch.
> > 
> > Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> > platform. xen_smp_init just sets smp_ops to psci_smp_ops.
> 
> I still think the above is redundant, especially since psci_smp_ops has 
> priority over default mdesc->smp_ops.  And doing so does break MCPM. But 
> we're apparently going in circle over this issue.

Did you read my last email on this issue?

http://marc.info/?l=linux-arm-kernel&m=136500098703317&w=2


Let's examine the use cases here, assuming that your MCPM patch series
has been applied.


This is what happens:

- No Xen
Xen is not running on the platform and a Xen hypervisor node is not
available on device tree.
Everything keeps working seamlessly, this patch doesn't change anything.

- we are running on Xen
Xen is running on the platform, we are running as a guest on Xen and an
hypervisor node is available on device tree.
Let's also assume that there aren't any "arm,cci" compatible nodes on
device tree because Xen wouldn't export this kind of information to any
guests right now. Therefore PSCI should be used to boot secondary cpus.
Because the versatile express machine sets smp_init to
vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
Xen.

With this patch, xen_smp_init will be called instead of
vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
therefore *unbreaking* Xen.

In fact what makes this patch really necessary is smp_init together with
the MCPM series.


Do you agree with me?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > 
> > > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > > going to be called very early from setup_arch.
> > > 
> > > Change machine_desc->smp_init to xen_smp_init if Xen is present on the
> > > platform. xen_smp_init just sets smp_ops to psci_smp_ops.
> > 
> > I still think the above is redundant, especially since psci_smp_ops has 
> > priority over default mdesc->smp_ops.  And doing so does break MCPM. But 
> > we're apparently going in circle over this issue.
> 
> Did you read my last email on this issue?
> 
> http://marc.info/?l=linux-arm-kernel&m=136500098703317&w=2
> 
> 
> Let's examine the use cases here, assuming that your MCPM patch series
> has been applied.
> 
> 
> This is what happens:
> 
> - No Xen
> Xen is not running on the platform and a Xen hypervisor node is not
> available on device tree.
> Everything keeps working seamlessly, this patch doesn't change anything.
> 
> - we are running on Xen
> Xen is running on the platform, we are running as a guest on Xen and an
> hypervisor node is available on device tree.
> Let's also assume that there aren't any "arm,cci" compatible nodes on
> device tree because Xen wouldn't export this kind of information to any
> guests right now. Therefore PSCI should be used to boot secondary cpus.

Just in case this isn't clear enough: we don't have big.LITTLE support
in Xen right now, not in the hypervisor and certainly not in guests.
I'm keen on having big.LITTLE support in the hypervisor (thus some code
similar to your MCPM patch series will probably end up in Xen at some
point) but I doubt we'll expose big.LITTLE to guests any time soon.
It's going to be years, so I am not particularly worried about it right
now.


> Because the versatile express machine sets smp_init to
> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> Xen.
> 
> With this patch, xen_smp_init will be called instead of
> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> therefore *unbreaking* Xen.
> 
> In fact what makes this patch really necessary is smp_init together with
> the MCPM series.
> 
> 
> Do you agree with me?
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

On Fri, 5 Apr 2013, Rob Herring wrote:
> On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > 
> >> This is what happens:
> >>
> >> - No Xen
> >> Xen is not running on the platform and a Xen hypervisor node is not
> >> available on device tree.
> >> Everything keeps working seamlessly, this patch doesn't change anything.
> >>
> >> - we are running on Xen
> >> Xen is running on the platform, we are running as a guest on Xen and an
> >> hypervisor node is available on device tree.
> >> Let's also assume that there aren't any "arm,cci" compatible nodes on
> >> device tree because Xen wouldn't export this kind of information to any
> >> guests right now. Therefore PSCI should be used to boot secondary cpus.
> >> Because the versatile express machine sets smp_init to
> >> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> >> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> >> Xen.
> > 
> > OK I see.
> > 
> >> With this patch, xen_smp_init will be called instead of
> >> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> >> therefore *unbreaking* Xen.
> > 
> > However that breaks MCPM.
> 
> You mean on bare metal, right? For the bare metal, "xen,xen" property
> would not be present and xen_smp_init is not used. So the vexpress MCPM
> ops will be used.

That is correct.


> Aren't Dom0 cpu's basically virtual cpus? If Xen ever
> needs the MCPM support, the Xen hook itself can figure out whether to
> use MCPM support.

Right.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Rob Herring wrote:
> 
> > On 04/05/2013 02:36 PM, Nicolas Pitre wrote:
> > > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> > > 
> > >> This is what happens:
> > >>
> > >> - No Xen
> > >> Xen is not running on the platform and a Xen hypervisor node is not
> > >> available on device tree.
> > >> Everything keeps working seamlessly, this patch doesn't change anything.
> > >>
> > >> - we are running on Xen
> > >> Xen is running on the platform, we are running as a guest on Xen and an
> > >> hypervisor node is available on device tree.
> > >> Let's also assume that there aren't any "arm,cci" compatible nodes on
> > >> device tree because Xen wouldn't export this kind of information to any
> > >> guests right now. Therefore PSCI should be used to boot secondary cpus.
> > >> Because the versatile express machine sets smp_init to
> > >> vexpress_smp_init_ops, vexpress_smp_init_ops will be called.
> > >> vexpress_smp_init_ops sets smp_ops to vexpress_smp_ops, that *break*
> > >> Xen.
> > > 
> > > OK I see.
> > > 
> > >> With this patch, xen_smp_init will be called instead of
> > >> vexpress_smp_init_ops, and smp_ops will be set to psci_smp_ops,
> > >> therefore *unbreaking* Xen.
> > > 
> > > However that breaks MCPM.
> > 
> > You mean on bare metal, right? For the bare metal, "xen,xen" property
> > would not be present and xen_smp_init is not used. So the vexpress MCPM
> > ops will be used. Aren't Dom0 cpu's basically virtual cpus? If Xen ever
> > needs the MCPM support, the Xen hook itself can figure out whether to
> > use MCPM support.
> 
> Well, if Xen has its own mdesc distinct from the VExpress one then 
> things
> are indeed fine.

It's not about the mdesc: Xen has its own hypervisor node on device tree
if and only if Xen is running on the platform, therefore the Xen early
hook is never going to do anything at all on native.

In other words, this patch should NOT change the behaviour of Linux on
native, and if it did, it would be a bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] x86: Hyper-V: register clocksource only if its advertised

[Stefano Stabellini]

On Tue, 29 Jan 2013, KY Srinivasan wrote:
> > The patch which started this thread is still valid because it enables
> > feature B only if the featurebit for B is enabled.
> 
> Why would we need this if we have some other way of detecting that Hyper-V is 
> being
> emulated.

I don't think that Hyper-V being emulated or not matters here.
What matters is whether the feature is available: only if it is then it
should be used.


> Furthermore, I am not sure I understand the logic here. The fact that the 
> hypervisor
> supports PARTITION_REFERENCE_COUNTER does not necessarily mean that we should 
> register
> a clocksource based on that reference counter. It is true that that is the 
> case on Hyper-V today.
> However, on other hypervisors emulating Hyper-V, other standard clocksources 
> maybe more
> appropriate.

The point is that if a feature is NOT supported, then it should NOT be
used. Only if it is supported, then Linux might consider using it. And
of course can decide not to use it.


> I agree with you that your patch is valid for making the Hyper-V code more 
> robust but not for dealing
> with general issue of Xen emulating Hyper-V.

What "general issue" would that be?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] x86: Hyper-V: register clocksource only if its advertised

[Stefano Stabellini]

On Tue, 29 Jan 2013, KY Srinivasan wrote:
> > > I agree with you that your patch is valid for making the Hyper-V code more
> > robust but not for dealing
> > > with general issue of Xen emulating Hyper-V.
> > 
> > What "general issue" would that be?
> 
> Not all Hyper-V specific features are advertised via a feature bit. For 
> instance, we need to reserve
> an IDT entry to have VMBUS interrupts delivered on a per-CPU basis and this 
> reservation is done
> after confirming that we are running on Hyper-V. With Xen emulating Hyper-V, 
> we have an issue.
> Since Hyper-V will never emulate Xen, I am going to add a check in the 
> Hyper-V detection code to
> deal with this issue.

I personally think that it would be much nicer to have a feature flag
somewhere to advertise per-CPU VMBUS interrupts.
However adding a check in the Hyper-V detection code is OK too for me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] X86: Add a check to catch Xen emulation of Hyper-V

[Stefano Stabellini]

On Thu, 31 Jan 2013, H. Peter Anvin wrote:
> On 01/30/2013 12:53 AM, Jan Beulich wrote:
> > 
> > I'm not convinced that's the right approach - any hypervisor
> > could do similar emulation, and hence you either want to make
> > sure you run on Hyper-V (by excluding all others), or you
> > tolerate using the emulation (which may require syncing up with
> > the other guest implementations so that shared resources don't
> > get used by two parties).
> > 
> > I also wonder whether using the Hyper-V emulation (where
> > useful, there might not be anything right now, but this may
> > change going forward) when no Xen support is configured
> > wouldn't be better than not using anything...
> > 
> 
> I'm confused about "the right approach" here is.  As far as I
> understand, this only can affect a Xen guest where HyperV guest support
> is enabled but not Xen support, and only because Xen emulates HyperV but
> does so incorrectly.
> 
> This is a Xen bug, and as such it makes sense to reject Xen
> specifically.  If another hypervisor emulates HyperV and does so
> correctly there seems to be no reason to reject it.

I don't think so.

AFAIK originally there were features exported as flags and Xen doesn't
turn on the flags that correspond to features that are not implemented.
The problem here is that Hyper-V is about to introduce a feature without
a flag that is not implemented by Xen (see "X86: Deliver Hyper-V
interrupts on a separate IDT vector").
K.Y. please confirm if I got this right.

If I were the Microsoft engineer implementing this feature, no matter
what Xen does or does not, I would also make sure that there is a
corresponding flag for it, because in my experience they avoid future
headaches.
I wonder what happens if you run Linux with Hyper-V support on an old
Hyper-V host that doesn't support vector injection.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] x86: Hyper-V: register clocksource only if its advertised

[Stefano Stabellini]

On Fri, 25 Jan 2013, KY Srinivasan wrote:
> > -Original Message-
> > From: Olaf Hering [mailto:o...@aepfle.de]
> > Sent: Friday, January 25, 2013 12:19 PM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; Greg KH; Jan Beulich (jbeul...@suse.com)
> > Subject: Re: [PATCH] x86: Hyper-V: register clocksource only if its 
> > advertised
> > 
> > On Fri, Jan 25, KY Srinivasan wrote:
> > 
> > > My fear is that there is no guarantee that Xen would not emulate this
> > > feature in the spirit of making Hyper-V emulation "more" complete.
> > > Since all this problem is because Xen thinks it is running a viridian
> > > domain (when in fact it is running Linux), I felt we should explore
> > > why the viridian tag got set for a Linux VM. If we can fix that we
> > > would have a solution that does not depend upon assuming that Xen
> > > would not emulate a particular Hyper-V feature.
> > 
> > In my opinion this logic is backwards. A host provides a set of
> > functionality/features to a given guest, no matter what runs inside the
> > guest. And the guest can query the feature list and configure itself
> > accordingly. In this specific case the guest finds feature A (the cpuid
> > result) and expects that feature B (a clock source) is present as well,
> > even if feature B has its very own availability flag.
> 
> I would agree with you in the abstract but not in this specific case. First,
> the current Hyper-V code in Linux verifies that the underlying hypervisor is
> Hyper-V and proceeds to setup state that is needed to run Linux on Hyper-V.
> If Xen were not emulating Hyper-V, we would not have any issue here. However,
> Xen does emulate Hyper-V and it is emulating Hyper-V not to run Linux, but to 
> run
> enlightened Windows (making Windows think it is running on Hyper-V). We have 
> a 
> mechanism in place for controlling this Hyper-V emulation in Xen - the 
> viridian flag.
> In my view, ensuring that this flag is not set for a non -Windows guest is 
> the only safe
> approach to dealing with this issue. Your current approach of using the 
> "Partition Reference
> Counter" feature bit is very fragile. Let us assume that future Windows 
> guests depend on this
> feature; Xen would certainly emulate this to have a "good" emulation of 
> Hyper-V and we are
> back to square one.

I think that Olaf made his point very clear: a feature A should only be
enabled if the corresponding flag A is set.
In fact it seems to me that this patch is correct on its own merits,
regardless of Xen does or does not.

The Xen tools might or might not know whether a guest is going to be
Linux, Windows, FreeBSD or whatever else people use nowadays.  Setting
viridian=1 is the safe choice, given that it shouldn't create any
issues: after all guests are supposed to check for feature flags before
using them.

If Xen is going to implement "Partition Reference Counter", it is also
going to set the corresponding flag, so the guest OS (Windows, Linux,
my pet OS) can check whether the feature is available and decide whether
it wants to use it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -v4 5/5] x86,smp: limit spinlock delay on virtual machines

[Stefano Stabellini]

On Fri, 25 Jan 2013, Rik van Riel wrote:
> Modern Intel and AMD CPUs will trap to the host when the guest
> is spinning on a spinlock, allowing the host to schedule in
> something else.
> 
> This effectively means the host is taking care of spinlock
> backoff for virtual machines. It also means that doing the
> spinlock backoff in the guest anyway can lead to totally
> unpredictable results, extremely large backoffs, and
> performance regressions.
> 
> To prevent those problems, we limit the spinlock backoff
> delay, when running in a virtual machine, to a small value.
> 
> Signed-off-by: Rik van Riel 
> ---
>  arch/x86/include/asm/processor.h |2 ++
>  arch/x86/kernel/setup.c  |2 ++
>  arch/x86/kernel/smp.c|   30 --
>  3 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 888184b..a365f97 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -997,6 +997,8 @@ extern bool cpu_has_amd_erratum(const int *);
>  extern unsigned long arch_align_stack(unsigned long sp);
>  extern void free_init_pages(char *what, unsigned long begin, unsigned long 
> end);
>  
> +extern void init_spinlock_delay(void);
> +
>  void default_idle(void);
>  bool set_pm_idle_to_default(void);
>  
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 23ddd55..b834eae 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1048,6 +1048,8 @@ void __init setup_arch(char **cmdline_p)
>  
>   arch_init_ideal_nops();
>  
> + init_spinlock_delay();
> +
>   register_refined_jiffies(CLOCK_TICK_RATE);
>  
>  #ifdef CONFIG_EFI
> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> index 1877890..b1a65f0 100644
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  /*
>   *   Some notes on x86 processor bugs affecting SMP operation:
>   *
> @@ -114,6 +115,27 @@ static atomic_t stopping_cpu = ATOMIC_INIT(-1);
>  static bool smp_no_nmi_ipi = false;
>  
>  /*
> + * Modern Intel and AMD CPUs tell the hypervisor when a guest is
> + * spinning excessively on a spinlock.

I take that you are talking about PAUSE-loop exiting?


> The hypervisor will then
> + * schedule something else, effectively taking care of the backoff
> + * for us. Doing our own backoff on top of the hypervisor's pause
> + * loop exit handling can lead to excessively long delays, and
> + * performance degradations. Limit the spinlock delay in virtual
> + * machines to a smaller value.
> + */
> +#define DELAY_SHIFT 8
> +#define DELAY_FIXED_1 (1< +#define MIN_SPINLOCK_DELAY (1 * DELAY_FIXED_1)
> +#define MAX_SPINLOCK_DELAY_NATIVE (16000 * DELAY_FIXED_1)
> +#define MAX_SPINLOCK_DELAY_GUEST (16 * DELAY_FIXED_1)
> +static int __read_mostly max_spinlock_delay = MAX_SPINLOCK_DELAY_NATIVE;
> +void __init init_spinlock_delay(void)
> +{
> + if (x86_hyper)
> + max_spinlock_delay = MAX_SPINLOCK_DELAY_GUEST;
> +}

Before reducing max_spinlock_delay, shouldn't we check that PAUSE-loop
exiting is available? What if we are running on an older x86 machine
that doesn't support it?

It is probably worth mentioning in the comment that Xen PV guests cannot
take advantage of PAUSE-loop exiting (they don't run inside a VMX
environment), but that's OK because Xen PV guests don't set x86_hyper.

On the other hand Xen PV on HVM guests can take advantage of it (they
run in a VMX environment), and in fact they set x86_hyper to
x86_hyper_xen_hvm.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch/x86/xen: remove depends on CONFIG_EXPERIMENTAL

[Stefano Stabellini]

On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> >  wrote:
> > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook  wrote:
> > >>
> > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > >> while now and is almost always enabled by default. As agreed during the
> > >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > >>
> > >> Signed-off-by: Kees Cook 
> > >> Cc: Stefano Stabellini 
> > >> Cc: Mukesh Rathor 
> > >> Cc: Konrad Rzeszutek Wilk 
> > >> ---
> > >>  arch/x86/xen/Kconfig |2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > >> index 93ff4e1..8cada4c 100644
> > >> --- a/arch/x86/xen/Kconfig
> > >> +++ b/arch/x86/xen/Kconfig
> > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > >>
> > >>  config XEN_X86_PVH
> > >> bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > >
> > > Why not remove this 'EXPERIMENTAL' too ?
> > 
> > It was unclear to me if the feature was actually considered unstable.
> > I can resend with the text removed from the title too, if that's the
> > correct action here?
> 
> It certainly is unstable right now (which is why it was unstaged from
> the v3.9 train). I hope that by v3.10 it won't be - at which
> point this patch (and the EXPERIMENTAL) makes sense.
> 
> So could you respin it please with the text removed as well - and I will
> queue it up in the branch that carries the PVH feature?

We also have the same flag on Xen ARM, and the reason is that the ABI is
not stable yet. As soon as it is (I think soon now), I'll send a patch
to remove EXPERIMENTAL from there too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] arch/x86/xen: remove depends on CONFIG_EXPERIMENTAL

[Stefano Stabellini]

On Mon, 25 Feb 2013, Ian Campbell wrote:
> On Sat, 2013-02-23 at 20:47 +0000, Stefano Stabellini wrote:
> > On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > > On Sat, Feb 23, 2013 at 09:03:20AM -0800, Kees Cook wrote:
> > > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > > >  wrote:
> > > > > On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook  
> > > > > wrote:
> > > > >>
> > > > >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for 
> > > > >> a
> > > > >> while now and is almost always enabled by default. As agreed during 
> > > > >> the
> > > > >> Linux kernel summit, remove it from any "depends on" lines in 
> > > > >> Kconfigs.
> > > > >>
> > > > >> Signed-off-by: Kees Cook 
> > > > >> Cc: Stefano Stabellini 
> > > > >> Cc: Mukesh Rathor 
> > > > >> Cc: Konrad Rzeszutek Wilk 
> > > > >> ---
> > > > >>  arch/x86/xen/Kconfig |2 +-
> > > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >>
> > > > >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > > >> index 93ff4e1..8cada4c 100644
> > > > >> --- a/arch/x86/xen/Kconfig
> > > > >> +++ b/arch/x86/xen/Kconfig
> > > > >> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > > > >>
> > > > >>  config XEN_X86_PVH
> > > > >> bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > > > >
> > > > > Why not remove this 'EXPERIMENTAL' too ?
> > > > 
> > > > It was unclear to me if the feature was actually considered unstable.
> > > > I can resend with the text removed from the title too, if that's the
> > > > correct action here?
> > > 
> > > It certainly is unstable right now (which is why it was unstaged from
> > > the v3.9 train). I hope that by v3.10 it won't be - at which
> > > point this patch (and the EXPERIMENTAL) makes sense.
> > > 
> > > So could you respin it please with the text removed as well - and I will
> > > queue it up in the branch that carries the PVH feature?
> > 
> > We also have the same flag on Xen ARM, and the reason is that the ABI is
> > not stable yet. As soon as it is (I think soon now), I'll send a patch
> > to remove EXPERIMENTAL from there too.
> 
> In the meantime if the depends EXPERIMENTAL is going away perhaps we
> should explain the EXPERIMENTAL in the title:
> 
> 8<
> 
> From bc22bd0f7b20296c449a05d82be950922042bc92 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Thu, 4 Oct 2012 09:12:51 +0100
> Subject: [PATCH] arm: xen: explain the EXPERIMENTAL dependency in the Kconfig 
> help
> 
> Signed-off-by: Ian Campbell 
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org

Acked-by: Stefano Stabellini 


>  arch/arm/Kconfig |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 67874b8..ef14873 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1865,6 +1865,14 @@ config XEN
>   help
> Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> +
> +   This option is EXPERIMENTAL because the hypervisor
> +   interfaces which it uses are not yet considered stable
> +   therefore backwards and forwards compatibility is not yet
> +   guaranteed.
> +
> +   If unsure, say N.
> +
>  endmenu
>  
>  menu "Boot options"
> -- 
> 1.7.2.5
> 
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch/x86/xen: remove depends on CONFIG_EXPERIMENTAL

[Stefano Stabellini]

On Sun, 24 Feb 2013, Greg Kroah-Hartman wrote:
> On Sun, Feb 24, 2013 at 05:51:44PM +0800, Dongsheng Song wrote:
> > On Sun, Feb 24, 2013 at 1:03 AM, Kees Cook  wrote:
> > > On Sat, Feb 23, 2013 at 3:59 AM, Dongsheng Song
> > >  wrote:
> > >> On Sat, Feb 23, 2013 at 3:29 PM, Kees Cook  wrote:
> > >>>
> > >>> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> > >>> while now and is almost always enabled by default. As agreed during the
> > >>> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> > >>>
> > >>> Signed-off-by: Kees Cook 
> > >>> Cc: Stefano Stabellini 
> > >>> Cc: Mukesh Rathor 
> > >>> Cc: Konrad Rzeszutek Wilk 
> > >>> ---
> > >>>  arch/x86/xen/Kconfig |2 +-
> > >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > >>> index 93ff4e1..8cada4c 100644
> > >>> --- a/arch/x86/xen/Kconfig
> > >>> +++ b/arch/x86/xen/Kconfig
> > >>> @@ -53,7 +53,7 @@ config XEN_DEBUG_FS
> > >>>
> > >>>  config XEN_X86_PVH
> > >>> bool "Support for running as a PVH guest (EXPERIMENTAL)"
> > >>
> > >> Why not remove this 'EXPERIMENTAL' too ?
> > >
> > > It was unclear to me if the feature was actually considered unstable.
> > > I can resend with the text removed from the title too, if that's the
> > > correct action here?
> > >
> > > -Kees
> > >
> > 
> > If such a feature was considered unstable, it should depends on 
> > EXPERIMENTAL.
> 
> CONFIG_EXPERIMENTAL is going away.
> 
> > We should not surprised users.
> 
> You should not have unstable options in the kernel in the first place,
> sorry.
 
With the premise that the removal of CONFIG_EXPERIMENTAL is not an issue
for me personally or my work, I am going to give you my 2 cents on the
matter, but feel free to ignore them :)

While I understand that CONFIG_EXPERIMENTAL has been abused, I feel that
rejecting everything that is not fully stable and with external
interfaces set in stones, might hinder the development of new features.

After all, given how fast the kernel is moving nowadays, maintaining a
project out-of-tree until is completely ready for production can be
very expensive. Merging the project earlier and completing the
development upstream can bring better results. But in these cases one
wouldn't want to "market" the feature as stable yet, because it just
isn't. If CONFIG_EXPERIMENTAL is going away, is there anything in the
kernel that can be used to tag a feature as "I wouldn't use it in
production if I were you"? Maybe just a comment in the kconfig
description?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] arch/x86/xen: remove depends on CONFIG_EXPERIMENTAL

[Stefano Stabellini]

On Thu, 28 Feb 2013, Kees Cook wrote:
> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> while now and is almost always enabled by default. As agreed during the
> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> 
> Signed-off-by: Kees Cook 
> Cc: Stefano Stabellini 
> Cc: Mukesh Rathor 
> Cc: Konrad Rzeszutek Wilk 
> ---
> 
> v2:
>  - drop EXPERIMENTAL from bool and help text too.
> 
> ---
>  arch/x86/xen/Kconfig |8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 93ff4e1..6c5802f 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
> Enabling this option may incur a significant performance overhead.
>  
>  config XEN_X86_PVH
> - bool "Support for running as a PVH guest (EXPERIMENTAL)"
> - depends on X86_64 && XEN && EXPERIMENTAL
> + bool "Support for running as a PVH guest"
> + depends on X86_64 && XEN
>   default n
>   help
>  This option enables support for running as a PVH guest (PV guest
>  using hardware extensions) under a suitably capable hypervisor.
> -This option is EXPERIMENTAL because the hypervisor interfaces
> -which it uses is not yet considered stable therefore backwards and
> -forwards compatibility is not yet guaranteed.  If unsure, say N.
> +If unsure, say N.

Please do not change the text this way.
The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
fact that this feature is experimental.
Maybe you want to replace EXPERIMENTAL with experimental, or if
experimental has become as taboo word, I am sure you can find a suitable
synonym.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] arch/x86/xen: remove depends on CONFIG_EXPERIMENTAL

[Stefano Stabellini]

On Thu, 28 Feb 2013, Kees Cook wrote:
> On Thu, Feb 28, 2013 at 2:53 PM, Stefano Stabellini
>  wrote:
> > On Thu, 28 Feb 2013, Kees Cook wrote:
> >> The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
> >> while now and is almost always enabled by default. As agreed during the
> >> Linux kernel summit, remove it from any "depends on" lines in Kconfigs.
> >>
> >> Signed-off-by: Kees Cook 
> >> Cc: Stefano Stabellini 
> >> Cc: Mukesh Rathor 
> >> Cc: Konrad Rzeszutek Wilk 
> >> ---
> >>
> >> v2:
> >>  - drop EXPERIMENTAL from bool and help text too.
> >>
> >> ---
> >>  arch/x86/xen/Kconfig |8 +++-
> >>  1 file changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> >> index 93ff4e1..6c5802f 100644
> >> --- a/arch/x86/xen/Kconfig
> >> +++ b/arch/x86/xen/Kconfig
> >> @@ -52,12 +52,10 @@ config XEN_DEBUG_FS
> >> Enabling this option may incur a significant performance overhead.
> >>
> >>  config XEN_X86_PVH
> >> - bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >> - depends on X86_64 && XEN && EXPERIMENTAL
> >> + bool "Support for running as a PVH guest"
> >> + depends on X86_64 && XEN
> >>   default n
> >>   help
> >>  This option enables support for running as a PVH guest (PV guest
> >>  using hardware extensions) under a suitably capable hypervisor.
> >> -This option is EXPERIMENTAL because the hypervisor interfaces
> >> -which it uses is not yet considered stable therefore backwards and
> >> -forwards compatibility is not yet guaranteed.  If unsure, say N.
> >> +If unsure, say N.
> >
> > Please do not change the text this way.
> > The fact that CONFIG_EXPERIMENTAL is going away it doesn't change the
> > fact that this feature is experimental.
> > Maybe you want to replace EXPERIMENTAL with experimental, or if
> > experimental has become as taboo word, I am sure you can find a suitable
> > synonym.
> 
> Ah, sorry, I misunderstood what was being recommended from the other
> thread (quoting below...)
> 
> On Sat, 23 Feb 2013, Konrad Rzeszutek Wilk wrote:
> > It certainly is unstable right now (which is why it was unstaged from
> > the v3.9 train). I hope that by v3.10 it won't be - at which
> > point this patch (and the EXPERIMENTAL) makes sense.
> 
> Only "depends on EXPERIMENTAL" must go away. Did you want either the
> bool or help text to go away too? If neither, my original patch should
> work. If you only want the bool text gone, I can send that version
> instead.

I think your original patch is good, but I'll let Konrad decide.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] xen: introduce xen_remap, use it instead of ioremap

[Stefano Stabellini]

ioremap can't be used to map ring pages on ARM because it uses device
memory caching attributes (MT_DEVICE*).

Introduce a Xen specific abstraction to map ring pages, called
xen_remap, that is defined as ioremap on x86 (no behavioral changes).
On ARM it explicitly calls __arm_ioremap with the right caching
attributes: MT_MEMORY.

Signed-off-by: Stefano Stabellini 

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index c6b9096..30cdacb 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,6 +1,7 @@
 #ifndef _ASM_ARM_XEN_PAGE_H
 #define _ASM_ARM_XEN_PAGE_H
 
+#include 
 #include 
 #include 
 
@@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, 
unsigned long mfn)
 {
return __set_phys_to_machine(pfn, mfn);
 }
+
+#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
+
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6aef9fb 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
 void make_lowmem_page_readonly(void *vaddr);
 void make_lowmem_page_readwrite(void *vaddr);
 
+#define xen_remap(cookie, size) ioremap((cookie), (size));
+
 #endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 19843ec..682210d7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r < 0 || v == 0)
goto err;
mfn = v;
-   info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+   info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
if (info->intf == NULL)
goto err;
info->vtermno = HVC_COOKIE;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7038de5..1c2a1e5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,7 +1146,7 @@ int gnttab_resume(void)
return gnttab_map(0, nr_grant_frames - 1);
 
if (gnttab_shared.addr == NULL) {
-   gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+   gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
PAGE_SIZE * max_nr_gframes);
if (gnttab_shared.addr == NULL) {
printk(KERN_WARNING
diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index 038b71d..3325884 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -769,7 +769,7 @@ static int __init xenbus_init(void)
goto out_error;
xen_store_mfn = (unsigned long)v;
xen_store_interface =
-   ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
+   xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
break;
default:
pr_warn("Xenstore state unknown\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen: introduce xen_remap, use it instead of ioremap

[Stefano Stabellini]

On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 01:59:19PM +0000, Stefano Stabellini wrote:
> > ioremap can't be used to map ring pages on ARM because it uses device
> > memory caching attributes (MT_DEVICE*).
> > 
> > Introduce a Xen specific abstraction to map ring pages, called
> > xen_remap, that is defined as ioremap on x86 (no behavioral changes).
> > On ARM it explicitly calls __arm_ioremap with the right caching
> > attributes: MT_MEMORY.
> 
> Do you want to push this to Linus yourself or should I just include it
> in my 'for-39' tree?
> 
> Do you have other patches for 3.9?

Ian has two patches ("linux: public interface changes for arm"), it
would be great if they could go in 3.9.
Given the small number of patches (three all together), it is probably
easier to go via your tree, if you are OK with that.



> > Signed-off-by: Stefano Stabellini 
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h 
> > b/arch/arm/include/asm/xen/page.h
> > index c6b9096..30cdacb 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -1,6 +1,7 @@
> >  #ifndef _ASM_ARM_XEN_PAGE_H
> >  #define _ASM_ARM_XEN_PAGE_H
> >  
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn, 
> > unsigned long mfn)
> >  {
> > return __set_phys_to_machine(pfn, mfn);
> >  }
> > +
> > +#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
> > +
> >  #endif /* _ASM_ARM_XEN_PAGE_H */
> > diff --git a/arch/x86/include/asm/xen/page.h 
> > b/arch/x86/include/asm/xen/page.h
> > index 472b9b7..6aef9fb 100644
> > --- a/arch/x86/include/asm/xen/page.h
> > +++ b/arch/x86/include/asm/xen/page.h
> > @@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
> >  void make_lowmem_page_readonly(void *vaddr);
> >  void make_lowmem_page_readwrite(void *vaddr);
> >  
> > +#define xen_remap(cookie, size) ioremap((cookie), (size));
> > +
> >  #endif /* _ASM_X86_XEN_PAGE_H */
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index 19843ec..682210d7 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> > if (r < 0 || v == 0)
> > goto err;
> > mfn = v;
> > -   info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > +   info->intf = xen_remap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > if (info->intf == NULL)
> > goto err;
> > info->vtermno = HVC_COOKIE;
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index 7038de5..1c2a1e5 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -1146,7 +1146,7 @@ int gnttab_resume(void)
> > return gnttab_map(0, nr_grant_frames - 1);
> >  
> > if (gnttab_shared.addr == NULL) {
> > -   gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
> > +   gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
> > PAGE_SIZE * max_nr_gframes);
> > if (gnttab_shared.addr == NULL) {
> > printk(KERN_WARNING
> > diff --git a/drivers/xen/xenbus/xenbus_probe.c 
> > b/drivers/xen/xenbus/xenbus_probe.c
> > index 038b71d..3325884 100644
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -769,7 +769,7 @@ static int __init xenbus_init(void)
> > goto out_error;
> > xen_store_mfn = (unsigned long)v;
> > xen_store_interface =
> > -   ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > +   xen_remap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > break;
> > default:
> > pr_warn("Xenstore state unknown\n");
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH XEN] xen: event channel arrays are xen_ulong_t and not unsigned long

[Stefano Stabellini]

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 
> Cc: Keir (Xen.org) 
> Cc: Tim Deegan 
> Cc: Stefano Stabellini 
> Cc: Konrad Rzeszutek Wilk 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xen.org

Acked-by: Stefano Stabellini 


>  tools/include/xen-foreign/mkheader.py |6 ++
>  xen/include/public/xen.h  |8 
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/include/xen-foreign/mkheader.py 
> b/tools/include/xen-foreign/mkheader.py
> index d189b07..57681fa 100644
> --- a/tools/include/xen-foreign/mkheader.py
> +++ b/tools/include/xen-foreign/mkheader.py
> @@ -21,13 +21,18 @@ inttypes["arm"] = {
>  "unsigned long" : "uint32_t",
>  "long"  : "uint32_t",
>  "xen_pfn_t" : "uint64_t",
> +"xen_ulong_t"   : "uint64_t",
>  };
> +header["arm"] = """
> +#define __arm___ARM32 1
> +""";
>  
>  # x86_32
>  inttypes["x86_32"] = {
>  "unsigned long" : "uint32_t",
>  "long"  : "uint32_t",
>  "xen_pfn_t" : "uint32_t",
> +"xen_ulong_t"   : "uint32_t",
>  };
>  header["x86_32"] = """
>  #define __i386___X86_32 1
> @@ -42,6 +47,7 @@ inttypes["x86_64"] = {
>  "unsigned long" : "__align8__ uint64_t",
>  "long"  : "__align8__ uint64_t",
>  "xen_pfn_t" : "__align8__ uint64_t",
> +"xen_ulong_t"   : "__align8__ uint64_t",
>  };
>  header["x86_64"] = """
>  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 5593066..99c8212 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
>   * Event channel endpoints per domain:
>   *  1024 if a long is 32 bits; 4096 if a long is 64 bits.
>   */
> -#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 
> 64)
> +#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
>  
>  struct vcpu_time_info {
>  /*
> @@ -613,7 +613,7 @@ struct vcpu_info {
>   */
>  uint8_t evtchn_upcall_pending;
>  uint8_t evtchn_upcall_mask;
> -unsigned long evtchn_pending_sel;
> +xen_ulong_t evtchn_pending_sel;
>  struct arch_vcpu_info arch;
>  struct vcpu_time_info time;
>  }; /* 64 bytes (x86) */
> @@ -663,8 +663,8 @@ struct shared_info {
>   * per-vcpu selector word to be set. Each bit in the selector covers a
>   * 'C long' in the PENDING bitfield array.
>   */
> -unsigned long evtchn_pending[sizeof(unsigned long) * 8];
> -unsigned long evtchn_mask[sizeof(unsigned long) * 8];
> +xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
> +xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
>  
>  /*
>   * Wallclock time: updated only by control software. Guests should base
> -- 
> 1.7.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH LINUX] xen: event channel arrays are xen_ulong_t and not unsigned long

[Stefano Stabellini]

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 
> Cc: Keir (Xen.org) 
> Cc: Tim Deegan 
> Cc: Stefano Stabellini 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xen.org
> ---
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 
>  arch/x86/include/asm/xen/events.h |3 +
>  drivers/xen/events.c  |  103 
> -
>  include/xen/interface/xen.h   |8 ++--
>  4 files changed, 84 insertions(+), 52 deletions(-)

You might have to rebase this patch: it doesn't apply on Linux 3.8.


> diff --git a/arch/arm/include/asm/xen/events.h 
> b/arch/arm/include/asm/xen/events.h
> index 94b4e90..9bb5f50 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
> 
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +   xen_ulong_t oldval;
> +   unsigned int tmp;
> +
> +   wmb();
> +   asm volatile("@ read_evtchn_pending_sel\n"
   ^ do we need this?


> +   "1: ldrexd  %0, %H0, [%3]\n"
> +   "   strexd  %1, %2, %H2, [%3]\n"
> +   "   teq %1, #0\n"
> +   "   bne 1b"
> +   : "=&r" (oldval), "=&r" (tmp)
> +   : "r" (val), "r" (ptr)
> +   : "memory", "cc");
> +   return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */

[...]

> @@ -1295,18 +1306,14 @@ static void __xen_evtchn_do_upcall(void)
> unsigned count;
> 
> do {
> -   unsigned long pending_words;
> +   xen_ulong_t pending_words;
> 
> vcpu_info->evtchn_upcall_pending = 0;
> 
> if (__this_cpu_inc_return(xed_nesting_count) - 1)
> goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -   /* Clear master flag /before/ clearing selector flag. */
> -   wmb();
> -#endif

Even though I understand that moving wmb() into xchg_xen_ulong gets rid
of an ugly ifndef, I am not sure whether it is a good thing from the
code readability point of view. I'll let Konrad decide on this one.


> -   pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +   pending_words = 
> xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
> start_word_idx = __this_cpu_read(current_word_idx);
> start_bit_idx = __this_cpu_read(current_bit_idx);
> @@ -1314,8 +1321,8 @@ static void __xen_evtchn_do_upcall(void)
> word_idx = start_word_idx;
> 
> for (i = 0; pending_words != 0; i++) {
> -   unsigned long pending_bits;
> -   unsigned long words;
> +   xen_ulong_t pending_bits;
> +   xen_ulong_t words;
> 
> words = MASK_LSBS(pending_words, word_idx);
> 
> @@ -1327,7 +1334,7 @@ static void __xen_evtchn_do_upcall(void)
> bit_idx = 0;
> continue;
> }
> -   word_idx = __ffs(words);
> +   word_idx = find_first_bit(BM(&words), sizeof(words));
> 
> pending_bits = active_evtchns(cpu, s, word_idx);
> bit_idx = 0; /* usually scan entire word from start */

is that because find_first_bit can actually cope with a bit number >=
32 and __ffs can't?
In that case it is worth adding a comment somewhere in this file,
reminding people to only use bit operations that can handle size >
unsigned long

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH LINUX v4] xen: event channel arrays are xen_ulong_t and not unsigned long

[Stefano Stabellini]

On Tue, 19 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 
> Cc: Keir (Xen.org) 
> Cc: Tim Deegan 
> Cc: Stefano Stabellini 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xen.org
> Cc: Konrad Rzeszutek Wilk 
> ---
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...

still doesn't apply to 3.8


> do {
> -   unsigned long pending_words;
> +   xen_ulong_t pending_words;
> 
> vcpu_info->evtchn_upcall_pending = 0;
> 
> if (__this_cpu_inc_return(xed_nesting_count) - 1)
> goto out;
> 
> -#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x86. */
> -   /* Clear master flag /before/ clearing selector flag. */
> -   wmb();
> -#endif
> -   pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
> +   /*
> +* Master flag must be /before/ clearing selector
> +* flag. xchg_xen_ulong must contain an appropriate
> +* barrier.
> +*/

Master flag must be *cleared* ...

> +   pending_words = 
> xchg_xen_ulong(&vcpu_info->evtchn_pending_sel, 0);
> 
> start_word_idx = __this_cpu_read(current_word_idx);
> start_bit_idx = __this_cpu_read(current_bit_idx);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long

[Stefano Stabellini]

On Wed, 20 Feb 2013, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
> 
> This is an ABI change on ARM. X86 does not change.
> 
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 
> Cc: Keir (Xen.org) 
> Cc: Tim Deegan 
> Cc: Stefano Stabellini 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: xen-de...@lists.xen.org
> Cc: Konrad Rzeszutek Wilk 

Acked-by: Stefano Stabellini 


> Changes since V4
>   Rebase onto v3.8
>   Fix wording of comment
>   Fix bitmask length passed to find_first_bit, need sizeof*8 for bits not just
>   sizeof. Use BITS_PER_EVTCHN_WORD and provide a convenience wrapper.
> Changes since V3
>   s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> Changes since V2
>   Add comments about the correct bitops to use, and on the ordering/barrier
>   requirements on xchg_xen_ulong.
> Changes since V1
>   use find_first_set not __ffs
>   fix some more unsigned long -> xen_ulong_t
>   use more generic xchg_xen_ulong instead of ...read_evtchn...
> ---
>  arch/arm/include/asm/xen/events.h |   22 +++
>  arch/x86/include/asm/xen/events.h |3 +
>  drivers/xen/events.c  |  115 +---
>  include/xen/interface/xen.h   |8 +-
>  4 files changed, 96 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/events.h 
> b/arch/arm/include/asm/xen/events.h
> index 94b4e90..5c27696 100644
> --- a/arch/arm/include/asm/xen/events.h
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> return raw_irqs_disabled_flags(regs->ARM_cpsr);
>  }
> 
> +/*
> + * We cannot use xchg because it does not support 8-byte
> + * values. However it is safe to use {ldr,dtd}exd directly because all
> + * platforms which Xen can run on support those instructions.
> + */
> +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> +{
> +   xen_ulong_t oldval;
> +   unsigned int tmp;
> +
> +   wmb();
> +   asm volatile("@ xchg_xen_ulong\n"
> +   "1: ldrexd  %0, %H0, [%3]\n"
> +   "   strexd  %1, %2, %H2, [%3]\n"
> +   "   teq %1, #0\n"
> +   "   bne 1b"
> +   : "=&r" (oldval), "=&r" (tmp)
> +   : "r" (val), "r" (ptr)
> +   : "memory", "cc");
> +   return oldval;
> +}
> +
>  #endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/x86/include/asm/xen/events.h 
> b/arch/x86/include/asm/xen/events.h
> index cc146d5..ca842f2 100644
> --- a/arch/x86/include/asm/xen/events.h
> +++ b/arch/x86/include/asm/xen/events.h
> @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> return raw_irqs_disabled_flags(regs->flags);
>  }
> 
> +/* No need for a barrier -- XCHG is a barrier on x86. */
> +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> +
>  #endif /* _ASM_X86_XEN_EVENTS_H */
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 74d77df..dfd62b5 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -120,7 +120,22 @@ static unsigned long *pirq_eoi_map;
>  #endif
>  static bool (*pirq_needs_eoi)(unsigned irq);
> 
> -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> +/*
> + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> + * careful to only use bitops which allow for this (e.g
> + * test_bit/find_first_bit and friends but not __ffs) and to pass
> + * BITS_PER_EVTCHN_WORD as the bitmask length.
> + */
> +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> +/*
> + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> + * array. Primarily to avoid long lines (hence the terse name).
> + */
> +#define BM(x) (unsigned long *)(x)
> +/* Find the first set bit in a evtchn mask */
> +#define EVTCHN_FIRST_BIT(w) find_first_bit(BM(&(w)), BITS_PER_EVTCHN_WORD)
> +
> +static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
>   cpu_evtchn_mask);
> 
>  /* Xen will never allocate port zero for any purpose. */
> @@ -294,9 +309,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
> return info->u.pirq.flags & PIRQ_NEEDS_EOI;
>  }
> 
> -static inline unsigned long active_evtchns(unsigned int cpu,
> -  struct shared_info *sh,
> -  unsigned int idx)
> +static inline xen_ulong_t active_evtchns(unsigned int cpu,

[PATCH] xen/m2p: do not reuse kmap_op->dev_bus_addr

[Stefano Stabellini]

If the caller passes a valid kmap_op to m2p_add_override, we use
kmap_op->dev_bus_addr to store the original mfn, but dev_bus_addr is
part of the interface with Xen and if we are batching the hypercalls it
might not have been written by the hypervisor yet. That means that later
on Xen will write to it and we'll think that the original mfn is
actually what Xen has written to it.

Rather than "stealing" struct members from kmap_op, keep using
page->index to store the original mfn and add another parameter to
m2p_remove_override to get the corresponding kmap_op instead.
It is now responsibility of the caller to keep track of which kmap_op
corresponds to a particular page in the m2p_override (gntdev, the only
user of this interface that passes a valid kmap_op, is already doing that).

Tested-By: Sander Eikelenboom 
Signed-off-by: Stefano Stabellini 

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 93971e8..472b9b7 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,7 +51,8 @@ extern unsigned long set_phys_range_identity(unsigned long 
pfn_s,
 
 extern int m2p_add_override(unsigned long mfn, struct page *page,
struct gnttab_map_grant_ref *kmap_op);
-extern int m2p_remove_override(struct page *page, bool clear_pte);
+extern int m2p_remove_override(struct page *page,
+   struct gnttab_map_grant_ref *kmap_op);
 extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long 
pfn);
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 64effdc..2825594 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -734,9 +734,6 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 
xen_mc_issue(PARAVIRT_LAZY_MMU);
}
-   /* let's use dev_bus_addr to record the old mfn instead */
-   kmap_op->dev_bus_addr = page->index;
-   page->index = (unsigned long) kmap_op;
}
spin_lock_irqsave(&m2p_override_lock, flags);
list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
@@ -763,7 +760,8 @@ int m2p_add_override(unsigned long mfn, struct page *page,
return 0;
 }
 EXPORT_SYMBOL_GPL(m2p_add_override);
-int m2p_remove_override(struct page *page, bool clear_pte)
+int m2p_remove_override(struct page *page,
+   struct gnttab_map_grant_ref *kmap_op)
 {
unsigned long flags;
unsigned long mfn;
@@ -793,10 +791,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
WARN_ON(!PagePrivate(page));
ClearPagePrivate(page);
 
-   if (clear_pte) {
-   struct gnttab_map_grant_ref *map_op =
-   (struct gnttab_map_grant_ref *) page->index;
-   set_phys_to_machine(pfn, map_op->dev_bus_addr);
+   set_phys_to_machine(pfn, page->index);
+   if (kmap_op != NULL) {
if (!PageHighMem(page)) {
struct multicall_space mcs;
struct gnttab_unmap_grant_ref *unmap_op;
@@ -808,13 +804,13 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 * issued. In this case handle is going to -1 because
 * it hasn't been modified yet.
 */
-   if (map_op->handle == -1)
+   if (kmap_op->handle == -1)
xen_mc_flush();
/*
-* Now if map_op->handle is negative it means that the
+* Now if kmap_op->handle is negative it means that the
 * hypercall actually returned an error.
 */
-   if (map_op->handle == GNTST_general_error) {
+   if (kmap_op->handle == GNTST_general_error) {
printk(KERN_WARNING "m2p_remove_override: "
"pfn %lx mfn %lx, failed to 
modify kernel mappings",
pfn, mfn);
@@ -824,8 +820,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
mcs = xen_mc_entry(
sizeof(struct gnttab_unmap_grant_ref));
unmap_op = mcs.args;
-   unmap_op->host_addr = map_op->host_addr;
-   unmap_op->handle = map_op->handle;
+   unmap_op->host_addr = kmap_op->host_addr;
+   unmap_op->handle = kmap_op->handle;
unmap_op->dev_bus_addr = 0;
 
MULTI_grant_table_op(mcs.mc,
@@ -836,10 +832,9 @@ int m2p_remove_override(struct page *page

Re: [PATCH v3 06/25] docs: Xen ARM DT bindings

[Stefano Stabellini]

On Tue, 28 Aug 2012, Rob Herring wrote:
> On 08/16/2012 10:35 AM, Stefano Stabellini wrote:
> > Add a doc to describe the Xen ARM device tree bindings
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: devicetree-disc...@lists.ozlabs.org
> > CC: David Vrabel 
> > ---
> >  Documentation/devicetree/bindings/arm/xen.txt |   22 ++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
> > b/Documentation/devicetree/bindings/arm/xen.txt
> > new file mode 100644
> > index 000..ec6d884
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > @@ -0,0 +1,22 @@
> > +* Xen hypervisor device tree bindings
> > +
> > +Xen ARM virtual platforms shall have the following properties:
> > +
> > +- compatible:
> > +   compatible = "xen,xen", "xen,xen-";
> > +  where  is the version of the Xen ABI of the platform.
> > +
> > +- reg: specifies the base physical address and size of a region in
> > +  memory where the grant table should be mapped to, using an
> > +  HYPERVISOR_memory_op hypercall. 
> > +
> > +- interrupts: the interrupt used by Xen to inject event notifications.
> 
> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> While it is a PPC doc, we should reuse or extend what makes sense.
> 
> See section 7.5:
> 
> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf

Thanks for the link, I wasn't aware of ePAPR.

The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?

Personally I would rather avoid full compatibility with ePAPR.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 06/25] docs: Xen ARM DT bindings

[Stefano Stabellini]

On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> On Tue, 28 Aug 2012, Rob Herring wrote:
> > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > While it is a PPC doc, we should reuse or extend what makes sense.
> > 
> > See section 7.5:
> > 
> > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> 
> Thanks for the link, I wasn't aware of ePAPR.
> 
> The hypervisor node defined by ePAPR is not very different from what I
> am proposing. Should I try to be compatible with the hypervisor
> specification above (as in compatible = "epapr,hypervisor-1.1")?
> Or should I just use it as a reference for my own specification?
> 
> Personally I would rather avoid full compatibility with ePAPR.

In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:

- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).

- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.

- guest-id
we usually make a point in trying not to tell the guest its own domid
because if the VM gets migrated to a different host it acquires a new
domid, therefore it should not rely on it.

- guest-name
we could pass the guest name here, but I don't see how it could be
of any use.



On the other hand, thinking more about what Xen needs in the device
tree, I think we could improve the current spec by clarifying the
meaning of the memory region and interrupt properties we currently
require. I thought about moving them to two separate children node with
an explicit name:

---

* Xen hypervisor device tree bindings

Xen ARM virtual platforms shall have the following properties and
children nodes:

- compatible property:
compatible = "xen,xen", "xen,xen-";
  where  is the version of the Xen ABI of the platform.

- grant_table child with the following properties:
- name:
name = "grant_table";
- reg: specifies the base physical address and size of a region in
memory where the grant table should be mapped to, using an
HYPERVISOR_memory_op hypercall. 

- events child with the following properties:
- name:
name = "events";
- interrupts: the interrupt used by Xen to inject event notifications.


Example:
hypervisor {
compatible = "xen,xen", "xen,xen-4.2";
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <3>;
ranges = <0xb000 0xb000 0x2>;

grant_table {
name = "grant_table";
reg = <0xb000 0x2>;
};

events {
name = "events";
interrupts = <1 15 0xf08>;
};
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 06/25] docs: Xen ARM DT bindings

[Stefano Stabellini]

On Thu, 13 Sep 2012, Dave Martin wrote:
> On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> Some thoughts on this:
> 
> We decided that embedding machine instructions into the DT is a fairly
> awful idea when discussing how to describe low-level debug UARTs in the
> DT.  I don't think it's a lot better in this case (never mind issues
> like ARM versus Thumb, endianness etc.)
> 
> If we are going to attempt to describe the call interface, we should
> do it symbolically, allowing the hypervisor interface code in the kernel
> to choose (or, if necessary, generate) the right call wrappers.
> 
> We will have this issue for descrbing power firmware interfaces for
> example: we already know that this functionality might require an SMC
> or HVC instruction to call it, depending on the platform.
> 
> A hypervisor with only one call ABI could leave this to be implicit,
> providing there is a version number property of similar to allow future
> changes to be accommodated.

I completely agree with Dave.
I have no problems adding a symbolic property to say "we are using hvc
with parameters on registers". I just want to avoid having actual
machine instructions (and potentially dealing with executing them) into
the DT.

Maybe we could have a "calling-convention" property that can be "xen"
or something else. When a new hypervisor vendor comes along it can
change the value of "calling-convention" to "foo".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 06/25] docs: Xen ARM DT bindings

[Stefano Stabellini]

On Thu, 13 Sep 2012, Dave Martin wrote:
> Do you think it's feasible to standardise on some interoperable ABI for
> kvm and Xen?  This sounds pretty optimistic, but I'm not aware of all
> the technicalities, or what possible third-party hypervisors are out
> there.
> 
> If we could do it, it would be good.  But I have my doubts about the
> feasibility and the benefits.  If different hypervisors are significantly
> imcompatible, then having a common low-level ABI doesn't help all that
> much.

It is not really possible because each hypervisor offers a different set
of hypercalls and has a different calling convention, so there is very
little we can do to unify them.

For example many of the current Xen hypercalls are to deal with the grant
table and event channels, that are Xen specific concepts completely
missing in KVM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 06/25] docs: Xen ARM DT bindings

[Stefano Stabellini]

On Thu, 13 Sep 2012, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While it is a PPC doc, we should reuse or extend what makes sense.
> >>>
> >>> See section 7.5:
> >>>
> >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> >>
> >> Thanks for the link, I wasn't aware of ePAPR.
> >>
> >> The hypervisor node defined by ePAPR is not very different from what I
> >> am proposing. Should I try to be compatible with the hypervisor
> >> specification above (as in compatible = "epapr,hypervisor-1.1")?
> >> Or should I just use it as a reference for my own specification?
> >>
> >> Personally I would rather avoid full compatibility with ePAPR.
> > 
> > In particular reading section 7.5, these are the required properties of
> > the ePAPR hypervisor node:
> > 
> > - compatible = "epapr,hypervisor-1.1"
> > compared to what I am proposing, it is laking information about what
> > hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> > of the ABI (xen-4.2).
> 
> compatible properties are often changed. If we do deviate on the rest of
> the binding, then it needs to be different.
> 
> Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
> doesn't even appear in the kernel.
> 
> We also perhaps have to consider the possibility of Xen on PowerPC. Then
> alignment is more important.

OK. In that case I think that we can just use "xen,xen-4.2".


> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> It's really about the parameters passed with the HVC. The ePAPR may be a
> good model for defining this. Just grepping "hypervisor" under
> arch/powerpc, it's pretty clear hypervisor support happened first and
> the ePAPR came second. Hopefully we can avoid that for ARM.

Right. As I wrote in the other email, we could have a new property to
select the calling convention (and therefore the hypercall wrappers) to
be used with the hypervisor.


> > - guest-id
> > we usually make a point in trying not to tell the guest its own domid
> > because if the VM gets migrated to a different host it acquires a new
> > domid, therefore it should not rely on it.
> > 
> > - guest-name
> > we could pass the guest name here, but I don't see how it could be
> > of any use.
> > 
> 
> I have no issue with these being optional.

OK, good.


> > On the other hand, thinking more about what Xen needs in the device
> > tree, I think we could improve the current spec by clarifying the
> > meaning of the memory region and interrupt properties we currently
> > require. I thought about moving them to two separate children node with
> > an explicit name:
> > 
> > ---
> > 
> > * Xen hypervisor device tree bindings
> > 
> 
> I really think we need to define ARM hypervisor device tree bindings
> first, then Xen specific bindings as an addition to that. I worry that
> the KVM folks aren't paying attention and then want something different
> later on.

The problem is that there isn't much in common between Xen and KVM at
least from the DT point of view. I am not sure what would go into this
common hypervisor node.
The three key pieces of information that we are currently passing in the
DT (xen-4.2, a memory region, a PPI) are Xen specific.

If one day KVM (or another hypervisor vendor) decides to support the Xen
interface, can't they just have the Xen specific binding with a slightly
different compatible node?
For example:

compatible = "linux,kvm", "xen,xen-4.2"

wouldn't that mean "I am KVM but I can support the Xen interface"?


> > Xen ARM virtual platforms shall have the following properties and
> > children nodes:
> > 
> > - compatible property:
> > compatible = "xen,xen", "xen,xen-";
> 
> "xen,xen" should be last a

Re: [PATCH v3 00/23] Introduce Xen support on ARM

[Stefano Stabellini]

Russell,
sorry for not CC'ing you on the entire patch series in the past, I'll do
it in the next iteration of the series (that TBH is nearly identical to
this one apart from being 3.6-rc5 based).

Are you happy with it? Given that the changes are entirely contained
within arch/arm/xen and arch/arm/include/asm/xen (apart from patch #21
that is a generic ARM fix), should this patch series go through you or
Arnd?

Thanks,

Stefano




On Thu, 16 Aug 2012, Stefano Stabellini wrote:
> Hi all,
> this patch series implements Xen support for ARMv7 with virtualization
> extensions.  It allows a Linux guest to boot as dom0 and
> as domU on Xen on ARM. PV console, disk and network frontends and
> backends are all working correctly.
> 
> It has been tested on a Versatile Express Cortex A15 emulator, using the
> latest Xen ARM developement branch
> (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
> the "ARM hypercall ABI: 64 bit ready" patch series
> (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
> tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).
> 
> The patch marked with [HACK] shouldn't be applied and is part of the
> series only because it is needed to create domUs.
> 
> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.
> 
> Comments are very welcome!
> 
> 
> Changes in v3:
> - move patches that have been picked up by Konrad at the end of the
>   series;
> - improve comments;
> - add a doc to describe the Xen Device Tree format;
> - do not use xen_ulong_t for multicalls and apic_physbase;
> - add a patch at the end of the series to use the new __HVC macro;
> - add missing pvclock-abi.h include to ia64 header files;
> - do not use an anonymous union in struct xen_add_to_physmap.
> 
> 
> Changes in v2:
> - fix up many comments and commit messages;
> - remove the early_printk patches: rely on the emulated serial for now;
> - remove the xen_guest_init patch: without any PV early_printk, we don't
>   need any early call to xen_guest_init, we can rely on core_initcall
>   alone;
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
>   at the moment is unused;
> - use ldm instead of pop in the hypercall wrappers;
> - return -ENOSYS rather than -1 from the unimplemented grant_table
>   functions;
> - remove the pvclock ifdef in the Xen headers;
> - remove include linux/types.h from xen/interface/xen.h;
> - replace pr_info with pr_debug in xen_guest_init;
> - add a new patch to introduce xen_ulong_t and use it top replace all
>   the occurences of unsigned long in the public Xen interface;
> - explicitely size all the pointers to 64 bit on ARM, so that the
>   hypercall ABI is "64 bit ready";
> - clean up xenbus_init;
> - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
> - mark Xen guest support on ARM as EXPERIMENTAL;
> - introduce GRANT_TABLE_PHYSADDR;
> - remove unneeded initialization of boot_max_nr_grant_frames;
> - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
> - return -EINVAL from xen_remap_domain_mfn_range if
>   auto_translated_physmap;
> - retain binary compatibility in xen_add_to_physmap: use a union to
>   introduce foreign_domid.
> 
> 
> Ian Campbell (1):
>   [HACK] xen/arm: implement xen_remap_domain_mfn_range
> 
> Stefano Stabellini (24):
>   arm: initial Xen support
>   xen/arm: hypercalls
>   xen/arm: page.h definitions
>   xen/arm: sync_bitops
>   xen/arm: empty implementation of grant_table arch specific functions
>   docs: Xen ARM DT bindings
>   xen/arm: Xen detection and shared_info page mapping
>   xen/arm: Introduce xen_pfn_t for pfn and mfn types
>   xen/arm: Introduce xen_ulong_t for unsigned long
>   xen/arm: compile and run xenbus
>   xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
>   xen/arm: introduce CONFIG_XEN on ARM
>   xen/arm: get privilege status
>   xen/arm: initialize grant_table on ARM
>   xen/arm: receive Xen events on ARM
>   xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
>   xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
>   xen: allow privcmd for HVM guests
>   xen/arm:

[PATCH v4 02/24] xen/arm: hypercalls

[Stefano Stabellini]

Use r12 to pass the hypercall number to the hypervisor.

We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.

Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".

Use the ISS to pass an hypervisor specific tag.


Changes in v2:
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop;
- fix up comments.


Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/hypercall.h |   50 
 arch/arm/xen/Makefile|2 +-
 arch/arm/xen/hypercall.S |  106 ++
 3 files changed, 157 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/hypercall.h
 create mode 100644 arch/arm/xen/hypercall.S

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
new file mode 100644
index 000..4ac0624
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -0,0 +1,50 @@
+/**
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * Stefano Stabellini , Citrix, 2012
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _ASM_ARM_XEN_HYPERCALL_H
+#define _ASM_ARM_XEN_HYPERCALL_H
+
+#include 
+
+long privcmd_call(unsigned call, unsigned long a1,
+   unsigned long a2, unsigned long a3,
+   unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+
+#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 0bad594..b9d6acc 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y  := enlighten.o
+obj-y  := enlighten.o hypercall.o
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
new file mode 100644
index 000..074f5ed
--- /dev/null
+++ b/arch/arm/xen/hypercall.S
@@ -0,0 +1,106 @@
+/**
+ * hypercall.S
+ *
+ * Xen hypercall wrappers
+ *
+ * Stefano Stabellini , Citrix, 2012
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS 

[PATCH v4 10/24] xen/arm: compile and run xenbus

[Stefano Stabellini]

bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
an error.

If Linux is running as an HVM domain and is running as Dom0, use
xenstored_local_init to initialize the xenstore page and event channel.


Changes in v4:

- do not xs_reset_watches on dom0.


Changes in v2:

- refactor xenbus_init.

Signed-off-by: Stefano Stabellini 
---
 drivers/xen/xenbus/xenbus_comms.c |2 +-
 drivers/xen/xenbus/xenbus_probe.c |   62 +---
 drivers/xen/xenbus/xenbus_xs.c|3 +-
 3 files changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c 
b/drivers/xen/xenbus/xenbus_comms.c
index 52fe7ad..c5aa55c 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -224,7 +224,7 @@ int xb_init_comms(void)
int err;
err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
0, "xenbus", &xb_waitq);
-   if (err <= 0) {
+   if (err < 0) {
printk(KERN_ERR "XENBUS request irq failed %i\n", err);
return err;
}
diff --git a/drivers/xen/xenbus/xenbus_probe.c 
b/drivers/xen/xenbus/xenbus_probe.c
index b793723..a67ccc0 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
return err;
 }
 
+enum xenstore_init {
+   UNKNOWN,
+   PV,
+   HVM,
+   LOCAL,
+};
 static int __init xenbus_init(void)
 {
int err = 0;
+   enum xenstore_init usage = UNKNOWN;
+   uint64_t v = 0;
 
if (!xen_domain())
return -ENODEV;
 
xenbus_ring_ops_init();
 
-   if (xen_hvm_domain()) {
-   uint64_t v = 0;
-   err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-   if (err)
-   goto out_error;
-   xen_store_evtchn = (int)v;
-   err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
-   if (err)
-   goto out_error;
-   xen_store_mfn = (unsigned long)v;
-   xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, 
PAGE_SIZE);
-   } else {
-   xen_store_evtchn = xen_start_info->store_evtchn;
-   xen_store_mfn = xen_start_info->store_mfn;
-   if (xen_store_evtchn)
-   xenstored_ready = 1;
-   else {
+   if (xen_pv_domain())
+   usage = PV;
+   if (xen_hvm_domain())
+   usage = HVM;
+   if (xen_hvm_domain() && xen_initial_domain())
+   usage = LOCAL;
+   if (xen_pv_domain() && !xen_start_info->store_evtchn)
+   usage = LOCAL;
+   if (xen_pv_domain() && xen_start_info->store_evtchn)
+   xenstored_ready = 1;
+
+   switch (usage) {
+   case LOCAL:
err = xenstored_local_init();
if (err)
goto out_error;
-   }
-   xen_store_interface = mfn_to_virt(xen_store_mfn);
+   xen_store_interface = mfn_to_virt(xen_store_mfn);
+   break;
+   case PV:
+   xen_store_evtchn = xen_start_info->store_evtchn;
+   xen_store_mfn = xen_start_info->store_mfn;
+   xen_store_interface = mfn_to_virt(xen_store_mfn);
+   break;
+   case HVM:
+   err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+   if (err)
+   goto out_error;
+   xen_store_evtchn = (int)v;
+   err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
+   if (err)
+   goto out_error;
+   xen_store_mfn = (unsigned long)v;
+   xen_store_interface =
+   ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
+   break;
+   default:
+   pr_warn("Xenstore state unknown\n");
+   break;
}
 
/* Initialize the interface to xenstore. */
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index bce15cf..131dec0 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "xenbus_comms.h"
@@ -622,7 +623,7 @@ static void xs_reset_watches(void)
 {
int err, supported = 0;
 
-   if (!xen_hvm_domain())
+   if (!xen_hvm_domain() || xen_initial_domain())
return;
 
err =

[PATCH v4 06/24] docs: Xen ARM DT bindings

[Stefano Stabellini]

Add a doc to describe the Xen ARM device tree bindings


Changes in v4:

- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.


Signed-off-by: Stefano Stabellini 
CC: devicetree-disc...@lists.ozlabs.org
CC: David Vrabel 
CC: Rob Herring 
CC: Dave Martin 
---
 Documentation/devicetree/bindings/arm/xen.txt |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/xen.txt

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 000..1f8f7d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have the following properties:
+
+- compatible:
+   compatible = "xen,xen-", "xen,xen";
+  where  is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+  memory where the grant table should be mapped to, using an
+  HYPERVISOR_memory_op hypercall. 
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+
+
+Example:
+
+hypervisor {
+   compatible = "xen,xen-4.3", "xen,xen";
+   reg = <0 0xb000 0 0x2>;
+   interrupts = <1 15 0xf08>;
+};
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 01/24] arm: initial Xen support

[Stefano Stabellini]

- Basic hypervisor.h and interface.h definitions.
- Skeleton enlighten.c, set xen_start_info to an empty struct.
- Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.

The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in patch #11 "xen/arm: introduce CONFIG_XEN on
ARM".

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/Makefile |1 +
 arch/arm/include/asm/hypervisor.h |6 +++
 arch/arm/include/asm/xen/hypervisor.h |   19 ++
 arch/arm/include/asm/xen/interface.h  |   65 +
 arch/arm/xen/Makefile |1 +
 arch/arm/xen/enlighten.c  |   35 ++
 include/xen/xen.h |2 +-
 7 files changed, 128 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/interface.h
 create mode 100644 arch/arm/xen/Makefile
 create mode 100644 arch/arm/xen/enlighten.c

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..f42968a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -251,6 +251,7 @@ endif
 core-$(CONFIG_FPE_NWFPE)   += arch/arm/nwfpe/
 core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
 core-$(CONFIG_VFP) += arch/arm/vfp/
+core-$(CONFIG_XEN) += arch/arm/xen/
 
 # If we have a machine-specific directory, then include it in the build.
 core-y += arch/arm/kernel/ arch/arm/mm/ 
arch/arm/common/
diff --git a/arch/arm/include/asm/hypervisor.h 
b/arch/arm/include/asm/hypervisor.h
new file mode 100644
index 000..b90d9e5
--- /dev/null
+++ b/arch/arm/include/asm/hypervisor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_HYPERVISOR_H
+#define _ASM_ARM_HYPERVISOR_H
+
+#include 
+
+#endif
diff --git a/arch/arm/include/asm/xen/hypervisor.h 
b/arch/arm/include/asm/xen/hypervisor.h
new file mode 100644
index 000..d7ab99a
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+   PARAVIRT_LAZY_NONE,
+   PARAVIRT_LAZY_MMU,
+   PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+   return PARAVIRT_LAZY_NONE;
+}
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
new file mode 100644
index 000..9e0ec5a
--- /dev/null
+++ b/arch/arm/include/asm/xen/interface.h
@@ -0,0 +1,65 @@
+/**
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini , Citrix, 2012
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include 
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+   typedef type * __guest_handle_ ## name
+
+#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
+
+#define set_xen_guest_handle(hnd, val) \
+   do {\
+   if (sizeof(hnd) == 8)   \
+   *(uint64_t *)&(hnd) = 0;\
+   (hnd) = val;\
+   } while (0)
+
+#ifndef __ASSEMBLY__
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint,  unsigned int);
+__DEFINE_GUEST_HANDLE(ulong, unsigned long);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(long);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+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 */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+   u32   version;
+   u32   sec;
+   u32   nsec;
+} __attribute__((__packed__));
+#endif
+
+#endif /* _ASM_ARM_XEN_INTERFACE_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
new file mode 100644
index 000..0bad594
--- /dev/null
+++ 

[PATCH v4 03/24] xen/arm: page.h definitions

[Stefano Stabellini]

ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/include/asm/xen/page.h |   82 +++
 1 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/page.h

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 000..1742023
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,82 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#define pfn_to_mfn(pfn)(pfn)
+#define phys_to_machine_mapping_valid  (1)
+#define mfn_to_pfn(mfn)(mfn)
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+#define pte_mfnpte_pfn
+#define mfn_ptepfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+   phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+   phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x)  ((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x)  ((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+   unsigned offset = phys.paddr & ~PAGE_MASK;
+   return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+   unsigned offset = machine.maddr & ~PAGE_MASK;
+   return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT <-> MACHINE conversion */
+#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
+#define virt_to_pfn(v)  (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+   /* TODO: assuming it is mapped in the kernel 1:1 */
+   return virt_to_machine(vaddr);
+}
+
+/* TODO: this shouldn't be here but it is because the frontend drivers
+ * are using it (its rolled in headers) even though we won't hit the code path.
+ * So for right now just punt with this.
+ */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+   BUG();
+   return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+   struct gnttab_map_grant_ref *kmap_op)
+{
+   return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+   return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+   BUG();
+   return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_H */
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 04/24] xen/arm: sync_bitops

[Stefano Stabellini]

sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.

We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
under Xen you might be communicating with a completely external entity
who might be on another CPU (e.g. two uniprocessor guests communicating
via event channels and grant tables). So we need a variant of the bit
ops which are SMP safe even on a UP kernel.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/include/asm/sync_bitops.h |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/sync_bitops.h

diff --git a/arch/arm/include/asm/sync_bitops.h 
b/arch/arm/include/asm/sync_bitops.h
new file mode 100644
index 000..63479ee
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,27 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include 
+#include 
+
+/* sync_bitops functions are equivalent to the SMP implementation of the
+ * original functions, independently from CONFIG_SMP being defined.
+ *
+ * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
+ * under Xen you might be communicating with a completely external entity
+ * who might be on another CPU (e.g. two uniprocessor guests communicating
+ * via event channels and grant tables). So we need a variant of the bit
+ * ops which are SMP safe even on a UP kernel.
+ */
+
+#define sync_set_bit(nr, p)_set_bit(nr, p)
+#define sync_clear_bit(nr, p)  _clear_bit(nr, p)
+#define sync_change_bit(nr, p) _change_bit(nr, p)
+#define sync_test_and_set_bit(nr, p)   _test_and_set_bit(nr, p)
+#define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p)
+#define sync_test_and_change_bit(nr, p)_test_and_change_bit(nr, p)
+#define sync_test_bit(nr, addr)test_bit(nr, addr)
+#define sync_cmpxchg   cmpxchg
+
+
+#endif
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 05/24] xen/arm: empty implementation of grant_table arch specific functions

[Stefano Stabellini]

Changes in v2:

- return -ENOSYS rather than -1.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/xen/Makefile  |2 +-
 arch/arm/xen/grant-table.c |   53 
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/xen/grant-table.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index b9d6acc..4384103 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y  := enlighten.o hypercall.o
+obj-y  := enlighten.o hypercall.o grant-table.o
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
new file mode 100644
index 000..dbd1330
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,53 @@
+/**
+ * grant_table.c
+ * ARM specific part
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+  unsigned long max_nr_gframes,
+  void **__shared)
+{
+   return -ENOSYS;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+   return;
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+  unsigned long max_nr_gframes,
+  grant_status_t **__shared)
+{
+   return -ENOSYS;
+}
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 08/24] xen/arm: Introduce xen_pfn_t for pfn and mfn types

[Stefano Stabellini]

All the original Xen headers have xen_pfn_t as mfn and pfn type, however
when they have been imported in Linux, xen_pfn_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_pfn_t and let each architecture define xen_pfn_t as they
see fit.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/include/asm/xen/interface.h  |4 
 arch/ia64/include/asm/xen/interface.h |5 -
 arch/x86/include/asm/xen/interface.h  |5 +
 include/xen/interface/grant_table.h   |4 ++--
 include/xen/interface/memory.h|6 +++---
 include/xen/interface/platform.h  |4 ++--
 include/xen/interface/xen.h   |6 +++---
 include/xen/privcmd.h |2 --
 8 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 9e0ec5a..74c72b5 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -25,6 +25,9 @@
} while (0)
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+typedef uint64_t xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -35,6 +38,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/ia64/include/asm/xen/interface.h 
b/arch/ia64/include/asm/xen/interface.h
index 09d5f7f..686464e 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -67,6 +67,10 @@
 #define set_xen_guest_handle(hnd, val) do { (hnd).p = val; } while (0)
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the public interface
+ * with Xen so that we could have one ABI that works for 32 and 64 bit
+ * guests. */
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
@@ -79,7 +83,6 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 
-typedef unsigned long xen_pfn_t;
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 #define PRI_xen_pfn"lx"
 #endif
diff --git a/arch/x86/include/asm/xen/interface.h 
b/arch/x86/include/asm/xen/interface.h
index cbf0c9d..2289075 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -47,6 +47,10 @@
 #endif
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the public interface
+ * with Xen so that on ARM we can have one ABI that works for 32 and 64
+ * bit guests. */
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -57,6 +61,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 #ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/grant_table.h 
b/include/xen/interface/grant_table.h
index a17d844..7da811b 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -338,7 +338,7 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_dump_table);
 #define GNTTABOP_transfer4
 struct gnttab_transfer {
 /* IN parameters. */
-unsigned long mfn;
+xen_pfn_t mfn;
 domid_t   domid;
 grant_ref_t   ref;
 /* OUT parameters. */
@@ -375,7 +375,7 @@ struct gnttab_copy {
struct {
union {
grant_ref_t ref;
-   unsigned long   gmfn;
+   xen_pfn_t   gmfn;
} u;
domid_t  domid;
uint16_t offset;
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eac3ce1..abbbff0 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -31,7 +31,7 @@ struct xen_memory_reservation {
  *   OUT: GMFN bases of extents that were allocated
  *   (NB. This command also updates the mach_to_phys translation table)
  */
-GUEST_HANDLE(ulong) extent_start;
+GUEST_HANDLE(xen_pfn_t) extent_start;
 
 /* Number of extents, and size/alignment of each (2^extent_order pages). */
 unsigned long  nr_extents;
@@ -130,7 +130,7 @@ struct xen_machphys_mfn_list {
  * any large discontiguities in the machine address space, 2MB gaps in
  * the machphys table will be represented by an MFN base of zero.
  */
-GUEST_HANDLE(ulong) extent_start;
+GUEST_HANDLE(xen_pfn_t) ex

[PATCH v4 09/24] xen/arm: Introduce xen_ulong_t for unsigned long

[Stefano Stabellini]

All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.

Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.


Changes in v3:

- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.


Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/interface.h  |8 ++--
 arch/ia64/include/asm/xen/interface.h |1 +
 arch/x86/include/asm/xen/interface.h  |1 +
 include/xen/interface/memory.h|   12 ++--
 include/xen/interface/physdev.h   |2 +-
 include/xen/interface/version.h   |2 +-
 6 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 74c72b5..ae05e56 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,8 +9,11 @@
 
 #include 
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
+
 #define __DEFINE_GUEST_HANDLE(name, type) \
-   typedef type * __guest_handle_ ## name
+   typedef struct { union { type *p; uint64_aligned_t q; }; }  \
+__guest_handle_ ## name
 
 #define DEFINE_GUEST_HANDLE_STRUCT(name) \
__DEFINE_GUEST_HANDLE(name, struct name)
@@ -21,13 +24,14 @@
do {\
if (sizeof(hnd) == 8)   \
*(uint64_t *)&(hnd) = 0;\
-   (hnd) = val;\
+   (hnd).p = val;  \
} while (0)
 
 #ifndef __ASSEMBLY__
 /* Explicitly size integers that represent pfns in the interface with
  * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
 typedef uint64_t xen_pfn_t;
+typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/arch/ia64/include/asm/xen/interface.h 
b/arch/ia64/include/asm/xen/interface.h
index 686464e..7c83445 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,6 +71,7 @@
  * with Xen so that we could have one ABI that works for 32 and 64 bit
  * guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h 
b/arch/x86/include/asm/xen/interface.h
index 2289075..25cc8df 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,6 +51,7 @@
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index abbbff0..b5c3098 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -34,7 +34,7 @@ struct xen_memory_reservation {
 GUEST_HANDLE(xen_pfn_t) extent_start;
 
 /* Number of extents, and size/alignment of each (2^extent_order pages). */
-unsigned long  nr_extents;
+xen_ulong_t  nr_extents;
 unsigned int   extent_order;
 
 /*
@@ -92,7 +92,7 @@ struct xen_memory_exchange {
  * command will be non-zero.
  *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
  */
-unsigned long nr_exchanged;
+xen_ulong_t nr_exchanged;
 };
 
 DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
@@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
  */
 #define XENMEM_machphys_mapping 12
 struct xen_machphys_mapping {
-unsigned long v_start, v_end; /* Start and end virtual addresses.   */
-unsigned long max_mfn;/* Maximum MFN that can be looked up. */
+xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
+xen_ulong_t max_mfn;/* Maximum MFN that can be looked up. */
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
@@ -169,7 +169,7 @@ struct xen_add_to_physmap {
 unsigned int space;
 
 /* Index into source mapping space. */
-unsigned long idx;
+xen_ulong_t idx;
 
 /* GPFN where the source mapping page should appear. */
 xen_pfn_t gpfn;
@@ -186,7 +186,7 @@ struct xen_translate_gpfn_list {
 domid_t domid;
 
 /* Length of list. */
-unsigned long nr_gpfns;
+xen_ulong_t nr_gpfns;
 
 /* List of GPFNs to translate. */
 GUEST_HANDLE(ulong) gpfn_list;
diff --git a/include/xen/interface/physdev

[PATCH v4 07/24] xen/arm: Xen detection and shared_info page mapping

[Stefano Stabellini]

Check for a node in the device tree compatible with "xen,xen", if it is
present set xen_domain_type to XEN_HVM_DOMAIN and continue
initialization.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Changes in v4:

- simpler parsing of Xen version in the compatible DT node.

Changes in v3:

- use the "xen,xen" notation rather than "arm,xen";
- add an additional check on the presence of the Xen version.

Changes in v2:

- replace pr_info with pr_debug.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |   61 ++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c535540..6a0217d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
@@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
return -ENOSYS;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * see Documentation/devicetree/bindings/arm/xen.txt for the
+ * documentation of the Xen Device Tree format.
+ */
+static int __init xen_guest_init(void)
+{
+   struct xen_add_to_physmap xatp;
+   static struct shared_info *shared_info_page = 0;
+   struct device_node *node;
+   int len;
+   const char *s = NULL;
+   const char *version = NULL;
+   const char *xen_prefix = "xen,xen-";
+
+   node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!node) {
+   pr_debug("No Xen support\n");
+   return 0;
+   }
+   s = of_get_property(node, "compatible", &len);
+   if (strlen(xen_prefix) + 3  < len &&
+   !strncmp(xen_prefix, s, strlen(xen_prefix)))
+   version = s + strlen(xen_prefix);
+   if (version == NULL) {
+   pr_debug("Xen version not found\n");
+   return 0;
+   }
+   xen_domain_type = XEN_HVM_DOMAIN;
+
+   if (!shared_info_page)
+   shared_info_page = (struct shared_info *)
+   get_zeroed_page(GFP_KERNEL);
+   if (!shared_info_page) {
+   pr_err("not enough memory\n");
+   return -ENOMEM;
+   }
+   xatp.domid = DOMID_SELF;
+   xatp.idx = 0;
+   xatp.space = XENMAPSPACE_shared_info;
+   xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+   if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
+   BUG();
+
+   HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+   /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+* page, we use it in the event channel upcall and in some pvclock
+* related functions. We don't need the vcpu_info placement
+* optimizations because we don't use any pv_mmu or pv_irq op on
+* HVM.
+* The shared info contains exactly 1 CPU (the boot CPU). The guest
+* is required to use VCPUOP_register_vcpu_info to place vcpu info
+* for secondary CPUs as they are brought up. */
+   per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+   return 0;
+}
+core_initcall(xen_guest_init);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 00/24] Introduce Xen support on ARM (based on 3.6-rc5)

[Stefano Stabellini]

Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions.  It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.

It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen ARM developement branch
(git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
the "ARM hypercall ABI: 64 bit ready" patch series
(http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).

The patch marked with [HACK] has been dropped from this series, however
you can find it here:
http://marc.info/?l=linux-kernel&m=134513277823527&w=2.

I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
and it is appended in binary form to the guest kernel image. I am not
sure where they are supposed to live yet, so I am just attaching them
here so that people can actually try out this series if they want to.

Comments are very welcome!



Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not
present" touches generic ARM code and still needs to be acked/reviewed.

Arnd, Russell, what do you think about this series? If you are OK with
it, to whom should I submit it?



Changes in v4:
- rebase on 3.6-rc5;
- devicetree: "xen,xen" should be last as it is less specific;
- devicetree: use 2 address-cells and 2 size-cells in the reg property;
- do not xs_reset_watches on dom0;
- compile drivers/xen/pcpu.c only on x86;
- use "+=" instead of ":=" for dom0- targets;
- add a patch to update the MAINTAINERS file.


Changes in v3:
- move patches that have been picked up by Konrad at the end of the
  series;
- improve comments;
- add a doc to describe the Xen Device Tree format;
- do not use xen_ulong_t for multicalls and apic_physbase;
- add a patch at the end of the series to use the new __HVC macro;
- add missing pvclock-abi.h include to ia64 header files;
- do not use an anonymous union in struct xen_add_to_physmap.


Changes in v2:
- fix up many comments and commit messages;
- remove the early_printk patches: rely on the emulated serial for now;
- remove the xen_guest_init patch: without any PV early_printk, we don't
  need any early call to xen_guest_init, we can rely on core_initcall
  alone;
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
  at the moment is unused;
- use ldm instead of pop in the hypercall wrappers;
- return -ENOSYS rather than -1 from the unimplemented grant_table
  functions;
- remove the pvclock ifdef in the Xen headers;
- remove include linux/types.h from xen/interface/xen.h;
- replace pr_info with pr_debug in xen_guest_init;
- add a new patch to introduce xen_ulong_t and use it top replace all
  the occurences of unsigned long in the public Xen interface;
- explicitely size all the pointers to 64 bit on ARM, so that the
  hypercall ABI is "64 bit ready";
- clean up xenbus_init;
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
- mark Xen guest support on ARM as EXPERIMENTAL;
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames;
- add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap;
- retain binary compatibility in xen_add_to_physmap: use a union to
  introduce foreign_domid.


Shortlog and diffstat:

Stefano Stabellini (24):
  arm: initial Xen support
  xen/arm: hypercalls
  xen/arm: page.h definitions
  xen/arm: sync_bitops
  xen/arm: empty implementation of grant_table arch specific functions
  docs: Xen ARM DT bindings
  xen/arm: Xen detection and shared_info page mapping
  xen/arm: Introduce xen_pfn_t for pfn and mfn types
  xen/arm: Introduce xen_ulong_t for unsigned long
  xen/arm: compile and run xenbus
  xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on 
ARM
  xen/arm: introduce CONFIG_XEN on ARM
  xen/arm: get privilege status
  xen/arm: initialize grant_table on ARM
  xen/arm: receive Xen events on ARM
  xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
  xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
  xen: allow privcmd for HVM guests
  xen/arm: compile blkfront and blkback
  xen/arm: compile netback
  arm/v2m: initialize arch_timers even if v2m_timer is not present
  xen: missing includes
  xen: update xen_add_to_physmap interface
  MAINTAINERS: add myself as Xen ARM maintainer

 Documentation/devicetree/bindings/arm/xen.txt

[PATCH v4 11/24] xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM

[Stefano Stabellini]

Changes in v4:
- compile pcpu only on x86;
- use "+=" instead of ":=" for dom0- targets.

Changes in v2:

- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/Makefile |   13 +
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d80bea5..cd28aae 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,11 +1,18 @@
-obj-y  += grant-table.o features.o events.o manage.o balloon.o
+ifneq ($(CONFIG_ARM),y)
+obj-y  += manage.o balloon.o
+obj-$(CONFIG_HOTPLUG_CPU)  += cpu_hotplug.o
+endif
+obj-y  += grant-table.o features.o events.o
 obj-y  += xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o  := $(nostackp)
 
+obj-$(CONFIG_XEN_DOM0) += $(dom0-y)
+dom0-$(CONFIG_PCI) += pci.o
+dom0-$(CONFIG_ACPI) += acpi.o
+dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_BLOCK)+= biomerge.o
-obj-$(CONFIG_HOTPLUG_CPU)  += cpu_hotplug.o
 obj-$(CONFIG_XEN_XENCOMM)  += xencomm.o
 obj-$(CONFIG_XEN_BALLOON)  += xen-balloon.o
 obj-$(CONFIG_XEN_SELFBALLOONING)   += xen-selfballoon.o
@@ -17,8 +24,6 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)  += sys-hypervisor.o
 obj-$(CONFIG_XEN_PVHVM)+= platform-pci.o
 obj-$(CONFIG_XEN_TMEM) += tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)  += swiotlb-xen.o
-obj-$(CONFIG_XEN_DOM0) += pcpu.o
-obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o
 obj-$(CONFIG_XEN_MCE_LOG)  += mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)   += xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)  += xen-privcmd.o
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 14/24] xen/arm: initialize grant_table on ARM

[Stefano Stabellini]

Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).

Changes in v2:

- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/xen/enlighten.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c2a47a7..036a4d8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,8 +1,12 @@
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
+#define GRANT_TABLE_PHYSADDR 0
 static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
@@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
const char *s = NULL;
const char *version = NULL;
const char *xen_prefix = "xen,xen-";
+   struct resource res;
 
node = of_find_compatible_node(NULL, NULL, "xen,xen");
if (!node) {
@@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
pr_debug("Xen version not found\n");
return 0;
}
+   if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
+   return 0;
+   xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
xen_domain_type = XEN_HVM_DOMAIN;
 
xen_setup_features();
@@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
 * is required to use VCPUOP_register_vcpu_info to place vcpu info
 * for secondary CPUs as they are brought up. */
per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
+   gnttab_init();
+   if (!xen_initial_domain())
+   xenbus_probe(NULL);
+
return 0;
 }
 core_initcall(xen_guest_init);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST

[Stefano Stabellini]

Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
irq_startup, that is responsible for calling irq_unmask at startup time.
As a result event channels remain masked.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/events.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 5ecb596..8ffb7b7 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
struct irq_info *info = info_for_irq(irq);
WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
}
+   irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
 
 out:
mutex_unlock(&irq_mapping_update_lock);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 13/24] xen/arm: get privilege status

[Stefano Stabellini]

Use Xen features to figure out if we are privileged.

XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/xen/enlighten.c |7 +++
 include/xen/interface/features.h |3 +++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6a0217d..c2a47a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +67,12 @@ static int __init xen_guest_init(void)
}
xen_domain_type = XEN_HVM_DOMAIN;
 
+   xen_setup_features();
+   if (xen_feature(XENFEAT_dom0))
+   xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
+   else
+   xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+
if (!shared_info_page)
shared_info_page = (struct shared_info *)
get_zeroed_page(GFP_KERNEL);
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index b6ca39a..131a6cc 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -50,6 +50,9 @@
 /* x86: pirq can be used by HVM guests */
 #define XENFEAT_hvm_pirqs   10
 
+/* operation as Dom0 is supported */
+#define XENFEAT_dom0  11
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 15/24] xen/arm: receive Xen events on ARM

[Stefano Stabellini]

Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/events.h |   18 ++
 arch/arm/xen/enlighten.c  |   33 +
 arch/x86/xen/enlighten.c  |1 +
 arch/x86/xen/irq.c|1 +
 arch/x86/xen/xen-ops.h|1 -
 drivers/xen/events.c  |   17 ++---
 include/xen/events.h  |2 ++
 7 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/events.h

diff --git a/arch/arm/include/asm/xen/events.h 
b/arch/arm/include/asm/xen/events.h
new file mode 100644
index 000..94b4e90
--- /dev/null
+++ b/arch/arm/include/asm/xen/events.h
@@ -0,0 +1,18 @@
+#ifndef _ASM_ARM_XEN_EVENTS_H
+#define _ASM_ARM_XEN_EVENTS_H
+
+#include 
+
+enum ipi_vector {
+   XEN_PLACEHOLDER_VECTOR,
+
+   /* Xen IPIs go here */
+   XEN_NR_IPIS,
+};
+
+static inline int xen_irqs_disabled(struct pt_regs *regs)
+{
+   return raw_irqs_disabled_flags(regs->ARM_cpsr);
+}
+
+#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 036a4d8..bad67ad 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -9,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+static __read_mostly int xen_events_irq = -1;
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
   unsigned long addr,
   unsigned long mfn, int nr,
@@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
return 0;
xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
+   xen_events_irq = irq_of_parse_and_map(node, 0);
+   pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
+   version, xen_events_irq, xen_hvm_resume_frames);
xen_domain_type = XEN_HVM_DOMAIN;
 
xen_setup_features();
@@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
return 0;
 }
 core_initcall(xen_guest_init);
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+   xen_hvm_evtchn_do_upcall();
+   return IRQ_HANDLED;
+}
+
+static int __init xen_init_events(void)
+{
+   if (!xen_domain() || xen_events_irq < 0)
+   return -ENODEV;
+
+   xen_init_IRQ();
+
+   if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+   "events", xen_vcpu)) {
+   pr_err("Error requesting IRQ %d\n", xen_events_irq);
+   return -EINVAL;
+   }
+
+   enable_percpu_irq(xen_events_irq, 0);
+
+   return 0;
+}
+postcore_initcall(xen_init_events);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..3f8263e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..01a4dc0 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 202d4c1..2368295 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,7 +35,6 @@ void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 void __init xen_arch_setup(void);
-void __init xen_init_IRQ(void);
 void xen_enable_sysenter(void);
 void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7595581..5ecb596 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,14 +31,16 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
+#endif
+#include 
 #include 
 #include 
 
@@ -50,6 +52,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 /*
  * This lock protects updates to the following mapping and reference-count
@@ -1374,7 +1379,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
struct pt_regs *old_regs = set_irq_regs(regs);
 
+#ifdef CONFIG_X86
exit_idle();
+#endif
irq_enter();
 
__xen_evtchn_do_upcall();
@@ -1783,9 +1790,9 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
-void __init xen_init_IRQ(void)
+void xen_init_IRQ(void)
 {
-   int i, rc;
+   int i;
 
evtchn_t

[PATCH v4 21/24] arm/v2m: initialize arch_timers even if v2m_timer is not present

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
CC: Russell King 
CC: Pawel Moll 
CC: Marc Zyngier 
---
 arch/arm/mach-vexpress/v2m.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 37608f2..4e567f7 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -621,16 +621,17 @@ static void __init v2m_dt_timer_init(void)
 
v2m_clk_init();
 
-   err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
-   if (WARN_ON(err))
-   return;
-   node = of_find_node_by_path(path);
-   v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
if (arch_timer_of_register() != 0)
twd_local_timer_of_register();
 
if (arch_timer_sched_clock_init() != 0)
versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 
2400);
+
+   err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
+   if (WARN_ON(err))
+   return;
+   node = of_find_node_by_path(path);
+   v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
 }
 
 static struct sys_timer v2m_dt_timer = {
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 18/24] xen: allow privcmd for HVM guests

[Stefano Stabellini]

This patch removes the "return -ENOSYS" for auto_translated_physmap
guests from privcmd_mmap, thus it allows ARM guests to issue privcmd
mmap calls. However privcmd mmap calls are still going to fail for HVM
and hybrid guests on x86 because the xen_remap_domain_mfn_range
implementation is currently PV only.

Changes in v2:

- better commit message;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap.


Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/mmu.c|3 +++
 drivers/xen/privcmd.c |4 
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5141d80..984cf66 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2337,6 +2337,9 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long range;
int err = 0;
 
+   if (xen_feature(XENFEAT_auto_translated_physmap))
+   return -EINVAL;
+
prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
 
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..85226cb 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -380,10 +380,6 @@ static struct vm_operations_struct privcmd_vm_ops = {
 
 static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 {
-   /* Unsupported for auto-translate guests. */
-   if (xen_feature(XENFEAT_auto_translated_physmap))
-   return -ENOSYS;
-
/* DONTCOPY is essential for Xen because copy_page_range doesn't know
 * how to recreate these mappings */
vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 17/24] xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree

[Stefano Stabellini]

Only until we get the balloon driver to work.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/xen/enlighten.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index bad67ad..59bcb96 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -148,3 +148,21 @@ static int __init xen_init_events(void)
return 0;
 }
 postcore_initcall(xen_init_events);
+
+/* XXX: only until balloon is properly working */
+int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
+{
+   *pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
+   get_order(nr_pages));
+   if (*pages == NULL)
+   return -ENOMEM;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
+
+void free_xenballooned_pages(int nr_pages, struct page **pages)
+{
+   kfree(*pages);
+   *pages = NULL;
+}
+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 20/24] xen/arm: compile netback

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/include/asm/xen/hypercall.h |   19 +++
 drivers/net/xen-netback/netback.c|1 +
 drivers/net/xen-netfront.c   |1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index 4ac0624..8a82325 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -47,4 +47,23 @@ unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+   unsigned int new_val, unsigned long flags)
+{
+   BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+int count, int *success_count, domid_t domid)
+{
+   BUG();
+}
+
+static inline int
+HYPERVISOR_multicall(void *call_list, int nr_calls)
+{
+   BUG();
+}
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 682633b..1c0a302 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -40,6 +40,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 650f79a..24d968d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM

[Stefano Stabellini]

Changes in v2:

- mark Xen guest support on ARM as EXPERIMENTAL.

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 arch/arm/Kconfig |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..e92518d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
  This was deprecated in 2001 and announced to live on for 5 years.
  Some old boot loaders still use this way.
 
+config XEN_DOM0
+   def_bool y
+
+config XEN
+   bool "Xen guest support on ARM (EXPERIMENTAL)"
+   depends on EXPERIMENTAL && ARM && OF
+   select XEN_DOM0
+   help
+ Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+
 endmenu
 
 menu "Boot options"
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 19/24] xen/arm: compile blkfront and blkback

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
---
 drivers/block/xen-blkback/blkback.c  |1 +
 include/xen/interface/io/protocols.h |3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c 
b/drivers/block/xen-blkback/blkback.c
index 73f196c..63dd5b9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -42,6 +42,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "common.h"
diff --git a/include/xen/interface/io/protocols.h 
b/include/xen/interface/io/protocols.h
index 01fc8ae..0eafaf2 100644
--- a/include/xen/interface/io/protocols.h
+++ b/include/xen/interface/io/protocols.h
@@ -5,6 +5,7 @@
 #define XEN_IO_PROTO_ABI_X86_64 "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64   "ia64-abi"
 #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
+#define XEN_IO_PROTO_ABI_ARM"arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -14,6 +15,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
 #elif defined(__powerpc64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 23/24] xen: update xen_add_to_physmap interface

[Stefano Stabellini]

Update struct xen_add_to_physmap to be in sync with Xen's version of the
structure.
The size field was introduced by:

changeset:   24164:707d27fe03e7
user:Jean Guyader 
date:Fri Nov 18 13:42:08 2011 +
summary: mm: New XENMEM space, XENMAPSPACE_gmfn_range

According to the comment:

"This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions."

Note: this patch should be already in Konrad's tree, it is here just for
convenience.

Changes in v2:

- remove erroneous comment in the commit message.

Signed-off-by: Stefano Stabellini 
---
 include/xen/interface/memory.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b5c3098..b66d04c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,6 +163,9 @@ struct xen_add_to_physmap {
 /* Which domain to change the mapping for. */
 domid_t domid;
 
+/* Number of pages to go through for gmfn_range */
+uint16_tsize;
+
 /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 24/24] MAINTAINERS: add myself as Xen ARM maintainer

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
CC: Arnd Bergmann 
CC: Konrad Rzeszutek Wilk 
---
 MAINTAINERS |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdc0119..3d38291 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7752,6 +7752,13 @@ F:   drivers/xen/
 F: arch/x86/include/asm/xen/
 F: include/xen/
 
+XEN HYPERVISOR ARM
+M: Stefano Stabellini 
+L: xen-de...@lists.xensource.com (moderated for non-subscribers)
+S: Supported
+F: arch/arm/xen/
+F: arch/arm/include/asm/xen/
+
 XEN NETWORK BACKEND DRIVER
 M: Ian Campbell 
 L: xen-de...@lists.xensource.com (moderated for non-subscribers)
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 22/24] xen: missing includes

[Stefano Stabellini]

Note: this patch should be already in Konrad's tree, it is here just for
convenience.

Changes in v3:
- add missing pvclock-abi.h include to ia64 header files.

Changes in v2:
- remove pvclock hack;
- remove include linux/types.h from xen/interface/xen.h.

Signed-off-by: Stefano Stabellini 
---
 arch/ia64/include/asm/xen/interface.h  |2 ++
 arch/x86/include/asm/xen/interface.h   |2 ++
 drivers/tty/hvc/hvc_xen.c  |2 ++
 drivers/xen/grant-table.c  |1 +
 drivers/xen/xenbus/xenbus_probe_frontend.c |1 +
 include/xen/interface/xen.h|1 -
 include/xen/privcmd.h  |1 +
 7 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/include/asm/xen/interface.h 
b/arch/ia64/include/asm/xen/interface.h
index 7c83445..e88c5de 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -269,6 +269,8 @@ typedef struct xen_callback xen_callback_t;
 
 #endif /* !__ASSEMBLY__ */
 
+#include 
+
 /* Size of the shared_info area (this is not related to page size).  */
 #define XSI_SHIFT  14
 #define XSI_SIZE   (1 << XSI_SHIFT)
diff --git a/arch/x86/include/asm/xen/interface.h 
b/arch/x86/include/asm/xen/interface.h
index 25cc8df..28fc621 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -127,6 +127,8 @@ struct arch_shared_info {
 #include "interface_64.h"
 #endif
 
+#include 
+
 #ifndef __ASSEMBLY__
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 1e456dc..2944ff8 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..1d0d95e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c 
b/drivers/xen/xenbus/xenbus_probe_frontend.c
index a31b54d..3159a37 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 0054db1..1e0df6b 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -10,7 +10,6 @@
 #define __XEN_PUBLIC_XEN_H__
 
 #include 
-#include 
 
 /*
  * XEN "SYSTEM CALLS" (a.k.a. HYPERCALLS).
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 59f1bd8..45c1aa1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 
 struct privcmd_hypercall {
__u64 op;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 21/24] arm/v2m: initialize arch_timers even if v2m_timer is not present

[Stefano Stabellini]

On Fri, 14 Sep 2012, Pawel Moll wrote:
> On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini 
> > CC: Russell King 
> > CC: Pawel Moll 
> > CC: Marc Zyngier 
> > ---
> >  arch/arm/mach-vexpress/v2m.c |   11 ++-
> >  1 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> > index 37608f2..4e567f7 100644
> > --- a/arch/arm/mach-vexpress/v2m.c
> > +++ b/arch/arm/mach-vexpress/v2m.c
> > @@ -621,16 +621,17 @@ static void __init v2m_dt_timer_init(void)
> >  
> > v2m_clk_init();
> >  
> > -   err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
> > -   if (WARN_ON(err))
> > -   return;
> > -   node = of_find_node_by_path(path);
> > -   v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
> > if (arch_timer_of_register() != 0)
> > twd_local_timer_of_register();
> >  
> > if (arch_timer_sched_clock_init() != 0)
> > versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 
> > 2400);
> > +
> > +   err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
> > +   if (WARN_ON(err))
> > +   return;
> > +   node = of_find_node_by_path(path);
> > +   v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
> >  }
> >  
> >  static struct sys_timer v2m_dt_timer = {
> 
> Fair point. The alias is going to disappear anyway (I'm working on a VE
> platform rework right now), but in case I won't get it on time for 3.7,
> I'll make sure this one is merged instead.

Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/24] Introduce Xen support on ARM (based on 3.6-rc5)

[Stefano Stabellini]

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> I already put in these
> 
> 1)  xen/events: fix unmask_evtchn for PV on HVM guests
> 2)  xen: missing includes
> 3)  xen: update xen_add_to_physmap interface
> 4)  xen: Introduce xen_pfn_t for pfn and mfn types
> 5)  xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
> 6)  xen: allow privcmd for HVM guests
> 
> in my tree as they also impact/help the PVH domains which works for
> x86 (Well, not all of them). They are in my stable/for-linus-3.7 git tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git)
> and also in #linux-next.
> 
> 
> If it would make reviewing easier, I would recommend you rebase
> your tree on top of the stable/for-linus-3.7 and just post them
> as it would make the number of patches smaller.

I have done that and it went quite smoothly. The patch series is now 5
patches smaller.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 02/24] xen/arm: hypercalls

[Stefano Stabellini]

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 12:13, Stefano Stabellini wrote:
> > Use r12 to pass the hypercall number to the hypervisor.
> > 
> > We need a register to pass the hypercall number because we might not
> > know it at compile time and HVC only takes an immediate argument.
> > 
> > Among the available registers r12 seems to be the best choice because it
> > is defined as "intra-procedure call scratch register".
> > 
> > Use the ISS to pass an hypervisor specific tag.
> > 
> > 
> > Changes in v2:
> > - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
> > at the moment is unused;
> > - use ldm instead of pop;
> > - fix up comments.
> > 
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  arch/arm/include/asm/xen/hypercall.h |   50 
> >  arch/arm/xen/Makefile|2 +-
> >  arch/arm/xen/hypercall.S |  106 
> > ++
> >  3 files changed, 157 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/include/asm/xen/hypercall.h
> >  create mode 100644 arch/arm/xen/hypercall.S
> > 
> > diff --git a/arch/arm/include/asm/xen/hypercall.h 
> > b/arch/arm/include/asm/xen/hypercall.h
> > new file mode 100644
> > index 000..4ac0624
> > --- /dev/null
> > +++ b/arch/arm/include/asm/xen/hypercall.h
> > @@ -0,0 +1,50 @@
> > +/**
> > + * hypercall.h
> > + *
> > + * Linux-specific hypervisor handling.
> > + *
> > + * Stefano Stabellini , Citrix, 2012
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License version 2
> > + * as published by the Free Software Foundation; or, when distributed
> > + * separately from the Linux kernel or incorporated into other
> > + * software packages, subject to the following license:
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a 
> > copy
> > + * of this source file (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use, copy, 
> > modify,
> > + * merge, publish, distribute, sublicense, and/or sell copies of the 
> > Software,
> > + * and to permit persons to whom the Software is furnished to do so, 
> > subject to
> > + * the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included 
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> > THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> > +#define _ASM_ARM_XEN_HYPERCALL_H
> > +
> > +#include 
> > +
> > +long privcmd_call(unsigned call, unsigned long a1,
> > +   unsigned long a2, unsigned long a3,
> > +   unsigned long a4, unsigned long a5);
> > +int HYPERVISOR_xen_version(int cmd, void *arg);
> > +int HYPERVISOR_console_io(int cmd, int count, char *str);
> > +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int 
> > count);
> > +int HYPERVISOR_sched_op(int cmd, void *arg);
> > +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> > +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> > +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> > +int HYPERVISOR_physdev_op(int cmd, void *arg);
> > +
> > +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> > diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> > index 0bad594..b9d6acc 100644
> > --- a/arch/arm/xen/Makefile
> > +++ b/arch/arm/xen/Makefile
> > @@ -1 +1 @@
> > -obj-y  := enlighten.o
> > +obj-y  := enlighten.o hypercall.o
> > diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> > new file mode 100644
> > index 000..074f5ed
> > --- /dev/null
> > +++ b/arch/ar

Re: [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST

[Stefano Stabellini]

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 12:13, Stefano Stabellini wrote:
> > Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> > default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> > irq_startup, that is responsible for calling irq_unmask at startup time.
> > As a result event channels remain masked.
> > 
> > Signed-off-by: Stefano Stabellini 
> > Acked-by: Konrad Rzeszutek Wilk 
> > ---
> >  drivers/xen/events.c |1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 5ecb596..8ffb7b7 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
> > struct irq_info *info = info_for_irq(irq);
> > WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
> > }
> > +   irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
> 
> This one just sent a shiver down my spine. Are you doing this for a PPI?

Not really: even though there is just one source of event notifications
(that is a PPI), we have many event channels. When a domain receives a
notification (via the PPI), it checks on a bitmask to which event channel
it corresponds. From the Linux point of view every event channel is a
Linux irq belonging to the xen_dynamic_chip (see
drivers/xen/events.c:xen_dynamic_chip).

So here I am not doing this for the one PPI, but I am doing this for
every Linux irq (of chip xen_dynamic_chip) that represents an event
channel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 06/24] docs: Xen ARM DT bindings

[Stefano Stabellini]

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> > Add a doc to describe the Xen ARM device tree bindings
> > 
> > 
> > Changes in v4:
> > 
> > - "xen,xen" should be last as it is less specific;
> > - update reg property using 2 address-cells and 2 size-cells.
> > 
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: devicetree-disc...@lists.ozlabs.org
> > CC: David Vrabel 
> > CC: Rob Herring 
> > CC: Dave Martin 
> > ---
> >  Documentation/devicetree/bindings/arm/xen.txt |   22 ++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
> > b/Documentation/devicetree/bindings/arm/xen.txt
> > new file mode 100644
> > index 000..1f8f7d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > @@ -0,0 +1,22 @@
> > +* Xen hypervisor device tree bindings
> > +
> > +Xen ARM virtual platforms shall have the following properties:
> > +
> > +- compatible:
> > +   compatible = "xen,xen-", "xen,xen";
> > +  where  is the version of the Xen ABI of the platform.
> > +
> > +- reg: specifies the base physical address and size of a region in
> > +  memory where the grant table should be mapped to, using an
> > +  HYPERVISOR_memory_op hypercall. 
> > +
> > +- interrupts: the interrupt used by Xen to inject event notifications.
> 
> Its singular here.. but in the example its plurar. What if you use
> multiple of the same number ("16 0xf")?

The "interrupts" property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.

>From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.

Regarding the three cells used in the example (<1 15 0xf08>), they have
a specific meaning in the GIC context:

"""
  The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
  interrupts.

  The 2nd cell contains the interrupt number for the interrupt type.
  SPI interrupts are in the range [0-987].  PPI interrupts are in the
  range [0-15].

  The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
the interrupt is wired to that CPU.  Only valid for PPI interrupts.
"""

So <1 15 0xf08> means the last PPI.



> > +
> > +
> > +Example:
> > +
> > +hypervisor {
> > +   compatible = "xen,xen-4.3", "xen,xen";
> > +   reg = <0 0xb000 0 0x2>;
> 
> So two grant tables?
> 
> Hm, physical address is zero, and the size is 0xbignumber?
> Or is the '0' denotating a seperator of arguments, so it is
> 0xb000.. for physical address and 0x2 for size?

from http://devicetree.org/Device_Tree_Usage:

"Each addressable device gets a reg which is a list of tuples in the
form reg = http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST

[Stefano Stabellini]

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 15:13, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Marc Zyngier wrote:
> >> On 14/09/12 12:13, Stefano Stabellini wrote:
> >>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> >>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> >>> irq_startup, that is responsible for calling irq_unmask at startup time.
> >>> As a result event channels remain masked.
> >>>
> >>> Signed-off-by: Stefano Stabellini 
> >>> Acked-by: Konrad Rzeszutek Wilk 
> >>> ---
> >>>  drivers/xen/events.c |1 +
> >>>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> >>> index 5ecb596..8ffb7b7 100644
> >>> --- a/drivers/xen/events.c
> >>> +++ b/drivers/xen/events.c
> >>> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
> >>>   struct irq_info *info = info_for_irq(irq);
> >>>   WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
> >>>   }
> >>> + irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
> >>
> >> This one just sent a shiver down my spine. Are you doing this for a PPI?
> > 
> > Not really: even though there is just one source of event notifications
> > (that is a PPI), we have many event channels. When a domain receives a
> > notification (via the PPI), it checks on a bitmask to which event channel
> > it corresponds. From the Linux point of view every event channel is a
> > Linux irq belonging to the xen_dynamic_chip (see
> > drivers/xen/events.c:xen_dynamic_chip).
> > 
> > So here I am not doing this for the one PPI, but I am doing this for
> > every Linux irq (of chip xen_dynamic_chip) that represents an event
> > channel.
> 
> So this is some sort of secondary interrupt controller, cascaded into
> your GIC emulation,

I guess it could be seen as a secondary interrupt controller


> and this patch only affects the xen_dynamic_chip?

Yep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 07/24] xen/arm: Xen detection and shared_info page mapping

[Stefano Stabellini]

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:09PM +0100, Stefano Stabellini wrote:
> > Check for a node in the device tree compatible with "xen,xen", if it is
> > present set xen_domain_type to XEN_HVM_DOMAIN and continue
> > initialization.
> > 
> > Map the real shared info page using XENMEM_add_to_physmap with
> > XENMAPSPACE_shared_info.
> > 
> > Changes in v4:
> > 
> > - simpler parsing of Xen version in the compatible DT node.
> > 
> > Changes in v3:
> > 
> > - use the "xen,xen" notation rather than "arm,xen";
> > - add an additional check on the presence of the Xen version.
> > 
> > Changes in v2:
> > 
> > - replace pr_info with pr_debug.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  arch/arm/xen/enlighten.c |   61 
> > ++
> >  1 files changed, 61 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index c535540..6a0217d 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -5,6 +5,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  struct start_info _xen_start_info;
> >  struct start_info *xen_start_info = &_xen_start_info;
> > @@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct 
> > *vma,
> > return -ENOSYS;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > +
> > +/*
> > + * see Documentation/devicetree/bindings/arm/xen.txt for the
> > + * documentation of the Xen Device Tree format.
> > + */
> > +static int __init xen_guest_init(void)
> > +{
> > +   struct xen_add_to_physmap xatp;
> > +   static struct shared_info *shared_info_page = 0;
> > +   struct device_node *node;
> > +   int len;
> > +   const char *s = NULL;
> > +   const char *version = NULL;
> > +   const char *xen_prefix = "xen,xen-";
> > +
> > +   node = of_find_compatible_node(NULL, NULL, "xen,xen");
> > +   if (!node) {
> > +   pr_debug("No Xen support\n");
> > +   return 0;
> > +   }
> > +   s = of_get_property(node, "compatible", &len);
> > +   if (strlen(xen_prefix) + 3  < len &&
> > +   !strncmp(xen_prefix, s, strlen(xen_prefix)))
> 
> If we have version '4.3.1' won't this trip us over?

This isn't an issue:

if (8 + 3 < 14 &&
!strncmp("xen,xen-", "xen,xen-4.3.1", 8)

would return true

and version is set to "4.3.1".


> Or if we only have 'major' and 'minor', then won't '4.11' trip us
> over too?

For the same reason this shouldn't be an issue either:

if (8 + 3 < 13 &&
!strncmp("xen,xen-", "xen,xen-4.11", 8)

would return true

and version would be set to "4.11".

BTW I have just tried both out of paranoia and it works as expected.


> > +   version = s + strlen(xen_prefix);
> > +   if (version == NULL) {
> > +   pr_debug("Xen version not found\n");
> > +   return 0;
> > +   }
> > +   xen_domain_type = XEN_HVM_DOMAIN;
> > +
> > +   if (!shared_info_page)
> > +   shared_info_page = (struct shared_info *)
> > +   get_zeroed_page(GFP_KERNEL);
> > +   if (!shared_info_page) {
> > +   pr_err("not enough memory\n");
> > +   return -ENOMEM;
> > +   }
> > +   xatp.domid = DOMID_SELF;
> > +   xatp.idx = 0;
> > +   xatp.space = XENMAPSPACE_shared_info;
> > +   xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> > +   if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
> > +   BUG();
> > +
> > +   HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> > +
> > +   /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
> > +* page, we use it in the event channel upcall and in some pvclock
> > +* related functions. We don't need the vcpu_info placement
> > +* optimizations because we don't use any pv_mmu or pv_irq op on
> > +* HVM.
> > +* The shared info contains exactly 1 CPU (the boot CPU). The guest
> > +* is required to use VCPUOP_register_vcpu_info to place vcpu info
> > +* for secondary CPUs as they are brought up. */
> > +   per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > +   return 0;
> > +}
> > +core_initcall(xen_guest_init);
> > -- 
> > 1.7.2.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 14/24] xen/arm: initialize grant_table on ARM

[Stefano Stabellini]

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > Initialize the grant table mapping at the address specified at index 0
> > in the DT under the /xen node.
> > After the grant table is initialized, call xenbus_probe (if not dom0).
> 
> So we don't really care about the grant's size then? The DT xen.txt
> talks about it..

I am assuming that the size of the memory region specified in the device
tree is sufficiently large to map the entire grant table, given that both
the device tree hypervisor entry and the grant table size comes from Xen.

The grant table size is currently queried to Xen directly via an
hypercall (GNTTABOP_query_size). Basically the size in the device tree
is redundant information.


> > Changes in v2:
> > 
> > - introduce GRANT_TABLE_PHYSADDR;
> > - remove unneeded initialization of boot_max_nr_grant_frames.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  arch/arm/xen/enlighten.c |   14 ++
> >  1 files changed, 14 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index c2a47a7..036a4d8 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -1,8 +1,12 @@
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> >   * see Documentation/devicetree/bindings/arm/xen.txt for the
> >   * documentation of the Xen Device Tree format.
> >   */
> > +#define GRANT_TABLE_PHYSADDR 0
> >  static int __init xen_guest_init(void)
> >  {
> > struct xen_add_to_physmap xatp;
> > @@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
> > const char *s = NULL;
> > const char *version = NULL;
> > const char *xen_prefix = "xen,xen-";
> > +   struct resource res;
> >  
> > node = of_find_compatible_node(NULL, NULL, "xen,xen");
> > if (!node) {
> > @@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
> > pr_debug("Xen version not found\n");
> > return 0;
> > }
> > +   if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
> > +   return 0;
> > +   xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
> > xen_domain_type = XEN_HVM_DOMAIN;
> >  
> > xen_setup_features();
> > @@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
> >  * is required to use VCPUOP_register_vcpu_info to place vcpu info
> >  * for secondary CPUs as they are brought up. */
> > per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > +
> > +   gnttab_init();
> > +   if (!xen_initial_domain())
> > +   xenbus_probe(NULL);
> > +
> > return 0;
> >  }
> >  core_initcall(xen_guest_init);
> > -- 
> > 1.7.2.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 14/24] xen/arm: initialize grant_table on ARM

[Stefano Stabellini]

On Fri, 14 Sep 2012, Ian Campbell wrote:
> On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > > > Initialize the grant table mapping at the address specified at index 0
> > > > in the DT under the /xen node.
> > > > After the grant table is initialized, call xenbus_probe (if not dom0).
> > > 
> > > So we don't really care about the grant's size then? The DT xen.txt
> > > talks about it..
> > 
> > I am assuming that the size of the memory region specified in the device
> > tree is sufficiently large to map the entire grant table, given that both
> > the device tree hypervisor entry and the grant table size comes from Xen.
> 
> Actually, the grant table can grow dynamically under the control of the
> guest, I think you just pass GNTTABOP_setup_table with some more frames.
> See drivers/xen/grant_table.c:gnttab_expand().

gnttab_expand can return error if the new size exceeds
gnttab_max_grant_frames(), that is implemented using
GNTTABOP_query_size.


> > The grant table size is currently queried to Xen directly via an
> > hypercall (GNTTABOP_query_size). Basically the size in the device tree
> > is redundant information.
> 
> This size is the size of the physical address space where the guest
> could chose map grant table frames. It could be either larger or smaller
> than the actual grant table. (smaller because the guest could use
> physical addresses not within this region, if it wanted to for some
> reason).

Right.

What I am saying is that I assume that the memory region specified in
the device tree is greater or equal than gnttab_max_grant_frames().
Maybe I should add this to the device tree doc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/10] xen/swiotlb: Move the error strings to its own function.

[Stefano Stabellini]

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> That way we can more easily reuse those errors when using the
> late SWIOTLB init.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Stefano Stabellini 


>  drivers/xen/swiotlb-xen.c |   35 +++
>  1 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index a2aad6e..701b103 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -154,11 +154,33 @@ static unsigned long xen_set_nslabs(unsigned long 
> nr_tbl)
>  
>   return xen_io_tlb_nslabs << IO_TLB_SHIFT;
>  }
> +
> +enum xen_swiotlb_err {
> + XEN_SWIOTLB_UNKNOWN = 0,
> + XEN_SWIOTLB_ENOMEM,
> + XEN_SWIOTLB_EFIXUP
> +};
> +
> +static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
> +{
> + switch (err) {
> + case XEN_SWIOTLB_ENOMEM:
> + return "Cannot allocate Xen-SWIOTLB buffer\n";
> + case XEN_SWIOTLB_EFIXUP:
> + return "Failed to get contiguous memory for DMA from Xen!\n"\
> + "You either: don't have the permissions, do not have"\
> + " enough free memory under 4GB, or the hypervisor memory"\
> + " is too fragmented!";
> + default:
> + break;
> + }
> + return "";
> +}
>  void __init xen_swiotlb_init(int verbose)
>  {
>   unsigned long bytes;
>   int rc = -ENOMEM;
> - char *m = NULL;
> + enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
>   unsigned int repeat = 3;
>  
>   xen_io_tlb_nslabs = swiotlb_nr_tbl();
> @@ -169,7 +191,7 @@ retry:
>*/
>   xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>   if (!xen_io_tlb_start) {
> - m = "Cannot allocate Xen-SWIOTLB buffer!\n";
> + m_ret = XEN_SWIOTLB_ENOMEM;
>   goto error;
>   }
>   xen_io_tlb_end = xen_io_tlb_start + bytes;
> @@ -181,10 +203,7 @@ retry:
>  xen_io_tlb_nslabs);
>   if (rc) {
>   free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> - m = "Failed to get contiguous memory for DMA from Xen!\n"\
> - "You either: don't have the permissions, do not have"\
> - " enough free memory under 4GB, or the hypervisor memory"\
> - "is too fragmented!";
> + m_ret = XEN_SWIOTLB_EFIXUP;
>   goto error;
>   }
>   start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> @@ -199,8 +218,8 @@ error:
> (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
>   goto retry;
>   }
> - xen_raw_printk("%s (rc:%d)", m, rc);
> - panic("%s (rc:%d)", m, rc);
> + xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> + panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>  }
>  
>  void *
> -- 
> 1.7.7.6
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] xen/swiotlb: Remove functions not needed anymore.

[Stefano Stabellini]

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> Sparse warns us off:
> drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not 
> declared. Should it be static?
> drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was 
> not declared. Should it be static?
> 
> and it looks like we do not need this function at all.

A grep seems to find them used in arch/x86/xen/pci-swiotlb-xen.c.
I fail to see where you removed them from pci-swiotlb-xen.c. Is it in
this patch series or another one?


> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/swiotlb-xen.c |   16 
>  include/xen/swiotlb-xen.h |9 -
>  2 files changed, 0 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index f0825cb..6f81994 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -514,14 +514,6 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct 
> scatterlist *sgl,
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
>  
> -int
> -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> -enum dma_data_direction dir)
> -{
> - return xen_swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> -}
> -EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg);
> -
>  /*
>   * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
>   * concerning calls here are the same as for swiotlb_unmap_page() above.
> @@ -542,14 +534,6 @@ xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct 
> scatterlist *sgl,
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg_attrs);
>  
> -void
> -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int 
> nelems,
> -  enum dma_data_direction dir)
> -{
> - return xen_swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> -}
> -EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg);
> -
>  /*
>   * Make physical memory consistent for a set of streaming mode DMA 
> translations
>   * after a transfer.
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index f26f9f3..a0db2b7 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -23,15 +23,6 @@ extern dma_addr_t xen_swiotlb_map_page(struct device *dev, 
> struct page *page,
>  extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
>  size_t size, enum dma_data_direction dir,
>  struct dma_attrs *attrs);
> -/*
> -extern int
> -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> -enum dma_data_direction dir);
> -
> -extern void
> -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> -  enum dma_data_direction dir);
> -*/
>  extern int
>  xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>int nelems, enum dma_data_direction dir,
> -- 
> 1.7.7.6
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/10] xen/swiotlb: Move the nr_tbl determination in its own function.

[Stefano Stabellini]

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> Moving the function out of the way to prepare for the late
> SWIOTLB init.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Stefano Stabellini 

>  drivers/xen/swiotlb-xen.c |   21 +++--
>  1 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 1afb4fb..a2aad6e 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -144,25 +144,26 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long 
> nslabs)
>   } while (i < nslabs);
>   return 0;
>  }
> +static unsigned long xen_set_nslabs(unsigned long nr_tbl)
> +{
> + if (!nr_tbl) {
> + xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
> + xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
> + } else
> + xen_io_tlb_nslabs = nr_tbl;
>  
> + return xen_io_tlb_nslabs << IO_TLB_SHIFT;
> +}
>  void __init xen_swiotlb_init(int verbose)
>  {
>   unsigned long bytes;
>   int rc = -ENOMEM;
> - unsigned long nr_tbl;
>   char *m = NULL;
>   unsigned int repeat = 3;
>  
> - nr_tbl = swiotlb_nr_tbl();
> - if (nr_tbl)
> - xen_io_tlb_nslabs = nr_tbl;
> - else {
> - xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
> - xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
> - }
> + xen_io_tlb_nslabs = swiotlb_nr_tbl();
>  retry:
> - bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
> -
> + bytes = xen_set_nslabs(xen_io_tlb_nslabs);
>   /*
>* Get IO TLB memory from any location.
>*/
> -- 
> 1.7.7.6
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/10] xen/swiotlb: Depending on after_bootmem is not correct.

[Stefano Stabellini]

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> When PCI IOMMUs are initialized it is after after_bootmem but
> before a lot of "other" subsystems are initialized. As such
> the check for after_bootmem is incorrect and we should
> just use a parameter to define whether we are early or late.
> 
> This solves this bootup problem:
> 
> __ex_table already sorted, skipping sortM
> Initializing CPU#0
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Cannot allocate Xen-SWIOTLB buffer (rc:-12)
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/xen/pci-swiotlb-xen.c |4 ++--
>  drivers/xen/swiotlb-xen.c  |   11 ++-
>  include/xen/swiotlb-xen.h  |2 +-
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index fc0c78f..1608244 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
>  void __init pci_xen_swiotlb_init(void)
>  {
>   if (xen_swiotlb) {
> - xen_swiotlb_init(1);
> + xen_swiotlb_init(1, true /* early */);
>   dma_ops = &xen_swiotlb_dma_ops;
>  
>   /* Make sure ACS will be enabled */
> @@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
>   if (xen_swiotlb)
>   return 0;
>  
> - rc = xen_swiotlb_init(1);
> + rc = xen_swiotlb_init(1, false /* late */);
>   if (rc)
>   return rc;
>  
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 6f81994..7443e19 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err 
> err)
>   }
>   return "";
>  }
> -int __ref xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose, bool early)
>  {
>   unsigned long bytes, order;
>   int rc = -ENOMEM;
> @@ -190,7 +190,7 @@ retry:
>   /*
>* Get IO TLB memory from any location.
>*/
> - if (!after_bootmem)
> + if (early)
>   xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>   else {
>  #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> @@ -220,7 +220,7 @@ retry:
>  bytes,
>  xen_io_tlb_nslabs);
>   if (rc) {
> - if (!after_bootmem)
> + if (early)
>   free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>   else {
>   free_pages((unsigned long)xen_io_tlb_start, order);
> @@ -230,7 +230,8 @@ retry:
>   goto error;
>   }
>   start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> - if (!after_bootmem)
> + rc = 0;
 ^
why does this change belong to this patch?


> + if (early)
>   swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, 
> verbose);
>   else
>   rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, 
> xen_io_tlb_nslabs);
> @@ -244,7 +245,7 @@ error:
>   goto retry;
>   }
>   pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> - if (!after_bootmem)
> + if (early)
>   panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>   else
>   free_pages((unsigned long)xen_io_tlb_start, order);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index a0db2b7..de8bcc6 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -3,7 +3,7 @@
>  
>  #include 
>  
> -extern int xen_swiotlb_init(int verbose);
> +extern int xen_swiotlb_init(int verbose, bool early);
>  
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> -- 
> 1.7.7.6
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.

[Stefano Stabellini]

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL 
> pointer
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL 
> pointer
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Acked-by: Stefano Stabellini 


>  arch/x86/xen/pci-swiotlb-xen.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 406f9c4..fc0c78f 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -97,6 +97,6 @@ int pci_xen_swiotlb_init_late(void)
>  EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
>  
>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> -   0,
> +   NULL,
> pci_xen_swiotlb_init,
> -   0);
> +   NULL);
> -- 
> 1.7.7.6
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/10] xen/swiotlb: Use the swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is used.

[Stefano Stabellini]

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> With this patch we provide the functionality to initialize the
> Xen-SWIOTLB late in the bootup cycle - specifically for
> Xen PCI-frontend. We still will work if the user had
> supplied 'iommu=soft' on the Linux command line.
> 
> CC: FUJITA Tomonori 
> [v1: Fix smatch warnings]
> [v2: Added check for xen_swiotlb]
> [v3: Rebased with new xen-swiotlb changes]
> Signed-off-by: Konrad Rzeszutek Wilk 

Reviewed-by: Stefano Stabellini 


>  arch/x86/include/asm/xen/swiotlb-xen.h |2 +
>  arch/x86/xen/pci-swiotlb-xen.c |   22 ++-
>  drivers/xen/swiotlb-xen.c  |   48 +--
>  include/xen/swiotlb-xen.h  |2 +-
>  4 files changed, 62 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h 
> b/arch/x86/include/asm/xen/swiotlb-xen.h
> index 1be1ab7..ee52fca 100644
> --- a/arch/x86/include/asm/xen/swiotlb-xen.h
> +++ b/arch/x86/include/asm/xen/swiotlb-xen.h
> @@ -5,10 +5,12 @@
>  extern int xen_swiotlb;
>  extern int __init pci_xen_swiotlb_detect(void);
>  extern void __init pci_xen_swiotlb_init(void);
> +extern int pci_xen_swiotlb_init_late(void);
>  #else
>  #define xen_swiotlb (0)
>  static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
>  static inline void __init pci_xen_swiotlb_init(void) { }
> +static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
>  #endif
>  
>  #endif /* _ASM_X86_SWIOTLB_XEN_H */
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 1c17227..406f9c4 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -12,7 +12,7 @@
>  #include 
>  #include 
>  #endif
> -
> +#include 
>  int xen_swiotlb __read_mostly;
>  
>  static struct dma_map_ops xen_swiotlb_dma_ops = {
> @@ -76,6 +76,26 @@ void __init pci_xen_swiotlb_init(void)
>   pci_request_acs();
>   }
>  }
> +
> +int pci_xen_swiotlb_init_late(void)
> +{
> + int rc;
> +
> + if (xen_swiotlb)
> + return 0;
> +
> + rc = xen_swiotlb_init(1);
> + if (rc)
> + return rc;
> +
> + dma_ops = &xen_swiotlb_dma_ops;
> + /* Make sure ACS will be enabled */
> + pci_request_acs();
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
> +
>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> 0,
> pci_xen_swiotlb_init,
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 701b103..f0825cb 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,9 +176,9 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err 
> err)
>   }
>   return "";
>  }
> -void __init xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose)
>  {
> - unsigned long bytes;
> + unsigned long bytes, order;
>   int rc = -ENOMEM;
>   enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
>   unsigned int repeat = 3;
> @@ -186,10 +186,28 @@ void __init xen_swiotlb_init(int verbose)
>   xen_io_tlb_nslabs = swiotlb_nr_tbl();
>  retry:
>   bytes = xen_set_nslabs(xen_io_tlb_nslabs);
> + order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
>   /*
>* Get IO TLB memory from any location.
>*/
> - xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> + if (!after_bootmem)
> + xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> + else {
> +#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> +#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
> + while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
> + xen_io_tlb_start = (void 
> *)__get_free_pages(__GFP_NOWARN, order);
> + if (xen_io_tlb_start)
> + break;
> + order--;
> + }
> + if (order != get_order(bytes)) {
> + pr_warn("Warning: only able to allocate %ld MB "
> + "for software IO TLB\n", (PAGE_SIZE << order) 
> >> 20);
> + xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
> + bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
> + }
> + }
>   if (!xen_io_tlb_start) {
>   m_ret = XEN_SWIOTLB_ENOMEM;
>   goto error;
> @@ -202,14 +220,21 @@ retry:
>  bytes,
>   

Re: linux-next: manual merge of the xen-two tree with Linus' tree

[Stefano Stabellini]

On Tue, 2 Oct 2012, Stephen Rothwell wrote:
> Hi Konrad,
> 
> Today's linux-next merge of the xen-two tree got a conflict in
> drivers/xen/Makefile between commit 9fa5780beea1 ("USB EHCI/Xen:
> propagate controller reset information to hypervisor") from Linus' tree
> and commit 13febc84849d ("xen: do not compile manage, balloon, pci, acpi,
> pcpu and cpu_hotplug on ARM") from the xen-two tree.
> 
> I fixed it up (I am not sure exactly what it should depend on - see
> below) and can carry the fix as necessary (no action is required).
>
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/xen/Makefile
> index a4a3cab,cd28aae..000
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@@ -4,8 -8,11 +8,12 @@@ obj-y+= xenbus
>   nostackp := $(call cc-option, -fno-stack-protector)
>   CFLAGS_features.o   := $(nostackp)
>   
> + obj-$(CONFIG_XEN_DOM0)  += $(dom0-y)
> + dom0-$(CONFIG_PCI) += pci.o
> ++dom0-$(CONFIG_X86) += dbgp.o
> + dom0-$(CONFIG_ACPI) += acpi.o
> + dom0-$(CONFIG_X86) += pcpu.o
>   obj-$(CONFIG_BLOCK) += biomerge.o
> - obj-$(CONFIG_HOTPLUG_CPU)   += cpu_hotplug.o
>   obj-$(CONFIG_XEN_XENCOMM)   += xencomm.o
>   obj-$(CONFIG_XEN_BALLOON)   += xen-balloon.o
>   obj-$(CONFIG_XEN_SELFBALLOONING)+= xen-selfballoon.o
 

Considering that dbgp doesn't seem to be very useful without PCI at the
moment, could we just turn it into:

dom0-$(CONFIG_PCI) += dbgp.o

?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the xen-two tree with Linus' tree

[Stefano Stabellini]

On Tue, 2 Oct 2012, Jan Beulich wrote:
> >>> On 02.10.12 at 12:44, Stefano Stabellini 
> >>>  wrote:
> >> --- a/drivers/xen/Makefile
> >> +++ b/drivers/xen/Makefile
> >> @@@ -4,8 -8,11 +8,12 @@@ obj-y += xenbus
> >>   nostackp := $(call cc-option, -fno-stack-protector)
> >>   CFLAGS_features.o:= $(nostackp)
> >>   
> >> + obj-$(CONFIG_XEN_DOM0)   += $(dom0-y)
> >> + dom0-$(CONFIG_PCI) += pci.o
> >> ++dom0-$(CONFIG_X86) += dbgp.o
> >> + dom0-$(CONFIG_ACPI) += acpi.o
> >> + dom0-$(CONFIG_X86) += pcpu.o
> >>   obj-$(CONFIG_BLOCK)  += biomerge.o
> >> - obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o
> >>   obj-$(CONFIG_XEN_XENCOMM)+= xencomm.o
> >>   obj-$(CONFIG_XEN_BALLOON)+= xen-balloon.o
> >>   obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o
> >  
> > 
> > Considering that dbgp doesn't seem to be very useful without PCI at the
> > moment, could we just turn it into:
> > 
> > dom0-$(CONFIG_PCI) += dbgp.o
> > 
> > ?
> 
> Better not - the code is specifically not PCI-only. And I can't see
> how it would be harmful to be compiled on e.g. ARM (so the
> merge perhaps really should use XEN_DOM0 alone, without
> X86. If anything (and that may indeed be a minor oversight of
> the original patch) one might want it to depend on USB_SUPPORT,
> as without that no in-tree debug port capable driver would be
> able to load (and hence interfere with Xen's use of the debug
> port). However, as long as it builds fine with USB_SUPPORT
> undefined (which I believe it does), having it in the shape it
> is allows for out-of-tree drivers as well (as long as they make
> use of the designated interface).

OK for PCI.
Regarding USB_SUPPORT, considering that gbgp.c calls hcd_to_bus, I think
it would make sense to make it depend on it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] xen: mark xen_init_IRQ __init

[Stefano Stabellini]

xen_init_IRQ should be marked __init because it calls other functions
marked __init and is always called by functions marked __init (on both
x86 and arm).

Also remove the unused EXPORT_SYMBOL_GPL(xen_init_IRQ).

Both changes were introduced by "xen/arm: receive Xen events on ARM".

Signed-off-by: Stefano Stabellini 

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 8672211..59e10a1 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1802,7 +1802,7 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
-void xen_init_IRQ(void)
+void __init xen_init_IRQ(void)
 {
int i;
 
@@ -1846,4 +1846,3 @@ void xen_init_IRQ(void)
}
 #endif
 }
-EXPORT_SYMBOL_GPL(xen_init_IRQ);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] xen/Makefile: fix dom-y build

[Stefano Stabellini]

We need to add $(dom0-y) to obj-$(CONFIG_XEN_DOM0) after dom0-y is
defined otherwise we end up adding nothing.

Signed-off-by: Stefano Stabellini 

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index cd28aae..275abfc 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -8,10 +8,10 @@ obj-y += xenbus/
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o  := $(nostackp)
 
-obj-$(CONFIG_XEN_DOM0) += $(dom0-y)
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_ACPI) += acpi.o
 dom0-$(CONFIG_X86) += pcpu.o
+obj-$(CONFIG_XEN_DOM0) += $(dom0-y)
 obj-$(CONFIG_BLOCK)+= biomerge.o
 obj-$(CONFIG_XEN_XENCOMM)  += xencomm.o
 obj-$(CONFIG_XEN_BALLOON)  += xen-balloon.o
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1

[Stefano Stabellini]

This patch is actually a merge conflict resolution between Konrad's Xen
tree and the following commit:

commit 9fa5780beea1274d498a224822397100022da7d4
Author: Jan Beulich 
Date:   Tue Sep 18 12:23:02 2012 +0100

USB EHCI/Xen: propagate controller reset information to hypervisor


Compile dbgp.o only if CONFIG_USB is defined.
After all xen_dbgp_op relies on hcd_to_bus.

This patch should be applied on top of 

http://marc.info/?l=linux-kernel&m=134919011231980&w=2


Reported-by: Stephen Rothwell 
Signed-off-by: Stefano Stabellini 

diff --cc drivers/xen/Makefile
index a4a3cab,275abfc..33711ad
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@@ -4,8 -8,11 +8,12 @@@ obj-y  += xenbus
  nostackp := $(call cc-option, -fno-stack-protector)
  CFLAGS_features.o := $(nostackp)
  
+ dom0-$(CONFIG_PCI) += pci.o
+ dom0-$(CONFIG_ACPI) += acpi.o
+ dom0-$(CONFIG_X86) += pcpu.o
++dom0-$(CONFIG_USB) += dbgp.o
+ obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
  obj-$(CONFIG_BLOCK)   += biomerge.o
- obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
  obj-$(CONFIG_XEN_XENCOMM) += xencomm.o
  obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o
  obj-$(CONFIG_XEN_SELFBALLOONING)  += xen-selfballoon.o
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen/Makefile: resolve merge conflict with 9fa5780beea1

[Stefano Stabellini]

On Tue, 2 Oct 2012, Jan Beulich wrote:
> >>> On 02.10.12 at 17:13, Stefano Stabellini 
> >>>  wrote:
> > This patch is actually a merge conflict resolution between Konrad's Xen
> > tree and the following commit:
> > 
> > commit 9fa5780beea1274d498a224822397100022da7d4
> > Author: Jan Beulich 
> > Date:   Tue Sep 18 12:23:02 2012 +0100
> > 
> > USB EHCI/Xen: propagate controller reset information to hypervisor
> > 
> > 
> > Compile dbgp.o only if CONFIG_USB is defined.
> 
> Now this is wrong: USB is a tristate config option, yet dbgp.o
> must be built in. This is why I suggested to use USB_SUPPORT
> (if anything at all).

I see. You are right. I'll re-send the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

make dtbs in linus/master

[Stefano Stabellini]

Hello,
I am testing linus/master after the recent merge with the arm-soc tree
and I find that if I choose:

ARM system type
  1. Allow multiple platforms to be selected (ARCH_MULTIPLATFORM) (NEW)
  2. ARM Ltd. Integrator family (ARCH_INTEGRATOR)
  3. ARM Ltd. RealView family (ARCH_REALVIEW)
>  4. ARM Ltd. Versatile family (ARCH_VERSATILE)

in my kernel config, then "make dtbs" doesn't work.
However if I choose ARCH_MULTIPLATFORM then it works properly.

Is it expected?

Cheers,

Stefano
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] xen/Makefile: resolve merge conflict with 9fa5780beea1

[Stefano Stabellini]

This patch is actually a merge conflict resolution between Konrad's Xen
tree and the following commit:

commit 9fa5780beea1274d498a224822397100022da7d4
Author: Jan Beulich 
Date:   Tue Sep 18 12:23:02 2012 +0100

USB EHCI/Xen: propagate controller reset information to hypervisor


Compile dbgp.o only if CONFIG_USB_SUPPORT is defined.
After all xen_dbgp_op relies on hcd_to_bus.

This patch should be applied on top of 

http://marc.info/?l=linux-kernel&m=134919011231980&w=2


Reported-by: Stephen Rothwell 
Suggested-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 

diff --cc drivers/xen/Makefile
index a4a3cab,275abfc..33711ad
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@@ -4,8 -8,11 +8,12 @@@ obj-y  += xenbus
  nostackp := $(call cc-option, -fno-stack-protector)
  CFLAGS_features.o := $(nostackp)
  
+ dom0-$(CONFIG_PCI) += pci.o
+ dom0-$(CONFIG_ACPI) += acpi.o
+ dom0-$(CONFIG_X86) += pcpu.o
++dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
+ obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
  obj-$(CONFIG_BLOCK)   += biomerge.o
- obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
  obj-$(CONFIG_XEN_XENCOMM) += xencomm.o
  obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o
  obj-$(CONFIG_XEN_SELFBALLOONING)  += xen-selfballoon.o
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] xen: resolve merge conflict with 617276307cd4cdb9a95c77efaa3063695af63aa7

[Stefano Stabellini]

The Xen tree tries to add a line to
arch/arm/mach-vexpress/Makefile.boot that has been removed by the
following commit in Linus' master:

commit 617276307cd4cdb9a95c77efaa3063695af63aa7
Author: Rob Herring 
Date:   Thu Sep 6 13:43:04 2012 -0500

ARM: vexpress: convert to multi-platform

In fact the dts Makefile is now arch/arm/boot/dts/Makefile, as per
commit 9cd11c0c47b8690b47e7573311ce5c483cb344ed.


This is the merge resolution patch.

Signed-off-by: Stefano Stabellini 

diff --cc arch/arm/boot/dts/Makefile
index 43c084c,000..4745c1f
mode 100644,00..100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@@ -1,101 -1,0 +1,102 @@@
 +ifeq ($(CONFIG_OF),y)
 +
 +dtb-$(CONFIG_ARCH_AT91) += aks-cdu.dtb \
 +  at91sam9263ek.dtb \
 +  at91sam9g20ek_2mmc.dtb \
 +  at91sam9g20ek.dtb \
 +  at91sam9g25ek.dtb \
 +  at91sam9m10g45ek.dtb \
 +  at91sam9n12ek.dtb \
 +  ethernut5.dtb \
 +  evk-pro3.dtb \
 +  kizbox.dtb \
 +  tny_a9260.dtb \
 +  tny_a9263.dtb \
 +  tny_a9g20.dtb \
 +  usb_a9260.dtb \
 +  usb_a9263.dtb \
 +  usb_a9g20.dtb
 +dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 +dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 +  exynos4210-smdkv310.dtb \
 +  exynos4210-trats.dtb \
 +  exynos5250-smdk5250.dtb
 +dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
 +dtb-$(CONFIG_ARCH_IMX5) += imx51-babbage.dtb \
 +  imx53-ard.dtb \
 +  imx53-evk.dtb \
 +  imx53-qsb.dtb \
 +  imx53-smd.dtb
 +dtb-$(CONFIG_SOC_IMX6Q) += imx6q-arm2.dtb \
 +  imx6q-sabrelite.dtb \
 +  imx6q-sabresd.dtb
 +dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
 +dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
 +  kirkwood-dns325.dtb \
 +  kirkwood-dreamplug.dtb \
 +  kirkwood-goflexnet.dtb \
 +  kirkwood-ib62x0.dtb \
 +  kirkwood-iconnect.dtb \
 +  kirkwood-lschlv2.dtb \
 +  kirkwood-lsxhl.dtb \
 +  kirkwood-ts219-6281.dtb \
 +  kirkwood-ts219-6282.dtb
 +dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
 +  msm8960-cdp.dtb
 +dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
 +  armada-xp-db.dtb
 +dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
 +  imx53-ard.dtb \
 +  imx53-evk.dtb \
 +  imx53-qsb.dtb \
 +  imx53-smd.dtb \
 +  imx6q-arm2.dtb \
 +  imx6q-sabrelite.dtb \
 +  imx6q-sabresd.dtb
 +dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
 +  imx23-olinuxino.dtb \
 +  imx23-stmp378x_devb.dtb \
 +  imx28-apx4devkit.dtb \
 +  imx28-cfa10036.dtb \
 +  imx28-cfa10049.dtb \
 +  imx28-evk.dtb \
 +  imx28-m28evk.dtb \
 +  imx28-tx28.dtb
 +dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 +  omap3-beagle-xm.dtb \
 +  omap3-evm.dtb \
 +  omap3-tobi.dtb \
 +  omap4-panda.dtb \
 +  omap4-pandaES.dtb \
 +  omap4-var_som.dtb \
 +  omap4-sdp.dtb \
 +  omap5-evm.dtb
 +dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
 +dtb-$(CONFIG_ARCH_U8500) += snowball.dtb
 +dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 +  r8a7740-armadillo800eva.dtb \
 +  sh73a0-kzm9g.dtb
 +dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
 +  spear1340-evb.dtb
 +dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
 +  spear310-evb.dtb \
 +  spear320-evb.dtb
 +dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
 +dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 +  tegra20-medcom-wide.dtb \
 +  tegra20-paz00.dtb \
 +  tegra20-plutux.dtb \
 +  tegra20-seaboard.dtb \
 +  tegra20-tec.dtb \
 +  tegra20-trimslice.dtb \
 +  tegra20-ventana.dtb \
 +  tegra20-whistler.dtb \
 +  tegra30-cardhu-a02.dtb \
 +  tegra30-cardhu-a04.dtb
 +dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
 +  vexpress-v2p-ca9.dtb \
 +  vexpress-v2p-ca15-tc1.dtb \
-   vexpress-v2p-ca15_a7.dtb
++  vexpress-v2p-ca15_a7.dtb \
++  xenvm-4.2.dtb
 +
 +endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini]

PV on HVM guests don't have a start_info page mapped by Xen, so
xen_start_info is just NULL for them.
That is problem because other parts of the code expect xen_start_info to
point to something valid, for example xen_initial_domain() is defined as
follow:

#define xen_initial_domain()(xen_domain() && \
 xen_start_info->flags & SIF_INITDOMAIN)


Allocate a dummy start_info struct and point xen_start_info to it, as we
do on ARM.
This is not going to change things for PV guests because
xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen.

Signed-off-by: Stefano Stabellini 

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf788d3..5f242cb 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping);
 unsigned long  machine_to_phys_nr;
 EXPORT_SYMBOL(machine_to_phys_nr);
 
-struct start_info *xen_start_info;
+static struct start_info _xen_start_info;
+struct start_info *xen_start_info = &_xen_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
 
 struct shared_info xen_dummy_shared_info;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini]

On Wed, 3 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote:
> > PV on HVM guests don't have a start_info page mapped by Xen, so
> > xen_start_info is just NULL for them.
> > That is problem because other parts of the code expect xen_start_info to
> > point to something valid, for example xen_initial_domain() is defined as
> > follow:
> > 
> > #define xen_initial_domain()(xen_domain() && \
> >  xen_start_info->flags & SIF_INITDOMAIN)
> 
> But anyone who calls this before xen_start_info is setup is going to get
> a bogus result, specifically in this case they will think they are domU
> when in reality they are dom0 -- wouldn't it be better to fix those
> callsites?

That cannot be the case because setting up xen_start_info is the very
first thing that is done, before even calling to C.


> Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to
> make catching these cases easier?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini]

On Wed, 3 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote:
> > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote:
> > > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote:
> > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so
> > > > > > xen_start_info is just NULL for them.
> > > > > > That is problem because other parts of the code expect 
> > > > > > xen_start_info to
> > > > > > point to something valid, for example xen_initial_domain() is 
> > > > > > defined as
> > > > > > follow:
> > > > > > 
> > > > > > #define xen_initial_domain()(xen_domain() && \
> > > > > >  xen_start_info->flags & SIF_INITDOMAIN)
> > > > > 
> > > > > But anyone who calls this before xen_start_info is setup is going to 
> > > > > get
> > > > > a bogus result, specifically in this case they will think they are 
> > > > > domU
> > > > > when in reality they are dom0 -- wouldn't it be better to fix those
> > > > > callsites?
> > > > 
> > > > That cannot be the case because setting up xen_start_info is the very
> > > > first thing that is done, before even calling to C.
> > > 
> > > On PV, yes, but you are trying to fix PVHVM here, no?
> > > 
> > > Otherwise if this is always set before calling into C then what is the
> > > purpose of this patch?
> > 
> > to fix this - as PVHVM has it set to NULL and we end up de-referencing
> > the xen_start_info and crashing. As so::
> > 
> 
> Right, so returning to my original point: The caller here is calling
> xen_initial_domain() *before* start info is setup. This is bogus and is
> your actual bug, all this patch does is hide that real issue.

That is because xen_start_info wasn't setup at all for PV on HVM guests.

The real reason is that PV on HVM guests don't have one, but that is
another matter. Until we get rid of all the references to xen_start_info
outside of PV specific code, we should just assume that there is one,
and that is already setup.

One day not too far from now, we might refactor the code to never
reference xen_start_info directly, but I don't think that now is the
time for that. Also consider that this is the same thing we do on ARM.


> With this "fix" the caller of xen_initial_domain shown in this trace now
> gets a rubbish result based on the content of a dummy shared info
> instead of the real answer from that actual shared info.

That is not true. The caller gets a zero result, that is completely
appropriate in this case, given that a PV on HVM guest doesn't have a
start_info.


> The right fix is to fix the caller to not call xen_initial_domain()
> until after the shared info has been setup. Maybe that means moving
> shinfo setup earlier, or maybe it means deferring this call until later
> in the PVHVM case.

I don't think so, we should be able to call xen_initial_domain() at any
point in the code.

The best course of action is taking this fix now (making PVHVM x86
guests behave the same way as ARM guests) and refactor all the callers to
xen_start_info later.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini]

On Wed, 3 Oct 2012, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 03, 2012 at 02:37:53PM +0100, Stefano Stabellini wrote:
> > PV on HVM guests don't have a start_info page mapped by Xen, so
> > xen_start_info is just NULL for them.
> > That is problem because other parts of the code expect xen_start_info to
> > point to something valid, for example xen_initial_domain() is defined as
> > follow:
> > 
> > #define xen_initial_domain()(xen_domain() && \
> >  xen_start_info->flags & SIF_INITDOMAIN)
> > 
> 
> .. introduced by commit 4c071ee5268f7234c3d084b6093bebccc28cdcba
> ("arm: initial Xen support)
> 
> > 
> > Allocate a dummy start_info struct and point xen_start_info to it, as we
> > do on ARM.
> > This is not going to change things for PV guests because
> > xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> Reported-by: Konrad Rzeszutek Wilk 
> > 
> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index bf788d3..5f242cb 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -96,7 +96,8 @@ EXPORT_SYMBOL(machine_to_phys_mapping);
> >  unsigned long  machine_to_phys_nr;
> >  EXPORT_SYMBOL(machine_to_phys_nr);
> >  
> > -struct start_info *xen_start_info;
> > +static struct start_info _xen_start_info;
> 
> And lets change that to
> 'xen_dummy_start_info' to keep in sync with the other dummy one.
> 
> And also add a commnt:
> 
> /*
>  * Since 'xen_initial_domain' dereferences the xen_start_info we need
>  * a dummy structure filled with zeros (for PVHVM guests which initialize
>  * this late). For PV guests we do not have to worry about this as the first
>  * few instructions (startup_xen) set it  properly.
>  */

I agree with all the changes, I'll repost soon

> > +struct start_info *xen_start_info = &_xen_start_info;
> >  EXPORT_SYMBOL_GPL(xen_start_info);
> >  
> >  struct shared_info xen_dummy_shared_info;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini]

PV on HVM guests don't have a start_info page mapped by Xen, so
xen_start_info is just NULL for them.
That is problem because other parts of the code expect xen_start_info to
point to something valid, for example xen_initial_domain() is defined as
follow since commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm:
initial Xen support"):


#define xen_initial_domain()(xen_domain() && \
 xen_start_info->flags & SIF_INITDOMAIN)


Allocate a dummy start_info struct and point xen_start_info to it, as we
do on ARM.
This is not going to change things for PV guests because
xen_start_info is set by arch/x86/xen/xen-head.S:startup_xen.

Signed-off-by: Stefano Stabellini 
Reported-by: Konrad Rzeszutek Wilk 


diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf788d3..b73e6ed 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -96,7 +96,14 @@ EXPORT_SYMBOL(machine_to_phys_mapping);
 unsigned long  machine_to_phys_nr;
 EXPORT_SYMBOL(machine_to_phys_nr);
 
-struct start_info *xen_start_info;
+/*
+ * Since 'xen_initial_domain' dereferences xen_start_info we need
+ * a dummy structure filled with zeros (for PVHVM guests which don't
+ * have one). For PV guests we do not have to worry about this as the first
+ * few instructions (startup_xen) set it properly.
+ */
+static struct start_info xen_dummy_start_info;
+struct start_info *xen_start_info = &xen_dummy_start_info;
 EXPORT_SYMBOL_GPL(xen_start_info);
 
 struct shared_info xen_dummy_shared_info;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini]

On Wed, 3 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote:
> > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote:
> > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote:
> > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote:
> > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so
> > > > > > > > xen_start_info is just NULL for them.
> > > > > > > > That is problem because other parts of the code expect 
> > > > > > > > xen_start_info to
> > > > > > > > point to something valid, for example xen_initial_domain() is 
> > > > > > > > defined as
> > > > > > > > follow:
> > > > > > > > 
> > > > > > > > #define xen_initial_domain()(xen_domain() && \
> > > > > > > >  xen_start_info->flags & SIF_INITDOMAIN)
> > > > > > > 
> > > > > > > But anyone who calls this before xen_start_info is setup is going 
> > > > > > > to get
> > > > > > > a bogus result, specifically in this case they will think they 
> > > > > > > are domU
> > > > > > > when in reality they are dom0 -- wouldn't it be better to fix 
> > > > > > > those
> > > > > > > callsites?
> > > > > > 
> > > > > > That cannot be the case because setting up xen_start_info is the 
> > > > > > very
> > > > > > first thing that is done, before even calling to C.
> > > > > 
> > > > > On PV, yes, but you are trying to fix PVHVM here, no?
> > > > > 
> > > > > Otherwise if this is always set before calling into C then what is the
> > > > > purpose of this patch?
> > > > 
> > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing
> > > > the xen_start_info and crashing. As so::
> > > > 
> > > 
> > > Right, so returning to my original point: The caller here is calling
> > > xen_initial_domain() *before* start info is setup. This is bogus and is
> > > your actual bug, all this patch does is hide that real issue.
> > 
> > That is because xen_start_info wasn't setup at all for PV on HVM guests.
> > 
> > The real reason is that PV on HVM guests don't have one, but that is
> > another matter. Until we get rid of all the references to xen_start_info
> > outside of PV specific code, we should just assume that there is one,
> > and that is already setup.
> > 
> > One day not too far from now, we might refactor the code to never
> > reference xen_start_info directly, but I don't think that now is the
> > time for that. Also consider that this is the same thing we do on ARM.
> 
> We actual fill in the dummy start info with valid information on ARM
> though, we don't just leave it full of zeroes.
> 
> If we do start out with start_info pointing to an uninitialised
> start_info on ARM too then I would argue that this is also a mistake.

Yes, we do point xen_start_info to an uninitialised start_info on ARM
too (I don't think is a mistake). Then when and if we have more
information we write them to start_info.


> We
> should leave the NULL pointer in place until we setup the content of the
> dummy start info -- exactly because the resulting crash indicates to us
> that someone has accessed the si before we've initialised it.

I don't think so. It is initialized to zero, that is the right thing to
do.


> > > With this "fix" the caller of xen_initial_domain shown in this trace now
> > > gets a rubbish result based on the content of a dummy shared info
> > > instead of the real answer from that actual shared info.
> > 
> > That is not true. The caller gets a zero result, that is completely
> > appropriate in this case, given that a PV on HVM guest doesn't have a
> > start_info.
> 
> It's just a side effect of Linux zeroing its bss though and zero
> happening to be the right answer for a PVHVM guest in this case.

well, I would call that "by design" ;-)


> Is it true that zero is an appropriate result for all uses of fields in
> start_info on PVHVM?

I think so. In fact, if we wanted to, we could have the dummy struct
initialized to something different, but I don't think that we should.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini]

On Wed, 3 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-03 at 17:13 +0100, Ian Campbell wrote:
> > On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote:
> > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote:
> > > > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote:
> > > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote:
> > > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote:
> > > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote:
> > > > > > > > > > > PV on HVM guests don't have a start_info page mapped by 
> > > > > > > > > > > Xen, so
> > > > > > > > > > > xen_start_info is just NULL for them.
> > > > > > > > > > > That is problem because other parts of the code expect 
> > > > > > > > > > > xen_start_info to
> > > > > > > > > > > point to something valid, for example 
> > > > > > > > > > > xen_initial_domain() is defined as
> > > > > > > > > > > follow:
> > > > > > > > > > > 
> > > > > > > > > > > #define xen_initial_domain()(xen_domain() && \
> > > > > > > > > > >  xen_start_info->flags & SIF_INITDOMAIN)
> > > > > > > > > > 
> > > > > > > > > > But anyone who calls this before xen_start_info is setup is 
> > > > > > > > > > going to get
> > > > > > > > > > a bogus result, specifically in this case they will think 
> > > > > > > > > > they are domU
> > > > > > > > > > when in reality they are dom0 -- wouldn't it be better to 
> > > > > > > > > > fix those
> > > > > > > > > > callsites?
> > > > > > > > > 
> > > > > > > > > That cannot be the case because setting up xen_start_info is 
> > > > > > > > > the very
> > > > > > > > > first thing that is done, before even calling to C.
> > > > > > > > 
> > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no?
> > > > > > > > 
> > > > > > > > Otherwise if this is always set before calling into C then what 
> > > > > > > > is the
> > > > > > > > purpose of this patch?
> > > > > > > 
> > > > > > > to fix this - as PVHVM has it set to NULL and we end up 
> > > > > > > de-referencing
> > > > > > > the xen_start_info and crashing. As so::
> > > > > > > 
> > > > > > 
> > > > > > Right, so returning to my original point: The caller here is calling
> > > > > > xen_initial_domain() *before* start info is setup. This is bogus 
> > > > > > and is
> > > > > > your actual bug, all this patch does is hide that real issue.
> > > > > 
> > > > > That is because xen_start_info wasn't setup at all for PV on HVM 
> > > > > guests.
> > > > > 
> > > > > The real reason is that PV on HVM guests don't have one, but that is
> > > > > another matter. Until we get rid of all the references to 
> > > > > xen_start_info
> > > > > outside of PV specific code, we should just assume that there is one,
> > > > > and that is already setup.
> > > > > 
> > > > > One day not too far from now, we might refactor the code to never
> > > > > reference xen_start_info directly, but I don't think that now is the
> > > > > time for that. Also consider that this is the same thing we do on ARM.
> > > > 
> > > > We actual fill in the dummy start info with valid information on ARM
> > > > though, we don't just leave it full of zeroes.
> > > > 
> > > > If we do start out with start_info pointing to an uninitialised
> > > > st