as well, to make NO_HZ_FULL work again on the stable trees?
Thanks,
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
L2, it should have a lot more
information.
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 FAQ at http://www.tux.org/lkml/
's log file inside ESXi and you
will likely find some errors related to running nested, MSRs KVM does
not emulate properly, or something else that causes ESXi to use binary
translation for its L2.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
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
aved_max_pfn completely.
If this is not too painful then this would be my preference too.
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.ht
o move
> it to drivers/iommu?
Not sure I see the potential benefit... I think for Calgary it's
either leave it in arch/x86 or rip it out.
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
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 l
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 th
7295 cpu_id=3
-0 [003] d...2.. 355.621762: cpu_idle: state=1 cpu_id=3
--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 FAQ at http://www.tux.org/lkml/
On Fri, Feb 15, 2008 at 10:28:22AM -0800, Greg KH wrote:
> That would be nice. Muli, want to make a patch for this?
Sure, I'll put something together.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
PCI
device initialization, since we want to turn translation on before any
device will try to DMA.
In conclusion, our usage doesn't seem lika a good fit for the probe
approach, although it could probably converted provided we got the
ordering right with regards to regular PCI device
initializati
g like the patch below would be fine?
Yep, looks good.
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
Please read the FAQ at http://www.tux.org/lkml/
symmetry. Feel free to nuke
it and walk the list forward.
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
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Feb 12, 2008 at 01:00:06AM -0800, David Miller wrote:
> From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 10:52:56 +0200
>
> > The streaming DMA-API was designed to conserve IOMMU mappings for
> > machines where IOMMU mappings are a scarce reso
O is to fix the drivers to batch mapping and unmapping operations
or map up-front and unmap when done. The streaming DMA-API was
designed to conserve IOMMU mappings for machines where IOMMU mappings
are a scarce resource, and is a poor fit for a modern IOMMU such as
VT-d with a 64-bit IO address spa
ready submission deadline: May 13th, 2008
OSR guest editors:
* Muli Ben-Yehuda, IBM Haifa Research Lab <[EMAIL PROTECTED]>
* Eric Van Hensbergen, IBM Austin Research Lab <[EMAIL PROTECTED]>
* Marc E. Fiuczynski, Princeton University <[EMAIL PROTECTED]>
Review committee:
* Patr
needs to be cleared if DMA's are going to happen
> effectively.
>
> please apply
>
> --mgross
>
> Signed-off-by: mark gross <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Mark, please try in the future to not mix unrelated changes such as
th
t just return prev_ops->op if it's set.
> It seems a small dispatcher which takes care of this seems the
> likely choice here, but avoiding it (or at least caching the
> decisions) is something that needs more thought.
Yeah, I'm not too enthusiastic about it, but we do need su
On Mon, Nov 12, 2007 at 05:26:24PM +0530, Amit Shah wrote:
> On Monday 12 November 2007 16:20:01 Muli Ben-Yehuda wrote:
> > On Wed, Nov 07, 2007 at 04:21:04PM +0200, Amit Shah wrote:
> > > We make the dma_mapping_ops structure to point to our structure so
> > > that ev
. the reason it's done this way is that
Andi Kleen preferred it for some reason at the time. How about trying
to fix it cleanly so that dma_alloc_coherent always gets called rather
than adding a hack to work around a hack? It will require auditing all
of the different x86 dma-ops but I can he
ons.
Doesn't really belong in the DMA mapping API. Instead what I think we
should do is to cache this (per device) value in the pci_device struct
(or device struct?) and in the dma-ops implementation inspect it to
decide exactly how to do DMA mapping for this device.
Cheers,
Muli
-
To unsubsc
I need the same facility for Calgary for falling back to swiotlb if a
translation is disabled on some slot, and IB needs the same facility
for some IB adapters (e.g., ipath). Perhaps it's time to consider
stackable dma-ops (unless someone has a better idea...).
Cheers,
Muli
-
To unsubscribe fr
unk <[EMAIL PROTECTED]>
Thanks, applied. Will push with my next batch of Calgary updates.
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/m
- } while (count--);
> > + } while (--count);
> >
> > spin_unlock_irqrestore(&card->lock, flags);
> >
> > if (count == 0) {
> >
>
> Thanks, much better. In the future, please also CC: the appropriate
> maintainers, o
> restrictions, rather than fixing all the IOMMUs' free area
> management,
In general it sounds like a great idea, but have you looked at what
impact this has on the performance of the IO path?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
point to having a command line to preserve any protected areas
> set up at boot time.
The society for controlled proliferation of command line options
thanks you.
> Signed-off-by: mark gross <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
--
SYS
lear_pmen_epm = 0;
`suppress', I assume. Rest looks fine, if the configuration option is
really needed.
Cheers,
Muli
--
SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007
http://www.haifa.il.ibm.com/Workshops/systor2007/
Virtualization workshop: Oct 29th, 2007 | Storage
IOMMU is off?" and "how come some iommu_xxx options
(which were really gart options...) don't actually affect the
(Calgary) IOMMU"?
If the variable names clash the correct solution is to s/gart/agpgart/
in the AGP code and then continue renaming gart specific bits 'gart&#
On Tue, Oct 23, 2007 at 07:41:32PM +0200, Joerg Roedel wrote:
> This patch makes some functions and variables static in pci-gart_64.c which
> are
> not used somewhere else.
>
> Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]&g
On Tue, Oct 23, 2007 at 07:41:31PM +0200, Joerg Roedel wrote:
> This patch renames the IOMMU config option to GART_IOMMU because in fact it
> means the GART and not general support for an IOMMU on x86.
>
> Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Acked-by: Muli
Roedel <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
--
SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007
http://www.haifa.il.ibm.com/Workshops/systor2007/
Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007
-
To
renaming the config option to
CONFIG_GART_IOMMU while you're at it?
Cheers,
Muli
--
SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007
http://www.haifa.il.ibm.com/Workshops/systor2007/
Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007
-
To unsubscr
On Wed, Oct 10, 2007 at 11:00:58AM +0530, Vivek Goyal wrote:
> On Tue, Oct 09, 2007 at 11:06:23PM +0200, Muli Ben-Yehuda wrote:
> > Hi Chandru,
> >
> > Thanks for the patch. Comments on the patch below, but first a general
> > question for my education: the mai
not be
corrupted...) from the old kernel.
Cheers,
Muli
On Wed, Oct 10, 2007 at 02:10:13AM +0530, chandru wrote:
> kdump kernel fails to boot with calgary iommu and aacraid driver on
> a x366 box. The ongoing dma's of aacraid from the first kernel
> continue to exist until the driver
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
The old check we used based on dev->bus->number is wrong for devices
on CalIOC2. Instead look whether we have an IOMMU table for that bus -
if not, translation is disabled.
Thanks to Murillo Fernandes Bernardes <[EMAIL PROTECTED]> for
spotting, suggesting a fix and testing.
Signed-
0x1fffULL
> -#define DMA_28BIT_MASK 0x0fffULL
> -#define DMA_24BIT_MASK 0x00ffULL
> +#define DMA_BIT_MASK(n) ((1ULL<<(n))-1)
> +
> +#define DMA_64BIT_MASK DMA_BIT_MASK(64)
This one does not do what you mean. You need an explic
atch solves my problem.
> Any objection to below patch?
I will give it a spin to verify it works for me, but in general I am
wary of making such changes unless we can verify (read: audit) that
they have no adverse side effects *on all architectures*.
Cheers,
Muli
-
To unsubscribe from this li
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
y used by IOMMU driver to
> keep its per device context pointer.
Hmpf, why is this needed? with the pci_sysdata work that recently went
into mainline we have a void *iommu member in pci_sysdata which should
be all that's needed. Please elaborate if it's not enough for your
needs.
Thanks,
On Sat, Sep 01, 2007 at 10:32:23AM -0400, Jeff Garzik wrote:
>
> Now that the dust has settled and the prep work is upstream, adding
> PCI edomain support to x86 is a lot more straightforward.
>
> Targetted for 2.6.24.
Looks good to me.
Cheers,
Muli
-
To unsubscribe from this
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 thi
On Mon, Aug 13, 2007 at 10:25:02AM -0700, Joe Perches wrote:
> On Mon, 2007-08-13 at 15:18 +0300, Muli Ben-Yehuda wrote:
> > Nope, this entry is for sound/oss/trident*.
>
> TRIDENT 4DWAVE/SIS 7018 PCI AUDIO CORE
> P:Muli Ben-Yehuda
> M:[EMAIL PROTECTED]
INTAINERS
> @@ -4563,6 +4563,7 @@ P: Muli Ben-Yehuda
> M: [EMAIL PROTECTED]
> L: linux-kernel@vger.kernel.org
> S: Maintained
> +F: sound/pci/trident/
Nope, this entry is for sound/oss/trident*.
Cheers,
Muli
-
To unsubscribe from this list: send the line "uns
Multiple F: lines acceptable.
> -
> 3C359 NETWORK DRIVER
> P: Mike Phillips
> M: [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
Please read the FAQ at http://www.tux.org/lkml/
+F: arch/x86_64/kernel/tce.c
> +F: include/asm-x86_6/calgary.h
> +F: include/asm-x86_6/pci.h
Likewise pci.h.
You may also want to include
F: include/asm-x86_6/tce.h
F: include/asm-x86_6/rio.h
Rest looks good:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
M
e page point(ed) to.
I see, thanks.
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
Please read the FAQ at http://www.tux.org/lkml/
bug Jan pointed out with the patch, we're also using
cflflush in other places (arch/i386/kernel/alternative.c and
arch/x86_64/kernel/tce.c). Is the issue with clflush support specific
to pageattr.c or should it be disabled every else too? what
specifically is the issue?
Cheers,
Muli
-
To uns
issues you've seen?
Riku, does this fix "pci=noacpi" on your laptop?
Comments appreciated. If this looks ok it should go into 2.6.23.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cc: Yinghai Lu <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: An
ne update version to pci_sysdata ... also reverse
> pci_acpi_scan_root to use pcibios_scan_root again.
Can you explain why this patch (and your other patches in this area)
are needed? is this a performance issue? the patches seem complex, is
there a good argument for that complexity?
Cheers,
ything from Andy Whitcroft. It passes all of
my tests and what we have now is obviously broken... I think we should
put the fix in.
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:/
ming for the minimal "obviously
correc" change for 2.6.23...
> pci_scan_bus_with_sysdata(int busno) make me feel that i need feed one
> sysdata as on param for it.
Yeah, lousy name, but the best I came up with. Runner up was
'x86_pci_scan_bus', which is I think worse?
Cheers
S) and run-time tested on i386 and x86-64. Unfortunately none of
my machines exhibited the bugs so caveat emptor.
Andy, could you please see if this fixes the NUMA issues you've seen?
Riku, does this fix "pci=noacpi" on your laptop?
Comments appreciated. If this looks ok it s
h should be considered for 2.6.24.
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
Please read the FAQ at http://www.tux.org/lkml/
_bus_to_node-as-early-v2) that only takes care
of the missing ->sysdata bits. If that patch cures the original bug
and doesn't cause any more regressions, it's definitely 2.6.23
material.
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
Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc1 ->sysdata breakage?
Reverting my and jgarzik's sysdata patch won't fix Andy's issue.
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.kern
On Sat, Aug 04, 2007 at 09:33:58PM -0700, Yinghai Lu wrote:
> I hope we can use .node and .iommu in pci_bus...
pci_bus is shared between different architectures, and not all
architectures need .node and .iommu. Why is this better than using the
(arch specific) ->sysdata?
Cheers,
Mul
on any of my machines, but I'm
looking into it.
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
Please read the FAQ at http://www.tux.org/lkml/
}
> > }
> > }
> >
>
> Andy keeps trotting out a patch which will probably fix this, but
> for some reason it doesn't seem to make progress.
Hmm, looks like we're missing one of the paths where
Andrew, can you please push this Calgary bug-fix to 2.6.23 in your
next merge? it fixes a showstopper bug in the recently merged CalIOC2
support that hits machines with multiple levels of PCI-to-PCI bridges.
Thanks,
Muli
---
From: Murillo Fernandes Bernardes <[EMAIL PROTECTED]>
Subject:
On Wed, Aug 01, 2007 at 07:53:15PM +0200, Michal Piotrowski wrote:
> Hi,
>
> There is no need to include linux/init.h twice
Thanks, looks good. Will be pushed for 2.6.24.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Sun, Jul 29, 2007 at 06:27:22PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix typos and update function parameters.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Mul
prototype is for consistency's sake with the
definition. The extern I have no idea... probably legacy from some
other code, but they don't bother me.
Anyway, forgot to mention earlier - thanks for your patch!
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe l
nce to
.init.text:free_bootmem (between 'free_tce_table' and 'build_tce_table')
WARNING: vmlinux.o(.text+0x187e5): Section mismatch: reference to
.init.text:__alloc_bootmem_low (between 'alloc_tce_table' and
'kretprobe_trampoline_holder')
Signed-off-by: Randy Du
igned-off-by: Randy Dunlap <[EMAIL PROTECTED]>
At some point in time we will need to support hotplug with IOMMU
translation enabled, in which case they'll be called when hotplug
happens as well, but in the mean time
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
I'll
On Sat, Jul 21, 2007 at 03:09:41PM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> > Ok, let's try again:
> >
> > You're changing this (pageattr.c)
> >
> > asm volatile("clflush (%0)" :: "r" (adr
On Sat, Jul 21, 2007 at 01:18:54PM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> > So it looks like we have a purely syntactic patch that does something
> > different than the original code in one of the above places. What am I
> > missing?
> >
On Sat, Jul 21, 2007 at 12:52:26PM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> > Mostly looks good, but see below.
> >
> >> diff --git a/drivers/char/agp/efficeon-agp.c
> >> b/drivers/char/agp/efficeon-agp.c
> >> index df8da72..41f
f (last_page &&
> + (((unsigned long)page^(unsigned long)last_page) &
> + clflush_mask))
> + clflush(last_page);
Same thing.
> last_page = page;
> }
>
> if ( last_page )
> -
m volatile("wbinvd":::"memory");
> >> + wbinvd();
> >
> > I guess it can be just removed there. I don' think there are any
> > calgary machines without clflush
> >
> That seems like an unsafe thing to do (unless we err out so
of chained sglists once
> that happens.
I sincerely hope they'll make 2.6.23 but Andi appears to have fallen
into a black hole.
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
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
gt; #endif
The generic bits look much better than the previous version,
thanks. Is the generic dma_data_direction_set_dmaflush really needed?
if yes, what about dma_data_direction_get_direction and
dma_data_direction_get_dmaflush?
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
Please read the FAQ at http://www.tux.org/lkml/
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 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
#x27;t boot without it
if CONFIG_CALGARY_IOMMU is enabled).
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
Please read the FAQ at http://www.tux.org/lkml/
and code churn, I also don't like teaching every
architecture about every other architecture's use of sysdata, which is
inherently architecture specific. I think the benefits of modularity
here outweigh the benefits of a little type safety.
Cheers,
Muli
-
To unsubscribe from this
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 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
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 +
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
No actual code was harmed in the production of this patch.
Thanks to Andrew Morton <[EMAIL PROTECTED]> for telling me
about checkpatch.pl.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |9
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Currently the IOMMU table's lock protects both the bitmap and access
to the hardware's TCE table. Access to the TCE table is synchronized
through the bitmap; therefore, only hold the lock while modifying the
bitmap. This gives a yummy 10-
apply.
Thanks,
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
Please read the FAQ at http://www.tux.org/lkml/
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
After the bitmap changes we can get rid of the unlocked versions of
calgary_unmap_sg and iommu_free. Fold __calgary_unmap_sg and
__iommu_free into their calgary_unmap_sg and iommu_free, respectively.
Signed-off-by: Muli Ben-Yehuda <[EMAIL
From: Yinghai Lu <[EMAIL PROTECTED]>
there function are called via dma_ops->.., so change them to static
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |8
1 files change
;re right, that should be a debug message as well.
> [..]
> Calgary: detecting Calgary via BIOS EBDA area
> Calgary: Unable to locate Rio Grande table in EBDA - bailing!
These are KERN_DEBUG messages.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-
return 0;
The convention is to print a KERN_DEBUG message if hardware is not
found when probing it, otherwise the boot messages become cluttered
with lots of "$FOO not found".
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
Please read the FAQ at http://www.tux.org/lkml/
asm-x86_64/dma_mapping.h to
> arch/x86_64/pci-dma.c?
If yes, why? it's not exactly a big function:
static inline dma_addr_t
dma_map_single(struct device *hwdev, void *ptr, size_t size,
int direction)
{
BUG_ON(!valid_dma_direction(direction));
return dma_ops->
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
>
that block and net IOs will not straddle a page
boundary?
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
Please read the FAQ at http://www.tux.org/lkml/
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.
hernet cards.
Please try netperf and a bigger machine for a meaningful comparison :-)
I assume this is with e1000?
> Going forward we will do more benchmark tests and will share the
> results.
Looking forward to it.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscri
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
ping is
> needed.
Calgary already does this internally (via calgary=disable=)
but that's pretty ugly. It would be better to do it in a generic
fashion when deciding which dma_ops to call (i.e., a dma_ops per bus
or device).
> Also the user interface for X server case needs more work.
Is
ink an iommu_ops is a better approach. I'll put
something together when I add the Calgary shutdown bits next week
after OLS.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
interesting to see comparable numbers for VT-d.
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
Please read the FAQ at http://www.tux.org/lkml/
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_m
ommu_detected;
> #ifdef CONFIG_IOMMU
> extern void gart_iommu_init(void);
> +extern void gart_iommu_shutdown(void);
> extern void __init gart_parse_options(char *);
> extern void iommu_hole_init(void);
> extern int fallback_aper_order;
> @@ -101,6 +103,11 @@ extern int fix_apertur
ile if !CONFIG_IOMMU. That's quite standard kernel practice and
> >might help avoid some other problems...
>
> move ifdef into gart_iommu_shudown()?
What Andrew means is
(in a header file)
#ifdef CONFIG_IOMMU
extern void gart_iommu_shutdown(void);
#else
static inline void gart_iommu
own
> handler in sysfs Don't see any value in going through a generic
> layer because there is no shared code.
Going through the shared layer makes it obvious to new IOMMU
implementers that they will need to implement a shutdown hook and
takes roughly the same ammount of work. I think th
1 - 100 of 181 matches
Mail list logo
