From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: Extending boot protocol & bzImage for paravirt_ops Date: Fri, 01 Jun 2007 14:57:10 -0700 Message-ID: <46609636.4050208@zytor.com> References: <4656FB8F.4090604@goop.org> <466087CF.70708@goop.org> <4660924A.2070009@zytor.com> <466093E3.4010701@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <466093E3.4010701@goop.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Jeremy Fitzhardinge Cc: Chris Wright , Virtualization Mailing List , "Eric W. Biederman" , Linux Kernel Mailing List List-Id: virtualization@lists.linuxfoundation.org Jeremy Fitzhardinge wrote: > H. Peter Anvin wrote: >>> Do we care particularly? If 8 bytes is enough for the subarch, do we >>> care whether its a pointer or literal? After all, this is just a private >>> channel between the bootloader and some subarch-specific piece of code >>> in the kernel. >>> >>> >> I see two options: either we make it a pointer *and a length* so that a >> loader can reshuffle it at will (that also implies no absolute pointers >> within the data), or it's an opaque cookie anyway. > > No, it has to be completely opaque. It might be a pointer to some > special shared memory or something, and not movable. > Well, if we define is as a movable object then it has to be treated as such. It's a protocol definition issue. If we define it opaque, though -- of for that matter, if we don't -- we should define what memory it can live in, though. Right now, the only "available" memory we have is end of setup to 0xa0000; the command line is defined to be allocated from this memory. -hpa