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 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).