On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
> [PATCH] x86-64: disable the GART before allocate aperture
>
> For K8 system: 4G RAM with memory hole remapping enabled, or more
> than 4G RAM installed. when mem is allocated for GART, it will do
> the memset for clear. and for kexec c
On Fri, Jun 22, 2007 at 03:32:53PM -0600, Eric W. Biederman wrote:
> Alan Cox <[EMAIL PROTECTED]> writes:
>
> > You've got mapped live gart pages from the previous kernel. Even
> > if you disable the gart before a memset you may well have the
> > video card using gart translations and possibly liv
On Fri, Jun 22, 2007 at 05:27:50PM -0700, Yinghai Lu wrote:
> Andi Kleen wrote:
> >On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
> >The kdump kernel should be normally all <4GB anyways. You won't
> >need any IOMMU for its IO unless you O_DIRECT/sendfile out of /proc/kcore.
> >Just don't do that
On Fri, Jun 22, 2007 at 07:34:59PM -0700, Yinghai Lu wrote:
> [PATCH] x86-64: disable the GART in shutdown
>
> For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
> installed. when mem is allocated for GART, it will do the memset for clear.
> and for kexec case, the first
On Sat, Jun 23, 2007 at 12:59:17PM +0200, Andi Kleen wrote:
>
> > I'm going to need exactly the same hook fro Calgary, as well Intel for
> > VT-d, and AMD for their upcoming IOMMU, etc. How about we do
> >
> > struct iommu_ops {
> > struct dma_ops {
> > ...
> > }
> > void (*shutdown)(vo
On Sun, Jun 24, 2007 at 05:22:30PM -0700, Yinghai Lu wrote:
> On 6/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >> void __init gart_iommu_init(void)
> >> {
> >> struct agp_kern_info info;
> >> diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
> >> index 9f80aad..
On Mon, Jun 25, 2007 at 12:34:03PM -0700, Yinghai Lu wrote:
> [PATCH] x86-64: disable the GART in shutdown
>
> For K8 system: 4G RAM with memory hole remapping enabled, or more than 4G RAM
> installed. when using kexec to load second kernel. In the second kernel,
> when mem is allocated for GART
On Mon, Jun 25, 2007 at 12:52:48PM -0700, Yinghai Lu wrote:
> >I suggest include/asm-x86_64/iommu.h for this. proto.h doesn't have
> >anything to do with it.
>
> move iommu releated to iommu.h and add iommu_ops struct?
That's how I would do it, to complement dma_mapping.h.
Cheers,
Muli
-
To uns
On Tue, Jun 26, 2007 at 09:12:45AM +0200, Andi Kleen wrote:
> There are some potential performance benefits too:
> - When you have a device that cannot address the complete address range
> an IOMMU can remap its memory instead of bounce buffering. Remapping
> is likely cheaper than copying.
But
On Mon, Jun 25, 2007 at 02:49:26PM -0700, Yinghai Lu wrote:
> [PATCH 2/2] x86_84: move iommu declaration from proto to iommu.h
Sorry for the hassle, but this patch should come first and then your
current first patch becomes much simpler and does not touch proto.h
needlessly.
Also, I still think
for having other users of sysdata, such as
the PCI domains work.
The Calgary bits are tested, the NUMA bits just look ok.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/i386/pci/acpi.c | 32 +
On Wed, Jul 11, 2007 at 09:41:59AM -0700, Yinghai Lu wrote:
> Muli Ben-Yehuda wrote:
> >Andi, please consider applying for 2.6.23. Applies on top of the
> >Calgary update I just sent out ("Calgary: more updates for 2.6.23").
> >
> >This patch introduces stru
On Thu, Jul 12, 2007 at 09:17:31AM +0800, Arjan van de Ven wrote:
> On Wed, 2007-07-11 at 16:45 +0300, Muli Ben-Yehuda wrote:
> > Andi, please consider applying for 2.6.23. Applies on top of the
> > Calgary update I just sent out ("Calgary: more updates for 2.6.23").
>
On Thu, Jul 12, 2007 at 05:13:05PM +0800, Arjan van de Ven wrote:
> > > I very much start to dislike the untyped "sysdata"... I much
> > > rather have separate fields for the different uses (like a IOMMU
> > > field) that aren't going to share ever. Possibly even typed, but
> > > for IOMMU that ma
On Fri, Jun 01, 2007 at 10:26:01PM +0200, Andi Kleen wrote:
> Normally swiotlb doesn't even try to bounce when dma mask is <=
> end_pfn so something must be very wrong in your kernel. It
> definitely isn't a mainline kernel. If this happens in Xen then Xen
> just needs fixing -- it should not try
On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote:
> > I'll keep rebasing sglist and the other branches I pull into for-akpm,
> > so you can just re-enable the for-akpm pull when the a) is true.
>
> Andi's tree is very out of date and is about to be damaged (to what
> extent I don't y
On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote:
> On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> > The Xen and Calgary bits are mutually exclusive, so hopefully (a)
> > will not be held up on account of the Xen merge (or for any other
> > reason... CalIOC2 machine
On Tue, Jul 17, 2007 at 10:51:23AM +0200, Jens Axboe wrote:
> On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote:
> >
> > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote:
> >
> > > > The Xen a
On Mon, Jul 16, 2007 at 07:18:12PM -0700, [EMAIL PROTECTED] wrote:
> diff --git a/include/asm-ia64/dma-mapping.h b/include/asm-ia64/dma-mapping.h
> index 6299b51..22af26b 100644
> --- a/include/asm-ia64/dma-mapping.h
> +++ b/include/asm-ia64/dma-mapping.h
> @@ -73,4 +73,26 @@ dma_cache_sync (struc
OTECTED]>
> ---
> arch/x86_64/kernel/pci-calgary.c | 25 --
> arch/x86_64/kernel/pci-gart.c| 63 -
> arch/x86_64/kernel/pci-nommu.c |5 ++-
Calgary and nommu bits are:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
FYI
On Tue, Jul 17, 2007 at 01:05:03PM +0200, Jens Axboe wrote:
> > FYI, here's the Calgary diff on top of the outstanding Calgary
> > changes.
>
> When are these bits being merged into mainline? I'll hang on to this
> version for helping me rebase the arch bits of chained sglists once
> that happens
On Thu, May 10, 2007 at 04:47:32AM -0700, David Miller wrote:
> From: Mahesh <[EMAIL PROTECTED]>
> Date: Thu, 10 May 2007 17:11:17 +0530
>
> > Hi, > You haven't given an example of where this might actually
> > happen. > > The driver is where the DMA mappings almost always
> > occur because > tha
On Mon, Jun 04, 2007 at 03:06:54PM -0400, Jeff Garzik wrote:
> On Mon, Jun 04, 2007 at 11:33:44AM -0700, Andrew Morton wrote:
> > On Tue, 22 May 2007 04:05:54 -0400
> > [EMAIL PROTECTED] wrote:
> >
> > > From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
> >
On Mon, Jun 04, 2007 at 05:05:51PM -0400, Jeff Garzik wrote:
>
> This patch introduces struct pci_sysdata to x86 and x86-64, and
> converts the existing two users (NUMA, Calgary) to use it.
>
> This eliminates the conflict between NUMA and Calgary using the same
> pointer for different uses, and
On Tue, Jun 05, 2007 at 01:29:05PM +0300, Muli Ben-Yehuda wrote:
> On Mon, Jun 04, 2007 at 05:05:51PM -0400, Jeff Garzik wrote:
> >
> > This patch introduces struct pci_sysdata to x86 and x86-64, and
> > converts the existing two users (NUMA, Calgary) to use it.
> &g
On Wed, Jun 06, 2007 at 05:21:51PM -0400, Jeff Garzik wrote:
> > Ok, patch fixed, works for me with Calgary. Andi, it looks like you
> > added the acpi.c NUMA bits originally, perhaps you could test and/or
> > ack them?
>
> Just so there is no misunderstanding, I added the allocation bits.
>
> No
On Tue, Jun 26, 2007 at 05:56:49PM +0200, Andi Kleen wrote:
> > > - The IOMMU can merge sg lists into a single virtual block. This could
> > > potentially speed up SG IO when the device is slow walking SG
> > > lists. [I long ago benchmarked 5% on some block benchmark with
> > > an old MPT Fusion
On Tue, Jun 26, 2007 at 08:03:59AM -0700, Arjan van de Ven wrote:
> Muli Ben-Yehuda wrote:
> >How much? we have numbers (to be presented at OLS later this week)
> >that show that on bare-metal an IOMMU can cost as much as 15%-30% more
> >CPU utilization for an IO intensive w
On Tue, Jun 26, 2007 at 08:48:04AM -0700, Keshavamurthy, Anil S wrote:
> Our initial benchmark results showed we had around 3% extra CPU
> utilization overhead when compared to native(i.e without IOMMU).
> Again, our benchmark was on small SMP machine and we used iperf and
> a 1G ethernet cards.
On Wed, Jun 27, 2007 at 10:41:21AM -0700, Yinghai Lu wrote:
> [PATCH] x86_64: change _map_single to static in pci_gart.c etc
>
> there function is called via dma_ops->.., so change it to static
Thanks, mostly looks good - will verify and push via the next set of
Calgary updates.
Cheers,
Muli
-
T
On Wed, Jun 27, 2007 at 05:26:50PM +0200, Andi Kleen wrote:
> See the recent "quiet down swiotlb warnings" thread which uncovered
> quite some corpses in Xen's current IO setup.
>
> Xen apparently bounces for multi page IOs which get merged from block
> lists because the block layer doesn't know
On Wed, Jun 27, 2007 at 04:21:10PM -0400, Muli Ben-Yehuda wrote:
> On Wed, Jun 27, 2007 at 10:41:21AM -0700, Yinghai Lu wrote:
> > [PATCH] x86_64: change _map_single to static in pci_gart.c etc
> >
> > there function is called via dma_ops->.., so change it to static
>
On Wed, Jun 27, 2007 at 01:29:46PM -0700, Yinghai Lu wrote:
> On 6/27/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >On Wednesday 27 June 2007 22:25:11 Yinghai Lu wrote:
> >> On 6/27/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> > On Wednesday 27 June 2007 19:41:21 Yinghai Lu wrote:
> >> > > [PATCH]
On Fri, Jun 29, 2007 at 08:28:58AM -0700, Keshavamurthy, Anil S wrote:
> Here is the revised patch of the above.
> Andrew, please add this fix to
> +intel-iommu-dmar-detection-and-parsing-logic.patch
>
>
> Check for dmar_tbl pointer as this can be
On Fri, Jun 29, 2007 at 12:23:53PM -0700, Keshavamurthy, Anil S wrote:
> Since this is IOMMU is built into the kernel and it is good idea to
> report that the device is not present.
Yes - as a debug message.
> The above is printed only once and is consistent with other IOMMU
> implementation. At
a
different structure) so ...
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
On Fri, Apr 06, 2007 at 10:55:57AM +0200, Guillaume Thouvenin wrote:
> Cleanup unneeded macros used for register space address calculation.
> Now we are using the EBDA to find the space address.
>
> Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
Applied, thank you. I'll push it out with
On Tue, Apr 10, 2007 at 03:57:28PM +0800, Shaohua Li wrote:
> On Tue, 2007-04-10 at 09:49 +0200, Andi Kleen wrote:
> > On Monday 09 April 2007 23:55:52 Ashok Raj wrote:
> >
> > > Please help review and provide feedback.
> >
> > High level question: how did you solve the "user X server needs IOMMU
On Thu, Mar 29, 2007 at 08:58:00AM +0100, Jan Beulich wrote:
> Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
> subsequent pfn-s are also invalid is wrong. Thus replace this by
> explicitly checking against the E820 map.
>
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
> Ac
On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
> Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
This patch feels like a huge hack. See below.
> This patch removes sysdata from pci_dev struct and creates a new
> field called sys_data which is exclusively used by IOM
On Mon, Sep 10, 2007 at 08:43:59AM -0700, Keshavamurthy, Anil S wrote:
> On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
> > On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
> >
> > > Subject: [RFC][Intel-IOMMU] Fix for IOMMU early c
On Tue, Sep 11, 2007 at 10:42:31AM -0700, Keshavamurthy, Anil S wrote:
> Yes, I agree that pci_dev->sysdata can;t be removed. Even we (IOMMU)
> were dependent on this field but somehow this field is being
> overwritten to point to pci_bus's->sysdata and hence IOMMU was
> failing. Earlier it was ov
On Tue, Sep 18, 2007 at 06:29:19AM +0200, Borislav Petkov wrote:
> These patches remove redundant DMA_..BIT_MASK definitions across two drivers.
> In this version of the patches, the computation of the bitmasks is done by
> the compiler.
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> Cc:
off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Acked-by: Murillo Fernandes Bernardes <[EMAIL PROTECTED]>
---
Andi, This is Calgary 2.6.24 material - please apply.
pci-calgary.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff -r ca20f7bdb869 -r c9308d0538d
Now that we check for translation enabled/disabled based on the
presence of the IOMMU translation table, we can get rid of
translate_phb.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
pci-calgary.c | 31 +++
1 files changed, 15 insertions(+), 16 del
On Wed, Aug 22, 2007 at 11:56:22PM +0200, Thomas Gleixner wrote:
> We are pleased to announce v2 of the unified arch/x86 project we are
> working on.
After having recently inadvertently broken i386 while making x86-64
changes, thumbs up from me!
Cheers,
Muli
-
To unsubscribe from this list: send
On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote:
> Hi, Muli
>
> saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
> could get rid of saved_max_pfn at all. But If this can't work, how
> about exporting a calgary tce table size to user space, so that
> kexec-tools can s
On Wed, Mar 05, 2014 at 10:50:41PM -0800, H. Peter Anvin wrote:
> OK, second question... is it time to axe Calgary?
I don't know of anyone still using it, but it's not
impossible. Calgary and CalIOC2 machines would now be ~5-8 years old.
Cheers,
Muli
--
To unsubscribe from this list: send the li
On Thu, Mar 06, 2014 at 07:46:44AM -0700, Jon Mason wrote:
> > I don't know of anyone still using it, but it's not
> > impossible. Calgary and CalIOC2 machines would now be ~5-8 years
> > old.
>
> It is getting a bit crufty in arch/x86. Would it be better to move
> it to drivers/iommu?
Not sure
On Fri, Mar 07, 2014 at 11:09:06AM -0500, Vivek Goyal wrote:
> I would say it is not very complicated to maintain backward
> compatibility in this case. So let us keep saved_max_pfn for some
> time and make kexec-tools changes. Some time down the line, one can
> get rid of saved_max_pfn completely
Patch looks good to me.
Acked-by: Muli Ben-Yehuda
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
On Sun, Jun 01, 2014 at 05:54:25PM +0700, Jun Koi wrote:
> So this means ESXi never uses VMResume/VMLaunch? How is this
> possible, because it uses VMX for its implementation?
ESXi will fall back to binary translation if it decides that it cannot
use VMX for some reason. Look at the L2's log file
On Sun, Jun 01, 2014 at 11:30:02PM +0700, Jun Koi wrote:
> (1) do you think this VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL is the
> reason why ESXi falls back to binary translation?
It might be, its been a while since I got ESXi to use VMX on KVM. Take
a look at the VMware log file for the L2, it sh
101 - 153 of 153 matches
Mail list logo
