qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>"Richard W.M. Jones"
	<rjones@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 2/7] fw_cfg: introduce the "data_memwidth" property
Date: Fri, 12 Dec 2014 14:39:56 +0100	[thread overview]
Message-ID: <548AF02C.4090400@redhat.com> (raw)
In-Reply-To: <CAFEAcA9SKSQEruvUfyDT3MASkZVmThoUt02CwcmfWuCbCVpG2A@mail.gmail.com>

On 12/12/14 13:49, Peter Maydell wrote:
> On 9 December 2014 at 01:13, Laszlo Ersek <lersek@redhat.com> wrote:
>> The "data_memwidth" property is capable of changing the maximum valid
>> access size to the MMIO data register, and (corresponding to the previous
>> patch) resizes the memory region similarly, at device realization time.
>>
>> (Because "data_iomem" is configured and installed dynamically now, we must
>> delay those steps to the realize callback.)
>>
>> The default value of "data_memwidth" is set so that we don't yet diverge
>> from "fw_cfg_data_mem_ops".
>>
>> Most of the fw_cfg users will stick with the default, and for them we
>> should continue using the statically allocated "fw_cfg_data_mem_ops". This
>> is beneficial for debugging because gdb can resolve pointers referencing
>> static objects to the names of those objects.
>>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> 
> Mostly looks good to me. A few nits:
> 
>> +    qdev_prop_set_uint32(dev, "data_memwidth",
>> +                         fw_cfg_data_mem_ops.valid.max_access_size);
> 
> Why not just make this the default value of the property, rather
> than setting the default value to -1 and always manually overriding it?

This hunk just prepares the ground for the next patch, where the
property will be set from a new function parameter. Ultimately I wanted
to leave the default value of the property at -1, for consistency with
the other two properties.

> 
>> @@ -607,12 +610,8 @@ static void fw_cfg_initfn(Object *obj)
>>
>>      memory_region_init_io(&s->ctl_iomem, OBJECT(s), &fw_cfg_ctl_mem_ops, s,
>>                            "fwcfg.ctl", FW_CFG_SIZE);
>>      sysbus_init_mmio(sbd, &s->ctl_iomem);
>> -    memory_region_init_io(&s->data_iomem, OBJECT(s), &fw_cfg_data_mem_ops, s,
>> -                          "fwcfg.data",
>> -                          fw_cfg_data_mem_ops.valid.max_access_size);
>> -    sysbus_init_mmio(sbd, &s->data_iomem);
> 
>>      /* In case ctl and data overlap: */
>>      memory_region_init_io(&s->comb_iomem, OBJECT(s), &fw_cfg_comb_mem_ops, s,
>>                            "fwcfg", FW_CFG_SIZE);
>>  }
>> @@ -620,9 +619,20 @@ static void fw_cfg_initfn(Object *obj)
>>  static void fw_cfg_realize(DeviceState *dev, Error **errp)
>>  {
>>      FWCfgState *s = FW_CFG(dev);
>>      SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
>> +    const MemoryRegionOps *data_mem_ops = &fw_cfg_data_mem_ops;
>>
>> +    if (s->data_memwidth > data_mem_ops->valid.max_access_size) {
>> +        MemoryRegionOps *ops;
>> +
>> +        ops = g_memdup(data_mem_ops, sizeof(*data_mem_ops));
>> +        ops->valid.max_access_size = s->data_memwidth;
>> +        data_mem_ops = ops;
>> +    }
>> +    memory_region_init_io(&s->data_iomem, OBJECT(s), data_mem_ops, s,
>> +                          "fwcfg.data", data_mem_ops->valid.max_access_size);
>> +    sysbus_init_mmio(sbd, &s->data_iomem);
> 
> The property changes the width of the data port, but only in
> the case where it's not combined with the control port
> (there the data width remains always 1). Is it worth throwing
> an error in realize if the caller tried to set data_memwidth
> and also use the combined-port? (Possibly even if the caller
> set data_memwidth and tried to use data_iobase at all? Does
> it make sense to define an AWAP I/O port ?)

I considered "locking down" the new interface, and preventing callers
from passing in any IO ports when they want a wider MMIO data register.
I didn't do that because someone might want a wider ioport mapping at
some point (although no current such user exists and I couldn't name
what the advantage would be in it). Unless you use the combined thing,
the wide data register should work with the ioport mapping too.

The combined case I thought to leave simply undefined.

If you want, I can set an error, but then I'd prefer to prevent callers
from passing IO ports through the new data_memwidth-taking functions.

Thanks
Laszlo

> 
>>
>>      if (s->ctl_iobase + 1 == s->data_iobase) {
>>          sysbus_add_io(sbd, s->ctl_iobase, &s->comb_iomem);
>>      } else {
>> @@ -637,8 +647,9 @@ static void fw_cfg_realize(DeviceState *dev, Error **errp)
>>
>>  static Property fw_cfg_properties[] = {
>>      DEFINE_PROP_UINT32("ctl_iobase", FWCfgState, ctl_iobase, -1),
>>      DEFINE_PROP_UINT32("data_iobase", FWCfgState, data_iobase, -1),
>> +    DEFINE_PROP_UINT32("data_memwidth", FWCfgState, data_memwidth, -1),
>>      DEFINE_PROP_END_OF_LIST(),
>>  };
> 
> thanks
> -- PMM
> 

  reply	other threads:[~2014-12-12 13:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09  1:12 [Qemu-devel] [PATCH v3 0/7] fw_cfg, bootorder, and UEFI+'-kernel' on arm/virt Laszlo Ersek
2014-12-09  1:12 ` [Qemu-devel] [PATCH v3 1/7] fw_cfg: max access size and region size are the same for MMIO data reg Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 2/7] fw_cfg: introduce the "data_memwidth" property Laszlo Ersek
2014-12-12 12:49   ` Peter Maydell
2014-12-12 13:39     ` Laszlo Ersek [this message]
2014-12-12 13:41       ` Peter Maydell
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 3/7] fw_cfg: expose the "data_memwidth" prop with fw_cfg_init_data_memwidth() Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 4/7] arm: add fw_cfg to "virt" board Laszlo Ersek
2014-12-12 12:55   ` Peter Maydell
2014-12-12 13:41     ` Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 5/7] hw/loader: split out load_image_gzipped_buffer() Laszlo Ersek
2014-12-12 13:11   ` Peter Maydell
2014-12-12 13:43     ` Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 6/7] hw/arm: pass pristine kernel image to guest firmware over fw_cfg Laszlo Ersek
2014-12-12 13:20   ` Peter Maydell
2014-12-12 13:52     ` Laszlo Ersek
2014-12-12 13:57       ` Peter Maydell
2014-12-12 14:10         ` Laszlo Ersek
2014-12-12 14:14           ` Richard W.M. Jones
2014-12-12 14:24             ` Laszlo Ersek
2014-12-09  1:13 ` [Qemu-devel] [PATCH v3 7/7] hw/arm/virt: enable passing of EFI-stubbed kernel to guest UEFI firmware Laszlo Ersek
2014-12-12 13:20   ` Peter Maydell

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=548AF02C.4090400@redhat.com \
    --to=lersek@redhat.com \
    --cc=drjones@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).