All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: julien.grall@arm.com, xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, Andre Przywara <andre.przywara@linaro.org>
Subject: Re: [PATCH 6/6] ARM: GIC: extend LR read/write functions to cover EOI and source
Date: Wed, 14 Mar 2018 18:19:09 +0000	[thread overview]
Message-ID: <8d0ded18-9574-ac62-cd6a-cf331a12fe61@arm.com> (raw)
In-Reply-To: <20180309163511.18808-7-julien.grall@arm.com>

Hi,

On 09/03/18 16:35, julien.grall@arm.com wrote:
> From: Andre Przywara <andre.przywara@linaro.org>

I think this is quite different from what I ever wrote, so please drop
my authorship here.

> So far our LR read/write functions do not handle the EOI bit and the
> source CPUID bits in an LR, because the current VGIC implementation does
> not use them.
> Extend the gic_lr data structure to hold these bits of information by
> using a union to differentiate field used depending on whether the vIRQ
> has a corresponding pIRQ.

As mentioned before, I am not sure this is really necessary. The idea of
struct gic_lr is to provide a hardware agnostic view of an LR. So the
actual read_lr/write_lr function take care of reading/populating pINTID,
iff the HW bit is set (as done in your patch 5/6).
Given that, I don't think we need to change the current code in this
respect, as this is just a small internal interface.

But then again I don't care enough, so if that makes you happy ....

> Note that source is not covered by GICv3 LR.

I was thinking the same, but Marc pointed me to that inconspicuous note
on page 8-299 in ARM IHI 0069D (at the end of "vINTID", chapter 8.4.6).

> This allows the new VGIC to use this information.
> 
> Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/arch/arm/gic-v2.c     | 22 +++++++++++++++++++---
>  xen/arch/arm/gic-v3.c     | 11 +++++++++--
>  xen/include/asm-arm/gic.h | 16 ++++++++++++++--
>  3 files changed, 42 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index daf8c61258..69f8d6044a 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -474,8 +474,17 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
>  
>      if ( lr_reg->hw_status )
>      {
> -        lr_reg->pirq = lrv >> GICH_V2_LR_PHYSICAL_SHIFT;
> -        lr_reg->pirq &= GICH_V2_LR_PHYSICAL_MASK;
> +        lr_reg->h.pirq = lrv >> GICH_V2_LR_PHYSICAL_SHIFT;
> +        lr_reg->h.pirq &= GICH_V2_LR_PHYSICAL_MASK;
> +    }
> +    else
> +    {
> +        lr_reg->v.eoi = (lrv & GICH_V2_LR_MAINTENANCE_IRQ) == GICH_V2_LR_MAINTENANCE_IRQ;

I think you can drop the " == GICH_V2_LR_MAINTENANCE_IRQ", as .eoi is a
bool. Avoids the linebreak.

> +        /*
> +         * This is only valid for SGI, but it does not matter to always
> +         * read it as it should be 0 by default.
> +         */
> +        lr_reg->v.source = (lrv >> GICH_V2_LR_CPUID_SHIFT) & GICH_V2_LR_CPUID_MASK;
>      }
>  }
>  
> @@ -496,7 +505,14 @@ static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
>      if ( lr_reg->hw_status )
>      {
>          lrv |= GICH_V2_LR_HW;
> -        lrv |= lr_reg->pirq << GICH_V2_LR_PHYSICAL_SHIFT;
> +        lrv |= lr_reg->h.pirq << GICH_V2_LR_PHYSICAL_SHIFT;
> +    }
> +    else
> +    {
> +        if ( lr_reg->v.eoi )
> +            lrv |= GICH_V2_LR_MAINTENANCE_IRQ;
> +        if ( lr_reg->virq < NR_GIC_SGI )
> +            lrv |= (uint32_t)lr_reg->v.source << GICH_V2_LR_CPUID_SHIFT;
>      }
>  
>      writel_gich(lrv, GICH_LR + lr * 4);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index f73d386df1..a855069111 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1014,7 +1014,9 @@ static void gicv3_read_lr(int lr, struct gic_lr *lr_reg)
>      lr_reg->hw_status = (lrv & ICH_LR_HW) == ICH_LR_HW;
>  
>      if ( lr_reg->hw_status )
> -        lr_reg->pirq = (lrv >> ICH_LR_PHYSICAL_SHIFT) & ICH_LR_PHYSICAL_MASK;
> +        lr_reg->h.pirq = (lrv >> ICH_LR_PHYSICAL_SHIFT) & ICH_LR_PHYSICAL_MASK;
> +    else
> +        lr_reg->v.eoi = (lrv & ICH_LR_MAINTENANCE_IRQ) == ICH_LR_MAINTENANCE_IRQ;

Same here.

>  }
>  
>  static void gicv3_write_lr(int lr_reg, const struct gic_lr *lr)
> @@ -1033,7 +1035,12 @@ static void gicv3_write_lr(int lr_reg, const struct gic_lr *lr)
>      if ( lr->hw_status )
>      {
>          lrv |= ICH_LR_HW;
> -        lrv |= (uint64_t)lr->pirq << ICH_LR_PHYSICAL_SHIFT;
> +        lrv |= (uint64_t)lr->h.pirq << ICH_LR_PHYSICAL_SHIFT;
> +    }
> +    else
> +    {
> +        if ( lr->v.eoi )
> +            lrv |= ICH_LR_MAINTENANCE_IRQ;
>      }
>  
>      /*
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 545901b120..4cf5bb385d 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -204,14 +204,26 @@ union gic_state_data {
>   * The LR register format is different for GIC HW version
>   */
>  struct gic_lr {
> -   /* Physical IRQ -> Only set when hw_status is set. */
> -   uint32_t pirq;
>     /* Virtual IRQ */
>     uint32_t virq;
>     uint8_t priority;
>     bool active;
>     bool pending;
>     bool hw_status;
> +   union
> +   {
> +       /* Only filled when there are a corresponding pIRQ (hw_state = true) */
> +       struct
> +       {
> +           uint32_t pirq;
> +       } h;
> +       /* Only filled when there are no corresponding pIRQ (hw_state = false) */
> +       struct
> +       {
> +           bool eoi;
> +           uint8_t source;      /* GICv2 only */
> +       } v;

That looks somewhat confusing to me. So either you use "hw" and "virt"
for the struct identifiers, or, preferably, just drop them altogether:

union {
	uint32_t pirq;	/* Contains the associated hardware IRQ. */
	struct		/* Only used for virtual interrupts. */
	{
		bool eoi;
		uint8_t source;
	};
};

Cheers,
Andre.

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

  reply	other threads:[~2018-03-14 18:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-09 16:35 [PATCH 0/6] xen/arm: Rework the way to store the LR julien.grall
2018-03-09 16:35 ` [PATCH 1/6] xen/arm: gic: Fix indentation in gic_update_one_lr julien.grall
2018-03-10 15:53   ` André Przywara
2018-03-09 16:35 ` [PATCH 2/6] xen/arm: vgic: Override the group in lr everytime julien.grall
2018-03-14 18:02   ` Andre Przywara
2018-03-14 18:07     ` Julien Grall
2018-03-09 16:35 ` [PATCH 3/6] xen/arm: gic: Use bool instead of uint8_t for the hw_status in gic_lr julien.grall
2018-03-14 18:06   ` Andre Przywara
2018-03-09 16:35 ` [PATCH 4/6] xen/arm: gic: Split the field state in gic_lr in 2 fields active and pending julien.grall
2018-03-14 18:09   ` Andre Przywara
2018-03-14 18:20     ` Julien Grall
2018-03-09 16:35 ` [PATCH 5/6] xen/arm: GIC: Only set pirq in the LR when hw_status is set julien.grall
2018-03-14 18:14   ` Andre Przywara
2018-03-09 16:35 ` [PATCH 6/6] ARM: GIC: extend LR read/write functions to cover EOI and source julien.grall
2018-03-14 18:19   ` Andre Przywara [this message]
2018-03-14 18:32     ` 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=8d0ded18-9574-ac62-cd6a-cf331a12fe61@arm.com \
    --to=andre.przywara@arm.com \
    --cc=andre.przywara@linaro.org \
    --cc=julien.grall@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 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.