All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Gleb Natapov <gleb@redhat.com>
Cc: Kevin O'Connor <kevin@koconnor.net>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch
Date: Tue, 23 Feb 2010 07:50:16 -0600	[thread overview]
Message-ID: <4B83DD18.7060808@codemonkey.ws> (raw)
In-Reply-To: <20100223082205.GB29041@redhat.com>

On 02/23/2010 02:22 AM, Gleb Natapov wrote:
> On Mon, Feb 22, 2010 at 08:31:00PM -0500, Kevin O'Connor wrote:
>    
>> On Mon, Feb 22, 2010 at 10:33:12AM +0200, Gleb Natapov wrote:
>>      
>>> On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'Connor wrote:
>>>        
>>>> Are you thinking of moving qemu more torwards what coreboot does, or
>>>> did you have a different idea in mind?
>>>>
>>>>          
>>> We shouldn't compare coreboot with qemu. Qemu is a hardware. Coreboot
>>> is part of a firmware.
>>>        
>> Coreboot and qemu often face the same problems when trying to pass
>> information into the BIOS.  I think it helps to look at how others
>> have solved similar problems.
>>
>>      
> Since qemu is a HW and coreboot is one part of firmware stack the
> information they are passing to Seabios is often fundamentally different.
> It is OK for coreboot to create ACPI/SMBIOS/E820 tables and pass them to
> Seabios, but it is not OK if qemu does that.

Actually, we do passthrough ACPI tables (you wrote that ;-)) and we 
build SMBIOS tables and pass them through to Seabios.

Regards,

Anthony Liguori

>   Information that QEMU pass
> to Seabios can be divided into two types. First one can be classified
> as board description. It is needed so Seabios would be able to support
> more then one qemu configuration without recompile. Second is "bios
> configuration" (boot priority, show bunner, etc). I don't know who
> manages this information on coreboot + Seabios combo, but I think it
> should be Seabios, so this kind of info should not be passed between
> coreboot an Seabios at all.
>
> --
> 			Gleb.
>
>
>    

  reply	other threads:[~2010-02-23 13:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-15 17:33 [Qemu-devel] [PATCH] QEMU e820 reservation patch Jes Sorensen
2010-02-15 18:54 ` [Qemu-devel] " Stefano Stabellini
2010-02-16  8:49   ` Jes Sorensen
2010-02-19 21:02 ` [Qemu-devel] " Anthony Liguori
2010-02-21 17:44   ` Jes Sorensen
2010-02-21 19:13     ` Kevin O'Connor
2010-02-22  8:33       ` Gleb Natapov
2010-02-23  1:31         ` Kevin O'Connor
2010-02-23  8:22           ` Gleb Natapov
2010-02-23 13:50             ` Anthony Liguori [this message]
2010-02-23 14:01               ` Gleb Natapov
2010-02-22  9:23       ` Avi Kivity
2010-02-19 22:00 ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B83DD18.7060808@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=gleb@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.