* Re: [PATCH 00/37] net: manually convert files to ReST format - part 2
From: David Miller @ 2020-04-30 19:56 UTC (permalink / raw)
To: mchehab+huawei
Cc: marcelo.leitner, linux-doc, dhowells, linux-sctp, paulus,
ioana.ciornei, linux-afs, devel, rds-devel, socketcan,
ruxandra.radulescu, corbet, linux-rdma, kadlec, coreteam, kuba,
pablo, linux-x25, santosh.shilimkar, linux-can, mkl, courmisch,
kvalo, fw, nhorman, geoff, netdev, vyasevich, linux-wireless,
linux-kernel, netfilter-devel, gregkh, johannes, linuxppc-dev
In-Reply-To: <cover.1588261997.git.mchehab+huawei@kernel.org>
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date: Thu, 30 Apr 2020 18:03:55 +0200
> That's the second part of my work to convert the networking
> text files into ReST. it is based on today's linux-next (next-20200430).
>
> The full series (including those ones) are at:
>
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=net-docs
>
> I should be sending the remaining patches (another /38 series)
> after getting those merged at -next.
>
> The documents, converted to HTML via the building system are at:
>
> https://www.infradead.org/~mchehab/kernel_docs/networking/
Series applied to net-next, thank you.
^ permalink raw reply
* [PATCH v3 2/2] PCI/DPC: Use _OSC to determine DPC support
From: Jon Derrick @ 2020-04-30 18:46 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kuppuswamy Sathyanarayanan, Rajat Jain, Frederick Lawler,
Sam Bobroff, linux-pci, Rafael J. Wysocki, linuxppc-dev,
linux-kernel, Olof Johansson, Alex Williamson, Patel, Mayurkumar,
Oliver O'Halloran, Bjorn Helgaas, Andy Shevchenko,
Mika Westerberg, Jon Derrick
In-Reply-To: <1588272369-2145-1-git-send-email-jonathan.derrick@intel.com>
After a5bf8719af: "PCI/AER: Use only _OSC to determine AER ownership",
_OSC is the primary determiner of ownership of Firmware First error
handling rather than HEST.
With the addition of DPC to _OSC [1], OSPM is able to negotiate DPC
services from Firmware. ACPI Root Bus enumeration sets the Host Bridge's
Native DPC flag on negotiation of those service. This patch changes DPC
probing to check DPC control as determined by _OSC, by checking the Host
Bridge's Native DPC member.
As most older platforms won't have DPC negotiable by _OSC, this patch
doesn't attempt to change behavior that assumes if OSPM has negotiated
AER by _OSC, OSPM will also want DPC control.
[1] https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
---
drivers/pci/pcie/dpc.c | 3 ---
drivers/pci/pcie/portdrv_core.c | 3 ++-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index 7621704..9104929 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/drivers/pci/pcie/dpc.c
@@ -284,9 +284,6 @@ static int dpc_probe(struct pcie_device *dev)
int status;
u16 ctl, cap;
- if (pcie_aer_get_firmware_first(pdev) && !pcie_ports_dpc_native)
- return -ENOTSUPP;
-
status = devm_request_threaded_irq(device, dev->irq, dpc_irq,
dpc_handler, IRQF_SHARED,
"pcie-dpc", pdev);
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 50a9522..f2139a1 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -256,7 +256,8 @@ static int get_port_device_capability(struct pci_dev *dev)
*/
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
pci_aer_available() &&
- (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
+ (pcie_ports_dpc_native || host->native_dpc ||
+ (services & PCIE_PORT_SERVICE_AER)))
services |= PCIE_PORT_SERVICE_DPC;
if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 1/2] PCI/AER: Use _OSC to determine Firmware First before HEST
From: Jon Derrick @ 2020-04-30 18:46 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kuppuswamy Sathyanarayanan, Rajat Jain, Frederick Lawler,
Sam Bobroff, linux-pci, Rafael J. Wysocki, linuxppc-dev,
linux-kernel, Olof Johansson, Alex Williamson, Patel, Mayurkumar,
Oliver O'Halloran, Bjorn Helgaas, Andy Shevchenko,
Mika Westerberg, Jon Derrick
In-Reply-To: <1588272369-2145-1-git-send-email-jonathan.derrick@intel.com>
After a5bf8719af: "PCI/AER: Use only _OSC to determine AER ownership",
_OSC is the primary determiner of ownership of Firmware First error
handling rather than HEST.
ACPI Root Bus enumeration has been modified to flag Host Bridge devices
as using Native AER when _OSC has been negotiated for AER services.
This patch ensures the PCI layers first uses the _OSC negotiated state
by checking the Host Bridge's Native AER flag prior to HEST parsing.
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
---
drivers/pci/pcie/aer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index efc2677..f3d02f4 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -314,6 +314,9 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
if (pcie_ports_native)
return 0;
+ if (pci_find_host_bridge(dev->bus)->native_aer)
+ return 0;
+
if (!dev->__aer_firmware_first_valid)
aer_set_firmware_first(dev);
return dev->__aer_firmware_first;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 0/2] PCI/ERR: Allow Native AER/DPC using _OSC
From: Jon Derrick @ 2020-04-30 18:46 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kuppuswamy Sathyanarayanan, Rajat Jain, Frederick Lawler,
Sam Bobroff, linux-pci, Rafael J. Wysocki, linuxppc-dev,
linux-kernel, Olof Johansson, Alex Williamson, Patel, Mayurkumar,
Oliver O'Halloran, Bjorn Helgaas, Andy Shevchenko,
Mika Westerberg, Jon Derrick
Hi Bjorn & Kuppuswamy,
I see a problem in the DPC ECN [1] to _OSC in that it doesn't give us a way to
determine if firmware supports _OSC DPC negotation, and therefore how to handle
DPC.
Here is the wording of the ECN that implies that Firmware without _OSC DPC
negotiation support should have the OSPM rely on _OSC AER negotiation when
determining DPC control:
PCIe Base Specification suggests that Downstream Port Containment may be
controlled either by the Firmware or the Operating System. It also suggests
that the Firmware retain ownership of Downstream Port Containment if it also
owns AER. When the Firmware owns Downstream Port Containment, it is expected
to use the new "Error Disconnect Recover" notification to alert OSPM of a
Downstream Port Containment event.
In legacy platforms, as bits in _OSC are reserved prior to implementation, ACPI
Root Bus enumeration will mark these Host Bridges as without Native DPC
support, even though the specification implies it's expected that AER _OSC
negotiation determines DPC control for these platforms. There seems to be a
need for a way to determine if the DPC control bit in _OSC is supported and
fallback on AER otherwise.
Currently portdrv assumes DPC control if the port has Native AER services:
static int get_port_device_capability(struct pci_dev *dev)
...
if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
pci_aer_available() &&
(pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
services |= PCIE_PORT_SERVICE_DPC;
Newer firmware may not grant OSPM DPC control, if for instance, it expects to
use Error Disconnect Recovery. However it looks like ACPI will use DPC services
via the EDR driver, without binding the full DPC port service driver.
If we change portdrv to probe based on host->native_dpc and not AER, then we
break instances with legacy firmware where OSPM will clear host->native_dpc
solely due to _OSC bits being reserved:
struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
...
if (!(root->osc_control_set & OSC_PCI_EXPRESS_DPC_CONTROL))
host_bridge->native_dpc = 0;
So my assumption instead is that host->native_dpc can be 0 and expect Native
DPC services if AER is used. In other words, if and only if DPC probe is
invoked from portdrv, then it needs to rely on the AER dependency. Otherwise it
should be assumed that ACPI set up DPC via EDR. This covers legacy firmware.
However it seems like that could be trouble with newer firmware that might give
OSPM control of AER but not DPC, and would result in both Native DPC and EDR
being in effect.
Anyways here are two patches that give control of AER and DPC on the results of
_OSC. They don't mess with the HEST parser as I expect those to be removed at
some point. I need these for VMD support which doesn't even rely on _OSC, but I
suspect this won't be the last effort as we detangle Firmware First.
[1] https://members.pcisig.com/wg/PCI-SIG/document/12888
Jon Derrick (2):
PCI/AER: Use _OSC to determine Firmware First before HEST
PCI/DPC: Use _OSC to determine DPC support
drivers/pci/pcie/aer.c | 3 +++
drivers/pci/pcie/dpc.c | 3 ---
drivers/pci/pcie/portdrv_core.c | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Dan Williams @ 2020-04-30 18:58 UTC (permalink / raw)
To: David Hildenbrand
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, Linux ACPI,
Wei Yang, linux-s390, linux-nvdimm, Linux Kernel Mailing List,
virtualization, Linux MM, Michael S . Tsirkin, Eric W. Biederman,
Pankaj Gupta, xen-devel, Andrew Morton, Michal Hocko,
linuxppc-dev
In-Reply-To: <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
On Thu, Apr 30, 2020 at 11:44 AM David Hildenbrand <david@redhat.com> wrote:
>
> >>> If the class of memory is different then please by all means let's mark
> >>> it differently in struct resource so everyone knows it is different.
> >>> But that difference needs to be more than hotplug.
> >>>
> >>> That difference needs to be the hypervisor loaned us memory and might
> >>> take it back at any time, or this memory is persistent and so it has
> >>> these different characteristics so don't use it as ordinary ram.
> >>
> >> Yes, and I think kmem took an excellent approach of explicitly putting
> >> that "System RAM" into a resource hierarchy. That "System RAM" won't
> >> show up as a root node under /proc/iomem (see patch #3), which already
> >> results in kexec-tools to treat it in a special way. I am thinking about
> >> doing the same for virtio-mem.
> >
> > Reading this and your patch cover letters again my concern is that
> > the justification seems to be letting the tail wag the dog.
> >
> > You want kexec-tools to behave in a certain way so you are changing the
> > kernel.
> >
> > Rather it should be change the kernel to clearly reflect reality and if
> > you can get away without a change to kexec-tools that is a bonus.
> >
>
> Right, because user space has to have a way to figure out what to do.
>
> But talking about the firmware memmap, indicating something via a "raw
> firmware-provided memory map", that is not actually in the "raw
> firmware-provided memory map" feels wrong to me. (below)
>
>
> >>> That information is also useful to other people looking at the system
> >>> and seeing what is going on.
> >>>
> >>> Just please don't muddle the concepts, or assume that whatever subset of
> >>> hotplug memory you are dealing with is the only subset.
> >>
> >> I can certainly rephrase the subject/description/comment, stating that
> >> this is not to be used for ordinary hotplugged DIMMs - only when the
> >> device driver is under control to decide what to do with that memory -
> >> especially when kexec'ing.
> >>
> >> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
> >> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
> >>
> >> Would that make it clearer?
> >
> > I am not certain, but Andrew Morton deliberately added that
> > firmware_map_add_hotplug call. Which means that there is a reason
> > for putting hotplugged memory in the firmware map.
> >
> > So the justification needs to take that reason into account. The
> > justification can not be it is hotplugged therefore it should not belong
> > in the firmware memory map. Unless you can show that
> > firmware_map_add_hotplug that was actually a bug and should be removed.
> > But as it has been that way since 2010 that seems like a long shot.
> >
> > So my question is what is right for the firmware map?
>
> We have documentation for that since 2008. Andrews patch is from 2010.
>
> Documentation/ABI/testing/sysfs-firmware-memmap
>
> It clearly talks about "raw firmware-provided memory map" and why the
> interface was introduced at all ("on most architectures that
> firmware-provided memory map is modified afterwards by the kernel itself").
>
> >
> > Why does the firmware map support hotplug entries?
>
> I assume:
>
> The firmware memmap was added primarily for x86-64 kexec (and still, is
> mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
> get hotplugged on real HW, they get added to e820. Same applies to
> memory added via HyperV balloon (unless memory is unplugged via
> ballooning and you reboot ... the the e820 is changed as well). I assume
> we wanted to be able to reflect that, to make kexec look like a real reboot.
I can at least say that this breakdown makes sense to me. Traditional
memory hotplug results in permanent change to the raw firmware memory
map reported by the host at next reboot. These device-driver-owned
memory regions really want a hotplug policy per-kernel boot instance
and should fall back to the default reserved state at reboot (kexec or
otherwise). When I say hotplug-policy I mean whether the current
kernel wants to treat the device range as System RAM or leave it as
device-managed. The intent is that the follow-on kernel needs to
re-decide the device policy.
>
> This worked for a while. Then came dax/kmem. Now comes virtio-mem.
>
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 18:43 UTC (permalink / raw)
To: Eric W. Biederman, Andrew Morton
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, linux-mm,
Wei Yang, linux-s390, linux-nvdimm, linux-kernel, virtualization,
linux-acpi, Michael S . Tsirkin, Pankaj Gupta, xen-devel,
Michal Hocko, linuxppc-dev
In-Reply-To: <875zdg26hp.fsf@x220.int.ebiederm.org>
>>> If the class of memory is different then please by all means let's mark
>>> it differently in struct resource so everyone knows it is different.
>>> But that difference needs to be more than hotplug.
>>>
>>> That difference needs to be the hypervisor loaned us memory and might
>>> take it back at any time, or this memory is persistent and so it has
>>> these different characteristics so don't use it as ordinary ram.
>>
>> Yes, and I think kmem took an excellent approach of explicitly putting
>> that "System RAM" into a resource hierarchy. That "System RAM" won't
>> show up as a root node under /proc/iomem (see patch #3), which already
>> results in kexec-tools to treat it in a special way. I am thinking about
>> doing the same for virtio-mem.
>
> Reading this and your patch cover letters again my concern is that
> the justification seems to be letting the tail wag the dog.
>
> You want kexec-tools to behave in a certain way so you are changing the
> kernel.
>
> Rather it should be change the kernel to clearly reflect reality and if
> you can get away without a change to kexec-tools that is a bonus.
>
Right, because user space has to have a way to figure out what to do.
But talking about the firmware memmap, indicating something via a "raw
firmware-provided memory map", that is not actually in the "raw
firmware-provided memory map" feels wrong to me. (below)
>>> That information is also useful to other people looking at the system
>>> and seeing what is going on.
>>>
>>> Just please don't muddle the concepts, or assume that whatever subset of
>>> hotplug memory you are dealing with is the only subset.
>>
>> I can certainly rephrase the subject/description/comment, stating that
>> this is not to be used for ordinary hotplugged DIMMs - only when the
>> device driver is under control to decide what to do with that memory -
>> especially when kexec'ing.
>>
>> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
>> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
>>
>> Would that make it clearer?
>
> I am not certain, but Andrew Morton deliberately added that
> firmware_map_add_hotplug call. Which means that there is a reason
> for putting hotplugged memory in the firmware map.
>
> So the justification needs to take that reason into account. The
> justification can not be it is hotplugged therefore it should not belong
> in the firmware memory map. Unless you can show that
> firmware_map_add_hotplug that was actually a bug and should be removed.
> But as it has been that way since 2010 that seems like a long shot.
>
> So my question is what is right for the firmware map?
We have documentation for that since 2008. Andrews patch is from 2010.
Documentation/ABI/testing/sysfs-firmware-memmap
It clearly talks about "raw firmware-provided memory map" and why the
interface was introduced at all ("on most architectures that
firmware-provided memory map is modified afterwards by the kernel itself").
>
> Why does the firmware map support hotplug entries?
I assume:
The firmware memmap was added primarily for x86-64 kexec (and still, is
mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
get hotplugged on real HW, they get added to e820. Same applies to
memory added via HyperV balloon (unless memory is unplugged via
ballooning and you reboot ... the the e820 is changed as well). I assume
we wanted to be able to reflect that, to make kexec look like a real reboot.
This worked for a while. Then came dax/kmem. Now comes virtio-mem.
But I assume only Andrew can enlighten us.
@Andrew, any guidance here? Should we really add all memory to the
firmware memmap, even if this contradicts with the existing
documentation? (especially, if the actual firmware memmap will *not*
contain that memory after a reboot)
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH net] ibmvnic: Skip fatal error reset after passive init
From: Juliet Kim @ 2020-04-30 18:22 UTC (permalink / raw)
To: netdev; +Cc: julietk, tlfalcon, linuxppc-dev
During MTU change, the following events may happen.
Client-driven CRQ initialization fails due to partner’s CRQ closed,
causing client to enqueue a reset task for FATAL_ERROR. Then passive
(server-driven) CRQ initialization succeeds, causing client to
release CRQ and enqueue a reset task for failover. If the passive
CRQ initialization occurs before the FATAL reset task is processed,
the FATAL error reset task would try to access a CRQ message queue
that was freed, causing an oops. The problem may be most likely to
occur during DLPAR add vNIC with a non-default MTU, because the DLPAR
process will automatically issue a change MTU request.
Fix this by not processing fatal error reset if CRQ is passively
initialized after client-driven CRQ initialization fails.
Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 4bd33245bad6..3de549c6c693 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2189,7 +2189,8 @@ static void __ibmvnic_reset(struct work_struct *work)
rc = do_hard_reset(adapter, rwi, reset_state);
rtnl_unlock();
}
- } else {
+ } else if (!(rwi->reset_reason == VNIC_RESET_FATAL &&
+ adapter->from_passive_init)) {
rc = do_reset(adapter, rwi, reset_state);
}
kfree(rwi);
--
2.16.4
^ permalink raw reply related
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Eric W. Biederman @ 2020-04-30 18:06 UTC (permalink / raw)
To: David Hildenbrand
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, linux-mm,
Wei Yang, linux-s390, linux-nvdimm, linux-kernel, virtualization,
linux-acpi, Michael S . Tsirkin, Pankaj Gupta, xen-devel,
Andrew Morton, Michal Hocko, linuxppc-dev
In-Reply-To: <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 30.04.20 18:33, Eric W. Biederman wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> On 30.04.20 17:38, Eric W. Biederman wrote:
>>>> David Hildenbrand <david@redhat.com> writes:
>>>>
>>>>> Some devices/drivers that add memory via add_memory() and friends (e.g.,
>>>>> dax/kmem, but also virtio-mem in the future) don't want to create entries
>>>>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>>>>> memory to the boot memmap of the kexec kernel.
>>>>>
>>>>> In fact, such memory is never exposed via the firmware memmap as System
>>>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>>>> wrong:
>>>>> "kexec needs the raw firmware-provided memory map to setup the
>>>>> parameter segment of the kernel that should be booted with
>>>>> kexec. Also, the raw memory map is useful for debugging. For
>>>>> that reason, /sys/firmware/memmap is an interface that provides
>>>>> the raw memory map to userspace." [1]
>>>>>
>>>>> We don't have to worry about firmware_map_remove() on the removal path.
>>>>> If there is no entry, it will simply return with -EINVAL.
>>>>>
>>>>> [1]
>>>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
>>>>
>>>>
>>>> You know what this justification is rubbish, and I have previously
>>>> explained why it is rubbish.
>>>
>>> Actually, no, I don't think it is rubbish. See patch #3 and the cover
>>> letter why this is the right thing to do *for special memory*, *not
>>> ordinary DIMMs*.
>>>
>>> And to be quite honest, I think your response is a little harsh. I don't
>>> recall you replying to my virtio-mem-related comments.
>>>
>>>>
>>>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>>
>>>> This needs to be based on weather the added memory is ultimately normal
>>>> ram or is something special.
>>>
>>> Yes, that's what the caller are expected to decide, see patch #3.
>>>
>>> kexec should try to be as closely as possible to a real reboot - IMHO.
>>
>> That is very fuzzy in terms of hotplug memory. The kexec'd kernel
>> should see the hotplugged memory assuming it is ordinary memory.
>>
>> But kexec is not a reboot although it is quite similar. Kexec is
>> swapping one running kernel and it's state for another kernel without
>> rebooting.
>
> I agree (especially regarding the arm64 DIMM hotplug discussion).
> However, for the two cases
>
> a) dax/kmem
> b) virtio-mem
>
> We really want to let the driver take back control and figure out "what
> to do with the memory".
From reading your v1 cover letter (the description appears missing in
v2) I see what you are talking about with respect to virtio-mem.
So I will count virt-io mem as something different.
>>>> Justifying behavior by documentation that does not consider memory
>>>> hotplug is bad thinking.
>>>
>>> Are you maybe confusing this patch series with the arm64 approach? This
>>> is not about ordinary hotplugged DIMMs.
>>
>> I think I am.
>>
>> My challenge is that I don't see anything in the description that says
>> this isn't about ordinary hotplugged DIMMs. All I saw was hotplug
>> memory.
>
> I'm sorry if that was confusing, I tried to stress that kmem and
> virtio-mem is special in the description.
>
> I squeezed a lot of that information into the cover letter and into
> patch #3.
>> If the class of memory is different then please by all means let's mark
>> it differently in struct resource so everyone knows it is different.
>> But that difference needs to be more than hotplug.
>>
>> That difference needs to be the hypervisor loaned us memory and might
>> take it back at any time, or this memory is persistent and so it has
>> these different characteristics so don't use it as ordinary ram.
>
> Yes, and I think kmem took an excellent approach of explicitly putting
> that "System RAM" into a resource hierarchy. That "System RAM" won't
> show up as a root node under /proc/iomem (see patch #3), which already
> results in kexec-tools to treat it in a special way. I am thinking about
> doing the same for virtio-mem.
Reading this and your patch cover letters again my concern is that
the justification seems to be letting the tail wag the dog.
You want kexec-tools to behave in a certain way so you are changing the
kernel.
Rather it should be change the kernel to clearly reflect reality and if
you can get away without a change to kexec-tools that is a bonus.
>> That information is also useful to other people looking at the system
>> and seeing what is going on.
>>
>> Just please don't muddle the concepts, or assume that whatever subset of
>> hotplug memory you are dealing with is the only subset.
>
> I can certainly rephrase the subject/description/comment, stating that
> this is not to be used for ordinary hotplugged DIMMs - only when the
> device driver is under control to decide what to do with that memory -
> especially when kexec'ing.
>
> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
>
> Would that make it clearer?
I am not certain, but Andrew Morton deliberately added that
firmware_map_add_hotplug call. Which means that there is a reason
for putting hotplugged memory in the firmware map.
So the justification needs to take that reason into account. The
justification can not be it is hotplugged therefore it should not belong
in the firmware memory map. Unless you can show that
firmware_map_add_hotplug that was actually a bug and should be removed.
But as it has been that way since 2010 that seems like a long shot.
So my question is what is right for the firmware map?
Why does the firmware map support hotplug entries?
Once we have the answers to those questions we can figure out what logic
the special kinds of memory hotplug need.
Ref: d96ae5309165 ("memory-hotplug: create /sys/firmware/memmap entry for new memory")
Eric
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 16:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, linux-mm,
Wei Yang, linux-s390, linux-nvdimm, linux-kernel, virtualization,
linux-acpi, Michael S . Tsirkin, Pankaj Gupta, xen-devel,
Andrew Morton, Michal Hocko, linuxppc-dev
In-Reply-To: <871ro52ary.fsf@x220.int.ebiederm.org>
On 30.04.20 18:33, Eric W. Biederman wrote:
> David Hildenbrand <david@redhat.com> writes:
>
>> On 30.04.20 17:38, Eric W. Biederman wrote:
>>> David Hildenbrand <david@redhat.com> writes:
>>>
>>>> Some devices/drivers that add memory via add_memory() and friends (e.g.,
>>>> dax/kmem, but also virtio-mem in the future) don't want to create entries
>>>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>>>> memory to the boot memmap of the kexec kernel.
>>>>
>>>> In fact, such memory is never exposed via the firmware memmap as System
>>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>>> wrong:
>>>> "kexec needs the raw firmware-provided memory map to setup the
>>>> parameter segment of the kernel that should be booted with
>>>> kexec. Also, the raw memory map is useful for debugging. For
>>>> that reason, /sys/firmware/memmap is an interface that provides
>>>> the raw memory map to userspace." [1]
>>>>
>>>> We don't have to worry about firmware_map_remove() on the removal path.
>>>> If there is no entry, it will simply return with -EINVAL.
>>>>
>>>> [1]
>>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
>>>
>>>
>>> You know what this justification is rubbish, and I have previously
>>> explained why it is rubbish.
>>
>> Actually, no, I don't think it is rubbish. See patch #3 and the cover
>> letter why this is the right thing to do *for special memory*, *not
>> ordinary DIMMs*.
>>
>> And to be quite honest, I think your response is a little harsh. I don't
>> recall you replying to my virtio-mem-related comments.
>>
>>>
>>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>
>>> This needs to be based on weather the added memory is ultimately normal
>>> ram or is something special.
>>
>> Yes, that's what the caller are expected to decide, see patch #3.
>>
>> kexec should try to be as closely as possible to a real reboot - IMHO.
>
> That is very fuzzy in terms of hotplug memory. The kexec'd kernel
> should see the hotplugged memory assuming it is ordinary memory.
>
> But kexec is not a reboot although it is quite similar. Kexec is
> swapping one running kernel and it's state for another kernel without
> rebooting.
I agree (especially regarding the arm64 DIMM hotplug discussion).
However, for the two cases
a) dax/kmem
b) virtio-mem
We really want to let the driver take back control and figure out "what
to do with the memory".
>
>>> Justifying behavior by documentation that does not consider memory
>>> hotplug is bad thinking.
>>
>> Are you maybe confusing this patch series with the arm64 approach? This
>> is not about ordinary hotplugged DIMMs.
>
> I think I am.
>
> My challenge is that I don't see anything in the description that says
> this isn't about ordinary hotplugged DIMMs. All I saw was hotplug
> memory.
I'm sorry if that was confusing, I tried to stress that kmem and
virtio-mem is special in the description.
I squeezed a lot of that information into the cover letter and into
patch #3.
>
> If the class of memory is different then please by all means let's mark
> it differently in struct resource so everyone knows it is different.
> But that difference needs to be more than hotplug.
>
> That difference needs to be the hypervisor loaned us memory and might
> take it back at any time, or this memory is persistent and so it has
> these different characteristics so don't use it as ordinary ram.
Yes, and I think kmem took an excellent approach of explicitly putting
that "System RAM" into a resource hierarchy. That "System RAM" won't
show up as a root node under /proc/iomem (see patch #3), which already
results in kexec-tools to treat it in a special way. I am thinking about
doing the same for virtio-mem.
>
> That information is also useful to other people looking at the system
> and seeing what is going on.
>
> Just please don't muddle the concepts, or assume that whatever subset of
> hotplug memory you are dealing with is the only subset.
I can certainly rephrase the subject/description/comment, stating that
this is not to be used for ordinary hotplugged DIMMs - only when the
device driver is under control to decide what to do with that memory -
especially when kexec'ing.
(previously, I called this flag MHP_DRIVER_MANAGED, but I think
MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
Would that make it clearer?
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Eric W. Biederman @ 2020-04-30 16:33 UTC (permalink / raw)
To: David Hildenbrand
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, linux-mm,
Wei Yang, linux-s390, linux-nvdimm, linux-kernel, virtualization,
linux-acpi, Michael S . Tsirkin, Pankaj Gupta, xen-devel,
Andrew Morton, Michal Hocko, linuxppc-dev
In-Reply-To: <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 30.04.20 17:38, Eric W. Biederman wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> Some devices/drivers that add memory via add_memory() and friends (e.g.,
>>> dax/kmem, but also virtio-mem in the future) don't want to create entries
>>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>>> memory to the boot memmap of the kexec kernel.
>>>
>>> In fact, such memory is never exposed via the firmware memmap as System
>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>> wrong:
>>> "kexec needs the raw firmware-provided memory map to setup the
>>> parameter segment of the kernel that should be booted with
>>> kexec. Also, the raw memory map is useful for debugging. For
>>> that reason, /sys/firmware/memmap is an interface that provides
>>> the raw memory map to userspace." [1]
>>>
>>> We don't have to worry about firmware_map_remove() on the removal path.
>>> If there is no entry, it will simply return with -EINVAL.
>>>
>>> [1]
>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
>>
>>
>> You know what this justification is rubbish, and I have previously
>> explained why it is rubbish.
>
> Actually, no, I don't think it is rubbish. See patch #3 and the cover
> letter why this is the right thing to do *for special memory*, *not
> ordinary DIMMs*.
>
> And to be quite honest, I think your response is a little harsh. I don't
> recall you replying to my virtio-mem-related comments.
>
>>
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> This needs to be based on weather the added memory is ultimately normal
>> ram or is something special.
>
> Yes, that's what the caller are expected to decide, see patch #3.
>
> kexec should try to be as closely as possible to a real reboot - IMHO.
That is very fuzzy in terms of hotplug memory. The kexec'd kernel
should see the hotplugged memory assuming it is ordinary memory.
But kexec is not a reboot although it is quite similar. Kexec is
swapping one running kernel and it's state for another kernel without
rebooting.
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
>
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
I think I am.
My challenge is that I don't see anything in the description that says
this isn't about ordinary hotplugged DIMMs. All I saw was hotplug
memory.
If the class of memory is different then please by all means let's mark
it differently in struct resource so everyone knows it is different.
But that difference needs to be more than hotplug.
That difference needs to be the hypervisor loaned us memory and might
take it back at any time, or this memory is persistent and so it has
these different characteristics so don't use it as ordinary ram.
That information is also useful to other people looking at the system
and seeing what is going on.
Just please don't muddle the concepts, or assume that whatever subset of
hotplug memory you are dealing with is the only subset.
I didn't see that flag making the distinction about the kind of memory
it is.
Eric
^ permalink raw reply
* [PATCH v4 00/19] Manually convert thermal, crypto and misc devices to ReST
From: Mauro Carvalho Chehab @ 2020-04-30 16:18 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: kvm, linux-pm, Mauro Carvalho Chehab, linux-pci, Jonathan Corbet,
linux-kernel, keyrings, linux-crypto, linux-sh, dmaengine,
linuxppc-dev, linux-arm-kernel
Manually convert some files from thermal, crypto and misc-devices
to ReST format.
This series is against linux-next 20200430 tag (as I rebased it, in order
to check if some patch were already merged via some other tree),
but it should very likely merge fine against docs-next.
The full series (including those ones) are at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=misc-docs
The documents touched on this patch, converted to HTML via the
building system are at (together with patches from other series):
https://www.infradead.org/~mchehab/kernel_docs/
v4:
- added some acks.
v3:
- removed the cpu-freq patches from this series, as Rafael should
be applying it on his tree.
v2:
- a small change at patch 2 to avoid uneeded whitespace changes;
- added 13 new patches at the end
Mauro Carvalho Chehab (19):
docs: thermal: convert cpu-idle-cooling.rst to ReST
docs: crypto: convert asymmetric-keys.txt to ReST
docs: crypto: convert api-intro.txt to ReST format
docs: crypto: convert async-tx-api.txt to ReST format
docs: crypto: descore-readme.txt: convert to ReST format
docs: misc-devices/spear-pcie-gadget.txt: convert to ReST
docs: misc-devices/pci-endpoint-test.txt: convert to ReST
docs: misc-devices/pci-endpoint-test.txt: convert to ReST
docs: misc-devices/c2port.txt: convert to ReST format
docs: misc-devices/bh1770glc.txt: convert to ReST
docs: misc-devices/apds990x.txt: convert to ReST format
docs: pci: endpoint/function/binding/pci-test.txt convert to ReST
docs: arm64: convert perf.txt to ReST format
docs: powerpc: convert vcpudispatch_stats.txt to ReST
docs: sh: convert new-machine.txt to ReST
docs: sh: convert register-banks.txt to ReST
docs: trace: ring-buffer-design.txt: convert to ReST format
docs: kvm: get read of devices/README
docs: misc-devices: add uacce to the index.rst
.../endpoint/function/binding/pci-test.rst | 26 +
.../endpoint/function/binding/pci-test.txt | 19 -
Documentation/PCI/endpoint/index.rst | 2 +
Documentation/arm64/index.rst | 1 +
Documentation/arm64/{perf.txt => perf.rst} | 7 +-
.../crypto/{api-intro.txt => api-intro.rst} | 186 ++--
...symmetric-keys.txt => asymmetric-keys.rst} | 91 +-
.../{async-tx-api.txt => async-tx-api.rst} | 253 +++---
...{descore-readme.txt => descore-readme.rst} | 152 +++-
Documentation/crypto/index.rst | 5 +
Documentation/driver-api/dmaengine/client.rst | 2 +-
.../driver-api/dmaengine/provider.rst | 2 +-
.../driver-api/thermal/cpu-idle-cooling.rst | 18 +-
Documentation/driver-api/thermal/index.rst | 1 +
.../{ad525x_dpot.txt => ad525x_dpot.rst} | 24 +-
.../{apds990x.txt => apds990x.rst} | 31 +-
.../{bh1770glc.txt => bh1770glc.rst} | 45 +-
.../misc-devices/{c2port.txt => c2port.rst} | 58 +-
Documentation/misc-devices/index.rst | 7 +
.../misc-devices/pci-endpoint-test.rst | 56 ++
.../misc-devices/pci-endpoint-test.txt | 41 -
.../misc-devices/spear-pcie-gadget.rst | 170 ++++
.../misc-devices/spear-pcie-gadget.txt | 130 ---
Documentation/powerpc/index.rst | 1 +
...patch_stats.txt => vcpudispatch_stats.rst} | 17 +-
Documentation/security/keys/core.rst | 2 +-
Documentation/sh/index.rst | 6 +
.../sh/{new-machine.txt => new-machine.rst} | 195 +++--
...{register-banks.txt => register-banks.rst} | 13 +-
Documentation/trace/index.rst | 1 +
...ffer-design.txt => ring-buffer-design.rst} | 802 ++++++++++--------
Documentation/virt/kvm/devices/README | 1 -
Documentation/virt/kvm/devices/index.rst | 3 +
MAINTAINERS | 4 +-
arch/sh/Kconfig.cpu | 2 +-
crypto/asymmetric_keys/asymmetric_type.c | 2 +-
crypto/asymmetric_keys/public_key.c | 2 +-
crypto/asymmetric_keys/signature.c | 2 +-
drivers/misc/Kconfig | 2 +-
drivers/misc/ad525x_dpot.c | 2 +-
include/crypto/public_key.h | 2 +-
include/keys/asymmetric-parser.h | 2 +-
include/keys/asymmetric-subtype.h | 2 +-
include/keys/asymmetric-type.h | 2 +-
44 files changed, 1358 insertions(+), 1034 deletions(-)
create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.rst
delete mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txt
rename Documentation/arm64/{perf.txt => perf.rst} (95%)
rename Documentation/crypto/{api-intro.txt => api-intro.rst} (70%)
rename Documentation/crypto/{asymmetric-keys.txt => asymmetric-keys.rst} (91%)
rename Documentation/crypto/{async-tx-api.txt => async-tx-api.rst} (55%)
rename Documentation/crypto/{descore-readme.txt => descore-readme.rst} (81%)
rename Documentation/misc-devices/{ad525x_dpot.txt => ad525x_dpot.rst} (85%)
rename Documentation/misc-devices/{apds990x.txt => apds990x.rst} (86%)
rename Documentation/misc-devices/{bh1770glc.txt => bh1770glc.rst} (83%)
rename Documentation/misc-devices/{c2port.txt => c2port.rst} (59%)
create mode 100644 Documentation/misc-devices/pci-endpoint-test.rst
delete mode 100644 Documentation/misc-devices/pci-endpoint-test.txt
create mode 100644 Documentation/misc-devices/spear-pcie-gadget.rst
delete mode 100644 Documentation/misc-devices/spear-pcie-gadget.txt
rename Documentation/powerpc/{vcpudispatch_stats.txt => vcpudispatch_stats.rst} (94%)
rename Documentation/sh/{new-machine.txt => new-machine.rst} (73%)
rename Documentation/sh/{register-banks.txt => register-banks.rst} (88%)
rename Documentation/trace/{ring-buffer-design.txt => ring-buffer-design.rst} (55%)
delete mode 100644 Documentation/virt/kvm/devices/README
--
2.25.4
^ permalink raw reply
* [PATCH v4 14/19] docs: powerpc: convert vcpudispatch_stats.txt to ReST
From: Mauro Carvalho Chehab @ 2020-04-30 16:18 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Jonathan Corbet, Mauro Carvalho Chehab, linux-kernel,
Paul Mackerras, linuxppc-dev
In-Reply-To: <cover.1588263270.git.mchehab+huawei@kernel.org>
- Add a SPDX header;
- Use standard markup for document title;
- Adjust identation on lists and add blank lines where
needed;
- Add it to the powerpc index.rst file.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> # powerpc
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
Documentation/powerpc/index.rst | 1 +
...ispatch_stats.txt => vcpudispatch_stats.rst} | 17 ++++++++++++-----
2 files changed, 13 insertions(+), 5 deletions(-)
rename Documentation/powerpc/{vcpudispatch_stats.txt => vcpudispatch_stats.rst} (94%)
diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
index afe2d5e54db6..748bf483b1c2 100644
--- a/Documentation/powerpc/index.rst
+++ b/Documentation/powerpc/index.rst
@@ -31,6 +31,7 @@ powerpc
transactional_memory
ultravisor
vas-api
+ vcpudispatch_stats
.. only:: subproject and html
diff --git a/Documentation/powerpc/vcpudispatch_stats.txt b/Documentation/powerpc/vcpudispatch_stats.rst
similarity index 94%
rename from Documentation/powerpc/vcpudispatch_stats.txt
rename to Documentation/powerpc/vcpudispatch_stats.rst
index e21476bfd78c..5704657a5987 100644
--- a/Documentation/powerpc/vcpudispatch_stats.txt
+++ b/Documentation/powerpc/vcpudispatch_stats.rst
@@ -1,5 +1,8 @@
-VCPU Dispatch Statistics:
-=========================
+.. SPDX-License-Identifier: GPL-2.0
+
+========================
+VCPU Dispatch Statistics
+========================
For Shared Processor LPARs, the POWER Hypervisor maintains a relatively
static mapping of the LPAR processors (vcpus) to physical processor
@@ -20,25 +23,29 @@ The statistics themselves are available by reading the procfs file
a vcpu as represented by the first field, followed by 8 numbers.
The first number corresponds to:
+
1. total vcpu dispatches since the beginning of statistics collection
The next 4 numbers represent vcpu dispatch dispersions:
+
2. number of times this vcpu was dispatched on the same processor as last
time
3. number of times this vcpu was dispatched on a different processor core
as last time, but within the same chip
4. number of times this vcpu was dispatched on a different chip
5. number of times this vcpu was dispatches on a different socket/drawer
-(next numa boundary)
+ (next numa boundary)
The final 3 numbers represent statistics in relation to the home node of
the vcpu:
+
6. number of times this vcpu was dispatched in its home node (chip)
7. number of times this vcpu was dispatched in a different node
8. number of times this vcpu was dispatched in a node further away (numa
-distance)
+ distance)
+
+An example output::
-An example output:
$ sudo cat /proc/powerpc/vcpudispatch_stats
cpu0 6839 4126 2683 30 0 6821 18 0
cpu1 2515 1274 1229 12 0 2509 6 0
--
2.25.4
^ permalink raw reply related
* Re: [PATCH] net/bonding: Do not transition down slave after speed/duplex check
From: Thomas Falcon @ 2020-04-30 16:14 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, Veaceslav Falico, linuxppc-dev, Andy Gospodarek
In-Reply-To: <29484.1588185503@famine>
On 4/29/20 1:38 PM, Jay Vosburgh wrote:
> Thomas Falcon <tlfalcon@linux.ibm.com> wrote:
>
>> The following behavior has been observed when testing logical partition
>> migration of LACP-bonded VNIC devices in a PowerVM pseries environment.
>>
>> 1. When performing the migration, the bond master detects that a slave has
>> lost its link, deactivates the LACP port, and sets the port's
>> is_enabled flag to false.
>> 2. The slave device then updates it's carrier state to off while it resets
>> itself. This update triggers a NETDEV_CHANGE notification, which performs
>> a speed and duplex update. The device does not return a valid speed
>> and duplex, so the master sets the slave link state to BOND_LINK_FAIL.
>> 3. When the slave VNIC device(s) are active again, some operations, such
>> as setting the port's is_enabled flag, are not performed when transitioning
>> the link state back to BOND_LINK_UP from BOND_LINK_FAIL, though the state
>> prior to the speed check was BOND_LINK_DOWN.
> Just to make sure I'm understanding correctly, in regards to
> "the state prior to the speed check was BOND_LINK_DOWN," do you mean
> that during step 1, the slave link is set to BOND_LINK_DOWN, and then in
> step 2 changed from _DOWN to _FAIL?
>
>> Affected devices are therefore not utilized in the aggregation though they
>> are operational. The simplest way to fix this seems to be to restrict the
>> link state change to devices that are currently up and running.
> This sounds similar to an issue from last fall; can you confirm
> that you're running with a kernel that includes:
>
> 1899bb325149 bonding: fix state transition issue in link monitoring
It did not have that fix. I will patch the kernel and rerun the test.
Thanks,
Tom
>
> -J
>
>
>> CC: Jay Vosburgh <j.vosburgh@gmail.com>
>> CC: Veaceslav Falico <vfalico@gmail.com>
>> CC: Andy Gospodarek <andy@greyhouse.net>
>> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
>> ---
>> drivers/net/bonding/bond_main.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 2e70e43c5df5..d840da7cd379 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -3175,7 +3175,8 @@ static int bond_slave_netdev_event(unsigned long event,
>> * speeds/duplex are available.
>> */
>> if (bond_update_speed_duplex(slave) &&
>> - BOND_MODE(bond) == BOND_MODE_8023AD) {
>> + BOND_MODE(bond) == BOND_MODE_8023AD &&
>> + slave->link == BOND_LINK_UP) {
>> if (slave->last_link_up)
>> slave->link = BOND_LINK_FAIL;
>> else
>> --
>> 2.18.2
>>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* [PATCH 07/37] docs: networking: convert netconsole.txt to ReST
From: Mauro Carvalho Chehab @ 2020-04-30 16:04 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Jonathan Corbet, Mauro Carvalho Chehab, linux-kernel,
Geoff Levand, netdev, Paul Mackerras, Jakub Kicinski,
linuxppc-dev, David S. Miller
In-Reply-To: <cover.1588261997.git.mchehab+huawei@kernel.org>
- add SPDX header;
- add a document title;
- mark code blocks and literals as such;
- mark tables as such;
- add notes markups;
- adjust identation, whitespaces and blank lines;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
.../admin-guide/kernel-parameters.txt | 2 +-
Documentation/admin-guide/serial-console.rst | 2 +-
Documentation/networking/index.rst | 1 +
.../{netconsole.txt => netconsole.rst} | 125 +++++++++++-------
drivers/net/Kconfig | 4 +-
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
drivers/net/ethernet/toshiba/spider_net.c | 2 +-
7 files changed, 84 insertions(+), 54 deletions(-)
rename Documentation/networking/{netconsole.txt => netconsole.rst} (66%)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 25644daa36ea..5a44c1bf85e7 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -638,7 +638,7 @@
See Documentation/admin-guide/serial-console.rst for more
information. See
- Documentation/networking/netconsole.txt for an
+ Documentation/networking/netconsole.rst for an
alternative.
uart[8250],io,<addr>[,options]
diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst
index a8d1e36b627a..58b32832e50a 100644
--- a/Documentation/admin-guide/serial-console.rst
+++ b/Documentation/admin-guide/serial-console.rst
@@ -54,7 +54,7 @@ You will need to create a new device to use ``/dev/console``. The official
``/dev/console`` is now character device 5,1.
(You can also use a network device as a console. See
-``Documentation/networking/netconsole.txt`` for information on that.)
+``Documentation/networking/netconsole.rst`` for information on that.)
Here's an example that will use ``/dev/ttyS1`` (COM2) as the console.
Replace the sample values as needed.
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 492658bf7c0d..e58f872d401d 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -80,6 +80,7 @@ Contents:
mac80211-injection
mpls-sysctl
multiqueue
+ netconsole
.. only:: subproject and html
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.rst
similarity index 66%
rename from Documentation/networking/netconsole.txt
rename to Documentation/networking/netconsole.rst
index 296ea00fd3eb..1f5c4a04027c 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.rst
@@ -1,7 +1,16 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========
+Netconsole
+==========
+
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
+
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
+
IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013
+
Extended console support by Tejun Heo <tj@kernel.org>, May 1 2015
Please send bug reports to Matt Mackall <mpm@selenic.com>
@@ -23,34 +32,34 @@ Sender and receiver configuration:
==================================
It takes a string configuration parameter "netconsole" in the
-following format:
+following format::
netconsole=[+][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
where
- + if present, enable extended console support
- src-port source for UDP packets (defaults to 6665)
- src-ip source IP to use (interface address)
- dev network interface (eth0)
- tgt-port port for logging agent (6666)
- tgt-ip IP address for logging agent
- tgt-macaddr ethernet MAC address for logging agent (broadcast)
+ + if present, enable extended console support
+ src-port source for UDP packets (defaults to 6665)
+ src-ip source IP to use (interface address)
+ dev network interface (eth0)
+ tgt-port port for logging agent (6666)
+ tgt-ip IP address for logging agent
+ tgt-macaddr ethernet MAC address for logging agent (broadcast)
-Examples:
+Examples::
linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
- or
+or::
insmod netconsole netconsole=@/,@10.0.0.2/
- or using IPv6
+or using IPv6::
insmod netconsole netconsole=@/,@fd00:1:2:3::1/
It also supports logging to multiple remote agents by specifying
parameters for the multiple agents separated by semicolons and the
-complete string enclosed in "quotes", thusly:
+complete string enclosed in "quotes", thusly::
modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,6892@10.0.0.3/"
@@ -67,14 +76,19 @@ for example:
On distributions using a BSD-based netcat version (e.g. Fedora,
openSUSE and Ubuntu) the listening port must be specified without
- the -p switch:
+ the -p switch::
- 'nc -u -l -p <port>' / 'nc -u -l <port>' or
- 'netcat -u -l -p <port>' / 'netcat -u -l <port>'
+ nc -u -l -p <port>' / 'nc -u -l <port>
+
+ or::
+
+ netcat -u -l -p <port>' / 'netcat -u -l <port>
3) socat
- 'socat udp-recv:<port> -'
+::
+
+ socat udp-recv:<port> -
Dynamic reconfiguration:
========================
@@ -92,7 +106,7 @@ netconsole module (or kernel, if netconsole is built-in).
Some examples follow (where configfs is mounted at the /sys/kernel/config
mountpoint).
-To add a remote logging target (target names can be arbitrary):
+To add a remote logging target (target names can be arbitrary)::
cd /sys/kernel/config/netconsole/
mkdir target1
@@ -102,12 +116,13 @@ above) and are disabled by default -- they must first be enabled by writing
"1" to the "enabled" attribute (usually after setting parameters accordingly)
as described below.
-To remove a target:
+To remove a target::
rmdir /sys/kernel/config/netconsole/othertarget/
The interface exposes these parameters of a netconsole target to userspace:
+ ============== ================================= ============
enabled Is this target currently enabled? (read-write)
extended Extended mode enabled (read-write)
dev_name Local network interface name (read-write)
@@ -117,12 +132,13 @@ The interface exposes these parameters of a netconsole target to userspace:
remote_ip Remote agent's IP address (read-write)
local_mac Local interface's MAC address (read-only)
remote_mac Remote agent's MAC address (read-write)
+ ============== ================================= ============
The "enabled" attribute is also used to control whether the parameters of
a target can be updated or not -- you can modify the parameters of only
disabled targets (i.e. if "enabled" is 0).
-To update a target's parameters:
+To update a target's parameters::
cat enabled # check if enabled is 1
echo 0 > enabled # disable the target (if required)
@@ -140,12 +156,12 @@ Extended console:
If '+' is prefixed to the configuration line or "extended" config file
is set to 1, extended console support is enabled. An example boot
-param follows.
+param follows::
linux netconsole=+4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
Log messages are transmitted with extended metadata header in the
-following format which is the same as /dev/kmsg.
+following format which is the same as /dev/kmsg::
<level>,<sequnum>,<timestamp>,<contflag>;<message text>
@@ -155,12 +171,12 @@ newline is used as the delimeter.
If a message doesn't fit in certain number of bytes (currently 1000),
the message is split into multiple fragments by netconsole. These
-fragments are transmitted with "ncfrag" header field added.
+fragments are transmitted with "ncfrag" header field added::
ncfrag=<byte-offset>/<total-bytes>
For example, assuming a lot smaller chunk size, a message "the first
-chunk, the 2nd chunk." may be split as follows.
+chunk, the 2nd chunk." may be split as follows::
6,416,1758426,-,ncfrag=0/31;the first chunk,
6,416,1758426,-,ncfrag=16/31; the 2nd chunk.
@@ -168,39 +184,52 @@ chunk, the 2nd chunk." may be split as follows.
Miscellaneous notes:
====================
-WARNING: the default target ethernet setting uses the broadcast
-ethernet address to send packets, which can cause increased load on
-other systems on the same ethernet segment.
+.. Warning::
-TIP: some LAN switches may be configured to suppress ethernet broadcasts
-so it is advised to explicitly specify the remote agents' MAC addresses
-from the config parameters passed to netconsole.
+ the default target ethernet setting uses the broadcast
+ ethernet address to send packets, which can cause increased load on
+ other systems on the same ethernet segment.
-TIP: to find out the MAC address of, say, 10.0.0.2, you may try using:
+.. Tip::
- ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
+ some LAN switches may be configured to suppress ethernet broadcasts
+ so it is advised to explicitly specify the remote agents' MAC addresses
+ from the config parameters passed to netconsole.
-TIP: in case the remote logging agent is on a separate LAN subnet than
-the sender, it is suggested to try specifying the MAC address of the
-default gateway (you may use /sbin/route -n to find it out) as the
-remote MAC address instead.
+.. Tip::
-NOTE: the network device (eth1 in the above case) can run any kind
-of other network traffic, netconsole is not intrusive. Netconsole
-might cause slight delays in other traffic if the volume of kernel
-messages is high, but should have no other impact.
+ to find out the MAC address of, say, 10.0.0.2, you may try using::
-NOTE: if you find that the remote logging agent is not receiving or
-printing all messages from the sender, it is likely that you have set
-the "console_loglevel" parameter (on the sender) to only send high
-priority messages to the console. You can change this at runtime using:
+ ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
- dmesg -n 8
+.. Tip::
-or by specifying "debug" on the kernel command line at boot, to send
-all kernel messages to the console. A specific value for this parameter
-can also be set using the "loglevel" kernel boot option. See the
-dmesg(8) man page and Documentation/admin-guide/kernel-parameters.rst for details.
+ in case the remote logging agent is on a separate LAN subnet than
+ the sender, it is suggested to try specifying the MAC address of the
+ default gateway (you may use /sbin/route -n to find it out) as the
+ remote MAC address instead.
+
+.. note::
+
+ the network device (eth1 in the above case) can run any kind
+ of other network traffic, netconsole is not intrusive. Netconsole
+ might cause slight delays in other traffic if the volume of kernel
+ messages is high, but should have no other impact.
+
+.. note::
+
+ if you find that the remote logging agent is not receiving or
+ printing all messages from the sender, it is likely that you have set
+ the "console_loglevel" parameter (on the sender) to only send high
+ priority messages to the console. You can change this at runtime using::
+
+ dmesg -n 8
+
+ or by specifying "debug" on the kernel command line at boot, to send
+ all kernel messages to the console. A specific value for this parameter
+ can also be set using the "loglevel" kernel boot option. See the
+ dmesg(8) man page and Documentation/admin-guide/kernel-parameters.rst
+ for details.
Netconsole was designed to be as instantaneous as possible, to
enable the logging of even the most critical kernel bugs. It works
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c822f4a6d166..ad64be98330f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -302,7 +302,7 @@ config NETCONSOLE
tristate "Network console logging support"
---help---
If you want to log kernel messages over the network, enable this.
- See <file:Documentation/networking/netconsole.txt> for details.
+ See <file:Documentation/networking/netconsole.rst> for details.
config NETCONSOLE_DYNAMIC
bool "Dynamic reconfiguration of logging targets"
@@ -312,7 +312,7 @@ config NETCONSOLE_DYNAMIC
This option enables the ability to dynamically reconfigure target
parameters (interface, IP addresses, port numbers, MAC addresses)
at runtime through a userspace interface exported using configfs.
- See <file:Documentation/networking/netconsole.txt> for details.
+ See <file:Documentation/networking/netconsole.rst> for details.
config NETPOLL
def_bool NETCONSOLE
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 070dd6fa9401..310e6839c6e5 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -1150,7 +1150,7 @@ static irqreturn_t gelic_card_interrupt(int irq, void *ptr)
* gelic_net_poll_controller - artificial interrupt for netconsole etc.
* @netdev: interface device structure
*
- * see Documentation/networking/netconsole.txt
+ * see Documentation/networking/netconsole.rst
*/
void gelic_net_poll_controller(struct net_device *netdev)
{
diff --git a/drivers/net/ethernet/toshiba/spider_net.c b/drivers/net/ethernet/toshiba/spider_net.c
index 6576271642c1..3902b3aeb0c2 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -1615,7 +1615,7 @@ spider_net_interrupt(int irq, void *ptr)
* spider_net_poll_controller - artificial interrupt for netconsole etc.
* @netdev: interface device structure
*
- * see Documentation/networking/netconsole.txt
+ * see Documentation/networking/netconsole.rst
*/
static void
spider_net_poll_controller(struct net_device *netdev)
--
2.25.4
^ permalink raw reply related
* [PATCH 00/37] net: manually convert files to ReST format - part 2
From: Mauro Carvalho Chehab @ 2020-04-30 16:03 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Marcelo Ricardo Leitner, David Howells, linux-sctp,
Paul Mackerras, Ioana Ciornei, linux-afs, devel, rds-devel,
Oliver Hartkopp, Ioana Radulescu, Jonathan Corbet,
Mauro Carvalho Chehab, Jozsef Kadlecsik, coreteam, Jakub Kicinski,
Pablo Neira Ayuso, linux-x25, Santosh Shilimkar, linux-can,
Marc Kleine-Budde, Remi Denis-Courmont, Kalle Valo,
Florian Westphal, Neil Horman, Geoff Levand, netdev,
Vlad Yasevich, linux-wireless, linux-kernel, linux-rdma,
netfilter-devel, Greg Kroah-Hartman, Johannes Berg, linuxppc-dev,
David S. Miller
That's the second part of my work to convert the networking
text files into ReST. it is based on today's linux-next (next-20200430).
The full series (including those ones) are at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=net-docs
I should be sending the remaining patches (another /38 series)
after getting those merged at -next.
The documents, converted to HTML via the building system are at:
https://www.infradead.org/~mchehab/kernel_docs/networking/
Mauro Carvalho Chehab (37):
docs: networking: convert l2tp.txt to ReST
docs: networking: convert lapb-module.txt to ReST
docs: networking: convert ltpc.txt to ReST
docs: networking: convert mac80211-injection.txt to ReST
docs: networking: convert mpls-sysctl.txt to ReST
docs: networking: convert multiqueue.txt to ReST
docs: networking: convert netconsole.txt to ReST
docs: networking: convert netdev-features.txt to ReST
docs: networking: convert netdevices.txt to ReST
docs: networking: convert netfilter-sysctl.txt to ReST
docs: networking: convert netif-msg.txt to ReST
docs: networking: convert nf_conntrack-sysctl.txt to ReST
docs: networking: convert nf_flowtable.txt to ReST
docs: networking: convert openvswitch.txt to ReST
docs: networking: convert operstates.txt to ReST
docs: networking: convert packet_mmap.txt to ReST
docs: networking: convert phonet.txt to ReST
docs: networking: convert pktgen.txt to ReST
docs: networking: convert PLIP.txt to ReST
docs: networking: convert ppp_generic.txt to ReST
docs: networking: convert proc_net_tcp.txt to ReST
docs: networking: convert radiotap-headers.txt to ReST
docs: networking: convert ray_cs.txt to ReST
docs: networking: convert rds.txt to ReST
docs: networking: convert regulatory.txt to ReST
docs: networking: convert rxrpc.txt to ReST
docs: networking: convert sctp.txt to ReST
docs: networking: convert secid.txt to ReST
docs: networking: convert seg6-sysctl.txt to ReST
docs: networking: convert skfp.txt to ReST
docs: networking: convert strparser.txt to ReST
docs: networking: convert switchdev.txt to ReST
docs: networking: convert tc-actions-env-rules.txt to ReST
docs: networking: convert tcp-thin.txt to ReST
docs: networking: convert team.txt to ReST
docs: networking: convert timestamping.txt to ReST
docs: networking: convert tproxy.txt to ReST
.../admin-guide/kernel-parameters.txt | 2 +-
Documentation/admin-guide/serial-console.rst | 2 +-
Documentation/filesystems/afs.rst | 2 +-
Documentation/networking/bonding.rst | 2 +-
Documentation/networking/can.rst | 2 +-
.../networking/checksum-offloads.rst | 2 +-
Documentation/networking/index.rst | 37 +
Documentation/networking/ip-sysctl.rst | 2 +-
.../networking/{l2tp.txt => l2tp.rst} | 145 ++-
.../{lapb-module.txt => lapb-module.rst} | 120 +-
.../networking/{ltpc.txt => ltpc.rst} | 45 +-
...1-injection.txt => mac80211-injection.rst} | 41 +-
.../{mpls-sysctl.txt => mpls-sysctl.rst} | 17 +-
.../{multiqueue.txt => multiqueue.rst} | 41 +-
.../{netconsole.txt => netconsole.rst} | 125 +-
...etdev-features.txt => netdev-features.rst} | 19 +-
.../{netdevices.txt => netdevices.rst} | 21 +-
...filter-sysctl.txt => netfilter-sysctl.rst} | 11 +-
Documentation/networking/netif-msg.rst | 95 ++
Documentation/networking/netif-msg.txt | 79 --
...ack-sysctl.txt => nf_conntrack-sysctl.rst} | 51 +-
.../{nf_flowtable.txt => nf_flowtable.rst} | 55 +-
.../{openvswitch.txt => openvswitch.rst} | 23 +-
.../{operstates.txt => operstates.rst} | 45 +-
Documentation/networking/packet_mmap.rst | 1084 +++++++++++++++++
Documentation/networking/packet_mmap.txt | 1061 ----------------
.../networking/{phonet.txt => phonet.rst} | 56 +-
.../networking/{pktgen.txt => pktgen.rst} | 316 ++---
.../networking/{PLIP.txt => plip.rst} | 43 +-
.../{ppp_generic.txt => ppp_generic.rst} | 52 +-
.../{proc_net_tcp.txt => proc_net_tcp.rst} | 23 +-
...iotap-headers.txt => radiotap-headers.rst} | 99 +-
.../networking/{ray_cs.txt => ray_cs.rst} | 101 +-
Documentation/networking/{rds.txt => rds.rst} | 295 +++--
.../{regulatory.txt => regulatory.rst} | 29 +-
.../networking/{rxrpc.txt => rxrpc.rst} | 306 ++---
.../networking/{sctp.txt => sctp.rst} | 37 +-
.../networking/{secid.txt => secid.rst} | 6 +
Documentation/networking/seg6-sysctl.rst | 26 +
Documentation/networking/seg6-sysctl.txt | 18 -
.../networking/{skfp.txt => skfp.rst} | 153 ++-
.../{strparser.txt => strparser.rst} | 85 +-
.../{switchdev.txt => switchdev.rst} | 114 +-
.../networking/tc-actions-env-rules.rst | 29 +
.../networking/tc-actions-env-rules.txt | 24 -
.../networking/{tcp-thin.txt => tcp-thin.rst} | 5 +
.../networking/{team.txt => team.rst} | 6 +
.../{timestamping.txt => timestamping.rst} | 154 ++-
.../networking/{tproxy.txt => tproxy.rst} | 55 +-
MAINTAINERS | 14 +-
drivers/net/Kconfig | 4 +-
drivers/net/appletalk/Kconfig | 2 +-
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
drivers/net/ethernet/toshiba/spider_net.c | 2 +-
drivers/net/fddi/Kconfig | 2 +-
drivers/net/plip/Kconfig | 2 +-
drivers/net/wireless/Kconfig | 2 +-
drivers/staging/fsl-dpaa2/ethsw/README | 2 +-
include/linux/netdev_features.h | 2 +-
include/net/cfg80211.h | 2 +-
include/uapi/linux/errqueue.h | 2 +-
net/Kconfig | 2 +-
net/core/pktgen.c | 2 +-
net/lapb/Kconfig | 2 +-
net/mac80211/tx.c | 2 +-
net/netfilter/Kconfig | 2 +-
net/rxrpc/Kconfig | 6 +-
net/rxrpc/sysctl.c | 2 +-
net/wireless/radiotap.c | 2 +-
samples/pktgen/README.rst | 2 +-
70 files changed, 2864 insertions(+), 2357 deletions(-)
rename Documentation/networking/{l2tp.txt => l2tp.rst} (79%)
rename Documentation/networking/{lapb-module.txt => lapb-module.rst} (74%)
rename Documentation/networking/{ltpc.txt => ltpc.rst} (86%)
rename Documentation/networking/{mac80211-injection.txt => mac80211-injection.rst} (67%)
rename Documentation/networking/{mpls-sysctl.txt => mpls-sysctl.rst} (82%)
rename Documentation/networking/{multiqueue.txt => multiqueue.rst} (76%)
rename Documentation/networking/{netconsole.txt => netconsole.rst} (66%)
rename Documentation/networking/{netdev-features.txt => netdev-features.rst} (95%)
rename Documentation/networking/{netdevices.txt => netdevices.rst} (89%)
rename Documentation/networking/{netfilter-sysctl.txt => netfilter-sysctl.rst} (62%)
create mode 100644 Documentation/networking/netif-msg.rst
delete mode 100644 Documentation/networking/netif-msg.txt
rename Documentation/networking/{nf_conntrack-sysctl.txt => nf_conntrack-sysctl.rst} (85%)
rename Documentation/networking/{nf_flowtable.txt => nf_flowtable.rst} (76%)
rename Documentation/networking/{openvswitch.txt => openvswitch.rst} (95%)
rename Documentation/networking/{operstates.txt => operstates.rst} (87%)
create mode 100644 Documentation/networking/packet_mmap.rst
delete mode 100644 Documentation/networking/packet_mmap.txt
rename Documentation/networking/{phonet.txt => phonet.rst} (82%)
rename Documentation/networking/{pktgen.txt => pktgen.rst} (62%)
rename Documentation/networking/{PLIP.txt => plip.rst} (92%)
rename Documentation/networking/{ppp_generic.txt => ppp_generic.rst} (91%)
rename Documentation/networking/{proc_net_tcp.txt => proc_net_tcp.rst} (83%)
rename Documentation/networking/{radiotap-headers.txt => radiotap-headers.rst} (70%)
rename Documentation/networking/{ray_cs.txt => ray_cs.rst} (65%)
rename Documentation/networking/{rds.txt => rds.rst} (59%)
rename Documentation/networking/{regulatory.txt => regulatory.rst} (94%)
rename Documentation/networking/{rxrpc.txt => rxrpc.rst} (85%)
rename Documentation/networking/{sctp.txt => sctp.rst} (64%)
rename Documentation/networking/{secid.txt => secid.rst} (87%)
create mode 100644 Documentation/networking/seg6-sysctl.rst
delete mode 100644 Documentation/networking/seg6-sysctl.txt
rename Documentation/networking/{skfp.txt => skfp.rst} (68%)
rename Documentation/networking/{strparser.txt => strparser.rst} (80%)
rename Documentation/networking/{switchdev.txt => switchdev.rst} (84%)
create mode 100644 Documentation/networking/tc-actions-env-rules.rst
delete mode 100644 Documentation/networking/tc-actions-env-rules.txt
rename Documentation/networking/{tcp-thin.txt => tcp-thin.rst} (97%)
rename Documentation/networking/{team.txt => team.rst} (67%)
rename Documentation/networking/{timestamping.txt => timestamping.rst} (89%)
rename Documentation/networking/{tproxy.txt => tproxy.rst} (70%)
--
2.25.4
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Dave Hansen @ 2020-04-30 16:04 UTC (permalink / raw)
To: David Hildenbrand, Eric W. Biederman
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, linux-mm,
Wei Yang, linux-s390, linux-nvdimm, linux-kernel, virtualization,
linux-acpi, Michael S . Tsirkin, Pankaj Gupta, xen-devel,
Andrew Morton, Michal Hocko, linuxppc-dev
In-Reply-To: <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
On 4/30/20 8:52 AM, David Hildenbrand wrote:
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
>
> I'd love to get Dan's, Dave's and Michal's opinion.
The impact on kexec from the DAX "kmem" driver's use of hotplug was
inadvertent and unfortunate.
The problem statement and solution seem pretty sane to me.
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 15:52 UTC (permalink / raw)
To: Eric W. Biederman
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, linux-mm,
Wei Yang, linux-s390, linux-nvdimm, linux-kernel, virtualization,
linux-acpi, Michael S . Tsirkin, Pankaj Gupta, xen-devel,
Andrew Morton, Michal Hocko, linuxppc-dev
In-Reply-To: <87pnbp2dcz.fsf@x220.int.ebiederm.org>
On 30.04.20 17:38, Eric W. Biederman wrote:
> David Hildenbrand <david@redhat.com> writes:
>
>> Some devices/drivers that add memory via add_memory() and friends (e.g.,
>> dax/kmem, but also virtio-mem in the future) don't want to create entries
>> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
>> memory to the boot memmap of the kexec kernel.
>>
>> In fact, such memory is never exposed via the firmware memmap as System
>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>> wrong:
>> "kexec needs the raw firmware-provided memory map to setup the
>> parameter segment of the kernel that should be booted with
>> kexec. Also, the raw memory map is useful for debugging. For
>> that reason, /sys/firmware/memmap is an interface that provides
>> the raw memory map to userspace." [1]
>>
>> We don't have to worry about firmware_map_remove() on the removal path.
>> If there is no entry, it will simply return with -EINVAL.
>>
>> [1]
>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
>
>
> You know what this justification is rubbish, and I have previously
> explained why it is rubbish.
Actually, no, I don't think it is rubbish. See patch #3 and the cover
letter why this is the right thing to do *for special memory*, *not
ordinary DIMMs*.
And to be quite honest, I think your response is a little harsh. I don't
recall you replying to my virtio-mem-related comments.
>
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> This needs to be based on weather the added memory is ultimately normal
> ram or is something special.
Yes, that's what the caller are expected to decide, see patch #3.
kexec should try to be as closely as possible to a real reboot - IMHO.
>
> At least when we are talking memory resources. Keeping it out of the
> firmware map that is fine.
>
> If the hotplugged memory is the result of plugging a stick of ram
> into the kernel and can and should used be like any other memory
> it should be treated like any normal memory.
>
> If the hotplugged memory is something special it should be treated as
> something special.
I am really sorry, I can't make sense of what you are trying to say here.
>
> Justifying behavior by documentation that does not consider memory
> hotplug is bad thinking.
Are you maybe confusing this patch series with the arm64 approach? This
is not about ordinary hotplugged DIMMs.
I'd love to get Dan's, Dave's and Michal's opinion.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Eric W. Biederman @ 2020-04-30 15:38 UTC (permalink / raw)
To: David Hildenbrand
Cc: virtio-dev, linux-hyperv, Michal Hocko, Baoquan He, linux-mm,
Wei Yang, linux-s390, linux-nvdimm, linux-kernel, virtualization,
linux-acpi, Michael S . Tsirkin, Pankaj Gupta, xen-devel,
Andrew Morton, Michal Hocko, linuxppc-dev
In-Reply-To: <20200430102908.10107-3-david@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> Some devices/drivers that add memory via add_memory() and friends (e.g.,
> dax/kmem, but also virtio-mem in the future) don't want to create entries
> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this
> memory to the boot memmap of the kexec kernel.
>
> In fact, such memory is never exposed via the firmware memmap as System
> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
> wrong:
> "kexec needs the raw firmware-provided memory map to setup the
> parameter segment of the kernel that should be booted with
> kexec. Also, the raw memory map is useful for debugging. For
> that reason, /sys/firmware/memmap is an interface that provides
> the raw memory map to userspace." [1]
>
> We don't have to worry about firmware_map_remove() on the removal path.
> If there is no entry, it will simply return with -EINVAL.
>
> [1]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap
You know what this justification is rubbish, and I have previously
explained why it is rubbish.
Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
This needs to be based on weather the added memory is ultimately normal
ram or is something special.
At least when we are talking memory resources. Keeping it out of the
firmware map that is fine.
If the hotplugged memory is the result of plugging a stick of ram
into the kernel and can and should used be like any other memory
it should be treated like any normal memory.
If the hotplugged memory is something special it should be treated as
something special.
Justifying behavior by documentation that does not consider memory
hotplug is bad thinking.
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> include/linux/memory_hotplug.h | 8 ++++++++
> mm/memory_hotplug.c | 3 ++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0151fb935c09..4ca418a731eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
> pgprot_t pgprot;
> };
>
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/. The memory is detected and
> + * added via a device driver, not via the initial (firmware) memmap.
> + */
> +#define MHP_NO_FIRMWARE_MEMMAP 1
> +
> /*
> * Zone resizing functions
> *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c01be92693e3..e94ede9cad00 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
> BUG_ON(ret);
>
> /* create new memmap entry */
> - firmware_map_add_hotplug(start, start + size, "System RAM");
> + if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
> + firmware_map_add_hotplug(start, start + size, "System RAM");
>
> /* device_online() will take the lock when calling online_pages() */
> mem_hotplug_done();
^ permalink raw reply
* Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 15:28 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: virtio-dev, linux-hyperv, Michal Hocko, linux-acpi, Baoquan He,
linux-nvdimm, linux-s390, Michael S . Tsirkin, Dave Hansen,
virtualization, linux-mm, Wei Yang, Eric Biederman, Pankaj Gupta,
xen-devel, Andrew Morton, Michal Hocko, linuxppc-dev,
Dan Williams, Pavel Tatashin
In-Reply-To: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
On 30.04.20 13:23, Dave Hansen wrote:
> On 4/30/20 3:29 AM, David Hildenbrand wrote:
>> Currently, when adding memory, we create entries in /sys/firmware/memmap/
>> as "System RAM". This does not reflect the reality and will lead to
>> kexec-tools to add that memory to the fixed-up initial memmap for a
>> kexec kernel (loaded via kexec_load()). The memory will be considered
>> initial System RAM by the kexec kernel.
>>
>> We should let the kexec kernel decide how to use that memory - just as
>> we do during an ordinary reboot.
> ...
>> - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
>> + rc = add_memory(numa_node, new_res->start, resource_size(new_res),
>> + MHP_NO_FIRMWARE_MEMMAP);
>
> Looks fine. But, if you send another revision, could you add a comment
> about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
>
> /*
> * MHP_NO_FIRMWARE_MEMMAP ensures that future
> * kexec'd kernels will not treat this as RAM.
> */
>
> Not a biggie, though.
Sure, maybe Andrew can fixup when applying (if no resend is necessary).
Thanks Dave!
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH] i2c: powermac: use true,false for bool variable
From: Wolfram Sang @ 2020-04-30 14:19 UTC (permalink / raw)
To: Jason Yan; +Cc: linux-kernel, paulus, linux-i2c, linuxppc-dev
In-Reply-To: <20200426094228.23829-1-yanaijie@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
On Sun, Apr 26, 2020 at 05:42:28PM +0800, Jason Yan wrote:
> In i2c_powermac_register_devices(), variable 'found_onyx' is bool and
> assigned '0' and 'true' in different places. Use 'false' instead of '0'.
> This fixes the following coccicheck warning:
>
> drivers/i2c/busses/i2c-powermac.c:318:6-16: WARNING: Assignment of 0/1
> to bool variable
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 1/2 v2] powerpc/dma: Define map/unmap mmio resource callbacks
From: Max Gurtovoy @ 2020-04-30 13:15 UTC (permalink / raw)
To: hch, linux-pci, oohall, linuxppc-dev
Cc: vladimirk, clsoto, israelr, shlomin, fbarrat, Max Gurtovoy, idanw,
aneela
Define the map_resource/unmap_resource callbacks for the dma_iommu_ops
used by several powerpc platforms. The map_resource callback is called
when trying to map a mmio resource through the dma_map_resource()
driver API.
For now, the callback returns an invalid address for devices using
translations, but will "direct" map the resource when in bypass
mode. Previous behavior for dma_map_resource() was to always return an
invalid address.
We also call an optional platform-specific controller op in
case some setup is needed for the platform.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
---
changes from v1:
- rename pci_controller_ops callback to dma_direct_map_resource/dma_direct_unmap_resource
- cosmetic changes to make the code more readable
---
arch/powerpc/include/asm/pci-bridge.h | 7 +++++++
arch/powerpc/kernel/dma-iommu.c | 31 +++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 69f4cb3..aca3724 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -44,6 +44,13 @@ struct pci_controller_ops {
#endif
void (*shutdown)(struct pci_controller *hose);
+ int (*dma_direct_map_resource)(struct pci_dev *pdev,
+ phys_addr_t phys_addr,
+ size_t size,
+ enum dma_data_direction dir);
+ void (*dma_direct_unmap_resource)(struct pci_dev *pdev,
+ dma_addr_t addr, size_t size,
+ enum dma_data_direction dir);
};
/*
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index e486d1d..049d000 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -108,6 +108,35 @@ static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist,
dma_direct_unmap_sg(dev, sglist, nelems, direction, attrs);
}
+static dma_addr_t dma_iommu_map_resource(struct device *dev,
+ phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct pci_controller *phb = pci_bus_to_host(pdev->bus);
+ struct pci_controller_ops *ops = &phb->controller_ops;
+
+ if (!dma_iommu_map_bypass(dev, attrs) ||
+ !ops->dma_direct_map_resource ||
+ ops->dma_direct_map_resource(pdev, phys_addr, size, dir))
+ return DMA_MAPPING_ERROR;
+
+ return dma_direct_map_resource(dev, phys_addr, size, dir, attrs);
+}
+
+static void dma_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct pci_controller *phb = pci_bus_to_host(pdev->bus);
+ struct pci_controller_ops *ops = &phb->controller_ops;
+
+ if (dma_iommu_map_bypass(dev, attrs) && ops->dma_direct_unmap_resource)
+ ops->dma_direct_unmap_resource(pdev, dma_handle, size, dir);
+}
+
static bool dma_iommu_bypass_supported(struct device *dev, u64 mask)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -199,6 +228,8 @@ extern void dma_iommu_sync_sg_for_device(struct device *dev,
.free = dma_iommu_free_coherent,
.map_sg = dma_iommu_map_sg,
.unmap_sg = dma_iommu_unmap_sg,
+ .map_resource = dma_iommu_map_resource,
+ .unmap_resource = dma_iommu_unmap_resource,
.dma_supported = dma_iommu_dma_supported,
.map_page = dma_iommu_map_page,
.unmap_page = dma_iommu_unmap_page,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2 v2] powerpc/powernv: Enable and setup PCI P2P
From: Max Gurtovoy @ 2020-04-30 13:15 UTC (permalink / raw)
To: hch, linux-pci, oohall, linuxppc-dev
Cc: vladimirk, clsoto, israelr, shlomin, fbarrat, Max Gurtovoy, idanw,
aneela
In-Reply-To: <20200430131520.51211-1-maxg@mellanox.com>
Implement the generic dma_map_resource callback on the PCI controller
for powernv. This will enable PCI P2P on POWER9 architecture. It will
allow catching a cross-PHB mmio mapping, which needs to be setup in
hardware by calling opal. Both the initiator and target PHBs need to be
configured, so we look for which PHB owns the mmio address being mapped.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
[maxg: added CONFIG_PCI_P2PDMA wrappers]
Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
---
changes from v1:
- remove CONFIG_PCI_P2PDMA around opal_pci_set_p2p decleration
- divide pnv_pci_ioda_set_p2p to pnv_pci_ioda_enable_p2p/pnv_pci_ioda_disable_p2p
- added pnv_pci_dma_dir_to_opal_p2p static helper
---
arch/powerpc/include/asm/opal.h | 3 +-
arch/powerpc/platforms/powernv/opal-call.c | 1 +
arch/powerpc/platforms/powernv/pci-ioda.c | 212 +++++++++++++++++++++++++++--
arch/powerpc/platforms/powernv/pci.h | 9 ++
4 files changed, 213 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9986ac3..362f54b 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -284,7 +284,8 @@ int64_t opal_xive_set_queue_state(uint64_t vp, uint32_t prio,
uint32_t qtoggle,
uint32_t qindex);
int64_t opal_xive_get_vp_state(uint64_t vp, __be64 *out_w01);
-
+int64_t opal_pci_set_p2p(uint64_t phb_init, uint64_t phb_target,
+ uint64_t desc, uint16_t pe_number);
int64_t opal_imc_counters_init(uint32_t type, uint64_t address,
uint64_t cpu_pir);
int64_t opal_imc_counters_start(uint32_t type, uint64_t cpu_pir);
diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c
index 5cd0f52..442d5445c 100644
--- a/arch/powerpc/platforms/powernv/opal-call.c
+++ b/arch/powerpc/platforms/powernv/opal-call.c
@@ -273,6 +273,7 @@ int64_t name(int64_t a0, int64_t a1, int64_t a2, int64_t a3, \
OPAL_CALL(opal_imc_counters_init, OPAL_IMC_COUNTERS_INIT);
OPAL_CALL(opal_imc_counters_start, OPAL_IMC_COUNTERS_START);
OPAL_CALL(opal_imc_counters_stop, OPAL_IMC_COUNTERS_STOP);
+OPAL_CALL(opal_pci_set_p2p, OPAL_PCI_SET_P2P);
OPAL_CALL(opal_get_powercap, OPAL_GET_POWERCAP);
OPAL_CALL(opal_set_powercap, OPAL_SET_POWERCAP);
OPAL_CALL(opal_get_power_shift_ratio, OPAL_GET_POWER_SHIFT_RATIO);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 57d3a6a..9ecc576 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3706,18 +3706,208 @@ static void pnv_pci_ioda_dma_bus_setup(struct pci_bus *bus)
}
}
+#ifdef CONFIG_PCI_P2PDMA
+static DEFINE_MUTEX(p2p_mutex);
+
+static bool pnv_pci_controller_owns_addr(struct pci_controller *hose,
+ phys_addr_t addr, size_t size)
+{
+ int i;
+
+ /*
+ * It seems safe to assume the full range is under the same PHB, so we
+ * can ignore the size.
+ */
+ for (i = 0; i < ARRAY_SIZE(hose->mem_resources); i++) {
+ struct resource *res = &hose->mem_resources[i];
+
+ if (res->flags && addr >= res->start && addr < res->end)
+ return true;
+ }
+ return false;
+}
+
+/*
+ * find the phb owning a mmio address if not owned locally
+ */
+static struct pnv_phb *pnv_pci_find_owning_phb(struct pci_dev *pdev,
+ phys_addr_t addr, size_t size)
+{
+ struct pci_controller *hose;
+
+ /* fast path */
+ if (pnv_pci_controller_owns_addr(pdev->bus->sysdata, addr, size))
+ return NULL;
+
+ list_for_each_entry(hose, &hose_list, list_node) {
+ struct pnv_phb *phb = hose->private_data;
+
+ if (phb->type != PNV_PHB_NPU_NVLINK &&
+ phb->type != PNV_PHB_NPU_OCAPI) {
+ if (pnv_pci_controller_owns_addr(hose, addr, size))
+ return phb;
+ }
+ }
+ return NULL;
+}
+
+static u64 pnv_pci_dma_dir_to_opal_p2p(enum dma_data_direction dir)
+{
+ if (dir == DMA_TO_DEVICE)
+ return OPAL_PCI_P2P_STORE;
+ else if (dir == DMA_FROM_DEVICE)
+ return OPAL_PCI_P2P_LOAD;
+ else if (dir == DMA_BIDIRECTIONAL)
+ return OPAL_PCI_P2P_LOAD | OPAL_PCI_P2P_STORE;
+ else
+ return 0;
+}
+
+static int pnv_pci_ioda_enable_p2p(struct pci_dev *initiator,
+ struct pnv_phb *phb_target,
+ enum dma_data_direction dir)
+{
+ struct pci_controller *hose;
+ struct pnv_phb *phb_init;
+ struct pnv_ioda_pe *pe_init;
+ u64 desc;
+ int rc;
+
+ if (!opal_check_token(OPAL_PCI_SET_P2P))
+ return -ENXIO;
+
+ hose = pci_bus_to_host(initiator->bus);
+ phb_init = hose->private_data;
+
+ pe_init = pnv_ioda_get_pe(initiator);
+ if (!pe_init)
+ return -ENODEV;
+
+ if (!pe_init->tce_bypass_enabled)
+ return -EINVAL;
+
+ /*
+ * Configuring the initiator's PHB requires to adjust its TVE#1
+ * setting. Since the same device can be an initiator several times for
+ * different target devices, we need to keep a reference count to know
+ * when we can restore the default bypass setting on its TVE#1 when
+ * disabling. Opal is not tracking PE states, so we add a reference
+ * count on the PE in linux.
+ *
+ * For the target, the configuration is per PHB, so we keep a
+ * target reference count on the PHB.
+ */
+ mutex_lock(&p2p_mutex);
+
+ desc = OPAL_PCI_P2P_ENABLE | pnv_pci_dma_dir_to_opal_p2p(dir);
+ /* always go to opal to validate the configuration */
+ rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id, desc,
+ pe_init->pe_number);
+ if (rc != OPAL_SUCCESS) {
+ rc = -EIO;
+ goto out;
+ }
+
+ pe_init->p2p_initiator_count++;
+ phb_target->p2p_target_count++;
+
+
+ rc = 0;
+out:
+ mutex_unlock(&p2p_mutex);
+ return rc;
+}
+
+static int pnv_pci_dma_map_resource(struct pci_dev *pdev,
+ phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir)
+{
+ struct pnv_phb *target_phb;
+
+ target_phb = pnv_pci_find_owning_phb(pdev, phys_addr, size);
+ if (!target_phb)
+ return 0;
+
+ return pnv_pci_ioda_enable_p2p(pdev, target_phb, dir);
+}
+
+static int pnv_pci_ioda_disable_p2p(struct pci_dev *initiator,
+ struct pnv_phb *phb_target)
+{
+ struct pci_controller *hose;
+ struct pnv_phb *phb_init;
+ struct pnv_ioda_pe *pe_init;
+ int rc;
+
+ if (!opal_check_token(OPAL_PCI_SET_P2P))
+ return -ENXIO;
+
+ hose = pci_bus_to_host(initiator->bus);
+ phb_init = hose->private_data;
+
+ pe_init = pnv_ioda_get_pe(initiator);
+ if (!pe_init)
+ return -ENODEV;
+
+ mutex_lock(&p2p_mutex);
+
+ if (!pe_init->p2p_initiator_count || !phb_target->p2p_target_count) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ if (--pe_init->p2p_initiator_count == 0)
+ pnv_pci_ioda2_set_bypass(pe_init, true);
+
+ if (--phb_target->p2p_target_count == 0) {
+ rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id,
+ 0, pe_init->pe_number);
+ if (rc != OPAL_SUCCESS) {
+ rc = -EIO;
+ goto out;
+ }
+ }
+
+ rc = 0;
+out:
+ mutex_unlock(&p2p_mutex);
+ return rc;
+}
+
+static void pnv_pci_dma_unmap_resource(struct pci_dev *pdev,
+ dma_addr_t addr, size_t size,
+ enum dma_data_direction dir)
+{
+ struct pnv_phb *target_phb;
+ int rc;
+
+ target_phb = pnv_pci_find_owning_phb(pdev, addr, size);
+ if (!target_phb)
+ return;
+
+ rc = pnv_pci_ioda_disable_p2p(pdev, target_phb);
+ if (rc)
+ dev_err(&pdev->dev, "Failed to undo PCI peer-to-peer setup for address %llx: %d\n",
+ addr, rc);
+}
+#endif
+
static const struct pci_controller_ops pnv_pci_ioda_controller_ops = {
- .dma_dev_setup = pnv_pci_ioda_dma_dev_setup,
- .dma_bus_setup = pnv_pci_ioda_dma_bus_setup,
- .iommu_bypass_supported = pnv_pci_ioda_iommu_bypass_supported,
- .setup_msi_irqs = pnv_setup_msi_irqs,
- .teardown_msi_irqs = pnv_teardown_msi_irqs,
- .enable_device_hook = pnv_pci_enable_device_hook,
- .release_device = pnv_pci_release_device,
- .window_alignment = pnv_pci_window_alignment,
- .setup_bridge = pnv_pci_setup_bridge,
- .reset_secondary_bus = pnv_pci_reset_secondary_bus,
- .shutdown = pnv_pci_ioda_shutdown,
+ .dma_dev_setup = pnv_pci_ioda_dma_dev_setup,
+ .dma_bus_setup = pnv_pci_ioda_dma_bus_setup,
+ .iommu_bypass_supported = pnv_pci_ioda_iommu_bypass_supported,
+ .setup_msi_irqs = pnv_setup_msi_irqs,
+ .teardown_msi_irqs = pnv_teardown_msi_irqs,
+ .enable_device_hook = pnv_pci_enable_device_hook,
+ .release_device = pnv_pci_release_device,
+ .window_alignment = pnv_pci_window_alignment,
+ .setup_bridge = pnv_pci_setup_bridge,
+ .reset_secondary_bus = pnv_pci_reset_secondary_bus,
+ .shutdown = pnv_pci_ioda_shutdown,
+#ifdef CONFIG_PCI_P2PDMA
+ .dma_direct_map_resource = pnv_pci_dma_map_resource,
+ .dma_direct_unmap_resource = pnv_pci_dma_unmap_resource,
+#endif
};
static const struct pci_controller_ops pnv_npu_ioda_controller_ops = {
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index d3bbdea..5f85d9c 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -79,6 +79,10 @@ struct pnv_ioda_pe {
struct pnv_ioda_pe *master;
struct list_head slaves;
+#ifdef CONFIG_PCI_P2PDMA
+ /* PCI peer-to-peer*/
+ int p2p_initiator_count;
+#endif
/* Link in list of PE#s */
struct list_head list;
};
@@ -168,6 +172,11 @@ struct pnv_phb {
/* PHB and hub diagnostics */
unsigned int diag_data_size;
u8 *diag_data;
+
+#ifdef CONFIG_PCI_P2PDMA
+ /* PCI peer-to-peer*/
+ int p2p_target_count;
+#endif
};
extern struct pci_ops pnv_pci_ops;
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC PATCH v2 7/7] powerpc/selftest: reuse ppc-opcode macros to avoid redundancy
From: Naveen N. Rao @ 2020-04-30 11:57 UTC (permalink / raw)
To: Balamuruhan S, Michael Ellerman
Cc: ravi.bangoria, jniethe5, paulus, sandipan, linuxppc-dev
In-Reply-To: <87y2qdelvm.fsf@mpe.ellerman.id.au>
Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>> Michael Ellerman wrote:
>>> Balamuruhan S <bala24@linux.ibm.com> writes:
>>>> Avoid redefining macros to encode ppc instructions instead reuse it from
>>>> ppc-opcode.h, Makefile changes are necessary to compile memcmp_64.S with
>>>> __ASSEMBLY__ defined from selftests.
>>>>
>>>> Signed-off-by: Balamuruhan S <bala24@linux.ibm.com>
>>>> ---
>>>> .../selftests/powerpc/stringloops/Makefile | 34 ++++++++++++++----
>>>> .../powerpc/stringloops/asm/asm-const.h | 1 +
>>>> .../powerpc/stringloops/asm/ppc-opcode.h | 36 +------------------
>>>> 3 files changed, 29 insertions(+), 42 deletions(-)
>>>> create mode 120000 tools/testing/selftests/powerpc/stringloops/asm/asm-const.h
>>>> mode change 100644 => 120000 tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h
>>>>
>>>> diff --git a/tools/testing/selftests/powerpc/stringloops/Makefile b/tools/testing/selftests/powerpc/stringloops/Makefile
>>>> index 7fc0623d85c3..efe76c5a5b94 100644
>>>> --- a/tools/testing/selftests/powerpc/stringloops/Makefile
>>>> +++ b/tools/testing/selftests/powerpc/stringloops/Makefile
>>>> @@ -1,26 +1,44 @@
>>>> # SPDX-License-Identifier: GPL-2.0
>>>> # The loops are all 64-bit code
>>>> -CFLAGS += -I$(CURDIR)
>>>> +GIT_VERSION = $(shell git describe --always --long --dirty || echo "unknown")
>>>> +CFLAGS += -DGIT_VERSION='"$(GIT_VERSION)"' -I$(CURDIR) -I$(CURDIR)/../include
>>>>
>>>> EXTRA_SOURCES := ../harness.c
>>>>
>>>> build_32bit = $(shell if ($(CC) $(CFLAGS) -m32 -o /dev/null memcmp.c >/dev/null 2>&1) then echo "1"; fi)
>>>>
>>>> +ifneq ($(build_32bit),1)
>>>> TEST_GEN_PROGS := memcmp_64 strlen
>>>> +TEST_GEN_FILES := memcmp.o memcmp_64.o memcmp_64
>>>> +MEMCMP := $(OUTPUT)/memcmp.o
>>>> +MEMCMP_64 := $(OUTPUT)/memcmp_64.o
>>>> +HARNESS := $(OUTPUT)/../harness.o
>>>> +CFLAGS += -m64 -maltivec
>>>>
>>>> -$(OUTPUT)/memcmp_64: memcmp.c
>>>> -$(OUTPUT)/memcmp_64: CFLAGS += -m64 -maltivec
>>>> +OVERRIDE_TARGETS := 1
>>>> +include ../../lib.mk
>>>>
>>>> -ifeq ($(build_32bit),1)
>>>> +$(OUTPUT)/memcmp_64: $(MEMCMP_64) $(MEMCMP) $(HARNESS)
>>>> + $(CC) $(CFLAGS) memcmp.o memcmp_64.o ../harness.o -o memcmp_64
>>>> +
>>>> +$(MEMCMP_64): memcmp_64.S
>>>> + $(CC) $(CFLAGS) -D__ASSEMBLY__ -o memcmp_64.o -c memcmp_64.S
>>>> +
>>>> +$(MEMCMP): memcmp.c
>>>> + $(CC) $(CFLAGS) -o memcmp.o -c memcmp.c
>>>> +
>>>> +$(HARNESS): $(EXTRA_SOURCES)
>>>> + $(CC) $(CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"' -o ../harness.o -c $(EXTRA_SOURCES)
>>>
>>> What are you actually trying to do here? Is it just that you need to
>>> define __ASSEMBLY__ for memcmp_64.S?
>>
>> Adding __ASSEMBLY__ while building memcmp_64.S would be the goal, so as
>> to reuse ppc-opcode.h. However, asm/ppc-opcode.h under stringloops test
>> is tiny and doesn't seem to justify the change.
>
> I don't see ppc-opcode.h testing __ASSEMBLY__ though, so I don't think
> we even need to define it?
Right -- it's rather 'stringify_in_c' which tests it. 'asm/ppc-opcode.h'
under stringloops/ unconditionally defines 'stringify_in_c' this way:
# define stringify_in_c(...) __VA_ARGS__
- Naveen
^ permalink raw reply
* Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
From: Dave Hansen @ 2020-04-30 11:23 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: virtio-dev, linux-hyperv, Michal Hocko, linux-acpi, Baoquan He,
linux-nvdimm, linux-s390, Michael S . Tsirkin, Dave Hansen,
virtualization, linux-mm, Wei Yang, Eric Biederman, Pankaj Gupta,
xen-devel, Andrew Morton, Michal Hocko, linuxppc-dev,
Dan Williams, Pavel Tatashin
In-Reply-To: <20200430102908.10107-4-david@redhat.com>
On 4/30/20 3:29 AM, David Hildenbrand wrote:
> Currently, when adding memory, we create entries in /sys/firmware/memmap/
> as "System RAM". This does not reflect the reality and will lead to
> kexec-tools to add that memory to the fixed-up initial memmap for a
> kexec kernel (loaded via kexec_load()). The memory will be considered
> initial System RAM by the kexec kernel.
>
> We should let the kexec kernel decide how to use that memory - just as
> we do during an ordinary reboot.
...
> - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
> + rc = add_memory(numa_node, new_res->start, resource_size(new_res),
> + MHP_NO_FIRMWARE_MEMMAP);
Looks fine. But, if you send another revision, could you add a comment
about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
/*
* MHP_NO_FIRMWARE_MEMMAP ensures that future
* kexec'd kernels will not treat this as RAM.
*/
Not a biggie, though.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v6 3/4] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
From: Vaibhav Jain @ 2020-04-30 11:07 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, linux-nvdimm; +Cc: Aneesh Kumar K . V
In-Reply-To: <87lfmde3il.fsf@mpe.ellerman.id.au>
Hi Mpe,
Thanks again for reviewing this patchset.
Michael Ellerman <mpe@ellerman.id.au> writes:
> Vaibhav Jain <vaibhav@linux.ibm.com> writes:
>> Introduce support for Papr nvDimm Specific Methods (PDSM) in papr_scm
>> modules and add the command family to the white list of NVDIMM command
>> sets. Also advertise support for ND_CMD_CALL for the dimm
>> command mask and implement necessary scaffolding in the module to
>> handle ND_CMD_CALL ioctl and PDSM requests that we receive.
>>
>> The layout of the PDSM request as we expect from libnvdimm/libndctl is
>> described in newly introduced uapi header 'papr_scm_pdsm.h' which
>> defines a new 'struct nd_pdsm_cmd_pkg' header. This header is used
>> to communicate the PDSM request via member
>> 'nd_pkg_papr_scm->nd_command' and size of payload that need to be
>> sent/received for servicing the PDSM.
>>
>> A new function is_cmd_valid() is implemented that reads the args to
>> papr_scm_ndctl() and performs sanity tests on them. A new function
>> papr_scm_service_pdsm() is introduced and is called from
>> papr_scm_ndctl() in case of a PDSM request is received via ND_CMD_CALL
>> command from libnvdimm.
>>
>> Cc: Dan Williams <dan.j.williams@intel.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
>> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
>> ---
>> Changelog
>>
>> v5..v6 :
>> * Changed the usage of the term DSM to PDSM to distinguish it from the
>> ACPI term [ Dan Williams ]
>> * Renamed papr_scm_dsm.h to papr_scm_pdsm.h and updated various struct
>> to reflect the new terminology.
>> * Updated the patch description and title to reflect the new terminology.
>> * Squashed patch to introduce new command family in 'ndctl.h' with
>> this patch [ Dan Williams ]
>> * Updated the papr_scm_pdsm method starting index from 0x10000 to 0x0
>> [ Dan Williams ]
>> * Removed redundant license text from the papr_scm_psdm.h file.
>> [ Dan Williams ]
>> * s/envelop/envelope/ at various places [ Dan Williams ]
>> * Added '__packed' attribute to command package header to gaurd
>> against different compiler adding paddings between the fields.
>> [ Dan Williams]
>> * Converted various pr_debug to dev_debug [ Dan Williams ]
>>
>> v4..v5 :
>> * None
>>
>> v3..v4 :
>> * None
>>
>> v2..v3 :
>> * Updated the patch prefix to 'ndctl/uapi' [Aneesh]
>>
>> v1..v2 :
>> * None
>> ---
>> arch/powerpc/include/uapi/asm/papr_scm_pdsm.h | 153 ++++++++++++++++++
>> arch/powerpc/platforms/pseries/papr_scm.c | 101 +++++++++++-
>> include/uapi/linux/ndctl.h | 1 +
>> 3 files changed, 249 insertions(+), 6 deletions(-)
>> create mode 100644 arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
>>
>> diff --git a/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
>> new file mode 100644
>> index 000000000000..ec48b5c7fc18
>> --- /dev/null
>> +++ b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
>> @@ -0,0 +1,153 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
>> +/*
>> + * PAPR-SCM Dimm specific methods (PDSM) and structs for libndctl
>> + *
>> + * (C) Copyright IBM 2020
>> + *
>> + * Author: Vaibhav Jain <vaibhav at linux.ibm.com>
>> + */
>> +
>> +#ifndef _UAPI_ASM_POWERPC_PAPR_SCM_PDSM_H_
>> +#define _UAPI_ASM_POWERPC_PAPR_SCM_PDSM_H_
>> +
>> +#include <linux/types.h>
>> +
>> +#ifdef __KERNEL__
>> +#include <linux/ndctl.h>
>> +#else
>> +#include <ndctl.h>
>> +#endif
>
> We shouldn't be checking __KERNEL__ in uapi headers, something has gone
> wrong if this is necessary.
This header file is shared with userspace libndctl changes as proposed at
https://lore.kernel.org/linux-nvdimm/20200420075556.272174-5-vaibhav@linux.ibm.com/
The definition of "struct nd_cmd_pkg" on which 'struct nd_pdsm_cmd_pkg'
depenends on, is available in different locations in kernel and libndctl
>
>> +
>> +/*
>> + * PDSM Envelope:
>> + *
>> + * The ioctl ND_CMD_CALL transfers data between user-space and kernel via
>> + * 'envelopes' which consists of a header and user-defined payload sections.
>> + * The header is described by 'struct nd_pdsm_cmd_pkg' which expects a
>> + * payload following it and offset of which relative to the struct is provided
>> + * by 'nd_pdsm_cmd_pkg.payload_offset'. *
>> + *
>> + * +-------------+---------------------+---------------------------+
>> + * | 64-Bytes | 8-Bytes | Max 184-Bytes |
>> + * +-------------+---------------------+---------------------------+
>> + * | nd_pdsm_cmd_pkg | |
>> + * |-------------+ | |
>> + * | nd_cmd_pkg | | |
>> + * +-------------+---------------------+---------------------------+
>> + * | nd_family | | |
>> + * | nd_size_out | cmd_status | |
>> + * | nd_size_in | payload_version | PAYLOAD |
>> + * | nd_command | payload_offset -----> |
>> + * | nd_fw_size | | |
>> + * +-------------+---------------------+---------------------------+
>> + *
>> + * PDSM Header:
>> + *
>> + * The header is defined as 'struct nd_pdsm_cmd_pkg' which embeds a
>> + * 'struct nd_cmd_pkg' instance. The PDSM command is assigned to member
>> + * 'nd_cmd_pkg.nd_command'. Apart from size information of the envelope which is
>> + * contained in 'struct nd_cmd_pkg', the header also has members following
>> + * members:
>> + *
>> + * 'cmd_status' : (Out) Errors if any encountered while servicing PDSM.
>> + * 'payload_version' : (In/Out) Version number associated with the payload.
>> + * 'payload_offset' : (In)Relative offset of payload from start of envelope.
>> + *
>> + * PDSM Payload:
>> + *
>> + * The layout of the PDSM Payload is defined by various structs shared between
>> + * papr_scm and libndctl so that contents of payload can be interpreted. During
>> + * servicing of a PDSM the papr_scm module will read input args from the payload
>> + * field by casting its contents to an appropriate struct pointer based on the
>> + * PDSM command. Similarly the output of servicing the PDSM command will be
>> + * copied to the payload field using the same struct.
>> + *
>> + * 'libnvdimm' enforces a hard limit of 256 bytes on the envelope size, which
>> + * leaves around 184 bytes for the envelope payload (ignoring any padding that
>> + * the compiler may silently introduce).
>> + *
>> + * Payload Version:
>> + *
>> + * A 'payload_version' field is present in PDSM header that indicates a specific
>> + * version of the structure present in PDSM Payload for a given PDSM command.
>> + * This provides backward compatibility in case the PDSM Payload structure
>> + * evolves and different structures are supported by 'papr_scm' and 'libndctl'.
>> + *
>> + * When sending a PDSM Payload to 'papr_scm', 'libndctl' should send the version
>> + * of the payload struct it supports via 'payload_version' field. The 'papr_scm'
>> + * module when servicing the PDSM envelope checks the 'payload_version' and then
>> + * uses 'payload struct version' == MIN('payload_version field',
>> + * 'max payload-struct-version supported by papr_scm') to service the PDSM.
>> + * After servicing the PDSM, 'papr_scm' put the negotiated version of payload
>> + * struct in returned 'payload_version' field.
>> + *
>> + * Libndctl on receiving the envelope back from papr_scm again checks the
>> + * 'payload_version' field and based on it use the appropriate version dsm
>> + * struct to parse the results.
>> + *
>> + * Backward Compatibility:
>> + *
>> + * Above scheme of exchanging different versioned PDSM struct between libndctl
>> + * and papr_scm should provide backward compatibility until following two
>> + * assumptions/conditions when defining new PDSM structs hold:
>> + *
>> + * Let T(X) = { set of attributes in PDSM struct 'T' versioned X }
>> + *
>> + * 1. T(X) is a proper subset of T(Y) if X > Y.
>> + * i.e Each new version of PDSM struct should retain existing struct
>> + * attributes from previous version
>> + *
>> + * 2. If an entity (libndctl or papr_scm) supports a PDSM struct T(X) then
>> + * it should also support T(1), T(2)...T(X - 1).
>> + * i.e When adding support for new version of a PDSM struct, libndctl
>> + * and papr_scm should retain support of the existing PDSM struct
>> + * version they support.
>> + */
>> +
>> +#ifndef __packed
>> +#define __packed __attribute__((packed))
>> +#endif
>
> I'm not sure it's kosher to be defining __packed in a uapi header.
>
Similar reason as before. Userspace libndctl doesnt provide a definition
of __packed hence adding it here.
>> +
>> +/* Papr-scm-header + payload expected with ND_CMD_CALL ioctl from libnvdimm */
>> +struct nd_pdsm_cmd_pkg {
>> + struct nd_cmd_pkg hdr; /* Package header containing sub-cmd */
>> + __s32 cmd_status; /* Out: Sub-cmd status returned back */
>> + __u16 payload_offset; /* In: offset from start of struct */
>> + __u16 payload_version; /* In/Out: version of the payload */
>> + __u8 payload[]; /* In/Out: Sub-cmd data buffer */
>> +} __packed;
>> +
>> +/*
>> + * Methods to be embedded in ND_CMD_CALL request. These are sent to the kernel
>> + * via 'nd_pdsm_cmd_pkg.hdr.nd_command' member of the ioctl struct
>> + */
>> +enum papr_scm_pdsm {
>> + PAPR_SCM_PDSM_MIN = 0x0,
>> + PAPR_SCM_PDSM_MAX,
>> +};
>> +
>> +/* Helpers to evaluate the size of PDSM envelope */
>> +/* Calculate the papr_scm-header size */
>> +#define ND_PDSM_ENVELOPE_CONTENT_HDR_SIZE \
>> + (sizeof(struct nd_pdsm_cmd_pkg) - sizeof(struct nd_cmd_pkg))
>> +
>> +/* Given a type calculate envelope-content size (papr_scm-header + payload) */
>> +#define ND_PDSM_ENVELOPE_CONTENT_SIZE(_type_) \
>> + (sizeof(_type_) + ND_PDSM_ENVELOPE_CONTENT_HDR_SIZE)
>
> Those seem unused? Do we really need to make them part of the uapi for
> all time?
This helper macro is used in proposed libndctl changes to calculate returning
payload buffer size from the kernel.
https://lore.kernel.org/linux-nvdimm/20200420075556.272174-7-vaibhav@linux.ibm.com/
>
>> +/* Convert a libnvdimm nd_cmd_pkg to pdsm specific pkg */
>> +static struct nd_pdsm_cmd_pkg *nd_to_pdsm_cmd_pkg(struct nd_cmd_pkg *cmd)
>> +{
>> + return (struct nd_pdsm_cmd_pkg *) cmd;
>> +}
>> +
>> +/* Return the payload pointer for a given pcmd */
>> +static void *pdsm_cmd_to_payload(struct nd_pdsm_cmd_pkg *pcmd)
>
> That should probably be static inline?
Agree, will do.
>
>> +{
>> + if (pcmd->hdr.nd_size_in == 0 && pcmd->hdr.nd_size_out == 0)
>> + return NULL;
>> + else
>> + return (void *)((__u8 *) pcmd + pcmd->payload_offset);
>> +}
>> +
>> +#endif /* _UAPI_ASM_POWERPC_PAPR_SCM_PDSM_H_ */
>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
>> index f8fe579e6f2e..20da1b837017 100644
>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> @@ -15,13 +15,15 @@
>>
>> #include <asm/plpar_wrappers.h>
>> #include <asm/papr_scm.h>
>> +#include <asm/papr_scm_pdsm.h>
>>
>> #define BIND_ANY_ADDR (~0ul)
>>
>> #define PAPR_SCM_DIMM_CMD_MASK \
>> ((1ul << ND_CMD_GET_CONFIG_SIZE) | \
>> (1ul << ND_CMD_GET_CONFIG_DATA) | \
>> - (1ul << ND_CMD_SET_CONFIG_DATA))
>> + (1ul << ND_CMD_SET_CONFIG_DATA) | \
>> + (1ul << ND_CMD_CALL))
>>
>> struct papr_scm_priv {
>> struct platform_device *pdev;
>> @@ -306,16 +308,97 @@ static int papr_scm_meta_set(struct papr_scm_priv *p,
>> return 0;
>> }
>>
>> -int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
>> - unsigned int cmd, void *buf, unsigned int buf_len, int *cmd_rc)
>> +/*
>> + * Validate the inputs args to dimm-control function and return '0' if valid.
>> + * This also does initial sanity validation to ND_CMD_CALL sub-command packages.
>> + */
>> +static int is_cmd_valid(struct nvdimm *nvdimm, unsigned int cmd, void *buf,
>> + unsigned int buf_len)
>> {
>> - struct nd_cmd_get_config_size *get_size_hdr;
>> + unsigned long cmd_mask = PAPR_SCM_DIMM_CMD_MASK;
>> + struct nd_pdsm_cmd_pkg *pkg = nd_to_pdsm_cmd_pkg(buf);
>> struct papr_scm_priv *p;
>>
>> /* Only dimm-specific calls are supported atm */
>> if (!nvdimm)
>> return -EINVAL;
>>
>> + /* get the provider date from struct nvdimm */
>> + p = nvdimm_provider_data(nvdimm);
>> +
>> + if (!test_bit(cmd, &cmd_mask)) {
>> + dev_dbg(&p->pdev->dev, "Unsupported cmd=%u\n", cmd);
>> + return -EINVAL;
>> + } else if (cmd == ND_CMD_CALL) {
>> +
>> + /* Verify the envelope package */
>> + if (!buf || buf_len < sizeof(struct nd_pdsm_cmd_pkg)) {
>> + dev_dbg(&p->pdev->dev, "Invalid pkg size=%u\n",
>> + buf_len);
>> + return -EINVAL;
>> + }
>> +
>> + /* Verify that the PDSM family is valid */
>> + if (pkg->hdr.nd_family != NVDIMM_FAMILY_PAPR_SCM) {
>> + dev_dbg(&p->pdev->dev, "Invalid pkg family=0x%llx\n",
>> + pkg->hdr.nd_family);
>> + return -EINVAL;
>> +
>> + }
>> +
>> + /* We except a payload with all PDSM commands */
>> + if (pdsm_cmd_to_payload(pkg) == NULL) {
>> + dev_dbg(&p->pdev->dev,
>> + "Empty payload for sub-command=0x%llx\n",
>> + pkg->hdr.nd_command);
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + /* Command looks valid */
>> + return 0;
>> +}
>> +
>> +static int papr_scm_service_pdsm(struct papr_scm_priv *p,
>> + struct nd_pdsm_cmd_pkg *call_pkg)
>> +{
>> + /* unknown subcommands return error in packages */
>> + if (call_pkg->hdr.nd_command <= PAPR_SCM_PDSM_MIN ||
>> + call_pkg->hdr.nd_command >= PAPR_SCM_PDSM_MAX) {
>> + dev_dbg(&p->pdev->dev, "Invalid PDSM request 0x%llx\n",
>> + call_pkg->hdr.nd_command);
>> + call_pkg->cmd_status = -EINVAL;
>> + return 0;
>> + }
>> +
>> + /* Depending on the DSM command call appropriate service routine */
>> + switch (call_pkg->hdr.nd_command) {
>> + default:
>> + dev_dbg(&p->pdev->dev, "Unsupported PDSM request 0x%llx\n",
>> + call_pkg->hdr.nd_command);
>> + call_pkg->cmd_status = -ENOENT;
>> + return 0;
>> + }
>> +}
>> +
>> +int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
>> + unsigned int cmd, void *buf, unsigned int buf_len, int *cmd_rc)
>> +{
>> + struct nd_cmd_get_config_size *get_size_hdr;
>> + struct papr_scm_priv *p;
>> + struct nd_pdsm_cmd_pkg *call_pkg = NULL;
>> + int rc;
>> +
>> + /* Use a local variable in case cmd_rc pointer is NULL */
>> + if (cmd_rc == NULL)
>> + cmd_rc = &rc;
>> +
>> + *cmd_rc = is_cmd_valid(nvdimm, cmd, buf, buf_len);
>> + if (*cmd_rc) {
>> + pr_debug("Invalid cmd=0x%x. Err=%d\n", cmd, *cmd_rc);
>> + return *cmd_rc;
>> + }
>> +
>> p = nvdimm_provider_data(nvdimm);
>>
>> switch (cmd) {
>> @@ -336,13 +419,19 @@ int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
>> *cmd_rc = papr_scm_meta_set(p, buf);
>> break;
>>
>> + case ND_CMD_CALL:
>> + call_pkg = nd_to_pdsm_cmd_pkg(buf);
>> + *cmd_rc = papr_scm_service_pdsm(p, call_pkg);
>> + break;
>> +
>> default:
>> - return -EINVAL;
>> + dev_dbg(&p->pdev->dev, "Unknown command = %d\n", cmd);
>> + *cmd_rc = -EINVAL;
>> }
>>
>> dev_dbg(&p->pdev->dev, "returned with cmd_rc = %d\n", *cmd_rc);
>>
>> - return 0;
>> + return *cmd_rc;
>> }
>>
>> static inline int papr_scm_node(int node)
>> diff --git a/include/uapi/linux/ndctl.h b/include/uapi/linux/ndctl.h
>> index de5d90212409..99fb60600ef8 100644
>> --- a/include/uapi/linux/ndctl.h
>> +++ b/include/uapi/linux/ndctl.h
>> @@ -244,6 +244,7 @@ struct nd_cmd_pkg {
>> #define NVDIMM_FAMILY_HPE2 2
>> #define NVDIMM_FAMILY_MSFT 3
>> #define NVDIMM_FAMILY_HYPERV 4
>> +#define NVDIMM_FAMILY_PAPR_SCM 5
>
> Would like an ack from Dan for that change.
>
Agree
> cheers
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
~ Vaibhav
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox