Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Hanjun Guo @ 2016-09-20 11:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160920104348.GP25086@rric.localdomain>

+Cc Yisheng,

On 09/20/2016 06:43 PM, Robert Richter wrote:
> David,
>
> On 19.09.16 11:49:30, David Daney wrote:
>> Fix by supplying a cpu_to_node() implementation that returns correct
>> node mappings.
>
>> +int cpu_to_node(int cpu)
>> +{
>> +	int nid;
>> +
>> +	/*
>> +	 * Return 0 for unknown mapping so that we report something
>> +	 * sensible if firmware doesn't supply a proper mapping.
>> +	 */
>> +	if (cpu < 0 || cpu >= NR_CPUS)
>> +		return 0;
>> +
>> +	nid = cpu_to_node_map[cpu];
>> +	if (nid == NUMA_NO_NODE)
>> +		nid = 0;
>> +	return nid;
>> +}
>> +EXPORT_SYMBOL(cpu_to_node);
>
> this implementation fixes the per-cpu workqueue initialization, but I
> don't think a cpu_to_node() implementation private to arm64 is the
> proper solution.
>
> Apart from better using generic code, the cpu_to_node() function is
> called in the kernel's fast path. I think your implementation is too
> expensive and also does not consider per-cpu data access for the
> lookup as the generic code does. Secondly, numa_off is not considered
> at all.
>
> Instead we need to make sure the set_*numa_node() functions are called
> earlier before secondary cpus are booted. My suggested change for that
> is this:
>
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index d93d43352504..952365c2f100 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -204,7 +204,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>   static void smp_store_cpu_info(unsigned int cpuid)
>   {
>   	store_cpu_topology(cpuid);
> -	numa_store_cpu_info(cpuid);
>   }
>
>   /*
> @@ -719,6 +718,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>   			continue;
>
>   		set_cpu_present(cpu, true);
> +		numa_store_cpu_info(cpu);
>   	}
>   }

We tried a similar approach which add numa_store_cpu_info() in
early_map_cpu_to_node(), and remove it from smp_store_cpu_info,
but didn't work for us, we will try your approach to see if works.

>
>
> I have tested the code and it properly sets up all per-cpu workqueues.
>
> Unfortunately either your nor my code does fix the BUG_ON() I see with
> the numa kernel:
>
>   kernel BUG at mm/page_alloc.c:1848!
>
> See below for the core dump. It looks like this happens due to moving
> a mem block where first and last page are mapped to different numa
> nodes, thus, triggering the BUG_ON().

Didn't triggered it on our NUMA hardware, could you provide your
config then we can have a try?

Thanks
Hanjun

^ permalink raw reply

* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: kernel at martin.sperl.org @ 2016-09-20 11:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <8053bf5c-7ddc-b4f7-1961-93f161731b16@tronnes.org>


> On 20.09.2016, at 12:56, Noralf Tr?nnes <noralf@tronnes.org> wrote:
> 
> 
> Den 20.09.2016 12:15, skrev Martin Sperl:
>> 
>> 
>> On 20.09.2016 10:41, Noralf Tr?nnes wrote:
>>> 
>>> Den 20.09.2016 09:19, skrev Martin Sperl:
>>>> Hi Noralf!
>>>> 
>>>> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>>>>> Some SMBus protocols use Repeated Start Condition to switch from write
>>>>> mode to read mode. Devices like MMA8451 won't work without it.
>>>>> 
>>>>> When downstream implemented support for this in i2c-bcm2708, it broke
>>>>> support for some devices, so a module parameter was added and combined
>>>>> transfer was disabled by default.
>>>>> See https://github.com/raspberrypi/linux/issues/599
>>>>> It doesn't seem to have been any investigation into what the problem
>>>>> really was. Later there was added a timeout on the polling loop.
>>>>> 
>>>>> One of the devices mentioned to partially stop working was DS1307.
>>>>> 
>>>>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>>>>> and AT24C32 (eeprom) in parallel without problems.
>>>>> 
>>>>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>>>>> ---
>>>>>  drivers/i2c/busses/i2c-bcm2835.c | 107
>>>>> +++++++++++++++++++++++++++++++++++----
>>>>>  1 file changed, 98 insertions(+), 9 deletions(-)
>>>> ...
>>>>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>>>>> *adap, struct i2c_msg msgs[],
>>>>>      int i;
>>>>>      int ret = 0;
>>>>>  +    /* Combined write-read to the same address (smbus) */
>>>>> +    if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>>>> +        !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>>>> +        (msgs[0].len <= 16)) {
>>>>> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>>>> +
>>>>> +    return ret ? ret : 2;
>>>>> +    }
>>>>> +
>>>>>      for (i = 0; i < num; i++) {
>>>>> -        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>>>>> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>>>>>          if (ret)
>>>>>              break;
>>>>>      }
>>>> This does not seem to implement the i2c_msg api correctly.
>>>> 
>>>> As per comments in include/uapi/linux/i2c.h on line 58 only the last
>>>> message
>>>> in a group should - by default - send a STOP.
>>>> 
>>> 
>>> Apparently it's a known problem that the i2c controller doesn't support
>>> Repeated Start. It will always issue a Stop when it has transferred DLEN
>>> bytes.
>>> Refs:
>>> http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
>>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they 
>>> 
>>> 
>>> UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is set
>>> and before DONE is set (or the last byte is shifted, I don't know excatly).
>>> Refs:
>>> https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
>>> https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834 
>>> 
>>> 
>>> I found this answer/report by joan that the downstream combined support
>>> isn't reliable:
>>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they 
>>> 
>>> 
>>> My implementation differs from downstream in that I use local_irq_save()
>>> to protect the polling loop. But that only protects from missing the TA
>>> (downstream can miss the TA and issue a Stop).
>>> 
>>> So currently in mainline we have a driver that says it support the standard
>>> (I2C_FUNC_I2C), but it really only supports one message transfers since it
>>> can't do ReStart.
>>> 
>>> What I have done in this patch is to support ReStart for transfers with
>>> 2 messages: first write, then read. But maybe a better solution is to just
>>> leave this alone if it is flaky and use bitbanging instead. I don't know.
>> I have not said that the approach you have taken is wrong or bad.
>> 
> 
> I didn't take it as such, I'm just not sure what's the best approach here,
> so I added and looked up some more information
> 
>> I was only telling you that the portion inside the bcm2835_i2c_xfer:
>> +    /* Combined write-read to the same address (smbus) */
>> +    if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>> +        !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>> +        (msgs[0].len <= 16)) {
>> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>> +
>> +        return ret ? ret : 2;
>> +    }
>> is very specific and maybe could be done in a "generic" manner
>> supporting more cases.
>> 
> 
> It has to be specific when it comes to number of messages. We can only
> support ReStart after the first message unless we use polling for the
> whole transfer. And in that case we can't disable interrupts for such
> a long period and we will end up sometimes loosing Transfer Active,
> resulting in Stop Condition between the messages.
> So we can only do transfers with 2 messages if we want Restart.
> 
> It is possible to support more than 16 bytes for the first message,
> filling the FIFO after polling TA, but I'm not sure that is common.
> Mostly it's 1 or 2 bytes to set a register.
> The write-read restriction isn't absolutely necessary either, but it's the
> most common case I think. So it was about reusing bcm2835_i2c_xfer_msg().
> A less restrictive approach would require a dedicated function I think.
> 
>> At least add a dev_warn_once for all num > 1 cases not handled by the
>> code above.
>> 
>> This gives people an opportunity to detect such a situation if they
>> find something is not working as expected.
>> 
> 
> I agree.
> 
> After reading joan's report I wonder if it would be best to add a module
> parameter like downstream has, so it can be disabled. What do you think?
> 

I guess let us start simple:
* get warning in place about always issuing a stop for num > 1
  - instead we may just want to set max_num_msgs = 1 in quirks.
* apply your patch for the write (<=16) then read case.
  - maybe by setting quirks I2C_AQ_COMB_WRITE_THEN_READ
    plus max_comb_1st_msg_len = 16 and max_num_msgs = 2

If this becomes too restrictive for some specific HW, then someone 
may want to add the missing features.

As for the module parameters: no idea if this is acceptable
or sensible.

But that?s just my 2c...

Martin

^ permalink raw reply

* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Mark Rutland @ 2016-09-20 11:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160920104348.GP25086@rric.localdomain>

On Tue, Sep 20, 2016 at 12:43:48PM +0200, Robert Richter wrote:
> Unfortunately either your nor my code does fix the BUG_ON() I see with
> the numa kernel:
> 
>  kernel BUG at mm/page_alloc.c:1848!
> 
> See below for the core dump. It looks like this happens due to moving
> a mem block where first and last page are mapped to different numa
> nodes, thus, triggering the BUG_ON().

FWIW, I'm seeing a potentially-related BUG in the same function on a
v4.8-rc7 kernel without CONFIG_NUMA enabled. I have a number of debug
options set, including CONFIG_PAGE_POISONING and CONFIG_DEBUG_PAGEALLOC.

I've included the full log for that below, including subsequent
failures.

I'm triggering this by running $(hackbench 100 process 1000).

Thanks,
Mark.

[  742.923329] ------------[ cut here ]------------
[  742.927951] kernel BUG at mm/page_alloc.c:1844!
[  742.932475] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  742.937951] Modules linked in:
[  742.941075] CPU: 4 PID: 3608 Comm: hackbench Not tainted 4.8.0-rc7 #1
[  742.947506] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  742.955066] task: ffff800341c4af80 task.stack: ffff800341c84000
[  742.960981] PC is at move_freepages+0x220/0x338
[  742.965503] LR is at move_freepages_block+0x164/0x1e0
[  742.970544] pc : [<ffff2000083dfeb8>] lr : [<ffff2000083e0134>] pstate: 200001c5
[  742.977928] sp : ffff800341c86ce0
[  742.981233] x29: ffff800341c86ce0 x28: ffff20000c8d9308
[  742.986541] x27: ffff7e000ffbffc0 x26: 0000000000000100
[  742.991850] x25: 0000000000000000 x24: 00000000083fefff
[  742.997157] x23: ffff7e000ffb8000 x22: ffff20000c8d9000
[  743.002465] x21: ffff20000c8d9000 x20: 0000000000000700
[  743.007772] x19: ffff7e000ffb8000 x18: 0000000000000000
[  743.013079] x17: 0000000000000001 x16: ffff200008553d78
[  743.018387] x15: 0000000000000002 x14: 0000000000000000
[  743.023694] x13: ffffffffffffffff x12: ffff20000b311000
[  743.029000] x11: 0000000000000000 x10: ffff20000d540000
[  743.034307] x9 : dfff200000000000 x8 : ffff20000c8d9318
[  743.039614] x7 : 0000000000000001 x6 : 1fffe4000149ab66
[  743.044921] x5 : dfff200000000000 x4 : ffff20000a4d5b30
[  743.050228] x3 : 0000000000000000 x2 : ffff7e000ffbffc0
[  743.055535] x1 : 0000000000000000 x0 : 0000000000000000
[  743.060841]
[  743.062324] Process hackbench (pid: 3608, stack limit = 0xffff800341c84020)
[  743.069276] Stack: (0xffff800341c86ce0 to 0xffff800341c88000)
[  743.075013] 6ce0: ffff800341c86d70 ffff2000083e0134 00000000083fee00 ffff7e000ffb8000
[  743.082833] 6d00: ffff20000c8d9000 0000000008400000 ffff7e000ffb8000 00000000083fefff
[  743.090653] 6d20: 0000000000000000 0000000000000100 ffff20000a9873a0 ffff20000c8d9308
[  743.098472] 6d40: 0000000000000000 0000000000000003 0000000000000005 ffff20000c8d9000
[  743.106292] 6d60: 0000000000000000 0000000000000100 ffff800341c86dc0 ffff2000083e11bc
[  743.114111] 6d80: 0000000000000005 0000000000000001 0000000000000000 0000000000000003
[  743.121930] 6da0: 0000000000000005 ffff20000c8d9000 ffff20000b311000 1ffff000683896e8
[  743.129750] 6dc0: ffff800341c86f50 ffff2000083e41fc 0000000000000003 ffff800341c873a0
[  743.137570] 6de0: 00000000002156c0 0000000000000008 dfff200000000000 ffff20000a4d5000
[  743.145389] 6e00: 0000000000000000 00000000002156c0 dfff200000000000 ffff20000c8d9000
[  743.153209] 6e20: ffff800341c86ee0 ffff2000081b3758 0000000000000001 ffff800341c84000
[  743.161028] 6e40: 0000000000000000 ffff7e000ffbb000 1ffff00068390dce ffff800341c86f50
[  743.168848] 6e60: ffff7e000ffbb020 ffff7e000ffbb000 0000000041b58ab3 ffff20000a2777d8
[  743.176668] 6e80: ffff2000083e06f8 000000000000b394 ffff800341c86e01 ffff20000823cd10
[  743.184487] 6ea0: ffff20000b311000 00000000000001c0 ffff20000c8d9598 00000000002156c0
[  743.192307] 6ec0: dfff200000000000 0000000000000000 ffff800341c86f20 ffff200009c28074
[  743.200126] 6ee0: ffff20000c8d9580 0000000000000140 ffff2000083e41c8 0000000000000001
[  743.207946] 6f00: dfff200000000000 ffff20000a4d5000 0000000000000000 0000000000000000
[  743.215765] 6f20: ffff800341c86f50 ffff2000083e41c8 ffff20000c8d96e8 ffff800341c873a0
[  743.223585] 6f40: 00000000002156c0 ffff2000083e4884 ffff800341c87160 ffff2000083e74d4
[  743.231404] 6f60: ffff800341c4af80 ffff800341c873a0 00000000002156c0 0000000000000001
[  743.239224] 6f80: dfff200000000000 ffff20000a4d5000 0000000000000000 00000000002156c0
[  743.247043] 6fa0: 1ffff00068390e50 0000000000000001 00000000002156c0 ffff20000a9827c0
[  743.254863] 6fc0: ffff800341c873b0 0000000000000003 0000000000000268 00000008002156c0
[  743.262682] 6fe0: 1ffff00068390e18 0000000000000001 ffff8003ffef9000 0000000000000008
[  743.270501] 7000: ffff8003002156c0 0000000000000002 0000000000000000 ffff200008236b1c
[  743.278321] 7020: ffff800341c870a0 1ffff00068390e76 0000000000000140 ffff800341c4b740
[  743.286141] 7040: ffff800300000003 ffff200008236b1c ffff800341c870e0 ffff200008236b1c
[  743.293960] 7060: ffff800341c870e0 ffff200008236dac 0000000000000040 ffff800341c4b740
[  743.301780] 7080: ffff800341c87110 ffff20000c8d9e00 ffff20000c8d9580 ffff20000c8d9268
[  743.309599] 70a0: 0000000000000000 ffff800341c873a0 0000000000000000 ffff20000c8d9000
[  743.317419] 70c0: 0000000041b58ab3 ffff20000a266f80 ffff2000083e37c8 1ffff00068390e4a
[  743.325239] 70e0: ffff800341c4af80 0000000000000000 ffff800341c4af80 00000000000001c0
[  743.333058] 7100: ffff800341c87130 ffff20000823f928 ffff20000b311000 00000000002156c0
[  743.340878] 7120: 0000000000000140 00000000000001c0 ffff800341c87160 ffff2000083e71dc
[  743.348698] 7140: ffff8003ffdf4680 00000000025106c0 ffff20000c8d9e00 00000000ffffffff
[  743.356517] 7160: ffff800341c87400 ffff2000084ef36c ffff8003ffdf4680 00000000025106c0
[  743.364337] 7180: 00000000002156c0 00000000ffffffff 00000000024146c0 0000000000000003
[  743.372156] 71a0: 0000000000030020 ffff20000c8d9000 0000000000400000 0000000000000004
[  743.379976] 71c0: ffff800341c87290 ffff200008093624 ffff800341c87350 ffff800341c87310
[  743.387796] 71e0: ffff200008092ce0 ffff800341c4af80 ffff80036c0e0f80 ffff200009892b70
[  743.395615] 7200: ffff20000ab19b70 ffff80036c0e0f80 ffff800341c84000 0000000000000004
[  743.403435] 7220: 0000000041c4b738 1ffff000683896e7 0000000041b58ab3 ffff200000000040
[  743.411254] 7240: ffff200000000000 ffff20000c8d9e08 ffff04000191b3c1 0000000000000000
[  743.419074] 7260: 0000000000000000 ffff800341c87310 0000000300000000 ffff2000084ef36c
[  743.426894] 7280: 0000000041b58ab3 ffff20000a277828 ffff2000083e70b8 ffff2000080937ac
[  743.434713] 72a0: ffff800341c873f8 1ffff00068390e5e ffff800341c4af80 ffff800341c84000
[  743.442533] 72c0: ffff800341c87390 ffff20000809397c ffff800341c84000 ffff800341c873f8
[  743.450352] 72e0: 00000000025004c0 ffff800357ff2ac0 0000000041b58ab3 ffff20000a2623e8
[  743.458172] 7300: ffff200008093648 ffff800341c84000 ffff800341c873b0 ffff2000084fade8
[  743.465991] 7320: ffff800357ff2ce0 ffff800357ff2ba0 00000000025004c0 ffff800357ff2ac0
[  743.473811] 7340: ffff80036c0e0f80 ffff200009892b70 ffff800341c873b0 ffff200008b58184
[  743.481631] 7360: ffff20000a499000 000000000000b393 0000000000000000 00000000ffffffff
[  743.489450] 7380: 00000000024106c0 ffff200009892b94 0000000000030020 ffff20000ab18cf0
[  743.497270] 73a0: ffff20000c8d9e00 0000000000000000 ffff20000c8d9e00 0000000100000000
[  743.505089] 73c0: 0000000000000000 ffff200008235e10 ffff8003ffdf4680 00000000025106c0
[  743.512909] 73e0: 0000000000000000 ffff8003ffefd9b0 ffff800341c87400 ffff2000084ef38c
[  743.520729] 7400: ffff800341c87490 ffff2000084f3bc0 0000000000000000 ffff8003ffefc5d0
[  743.528548] 7420: 0000000000000000 ffff8003ffdf4680 00000000025106c0 ffff200009892b94
[  743.536368] 7440: 0000000000210d00 ffff20000ab18cf0 ffff20000ab19938 0000000000000004
[  743.544188] 7460: ffff2000098678a0 ffff20000854d770 ffff20000854ff38 025106c008553e20
[  743.552007] 7480: ffff200008084730 ffffffffffffffff ffff800341c87590 ffff2000084f4130
[  743.559827] 74a0: ffff20000a4a35d0 ffff20000a4d5e80 0000000000000140 00000000025106c0
[  743.567646] 74c0: ffff200009892b94 0000000000000004 ffff8003ffdf4680 ffff20000ab1cb30
[  743.575466] 74e0: ffff800341c84000 0000000000000004 ffff20000a499000 000000000000b392
[  743.583286] 7500: ffff20000ab19988 ffff8003ffefc5d0 ffff200009892b94 ffff20000a4d5000
[  743.591105] 7520: ffff800341c87580 ffff200008b5815c ffff20000a4a35d0 ffff8003ffdf4680
[  743.598925] 7540: 0000000000000140 00000000025106c0 ffff200009892b94 ffff20000a4d5000
[  743.606744] 7560: ffff8003ffdf4680 ffff20000ab1cb30 ffff800341c84000 ffff20000a278cb8
[  743.614564] 7580: ffff800341c87590 ffff2000084f40ec ffff800341c875e0 ffff2000084fa028
[  743.622383] 75a0: 0000000000000000 ffff8003ffdf4680 ffff8003ffdf4680 ffff20000ab1bff0
[  743.630203] 75c0: 00000000025106c0 ffff20000a4d5000 ffff200009892b94 ffff20000a4d5000
[  743.638023] 75e0: ffff800341c87660 ffff20000988cf54 ffff800341c87710 1ffff00068390ede
[  743.645842] 7600: 00000000025004c0 ffff200009892b94 0000000000000000 0000000000000200
[  743.653662] 7620: ffff80034219e940 dfff200000000000 ffff80034219e940 0000000000000000
[  743.661481] 7640: 0000000000000064 00000000025004c0 0000000000000000 ffff80036c0e0f80
[  743.669301] 7660: ffff800341c876a0 ffff200009892b94 ffff800357ff2ac0 1ffff00068390ede
[  743.677120] 7680: 0000000000000064 00000000025004c0 0000000000000000 ffff80036c0e0f80
[  743.684939] 76a0: ffff800341c87790 ffff200009893074 0000000000000000 0000000000000064
[  743.692759] 76c0: ffff80034219eb20 0000000000000000 0000000000000003 0000000000000000
[  743.700579] 76e0: ffff80034219e940 dfff200000000000 0000000041b58ab3 ffff20000a2cd5a8
[  743.708398] 7700: ffff200009892ad0 dfff200000000000 ffff80034219f200 ffff20000cb359b0
[  743.716218] 7720: ffff800342143364 ffff20000a4d5e90 ffff20000a4d5e90 00006003f5a2d000
[  743.724038] 7740: 1ffff0006842866c 0000000000000004 0000dffff5b2a188 ffff20000a4a0000
[  743.731857] 7760: ffff800341c877c0 ffff20000823daac ffff800341c84000 0000000000000140
[  743.739677] 7780: ffff20000a7ac240 000000000000010a ffff800341c87830 ffff20000986ec00
[  743.747498] 77a0: ffff800341c87920 7fffffffffffffff ffff80034219eb20 0000000000000000
[  743.755319] 77c0: 0000000000000002 1ffff00068433d65 ffff80034219e940 dfff200000000000
[  743.763138] 77e0: ffff80034219e940 0000000000000064 ffff800341c87830 ffff2000081b3178
[  743.770958] 7800: ffff800341c4af80 ffff20000a0f3aa0 000000000000010a 0000000000000000
[  743.778778] 7820: ffff8003025000c0 ffff800347135840 ffff800341c87980 ffff200009b33a10
[  743.786597] 7840: 0000000000000064 0000000000000000 0000000000000000 0000000000000000
[  743.794416] 7860: ffff800342198900 0000000000000064 ffff80034219e940 dfff200000000000
[  743.802236] 7880: 0000000000000000 0000000000000064 ffff20000a0f3140 1ffff00068390f4a
[  743.810055] 78a0: 0000000341c87ba0 0000000000000000 0000000000000064 ffff80034219ec50
[  743.817875] 78c0: 1ffff00068390f20 ffff800341c87a70 ffff200009b3c398 0000000000000064
[  743.825695] 78e0: ffff80034219eb28 ffff80034219ece2 1ffff00068433d8a ffff100068433d9c
[  743.833514] 7900: 0000000041b58ab3 ffff20000a2680e0 ffff20000986e710 ffff800341c4b740
[  743.841334] 7920: 1ffff000683896e8 000000000c8db000 ffff20000987442c 0000000000000140
[  743.849153] 7940: ffff800341c87980 ffff200009b33b70 ffff800341c87980 ffff200009b337d8
[  743.856973] 7960: ffff800347135840 ffff800341c87ba0 ffff20000a0f3140 0000000000000000
[  743.864793] 7980: ffff800341c87af0 ffff2000098675f8 ffff800347135840 ffff800341c87ba0
[  743.872612] 79a0: ffff20000a0f3140 ffff800341c87d77 ffff800341c87ba0 ffff800342b2a340
[  743.880432] 79c0: ffff800347135840 1ffff00068390faa 0000000000000002 1ffff0006856546c
[  743.888251] 79e0: ffff8003372a4780 ffff8003372a4790 1ffff00068390f4a ffff800347135840
[  743.896071] 7a00: ffff10006843312c ffff800342198960 ffff800341c87a70 ffff80034219eb28
[  743.903890] 7a20: ffff800341c87ab0 ffff800341c87be8 ffff800341c87ba0 1ffff00068390f7d
[  743.911710] 7a40: 0000000000000064 0000000000000064 0000000041b58ab3 ffff20000a2d20f8
[  743.919530] 7a60: ffff200009b33720 ffff20000a743000 00000000ffffff97 1ffff00068390f7e
[  743.927349] 7a80: ffff800341c4af80 0000000000000000 ffff800341c4af80 ffff8003ffef9000
[  743.935169] 7aa0: ffff800341c87ab0 ffff2000082383dc 0000000000000000 0000000000000000
[  743.942988] 7ac0: ffffffff00000000 00000000ffffffff ffff8003ffef9018 0000000000000000
[  743.950808] 7ae0: 0000000000000000 ffff2000081b205c ffff800341c87b30 ffff2000098678a0
[  743.958628] 7b00: ffff800341c87d50 ffff800341c87cf0 1ffff00068390f70 00000000000001c0
[  743.966447] 7b20: ffff8003ffef9018 ffff8003ffef9000 ffff800341c87c20 ffff20000854d770
[  743.974267] 7b40: 1ffff00068390f92 ffff20000a0c0980 ffff800341c87d50 ffff800341c87e80
[  743.982086] 7b60: 1ffff0006856546d ffff800342b2a368 1ffff00068390fd0 ffff80036ba1a480
[  743.989906] 7b80: 0000000041b58ab3 ffff20000a2ccf48 ffff2000098676e0 ffff20000caf9470
[  743.997725] 7ba0: 0000000000000000 0000000000000000 0000000000000001 0000000000000000
[  744.005545] 7bc0: 0000000000000064 ffff800341c87cb0 0000000000000001 0000000000000000
[  744.013364] 7be0: 0000000000000000 0000000000000000 ffff800341c87cf0 0000000000000001
[  744.021183] 7c00: ffff800341c4b76a ffff800341c4b748 ffff20000d540000 0000000000000001
[  744.029003] 7c20: ffff800341c87db0 ffff20000854ff38 ffff800342b2a340 0000000000000064
[  744.036822] 7c40: ffff800347135870 ffff800342b2a3b4 0000000000000004 1ffff00068565476
[  744.044642] 7c60: 0000ffffe63a1420 ffff800342b2a360 ffff800341c87e80 ffff800347135df0
[  744.052462] 7c80: 0000000000000064 ffff800342b29fd0 0000000041b58ab3 ffff20000a27c658
[  744.060281] 7ca0: ffff20000854d520 ffff800342b29fe0 0000ffffe63a1420 0000000000000064
[  744.068101] 7cc0: 0000dffff5b2a188 0000000000000001 1ffff0007ffdf327 0000000000000001
[  744.075920] 7ce0: ffff800341c87cf0 1ffff00068390fa2 ffff800342b2a340 0000000000000000
[  744.083739] 7d00: 0000000000000000 0000000000000000 0000000000000000 ffff20000a27dc50
[  744.091559] 7d20: ffff800341c87d60 ffff20000854f80c ffff800342b2a340 ffff800347135870
[  744.099378] 7d40: 0000000000000000 0000000000000001 0000000000000001 0000000000000000
[  744.107197] 7d60: 0000000000000064 ffff800341c87cb0 0000000000000001 0000000000000064
[  744.115016] 7d80: ffff800341c84000 ffff800342b2a3b4 0000000000000004 ffff800341c4b300
[  744.122836] 7da0: 0000000000000000 ffff8003372a4700 ffff800341c87e10 ffff200008553e20
[  744.130656] 7dc0: 1ffff00068390fcc ffff800342b2a340 ffff800342b2a340 dfff200000000000
[  744.138475] 7de0: 1ffff00068565487 0000ffffe63a1420 0000000000000064 ffff800342b2a438
[  744.146295] 7e00: ffff200009c47000 ffff800341c84000 0000000000000000 ffff200008084730
[  744.154114] 7e20: 0000000000000000 000000003d5e7b00 ffffffffffffffff 0000000000405acc
[  744.161934] 7e40: 0000000060000000 0000000000000015 0000000000000120 0000000000000040
[  744.169753] 7e60: 0000000041b58ab3 ffff20000a27c6d0 ffff200008553d78 000000003d5e7b00
[  744.177572] 7e80: 0000000000000000 0000000000405acc 0000000060000000 ffff200008084630
[  744.185392] 7ea0: 0000000000000000 ffff200008084624 0000000000000000 000000003d5e7b00
[  744.193212] 7ec0: 000000000000000c 0000ffffe63a1420 0000000000000064 0000ffffe63a1420
[  744.201031] 7ee0: 0000000000000000 00000000004a2790 000000000049d020 0000000000000058
[  744.208850] 7f00: 0000000000000040 1999999999999999 0000000000000000 0000000000000000
[  744.216669] 7f20: 0000000000000002 ffffffffffffffff 0000000000000000 00000000004a26f8
[  744.224488] 7f40: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
[  744.232307] 7f60: 000000003d5e7b00 0000000000000010 0000000000000064 0000000000000004
[  744.240126] 7f80: 00000000000000f6 000000000049b000 000000000049c010 0000000000401e40
[  744.247946] 7fa0: 0000000000000022 0000ffffe63a13d0 0000000000401dd4 0000ffffe63a13d0
[  744.255765] 7fc0: 0000000000405acc 0000000060000000 000000000000000c 0000000000000040
[  744.263584] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[  744.271402] Call trace:
[  744.273840] Exception stack(0xffff800341c86a90 to 0xffff800341c86bc0)
[  744.280270] 6a80:                                   ffff7e000ffb8000 0001000000000000
[  744.288090] 6aa0: ffff800341c86ce0 ffff2000083dfeb8 00000000200001c5 000000000000003d
[  744.295909] 6ac0: 0000000000000000 0000000000000100 ffff7e000ffbffc0 ffff800341c84000
[  744.303729] 6ae0: ffff800341c4b76a ffff800341c4b748 0000000041b58ab3 ffff20000a261068
[  744.311549] 6b00: ffff200008081b10 ffff800341c4af80 ffff800341c4b720 dfff200000000000
[  744.319368] 6b20: ffff20000b311000 0000000000000001 ffff20000b311a60 00000000000080e7
[  744.327188] 6b40: ffff800341c86ca0 ffff200009c16a78 ffff800341c86c10 ffff200009c28720
[  744.335007] 6b60: ffff800341c86bc0 ffff200008b58184 ffff20000a499000 000000000000b2f1
[  744.342826] 6b80: 0000000000000000 ffff20000a4d5000 ffff800336325e80 0000000000000000
[  744.350645] 6ba0: 0000dffff5b2a188 0000000000000001 0000000000000000 0000000000000000
[  744.358467] [<ffff2000083dfeb8>] move_freepages+0x220/0x338
[  744.364030] [<ffff2000083e0134>] move_freepages_block+0x164/0x1e0
[  744.370113] [<ffff2000083e11bc>] __rmqueue+0xac4/0x16d0
[  744.375329] [<ffff2000083e41fc>] get_page_from_freelist+0xa34/0x2228
[  744.381674] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  744.388019] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  744.393061] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  744.399665] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  744.406790] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  744.413050] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  744.419307] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  744.424522] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  744.430519] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  744.436605] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  744.442603] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  744.447906] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  744.453556] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  744.458858] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  744.463986] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  744.469029] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  744.474333] Code: 913d0000 941ebb67 17ffffed d503201f (d4210000)
[  744.480482] ---[ end trace a906e1a5ea5e05bb ]---
[  744.485103] BUG: sleeping function called from invalid context at ./include/linux/sched.h:3049
[  744.493712] in_atomic(): 1, irqs_disabled(): 0, pid: 3608, name: hackbench
[  744.500583] INFO: lockdep is turned off.
[  744.504503] Preemption disabled at:[<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  744.512856]
[  744.514341] CPU: 4 PID: 3608 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  744.521986] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  744.529544] Call trace:
[  744.531983] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  744.537373] [<ffff2000080942a4>] show_stack+0x14/0x20
[  744.542417] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  744.547550] [<ffff2000081b2e24>] ___might_sleep+0x5ec/0x868
[  744.553114] [<ffff2000081b3178>] __might_sleep+0xd8/0x350
[  744.558504] [<ffff20000816b740>] exit_signals+0x80/0x428
[  744.563807] [<ffff200008143f18>] do_exit+0x220/0x1828
[  744.568849] [<ffff2000080945a4>] die+0x2f4/0x3c8
[  744.573458] [<ffff2000080946dc>] bug_handler.part.1+0x64/0xf0
[  744.579194] [<ffff2000080947ac>] bug_handler+0x44/0x70
[  744.584322] [<ffff200008086c28>] brk_handler+0x168/0x348
[  744.589624] [<ffff200008081c00>] do_debug_exception+0xf0/0x368
[  744.595446] Exception stack(0xffff800341c86a90 to 0xffff800341c86bc0)
[  744.601877] 6a80:                                   ffff7e000ffb8000 0001000000000000
[  744.609697] 6aa0: ffff800341c86ce0 ffff2000083dfeb8 00000000200001c5 000000000000003d
[  744.617516] 6ac0: 0000000000000000 0000000000000100 ffff7e000ffbffc0 ffff800341c84000
[  744.625336] 6ae0: ffff800341c4b76a ffff800341c4b748 0000000041b58ab3 ffff20000a261068
[  744.633155] 6b00: ffff200008081b10 ffff800341c4af80 ffff800341c4b720 dfff200000000000
[  744.640975] 6b20: ffff20000b311000 0000000000000001 ffff20000b311a60 00000000000080e7
[  744.648795] 6b40: ffff800341c86ca0 ffff200009c16a78 ffff800341c86c10 ffff200009c28720
[  744.656614] 6b60: ffff800341c86bc0 ffff200008b58184 ffff20000a499000 000000000000b2f1
[  744.664434] 6b80: 0000000000000000 ffff20000a4d5000 ffff800336325e80 0000000000000000
[  744.672253] 6ba0: 0000dffff5b2a188 0000000000000001 0000000000000000 0000000000000000
[  744.680072] [<ffff200008083e5c>] el1_dbg+0x18/0x74
[  744.684854] [<ffff2000083e0134>] move_freepages_block+0x164/0x1e0
[  744.690937] [<ffff2000083e11bc>] __rmqueue+0xac4/0x16d0
[  744.696153] [<ffff2000083e41fc>] get_page_from_freelist+0xa34/0x2228
[  744.702497] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  744.708841] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  744.713882] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  744.720487] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  744.727612] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  744.733870] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  744.740127] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  744.745343] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  744.751339] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  744.757423] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  744.763421] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  744.768723] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  744.774372] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  744.779674] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  744.784802] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  744.789843] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  744.795159] note: hackbench[3608] exited with preempt_count 1
[  783.865366] BUG: spinlock lockup suspected on CPU#5, hackbench/3727
[  783.871631]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  783.881189] CPU: 5 PID: 3727 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  783.888835] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  783.896393] Call trace:
[  783.898832] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  783.904222] [<ffff2000080942a4>] show_stack+0x14/0x20
[  783.909265] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  783.914395] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  783.919524] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  783.925262] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  783.931346] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  783.937691] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  783.944034] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  783.949076] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  783.955680] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  783.962805] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  783.969063] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  783.975320] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  783.980536] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  783.986532] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  783.992616] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  783.998614] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  784.003916] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  784.009565] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  784.014867] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  784.019995] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  784.025037] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  802.492828] BUG: spinlock lockup suspected on CPU#7, hackbench/3194
[  802.499097]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  802.508655] CPU: 7 PID: 3194 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  802.516301] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  802.523859] Call trace:
[  802.526300] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  802.531690] [<ffff2000080942a4>] show_stack+0x14/0x20
[  802.536733] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  802.541862] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  802.546991] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  802.552729] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  802.558813] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  802.565158] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  802.571502] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  802.576544] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  802.583148] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  802.590273] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  802.596531] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  802.602789] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  802.608004] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  802.614001] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  802.620086] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  802.626083] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  802.631386] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  802.637035] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  802.642337] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  802.647465] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  802.652507] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  802.727119] BUG: spinlock lockup suspected on CPU#1, hackbench/5203
[  802.733384]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  802.742942] CPU: 1 PID: 5203 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  802.750587] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  802.758145] Call trace:
[  802.760584] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  802.765975] [<ffff2000080942a4>] show_stack+0x14/0x20
[  802.771017] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  802.776146] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  802.781275] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  802.787013] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  802.793097] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  802.799441] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  802.805785] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  802.810827] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  802.817432] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  802.824557] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  802.830815] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  802.837073] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  802.842289] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  802.848285] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  802.854370] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  802.860367] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  802.865670] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  802.871319] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  802.876621] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  802.881750] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  802.886792] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  806.778113] BUG: spinlock lockup suspected on CPU#6, hackbench/3240
[  806.784376]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  806.793933] CPU: 6 PID: 3240 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  806.801578] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  806.809136] Call trace:
[  806.811575] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  806.816966] [<ffff2000080942a4>] show_stack+0x14/0x20
[  806.822008] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  806.827137] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  806.832265] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  806.838002] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  806.844086] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  806.850430] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  806.856774] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  806.861815] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  806.868420] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  806.875545] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  806.881803] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  806.888060] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  806.893276] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  806.899272] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  806.905356] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  806.911354] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  806.916656] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  806.922306] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  806.927607] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  806.932736] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  806.937777] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  808.159084] BUG: spinlock lockup suspected on CPU#3, hackbench/4717
[  808.165350]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  808.174908] CPU: 3 PID: 4717 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  808.182554] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  808.190112] Call trace:
[  808.192552] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  808.197942] [<ffff2000080942a4>] show_stack+0x14/0x20
[  808.202985] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  808.208114] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  808.213243] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  808.218980] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  808.225064] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  808.231408] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  808.237752] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  808.242794] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  808.249399] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  808.256524] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  808.262782] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  808.269039] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  808.274255] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  808.280251] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  808.286335] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  808.292333] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  808.297635] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  808.303285] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  808.308587] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  808.313715] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  808.318757] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  809.327451] BUG: spinlock lockup suspected on CPU#2, hackbench/3360
[  809.333714]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  809.343271] CPU: 2 PID: 3360 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  809.350916] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  809.358474] Call trace:
[  809.360913] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  809.366303] [<ffff2000080942a4>] show_stack+0x14/0x20
[  809.371345] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  809.376475] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  809.381603] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  809.382291] BUG: spinlock lockup suspected on CPU#0, hackbench/5685
[  809.382297]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  809.403145] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  809.409229] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  809.415574] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  809.421917] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  809.426959] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  809.433564] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  809.440689] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  809.446946] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  809.453204] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  809.458420] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  809.464417] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  809.470501] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  809.476498] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  809.481801] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  809.487450] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  809.492752] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  809.497880] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  809.502922] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  809.508226] CPU: 0 PID: 5685 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  809.515873] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  809.523431] Call trace:
[  809.525871] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  809.531261] [<ffff2000080942a4>] show_stack+0x14/0x20
[  809.536304] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  809.541433] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  809.546562] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  809.552299] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  809.558383] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  809.564728] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  809.571071] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  809.576113] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  809.582717] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  809.589842] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  809.596100] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  809.602357] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  809.607573] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  809.613570] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  809.619654] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  809.625651] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  809.630953] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  809.636602] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  809.641904] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  809.647032] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  809.652074] [<ffff200008084730>] el0_svc_naked+0x24/0x28
[  810.224351] BUG: spinlock lockup suspected on CPU#4, hackbench/5272
[  810.230613]  lock: contig_page_data+0xc80/0x1900, .magic: dead4ead, .owner: hackbench/3608, .owner_cpu: 4
[  810.240169] CPU: 4 PID: 5272 Comm: hackbench Tainted: G      D         4.8.0-rc7 #1
[  810.247814] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive) (DT)
[  810.255371] Call trace:
[  810.257810] [<ffff200008093db8>] dump_backtrace+0x0/0x4d8
[  810.263200] [<ffff2000080942a4>] show_stack+0x14/0x20
[  810.268242] [<ffff200008afa714>] dump_stack+0xfc/0x150
[  810.273371] [<ffff20000824a16c>] spin_dump+0x19c/0x2f0
[  810.278499] [<ffff20000824a770>] do_raw_spin_lock+0x2d8/0x3e8
[  810.284236] [<ffff200009c28074>] _raw_spin_lock_irqsave+0x54/0x68
[  810.290320] [<ffff2000083e41c8>] get_page_from_freelist+0xa00/0x2228
[  810.296664] [<ffff2000083e74d4>] __alloc_pages_nodemask+0x41c/0x1f60
[  810.303008] [<ffff2000084ef36c>] new_slab+0x3e4/0x9d8
[  810.308049] [<ffff2000084f3bc0>] ___slab_alloc.constprop.18+0x3b8/0x8a8
[  810.314654] [<ffff2000084f4130>] __slab_alloc.isra.15.constprop.17+0x80/0x128
[  810.321779] [<ffff2000084fa028>] __kmalloc_track_caller+0x318/0x4e0
[  810.328037] [<ffff20000988cf54>] __kmalloc_reserve.isra.3+0x3c/0xc0
[  810.334294] [<ffff200009892b94>] __alloc_skb+0xc4/0x508
[  810.339509] [<ffff200009893074>] alloc_skb_with_frags+0x9c/0x650
[  810.345506] [<ffff20000986ec00>] sock_alloc_send_pskb+0x4f0/0x7d8
[  810.351590] [<ffff200009b33a10>] unix_stream_sendmsg+0x2f0/0x858
[  810.357587] [<ffff2000098675f8>] sock_sendmsg+0x88/0x138
[  810.362889] [<ffff2000098678a0>] sock_write_iter+0x1c0/0x308
[  810.368538] [<ffff20000854d770>] __vfs_write+0x250/0x4c8
[  810.373840] [<ffff20000854ff38>] vfs_write+0x128/0x520
[  810.378968] [<ffff200008553e20>] SyS_write+0xa8/0x140
[  810.384010] [<ffff200008084730>] el0_svc_naked+0x24/0x28

^ permalink raw reply

* [RFC] arm64: Ensure proper addressing for ldnp/stnp
From: Robin Murphy @ 2016-09-20 11:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <9a3f86d9037a478f0a1a87b2084c7496@codeaurora.org>

On 19/09/16 19:25, bdegraaf at codeaurora.org wrote:
> On 2016-09-19 14:01, Robin Murphy wrote:
>> On 19/09/16 18:36, Brent DeGraaf wrote:
>>> According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
>>> loads and stores do not verify that address dependency is met between a
>>> load of an address to a register and a subsequent non-temporal load or
>>> store using that address on the executing PE. Therefore, context switch
>>> code and subroutine calls that use non-temporally accessed addresses as
>>> parameters that might depend on a load of an address into an argument
>>> register must ensure that ordering requirements are met by introducing
>>> a barrier prior to the successive non-temporal access.  Add appropriate
>>> barriers whereever this specific situation comes into play.
>>>
>>> Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
>>> ---
>>>  arch/arm64/kernel/entry.S  | 1 +
>>>  arch/arm64/lib/copy_page.S | 2 ++
>>>  2 files changed, 3 insertions(+)
>>>
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index 441420c..982c4d3 100644
>>> --- a/arch/arm64/kernel/entry.S
>>> +++ b/arch/arm64/kernel/entry.S
>>> @@ -679,6 +679,7 @@ ENTRY(cpu_switch_to)
>>>      ldp    x27, x28, [x8], #16
>>>      ldp    x29, x9, [x8], #16
>>>      ldr    lr, [x8]
>>> +    dmb    nshld    // Existence of instructions with loose load-use
>>> dependencies (e.g. ldnp/stnp) make this barrier necessary
>>>      mov    sp, x9
>>>      and    x9, x9, #~(THREAD_SIZE - 1)
>>>      msr    sp_el0, x9
>>> diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
>>> index 4c1e700..21c6892 100644
>>> --- a/arch/arm64/lib/copy_page.S
>>> +++ b/arch/arm64/lib/copy_page.S
>>> @@ -47,6 +47,8 @@ alternative_endif
>>>      ldp    x14, x15, [x1, #96]
>>>      ldp    x16, x17, [x1, #112]
>>>
>>> +    dmb    nshld // In case x0 (for stnp) is dependent on a load
>>
>> The ARMv8 ARM (B2.7.2 in issue j) says that when an address dependency
>> exists between a load and a subsequent LDNP, *other* observers may
>> observe those accesses in any order. How's that related to an STNP on
>> the same CPU?
>>
>> Robin.
>>
>>> +
>>>      mov    x18, #(PAGE_SIZE - 128)
>>>      add    x1, x1, #128
>>>  1:
>>>
> 
> Yes, I have seen the section in the ARM ARM about this. But the
> Programmer's Guide goes further, even providing a concrete example:
> 
> "Non-temporal loads and stores relax the memory ordering
> requirements...the LDNP instruction might
> be observed before the preceding LDR instruction, which can result in
> reading from an unpredictable
> address in X0.
> 
> For example:
> LDR X0, [X3]
> LDNP X2, X1, [X0]
> To correct the above, you need an explicit load barrier:
> LDR X0, [X3]
> DMB NSHLD
> LDNP X2, X1, [X0]"
> 
> Did the ARM ARM leave this out?  Or is the Programmer's Guide section
> incorrect?

If the ARM ARM and the Programmer's Guide don't agree, then the
Programmer's Guide is wrong (I'll raise a bug against it).

All the ARM ARM says is that in this situation:

     P1                        P2
 STP x0, x1, [x2]      1: LDR x0, <ptr>
 DMB ISH                  CBZ x0, 1b
 STR x2, <ptr>            LDNP x1, x2, [x0]

P2's address dependency still very much exists from the point of view of
P2's execution, it just may not guarantee order against the DMB on P1,
so P2's LDNP isn't guaranteed to see the data from P1's STP (as opposed
to how a regular LDP *is*), and may still load older stale data instead.

Robin.

> 
> Thanks for your comments,
> Brent
> 

^ permalink raw reply

* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: Noralf Trønnes @ 2016-09-20 10:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4990930f-6d69-89c6-4b23-deae3d6713ed@martin.sperl.org>


Den 20.09.2016 12:15, skrev Martin Sperl:
>
>
> On 20.09.2016 10:41, Noralf Tr?nnes wrote:
>>
>> Den 20.09.2016 09:19, skrev Martin Sperl:
>>> Hi Noralf!
>>>
>>> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>>>> Some SMBus protocols use Repeated Start Condition to switch from write
>>>> mode to read mode. Devices like MMA8451 won't work without it.
>>>>
>>>> When downstream implemented support for this in i2c-bcm2708, it broke
>>>> support for some devices, so a module parameter was added and combined
>>>> transfer was disabled by default.
>>>> See https://github.com/raspberrypi/linux/issues/599
>>>> It doesn't seem to have been any investigation into what the problem
>>>> really was. Later there was added a timeout on the polling loop.
>>>>
>>>> One of the devices mentioned to partially stop working was DS1307.
>>>>
>>>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>>>> and AT24C32 (eeprom) in parallel without problems.
>>>>
>>>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>>>> ---
>>>>   drivers/i2c/busses/i2c-bcm2835.c | 107
>>>> +++++++++++++++++++++++++++++++++++----
>>>>   1 file changed, 98 insertions(+), 9 deletions(-)
>>> ...
>>>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>>>> *adap, struct i2c_msg msgs[],
>>>>       int i;
>>>>       int ret = 0;
>>>>   +    /* Combined write-read to the same address (smbus) */
>>>> +    if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>>> +        !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>>> +        (msgs[0].len <= 16)) {
>>>> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>>> +
>>>> +    return ret ? ret : 2;
>>>> +    }
>>>> +
>>>>       for (i = 0; i < num; i++) {
>>>> -        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>>>> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>>>>           if (ret)
>>>>               break;
>>>>       }
>>> This does not seem to implement the i2c_msg api correctly.
>>>
>>> As per comments in include/uapi/linux/i2c.h on line 58 only the last
>>> message
>>> in a group should - by default - send a STOP.
>>>
>>
>> Apparently it's a known problem that the i2c controller doesn't support
>> Repeated Start. It will always issue a Stop when it has transferred DLEN
>> bytes.
>> Refs:
>> http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they 
>>
>>
>>
>> UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is 
>> set
>> and before DONE is set (or the last byte is shifted, I don't know 
>> excatly).
>> Refs:
>> https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
>> https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834 
>>
>>
>>
>> I found this answer/report by joan that the downstream combined support
>> isn't reliable:
>> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they 
>>
>>
>>
>> My implementation differs from downstream in that I use local_irq_save()
>> to protect the polling loop. But that only protects from missing the TA
>> (downstream can miss the TA and issue a Stop).
>>
>> So currently in mainline we have a driver that says it support the 
>> standard
>> (I2C_FUNC_I2C), but it really only supports one message transfers 
>> since it
>> can't do ReStart.
>>
>> What I have done in this patch is to support ReStart for transfers with
>> 2 messages: first write, then read. But maybe a better solution is to 
>> just
>> leave this alone if it is flaky and use bitbanging instead. I don't 
>> know.
> I have not said that the approach you have taken is wrong or bad.
>

I didn't take it as such, I'm just not sure what's the best approach here,
so I added and looked up some more information

> I was only telling you that the portion inside the bcm2835_i2c_xfer:
> +    /* Combined write-read to the same address (smbus) */
> +    if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
> +        !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
> +        (msgs[0].len <= 16)) {
> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
> +
> +        return ret ? ret : 2;
> +    }
> is very specific and maybe could be done in a "generic" manner
> supporting more cases.
>

It has to be specific when it comes to number of messages. We can only
support ReStart after the first message unless we use polling for the
whole transfer. And in that case we can't disable interrupts for such
a long period and we will end up sometimes loosing Transfer Active,
resulting in Stop Condition between the messages.
So we can only do transfers with 2 messages if we want Restart.

It is possible to support more than 16 bytes for the first message,
filling the FIFO after polling TA, but I'm not sure that is common.
Mostly it's 1 or 2 bytes to set a register.
The write-read restriction isn't absolutely necessary either, but it's the
most common case I think. So it was about reusing bcm2835_i2c_xfer_msg().
A less restrictive approach would require a dedicated function I think.

> At least add a dev_warn_once for all num > 1 cases not handled by the
> code above.
>
> This gives people an opportunity to detect such a situation if they
> find something is not working as expected.
>

I agree.

After reading joan's report I wonder if it would be best to add a module
parameter like downstream has, so it can be disabled. What do you think?


Noralf.

^ permalink raw reply

* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Philipp Zabel @ 2016-09-20 10:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAK7LNASDYjUjUoUEstFygA1GOboVgDTNKak8Zkpcj_B3XbK-1w@mail.gmail.com>

Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada:
> Hi Philipp,
> 
> 
> 2016-09-20 16:30 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> > Hi Masahiro,
> >
> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
> >> merged.  Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
> >>
> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >> ---
> >>
> >> Philipp,
> >>
> >> IIRC, you mentioned that you were planning to consolidate the double
> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
> >>
> >> I have not seen it in the ML, so I am sending this.
> >>
> >> Please let me know if you have some updates.
> >
> > I had started to doodle a bit, see
> >
> >     git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
> >
> > but I haven't found time for cleanup and testing.
> 
> 
> OK, I will merge this patch for now.
> 
> 
> 
> BTW, I did not understand some of your commits under way.
> 
> 
> commit 7fe911f9c83737449565db03bebf953d3d94bbbf
> Author: Philipp Zabel <p.zabel@pengutronix.de>
> Date:   Tue Aug 9 11:18:51 2016 +0200
> 
>     dmaengine: sunx6i: do not depend on reset controller framework
> 
>     The reset controller framework provides inline function stubs if
>     disabled.
> 
>     Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> 
> 
> 
> 
> 
> As far as I see from drivers/dma/sun6i-dma.c,
> the reset control is mandatory for this driver.
> 
> Why are you removing the dependency?
> 
> 
> Don't you care if it works on run-time
> as long as it can build?

I have not thought about this too hard, it's just there because the
reset framework is not a build dependency (anymore). Some patches were
necessary to remove dependency loops, but I think this one could just be
dropped.

regards
Philipp

^ permalink raw reply

* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Robert Richter @ 2016-09-20 10:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474310970-21264-1-git-send-email-ddaney.cavm@gmail.com>

David,

On 19.09.16 11:49:30, David Daney wrote:
> Fix by supplying a cpu_to_node() implementation that returns correct
> node mappings.

> +int cpu_to_node(int cpu)
> +{
> +	int nid;
> +
> +	/*
> +	 * Return 0 for unknown mapping so that we report something
> +	 * sensible if firmware doesn't supply a proper mapping.
> +	 */
> +	if (cpu < 0 || cpu >= NR_CPUS)
> +		return 0;
> +
> +	nid = cpu_to_node_map[cpu];
> +	if (nid == NUMA_NO_NODE)
> +		nid = 0;
> +	return nid;
> +}
> +EXPORT_SYMBOL(cpu_to_node);

this implementation fixes the per-cpu workqueue initialization, but I
don't think a cpu_to_node() implementation private to arm64 is the
proper solution.

Apart from better using generic code, the cpu_to_node() function is
called in the kernel's fast path. I think your implementation is too
expensive and also does not consider per-cpu data access for the
lookup as the generic code does. Secondly, numa_off is not considered
at all.

Instead we need to make sure the set_*numa_node() functions are called
earlier before secondary cpus are booted. My suggested change for that
is this:


diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d93d43352504..952365c2f100 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -204,7 +204,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 static void smp_store_cpu_info(unsigned int cpuid)
 {
 	store_cpu_topology(cpuid);
-	numa_store_cpu_info(cpuid);
 }
 
 /*
@@ -719,6 +718,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 			continue;
 
 		set_cpu_present(cpu, true);
+		numa_store_cpu_info(cpu);
 	}
 }
 

I have tested the code and it properly sets up all per-cpu workqueues.

Unfortunately either your nor my code does fix the BUG_ON() I see with
the numa kernel:

 kernel BUG at mm/page_alloc.c:1848!

See below for the core dump. It looks like this happens due to moving
a mem block where first and last page are mapped to different numa
nodes, thus, triggering the BUG_ON().

Continuing with my investigations...

-Robert



[    9.674272] ------------[ cut here ]------------
[    9.678881] kernel BUG at mm/page_alloc.c:1848!
[    9.683406] Internal error: Oops - BUG: 0 [#1] SMP
[    9.688190] Modules linked in:
[    9.691247] CPU: 77 PID: 1 Comm: swapper/0 Tainted: G        W       4.8.0-rc5.vanilla5-00030-ga2b86cb3ce72 #38
[    9.701322] Hardware name: www.cavium.com ThunderX CRB-2S/ThunderX CRB-2S, BIOS 0.3 Aug 24 2016
[    9.710008] task: ffff800fe4561400 task.stack: ffff800ffbe0c000
[    9.715939] PC is at move_freepages+0x160/0x168
[    9.720460] LR is at move_freepages+0x160/0x168
[    9.724979] pc : [<ffff0000081ec7d0>] lr : [<ffff0000081ec7d0>] pstate: 600000c5
[    9.732362] sp : ffff800ffbe0f510
[    9.735666] x29: ffff800ffbe0f510 x28: ffff7fe043f80020
[    9.740975] x27: ffff7fe043f80000 x26: 000000000000000c
[    9.746283] x25: 000000000000000c x24: ffff810ffffaf0e0
[    9.751591] x23: 0000000000000001 x22: 0000000000000000
[    9.756898] x21: ffff7fe043ffffc0 x20: ffff810ffffaeb00
[    9.762206] x19: ffff7fe043f80000 x18: 0000000000000010
[    9.767513] x17: 0000000000000000 x16: 0000000100000000
[    9.772821] x15: ffff000088f03f37 x14: 6e2c303d64696e2c
[    9.778128] x13: 3038336566666666 x12: 6630303866666666
[    9.783436] x11: 3d656e6f7a203a64 x10: 0000000000000536 
[    9.788744] x9 : 0000000000000060 x8 : 3030626561666666 
[    9.794051] x7 : 6630313866666666 x6 : ffff000008f03f97 
[    9.799359] x5 : 0000000000000006 x4 : 000000000000000c 
[    9.804667] x3 : 0000000000010000 x2 : 0000000000010000 
[    9.809975] x1 : ffff000008da7be0 x0 : 0000000000000050 

[   10.517213] Call trace:
[   10.519651] Exception stack(0xffff800ffbe0f340 to 0xffff800ffbe0f470)
[   10.526081] f340: ffff7fe043f80000 0001000000000000 ffff800ffbe0f510 ffff0000081ec7d0
[   10.533900] f360: ffff000008f03988 0000000008da7bc8 ffff800ffbe0f410 ffff0000081275fc
[   10.541718] f380: ffff800ffbe0f470 ffff000008ac5a00 ffff7fe043ffffc0 0000000000000000
[   10.549536] f3a0: 0000000000000001 ffff810ffffaf0e0 000000000000000c 000000000000000c
[   10.557355] f3c0: ffff7fe043f80000 ffff7fe043f80020 0000000000000030 0000000000000000
[   10.565173] f3e0: 0000000000000050 ffff000008da7be0 0000000000010000 0000000000010000
[   10.572991] f400: 000000000000000c 0000000000000006 ffff000008f03f97 6630313866666666
[   10.580809] f420: 3030626561666666 0000000000000060 0000000000000536 3d656e6f7a203a64
[   10.588628] f440: 6630303866666666 3038336566666666 6e2c303d64696e2c ffff000088f03f37
[   10.596446] f460: 0000000100000000 0000000000000000
[   10.601316] [<ffff0000081ec7d0>] move_freepages+0x160/0x168
[   10.606879] [<ffff0000081ec880>] move_freepages_block+0xa8/0xb8
[   10.612788] [<ffff0000081ecf80>] __rmqueue+0x610/0x670
[   10.617918] [<ffff0000081ee2e4>] get_page_from_freelist+0x3cc/0xb40
[   10.624174] [<ffff0000081ef05c>] __alloc_pages_nodemask+0x12c/0xd40
[   10.630438] [<ffff000008244cd0>] alloc_page_interleave+0x60/0xb0
[   10.636434] [<ffff000008245398>] alloc_pages_current+0x108/0x168
[   10.642430] [<ffff0000081e49ac>] __page_cache_alloc+0x104/0x140
[   10.648339] [<ffff0000081e4b00>] pagecache_get_page+0x118/0x2e8
[   10.654248] [<ffff0000081e4d18>] grab_cache_page_write_begin+0x48/0x68
[   10.660769] [<ffff000008298c08>] simple_write_begin+0x40/0x150
[   10.666591] [<ffff0000081e47c0>] generic_perform_write+0xb8/0x1a0
[   10.672674] [<ffff0000081e6228>] __generic_file_write_iter+0x178/0x1c8
[   10.679191] [<ffff0000081e6344>] generic_file_write_iter+0xcc/0x1c8
[   10.685448] [<ffff00000826d12c>] __vfs_write+0xcc/0x140
[   10.690663] [<ffff00000826de08>] vfs_write+0xa8/0x1c0
[   10.695704] [<ffff00000826ee34>] SyS_write+0x54/0xb0
[   10.700666] [<ffff000008bf2008>] xwrite+0x34/0x7c
[   10.705359] [<ffff000008bf20ec>] do_copy+0x9c/0xf4
[   10.710140] [<ffff000008bf1dc4>] write_buffer+0x34/0x50
[   10.715354] [<ffff000008bf1e28>] flush_buffer+0x48/0xb8
[   10.720579] [<ffff000008c1faa0>] __gunzip+0x27c/0x324
[   10.725620] [<ffff000008c1fb60>] gunzip+0x18/0x20
[   10.730314] [<ffff000008bf26dc>] unpack_to_rootfs+0x168/0x280
[   10.736049] [<ffff000008bf2864>] populate_rootfs+0x70/0x138
[   10.741615] [<ffff000008082ff4>] do_one_initcall+0x44/0x138
[   10.747179] [<ffff000008bf0d0c>] kernel_init_freeable+0x1ac/0x24c
[   10.753267] [<ffff000008859f78>] kernel_init+0x20/0xf8
[   10.758395] [<ffff000008082b80>] ret_from_fork+0x10/0x50
[   10.763698] Code: 17fffff2 b00046c0 91280000 97ffd47d (d4210000) 
[   10.769834] ---[ end trace 972d622f64fd69c0 ]---

^ permalink raw reply related

* [PATCH] arm64: kgdb: handle read-only text / modules
From: Mark Rutland @ 2016-09-20 10:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160920100321.17846-1-takahiro.akashi@linaro.org>

On Tue, Sep 20, 2016 at 07:03:21PM +0900, AKASHI Takahiro wrote:
> Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> by using aarch64_insn_write() instead of probe_kernel_write().
> See how this works:
>     commit 2f896d586610 ("arm64: use fixmap for text patching")
> 
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Jason Wessel <jason.wessel@windriver.com>
> Cc: <stable@vger.kernel.org> # 4.0-

We had SET_MODULE_RONX in v3.17, and we had KGDB before that, so we need
something for v3.17+.

> ---
>  arch/arm64/kernel/kgdb.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index 6732a27..133cfe3 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -382,3 +382,23 @@ struct kgdb_arch arch_kgdb_ops = {
>  		KGDB_DYN_BRK_INS_BYTE(3),
>  	}
>  };
> +int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> +{
> +	int err;
> +
> +	BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
> +
> +	err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
> +	if (err)
> +		return err;
> +
> +	return aarch64_insn_write((void *)bpt->bpt_addr,
> +			(u32)AARCH64_BREAK_KGDB_DYN_DBG);
> +}

This changes the endianness of saved_instr (on BE), but it looks like
that's handed as an opaque token by the core code anyway, so that should
be fine.

This also renders arch_kgdb_ops.gdb_bpt_instr unused. Can/should we get
rid of that?

> +int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> +{
> +	return aarch64_insn_write((void *)bpt->bpt_addr,
> +			*(u32 *)bpt->saved_instr);
> +}

We also need a few additional includes:

<asm/debug-monitors.h> # for BREAK_INSTR_SIZE, AARCH64_BREAK_KGDB_DYN_DBG
<asm/insn.h> # for AARCH64_INSN_SIZE, insn_{read,write}
<linux/bug.h> # for BUILD_BUG_ON()

I take it that we're protected against nesting within
aarch64_insn_write(), so that we can't deadlock on patch_lock?

Other than that, this looks good to me.

Thanks,
Mark.

^ permalink raw reply

* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Marc Zyngier @ 2016-09-20 10:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <57E109CF.8030705@suse.de>

On 20/09/16 11:05, Alexander Graf wrote:
> On 09/20/2016 11:39 AM, Marc Zyngier wrote:
>> On 20/09/16 10:26, Alexander Graf wrote:
>>>
>>> On 20.09.16 11:21, Marc Zyngier wrote:
>>>> On 19/09/16 18:39, Alexander Graf wrote:
>>>>>
>>>>> On 19.09.16 16:48, Marc Zyngier wrote:
>>>>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>>>>
>>>>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>>>>> about timer events that may result in interrupt line state changes, so we
>>>>>>> lose out on timer events if we run with user space gic emulation.
>>>>>>>
>>>>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>>>>> emulation.
>>>>>>>
>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> v1 -> v2:
>>>>>>>
>>>>>>>    - Add back curly brace that got lost
>>>>>>>
>>>>>>> v2 -> v3:
>>>>>>>
>>>>>>>    - Split into patch set
>>>>>>>
>>>>>>> v3 -> v4:
>>>>>>>
>>>>>>>    - Improve documentation
>>>>>>> ---
>>>>>>>   Documentation/virtual/kvm/api.txt |  30 ++++++++-
>>>>>>>   arch/arm/include/asm/kvm_host.h   |   3 +
>>>>>>>   arch/arm/kvm/arm.c                |  22 ++++---
>>>>>>>   arch/arm64/include/asm/kvm_host.h |   3 +
>>>>>>>   include/uapi/linux/kvm.h          |  14 +++++
>>>>>>>   virt/kvm/arm/arch_timer.c         | 125 +++++++++++++++++++++++++++-----------
>>>>>>>   6 files changed, 155 insertions(+), 42 deletions(-)
>>>>>>>
>>>>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>>>>> index 23937e0..1c0bd86 100644
>>>>>>> --- a/Documentation/virtual/kvm/api.txt
>>>>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>>>>   	/* in */
>>>>>>>   	__u8 request_interrupt_window;
>>>>>>>   
>>>>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>>>>   interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
>>>>>>>   
>>>>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>>>>> +trigger forever. These lines are available:
>>>>>>> +
>>>>>>> +    KVM_IRQWINDOW_VTIMER  -  Masks hw virtual timer irq while in guest
>>>>>>> +
>>>>>>>   	__u8 padding1[7];
>>>>>>>   
>>>>>>>   	/* out */
>>>>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>>>>   event/message pages and to enable/disable SynIC messages/events processing
>>>>>>>   in userspace.
>>>>>>>   
>>>>>>> +		/* KVM_EXIT_ARM_TIMER */
>>>>>>> +		struct {
>>>>>>> +			__u8 timesource;
>>>>>>> +		} arm_timer;
>>>>>>> +
>>>>>>> +Indicates that a timer triggered that user space needs to handle and
>>>>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>>>>> +guest to proceed. This only happens for timers that got enabled through
>>>>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>>>>> +
>>>>>>> +    KVM_ARM_TIMER_VTIMER  - virtual cpu timer
>>>>>>> +
>>>>>>>   		/* Fix the size of the union. */
>>>>>>>   		char padding[256];
>>>>>>>   	};
>>>>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>>>>   accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>>>>   the guest.
>>>>>>>   
>>>>>>> +6.11 KVM_CAP_ARM_TIMER
>>>>>>> +
>>>>>>> +Architectures: arm, arm64
>>>>>>> +Target: vcpu
>>>>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>>>>> +
>>>>>>> +This capability allows to route per-core timers into user space. When it's
>>>>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>>>>> +
>>>>>>>   7. Capabilities that can be enabled on VMs
>>>>>>>   ------------------------------------------
>>>>>>>   
>>>>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>>>>> index de338d9..77d1f73 100644
>>>>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>>>>   
>>>>>>>   	/* Detect first run of a vcpu */
>>>>>>>   	bool has_run_once;
>>>>>>> +
>>>>>>> +	/* User space wants timer notifications */
>>>>>>> +	bool user_space_arm_timers;
>>>>>> Please move this to the timer structure.
>>>>> Sure.
>>>>>
>>>>>>>   };
>>>>>>>   
>>>>>>>   struct kvm_vm_stat {
>>>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>>>> index c84b6ad..57bdb71 100644
>>>>>>> --- a/arch/arm/kvm/arm.c
>>>>>>> +++ b/arch/arm/kvm/arm.c
>>>>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>>>>   	case KVM_CAP_ARM_PSCI_0_2:
>>>>>>>   	case KVM_CAP_READONLY_MEM:
>>>>>>>   	case KVM_CAP_MP_STATE:
>>>>>>> +	case KVM_CAP_ARM_TIMER:
>>>>>>>   		r = 1;
>>>>>>>   		break;
>>>>>>>   	case KVM_CAP_COALESCED_MMIO:
>>>>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>>>>   			return ret;
>>>>>>>   	}
>>>>>>>   
>>>>>>> -	/*
>>>>>>> -	 * Enable the arch timers only if we have an in-kernel VGIC
>>>>>>> -	 * and it has been properly initialized, since we cannot handle
>>>>>>> -	 * interrupts from the virtual timer with a userspace gic.
>>>>>>> -	 */
>>>>>>> -	if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>>>>> -		ret = kvm_timer_enable(vcpu);
>>>>>>> +	ret = kvm_timer_enable(vcpu);
>>>>>>>   
>>>>>>>   	return ret;
>>>>>>>   }
>>>>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>>>   			run->exit_reason = KVM_EXIT_INTR;
>>>>>>>   		}
>>>>>>>   
>>>>>>> +		if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>>>> Since this is a very unlikely event (in the grand scheme of things), how
>>>>>> about making this unlikely()?
>>>>>>
>>>>>>> +			/* Tell user space about the pending vtimer */
>>>>>>> +			ret = 0;
>>>>>>> +			run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>>>>> +			run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>>>>> +		}
>>>>>> More importantly: why does it have to be indirected by a
>>>>>> make_request/check_request, and not be handled as part of the
>>>>>> kvm_timer_sync() call? We do update the state there, and you could
>>>>>> directly find out whether an exit is required.
>>>>> I can try - it seemed like it could easily become quite racy because we
>>>>> call kvm_timer_sync_hwstate() at multiple places.
>>>> It shouldn't. We only do it at exactly two locations (depending whether
>>>> we've entered the guest or not).
>>>>
>>>> Also, take the following scenario:
>>>> (1) guest programs the timer to expire at time T
>>>> (2) guest performs an MMIO access which traps
>>>> (3) during the world switch, the timer expires and we mark the timer
>>>> interrupt as pending
>>>> (4) we exit to handle the MMIO, no sign of the timer being pending
>>>>
>>>> Is the timer event lost? Or simply delayed? I think this indicates that
>>>> the timer state should always be signalled to userspace, no matter what
>>>> the exit reason is.
>>> That's basically what I'm trying to get running right now, yes. I pushed
>>> the interrupt pending status field into the kvm_sync_regs struct and
>>> check it on every exit in user space - to make sure we catch pending
>>> state changes before mmio reads.
>>>
>>> On top of that we also need a force exit event when the state changes,
>>> in case there's no other event pending. Furthermore we probably want to
>>> indicate the user space status of the pending bit into the kernel to not
>>> exit too often.
>> All you need is to do is to stash the line state in the run structure.
> 
> That's what I do now, yes. The sync_regs struct is basically an arch 
> specific add-on to the run structure, so we don't modify padding / 
> alignment with the change.
> 
>> You shouldn't need any other information. And you trigger the exit on
>> "timer line high + timer line unmasked" in order to inject the
>> interrupt. Which is basically what the vgic does. It would greatly help
>> if you adopted a similar behaviour.
> 
> We also need to know "timer line low + timer line masked", as otherwise 
> we might get spurious interrupts in the guest, no?

Yes. Though you can't really know about this one, and you'll have to
wait until the next natural exit to find out. As long as the spurious is
"spurious in the GIC sense" (hence returning 0x3ff) and not a spurious
timer interrupt being presented, you're fine.

> Either way, I agree that this approach in general is saner. I don't 
> think it's easier to implement though, but we'll get to that when I send 
> a new version :)

OK.

	M
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [GIT PULL] iommu/arm-smmu: Updates for 4.9
From: Will Deacon @ 2016-09-20 10:25 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Joerg,

Please pull these significant arm-smmu updates for 4.9. The vast majority
of the code here is Robin's series to move the drivers over to the
generic DT bindings, which finally hooks up the DMA API and MSI mapping
for host machines. This has been stewing for a while and is now at the
point where I feel it's much better in mainline than languishing outside.

A consequence of that is that there are some non-trivial changes outside
of the drivers, but these are all acked by the relevant subsystem
maintainers.

Other stuff here includes some non-critical fixes to the queue handling
on SMMUv3 and a small devm cleanup that missed the boat last time around.

Cheers,

Will

--->8

The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8:

  Linux 4.8-rc4 (2016-08-28 15:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-joerg/arm-smmu/updates

for you to fetch changes up to 82db33dc5e49fb625262d81125625d07a0d6184e:

  iommu/io-pgtable-arm: Check for v7s-incapable systems (2016-09-16 09:34:23 +0100)

----------------------------------------------------------------
Jean-Philippe Brucker (2):
      iommu/arm-smmu: Fix event queues synchronization
      iommu/arm-smmu: Fix polling of command queue

Mark Rutland (1):
      Docs: dt: add PCI IOMMU map bindings

Peng Fan (1):
      iommu/arm-smmu: Drop devm_free_irq when driver detach

Robin Murphy (23):
      iommu/arm-smmu: Support v7s context format
      of/irq: Break out msi-map lookup (again)
      iommu/of: Handle iommu-map property for PCI
      iommu: Introduce iommu_fwspec
      Docs: dt: document ARM SMMUv3 generic binding usage
      iommu/arm-smmu: Fall back to global bypass
      iommu/arm-smmu: Implement of_xlate() for SMMUv3
      iommu/arm-smmu: Support non-PCI devices with SMMUv3
      iommu/arm-smmu: Set PRIVCFG in stage 1 STEs
      iommu/arm-smmu: Handle stream IDs more dynamically
      iommu/arm-smmu: Consolidate stream map entry state
      iommu/arm-smmu: Keep track of S2CR state
      iommu/arm-smmu: Refactor mmu-masters handling
      iommu/arm-smmu: Streamline SMMU data lookups
      iommu/arm-smmu: Add a stream map entry iterator
      iommu/arm-smmu: Intelligent SMR allocation
      iommu/arm-smmu: Convert to iommu_fwspec
      Docs: dt: document ARM SMMU generic binding usage
      iommu/arm-smmu: Wire up generic configuration support
      iommu/arm-smmu: Set domain geometry
      iommu/dma: Add support for mapping MSIs
      iommu/dma: Avoid PCI host bridge windows
      iommu/io-pgtable-arm: Check for v7s-incapable systems

Will Deacon (1):
      iommu/arm-smmu: Disable interrupts whilst holding the cmdq lock

 .../devicetree/bindings/iommu/arm,smmu-v3.txt      |   8 +-
 .../devicetree/bindings/iommu/arm,smmu.txt         |  61 +-
 .../devicetree/bindings/pci/pci-iommu.txt          | 171 ++++
 arch/arm64/mm/dma-mapping.c                        |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_iommu.h          |   2 +-
 drivers/iommu/Kconfig                              |   2 +-
 drivers/iommu/arm-smmu-v3.c                        | 561 ++++++------
 drivers/iommu/arm-smmu.c                           | 995 ++++++++++-----------
 drivers/iommu/dma-iommu.c                          | 161 +++-
 drivers/iommu/io-pgtable-arm-v7s.c                 |   4 +
 drivers/iommu/iommu.c                              |  58 ++
 drivers/iommu/of_iommu.c                           |  52 +-
 drivers/irqchip/irq-gic-v2m.c                      |   3 +
 drivers/irqchip/irq-gic-v3-its.c                   |   3 +
 drivers/of/irq.c                                   |  78 +-
 drivers/of/of_pci.c                                | 102 +++
 include/linux/device.h                             |   3 +
 include/linux/dma-iommu.h                          |  12 +-
 include/linux/iommu.h                              |  39 +
 include/linux/of_pci.h                             |  10 +
 20 files changed, 1430 insertions(+), 897 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt

^ permalink raw reply

* [PATCH 2/3] i2c: bcm2835: Add support for combined write-read transfer
From: Martin Sperl @ 2016-09-20 10:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <fb5e8e93-c6af-0050-1e7d-a69b722feadb@tronnes.org>



On 20.09.2016 10:41, Noralf Tr?nnes wrote:
>
> Den 20.09.2016 09:19, skrev Martin Sperl:
>> Hi Noralf!
>>
>> On 19.09.2016 17:26, Noralf Tr?nnes wrote:
>>> Some SMBus protocols use Repeated Start Condition to switch from write
>>> mode to read mode. Devices like MMA8451 won't work without it.
>>>
>>> When downstream implemented support for this in i2c-bcm2708, it broke
>>> support for some devices, so a module parameter was added and combined
>>> transfer was disabled by default.
>>> See https://github.com/raspberrypi/linux/issues/599
>>> It doesn't seem to have been any investigation into what the problem
>>> really was. Later there was added a timeout on the polling loop.
>>>
>>> One of the devices mentioned to partially stop working was DS1307.
>>>
>>> I have run thousands of transfers to a DS1307 (rtc), MMA8451 (accel)
>>> and AT24C32 (eeprom) in parallel without problems.
>>>
>>> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
>>> ---
>>>   drivers/i2c/busses/i2c-bcm2835.c | 107
>>> +++++++++++++++++++++++++++++++++++----
>>>   1 file changed, 98 insertions(+), 9 deletions(-)
>> ...
>>> @@ -209,8 +289,17 @@ static int bcm2835_i2c_xfer(struct i2c_adapter
>>> *adap, struct i2c_msg msgs[],
>>>       int i;
>>>       int ret = 0;
>>>   +    /* Combined write-read to the same address (smbus) */
>>> +    if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
>>> +        !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
>>> +        (msgs[0].len <= 16)) {
>>> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
>>> +
>>> +    return ret ? ret : 2;
>>> +    }
>>> +
>>>       for (i = 0; i < num; i++) {
>>> -        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i]);
>>> +        ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[i], NULL);
>>>           if (ret)
>>>               break;
>>>       }
>> This does not seem to implement the i2c_msg api correctly.
>>
>> As per comments in include/uapi/linux/i2c.h on line 58 only the last
>> message
>> in a group should - by default - send a STOP.
>>
>
> Apparently it's a known problem that the i2c controller doesn't support
> Repeated Start. It will always issue a Stop when it has transferred DLEN
> bytes.
> Refs:
> http://www.circuitwizard.de/raspi-i2c-fix/raspi-i2c-fix.html
> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>
>
> UNLESS: a Start Transfer (ST) is issued after Transfer Active (TA) is set
> and before DONE is set (or the last byte is shifted, I don't know excatly).
> Refs:
> https://github.com/raspberrypi/linux/issues/254#issuecomment-15254134
> https://www.raspberrypi.org/forums/viewtopic.php?p=807834&sid=2b612c7209f2175bf1a266359c72ae6c#p807834
>
>
> I found this answer/report by joan that the downstream combined support
> isn't reliable:
> http://raspberrypi.stackexchange.com/questions/31728/has-anyone-successfully-used-i2c-repeated-starts-on-the-pi2-my-scope-says-they
>
>
> My implementation differs from downstream in that I use local_irq_save()
> to protect the polling loop. But that only protects from missing the TA
> (downstream can miss the TA and issue a Stop).
>
> So currently in mainline we have a driver that says it support the standard
> (I2C_FUNC_I2C), but it really only supports one message transfers since it
> can't do ReStart.
>
> What I have done in this patch is to support ReStart for transfers with
> 2 messages: first write, then read. But maybe a better solution is to just
> leave this alone if it is flaky and use bitbanging instead. I don't know.
I have not said that the approach you have taken is wrong or bad.

I was only telling you that the portion inside the bcm2835_i2c_xfer:
+	/* Combined write-read to the same address (smbus) */
+	if (num == 2 && (msgs[0].addr == msgs[1].addr) &&
+	    !(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
+	    (msgs[0].len <= 16)) {
+		ret = bcm2835_i2c_xfer_msg(i2c_dev, &msgs[0], &msgs[1]);
+
+		return ret ? ret : 2;
+	}
is very specific and maybe could be done in a "generic" manner
supporting more cases.

At least add a dev_warn_once for all num > 1 cases not handled by the
code above.

This gives people an opportunity to detect such a situation if they
find something is not working as expected.

Martin

^ permalink raw reply

* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Hanjun Guo @ 2016-09-20 10:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474310970-21264-1-git-send-email-ddaney.cavm@gmail.com>

On 09/20/2016 02:49 AM, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> The wq_numa_init() function makes a private CPU to node map by calling
> cpu_to_node() early in the boot process, before the non-boot CPUs are
> brought online.  Since the default implementation of cpu_to_node()
> returns zero for CPUs that have never been brought online, the
> workqueue system's view is that *all* CPUs are on node zero.
>
> When the unbound workqueue for a non-zero node is created, the
> tsk_cpus_allowed() for the worker threads is the empty set because
> there are, in the view of the workqueue system, no CPUs on non-zero
> nodes.  The code in try_to_wake_up() using this empty cpumask ends up
> using the cpumask empty set value of NR_CPUS as an index into the
> per-CPU area pointer array, and gets garbage as it is one past the end
> of the array.  This results in:
>
> [    0.881970] Unable to handle kernel paging request at virtual address fffffb1008b926a4
> [    1.970095] pgd = fffffc00094b0000
> [    1.973530] [fffffb1008b926a4] *pgd=0000000000000000, *pud=0000000000000000, *pmd=0000000000000000
> [    1.982610] Internal error: Oops: 96000004 [#1] SMP
> [    1.987541] Modules linked in:
> [    1.990631] CPU: 48 PID: 295 Comm: cpuhp/48 Tainted: G        W       4.8.0-rc6-preempt-vol+ #9
> [    1.999435] Hardware name: Cavium ThunderX CN88XX board (DT)
> [    2.005159] task: fffffe0fe89cc300 task.stack: fffffe0fe8b8c000
> [    2.011158] PC is at try_to_wake_up+0x194/0x34c
> [    2.015737] LR is at try_to_wake_up+0x150/0x34c
> [    2.020318] pc : [<fffffc00080e7468>] lr : [<fffffc00080e7424>] pstate: 600000c5
> [    2.027803] sp : fffffe0fe8b8fb10
> [    2.031149] x29: fffffe0fe8b8fb10 x28: 0000000000000000
> [    2.036522] x27: fffffc0008c63bc8 x26: 0000000000001000
> [    2.041896] x25: fffffc0008c63c80 x24: fffffc0008bfb200
> [    2.047270] x23: 00000000000000c0 x22: 0000000000000004
> [    2.052642] x21: fffffe0fe89d25bc x20: 0000000000001000
> [    2.058014] x19: fffffe0fe89d1d00 x18: 0000000000000000
> [    2.063386] x17: 0000000000000000 x16: 0000000000000000
> [    2.068760] x15: 0000000000000018 x14: 0000000000000000
> [    2.074133] x13: 0000000000000000 x12: 0000000000000000
> [    2.079505] x11: 0000000000000000 x10: 0000000000000000
> [    2.084879] x9 : 0000000000000000 x8 : 0000000000000000
> [    2.090251] x7 : 0000000000000040 x6 : 0000000000000000
> [    2.095621] x5 : ffffffffffffffff x4 : 0000000000000000
> [    2.100991] x3 : 0000000000000000 x2 : 0000000000000000
> [    2.106364] x1 : fffffc0008be4c24 x0 : ffffff0ffffada80
> [    2.111737]
> [    2.113236] Process cpuhp/48 (pid: 295, stack limit = 0xfffffe0fe8b8c020)
> [    2.120102] Stack: (0xfffffe0fe8b8fb10 to 0xfffffe0fe8b90000)
> [    2.125914] fb00:                                   fffffe0fe8b8fb80 fffffc00080e7648
> .
> .
> .
> [    2.442859] Call trace:
> [    2.445327] Exception stack(0xfffffe0fe8b8f940 to 0xfffffe0fe8b8fa70)
> [    2.451843] f940: fffffe0fe89d1d00 0000040000000000 fffffe0fe8b8fb10 fffffc00080e7468
> [    2.459767] f960: fffffe0fe8b8f980 fffffc00080e4958 ffffff0ff91ab200 fffffc00080e4b64
> [    2.467690] f980: fffffe0fe8b8f9d0 fffffc00080e515c fffffe0fe8b8fa80 0000000000000000
> [    2.475614] f9a0: fffffe0fe8b8f9d0 fffffc00080e58e4 fffffe0fe8b8fa80 0000000000000000
> [    2.483540] f9c0: fffffe0fe8d10000 0000000000000040 fffffe0fe8b8fa50 fffffc00080e5ac4
> [    2.491465] f9e0: ffffff0ffffada80 fffffc0008be4c24 0000000000000000 0000000000000000
> [    2.499387] fa00: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000040
> [    2.507309] fa20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [    2.515233] fa40: 0000000000000000 0000000000000000 0000000000000000 0000000000000018
> [    2.523156] fa60: 0000000000000000 0000000000000000
> [    2.528089] [<fffffc00080e7468>] try_to_wake_up+0x194/0x34c
> [    2.533723] [<fffffc00080e7648>] wake_up_process+0x28/0x34
> [    2.539275] [<fffffc00080d3764>] create_worker+0x110/0x19c
> [    2.544824] [<fffffc00080d69dc>] alloc_unbound_pwq+0x3cc/0x4b0
> [    2.550724] [<fffffc00080d6bcc>] wq_update_unbound_numa+0x10c/0x1e4
> [    2.557066] [<fffffc00080d7d78>] workqueue_online_cpu+0x220/0x28c
> [    2.563234] [<fffffc00080bd288>] cpuhp_invoke_callback+0x6c/0x168
> [    2.569398] [<fffffc00080bdf74>] cpuhp_up_callbacks+0x44/0xe4
> [    2.575210] [<fffffc00080be194>] cpuhp_thread_fun+0x13c/0x148
> [    2.581027] [<fffffc00080dfbac>] smpboot_thread_fn+0x19c/0x1a8
> [    2.586929] [<fffffc00080dbd64>] kthread+0xdc/0xf0
> [    2.591776] [<fffffc0008083380>] ret_from_fork+0x10/0x50
> [    2.597147] Code: b00057e1 91304021 91005021 b8626822 (b8606821)
> [    2.603464] ---[ end trace 58c0cd36b88802bc ]---
> [    2.608138] Kernel panic - not syncing: Fatal exception
>
> Fix by supplying a cpu_to_node() implementation that returns correct
> node mappings.
>
> Cc: <stable@vger.kernel.org> # 4.7.x-
> Signed-off-by: David Daney <david.daney@cavium.com>
>
> ---
>   arch/arm64/include/asm/topology.h |  3 +++
>   arch/arm64/mm/numa.c              | 18 ++++++++++++++++++
>   2 files changed, 21 insertions(+)
>
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index 8b57339..8d935447 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -30,6 +30,9 @@ int pcibus_to_node(struct pci_bus *bus);
>   				 cpu_all_mask :				\
>   				 cpumask_of_node(pcibus_to_node(bus)))
>
> +int cpu_to_node(int cpu);
> +#define cpu_to_node cpu_to_node
> +
>   #endif /* CONFIG_NUMA */
>
>   #include <asm-generic/topology.h>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 5bb15ea..e76281b 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -130,6 +130,24 @@ void __init early_map_cpu_to_node(unsigned int cpu, int nid)
>   	cpu_to_node_map[cpu] = nid;
>   }
>
> +int cpu_to_node(int cpu)
> +{
> +	int nid;
> +
> +	/*
> +	 * Return 0 for unknown mapping so that we report something
> +	 * sensible if firmware doesn't supply a proper mapping.
> +	 */
> +	if (cpu < 0 || cpu >= NR_CPUS)
> +		return 0;
> +
> +	nid = cpu_to_node_map[cpu];
> +	if (nid == NUMA_NO_NODE)
> +		nid = 0;
> +	return nid;
> +}
> +EXPORT_SYMBOL(cpu_to_node);
> +
>   /**
>    * numa_add_memblk - Set node id to memblk
>    * @nid: NUMA node ID of the new memblk

Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>

Thanks for the fix!
Hanjun

^ permalink raw reply

* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-20 10:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <57E103E8.7040506@arm.com>

On 09/20/2016 11:39 AM, Marc Zyngier wrote:
> On 20/09/16 10:26, Alexander Graf wrote:
>>
>> On 20.09.16 11:21, Marc Zyngier wrote:
>>> On 19/09/16 18:39, Alexander Graf wrote:
>>>>
>>>> On 19.09.16 16:48, Marc Zyngier wrote:
>>>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>>>
>>>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>>>> about timer events that may result in interrupt line state changes, so we
>>>>>> lose out on timer events if we run with user space gic emulation.
>>>>>>
>>>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>>>> emulation.
>>>>>>
>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> v1 -> v2:
>>>>>>
>>>>>>    - Add back curly brace that got lost
>>>>>>
>>>>>> v2 -> v3:
>>>>>>
>>>>>>    - Split into patch set
>>>>>>
>>>>>> v3 -> v4:
>>>>>>
>>>>>>    - Improve documentation
>>>>>> ---
>>>>>>   Documentation/virtual/kvm/api.txt |  30 ++++++++-
>>>>>>   arch/arm/include/asm/kvm_host.h   |   3 +
>>>>>>   arch/arm/kvm/arm.c                |  22 ++++---
>>>>>>   arch/arm64/include/asm/kvm_host.h |   3 +
>>>>>>   include/uapi/linux/kvm.h          |  14 +++++
>>>>>>   virt/kvm/arm/arch_timer.c         | 125 +++++++++++++++++++++++++++-----------
>>>>>>   6 files changed, 155 insertions(+), 42 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>>>> index 23937e0..1c0bd86 100644
>>>>>> --- a/Documentation/virtual/kvm/api.txt
>>>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>>>   	/* in */
>>>>>>   	__u8 request_interrupt_window;
>>>>>>   
>>>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>>>   interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
>>>>>>   
>>>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>>>> +trigger forever. These lines are available:
>>>>>> +
>>>>>> +    KVM_IRQWINDOW_VTIMER  -  Masks hw virtual timer irq while in guest
>>>>>> +
>>>>>>   	__u8 padding1[7];
>>>>>>   
>>>>>>   	/* out */
>>>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>>>   event/message pages and to enable/disable SynIC messages/events processing
>>>>>>   in userspace.
>>>>>>   
>>>>>> +		/* KVM_EXIT_ARM_TIMER */
>>>>>> +		struct {
>>>>>> +			__u8 timesource;
>>>>>> +		} arm_timer;
>>>>>> +
>>>>>> +Indicates that a timer triggered that user space needs to handle and
>>>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>>>> +guest to proceed. This only happens for timers that got enabled through
>>>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>>>> +
>>>>>> +    KVM_ARM_TIMER_VTIMER  - virtual cpu timer
>>>>>> +
>>>>>>   		/* Fix the size of the union. */
>>>>>>   		char padding[256];
>>>>>>   	};
>>>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>>>   accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>>>   the guest.
>>>>>>   
>>>>>> +6.11 KVM_CAP_ARM_TIMER
>>>>>> +
>>>>>> +Architectures: arm, arm64
>>>>>> +Target: vcpu
>>>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>>>> +
>>>>>> +This capability allows to route per-core timers into user space. When it's
>>>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>>>> +
>>>>>>   7. Capabilities that can be enabled on VMs
>>>>>>   ------------------------------------------
>>>>>>   
>>>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>>>> index de338d9..77d1f73 100644
>>>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>>>   
>>>>>>   	/* Detect first run of a vcpu */
>>>>>>   	bool has_run_once;
>>>>>> +
>>>>>> +	/* User space wants timer notifications */
>>>>>> +	bool user_space_arm_timers;
>>>>> Please move this to the timer structure.
>>>> Sure.
>>>>
>>>>>>   };
>>>>>>   
>>>>>>   struct kvm_vm_stat {
>>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>>> index c84b6ad..57bdb71 100644
>>>>>> --- a/arch/arm/kvm/arm.c
>>>>>> +++ b/arch/arm/kvm/arm.c
>>>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>>>   	case KVM_CAP_ARM_PSCI_0_2:
>>>>>>   	case KVM_CAP_READONLY_MEM:
>>>>>>   	case KVM_CAP_MP_STATE:
>>>>>> +	case KVM_CAP_ARM_TIMER:
>>>>>>   		r = 1;
>>>>>>   		break;
>>>>>>   	case KVM_CAP_COALESCED_MMIO:
>>>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>>>   			return ret;
>>>>>>   	}
>>>>>>   
>>>>>> -	/*
>>>>>> -	 * Enable the arch timers only if we have an in-kernel VGIC
>>>>>> -	 * and it has been properly initialized, since we cannot handle
>>>>>> -	 * interrupts from the virtual timer with a userspace gic.
>>>>>> -	 */
>>>>>> -	if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>>>> -		ret = kvm_timer_enable(vcpu);
>>>>>> +	ret = kvm_timer_enable(vcpu);
>>>>>>   
>>>>>>   	return ret;
>>>>>>   }
>>>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>>   			run->exit_reason = KVM_EXIT_INTR;
>>>>>>   		}
>>>>>>   
>>>>>> +		if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>>> Since this is a very unlikely event (in the grand scheme of things), how
>>>>> about making this unlikely()?
>>>>>
>>>>>> +			/* Tell user space about the pending vtimer */
>>>>>> +			ret = 0;
>>>>>> +			run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>>>> +			run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>>>> +		}
>>>>> More importantly: why does it have to be indirected by a
>>>>> make_request/check_request, and not be handled as part of the
>>>>> kvm_timer_sync() call? We do update the state there, and you could
>>>>> directly find out whether an exit is required.
>>>> I can try - it seemed like it could easily become quite racy because we
>>>> call kvm_timer_sync_hwstate() at multiple places.
>>> It shouldn't. We only do it at exactly two locations (depending whether
>>> we've entered the guest or not).
>>>
>>> Also, take the following scenario:
>>> (1) guest programs the timer to expire at time T
>>> (2) guest performs an MMIO access which traps
>>> (3) during the world switch, the timer expires and we mark the timer
>>> interrupt as pending
>>> (4) we exit to handle the MMIO, no sign of the timer being pending
>>>
>>> Is the timer event lost? Or simply delayed? I think this indicates that
>>> the timer state should always be signalled to userspace, no matter what
>>> the exit reason is.
>> That's basically what I'm trying to get running right now, yes. I pushed
>> the interrupt pending status field into the kvm_sync_regs struct and
>> check it on every exit in user space - to make sure we catch pending
>> state changes before mmio reads.
>>
>> On top of that we also need a force exit event when the state changes,
>> in case there's no other event pending. Furthermore we probably want to
>> indicate the user space status of the pending bit into the kernel to not
>> exit too often.
> All you need is to do is to stash the line state in the run structure.

That's what I do now, yes. The sync_regs struct is basically an arch 
specific add-on to the run structure, so we don't modify padding / 
alignment with the change.

> You shouldn't need any other information. And you trigger the exit on
> "timer line high + timer line unmasked" in order to inject the
> interrupt. Which is basically what the vgic does. It would greatly help
> if you adopted a similar behaviour.

We also need to know "timer line low + timer line masked", as otherwise 
we might get spurious interrupts in the guest, no?

Either way, I agree that this approach in general is saner. I don't 
think it's easier to implement though, but we'll get to that when I send 
a new version :)


Alex

^ permalink raw reply

* [PATCH] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-20 10:03 UTC (permalink / raw)
  To: linux-arm-kernel

Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
by using aarch64_insn_write() instead of probe_kernel_write().
See how this works:
    commit 2f896d586610 ("arm64: use fixmap for text patching")

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: <stable@vger.kernel.org> # 4.0-
---
 arch/arm64/kernel/kgdb.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index 6732a27..133cfe3 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -382,3 +382,23 @@ struct kgdb_arch arch_kgdb_ops = {
 		KGDB_DYN_BRK_INS_BYTE(3),
 	}
 };
+
+int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+	int err;
+
+	BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
+
+	err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
+	if (err)
+		return err;
+
+	return aarch64_insn_write((void *)bpt->bpt_addr,
+			(u32)AARCH64_BREAK_KGDB_DYN_DBG);
+}
+
+int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
+{
+	return aarch64_insn_write((void *)bpt->bpt_addr,
+			*(u32 *)bpt->saved_instr);
+}
-- 
2.10.0

^ permalink raw reply related

* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: Yisheng Xie @ 2016-09-20  9:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474310970-21264-1-git-send-email-ddaney.cavm@gmail.com>



On 2016/9/20 2:49, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
> 
> The wq_numa_init() function makes a private CPU to node map by calling
> cpu_to_node() early in the boot process, before the non-boot CPUs are
> brought online.  Since the default implementation of cpu_to_node()
> returns zero for CPUs that have never been brought online, the
> workqueue system's view is that *all* CPUs are on node zero.
> 
> When the unbound workqueue for a non-zero node is created, the
> tsk_cpus_allowed() for the worker threads is the empty set because
> there are, in the view of the workqueue system, no CPUs on non-zero
> nodes.  The code in try_to_wake_up() using this empty cpumask ends up
> using the cpumask empty set value of NR_CPUS as an index into the
> per-CPU area pointer array, and gets garbage as it is one past the end
> of the array.  This results in:
> 
> [    0.881970] Unable to handle kernel paging request at virtual address fffffb1008b926a4
> [    1.970095] pgd = fffffc00094b0000
> [    1.973530] [fffffb1008b926a4] *pgd=0000000000000000, *pud=0000000000000000, *pmd=0000000000000000
> [    1.982610] Internal error: Oops: 96000004 [#1] SMP
> [    1.987541] Modules linked in:
> [    1.990631] CPU: 48 PID: 295 Comm: cpuhp/48 Tainted: G        W       4.8.0-rc6-preempt-vol+ #9
> [    1.999435] Hardware name: Cavium ThunderX CN88XX board (DT)
> [    2.005159] task: fffffe0fe89cc300 task.stack: fffffe0fe8b8c000
> [    2.011158] PC is at try_to_wake_up+0x194/0x34c
> [    2.015737] LR is at try_to_wake_up+0x150/0x34c
> [    2.020318] pc : [<fffffc00080e7468>] lr : [<fffffc00080e7424>] pstate: 600000c5
> [    2.027803] sp : fffffe0fe8b8fb10
> [    2.031149] x29: fffffe0fe8b8fb10 x28: 0000000000000000
> [    2.036522] x27: fffffc0008c63bc8 x26: 0000000000001000
> [    2.041896] x25: fffffc0008c63c80 x24: fffffc0008bfb200
> [    2.047270] x23: 00000000000000c0 x22: 0000000000000004
> [    2.052642] x21: fffffe0fe89d25bc x20: 0000000000001000
> [    2.058014] x19: fffffe0fe89d1d00 x18: 0000000000000000
> [    2.063386] x17: 0000000000000000 x16: 0000000000000000
> [    2.068760] x15: 0000000000000018 x14: 0000000000000000
> [    2.074133] x13: 0000000000000000 x12: 0000000000000000
> [    2.079505] x11: 0000000000000000 x10: 0000000000000000
> [    2.084879] x9 : 0000000000000000 x8 : 0000000000000000
> [    2.090251] x7 : 0000000000000040 x6 : 0000000000000000
> [    2.095621] x5 : ffffffffffffffff x4 : 0000000000000000
> [    2.100991] x3 : 0000000000000000 x2 : 0000000000000000
> [    2.106364] x1 : fffffc0008be4c24 x0 : ffffff0ffffada80
> [    2.111737]
> [    2.113236] Process cpuhp/48 (pid: 295, stack limit = 0xfffffe0fe8b8c020)
> [    2.120102] Stack: (0xfffffe0fe8b8fb10 to 0xfffffe0fe8b90000)
> [    2.125914] fb00:                                   fffffe0fe8b8fb80 fffffc00080e7648
> .
> .
> .
> [    2.442859] Call trace:
> [    2.445327] Exception stack(0xfffffe0fe8b8f940 to 0xfffffe0fe8b8fa70)
> [    2.451843] f940: fffffe0fe89d1d00 0000040000000000 fffffe0fe8b8fb10 fffffc00080e7468
> [    2.459767] f960: fffffe0fe8b8f980 fffffc00080e4958 ffffff0ff91ab200 fffffc00080e4b64
> [    2.467690] f980: fffffe0fe8b8f9d0 fffffc00080e515c fffffe0fe8b8fa80 0000000000000000
> [    2.475614] f9a0: fffffe0fe8b8f9d0 fffffc00080e58e4 fffffe0fe8b8fa80 0000000000000000
> [    2.483540] f9c0: fffffe0fe8d10000 0000000000000040 fffffe0fe8b8fa50 fffffc00080e5ac4
> [    2.491465] f9e0: ffffff0ffffada80 fffffc0008be4c24 0000000000000000 0000000000000000
> [    2.499387] fa00: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000040
> [    2.507309] fa20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [    2.515233] fa40: 0000000000000000 0000000000000000 0000000000000000 0000000000000018
> [    2.523156] fa60: 0000000000000000 0000000000000000
> [    2.528089] [<fffffc00080e7468>] try_to_wake_up+0x194/0x34c
> [    2.533723] [<fffffc00080e7648>] wake_up_process+0x28/0x34
> [    2.539275] [<fffffc00080d3764>] create_worker+0x110/0x19c
> [    2.544824] [<fffffc00080d69dc>] alloc_unbound_pwq+0x3cc/0x4b0
> [    2.550724] [<fffffc00080d6bcc>] wq_update_unbound_numa+0x10c/0x1e4
> [    2.557066] [<fffffc00080d7d78>] workqueue_online_cpu+0x220/0x28c
> [    2.563234] [<fffffc00080bd288>] cpuhp_invoke_callback+0x6c/0x168
> [    2.569398] [<fffffc00080bdf74>] cpuhp_up_callbacks+0x44/0xe4
> [    2.575210] [<fffffc00080be194>] cpuhp_thread_fun+0x13c/0x148
> [    2.581027] [<fffffc00080dfbac>] smpboot_thread_fn+0x19c/0x1a8
> [    2.586929] [<fffffc00080dbd64>] kthread+0xdc/0xf0
> [    2.591776] [<fffffc0008083380>] ret_from_fork+0x10/0x50
> [    2.597147] Code: b00057e1 91304021 91005021 b8626822 (b8606821)
> [    2.603464] ---[ end trace 58c0cd36b88802bc ]---
> [    2.608138] Kernel panic - not syncing: Fatal exception
> 
> Fix by supplying a cpu_to_node() implementation that returns correct
> node mappings.
> 
> Cc: <stable@vger.kernel.org> # 4.7.x-
> Signed-off-by: David Daney <david.daney@cavium.com>
> 
Tested-by: Yisheng Xie <xieyisheng1@huawei.com>
> ---
>  arch/arm64/include/asm/topology.h |  3 +++
>  arch/arm64/mm/numa.c              | 18 ++++++++++++++++++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index 8b57339..8d935447 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -30,6 +30,9 @@ int pcibus_to_node(struct pci_bus *bus);
>  				 cpu_all_mask :				\
>  				 cpumask_of_node(pcibus_to_node(bus)))
>  
> +int cpu_to_node(int cpu);
> +#define cpu_to_node cpu_to_node
> +
>  #endif /* CONFIG_NUMA */
>  
>  #include <asm-generic/topology.h>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 5bb15ea..e76281b 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -130,6 +130,24 @@ void __init early_map_cpu_to_node(unsigned int cpu, int nid)
>  	cpu_to_node_map[cpu] = nid;
>  }
>  
> +int cpu_to_node(int cpu)
> +{
> +	int nid;
> +
> +	/*
> +	 * Return 0 for unknown mapping so that we report something
> +	 * sensible if firmware doesn't supply a proper mapping.
> +	 */
> +	if (cpu < 0 || cpu >= NR_CPUS)
> +		return 0;
> +
> +	nid = cpu_to_node_map[cpu];
> +	if (nid == NUMA_NO_NODE)
> +		nid = 0;
> +	return nid;
> +}
> +EXPORT_SYMBOL(cpu_to_node);
> +
>  /**
>   * numa_add_memblk - Set node id to memblk
>   * @nid: NUMA node ID of the new memblk
> 

^ permalink raw reply

* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Thomas Gleixner @ 2016-09-20  9:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <39c4ceee-7e05-ebfd-2ea0-3c4e1c4ea619@st.com>

On Tue, 20 Sep 2016, Alexandre Torgue wrote:
> > On 09/14/2016 03:34 PM, Thomas Gleixner wrote:
> > > Well, you just used some function in some context which is not
> > > relevant to
> > > the normal operation. So adding that mask() is just paranoia for no
> > > value.
> > 
> A gentle reminder ping...
> If ".free" callback is not relevant then I 'll remove it from exti domain.

I was not talking about the .free callback in general. I was talking about
the masking. But yes, if the thing is otherwise a NOOP, then you can spare
it completely.

Thanks,

	tglx

^ permalink raw reply

* [PATCH v6 4/7] arm/arm64: vgic-new: Define required GICv3 reg definitions
From: Marc Zyngier @ 2016-09-20  9:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474351965-11586-5-git-send-email-vijay.kilari@gmail.com>

On 20/09/16 07:12, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> 
> Define register definitions for ICH_VMCR_EL2, ICC_CTLR_EL1 and
> ICH_VTR_EL2, ICC_BPR0_EL1, ICC_BPR1_EL1 registers.
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>

$SUBJECT should report "irqchip/gic-v3: Add missing system register
definitions", or something similar.

Also, please drop this "vgic-new", as there is no vgic-old anymore.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH v5 2/9] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre Torgue @ 2016-09-20  9:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <f64e4f9d-d811-2c6e-7c5a-d4ab06716e2c@st.com>

Hi Thomas,

On 09/14/2016 03:44 PM, Alexandre Torgue wrote:
>
>
> On 09/14/2016 03:34 PM, Thomas Gleixner wrote:
>> On Wed, 14 Sep 2016, Alexandre Torgue wrote:
>>> On 09/14/2016 11:19 AM, Thomas Gleixner wrote:
>>>>
>>>> Now what really bugs me is that you do that at all. An interrupt
>>>> which is
>>>> freed must be masked already. Why is it unmasked in the first place?
>>>
>>> Honestly I don't know. When "devm_free_irq" is called to release
>>> virq, there
>>> is no issue and interrupt is well masked. But, when I tried to use
>>> "irq_dispose_mapping(virq)" I observed that .free is called (child
>>> and parent
>>> domain) but interrupt is not masked.
>>
>> Well, you just used some function in some context which is not
>> relevant to
>> the normal operation. So adding that mask() is just paranoia for no
>> value.
>
A gentle reminder ping...
If ".free" callback is not relevant then I 'll remove it from exti domain.

> I agree. I just wanted to "force" a test for .free callback. If it not
> relevant I'll remove ".free" callback of exti domain.
> As a part of this series has already been taken by Linus (pinctrl part),
> I will send a new series only for irqchip part (patches [1] and [2]). Do
> you agree ?
>

Thanks in advance
Alex

> Thanks
> Alex
>
>
>>
>> Thanks,
>>
>>     tglx
>>
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-20  9:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <87shsv6ni8.fsf@free-electrons.com>

On Tuesday, September 20, 2016 9:25:51 AM CEST Gregory CLEMENT wrote:
> Hi Arnd,
>  
>  On lun., sept. 19 2016, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > On Monday, September 19, 2016 11:46:22 PM CEST Arnd Bergmann wrote:
> >> On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
> >> > mvebu soc for 4.9 (part 1)
> >> > 
> >> > - irq cleanup for old mvebu SoC
> >> > - Convert orion5x based SoC Netgear WNR854T to devicetree
> >> > 
> >> 
> >> Pulled into next/soc, thanks!
> >
> > Sorry, backed out again after seeing the PCI stuff on the WNR854T in
> > there. I thought the plan was to leave out PCI support from the DT
> > based machine file, and leave the old board in place, or am I
> > missing something?
> 
> I might have overlooked the thread, I thouhgt the state of the patch was
> OK as is, and further changes can be done later.
> 
> So it seems that it will be 4.10 material.
> 

We have gained a little more time since Linus delayed the merge window
by another week, so I think there is still a chance to respin this.

I also really want the NO_IRQ changes to get merged ;-)

Just drop the patch removing wnr854t-setup.c, and add another patch
on top to remove the PCI initialization from wrt350n-v2-setup.c,
and I'll take it.

	Arnd

^ permalink raw reply

* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Marc Zyngier @ 2016-09-20  9:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <580a8a26-ca8f-a08a-a9da-d19d1a595cb6@suse.de>

On 20/09/16 10:26, Alexander Graf wrote:
> 
> 
> On 20.09.16 11:21, Marc Zyngier wrote:
>> On 19/09/16 18:39, Alexander Graf wrote:
>>>
>>>
>>> On 19.09.16 16:48, Marc Zyngier wrote:
>>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>>
>>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>>> about timer events that may result in interrupt line state changes, so we
>>>>> lose out on timer events if we run with user space gic emulation.
>>>>>
>>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>>> emulation.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>
>>>>> ---
>>>>>
>>>>> v1 -> v2:
>>>>>
>>>>>   - Add back curly brace that got lost
>>>>>
>>>>> v2 -> v3:
>>>>>
>>>>>   - Split into patch set
>>>>>
>>>>> v3 -> v4:
>>>>>
>>>>>   - Improve documentation
>>>>> ---
>>>>>  Documentation/virtual/kvm/api.txt |  30 ++++++++-
>>>>>  arch/arm/include/asm/kvm_host.h   |   3 +
>>>>>  arch/arm/kvm/arm.c                |  22 ++++---
>>>>>  arch/arm64/include/asm/kvm_host.h |   3 +
>>>>>  include/uapi/linux/kvm.h          |  14 +++++
>>>>>  virt/kvm/arm/arch_timer.c         | 125 +++++++++++++++++++++++++++-----------
>>>>>  6 files changed, 155 insertions(+), 42 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>>> index 23937e0..1c0bd86 100644
>>>>> --- a/Documentation/virtual/kvm/api.txt
>>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>>  	/* in */
>>>>>  	__u8 request_interrupt_window;
>>>>>  
>>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>>  interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
>>>>>  
>>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>>> +trigger forever. These lines are available:
>>>>> +
>>>>> +    KVM_IRQWINDOW_VTIMER  -  Masks hw virtual timer irq while in guest
>>>>> +
>>>>>  	__u8 padding1[7];
>>>>>  
>>>>>  	/* out */
>>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>>  event/message pages and to enable/disable SynIC messages/events processing
>>>>>  in userspace.
>>>>>  
>>>>> +		/* KVM_EXIT_ARM_TIMER */
>>>>> +		struct {
>>>>> +			__u8 timesource;
>>>>> +		} arm_timer;
>>>>> +
>>>>> +Indicates that a timer triggered that user space needs to handle and
>>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>>> +guest to proceed. This only happens for timers that got enabled through
>>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>>> +
>>>>> +    KVM_ARM_TIMER_VTIMER  - virtual cpu timer
>>>>> +
>>>>>  		/* Fix the size of the union. */
>>>>>  		char padding[256];
>>>>>  	};
>>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>>  accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>>  the guest.
>>>>>  
>>>>> +6.11 KVM_CAP_ARM_TIMER
>>>>> +
>>>>> +Architectures: arm, arm64
>>>>> +Target: vcpu
>>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>>> +
>>>>> +This capability allows to route per-core timers into user space. When it's
>>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>>> +
>>>>>  7. Capabilities that can be enabled on VMs
>>>>>  ------------------------------------------
>>>>>  
>>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>>> index de338d9..77d1f73 100644
>>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>>  
>>>>>  	/* Detect first run of a vcpu */
>>>>>  	bool has_run_once;
>>>>> +
>>>>> +	/* User space wants timer notifications */
>>>>> +	bool user_space_arm_timers;
>>>>
>>>> Please move this to the timer structure.
>>>
>>> Sure.
>>>
>>>>
>>>>>  };
>>>>>  
>>>>>  struct kvm_vm_stat {
>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>> index c84b6ad..57bdb71 100644
>>>>> --- a/arch/arm/kvm/arm.c
>>>>> +++ b/arch/arm/kvm/arm.c
>>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>>  	case KVM_CAP_ARM_PSCI_0_2:
>>>>>  	case KVM_CAP_READONLY_MEM:
>>>>>  	case KVM_CAP_MP_STATE:
>>>>> +	case KVM_CAP_ARM_TIMER:
>>>>>  		r = 1;
>>>>>  		break;
>>>>>  	case KVM_CAP_COALESCED_MMIO:
>>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>>  			return ret;
>>>>>  	}
>>>>>  
>>>>> -	/*
>>>>> -	 * Enable the arch timers only if we have an in-kernel VGIC
>>>>> -	 * and it has been properly initialized, since we cannot handle
>>>>> -	 * interrupts from the virtual timer with a userspace gic.
>>>>> -	 */
>>>>> -	if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>>> -		ret = kvm_timer_enable(vcpu);
>>>>> +	ret = kvm_timer_enable(vcpu);
>>>>>  
>>>>>  	return ret;
>>>>>  }
>>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>  			run->exit_reason = KVM_EXIT_INTR;
>>>>>  		}
>>>>>  
>>>>> +		if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>>
>>>> Since this is a very unlikely event (in the grand scheme of things), how
>>>> about making this unlikely()?
>>>>
>>>>> +			/* Tell user space about the pending vtimer */
>>>>> +			ret = 0;
>>>>> +			run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>>> +			run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>>> +		}
>>>>
>>>> More importantly: why does it have to be indirected by a
>>>> make_request/check_request, and not be handled as part of the
>>>> kvm_timer_sync() call? We do update the state there, and you could
>>>> directly find out whether an exit is required.
>>>
>>> I can try - it seemed like it could easily become quite racy because we
>>> call kvm_timer_sync_hwstate() at multiple places.
>>
>> It shouldn't. We only do it at exactly two locations (depending whether
>> we've entered the guest or not).
>>
>> Also, take the following scenario:
>> (1) guest programs the timer to expire at time T
>> (2) guest performs an MMIO access which traps
>> (3) during the world switch, the timer expires and we mark the timer
>> interrupt as pending
>> (4) we exit to handle the MMIO, no sign of the timer being pending
>>
>> Is the timer event lost? Or simply delayed? I think this indicates that
>> the timer state should always be signalled to userspace, no matter what
>> the exit reason is.
> 
> That's basically what I'm trying to get running right now, yes. I pushed
> the interrupt pending status field into the kvm_sync_regs struct and
> check it on every exit in user space - to make sure we catch pending
> state changes before mmio reads.
> 
> On top of that we also need a force exit event when the state changes,
> in case there's no other event pending. Furthermore we probably want to
> indicate the user space status of the pending bit into the kernel to not
> exit too often.

All you need is to do is to stash the line state in the run structure.
You shouldn't need any other information. And you trigger the exit on
"timer line high + timer line unmasked" in order to inject the
interrupt. Which is basically what the vgic does. It would greatly help
if you adopted a similar behaviour.

> Something doesn't quite work with that approach yet though - I can't get
> edk2 to roll yet.

Oh well...

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Mark Rutland @ 2016-09-20  9:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474312560.4283.10.camel@buserror.net>

On Mon, Sep 19, 2016 at 02:16:00PM -0500, Scott Wood wrote:
> On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote:
> > > > Reconsidering my suggestion, I realise this will also affect the MMIO
> > > > timers, so that doesn't work.
> > > > 
> > > > So for the moment, I guess we have to keep fsl_a008585_set_next_event().
> > > What is the problem with MMIO timers? ?needs_fsl_a008585_workaround()
> > > should
> > > always be false for them.
> > As suggested, needs_fsl_a008585_workaround() takes no parameter, and
> > set_next_event is called for both cp15/sysreg and MMIO timers. So it
> > would either be true for all, or false for all.
> > 
> > If it's true for all, we'd end up calling fsl_a008585_set_next_event()
> > for the MMIO timers too.
> 
> There should not be any MMIO timers on a system where
> fsl_a008585_set_next_event() returns true.

I'm generally not keen on relying on that.

For reference, are no MMIO timers implemented at all, or are they simply
not listed in the DT today?

Thanks,
Mark.

^ permalink raw reply

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Jani Nikula @ 2016-09-20  9:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160920083251.GB26093@griffinp-ThinkPad-X1-Carbon-2nd>

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

^ permalink raw reply

* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-20  9:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <57E0FF95.7040305@arm.com>



On 20.09.16 11:21, Marc Zyngier wrote:
> On 19/09/16 18:39, Alexander Graf wrote:
>>
>>
>> On 19.09.16 16:48, Marc Zyngier wrote:
>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>>> handle them all using hardware acceleration through the vgic or we can emulate
>>>> a gic in user space and only drive CPU IRQ pins from there.
>>>>
>>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>>> about timer events that may result in interrupt line state changes, so we
>>>> lose out on timer events if we run with user space gic emulation.
>>>>
>>>> This patch fixes that by routing vtimer expiration events to user space.
>>>> With this patch I can successfully run edk2 and Linux with user space gic
>>>> emulation.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>
>>>> ---
>>>>
>>>> v1 -> v2:
>>>>
>>>>   - Add back curly brace that got lost
>>>>
>>>> v2 -> v3:
>>>>
>>>>   - Split into patch set
>>>>
>>>> v3 -> v4:
>>>>
>>>>   - Improve documentation
>>>> ---
>>>>  Documentation/virtual/kvm/api.txt |  30 ++++++++-
>>>>  arch/arm/include/asm/kvm_host.h   |   3 +
>>>>  arch/arm/kvm/arm.c                |  22 ++++---
>>>>  arch/arm64/include/asm/kvm_host.h |   3 +
>>>>  include/uapi/linux/kvm.h          |  14 +++++
>>>>  virt/kvm/arm/arch_timer.c         | 125 +++++++++++++++++++++++++++-----------
>>>>  6 files changed, 155 insertions(+), 42 deletions(-)
>>>>
>>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>>> index 23937e0..1c0bd86 100644
>>>> --- a/Documentation/virtual/kvm/api.txt
>>>> +++ b/Documentation/virtual/kvm/api.txt
>>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>>  	/* in */
>>>>  	__u8 request_interrupt_window;
>>>>  
>>>> -Request that KVM_RUN return when it becomes possible to inject external
>>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>>  interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
>>>>  
>>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>>> +trigger forever. These lines are available:
>>>> +
>>>> +    KVM_IRQWINDOW_VTIMER  -  Masks hw virtual timer irq while in guest
>>>> +
>>>>  	__u8 padding1[7];
>>>>  
>>>>  	/* out */
>>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>>  event/message pages and to enable/disable SynIC messages/events processing
>>>>  in userspace.
>>>>  
>>>> +		/* KVM_EXIT_ARM_TIMER */
>>>> +		struct {
>>>> +			__u8 timesource;
>>>> +		} arm_timer;
>>>> +
>>>> +Indicates that a timer triggered that user space needs to handle and
>>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>>> +guest to proceed. This only happens for timers that got enabled through
>>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>>> +
>>>> +    KVM_ARM_TIMER_VTIMER  - virtual cpu timer
>>>> +
>>>>  		/* Fix the size of the union. */
>>>>  		char padding[256];
>>>>  	};
>>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>>  accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>>  the guest.
>>>>  
>>>> +6.11 KVM_CAP_ARM_TIMER
>>>> +
>>>> +Architectures: arm, arm64
>>>> +Target: vcpu
>>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>>> +
>>>> +This capability allows to route per-core timers into user space. When it's
>>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>>> +
>>>>  7. Capabilities that can be enabled on VMs
>>>>  ------------------------------------------
>>>>  
>>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>>> index de338d9..77d1f73 100644
>>>> --- a/arch/arm/include/asm/kvm_host.h
>>>> +++ b/arch/arm/include/asm/kvm_host.h
>>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>>  
>>>>  	/* Detect first run of a vcpu */
>>>>  	bool has_run_once;
>>>> +
>>>> +	/* User space wants timer notifications */
>>>> +	bool user_space_arm_timers;
>>>
>>> Please move this to the timer structure.
>>
>> Sure.
>>
>>>
>>>>  };
>>>>  
>>>>  struct kvm_vm_stat {
>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>> index c84b6ad..57bdb71 100644
>>>> --- a/arch/arm/kvm/arm.c
>>>> +++ b/arch/arm/kvm/arm.c
>>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>  	case KVM_CAP_ARM_PSCI_0_2:
>>>>  	case KVM_CAP_READONLY_MEM:
>>>>  	case KVM_CAP_MP_STATE:
>>>> +	case KVM_CAP_ARM_TIMER:
>>>>  		r = 1;
>>>>  		break;
>>>>  	case KVM_CAP_COALESCED_MMIO:
>>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>>  			return ret;
>>>>  	}
>>>>  
>>>> -	/*
>>>> -	 * Enable the arch timers only if we have an in-kernel VGIC
>>>> -	 * and it has been properly initialized, since we cannot handle
>>>> -	 * interrupts from the virtual timer with a userspace gic.
>>>> -	 */
>>>> -	if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>>> -		ret = kvm_timer_enable(vcpu);
>>>> +	ret = kvm_timer_enable(vcpu);
>>>>  
>>>>  	return ret;
>>>>  }
>>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>  			run->exit_reason = KVM_EXIT_INTR;
>>>>  		}
>>>>  
>>>> +		if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>>
>>> Since this is a very unlikely event (in the grand scheme of things), how
>>> about making this unlikely()?
>>>
>>>> +			/* Tell user space about the pending vtimer */
>>>> +			ret = 0;
>>>> +			run->exit_reason = KVM_EXIT_ARM_TIMER;
>>>> +			run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>>> +		}
>>>
>>> More importantly: why does it have to be indirected by a
>>> make_request/check_request, and not be handled as part of the
>>> kvm_timer_sync() call? We do update the state there, and you could
>>> directly find out whether an exit is required.
>>
>> I can try - it seemed like it could easily become quite racy because we
>> call kvm_timer_sync_hwstate() at multiple places.
> 
> It shouldn't. We only do it at exactly two locations (depending whether
> we've entered the guest or not).
> 
> Also, take the following scenario:
> (1) guest programs the timer to expire at time T
> (2) guest performs an MMIO access which traps
> (3) during the world switch, the timer expires and we mark the timer
> interrupt as pending
> (4) we exit to handle the MMIO, no sign of the timer being pending
> 
> Is the timer event lost? Or simply delayed? I think this indicates that
> the timer state should always be signalled to userspace, no matter what
> the exit reason is.

That's basically what I'm trying to get running right now, yes. I pushed
the interrupt pending status field into the kvm_sync_regs struct and
check it on every exit in user space - to make sure we catch pending
state changes before mmio reads.

On top of that we also need a force exit event when the state changes,
in case there's no other event pending. Furthermore we probably want to
indicate the user space status of the pending bit into the kernel to not
exit too often.

Something doesn't quite work with that approach yet though - I can't get
edk2 to roll yet.


Alex

^ permalink raw reply

* [PATCH v4 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Marc Zyngier @ 2016-09-20  9:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <0960d2a7-6100-3212-c544-d5377df34d57@suse.de>

On 19/09/16 18:39, Alexander Graf wrote:
> 
> 
> On 19.09.16 16:48, Marc Zyngier wrote:
>> On 19/09/16 12:14, Alexander Graf wrote:
>>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>>> handle them all using hardware acceleration through the vgic or we can emulate
>>> a gic in user space and only drive CPU IRQ pins from there.
>>>
>>> Unfortunately, when driving IRQs from user space, we never tell user space
>>> about timer events that may result in interrupt line state changes, so we
>>> lose out on timer events if we run with user space gic emulation.
>>>
>>> This patch fixes that by routing vtimer expiration events to user space.
>>> With this patch I can successfully run edk2 and Linux with user space gic
>>> emulation.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>
>>> ---
>>>
>>> v1 -> v2:
>>>
>>>   - Add back curly brace that got lost
>>>
>>> v2 -> v3:
>>>
>>>   - Split into patch set
>>>
>>> v3 -> v4:
>>>
>>>   - Improve documentation
>>> ---
>>>  Documentation/virtual/kvm/api.txt |  30 ++++++++-
>>>  arch/arm/include/asm/kvm_host.h   |   3 +
>>>  arch/arm/kvm/arm.c                |  22 ++++---
>>>  arch/arm64/include/asm/kvm_host.h |   3 +
>>>  include/uapi/linux/kvm.h          |  14 +++++
>>>  virt/kvm/arm/arch_timer.c         | 125 +++++++++++++++++++++++++++-----------
>>>  6 files changed, 155 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>> index 23937e0..1c0bd86 100644
>>> --- a/Documentation/virtual/kvm/api.txt
>>> +++ b/Documentation/virtual/kvm/api.txt
>>> @@ -3202,9 +3202,14 @@ struct kvm_run {
>>>  	/* in */
>>>  	__u8 request_interrupt_window;
>>>  
>>> -Request that KVM_RUN return when it becomes possible to inject external
>>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>>>  interrupts into the guest.  Useful in conjunction with KVM_INTERRUPT.
>>>  
>>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>>> +trigger forever. These lines are available:
>>> +
>>> +    KVM_IRQWINDOW_VTIMER  -  Masks hw virtual timer irq while in guest
>>> +
>>>  	__u8 padding1[7];
>>>  
>>>  	/* out */
>>> @@ -3519,6 +3524,18 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>>>  event/message pages and to enable/disable SynIC messages/events processing
>>>  in userspace.
>>>  
>>> +		/* KVM_EXIT_ARM_TIMER */
>>> +		struct {
>>> +			__u8 timesource;
>>> +		} arm_timer;
>>> +
>>> +Indicates that a timer triggered that user space needs to handle and
>>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>>> +guest to proceed. This only happens for timers that got enabled through
>>> +KVM_CAP_ARM_TIMER. The following time sources are available:
>>> +
>>> +    KVM_ARM_TIMER_VTIMER  - virtual cpu timer
>>> +
>>>  		/* Fix the size of the union. */
>>>  		char padding[256];
>>>  	};
>>> @@ -3739,6 +3756,17 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>>>  accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>>>  the guest.
>>>  
>>> +6.11 KVM_CAP_ARM_TIMER
>>> +
>>> +Architectures: arm, arm64
>>> +Target: vcpu
>>> +Parameters: args[0] contains a bitmap of timers to select (see 5.)
>>> +
>>> +This capability allows to route per-core timers into user space. When it's
>>> +enabled and no in-kernel interrupt controller is in use, the timers selected
>>> +by args[0] trigger KVM_EXIT_ARM_TIMER guest exits when they are pending,
>>> +unless masked by vcpu->run->request_interrupt_window (see 5.).
>>> +
>>>  7. Capabilities that can be enabled on VMs
>>>  ------------------------------------------
>>>  
>>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>>> index de338d9..77d1f73 100644
>>> --- a/arch/arm/include/asm/kvm_host.h
>>> +++ b/arch/arm/include/asm/kvm_host.h
>>> @@ -180,6 +180,9 @@ struct kvm_vcpu_arch {
>>>  
>>>  	/* Detect first run of a vcpu */
>>>  	bool has_run_once;
>>> +
>>> +	/* User space wants timer notifications */
>>> +	bool user_space_arm_timers;
>>
>> Please move this to the timer structure.
> 
> Sure.
> 
>>
>>>  };
>>>  
>>>  struct kvm_vm_stat {
>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>> index c84b6ad..57bdb71 100644
>>> --- a/arch/arm/kvm/arm.c
>>> +++ b/arch/arm/kvm/arm.c
>>> @@ -187,6 +187,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>  	case KVM_CAP_ARM_PSCI_0_2:
>>>  	case KVM_CAP_READONLY_MEM:
>>>  	case KVM_CAP_MP_STATE:
>>> +	case KVM_CAP_ARM_TIMER:
>>>  		r = 1;
>>>  		break;
>>>  	case KVM_CAP_COALESCED_MMIO:
>>> @@ -474,13 +475,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>>>  			return ret;
>>>  	}
>>>  
>>> -	/*
>>> -	 * Enable the arch timers only if we have an in-kernel VGIC
>>> -	 * and it has been properly initialized, since we cannot handle
>>> -	 * interrupts from the virtual timer with a userspace gic.
>>> -	 */
>>> -	if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
>>> -		ret = kvm_timer_enable(vcpu);
>>> +	ret = kvm_timer_enable(vcpu);
>>>  
>>>  	return ret;
>>>  }
>>> @@ -601,6 +596,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>  			run->exit_reason = KVM_EXIT_INTR;
>>>  		}
>>>  
>>> +		if (kvm_check_request(KVM_REQ_PENDING_TIMER, vcpu)) {
>>
>> Since this is a very unlikely event (in the grand scheme of things), how
>> about making this unlikely()?
>>
>>> +			/* Tell user space about the pending vtimer */
>>> +			ret = 0;
>>> +			run->exit_reason = KVM_EXIT_ARM_TIMER;
>>> +			run->arm_timer.timesource = KVM_ARM_TIMER_VTIMER;
>>> +		}
>>
>> More importantly: why does it have to be indirected by a
>> make_request/check_request, and not be handled as part of the
>> kvm_timer_sync() call? We do update the state there, and you could
>> directly find out whether an exit is required.
> 
> I can try - it seemed like it could easily become quite racy because we
> call kvm_timer_sync_hwstate() at multiple places.

It shouldn't. We only do it at exactly two locations (depending whether
we've entered the guest or not).

Also, take the following scenario:
(1) guest programs the timer to expire at time T
(2) guest performs an MMIO access which traps
(3) during the world switch, the timer expires and we mark the timer
interrupt as pending
(4) we exit to handle the MMIO, no sign of the timer being pending

Is the timer event lost? Or simply delayed? I think this indicates that
the timer state should always be signalled to userspace, no matter what
the exit reason is.

> 
>>
>>> +
>>>  		if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
>>>  			vcpu->arch.power_off || vcpu->arch.pause) {
>>>  			local_irq_enable();
>>> @@ -887,6 +889,12 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
>>>  		return -EINVAL;
>>>  
>>>  	switch (cap->cap) {
>>> +	case KVM_CAP_ARM_TIMER:
>>> +		r = 0;
>>> +		if (cap->args[0] != KVM_ARM_TIMER_VTIMER)
>>> +			return -EINVAL;
>>> +		vcpu->arch.user_space_arm_timers = true;
>>> +		break;
>>>  	default:
>>>  		r = -EINVAL;
>>>  		break;
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index 3eda975..3d01481 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -270,6 +270,9 @@ struct kvm_vcpu_arch {
>>>  
>>>  	/* Detect first run of a vcpu */
>>>  	bool has_run_once;
>>> +
>>> +	/* User space wants timer notifications */
>>> +	bool user_space_arm_timers;
>>>  };
>>>  
>>>  #define vcpu_gp_regs(v)		(&(v)->arch.ctxt.gp_regs)
>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>> index 300ef25..00f4948 100644
>>> --- a/include/uapi/linux/kvm.h
>>> +++ b/include/uapi/linux/kvm.h
>>> @@ -205,6 +205,7 @@ struct kvm_hyperv_exit {
>>>  #define KVM_EXIT_S390_STSI        25
>>>  #define KVM_EXIT_IOAPIC_EOI       26
>>>  #define KVM_EXIT_HYPERV           27
>>> +#define KVM_EXIT_ARM_TIMER        28
>>>  
>>>  /* For KVM_EXIT_INTERNAL_ERROR */
>>>  /* Emulate instruction failed. */
>>> @@ -361,6 +362,10 @@ struct kvm_run {
>>>  		} eoi;
>>>  		/* KVM_EXIT_HYPERV */
>>>  		struct kvm_hyperv_exit hyperv;
>>> +		/* KVM_EXIT_ARM_TIMER */
>>> +		struct {
>>> +			__u8 timesource;
>>> +		} arm_timer;
>>>  		/* Fix the size of the union. */
>>>  		char padding[256];
>>>  	};
>>> @@ -870,6 +875,7 @@ struct kvm_ppc_smmu_info {
>>>  #define KVM_CAP_S390_USER_INSTR0 130
>>>  #define KVM_CAP_MSI_DEVID 131
>>>  #define KVM_CAP_PPC_HTM 132
>>> +#define KVM_CAP_ARM_TIMER 133
>>>  
>>>  #ifdef KVM_CAP_IRQ_ROUTING
>>>  
>>> @@ -1327,4 +1333,12 @@ struct kvm_assigned_msix_entry {
>>>  #define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
>>>  #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
>>>  
>>> +/* Available with KVM_CAP_ARM_TIMER */
>>> +
>>> +/* Bits for run->request_interrupt_window */
>>> +#define KVM_IRQWINDOW_VTIMER		(1 << 0)
>>> +
>>> +/* Bits for run->arm_timer.timesource */
>>> +#define KVM_ARM_TIMER_VTIMER		(1 << 0)
>>> +
>>>  #endif /* __LINUX_KVM_H */
>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>> index 4309b60..cbbb50dd 100644
>>> --- a/virt/kvm/arm/arch_timer.c
>>> +++ b/virt/kvm/arm/arch_timer.c
>>> @@ -170,16 +170,45 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
>>>  {
>>>  	int ret;
>>>  	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>> +	struct kvm_run *run = vcpu->run;
>>>  
>>> -	BUG_ON(!vgic_initialized(vcpu->kvm));
>>> +	BUG_ON(irqchip_in_kernel(vcpu->kvm) && !vgic_initialized(vcpu->kvm));
>>>  
>>>  	timer->active_cleared_last = false;
>>>  	timer->irq.level = new_level;
>>> -	trace_kvm_timer_update_irq(vcpu->vcpu_id, timer->irq.irq,
>>> +	trace_kvm_timer_update_irq(vcpu->vcpu_id, host_vtimer_irq,
>>>  				   timer->irq.level);
>>> -	ret = kvm_vgic_inject_mapped_irq(vcpu->kvm, vcpu->vcpu_id,
>>> -					 timer->irq.irq,
>>> -					 timer->irq.level);
>>> +
>>> +	if (irqchip_in_kernel(vcpu->kvm) && vgic_initialized(vcpu->kvm)) {
>>
>> Given how many times you repeat this idiom in this patch, you should
>> have a single condition that encapsulate it once and for all.
> 
> Sure.
> 
>>
>>> +		/* Fire the timer in the VGIC */
>>> +
>>> +		ret = kvm_vgic_inject_mapped_irq(vcpu->kvm, vcpu->vcpu_id,
>>> +						 timer->irq.irq,
>>> +						 timer->irq.level);
>>> +	} else if (!vcpu->arch.user_space_arm_timers) {
>>> +		/* User space has not activated timer use */
>>> +		ret = 0;
>>> +	} else {
>>> +		/*
>>> +		 * Set PENDING_TIMER so that user space can handle the event if
>>> +		 *
>>> +		 *   1) Level is high
>>> +		 *   2) The vtimer is not suppressed by user space
>>> +		 *   3) We are not in the timer trigger exit path
>>> +		 */
>>> +		if (new_level &&
>>> +		    !(run->request_interrupt_window & KVM_IRQWINDOW_VTIMER) &&
>>> +		    (run->exit_reason != KVM_EXIT_ARM_TIMER)) {
>>> +			/* KVM_REQ_PENDING_TIMER means vtimer triggered */
>>> +			kvm_make_request(KVM_REQ_PENDING_TIMER, vcpu);
>>> +		}
>>> +
>>> +		/* Force a new level high check on next entry */
>>> +		timer->irq.level = 0;
>>
>> I think this could become a bit more simple if you follow the flow I
>> mentioned earlier involving kvm_timer_sync(). Also, I only see how you
>> flag the line as being high, but not how you lower it. Care to explain
>> that flow?
> 
> We convert the level triggered timer into an edge up event (kvm exit).
> It's then up to user space to poll for the down event. Usually that will
> happen when the guest fiddles with the interrupt controller (eoi, enable
> line, etc).

Do you do this by inspecting the timer state? Or do you rely on the exit
itself to communicate the timer status to userspace?

> Can you think of a different option? We could maybe verify 2 kvm_run
> elements on guest entry and just see if they're identical: user space
> "active" line and arch timer "IMASK" bit. If not, exit to user space and
> let it update its state?
> 
> That should at least get rid of any chance for spurious interrupts.

My gut feeling is that any exit should communicate the state of the
timer interrupt, just like we do it for the in-kernel implementation.
Userspace should "see" the line state, whatever happens.

> 
>>
>>> +
>>> +		ret = 0;
>>> +	}
>>> +
>>>  	WARN_ON(ret);
>>>  }
>>>  
>>> @@ -197,7 +226,8 @@ static int kvm_timer_update_state(struct kvm_vcpu *vcpu)
>>>  	 * because the guest would never see the interrupt.  Instead wait
>>>  	 * until we call this function from kvm_timer_flush_hwstate.
>>>  	 */
>>> -	if (!vgic_initialized(vcpu->kvm) || !timer->enabled)
>>> +	if ((irqchip_in_kernel(vcpu->kvm) && !vgic_initialized(vcpu->kvm)) ||
>>> +	    !timer->enabled)
>>>  		return -ENODEV;
>>>  
>>>  	if (kvm_timer_should_fire(vcpu) != timer->irq.level)
>>> @@ -275,35 +305,57 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
>>>  	* to ensure that hardware interrupts from the timer triggers a guest
>>>  	* exit.
>>>  	*/
>>> -	phys_active = timer->irq.level ||
>>> -			kvm_vgic_map_is_active(vcpu, timer->irq.irq);
>>> -
>>> -	/*
>>> -	 * We want to avoid hitting the (re)distributor as much as
>>> -	 * possible, as this is a potentially expensive MMIO access
>>> -	 * (not to mention locks in the irq layer), and a solution for
>>> -	 * this is to cache the "active" state in memory.
>>> -	 *
>>> -	 * Things to consider: we cannot cache an "active set" state,
>>> -	 * because the HW can change this behind our back (it becomes
>>> -	 * "clear" in the HW). We must then restrict the caching to
>>> -	 * the "clear" state.
>>> -	 *
>>> -	 * The cache is invalidated on:
>>> -	 * - vcpu put, indicating that the HW cannot be trusted to be
>>> -	 *   in a sane state on the next vcpu load,
>>> -	 * - any change in the interrupt state
>>> -	 *
>>> -	 * Usage conditions:
>>> -	 * - cached value is "active clear"
>>> -	 * - value to be programmed is "active clear"
>>> -	 */
>>> -	if (timer->active_cleared_last && !phys_active)
>>> -		return;
>>> +	if (irqchip_in_kernel(vcpu->kvm) && vgic_initialized(vcpu->kvm)) {
>>> +		phys_active = timer->irq.level ||
>>> +				kvm_vgic_map_is_active(vcpu, timer->irq.irq);
>>> +
>>> +		/*
>>> +		 * We want to avoid hitting the (re)distributor as much as
>>> +		 * possible, as this is a potentially expensive MMIO access
>>> +		 * (not to mention locks in the irq layer), and a solution for
>>> +		 * this is to cache the "active" state in memory.
>>> +		 *
>>> +		 * Things to consider: we cannot cache an "active set" state,
>>> +		 * because the HW can change this behind our back (it becomes
>>> +		 * "clear" in the HW). We must then restrict the caching to
>>> +		 * the "clear" state.
>>> +		 *
>>> +		 * The cache is invalidated on:
>>> +		 * - vcpu put, indicating that the HW cannot be trusted to be
>>> +		 *   in a sane state on the next vcpu load,
>>> +		 * - any change in the interrupt state
>>> +		 *
>>> +		 * Usage conditions:
>>> +		 * - cached value is "active clear"
>>> +		 * - value to be programmed is "active clear"
>>> +		 */
>>> +		if (timer->active_cleared_last && !phys_active)
>>> +			return;
>>> +
>>> +		ret = irq_set_irqchip_state(host_vtimer_irq,
>>> +					    IRQCHIP_STATE_ACTIVE,
>>> +					    phys_active);
>>> +	} else {
>>> +		/* User space tells us whether the timer is in active mode */
>>> +		phys_active = vcpu->run->request_interrupt_window &
>>> +			      KVM_IRQWINDOW_VTIMER;
>>
>> No, this just says "mask the interrupt". It doesn't say anything about
>> the state of the timer. More importantly: you sample the shared page.
>> What guarantees that the information there is preserved? Is userspace
>> writing that bit each time the vcpu thread re-enters the kernel with
>> this interrupt being in flight?
> 
> The bit is owned by user space, so it has to guarantee that it stays.
> It's the way the kvm_run struct rolls :).
> 
>>
>>> +
>>> +		/* However if the line is high, we exit anyway, so we want
>>> +		 * to keep the IRQ masked */
>>> +		phys_active = phys_active || timer->irq.level;
>>
>> Why would you force the interrupt to be masked as soon as the timer is
>> firing? If userspace hasn't masked it, I don't think you should paper
>> over it.
> 
> This is to make sure that when we hit the second call to
> kvm_timer_sync_hwstate() in the exit path, we ignore it. We always set
> timer->irq.level = 0 in kvm_timer_update_irq.

I think you got the wrong end of the stick. There is only one call to
sync_hwstate per run (either because you've just exited the guest, or
because you have a something pending and we can't enter the guest).

> 
>>
>>> +
>>> +		/*
>>> +		 * So we can just explicitly mask or unmask the IRQ, gaining
>>> +		 * more compatibility with oddball irq controllers.
>>> +		 */
>>> +		if (phys_active)
>>> +			disable_percpu_irq(host_vtimer_irq);
>>> +		else
>>> +			enable_percpu_irq(host_vtimer_irq, 0);
>>
>> Since you are now targeting random irqchips (as opposed to a GIC
>> specifically), what guarantees that the timer is a per-cpu IRQ?
> 
> This is the host interrupt controller - and we're already using percpu
> irqs on it :). Also as it happens the RPi has them percpu (anything else
> wouldn't make sense...).

Not really. The RPi is faking percpu interrupts just to have some level
of compatibility with the host arch timer driver. But nonetheless, if
you're opening the code to something else than a GIC, then you should
check that the interrupt you're getting is percpu.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Masahiro Yamada @ 2016-09-20  8:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474356608.4030.7.camel@pengutronix.de>

Hi Philipp,


2016-09-20 16:30 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Hi Masahiro,
>
> Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> merged.  Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---
>>
>> Philipp,
>>
>> IIRC, you mentioned that you were planning to consolidate the double
>> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>>
>> I have not seen it in the ML, so I am sending this.
>>
>> Please let me know if you have some updates.
>
> I had started to doodle a bit, see
>
>     git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
>
> but I haven't found time for cleanup and testing.


OK, I will merge this patch for now.



BTW, I did not understand some of your commits under way.


commit 7fe911f9c83737449565db03bebf953d3d94bbbf
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Tue Aug 9 11:18:51 2016 +0200

    dmaengine: sunx6i: do not depend on reset controller framework

    The reset controller framework provides inline function stubs if
    disabled.

    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>





As far as I see from drivers/dma/sun6i-dma.c,
the reset control is mandatory for this driver.

Why are you removing the dependency?


Don't you care if it works on run-time
as long as it can build?




-- 
Best Regards
Masahiro Yamada

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox