All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Sam Eiderman" <sameid@google.com>,
	qemu-devel@nongnu.org
Cc: kwolf@redhat.com, qemu-block@nongnu.org, arbel.moshe@oracle.com,
	seabios@seabios.org, kraxel@redhat.com,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [SeaBIOS] [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values
Date: Thu, 26 Sep 2019 14:26:11 -0400	[thread overview]
Message-ID: <7dc7b14c-8e89-4851-6d05-d69b1bf36e3e@redhat.com> (raw)
In-Reply-To: <ffff9a59-3cbf-8b04-f4e5-8a01dad8d381@redhat.com>



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.eiderman@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.heubaum@oracle.com>
>> Reviewed-by: Arbel Moshe <arbel.moshe@oracle.com>
>> Signed-off-by: Sam Eiderman <shmuel.eiderman@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 */
>> +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.

>> +
>> +        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.

> 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.

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

--js


  reply	other threads:[~2019-09-26 18:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 11:06 [PATCH v7 0/8] Add Qemu to SeaBIOS LCHS interface Sam Eiderman via
2019-09-25 11:06 ` [PATCH v7 1/8] block: Refactor macros - fix tabbing Sam Eiderman via
2019-09-26  9:38   ` [SeaBIOS] " Philippe Mathieu-Daudé
2019-09-25 11:06 ` [PATCH v7 2/8] block: Support providing LCHS from user Sam Eiderman via
2019-09-25 11:06 ` [PATCH v7 3/8] bootdevice: Add interface to gather LCHS Sam Eiderman via
2019-09-25 11:06 ` [PATCH v7 4/8] scsi: Propagate unrealize() callback to scsi-hd Sam Eiderman via
2019-09-26  9:38   ` [SeaBIOS] " Philippe Mathieu-Daudé
2019-09-25 11:06 ` [PATCH v7 5/8] bootdevice: Gather LCHS from all relevant devices Sam Eiderman via
2019-09-25 11:06 ` [PATCH v7 6/8] bootdevice: Refactor get_boot_devices_list Sam Eiderman via
2019-09-26  9:42   ` [SeaBIOS] " Philippe Mathieu-Daudé
2019-09-25 11:06 ` [PATCH v7 7/8] bootdevice: FW_CFG interface for LCHS values Sam Eiderman via
2019-09-26  9:57   ` [SeaBIOS] " Philippe Mathieu-Daudé
2019-09-26 18:26     ` John Snow [this message]
2019-09-26 19:09       ` Philippe Mathieu-Daudé
2019-09-26 19:16         ` Philippe Mathieu-Daudé
2019-09-29 10:13           ` Sam Eiderman
2019-10-08 11:34             ` Philippe Mathieu-Daudé
2019-10-08 11:51               ` Sam Eiderman
2019-10-16 11:02                 ` Sam Eiderman
2019-10-16 12:14                   ` [SeaBIOS] " Laszlo Ersek
2019-10-16 12:29                     ` Philippe Mathieu-Daudé
2019-10-16 14:55                       ` Sam Eiderman
2019-10-16 15:07                         ` John Snow
2019-10-16 15:19                           ` Sam Eiderman
2019-10-16 16:41                             ` Philippe Mathieu-Daudé
2019-09-25 11:06 ` [PATCH v7 8/8] hd-geo-test: Add tests for lchs override Sam Eiderman via
2019-09-26 10:00   ` [SeaBIOS] " Philippe Mathieu-Daudé
2019-09-26 18:19     ` John Snow
2019-09-25 20:38 ` [PATCH v7 0/8] Add Qemu to SeaBIOS LCHS interface John Snow
2019-09-27 17:02 ` no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7dc7b14c-8e89-4851-6d05-d69b1bf36e3e@redhat.com \
    --to=jsnow@redhat.com \
    --cc=arbel.moshe@oracle.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lersek@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sameid@google.com \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.