xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Vijay Kilari <vijay.kilari@gmail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [RFC PATCH 11/24] ARM: vGICv3: handle virtual LPI pending and property tables
Date: Thu, 3 Nov 2016 20:21:15 +0000	[thread overview]
Message-ID: <1546eda5-fc0c-281b-a8dc-c6ea1ed188eb@arm.com> (raw)
In-Reply-To: <CALicx6uRU9BUzZdOXt5DaRCYGrZptTnkmH8jhuxfrTNsZsej5w@mail.gmail.com>

Hi,

On 24/10/16 16:32, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>> Allow a guest to provide the address and size for the memory regions
>> it has reserved for the GICv3 pending and property tables.
>> We sanitise the various fields of the respective redistributor
>> registers and map those pages into Xen's address space to have easy
>> access.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  xen/arch/arm/vgic-v3.c        | 189 ++++++++++++++++++++++++++++++++++++++----
>>  xen/arch/arm/vgic.c           |   4 +
>>  xen/include/asm-arm/domain.h  |   7 +-
>>  xen/include/asm-arm/gic-its.h |  10 ++-
>>  xen/include/asm-arm/vgic.h    |   3 +
>>  5 files changed, 197 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>> index e9b6490..8fe8386 100644
>> --- a/xen/arch/arm/vgic-v3.c
>> +++ b/xen/arch/arm/vgic-v3.c
>> @@ -20,12 +20,14 @@
>>
>>  #include <xen/bitops.h>
>>  #include <xen/config.h>
>> +#include <xen/domain_page.h>
>>  #include <xen/lib.h>
>>  #include <xen/init.h>
>>  #include <xen/softirq.h>
>>  #include <xen/irq.h>
>>  #include <xen/sched.h>
>>  #include <xen/sizes.h>
>> +#include <xen/vmap.h>
>>  #include <asm/current.h>
>>  #include <asm/mmio.h>
>>  #include <asm/gic_v3_defs.h>
>> @@ -228,12 +230,14 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
>>          goto read_reserved;
>>
>>      case VREG64(GICR_PROPBASER):
>> -        /* LPI's not implemented */
>> -        goto read_as_zero_64;
>> +        if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>> +        *r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
>> +        return 1;
>>
>>      case VREG64(GICR_PENDBASER):
>> -        /* LPI's not implemented */
>> -        goto read_as_zero_64;
>> +        if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>> +        *r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
>> +        return 1;
>>
>>      case 0x0080:
>>          goto read_reserved;
>> @@ -301,11 +305,6 @@ bad_width:
>>      domain_crash_synchronous();
>>      return 0;
>>
>> -read_as_zero_64:
>> -    if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>> -    *r = 0;
>> -    return 1;
>> -
>>  read_as_zero_32:
>>      if ( dabt.size != DABT_WORD ) goto bad_width;
>>      *r = 0;
>> @@ -330,11 +329,149 @@ read_unknown:
>>      return 1;
>>  }
>>
>> +static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
>> +                                    int field_shift,
>> +                                    uint64_t (*sanitise_fn)(uint64_t))
>> +{
>> +    uint64_t field = (reg & field_mask) >> field_shift;
>> +
>> +    field = sanitise_fn(field) << field_shift;
>> +    return (reg & ~field_mask) | field;
>> +}
>> +
>> +/* We want to avoid outer shareable. */
>> +static uint64_t vgic_sanitise_shareability(uint64_t field)
>> +{
>> +    switch (field) {
>> +    case GIC_BASER_OuterShareable:
>> +        return GIC_BASER_InnerShareable;
>> +    default:
>> +        return field;
>> +    }
>> +}
>> +
>> +/* Avoid any inner non-cacheable mapping. */
>> +static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
>> +{
>> +    switch (field) {
>> +    case GIC_BASER_CACHE_nCnB:
>> +    case GIC_BASER_CACHE_nC:
>> +        return GIC_BASER_CACHE_RaWb;
>> +    default:
>> +        return field;
>> +    }
>> +}
>> +
>> +/* Non-cacheable or same-as-inner are OK. */
>> +static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
>> +{
>> +    switch (field) {
>> +    case GIC_BASER_CACHE_SameAsInner:
>> +    case GIC_BASER_CACHE_nC:
>> +        return field;
>> +    default:
>> +        return GIC_BASER_CACHE_nC;
>> +    }
>> +}
>> +
>> +static uint64_t sanitize_propbaser(uint64_t reg)
>> +{
>> +    reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
>> +                              GICR_PROPBASER_SHAREABILITY_SHIFT,
>> +                              vgic_sanitise_shareability);
>> +    reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
>> +                              GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
>> +                              vgic_sanitise_inner_cacheability);
>> +    reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
>> +                              GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
>> +                              vgic_sanitise_outer_cacheability);
>> +
>> +    reg &= ~PROPBASER_RES0_MASK;
>> +    reg &= ~GENMASK(51, 48);
>> +    return reg;
>> +}
>> +
>> +static uint64_t sanitize_pendbaser(uint64_t reg)
>> +{
>> +    reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
>> +                              GICR_PENDBASER_SHAREABILITY_SHIFT,
>> +                              vgic_sanitise_shareability);
>> +    reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
>> +                              GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
>> +                              vgic_sanitise_inner_cacheability);
>> +    reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
>> +                              GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
>> +                              vgic_sanitise_outer_cacheability);
>> +
>> +    reg &= ~PENDBASER_RES0_MASK;
>> +    reg &= ~GENMASK(51, 48);
>> +    return reg;
>> +}
>> +
>> +/*
>> + * Allow mapping some parts of guest memory into Xen's VA space to have easy
>> + * access to it. This is to allow ITS configuration data to be held in
>> + * guest memory and avoid using Xen memory for that.
>> + */
>> +void *map_guest_pages(struct domain *d, paddr_t guest_addr, int nr_pages)
>    I think this file is not right place to put this generic function

Yeah, possibly.

>> +{
>> +    mfn_t onepage;
>> +    mfn_t *pages;
>> +    int i;
>> +    void *ptr;
>> +
>> +    /* TODO: free previous mapping, change prototype? use get-put-put? */
>> +
>> +    guest_addr &= PAGE_MASK;
>> +
>> +    if ( nr_pages == 1 )
>> +    {
>> +        pages = &onepage;
>> +    } else
>> +    {
>> +        pages = xmalloc_array(mfn_t, nr_pages);
>> +        if ( !pages )
>> +            return NULL;
>> +    }
>> +
>> +    for (i = 0; i < nr_pages; i++)
>> +    {
>> +        get_page_from_gfn(d, (guest_addr >> PAGE_SHIFT) + i, NULL, P2M_ALLOC);
> 
>              check return value of this function

Yes.

>> +        pages[i] = _mfn((guest_addr + i * PAGE_SIZE) >> PAGE_SHIFT);
>> +    }
>> +
>> +    ptr = vmap(pages, nr_pages);
>> +
>> +    if ( nr_pages > 1 )
>> +        xfree(pages);
>> +
>> +    return ptr;
>> +}
>> +
>> +void unmap_guest_pages(void *va, int nr_pages)
>       same here. Can be put in generic file p2m.c?
>> +{
>> +    paddr_t pa;
>> +    unsigned long i;
>> +
>> +    if ( !va )
>> +        return;
>> +
>> +    va = (void *)((uintptr_t)va & PAGE_MASK);
>> +    pa = virt_to_maddr(va);
>   can use _pa()

Do you mean __pa()? Which is defined to be exactly virt_to_maddr()?
I prefer the more verbose version, which is more readable, IMHO.

>> +
>> +    vunmap(va);
>> +    for (i = 0; i < nr_pages; i++)
>> +        put_page(mfn_to_page((pa >> PAGE_SHIFT) + i));
>> +
>> +    return;
>> +}
>> +
>>  static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>>                                            uint32_t gicr_reg,
>>                                            register_t r)
>>  {
>>      struct hsr_dabt dabt = info->dabt;
>> +    uint64_t reg;
>>
>>      switch ( gicr_reg )
>>      {
>> @@ -375,13 +512,37 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>>      case 0x0050:
>>          goto write_reserved;
>>
>> -    case VREG64(GICR_PROPBASER):
>> -        /* LPI is not implemented */
>> -        goto write_ignore_64;
>> +    case VREG64(GICR_PROPBASER): {
>> +        int nr_pages;
>> +
>> +        if ( info->dabt.size < DABT_WORD ) goto bad_width;
>> +        if ( v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED )
>> +            return 1;
>> +
>> +        reg = v->domain->arch.vgic.rdist_propbase;
>> +        vgic_reg64_update(&reg, r, info);
>> +        reg = sanitize_propbaser(reg);
>> +        v->domain->arch.vgic.rdist_propbase = reg;
>>
>> +        nr_pages = BIT((v->domain->arch.vgic.rdist_propbase & 0x1f) + 1) - 8192;
>              should be validated against HOST_LPIS?

I don't think so. The actual LPI numbers are totally independent between
host and Dom0.
So why and how should this be matched?

>> +        nr_pages = DIV_ROUND_UP(nr_pages, PAGE_SIZE);
>> +        unmap_guest_pages(v->domain->arch.vgic.proptable, nr_pages);
>> +        v->domain->arch.vgic.proptable = map_guest_pages(v->domain,
>> +                                                         reg & GENMASK(47, 12),
>> +                                                         nr_pages);
>> +        return 1;
>> +    }
>>      case VREG64(GICR_PENDBASER):
>> -        /* LPI is not implemented */
>> -        goto write_ignore_64;
>> +        if ( info->dabt.size < DABT_WORD ) goto bad_width;
> 
>    check on VGIC_V3_LPIS_ENABLED is required

Right, forgot this.

>> +       reg = v->arch.vgic.rdist_pendbase;
>> +       vgic_reg64_update(&reg, r, info);
>> +       reg = sanitize_pendbaser(reg);
>> +       v->arch.vgic.rdist_pendbase = reg;
>> +
>> +        unmap_guest_pages(v->arch.vgic.pendtable, 16);
>      why only 16 pages are unmapped?

Well, it matches the allocation below, but I agree that this should
match the advertised number of LPIs in GICD_TYPER.

Cheers,
Andre.

>> +       v->arch.vgic.pendtable = map_guest_pages(v->domain,
>> +                                                 reg & GENMASK(47, 12), 16);
>> +       return 1;
>>
>>      case 0x0080:
>>          goto write_reserved;
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index b961551..4d9304f 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -488,6 +488,10 @@ struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
>>          empty->pirq.irq = lpi;
>>      }
>>
>> +    /* Update the enabled status */
>> +    if ( gicv3_lpi_is_enabled(v->domain, lpi) )
>> +        set_bit(GIC_IRQ_GUEST_ENABLED, &empty->pirq.status);
>> +
>>      return &empty->pirq;
>>  }
>>
>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>> index ae8a9de..0cd3500 100644
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -109,6 +109,8 @@ struct arch_domain
>>          } *rdist_regions;
>>          int nr_regions;                     /* Number of rdist regions */
>>          uint32_t rdist_stride;              /* Re-Distributor stride */
>> +        uint64_t rdist_propbase;
>> +        uint8_t *proptable;
>>  #endif
>>      } vgic;
>>
>> @@ -247,7 +249,10 @@ struct arch_vcpu
>>
>>          /* GICv3: redistributor base and flags for this vCPU */
>>          paddr_t rdist_base;
>> -#define VGIC_V3_RDIST_LAST  (1 << 0)        /* last vCPU of the rdist */
>> +#define VGIC_V3_RDIST_LAST      (1 << 0)        /* last vCPU of the rdist */
>> +#define VGIC_V3_LPIS_ENABLED    (1 << 1)
>> +        uint64_t rdist_pendbase;
>> +        unsigned long *pendtable;
>>          uint8_t flags;
>>          struct list_head pending_lpi_list;
>>      } vgic;
>> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
>> index 1f881c0..3b2e5c0 100644
>> --- a/xen/include/asm-arm/gic-its.h
>> +++ b/xen/include/asm-arm/gic-its.h
>> @@ -139,7 +139,11 @@ int gicv3_lpi_drop_host_lpi(struct host_its *its,
>>
>>  static inline int gicv3_lpi_get_priority(struct domain *d, uint32_t lpi)
>>  {
>> -    return GIC_PRI_IRQ;
>> +    return d->arch.vgic.proptable[lpi - 8192] & 0xfc;
>> +}
>> +static inline bool gicv3_lpi_is_enabled(struct domain *d, uint32_t lpi)
>> +{
>> +    return d->arch.vgic.proptable[lpi - 8192] & LPI_PROP_ENABLED;
>>  }
>>
>>  #else
>> @@ -185,6 +189,10 @@ static inline int gicv3_lpi_get_priority(struct domain *d, uint32_t lpi)
>>  {
>>      return GIC_PRI_IRQ;
>>  }
>> +static inline bool gicv3_lpi_is_enabled(struct domain *d, uint32_t lpi)
>> +{
>> +    return false;
>> +}
>>
>>  #endif /* CONFIG_HAS_ITS */
>>
>> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>> index 4e29ba6..2b216cc 100644
>> --- a/xen/include/asm-arm/vgic.h
>> +++ b/xen/include/asm-arm/vgic.h
>> @@ -285,6 +285,9 @@ VGIC_REG_HELPERS(32, 0x3);
>>
>>  #undef VGIC_REG_HELPERS
>>
>> +void *map_guest_pages(struct domain *d, paddr_t guest_addr, int nr_pages);
>> +void unmap_guest_pages(void *va, int nr_pages);
>> +
>>  enum gic_sgi_mode;
>>
>>  /*
>> --
>> 2.9.0
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel
> 

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

  reply	other threads:[~2016-11-03 20:20 UTC|newest]

Thread overview: 144+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-28 18:24 [RFC PATCH 00/24] [FOR 4.9] arm64: Dom0 ITS emulation Andre Przywara
2016-09-28 18:24 ` [RFC PATCH 01/24] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT Andre Przywara
2016-10-26  1:11   ` Stefano Stabellini
2016-11-01 15:13   ` Julien Grall
2016-11-14 17:35     ` Andre Przywara
2016-11-23 15:39       ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 02/24] ARM: GICv3: allocate LPI pending and property table Andre Przywara
2016-10-24 14:28   ` Vijay Kilari
2016-11-02 16:22     ` Andre Przywara
2016-10-26  1:10   ` Stefano Stabellini
2016-11-10 15:29     ` Andre Przywara
2016-11-10 21:00       ` Stefano Stabellini
2016-11-01 17:22   ` Julien Grall
2016-11-15 11:32     ` Andre Przywara
2016-11-23 15:58       ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 03/24] ARM: GICv3 ITS: allocate device and collection table Andre Przywara
2016-10-09 13:55   ` Vijay Kilari
2016-10-10  9:05     ` Andre Przywara
2016-10-24 14:30   ` Vijay Kilari
2016-11-02 17:51     ` Andre Przywara
2016-10-26 22:57   ` Stefano Stabellini
2016-11-01 17:34     ` Julien Grall
2016-11-10 15:32     ` Andre Przywara
2016-11-10 21:06       ` Stefano Stabellini
2016-11-01 18:19   ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 04/24] ARM: GICv3 ITS: map ITS command buffer Andre Przywara
2016-10-24 14:31   ` Vijay Kilari
2016-10-26 23:03   ` Stefano Stabellini
2016-11-10 16:04     ` Andre Przywara
2016-11-02 13:38   ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 05/24] ARM: GICv3 ITS: introduce ITS command handling Andre Przywara
2016-10-26 23:55   ` Stefano Stabellini
2016-10-27 21:52     ` Stefano Stabellini
2016-11-10 15:57     ` Andre Przywara
2016-11-02 15:05   ` Julien Grall
2017-01-31  9:10     ` Andre Przywara
2017-01-31 10:23       ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 06/24] ARM: GICv3 ITS: introduce host LPI array Andre Przywara
2016-10-27 22:59   ` Stefano Stabellini
2016-11-02 15:14     ` Julien Grall
2016-11-10 17:22     ` Andre Przywara
2016-11-10 21:48       ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 07/24] ARM: GICv3 ITS: introduce device mapping Andre Przywara
2016-10-24 15:31   ` Vijay Kilari
2016-11-03 19:33     ` Andre Przywara
2016-10-28  0:08   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs Andre Przywara
2016-10-24 15:31   ` Vijay Kilari
2016-11-03 19:47     ` Andre Przywara
2016-10-28  1:04   ` Stefano Stabellini
2017-01-12 19:14     ` Andre Przywara
2017-01-13 19:37       ` Stefano Stabellini
2017-01-16  9:44         ` André Przywara
2017-01-16 19:16           ` Stefano Stabellini
2016-11-04 15:46   ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 09/24] ARM: GICv3: forward pending LPIs to guests Andre Przywara
2016-10-28  1:51   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 10/24] ARM: GICv3: enable ITS and LPIs on the host Andre Przywara
2016-10-28 23:07   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 11/24] ARM: vGICv3: handle virtual LPI pending and property tables Andre Przywara
2016-10-24 15:32   ` Vijay Kilari
2016-11-03 20:21     ` Andre Przywara [this message]
2016-11-04 11:53       ` Julien Grall
2016-10-29  0:39   ` Stefano Stabellini
2017-03-29 15:47     ` Andre Przywara
2016-11-02 17:18   ` Julien Grall
2016-11-02 17:41     ` Stefano Stabellini
2016-11-02 18:03       ` Julien Grall
2016-11-02 18:09         ` Stefano Stabellini
2017-01-31  9:10     ` Andre Przywara
2017-01-31 10:38       ` Julien Grall
2017-01-31 12:04         ` Andre Przywara
2016-09-28 18:24 ` [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits Andre Przywara
2016-10-09 14:20   ` Vijay Kilari
2016-10-10 10:38     ` Andre Przywara
2016-10-24 15:31   ` Vijay Kilari
2016-11-03 19:26     ` Andre Przywara
2016-11-04 12:07       ` Julien Grall
2016-11-03 17:50   ` Julien Grall
2016-11-08 23:54   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 13/24] ARM: vITS: handle CLEAR command Andre Przywara
2016-11-04 15:48   ` Julien Grall
2016-11-09  0:39   ` Stefano Stabellini
2016-11-09 13:32     ` Julien Grall
2016-09-28 18:24 ` [RFC PATCH 14/24] ARM: vITS: handle INT command Andre Przywara
2016-11-09  0:42   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 15/24] ARM: vITS: handle MAPC command Andre Przywara
2016-11-09  0:48   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 16/24] ARM: vITS: handle MAPD command Andre Przywara
2016-11-09  0:54   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 17/24] ARM: vITS: handle MAPTI command Andre Przywara
2016-11-09  1:07   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 18/24] ARM: vITS: handle MOVI command Andre Przywara
2016-11-09  1:13   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 19/24] ARM: vITS: handle DISCARD command Andre Przywara
2016-11-09  1:28   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 20/24] ARM: vITS: handle INV command Andre Przywara
2016-11-09  1:49   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 21/24] ARM: vITS: handle INVALL command Andre Przywara
2016-10-24 15:32   ` Vijay Kilari
2016-11-04  9:22     ` Andre Przywara
2016-11-10  0:21       ` Stefano Stabellini
2016-11-10 11:57         ` Julien Grall
2016-11-10 20:42           ` Stefano Stabellini
2016-11-11 15:53             ` Julien Grall
2016-11-11 20:31               ` Stefano Stabellini
2016-11-18 18:39                 ` Stefano Stabellini
2016-11-25 16:10                   ` Julien Grall
2016-12-01  1:19                     ` Stefano Stabellini
2016-12-02 16:18                       ` Andre Przywara
2016-12-03  0:46                         ` Stefano Stabellini
2016-12-05 13:36                           ` Julien Grall
2016-12-05 19:51                             ` Stefano Stabellini
2016-12-06 15:56                               ` Julien Grall
2016-12-06 19:36                                 ` Stefano Stabellini
2016-12-06 21:32                                   ` Dario Faggioli
2016-12-06 21:53                                     ` Stefano Stabellini
2016-12-06 22:01                                       ` Stefano Stabellini
2016-12-06 22:12                                         ` Dario Faggioli
2016-12-06 23:13                                         ` Julien Grall
2016-12-07 20:20                                           ` Stefano Stabellini
2016-12-09 18:01                                             ` Julien Grall
2016-12-09 20:13                                               ` Stefano Stabellini
2016-12-09 18:07                                             ` Andre Przywara
2016-12-09 20:18                                               ` Stefano Stabellini
2016-12-14  2:39                                                 ` George Dunlap
2016-12-16  1:30                                                   ` Dario Faggioli
2016-12-06 22:39                                       ` Dario Faggioli
2016-12-06 23:24                                         ` Julien Grall
2016-12-07  0:17                                           ` Dario Faggioli
2016-12-07 20:21                                         ` Stefano Stabellini
2016-12-09 10:14                                           ` Dario Faggioli
2016-12-06 21:36                               ` Dario Faggioli
2016-12-09 19:00                           ` Andre Przywara
2016-12-10  0:30                             ` Stefano Stabellini
2016-12-12 10:38                               ` Andre Przywara
2016-12-14  0:38                                 ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 22/24] ARM: vITS: create and initialize virtual ITSes for Dom0 Andre Przywara
2016-11-10  0:38   ` Stefano Stabellini
2016-09-28 18:24 ` [RFC PATCH 23/24] ARM: vITS: create ITS subnodes for Dom0 DT Andre Przywara
2016-09-28 18:24 ` [RFC PATCH 24/24] ARM: vGIC: advertising LPI support Andre Przywara
2016-11-10  0:49   ` Stefano Stabellini
2016-11-10 11:22     ` Julien Grall
2016-11-02 13:56 ` [RFC PATCH 00/24] [FOR 4.9] arm64: Dom0 ITS emulation 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=1546eda5-fc0c-281b-a8dc-c6ea1ed188eb@arm.com \
    --to=andre.przywara@arm.com \
    --cc=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=vijay.kilari@gmail.com \
    --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).