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
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
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 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
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 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 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 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 [EMAIL PROTECTED]
More major
On Thu, Feb 14, 2008 at 11:17:03PM -0800, Greg KH wrote:
> Hm, that's wierd. I thought I got something, until I realized that
> you are doing a lot of logic before you ever even determine that
> your hardware is present in the system. Why are you calling
> calgary_locate_bbars() and doing all of
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/
On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote:
> Why does the calgary driver need this? Can we just use
> pci_get_device() instead? Why do you need to walk the device list
> backwards? Do you get false positives going forward?
It's not strictly needed, we used it for symmetry. Feel f
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
On Mon, Feb 11, 2008 at 02:41:05PM -0800, mark gross wrote:
> The intel-iommu hardware requires a polling operation to flush IOTLB
> PTE's after an unmap operation. Through some TSC instrumentation of
> a netperf UDP stream with small packets test case it was seen that
> the flush operations wher
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
On Mon, Nov 12, 2007 at 07:25:27PM +0530, Amit Shah wrote:
> Selectively? What happens in the case when some iommu doesn't want
> to invoke the prev_op, but the mapping depends on it being called
> (eg, the hypercalling op is embedded somewhere in the prev_op chain)
Bad things :-)
There needs to
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
On Wed, Nov 07, 2007 at 04:21:06PM +0200, Amit Shah wrote:
> Of all the DMA calls, only dma_alloc_coherent might not actually
> call dma_ops->alloc_coherent. We make sure that gets called if the
> device that's being worked on is a PV device
I always thougt that's a mess... the reason it's done t
On Wed, Nov 07, 2007 at 04:21:05PM +0200, Amit Shah wrote:
> A guest can call dma_ops->is_pv_device() to find out if a device is
> a passthrough'ed device (device passed on to a guest by the
> host). If this is true, a hypercall will be made to translate DMA
> mapping operations.
Doesn't really b
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 every DMA access goes through us. (This is the reason this only
> works for 64-bit guest. 32-bit guest doesn't yet have a dma_ops
> struct.)
I need the same facil
On Fri, Nov 09, 2007 at 07:03:30AM +0100, Adrian Bunk wrote:
> "debugging" is a horrible name for a global variable - thankfully it can
> become static.
>
> Also put it out of __read_mostly so that gcc no longer has to emit it
> at all.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Thanks,
- } 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
On Sat, Nov 03, 2007 at 02:05:39AM +0900, FUJITA Tomonori wrote:
> This patchset convert the PPC64 IOMMU to use the iova code for free
> area management.
>
> The IOMMUs ignores low level drivers' restrictions, the maximum
> segment size and segment boundary.
>
> I fixed the former:
>
> http://t
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
On Fri, Oct 26, 2007 at 11:18:49AM -0700, Mark Gross wrote:
> The following patch clears the portect memory region enable bit at
> boot time by default. It also provides a kernel parrameter for
> disabling this behavior and leave the PMEN_REG untouched if so
> wanted.
>
> If the boot loader or p
On Tue, Oct 23, 2007 at 08:10:54PM +0200, Andi Kleen wrote:
> I think his goal was to get an prefix that describes the module
> uniquely. gart_* clearly does not fulfill that criteria.
>
> So basically he's replacing an
> ambigious-with-other-IOMMU-implementations prefix with an
> ambigious-with
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
On Fri, Oct 19, 2007 at 02:38:11PM +0200, Joerg Roedel wrote:
> This patch renames the include file asm-x86/iommu.h to asm-x86/gart.h to make
> clear to which IOMMU implementation it belongs. The patch also adds "GART" to
> the Kconfig line.
Long overdue IMHO. How about also renaming the config o
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
Hi Chandru,
Thanks for the patch. Comments on the patch below, but first a general
question for my education: the main problem here that aacraid
continues DMA'ing when it shouldn't. Why can't we shut it down
cleanly? Even without the presence of an IOMMU, it seems dangerous to
let an adapter conti
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
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
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:
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 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 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 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 list: send the lin
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 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
On Sun, Aug 12, 2007 at 10:53:19PM -0700, Joe Perches wrote:
> Describe the new F: pattern
Patch looks reversed?
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d7f856..d3a0684 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -83,13 +83,
+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
On Thu, Aug 09, 2007 at 02:29:58PM +0100, Jan Beulich wrote:
> The issue here is not with clflush by itself, but with what pages it
> is being applied to. Here, it gets used on page table pages when
> flushing really is needed on what one or more page table entries in
> that page table page point(
On Thu, Aug 09, 2007 at 02:41:31PM +0200, Andi Kleen wrote:
>
> It turns out CLFLUSH support is still not complete; we
> flush the wrong pages. Again disable it for the release.
> Noticed by Jan Beulich.
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Aside from the bug Jan pointed out with t
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
On Tue, Aug 07, 2007 at 06:20:33PM -0700, Yinghai Lu wrote:
> please check this one against pci_scan_bus_with_sysdata
>
> [PATCH 1/5] x86_64: get mp_bus_to_node as early v3
>
> current on amd k8 system with multi ht chain, the numa_node of pci
> devices under r/sys/devices/pci:80/* always 0,
On Tue, Aug 07, 2007 at 03:49:11PM -0700, Andrew Morton wrote:
> I am sooo tired of this thing. Andi, someone, can we for heaven's
> sake please just get it all sorted out?
With regards to the sysdata conversion: Riku says he cannot test new
kernel. I haven't heard anything from Andy Whitcro
On Sun, Aug 05, 2007 at 01:49:57AM -0700, Yinghai Lu wrote:
> Can you change
> pci_scan_bus_with_sysdata(int busno)
> to
> pci_scan_bus_on_node(int bus, struct pci_ops *ops, int node)?
Do you anticipate passing in a different pci_ops or node?
In any case please remember I am aiming for the minim
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
On Sat, Aug 04, 2007 at 11:07:04PM -0700, Yinghai Lu wrote:
> You just use my patch plus Andy's patch together...
Your patch does other things that in my opinion are not appropriate at
this stage for 2.6.23. I am aiming for the minimal change that will
fix the regression, and your patch should be
On Sat, Aug 04, 2007 at 10:52:22PM -0700, Andrew Morton wrote:
> On Sat, 4 Aug 2007 12:02:35 -0700 "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
>
> > On 8/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > On Sat, 4 Aug 2007 10:45:31 -0700 "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Andrew,
On Sun, Aug 05, 2007 at 01:40:49AM +0200, Andi Kleen wrote:
> Oh what a mess. I think I'll ask Linus to revert the sysdata patch
> instead. Clearly the stuff is half-baked
By the way, Andi, just making sure you're aware the issue Andy's patch
addresses is separate from the 2.6.23-rc1 ->sysdata br
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,
Muli
-
To unsubs
On Sun, Aug 05, 2007 at 01:40:49AM +0200, Andi Kleen wrote:
> > "pci device ensure sysdata initialised", now at version 4.
>
> Oh what a mess. I think I'll ask Linus to revert the sysdata patch
> instead. Clearly the stuff is half-baked
Personally I don't care that much, but I think you'll make
On Fri, Aug 03, 2007 at 03:50:35PM -0700, Andrew Morton wrote:
> On Fri, 03 Aug 2007 18:10:03 -0400
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250859
> >
> > at line 74:
> >
> > [EMAIL PROTECTED]:
> > [EMAIL PROTECTED]:
pwards until we get to the top (Calgary/CalIOC2
bridge), where the iommu table resides.
Signed-off-by: Murillo Fernandes Bernardes <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
--
diff -ruN linux-2.6.23-rc1.orig/arch/x86_64/kernel/pci-calgary.c
linux-2.6.23-rc1/
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 a message to [EMAIL PRO
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
On Thu, Jul 26, 2007 at 12:02:38PM +0200, Sam Ravnborg wrote:
> Now I recall I saw it too :-(
> This one is beeter although the __init in the prototype declaration
> should have no effect. (Also wonder why the prototypes are extern -
> that should be a no-op too).
The __init in the prototype is
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
On Fri, Jul 20, 2007 at 02:19:58PM -0700, H. Peter Anvin wrote:
> Create an inline function for clflush(), with the proper arguments,
> and use it instead of hard-coding the instruction.
>
> This also removes one instance of hard-coded wbinvd, based on a patch
> by Bauder de Oliveira Costa.
>
> C
On Fri, Jul 20, 2007 at 10:22:21AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> > On Friday 20 July 2007 00:55:40 Glauber de Oliveira Costa wrote:
> >> This patch uses the already-existant wbinvd() macro to replace
> >> raw assembly to perform this very same task in some .c files
> >>
>
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
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 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
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
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 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 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 +
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
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 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 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 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 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 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 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 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 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
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 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 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 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 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 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 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 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 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 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 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 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
1 - 100 of 153 matches
Mail list logo
