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]
Message-ID: <1317301332.2580.108.camel@deneb.redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ