From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KY4Fr-00080r-Tb for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:31:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KY4Fn-0007ya-7G for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:31:03 -0400 Received: from [199.232.76.173] (port=41345 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KY4Fm-0007yW-Tr for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:30:58 -0400 Received: from il.qumranet.com ([212.179.150.194]:13947) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KY4Fm-0007Qo-8q for qemu-devel@nongnu.org; Tue, 26 Aug 2008 15:30:58 -0400 Message-ID: <48B459EE.7010101@qumranet.com> Date: Tue, 26 Aug 2008 22:30:54 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS communication. 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> <48B2F373.1020606@codemonkey.ws> <20080826082453.GV6192@minantech.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Gleb Natapov 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.