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 <sam...@google.com> wrote: > > > > On Tue, Oct 8, 2019, 13:34 Philippe Mathieu-Daudé <phi...@redhat.com> 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é >> > <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. > > > 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é <phi...@redhat.com >> > <mailto:phi...@redhat.com>> >> >> Meanwhile I withdraw my fast R-b :( >> >> Regards, >> >> Phil.