OMAP5 port.

OMAP5 port.

[Andrii Anisov]

[-- Attachment #1.1: Type: text/plain, Size: 1723 bytes --]

Hello Ian,

Thank you for your answer about the GIC.

We are doing an experimental porting XEN on a TI OMAP5 based board.
Yep, TI OMAP5 is stillborn but it's a Cortex-A15 based SOC and we have some
boards on a table.
So far we got XEN up and loading Dom0 Linux.
We have a linux 3.4 port for OMAP5. Backported xen/arm patches from git://
xenbits.xen.org/people/sstabellini/linux-pvhvm.git .

Currently our Dom0 boot dies at xenbus_init.
Getting parameters HVM_PARAM_STORE_EVTCHN and HVM_PARAM_STORE_PFN from XEN
returns 0*, *next access to xen_store_evtchn or xen_store_interface fields
is blocked by xen.

I did find how this parameters are acquired from XEN, but they are not
initialized. Could you please clarify how arch.hvm_domain.params should be
initialized. Unfortunately I got no clue about this from vexpress or linaro
xen sources.

One more question: is
http://lists.xen.org/archives/html/xen-devel/2012-09/msg01091.html the
latest version of the patchset?  Is it available as a tarball?

Sincerely,
Andrii Anisov.

On Wed, Mar 6, 2013 at 2:21 AM, Ian Campbell <ian.campbell@citrix.com>wrote:

> On Tue, 2013-03-05 at 19:57 +0000, Andrii Anisov wrote:
> >
> > In a function arch_domain_create() I do see mapping of GIC CPU
> > interface registers space of VM to point to the GIC virtual CPU
> > interface. But can't find how XEN handles VM's accesses to GIC
> > Distributor registers. Could you please explain me how is it done, or
> > point to the correspondent code.
>
> It's handled from the second stage fault handler, see the call to
> handle_mmio from do_trap_data_abort_guest. This eventually ends up
> calling vgic_distr_mmio_handler->{read,write} AKA vgic_distr_mmio_read
> (and ..._write).
>
> Ian.
>
>

[-- Attachment #1.2: Type: text/html, Size: 2636 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: OMAP5 port.

[Ian Campbell]

On Wed, 2013-03-13 at 14:55 +0000, Andrii Anisov wrote:
> We are doing an experimental porting XEN on a TI OMAP5 based board.

Cool!

[...]
> One more question: is
> http://lists.xen.org/archives/html/xen-devel/2012-09/msg01091.html the
> latest version of the patchset?  Is it available as a tarball?

That is an ancient and no doubt very incomplete set of patches, lots has
changed since September last year!

Everything which you need is in the mainline xen.git repository already:
        http://xenbits.xen.org/gitweb/?p=xen.git
        http://wiki.xen.org/wiki/Xen_Repositories
The master branch should be your first port of call.

I didn't bother replying to the other bits of your mail since they are
almost certainly due to running such an ancient hypervisor.

Ian.

Re: OMAP5 port.

[Andrii Anisov]

[-- Attachment #1.1: Type: text/plain, Size: 1306 bytes --]

Ian,

For sure we took the latest hypervisor from xen.git master branch, we have
our specific patches ontop of this commit:

commit ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
Author: Liu Jinsong <jinsong.liu@intel.com>
Date:   Thu Feb 28 09:22:41 2013 +0100

What was the master HEAD on start of this March.

I ask about the suitable kernel patch set we could port on our 3.4 kernel.

Sincerely,
Andrii Anisov.

On Wed, Mar 13, 2013 at 5:01 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Wed, 2013-03-13 at 14:55 +0000, Andrii Anisov wrote:
> > We are doing an experimental porting XEN on a TI OMAP5 based board.
>
> Cool!
>
> [...]
> > One more question: is
> > http://lists.xen.org/archives/html/xen-devel/2012-09/msg01091.html the
> > latest version of the patchset?  Is it available as a tarball?
>
> That is an ancient and no doubt very incomplete set of patches, lots has
> changed since September last year!
>
> Everything which you need is in the mainline xen.git repository already:
>         http://xenbits.xen.org/gitweb/?p=xen.git
>         http://wiki.xen.org/wiki/Xen_Repositories
> The master branch should be your first port of call.
>
> I didn't bother replying to the other bits of your mail since they are
> almost certainly due to running such an ancient hypervisor.
>
> Ian.
>
>

[-- Attachment #1.2: Type: text/html, Size: 2302 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: OMAP5 port.

[Ian Campbell]

Please can you not top post.

On Wed, 2013-03-13 at 15:51 +0000, Andrii Anisov wrote:


> For sure we took the latest hypervisor from xen.git master branch, we
> have our specific patches ontop of this commit:
>         commit ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
>         Author: Liu Jinsong <jinsong.liu@intel.com>
>         Date:   Thu Feb 28 09:22:41 2013 +0100
> What was the master HEAD on start of this March.

Sorry, I misread your link as being to the initial h/v patches.

> I ask about the suitable kernel patch set we could port on our 3.4
> kernel. 

I'm afraid I don't know this for the kernel side, Stefano is the man to
ask.

Ian

Re: OMAP5 port.

[Andrii Anisov]

[-- Attachment #1.1: Type: text/plain, Size: 543 bytes --]

Ian,

Sorry, I misread your link as being to the initial h/v patches.

No problem, anyway thank you for answer.
Is it still suitable list to discuss kernel side questions?

Stefano,

We are porting xen for TI OMAP5 (a Cortex-A15 based SoC). We have 3.4
kernel ported for our chip, could you please suggest proper patch set we
would need backport to get Dom0 kernel. It looks git://
xenbits.xen.org/people/sstabellini/linux-pvhvm.git branch xenarm-for-linus
has the most recent ARMv7V Dom0 sources, but I'm not sure.

Sincerely,
Andrii Anisov.

[-- Attachment #1.2: Type: text/html, Size: 957 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: OMAP5 port.

[Ian Campbell]

On Wed, 2013-03-13 at 16:50 +0000, Andrii Anisov wrote:

> Is it still suitable list to discuss kernel side questions?

As they relate to running that kernel on Xen, yes.

Re: OMAP5 port.

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Wed, 13 Mar 2013, Andrii Anisov wrote:
> Ian,
>       Sorry, I misread your link as being to the initial h/v patches.
> 
> No problem, anyway thank you for answer.
> Is it still suitable list to discuss kernel side questions?
> 
> Stefano,
> 
> We are porting xen for TI OMAP5 (a Cortex-A15 based SoC). We have 3.4 kernel ported for our chip, could you please suggest
> proper patch set we would need backport to get Dom0 kernel. It looks git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
> branch xenarm-for-linus has the most recent ARMv7V Dom0 sources, but I'm not sure.

Anthony (CC'ed) recently backported all the patches needed to get Linux
running on Xen on ARM on Linux 3.4 too, he should be able to tell you
the full list of commits and might even be able to give you a git branch
to pull from.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: OMAP5 port.

[Anthony PERARD]

On 14/03/13 16:42, Stefano Stabellini wrote:
> On Wed, 13 Mar 2013, Andrii Anisov wrote:
>> Ian,
>>       Sorry, I misread your link as being to the initial h/v patches.
>>
>> No problem, anyway thank you for answer.
>> Is it still suitable list to discuss kernel side questions?
>>
>> Stefano,
>>
>> We are porting xen for TI OMAP5 (a Cortex-A15 based SoC). We have 3.4 kernel ported for our chip, could you please suggest
>> proper patch set we would need backport to get Dom0 kernel. It looks git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
>> branch xenarm-for-linus has the most recent ARMv7V Dom0 sources, but I'm not sure.
> 
> Anthony (CC'ed) recently backported all the patches needed to get Linux
> running on Xen on ARM on Linux 3.4 too, he should be able to tell you
> the full list of commits and might even be able to give you a git branch
> to pull from.

Hi Andrii,

Here is a tree with all the backported Xen related patches:
git://xenbits.xen.org/people/aperard/linux-chromebook.git

Most of the commit from 95851ef3f08627307f86f77a7f99acbfff4d4470.. are
the one you will need, with few Exynos related.

But just in case, here is the list:
ea57973 ARM: 7511/1: opcodes: Opcode definitions for the Virtualization
Extensions
1c000c6 xen/events: fix unmask_evtchn for PV on HVM guests
e0ea6b8 xen: Introduce xen_pfn_t for pfn and mfn types
56b772f xen: allow privcmd for HVM guests
f0eaaa4 xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
a782478 xen: missing includes
e42e7a2 xen: resynchronise grant table status codes with upstream
96cd0eb xen/arm: compile and run xenbus
6d3c663 arm: initial Xen support
f02e85e xen/arm: hypercalls
740f966 xen/arm: page.h definitions
a5c02b7 xen/arm: sync_bitops
be13481 xen/arm: empty implementation of grant_table arch specific functions
9a92b51 docs: Xen ARM DT bindings
a883572 xen/arm: Xen detection and shared_info page mapping
9964c0b xen/arm: Introduce xen_ulong_t for unsigned long
b05145a xen: do not compile manage, balloon, pci, acpi, pcpu and
cpu_hotplug on ARM
642afdb xen/arm: introduce CONFIG_XEN on ARM
cb4ecb7 xen/arm: get privilege status
2e4c809 xen/arm: initialize grant_table on ARM
58ffdbb xen/arm: receive Xen events on ARM
a24d975 xen/arm: implement alloc/free_xenballooned_pages with
alloc_pages/kfree
33d1e73 xen/arm: compile blkfront and blkback
dcea9e1 xen/arm: compile netback
cd5afc5 MAINTAINERS: add myself as Xen ARM maintainer
94874cd arm: introduce a DTS for Xen unprivileged virtual machines
c3ae4bd xen/arm: Fix compile errors when drivers are compiled as modules
(export more).
03c4c21 xen/arm: use the __HVC macro
67169ec xen/xen_initial_domain: check that xen_start_info is initialized
2f56f83 xen: mark xen_init_IRQ __init
19fee1a xen/Makefile: fix dom-y build
1f70737 compile fixes
f6647e4 ioremap_cache
22a8d4d xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
d613a45 xen/privcmd: Fix mmap batch ioctl error status copy back.
f57e320 xen/privcmd: return -EFAULT on error
c21ce28 xen/privcmd: Correctly return success from IOCTL_PRIVCMD_MMAPBATCH
b09bc43 xen: add pages parameter to xen_remap_domain_mfn_range
117c19c xen: privcmd: support autotranslated physmap guests.
9310c3a xen: balloon: don't include e820.h
2a884ae xen: balloon: use correct type for frame_list
a22a025 xen: balloon: allow PVMMU interfaces to be compiled out
2f7fc7b xen: arm: enable balloon driver
78e9bed xen: correctly use xen_pfn_t in remap_domain_mfn_range.
f1a593a xen: arm: make p2m operations NOPs
4d8f044 xen: arm: implement remap interfaces needed for privcmd mappings.


Also, the next two commit are fixing the GIC in the DT, so you will
maybe need something similair:
adba8c3 DEBUG Xen: have proper gic
21a3d8a fixup! DEBUG Xen: have proper gic


Hopefully, all those will be enough.

Have fun,

-- 
Anthony PERARD

Re: OMAP5 port.

[Stefano Stabellini]

On Wed, 13 Mar 2013, Ian Campbell wrote:
> Please can you not top post.
> 
> On Wed, 2013-03-13 at 15:51 +0000, Andrii Anisov wrote:
> 
> 
> > For sure we took the latest hypervisor from xen.git master branch, we
> > have our specific patches ontop of this commit:
> >         commit ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
> >         Author: Liu Jinsong <jinsong.liu@intel.com>
> >         Date:   Thu Feb 28 09:22:41 2013 +0100
> > What was the master HEAD on start of this March.
> 
> Sorry, I misread your link as being to the initial h/v patches.
> 
> > I ask about the suitable kernel patch set we could port on our 3.4
> > kernel. 
> 
> I'm afraid I don't know this for the kernel side, Stefano is the man to
> ask.

Sorry for the late reply.

We already have a 3.4 Linux tree with the Xen patches backported on it:
it's actually Google's Linux tree for the Chromebook, but I think you
should find it useful anyway because starting from it, it should be very
easy to rebase the Xen patches on a vanilla 3.4.

Anthony, can you please point Andrii to your 3.4 Linux tree?

Re: OMAP5 port.

[Chen Baozi]

On Fri, Mar 22, 2013 at 01:56:50PM +0000, Stefano Stabellini wrote:
> On Wed, 13 Mar 2013, Ian Campbell wrote:
> > Please can you not top post.
> > 
> > On Wed, 2013-03-13 at 15:51 +0000, Andrii Anisov wrote:
> > 
> > 
> > > For sure we took the latest hypervisor from xen.git master branch, we
> > > have our specific patches ontop of this commit:
> > >         commit ba9ef879973f9bee4b72c8f1d3ef816bc58e5fdc
> > >         Author: Liu Jinsong <jinsong.liu@intel.com>
> > >         Date:   Thu Feb 28 09:22:41 2013 +0100
> > > What was the master HEAD on start of this March.
> > 
> > Sorry, I misread your link as being to the initial h/v patches.
> > 
> > > I ask about the suitable kernel patch set we could port on our 3.4
> > > kernel. 
> > 
> > I'm afraid I don't know this for the kernel side, Stefano is the man to
> > ask.
> 
> Sorry for the late reply.
> 
> We already have a 3.4 Linux tree with the Xen patches backported on it:
> it's actually Google's Linux tree for the Chromebook, but I think you
> should find it useful anyway because starting from it, it should be very
> easy to rebase the Xen patches on a vanilla 3.4.
Hi Stefano,

I've rebuilt Anthony's 3.4 Linux kernel and Xen for ARM on my Chromebook. (If
I'm right, the repo is git://xenbits.xen.org/people/aperard/linux-chromebook.git) 
But I've no idea how to wrap the xen into u-boot format image properly. Is
there any brief introductions about it?

Thanks,

  - Chen Baozi 
> 
> Anthony, can you please point Andrii to your 3.4 Linux tree?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: OMAP5 port.

[Anthony PERARD]

On 22/03/13 15:17, Chen Baozi wrote:
> 
> I've rebuilt Anthony's 3.4 Linux kernel and Xen for ARM on my Chromebook. (If
> I'm right, the repo is git://xenbits.xen.org/people/aperard/linux-chromebook.git) 
> But I've no idea how to wrap the xen into u-boot format image properly. Is
> there any brief introductions about it?

Not yet, sorry for that.

I will write some on the wiki soon, hopefully by Monday.

-- 
Anthony PERARD

Re: OMAP5 port.

[Chen Baozi]

On Fri, Mar 22, 2013 at 03:30:34PM +0000, Anthony PERARD wrote:
> On 22/03/13 15:17, Chen Baozi wrote:
> > 
> > I've rebuilt Anthony's 3.4 Linux kernel and Xen for ARM on my Chromebook. (If
> > I'm right, the repo is git://xenbits.xen.org/people/aperard/linux-chromebook.git) 
> > But I've no idea how to wrap the xen into u-boot format image properly. Is
> > there any brief introductions about it?
> 
> Not yet, sorry for that.
> 
> I will write some on the wiki soon, hopefully by Monday.
Hi Anthony,

Since Julien has updated the wiki about running Xen on Arndale board, I made
a little progress to boot Xen on Chromebook right now. (It seems that u-boot
has loaded Xen's image and switch the control to it.) However the problem
is still there that it is impossible to get the console output after. Is 
there any good ways to catch the booting information to debug?

Thanks,

  - Chen Baozi

> -- 
> Anthony PERARD

Re: OMAP5 port.

[Andrii Anisov]

[-- Attachment #1.1: Type: text/plain, Size: 179 bytes --]

Hello,

For those who are looking for Dom0 patch set for LK 3.4, attached patches
will save some time for you.
These patches are borrowed from Arndale.

Sincerely,
Andrii Anisov.

[-- Attachment #1.2: Type: text/html, Size: 377 bytes --]

[-- Attachment #2: 0001-xen-event-channel-arrays-are-xen_ulong_t-and-not-uns.patch --]
[-- Type: application/octet-stream, Size: 14782 bytes --]

From 12b3ba7091d10c6477dde895ad88df3699bce49f Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 20 Feb 2013 11:48:06 +0000
Subject: [PATCH] xen: event channel arrays are xen_ulong_t and not unsigned
 long

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 <ian.campbell@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir (Xen.org) <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 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 0be4df3..342edc0 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,
+					 struct shared_info *sh,
+					 unsigned int idx)
 {
 	return sh->evtchn_pending[idx] &
 		per_cpu(cpu_evtchn_mask, cpu)[idx] &
@@ -312,8 +327,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 	cpumask_copy(irq_to_desc(irq)->irq_data.affinity, cpumask_of(cpu));
 #endif
 
-	clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
-	set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+	clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq))));
+	set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
 
 	info_for_irq(irq)->cpu = cpu;
 }
@@ -339,19 +354,19 @@ static void init_evtchn_cpu_bindings(void)
 static inline void clear_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_clear_bit(port, &s->evtchn_pending[0]);
+	sync_clear_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline void set_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_pending[0]);
+	sync_set_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 static inline int test_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	return sync_test_bit(port, &s->evtchn_pending[0]);
+	return sync_test_bit(port, BM(&s->evtchn_pending[0]));
 }
 
 
@@ -375,7 +390,7 @@ EXPORT_SYMBOL_GPL(notify_remote_via_irq);
 static void mask_evtchn(int port)
 {
 	struct shared_info *s = HYPERVISOR_shared_info;
-	sync_set_bit(port, &s->evtchn_mask[0]);
+	sync_set_bit(port, BM(&s->evtchn_mask[0]));
 }
 
 static void unmask_evtchn(int port)
@@ -389,7 +404,7 @@ static void unmask_evtchn(int port)
 	if (unlikely((cpu != cpu_from_evtchn(port))))
 		do_hypercall = 1;
 	else
-		evtchn_pending = sync_test_bit(port, &s->evtchn_pending[0]);
+		evtchn_pending = sync_test_bit(port, BM(&s->evtchn_pending[0]));
 
 	if (unlikely(evtchn_pending && xen_hvm_domain()))
 		do_hypercall = 1;
@@ -403,7 +418,7 @@ static void unmask_evtchn(int port)
 	} else {
 		struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
 
-		sync_clear_bit(port, &s->evtchn_mask[0]);
+		sync_clear_bit(port, BM(&s->evtchn_mask[0]));
 
 		/*
 		 * The following is basically the equivalent of
@@ -411,8 +426,8 @@ static void unmask_evtchn(int port)
 		 * the interrupt edge' if the channel is masked.
 		 */
 		if (evtchn_pending &&
-		    !sync_test_and_set_bit(port / BITS_PER_LONG,
-					   &vcpu_info->evtchn_pending_sel))
+		    !sync_test_and_set_bit(port / BITS_PER_EVTCHN_WORD,
+					   BM(&vcpu_info->evtchn_pending_sel)))
 			vcpu_info->evtchn_upcall_pending = 1;
 	}
 
@@ -1189,7 +1204,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 {
 	struct shared_info *sh = HYPERVISOR_shared_info;
 	int cpu = smp_processor_id();
-	unsigned long *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
+	xen_ulong_t *cpu_evtchn = per_cpu(cpu_evtchn_mask, cpu);
 	int i;
 	unsigned long flags;
 	static DEFINE_SPINLOCK(debug_lock);
@@ -1205,7 +1220,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 		pending = (get_irq_regs() && i == cpu)
 			? xen_irqs_disabled(get_irq_regs())
 			: v->evtchn_upcall_mask;
-		printk("%d: masked=%d pending=%d event_sel %0*lx\n  ", i,
+		printk("%d: masked=%d pending=%d event_sel %0*"PRI_xen_ulong"\n  ", i,
 		       pending, v->evtchn_upcall_pending,
 		       (int)(sizeof(v->evtchn_pending_sel)*2),
 		       v->evtchn_pending_sel);
@@ -1214,49 +1229,52 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id)
 
 	printk("\npending:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_pending)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)sizeof(sh->evtchn_pending[0])*2,
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)sizeof(sh->evtchn_pending[0])*2,
 		       sh->evtchn_pending[i],
 		       i % 8 == 0 ? "\n   " : " ");
 	printk("\nglobal mask:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s",
+		printk("%0*"PRI_xen_ulong"%s",
 		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nglobally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       sh->evtchn_pending[i] & ~sh->evtchn_mask[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocal cpu%d mask:\n   ", cpu);
-	for (i = (NR_EVENT_CHANNELS/BITS_PER_LONG)-1; i >= 0; i--)
-		printk("%0*lx%s", (int)(sizeof(cpu_evtchn[0])*2),
+	for (i = (NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD)-1; i >= 0; i--)
+		printk("%0*"PRI_xen_ulong"%s", (int)(sizeof(cpu_evtchn[0])*2),
 		       cpu_evtchn[i],
 		       i % 8 == 0 ? "\n   " : " ");
 
 	printk("\nlocally unmasked:\n   ");
 	for (i = ARRAY_SIZE(sh->evtchn_mask)-1; i >= 0; i--) {
-		unsigned long pending = sh->evtchn_pending[i]
+		xen_ulong_t pending = sh->evtchn_pending[i]
 			& ~sh->evtchn_mask[i]
 			& cpu_evtchn[i];
-		printk("%0*lx%s", (int)(sizeof(sh->evtchn_mask[0])*2),
+		printk("%0*"PRI_xen_ulong"%s",
+		       (int)(sizeof(sh->evtchn_mask[0])*2),
 		       pending, i % 8 == 0 ? "\n   " : " ");
 	}
 
 	printk("\npending list:\n");
 	for (i = 0; i < NR_EVENT_CHANNELS; i++) {
-		if (sync_test_bit(i, sh->evtchn_pending)) {
-			int word_idx = i / BITS_PER_LONG;
+		if (sync_test_bit(i, BM(sh->evtchn_pending))) {
+			int word_idx = i / BITS_PER_EVTCHN_WORD;
 			printk("  %d: event %d -> irq %d%s%s%s\n",
 			       cpu_from_evtchn(i), i,
 			       evtchn_to_irq[i],
-			       sync_test_bit(word_idx, &v->evtchn_pending_sel)
+			       sync_test_bit(word_idx, BM(&v->evtchn_pending_sel))
 					     ? "" : " l2-clear",
-			       !sync_test_bit(i, sh->evtchn_mask)
+			       !sync_test_bit(i, BM(sh->evtchn_mask))
 					     ? "" : " globally-masked",
-			       sync_test_bit(i, cpu_evtchn)
+			       sync_test_bit(i, BM(cpu_evtchn))
 					     ? "" : " locally-masked");
 		}
 	}
@@ -1273,7 +1291,7 @@ static DEFINE_PER_CPU(unsigned int, current_bit_idx);
 /*
  * Mask out the i least significant bits of w
  */
-#define MASK_LSBS(w, i) (w & ((~0UL) << i))
+#define MASK_LSBS(w, i) (w & ((~((xen_ulong_t)0UL)) << i))
 
 /*
  * Search the CPUs pending events bitmasks.  For each one found, map
@@ -1295,18 +1313,19 @@ 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
-		pending_words = xchg(&vcpu_info->evtchn_pending_sel, 0);
+		/*
+		 * Master flag must be cleared /before/ clearing
+		 * selector flag. xchg_xen_ulong must contain an
+		 * appropriate barrier.
+		 */
+		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 +1333,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 +1346,7 @@ static void __xen_evtchn_do_upcall(void)
 				bit_idx = 0;
 				continue;
 			}
-			word_idx = __ffs(words);
+			word_idx = EVTCHN_FIRST_BIT(words);
 
 			pending_bits = active_evtchns(cpu, s, word_idx);
 			bit_idx = 0; /* usually scan entire word from start */
@@ -1342,7 +1361,7 @@ static void __xen_evtchn_do_upcall(void)
 			}
 
 			do {
-				unsigned long bits;
+				xen_ulong_t bits;
 				int port, irq;
 				struct irq_desc *desc;
 
@@ -1352,10 +1371,10 @@ static void __xen_evtchn_do_upcall(void)
 				if (bits == 0)
 					break;
 
-				bit_idx = __ffs(bits);
+				bit_idx = EVTCHN_FIRST_BIT(bits);
 
 				/* Process port. */
-				port = (word_idx * BITS_PER_LONG) + bit_idx;
+				port = (word_idx * BITS_PER_EVTCHN_WORD) + bit_idx;
 				irq = evtchn_to_irq[port];
 
 				if (irq != -1) {
@@ -1364,12 +1383,12 @@ static void __xen_evtchn_do_upcall(void)
 						generic_handle_irq_desc(irq, desc);
 				}
 
-				bit_idx = (bit_idx + 1) % BITS_PER_LONG;
+				bit_idx = (bit_idx + 1) % BITS_PER_EVTCHN_WORD;
 
 				/* Next caller starts at last processed + 1 */
 				__this_cpu_write(current_word_idx,
 						 bit_idx ? word_idx :
-						 (word_idx+1) % BITS_PER_LONG);
+						 (word_idx+1) % BITS_PER_EVTCHN_WORD);
 				__this_cpu_write(current_bit_idx, bit_idx);
 			} while (bit_idx != 0);
 
@@ -1377,7 +1396,7 @@ static void __xen_evtchn_do_upcall(void)
 			if ((word_idx != start_word_idx) || (i != 0))
 				pending_words &= ~(1UL << word_idx);
 
-			word_idx = (word_idx + 1) % BITS_PER_LONG;
+			word_idx = (word_idx + 1) % BITS_PER_EVTCHN_WORD;
 		}
 
 		BUG_ON(!irqs_disabled());
@@ -1487,8 +1506,8 @@ int resend_irq_on_evtchn(unsigned int irq)
 	if (!VALID_EVTCHN(evtchn))
 		return 1;
 
-	masked = sync_test_and_set_bit(evtchn, s->evtchn_mask);
-	sync_set_bit(evtchn, s->evtchn_pending);
+	masked = sync_test_and_set_bit(evtchn, BM(s->evtchn_mask));
+	sync_set_bit(evtchn, BM(s->evtchn_pending));
 	if (!masked)
 		unmask_evtchn(evtchn);
 
@@ -1536,8 +1555,8 @@ static int retrigger_dynirq(struct irq_data *data)
 	if (VALID_EVTCHN(evtchn)) {
 		int masked;
 
-		masked = sync_test_and_set_bit(evtchn, sh->evtchn_mask);
-		sync_set_bit(evtchn, sh->evtchn_pending);
+		masked = sync_test_and_set_bit(evtchn, BM(sh->evtchn_mask));
+		sync_set_bit(evtchn, BM(sh->evtchn_pending));
 		if (!masked)
 			unmask_evtchn(evtchn);
 		ret = 1;
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 886a5d8..53ec416 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -285,7 +285,7 @@ DEFINE_GUEST_HANDLE_STRUCT(multicall_entry);
  * 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 {
 	/*
@@ -341,7 +341,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 pvclock_vcpu_time_info time;
 }; /* 64 bytes (x86) */
@@ -384,8 +384,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.5


[-- Attachment #3: 0001-xen-sysfs-fix-build-warning.patch --]
[-- Type: application/octet-stream, Size: 2634 bytes --]

From 37ea0fcb6a3f3318bf45888e624722a2945cec04 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 17 Oct 2012 09:39:10 +0100
Subject: [PATCH] xen: sysfs: fix build warning.

Define PRI macros for xen_ulong_t and xen_pfn_t and use to fix:
drivers/xen/sys-hypervisor.c:288:4: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'xen_ulong_t' [-Wformat]

Ideally this would use PRIx64 on ARM but these (or equivalent) don't
seem to be available in the kernel.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/interface.h |    2 ++
 arch/x86/include/asm/xen/interface.h |    2 ++
 drivers/xen/sys-hypervisor.c         |    3 ++-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index ae05e56..62160f2 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -31,7 +31,9 @@
 /* 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;
+#define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong "llx"
 /* 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 28fc6211..c5b13e7 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,7 +51,9 @@
  * 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;
+#define PRI_xen_pfn "lx"
 typedef unsigned long xen_ulong_t;
+#define PRI_xen_ulong "lx"
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 66a0a14..96453f8 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -285,7 +285,8 @@ static ssize_t virtual_start_show(struct hyp_sysfs_attr *attr, char *buffer)
 		ret = HYPERVISOR_xen_version(XENVER_platform_parameters,
 					     parms);
 		if (!ret)
-			ret = sprintf(buffer, "%lx\n", parms->virt_start);
+			ret = sprintf(buffer, "%"PRI_xen_ulong"\n",
+				      parms->virt_start);
 		kfree(parms);
 	}
 
-- 
1.7.9.5


[-- Attachment #4: 0001-xen-update-xen_add_to_physmap-interface.patch --]
[-- Type: application/octet-stream, Size: 1540 bytes --]

From b58aaa4b0b3506c094308342d746f600468c63d9 Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 6 Aug 2012 15:27:24 +0100
Subject: [PATCH] xen: update xen_add_to_physmap interface

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 <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
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."

Changes in v2:

- remove erroneous comment in the commit message.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 include/xen/interface/memory.h |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eac3ce1..8d4efc1 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_t    size;
+
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-- 
1.7.9.5


[-- Attachment #5: Type: text/plain, Size: 126 bytes --]

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