From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKfr1-0008GD-FJ for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:26:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKfqw-0008FN-0z for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:26:50 -0500 Received: from [199.232.76.173] (port=43330 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKfqv-0008FK-Qp for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:26:45 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:34382) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKfqv-0007o3-W3 for qemu-devel@nongnu.org; Tue, 15 Dec 2009 17:26:46 -0500 Received: by yxe26 with SMTP id 26so403282yxe.4 for ; Tue, 15 Dec 2009 14:26:45 -0800 (PST) Message-ID: <4B280D20.5050203@codemonkey.ws> Date: Tue, 15 Dec 2009 16:26:40 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?) References: <20091214203603.GJ6150@redhat.com> <4B26A3B2.2030006@codemonkey.ws> <20091214205141.GC6398@redhat.com> <4B26F678.4010603@codemonkey.ws> <4B27541F.9020603@redhat.com> <4B27E1C2.5090506@codemonkey.ws> <20091215211900.GG26712@redhat.com> <4B280374.5010604@codemonkey.ws> <20091215215244.GI26712@redhat.com> <4B28064A.1070501@codemonkey.ws> <20091215215942.GJ26712@redhat.com> In-Reply-To: <20091215215942.GJ26712@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: glommer@redhat.com, qemu-devel@nongnu.org, Alexander Graf , Kevin O'Connor , Gerd Hoffmann , Sebastian Herbszt Michael S. Tsirkin wrote: >> I think it's stable-0.12 material because it's badly broken right now >> > > I thought the rule was no guest visible changes in stable series? > Yeah, good point, so we need to figure out something for 0.12.0. Sebastian's suggestion of loading roms from 0xc0000 first and then from PCI devices is a good one, but I think the problem with that is that the roms don't necessarily have to be contiguous in that space. For instance, the lower bios portions are technically in the rom area which leaves a big gap in the middle. We could just assume that knowledge in SeaBIOS. We'll also need the ability to select whether to use PCI or legacy rom loading for each PCI device (via a qdev property). This will need to be plumbed into the machine compat bits such that -M pc-0.11.0 uses legacy rom loading. Otherwise, the PCI devices will be detectably different within the guest. Regards, Anthony Liguori