linux-next: kvm tree build failure

linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next build (powerpc ppc44x_defconfig) failed like this:

arch/powerpc/kvm/built-in.o: In function `kvm_destroy_vm':
kvm_main.c:(.text+0x2cfc): undefined reference to `kvm_irqfd_release'
arch/powerpc/kvm/built-in.o: In function `kvm_vm_ioctl':
kvm_main.c:(.text+0x3230): undefined reference to `kvm_irqfd'

Caused by commit 302471ec2b5b6f74eba06973fb85e4584d20ef1e ("KVM: irqfd")
which I have reverted for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kvm tree build failure

[Avi Kivity]

Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
> arch/powerpc/kvm/built-in.o: In function `kvm_destroy_vm':
> kvm_main.c:(.text+0x2cfc): undefined reference to `kvm_irqfd_release'
> arch/powerpc/kvm/built-in.o: In function `kvm_vm_ioctl':
> kvm_main.c:(.text+0x3230): undefined reference to `kvm_irqfd'
>
> Caused by commit 302471ec2b5b6f74eba06973fb85e4584d20ef1e ("KVM: irqfd")
> which I have reverted for today.
>   

Sorry about that.  I now have build testing for s390 and ia64, so of 
course it triggered on ppc.

I'll look for a ppc machine for build testing.

-- 
error compiling committee.c: too many arguments to function

Re: linux-next: kvm tree build failure

[Boaz Harrosh]

On 05/21/2009 10:32 AM, Avi Kivity wrote:
> Stephen Rothwell wrote:
>> Hi Avi,
>>
>> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>>
>> arch/powerpc/kvm/built-in.o: In function `kvm_destroy_vm':
>> kvm_main.c:(.text+0x2cfc): undefined reference to `kvm_irqfd_release'
>> arch/powerpc/kvm/built-in.o: In function `kvm_vm_ioctl':
>> kvm_main.c:(.text+0x3230): undefined reference to `kvm_irqfd'
>>
>> Caused by commit 302471ec2b5b6f74eba06973fb85e4584d20ef1e ("KVM: irqfd")
>> which I have reverted for today.
>>   
> 
> Sorry about that.  I now have build testing for s390 and ia64, so of 
> course it triggered on ppc.
> 
> I'll look for a ppc machine for build testing.
> 

Can't you cross compile for ppc? I can't remember someone posted a link
with binary cross-compiler packages a while back.

Boaz

Re: linux-next: kvm tree build failure

[Avi Kivity]

Boaz Harrosh wrote:
>> I'll look for a ppc machine for build testing.
>>
>>     
>
> Can't you cross compile for ppc? I can't remember someone posted a link
> with binary cross-compiler packages a while back.
>
>   

I have userspace to test as well, which needs a ton of cross-compiled 
libraries.

-- 
error compiling committee.c: too many arguments to function

Re: linux-next: kvm tree build failure

[Boaz Harrosh]

On 05/21/2009 10:39 AM, Avi Kivity wrote:
> Boaz Harrosh wrote:
>>> I'll look for a ppc machine for build testing.
>>>
>>>     
>> Can't you cross compile for ppc? I can't remember someone posted a link
>> with binary cross-compiler packages a while back.
>>
>>   
> 
> I have userspace to test as well, which needs a ton of cross-compiled 
> libraries.
> 

A cross compiler produces native foreign code. A Native distribution with
binary libraries will work just as well.

Do you mean to set up all the build environment and dependencies?
Perhaps get a ready made ppc linux image, mount and chroot into it
and build that way.

If only you had an emulator for ppc?

Boaz

Re: linux-next: kvm tree build failure

[Avi Kivity]

Boaz Harrosh wrote:
>> I have userspace to test as well, which needs a ton of cross-compiled 
>> libraries.
>>
>>     
>
> A cross compiler produces native foreign code. A Native distribution with
> binary libraries will work just as well.
>
> Do you mean to set up all the build environment and dependencies?
> Perhaps get a ready made ppc linux image, mount and chroot into it
> and build that way.
>
> If only you had an emulator for ppc?
>   

Life's too short for emulators.

-- 
error compiling committee.c: too many arguments to function

[PATCH] kvm: fix irqfd build failure discovered in linux-next

[Gregory Haskins]

Stephen Rothwell noted a build failure in arch != x86 in last nights
linux-next tree, as noted here:

http://lkml.org/lkml/2009/5/21/32

This patch corrects the build issue by requiring explicit support for
IRQFD to be defined, and only defining it on x86 (the only arch fully
supported).  The code itself isnt architecture dependent, but we need
to add a new file to each makefile, advertise the capability, and
of course, test that it works for each supported arch.  We will submit
patches against each relevant arch at a later time to enable support
there as well.

Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---

 arch/x86/kvm/Makefile    |    1 +
 include/linux/kvm_host.h |   17 +++++++++++++++++
 virt/kvm/eventfd.c       |    6 ++++++
 virt/kvm/kvm_main.c      |    2 +-
 4 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index 01e3c61..e5ce95e 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -1,5 +1,6 @@
 
 EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
+EXTRA_CFLAGS += -DKVM_HAVE_EVENTFD
 
 kvm-y			+= $(addprefix ../../../virt/kvm/, kvm_main.o ioapic.o \
 				coalesced_mmio.o irq_comm.o eventfd.o)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3b6caf5..8600473 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -134,7 +134,9 @@ struct kvm {
 	struct list_head vm_list;
 	struct kvm_io_bus mmio_bus;
 	struct kvm_io_bus pio_bus;
+#ifdef KVM_HAVE_EVENTFD
 	struct list_head irqfds;
+#endif
 	struct kvm_vm_stat stat;
 	struct kvm_arch arch;
 	atomic_t users_count;
@@ -529,7 +531,22 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {}
 
 #endif
 
+#ifdef KVM_HAVE_EVENTFD
+
+void kvm_irqfd_init(struct kvm *kvm);
 int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags);
 void kvm_irqfd_release(struct kvm *kvm);
 
+#else
+
+static inline void kvm_irqfd_init(struct kvm *kvm) {}
+static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
+{
+	return -EINVAL;
+}
+
+static inline void kvm_irqfd_release(struct kvm *kvm) {}
+
+#endif /* KVM_HAVE_EVENTFD */
+
 #endif
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 72a282e..c63ff6a 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -206,6 +206,12 @@ kvm_deassign_irqfd(struct kvm *kvm, int fd, int gsi)
 	return count ? count : -ENOENT;
 }
 
+void
+kvm_irqfd_init(struct kvm *kvm)
+{
+	INIT_LIST_HEAD(&kvm->irqfds);
+}
+
 int
 kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
 {
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index b58837d..de042cb 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -983,7 +983,7 @@ static struct kvm *kvm_create_vm(void)
 	atomic_inc(&kvm->mm->mm_count);
 	spin_lock_init(&kvm->mmu_lock);
 	kvm_io_bus_init(&kvm->pio_bus);
-	INIT_LIST_HEAD(&kvm->irqfds);
+	kvm_irqfd_init(kvm);
 	mutex_init(&kvm->lock);
 	kvm_io_bus_init(&kvm->mmio_bus);
 	init_rwsem(&kvm->slots_lock);

Re: [PATCH] kvm: fix irqfd build failure discovered in linux-next

[Avi Kivity]

Gregory Haskins wrote:
> Stephen Rothwell noted a build failure in arch != x86 in last nights
> linux-next tree, as noted here:
>
> http://lkml.org/lkml/2009/5/21/32
>
> This patch corrects the build issue by requiring explicit support for
> IRQFD to be defined, and only defining it on x86 (the only arch fully
> supported).  The code itself isnt architecture dependent, but we need
> to add a new file to each makefile, advertise the capability, and
> of course, test that it works for each supported arch.  We will submit
> patches against each relevant arch at a later time to enable support
> there as well.
>
> Signed-off-by: Gregory Haskins <ghaskins@novell.com>
> ---
>
>  arch/x86/kvm/Makefile    |    1 +
>  include/linux/kvm_host.h |   17 +++++++++++++++++
>  virt/kvm/eventfd.c       |    6 ++++++
>  virt/kvm/kvm_main.c      |    2 +-
>  4 files changed, 25 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index 01e3c61..e5ce95e 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -1,5 +1,6 @@
>  
>  EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
> +EXTRA_CFLAGS += -DKVM_HAVE_EVENTFD
>  
>   

The standard idiom for this is to use a Kconfig symbol; see for example 
HAVE_KVM_IRQCHIP in arch/*/kvm/Kconfig.


-- 
error compiling committee.c: too many arguments to function

Re: [PATCH] kvm: fix irqfd build failure discovered in linux-next

[Gregory Haskins]

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

Avi Kivity wrote:
> Gregory Haskins wrote:
>> Stephen Rothwell noted a build failure in arch != x86 in last nights
>> linux-next tree, as noted here:
>>
>> http://lkml.org/lkml/2009/5/21/32
>>
>> This patch corrects the build issue by requiring explicit support for
>> IRQFD to be defined, and only defining it on x86 (the only arch fully
>> supported).  The code itself isnt architecture dependent, but we need
>> to add a new file to each makefile, advertise the capability, and
>> of course, test that it works for each supported arch.  We will submit
>> patches against each relevant arch at a later time to enable support
>> there as well.
>>
>> Signed-off-by: Gregory Haskins <ghaskins@novell.com>
>> ---
>>
>>  arch/x86/kvm/Makefile    |    1 +
>>  include/linux/kvm_host.h |   17 +++++++++++++++++
>>  virt/kvm/eventfd.c       |    6 ++++++
>>  virt/kvm/kvm_main.c      |    2 +-
>>  4 files changed, 25 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
>> index 01e3c61..e5ce95e 100644
>> --- a/arch/x86/kvm/Makefile
>> +++ b/arch/x86/kvm/Makefile
>> @@ -1,5 +1,6 @@
>>  
>>  EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
>> +EXTRA_CFLAGS += -DKVM_HAVE_EVENTFD
>>  
>>   
>
> The standard idiom for this is to use a Kconfig symbol; see for
> example HAVE_KVM_IRQCHIP in arch/*/kvm/Kconfig.

Ah, I didn't realize I could do this in such a contained manner.  I was
afraid of polluting the top level arch/Kconfig, which is why I went this
other route.   But I see from your example that this is not the case.  I
will make a v2 with this change.

-Greg

>
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

[PATCH v2] kvm: fix irqfd build failure discovered in linux-next

[Gregory Haskins]

Stephen Rothwell noted a build failure in arch != x86 in last nights
linux-next tree, as noted here:

http://lkml.org/lkml/2009/5/21/32

This patch corrects the build issue by requiring explicit support for
IRQFD to be defined, and only defining it on x86 (the only arch fully
supported).  The code itself isnt architecture dependent, but we need
to add a new file to each makefile, advertise the capability, and
of course, test that it works for each supported arch.  We will submit
patches against each relevant arch at a later time to enable support
there as well.

Signed-off-by: Gregory Haskins <ghaskins@novell.com>
---

 arch/x86/kvm/Kconfig     |    4 ++++
 include/linux/kvm_host.h |   17 +++++++++++++++++
 virt/kvm/eventfd.c       |    6 ++++++
 virt/kvm/kvm_main.c      |    2 +-
 4 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 8600a09..6460091 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -8,6 +8,10 @@ config HAVE_KVM_IRQCHIP
        bool
        default y
 
+config HAVE_KVM_EVENTFD
+       bool
+       default y
+
 menuconfig VIRTUALIZATION
 	bool "Virtualization"
 	depends on HAVE_KVM || X86
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3b6caf5..28bd112 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -134,7 +134,9 @@ struct kvm {
 	struct list_head vm_list;
 	struct kvm_io_bus mmio_bus;
 	struct kvm_io_bus pio_bus;
+#ifdef CONFIG_HAVE_KVM_EVENTFD
 	struct list_head irqfds;
+#endif
 	struct kvm_vm_stat stat;
 	struct kvm_arch arch;
 	atomic_t users_count;
@@ -529,7 +531,22 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {}
 
 #endif
 
+#ifdef CONFIG_HAVE_KVM_EVENTFD
+
+void kvm_irqfd_init(struct kvm *kvm);
 int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags);
 void kvm_irqfd_release(struct kvm *kvm);
 
+#else
+
+static inline void kvm_irqfd_init(struct kvm *kvm) {}
+static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
+{
+	return -EINVAL;
+}
+
+static inline void kvm_irqfd_release(struct kvm *kvm) {}
+
+#endif /* CONFIG_HAVE_KVM_EVENTFD */
+
 #endif
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 72a282e..c63ff6a 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -206,6 +206,12 @@ kvm_deassign_irqfd(struct kvm *kvm, int fd, int gsi)
 	return count ? count : -ENOENT;
 }
 
+void
+kvm_irqfd_init(struct kvm *kvm)
+{
+	INIT_LIST_HEAD(&kvm->irqfds);
+}
+
 int
 kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
 {
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index b58837d..de042cb 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -983,7 +983,7 @@ static struct kvm *kvm_create_vm(void)
 	atomic_inc(&kvm->mm->mm_count);
 	spin_lock_init(&kvm->mmu_lock);
 	kvm_io_bus_init(&kvm->pio_bus);
-	INIT_LIST_HEAD(&kvm->irqfds);
+	kvm_irqfd_init(kvm);
 	mutex_init(&kvm->lock);
 	kvm_io_bus_init(&kvm->mmio_bus);
 	init_rwsem(&kvm->slots_lock);

Re: [PATCH] kvm: fix irqfd build failure discovered in linux-next

[Avi Kivity]

Gregory Haskins wrote:
>>>  EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
>>> +EXTRA_CFLAGS += -DKVM_HAVE_EVENTFD
>>>  
>>>   
>>>       
>> The standard idiom for this is to use a Kconfig symbol; see for
>> example HAVE_KVM_IRQCHIP in arch/*/kvm/Kconfig.
>>     
>
> Ah, I didn't realize I could do this in such a contained manner.  I was
> afraid of polluting the top level arch/Kconfig, which is why I went this
> other route.   But I see from your example that this is not the case.  I
> will make a v2 with this change.
>   

Note the situation is not as good as it could be, as you have to 
replicate the Kconfig for each arch.  One day I'll set up 
virt/kvm/Kconfig which will set up defaults, so archs can override them.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH v2] kvm: fix irqfd build failure discovered in linux-next

[Avi Kivity]

Gregory Haskins wrote:
> Stephen Rothwell noted a build failure in arch != x86 in last nights
> linux-next tree, as noted here:
>
> http://lkml.org/lkml/2009/5/21/32
>
> This patch corrects the build issue by requiring explicit support for
> IRQFD to be defined, and only defining it on x86 (the only arch fully
> supported).  The code itself isnt architecture dependent, but we need
> to add a new file to each makefile, advertise the capability, and
> of course, test that it works for each supported arch.  We will submit
> patches against each relevant arch at a later time to enable support
> there as well.
>
>  
> +config HAVE_KVM_EVENTFD
> +       bool
> +       default y
> +
>   

The build system will complain if it sees a symbol used but not defined; 
so you have to define it for all four archs.  So I went ahead and did 
virt/kvm/Kconfig and adapted your patch to use it.


-- 
error compiling committee.c: too many arguments to function

Re: [PATCH v2] kvm: fix irqfd build failure discovered in linux-next

[Gregory Haskins]

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

Avi Kivity wrote:
> Gregory Haskins wrote:
>> Stephen Rothwell noted a build failure in arch != x86 in last nights
>> linux-next tree, as noted here:
>>
>> http://lkml.org/lkml/2009/5/21/32
>>
>> This patch corrects the build issue by requiring explicit support for
>> IRQFD to be defined, and only defining it on x86 (the only arch fully
>> supported).  The code itself isnt architecture dependent, but we need
>> to add a new file to each makefile, advertise the capability, and
>> of course, test that it works for each supported arch.  We will submit
>> patches against each relevant arch at a later time to enable support
>> there as well.
>>
>>  
>> +config HAVE_KVM_EVENTFD
>> +       bool
>> +       default y
>> +
>>   
>
> The build system will complain if it sees a symbol used but not
> defined; so you have to define it for all four archs.  So I went ahead
> and did virt/kvm/Kconfig and adapted your patch to use it.
>
>

Cool, thanks!

-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

Re: linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

On Tue, 19 Jan 2010 09:57:41 +0200 Avi Kivity <avi@redhat.com> wrote:
>
> Doh, I noticed it and forgot to port the commit to linux-next.
> 
> Marcelo, can you add 270d27e07d8 to the .34 queue?

OK, good.

> (Stephen, please copy Marcelo on all kvm issues, we share maintainership 
> by switching tree ownership at semi random points in time so I can't 
> always do anything about the breakage personally).

OK, I have added Marcelo to the contacts for the kvm tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: kvm tree build failure

[Avi Kivity]

On 01/19/2010 03:42 AM, Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> usr/include/asm/kvm_para.h:5: included file 'asm-x86/hyperv.h' is not exported
>
> Caused by commit 328aca1e523bedc49592bbdd65bedaa690b8df29 ("KVM:
> Implement bare minimum of HYPER-V MSRs").
>
> I have used the kvm tree from next-20100118 for today.
>    

Doh, I noticed it and forgot to port the commit to linux-next.

Marcelo, can you add 270d27e07d8 to the .34 queue?

(Stephen, please copy Marcelo on all kvm issues, we share maintainership 
by switching tree ownership at semi random points in time so I can't 
always do anything about the breakage personally).

-- 
error compiling committee.c: too many arguments to function

linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

usr/include/asm/kvm_para.h:5: included file 'asm-x86/hyperv.h' is not exported

Caused by commit 328aca1e523bedc49592bbdd65bedaa690b8df29 ("KVM:
Implement bare minimum of HYPER-V MSRs").

I have used the kvm tree from next-20100118 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: kvm tree build failure

[Avi Kivity]

On 01/11/2010 10:07 AM, Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
>    

I pushed out a fix from Alex.

-- 
error compiling committee.c: too many arguments to function

Re: linux-next: kvm tree build failure

[Stephen Rothwell]

Hi Avi,

On Mon, 11 Jan 2010 19:07:49 +1100 Stephen Rothwell <Stephen@Rothwell.id.au> wrote:
>
> Caused by commit 7f31fad9aad3bb9df95793d72e037bb4d587ee83 ("KVM: PPC: Use
> accessor functions for GPR access").  I couldn't easily revert that
> commit, so I applied the following fixup patch instead.

After which I got this:

arch/powerpc/kvm/built-in.o: In function `kvmppc_handler_0':
(.text+0x69ba): undefined reference to `VCPU_GPRS'
arch/powerpc/kvm/built-in.o: In function `kvmppc_handler_0':
(.text+0x69be): undefined reference to `VCPU_GPRS'
arch/powerpc/kvm/built-in.o: In function `kvmppc_handler_1':
(.text+0x69e6): undefined reference to `VCPU_GPRS'
arch/powerpc/kvm/built-in.o: In function `kvmppc_handler_1':
(.text+0x69ea): undefined reference to `VCPU_GPRS'
arch/powerpc/kvm/built-in.o: In function `kvmppc_handler_2':
(.text+0x6a12): undefined reference to `VCPU_GPRS'
arch/powerpc/kvm/built-in.o:(.text+0x6a16): more undefined references to `VCPU_GPRS' follow

Caused by commit f38ae173fffd673d4bc5cb4062d9dc27146cfb4a ("KVM: PPC: Use
PACA backed shadow vcpu").  I have applied the following fixup patch for
today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Jan 2010 19:15:02 +1100
Subject: [PATCH] kvm: another PPC fixup (asm-offsets)

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/asm-offsets.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index be90ced..16dab65 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -437,11 +437,11 @@ int main(void)
 	DEFINE(VCPU_HIGHMEM_HANDLER, offsetof(struct kvm_vcpu, arch.highmem_handler));
 	DEFINE(VCPU_RMCALL, offsetof(struct kvm_vcpu, arch.rmcall));
 	DEFINE(VCPU_HFLAGS, offsetof(struct kvm_vcpu, arch.hflags));
-	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
 #else
 	DEFINE(VCPU_CR, offsetof(struct kvm_vcpu, arch.cr));
 	DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, arch.xer));
 #endif /* CONFIG_PPC64 */
+	DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
 #endif
 #ifdef CONFIG_44x
 	DEFINE(PGD_T_LOG2, PGD_T_LOG2);
-- 
1.6.5.7


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

linux-next: kvm tree build failure

[Stephen Rothwell]

Hi Avi,

Today's linux-next build (powerpc ppc44x_defconfig) failed like this:

arch/powerpc/kvm/booke_emulate.c: In function 'kvmppc_booke_emulate_mfspr':
arch/powerpc/kvm/booke_emulate.c:201: error: expected ')' before ';' token
arch/powerpc/kvm/booke_emulate.c:203: error: expected ')' before ';' token
arch/powerpc/kvm/booke_emulate.c:205: error: expected ')' before ';' token
arch/powerpc/kvm/booke_emulate.c:207: error: expected ')' before ';' token
arch/powerpc/kvm/booke_emulate.c:209: error: expected ')' before ';' token
arch/powerpc/kvm/booke_emulate.c:211: error: expected ')' before ';' token
arch/powerpc/kvm/44x_emulate.c: In function 'kvmppc_core_emulate_mfspr':
arch/powerpc/kvm/44x_emulate.c:171: error: lvalue required as left operand of assignment
arch/powerpc/kvm/44x_emulate.c:173: error: lvalue required as left operand of assignment
arch/powerpc/kvm/44x_emulate.c:175: error: lvalue required as left operand of assignment
arch/powerpc/kvm/44x_emulate.c:177: error: lvalue required as left operand of assignment

Caused by commit 7f31fad9aad3bb9df95793d72e037bb4d587ee83 ("KVM: PPC: Use
accessor functions for GPR access").  I couldn't easily revert that
commit, so I applied the following fixup patch instead.

More care is required ... please at least build test.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Jan 2010 18:50:23 +1100
Subject: [PATCH] kvm: fixup for botched PPC update

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kvm/44x_emulate.c   |    8 ++++----
 arch/powerpc/kvm/booke_emulate.c |   12 ++++++------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kvm/44x_emulate.c b/arch/powerpc/kvm/44x_emulate.c
index 0ff0d40..65ea083 100644
--- a/arch/powerpc/kvm/44x_emulate.c
+++ b/arch/powerpc/kvm/44x_emulate.c
@@ -168,13 +168,13 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
 
 	switch (sprn) {
 	case SPRN_PID:
-		kvmppc_get_gpr(vcpu, rt) = vcpu->arch.pid; break;
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.pid); break;
 	case SPRN_MMUCR:
-		kvmppc_get_gpr(vcpu, rt) = vcpu->arch.mmucr; break;
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.mmucr); break;
 	case SPRN_CCR0:
-		kvmppc_get_gpr(vcpu, rt) = vcpu->arch.ccr0; break;
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.ccr0); break;
 	case SPRN_CCR1:
-		kvmppc_get_gpr(vcpu, rt) = vcpu->arch.ccr1; break;
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.ccr1); break;
 	default:
 		emulated = kvmppc_booke_emulate_mfspr(vcpu, sprn, rt);
 	}
diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index ab1786c..cbc790e 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -198,17 +198,17 @@ int kvmppc_booke_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
 
 	switch (sprn) {
 	case SPRN_IVPR:
-		kvmppc_set_gpr(vcpu, rt, vcpu->arch.ivpr; break);
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.ivpr); break;
 	case SPRN_DEAR:
-		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dear; break);
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dear); break;
 	case SPRN_ESR:
-		kvmppc_set_gpr(vcpu, rt, vcpu->arch.esr; break);
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.esr); break;
 	case SPRN_DBCR0:
-		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dbcr0; break);
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dbcr0); break;
 	case SPRN_DBCR1:
-		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dbcr1; break);
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dbcr1); break;
 	case SPRN_DBSR:
-		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dbsr; break);
+		kvmppc_set_gpr(vcpu, rt, vcpu->arch.dbsr); break;
 
 	case SPRN_IVOR0:
 		kvmppc_set_gpr(vcpu, rt, vcpu->arch.ivor[BOOKE_IRQPRIO_CRITICAL]);
-- 
1.6.5.7


-- 
Cheers,
Stephen Rothwell                    Stephen@Rothwell.id.au

Re: linux-next: kvm tree build failure

[Avi Kivity]

On 08/13/2009 05:58 AM, Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> x86_64-linux-gcc: arch/x86/kvm/x86_emulate.c: No such file or directory
>
> Caused by commit 5383e9982ee230b06b3c385e675ae6fc7846c40f ("KVM: Rename
> x86_emulate.c to emulate.c").
>
> I have used the version of the kvm tree from next-20090812 for today.
>    

Fixed now, don't know how such brokenness slipped out.

-- 
error compiling committee.c: too many arguments to function

linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

x86_64-linux-gcc: arch/x86/kvm/x86_emulate.c: No such file or directory

Caused by commit 5383e9982ee230b06b3c385e675ae6fc7846c40f ("KVM: Rename
x86_emulate.c to emulate.c").

I have used the version of the kvm tree from next-20090812 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kvm tree build failure

[Avi Kivity]

On 06/23/2009 08:53 AM, Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next build (s390 allmodconfig) failed like this:
>
> In file included from include/trace/ftrace.h:261,
>                   from include/trace/define_trace.h:56,
>                   from include/trace/events/kvm.h:55,
>                   from arch/s390/kvm/../../../virt/kvm/kvm_main.c:63:
> include/trace/events/kvm.h: In function 'ftrace_raw_output_kvm_ack_irq':
> include/trace/events/kvm.h:31: error: 'KVM_IRQCHIP_PIC_MASTER' undeclared (first use in this function)
> include/trace/events/kvm.h:31: error: (Each undeclared identifier is reported only once
> include/trace/events/kvm.h:31: error: for each function it appears in.)
> include/trace/events/kvm.h:31: error: 'KVM_IRQCHIP_PIC_SLAVE' undeclared (first use in this function)
> include/trace/events/kvm.h:31: error: 'KVM_IRQCHIP_IOAPIC' undeclared (first use in this function)
>
> Caused by commit acb57be20f6b600848a99796d8f115ec079b8b08 ("KVM: convert
> custom marker based tracing to event traces").
>
>    

I applied a patch from Christian Borntraeger addressing this.

-- 
error compiling committee.c: too many arguments to function

linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next build (s390 allmodconfig) failed like this:

In file included from include/trace/ftrace.h:261,
                 from include/trace/define_trace.h:56,
                 from include/trace/events/kvm.h:55,
                 from arch/s390/kvm/../../../virt/kvm/kvm_main.c:63:
include/trace/events/kvm.h: In function 'ftrace_raw_output_kvm_ack_irq':
include/trace/events/kvm.h:31: error: 'KVM_IRQCHIP_PIC_MASTER' undeclared (first use in this function)
include/trace/events/kvm.h:31: error: (Each undeclared identifier is reported only once
include/trace/events/kvm.h:31: error: for each function it appears in.)
include/trace/events/kvm.h:31: error: 'KVM_IRQCHIP_PIC_SLAVE' undeclared (first use in this function)
include/trace/events/kvm.h:31: error: 'KVM_IRQCHIP_IOAPIC' undeclared (first use in this function)

Caused by commit acb57be20f6b600848a99796d8f115ec079b8b08 ("KVM: convert
custom marker based tracing to event traces").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kvm tree build failure

[Avi Kivity]

On 06/18/2009 07:25 AM, Jaswinder Singh Rajput wrote:
> [PATCH] KVM: use MSR_K7_HWCR for MSRC001_0015 Hardware Configuration Register (HWCR)
>
> MSR_K8_MSR is removed as it is duplicating MSRC001_0015 Hardware
> Configuration Register (HWCR), which is already defined as MSR_K7_HWCR
>
> Fix x86_64 allmodconfig :
>
> arch/x86/kvm/svm.c: In function 'svm_set_msr':
> arch/x86/kvm/svm.c:2152: error: 'MSR_K8_HWCR' undeclared (first use in this function)
>
>    

Applied, thanks.

-- 
error compiling committee.c: too many arguments to function

Re: linux-next: kvm tree build failure

[Jaswinder Singh Rajput]

Hello Stephen,

On Thu, 2009-06-18 at 11:11 +1000, Stephen Rothwell wrote:
> Hi Avi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> arch/x86/kvm/svm.c: In function 'svm_set_msr':
> arch/x86/kvm/svm.c:2152: error: 'MSR_K8_HWCR' undeclared (first use in this function)
> 
> Caused by commit 6878bf85dfc107cea4660f1167693c15754c1660 ("KVM:
> Implement MSRs used by Hyper-V").  MSR_K8_HWCR was removed by commit
> bf8b9a63c18a1a7777571650de0c9f4fd4368ca0 ("x86: msr-index.h remove
> duplicate MSR C001_0015 declaration") which is now in Linus' tree (it
> entered Linus' tree on Jun 10 via commit
> 7dc3ca39cb1e22eedbf1207ff9ac7bf682fc0f6d "Merge branch
> 'x86-cleanups-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip").
> 
> I have used the version of the kvm tree from 20090617.

Can you try this patch :

[PATCH] KVM: use MSR_K7_HWCR for MSRC001_0015 Hardware Configuration Register (HWCR)

MSR_K8_MSR is removed as it is duplicating MSRC001_0015 Hardware
Configuration Register (HWCR), which is already defined as MSR_K7_HWCR

Fix x86_64 allmodconfig :

arch/x86/kvm/svm.c: In function 'svm_set_msr':
arch/x86/kvm/svm.c:2152: error: 'MSR_K8_HWCR' undeclared (first use in this function)

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
 arch/x86/kvm/svm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index c283201..481010c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2149,7 +2149,7 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 data)
 		break;
 	case MSR_VM_CR:
 	case MSR_VM_IGNNE:
-	case MSR_K8_HWCR:
+	case MSR_K7_HWCR:
 		pr_unimpl(vcpu, "unimplemented wrmsr: 0x%x data 0x%llx\n", ecx, data);
 		break;
 	default:
-- 
1.6.0.6

linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

arch/x86/kvm/svm.c: In function 'svm_set_msr':
arch/x86/kvm/svm.c:2152: error: 'MSR_K8_HWCR' undeclared (first use in this function)

Caused by commit 6878bf85dfc107cea4660f1167693c15754c1660 ("KVM:
Implement MSRs used by Hyper-V").  MSR_K8_HWCR was removed by commit
bf8b9a63c18a1a7777571650de0c9f4fd4368ca0 ("x86: msr-index.h remove
duplicate MSR C001_0015 declaration") which is now in Linus' tree (it
entered Linus' tree on Jun 10 via commit
7dc3ca39cb1e22eedbf1207ff9ac7bf682fc0f6d "Merge branch
'x86-cleanups-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip").

I have used the version of the kvm tree from 20090617.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kvm tree build failure

[Avi Kivity]

Hollis Blanchard wrote:
> The "disarm" patch should fix the build. I'll resend that in a moment.
>
> I'd like to remind you though that the cause of this breakage was the
> debug patches you applied. It's also worth noting that the "fix" is to
> delete functionality, so any way you look at it it's not a good
> situation.
>   

No question.  We should have identified this earlier (my compile time 
tester) and dealt with it.  However, note that x86 is the main arch for 
kvm; we'll try hard to accommodate ppc, but you must adapt to x86 kvm 
changes, or lose functionality.

We'll try to make this tradeoff as rare as possible, of course.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: linux-next: kvm tree build failure

[Hollis Blanchard]

On Sun, 2009-01-04 at 13:08 +0200, Avi Kivity wrote:
> Stephen Rothwell wrote:
> > And again.  Can you please find some fix for this so that the kvm tree
> > can get some integration testing ...
> >   
> 
> Hollis, help!

The "disarm" patch should fix the build. I'll resend that in a moment.

I'd like to remind you though that the cause of this breakage was the
debug patches you applied. It's also worth noting that the "fix" is to
delete functionality, so any way you look at it it's not a good
situation.

Between that and other kernel breakage (like Rusty's
smp_call_function_many patch), it has taken a lot of effort just to try
to catch up.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: linux-next: kvm tree build failure

[Avi Kivity]

Stephen Rothwell wrote:
> And again.  Can you please find some fix for this so that the kvm tree
> can get some integration testing ...
>   

Hollis, help!

-- 
error compiling committee.c: too many arguments to function

Re: linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

On Mon, 29 Dec 2008 16:17:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 23 Dec 2008 00:25:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc44x_config) failed like this:
> > 
> > arch/powerpc/kvm/44x.c: In function 'kvmppc_core_load_guest_debugstate':
> > arch/powerpc/kvm/44x.c:58: warning: initialization from incompatible pointer type
> > arch/powerpc/kvm/44x.c:75: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:76: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:79: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:80: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:83: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:84: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:87: error: 'struct kvm_guest_debug' has no member named 'bp'
> > arch/powerpc/kvm/44x.c:88: error: 'struct kvm_guest_debug' has no member named 'bp'
> > 
> > Probably caused by commit 6968f31a2163f8fcf26ea8775c44d7e5be54d622 ("KVM:
> > Remove old kvm_guest_debug structs") so I have reverted the kvm tree for
> > today.
> 
> This error is still there, so I have dropped the kvm tree again today.

And again.  Can you please find some fix for this so that the kvm tree
can get some integration testing ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

On Tue, 23 Dec 2008 00:25:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc44x_config) failed like this:
> 
> arch/powerpc/kvm/44x.c: In function 'kvmppc_core_load_guest_debugstate':
> arch/powerpc/kvm/44x.c:58: warning: initialization from incompatible pointer type
> arch/powerpc/kvm/44x.c:75: error: 'struct kvm_guest_debug' has no member named 'bp'
> arch/powerpc/kvm/44x.c:76: error: 'struct kvm_guest_debug' has no member named 'bp'
> arch/powerpc/kvm/44x.c:79: error: 'struct kvm_guest_debug' has no member named 'bp'
> arch/powerpc/kvm/44x.c:80: error: 'struct kvm_guest_debug' has no member named 'bp'
> arch/powerpc/kvm/44x.c:83: error: 'struct kvm_guest_debug' has no member named 'bp'
> arch/powerpc/kvm/44x.c:84: error: 'struct kvm_guest_debug' has no member named 'bp'
> arch/powerpc/kvm/44x.c:87: error: 'struct kvm_guest_debug' has no member named 'bp'
> arch/powerpc/kvm/44x.c:88: error: 'struct kvm_guest_debug' has no member named 'bp'
> 
> Probably caused by commit 6968f31a2163f8fcf26ea8775c44d7e5be54d622 ("KVM:
> Remove old kvm_guest_debug structs") so I have reverted the kvm tree for
> today.

This error is still there, so I have dropped the kvm tree again today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next build (powerpc ppc44x_config) failed like this:

arch/powerpc/kvm/44x.c: In function 'kvmppc_core_load_guest_debugstate':
arch/powerpc/kvm/44x.c:58: warning: initialization from incompatible pointer type
arch/powerpc/kvm/44x.c:75: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:76: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:79: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:80: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:83: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:84: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:87: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:88: error: 'struct kvm_guest_debug' has no member named 'bp'

Probably caused by commit 6968f31a2163f8fcf26ea8775c44d7e5be54d622 ("KVM:
Remove old kvm_guest_debug structs") so I have reverted the kvm tree for
today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: kvm tree build failure

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next build (powerpc ppc44x_config) failed like this:

In file included from include/linux/kvm_host.h:27,
                 from arch/powerpc/include/asm/kvm_44x.h:23,
                 from arch/powerpc/kernel/asm-offsets.c:52:
arch/powerpc/include/asm/kvm_host.h:203: error: redefinition of 'struct kvm_guest_debug'

Caused by commit 887e823e3f9c402ff2fe1ea2dc25072ebe81b5b1 ("KVM: New
guest debug interface") which added struct kvm_guest_debug to
include/linux/kvm.h but didn't remove it from 
arch/powerpc/include/asm/kvm_host.h.  (ia64 and s390 probably have the
same problem.)

I have reverted the kvm tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kvm tree build failure

[Avi Kivity]

Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> In file included from arch/x86/kvm/../../../virt/kvm/vtd.c:28:
> include/linux/intel-iommu.h:31:27: error: dma_remapping.h: No such file or directory
> drivers/pci/intr_remapping.c:7:25: error: intel-iommu.h: No such file or directory
>
>   

I merged -linus and pushed, so this should be fixed now.

> I applied the following patch (which will need some consideration).
>   

I arrived at the same patch (with a few unrelated additions).  Please 
generate file movement patches with -M, much easier to review.

-- 
error compiling committee.c: too many arguments to function

linux-next: kvm tree build failure

[Stephen Rothwell]

Hi Avi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

In file included from arch/x86/kvm/../../../virt/kvm/vtd.c:28:
include/linux/intel-iommu.h:31:27: error: dma_remapping.h: No such file or directory
drivers/pci/intr_remapping.c:7:25: error: intel-iommu.h: No such file or directory

I applied the following patch (which will need some consideration).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

>From 45b0d91c36c7318bb71510ff8662a7e1b9c1d410 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 15 Oct 2008 16:43:17 +1100
Subject: [PATCH] kvm: fixes for movement of intel-iommu.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/pci/dma_remapping.h   |  157 -----------------------------------------
 drivers/pci/intr_remapping.c  |    2 +-
 drivers/pci/intr_remapping.h  |    2 +-
 include/linux/dma_remapping.h |  157 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 159 insertions(+), 159 deletions(-)
 delete mode 100644 drivers/pci/dma_remapping.h
 create mode 100644 include/linux/dma_remapping.h

diff --git a/drivers/pci/dma_remapping.h b/drivers/pci/dma_remapping.h
deleted file mode 100644
index bff5c65..0000000
--- a/drivers/pci/dma_remapping.h
+++ /dev/null
@@ -1,157 +0,0 @@
-#ifndef _DMA_REMAPPING_H
-#define _DMA_REMAPPING_H
-
-/*
- * We need a fixed PAGE_SIZE of 4K irrespective of
- * arch PAGE_SIZE for IOMMU page tables.
- */
-#define PAGE_SHIFT_4K		(12)
-#define PAGE_SIZE_4K		(1UL << PAGE_SHIFT_4K)
-#define PAGE_MASK_4K		(((u64)-1) << PAGE_SHIFT_4K)
-#define PAGE_ALIGN_4K(addr)	(((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
-
-#define IOVA_PFN(addr)		((addr) >> PAGE_SHIFT_4K)
-#define DMA_32BIT_PFN		IOVA_PFN(DMA_32BIT_MASK)
-#define DMA_64BIT_PFN		IOVA_PFN(DMA_64BIT_MASK)
-
-
-/*
- * 0: Present
- * 1-11: Reserved
- * 12-63: Context Ptr (12 - (haw-1))
- * 64-127: Reserved
- */
-struct root_entry {
-	u64	val;
-	u64	rsvd1;
-};
-#define ROOT_ENTRY_NR (PAGE_SIZE_4K/sizeof(struct root_entry))
-static inline bool root_present(struct root_entry *root)
-{
-	return (root->val & 1);
-}
-static inline void set_root_present(struct root_entry *root)
-{
-	root->val |= 1;
-}
-static inline void set_root_value(struct root_entry *root, unsigned long value)
-{
-	root->val |= value & PAGE_MASK_4K;
-}
-
-struct context_entry;
-static inline struct context_entry *
-get_context_addr_from_root(struct root_entry *root)
-{
-	return (struct context_entry *)
-		(root_present(root)?phys_to_virt(
-		root->val & PAGE_MASK_4K):
-		NULL);
-}
-
-/*
- * low 64 bits:
- * 0: present
- * 1: fault processing disable
- * 2-3: translation type
- * 12-63: address space root
- * high 64 bits:
- * 0-2: address width
- * 3-6: aval
- * 8-23: domain id
- */
-struct context_entry {
-	u64 lo;
-	u64 hi;
-};
-#define context_present(c) ((c).lo & 1)
-#define context_fault_disable(c) (((c).lo >> 1) & 1)
-#define context_translation_type(c) (((c).lo >> 2) & 3)
-#define context_address_root(c) ((c).lo & PAGE_MASK_4K)
-#define context_address_width(c) ((c).hi &  7)
-#define context_domain_id(c) (((c).hi >> 8) & ((1 << 16) - 1))
-
-#define context_set_present(c) do {(c).lo |= 1;} while (0)
-#define context_set_fault_enable(c) \
-	do {(c).lo &= (((u64)-1) << 2) | 1;} while (0)
-#define context_set_translation_type(c, val) \
-	do { \
-		(c).lo &= (((u64)-1) << 4) | 3; \
-		(c).lo |= ((val) & 3) << 2; \
-	} while (0)
-#define CONTEXT_TT_MULTI_LEVEL 0
-#define context_set_address_root(c, val) \
-	do {(c).lo |= (val) & PAGE_MASK_4K;} while (0)
-#define context_set_address_width(c, val) do {(c).hi |= (val) & 7;} while (0)
-#define context_set_domain_id(c, val) \
-	do {(c).hi |= ((val) & ((1 << 16) - 1)) << 8;} while (0)
-#define context_clear_entry(c) do {(c).lo = 0; (c).hi = 0;} while (0)
-
-/*
- * 0: readable
- * 1: writable
- * 2-6: reserved
- * 7: super page
- * 8-11: available
- * 12-63: Host physcial address
- */
-struct dma_pte {
-	u64 val;
-};
-#define dma_clear_pte(p)	do {(p).val = 0;} while (0)
-
-#define DMA_PTE_READ (1)
-#define DMA_PTE_WRITE (2)
-
-#define dma_set_pte_readable(p) do {(p).val |= DMA_PTE_READ;} while (0)
-#define dma_set_pte_writable(p) do {(p).val |= DMA_PTE_WRITE;} while (0)
-#define dma_set_pte_prot(p, prot) \
-		do {(p).val = ((p).val & ~3) | ((prot) & 3); } while (0)
-#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
-#define dma_set_pte_addr(p, addr) do {\
-		(p).val |= ((addr) & PAGE_MASK_4K); } while (0)
-#define dma_pte_present(p) (((p).val & 3) != 0)
-
-struct intel_iommu;
-
-struct dmar_domain {
-	int	id;			/* domain id */
-	struct intel_iommu *iommu;	/* back pointer to owning iommu */
-
-	struct list_head devices; 	/* all devices' list */
-	struct iova_domain iovad;	/* iova's that belong to this domain */
-
-	struct dma_pte	*pgd;		/* virtual address */
-	spinlock_t	mapping_lock;	/* page table lock */
-	int		gaw;		/* max guest address width */
-
-	/* adjusted guest address width, 0 is level 2 30-bit */
-	int		agaw;
-
-#define DOMAIN_FLAG_MULTIPLE_DEVICES 1
-	int		flags;
-};
-
-/* PCI domain-device relationship */
-struct device_domain_info {
-	struct list_head link;	/* link to domain siblings */
-	struct list_head global; /* link to global list */
-	u8 bus;			/* PCI bus numer */
-	u8 devfn;		/* PCI devfn number */
-	struct pci_dev *dev; /* it's NULL for PCIE-to-PCI bridge */
-	struct dmar_domain *domain; /* pointer to domain */
-};
-
-extern int init_dmars(void);
-extern void free_dmar_iommu(struct intel_iommu *iommu);
-
-extern int dmar_disabled;
-
-#ifndef CONFIG_DMAR_GFX_WA
-static inline void iommu_prepare_gfx_mapping(void)
-{
-	return;
-}
-#endif /* !CONFIG_DMAR_GFX_WA */
-
-#endif
diff --git a/drivers/pci/intr_remapping.c b/drivers/pci/intr_remapping.c
index bb642cc..738d4c8 100644
--- a/drivers/pci/intr_remapping.c
+++ b/drivers/pci/intr_remapping.c
@@ -4,7 +4,7 @@
 #include <linux/pci.h>
 #include <linux/irq.h>
 #include <asm/io_apic.h>
-#include "intel-iommu.h"
+#include <linux/intel-iommu.h>
 #include "intr_remapping.h"
 
 static struct ioapic_scope ir_ioapic[MAX_IO_APICS];
diff --git a/drivers/pci/intr_remapping.h b/drivers/pci/intr_remapping.h
index 05f2635..ca48f0d 100644
--- a/drivers/pci/intr_remapping.h
+++ b/drivers/pci/intr_remapping.h
@@ -1,4 +1,4 @@
-#include "intel-iommu.h"
+#include <linux/intel-iommu.h>
 
 struct ioapic_scope {
 	struct intel_iommu *iommu;
diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
new file mode 100644
index 0000000..bff5c65
--- /dev/null
+++ b/include/linux/dma_remapping.h
@@ -0,0 +1,157 @@
+#ifndef _DMA_REMAPPING_H
+#define _DMA_REMAPPING_H
+
+/*
+ * We need a fixed PAGE_SIZE of 4K irrespective of
+ * arch PAGE_SIZE for IOMMU page tables.
+ */
+#define PAGE_SHIFT_4K		(12)
+#define PAGE_SIZE_4K		(1UL << PAGE_SHIFT_4K)
+#define PAGE_MASK_4K		(((u64)-1) << PAGE_SHIFT_4K)
+#define PAGE_ALIGN_4K(addr)	(((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
+
+#define IOVA_PFN(addr)		((addr) >> PAGE_SHIFT_4K)
+#define DMA_32BIT_PFN		IOVA_PFN(DMA_32BIT_MASK)
+#define DMA_64BIT_PFN		IOVA_PFN(DMA_64BIT_MASK)
+
+
+/*
+ * 0: Present
+ * 1-11: Reserved
+ * 12-63: Context Ptr (12 - (haw-1))
+ * 64-127: Reserved
+ */
+struct root_entry {
+	u64	val;
+	u64	rsvd1;
+};
+#define ROOT_ENTRY_NR (PAGE_SIZE_4K/sizeof(struct root_entry))
+static inline bool root_present(struct root_entry *root)
+{
+	return (root->val & 1);
+}
+static inline void set_root_present(struct root_entry *root)
+{
+	root->val |= 1;
+}
+static inline void set_root_value(struct root_entry *root, unsigned long value)
+{
+	root->val |= value & PAGE_MASK_4K;
+}
+
+struct context_entry;
+static inline struct context_entry *
+get_context_addr_from_root(struct root_entry *root)
+{
+	return (struct context_entry *)
+		(root_present(root)?phys_to_virt(
+		root->val & PAGE_MASK_4K):
+		NULL);
+}
+
+/*
+ * low 64 bits:
+ * 0: present
+ * 1: fault processing disable
+ * 2-3: translation type
+ * 12-63: address space root
+ * high 64 bits:
+ * 0-2: address width
+ * 3-6: aval
+ * 8-23: domain id
+ */
+struct context_entry {
+	u64 lo;
+	u64 hi;
+};
+#define context_present(c) ((c).lo & 1)
+#define context_fault_disable(c) (((c).lo >> 1) & 1)
+#define context_translation_type(c) (((c).lo >> 2) & 3)
+#define context_address_root(c) ((c).lo & PAGE_MASK_4K)
+#define context_address_width(c) ((c).hi &  7)
+#define context_domain_id(c) (((c).hi >> 8) & ((1 << 16) - 1))
+
+#define context_set_present(c) do {(c).lo |= 1;} while (0)
+#define context_set_fault_enable(c) \
+	do {(c).lo &= (((u64)-1) << 2) | 1;} while (0)
+#define context_set_translation_type(c, val) \
+	do { \
+		(c).lo &= (((u64)-1) << 4) | 3; \
+		(c).lo |= ((val) & 3) << 2; \
+	} while (0)
+#define CONTEXT_TT_MULTI_LEVEL 0
+#define context_set_address_root(c, val) \
+	do {(c).lo |= (val) & PAGE_MASK_4K;} while (0)
+#define context_set_address_width(c, val) do {(c).hi |= (val) & 7;} while (0)
+#define context_set_domain_id(c, val) \
+	do {(c).hi |= ((val) & ((1 << 16) - 1)) << 8;} while (0)
+#define context_clear_entry(c) do {(c).lo = 0; (c).hi = 0;} while (0)
+
+/*
+ * 0: readable
+ * 1: writable
+ * 2-6: reserved
+ * 7: super page
+ * 8-11: available
+ * 12-63: Host physcial address
+ */
+struct dma_pte {
+	u64 val;
+};
+#define dma_clear_pte(p)	do {(p).val = 0;} while (0)
+
+#define DMA_PTE_READ (1)
+#define DMA_PTE_WRITE (2)
+
+#define dma_set_pte_readable(p) do {(p).val |= DMA_PTE_READ;} while (0)
+#define dma_set_pte_writable(p) do {(p).val |= DMA_PTE_WRITE;} while (0)
+#define dma_set_pte_prot(p, prot) \
+		do {(p).val = ((p).val & ~3) | ((prot) & 3); } while (0)
+#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
+#define dma_set_pte_addr(p, addr) do {\
+		(p).val |= ((addr) & PAGE_MASK_4K); } while (0)
+#define dma_pte_present(p) (((p).val & 3) != 0)
+
+struct intel_iommu;
+
+struct dmar_domain {
+	int	id;			/* domain id */
+	struct intel_iommu *iommu;	/* back pointer to owning iommu */
+
+	struct list_head devices; 	/* all devices' list */
+	struct iova_domain iovad;	/* iova's that belong to this domain */
+
+	struct dma_pte	*pgd;		/* virtual address */
+	spinlock_t	mapping_lock;	/* page table lock */
+	int		gaw;		/* max guest address width */
+
+	/* adjusted guest address width, 0 is level 2 30-bit */
+	int		agaw;
+
+#define DOMAIN_FLAG_MULTIPLE_DEVICES 1
+	int		flags;
+};
+
+/* PCI domain-device relationship */
+struct device_domain_info {
+	struct list_head link;	/* link to domain siblings */
+	struct list_head global; /* link to global list */
+	u8 bus;			/* PCI bus numer */
+	u8 devfn;		/* PCI devfn number */
+	struct pci_dev *dev; /* it's NULL for PCIE-to-PCI bridge */
+	struct dmar_domain *domain; /* pointer to domain */
+};
+
+extern int init_dmars(void);
+extern void free_dmar_iommu(struct intel_iommu *iommu);
+
+extern int dmar_disabled;
+
+#ifndef CONFIG_DMAR_GFX_WA
+static inline void iommu_prepare_gfx_mapping(void)
+{
+	return;
+}
+#endif /* !CONFIG_DMAR_GFX_WA */
+
+#endif
-- 
1.5.6.5

Re: linux-next: kvm tree build failure

[Jesse Barnes]

On Wednesday, September 24, 2008 5:39 am Avi Kivity wrote:
> Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> Hi Avi,
> >>
> >> Today's linux-next build (x86_64 allmodconfig) failed like this:
> >>
> >> In file included from arch/x86/kvm/../../../virt/kvm/kvm_main.c:44:
> >> include/linux/intel-iommu.h:31:27: error: dma_remapping.h: No such file
> >> or directory drivers/pci/intr_remapping.c:8:25: error: intel-iommu.h: No
> >> such file or directory
> >>
> >> I needed to add the following patch to complete the merge of the kvm
> >> tree due to commit 14f776b8e0aa6724069a35bf4e172d93be74ba90 ("VT-d:
> >> Changes to support KVM") interacting with other changes ("x64,
> >> x2apic/intr-remap: ...") in the x86 tree.
> >
> > hm, that looks like a non-trivial merge interaction. I'm wondering how
> > we should solve this. Avi, Jesse, any preferences?
>
> I'll look at the pci tree.  URL and branch, please?

git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git linux-next

Jesse

Re: linux-next: kvm tree build failure

[Avi Kivity]

Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>   
>> Hi Avi,
>>
>> Today's linux-next build (x86_64 allmodconfig) failed like this:
>>
>> In file included from arch/x86/kvm/../../../virt/kvm/kvm_main.c:44:
>> include/linux/intel-iommu.h:31:27: error: dma_remapping.h: No such file or directory
>> drivers/pci/intr_remapping.c:8:25: error: intel-iommu.h: No such file or directory
>>
>> I needed to add the following patch to complete the merge of the kvm tree
>> due to commit 14f776b8e0aa6724069a35bf4e172d93be74ba90 ("VT-d: Changes to
>> support KVM") interacting with other changes ("x64,
>> x2apic/intr-remap: ...") in the x86 tree.
>>     
>
> hm, that looks like a non-trivial merge interaction. I'm wondering how 
> we should solve this. Avi, Jesse, any preferences?
>   

I'll look at the pci tree.  URL and branch, please?

-- 
error compiling committee.c: too many arguments to function

Re: linux-next: kvm tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Avi,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> In file included from arch/x86/kvm/../../../virt/kvm/kvm_main.c:44:
> include/linux/intel-iommu.h:31:27: error: dma_remapping.h: No such file or directory
> drivers/pci/intr_remapping.c:8:25: error: intel-iommu.h: No such file or directory
> 
> I needed to add the following patch to complete the merge of the kvm tree
> due to commit 14f776b8e0aa6724069a35bf4e172d93be74ba90 ("VT-d: Changes to
> support KVM") interacting with other changes ("x64,
> x2apic/intr-remap: ...") in the x86 tree.

hm, that looks like a non-trivial merge interaction. I'm wondering how 
we should solve this. Avi, Jesse, any preferences?

	Ingo

linux-next: kvm tree build failure

[Stephen Rothwell]

Hi Avi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

In file included from arch/x86/kvm/../../../virt/kvm/kvm_main.c:44:
include/linux/intel-iommu.h:31:27: error: dma_remapping.h: No such file or directory
drivers/pci/intr_remapping.c:8:25: error: intel-iommu.h: No such file or directory

I needed to add the following patch to complete the merge of the kvm tree
due to commit 14f776b8e0aa6724069a35bf4e172d93be74ba90 ("VT-d: Changes to
support KVM") interacting with other changes ("x64,
x2apic/intr-remap: ...") in the x86 tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Sep 2008 16:50:35 +1000
Subject: [PATCH] kvm: fixup merge for intel_iommu.h move

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/pci/dma_remapping.h   |  157 -----------------------------------------
 drivers/pci/intr_remapping.c  |    2 +-
 drivers/pci/intr_remapping.h  |    2 +-
 include/linux/dma_remapping.h |  157 +++++++++++++++++++++++++++++++++++++++++
 include/linux/intel-iommu.h   |    4 +-
 5 files changed, 161 insertions(+), 161 deletions(-)
 delete mode 100644 drivers/pci/dma_remapping.h
 create mode 100644 include/linux/dma_remapping.h

diff --git a/drivers/pci/dma_remapping.h b/drivers/pci/dma_remapping.h
deleted file mode 100644
index bff5c65..0000000
--- a/drivers/pci/dma_remapping.h
+++ /dev/null
@@ -1,157 +0,0 @@
-#ifndef _DMA_REMAPPING_H
-#define _DMA_REMAPPING_H
-
-/*
- * We need a fixed PAGE_SIZE of 4K irrespective of
- * arch PAGE_SIZE for IOMMU page tables.
- */
-#define PAGE_SHIFT_4K		(12)
-#define PAGE_SIZE_4K		(1UL << PAGE_SHIFT_4K)
-#define PAGE_MASK_4K		(((u64)-1) << PAGE_SHIFT_4K)
-#define PAGE_ALIGN_4K(addr)	(((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
-
-#define IOVA_PFN(addr)		((addr) >> PAGE_SHIFT_4K)
-#define DMA_32BIT_PFN		IOVA_PFN(DMA_32BIT_MASK)
-#define DMA_64BIT_PFN		IOVA_PFN(DMA_64BIT_MASK)
-
-
-/*
- * 0: Present
- * 1-11: Reserved
- * 12-63: Context Ptr (12 - (haw-1))
- * 64-127: Reserved
- */
-struct root_entry {
-	u64	val;
-	u64	rsvd1;
-};
-#define ROOT_ENTRY_NR (PAGE_SIZE_4K/sizeof(struct root_entry))
-static inline bool root_present(struct root_entry *root)
-{
-	return (root->val & 1);
-}
-static inline void set_root_present(struct root_entry *root)
-{
-	root->val |= 1;
-}
-static inline void set_root_value(struct root_entry *root, unsigned long value)
-{
-	root->val |= value & PAGE_MASK_4K;
-}
-
-struct context_entry;
-static inline struct context_entry *
-get_context_addr_from_root(struct root_entry *root)
-{
-	return (struct context_entry *)
-		(root_present(root)?phys_to_virt(
-		root->val & PAGE_MASK_4K):
-		NULL);
-}
-
-/*
- * low 64 bits:
- * 0: present
- * 1: fault processing disable
- * 2-3: translation type
- * 12-63: address space root
- * high 64 bits:
- * 0-2: address width
- * 3-6: aval
- * 8-23: domain id
- */
-struct context_entry {
-	u64 lo;
-	u64 hi;
-};
-#define context_present(c) ((c).lo & 1)
-#define context_fault_disable(c) (((c).lo >> 1) & 1)
-#define context_translation_type(c) (((c).lo >> 2) & 3)
-#define context_address_root(c) ((c).lo & PAGE_MASK_4K)
-#define context_address_width(c) ((c).hi &  7)
-#define context_domain_id(c) (((c).hi >> 8) & ((1 << 16) - 1))
-
-#define context_set_present(c) do {(c).lo |= 1;} while (0)
-#define context_set_fault_enable(c) \
-	do {(c).lo &= (((u64)-1) << 2) | 1;} while (0)
-#define context_set_translation_type(c, val) \
-	do { \
-		(c).lo &= (((u64)-1) << 4) | 3; \
-		(c).lo |= ((val) & 3) << 2; \
-	} while (0)
-#define CONTEXT_TT_MULTI_LEVEL 0
-#define context_set_address_root(c, val) \
-	do {(c).lo |= (val) & PAGE_MASK_4K;} while (0)
-#define context_set_address_width(c, val) do {(c).hi |= (val) & 7;} while (0)
-#define context_set_domain_id(c, val) \
-	do {(c).hi |= ((val) & ((1 << 16) - 1)) << 8;} while (0)
-#define context_clear_entry(c) do {(c).lo = 0; (c).hi = 0;} while (0)
-
-/*
- * 0: readable
- * 1: writable
- * 2-6: reserved
- * 7: super page
- * 8-11: available
- * 12-63: Host physcial address
- */
-struct dma_pte {
-	u64 val;
-};
-#define dma_clear_pte(p)	do {(p).val = 0;} while (0)
-
-#define DMA_PTE_READ (1)
-#define DMA_PTE_WRITE (2)
-
-#define dma_set_pte_readable(p) do {(p).val |= DMA_PTE_READ;} while (0)
-#define dma_set_pte_writable(p) do {(p).val |= DMA_PTE_WRITE;} while (0)
-#define dma_set_pte_prot(p, prot) \
-		do {(p).val = ((p).val & ~3) | ((prot) & 3); } while (0)
-#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
-#define dma_set_pte_addr(p, addr) do {\
-		(p).val |= ((addr) & PAGE_MASK_4K); } while (0)
-#define dma_pte_present(p) (((p).val & 3) != 0)
-
-struct intel_iommu;
-
-struct dmar_domain {
-	int	id;			/* domain id */
-	struct intel_iommu *iommu;	/* back pointer to owning iommu */
-
-	struct list_head devices; 	/* all devices' list */
-	struct iova_domain iovad;	/* iova's that belong to this domain */
-
-	struct dma_pte	*pgd;		/* virtual address */
-	spinlock_t	mapping_lock;	/* page table lock */
-	int		gaw;		/* max guest address width */
-
-	/* adjusted guest address width, 0 is level 2 30-bit */
-	int		agaw;
-
-#define DOMAIN_FLAG_MULTIPLE_DEVICES 1
-	int		flags;
-};
-
-/* PCI domain-device relationship */
-struct device_domain_info {
-	struct list_head link;	/* link to domain siblings */
-	struct list_head global; /* link to global list */
-	u8 bus;			/* PCI bus numer */
-	u8 devfn;		/* PCI devfn number */
-	struct pci_dev *dev; /* it's NULL for PCIE-to-PCI bridge */
-	struct dmar_domain *domain; /* pointer to domain */
-};
-
-extern int init_dmars(void);
-extern void free_dmar_iommu(struct intel_iommu *iommu);
-
-extern int dmar_disabled;
-
-#ifndef CONFIG_DMAR_GFX_WA
-static inline void iommu_prepare_gfx_mapping(void)
-{
-	return;
-}
-#endif /* !CONFIG_DMAR_GFX_WA */
-
-#endif
diff --git a/drivers/pci/intr_remapping.c b/drivers/pci/intr_remapping.c
index 2dcf973..c9880a7 100644
--- a/drivers/pci/intr_remapping.c
+++ b/drivers/pci/intr_remapping.c
@@ -5,7 +5,7 @@
 #include <linux/pci.h>
 #include <linux/irq.h>
 #include <asm/io_apic.h>
-#include "intel-iommu.h"
+#include <linux/intel-iommu.h>
 #include "intr_remapping.h"
 
 static struct ioapic_scope ir_ioapic[MAX_IO_APICS];
diff --git a/drivers/pci/intr_remapping.h b/drivers/pci/intr_remapping.h
index 05f2635..ca48f0d 100644
--- a/drivers/pci/intr_remapping.h
+++ b/drivers/pci/intr_remapping.h
@@ -1,4 +1,4 @@
-#include "intel-iommu.h"
+#include <linux/intel-iommu.h>
 
 struct ioapic_scope {
 	struct intel_iommu *iommu;
diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
new file mode 100644
index 0000000..bff5c65
--- /dev/null
+++ b/include/linux/dma_remapping.h
@@ -0,0 +1,157 @@
+#ifndef _DMA_REMAPPING_H
+#define _DMA_REMAPPING_H
+
+/*
+ * We need a fixed PAGE_SIZE of 4K irrespective of
+ * arch PAGE_SIZE for IOMMU page tables.
+ */
+#define PAGE_SHIFT_4K		(12)
+#define PAGE_SIZE_4K		(1UL << PAGE_SHIFT_4K)
+#define PAGE_MASK_4K		(((u64)-1) << PAGE_SHIFT_4K)
+#define PAGE_ALIGN_4K(addr)	(((addr) + PAGE_SIZE_4K - 1) & PAGE_MASK_4K)
+
+#define IOVA_PFN(addr)		((addr) >> PAGE_SHIFT_4K)
+#define DMA_32BIT_PFN		IOVA_PFN(DMA_32BIT_MASK)
+#define DMA_64BIT_PFN		IOVA_PFN(DMA_64BIT_MASK)
+
+
+/*
+ * 0: Present
+ * 1-11: Reserved
+ * 12-63: Context Ptr (12 - (haw-1))
+ * 64-127: Reserved
+ */
+struct root_entry {
+	u64	val;
+	u64	rsvd1;
+};
+#define ROOT_ENTRY_NR (PAGE_SIZE_4K/sizeof(struct root_entry))
+static inline bool root_present(struct root_entry *root)
+{
+	return (root->val & 1);
+}
+static inline void set_root_present(struct root_entry *root)
+{
+	root->val |= 1;
+}
+static inline void set_root_value(struct root_entry *root, unsigned long value)
+{
+	root->val |= value & PAGE_MASK_4K;
+}
+
+struct context_entry;
+static inline struct context_entry *
+get_context_addr_from_root(struct root_entry *root)
+{
+	return (struct context_entry *)
+		(root_present(root)?phys_to_virt(
+		root->val & PAGE_MASK_4K):
+		NULL);
+}
+
+/*
+ * low 64 bits:
+ * 0: present
+ * 1: fault processing disable
+ * 2-3: translation type
+ * 12-63: address space root
+ * high 64 bits:
+ * 0-2: address width
+ * 3-6: aval
+ * 8-23: domain id
+ */
+struct context_entry {
+	u64 lo;
+	u64 hi;
+};
+#define context_present(c) ((c).lo & 1)
+#define context_fault_disable(c) (((c).lo >> 1) & 1)
+#define context_translation_type(c) (((c).lo >> 2) & 3)
+#define context_address_root(c) ((c).lo & PAGE_MASK_4K)
+#define context_address_width(c) ((c).hi &  7)
+#define context_domain_id(c) (((c).hi >> 8) & ((1 << 16) - 1))
+
+#define context_set_present(c) do {(c).lo |= 1;} while (0)
+#define context_set_fault_enable(c) \
+	do {(c).lo &= (((u64)-1) << 2) | 1;} while (0)
+#define context_set_translation_type(c, val) \
+	do { \
+		(c).lo &= (((u64)-1) << 4) | 3; \
+		(c).lo |= ((val) & 3) << 2; \
+	} while (0)
+#define CONTEXT_TT_MULTI_LEVEL 0
+#define context_set_address_root(c, val) \
+	do {(c).lo |= (val) & PAGE_MASK_4K;} while (0)
+#define context_set_address_width(c, val) do {(c).hi |= (val) & 7;} while (0)
+#define context_set_domain_id(c, val) \
+	do {(c).hi |= ((val) & ((1 << 16) - 1)) << 8;} while (0)
+#define context_clear_entry(c) do {(c).lo = 0; (c).hi = 0;} while (0)
+
+/*
+ * 0: readable
+ * 1: writable
+ * 2-6: reserved
+ * 7: super page
+ * 8-11: available
+ * 12-63: Host physcial address
+ */
+struct dma_pte {
+	u64 val;
+};
+#define dma_clear_pte(p)	do {(p).val = 0;} while (0)
+
+#define DMA_PTE_READ (1)
+#define DMA_PTE_WRITE (2)
+
+#define dma_set_pte_readable(p) do {(p).val |= DMA_PTE_READ;} while (0)
+#define dma_set_pte_writable(p) do {(p).val |= DMA_PTE_WRITE;} while (0)
+#define dma_set_pte_prot(p, prot) \
+		do {(p).val = ((p).val & ~3) | ((prot) & 3); } while (0)
+#define dma_pte_addr(p) ((p).val & PAGE_MASK_4K)
+#define dma_set_pte_addr(p, addr) do {\
+		(p).val |= ((addr) & PAGE_MASK_4K); } while (0)
+#define dma_pte_present(p) (((p).val & 3) != 0)
+
+struct intel_iommu;
+
+struct dmar_domain {
+	int	id;			/* domain id */
+	struct intel_iommu *iommu;	/* back pointer to owning iommu */
+
+	struct list_head devices; 	/* all devices' list */
+	struct iova_domain iovad;	/* iova's that belong to this domain */
+
+	struct dma_pte	*pgd;		/* virtual address */
+	spinlock_t	mapping_lock;	/* page table lock */
+	int		gaw;		/* max guest address width */
+
+	/* adjusted guest address width, 0 is level 2 30-bit */
+	int		agaw;
+
+#define DOMAIN_FLAG_MULTIPLE_DEVICES 1
+	int		flags;
+};
+
+/* PCI domain-device relationship */
+struct device_domain_info {
+	struct list_head link;	/* link to domain siblings */
+	struct list_head global; /* link to global list */
+	u8 bus;			/* PCI bus numer */
+	u8 devfn;		/* PCI devfn number */
+	struct pci_dev *dev; /* it's NULL for PCIE-to-PCI bridge */
+	struct dmar_domain *domain; /* pointer to domain */
+};
+
+extern int init_dmars(void);
+extern void free_dmar_iommu(struct intel_iommu *iommu);
+
+extern int dmar_disabled;
+
+#ifndef CONFIG_DMAR_GFX_WA
+static inline void iommu_prepare_gfx_mapping(void)
+{
+	return;
+}
+#endif /* !CONFIG_DMAR_GFX_WA */
+
+#endif
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 861ebdf..e7b196b 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -25,10 +25,10 @@
 #include <linux/types.h>
 #include <linux/msi.h>
 #include <linux/sysdev.h>
-#include "iova.h"
+#include <linux/iova.h>
 #include <linux/io.h>
 #include <asm/cacheflush.h>
-#include "dma_remapping.h"
+#include <linux/dma_remapping.h>
 
 /*
  * Intel IOMMU register specification per version 1.0 public spec.
-- 
1.5.6.5