* Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
From: Suzuki Poulose @ 2011-11-09 8:42 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Nathan Miller, Josh Poimboeuf, Dave Hansen, Alan Modra,
Scott Wood, Paul Mackerras, linuxppc-dev
In-Reply-To: <20111109120303.51ac3b1b@suzukikp.in.ibm.com>
On 11/09/11 12:03, Suzuki Poulose wrote:
> On Tue, 08 Nov 2011 10:19:05 -0600
> Josh Poimboeuf<jpoimboe@linux.vnet.ibm.com> wrote:
>
>> On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
>>> What I was suggesting is, instead of flushing the cache in
>>> relocate(), lets do it like:
>>>
>>> for e.g, on 440x, (in head_44x.S :)
>>>
>>> #ifdef CONFIG_RELOCATABLE
>>> ...
>>> bl relocate
>>>
>>> #Flush the d-cache and invalidate the i-cache here
>>> #endif
>>>
>>>
>>> This would let the different platforms do the the cache
>>> invalidation in their own way.
>>>
>>> Btw, I didn't find an instruction to flush the entire d-cache in
>>> PPC440 manual. We have instructions to flush only a block
>>> corresponding to an address.
>>>
>>> However, we have 'iccci' which would invalidate the entire i-cache
>>> which, which I think is better than 80,000 i-cache invalidates.
>>
>> In misc_32.S there are already some platform-independent cache
>> management functions. If we use those, then relocate() could simply
>> call them. Then the different platforms calling relocate() wouldn't
>> have to worry about flushing/invalidating caches.
>>
>> For example, there's a clean_dcache_range() function. Given any range
>> twice the size of the d-cache, it should flush the entire d-cache.
>> But the only drawback is that it would require the caller to know the
>> size of the d-cache.
>>
>> Instead, I think it would be preferable to create a new clean_dcache()
>> (or clean_dcache_all()?) function in misc_32.S, which could call
>> clean_dcache_range() with the appropriate args for flushing the entire
>> d-cache. relocate() could then call the platform-independent
>> clean_dcache().
>>
>
>
> How about using clean_dcache_range() to flush the range runtime
> address range [ _stext, _end ] ? That would flush the entire
> instructions.
>
>
>> For i-cache invalidation there's already the (incorrectly named?)
>> flush_instruction_cache(). It uses the appropriate platform-specific
>> methods (e.g. iccci for 44x) to invalidate the entire i-cache.
>
> Agreed. The only thing that worries me is the use of KERNELBASE in the
> flush_instruction_cache() for CONFIG_4xx. Can we safely assume all 4xx
> implementations ignore the arguments passed to iccci ?
>>
>> Suzuki, if you agree with this direction, I could work up a new patch
>> if needed.
>>
>
> I have the following (untested) patch which uses clean_dcache_range()
> and flush_instruction_cache(): I will send the next version soon
> with those changes and the DYNAMIC_MEMSTART config for oldstyle
> relocatoin, if every one agrees to this.
>
>
> diff --git a/arch/powerpc/kernel/reloc_32.S
> b/arch/powerpc/kernel/reloc_32.S index 045d61e..cce0510 100644
> --- a/arch/powerpc/kernel/reloc_32.S
> +++ b/arch/powerpc/kernel/reloc_32.S
> @@ -33,10 +33,9 @@ R_PPC_RELATIVE = 22
>
> _GLOBAL(relocate)
>
> - mflr r0
> + mflr r14 /* Save our LR */
> bl 0f /* Find our current runtime
> address */ 0: mflr r12 /* Make it
> accessible */
> - mtlr r0
>
> lwz r11, (p_dyn - 0b)(r12)
> add r11, r11, r12 /* runtime address of .dynamic
> section */ @@ -87,18 +86,19 @@ eodyn: /*
> End of Dyn Table scan */
> * Work out the current offset from the link time address
> of .rela
> * section.
> * cur_offset[r7] = rela.run[r9] - rela.link [r7]
> - * _stext.link[r10] = _stext.run[r10] - cur_offset[r7]
> - * final_offset[r3] = _stext.final[r3] - _stext.link[r10]
> + * _stext.link[r12] = _stext.run[r10] - cur_offset[r7]
> + * final_offset[r3] = _stext.final[r3] - _stext.link[r12]
> */
> subf r7, r7, r9 /* cur_offset */
> - subf r10, r7, r10
> - subf r3, r10, r3 /* final_offset */
> + subf r12, r7, r10
> + subf r3, r12, r3 /* final_offset */
>
> subf r8, r6, r8 /* relaz -= relaent */
> /*
> * Scan through the .rela table and process each entry
> * r9 - points to the current .rela table entry
> * r13 - points to the symbol table
> + * r10 - holds the runtime address of _stext
> */
>
> /*
> @@ -180,12 +180,23 @@ store_half:
>
> nxtrela:
> cmpwi r8, 0 /* relasz = 0 ? */
> - ble done
> + ble flush
> add r9, r9, r6 /* move to next entry in
> the .rela table */ subf r8, r6, r8 /* relasz -= relaent */
> b applyrela
>
> -done: blr
> + /* Flush the d-cache'd instructions */
> +flush:
> + mr r3, r10
> + lis r4, (_end - _stext)@h
> + ori r4, r4, (_end - _stext)@l
Err ! This doesn't compile :
arch/powerpc/kernel/reloc_32.S: Assembler messages:
arch/powerpc/kernel/reloc_32.S:191: Error: can't resolve `_end' {*UND* section} - `_stext' {*UND* section}
I will fix it, but the idea remains the same.
Thanks
Suzuki
^ permalink raw reply
* RE: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
From: Li Yang-R58472 @ 2011-11-09 8:31 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Zhao Chenhui-B35336
In-Reply-To: <4EB997C5.60105@freescale.com>
>-----Original Message-----
>From: Wood Scott-B07421
>Sent: Wednesday, November 09, 2011 4:58 AM
>To: Li Yang-R58472
>Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
>
>On 11/08/2011 04:05 AM, Li Yang-R58472 wrote:
>>> Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
>>>
>>> On 11/04/2011 07:31 AM, Zhao Chenhui wrote:
>>>> +static int is_corenet;
>>>> +static void __cpuinit smp_85xx_setup_cpu(int cpu_nr);
>>>> +
>>>> +#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC32)
>>>
>>> Why PPC32?
>>
>> Not sure if it is the same for e5500. E5500 support will be verified
>later.
>
>It's better to have 64-bit silently do nothing here?
>
>>>> + flush_disable_L1();
>>>
>>> You'll also need to take down L2 on e500mc.
>>
>> Right. E500mc support is beyond this patch series. We will work on it
>after the e500v2 support is finalized.
>
>I saw some support with "is_corenet"... If we don't support e500mc, make
>sure the code doesn't try to run on e500mc.
The is_corenet code is just a start of the e500mc support and is far from c=
omplete.
>
>This isn't an e500v2-only BSP you're putting the code into. :-)
Yes, I know. But it will take quite some time to perfect the support for d=
ifferent type of cores. I'd like to make the effort into stages. We want =
to push the e500v2 support in first and add support to newer cores later so=
that we don't need to re-spin the patches again and again. And the upstre=
am kernel can get the PM functionality at least for e500v2 earlier. Anyway=
, we need to update the title of the patch to be more specific on e500v2.
>
>>>> + tmp =3D 0;
>>>> + if (cpu_has_feature(CPU_FTR_CAN_NAP))
>>>> + tmp =3D HID0_NAP;
>>>> + else if (cpu_has_feature(CPU_FTR_CAN_DOZE))
>>>> + tmp =3D HID0_DOZE;
>>>
>>> Those FTR bits are for what we can do in idle, and can be cleared if
>>> the user sets CONFIG_BDI_SWITCH.
>>
>> It is powersave_nap variable shows what we can do in idle.
>
>No, that shows what the user wants to do in idle.
>
>> I think it's correct to use the CPU_FTR_CAN_* macro as CPU capability.
>
>This is 85xx-specific code. We always can, and want to, nap here (though
>the way we enter nap will be different on e500mc and up) -- even if it's
>broken to use it for idle (such as on p4080, which would miss doorbells as
>wake events).
Ok. Will stick to Nap.
>
>>>> +static void __cpuinit smp_85xx_reset_core(int nr) {
>>>> + __iomem u32 *vaddr, *pir_vaddr;
>>>> + u32 val, cpu_mask;
>>>> +
>>>> + /* If CoreNet platform, use BRR as release register. */
>>>> + if (is_corenet) {
>>>> + cpu_mask =3D 1 << nr;
>>>> + vaddr =3D ioremap(get_immrbase() + MPC85xx_BRR_OFF, 4);
>>>> + } else {
>>>> + cpu_mask =3D 1 << (24 + nr);
>>>> + vaddr =3D ioremap(get_immrbase() + MPC85xx_ECM_EEBPCR_OFF, 4);
>>>> + }
>>>
>>> Please use the device tree node, not get_immrbase().
>>
>> The get_immrbase() implementation uses the device tree node.
>
>I mean the guts node. get_immrbase() should be avoided where possible.
Ok. I got your point to use offset from guts.
>
>Also, some people might care about latency to enter/exit deep sleep.
>Searching through the device tree at this point (rather than on init)
>slows that down.
Actually the get_immrbase() is smarter than you thought. :) It only search =
the device tree on first call and returns the saved value on follow up call=
s.
>
>>>> +static int __cpuinit smp_85xx_map_bootpg(u32 page) {
>>>> + __iomem u32 *bootpg_ptr;
>>>> + u32 bptr;
>>>> +
>>>> + /* Get the BPTR */
>>>> + bootpg_ptr =3D ioremap(get_immrbase() + MPC85xx_BPTR_OFF, 4);
>>>> +
>>>> + /* Set the BPTR to the secondary boot page */
>>>> + bptr =3D MPC85xx_BPTR_EN | (page & MPC85xx_BPTR_BOOT_PAGE_MASK);
>>>> + out_be32(bootpg_ptr, bptr);
>>>> +
>>>> + iounmap(bootpg_ptr);
>>>> + return 0;
>>>> +}
>>>
>>> Shouldn't the boot page already be set by U-Boot?
>>
>> The register should be lost after a deep sleep. Better to do it again.
>
>How can it be lost after a deep sleep if we're relying on it to hold our
>wakeup code?
In order to wake up from deep sleep, the boot page has been set to the deep=
sleep restoration function. We need to set it back to the bootpage from u=
-boot.
>
>It's not "better to do it again" if we're making a bad assumption about
>the code and the table being in the same page.
Currently we are reusing the whole boot page including the spin-table from =
u-boot. Are you suggesting to move just the boot page to kernel?
>
>>>> local_irq_save(flags);
>>>>
>>>> - out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
>>>> + out_be32(&epapr->pir, hw_cpu);
>>>> #ifdef CONFIG_PPC32
>>>> - out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
>>>> +#ifdef CONFIG_HOTPLUG_CPU
>>>> + if (system_state =3D=3D SYSTEM_RUNNING) {
>>>> + out_be32(&epapr->addr_l, 0);
>>>> + smp_85xx_map_bootpg((u32)(*cpu_rel_addr >> PAGE_SHIFT));
>>>
>>> Why is this inside PPC32?
>>
>> Not tested on 64-bit yet. Might require a different implementation on
>PPC64.
>
>Please make a reasonable effort to do things in a way that works on both.
>It shouldn't be a big deal to test that it doesn't break booting on p5020.
Will do. But in stages.
>
>>>> if (!ioremappable)
>>>> - flush_dcache_range((ulong)bptr_vaddr,
>>>> - (ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
>>>> + flush_dcache_range((ulong)epapr,
>>>> + (ulong)epapr + sizeof(struct epapr_entry));
>>>
>>> We don't wait for the core to come up on 64-bit?
>>
>> Not sure about it. But at least the normal boot up should be tested on
>P5020, right?
>
>Well, that's a special case in that it only has one secondary. :-)
>
>Or we could be getting lucky with timing. It's not a new issue with this
>patch, it just looks odd.
We will look into it more when doing the e5500 support.
- Leo
^ permalink raw reply
* Re: [PATCH v3 3/3] Use separate struct console structure for each hvc_console.
From: Michael Ellerman @ 2011-11-09 8:05 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, Greg Kroah-Hartman, Konrad Rzeszutek Wilk,
Rusty Russell, linux-kernel, virtualization, xen-devel,
Anton Blanchard, Amit Shah, Mike Waychison, ppc-dev,
Eric Northrup
In-Reply-To: <20111108214509.28884.98169.stgit@miche.sea.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]
On Tue, 2011-11-08 at 13:45 -0800, Miche Baker-Harvey wrote:
> It is possible to make any virtio_console port be a console
> by sending VIRITO_CONSOLE_CONSOLE_PORT. But hvc_alloc was
> using a single struct console hvc_console, which contains
> both an index and flags which are per-port.
>
> This adds a separate struct console for each virtio_console
> that is CONSOLE_PORT.
Hi Miche,
I'm testing this on powerpc and unfortunately it's working a little _too
well_. I end up with two struct consoles registered and so I get every
line of output twice :)
The problem is that we're registering two struct consoles. The first
obviously is hvc_console, either in hvc_console_init(), or in my case
from hvc_instantiate().
Then we register the allocated one in hvc_alloc(). But because they both
point back to the same hardware you get duplicate output.
We _do_ want to register a console early, in either/both
hvc_console_init() and hvc_instantiate(), because we want to have
console during boot prior to when hvc_alloc() gets called.
I think maybe we should be checking in hvc_alloc() whether we already
have hvc_console associated with the vtermno and if so we use
hvc_console instead of allocating a new one.
Patch below to do that, and works for me, but it's a bit of a hack,
there must be a better solution.
Finally I'm not sure how your patch affects the code in hvc_poll() which
checks hvc_console.index to do the SYSRQ hack.
cheers
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index fff35da..b249195 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -815,13 +815,15 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
kref_init(&hp->kref);
INIT_WORK(&hp->tty_resize, hvc_set_winsz);
- /*
- * Make each console its own struct console.
- */
- cp = kmemdup(&hvc_console, sizeof(*cp), GFP_KERNEL);
- if (!cp) {
- kfree(hp);
- return ERR_PTR(-ENOMEM);
+
+ if (hvc_console.index >= 0 && vtermnos[hvc_console.index] == hp->vtermno)
+ cp = &hvc_console;
+ else {
+ cp = kmemdup(&hvc_console, sizeof(*cp), GFP_KERNEL);
+ if (!cp) {
+ kfree(hp);
+ return ERR_PTR(-ENOMEM);
+ }
}
hp->hvc_console = cp;
@@ -850,7 +852,9 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
list_add_tail(&(hp->next), &hvc_structs);
spin_unlock(&hvc_structs_lock);
- register_console(cp);
+
+ if (cp != &hvc_console)
+ register_console(cp);
return hp;
}
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH] memory hotplug: Refuse to add unaligned memory regions
From: Chen Gong @ 2011-11-09 7:28 UTC (permalink / raw)
To: Anton Blanchard; +Cc: gregkh, linuxppc-dev, linux-kernel
In-Reply-To: <20110915062615.782bc4df@kryten>
于 2011/9/15 4:26, Anton Blanchard 写道:
>
> The sysfs memory probe interface allows unaligned regions
> to be added:
>
> # echo 0xffffff> /sys/devices/system/memory/probe
>
> # cat /proc/iomem
> 00ffffff-01fffffe : System RAM
> 01ffffff-02fffffe : System RAM
> 02ffffff-03fffffe : System RAM
> 03ffffff-04fffffe : System RAM
> 04ffffff-05fffffe : System RAM
>
> Return -EINVAL instead of creating these bad regions.
>
> Signed-off-by: Anton Blanchard<anton@samba.org>
> ---
>
> Index: linux-build/drivers/base/memory.c
> ===================================================================
> --- linux-build.orig/drivers/base/memory.c 2011-08-11 08:25:55.005941391 +1000
> +++ linux-build/drivers/base/memory.c 2011-08-11 08:28:27.938580440 +1000
> @@ -380,9 +380,13 @@ memory_probe_store(struct class *class,
> u64 phys_addr;
> int nid;
> int i, ret;
> + unsigned long pages_per_block = PAGES_PER_SECTION * sections_per_block;
>
> phys_addr = simple_strtoull(buf, NULL, 0);
>
> + if (phys_addr& ((pages_per_block<< PAGE_SHIFT) - 1))
> + return -EINVAL;
> +
> for (i = 0; i< sections_per_block; i++) {
> nid = memory_add_physaddr_to_nid(phys_addr);
> ret = add_memory(nid, phys_addr,
> --
what platform doese it affect? PowerPC or else?
As I know, on x86 platform it should not use this interface: *probe*,
instead of acpi_hotplug_xxx. But PowerPC is RISC so how can you add
such weird address for it? Maybe it is because PowerPC uses 16M as
one section size and you assign a wrong address to it intentionally.
The final result is as you show, isn't it?
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Michael Ellerman @ 2011-11-09 7:24 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, Greg Kroah-Hartman, Konrad Rzeszutek Wilk,
Rusty Russell, linux-kernel, virtualization, xen-devel,
Anton Blanchard, Amit Shah, Mike Waychison, ppc-dev,
Eric Northrup
In-Reply-To: <20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
On Tue, 2011-11-08 at 13:45 -0800, Miche Baker-Harvey wrote:
> hvc_init() must only be called once, and no thread should continue with hvc_alloc()
> until after initialization is complete. The original code does not enforce either
> of these requirements. A new mutex limits entry to hvc_init() to a single thread,
> and blocks all later comers until it has completed.
>
> This patch fixes multiple crash symptoms.
Hi Miche,
A few nit-picky comments below ..
> @@ -84,6 +85,10 @@ static LIST_HEAD(hvc_structs);
> * list traversal.
> */
> static DEFINE_SPINLOCK(hvc_structs_lock);
> +/*
> + * only one task does allocation at a time.
> + */
> +static DEFINE_MUTEX(hvc_ports_mutex);
The comment is wrong, isn't it? Only one task does _init_ at a time.
Once the driver is initialised allocs can run concurrently.
So shouldn't it be called hvc_init_mutex ?
> @@ -825,11 +830,15 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
> int i;
>
> /* We wait until a driver actually comes along */
> + mutex_lock(&hvc_ports_mutex);
> if (!hvc_driver) {
> int err = hvc_init();
> - if (err)
> + if (err) {
> + mutex_unlock(&hvc_ports_mutex);
> return ERR_PTR(err);
> + }
> }
> + mutex_unlock(&hvc_ports_mutex);
>
> hp = kzalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size,
> GFP_KERNEL);
It'd be cleaner I think to do all the locking in hvc_init(). That's safe
as long as you recheck !hvc_driver in hvc_init() with the lock held.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Export PIR data through sysfs
From: Michael Ellerman @ 2011-11-09 6:51 UTC (permalink / raw)
To: Scott Wood; +Cc: mahesh, linuxppc-dev, Anton Blanchard
In-Reply-To: <4EB96002.5030605@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Tue, 2011-11-08 at 10:59 -0600, Scott Wood wrote:
> On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> >> What use does userspace have for this? If you want to return the
> >> currently executing CPU (which unless you're pinned could change as soon
> >> as the value is read...), why not just return smp_processor_id() or
> >> hard_smp_processor_id()?
> >
> > Its not just the current cpu. Decoding PIR can tell you the core id,
> > thread id in case of SMT, and this information can be used by userspace
> > apps to set affinities, etc.
>
> Wouldn't it make more sense to expose the thread to core mappings in a
> general way, not tied to hardware or what thread we're currently running on?
AFAIK that is already available in /sys/devices/system/cpu/cpuX/topology
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
From: Suzuki Poulose @ 2011-11-09 6:33 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Nathan Miller, Josh Poimboeuf, Dave Hansen, Alan Modra,
Scott Wood, Paul Mackerras, linuxppc-dev
In-Reply-To: <1320769145.5273.26.camel@treble>
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf <jpoimboe@linux.vnet.ibm.com> wrote:
> On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
> > What I was suggesting is, instead of flushing the cache in
> > relocate(), lets do it like:
> >
> > for e.g, on 440x, (in head_44x.S :)
> >
> > #ifdef CONFIG_RELOCATABLE
> > ...
> > bl relocate
> >
> > #Flush the d-cache and invalidate the i-cache here
> > #endif
> >
> >
> > This would let the different platforms do the the cache
> > invalidation in their own way.
> >
> > Btw, I didn't find an instruction to flush the entire d-cache in
> > PPC440 manual. We have instructions to flush only a block
> > corresponding to an address.
> >
> > However, we have 'iccci' which would invalidate the entire i-cache
> > which, which I think is better than 80,000 i-cache invalidates.
>
> In misc_32.S there are already some platform-independent cache
> management functions. If we use those, then relocate() could simply
> call them. Then the different platforms calling relocate() wouldn't
> have to worry about flushing/invalidating caches.
>
> For example, there's a clean_dcache_range() function. Given any range
> twice the size of the d-cache, it should flush the entire d-cache.
> But the only drawback is that it would require the caller to know the
> size of the d-cache.
>
> Instead, I think it would be preferable to create a new clean_dcache()
> (or clean_dcache_all()?) function in misc_32.S, which could call
> clean_dcache_range() with the appropriate args for flushing the entire
> d-cache. relocate() could then call the platform-independent
> clean_dcache().
>
How about using clean_dcache_range() to flush the range runtime
address range [ _stext, _end ] ? That would flush the entire
instructions.
> For i-cache invalidation there's already the (incorrectly named?)
> flush_instruction_cache(). It uses the appropriate platform-specific
> methods (e.g. iccci for 44x) to invalidate the entire i-cache.
Agreed. The only thing that worries me is the use of KERNELBASE in the
flush_instruction_cache() for CONFIG_4xx. Can we safely assume all 4xx
implementations ignore the arguments passed to iccci ?
>
> Suzuki, if you agree with this direction, I could work up a new patch
> if needed.
>
I have the following (untested) patch which uses clean_dcache_range()
and flush_instruction_cache(): I will send the next version soon
with those changes and the DYNAMIC_MEMSTART config for oldstyle
relocatoin, if every one agrees to this.
diff --git a/arch/powerpc/kernel/reloc_32.S
b/arch/powerpc/kernel/reloc_32.S index 045d61e..cce0510 100644
--- a/arch/powerpc/kernel/reloc_32.S
+++ b/arch/powerpc/kernel/reloc_32.S
@@ -33,10 +33,9 @@ R_PPC_RELATIVE = 22
_GLOBAL(relocate)
- mflr r0
+ mflr r14 /* Save our LR */
bl 0f /* Find our current runtime
address */ 0: mflr r12 /* Make it
accessible */
- mtlr r0
lwz r11, (p_dyn - 0b)(r12)
add r11, r11, r12 /* runtime address of .dynamic
section */ @@ -87,18 +86,19 @@ eodyn: /*
End of Dyn Table scan */
* Work out the current offset from the link time address
of .rela
* section.
* cur_offset[r7] = rela.run[r9] - rela.link [r7]
- * _stext.link[r10] = _stext.run[r10] - cur_offset[r7]
- * final_offset[r3] = _stext.final[r3] - _stext.link[r10]
+ * _stext.link[r12] = _stext.run[r10] - cur_offset[r7]
+ * final_offset[r3] = _stext.final[r3] - _stext.link[r12]
*/
subf r7, r7, r9 /* cur_offset */
- subf r10, r7, r10
- subf r3, r10, r3 /* final_offset */
+ subf r12, r7, r10
+ subf r3, r12, r3 /* final_offset */
subf r8, r6, r8 /* relaz -= relaent */
/*
* Scan through the .rela table and process each entry
* r9 - points to the current .rela table entry
* r13 - points to the symbol table
+ * r10 - holds the runtime address of _stext
*/
/*
@@ -180,12 +180,23 @@ store_half:
nxtrela:
cmpwi r8, 0 /* relasz = 0 ? */
- ble done
+ ble flush
add r9, r9, r6 /* move to next entry in
the .rela table */ subf r8, r6, r8 /* relasz -= relaent */
b applyrela
-done: blr
+ /* Flush the d-cache'd instructions */
+flush:
+ mr r3, r10
+ lis r4, (_end - _stext)@h
+ ori r4, r4, (_end - _stext)@l
+ add r4, r3, r4
+ bl clean_dcache_range
+ /* Invalidate the i-cache */
+ bl flush_instruction_cache
+done:
+ mtlr r14
+ blr
p_dyn: .long __dynamic_start - 0b
Thanks
Suzuki
^ permalink raw reply
* Re: [PATCH] powerpc: Export PIR data through sysfs
From: Ananth N Mavinakayanahalli @ 2011-11-09 4:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Anton Blanchard, mahesh
In-Reply-To: <4EB96002.5030605@freescale.com>
On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> >> What use does userspace have for this? If you want to return the
> >> currently executing CPU (which unless you're pinned could change as soon
> >> as the value is read...), why not just return smp_processor_id() or
> >> hard_smp_processor_id()?
> >
> > Its not just the current cpu. Decoding PIR can tell you the core id,
> > thread id in case of SMT, and this information can be used by userspace
> > apps to set affinities, etc.
>
> Wouldn't it make more sense to expose the thread to core mappings in a
> general way, not tied to hardware or what thread we're currently running on?
AFAIK, the information encoding in PIR is platform dependent. There is
no general way to expose this information unless you want have a
per-platform ifdef. Even then, I am not sure if that information will
generally be available or provided.
> What's the use case for knowing this information only about the current
> thread (or rather the state the current thread was in a few moments ago)?
Its not information about the thread but about the cpu. Unless you have
a shared LPAR environment, the data will be consistent and can be used
by applications with knowledge of the platform.
> > +#if defined(CONFIG_SMP) && defined(SPRN_PIR)
> > +SYSFS_PMCSETUP(pir, SPRN_PIR);
> > +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
> > +#endif
>
> This only helps on architectures such as 8xx where you can't build as
> SMP -- and I don't think #ifdef SPRN_PIR excludes any builds.
>
> It doesn't help on chips like 750 or e300 where you can run a normal 6xx
> SMP build, you just won't have multiple CPUs, and thus won't run things
> like the secondary entry code.
Ugh! Booke builds seem to be fun :-)
I think this calls for a CPU_FTR_PIR. What do you suggest?
Ananth
^ permalink raw reply
* Re: [PATCH 0/2] PS3 fixes for 3.2
From: Benjamin Herrenschmidt @ 2011-11-09 2:33 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, linuxppc-dev, Andre Heider
In-Reply-To: <E1RNxlF-0000wf-Rh@casper.infradead.org>
On Tue, 2011-11-08 at 17:51 -0800, Geoff Levand wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git
Thanks. Will do after he pulls my current batch.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 2/2] powerpc/ps3: Fix SMP lockdep boot warning
From: Geoff Levand @ 2011-11-08 22:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: cbe-oss-dev, linuxppc-dev, Andre Heider
Move the PS3 IPI message setup from ps3_smp_setup_cpu() to ps3_smp_probe().
Fixes startup warnings like these:
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:2649
Modules linked in:
...
---[ end trace 31fd0ba7d8756001 ]---
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/powerpc/platforms/ps3/smp.c | 64 +++++++++++++++++++-------------------
1 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
index f609345..efc1cd8 100644
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -59,48 +59,49 @@ static void ps3_smp_message_pass(int cpu, int msg)
static int ps3_smp_probe(void)
{
- return 2;
-}
+ int cpu;
-static void __init ps3_smp_setup_cpu(int cpu)
-{
- int result;
- unsigned int *virqs = per_cpu(ps3_ipi_virqs, cpu);
- int i;
+ for (cpu = 0; cpu < 2; cpu++) {
+ int result;
+ unsigned int *virqs = per_cpu(ps3_ipi_virqs, cpu);
+ int i;
- DBG(" -> %s:%d: (%d)\n", __func__, __LINE__, cpu);
+ DBG(" -> %s:%d: (%d)\n", __func__, __LINE__, cpu);
- /*
- * Check assumptions on ps3_ipi_virqs[] indexing. If this
- * check fails, then a different mapping of PPC_MSG_
- * to index needs to be setup.
- */
+ /*
+ * Check assumptions on ps3_ipi_virqs[] indexing. If this
+ * check fails, then a different mapping of PPC_MSG_
+ * to index needs to be setup.
+ */
- BUILD_BUG_ON(PPC_MSG_CALL_FUNCTION != 0);
- BUILD_BUG_ON(PPC_MSG_RESCHEDULE != 1);
- BUILD_BUG_ON(PPC_MSG_CALL_FUNC_SINGLE != 2);
- BUILD_BUG_ON(PPC_MSG_DEBUGGER_BREAK != 3);
+ BUILD_BUG_ON(PPC_MSG_CALL_FUNCTION != 0);
+ BUILD_BUG_ON(PPC_MSG_RESCHEDULE != 1);
+ BUILD_BUG_ON(PPC_MSG_CALL_FUNC_SINGLE != 2);
+ BUILD_BUG_ON(PPC_MSG_DEBUGGER_BREAK != 3);
- for (i = 0; i < MSG_COUNT; i++) {
- result = ps3_event_receive_port_setup(cpu, &virqs[i]);
+ for (i = 0; i < MSG_COUNT; i++) {
+ result = ps3_event_receive_port_setup(cpu, &virqs[i]);
- if (result)
- continue;
+ if (result)
+ continue;
- DBG("%s:%d: (%d, %d) => virq %u\n",
- __func__, __LINE__, cpu, i, virqs[i]);
+ DBG("%s:%d: (%d, %d) => virq %u\n",
+ __func__, __LINE__, cpu, i, virqs[i]);
- result = smp_request_message_ipi(virqs[i], i);
+ result = smp_request_message_ipi(virqs[i], i);
- if (result)
- virqs[i] = NO_IRQ;
- else
- ps3_register_ipi_irq(cpu, virqs[i]);
- }
+ if (result)
+ virqs[i] = NO_IRQ;
+ else
+ ps3_register_ipi_irq(cpu, virqs[i]);
+ }
- ps3_register_ipi_debug_brk(cpu, virqs[PPC_MSG_DEBUGGER_BREAK]);
+ ps3_register_ipi_debug_brk(cpu, virqs[PPC_MSG_DEBUGGER_BREAK]);
- DBG(" <- %s:%d: (%d)\n", __func__, __LINE__, cpu);
+ DBG(" <- %s:%d: (%d)\n", __func__, __LINE__, cpu);
+ }
+
+ return 2;
}
void ps3_smp_cleanup_cpu(int cpu)
@@ -123,7 +124,6 @@ static struct smp_ops_t ps3_smp_ops = {
.probe = ps3_smp_probe,
.message_pass = ps3_smp_message_pass,
.kick_cpu = smp_generic_kick_cpu,
- .setup_cpu = ps3_smp_setup_cpu,
};
void smp_init_ps3(void)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/ps3: Fix lost SMP IPIs
From: Geoff Levand @ 2011-11-08 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: cbe-oss-dev, linuxppc-dev, Andre Heider, Peter Zijlstra
Fixes the PS3 bootup hang introduced in 3.0-rc1 by:
commit 317f394160e9beb97d19a84c39b7e5eb3d7815a
sched: Move the second half of ttwu() to the remote cpu
Move the PS3's LV1 EOI call lv1_end_of_interrupt_ext() from ps3_chip_eoi()
to ps3_get_irq() for IPI messages.
If lv1_send_event_locally() is called between a previous call to
lv1_send_event_locally() and the coresponding call to
lv1_end_of_interrupt_ext() the second event will not be delivered to the
target cpu.
The PS3's SMP IPIs are implemented using lv1_send_event_locally(), so if two
IPI messages of the same type are sent to the same target in a relatively
short period of time the second IPI event can become lost when
lv1_end_of_interrupt_ext() is called from ps3_chip_eoi().
CC: stable@kernel.org
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/powerpc/platforms/ps3/interrupt.c | 23 ++++++++++++++++++++++-
arch/powerpc/platforms/ps3/platform.h | 1 +
arch/powerpc/platforms/ps3/smp.c | 2 ++
3 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
index 404bc52..1d6f4f4 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -88,6 +88,7 @@ struct ps3_private {
struct ps3_bmp bmp __attribute__ ((aligned (PS3_BMP_MINALIGN)));
u64 ppe_id;
u64 thread_id;
+ unsigned long ipi_mask;
};
static DEFINE_PER_CPU(struct ps3_private, ps3_private);
@@ -144,7 +145,11 @@ static void ps3_chip_unmask(struct irq_data *d)
static void ps3_chip_eoi(struct irq_data *d)
{
const struct ps3_private *pd = irq_data_get_irq_chip_data(d);
- lv1_end_of_interrupt_ext(pd->ppe_id, pd->thread_id, d->irq);
+
+ /* non-IPIs are EOIed here. */
+
+ if (!test_bit(63 - d->irq, &pd->ipi_mask))
+ lv1_end_of_interrupt_ext(pd->ppe_id, pd->thread_id, d->irq);
}
/**
@@ -691,6 +696,16 @@ void __init ps3_register_ipi_debug_brk(unsigned int cpu, unsigned int virq)
cpu, virq, pd->bmp.ipi_debug_brk_mask);
}
+void __init ps3_register_ipi_irq(unsigned int cpu, unsigned int virq)
+{
+ struct ps3_private *pd = &per_cpu(ps3_private, cpu);
+
+ set_bit(63 - virq, &pd->ipi_mask);
+
+ DBG("%s:%d: cpu %u, virq %u, ipi_mask %lxh\n", __func__, __LINE__,
+ cpu, virq, pd->ipi_mask);
+}
+
static unsigned int ps3_get_irq(void)
{
struct ps3_private *pd = &__get_cpu_var(ps3_private);
@@ -720,6 +735,12 @@ static unsigned int ps3_get_irq(void)
BUG();
}
#endif
+
+ /* IPIs are EOIed here. */
+
+ if (test_bit(63 - plug, &pd->ipi_mask))
+ lv1_end_of_interrupt_ext(pd->ppe_id, pd->thread_id, plug);
+
return plug;
}
diff --git a/arch/powerpc/platforms/ps3/platform.h b/arch/powerpc/platforms/ps3/platform.h
index 9a196a8..1a633ed 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -43,6 +43,7 @@ void ps3_mm_shutdown(void);
void ps3_init_IRQ(void);
void ps3_shutdown_IRQ(int cpu);
void __init ps3_register_ipi_debug_brk(unsigned int cpu, unsigned int virq);
+void __init ps3_register_ipi_irq(unsigned int cpu, unsigned int virq);
/* smp */
diff --git a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
index 4c44794..f609345 100644
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -94,6 +94,8 @@ static void __init ps3_smp_setup_cpu(int cpu)
if (result)
virqs[i] = NO_IRQ;
+ else
+ ps3_register_ipi_irq(cpu, virqs[i]);
}
ps3_register_ipi_debug_brk(cpu, virqs[PPC_MSG_DEBUGGER_BREAK]);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/2] PS3 fixes for 3.2
From: Geoff Levand @ 2011-11-09 1:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: cbe-oss-dev, linuxppc-dev, Andre Heider
Ben,
Here are two fixes for PS3. Please apply for 3.2.
-Geoff
The following changes
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git for-powerpc
Geoff Levand (2):
powerpc/ps3: Fix lost SMP IPIs
powerpc/ps3: Fix SMP lockdep boot warning
arch/powerpc/platforms/ps3/interrupt.c | 23 +++++++++++-
arch/powerpc/platforms/ps3/platform.h | 1 +
arch/powerpc/platforms/ps3/smp.c | 62 ++++++++++++++++---------------
3 files changed, 55 insertions(+), 31 deletions(-)
^ permalink raw reply
* [PATCH v3 3/3] Use separate struct console structure for each hvc_console.
From: Miche Baker-Harvey @ 2011-11-08 21:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk, Rusty Russell,
linux-kernel, virtualization, Anton Blanchard, Amit Shah,
Mike Waychison, ppc-dev, Eric Northrup
In-Reply-To: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
It is possible to make any virtio_console port be a console
by sending VIRITO_CONSOLE_CONSOLE_PORT. But hvc_alloc was
using a single struct console hvc_console, which contains
both an index and flags which are per-port.
This adds a separate struct console for each virtio_console
that is CONSOLE_PORT.
Signed-off-by: Miche Baker-Harvey <miche@google.com>
---
drivers/tty/hvc/hvc_console.c | 20 ++++++++++++++++++++
drivers/tty/hvc/hvc_console.h | 1 +
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 09a6159..24a84d6 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -247,6 +247,7 @@ static void destroy_hvc_struct(struct kref *kref)
spin_unlock(&hvc_structs_lock);
+ kfree(hp->hvc_console);
kfree(hp);
}
@@ -827,6 +828,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
int outbuf_size)
{
struct hvc_struct *hp;
+ struct console *cp;
int i;
/* We wait until a driver actually comes along */
@@ -854,6 +856,17 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
kref_init(&hp->kref);
INIT_WORK(&hp->tty_resize, hvc_set_winsz);
+ /*
+ * Make each console its own struct console.
+ */
+ cp = kmemdup(&hvc_console, sizeof(*cp), GFP_KERNEL);
+ if (!cp) {
+ kfree(hp);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ hp->hvc_console = cp;
+
spin_lock_init(&hp->lock);
spin_lock(&hvc_structs_lock);
@@ -872,8 +885,13 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
hp->index = i;
+ cp->index = i;
+ vtermnos[i] = vtermno;
+ cons_ops[i] = ops;
+
list_add_tail(&(hp->next), &hvc_structs);
spin_unlock(&hvc_structs_lock);
+ register_console(cp);
return hp;
}
@@ -884,6 +902,8 @@ int hvc_remove(struct hvc_struct *hp)
unsigned long flags;
struct tty_struct *tty;
+ BUG_ON(!hp->hvc_console);
+ unregister_console(hp->hvc_console);
spin_lock_irqsave(&hp->lock, flags);
tty = tty_kref_get(hp->tty);
diff --git a/drivers/tty/hvc/hvc_console.h b/drivers/tty/hvc/hvc_console.h
index c335a14..2d20ab7 100644
--- a/drivers/tty/hvc/hvc_console.h
+++ b/drivers/tty/hvc/hvc_console.h
@@ -58,6 +58,7 @@ struct hvc_struct {
const struct hv_ops *ops;
int irq_requested;
int data;
+ struct console *hvc_console;
struct winsize ws;
struct work_struct tty_resize;
struct list_head next;
^ permalink raw reply related
* [PATCH RFC v3 0/3] Support multiple VirtioConsoles.
From: Miche Baker-Harvey @ 2011-11-08 21:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk, Rusty Russell,
linux-kernel, virtualization, Anton Blanchard, Amit Shah,
Mike Waychison, ppc-dev, Eric Northrup
(Amit pointed out that the patches never went out. This was a resend of
the series meant to go out on 11/2/2011; Now it's a resend of the mail this
morning, with everyone copied on the same mail. So sorry for the spam!
This is v3.)
This patchset applies to linux-next/next-20111102.
This series implements support for multiple virtio_consoles using KVM.
This patchset addresses several issues associated with trying to
establish multiple virtio consoles.
I'm trying to start a guest via KVM that supports multiple virtual
consoles, with getty's on each, and with some being console devices.
These patches let me establish more than one VirtioConsole (I'm
running eight at the moment), and enable console output appearing on
one of them. It still doesn't successfully generate console output on
multiple VirtioConsoles.
Let me apologise for my last patch having gotten into Linus' tree, and
leaving other people to deal with crashes. I had meant to be asking
for guidance, but I didn't mark it as "RFC".
This series reflects the input from Konrad Rzeszutek, Amit Shah, Stephen
Boyd, and Rusty Russell. I think we do have to limit hvc_alloc() to one
thread.
I would appreciate any comments or feedback, or accept if appropriate.
Thanks,
Miche Baker-Harvey
---
Miche Baker-Harvey (3):
virtio_console: Fix locking of vtermno.
hvc_init(): Enforce one-time initialization.
Use separate struct console structure for each hvc_console.
drivers/char/virtio_console.c | 9 ++++++---
drivers/tty/hvc/hvc_console.c | 33 +++++++++++++++++++++++++++++++--
drivers/tty/hvc/hvc_console.h | 1 +
3 files changed, 38 insertions(+), 5 deletions(-)
--
^ permalink raw reply
* [PATCH v3 1/3] virtio_console: Fix locking of vtermno.
From: Miche Baker-Harvey @ 2011-11-08 21:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk, Rusty Russell,
linux-kernel, virtualization, Anton Blanchard, Amit Shah,
Mike Waychison, ppc-dev, Eric Northrup
In-Reply-To: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
Some modifications of vtermno were not done under the spinlock.
Moved assignment from vtermno and increment of vtermno together,
putting both under the spinlock. Revert vtermno on failure.
Signed-off-by: Miche Baker-Harvey <miche@google.com>
---
drivers/char/virtio_console.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8e3c46d..9722e76 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -987,18 +987,21 @@ int init_port_console(struct port *port)
* pointers. The final argument is the output buffer size: we
* can do any size, so we put PAGE_SIZE here.
*/
- port->cons.vtermno = pdrvdata.next_vtermno;
+ spin_lock_irq(&pdrvdata_lock);
+ port->cons.vtermno = pdrvdata.next_vtermno++;
+ spin_unlock_irq(&pdrvdata_lock);
port->cons.hvc = hvc_alloc(port->cons.vtermno, 0, &hv_ops, PAGE_SIZE);
+ spin_lock_irq(&pdrvdata_lock);
if (IS_ERR(port->cons.hvc)) {
ret = PTR_ERR(port->cons.hvc);
dev_err(port->dev,
"error %d allocating hvc for port\n", ret);
port->cons.hvc = NULL;
+ port->cons.vtermno = pdrvdata.next_vtermno--;
+ spin_unlock_irq(&pdrvdata_lock);
return ret;
}
- spin_lock_irq(&pdrvdata_lock);
- pdrvdata.next_vtermno++;
list_add_tail(&port->cons.list, &pdrvdata.consoles);
spin_unlock_irq(&pdrvdata_lock);
port->guest_connected = true;
^ permalink raw reply related
* [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Miche Baker-Harvey @ 2011-11-08 21:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk, Rusty Russell,
linux-kernel, virtualization, Anton Blanchard, Amit Shah,
Mike Waychison, ppc-dev, Eric Northrup
In-Reply-To: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
hvc_init() must only be called once, and no thread should continue with hvc_alloc()
until after initialization is complete. The original code does not enforce either
of these requirements. A new mutex limits entry to hvc_init() to a single thread,
and blocks all later comers until it has completed.
This patch fixes multiple crash symptoms.
Signed-off-by: Miche Baker-Harvey <miche@google.com>
---
drivers/tty/hvc/hvc_console.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index b6b2d18..09a6159 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -29,8 +29,9 @@
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <linux/list.h>
-#include <linux/module.h>
#include <linux/major.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/sysrq.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
@@ -84,6 +85,10 @@ static LIST_HEAD(hvc_structs);
* list traversal.
*/
static DEFINE_SPINLOCK(hvc_structs_lock);
+/*
+ * only one task does allocation at a time.
+ */
+static DEFINE_MUTEX(hvc_ports_mutex);
/*
* This value is used to assign a tty->index value to a hvc_struct based
@@ -825,11 +830,15 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
int i;
/* We wait until a driver actually comes along */
+ mutex_lock(&hvc_ports_mutex);
if (!hvc_driver) {
int err = hvc_init();
- if (err)
+ if (err) {
+ mutex_unlock(&hvc_ports_mutex);
return ERR_PTR(err);
+ }
}
+ mutex_unlock(&hvc_ports_mutex);
hp = kzalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size,
GFP_KERNEL);
^ permalink raw reply related
* Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
From: Scott Wood @ 2011-11-08 20:57 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052BC6F1@039-SN1MPN1-004.039d.mgd.msft.net>
On 11/08/2011 04:05 AM, Li Yang-R58472 wrote:
>> Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
>>
>> On 11/04/2011 07:31 AM, Zhao Chenhui wrote:
>>> +static int is_corenet;
>>> +static void __cpuinit smp_85xx_setup_cpu(int cpu_nr);
>>> +
>>> +#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC32)
>>
>> Why PPC32?
>
> Not sure if it is the same for e5500. E5500 support will be verified later.
It's better to have 64-bit silently do nothing here?
>>> + flush_disable_L1();
>>
>> You'll also need to take down L2 on e500mc.
>
> Right. E500mc support is beyond this patch series. We will work on it after the e500v2 support is finalized.
I saw some support with "is_corenet"... If we don't support e500mc,
make sure the code doesn't try to run on e500mc.
This isn't an e500v2-only BSP you're putting the code into. :-)
>>> + tmp = 0;
>>> + if (cpu_has_feature(CPU_FTR_CAN_NAP))
>>> + tmp = HID0_NAP;
>>> + else if (cpu_has_feature(CPU_FTR_CAN_DOZE))
>>> + tmp = HID0_DOZE;
>>
>> Those FTR bits are for what we can do in idle, and can be cleared if the
>> user sets CONFIG_BDI_SWITCH.
>
> It is powersave_nap variable shows what we can do in idle.
No, that shows what the user wants to do in idle.
> I think it's correct to use the CPU_FTR_CAN_* macro as CPU capability.
This is 85xx-specific code. We always can, and want to, nap here
(though the way we enter nap will be different on e500mc and up) -- even
if it's broken to use it for idle (such as on p4080, which would miss
doorbells as wake events).
>>> +static void __cpuinit smp_85xx_reset_core(int nr)
>>> +{
>>> + __iomem u32 *vaddr, *pir_vaddr;
>>> + u32 val, cpu_mask;
>>> +
>>> + /* If CoreNet platform, use BRR as release register. */
>>> + if (is_corenet) {
>>> + cpu_mask = 1 << nr;
>>> + vaddr = ioremap(get_immrbase() + MPC85xx_BRR_OFF, 4);
>>> + } else {
>>> + cpu_mask = 1 << (24 + nr);
>>> + vaddr = ioremap(get_immrbase() + MPC85xx_ECM_EEBPCR_OFF, 4);
>>> + }
>>
>> Please use the device tree node, not get_immrbase().
>
> The get_immrbase() implementation uses the device tree node.
I mean the guts node. get_immrbase() should be avoided where possible.
Also, some people might care about latency to enter/exit deep sleep.
Searching through the device tree at this point (rather than on init)
slows that down.
>>> +static int __cpuinit smp_85xx_map_bootpg(u32 page)
>>> +{
>>> + __iomem u32 *bootpg_ptr;
>>> + u32 bptr;
>>> +
>>> + /* Get the BPTR */
>>> + bootpg_ptr = ioremap(get_immrbase() + MPC85xx_BPTR_OFF, 4);
>>> +
>>> + /* Set the BPTR to the secondary boot page */
>>> + bptr = MPC85xx_BPTR_EN | (page & MPC85xx_BPTR_BOOT_PAGE_MASK);
>>> + out_be32(bootpg_ptr, bptr);
>>> +
>>> + iounmap(bootpg_ptr);
>>> + return 0;
>>> +}
>>
>> Shouldn't the boot page already be set by U-Boot?
>
> The register should be lost after a deep sleep. Better to do it again.
How can it be lost after a deep sleep if we're relying on it to hold our
wakeup code?
It's not "better to do it again" if we're making a bad assumption about
the code and the table being in the same page.
>>> local_irq_save(flags);
>>>
>>> - out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
>>> + out_be32(&epapr->pir, hw_cpu);
>>> #ifdef CONFIG_PPC32
>>> - out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
>>> +#ifdef CONFIG_HOTPLUG_CPU
>>> + if (system_state == SYSTEM_RUNNING) {
>>> + out_be32(&epapr->addr_l, 0);
>>> + smp_85xx_map_bootpg((u32)(*cpu_rel_addr >> PAGE_SHIFT));
>>
>> Why is this inside PPC32?
>
> Not tested on 64-bit yet. Might require a different implementation on PPC64.
Please make a reasonable effort to do things in a way that works on
both. It shouldn't be a big deal to test that it doesn't break booting
on p5020.
>>> if (!ioremappable)
>>> - flush_dcache_range((ulong)bptr_vaddr,
>>> - (ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
>>> + flush_dcache_range((ulong)epapr,
>>> + (ulong)epapr + sizeof(struct epapr_entry));
>>
>> We don't wait for the core to come up on 64-bit?
>
> Not sure about it. But at least the normal boot up should be tested on P5020, right?
Well, that's a special case in that it only has one secondary. :-)
Or we could be getting lucky with timing. It's not a new issue with
this patch, it just looks odd.
-Scott
^ permalink raw reply
* Re: [PATCH 5/7] fsl_pmc: update device bindings
From: Scott Wood @ 2011-11-08 20:39 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052BC964@039-SN1MPN1-004.039d.mgd.msft.net>
On 11/08/2011 04:56 AM, Li Yang-R58472 wrote:
>>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>> b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>>> index 07256b7..d84b4f8 100644
>>> --- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>>> @@ -9,22 +9,27 @@ Properties:
>>>
>>> "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
>>> compatible. "fsl,mpc8536-pmc" should also be listed for any chip
>>> - whose PMC is compatible, and implies deep-sleep capability.
>>> + whose PMC is compatible, and implies deep-sleep capability and
>>> + wake on user defined packet(wakeup on ARP).
>>
>> Why does the PMC care? This is an ethernet controller feature, the PMC
>> is just keeping the wakeup-relevant parts of the ethernet controller
>> alive (whatever they happen to be).
>>
>> Do we have any chips that have ethernet controller support for wake on
>> user-defined packet, but a sleep mode that doesn't let it be used?
>
> I think it is more a PMC feature cause Ethernet controller on many
> SoCs have the filer feature, but only very limited SoCs can support
> using it as a wake-up source. The differences should be mostly in
> the PM controller block.
Have you tried waking from sleep with it on those other SoCs?
> Also the wake on user-defined packet feature was never mentioned in the Ethernet controller part of UM.
AFAICT all this "feature" is, is programming the Ethernet controller to
filter out some packets that we don't want to wake us up, and then
refraining from entering magic packet mode. What PMC registers are
programmed any differently for this?
It's in the PM part of the manual because that's where they generally
describe issues related to PM. They describe magic packet there too.
The set of devices which are still active during sleep is a different
issue from the conditions on which a device will request a wake.
I also don't trust our PM documentation very much. It's ambiguous just
what gets shut down in ordinary sleep mode. E.g. the mpc8544 manual
talks about "external interrupts", but in one place it looks like it
means external to the SoC:
> In sleep mode, all clocks internal to the e500 core are turned off, including the timer facilities clock. All
> I/O interfaces in the device logic are also shut down. Only the clocks to the MPC8544E PIC are still
> running so that an external interrupt can wake up the device.
But the note immediately below that seems to imply they're talking about
external to the core:
> Only external interrupts can wake the MPC8544E from sleep mode. Internal
> interrupt sources like the core interval timer or watchdog timer depend on
> an active clock for their operation and these are disabled in sleep mode.
>> Normally that shouldn't matter, but we already an unused binding for
>> this. :-)
>>
>> Please provide rationale for doing it this way. Ideally it should
>> probably use whatever http://devicetree.org/ClockBindings ends up being.
>
> I have looked into that binding. The binding was primarily defined for the Linux clock API which is not same as what we are doing here(set wakeup source).
> If in the future the clock API also covers wakeup related features, we can change to use it.
While Linux APIs can serve as an inspiration, they're not the basis of
device tree bindings. The device tree is not Linux-specific, and should
not change just because Linux changes, but rather should describe the
hardware. We want to get this right the first time.
What we are describing here is how a device's clock is connected to the PMC.
-Scott
^ permalink raw reply
* [PATCH v2 3/3] Use separate struct console structure for each hvc_console.
From: Miche Baker-Harvey @ 2011-11-08 19:30 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20111108193005.30707.23990.stgit@miche.sea.corp.google.com>
It is possible to make any virtio_console port be a console
by sending VIRITO_CONSOLE_CONSOLE_PORT. But hvc_alloc was
using a single struct console hvc_console, which contains
both an index and flags which are per-port.
This adds a separate struct console for each virtio_console
that is CONSOLE_PORT.
Signed-off-by: Miche Baker-Harvey <miche@google.com>
---
drivers/tty/hvc/hvc_console.c | 20 ++++++++++++++++++++
drivers/tty/hvc/hvc_console.h | 1 +
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 09a6159..24a84d6 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -247,6 +247,7 @@ static void destroy_hvc_struct(struct kref *kref)
spin_unlock(&hvc_structs_lock);
+ kfree(hp->hvc_console);
kfree(hp);
}
@@ -827,6 +828,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
int outbuf_size)
{
struct hvc_struct *hp;
+ struct console *cp;
int i;
/* We wait until a driver actually comes along */
@@ -854,6 +856,17 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
kref_init(&hp->kref);
INIT_WORK(&hp->tty_resize, hvc_set_winsz);
+ /*
+ * Make each console its own struct console.
+ */
+ cp = kmemdup(&hvc_console, sizeof(*cp), GFP_KERNEL);
+ if (!cp) {
+ kfree(hp);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ hp->hvc_console = cp;
+
spin_lock_init(&hp->lock);
spin_lock(&hvc_structs_lock);
@@ -872,8 +885,13 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
hp->index = i;
+ cp->index = i;
+ vtermnos[i] = vtermno;
+ cons_ops[i] = ops;
+
list_add_tail(&(hp->next), &hvc_structs);
spin_unlock(&hvc_structs_lock);
+ register_console(cp);
return hp;
}
@@ -884,6 +902,8 @@ int hvc_remove(struct hvc_struct *hp)
unsigned long flags;
struct tty_struct *tty;
+ BUG_ON(!hp->hvc_console);
+ unregister_console(hp->hvc_console);
spin_lock_irqsave(&hp->lock, flags);
tty = tty_kref_get(hp->tty);
diff --git a/drivers/tty/hvc/hvc_console.h b/drivers/tty/hvc/hvc_console.h
index c335a14..2d20ab7 100644
--- a/drivers/tty/hvc/hvc_console.h
+++ b/drivers/tty/hvc/hvc_console.h
@@ -58,6 +58,7 @@ struct hvc_struct {
const struct hv_ops *ops;
int irq_requested;
int data;
+ struct console *hvc_console;
struct winsize ws;
struct work_struct tty_resize;
struct list_head next;
^ permalink raw reply related
* [PATCH v2 2/3] hvc_init(): Enforce one-time initialization.
From: Miche Baker-Harvey @ 2011-11-08 19:30 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20111108193005.30707.23990.stgit@miche.sea.corp.google.com>
hvc_init() must only be called once, and no thread should continue with hvc_alloc()
until after initialization is complete. The original code does not enforce either
of these requirements. A new mutex limits entry to hvc_init() to a single thread,
and blocks all later comers until it has completed.
This patch fixes multiple crash symptoms.
Signed-off-by: Miche Baker-Harvey <miche@google.com>
---
drivers/tty/hvc/hvc_console.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index b6b2d18..09a6159 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -29,8 +29,9 @@
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <linux/list.h>
-#include <linux/module.h>
#include <linux/major.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/sysrq.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
@@ -84,6 +85,10 @@ static LIST_HEAD(hvc_structs);
* list traversal.
*/
static DEFINE_SPINLOCK(hvc_structs_lock);
+/*
+ * only one task does allocation at a time.
+ */
+static DEFINE_MUTEX(hvc_ports_mutex);
/*
* This value is used to assign a tty->index value to a hvc_struct based
@@ -825,11 +830,15 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
int i;
/* We wait until a driver actually comes along */
+ mutex_lock(&hvc_ports_mutex);
if (!hvc_driver) {
int err = hvc_init();
- if (err)
+ if (err) {
+ mutex_unlock(&hvc_ports_mutex);
return ERR_PTR(err);
+ }
}
+ mutex_unlock(&hvc_ports_mutex);
hp = kzalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size,
GFP_KERNEL);
^ permalink raw reply related
* [PATCH v2 1/3] virtio_console: Fix locking of vtermno.
From: Miche Baker-Harvey @ 2011-11-08 19:30 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <20111108193005.30707.23990.stgit@miche.sea.corp.google.com>
Some modifications of vtermno were not done under the spinlock.
Moved assignment from vtermno and increment of vtermno together,
putting both under the spinlock. Revert vtermno on failure.
Signed-off-by: Miche Baker-Harvey <miche@google.com>
---
drivers/char/virtio_console.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8e3c46d..9722e76 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -987,18 +987,21 @@ int init_port_console(struct port *port)
* pointers. The final argument is the output buffer size: we
* can do any size, so we put PAGE_SIZE here.
*/
- port->cons.vtermno = pdrvdata.next_vtermno;
+ spin_lock_irq(&pdrvdata_lock);
+ port->cons.vtermno = pdrvdata.next_vtermno++;
+ spin_unlock_irq(&pdrvdata_lock);
port->cons.hvc = hvc_alloc(port->cons.vtermno, 0, &hv_ops, PAGE_SIZE);
+ spin_lock_irq(&pdrvdata_lock);
if (IS_ERR(port->cons.hvc)) {
ret = PTR_ERR(port->cons.hvc);
dev_err(port->dev,
"error %d allocating hvc for port\n", ret);
port->cons.hvc = NULL;
+ port->cons.vtermno = pdrvdata.next_vtermno--;
+ spin_unlock_irq(&pdrvdata_lock);
return ret;
}
- spin_lock_irq(&pdrvdata_lock);
- pdrvdata.next_vtermno++;
list_add_tail(&port->cons.list, &pdrvdata.consoles);
spin_unlock_irq(&pdrvdata_lock);
port->guest_connected = true;
^ permalink raw reply related
* [PATCH RFC v2 0/3] Support multiple VirtioConsoles.
From: Miche Baker-Harvey @ 2011-11-08 19:30 UTC (permalink / raw)
To: ppc-dev
(Amit pointed out that the patches never went out. This is a resend of
the series meant to go out on 11/2/2011; I've marked it "v2".)
This patchset applies to linux-next/next-20111102.
This series implements support for multiple virtio_consoles using KVM.
This patchset addresses several issues associated with trying to
establish multiple virtio consoles.
I'm trying to start a guest via KVM that supports multiple virtual
consoles, with getty's on each, and with some being console devices.
These patches let me establish more than one VirtioConsole (I'm
running eight at the moment), and enable console output appearing on
one of them. It still doesn't successfully generate console output on
multiple VirtioConsoles.
Let me apologise for my last patch having gotten into Linus' tree, and
leaving other people to deal with crashes. I had meant to be asking
for guidance, but I didn't mark it as "RFC".
This series reflects the input from Konrad Rzeszutek, Amit Shah, Stephen
Boyd, and Rusty Russell. I think we do have to limit hvc_alloc() to one
thread.
I would appreciate any comments or feedback, or accept if appropriate.
Thanks,
Miche Baker-Harvey
---
Miche Baker-Harvey (3):
virtio_console: Fix locking of vtermno.
hvc_init(): Enforce one-time initialization.
Use separate struct console structure for each hvc_console.
drivers/char/virtio_console.c | 9 ++++++---
drivers/tty/hvc/hvc_console.c | 33 +++++++++++++++++++++++++++++++--
drivers/tty/hvc/hvc_console.h | 1 +
3 files changed, 38 insertions(+), 5 deletions(-)
--
^ permalink raw reply
* Re: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
From: Scott Wood @ 2011-11-08 17:31 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052BC91C@039-SN1MPN1-004.039d.mgd.msft.net>
On 11/08/2011 04:32 AM, Li Yang-R58472 wrote:
>> Subject: Re: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
>>
>> On 11/04/2011 07:33 AM, Zhao Chenhui wrote:
>>> static int pmc_suspend_enter(suspend_state_t state)
>>> {
>>> int ret;
>>> + u32 powmgtreq = 0x00500000;
>>
>> Where does this 0x00500000 come from? Please symbolically define
>> individual bits.
>>
>> The comment in the asm code says it should be 0x00100000, BTW.
>
> I think we should get rid of the powmgtreq argument, as we don't support multiple modes for mpc85xx_enter_deep_sleep() now.
Doesn't that happen later in the patch series?
-Scott
^ permalink raw reply
* Re: [PATCH 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
From: Scott Wood @ 2011-11-08 17:28 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052BC5F8@039-SN1MPN1-004.039d.mgd.msft.net>
On 11/08/2011 03:06 AM, Li Yang-R58472 wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+leoli=freescale.com@lists.ozlabs.org
>> [mailto:linuxppc-dev-bounces+leoli=freescale.com@lists.ozlabs.org] On
>> Behalf Of Scott Wood
>> Sent: Saturday, November 05, 2011 1:34 AM
>> To: Zhao Chenhui-B35336
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH 1/7] powerpc/85xx: re-enable timebase sync disabled by
>> KEXEC patch
>>
>> On 11/04/2011 07:29 AM, Zhao Chenhui wrote:
>>> From: Li Yang <leoli@freescale.com>
>>>
>>> The timebase sync is not only necessary when using KEXEC. It should also
>>> be used by normal boot up and cpu hotplug. Remove the ifdef added by
>>> the KEXEC patch.
>>
>> The KEXEC patch didn't just add the ifdef, it also added the initializers:
>
> Yes. But the code suggests that the timebase synchronization is only necessary for KEXEC, but it turns out that sleep/wakeup also need it. Maybe the description of the patch need to be changed as KEXEC is not to be blamed.
It is needed when you hard reset a core. This was something we never
did on SMP before kexec. Now you're adding a second thing that does it,
so it'll need the sync as well, but that doesn't mean we should do it on
normal boot.
>>> @@ -105,8 +107,64 @@ smp_85xx_setup_cpu(int cpu_nr)
>>>
>>> struct smp_ops_t smp_85xx_ops = {
>>> .kick_cpu = smp_85xx_kick_cpu,
>>> +#ifdef CONFIG_KEXEC
>>> + .give_timebase = smp_generic_give_timebase,
>>> + .take_timebase = smp_generic_take_timebase,
>>> +#endif
>>> };
>>
>> U-Boot synchronizes the timebase on 85xx. With what chip and U-Boot
>> version are you seeing this not happen?
>
> I'm curious why don't we make it happen in kernel as we are against
> adding dependency to the bootloader?
We are against adding gratuitous dependencies on the bootloader, but
some things are just a lot easier to do in that context. Nobody
complains about Linux expecting RAM to be working on entry. :-)
While it's certainly possible to do this in Linux (and should be done
the way U-Boot does instead of the software sync, in the cases where we
need to), it's easier to do in U-Boot, before the cores are running.
It would be impossible for Linux to do this (or any other tb
modifications) when running on top of a hypervisor.
In http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-June/091321.html,
Ben Herrenschmidt said, "smp-tbsync.c is and has always been a
'workaround' for broken HW."
> Other architectures don't have this dependency,
Which "other architectures" are you referring to?
On PPC server this is handled with a firmware call to freeze the
timebase. On x86 this is handled by the BIOS by the time the OS starts.
-Scott
^ permalink raw reply
* [PATCH] KVM: PPC: protect use of kvmppc_h_pr
From: Andreas Schwab @ 2011-11-08 17:17 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <1312907508-14599-10-git-send-email-agraf@suse.de>
kvmppc_h_pr is only available if CONFIG_KVM_BOOK3S_64_PR.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/kvm/book3s_pr.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index bc4d50d..05473b5 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -660,10 +660,12 @@ program_interrupt:
ulong cmd = kvmppc_get_gpr(vcpu, 3);
int i;
+#ifdef CONFIG_KVM_BOOK3S_64_PR
if (kvmppc_h_pr(vcpu, cmd) == EMULATE_DONE) {
r = RESUME_GUEST;
break;
}
+#endif
run->papr_hcall.nr = cmd;
for (i = 0; i < 9; ++i) {
--
1.7.7.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox