From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel]  KVM call agenda for 2013-05-28
Date: Thu, 30 May 2013 20:45:39 +0300
Message-ID: <20130530174539.GF29091@redhat.com>
References: <20130523124132.GA18596@redhat.com>
 <20130528235309.GA31648@morn.localdomain>
 <51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws>
 <1369905828.20691.50.camel@shinybook.infradead.org>
 <51A73459.2020407@redhat.com>
 <1369916358.5141.32.camel@i7.infradead.org>
 <CAFe8ug_=WJEvJspRRWsTG7POWBxmeO3+kcUVQHmntt0gxZqfRA@mail.gmail.com>
 <51A78152.10000@redhat.com>
 <CAFe8ug9CTjAZ9HfnJpmNK6wtogyY6xxNkc5tBjQd-qiHNkUVyA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
 Juan Quintela <quintela@redhat.com>, seabios@seabios.org,
 qemu-devel qemu-devel <qemu-devel@nongnu.org>,
 Gerd Hoffmann <kraxel@redhat.com>,
 "Jordan Justen \(Intel address\)" <jordan.l.justen@intel.com>,
 David Woodhouse <dwmw2@infradead.org>
To: Jordan Justen <jljusten@gmail.com>
Return-path: <seabios-bounces@seabios.org>
Content-Disposition: inline
In-Reply-To: <CAFe8ug9CTjAZ9HfnJpmNK6wtogyY6xxNkc5tBjQd-qiHNkUVyA@mail.gmail.com>
List-Unsubscribe: <http://www.seabios.org/mailman/options/seabios>,
 <mailto:seabios-request@seabios.org?subject=unsubscribe>
List-Archive: <http://www.seabios.org/pipermail/seabios>
List-Post: <mailto:seabios@seabios.org>
List-Help: <mailto:seabios-request@seabios.org?subject=help>
List-Subscribe: <http://www.seabios.org/mailman/listinfo/seabios>,
 <mailto:seabios-request@seabios.org?subject=subscribe>
Errors-To: seabios-bounces@seabios.org
Sender: seabios-bounces@seabios.org
List-Id: kvm.vger.kernel.org

On Thu, May 30, 2013 at 09:57:10AM -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek <lersek@redhat.com> wrote:
> > On 05/30/13 18:20, Jordan Justen wrote:
> >> I think ACPI table generation lives in firmware on real products,
> >> because on real products the firmware is the point that best
> >> understands the actual hardware layout for the machine. In qemu, I
> >> would say that qemu best knows the hardware layout, given that the
> >> firmware is generally a slightly separate project from qemu.
> >>
> >> I don't think adding a coreboot layer into the picture helps, if it
> >> brings along the coreboot payload boot interface as a requirement.
> >>
> >> Then again, I don't really understand how firmware could be swapped
> >> out in this case. What would -bios do? How would the coreboot ACPI
> >> shim layer be specified to qemu?
> >
> > I guess -bios would load coreboot. Coreboot would siphon the data
> > necessary for ACPI table building through the current (same) fw_cfg
> > bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or
> > something else -- not sure how to configure that), and pass down the
> > tables to the firmware (through a now unspecified interface -- perhaps
> > the tables could even be installed at this point). This could introduce
> > another interface (fw_cfg+something rather than just fw_cfg), but ACPI
> > table preparation would be concentrated in one project.
> >
> > I guess.
> 
> For reference, I believe that both Xen and virtualbox build ACPI table
> in the VMM rather than firmware. They both dump the tables into the
> 0xe000 segment (yuck) where firmware finds and publishes it to the OS.
> I think fw-cfg would be a reasonable alternative to this for
> communicating the tables.
> 
> -Jordan

Want to review/ack the patches I sent? That's exactly what they do.

-- 
MST