qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Jordan Justen <jljusten@gmail.com>,
	seabios@seabios.org, qemu-devel <qemu-devel@nongnu.org>,
	Kevin O'Connor <kevin@koconnor.net>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Date: Tue, 11 Jun 2013 09:49:32 +0300	[thread overview]
Message-ID: <20130611064932.GA31474@redhat.com> (raw)
In-Reply-To: <CA+aC4ktu25Bg78ct2-t6AX+aR=-+1sYrD_eQVBiDqS35JES9iw@mail.gmail.com>

On Mon, Jun 10, 2013 at 08:25:15PM -0500, Anthony Liguori wrote:
> > I do understand your desire to pass this stuff as parameters, but I
> > really don't see it as feasible.  I'm hoping that if you can write up
> > some examples with specifics you'll either enlighten me or you'll see
> > the difficulties I'm trying to describe.
> 
> Is your basic argument that generating these tables is hard, QEMU can
> and should just hard code them and change them whenever it feels like
> without involving SeaBIOS?

Basically I think it makes sense to listen to people
that write drivers for PV hardware that QEMU exposes.
bios is one such example.

If people that are supposed to use our interfaces
ask for a specific interface, I think we should listen.
If people come and say that building acpi dynamically is hard
for them and they want QEMU to prepare templates for acpi -
and there's overwhelming concensus on this -
QEMU should stop going "tough luck we know what's best for you".

> If that's what it boils down to, I'll look more closely at it.

So please look at the original patchset
[PATCH RFC 00/13] qemu: generate acpi tables for the guest

and let's move the discussion of it beyond the meta-argument
"QEMU does not need to generate any ACPI tables" 
and to the specific interface that we can use
to make life easier for the bios.

Specifically several options were discussed, on and off-line for passing
per-formatted tables to firmware:

1. use existing fw cfg interface from bios,
   qemu side make it work well with cross version migration.
2. same as 1 but find some existing hardware that is similar
   to fw cfg and emulate it. For example build a directory
   structure in some flash.
3. make qemu put tables into guest memory.
   bios needs to reserve this memory.
4. same as 3 but bios allocates memory and
   passes address to qemu.

Kevin suggested 1. This is what my patchset implements.
But I think bios could live with any of
the others, as long as it's a generic interface so
we can stop changing bios code all the time.

-- 
MST

  parent reply	other threads:[~2013-06-11  6:49 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-10 16:41 [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support Michael S. Tsirkin
2013-06-10 18:58 ` Anthony Liguori
2013-06-10 19:17   ` Peter Maydell
2013-06-10 19:50     ` Anthony Liguori
2013-06-10 19:43   ` Laszlo Ersek
2013-06-10 19:57     ` Anthony Liguori
2013-06-10 20:43       ` Laszlo Ersek
2013-06-10 21:14         ` Laszlo Ersek
2013-06-10 21:45         ` Anthony Liguori
2013-06-10 23:05           ` Kevin O'Connor
2013-06-10 23:34             ` Anthony Liguori
2013-06-10 23:52               ` David Woodhouse
2013-06-11  0:11                 ` Anthony Liguori
2013-06-11 14:11                   ` David Woodhouse
2013-06-11  0:23               ` Kevin O'Connor
2013-06-11  0:51                 ` Anthony Liguori
2013-06-11  1:19                   ` Kevin O'Connor
2013-06-11  1:25                     ` Anthony Liguori
2013-06-11  1:49                       ` Kevin O'Connor
2013-06-11  6:49                       ` Michael S. Tsirkin [this message]
2013-06-11  0:28           ` Jordan Justen
2013-06-11  1:03             ` Anthony Liguori
2013-06-11  1:32               ` Jordan Justen
2013-06-11  7:35               ` Michael S. Tsirkin
2013-06-13 23:05                 ` Paolo Bonzini
2013-06-14  0:59                   ` Anthony Liguori
2013-06-14  1:23                     ` [Qemu-devel] [SeaBIOS] " Peter Stuge
2013-06-11 14:04               ` David Woodhouse
2013-06-13 23:02               ` [Qemu-devel] " Paolo Bonzini
2013-06-14  0:26                 ` Laszlo Ersek
2013-06-16 10:00                   ` Laszlo Ersek
2013-06-11  5:22   ` Michael S. Tsirkin
2013-06-11  5:33 ` Gerd Hoffmann
2013-06-11  6:55   ` Michael S. Tsirkin
2013-06-11  7:42     ` Gerd Hoffmann
2013-06-11  7:53       ` Michael S. Tsirkin
2013-06-11  8:00         ` Gerd Hoffmann
2013-06-11  8:18           ` Michael S. Tsirkin
2013-06-11  8:27             ` Michael S. Tsirkin

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=20130611064932.GA31474@redhat.com \
    --to=mst@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=dwmw2@infradead.org \
    --cc=jljusten@gmail.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).