qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>, Ben Warren <ben@skyportsystems.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries
Date: Fri, 27 Jan 2017 17:12:43 +0100	[thread overview]
Message-ID: <0e627b59-08ad-ac77-5a7b-c80c0b027406@redhat.com> (raw)
In-Reply-To: <20170127154313.GB7213@morn.lan>

On 01/27/17 16:43, 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

I know no specific reason; I just thought this possible generalization
was one of the advantages in Michael's suggestion.

> as well as why it would want support for
> pointers smaller than 8 bytes in size.

Hm, right, good point.

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

That might be the main reason I guess; reading back a bit, Michael wrote
"... a variant of ADD_POINTER".

>  I'm okay with either format.

I'd say let's go ahead with Michael's proposal then. Ben, are you okay
with that?

Thanks!
Laszlo

  reply	other threads:[~2017-01-27 16:12 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 [this message]
2017-01-27 18:19                             ` Ben Warren
2017-01-30 12:07                               ` Laszlo Ersek
2017-01-30 20:28                           ` Michael S. Tsirkin
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=0e627b59-08ad-ac77-5a7b-c80c0b027406@redhat.com \
    --to=lersek@redhat.com \
    --cc=ben@skyportsystems.com \
    --cc=imammedo@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=mst@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).