From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KY4S2-0001V6-WB
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:43:39 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KY4S2-0001Tj-31
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:43:38 -0400
Received: from [199.232.76.173] (port=41910 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KY4S1-0001TW-V8
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:43:38 -0400
Received: from wf-out-1314.google.com ([209.85.200.172]:35257)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1KY4S1-00037a-B1
	for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:43:37 -0400
Received: by wf-out-1314.google.com with SMTP id 27so2437078wfd.4
	for <qemu-devel@nongnu.org>; Tue, 26 Aug 2008 12:43:35 -0700 (PDT)
Message-ID: <f43fc5580808261243u12dc19e5tb62f372624f01799@mail.gmail.com>
Date: Tue, 26 Aug 2008 22:43:35 +0300
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS
	communication.
In-Reply-To: <48B459EE.7010101@qumranet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080825095800.18703.30602.stgit@gleb-debian.qumranet.com.qumranet.com>
	<20080825095805.18703.63202.stgit@gleb-debian.qumranet.com.qumranet.com>
	<48B2C0A1.7040309@codemonkey.ws> <20080825144026.GQ6192@minantech.com>
	<f43fc5580808250801s3e975006s1e0e99b291291a8e@mail.gmail.com>
	<48B2F373.1020606@codemonkey.ws>
	<f43fc5580808251127m36cec30du40858fb0e731832c@mail.gmail.com>
	<20080826082453.GV6192@minantech.com>
	<f43fc5580808260946t67536b67nb46acc6ed450aa80@mail.gmail.com>
	<48B459EE.7010101@qumranet.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On 8/26/08, Avi Kivity <avi@qumranet.com> wrote:
> Blue Swirl wrote:
>  >
>  > One problem with this IO method is that it is not SMP safe, because of
>  > the cur_entry selection and reading will not be atomic. Think of boot
>  > CPU waking up all other CPUs with broadcast interrupt and then these
>  > other CPUs all want to know the boot parameters at the same time. The
>  > same could happen with warm reset. Directly mapped ROM doesn't have
>  > this problem, but multiplexed ROM (or Sparc64 nvram used now) is also
>  > unsafe.
>  >
>  > I could think of a couple of solutions:
>  > - different IO port for each CPU (not possible on PC)
>  > - per-CPU cur_entry, the device "knows" the CPU index (not very beautiful)
>  > - lock mechanism: before access, the CPU must win lock and only then
>  > it can access the data. But IO ports don't support atomic
>  > instructions? How about some kind of MAC-like protocol? It gets pretty
>  > complex.
>  >
>  > Are there other solutions?
>  >
>  >
>
>
> Put the lock in memory.  Or even simpler, have the boot cpu extract the
>  parameters and place them in memory, and then wake up other cpus.

Where in the memory? What about reset, when all CPUs are online? And
CPUs would need to know if they are the boot CPU or not without
disturbing our IO port.