From: "Michael S. Tsirkin" <mst@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: Laszlo Ersek <lersek@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org, Ben Warren <ben@skyportsystems.com>
Subject: Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries
Date: Mon, 30 Jan 2017 22:28:41 +0200 [thread overview]
Message-ID: <20170130222539-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170127154313.GB7213@morn.lan>
On Fri, Jan 27, 2017 at 10:43:13AM -0500, Kevin O'Connor wrote:
> On Fri, Jan 27, 2017 at 03:46:33PM +0100, Laszlo Ersek wrote:
> > On 01/27/17 15:18, Kevin O'Connor wrote:
> > > If an offset is going to be added, shouldn't both a source offset and
> > > destination offset be used?
> > >
> > > /*
> > > * COMMAND_WRITE_POINTER - update a writeable file named
> > > * @pointer.dest_file at @pointer.dest_offset, by writing pointer
> > > * plus @pointer.src_offset to the blob originating from
> > > * @src_file. 1,2,4 or 8 byte unsigned write is used depending
> > > * on @pointer.size.
> > > */
> > > struct {
> > > char dest_file[BIOS_LINKER_LOADER_FILESZ];
> > > char src_file[BIOS_LINKER_LOADER_FILESZ];
> > > uint32_t src_offset, dest_offset;
> > > uint8_t size;
> > > } pointer;
> > >
> > > I doubt the offsets or size is really all that important though.
> >
> > The offset into the fw_cfg file that receives the allocation address is
> > important, that allows the same file to receive several different
> > addresses (for different downloaded blobs), at different offsets.
> >
> > OTOH, asking the firmware to add a constant to the address value before
> > writing it to the fw_cfg file is not necessary, in my opinion. The blob
> > that the firmware allocated and downloaded originates from QEMU to begin
> > with, so QEMU knows its internal structure.
>
> I guess I'm missing why QEMU would want to use the same writable file
> for multiple pointers as well as why it would want support for
> pointers smaller than 8 bytes in size. If it's because it may be
> easier to support an internal QEMU blob of a particular format, then
> adding a src_offset would facilitate that.
>
> However, if it was done so that WRITE_POINTER mimicks ADD_POINTER then
> that's fine too. I'm okay with either format.
>
> -Kevin
Both reasons :) offset is because it's easier for QEMU not to have to add
more files (e.g. it simplifies cross-version migration if we don't).
size is to mimick ADD_POINTER.
--
MST
next prev parent reply other threads:[~2017-01-30 20:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 1:43 [Qemu-devel] [PATCH v4 0/9] Add support for VM Generation ID ben
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries ben
2017-01-25 3:55 ` Laszlo Ersek
2017-01-25 17:36 ` Ben Warren
2017-01-25 18:35 ` Michael S. Tsirkin
2017-01-26 0:48 ` Laszlo Ersek
2017-01-26 5:35 ` Ben Warren
2017-01-26 8:21 ` Laszlo Ersek
2017-01-26 15:20 ` Michael S. Tsirkin
2017-01-26 17:43 ` Laszlo Ersek
2017-01-26 18:15 ` Michael S. Tsirkin
2017-01-26 18:25 ` Laszlo Ersek
2017-01-26 18:59 ` Michael S. Tsirkin
2017-01-27 3:20 ` Laszlo Ersek
2017-01-27 14:18 ` Kevin O'Connor
2017-01-27 14:46 ` Laszlo Ersek
2017-01-27 15:43 ` Kevin O'Connor
2017-01-27 16:12 ` Laszlo Ersek
2017-01-27 18:19 ` Ben Warren
2017-01-30 12:07 ` Laszlo Ersek
2017-01-30 20:28 ` Michael S. Tsirkin [this message]
2017-01-31 9:51 ` Igor Mammedov
2017-01-31 21:39 ` Michael S. Tsirkin
2017-02-01 11:46 ` Igor Mammedov
2017-02-01 17:55 ` Michael S. Tsirkin
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 2/9] linker-loader: Add new 'allocate and return address' cmd ben
2017-01-25 4:30 ` Laszlo Ersek
2017-01-25 13:03 ` Laszlo Ersek
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 3/9] docs: VM Generation ID device description ben
2017-01-25 5:29 ` Laszlo Ersek
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 4/9] ACPI: Add Virtual Machine Generation ID support ben
2017-01-25 10:04 ` Laszlo Ersek
2017-01-25 14:00 ` Laszlo Ersek
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 5/9] qmp/hmp: add query-vm-generation-id and 'info vm-generation-id' commands ben
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 6/9] qmp/hmp: add set-vm-generation-id commands ben
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 7/9] PC: Support dynamic sysbus on pc_i440fx ben
2017-01-25 10:09 ` Laszlo Ersek
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 8/9] tests: Move reusable ACPI macros into a new header file ben
2017-01-25 1:43 ` [Qemu-devel] [PATCH v4 9/9] tests: Add unit tests for the VM Generation ID feature ben
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=20170130222539-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ben@skyportsystems.com \
--cc=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--cc=lersek@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.