[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries |
Date: |
Mon, 30 Jan 2017 13:07:23 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 |
On 01/27/17 19:19, Ben Warren wrote:
>
>> On Jan 27, 2017, at 8:12 AM, Laszlo Ersek <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>> 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?
>>
> Yes, this seems reasonable. If I’m interpreting this properly, it’s
> like ADD_POINTER, except that we extend the write path back to QEMU over
> DMA. Is that about right?
Yes. Basically the command differs from ADD_POINTER in that (a) the
pointer field to patch lives in "fw_cfg space", not in guest RAM, so
rather than updating guest RAM, the firmware has to select a writeable
fw_cfg file, seek ("skip") to the specified offset, and rewrite the
field, (b) the nature of the patching is not "increment", just a plain
"overwrite".
Thanks!
Laszlo
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, (continued)
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Laszlo Ersek, 2017/01/26
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Michael S. Tsirkin, 2017/01/26
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Laszlo Ersek, 2017/01/26
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Michael S. Tsirkin, 2017/01/26
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Laszlo Ersek, 2017/01/26
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Kevin O'Connor, 2017/01/27
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Laszlo Ersek, 2017/01/27
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Kevin O'Connor, 2017/01/27
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Laszlo Ersek, 2017/01/27
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Ben Warren, 2017/01/27
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries,
Laszlo Ersek <=
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Michael S. Tsirkin, 2017/01/30
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Igor Mammedov, 2017/01/31
- Re: [Qemu-devel] [PATCH v4 1/9] ACPI: Add a function for building named qword entries, Michael S. Tsirkin, 2017/01/31
[Qemu-devel] [PATCH v4 3/9] docs: VM Generation ID device description, ben, 2017/01/24
[Qemu-devel] [PATCH v4 5/9] qmp/hmp: add query-vm-generation-id and 'info vm-generation-id' commands, ben, 2017/01/24
[Qemu-devel] [PATCH v4 6/9] qmp/hmp: add set-vm-generation-id commands, ben, 2017/01/24
[Qemu-devel] [PATCH v4 2/9] linker-loader: Add new 'allocate and return address' cmd, ben, 2017/01/24