[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: |
Sam Eiderman |
Subject: |
Re: [SeaBIOS] [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values |
Date: |
Wed, 16 Oct 2019 14:02:39 +0300 |
Gentle Ping,
Philippe, John?
Just wondering if the series is okay, as Gerd pointed out this series
is a blocker for the corresponding changes in SeaBIOS for v 1.13
Sam
On Tue, Oct 8, 2019 at 2:51 PM Sam Eiderman <address@hidden> wrote:
>
>
>
> On Tue, Oct 8, 2019, 13:34 Philippe Mathieu-Daudé <address@hidden> wrote:
>>
>> 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é
>> > <address@hidden <mailto:address@hidden>> 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 <address@hidden
>> > <mailto: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
>> > <mailto:address@hidden>>
>> > >>>> Reviewed-by: Arbel Moshe <address@hidden
>> > <mailto:address@hidden>>
>> > >>>> Signed-off-by: Sam Eiderman <address@hidden
>> > <mailto: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 */
>>
>> I suppose the lchs struct is serialized in little-endian.
>
>
> Nice catch, that's just a bad comment, should be removed.
> There used to be a struct with 3 uint32_t values, Laszlo pointed out that
> there is an endianess problem (this was fixed in v3) later Kevin suggested to
> make it a textual interface and the struct was removed (in v4) but the
> comment remained.
>>
>>
>> > >>>> +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, since this is a textual interface, I believe this should work no?
>
> uint32_t a = 4;
> g_strdup_printf("%s" PRIu32, a);
>
> Should return "4" no matter the endianess? (Taken care of by glib?)
>
>>
>> > >>>
>> > >>> 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é <address@hidden
>> > <mailto:address@hidden>>
>>
>> Meanwhile I withdraw my fast R-b :(
>>
>> Regards,
>>
>> Phil.
- Re: [SeaBIOS] [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, Philippe Mathieu-Daudé, 2019/10/08
- Re: [SeaBIOS] [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, Sam Eiderman, 2019/10/08
- Re: [SeaBIOS] [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values,
Sam Eiderman <=
- Re: [SeaBIOS] Re: [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, Laszlo Ersek, 2019/10/16
- Re: [SeaBIOS] Re: [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, Philippe Mathieu-Daudé, 2019/10/16
- Re: [SeaBIOS] Re: [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, Sam Eiderman, 2019/10/16
- Re: [SeaBIOS] Re: [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, John Snow, 2019/10/16
- Re: [SeaBIOS] Re: [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, Sam Eiderman, 2019/10/16
- Re: [SeaBIOS] Re: [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values, Philippe Mathieu-Daudé, 2019/10/16