linux-kernel - Re: [PATCH v3 00/24] C6X: New architecture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Sep 2011 09:02:11 -0400
From:	Mark Salter <msalter@...hat.com>
To:	Valdis.Kletnieks@...edu
Cc:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH v3 00/24] C6X: New architecture

On Thu, 2011-09-29 at 08:42 -0400, Valdis.Kletnieks@...edu wrote:
> On Thu, 29 Sep 2011 08:21:58 EDT, Mark Salter said:
> 
> > One thing that we plan to push later is an XIP model where cores can share a
> > single kernel text image but run with their own copies of data. So you end up
> > with something like a loosely coupled multiprocessor system with some hardware
> > support for multicore communication and peripheral sharing.
> 
> Ah, OK.  I eventually came across a mention in one of the patches of running
> a separate instance of Linux on each core, whick left me even more mystified.
> But the above clarifies it, thanks...
> 
> I wonder how many currently global variables will need to be moved to per_cpu
> structures to make it work, and how intrusive that will end up.  Or is the plan
> to have the boot loader simply plonk the entire .data/.bss in different locations
> for each core?
> 

What we have prototyped is more like the latter. The XIP image (binary
kernel block) is in ROM. Bootloader boots the first core by jumping to
kernel image. Kernel copies initialized data to its reserved chunk of
RAM and runs from there. The other kernels can be started by the boot
kernel and they too will jump to the ROM image and make their own copies
of all data. Without cache coherency, sharing any cached data is
problematic.

Other models are also possible. For instance, other cores could run
dedicated DSP applications using some other minimal OS with HW supported
communication with the Linux OS acting as the overall manager.

--Mark

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/