On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> Amit,
>
> Ah, indeed. I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
> calls vp_request_intx() and sets up an interrupt callback. From
> there, when an interrupt occurs, the stack looks something like this:
>
> virtio_pci::
On Thu, Dec 15, 2011 at 9:35 PM, Benjamin Herrenschmidt
wrote:
>> This is 4/5 which is also waiting for your review.
>>
>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-October/093474.html
>
> Ah missed that. This is FSL specific, I'd need Kumar and/or Scott's ack
> for that one.
I believe
On Fri, 2011-12-16 at 03:29 +, McClintock Matthew-B29882 wrote:
> On Thu, Dec 15, 2011 at 9:12 PM, Benjamin Herrenschmidt
> wrote:
> > On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
> >> boot_cpuid and init_thread_info.cpu are redundant, just use the
> >> var that stays around lo
On Thu, Dec 15, 2011 at 9:12 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
>> boot_cpuid and init_thread_info.cpu are redundant, just use the
>> var that stays around longer and add a define to make boot_cpuid
>> point at the correct value
>>
>> b
On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
> boot_cpuid and init_thread_info.cpu are redundant, just use the
> var that stays around longer and add a define to make boot_cpuid
> point at the correct value
>
> boot_cpudid_phys is not needed and can completly go away from the
> SMP
于 2011年12月15日 04:15, Scott Wood 写道:
On 12/14/2011 02:41 AM, LiuShuo wrote:
于 2011年12月13日 10:46, LiuShuo 写道:
于 2011年12月13日 05:30, Scott Wood 写道:
On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
NAND chips come from the factory with bad block
Vineeth wrote:
> found p5020_ds.c in platforms/85xx;
> why is it a part of 85xx directory ? the core of P5020 is E5500 where the
> core of 85xx is e500;
>
e5500 is e500mc-64bit Power Architecture core.
> Do we have the processor initialization code (start.S, head.S) files, port
> available with
On Thu, Dec 15, 2011 at 11:08:08AM +0100, Jiri Kosina wrote:
> Tony,
>
> have you actually tested this one to work in the configuration you have
> been seeing it to fail?
>
> I don't seem to be able to find any use of '==' in other Kconfig files
> (and never used it myself), so I'd like to ha
Ill check through the commits.. Thank you for applying..
On Dec 15, 2011 9:46 AM, "Jiri Kosina" wrote:
> On Thu, 15 Dec 2011, Justin P. Mattock wrote:
>
> > what would be the status of these? should I resend/rebase to the current
> > etc?..
>
> Check linux-next, it's already there.
>
> >
> > On
On Thu, 15 Dec 2011, Justin P. Mattock wrote:
> what would be the status of these? should I resend/rebase to the current
> etc?..
Check linux-next, it's already there.
>
> On 11/21/2011 08:43 AM, Justin P. Mattock wrote:
> > From: "Justin P. Mattock"
> >
> > The patch below removes an extra se
On 12/14/2011 10:59 PM, Li Yang wrote:
> The limitation of the proposed bad block marker migration is that you
> need to make sure the migration is done and only done once. If it is
> done more than once, the factory bad block marker is totally messed
> up. It requires a complex mechanism to auto
Andy Fleming wrote:
> Why? Doesn't this just obfuscate things a little, while providing no
> immediate benefit?
I see code like this frequently:
bus = mdiobus_alloc();
if (bus == NULL)
return -ENOMEM;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (
On Dec 15, 2011, at 11:51 AM, Timur Tabi wrote:
> Augment mdiobus_alloc() to take a parameter indicating the number of extra
> bytes to allocate for private data. Almost all callers of mdiobus_alloc()
> separately allocate a private data structure. By allowing mdiobus_alloc()
> to allocate extr
what would be the status of these? should I resend/rebase to the current
etc?..
On 11/21/2011 08:43 AM, Justin P. Mattock wrote:
From: "Justin P. Mattock"
The patch below removes an extra semicolon.
Signed-off-by: Justin P. Mattock
CC: linuxppc-dev@lists.ozlabs.org
CC: Paul Mackerras
---
ar
Augment mdiobus_alloc() to take a parameter indicating the number of extra
bytes to allocate for private data. Almost all callers of mdiobus_alloc()
separately allocate a private data structure. By allowing mdiobus_alloc()
to allocate extra memory, the two allocations can be merged into one.
Thi
On 12/15/2011 02:08 AM, Jiri Kosina wrote:
> On Mon, 12 Dec 2011, Tony Breeds wrote:
>
>> On Mon, Dec 12, 2011 at 12:21:16AM +0100, Jiri Kosina wrote:
>>> On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote:
Hm. How about making it "depends on HID && POWER_SUPPLY"? I think that
would ne
On Thu, Dec 15, 2011 at 5:45 AM, Vineeth wrote:
>
> why is it a part of 85xx directory ? the core of P5020 is E5500 where the
> core of 85xx is e500;
e5500 is very similar to e500, so it's all part of the same family of cores.
--
Timur Tabi
Linux kernel developer at Freescale
__
This uses the host view of the hardware R (referenced) bit to speed
up kvm_age_hva() and kvm_test_age_hva(). Instead of removing all
the relevant HPTEs in kvm_age_hva(), we now just reset their R bits
if set. Also, kvm_test_age_hva() now scans the relevant HPTEs to
see if any of them have R set.
This adds implementations for the H_CLEAR_REF (test and clear reference
bit) and H_CLEAR_MOD (test and clear changed bit) hypercalls. These
hypercalls are not used by Linux guests at this stage, and these
implementations are only compile tested.
Signed-off-by: Paul Mackerras
---
arch/powerpc/kv
This reworks the implementations of the H_REMOVE and H_BULK_REMOVE
hcalls to make sure that we keep the HPTE locked and in the reverse-
mapping chain until we have finished invalidating it. Previously
we would remove it from the chain and unlock it before invalidating
it, leaving a tiny window whe
This allows both the guest and the host to use the referenced (R) and
changed (C) bits in the guest hashed page table. The guest has a view
of R and C that is maintained in the guest_rpte field of the revmap
entry for the HPTE, and the host has a view that is maintained in the
rmap entry for the a
This changes the implementation of kvm_vm_ioctl_get_dirty_log() for
Book3s HV guests to use the hardware C (changed) bits in the guest
hashed page table. Since this makes the implementation quite different
from the Book3s PR case, this moves the existing implementation from
book3s.c to book3s_pr.c
This series of patches builds on top of my previous series and
modifies the Book3S HV memory management code to use the hardware
reference and change bits in the guest hashed page table. This makes
kvm_age_hva() more efficient, lets us implement the dirty page
tracking properly (which in turn mean
found p5020_ds.c in platforms/85xx;
why is it a part of 85xx directory ? the core of P5020 is E5500 where the
core of 85xx is e500;
Do we have the processor initialization code (start.S, head.S) files, port
available with linux ?
On Wed, Dec 14, 2011 at 12:58 AM, Scott Wood wrote:
> On 12/12
Looks we have to go into 'restore' at last as I said previously. I send v2 based
on your all comments.
>> I assume it may not necessary to reorganize ret_from_except for *ppc32* .
>
> It might be cleaner but I can do that myself later.
>
I have this version but I'm not 100% sure if its as you e
We can't emulate stwu since that may corrupt current exception stack.
So we will have to do real store operation in the exception return code.
Firstly we'll allocate a trampoline exception frame below the kprobed
function stack and copy the current exception frame to the trampoline.
Then we can do
Changes from V1:
* use memcpy simply to withdraw copy_exc_stack
* add !(regs->msr & MSR_PR)) and
WARN_ON(test_thread_flag(TIF_EMULATE_STACK_STORE));
to make sure we're in goot path.
* move this migration process inside 'restore'
* clear TIF flag atomically
Tiejun Chen (3):
powerp
We need to add a new thread flag, TIF_EMULATE_STACK_STORE,
for emulating stack store operation while exiting exception.
Signed-off-by: Tiejun Chen
---
arch/powerpc/include/asm/thread_info.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/thread
We don't do the real store operation for kprobing 'stwu Rx,(y)R1'
since this may corrupt the exception frame, now we will do this
operation safely in exception return code after migrate current
exception frame below the kprobed function stack.
So we only update gpr[1] here and trigger a thread fla
On Mon, 12 Dec 2011, Tony Breeds wrote:
> On Mon, Dec 12, 2011 at 12:21:16AM +0100, Jiri Kosina wrote:
> > On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote:
> > >
> > > Hm. How about making it "depends on HID && POWER_SUPPLY"? I think that
> > > would needlessly disable it if HID is also modular,
The wrapper code which uncompresses the kernel in case of a 'ppc' boot
is by default loaded at 0x0040 and the kernel will be uncompressed
to fit the location 0-0x0040. But with dynamic relocations, the size
of the kernel may exceed 0x0040(4M). This would cause an overlap
of the uncompre
Now that we have relocatable kernel, supporting CRASH_DUMP only requires
turning the switches on for UP machines.
We don't have kexec support on 47x yet. Enabling SMP support would be done
as part of enabling the PPC_47x support.
Signed-off-by: Suzuki K. Poulose
Cc: Josh Boyer
Cc: Benjamin Her
The following patch adds relocatable kernel support - based on processing
of dynamic relocations - for PPC44x kernel.
We find the runtime address of _stext and relocate ourselves based
on the following calculation.
virtual_base = ALIGN(KERNELBASE,256M) +
MODULO(_st
The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
the kernel image to the same.
Currently the following relocation types are handled :
R_PPC_RELATIVE
R_PPC_ADDR16_LO
R_PPC_ADDR16_
DYNAMIC_MEMSTART(old RELOCATABLE) was restricted only to PPC_47x variants
of 44x. This patch enables DYNAMIC_MEMSTART for 440x based chipsets.
Signed-off-by: Suzuki K. Poulose
Cc: Josh Boyer
Cc: Kumar Gala
Cc: Benjamin Herrenschmidt
Cc: linux ppc dev
---
arch/powerpc/Kconfig |
We find the runtime address of _stext and relocate ourselves based
on the following calculation.
virtual_base = ALIGN(KERNELBASE,KERNEL_TLB_PIN_SIZE) +
MODULO(_stext.run,KERNEL_TLB_PIN_SIZE)
relocate() is called with the Effective Virtual Base Address (as
shown bel
The current implementation of CONFIG_RELOCATABLE in BookE is based
on mapping the page aligned kernel load address to KERNELBASE. This
approach however is not enough for platforms, where the TLB page size
is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used
currently in BookE to DYN
The following series implements:
* Generic framework for relocatable kernel on PPC32, based on processing
the dynamic relocation entries.
* Relocatable kernel support for 44x
* Kdump support for 44x. Doesn't support 47x yet, as the kexec
support is missing.
Changes from V4:
(Suggeste
Am 15.12.2011 00:58, schrieb Benjamin Herrenschmidt:
> We rename the mach64 hack to "simple" since that's also applicable
> to anything using VGA-style DAC IO ports (set to 8-bit DAC) and we
> use it for qemu vga.
>
> Note that this is keyed on a device-tree "compatible" property that
> is current
On Thu, 2011-12-15 at 08:49 +0100, Andreas Färber wrote:
> Am 15.12.2011 00:58, schrieb Benjamin Herrenschmidt:
> > We rename the mach64 hack to "simple" since that's also applicable
> > to anything using VGA-style DAC IO ports (set to 8-bit DAC) and we
> > use it for qemu vga.
> >
> > Note that t
40 matches
Mail list logo
