xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Manish Jaggi <mjaggi@caviumnetworks.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andre Przywara <andre.przywara@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Punit Agrawal <punit.agrawal@arm.com>
Cc: nd@arm.com
Subject: Re: [RFC v2][PATCH] arm-acpi: Add ITS Support for Dom0
Date: Fri, 9 Jun 2017 09:39:36 +0100	[thread overview]
Message-ID: <8b1715ab-47c0-3f5b-775f-56e14dbe9187@arm.com> (raw)
In-Reply-To: <2a6f5dd6-68b8-91d3-b2aa-15568b53a1e2@caviumnetworks.com>



On 09/06/2017 07:48, Manish Jaggi wrote:
>
> On 6/8/2017 7:28 PM, Julien Grall wrote:
>> Hi,
> Hello Julien,

Hello,

>>> +    list_for_each_entry(its_data, &host_its_list, entry)
>>> +    {
>>
>> Pointless {
>>
>>> +        size += sizeof(struct acpi_madt_generic_translator);
>>> +    }
> Just for readability of code.

You have indentation for that. So I don't think it helps.

>>
>> Same here + add a newline.
>>
> Sure.
>>> +    return size;
>>> +}
>>> +
>>> +u32 gicv3_its_make_hwdom_madt(u8 *base_ptr, u32 offset)
>>> +{
>>> +    struct acpi_madt_generic_translator *gic_its;
>>> +    const struct host_its *its_data;
>>> +    u32 table_len = offset, size;
>>> +
>>> +    /* Update GIC ITS information in hardware domain's MADT */
>>> +    list_for_each_entry(its_data, &host_its_list, entry)
>>> +    {
>>> +        size = sizeof(struct acpi_madt_generic_translator);
>>> +        gic_its = (struct acpi_madt_generic_translator *)(base_ptr +
>>> table_len);
>>
>> This line is likely too long.
>>
> I will check it.
>>> +        gic_its->header.type = ACPI_MADT_TYPE_GENERIC_TRANSLATOR;
>>> +        gic_its->header.length = size;
>>> +        gic_its->base_address = its_data->addr;
>>
>> On the previous patch you had:
>>
>> gic_its->translation_id = its_data->translation_id;
>>
>> I asked to explain why you need to have the same ID as the host. And
>> now you dropped it. This does not match the spec (Table 5-67 in ACPI
>> 6.1):
>>
>> "GIC ITS ID. In a system with multiple GIC ITS units, this value must
>> be unique to each one."
>>
>> But here, the ITS ID will not be unique. So why did you dropped it?
>>
> The reason I dropped it from its_data as I was not setting it. So it
> doesn't belong there.

Where would it belong then?

This function is used to generate ACPI tables for the hardware domain.


> Will the below code be ok?

If you noticed, I didn't say this code is wrong. Instead I asked why you 
use the same ID. Meaning, is there anything in the DSDT requiring this 
value?

> + int tras_id = 0;

unsigned.

> + list_for_each_entry(its_data, &host_its_list, entry)
> + {
> +    gic_its->translation_id = ++trans_id;

You start the translation ID at 1. Why?

>
>>> +        table_len +=  size;
>>> +    }
>>> +    return table_len;
>>> +}
>>> +
>>>  /*
>>>   * Create the respective guest DT nodes from a list of host ITSes.
>>>   * This copies the reg property, so the guest sees the ITS at the same
>>> address
>>> @@ -992,6 +1045,26 @@ int gicv3_its_make_hwdom_dt_nodes(const struct
>>> domain *d,
>>>      return res;
>>>  }
>>>
>>> +int gicv3_its_acpi_init(struct acpi_subtable_header *header, const
>>> unsigned long end)
>>
>> ACPI is an option and is not able by default. Please make sure that
>> this code build without ACPI. Likely this means surrounding with
>> #ifdef CONFIG_ACPI.
> I will get compiled but not called. Do you still want to put ifdef, i
> can add that.

All ACPIs functions are protected by ifdef. So this one should be as well.

>>
>>> +{
>>> +    struct acpi_madt_generic_translator *its_entry;
>>> +    struct host_its *its_data;
>>> +
>>> +    its_data = xzalloc(struct host_its);
>>> +    if (!its_data)
>>
>> Coding style.
>>
> Sure.
>>> +        return -1;
>>> +
>>> +    its_entry = (struct acpi_madt_generic_translator *)header;
>>> +    its_data->addr  = its_entry->base_address;
>>> +    its_data->size = ACPI_GICV3_ITS_MEM_SIZE;
>>> +
>>> +    spin_lock_init(&its_data->cmd_lock);
>>> +
>>> +    printk("GICv3: Found ITS @0x%lx\n", its_data->addr);
>>> +
>>> +    list_add_tail(&its_data->entry, &host_its_list);
>>
>> As said on v1, likely you could re-use factorize a part of
>> gicv3_its_dt_init to avoid implementing twice the initialization.
>>
> For this I have a different opinion.

Why didn't you state it on the previous version? I usually interpret a 
non-answer as an acknowledgment.

> gicv3_its_dt_init has a loop  dt_for_each_child_node(node, its) while
> gicv3_its_acpi_init is a callback.
> Moreover,  apart from xzalloc and list_add_tail most of the code is
> different. so IMHO keeping them separate is better.

You still set addr and size as in the DT counterpart. Also, this is a 
call to forget to initialize a field if we decided to extend the 
structure host_its. So I still don't see any reason to open-code it and 
take the risk to introduce bug in the future...

>> Also newline.
>>
>>> +    return 0;
>>> +}
>>
>> Newline here.
> Sure.
>>
>>>  /* Scan the DT for any ITS nodes and create a list of host ITSes out of
>>> it. */
>>>  void gicv3_its_dt_init(const struct dt_device_node *node)
>>>  {
>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>> index c927306..f0f6d12 100644
>>> --- a/xen/arch/arm/gic-v3.c
>>> +++ b/xen/arch/arm/gic-v3.c
>>> @@ -1333,9 +1333,8 @@ static int gicv3_iomem_deny_access(const struct
>>> domain *d)
>>>          return iomem_deny_access(d, mfn, mfn + nr);
>>>      }
>>>
>>> -    return 0;
>>> +    return gicv3_its_deny_access(d);
>>
>> Copying my answer from v1 for convenience:
>>
>>     if ( vbase != INVALID_PADDR )
>>     {
>>         mfn = vbase >> PAGE_SHIFT;
>>         nr = DIV_ROUND_UP(csize, PAGE_SIZE);
>>         return iomem_deny_access(d, mfn, mfn + nr);
>>     }
>>
>> When GICv3 is able to support GICv2, vbase will be valid and the code
>> will bail out after denying access to the GICV. So the ITS regions
>> will not be denied.
>>
> Ok, got your point. Would the below code be ok?

LGTM.

> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index c927306..a3d1eff 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1308,6 +1308,13 @@ static int gicv3_iomem_deny_access(const struct
> domain *d)
>      if ( rc )
>          return rc;
>
> +    if ( gicv3_its_host_has_its() )
> +    {
> +        rc = gicv3_its_deny_access(d);
> +        if ( rc )
> +            return rc;
> +    }
> +
>      for ( i = 0; i < gicv3.rdist_count; i++ )
>      {
>          mfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
>>>  }
>>> -
>>
>> Again, why did you drop this newline?
> I will fix it
>>
>>>  #ifdef CONFIG_ACPI
>>>  static void __init
>>>  gic_acpi_add_rdist_region(paddr_t base, paddr_t size, bool
>>> single_rdist)
>>> @@ -1374,6 +1373,7 @@ static int gicv3_make_hwdom_madt(const struct
>>> domain *d, u32 offset)
>>>      for ( i = 0; i < d->max_vcpus; i++ )
>>>      {
>>>          gicc = (struct acpi_madt_generic_interrupt *)(base_ptr +
>>> table_len);
>>> +
>>
>> As said on v1, spurious change.
> No. I wanted to add it intentionally. for a better code readability.

A general and simple rule is to separate code clean-up with new 
functionality. This is not a new functionality and therefore should not 
be there.

>>
>>>          ACPI_MEMCPY(gicc, host_gicc, size);
>>>          gicc->cpu_interface_number = i;
>>>          gicc->uid = i;
>>> @@ -1399,7 +1399,7 @@ static int gicv3_make_hwdom_madt(const struct
>>> domain *d, u32 offset)
>>>          gicr->length = d->arch.vgic.rdist_regions[i].size;
>>>          table_len += size;
>>>      }
>>> -
>>
>> Again why did you drop the newline?
> I will fix it
>>
>>> +    table_len = gicv3_its_make_hwdom_madt(base_ptr, table_len);
>>>      return table_len;
>>>  }
>>>
>>> @@ -1567,6 +1567,9 @@ static void __init gicv3_acpi_init(void)
>>>
>>>      gicv3.rdist_stride = 0;
>>>
>>> +    acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
>>> +                          gicv3_its_acpi_init, 0);
>>
>> As said on v1, acpi_table_parse_madt may return an error. Why this is
>> not checked?
>>
> I missed that, I will add it,
>>> +
>>>      /*
>>>       * In ACPI, 0 is considered as the invalid address. However the
>>> rest
>>>       * of the initialization rely on the invalid address to be
>>> @@ -1585,6 +1588,7 @@ static void __init gicv3_acpi_init(void)
>>>      else
>>>          vsize = GUEST_GICC_SIZE;
>>>
>>> +
>>
>> As said on v1, this is a spurious newline.
> ok
>>
>>>  }
>>>  #else
>>>  static void __init gicv3_acpi_init(void) { }
>>> diff --git a/xen/include/asm-arm/gic_v3_its.h
>>> b/xen/include/asm-arm/gic_v3_its.h
>>> index d2a3e53..b72aec2 100644
>>> --- a/xen/include/asm-arm/gic_v3_its.h
>>> +++ b/xen/include/asm-arm/gic_v3_its.h
>>> @@ -105,6 +105,7 @@
>>>
>>>  #include <xen/device_tree.h>
>>>  #include <xen/rbtree.h>
>>> +#include <xen/acpi.h>
>>>
>>>  #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
>>>  #define HOST_ITS_USES_PTA               (1U << 1)
>>> @@ -134,6 +135,7 @@ extern struct list_head host_its_list;
>>>
>>>  /* Parse the host DT and pick up all host ITSes. */
>>>  void gicv3_its_dt_init(const struct dt_device_node *node);
>>> +int  gicv3_its_acpi_init(struct acpi_subtable_header *header, const
>>> unsigned long end);
>>
>> This will likely need an #ifdef CONFIG_ACPI. And also a stub would be
>> required if ITS is disabled.
>>
> Sorry didnt got your point. on ifdef.

Look how gicv3_its_dt_init has been introduced. There is a stub for when 
ITS is not built-in. Furthermore, the function is ACPI specific are 
therefore should be protected with #ifdef CONFIG_ACPI.

> I can add a check gicv3_its_host_has_its() before calling
> gicv3_its_acpi_init, would that be ok?

gicv3_its_host_has_its will always return false as it is rely on the 
list of ITS to be populated. However, this will be populated by 
gicv3_its_acpi_init...

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-06-09  8:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08 13:03 [RFC v2][PATCH] arm-acpi: Add ITS Support for Dom0 Manish Jaggi
2017-06-08 13:58 ` Julien Grall
2017-06-09  6:48   ` Manish Jaggi
2017-06-09  8:39     ` Julien Grall [this message]
2017-06-13 11:02       ` Manish Jaggi
2017-06-13 11:28         ` Julien Grall
2017-06-13 11:44           ` Manish Jaggi
2017-06-13 11:58             ` Julien Grall

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=8b1715ab-47c0-3f5b-775f-56e14dbe9187@arm.com \
    --to=julien.grall@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=mjaggi@caviumnetworks.com \
    --cc=nd@arm.com \
    --cc=punit.agrawal@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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).