qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu devel list <qemu-devel@nongnu.org>,
	"Gabriel L. Somlo" <somlo@cmu.edu>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v4 3/7] fw-cfg: expose "file_slots" parameter in fw_cfg_init_io_dma()
Date: Tue, 6 Dec 2016 17:46:51 +0100	[thread overview]
Message-ID: <3da2baa9-9fa6-7802-fe56-afa02a892a07@redhat.com> (raw)
In-Reply-To: <20161206124906.76a41896@nial.brq.redhat.com>

On 12/06/16 12:49, Igor Mammedov wrote:
> On Thu,  1 Dec 2016 18:06:20 +0100
> Laszlo Ersek <lersek@redhat.com> wrote:
> 
>> Accordingly, generalize the "file_slots" minimum calculation in
>> fw_cfg_init_io_dma(), and move the constant FW_CFG_FILE_SLOTS_TRAD
>> argument to the callers of fw_cfg_init_io_dma().
> If I get idea correctly you're extending fw_cfg_init_io_dma() and
> setting
>  qdev_prop_set_uint32(dev, "file_slots", file_slots);
> manually to keep old fw_cfg_init_io() the same without touching
> xen/sun4u machines.

First, to my knowledge, Xen does not use fw_cfg. The following call
chains depend on (!xen_enabled()):

pc_init1() | pc_q35_init()
  if (!xen_enabled()):
    pc_memory_init()
      bochs_bios_init()
        fw_cfg_init_io_dma()

Second, I wanted to keep the fw_cfg_init_io() call sites un-touched. In
this patch, the fw_cfg_init_io() function passes an additional /
internal-only parameter to fw_cfg_init_io_dma(), and the unconditional
qdev_prop_set_uint32() call in fw_cfg_init_io_dma() is replaced with a
conditional one (so that the property can only be lowered, not raised,
by board code).

> That way we would have 2 different ways to set defaults
> per machine type/version rather then the single COMPAT property way.
> 
> How about dropping this patch and adding
>  SET_MACHINE_COMPAT
> to xen/sun4u machines instead and dropping fw_cfg_init_io() in
> favor of fw_cfg_init_io_dma() along the way.

For the conditional qdev_prop_set_uint32() call, added in this patch, I
used commit e6915b5f3a87 ("fw_cfg: unbreak migration compatibility for
2.4 and earlier machines") as model. According to that model, I couldn't
drop this patch completely, because the new feature -- i.e., DMA in that
patch, and higher fw_cfg file slots in this patch -- depends on both
machine versions and board opt-in.

However, if we agree (according to your feedback on patch v4 2/7) that
we will silently bump the fw_cfg file count for all new machine
versions, without requiring (or permitting) board opt-in / opt-out, then
I agree your above suggestion is consistent with that.

I think I don't have to drop fw_cfg_init_io() actually. But, with the
board opt-in going away, I can drop both the additional "file_slots"
parameter in fw_cfg_init_io_dma(), and the qdev_prop_set_uint32() call
in it (even the unconditional one).

In fact I like this simplicity more, I just wanted to be extra cautious
in the first version of the series that turned file_slots into a property.

... Actually, are sun4u machines versioned? Hm... "hw/sparc64/sun4u.c"
doesn't seem to define versioned machine types. Doesn't that imply that
migration is *completely* unsupported for sun4u? Because, if that's the
case, then I wouldn't even have to add SET_MACHINE_COMPAT().

Thanks!
Laszlo

> 
>>
>> Cc: "Gabriel L. Somlo" <somlo@cmu.edu>
>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>> Cc: Igor Mammedov <imammedo@redhat.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>  docs/specs/fw_cfg.txt     |  4 ++--
>>  include/hw/nvram/fw_cfg.h |  2 +-
>>  hw/i386/pc.c              |  3 ++-
>>  hw/nvram/fw_cfg.c         | 13 ++++++-------
>>  4 files changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
>> index 84e2978706f5..4a6888b511f4 100644
>> --- a/docs/specs/fw_cfg.txt
>> +++ b/docs/specs/fw_cfg.txt
>> @@ -153,12 +153,12 @@ Selector Reg.    Range Usage
>>  0x4000 - 0x7fff  Generic (0x0000 - 0x3fff, RW, ignored in QEMU v2.4+)
>>  0x8000 - 0xbfff  Arch. Specific (0x0000 - 0x3fff, generally RO, possibly RW
>>                                   through the DMA interface in QEMU v2.9+)
>>  0xc000 - 0xffff  Arch. Specific (0x0000 - 0x3fff, RW, ignored in v2.4+)
>>  
>> -In practice, the number of allowed firmware configuration items is given
>> -by the value (FW_CFG_FILE_FIRST + FW_CFG_FILE_SLOTS_TRAD) (see fw_cfg.h).
>> +In practice, the number of allowed firmware configuration items depends on the
>> +machine type.
> machine type/version
> 
>>  
>>  = Guest-side DMA Interface =
>>  
>>  If bit 1 of the feature bitmap is set, the DMA interface is present. This does
>>  not replace the existing fw_cfg interface, it is an add-on. This interface
>> diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
>> index b980cbaebf43..e9a6b6aa968c 100644
>> --- a/include/hw/nvram/fw_cfg.h
>> +++ b/include/hw/nvram/fw_cfg.h
>> @@ -173,11 +173,11 @@ void fw_cfg_add_file_callback(FWCfgState *s, const char *filename,
>>   */
>>  void *fw_cfg_modify_file(FWCfgState *s, const char *filename, void *data,
>>                           size_t len);
>>  
>>  FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
>> -                                AddressSpace *dma_as);
>> +                                AddressSpace *dma_as, uint32_t file_slots);
>>  FWCfgState *fw_cfg_init_io(uint32_t iobase);
>>  FWCfgState *fw_cfg_init_mem(hwaddr ctl_addr, hwaddr data_addr);
>>  FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
>>                                   hwaddr data_addr, uint32_t data_width,
>>                                   hwaddr dma_addr, AddressSpace *dma_as);
>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> index a9e64a88e5e7..5d929d8fc887 100644
>> --- a/hw/i386/pc.c
>> +++ b/hw/i386/pc.c
>> @@ -741,11 +741,12 @@ static FWCfgState *bochs_bios_init(AddressSpace *as, PCMachineState *pcms)
>>  {
>>      FWCfgState *fw_cfg;
>>      uint64_t *numa_fw_cfg;
>>      int i, j;
>>  
>> -    fw_cfg = fw_cfg_init_io_dma(FW_CFG_IO_BASE, FW_CFG_IO_BASE + 4, as);
>> +    fw_cfg = fw_cfg_init_io_dma(FW_CFG_IO_BASE, FW_CFG_IO_BASE + 4, as,
>> +                                FW_CFG_FILE_SLOTS_TRAD);
>>      fw_cfg_add_i16(fw_cfg, FW_CFG_NB_CPUS, pcms->boot_cpus);
>>  
>>      /* FW_CFG_MAX_CPUS is a bit confusing/problematic on x86:
>>       *
>>       * For machine types prior to 1.8, SeaBIOS needs FW_CFG_MAX_CPUS for
>> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
>> index 2e1441c09750..c33c76ab93b1 100644
>> --- a/hw/nvram/fw_cfg.c
>> +++ b/hw/nvram/fw_cfg.c
>> @@ -926,11 +926,11 @@ static void fw_cfg_init1(DeviceState *dev)
>>      s->machine_ready.notify = fw_cfg_machine_ready;
>>      qemu_add_machine_init_done_notifier(&s->machine_ready);
>>  }
>>  
>>  FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
>> -                                AddressSpace *dma_as)
>> +                                AddressSpace *dma_as, uint32_t file_slots)
>>  {
>>      DeviceState *dev;
>>      FWCfgState *s;
>>      uint32_t version = FW_CFG_VERSION;
>>      bool dma_requested = dma_iobase && dma_as;
>> @@ -940,15 +940,14 @@ FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
>>      qdev_prop_set_uint32(dev, "dma_iobase", dma_iobase);
>>      if (!dma_requested) {
>>          qdev_prop_set_bit(dev, "dma_enabled", false);
>>      }
>>  
>> -    /* Once we expose the "file_slots" property to callers of
>> -     * fw_cfg_init_io_dma(), the following setting should become conditional on
>> -     * the input parameter being lower than the current value of the property.
>> -     */
>> -    qdev_prop_set_uint32(dev, "file_slots", FW_CFG_FILE_SLOTS_TRAD);
>> +    if (file_slots < object_property_get_int(OBJECT(dev), "file_slots",
>> +                                             &error_abort)) {
>> +        qdev_prop_set_uint32(dev, "file_slots", file_slots);
>> +    }
>>  
>>      fw_cfg_init1(dev);
>>      s = FW_CFG(dev);
>>  
>>      if (s->dma_enabled) {
>> @@ -964,11 +963,11 @@ FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
>>      return s;
>>  }
>>  
>>  FWCfgState *fw_cfg_init_io(uint32_t iobase)
>>  {
>> -    return fw_cfg_init_io_dma(iobase, 0, NULL);
>> +    return fw_cfg_init_io_dma(iobase, 0, NULL, FW_CFG_FILE_SLOTS_TRAD);
>>  }
>>  
>>  FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
>>                                   hwaddr data_addr, uint32_t data_width,
>>                                   hwaddr dma_addr, AddressSpace *dma_as)
> 

  reply	other threads:[~2016-12-06 16:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01 17:06 [Qemu-devel] [PATCH v4 0/7] q35: add negotiable broadcast SMI Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 1/7] fw-cfg: support writeable blobs Laszlo Ersek
2016-12-20 15:58   ` Marcel Apfelbaum
2017-01-10 13:33     ` Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 2/7] fw-cfg: turn FW_CFG_FILE_SLOTS into a device property Laszlo Ersek
2016-12-02 11:10   ` Gerd Hoffmann
2016-12-02 11:48     ` Laszlo Ersek
2016-12-02 12:47       ` Gerd Hoffmann
2016-12-06 10:50   ` Igor Mammedov
2016-12-06 11:43     ` Laszlo Ersek
2016-12-06 12:02       ` Igor Mammedov
2016-12-06 16:22         ` Laszlo Ersek
2017-01-10 15:02   ` Michael S. Tsirkin
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 3/7] fw-cfg: expose "file_slots" parameter in fw_cfg_init_io_dma() Laszlo Ersek
2016-12-06 11:49   ` Igor Mammedov
2016-12-06 16:46     ` Laszlo Ersek [this message]
2016-12-06 16:52       ` Laszlo Ersek
2016-12-06 23:21         ` David Gibson
2016-12-06 18:09       ` Igor Mammedov
2016-12-06 19:29         ` Stefano Stabellini
2017-01-10 15:02   ` Michael S. Tsirkin
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 4/7] hw/i386/pc: introduce 2.9 machine types with 0x20 fw_cfg file slots Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 5/7] hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg Laszlo Ersek
2016-12-02 11:54   ` Igor Mammedov
2016-12-02 12:00     ` Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 6/7] hw/isa/lpc_ich9: add broadcast SMI feature Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 7/7] hw/i386/pc_q35: advertise broadcast SMI if VCPU hotplug is turned off Laszlo Ersek
2016-12-01 19:13   ` Eduardo Habkost
2016-12-01 20:42     ` Laszlo Ersek
2016-12-01 20:53       ` Eduardo Habkost
2016-12-02 12:18       ` Igor Mammedov
2016-12-02 19:32         ` Laszlo Ersek
2016-12-20 23:01 ` [Qemu-devel] [PATCH v4 0/7] q35: add negotiable broadcast SMI no-reply
2016-12-21 15:22   ` [Qemu-devel] checkpatch.pl false positive (was Re: [PATCH v4 0/7] q35: add negotiable broadcast SMI) Eduardo Habkost
2016-12-21 17:47     ` Paolo Bonzini
2016-12-21 18:01       ` Eduardo Habkost
2016-12-21 18:08         ` Paolo Bonzini
2016-12-21 18:19           ` Eduardo Habkost
2017-01-10 15:06 ` [Qemu-devel] [PATCH v4 0/7] q35: add negotiable broadcast SMI Michael S. Tsirkin
2017-01-10 15:23   ` Laszlo Ersek
2017-01-10 16:05     ` Michael S. Tsirkin
2017-01-10 16:19       ` Laszlo Ersek
2017-01-10 16:21     ` Igor Mammedov
2017-01-10 16:30       ` Laszlo Ersek

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=3da2baa9-9fa6-7802-fe56-afa02a892a07@redhat.com \
    --to=lersek@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=somlo@cmu.edu \
    /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).