qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
	dwmw2@infradead.org, seabios@seabios.org,
	qemu-devel <qemu-devel@nongnu.org>,
	Kevin O'Connor <kevin@koconnor.net>,
	ddutile@redhat.com, Anthony Liguori <anthony@codemonkey.ws>,
	lersek@redhat.com
Subject: Re: [Qemu-devel] KVM call agenda for 2013-06-11
Date: Tue, 11 Jun 2013 18:45:51 +0300	[thread overview]
Message-ID: <20130611154551.GA2756@redhat.com> (raw)
In-Reply-To: <20130604132431.GA24301@redhat.com>

On Tue, Jun 04, 2013 at 04:24:31PM +0300, Michael S. Tsirkin wrote:
> Juan is not available now, and Anthony asked for
> agenda to be sent early.
> So here comes:
> 
> Agenda for the meeting Tue, June 11:
>  
> - Generating acpi tables, redux

Not so much notes as a quick summary of the call:

There are the following reasons to generate ACPI tables in QEMU:

- sharing code with e.g. ovmf
	Anthony thinks this is not a valid argument

- so we can make tables more dynamic and move away from iasl
	Anthony thinks this is not a valid reason too,
	since qemu and seabios have access to same info
	MST noted several info not accessible to bios.
	Anthony said they can be added, e.g. by exposing
	QOM to the bios.

- even though most tables are static, hardcoded
  they are likely to change over time
	Anthony sees this as justified

To summarize, there's a concensus now that generating ACPI
tables in QEMU is a good idea.

Two issues that need to be addressed:
- original patches break cross-version migration. Need to fix that.

- Anthony requested that patchset is merged together with
  some new feature. I'm not sure the reasoning is clear:
  current a version intentionally generates tables
  that are bug for bug compatible with seabios,
  to simplify testing.

  It seems clear we have users for this such as
  hotplug of devices behind pci bridges, so
  why keep the infrastructure out of tree?

  Looking for something additional, smaller as the hotplug patch
  is a bit big, so might delay merging.


Going forward - would we want to move
smbios as well? Everyone seems to think it's a
good idea.

-- 
MST

  parent reply	other threads:[~2013-06-11 15:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04 13:24 [Qemu-devel] KVM call agenda for 2013-06-11 Michael S. Tsirkin
2013-06-10 16:50 ` Michael S. Tsirkin
2013-06-11 15:45 ` Michael S. Tsirkin [this message]
2013-06-11 18:06   ` Laszlo Ersek
2013-06-11 19:15     ` Michael S. Tsirkin
2013-06-11 18:38   ` Anthony Liguori
2013-06-11 19:22     ` 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=20130611154551.GA2756@redhat.com \
    --to=mst@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=ddutile@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=kevin@koconnor.net \
    --cc=kvm@vger.kernel.org \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --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).