All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/3] acpi: more infrastructure cleanups
Date: Mon, 15 Apr 2013 17:05:13 +0300	[thread overview]
Message-ID: <20130415140513.GC19549@redhat.com> (raw)
In-Reply-To: <516BFF70.8050907@redhat.com>

On Mon, Apr 15, 2013 at 03:24:00PM +0200, Laszlo Ersek wrote:
> On 04/15/13 13:25, Michael S. Tsirkin wrote:
> > On Mon, Apr 15, 2013 at 12:37:37PM +0300, Michael S. Tsirkin wrote:
> >> I wanted to help Laszlo completely move ACPI tables out of seabios in
> >> time for 1.5, but had to put out some fires so didn't manage to do this
> >> in time, and going offline for now.
> >>
> >> Meanwhile, here is some refactoring that I did complete.  This does not
> >> do much by itself, but works fine for me and will be helpful down the
> >> road.
> >>
> >> This includes a couple of patches I posted previously
> >> and another one on top.
> >>
> >> Pls consider for 1.5.
> > 
> > Just two clarifications
> > 1. This conflicts with Laszlo's MADT change. As such if Laszlo's patch is applied,
> >    this will need to be rebased on top.
> > 2. This was lightly tested but there's a holiday here so I run out of
> >    time for testing. Will report in a couple of days.
> 
> First, thank you very much for the help!
> 
> Second, 2/3 breaks the binary format exported under the
> FW_CFG_ACPI_TABLES key. The format is as follows:
> 
>   * number of tables in entire fw_cfg blob : uint16_t
>   for each table:
>     * ACPI payload size belonging to this table : uint16_t
>     * standard ACPI header
>     * ACPI table contents
> 
> whereas 2/3 changes the format to:
> 
>   * zero-filled uint16_t (i)
>   for each table:
>     * uint16_t storing value 1 in LE order (ii)
>     * number of bytes in blob segment belonging to this table : uint16_t
>     * standard ACPI header
>     * ACPI table contents
> 
> (ii) shouldn't exist in per-table storage, the increments should target
> (i) actually.
> 
> 
> Another note: 2/3 introduces two ways to spell "has_header" in the
> leading comments. The first use is "&&!@has_header" (correct with @, but
> whitespace missing). The second use is "&& !has_header" (from my last
> series, also see "bloblen"), which has the whitespace OK, but misses the
> at-sign @ customary in comments when referring to function paramteres.
> 
> 
> Finally, regarding the purpose of this patch. It seems to be to prepend
> a standard ACPI header to a "headerles" table.
> 
> I think we can do without the reallocation. When preparing any ACPI
> table, we know in advance the size of the ACPI header we're going to
> need. So we can take it into account when allocating the buffer: fill in
> the table body, and then call a function that puts the header at front,
> into existing storage. See pc_acpi_install() in "[Qemu-devel] [qemu
> PATCH 5/5] i386/pc: build ACPI MADT (APIC) for fw_cfg clients".
> 
> I propose the following:
> 
> (1) I'll resend my "[qemu PATCH 0/5] publish etc/acpi/APIC in fw_cfg"
> series from last Monday, rebased to current (or then) master, with the
> following changes suggested by Michael in private:
> (1a) separating some stuff out into different files,
> (1b) adding licensing bits related to SeaBIOS,
> (1c) I'll try to consider 1/3 and 3/3 in this series that Paolo has
> already picked up (may not match or be useful any longer),
> 
> (2) Then, please review / apply that updated series of mine,
> 
> (3) then please rebase 2/3 from here on top of (2). Again, I suggest
> that acpi_table_add_hdr(), if any, fill in preallocated space; this is
> consistent with updating the checksum too.
> 
> (4) I *do* anticipate that my code in (2) is not / will not be flexible
> enough for all tables. However, please split up functions / extract bits
> / reorganize them only in a series that puts those new extracted
> functions to use *at once* (probably near the end of said series). I
> can't reason about "librarization" without actual use.
> 
> I'll wait for Michael's answer before doing anything.
> 
> Thanks
> Laszlo

I'm fine with this. FYI, I'm offline for the rest of today and
tomorrow.

-- 
MST

  parent reply	other threads:[~2013-04-15 14:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-15  9:37 [Qemu-devel] [PATCH 0/3] acpi: more infrastructure cleanups Michael S. Tsirkin
2013-04-15  9:37 ` [Qemu-devel] [PATCH 1/3] acpi: move declarations from pc.h to acpi.h Michael S. Tsirkin
2013-04-15 10:42   ` Paolo Bonzini
2013-04-15 11:00     ` Laszlo Ersek
2013-04-15 11:00       ` Paolo Bonzini
2013-04-15  9:37 ` [Qemu-devel] [PATCH 2/3] acpi: add acpi_table_add_hdr Michael S. Tsirkin
2013-04-15  9:37 ` [Qemu-devel] [PATCH 3/3] acpi.h: make it self contained Michael S. Tsirkin
2013-04-15 11:25 ` [Qemu-devel] [PATCH 0/3] acpi: more infrastructure cleanups Michael S. Tsirkin
2013-04-15 13:24   ` Laszlo Ersek
2013-04-15 13:31     ` Laszlo Ersek
2013-04-15 14:05     ` Michael S. Tsirkin [this message]
2013-04-15 21:10 ` Anthony Liguori
2013-04-15 21:26   ` Laszlo Ersek

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=20130415140513.GC19549@redhat.com \
    --to=mst@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --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.