qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SeaBIOS] [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS value


From: Philippe Mathieu-Daudé
Subject: Re: [SeaBIOS] [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values
Date: Thu, 26 Sep 2019 21:09:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

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 <address@hidden>
>>>
>>> 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 <address@hidden>
>>> Reviewed-by: Arbel Moshe <address@hidden>
>>> Signed-off-by: Sam Eiderman <address@hidden>
>>> ---
>>>  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 */
>>> +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);
>>
>> 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.

> 
>> Thanks,
>>
>> Phil.
>>
> Thanks for the reviews :)

:)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]