On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
> which
> the updated bindings[1] define #address-cells = <0> and so no reg
> property.
>
> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
Why did you d
On Fri, 2013-08-16 at 18:39 +0100, Sudeep KarkadaNagesha wrote:
> +#ifdef CONFIG_PPC
> + /* Check for historical "ibm,ppc-interrupt-server#s" property
> +* for thread ids on PowerPC. If it doesn't exist fallback to
> +* standard "reg" property.
> +
On Fri, 2013-08-16 at 18:39 +0100, Sudeep KarkadaNagesha wrote:
> +static bool __of_find_n_match_cpu_property(struct device_node *cpun,
> + const char *prop_name, int cpu, unsigned int
> *thread)
> +{
> + const __be32 *cell;
> + int ac, prop_len, tid;
> + u64
On Fri, 2013-08-16 at 09:48 +0100, Sudeep KarkadaNagesha wrote:
> > Naming is a bit gross. You might want to make it clearer that
> > we are talking about CPU IDs in the device-tree here.
> >
> Any particular preference to the name or just a note is sufficient.
> Also unlike PPC, in ARM we don't
On Thu, 2013-08-15 at 18:09 +0100, Sudeep KarkadaNagesha wrote:
>/* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
> * fallback to "reg" property and assume no threads
> */
> -
Oh and I forgot ... that comment is now wrong, since your co
On Thu, 2013-08-15 at 18:09 +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic nee
On Wed, 2013-08-14 at 14:21 +0100, Sudeep KarkadaNagesha wrote:
> IMO moving of handling ibm,ppc-interrupt-server#s to generic code
> under
> #ifdef CONFIG_PPC seems to be cleaner approach than weak definitation.
>
> As per my understanding each thread is a different logical cpu.
> Each logical cp
On Wed, 2013-08-14 at 11:01 +0100, Sudeep KarkadaNagesha wrote:
> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s",
> for
> which we can have PPC specific wrapper above the generic one i.e. get
> the cpu node and then parse for thread id under custom property.
A wrapper is wrong.
On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
> This is to reserve a capablity number for upcoming support
> of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
> which support mulptiple DMA map/unmap operations per one call.
Gleb, any chance you can put this (and the next on
On Tue, 2013-08-13 at 21:45 +0200, Rafael J. Wysocki wrote:
>
> I'd go for 1 above personally.
Yuck no. Two functions with roughly the same name and the same purpose
differing only by an underscore just because one can't take 5mn to
reconcile the new one with the old one ? No way.
Ben.
--
To u
On Tue, 2013-08-13 at 13:44 -0500, Rob Herring wrote:
> It is up to Rafael if he is willing/able to rebase his tree, but I
> would drop this series until this is sorted out. I think the new
> common function should be and can be generalized to work for powerpc.
> It would need to make reg property
On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
> I don't understand completely the use of ibm,ppc-interrupt-server#s and
> its implications on generic of_get_cpu_node implementation.
> I see the PPC specific definition of of_get_cpu_node uses thread id only
> in 2 instances. Based
On Tue, 2013-08-13 at 16:40 +0100, Sudeep KarkadaNagesha wrote:
> There seems to be conflict in the new function "of_get_cpu_node" added.
> PowerPC also defines the same function name. Further microblaze and
> openrisc declares it(can be removed) but doesn't define it.
> To fix this:
> 1. I can ren
Hi Linus !
Here are some powerpc fixes for you.
This includes small series from Michael Neuling to fix a couple of nasty
remaining problems with the new Power8 support, also targeted at stable
3.10, without which some new userspace accessible registers aren't
properly context switched, and in som
On Tue, 2013-08-06 at 15:44 -0500, Nathan Fontenot wrote:
> I am planning on pulling the first two patches and sending them out
> separate from the patch set since they are really independent of the
> rest of the patch series.
>
> The remaining code I will send out for review and inclusion in
> li
On Wed, 2013-08-07 at 18:15 -0500, Fionnuala Gunter wrote:
> This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
> nx-crypto driver on input larger than 32 bytes.
>
> The chaining value from co-processor was not being saved. This value is
> needed because it is used as the IV
On Tue, 2013-08-06 at 18:08 -0500, Scott Wood wrote:
> Here's another example. get_lppaca() will only build on book3s -- and
> yet we get requests for e500 code to use this file.
Indeed, Besides there is already accessors afaik for lppaca that compile
to nothing on E (and if not they would be tri
On Fri, 2013-08-02 at 17:37 -0600, Alex Williamson wrote:
> > Yes.
> >
> > We have that similar issue with error handling, when the driver doesn't
> > have the right hooks, we simulate an unplug, reset, then replug.
> >
> > Maybe we could provide generic helpers to do that...
>
> Devices going
On Fri, 2013-08-02 at 16:49 -0600, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> On Fri, Aug 2, 2013 at 3:28 PM, Benjamin Herrenschmidt
> wrote:
>
> > Right. Another use case is, I know of devices that need a fundamental
> > reset (PERST) after applying a FW update.
>
[ resent in case you missed it ]
Hi Linus !
Here is not quite a handful of powerpc fixes for rc3. The windfarm fix is
a regression fix (though not a new one), the PMU interrupt rename is not
a fix per-se but has been submitted a long time ago and I kept forgetting
to put it in (it puts us back in
On Fri, 2013-08-02 at 10:36 -0600, Alex Williamson wrote:
> > Also in some cases, at least for us, we have a problem where the scope
> > of the reset can be larger than the group ... in this case I think we
> > need to forbid the reset.
>
> Interesting, I would have ventured to guess that resets
On Fri, 2013-08-02 at 10:19 -0400, Paul Gortmaker wrote:
>
> Yep, 3.8 shuffled TIF_MEMDIE to the end of the queue, but
> in 3.10, mainline commit 22ecbe8dcef has already done that trick.
>
> The list of donor victims that aren't used in asm is getting
> smaller, but TIF_POLLING_NRFLAG seems OK an
On Thu, 2013-08-01 at 16:18 -0600, Alex Williamson wrote:
> vfio-pci needs to support an interface to do hot resets (PCI parent
> bridge secondary bus reset). We need this to support reset of
> co-assigned devices where one or more of the devices does not support
> function level reset. In parti
On Thu, 2013-08-01 at 20:03 -0400, Paul Gortmaker wrote:
> I've added Ben to the CC in case he has a suggestion on
> how best to fix this, even though it is not yet mainline.
Can you exchange with a TIF_ that isn't used in asm ? For example
TIF_PERFMON_* ? Keep all the asm ones below 16 and move u
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
> This series of patches fixes two bugs that are triggered when the input data
> is
> too large. The first one is caused by the miscalculation of physical addresses
> and the second one by some limits that the co-processor has to the input da
Hi Linus !
Here is not quite a handful of powerpc fixes for rc3. The windfarm fix is
a regression fix (though not a new one), the PMU interrupt rename is not
a fix per-se but has been submitted a long time ago and I kept forgetting
to put it in (it puts us back in sync with x86), the other perf bi
On Mon, 2013-07-22 at 00:44 +0100, Grant Likely wrote:
> > BTW, it looks like Grant has attempted this already:
>
> Yup, things broke badly. Unfortunately the of_platform_device and
> platform_device history doesn't treat resources in the same way. I
> would like to merge the code, but I haven't b
On Fri, 2013-07-19 at 20:14 +0200, Sebastian Andrzej Siewior wrote:
> The problem is that platform_device_del() "releases" each ressource in its
> tree. This does not work on platform_devices created by OF becuase they
> were never added via insert_resource(). As a consequence old->parent in
> __re
On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote:
> *The lapic of a broadcast CPU is active always*. Say CPUX, wants the
> broadcast CPU to wake it up at timeX. Since we cannot program the lapic
> of a remote CPU, CPUX will need to send an IPI to the broadcast CPU,
> asking it to program i
On Fri, 2013-07-26 at 12:54 -0700, Linus Torvalds wrote:
>
> *Some* other 64-bit architectures do 16k stack sizes. But neither
> x86-64 nor powerpc do, afaik. Instead, they do irq stacks, which is
> generally a better idea than having one big stack.
Sadly you over estimated us here :-) We do 16K
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
> ---
> drivers/crypto/nx/nx-sha256.c | 108 +++-
> drivers/crypto/nx/nx-sha512.c | 113
> --
> 2 files changed, 129 insertions(+), 92 deletions(-)
What about the o
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote:
>
> Signed-off-by: Fionnuala Gunter
> Signed-off-by: Joel Schopp
> Signed-off-by: Joy Latten
> Signed-off-by: Marcelo Cerri
> ---
Why that enormous S-O-B list ? Did every of these people actually carry
the patch ? If it's just acks or re
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
> > Apart from the annoying colors, is there anything specific I should
> > be looking for? Some sort of error message, or output that actually
> > makes sense?
>
> Thanks for testing! Ben, I think the patch is good to go.
Sent it yesterd
On Wed, 2013-07-24 at 15:43 -0700, Andrew Morton wrote:
> For what? The three lines of comment in page-flags.h? ack :)
>
> Manipulating page->_count directly is considered poor form. Don't
> blame us if we break your code ;)
>
> Actually, the manipulation in realmode_get_page() duplicates the
Hi Linus !
Here is a series of powerpc fixes. It's a bit big, mostly because of the
series of 11 "EEH" patches from Gavin. The EEH (Our IBM specific
PCI/PCIe Enhanced Error Handling) code had been rotting for a while and
this merge window saw a significant rework & fixing of it by Gavin Shan.
How
On Mon, 2013-07-22 at 19:53 -0700, Joe Perches wrote:
> Anyway, you cc'd all the right people already.
>
> If no one responds after a couple weeks, either
> send it to Jiri or directly to Linus.
Or I'll just merge it with the rest of the series.
Cheers,
Ben.
--
To unsubscribe from this list: s
On Wed, 2013-07-17 at 11:51 -0700, Sarah Sharp wrote:
> Here's a gem from a senior software developer at Nvidia:
> https://picasaweb.google.com/116960357493251979546/Trolls#5901298464591248626
>
> And another email from a software developer in Portland, where I live:
> https://picasaweb.google.com
On Wed, 2013-07-17 at 10:14 +0400, James Bottomley wrote:
> > OK, I am stupid enough to take a stab at this...
> >
> > 1.Does the Linux kernel community's health depend on the occasional
> > rant? [My guess is that we simply have no way of knowing.
> > That said, I would be intere
On Tue, 2013-07-16 at 17:40 -0500, Scott Wood wrote:
> On 07/15/2013 03:47:06 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> > > Module CRCs are implemented as absolute symbols that get resolved by
> > > a linker scrip
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> Module CRCs are implemented as absolute symbols that get resolved by
> a linker script. We build an intermediate .o that contains an
> unresolved symbol for each CRC. genksysms parses this .o, calculates
> the CRCs and writes a linker scri
On Sun, 2013-07-14 at 18:40 -0700, Linus Torvalds wrote:
> Not before it's been in the distro, no. Something like a PCI change
> *definitely* should never be marked for stable, unless it causes
> crashes or is a _new_ regression that causes dead machines.
>
> Because the likelihood that that 4-5 l
On Fri, 2013-07-12 at 10:50 -0700, Linus Torvalds wrote:
> You cut out the important part:
>
> - It must fix a problem that causes a build error (but not for things
>marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>security issue, or some "oh, that's not good" issue. In s
On Thu, 2013-07-11 at 15:01 -0700, Greg Kroah-Hartman wrote:
> s is the start of the stable review cycle for the 3.10.1 release.
> There are 19 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied,
> please
> let me know.
>
> Re
On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:
> > And the later in -rc we are, the more reluctant some people seem to be
> > at sending stuff. Which, for slowing things down as we go through -rc is
> > great,
> > but not so much when people stop sending _everything_ and start thinki
On Thu, 2013-07-11 at 18:14 -0400, Josh Boyer wrote:
>Why are subsystem maintainers holding on to fixes that are
> > _supposedly_ affecting all users? I mean, 21 powerpc core changes
> > that I don't see until a -rc1 merge? It's as if developers don't
> > expect people to use a .0 relea
On Fri, 2013-07-12 at 10:05 -0700, Greg Kroah-Hartman wrote:
> Specific example is, again, the powerpc patches. Out of 21 patches
> marked for stable that showed up in the -rc1 merge, at least 7 of them
> had _plenty_ of time to get into 3.10.0 as they are weeks, and sometimes
> months, old. Some
On Sun, 2013-07-14 at 13:02 +0200, Paul Bolle wrote:
> The Kconfig symbol HOTPLUG was removed with commit 40b313608a ("Finally
> eradicate CONFIG_HOTPLUG"). But there's still one select statement for
> that symbol. It seems that select statement was added after the patch to
> remove CONFIG_HOTPLUG
On Thu, 2013-07-11 at 12:11 +0200, Alexander Graf wrote:
> > So I must add one more ioctl to enable MULTITCE in kernel handling. Is it
> > what you are saying?
> >
> > I can see KVM_CHECK_EXTENSION but I do not see KVM_ENABLE_EXTENSION or
> > anything like that.
>
> KVM_ENABLE_CAP. It's how we en
On Thu, 2013-07-11 at 15:12 +1000, Alexey Kardashevskiy wrote:
> >> Any debug code is prohibited? Ok, I'll remove.
> >
> > Debug code that requires code changes is prohibited, yes.
> > Debug code that is runtime switchable (pr_debug, trace points, etc)
> > are allowed.
Bollox.
$ grep DBG\( arch/
On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote:
> I don't like bloat usually. But Alexey even had an #ifdef DEBUG in
> there to selectively disable in-kernel handling of multi-TCE. Not
> calling ENABLE_CAP would give him exactly that without ugly #ifdefs in
> the kernel.
I don't see much
On Thu, 2013-07-11 at 14:50 +0200, Alexander Graf wrote:
> > Not really no. But that would do. You could have give a more useful
> > answer in the first place though rather than stringing him along.
>
> Sorry, I figured it was obvious.
It wasn't no, because of the mess with modules and the nasty
On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote:
> There are 2 ways of dealing with this:
>
> 1) Call the ENABLE_CAP on every vcpu. That way one CPU may handle
> this hypercall in the kernel while another one may not. The same as we
> handle PAPR today.
>
> 2) Create a new ENABLE_CAP
On Thu, 2013-07-11 at 13:15 +0200, Alexander Graf wrote:
> And that's bad. Jeez, seriously. Don't argue this case. We enable new
> features individually unless we're 100% sure we can keep everything
> working. In this case an ENABLE_CAP doesn't hurt at all, because user
> space still needs to handl
On Thu, 2013-07-11 at 11:52 +0200, Alexander Graf wrote:
> > Where exactly (it is rather SPAPR_TCE_IOMMU but does not really
> matter)?
> > Select it on KVM_BOOK3S_64? CONFIG_KVM_BOOK3S_64_HV?
> > CONFIG_KVM_BOOK3S_64_PR? PPC_BOOK3S_64?
>
> I'd say the most logical choice would be to check the Mak
On Wed, 2013-07-10 at 12:33 +0200, Alexander Graf wrote:
>
> It's not exactly obvious that you're calling it with writing == 1 :).
> Can you create a new local variable "is_write" in the calling
> function, set that to 1 before the call to get_user_pages_fast and
> pass it in instead of the 1? The
On Tue, 2013-07-09 at 18:02 +0200, Alexander Graf wrote:
> On 07/06/2013 05:07 PM, Alexey Kardashevskiy wrote:
> > The existing TCE machine calls (tce_build and tce_free) only support
> > virtual mode as they call __raw_writeq for TCE invalidation what
> > fails in real mode.
> >
> > This introduce
On Mon, 2013-07-08 at 17:31 +1000, Alexey Kardashevskiy wrote:
> btw is phys_addr_t correct here?
Yes.
Cheers,
Ben.
--
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/ma
On Mon, 2013-07-08 at 14:44 +1000, Alexey Kardashevskiy wrote:
> diff --git a/arch/powerpc/platforms/powernv/pci.h
> b/arch/powerpc/platforms/powernv/pci.h
> index 25d76c4..7ea82c1 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -52,6 +52,7 @@
On Sun, 2013-07-07 at 01:07 +1000, Alexey Kardashevskiy wrote:
> The current VFIO-on-POWER implementation supports only user mode
> driven mapping, i.e. QEMU is sending requests to map/unmap pages.
> However this approach is really slow, so we want to move that to KVM.
> Since H_PUT_TCE can be extr
On Fri, 2013-07-05 at 17:36 -0600, Bjorn Helgaas wrote:
> It seems a little strange to me that this "run the driver probe method
> on the correct node" code is in PCI. I would think this behavior
> would be desirable for *all* bus types, not just PCI, so maybe it
> would make sense to do this up i
on code
powerpc/pseries: Support compression of oops text via pstore
pstore: Add hsize argument in write_buf call of pstore_ftrace_call
Benjamin Herrenschmidt (8):
powerpc/math-emu: Fix decoding of some instructions
powerpc/math-emu: Allow math-emu to be used for HW FP
On Tue, 2013-07-02 at 11:06 +0530, Aruna Balakrishnaiah wrote:
> Incorporate the addition of hsize argument in write_buf callback
> of pstore.
Thanks. I've added that to powerpc-next. It should hit Stephen tomorrow.
Cheers,
Ben.
> Signed-off-by: Aruna Balakrishnaiah
> ---
>
> fs/pstore/ftrace
On Tue, 2013-07-02 at 10:54 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/pstore/ftrace.c: In function 'pstore_ftrace_call':
> fs/pstore/ftrace.c:47:6: warning: passing argument 7 of 'psinfo->
Hi Linus !
Earlier today I mentioned that while we had fixed the kernel crashes,
EEH error recovery didn't always recover... It appears that I had
a fix for that already in powerpc-next (with a stable CC).
I cherry-picked it today and did a few tests and it seems that things
now work quite well.
Hi Linus !
We discovered some breakage in our "EEH" (PCI Error Handling) code while
doing error injection, due to a couple of regressions. One of them is
due to a patch (37f02195b) that, in hindsight, I shouldn't have merged
considering that it caused more problems than it solved.
Please pull tho
On Thu, 2013-06-27 at 16:59 +1000, Stephen Rothwell wrote:
> > +/* Allows an external user (for example, KVM) to unlock an IOMMU
> group */
> > +static void vfio_group_del_external_user(struct file *filep)
> > +{
> > + struct vfio_group *group = filep->private_data;
> > +
> > + BUG_ON(filep
On Thu, 2013-06-27 at 14:53 +1000, Alexey Kardashevskiy wrote:
>
> 2. remove locks from functions being called by VFIO. The whole table
> is given to the user space so it is responsible now for races.
Sure but you still need to be careful that userspace cannot cause things
that crash the kernel.
On Wed, 2013-06-26 at 16:19 +0200, Oleg Nesterov wrote:
>
> You were cc'ed every time ;)
>
> > Why didn't it go through the powerpc tree ?
>
> Because this series needs to update any user of
> ptrace_get/put_breakpoints
> in arch/ (simply remove these calls), then change the core kernel
> code,
On Wed, 2013-06-26 at 16:56 +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm tree got a conflict in
> arch/powerpc/kernel/ptrace.c between commit b0b0aa9c7faf
> ("powerpc/hw_brk: Fix setting of length for exact mode breakpoints") from
> the powerpc tree and commit "ptrace/power
On Wed, 2013-06-26 at 15:39 +1000, Alexey Kardashevskiy wrote:
> VFIO IOMMU driver for sPAPR TCE locks the whole DMA window by setting
> ones to iommu_table.it_map. However this was not protected by the locks
> which other clients of iommu_table use.
>
> The patch fixes this.
>
> Signed-off-by: A
On Tue, 2013-06-25 at 15:15 -0600, Bjorn Helgaas wrote:
> - for_each_pci_dev(dev) {
> > - int i;
> > + /* Not assigned, or rejected by kernel ? */
> > + if (r->flags && !r->start) {
> > + (*unassigned)++;
> > + return 1
Hi Linus !
This is a fix for a regression causing a freescale "83xx" based platforms
to crash on boot due to some PCI breakage. Please apply.
Cheers,
Ben.
The following changes since commit 17858ca65eef148d335ffd4cfc09228a1c1cbfb5:
Merge tag 'please-pull-fixia64' of
git://git.kernel.org/pub/
On Sun, 2013-06-16 at 14:12 +0930, Rusty Russell wrote:
> Sweep of the simple cases.
>
> Cc: net...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Julia Lawall
> Signed-off-by: Rusty Russell
Acked-by: Benjamin Herrensc
On Tue, 2013-06-25 at 17:19 +1000, Michael Ellerman wrote:
> Here's another trace from 3.10-rc7 plus a few local patches.
>
> We suspect that the perf enable could be causing a flood of
> interrupts, but why
> that's clogging things up so badly who knows.
Additionally, perf being potentially NMIs
On Tue, 2013-06-25 at 12:58 +1000, Michael Ellerman wrote:
> On Tue, Jun 25, 2013 at 12:13:04PM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2013-06-25 at 12:08 +1000, Michael Ellerman wrote:
> > > We're not checking for allocation failure, which we should be.
> &
On Tue, 2013-06-25 at 12:08 +1000, Michael Ellerman wrote:
> We're not checking for allocation failure, which we should be.
>
> But this code is only used on powermac and 85xx, so it should probably
> just be a TODO to fix this up to handle the failure.
And what can we do if they fail ?
Cheers,
On Mon, 2013-06-24 at 08:26 -0700, Arjan van de Ven wrote:
>
> to bring the system back up if all cores in the whole system are idle and
> power gated,
> memory in SR etc... is typically < 250 usec (depends on the exact version
> of the cpu etc). But the moment even one core is running, that core
On Mon, 2013-06-24 at 13:54 +1000, David Gibson wrote:
> > DDW means an API by which the guest can request the creation of
> > additional iommus for a given device (typically, in addition to the
> > default smallish 32-bit one using 4k pages, the guest can request
> > a larger window in 64-bit spac
On Fri, 2013-06-21 at 09:54 -0700, Guenter Roeck wrote:
> > v2: Ensure that PCI bus fixup code has been executed before calling
> > device setup code.
> >
> Hi Ben,
>
> any comments/feedback on this approach ?
>
> It is much less invasive than before and should address your concerns.
And a
On Fri, 2013-06-21 at 14:34 -0700, Arjan van de Ven wrote:
> On 6/21/2013 2:23 PM, Catalin Marinas wrote:
> >>
> >> oops sorry I misread your mail (lack of early coffee I suppose)
> >>
> >> I can see your point of having a thing for "did we ask for all the
> >> performance
> >> we could ask for" p
On Sat, 2013-06-22 at 22:03 +1000, David Gibson wrote:
> I think the interface should not take the group fd, but the container
> fd. Holding a reference to *that* would keep the necessary things
> around. But more to the point, it's the right thing semantically:
>
> The container is essentially
On Thu, 2013-06-20 at 15:33 +0200, Joerg Roedel wrote:
> (In case this topic is still relevant)
>
> On Thu, May 09, 2013 at 06:09:42PM +1000, Benjamin Herrenschmidt wrote:
> > Do we provide drivers any guarantee to what happen if an MSI is shot
> > while masked with disable_i
On Thu, 2013-06-20 at 15:28 +1000, David Gibson wrote:
> > Just out of curiosity - would not get_file() and fput_atomic() on a
> group's
> > file* do the right job instead of vfio_group_add_external_user() and
> > vfio_group_del_external_user()?
>
> I was thinking that too. Grabbing a file refere
Hi Linus !
Please pull this regression fix into 3.10. We accidentally broke
hugetlbfs on Freescale embedded processors which use a slightly
different page table layout than our server processors.
Cheers,
Ben.
The following changes since commit c0691143dfe1d42ec9bd89de5921ccb6a27ea1b3:
mn10300
On Wed, 2013-06-19 at 11:58 +0200, Alexander Graf wrote:
> > Alex, any objection ?
>
> Which Alex? :)
Heh, mostly Williamson in this specific case but your input is still
welcome :-)
> I think validate works, it keeps iteration logic out of the kernel
> which is a good thing. There still needs
On Wed, 2013-06-19 at 13:05 +0930, Rusty Russell wrote:
> symbol_get() won't try to load a module; it'll just fail. This is what
> you want, since they must have vfio in the kernel to get a valid fd...
Ok, cool. I suppose what we want here Alexey is slightly higher level,
something like:
On Tue, 2013-06-18 at 08:48 -0600, Alex Williamson wrote:
> On Tue, 2013-06-18 at 14:38 +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-06-17 at 20:32 -0600, Alex Williamson wrote:
> >
> > > Right, we don't want to create dependencies across modules. I don&
On Mon, 2013-06-17 at 20:32 -0600, Alex Williamson wrote:
> Right, we don't want to create dependencies across modules. I don't
> have a vision for how this should work. This is effectively a complete
> side-band to vfio, so we're really just dealing in the iommu group
> space. Maybe there need
On Mon, 2013-06-17 at 17:55 +1000, Alexey Kardashevskiy wrote:
> David:
> ===
> So, in the case of MULTITCE, that's not quite right. PR KVM can
> emulate a PAPR system on a BookE machine, and there's no reason not to
> allow TCE acceleration as well. We can't make it dependent on PAPR
> mode bein
On Sun, 2013-06-16 at 21:13 -0600, Alex Williamson wrote:
> IOMMU groups themselves don't provide security, they're accessed by
> interfaces like VFIO, which provide the security. Given a brief look, I
> agree, this looks like a possible backdoor. The typical VFIO way to
> handle this would be t
On Wed, 2013-06-05 at 16:11 +1000, Alexey Kardashevskiy wrote:
> +long kvm_vm_ioctl_create_spapr_tce_iommu(struct kvm *kvm,
> + struct kvm_create_spapr_tce_iommu *args)
> +{
> + struct kvmppc_spapr_tce_table *tt = NULL;
> + struct iommu_group *grp;
> + struct iommu_t
On Wed, 2013-06-05 at 16:11 +1000, Alexey Kardashevskiy wrote:
> @@ -185,7 +186,31 @@ static unsigned long kvmppc_realmode_gpa_to_hpa(struct
> kvm_vcpu *vcpu,
> unsigned long hva, hpa, pg_size = 0, offset;
> unsigned long gfn = gpa >> PAGE_SHIFT;
> bool writing = gpa & TCE_PCI_W
> static pte_t kvmppc_lookup_pte(pgd_t *pgdir, unsigned long hva, bool writing,
> - unsigned long *pte_sizep)
> + unsigned long *pte_sizep, bool do_get_page)
> {
> pte_t *ptep;
> unsigned int shift = 0;
> @@ -135,6 +136,14 @@ static pte_t kvmppc
On Sun, 2013-06-16 at 14:26 +1000, Benjamin Herrenschmidt wrote:
> > +int realmode_get_page(struct page *page)
> > +{
> > + if (PageCompound(page))
> > + return -EAGAIN;
> > +
> > + get_page(page);
> > +
> > + return 0;
> &
> +#if defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_FLATMEM)
> +int realmode_get_page(struct page *page)
> +{
> + if (PageCompound(page))
> + return -EAGAIN;
> +
> + get_page(page);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(realmode_get_page);
> +
> +int realmode_pu
On Wed, 2013-06-05 at 16:11 +1000, Alexey Kardashevskiy wrote:
> This adds real mode handlers for the H_PUT_TCE_INDIRECT and
> H_STUFF_TCE hypercalls for QEMU emulated devices such as IBMVIO
> devices or emulated PCI. These calls allow adding multiple entries
> (up to 512) into the TCE table in on
:
powerpc: Fix missing/delayed calls to irq_work (2013-06-15 12:33:30 +1000)
Benjamin Herrenschmidt (1):
powerpc: Fix missing/delayed calls to irq_work
Michael Ellerman (1):
powerpc: Fix stack overflow crash in resume_kernel
On Fri, 2013-06-14 at 22:17 -0400, Steven Rostedt wrote:
> On Sat, 2013-06-15 at 12:02 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-06-14 at 17:06 -0400, Steven Rostedt wrote:
> > > I was pretty much able to reproduce this on my PA Semi PPC box. Funny
> > > t
On Fri, 2013-06-14 at 17:06 -0400, Steven Rostedt wrote:
> I was pretty much able to reproduce this on my PA Semi PPC box. Funny
> thing is, when I type on the console, it makes progress. Anyway, it
> seems that powerpc has an issue with irq_work(). I'll try to get some
> time either tonight or nex
On Fri, 2013-06-14 at 14:17 -0400, Waiman Long wrote:
>
> With some minor changes, the current patch can be modified to support
> debugging lock for 32-bit system. For 64-bit system, we can apply a
> similar concept for debugging lock with cmpxchg_double. However, for
> architecture that does n
1201 - 1300 of 2780 matches
Mail list logo
