All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: yang.zhong@intel.com, peter.maydell@linaro.org,
	kevin.tian@intel.com, tnowicki@marvell.com, mst@redhat.com,
	jean-philippe.brucker@arm.com, quintela@redhat.com,
	qemu-devel@nongnu.org, peterx@redhat.com, dgilbert@redhat.com,
	bharatb.linux@gmail.com, qemu-arm@nongnu.org,
	eric.auger.pro@gmail.com
Subject: Re: [PATCH for-5.0 v11 12/20] qapi: Introduce DEFINE_PROP_INTERVAL
Date: Thu, 12 Dec 2019 16:13:06 +0100	[thread overview]
Message-ID: <66ae0999-bdd8-6b54-f550-f036dafc982b@redhat.com> (raw)
In-Reply-To: <87wob17n6j.fsf@dusky.pond.sub.org>

Hi Markus,

On 12/12/19 1:17 PM, Markus Armbruster wrote:
> Eric Auger <eric.auger@redhat.com> writes:
> 
>> Introduce a new property defining a labelled interval:
>> <low address>,<high address>,label.
>>
>> This will be used to encode reserved IOVA regions. The label
>> is left undefined to ease reuse accross use cases.
> 
> What does the last sentence mean?
The dilemma was shall I specialize this property such as ReservedRegion
or shall I leave it generic enough to serve somebody else use case. I
first chose the latter but now I think I should rather call it something
like ReservedRegion as in any case it has addresses and an integer label.
> 
>> For instance, in virtio-iommu use case, reserved IOVA regions
>> will be passed by the machine code to the virtio-iommu-pci
>> device (an array of those). The label will match the
>> virtio_iommu_probe_resv_mem subtype value:
>> - VIRTIO_IOMMU_RESV_MEM_T_RESERVED (0)
>> - VIRTIO_IOMMU_RESV_MEM_T_MSI (1)
>>
>> This is used to inform the virtio-iommu-pci device it should
>> bypass the MSI region: 0xfee00000, 0xfeefffff, 1.
> 
> So the "label" part of "<low address>,<high address>,label" is a number?
yes it is.
> 
> Is a number appropriate for your use case, or would an enum be better?
I think a number is OK. There might be other types of reserved regions
in the future. Also if we want to allow somebody else to reuse that
property in another context, I would rather leave it open?
> 
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com> ---
>> hw/core/qdev-properties.c | 90 ++++++++++++++++++++++++++++++++++++
>> include/exec/memory.h | 6 +++ include/hw/qdev-properties.h | 3 ++
>> include/qemu/typedefs.h | 1 + 4 files changed, 100 insertions(+)
> 
> Subject has 'qapi:', but it's actually about qdev.  Please adjust the subject.
OK
> 
>> diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
>> index ac28890e5a..8d70f34e37 100644
>> --- a/hw/core/qdev-properties.c
>> +++ b/hw/core/qdev-properties.c
>> @@ -13,6 +13,7 @@
>>  #include "qapi/visitor.h"
>>  #include "chardev/char.h"
>>  #include "qemu/uuid.h"
>> +#include "qemu/cutils.h"
>>  
>>  void qdev_prop_set_after_realize(DeviceState *dev, const char *name,
>>                                    Error **errp)
>> @@ -585,6 +586,95 @@ const PropertyInfo qdev_prop_macaddr = {
>>      .set   = set_mac,
>>  };
>>  
>> +/* --- Labelled Interval --- */
>> +
>> +/*
>> + * accepted syntax versions:
> 
> "versions"?
s/versions/version
> 
>> + *   <low address>,<high address>,<type>
>> + *   where low/high addresses are uint64_t in hexa (feat. 0x prefix)
> 
> "hexa" is not a word.
OK
> 
> I'm afraid I don't get the parenthesis.
I wanted to mention the 0x prefix was needed but as you mentionned below
it is not needed actually.
> 
>> + *   and type is an unsigned integer
>> + */
>> +static void get_interval(Object *obj, Visitor *v, const char *name,
>> +                         void *opaque, Error **errp)
>> +{
>> +    DeviceState *dev = DEVICE(obj);
>> +    Property *prop = opaque;
>> +    Interval *interval = qdev_get_prop_ptr(dev, prop);
>> +    char buffer[64];
>> +    char *p = buffer;
>> +
>> +    Snprintf(buffer, sizeof(buffer), "0x%"PRIx64",0x%"PRIx64",%d",
>> +             interval->low, interval->high, interval->type);
> 
> interval->type is unsigned.  Use %u, not %d.
OK
> 
>> +
>> +    visit_type_str(v, name, &p, errp);
>> +}
>> +
>> +static void set_interval(Object *obj, Visitor *v, const char *name,
>> +                         void *opaque, Error **errp)
>> +{
>> +    DeviceState *dev = DEVICE(obj);
>> +    Property *prop = opaque;
>> +    Interval *interval = qdev_get_prop_ptr(dev, prop);
>> +    Error *local_err = NULL;
>> +    unsigned int type;
>> +    gchar **fields;
>> +    uint64_t addr;
>> +    char *str;
>> +    int ret;
>> +
>> +    if (dev->realized) {
>> +        qdev_prop_set_after_realize(dev, name, errp);
>> +        return;
>> +    }
>> +
>> +    visit_type_str(v, name, &str, &local_err);
>> +    if (local_err) {
>> +        error_propagate(errp, local_err);
>> +        return;
>> +    }
>> +
>> +    fields = g_strsplit(str, ",", 3);
>> +
>> +    ret = qemu_strtou64(fields[0], NULL, 16, &addr);
> 
> Aha, the 0x prefix is actually optional.
> 
>> +    if (!ret) {
>> +        interval->low = addr;
>> +    } else {
>> +        error_setg(errp, "Failed to decode interval low addr");
>> +        error_append_hint(errp,
>> +                          "should be an address in hexa with 0x prefix\n");
> 
> "hexa" is not a word, and the 0x prefix is actually optional.
OK
> 
>> +        goto out;
>> +    }
> 
> I prefer
> 
>        if (error) {
>            handle error
>            bail out
>        }
>        handle success
> 
> over
> 
>        if (success) {
>            handle success
>        if (error) {
>            handle error
>            bail out
>        }
> 
> In this case:
> 
>        if (ret) {
>            error_setg(errp, "Failed to decode interval low addr");
>            error_append_hint(errp,
>                              "should be an address in hexa with 0x prefix\n");
>            goto out;
>        }
>        interval->low = addr;
OK
> 
> 
>> +
>> +    ret = qemu_strtou64(fields[1], NULL, 16, &addr);
> 
> Crash if @str doesn't contain ',', because the g_strsplit(str, ",", 3)
> yields { [0] = str, NULL }.
> 
>> +    if (!ret) {
>> +        interval->high = addr;
>> +    } else {
>> +        error_setg(errp, "Failed to decode interval high addr");
>> +        error_append_hint(errp,
>> +                          "should be an address in hexa with 0x prefix\n");
>> +        goto out;
>> +    }
>> +
>> +    ret = qemu_strtoui(fields[2], NULL, 10, &type);
> 
> Likewise, crash if @str contains only one ','.
> 
> I wouldn't use g_strsplit() here.  After
> 
>     ret = qemu_strtoui(str, &endptr, 16, &interval->low);
> 
> @endptr points behind the address.  So:
> 
>     if (ret || *endptr != ',') {
>         handle error ...
>         goto out
>     }
> 
>     ret = qemu_strtoui(endptr + 1, &endptr, 16, &interval->high);
> 
> and so forth.
> 
> Note that the if (ret || *endptr != ',') checks for two distinct errors.
> Distinct error messages might be more helpful.
OK I will revisit that.
> 
>> +    if (!ret) {
>> +        interval->type = type;
>> +    } else {
>> +        error_setg(errp, "Failed to decode interval type");
>> +        error_append_hint(errp, "should be an unsigned int in decimal\n");
>> +    }
>> +out:
>> +    g_free(str);
>> +    g_strfreev(fields);
>> +    return;
>> +}
>> +
>> +const PropertyInfo qdev_prop_interval = {
>> +    .name  = "labelled_interval",
>> +    .description = "Labelled interval, example: 0xFEE00000,0xFEEFFFFF,0",
>> +    .get   = get_interval,
>> +    .set   = set_interval,
>> +};
>> +
>>  /* --- on/off/auto --- */
>>  
>>  const PropertyInfo qdev_prop_on_off_auto = {
>> diff --git a/include/exec/memory.h b/include/exec/memory.h
>> index e499dc215b..e238d1c352 100644
>> --- a/include/exec/memory.h
>> +++ b/include/exec/memory.h
>> @@ -57,6 +57,12 @@ struct MemoryRegionMmio {
>>      CPUWriteMemoryFunc *write[3];
>>  };
>>  
>> +struct Interval {
>> +    hwaddr low;
>> +    hwaddr high;
>> +    unsigned int type;
>> +};
> 
> This isn't an interval.  An interval consists of two values, not three.
> 
> The third one is called "type" here, and "label" elsewhere.  Pick one
> and stick to it.
> 
> Then pick a name for the triple.  Elsewhere, you call it "labelled
> interval".
I would tend to use ReservedRegion now if nobody objects.

Thank you for the review!


Eric
> 
>> +
>>  typedef struct IOMMUTLBEntry IOMMUTLBEntry;
>>  
>>  /* See address_space_translate: bit 0 is read, bit 1 is write.  */
>> diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
>> index c6a8cb5516..2ba7c8711b 100644
>> --- a/include/hw/qdev-properties.h
>> +++ b/include/hw/qdev-properties.h
>> @@ -20,6 +20,7 @@ extern const PropertyInfo qdev_prop_chr;
>>  extern const PropertyInfo qdev_prop_tpm;
>>  extern const PropertyInfo qdev_prop_ptr;
>>  extern const PropertyInfo qdev_prop_macaddr;
>> +extern const PropertyInfo qdev_prop_interval;
>>  extern const PropertyInfo qdev_prop_on_off_auto;
>>  extern const PropertyInfo qdev_prop_losttickpolicy;
>>  extern const PropertyInfo qdev_prop_blockdev_on_error;
>> @@ -202,6 +203,8 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
>>      DEFINE_PROP(_n, _s, _f, qdev_prop_drive_iothread, BlockBackend *)
>>  #define DEFINE_PROP_MACADDR(_n, _s, _f)         \
>>      DEFINE_PROP(_n, _s, _f, qdev_prop_macaddr, MACAddr)
>> +#define DEFINE_PROP_INTERVAL(_n, _s, _f)         \
>> +    DEFINE_PROP(_n, _s, _f, qdev_prop_interval, Interval)
>>  #define DEFINE_PROP_ON_OFF_AUTO(_n, _s, _f, _d) \
>>      DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_on_off_auto, OnOffAuto)
>>  #define DEFINE_PROP_LOSTTICKPOLICY(_n, _s, _f, _d) \
>> diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
>> index 375770a80f..a827c9a3fe 100644
>> --- a/include/qemu/typedefs.h
>> +++ b/include/qemu/typedefs.h
>> @@ -58,6 +58,7 @@ typedef struct ISABus ISABus;
>>  typedef struct ISADevice ISADevice;
>>  typedef struct IsaDma IsaDma;
>>  typedef struct MACAddr MACAddr;
>> +typedef struct Interval Interval;
>>  typedef struct MachineClass MachineClass;
>>  typedef struct MachineState MachineState;
>>  typedef struct MemoryListener MemoryListener;
> 
> 



  reply	other threads:[~2019-12-12 15:14 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22 18:29 [PATCH for-5.0 v11 00/20] VIRTIO-IOMMU device Eric Auger
2019-11-22 18:29 ` [PATCH for-5.0 v11 01/20] migration: Support QLIST migration Eric Auger
2019-11-27 11:46   ` Dr. David Alan Gilbert
2020-01-08 13:19     ` Juan Quintela
2020-01-08 13:40       ` Auger Eric
2020-01-08 13:51         ` Juan Quintela
2020-01-08 14:02           ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 02/20] virtio-iommu: Add skeleton Eric Auger
2019-12-10 16:31   ` Jean-Philippe Brucker
2019-12-19 10:31     ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 03/20] virtio-iommu: Decode the command payload Eric Auger
2019-12-10 16:32   ` Jean-Philippe Brucker
2019-12-10 19:14   ` Peter Xu
2019-11-22 18:29 ` [PATCH for-5.0 v11 04/20] virtio-iommu: Add the iommu regions Eric Auger
2019-12-10 16:34   ` Jean-Philippe Brucker
2019-12-19 18:11     ` Auger Eric
2019-12-10 19:18   ` Peter Xu
2019-11-22 18:29 ` [PATCH for-5.0 v11 05/20] virtio-iommu: Endpoint and domains structs and helpers Eric Auger
2019-12-10 16:37   ` Jean-Philippe Brucker
2019-12-19 18:31     ` Auger Eric
2019-12-20 17:00       ` Jean-Philippe Brucker
2019-12-23  9:11         ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 06/20] virtio-iommu: Implement attach/detach command Eric Auger
2019-12-10 16:41   ` Jean-Philippe Brucker
2019-12-23  9:14     ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 07/20] virtio-iommu: Implement map/unmap Eric Auger
2019-12-10 16:43   ` Jean-Philippe Brucker
2019-12-23  9:42     ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 08/20] virtio-iommu: Implement translate Eric Auger
2019-12-10 16:43   ` Jean-Philippe Brucker
2019-12-10 19:33   ` Peter Xu
2019-12-19 10:30     ` Auger Eric
2019-12-19 13:33       ` Peter Xu
2019-12-19 14:38         ` Auger Eric
2019-12-19 14:49           ` Peter Xu
2019-12-19 15:09             ` Auger Eric
2019-12-20 16:26               ` Jean-Philippe Brucker
2019-12-20 16:51                 ` Peter Xu
2020-01-06 17:06                   ` Jean-Philippe Brucker
2020-01-06 17:58                     ` Peter Xu
2020-01-07 10:10                       ` Jean-Philippe Brucker
2020-01-08 16:55                         ` Auger Eric
2020-01-09  8:47                           ` Jean-Philippe Brucker
2020-01-09  8:58                             ` Auger Eric
2020-01-09 10:40                               ` Jean-Philippe Brucker
2020-01-09 11:01                                 ` Auger Eric
2020-01-09 11:15                                   ` Jean-Philippe Brucker
2020-01-09 11:32                                     ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 09/20] virtio-iommu: Implement fault reporting Eric Auger
2019-12-10 16:44   ` Jean-Philippe Brucker
2019-11-22 18:29 ` [PATCH for-5.0 v11 10/20] virtio-iommu-pci: Add virtio iommu pci support Eric Auger
2019-12-10 16:44   ` Jean-Philippe Brucker
2019-11-22 18:29 ` [PATCH for-5.0 v11 11/20] hw/arm/virt: Add the virtio-iommu device tree mappings Eric Auger
2019-12-10 16:45   ` Jean-Philippe Brucker
2019-11-22 18:29 ` [PATCH for-5.0 v11 12/20] qapi: Introduce DEFINE_PROP_INTERVAL Eric Auger
2019-11-22 19:03   ` Dr. David Alan Gilbert
2019-11-25 13:12     ` Auger Eric
2019-12-12 12:17   ` Markus Armbruster
2019-12-12 15:13     ` Auger Eric [this message]
2019-12-13 10:03       ` Markus Armbruster
2019-11-22 18:29 ` [PATCH for-5.0 v11 13/20] virtio-iommu: Implement probe request Eric Auger
2019-12-10 16:46   ` Jean-Philippe Brucker
2019-12-10 19:36   ` Peter Xu
2019-11-22 18:29 ` [PATCH for-5.0 v11 14/20] virtio-iommu: Handle reserved regions in the translation process Eric Auger
2019-12-10 16:46   ` Jean-Philippe Brucker
2019-12-10 19:39   ` Peter Xu
2019-11-22 18:29 ` [PATCH for-5.0 v11 15/20] virtio-iommu-pci: Add array of Interval properties Eric Auger
2019-12-10 16:47   ` Jean-Philippe Brucker
2019-11-22 18:29 ` [PATCH for-5.0 v11 16/20] hw/arm/virt-acpi-build: Introduce fill_iort_idmap helper Eric Auger
2019-12-10 16:47   ` Jean-Philippe Brucker
2019-11-22 18:29 ` [PATCH for-5.0 v11 17/20] hw/arm/virt-acpi-build: Add virtio-iommu node in IORT table Eric Auger
2019-12-10 16:48   ` Jean-Philippe Brucker
2019-11-22 18:29 ` [PATCH for-5.0 v11 18/20] virtio-iommu: Support migration Eric Auger
2019-11-27 12:06   ` Dr. David Alan Gilbert
2019-12-10 16:50   ` Jean-Philippe Brucker
2019-12-19 11:03     ` Auger Eric
2019-12-10 20:01   ` Peter Xu
2019-12-24  7:39     ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 19/20] pc: Add support for virtio-iommu-pci Eric Auger
2019-12-10 16:50   ` Jean-Philippe Brucker
2019-12-24  7:39     ` Auger Eric
2020-01-09 12:02   ` Michael S. Tsirkin
2020-01-09 13:34     ` Auger Eric
2019-11-22 18:29 ` [PATCH for-5.0 v11 20/20] tests: Add virtio-iommu test Eric Auger
2019-11-22 21:56 ` [PATCH for-5.0 v11 00/20] VIRTIO-IOMMU device no-reply
2019-12-11 16:40 ` Michael S. Tsirkin
2019-12-11 16:48   ` Auger Eric
2019-12-11 20:40     ` Michael S. Tsirkin
2019-12-12 15:05       ` Auger Eric

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=66ae0999-bdd8-6b54-f550-f036dafc982b@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=armbru@redhat.com \
    --cc=bharatb.linux@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=tnowicki@marvell.com \
    --cc=yang.zhong@intel.com \
    /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.