Re: [Xen-devel] unknown gpa read address error for GICv3 re-distributor register access.

[Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>]

> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@xxxxxxxxxx]
> Sent: 28 September 2015 10:43
> To: Shameerali Kolothum Thodi; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Ian Campbell; Vijay Kilari
> Subject: Re: unknown gpa read address error for GICv3 re-distributor
> register access.
> 
> 
> 
> On 28/09/2015 09:36, Shameerali Kolothum Thodi wrote:
> > Hi All,
> 
> Hi,
> 
> 
> > I am working on enabling Xen on our HIPO5
> > board(http://lists.xenproject.org/archives/html/xen-users/2015-
> 07/msg0
> > 0090.html)
> >
> > Since the board has got GIC/ITS, tried this ITS  patch series
> (https://github.com/vijaykilari/its_v6/commits/stating_its_v6).
> 
> The ITS series is not upstream and unless your PCI device can't work
> without MSI I would advise you to first boot Xen and DOM0 without ITS.
> Once you have a working base, you can add the ITS series.
> 
> Although, use the latest version i.e v7:
> https://github.com/vijaykilari/its_v6/tree/staging_its_v7.

Sure. But I think as you mentioned below this is not related to ITS patch.

> 
> >
> > The board has got 16 cores. The dts file for the GIC is as below.
> >
> >
> >          gic: interrupt-controller@8d000000 {
> >                  compatible = "hisilicon,gic-v3";
> 
> This compatible string is not supported by Xen and below your log shows
> that your tree is dirty. What's the difference between staging and your
> tree?
> 
> >                  #interrupt-cells = <3>;
> >                  #address-cells = <2>;
> >                  #size-cells = <2>;
> >                  ranges;
> >                  interrupt-controller;
> >                  #redistributor-regions = <1>;
> >                  redistributor-stride = <0x0 0x30000>;
> 
> The GICv3 driver reads an 32 byte value for this field. It seems to be
> a mistake in our implementation (will send a patch for it).

Sorry, forgot to mention, I have the compatible string changes and stride size 
64 changes in the xen code.

> Although I don't think it's affecting your problem because Xen seems to
> retrieve the correct stride:
> 
>   (XEN) GICv3 initialization:
>   (XEN)       gic_dist_addr=0x0000008d000000
>   (XEN)       gic_maintenance_irq=25
>   (XEN)       gic_rdist_stride=30000
> 
> >                  reg = <0x0 0x8d000000 0 0x10000>,       /* GICD */
> >                        <0x0 0x8d100000 0 0x300000>,      /* GICR c */
> >                        <0x0 0xfe000000 0 0x10000>,       /* GICC */
> >                        <0x0 0xfe010000 0 0x10000>,       /* GICH */
> >                        <0x0 0xfe020000 0 0x10000>;       /* GICV */
> >                  interrupts = <1 9 0xff04>;
> 
> [...]
> 
> >          };
> >
> >
> > It has got the re-distributor base as 0x8d1000000 and stride size as
> 0x30000.I have seen couple of issues that blocks my Dom0 boot attempt.
> The first issue is related to the Dom0 secondary cpu boot failure.
> >
> > This is what I believe is happening(Please correct me if my
> understanding is wrong).
> > -Dom0 make the CPU1 on.
> > -gic_secondary_init() -->gic_populate_rdist()  (irq-gic-v3.c)
> >
> > Here it tries to find the re-distributor address by reading the
> GICR_TYPER register.  Since we have the rdbase as 0x8d100000 and stride
> size as 0x30000, a read is issued at 0x8d130008.
> >
> > Please find the Xen log below(Full log is attached at the end).
> >
> > (XEN) d0v0: vGICR: unknown gpa read address 000000008d130008
> > (XEN) traps.c:2447:d0v1 HSR=0x93c08006 pc=0xffffffc00032362c
> > gva=0xffffff80000b0008 gpa=0x0000008d130008
> > (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill
> the idle task!
> > (XEN) DOM0: CPU1: failed to come online
> >
> > vgic_v3_rdistr_mmio_read()
> > {
> >     ----
> >     v = get_vcpu_from_rdist(info->gpa, v, &offset);
> >     ----
> > }
> > I think the function returns the offset as 0x20008 and vcpu as 0,
> instead what I am expecting is offset 0x8 and vcpu 1.
> 
> It seems that you are right. To get the offset in the region, we use
> stride - 1 which will give 0x2ffff for your platform.
> 
> The code to get the vCPU is only valid when there is only a bit set in
> the stride.
> 
> I'm not sure if we can turn the mask into modulo and division. I will
> try to see how I can fix it.
>
Thanks for confirming this. Yes, the offset and base address calculation is 
wrong in our scenario.
I will have some workaround on this for now and move on to the staging_its_v7.
 
> Regards,
> 
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel