<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >Mikey,</div>
<div dir="ltr" > </div>
<div dir="ltr" >The reason I suggested an nvram configuration option is due simply to time. We need a solution for the KVM case as soon as possible. We've done some performance measurements with snarfing disabled in bare metal and it has not shown there to be any significant performance delta. However, there is some concern that there might be workloads we've not run that might be affected. To mitigate that, the proposal was a chicken switch. That way if anyone running bare metal reported a performance regression, we could ask them to re-enable snarfing and we'd easily know if this was the source of the regression. Long term, I certainly would like to see this go away. As to the bare metal scenario, bare metal users should not encounter this due to a change made in the Nvidia driver. However, an NVidia driver change for a host checkstop is not a solution in a KVM environment.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Let me know if you still want Alexey to pull out the config option and we can just disable snarfing everywhere. We'd just be doing that sooner than we planned.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Thanks,</div>
<div dir="ltr" > </div>
<div dir="ltr" >Brian</div>
<div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" ><br>Brian King</div>
<div dir="ltr" >STSM, Linux on Power I/O Chief Architect<br>Linux Technology Center</div></div></div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: "Michael Neuling" <mikey@neuling.org><br>To: "Alexey Kardashevskiy" <aik@ozlabs.ru>, skiboot@lists.ozlabs.org<br>Cc: Brian J King/Rochester/IBM@IBMUS, "Jose Ricardo Ziviani" <joserz@linux.ibm.com>, "Alistair Popple" <alistair@popple.id.au>, "Daniel Henrique Barboza" <danielhb413@gmail.com>, "Piotr Jaroszynski" <pjaroszynski@nvidia.com>, "Leonardo Augusto Guimarães Garcia" <lagarcia@br.ibm.com>, "Reza Arbab" <arbab@linux.ibm.com><br>Subject: Re: [Skiboot] [PATCH skiboot] npu2: Allow disabling Probe.I.MO snarfing<br>Date: Fri, Apr 26, 2019 2:31 AM<br>
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >> Re: [Skiboot] [PATCH skiboot] npu2: Allow disabling Probe.I.MO snarfing<br><br>"I.MO" ???<br><br><br>On Wed, 2019-04-24 at 17:21 +1000, Alexey Kardashevskiy wrote:<br>> V100 GPUs are known to violate NVLink2 protocol in some cases (one is when<br>> memory was accessed by the CPU and they by GPU using so called block<br>> linear mapping) and issue double probes to NPU which can still handle this<br>> but only if CONFIG_ENABLE_SNARF_CPM is not set in the CQ_SM Misc Config<br>> register #0. If the bit is set (which is the case today), NPU issues<br>> the machine check stop.<br>><br>> The snarfing feature is designed to detect 2 probes in flight and combine<br>> them into one.<br>><br>> This adds a new "opal-npu2-snarf-cpm" nvram variable which controls<br>> CONFIG_ENABLE_SNARF_CPM for all NVLinks to prevent the machine check<br>> stop from happening. By default snarfing is not disabled.<br><br>change "not disabled" to "enabled".<br><br>> In order to<br>> disable it, the user has to run:<br>><br>> sudo nvram -p ibm,skiboot --update-config opal-npu2-snarf-cpm=disable<br><br>I'm against adding this as an nvram option.<br><br>We need to make a decision as to which way to go and stick with that. Users<br>shouldn't be controlling this sort of thing unless in a very very very special<br>case. In that case, they can recompile skiboot.<br><br>If it's a platform decision, then make it per platform for the user.<br><br>If it's causing a checkstop, we need to disable it.<br><br>If we start adding nvram options for all these types of things we are going to<br>end up with a billion different options that users will never know what to set<br>to.<br><br>> and reboot the host system.<br>><br>> While at this, define macros for register names as well to avoid touching<br>> same lines over and over again.<br>><br>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru><br>> ---<br>> include/npu2-regs.h | 14 ++++++++++++++<br>> hw/npu2.c | 45 ++++++++++++++++++++++++++++++++-------------<br>> 2 files changed, 46 insertions(+), 13 deletions(-)<br>><br>> diff --git a/include/npu2-regs.h b/include/npu2-regs.h<br>> index ba10b8eaf88d..61e8ea8615f8 100644<br>> --- a/include/npu2-regs.h<br>> +++ b/include/npu2-regs.h<br>> @@ -791,4 +791,18 @@ void npu2_scom_write(uint64_t gcid, uint64_t scom_base,<br>> #define L3_PRD_PURGE_TTYPE_MASK PPC_BIT(1) | PPC_BIT(2) |<br>> PPC_BIT(3) | PPC_BIT(4)<br>> #define L3_FULL_PURGE 0x0<br>> <br>> +/* Config registers for NPU2 */<br>> +#define NPU_STCK0_CS_SM0_MISC_CONFIG0 0x5011000<br>> +#define NPU_STCK0_CS_SM1_MISC_CONFIG0 0x5011030<br>> +#define NPU_STCK0_CS_SM2_MISC_CONFIG0 0x5011060<br>> +#define NPU_STCK0_CS_SM3_MISC_CONFIG0 0x5011090<br>> +#define NPU_STCK1_CS_SM0_MISC_CONFIG0 0x5011200<br>> +#define NPU_STCK1_CS_SM1_MISC_CONFIG0 0x5011230<br>> +#define NPU_STCK1_CS_SM2_MISC_CONFIG0 0x5011260<br>> +#define NPU_STCK1_CS_SM3_MISC_CONFIG0 0x5011290<br>> +#define NPU_STCK2_CS_SM0_MISC_CONFIG0 0x5011400<br>> +#define NPU_STCK2_CS_SM1_MISC_CONFIG0 0x5011430<br>> +#define NPU_STCK2_CS_SM2_MISC_CONFIG0 0x5011460<br>> +#define NPU_STCK2_CS_SM3_MISC_CONFIG0 0x5011490<br>> +<br>> #endif /* __NPU2_REGS_H */<br>> diff --git a/hw/npu2.c b/hw/npu2.c<br>> index d532c4da3532..c7b7b071f3e0 100644<br>> --- a/hw/npu2.c<br>> +++ b/hw/npu2.c<br>> @@ -1452,7 +1452,7 @@ static void assign_mmio_bars(uint64_t gcid, uint32_t<br>> scom, uint64_t reg[2], uint<br>> int npu2_nvlink_init_npu(struct npu2 *npu)<br>> {<br>> struct dt_node *np;<br>> - uint64_t reg[2], mm_win[2], val;<br>> + uint64_t reg[2], mm_win[2], val, mask;<br>> <br>> /* TODO: Clean this up with register names, etc. when we get<br>> * time. This just turns NVLink mode on in each brick and should<br>> @@ -1461,18 +1461,37 @@ int npu2_nvlink_init_npu(struct npu2 *npu)<br>> *<br>> * Obviously if the year is now 2020 that didn't happen and you<br>> * should fix this :-) */<br>> - xscom_write_mask(npu->chip_id, 0x5011000, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011030, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011060, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011090, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011200, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011230, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011260, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011290, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011400, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011430, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011460, PPC_BIT(58), PPC_BIT(58));<br>> - xscom_write_mask(npu->chip_id, 0x5011490, PPC_BIT(58), PPC_BIT(58));<br>> +<br>> + val = PPC_BIT(58);<br>> + mask = PPC_BIT(58); /* CONFIG_NVLINK_MODE */<br>> +<br>> + if (nvram_query_eq("opal-npu2-snarf-cpm", "disable"))<br>> + mask |= PPC_BIT(40); /* CONFIG_ENABLE_SNARF_CPM */<br><br>Need a big print here so we can debug this in the field.<br><br><br><br>> +<br>> + xscom_write_mask(npu->chip_id, NPU_STCK0_CS_SM0_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK0_CS_SM1_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK0_CS_SM2_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK0_CS_SM3_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK1_CS_SM0_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK1_CS_SM1_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK1_CS_SM2_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK1_CS_SM3_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK2_CS_SM0_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK2_CS_SM1_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK2_CS_SM2_MISC_CONFIG0,<br>> + val, mask);<br>> + xscom_write_mask(npu->chip_id, NPU_STCK2_CS_SM3_MISC_CONFIG0,<br>> + val, mask);<br>> <br>> xscom_write_mask(npu->chip_id, 0x50110c0, PPC_BIT(53), PPC_BIT(53));<br>> xscom_write_mask(npu->chip_id, 0x50112c0, PPC_BIT(53), PPC_BIT(53));</font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>