Hi Sam,
On 9/29/19 12:13 PM, Sam Eiderman wrote:
Philippe, thanks for the fast review,
Fast is not always the friend of careful.
John, thanks for picking up this hot potato :-)
Sam
On Thu, Sep 26, 2019 at 10:16 PM Philippe Mathieu-Daudé
<phi...@redhat.com <mailto:phi...@redhat.com>> wrote:
On 9/26/19 9:09 PM, Philippe Mathieu-Daudé wrote:
> On 9/26/19 8:26 PM, John Snow wrote:
>> On 9/26/19 5:57 AM, Philippe Mathieu-Daudé wrote:
>>> Hi Sam,
>>>
>>> On 9/25/19 1:06 PM, Sam Eiderman wrote:
>>>> From: Sam Eiderman <shmuel.eider...@oracle.com
<mailto:shmuel.eider...@oracle.com>>
>>>>
>>>> Using fw_cfg, supply logical CHS values directly from QEMU to
the BIOS.
>>>>
>>>> Non-standard logical geometries break under QEMU.
>>>>
>>>> A virtual disk which contains an operating system which depends on
>>>> logical geometries (consistent values being reported from BIOS
INT13
>>>> AH=08) will most likely break under QEMU/SeaBIOS if it has
non-standard
>>>> logical geometries - for example 56 SPT (sectors per track).
>>>> No matter what QEMU will report - SeaBIOS, for large enough
disks - will
>>>> use LBA translation, which will report 63 SPT instead.
>>>>
>>>> In addition we cannot force SeaBIOS to rely on physical
geometries at
>>>> all. A virtio-blk-pci virtual disk with 255 phyiscal heads cannot
>>>> report more than 16 physical heads when moved to an IDE
controller,
>>>> since the ATA spec allows a maximum of 16 heads - this is an
artifact of
>>>> virtualization.
>>>>
>>>> By supplying the logical geometries directly we are able to
support such
>>>> "exotic" disks.
>>>>
>>>> We serialize this information in a similar way to the "bootorder"
>>>> interface.
>>>> The new fw_cfg entry is "bios-geometry".
>>>>
>>>> Reviewed-by: Karl Heubaum <karl.heub...@oracle.com
<mailto:karl.heub...@oracle.com>>
>>>> Reviewed-by: Arbel Moshe <arbel.mo...@oracle.com
<mailto:arbel.mo...@oracle.com>>
>>>> Signed-off-by: Sam Eiderman <shmuel.eider...@oracle.com
<mailto:shmuel.eider...@oracle.com>>
>>>> ---
>>>> bootdevice.c | 32 ++++++++++++++++++++++++++++++++
>>>> hw/nvram/fw_cfg.c | 14 +++++++++++---
>>>> include/sysemu/sysemu.h | 1 +
>>>> 3 files changed, 44 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/bootdevice.c b/bootdevice.c
>>>> index 2b12fb85a4..b034ad7bdc 100644
>>>> --- a/bootdevice.c
>>>> +++ b/bootdevice.c
>>>> @@ -405,3 +405,35 @@ void del_boot_device_lchs(DeviceState
*dev, const char *suffix)
>>>> }
>>>> }
>>>> }
>>>> +
>>>> +/* Serialized as: (device name\0 + lchs struct) x devices */
I suppose the lchs struct is serialized in little-endian.
>>>> +char *get_boot_devices_lchs_list(size_t *size)
>>>> +{
>>>> + FWLCHSEntry *i;
>>>> + size_t total = 0;
>>>> + char *list = NULL;
>>>> +
>>>> + QTAILQ_FOREACH(i, &fw_lchs, link) {
>>>> + char *bootpath;
>>>> + char *chs_string;
>>>> + size_t len;
>>>> +
>>>> + bootpath = get_boot_device_path(i->dev, false,
i->suffix);
>>>> + chs_string = g_strdup_printf("%s %" PRIu32 " %"
PRIu32 " %" PRIu32,
>>>> + bootpath, i->lcyls,
i->lheads, i->lsecs);
Sam. can you check if you don't need endianness conversion here?
>>>
>>> Hmm maybe we can g_free(bootpath) directly here.
>>>
>>
>> I think it's okay to do it at the bottom of the loop. No real
benefit to
>> being that eager to free resources in my mind. I expect setup at
the top
>> of a block and teardown at the bottom of a block.
>>
>> Trying to do too much in the middle gets messy in my opinion,
not that
>> it seems to matter here.
>
> No problem.
>
>>>> +
>>>> + if (total) {
>>>> + list[total - 1] = '\n';
>>>> + }
>>>> + len = strlen(chs_string) + 1;
>>>> + list = g_realloc(list, total + len);
>>>> + memcpy(&list[total], chs_string, len);
>>>> + total += len;
>>>> + g_free(chs_string);
>>>> + g_free(bootpath);
>>>> + }
>>>> +
>>>> + *size = total;
>>>> +
>>>> + return list;
>>>> +}
>>>> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
>>>> index 7dc3ac378e..18aff658c0 100644
>>>> --- a/hw/nvram/fw_cfg.c
>>>> +++ b/hw/nvram/fw_cfg.c
>>>> @@ -920,13 +920,21 @@ void *fw_cfg_modify_file(FWCfgState *s,
const char *filename,
>>>>
>>>> static void fw_cfg_machine_reset(void *opaque)
>>>> {
>>>> + MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
>>>> + FWCfgState *s = opaque;
>>>> void *ptr;
>>>> size_t len;
>>>> - FWCfgState *s = opaque;
>>>> - char *bootindex = get_boot_devices_list(&len);
>>>> + char *buf;
>>>>
>>>> - ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t
*)bootindex, len);
>>>> + buf = get_boot_devices_list(&len);
>>>> + ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)buf,
len);
>>>> g_free(ptr);
>>>> +
>>>> + if (!mc->legacy_fw_cfg_order) {
>>>> + buf = get_boot_devices_lchs_list(&len);
>>>> + ptr = fw_cfg_modify_file(s, "bios-geometry", (uint8_t
*)buf, len);
>>>
>>> OK. Can you add a test in tests/fw_cfg-test.c please?
>>>
>>
>> :D
>>
>>>> + g_free(ptr);
>>>> + }
>>>> }
>>>>
>>>> static void fw_cfg_machine_ready(struct Notifier *n, void *data)
>>>> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
>>>> index 5bc5c79cbc..80c57fdc4e 100644
>>>> --- a/include/sysemu/sysemu.h
>>>> +++ b/include/sysemu/sysemu.h
>>>> @@ -106,6 +106,7 @@ void validate_bootdevices(const char
*devices, Error **errp);
>>>> void add_boot_device_lchs(DeviceState *dev, const char *suffix,
>>>> uint32_t lcyls, uint32_t lheads,
uint32_t lsecs);
>>>> void del_boot_device_lchs(DeviceState *dev, const char *suffix);
>>>> +char *get_boot_devices_lchs_list(size_t *size);
>>>
>>> Please add some documentation. At least 'size' must be non-NULL.
>>>
>>
>> Sure; but I wasn't going to gate on it because this series went
unloved
>> for so long. At this point, a follow-up patch is fine.
>
> OK
>
>>
>>> Ideally you should add doc for the other functions added in 3/8
>>> "bootdevice: Add interface to gather LCHS" too.
>>>
>>
>> Same thing here.
>>
>>> John, what do you think about extracting the *boot_device*
functions out
>>> of "sysemu.h"?
>>>
>>
>> Potentially worthwhile; but not critical at the moment. The
source tree
>> is not the best-organized thing as-is and I don't think it's fair to
>> hold this series up for much longer for nice-to-haves, ultimately.
>>
>> More targeted improvements might avoid the "whose responsibility
is it
>> to stage this?" hot potato we played with this one; so I'd
rather have
>> smaller follow-up patches handled by the respective maintainers.
>
> Sure, fair enough.
I forgot:
Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com
<mailto:phi...@redhat.com>>
Meanwhile I withdraw my fast R-b :(
Regards,
Phil.
