linux-next: manual merge of the kvm tree

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next merge of the kvm tree got conflicts in about 23
files.  This has happened because only a subset of the kvm tree that is
merged into the linux-next tree has been merged into Linus' tree *and*
that subset was rebased before the merge happened.

I have dropped the kvm tree.

Is there some other branch that I should be including in linux-next
instead of the current one i.e. something that represents what you will
actually send to Linus that doesn't need to be rebased before that
happens?
-- 
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: manual merge of the kvm tree

[Avi Kivity]

On 06/12/2009 05:57 AM, Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next merge of the kvm tree got conflicts in about 23
> files.  This has happened because only a subset of the kvm tree that is
> merged into the linux-next tree has been merged into Linus' tree *and*
> that subset was rebased before the merge happened.
>
> I have dropped the kvm tree.
>    

I'll merge asap.

> Is there some other branch that I should be including in linux-next
> instead of the current one i.e. something that represents what you will
> actually send to Linus that doesn't need to be rebased before that
> happens?
>    

There's always kvm-updates/2.6.n+1, but that doesn't get updates until 
the merge window gets close.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kernel/reboot.c between commit
824877111cd7f2b4fd2fe6947c5c5cbbb3ac5bd8 ("x86, pci: move
arch/x86/pci/pci.h to arch/x86/include/asm/pci_x86.h") from the x86 tree
and commit 87238e8d2a086678c246825bc1a9dd148bba77cb ("x86: disable VMX on
all CPUs on reboot") from the kvm tree.

Just overlapping additions.  I fixed it up (see below) and can carry it
as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/kernel/reboot.c
index 5b1f23b,72e0e4e..0000000
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@@ -12,7 -12,7 +12,8 @@@
  #include <asm/proto.h>
  #include <asm/reboot_fixups.h>
  #include <asm/reboot.h>
 +#include <asm/pci_x86.h>
+ #include <asm/virtext.h>
  
  #ifdef CONFIG_X86_32
  # include <linux/dmi.h>

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
arch/powerpc/kvm/powerpc.c between commits
2a4aca1144394653269720ffbb5a325a77abd5fa ("powerpc/mm: Split low level
tlb invalidate for nohash processors") and
fad7b9b51e21a97e9e2662f1b51869ed2d209097 ("powerpc: Fix KVM build on
ppc440") from the powerpc tree (already merged into Linus' tree) and
commits 48e5562f7278782ae5d1772b7baa1ff76f035285 ("KVM: ppc: Refactor
powerpc.c to relocate 440-specific code") and
408e29020273079445b5a9161a80d6ce07ab6b1c ("KVM: ppc: Implement in-kernel
exit timing statistics") from the kvm tree.

I just used the kvm tree version of the file.
-- 
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: manual merge of the kvm tree

[Benjamin Herrenschmidt]

On Mon, 2008-12-22 at 19:02 -0600, Hollis Blanchard wrote:
> If you commit a new change to your tree that reverses only the
> arch/powerpc/kvm/powerpc.c part of Ben's patch, would that solve the
> merge problem? ppc44x_defconfig would still fail in the meantime though.
> If you fix the ppc44x_defconfig build, the merge problem is compounded.
> Either way I guess it is something that needs to be sorted out in
> powerpc.git, so you can pick which style of breakage you'd prefer?

Or add #include "../mm/mmu_decl.h" to powerpc to fix the local build
breakage now and fix the merge conflict later at merge time.

Cheers,
Ben.

Re: linux-next: manual merge of the kvm tree

[Hollis Blanchard]

On Tue, 2008-12-23 at 11:07 +1100, Paul Mackerras wrote:
> Hollis Blanchard writes:
> 
> > On Tue, 2008-12-23 at 09:29 +1100, Paul Mackerras wrote:
> > > Hollis Blanchard writes:
> > > 
> > > > > Patch is in Paulus -next already so we'll have to do a manual resolve.
> > > > 
> > > > Who has to do it? My code should "win".
> > > 
> > > Do you have your own tree or is all your stuff in the main kvm tree?
> > > 
> > > If there is a powerpc KVM tree, I could pull that and resolve the
> > > conflict, but I don't want to pull all the queued up KVM stuff.
> > 
> > It's just the main KVM tree.
> > 
> > > Worst case is Linus gets to resolve the conflict in the merge window.
> > > If that's just a matter of him taking your version of the file, it
> > > should be within his powers to manage. :)
> > 
> > Yeah, that's what I meant by "win"... whatever changes Ben made are to
> > now-dead code, so the code in kvm.git should be used. Does Linus need
> > special instruction to do this, or how does that work?
> 
> ppc44x_defconfig now fails to build in my tree because of _tlbil_all
> being undefined (it has CONFIG_KVM=y), so I need some sort of fix.
> What would happen if I made arch/powerpc/kvm/powerpc.c look like the
> version from the KVM tree?

It still wouldn't build, because it would require new functions (e.g.
kvmppc_core_vcpu_put) to be defined in other files.

I don't really know what to say, because from my point of view the
offending code was removed a long time ago, so it shouldn't be causing
these problems. In hindsight, what is the best solution in these
situations? Maybe if Ben had talked to me we could have applied the
exact same patch to powerpc.git and kvm.git at the same time, which
would keep both trees building and still be automatically merged later.

If you commit a new change to your tree that reverses only the
arch/powerpc/kvm/powerpc.c part of Ben's patch, would that solve the
merge problem? ppc44x_defconfig would still fail in the meantime though.
If you fix the ppc44x_defconfig build, the merge problem is compounded.
Either way I guess it is something that needs to be sorted out in
powerpc.git, so you can pick which style of breakage you'd prefer?

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: linux-next: manual merge of the kvm tree

[Paul Mackerras]

Hollis Blanchard writes:

> On Tue, 2008-12-23 at 09:29 +1100, Paul Mackerras wrote:
> > Hollis Blanchard writes:
> > 
> > > > Patch is in Paulus -next already so we'll have to do a manual resolve.
> > > 
> > > Who has to do it? My code should "win".
> > 
> > Do you have your own tree or is all your stuff in the main kvm tree?
> > 
> > If there is a powerpc KVM tree, I could pull that and resolve the
> > conflict, but I don't want to pull all the queued up KVM stuff.
> 
> It's just the main KVM tree.
> 
> > Worst case is Linus gets to resolve the conflict in the merge window.
> > If that's just a matter of him taking your version of the file, it
> > should be within his powers to manage. :)
> 
> Yeah, that's what I meant by "win"... whatever changes Ben made are to
> now-dead code, so the code in kvm.git should be used. Does Linus need
> special instruction to do this, or how does that work?

ppc44x_defconfig now fails to build in my tree because of _tlbil_all
being undefined (it has CONFIG_KVM=y), so I need some sort of fix.
What would happen if I made arch/powerpc/kvm/powerpc.c look like the
version from the KVM tree?

Paul.

Re: linux-next: manual merge of the kvm tree

[Hollis Blanchard]

On Tue, 2008-12-23 at 09:29 +1100, Paul Mackerras wrote:
> Hollis Blanchard writes:
> 
> > > Patch is in Paulus -next already so we'll have to do a manual resolve.
> > 
> > Who has to do it? My code should "win".
> 
> Do you have your own tree or is all your stuff in the main kvm tree?
> 
> If there is a powerpc KVM tree, I could pull that and resolve the
> conflict, but I don't want to pull all the queued up KVM stuff.

It's just the main KVM tree.

> Worst case is Linus gets to resolve the conflict in the merge window.
> If that's just a matter of him taking your version of the file, it
> should be within his powers to manage. :)

Yeah, that's what I meant by "win"... whatever changes Ben made are to
now-dead code, so the code in kvm.git should be used. Does Linus need
special instruction to do this, or how does that work?

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: linux-next: manual merge of the kvm tree

[Paul Mackerras]

Hollis Blanchard writes:

> > Patch is in Paulus -next already so we'll have to do a manual resolve.
> 
> Who has to do it? My code should "win".

Do you have your own tree or is all your stuff in the main kvm tree?

If there is a powerpc KVM tree, I could pull that and resolve the
conflict, but I don't want to pull all the queued up KVM stuff.

Worst case is Linus gets to resolve the conflict in the merge window.
If that's just a matter of him taking your version of the file, it
should be within his powers to manage. :)

Paul.

Re: linux-next: manual merge of the kvm tree

[Benjamin Herrenschmidt]

On Mon, 2008-12-22 at 16:03 -0600, Hollis Blanchard wrote:
> > Patch is in Paulus -next already so we'll have to do a manual
> resolve.
> 
> Who has to do it? My code should "win".

I don't understand. There is no "win" or "lose" here, just somebody who
has to fixup the merge conflict :-) In any case I don't see why any code
should "win" here.

Shouldn't be hard, we just need to sync with paulus who pulls what tree
in what tree to solve it. Maybe we can pull kvm into powerpc and solve
it there or something like that ?

The other solution is to rebase powerpc and change the patch but that's
evil, we always avoid rebasing, it hurts too many people.

> > Also, you'll need to include ../mm/mmu_decl.h to get to _tlbil_* ..
> > sorry about that.
> 
> I don't want _tlb anything; I was only using _tlbia(), and I'm not any
> more.

Ok. I got confused by another mail about undefined _tlbil_all() which
was probably another fix for that same stuff.

Cheers,
Ben.

Re: linux-next: manual merge of the kvm tree

[Hollis Blanchard]

On Tue, 2008-12-23 at 08:41 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2008-12-22 at 15:39 -0600, Hollis Blanchard wrote:
> > On Mon, 2008-12-22 at 16:13 +1100, Benjamin Herrenschmidt wrote:
> > > On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> > > > 
> > > > The former patch changes the _tlbia() to _tlbil_all() in
> > > > kvm_arch_vcpu_put().  The latter restructures this code.
> > > > 
> > > > I don't know enough to fix this up, so for today I have merely used the
> > > > kvm tree version.  Please come up with something better (if needed) and I
> > > > can use that as a merge resolution.
> > > 
> > > Hollis, can you have a look ? I suspect whatever is in the kvm tree is
> > > ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
> > > which don't exist anymore for nohash...
> > 
> > I've stopped calling _tlbia() in KVM, so I think the easiest solution
> > would be to drop the KVM part of your patch, Ben.
> 
> Patch is in Paulus -next already so we'll have to do a manual resolve.

Who has to do it? My code should "win".

> Also, you'll need to include ../mm/mmu_decl.h to get to _tlbil_* ..
> sorry about that.

I don't want _tlb anything; I was only using _tlbia(), and I'm not any
more.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: linux-next: manual merge of the kvm tree

[Benjamin Herrenschmidt]

On Mon, 2008-12-22 at 15:39 -0600, Hollis Blanchard wrote:
> On Mon, 2008-12-22 at 16:13 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> > > 
> > > The former patch changes the _tlbia() to _tlbil_all() in
> > > kvm_arch_vcpu_put().  The latter restructures this code.
> > > 
> > > I don't know enough to fix this up, so for today I have merely used the
> > > kvm tree version.  Please come up with something better (if needed) and I
> > > can use that as a merge resolution.
> > 
> > Hollis, can you have a look ? I suspect whatever is in the kvm tree is
> > ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
> > which don't exist anymore for nohash...
> 
> I've stopped calling _tlbia() in KVM, so I think the easiest solution
> would be to drop the KVM part of your patch, Ben.

Patch is in Paulus -next already so we'll have to do a manual resolve.
Also, you'll need to include ../mm/mmu_decl.h to get to _tlbil_* ..
sorry about that.

Cheers,
Ben.

Re: linux-next: manual merge of the kvm tree

[Hollis Blanchard]

On Mon, 2008-12-22 at 16:13 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> > 
> > The former patch changes the _tlbia() to _tlbil_all() in
> > kvm_arch_vcpu_put().  The latter restructures this code.
> > 
> > I don't know enough to fix this up, so for today I have merely used the
> > kvm tree version.  Please come up with something better (if needed) and I
> > can use that as a merge resolution.
> 
> Hollis, can you have a look ? I suspect whatever is in the kvm tree is
> ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
> which don't exist anymore for nohash...

I've stopped calling _tlbia() in KVM, so I think the easiest solution
would be to drop the KVM part of your patch, Ben.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: linux-next: manual merge of the kvm tree

[Benjamin Herrenschmidt]

On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> 
> The former patch changes the _tlbia() to _tlbil_all() in
> kvm_arch_vcpu_put().  The latter restructures this code.
> 
> I don't know enough to fix this up, so for today I have merely used the
> kvm tree version.  Please come up with something better (if needed) and I
> can use that as a merge resolution.

Hollis, can you have a look ? I suspect whatever is in the kvm tree is
ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
which don't exist anymore for nohash...

Cheers,
Ben.

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
arch/powerpc/kvm/powerpc.c between commit
2a4aca1144394653269720ffbb5a325a77abd5fa ("powerpc/mm: Split low level
tlb invalidate for nohash processors") from the powerpc tree and commit
48e5562f7278782ae5d1772b7baa1ff76f035285 ("KVM: ppc: Refactor powerpc.c
to relocate 440-specific code") from the kvm tree.

The former patch changes the _tlbia() to _tlbil_all() in
kvm_arch_vcpu_put().  The latter restructures this code.

I don't know enough to fix this up, so for today I have merely used the
kvm tree version.  Please come up with something better (if needed) and I
can use that as a merge resolution.
-- 
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: manual merge of the kvm tree

[Stephen Rothwell]

[Resent to get past vgers filters]

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kernel/reboot.c between commit
14d7ca5c575853664d8fe4f225a77b8df1b7de7d ("x86: attempt reboot via port
CF9 if we have standard PCI ports") from the x86 tree and commit
87238e8d2a086678c246825bc1a9dd148bba77cb ("x86: disable VMX on all CPUs
on reboot") from the kvm tree.

Just a context change.  I fixed it up (see below) and can carry the fix
as needed.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/kernel/reboot.c
index 0acde8f,a8b9304..0000000
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@@ -39,10 -40,13 +40,16 @@@ int reboot_force
  static int reboot_cpu = -1;
  #endif
  
+ /* This is set if we need to go through the 'emergency' path.
+  * When machine_emergency_restart() is called, we may be on
+  * an inconsistent state and won't be able to do a clean cleanup
+  */
+ static int reboot_emergency;
+ 
 -/* reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old]
 +/* This is set by the PCI code if either type 1 or type 2 PCI is detected */
 +bool port_cf9_safe = false;
 +
 +/* reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] | p[ci]
     warm   Don't set the cold reboot flag
     cold   Set the cold reboot flag
     bios   Reboot by jumping through the BIOS (only for X86_32)

Re: linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

On Wed, 29 Oct 2008 11:55:52 +0200 Avi Kivity <avi@redhat.com> wrote:
>
> I've done the same merge and pushed kvm.git, so this should disappear on 
> the next -next.

Thanks for that.

-- 
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: manual merge of the kvm tree

[Avi Kivity]

Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next merge of the kvm tree got a conflict in
> include/linux/kvm_host.h virt/kvm/kvm_main.c between commit
> 5550af4df179e52753d3a43a788a113ad8cd95cd ("KVM: Fix guest shared
> interrupt with in-kernel irqchip") from Linus' tree and commit
> 89c6b6a1b5059efa255ec254c8ee6667bdf6b2a0 ("KVM: IRQ ACK notifier should
> be used with in-kernel irqchip") from the kvm tree.
>
> Just a context change.  I fixed it up (taking the kvm tree's removal of
> the first argument of kvm_unregister_irq_ack_notifier).
>   

I've done the same merge and pushed kvm.git, so this should disappear on 
the next -next.

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

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
include/linux/kvm_host.h virt/kvm/kvm_main.c between commit
5550af4df179e52753d3a43a788a113ad8cd95cd ("KVM: Fix guest shared
interrupt with in-kernel irqchip") from Linus' tree and commit
89c6b6a1b5059efa255ec254c8ee6667bdf6b2a0 ("KVM: IRQ ACK notifier should
be used with in-kernel irqchip") from the kvm tree.

Just a context change.  I fixed it up (taking the kvm tree's removal of
the first argument of kvm_unregister_irq_ack_notifier).
-- 
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: manual merge of the kvm tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
include/linux/intel-iommu.h between commit
b6fcb33ad6c05f152a672f7c96c1fab006527b80 ("x64, x2apic/intr-remap:
routines managing Interrupt remapping table entries") from Linus' tree
and commit 14f776b8e0aa6724069a35bf4e172d93be74ba90 ("VT-d: Changes to
support KVM") from the kvm tree.

Overlapping additions.  I fixed it up (see below - which may not be
correct).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc include/linux/intel-iommu.h
index 2142c01,5fa9d26..0000000
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@@ -282,26 -332,32 +282,46 @@@ struct intel_iommu 
  	unsigned char name[7];    /* Device Name */
  	struct msi_msg saved_msg;
  	struct sys_device sysdev;
 +#endif
 +	struct q_inval  *qi;            /* Queued invalidation info */
 +#ifdef CONFIG_INTR_REMAP
 +	struct ir_table *ir_table;	/* Interrupt remapping info */
 +#endif
  };
  
 -#ifndef CONFIG_DMAR_GFX_WA
 -static inline void iommu_prepare_gfx_mapping(void)
 +static inline void __iommu_flush_cache(
 +	struct intel_iommu *iommu, void *addr, int size)
  {
 -	return;
 +	if (!ecap_coherent(iommu->ecap))
 +		clflush_cache_range(addr, size);
  }
 -#endif /* !CONFIG_DMAR_GFX_WA */
 +
 +extern struct dmar_drhd_unit * dmar_find_matched_drhd_unit(struct pci_dev *dev);
 +
 +extern int alloc_iommu(struct dmar_drhd_unit *drhd);
 +extern void free_iommu(struct intel_iommu *iommu);
 +extern int dmar_enable_qi(struct intel_iommu *iommu);
 +extern void qi_global_iec(struct intel_iommu *iommu);
 +
 +extern void qi_submit_sync(struct qi_desc *desc, struct intel_iommu *iommu);
+ 
+ void intel_iommu_domain_exit(struct dmar_domain *domain);
+ struct dmar_domain *intel_iommu_domain_alloc(struct pci_dev *pdev);
+ int intel_iommu_context_mapping(struct dmar_domain *domain,
+ 				struct pci_dev *pdev);
+ int intel_iommu_page_mapping(struct dmar_domain *domain, dma_addr_t iova,
+ 			     u64 hpa, size_t size, int prot);
+ void intel_iommu_detach_dev(struct dmar_domain *domain, u8 bus, u8 devfn);
+ struct dmar_domain *intel_iommu_find_domain(struct pci_dev *pdev);
+ u64 intel_iommu_iova_to_pfn(struct dmar_domain *domain, u64 iova);
+ 
+ #ifdef CONFIG_DMAR
+ int intel_iommu_found(void);
+ #else /* CONFIG_DMAR */
+ static inline int intel_iommu_found(void)
+ {
+ 	return 0;
+ }
+ #endif /* CONFIG_DMAR */
+ 
  #endif

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
include/linux/intel-iommu.h and drivers/pci/intel-iommu.h between several
commits ("x64, x2apic/intr-remap: ...") from the x86 tree and commit
14f776b8e0aa6724069a35bf4e172d93be74ba90 ("VT-d: Changes to support KVM")
from the kvm tree.

Just overlapping additions (the latter also moved the file). I fixed it
up (see below) and can carry the fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc include/linux/intel-iommu.h
index 2142c01,1490fc0..0000000
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@@ -282,26 -332,24 +282,38 @@@ struct intel_iommu 
  	unsigned char name[7];    /* Device Name */
  	struct msi_msg saved_msg;
  	struct sys_device sysdev;
 +#endif
 +	struct q_inval  *qi;            /* Queued invalidation info */
 +#ifdef CONFIG_INTR_REMAP
 +	struct ir_table *ir_table;	/* Interrupt remapping info */
 +#endif
  };
  
 -#ifndef CONFIG_DMAR_GFX_WA
 -static inline void iommu_prepare_gfx_mapping(void)
 +static inline void __iommu_flush_cache(
 +	struct intel_iommu *iommu, void *addr, int size)
  {
 -	return;
 +	if (!ecap_coherent(iommu->ecap))
 +		clflush_cache_range(addr, size);
  }
 -#endif /* !CONFIG_DMAR_GFX_WA */
 +
 +extern struct dmar_drhd_unit * dmar_find_matched_drhd_unit(struct pci_dev *dev);
 +
 +extern int alloc_iommu(struct dmar_drhd_unit *drhd);
 +extern void free_iommu(struct intel_iommu *iommu);
 +extern int dmar_enable_qi(struct intel_iommu *iommu);
 +extern void qi_global_iec(struct intel_iommu *iommu);
 +
 +extern void qi_submit_sync(struct qi_desc *desc, struct intel_iommu *iommu);
+ 
+ void intel_iommu_domain_exit(struct dmar_domain *domain);
+ struct dmar_domain *intel_iommu_domain_alloc(struct pci_dev *pdev);
+ int intel_iommu_context_mapping(struct dmar_domain *domain,
+ 				struct pci_dev *pdev);
+ int intel_iommu_page_mapping(struct dmar_domain *domain, dma_addr_t iova,
+ 			     u64 hpa, size_t size, int prot);
+ void intel_iommu_detach_dev(struct dmar_domain *domain, u8 bus, u8 devfn);
+ struct dmar_domain *intel_iommu_find_domain(struct pci_dev *pdev);
+ int intel_iommu_found(void);
+ u64 intel_iommu_iova_to_pfn(struct dmar_domain *domain, u64 iova);
+ 
  #endif

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a trivial conflict in
drivers/pci/dmar.c between commit
fe962e90cb17a8426e144dee970e77ed789d98ee ("x64, x2apic/intr-remap: Queued
invalidation infrastructure (part of VT-d)") from the x86 tree and commit
14f776b8e0aa6724069a35bf4e172d93be74ba90 ("VT-d: Changes to support KVM")
from the kvm tree.

The former just changed the context of the latter.  I fixed it up (see
below) and can carry the fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc drivers/pci/dmar.c
index 9527405,1df28ea..0000000
--- a/drivers/pci/dmar.c
+++ b/drivers/pci/dmar.c
@@@ -28,9 -26,8 +28,9 @@@
  
  #include <linux/pci.h>
  #include <linux/dmar.h>
 +#include <linux/timer.h>
- #include "iova.h"
- #include "intel-iommu.h"
+ #include <linux/iova.h>
+ #include <linux/intel-iommu.h>
  
  #undef PREFIX
  #define PREFIX "DMAR:"

Re: linux-next: manual merge of the kvm tree

[Ingo Molnar]

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

> Hi Avi,
> 
> Today's linux-next merge of the kvm tree got a trivial conflict in
> include/asm-x86/msr-index.h between commit
> 77ef50a522717fa040636ee1017179ceba12ff62 ("x86: consolidate header
> guards") from the x86 tree and commit
> 370ad813e210ac91935c6b5fa2e9cf80a0305fad ("x86: Move VMX MSRs to
> msr-index.h") from the kvm tree.

these changes will likely be driven from the KVM tree, so it should not 
go beyond this initial conflict. (commit 77ef50a is already interwoven)

> I fixed it up (see below) and can carry the fixup.

thanks!

	Ingo

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a trivial conflict in
include/asm-x86/msr-index.h between commit
77ef50a522717fa040636ee1017179ceba12ff62 ("x86: consolidate header
guards") from the x86 tree and commit
370ad813e210ac91935c6b5fa2e9cf80a0305fad ("x86: Move VMX MSRs to
msr-index.h") from the kvm tree.

I fixed it up (see below) and can carry the fixup.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc include/asm-x86/msr-index.h
index 3052f05,715f951..0000000
--- a/include/asm-x86/msr-index.h
+++ b/include/asm-x86/msr-index.h
@@@ -310,4 -314,19 +314,19 @@@
  /* Geode defined MSRs */
  #define MSR_GEODE_BUSCONT_CONF0		0x00001900
  
+ /* Intel VT MSRs */
+ #define MSR_IA32_VMX_BASIC              0x00000480
+ #define MSR_IA32_VMX_PINBASED_CTLS      0x00000481
+ #define MSR_IA32_VMX_PROCBASED_CTLS     0x00000482
+ #define MSR_IA32_VMX_EXIT_CTLS          0x00000483
+ #define MSR_IA32_VMX_ENTRY_CTLS         0x00000484
+ #define MSR_IA32_VMX_MISC               0x00000485
+ #define MSR_IA32_VMX_CR0_FIXED0         0x00000486
+ #define MSR_IA32_VMX_CR0_FIXED1         0x00000487
+ #define MSR_IA32_VMX_CR4_FIXED0         0x00000488
+ #define MSR_IA32_VMX_CR4_FIXED1         0x00000489
+ #define MSR_IA32_VMX_VMCS_ENUM          0x0000048a
+ #define MSR_IA32_VMX_PROCBASED_CTLS2    0x0000048b
+ #define MSR_IA32_VMX_EPT_VPID_CAP       0x0000048c
+ 
 -#endif /* __ASM_MSR_INDEX_H */
 +#endif /* ASM_X86__MSR_INDEX_H */

Re: linux-next: manual merge of the kvm tree

[Stephen Rothwell]

Hi all,

On Sat, 13 Sep 2008 05:50:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Just contextual. I fixed it up (see below) and can carry the fix.

Oops, I needed to add the below as well.

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

diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 6a961e3..944c435 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -207,7 +207,7 @@ static int __pit_timer_fn(struct kvm_kpit_state *ps)
 	hrtimer_add_expires_ns(&pt->timer, pt->period);
 	pt->scheduled = ktime_to_ns(hrtimer_get_expires(&pt->timer));
 	if (pt->period)
-		ps->channels[0].count_load_time = pt->timer.expires;
+		ps->channels[0].count_load_time = hrtimer_get_expires(&pt->timer);
 
 	return (pt->period == 0 ? 0 : 1);
 }

Re: linux-next: manual merge of the kvm tree

[Arjan van de Ven]

Stephen Rothwell wrote:
> Hi Avi,
> 
> Today's linux-next merge of the kvm tree got a conflict in
> arch/x86/kvm/i8254.c between commit
> beb20d52d03a51218827fb4a36a4b583debb03f9 ("hrtimer: convert kvm to the
> new hrtimer apis") from the timers tree and commit
> 3dceed526eaab43af90bcec3476c4f534f98dd41 ("KVM: PIT: fix injection logic
> and count") from the kvm tree.
> 
> Just contextual. I fixed it up (see below) and can carry the fix.


Stephen: one option is to push the "introduce the new apis" patch to Linus
now (it just adds apis, nothing more); with that done it's possible to
push all the conversions via the separate maintainer git trees...

(not that it's all THAT painful right now, but still)

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
arch/x86/kvm/i8254.c between commit
beb20d52d03a51218827fb4a36a4b583debb03f9 ("hrtimer: convert kvm to the
new hrtimer apis") from the timers tree and commit
3dceed526eaab43af90bcec3476c4f534f98dd41 ("KVM: PIT: fix injection logic
and count") from the kvm tree.

Just contextual. I fixed it up (see below) and can carry the fix.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/kvm/i8254.c
index 1bf8f57,634132a..0000000
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@@ -200,13 -200,14 +200,14 @@@ static int __pit_timer_fn(struct kvm_kp
  
  	if (!atomic_inc_and_test(&pt->pending))
  		set_bit(KVM_REQ_PENDING_TIMER, &vcpu0->requests);
- 	if (vcpu0 && waitqueue_active(&vcpu0->wq)) {
- 		vcpu0->arch.mp_state = KVM_MP_STATE_RUNNABLE;
+ 
+ 	if (vcpu0 && waitqueue_active(&vcpu0->wq))
  		wake_up_interruptible(&vcpu0->wq);
- 	}
  
 -	pt->timer.expires = ktime_add_ns(pt->timer.expires, pt->period);
 -	pt->scheduled = ktime_to_ns(pt->timer.expires);
 +	hrtimer_add_expires_ns(&pt->timer, pt->period);
 +	pt->scheduled = ktime_to_ns(hrtimer_get_expires(&pt->timer));
+ 	if (pt->period)
+ 		ps->channels[0].count_load_time = pt->timer.expires;
  
  	return (pt->period == 0 ? 0 : 1);
  }

Re: linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

On Tue, 26 Aug 2008 10:39:49 +0300 Avi Kivity <avi@qumranet.com> wrote:
>
> Fixed it up; thanks.

Thanks.

-- 
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: manual merge of the kvm tree

[Avi Kivity]

Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next merge of the kvm tree got a conflict in
> include/linux/kvm.h between commit
> 1327138e294ffda120a50c8f31d792addb196c79 ("KVM: fix userspace ABI
> breakage") from Linus' tree (a version of which which also exists in the
> kvm tree) and commit b8486fbae0046883437c91e9b475f1878888fe72 ("KVM:
> kvmtrace: replace get_cycles with ktime_get v3") from the kvm tree.
>
> I used the version from the kvm tree.
>   

Fixed it up; thanks.

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

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
include/linux/kvm.h between commit
1327138e294ffda120a50c8f31d792addb196c79 ("KVM: fix userspace ABI
breakage") from Linus' tree (a version of which which also exists in the
kvm tree) and commit b8486fbae0046883437c91e9b475f1878888fe72 ("KVM:
kvmtrace: replace get_cycles with ktime_get v3") from the kvm tree.

I used the version from 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: 197 bytes --]

linux-next: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the kvm tree got a trivial conflict in
include/asm-x86/kvm.h between commit
77ef50a522717fa040636ee1017179ceba12ff62 ("x86: consolidate header
guards") from the x86 tree and commit
caa03c6696f78684a8396c63518fc84ed5922d44 ("KVM: Move KVM TRACE
DEFINITIONS to common header") from the kvm tree.

I fixed it up.
-- 
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: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next merge of the kvm tree got a conflict in
include/linux/kvm.h between commit
ed8486243379ef3e6c61363df915882945c0eaec ("KVM: Advertise synchronized
mmu support to userspace") from Linus' tree (which also extsts in the kvm
tree) and commit a6a19661fc371c188b9cdeceba402b93de2b957f ("KVM: pci
device assignment") from the kvm tree.

Just a contextual overlap.  I fixed it up.
-- 
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: manual merge of the kvm tree

[Stephen Rothwell]

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

Hi Avi,

Today's linux-next merge of the kvm tree got conflicts in
arch/powerpc/kvm/Makefile arch/x86/kvm/mmu.c, arch/x86/kvm/svm.c,
arch/x86/kvm/vmx.c, arch/x86/kvm/x86.c, arch/x86/kvm/x86_emulate.c,
include/asm-x86/kvm.h, include/asm-x86/kvm_host.h, include/linux/kvm.h
and virt/kvm/kvm_trace.c against Linus' tree.

It looks like a subset of the kvm tree in linux-next has been submitted
to Linus.  I have dropped the kvm tree form linux-next until it is fixed
up.

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

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