* [PATCH v7 01/11] arm: traps: use only least 32 bits of fid in PSCI handler
From: Volodymyr Babchuk @ 2017-10-04 21:00 UTC (permalink / raw)
To: xen-devel
Cc: Edgar E . Iglesias, Julien Grall, Stefano Stabellini,
Volodymyr Babchuk
In-Reply-To: <1507150827-7858-1-git-send-email-volodymyr_babchuk@epam.com>
According to SMCCC (ARM DEN 0028B, page 12), function id is
stored in least 32 bits of r0/x0 register:
The least significant 32-bits are used, and the most significant
32-bits are zero. Implementations must ignore the least significant
bits.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
---
xen/arch/arm/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 701fdc8..0cff83e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1463,14 +1463,14 @@ static void do_debug_trap(struct cpu_user_regs *regs, unsigned int code)
#endif
/* helper function for checking arm mode 32/64 bit */
-static inline int psci_mode_check(struct domain *d, register_t fid)
+static inline int psci_mode_check(struct domain *d, uint32_t fid)
{
return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
}
static void do_trap_psci(struct cpu_user_regs *regs)
{
- register_t fid = PSCI_ARG(regs,0);
+ uint32_t fid = PSCI_ARG32(regs,0);
/* preloading in case psci_mode_check fails */
PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v7 00/11] Handle SMCs and HVCs in conformance with SMCCC
From: Volodymyr Babchuk @ 2017-10-04 21:00 UTC (permalink / raw)
To: xen-devel
Cc: Edgar E . Iglesias, Julien Grall, Stefano Stabellini,
Volodymyr Babchuk
Hello all,
v7:
* Added new patch "arm: traps: use only least 32 bits of fid in PSCI handler"
It fixes fid usage on 64 bit machines. Now only least 32 bits are used,
as required by SMCCC. It is a separate change, so it can be back-ported.
* Fixed the same issue in "arm: traps: handle PSCI calls inside `vsmc.c`"
* Reworked definition of XEN_DEFINE_UUID() for C90/C99 compilers
* Fixed message for "public: xen.h: add definitions for UUID handling":
invalid usage for XEN_DEFINE_UUID() was provided
* Fixed formatting in "arm: PSCI: use definitions provided by asm/smccc.h"
As series [1] for traps.c cleanup were merged, there are no dependencies
for this patch series.
---
v6:
* XEN_DEFINE_UUID() now is in two variants: strict ANSI C and GCC,
more in corresponding patch
* added/reworked helpers that return information about SMCCC service
* fixed bug with compilation of "arm: traps: handle PSCI calls inside `vsmc.c`"
Next patch fixed that bug anyways, but xen tree would be broken at that
exact point
* More changes are described in corresponding patches
This patch series still depend on Julien's patches for traps.c cleanup ([1]).
---
v5:
* Patches that add end enable XENFEAT_ARM_SMCCC_supported were
squashed together
* All other chages are described in corresponding patches
This patch series still depend on Julien's patches for traps.c cleanup ([1]).
---
v4:
* Added patch with public definitiod for xen_uuid_t
* Added patch with immediate value mask for SMC, HVC and SVC
* Added patch with header smccc.h (generic SMCCC definitions)
* Added patches that add and enable XENFEAT_ARM_SMCCC_supported
* Removed patch that added inject_undef_exception() and friends
to the processor.h
This patch series depends on Julien's patches for traps.c cleanup ([1]).
There was discussion about SMCCC bindings (e.g. how to tell guest, that
it can safelly call SMCCC routines). As temporary solution, we'll
provide XENFEAT_ARM_SMCCC_supported feature. More generic solution
is still under discussion.
[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg117839.html
---
v3:
This is third version. Instead of 4 patches, there are 7 now.
As part of the series, I make some functions in traps.c
available globally, moved SMC conditional check into
separate patch, changed how PSCI functiond numbers are defined.
---
v2:
This is second version. Instead of 2 patches, there are 4 now.
I have divided PSCI patch into two: one changes how PSCI
code accesses registers and second one moves PSCI code with
new accessors to vsmc.c.
Also I had removed redundant 64 bit mode check in PSCI code, as it
does not conforms with SMCCC.
---
v1:
This patch series adds a generic way to handle standard calls
that are defined in ARM SMC calling convention (SMCCC).
First patch adds generic handler and second one moves PSCI
handling code to that generic handler.
With this patch series guest can query hypervisor in a standard
way to determine which virtualization system is used.
The same applies to PSCI calls. Now guest can tell if PSCI calls
are handled by hypervisor or by, say, ARM TF.
Also those patches are needed for upcoming TEE support.
---
Volodymyr Babchuk (11):
arm: traps: use only least 32 bits of fid in PSCI handler
arm: traps: use generic register accessors in the PSCI code
arm: traps: check if SMC was conditional before handling it
public: xen.h: add definitions for UUID handling
arm: processor.h: add definition for immediate value mask
arm: add SMCCC protocol definitions
arm: smccc: handle SMCs according to SMCCC
arm: traps: handle PSCI calls inside `vsmc.c`
arm: PSCI: use definitions provided by asm/smccc.h
arm: vsmc: remove 64 bit mode check in PSCI handler
public: add and enable XENFEAT_ARM_SMCCC_supported feature
xen/arch/arm/Makefile | 1 +
xen/arch/arm/platforms/seattle.c | 4 +-
xen/arch/arm/psci.c | 10 +-
xen/arch/arm/traps.c | 132 +------------
xen/arch/arm/vsmc.c | 356 ++++++++++++++++++++++++++++++++++++
xen/common/kernel.c | 3 +
xen/include/asm-arm/processor.h | 3 +
xen/include/asm-arm/psci.h | 43 ++---
xen/include/asm-arm/smccc.h | 105 +++++++++++
xen/include/asm-arm/traps.h | 4 +
xen/include/public/arch-arm/smccc.h | 66 +++++++
xen/include/public/features.h | 3 +
xen/include/public/xen.h | 33 ++++
13 files changed, 603 insertions(+), 160 deletions(-)
create mode 100644 xen/arch/arm/vsmc.c
create mode 100644 xen/include/asm-arm/smccc.h
create mode 100644 xen/include/public/arch-arm/smccc.h
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: fsi: Add OCC documentation
From: Rob Herring @ 2017-10-04 20:59 UTC (permalink / raw)
To: Eddie James
Cc: linux-kernel, gregkh, devicetree, mark.rutland, bradleyb, jk,
cbostic, joel, andrew, Edward A. James
In-Reply-To: <1506114362-492-5-git-send-email-eajames@linux.vnet.ibm.com>
On Fri, Sep 22, 2017 at 04:06:00PM -0500, Eddie James wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
>
> Document the bindings for the P9 OCC device. OCC devices are accessed
> through the SBEFIFO.
>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> ---
> Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>
> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
> new file mode 100644
> index 0000000..bcaefc9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
> @@ -0,0 +1,15 @@
> +Device-tree bindings for P9 On-Chip Controller
> +----------------------------------------------
> +
> +Required properties:
> + - compatible = "ibm,p9-occ";
> +
> +Optional properties:
> + - reg = <processor index>; : Index for the processor this OCC is on.
Need to say what this must be a child of.
> +
> +Examples:
> +
> + occ@1 {
> + compatible = "ibm,p9-occ";
> + reg = <1>;
> + };
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: fsi: Add OCC documentation
From: Rob Herring @ 2017-10-04 20:59 UTC (permalink / raw)
To: Eddie James
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
bradleyb-r5pk2Da7Bxt8sGd51Jp2sdBPR1lH4CV8,
jk-mnsaURCQ41sdnm+yROfE0A,
cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
joel-U3u1mxZcP9KHXe+LvDLADg, andrew-zrmu5oMJ5Fs, Edward A. James
In-Reply-To: <1506114362-492-5-git-send-email-eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Fri, Sep 22, 2017 at 04:06:00PM -0500, Eddie James wrote:
> From: "Edward A. James" <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Document the bindings for the P9 OCC device. OCC devices are accessed
> through the SBEFIFO.
>
> Signed-off-by: Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
>
> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
> new file mode 100644
> index 0000000..bcaefc9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt
> @@ -0,0 +1,15 @@
> +Device-tree bindings for P9 On-Chip Controller
> +----------------------------------------------
> +
> +Required properties:
> + - compatible = "ibm,p9-occ";
> +
> +Optional properties:
> + - reg = <processor index>; : Index for the processor this OCC is on.
Need to say what this must be a child of.
> +
> +Examples:
> +
> + occ@1 {
> + compatible = "ibm,p9-occ";
> + reg = <1>;
> + };
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [refpolicy] [PATCH v5] fc_sort: memory leakages
From: Guido Trentalancia @ 2017-10-04 20:59 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <CAFftDdq1u_84v4xA2+3WeK00PUPwg3+SQfcH+_ced0dd+LG8rw@mail.gmail.com>
On Wed, 04/10/2017 at 11.05 -0700, William Roberts wrote:
> On Wed, Oct 4, 2017 at 2:41 AM, Guido Trentalancia via refpolicy
> <refpolicy@oss.tresys.com> wrote:
> > Hello Christopher.
> >
> > The latest version (v5) has been tested not only with valgrind but
> > also with the Clang static analyzer and none of them reports any
> > error.
> >
> > The Clang analyzer is the same one that was mentioned in the
> > original bug report, I have used the latest version 5.0.
> >
> > I hope it helps.
> >
> > Regards,
> >
> > Guido
> >
> > Il 03 ottobre 2017 03:21:38 CEST, Chris PeBenito <pebenito@ieee.org
> > > ha scritto:
> > > On 09/30/2017 06:44 PM, Guido Trentalancia via refpolicy wrote:
> > > > Avoid memory leakages in the fc_sort executable (now passes
> > > > all valgrind AND Clang static analyzer tests fine).
> > > >
> > > > Some NULL pointer checks with or without associated error
> > > > reporting.
> > > >
> > > > Some white space and comment formatting fixes.
> > > >
> > > > Optimization: avoid unnecessary operations (unnecessary
> > > > memory allocation/deallocation and list copying).
> > > >
> > > > Reverts 7821eb6f37d785ab6ac3bbdc39282c799ad22393 as such
> > > > trick is no longer needed, given that all memory leakages
> > > > have now been fixed.
> > > >
> > > > This is the fifth version of this patch. Please do not use
> > > > the first version as it introduces a serious bug.
> > > >
> > > > For reference, the original issue reported by the Cland
> > > > static analyzer is as follows:
> > > >
> > > > support/fc_sort.c:494:6: warning: Potential leak of memory
> > > > pointed to by 'head'
> > > > malloc(sizeof(file_context_bucket_t));
> > >
> > > Bill, did your guys run this through their static analyzer? I'm
> > > inclined
> > > to merge this.
[...]
>
> FYI Ill be on vacation for a week, so I won't be reachable on this
> matter. Thanks for the patch!
>
> Bill
Thanks very much for reviewing it Bill ! I have now fixed the
whitespace as suggested by "git diff --check".
The new patch version will follow shortly...
Regards,
Guido
^ permalink raw reply
* Mimic timeline
From: Sage Weil @ 2017-10-04 20:58 UTC (permalink / raw)
To: ceph-devel, ceph-maintainers, ceph-users
Hi everyone,
After further discussion we are targetting 9 months for Mimic 13.2.0:
- Mar 16, 2018 feature freeze
- May 1, 2018 release
Upgrades for Mimic will be from Luminous only (we've already made that a
required stop), but we plan to allow Luminous -> Nautilus too (and Mimic
-> O).
Nautilus is planned for 9 months after that... Feb 1, 2019.
Thanks, everyone, for your input! We hope this works well enough for
everyone, and that additional predictability makes your planning easier.
sage
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/3] qom: update doc comment for type_register[_static]()
From: Eduardo Habkost @ 2017-10-04 20:58 UTC (permalink / raw)
To: Igor Mammedov; +Cc: qemu-devel, peter.maydell
In-Reply-To: <1507111682-66171-2-git-send-email-imammedo@redhat.com>
On Wed, Oct 04, 2017 at 12:08:00PM +0200, Igor Mammedov wrote:
> type_register()/type_register_static() functions in current impl.
> can't fail returning 0, also none of the users check for error
> so update doc comment to reflect current behaviour.
>
> Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
I'm queueing it on machine-next.
--
Eduardo
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: fsi: Add SBEFIFO documentation
From: Rob Herring @ 2017-10-04 20:58 UTC (permalink / raw)
To: Eddie James
Cc: linux-kernel, gregkh, devicetree, mark.rutland, bradleyb, jk,
cbostic, joel, andrew, Edward A. James
In-Reply-To: <1506114362-492-2-git-send-email-eajames@linux.vnet.ibm.com>
On Fri, Sep 22, 2017 at 04:05:57PM -0500, Eddie James wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
>
> Document the bindings for the SBE CFAM device. SBE devices are
> located on a CFAM off an FSI bus.
>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> ---
> .../devicetree/bindings/fsi/ibm,p9-sbefifo.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt
>
> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt
> new file mode 100644
> index 0000000..07fbf29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt
> @@ -0,0 +1,20 @@
> +Device-tree bindings for P9 SBEFIFO CFAM device
> +-----------------------------------------------
> +
> +Required properties:
> + - reg = < address size > : FSI CFAM address for the SBE engine
> + and address space size.
compatible?
> +
> +Optional properties:
> + - <child nodes> : Devices that are accessible through
> + the SBEFIFO.
You need some sort of definition what's in the child nodes.
> +
> +Examples:
> +
> + sbefifo@2400 {
> + reg = < 0x2400 0x400 >;
Need #{address,size}-cells here.
> +
> + occ@1 {
Need a reg property here and you need to define what reg represents.
> + ...
> + };
> + };
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: fsi: Add SBEFIFO documentation
From: Rob Herring @ 2017-10-04 20:58 UTC (permalink / raw)
To: Eddie James
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
bradleyb-r5pk2Da7Bxt8sGd51Jp2sdBPR1lH4CV8,
jk-mnsaURCQ41sdnm+yROfE0A,
cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
joel-U3u1mxZcP9KHXe+LvDLADg, andrew-zrmu5oMJ5Fs, Edward A. James
In-Reply-To: <1506114362-492-2-git-send-email-eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Fri, Sep 22, 2017 at 04:05:57PM -0500, Eddie James wrote:
> From: "Edward A. James" <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Document the bindings for the SBE CFAM device. SBE devices are
> located on a CFAM off an FSI bus.
>
> Signed-off-by: Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/fsi/ibm,p9-sbefifo.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt
>
> diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt
> new file mode 100644
> index 0000000..07fbf29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt
> @@ -0,0 +1,20 @@
> +Device-tree bindings for P9 SBEFIFO CFAM device
> +-----------------------------------------------
> +
> +Required properties:
> + - reg = < address size > : FSI CFAM address for the SBE engine
> + and address space size.
compatible?
> +
> +Optional properties:
> + - <child nodes> : Devices that are accessible through
> + the SBEFIFO.
You need some sort of definition what's in the child nodes.
> +
> +Examples:
> +
> + sbefifo@2400 {
> + reg = < 0x2400 0x400 >;
Need #{address,size}-cells here.
> +
> + occ@1 {
Need a reg property here and you need to define what reg represents.
> + ...
> + };
> + };
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v4 2/2] vl: Deprecate auto-loading of qemu.conf
From: Eduardo Habkost @ 2017-10-04 20:57 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Paolo Bonzini, qemu-devel
In-Reply-To: <20171004122308.GI4760@localhost.localdomain>
On Wed, Oct 04, 2017 at 09:23:08AM -0300, Eduardo Habkost wrote:
> On Wed, Oct 04, 2017 at 07:42:17AM +0200, Markus Armbruster wrote:
> > Eduardo Habkost <ehabkost@redhat.com> writes:
> >
> > > In case there were options set in the default config file, print
> > > a warning so users can update their scripts.
> > >
> > > If somebody wants to keep the config file as-is, avoid the
> > > warning and use a command-line that will work in future QEMU
> > > versions, they can use:
> > >
> > > $QEMU -no-user-config -readconfig /etc/qemu/qemu.conf
> > >
> > > I was going to include the suggestion in the warning message, but
> > > I thought it could make it more confusing. The suggestion is
> > > documented in qemu-doc.texi.
> > >
> > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > ---
> > > Changes v3 -> v4:
> > > * Use warn_report() instead of error_report("warning: ...")
> > > (Eric Blake)
> > > * Document as a deprecated feature in qemu-doc.texi
> > > * Update subject line
> > > (was: "vl: Print warning when a default config file is loaded")
> > >
> > > Changes v2 -> v3:
> > > * Rebase (no code changes)
> > > * Commit message update: suggest -no-user-config
> > > ---
> > > vl.c | 6 ++++++
> > > qemu-doc.texi | 8 ++++++++
> > > 2 files changed, 14 insertions(+)
> > >
> > > diff --git a/vl.c b/vl.c
> > > index 3fed457921..1b0ecdf74e 100644
> > > --- a/vl.c
> > > +++ b/vl.c
> > > @@ -3066,6 +3066,12 @@ static int qemu_read_default_config_file(void)
> > > return ret;
> > > }
> > >
> > > + if (ret > 0) {
> > > + loc_set_none();
> >
> > Sure we need this here?
>
> IIRC we needed it in the original version, but I don't remember
> why. I will check this.
This is the result if we don't clear error location state:
$ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -display none -device foobar
qemu-system-x86_64: -device foobar: warning: Future QEMU versions won't load /usr/local/etc/qemu/qemu.conf automatically
^^^^^^^^^^^^^^
However, it's probably better to do this right after the loop,
just like we already do in the second option parsing loop:
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
diff --git a/vl.c b/vl.c
index f9acc17c01..a8fd247d71 100644
--- a/vl.c
+++ b/vl.c
@@ -3067,7 +3067,6 @@ static int qemu_read_default_config_file(void)
}
if (ret > 0) {
- loc_set_none();
warn_report("Future QEMU versions won't load %s automatically",
CONFIG_QEMU_CONFDIR "/qemu.conf");
}
@@ -3224,6 +3223,11 @@ int main(int argc, char **argv, char **envp)
}
}
}
+ /*
+ * Clear error location left behind by the loop.
+ * Best done right after the loop. Do not insert code here!
+ */
+ loc_set_none();
if (userconfig) {
if (qemu_read_default_config_file() < 0) {
--
Eduardo
^ permalink raw reply related
* Re: [Xenomai] rt_task_set_affinity causes hang
From: Jackson Jones @ 2017-10-04 20:57 UTC (permalink / raw)
To: Xenomai
In-Reply-To: <CANXti+dsa30duyCYtuiN6OWvg+AoknE_mE8qzUME3wqemzv+ag@mail.gmail.com>
I am running on an i.MX6 quad core. It is running Debian Jessie with an
NXP/Varscite kernel 4.1.15. So it is a 32bit ARM platform like the Pi.
What I meant by freeze is it hangs the entire OS/SoC, a hard reset is the
only way out. I will check the status of all the return codes (I did not
write this example but I should have cleaned it up when the problem was
tossed to me).
On Wed, Oct 4, 2017 at 1:03 PM, Piotr Piorkowski <qba100@gmail.com> wrote:
> I have the same problem on Raspberry Pi 3.
> Its look as freeze platform. Under xenomai 3.0.3 programs works fine.
>
> Piotr
>
> 2017-10-04 19:49 GMT+02:00 Philippe Gerum <rpm@xenomai.org>:
>
>> On 10/04/2017 05:05 AM, Jackson Jones wrote:
>> > Below is an example program that runs fine under xenomai-3.0.3. Under
>> 3.0.5
>> > it hangs when rt_task_set_affinity() is called.
>> >
>> > Any ideas?
>> >
>>
>> - which CPU architecture is your app running on?
>>
>> - what do you mean by "it hangs"? Sleeps with no action with the rest of
>> the system still ok, or hard lockup of the whole SoC?
>>
>> - rt_task_sleep() returns a status code; if the application does not
>> care about it, it might enter a tight loop whenever the call fails, for
>> whatever reason. That status may help determining such reason.
>>
>> CONFIG_XENO_OPT_WATCHDOG is usually helpful for detecting runaway
>> threads, preventing hard lockups. --
>> Philippe.
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> https://xenomai.org/mailman/listinfo/xenomai
>>
>
>
^ permalink raw reply
* Re: [PATCH] xen-guest-image-minimal: remove lines modifying DISTRO_FEATURES
From: Bruce Ashfield @ 2017-10-04 20:55 UTC (permalink / raw)
To: Christopher Clark; +Cc: meta-virtualization@yoctoproject.org, Doug Goldstein
In-Reply-To: <1507057406-19771-1-git-send-email-christopher.w.clark@gmail.com>
merged.
Bruce
On Tue, Oct 3, 2017 at 3:03 PM, <christopher.w.clark@gmail.com> wrote:
> From: Christopher Clark <christopher.w.clark@gmail.com>
>
> Remove recipe lines modifying DISTRO_FEATURES that were intended to
> simplify the non-x86 x11 image dependencies, but did not.
>
> Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
> Reported-by: Mark Hatle <mark.hatle@windriver.com>
> ---
>
> recipes-extended/images/xen-guest-image-minimal.bb | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/recipes-extended/images/xen-guest-image-minimal.bb b/recipes-extended/images/xen-guest-image-minimal.bb
> index bca6017..d311eae 100644
> --- a/recipes-extended/images/xen-guest-image-minimal.bb
> +++ b/recipes-extended/images/xen-guest-image-minimal.bb
> @@ -13,11 +13,6 @@ IMAGE_INSTALL += "${@bb.utils.contains('IMAGE_FEATURES', 'x11', ' xf86-video-fbd
> IMAGE_INSTALL_append_x86-64 = "${@bb.utils.contains('IMAGE_FEATURES', 'x11', ' xf86-video-vesa', '', d)}"
> IMAGE_INSTALL_append_x86 = "${@bb.utils.contains('IMAGE_FEATURES', 'x11', ' xf86-video-vesa', '', d)}"
>
> -# When xf86-video-vesa is not present, add opengl and don't require wayland:
> -DISTRO_FEATURES_append = "${@bb.utils.contains('IMAGE_FEATURES', 'x11', \
> - bb.utils.contains('IMAGE_INSTALL', 'xf86-video-vesa', '', ' opengl', d), '', d)}"
> -DISTRO_FEATURES_remove = "${@bb.utils.contains('IMAGE_INSTALL', 'xf86-video-vesa', '', 'wayland', d)}"
> -
> REQUIRED_DISTRO_FEATURES += "${@bb.utils.contains('IMAGE_FEATURES', 'x11', ' x11', '', d)} xen"
>
> LICENSE = "MIT"
> --
> 2.7.4
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply
* Re: [PATCH 2/2] runc-opencontainers: go.bbclass compile fixes
From: Bruce Ashfield @ 2017-10-04 20:55 UTC (permalink / raw)
To: Paul Barker; +Cc: meta-virtualization@yoctoproject.org
In-Reply-To: <1507113626-3022-3-git-send-email-pbarker@toganlabs.com>
On Wed, Oct 4, 2017 at 6:40 AM, Paul Barker <pbarker@toganlabs.com> wrote:
> These fixes are needed due to updates to go.bbclass in oe-core. See commit
> 01a8d4537012ad93dc8510e9b762acdc8c4536c7 for more information.
Yah, same thing we did for the docker variant. This is now merged.
Bruce
>
> Signed-off-by: Paul Barker <pbarker@toganlabs.com>
> ---
> recipes-containers/runc/runc-opencontainers_git.bb | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-containers/runc/runc-opencontainers_git.bb b/recipes-containers/runc/runc-opencontainers_git.bb
> index 940ae95..902a93d 100644
> --- a/recipes-containers/runc/runc-opencontainers_git.bb
> +++ b/recipes-containers/runc/runc-opencontainers_git.bb
> @@ -6,9 +6,11 @@ RUNC_VERSION = "1.0.0-rc4"
> PROVIDES += "virtual/runc"
> RPROVIDES_${PN} = "virtual/runc"
>
> +GO_IMPORT = "import"
> +
> do_compile_prepend() {
> # Go looks in a src directory under any directory in GOPATH but
> # runc-opencontainers uses 'vendor' instead of 'vendor/src'. We can fix
> # this with a symlink.
> - ln -sfn . "${S}/vendor/src"
> + ln -sfn . "${S}/src/import/vendor/src"
> }
> --
> 2.7.4
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
^ permalink raw reply
* [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
From: Rob Clark @ 2017-10-04 20:54 UTC (permalink / raw)
To: u-boot
In-Reply-To: <d9f8f47f-de87-1995-caa0-51108b1e699e@gmx.de>
On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> Shell.efi uses this, and supporting color attributes makes things look
>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>> Not all colors have a perfect match, but spec just says "Devices
>> supporting a different number of text colors are required to emulate the
>> above colors to the best of the device’s capabilities".
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>> ---
>> include/efi_api.h | 29 +++++++++++++++++++++++++++++
>> lib/efi_loader/efi_console.c | 30 ++++++++++++++++++++++++++++++
>> 2 files changed, 59 insertions(+)
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 87c8ffe68e..3cc1dbac2e 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>> 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>
>> +#define EFI_BLACK 0x00
>> +#define EFI_BLUE 0x01
>> +#define EFI_GREEN 0x02
>> +#define EFI_CYAN 0x03
>> +#define EFI_RED 0x04
>> +#define EFI_MAGENTA 0x05
>> +#define EFI_BROWN 0x06
>> +#define EFI_LIGHTGRAY 0x07
>> +#define EFI_BRIGHT 0x08
>> +#define EFI_DARKGRAY 0x08
>> +#define EFI_LIGHTBLUE 0x09
>> +#define EFI_LIGHTGREEN 0x0a
>> +#define EFI_LIGHTCYAN 0x0b
>> +#define EFI_LIGHTRED 0x0c
>> +#define EFI_LIGHTMAGENTA 0x0d
>> +#define EFI_YELLOW 0x0e
>> +#define EFI_WHITE 0x0f
>> +#define EFI_BACKGROUND_BLACK 0x00
>> +#define EFI_BACKGROUND_BLUE 0x10
>> +#define EFI_BACKGROUND_GREEN 0x20
>> +#define EFI_BACKGROUND_CYAN 0x30
>> +#define EFI_BACKGROUND_RED 0x40
>> +#define EFI_BACKGROUND_MAGENTA 0x50
>> +#define EFI_BACKGROUND_BROWN 0x60
>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>
> Will we ever use these constants?
>
possibly not, but it is useful to understand what is going on with
efi->ansi mapping, so I would prefer to keep them.
>
> Where are the comments explaining the defines below?
>
>> +
>> +#define EFI_ATTR_FG(attr) ((attr) & 0x0f)
>
> This saves 8 entries in the table below.
> +#define EFI_ATTR_FG(attr) ((attr) & 0x07)
>
>> +#define EFI_ATTR_BG(attr) (((attr) >> 4) & 0x7)
>
> Add
> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>
>> +
>> struct efi_simple_text_output_protocol {
>> void *reset;
>> efi_status_t (EFIAPI *output_string)(
>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>> index 2e13fdc096..fcd65ca488 100644
>> --- a/lib/efi_loader/efi_console.c
>> +++ b/lib/efi_loader/efi_console.c
>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>> return EFI_EXIT(EFI_SUCCESS);
>> }
>>
>> +static const struct {
>> + unsigned fg;
>> + unsigned bg;
>> +} color[] = {
>> + { 30, 40 }, /* 0: black */
>> + { 34, 44 }, /* 1: blue */
>> + { 32, 42 }, /* 2: green */
>> + { 36, 46 }, /* 3: cyan */
>> + { 31, 41 }, /* 4: red */
>> + { 35, 45 }, /* 5: magenta */
>> + { 30, 40 }, /* 6: brown, map to black */
>
> This should be { 33, 43 }
>
>> + { 37, 47 }, /* 7: light grey, map to white */
>
> The entries below are redundant.
>
>> + { 37, 47 }, /* 8: bright, map to white */
>> + { 34, 44 }, /* 9: light blue, map to blue */
>> + { 32, 42 }, /* A: light green, map to green */
>> + { 36, 46 }, /* B: light cyan, map to cyan */
>> + { 31, 41 }, /* C: light red, map to red */
>> + { 35, 45 }, /* D: light magenta, map to magenta */
>> + { 33, 43 }, /* E: yellow */
>> + { 37, 47 }, /* F: white */
>> +};
>> +
I'm not totally convinced about mapping extra colors that UEFI defines
to bold.. unless you have some example of prior-art for this on other
platforms.
There are ansi extensions that allow for more colors, we could perhaps
map the extra EFI colors to the base sequence (presumably more widely
supported) followed by the extended sequence (which presumably not all
terminal emulators support).. I'm not sure if it is worth the effort.
The current patch implements something that is at least fairly
reasonable and within the bounds of what the spec says (ie. "Devices
supporting a different number of text colors are required to emulate
the above colors to the best of the device’s capabilities.")
BR,
-R
>
> No function without a comment explaining the parameters.
>
>> static efi_status_t EFIAPI efi_cout_set_attribute(
>> struct efi_simple_text_output_protocol *this,
>> unsigned long attribute)
>> {
>> + unsigned fg = EFI_ATTR_FG(attribute);
>> + unsigned bg = EFI_ATTR_BG(attribute);
>
> Use unsigned int.
>
>> +
>> EFI_ENTRY("%p, %lx", this, attribute);
>>
>> + if (attribute)
>
> Attribute 0 should be black on black. No need for any if here.
yeah, except in practice this results in unreadable black on black
display.. I debugged my way through this the hard way. The spec
doesn't make it clean, but in practice attribute==0 means to go back
to white on black.
BR,
-R
>> + printf(ESC"[%u;%um", color[fg].fg, color[bg].bg);
>
> Use bold for light colors.
>
> unsigned int bold;
> if (EFI_ATTRIB_BOLD(attr))
> bold = 1;
> else
> bold = 22;
>
>
> printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg)
>
> Best regards
>
> Heinrich
>
>> + else
>> + printf(ESC"[37;40m");
>
>
>> +
>> /* Just ignore attributes (colors) for now */
>> return EFI_EXIT(EFI_UNSUPPORTED);
>> }
>>
>
^ permalink raw reply
* Re: [PATCH] drm/i915: Transform whitelisting WAs into a simple reg write
From: Oscar Mateo @ 2017-10-04 20:54 UTC (permalink / raw)
To: Chris Wilson, Mika Kuoppala, intel-gfx
In-Reply-To: <150712303434.27301.463227499194874418@mail.alporthouse.com>
On 10/04/2017 06:17 AM, Chris Wilson wrote:
> Quoting Mika Kuoppala (2017-10-04 13:39:13)
>> Oscar Mateo <oscar.mateo@intel.com> writes:
>>
>>> RING_FORCE_TO_NONPRIV registers do not live in the logical context. They are simply
>>> global privileged MMIO registers that happen to be powercontext saved and restored
>>> (meaning only they can survive RC6). Therefore, there is absolutely no need to save
>>> them so that they can be restored everytime we create a new logical context.
>>>
>>> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
>>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>>> ---
>>> drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
>>> index a28e2a8..a75f5e8 100644
>>> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>>> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>>> @@ -845,8 +845,8 @@ static int wa_ring_whitelist_reg(struct intel_engine_cs *engine,
>>> if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
>>> return -EINVAL;
>>>
>>> - WA_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
>>> - i915_mmio_reg_offset(reg));
>>> + I915_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
>>> + i915_mmio_reg_offset(reg));
>> #define WA_WRITE should also been removed as it is clearly
>> dangerous. Chris pointed out that anything with nonmasked access
>> is not part of context image, and this seems to hold true in
>> atleast with current cases.
>>
>> But removing of define can be a followup.
> I've picked up this patch and I'll squash in the -WA_WRITE into the
> removal of WA_SET_BIT and push all 3 patches at once (when the shards
> report back).
>
> Thanks for the patch, review, testing, debate and keep having fun.
> -Chris
We can also remove RING_MAX_NONPRIV_SLOTS from here:
#define I915_MAX_WA_REGS (16 + RING_MAX_NONPRIV_SLOTS)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH RFC] gpio: of: document gpio-init nodes
From: Rob Herring @ 2017-10-04 20:53 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Linus Walleij, Mark Rutland, linux-gpio, devicetree, kernel
In-Reply-To: <20170922204138.29951-1-u.kleine-koenig@pengutronix.de>
On Fri, Sep 22, 2017 at 10:41:38PM +0200, Uwe Kleine-König wrote:
> Sometimes it is desirable to define a "safe" configuration for a GPIO in
> the device tree but let the operating system later still make use of
> this pin.
>
> This might for example be useful to initially configure a debug pin that
> is usually unconnected as output to prevent floating until it is used
> later.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> this picks up a discussion that pops up now and then with our customers.
>
> Last time I discussed this topic with Linus Walleij my suggestion was to
> merge this usecase with gpio-hogs, but he wasn't happy with it because
> hogging implies that the pin is not free for other usage and he
> suggested to use "gpio-init" instead.
>
> Maybe it's arguable if this "initial configuration" belongs into the
> device tree, but IMHO defining a "safe configuration" should have a
> place and the requirements are identical. This isn't implied by the name
> however, but I don't have a better idea for a different name.
It can be argued that by the time the kernel boots, it is way to late to
configure pins to a safe state. Of course, even secure world reads the
DT these days (or are at least talking about doing so). Still any s/w
handling this could be too slow to get to a safe state.
Maybe "optimal default" state would be more accurate.
>
> Thinking further (which was also discussed last time) it would also be
> nice to restrict usage. For example that a given pin that has
> "output-low" as its safe setting might be configured later als high
> output but not as input. Maybe:
I can't imagine that an output can't be an input. Regardless, what
you're describing is constraints and that seems like a whole other
problem than default/initial state.
Plus, for constraints I'd think we want this done at the pin level, not
GPIO. And we kind of already have that with pin states.
> companion-reset {
> gpio-somethingwithsafe;
> gpios = <12 0>;
"gpios" is already a defined property with a type (phandle + args). dtc
checks for this now though gpio-hogs is already one exception, and I
don't want to add another. Maybe it could be generalized to be allowed
when the parent is a gpio-controller, but really I'd like to avoid this
pattern from spreading.
> output-low;
> fixed-direction;
> };
>
> (Conceptually we would have a hog then when also adding "fixed-value".)
>
> I'm not sure the early configuration should be implemented in Linux. I'd
> target the bootloader for that instead, still having the blessing of a
> binding document would be great.
>
> I look forward to your comments and ideas.
>
> Best regards
> Uwe
>
> Documentation/devicetree/bindings/gpio/gpio.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 802402f6cc5d..849d620cee4d 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -207,6 +207,11 @@ configuration.
> Optional properties:
> - line-name: The GPIO label name. If not present the node name is used.
>
> +Similar to hogging above GPIOs can be initialized to a certain configuration
> +only which compared to hogs doesn't prevent the operating system to change the
> +pin later. The syntax is similar to hog definitons, the difference is only that
> +the identifying property is "gpio-init" instead of "gpio-hog".
> +
> Example of two SOC GPIO banks defined as gpio-controller nodes:
>
> qe_pio_a: gpio-controller@1400 {
> @@ -221,6 +226,12 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
> output-low;
> line-name = "foo-bar-gpio";
> };
> +
> + companion-reset {
> + gpio-init;
> + gpios = <12 0>;
> + output-low;
> + };
> };
>
> qe_pio_e: gpio-controller@1460 {
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v2 5/6] iio: adc: mcp320x: Add support for mcp3550/1/3
From: Jonathan Cameron @ 2017-10-04 20:53 UTC (permalink / raw)
To: Lukas Wunner, Jonathan Cameron
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Mathias Duckeck, Phil Elwell, Oskar Andero, Andrea Galbusera,
Akinobu Mita, Manfred Schlaegl, Michael Welling, Soeren Andersen,
linux-iio
In-Reply-To: <20171004195037.GB9195@wunner.de>
On 4 October 2017 20:50:37 BST, Lukas Wunner <lukas@wunner=2Ede> wrote:
>On Sun, Sep 10, 2017 at 05:15:14PM +0100, Jonathan Cameron wrote:
>> On Sat, 9 Sep 2017 20:32:41 +0200 Lukas Wunner <lukas@wunner=2Ede>
>wrote:
>> > These ADCs are marketed as single-channel 22 bit delta-sigma ADCs,
>but
>> > in reality their resolution is 21 bit with an overrange or
>underrange
>> > of 12% beyond Vref=2E In other words, "full scale" means +/- 2^20=2E
>[snip]
>>=20
>> Excellent=2E Applied to the togreg branch of iio=2Egit and pushed out =
as
>> testing=2E
>
>Just a gentle reminder, this patch isn't on your kernel=2Eorg branches
>yet=2E
>I assumed the reason was a dependency / merge conflict with my two
>patches
>on the fixes-togreg branch and you were waiting for them to be in
>upstream=2E
>They have landed in Linus' tree yesterday, I'm not sure if anything
>else is
>necessary (backmerge or some such)=2E
>
>Thanks,
>
>Lukas
Will investigate=2E Odd that I didn't mention waiting for dependencies=2E=
=2E=2E If necessary it may
be another week or so for it to propagate back to the IIO tree=2E
Jonathan
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger=2Ekernel=2Eorg
>More majordomo info at http://vger=2Ekernel=2Eorg/majordomo-info=2Ehtml
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E
^ permalink raw reply
* Re: [PATCH 07/25] xfs: scrub btree keys and records
From: Darrick J. Wong @ 2017-10-04 20:52 UTC (permalink / raw)
To: linux-xfs; +Cc: david
In-Reply-To: <150706329392.19351.7914012941264600843.stgit@magnolia>
On Tue, Oct 03, 2017 at 01:41:33PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Add to the btree scrubber the ability to check that the keys and
> records are in the right order and actually call out to our record
> iterator to do actual checking of the records.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/xfs/scrub/btree.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++
> fs/xfs/scrub/trace.h | 44 ++++++++++++++++++++
> 2 files changed, 152 insertions(+)
>
>
> diff --git a/fs/xfs/scrub/btree.c b/fs/xfs/scrub/btree.c
> index 899c9b1..ad3518c 100644
> --- a/fs/xfs/scrub/btree.c
> +++ b/fs/xfs/scrub/btree.c
> @@ -92,6 +92,101 @@ xfs_scrub_btree_set_corrupt(
> __return_address);
> }
>
> +/*
> + * Make sure this record is in order and doesn't stray outside of the parent
> + * keys.
> + */
> +STATIC void
> +xfs_scrub_btree_rec(
> + struct xfs_scrub_btree *bs)
> +{
> + struct xfs_btree_cur *cur = bs->cur;
> + union xfs_btree_rec *rec;
> + union xfs_btree_key key;
> + union xfs_btree_key hkey;
> + union xfs_btree_key *keyp;
> + struct xfs_btree_block *block;
> + struct xfs_btree_block *keyblock;
> + struct xfs_buf *bp;
> +
> + block = xfs_btree_get_block(cur, 0, &bp);
> + rec = xfs_btree_rec_addr(cur, cur->bc_ptrs[0], block);
> +
> + trace_xfs_scrub_btree_rec(bs->sc, cur, 0);
> +
> + /* If this isn't the first record, are they in order? */
> + if (!bs->firstrec && !cur->bc_ops->recs_inorder(cur, &bs->lastrec, rec))
> + xfs_scrub_btree_set_corrupt(bs->sc, cur, 0);
> + bs->firstrec = false;
> + memcpy(&bs->lastrec, rec, cur->bc_ops->rec_len);
> +
> + if (cur->bc_nlevels == 1)
> + return;
> +
> + /* Is this at least as large as the parent low key? */
> + cur->bc_ops->init_key_from_rec(&key, rec);
> + keyblock = xfs_btree_get_block(cur, 1, &bp);
> + keyp = xfs_btree_key_addr(cur, cur->bc_ptrs[1], keyblock);
> + if (cur->bc_ops->diff_two_keys(cur, &key, keyp) < 0)
> + xfs_scrub_btree_set_corrupt(bs->sc, cur, 1);
> +
> + if (!(cur->bc_flags & XFS_BTREE_OVERLAPPING))
> + return;
> +
> + /* Is this no larger than the parent high key? */
> + cur->bc_ops->init_high_key_from_rec(&hkey, rec);
> + keyp = xfs_btree_high_key_addr(cur, cur->bc_ptrs[1], keyblock);
> + if (cur->bc_ops->diff_two_keys(cur, keyp, &hkey) < 0)
> + xfs_scrub_btree_set_corrupt(bs->sc, cur, 1);
> +}
> +
> +/*
> + * Make sure this key is in order and doesn't stray outside of the parent
> + * keys.
> + */
> +STATIC void
> +xfs_scrub_btree_key(
> + struct xfs_scrub_btree *bs,
> + int level)
> +{
> + struct xfs_btree_cur *cur = bs->cur;
> + union xfs_btree_key *key;
> + union xfs_btree_key *keyp;
> + struct xfs_btree_block *block;
> + struct xfs_btree_block *keyblock;
> + struct xfs_buf *bp;
> +
> + block = xfs_btree_get_block(cur, level, &bp);
> + key = xfs_btree_key_addr(cur, cur->bc_ptrs[level], block);
> +
> + trace_xfs_scrub_btree_key(bs->sc, cur, level);
> +
> + /* If this isn't the first key, are they in order? */
> + if (!bs->firstkey[level] &&
> + !cur->bc_ops->keys_inorder(cur, &bs->lastkey[level], key))
> + xfs_scrub_btree_set_corrupt(bs->sc, cur, level);
> + bs->firstkey[level] = false;
> + memcpy(&bs->lastkey[level], key, cur->bc_ops->key_len);
> +
> + if (level + 1 >= cur->bc_nlevels)
> + return;
> +
> + /* Is this at least as large as the parent low key? */
> + keyblock = xfs_btree_get_block(cur, level + 1, &bp);
> + keyp = xfs_btree_key_addr(cur, cur->bc_ptrs[level + 1], keyblock);
> + if (cur->bc_ops->diff_two_keys(cur, key, keyp) < 0)
> + xfs_scrub_btree_set_corrupt(bs->sc, cur, level);
> +
> + if (!(cur->bc_flags & XFS_BTREE_OVERLAPPING))
> + return;
> +
> + /* Is this no larger than the parent high key? */
> + key = xfs_btree_high_key_addr(cur, cur->bc_ptrs[level], block);
> + keyp = xfs_btree_high_key_addr(cur, cur->bc_ptrs[level + 1], keyblock);
> + if (cur->bc_ops->diff_two_keys(cur, keyp, key) < 0)
> + xfs_scrub_btree_set_corrupt(bs->sc, cur, level);
> +}
> +
> /* Check a btree pointer. Returns true if it's ok to use this pointer. */
> static bool
> xfs_scrub_btree_ptr_ok(
> @@ -256,6 +351,7 @@ xfs_scrub_btree(
> struct xfs_scrub_btree bs = {0};
> union xfs_btree_ptr ptr;
> union xfs_btree_ptr *pp;
> + union xfs_btree_rec *recp;
> struct xfs_btree_block *block;
> int level;
> struct xfs_buf *bp;
> @@ -311,6 +407,15 @@ xfs_scrub_btree(
> continue;
> }
>
> + /* Records in order for scrub? */
> + xfs_scrub_btree_rec(&bs);
> +
> + /* Call out to the record checker. */
> + recp = xfs_btree_rec_addr(cur, cur->bc_ptrs[0], block);
> + error = bs.scrub_rec(&bs, recp);
> + if (error < 0 ||
> + error == XFS_BTREE_QUERY_RANGE_ABORT)
> + break;
> if (xfs_scrub_should_terminate(sc, &error))
> break;
Referencing the discussion of a later patch, we could check for
OFLAG_CORRUPT here as a quick way out if we find corruption in the
metadata object.
--D
>
> @@ -326,6 +431,9 @@ xfs_scrub_btree(
> continue;
> }
>
> + /* Keys in order for scrub? */
> + xfs_scrub_btree_key(&bs, level);
> +
> /* Drill another level deeper. */
> pp = xfs_btree_ptr_addr(cur, cur->bc_ptrs[level], block);
> if (!xfs_scrub_btree_ptr_ok(&bs, level, pp)) {
> diff --git a/fs/xfs/scrub/trace.h b/fs/xfs/scrub/trace.h
> index 78f96b0..a78c8d1 100644
> --- a/fs/xfs/scrub/trace.h
> +++ b/fs/xfs/scrub/trace.h
> @@ -423,6 +423,50 @@ TRACE_EVENT(xfs_scrub_ifork_btree_error,
> __entry->ret_ip)
> );
>
> +DECLARE_EVENT_CLASS(xfs_scrub_sbtree_class,
> + TP_PROTO(struct xfs_scrub_context *sc, struct xfs_btree_cur *cur,
> + int level),
> + TP_ARGS(sc, cur, level),
> + TP_STRUCT__entry(
> + __field(dev_t, dev)
> + __field(int, type)
> + __field(xfs_btnum_t, btnum)
> + __field(xfs_agnumber_t, agno)
> + __field(xfs_agblock_t, bno)
> + __field(int, level)
> + __field(int, nlevels)
> + __field(int, ptr)
> + ),
> + TP_fast_assign(
> + xfs_fsblock_t fsbno = xfs_scrub_btree_cur_fsbno(cur, level);
> + __entry->dev = sc->mp->m_super->s_dev;
> + __entry->type = sc->sm->sm_type;
> + __entry->btnum = cur->bc_btnum;
> + __entry->agno = XFS_FSB_TO_AGNO(cur->bc_mp, fsbno);
> + __entry->bno = XFS_FSB_TO_AGBNO(cur->bc_mp, fsbno);
> + __entry->level = level;
> + __entry->nlevels = cur->bc_nlevels;
> + __entry->ptr = cur->bc_ptrs[level];
> + ),
> + TP_printk("dev %d:%d type %u btnum %d agno %u agbno %u level %d nlevels %d ptr %d",
> + MAJOR(__entry->dev), MINOR(__entry->dev),
> + __entry->type,
> + __entry->btnum,
> + __entry->agno,
> + __entry->bno,
> + __entry->level,
> + __entry->nlevels,
> + __entry->ptr)
> +)
> +#define DEFINE_SCRUB_SBTREE_EVENT(name) \
> +DEFINE_EVENT(xfs_scrub_sbtree_class, name, \
> + TP_PROTO(struct xfs_scrub_context *sc, struct xfs_btree_cur *cur, \
> + int level), \
> + TP_ARGS(sc, cur, level))
> +
> +DEFINE_SCRUB_SBTREE_EVENT(xfs_scrub_btree_rec);
> +DEFINE_SCRUB_SBTREE_EVENT(xfs_scrub_btree_key);
> +
> #endif /* _TRACE_XFS_SCRUB_TRACE_H */
>
> #undef TRACE_INCLUDE_PATH
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drm/amd/powerplay: Partially revert changes and fix smu7_notify_smc_display()
From: Tom St Denis @ 2017-10-04 20:52 UTC (permalink / raw)
To: Andy Furniss, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <eb5871b8-3b6f-407d-55e5-c74e98be06ce-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Andy,
I didn't check that but this part of the original patch:
@@ -689,7 +697,7 @@ static int smu7_setup_dpm_tables_v0(struct pp_hwmgr
*hwmgr)
allowed_vdd_sclk_table->entries[i].clk) {
data->dpm_table.sclk_table.dpm_levels[data->dpm_table.sclk_table.count].value
=
allowed_vdd_sclk_table->entries[i].clk;
-
data->dpm_table.sclk_table.dpm_levels[data->dpm_table.sclk_table.count].enabled
= 1; /*(i==0) ? 1 : 0; to do */
+
data->dpm_table.sclk_table.dpm_levels[data->dpm_table.sclk_table.count].enabled
= (i == 0) ? 1 : 0;
data->dpm_table.sclk_table.count++;
}
}
@@ -703,7 +711,7 @@ static int smu7_setup_dpm_tables_v0(struct pp_hwmgr
*hwmgr)
allowed_vdd_mclk_table->entries[i].clk) {
data->dpm_table.mclk_table.dpm_levels[data->dpm_table.mclk_table.count].value
=
allowed_vdd_mclk_table->entries[i].clk;
-
data->dpm_table.mclk_table.dpm_levels[data->dpm_table.mclk_table.count].enabled
= 1; /*(i==0) ? 1 : 0; */
+
data->dpm_table.mclk_table.dpm_levels[data->dpm_table.mclk_table.count].enabled
= (i == 0) ? 1 : 0;
data->dpm_table.mclk_table.count++;
}
Might be the culprit. It seems to disable all but the first clock
settings. It's beyond EOD for me today but I'll check first thing in
the morning.
Cheers,
Tom
On 04/10/17 04:21 PM, Andy Furniss wrote:
> For me testing on 4.15-wip with tonga it does "fix", but memclk is
> stuck, which would have avoided the lines had I forced it without this.
>
> Maybe you see different on a different kernel - is memclk stuck for you
> with this?
>
> Tom St Denis wrote:
>> This partially reverts 0b6b4cbf77c995a34a4ec3d705a636434dadc51a and fixes
>> the noise issues on Tonga.
>>
>> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
>> ---
>> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 ++-----
>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> index 8dbe9148aad3..4826b2991b7e 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> @@ -3825,14 +3825,11 @@ static int
>> smu7_notify_link_speed_change_after_state_change(
>> static int smu7_notify_smc_display(struct pp_hwmgr *hwmgr)
>> {
>> struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
>> - int ret = 0;
>> - if (hwmgr->feature_mask & PP_VBI_TIME_SUPPORT_MASK) {
>> + if (hwmgr->feature_mask & PP_VBI_TIME_SUPPORT_MASK)
>> smum_send_msg_to_smc_with_parameter(hwmgr,
>> (PPSMC_Msg)PPSMC_MSG_SetVBITimeout, data->frame_time_x2);
>> - ret = (smum_send_msg_to_smc(hwmgr,
>> (PPSMC_Msg)PPSMC_HasDisplay) == 0) ? 0 : -EINVAL;
>> - }
>> - return ret;
>> + return (smum_send_msg_to_smc(hwmgr, (PPSMC_Msg)PPSMC_HasDisplay)
>> == 0) ? 0 : -EINVAL;
>> }
>> static int smu7_set_power_state_tasks(struct pp_hwmgr *hwmgr, const
>> void *input)
>>
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Tetsuo Handa @ 2017-10-04 20:49 UTC (permalink / raw)
To: Johannes Weiner, Andrew Morton
Cc: Alan Cox, Christoph Hellwig, Michal Hocko, linux-mm, linux-kernel,
kernel-team
In-Reply-To: <20171004185906.GB2136@cmpxchg.org>
On 2017/10/05 3:59, Johannes Weiner wrote:
> But the justification to make that vmalloc() call fail like this isn't
> convincing, either. The patch mentions an OOM victim exhausting the
> memory reserves and thus deadlocking the machine. But the OOM killer
> is only one, improbable source of fatal signals. It doesn't make sense
> to fail allocations preemptively with plenty of memory in most cases.
By the time the current thread reaches do_exit(), fatal_signal_pending(current)
should become false. As far as I can guess, the source of fatal signal will be
tty_signal_session_leader(tty, exit_session) which is called just before
tty_ldisc_hangup(tty, cons_filp != NULL) rather than the OOM killer. I don't
know whether it is possible to make fatal_signal_pending(current) true inside
do_exit() though...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"
From: Tetsuo Handa @ 2017-10-04 20:49 UTC (permalink / raw)
To: Johannes Weiner, Andrew Morton
Cc: Alan Cox, Christoph Hellwig, Michal Hocko, linux-mm, linux-kernel,
kernel-team
In-Reply-To: <20171004185906.GB2136@cmpxchg.org>
On 2017/10/05 3:59, Johannes Weiner wrote:
> But the justification to make that vmalloc() call fail like this isn't
> convincing, either. The patch mentions an OOM victim exhausting the
> memory reserves and thus deadlocking the machine. But the OOM killer
> is only one, improbable source of fatal signals. It doesn't make sense
> to fail allocations preemptively with plenty of memory in most cases.
By the time the current thread reaches do_exit(), fatal_signal_pending(current)
should become false. As far as I can guess, the source of fatal signal will be
tty_signal_session_leader(tty, exit_session) which is called just before
tty_ldisc_hangup(tty, cons_filp != NULL) rather than the OOM killer. I don't
know whether it is possible to make fatal_signal_pending(current) true inside
do_exit() though...
^ permalink raw reply
* Re: [PATCH v4 4/5] cramfs: add mmap support
From: Nicolas Pitre @ 2017-10-04 20:47 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Richard Weinberger, Alexander Viro, linux-mm@kvack.org,
linux-fsdevel, linux-embedded@vger.kernel.org, LKML, Chris Brandt
In-Reply-To: <20171004072553.GA24620@infradead.org>
On Wed, 4 Oct 2017, Christoph Hellwig wrote:
> As said in my last mail: look at the VM_MIXEDMAP flag and how it is
> used by DAX, and you'll get out of the vma splitting business in the
> fault path.
Alright, it appears to work.
The only downside so far is the lack of visibility from user space to
confirm it actually works as intended. With the vma splitting approach
you clearly see what gets directly mapped in /proc/*/maps thanks to
remap_pfn_range() storing the actual physical address in vma->vm_pgoff.
With VM_MIXEDMAP things are no longer visible. Any opinion for the best
way to overcome this?
Anyway, here's a replacement for patch 4/5 below:
----- >8
Subject: cramfs: add mmap support
When cramfs_physmem is used then we have the opportunity to map files
directly from ROM, directly into user space, saving on RAM usage.
This gives us Execute-In-Place (XIP) support.
For a file to be mmap()-able, the map area has to correspond to a range
of uncompressed and contiguous blocks, and in the MMU case it also has
to be page aligned. A version of mkcramfs with appropriate support is
necessary to create such a filesystem image.
In the MMU case it may happen for a vma structure to extend beyond the
actual file size. This is notably the case in binfmt_elf.c:elf_map().
Or the file's last block is shared with other files and cannot be mapped
as is. Rather than refusing to mmap it, we do a "mixed" map and let the
regular fault handler populate the unmapped area with RAM-backed pages.
In practice the unmapped area is seldom accessed so page faults might
never occur before this area is discarded.
In the non-MMU case it is the get_unmapped_area method that is responsible
for providing the address where the actual data can be found. No mapping
is necessary of course.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 2fc886092b..9d5d0c1f7d 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -15,7 +15,10 @@
#include <linux/module.h>
#include <linux/fs.h>
+#include <linux/file.h>
#include <linux/pagemap.h>
+#include <linux/pfn_t.h>
+#include <linux/ramfs.h>
#include <linux/init.h>
#include <linux/string.h>
#include <linux/blkdev.h>
@@ -49,6 +52,7 @@ static inline struct cramfs_sb_info *CRAMFS_SB(struct super_block *sb)
static const struct super_operations cramfs_ops;
static const struct inode_operations cramfs_dir_inode_operations;
static const struct file_operations cramfs_directory_operations;
+static const struct file_operations cramfs_physmem_fops;
static const struct address_space_operations cramfs_aops;
static DEFINE_MUTEX(read_mutex);
@@ -96,6 +100,10 @@ static struct inode *get_cramfs_inode(struct super_block *sb,
case S_IFREG:
inode->i_fop = &generic_ro_fops;
inode->i_data.a_ops = &cramfs_aops;
+ if (IS_ENABLED(CONFIG_CRAMFS_PHYSMEM) &&
+ CRAMFS_SB(sb)->flags & CRAMFS_FLAG_EXT_BLOCK_POINTERS &&
+ CRAMFS_SB(sb)->linear_phys_addr)
+ inode->i_fop = &cramfs_physmem_fops;
break;
case S_IFDIR:
inode->i_op = &cramfs_dir_inode_operations;
@@ -277,6 +285,188 @@ static void *cramfs_read(struct super_block *sb, unsigned int offset,
return NULL;
}
+/*
+ * For a mapping to be possible, we need a range of uncompressed and
+ * contiguous blocks. Return the offset for the first block and number of
+ * valid blocks for which that is true, or zero otherwise.
+ */
+static u32 cramfs_get_block_range(struct inode *inode, u32 pgoff, u32 *pages)
+{
+ struct super_block *sb = inode->i_sb;
+ struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
+ int i;
+ u32 *blockptrs, blockaddr;
+
+ /*
+ * We can dereference memory directly here as this code may be
+ * reached only when there is a direct filesystem image mapping
+ * available in memory.
+ */
+ blockptrs = (u32 *)(sbi->linear_virt_addr + OFFSET(inode) + pgoff*4);
+ blockaddr = blockptrs[0] & ~CRAMFS_BLK_FLAGS;
+ i = 0;
+ do {
+ u32 expect = blockaddr + i * (PAGE_SIZE >> 2);
+ expect |= CRAMFS_BLK_FLAG_DIRECT_PTR|CRAMFS_BLK_FLAG_UNCOMPRESSED;
+ if (blockptrs[i] != expect) {
+ pr_debug("range: block %d/%d got %#x expects %#x\n",
+ pgoff+i, pgoff+*pages-1, blockptrs[i], expect);
+ if (i == 0)
+ return 0;
+ break;
+ }
+ } while (++i < *pages);
+
+ *pages = i;
+
+ /* stored "direct" block ptrs are shifted down by 2 bits */
+ return blockaddr << 2;
+}
+
+static int cramfs_physmem_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct inode *inode = file_inode(file);
+ struct super_block *sb = inode->i_sb;
+ struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
+ unsigned int pages, vma_pages, max_pages, offset;
+ unsigned long address;
+ char *fail_reason;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_MMU))
+ return vma->vm_flags & (VM_SHARED | VM_MAYSHARE) ? 0 : -ENOSYS;
+
+ if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_MAYWRITE))
+ return -EINVAL;
+
+ /* Could COW work here? */
+ fail_reason = "vma is writable";
+ if (vma->vm_flags & VM_WRITE)
+ goto fail;
+
+ vma_pages = (vma->vm_end - vma->vm_start + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ max_pages = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ fail_reason = "beyond file limit";
+ if (vma->vm_pgoff >= max_pages)
+ goto fail;
+ pages = vma_pages;
+ if (pages > max_pages - vma->vm_pgoff)
+ pages = max_pages - vma->vm_pgoff;
+
+ offset = cramfs_get_block_range(inode, vma->vm_pgoff, &pages);
+ fail_reason = "unsuitable block layout";
+ if (!offset)
+ goto fail;
+ address = sbi->linear_phys_addr + offset;
+ fail_reason = "data is not page aligned";
+ if (!PAGE_ALIGNED(address))
+ goto fail;
+
+ /* Don't map the last page if it contains some other data */
+ if (unlikely(vma->vm_pgoff + pages == max_pages)) {
+ unsigned int partial = offset_in_page(inode->i_size);
+ if (partial) {
+ char *data = sbi->linear_virt_addr + offset;
+ data += (max_pages - 1) * PAGE_SIZE + partial;
+ while ((unsigned long)data & 7)
+ if (*data++ != 0)
+ goto nonzero;
+ while (offset_in_page(data)) {
+ if (*(u64 *)data != 0) {
+ nonzero:
+ pr_debug("mmap: %s: last page is shared\n",
+ file_dentry(file)->d_name.name);
+ pages--;
+ break;
+ }
+ data += 8;
+ }
+ }
+ }
+
+ if (!pages) {
+ fail_reason = "no suitable block remaining";
+ goto fail;
+ } else if (pages != vma_pages) {
+ /*
+ * Let's create a mixed map if we can't map it all.
+ * The normal paging machinery will take care of the
+ * unpopulated vma via cramfs_readpage().
+ */
+ int i;
+ vma->vm_flags |= VM_MIXEDMAP;
+ for (i = 0; i < pages; i++) {
+ unsigned long vaddr = vma->vm_start + i*PAGE_SIZE;
+ pfn_t pfn = phys_to_pfn_t(address + i*PAGE_SIZE, PFN_DEV);
+ ret = vm_insert_mixed(vma, vaddr, pfn);
+ if (ret)
+ return ret;
+ }
+ vma->vm_ops = &generic_file_vm_ops;
+ } else {
+ ret = remap_pfn_range(vma, vma->vm_start, address >> PAGE_SHIFT,
+ pages * PAGE_SIZE, vma->vm_page_prot);
+ if (ret)
+ return ret;
+ }
+
+ pr_debug("mapped %s at 0x%08lx (%u/%u pages) to vma 0x%08lx, "
+ "page_prot 0x%llx\n", file_dentry(file)->d_name.name,
+ address, pages, vma_pages, vma->vm_start,
+ (unsigned long long)pgprot_val(vma->vm_page_prot));
+ return 0;
+
+fail:
+ pr_debug("%s: direct mmap failed: %s\n",
+ file_dentry(file)->d_name.name, fail_reason);
+
+ /* We failed to do a direct map, but normal paging is still possible */
+ vma->vm_ops = &generic_file_vm_ops;
+ return 0;
+}
+
+#ifndef CONFIG_MMU
+
+static unsigned long cramfs_physmem_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len,
+ unsigned long pgoff, unsigned long flags)
+{
+ struct inode *inode = file_inode(file);
+ struct super_block *sb = inode->i_sb;
+ struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
+ unsigned int pages, block_pages, max_pages, offset;
+
+ pages = (len + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ max_pages = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ if (pgoff >= max_pages || pages > max_pages - pgoff)
+ return -EINVAL;
+ block_pages = pages;
+ offset = cramfs_get_block_range(inode, pgoff, &block_pages);
+ if (!offset || block_pages != pages)
+ return -ENOSYS;
+ addr = sbi->linear_phys_addr + offset;
+ pr_debug("get_unmapped for %s ofs %#lx siz %lu at 0x%08lx\n",
+ file_dentry(file)->d_name.name, pgoff*PAGE_SIZE, len, addr);
+ return addr;
+}
+
+static unsigned cramfs_physmem_mmap_capabilities(struct file *file)
+{
+ return NOMMU_MAP_COPY | NOMMU_MAP_DIRECT | NOMMU_MAP_READ | NOMMU_MAP_EXEC;
+}
+#endif
+
+static const struct file_operations cramfs_physmem_fops = {
+ .llseek = generic_file_llseek,
+ .read_iter = generic_file_read_iter,
+ .splice_read = generic_file_splice_read,
+ .mmap = cramfs_physmem_mmap,
+#ifndef CONFIG_MMU
+ .get_unmapped_area = cramfs_physmem_get_unmapped_area,
+ .mmap_capabilities = cramfs_physmem_mmap_capabilities,
+#endif
+};
+
static void cramfs_blkdev_kill_sb(struct super_block *sb)
{
struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
^ permalink raw reply related
* Re: [PATCH v4 4/5] cramfs: add mmap support
From: Nicolas Pitre @ 2017-10-04 20:47 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Richard Weinberger, Alexander Viro, linux-mm@kvack.org,
linux-fsdevel, linux-embedded@vger.kernel.org, LKML, Chris Brandt
In-Reply-To: <20171004072553.GA24620@infradead.org>
On Wed, 4 Oct 2017, Christoph Hellwig wrote:
> As said in my last mail: look at the VM_MIXEDMAP flag and how it is
> used by DAX, and you'll get out of the vma splitting business in the
> fault path.
Alright, it appears to work.
The only downside so far is the lack of visibility from user space to
confirm it actually works as intended. With the vma splitting approach
you clearly see what gets directly mapped in /proc/*/maps thanks to
remap_pfn_range() storing the actual physical address in vma->vm_pgoff.
With VM_MIXEDMAP things are no longer visible. Any opinion for the best
way to overcome this?
Anyway, here's a replacement for patch 4/5 below:
----- >8
Subject: cramfs: add mmap support
When cramfs_physmem is used then we have the opportunity to map files
directly from ROM, directly into user space, saving on RAM usage.
This gives us Execute-In-Place (XIP) support.
For a file to be mmap()-able, the map area has to correspond to a range
of uncompressed and contiguous blocks, and in the MMU case it also has
to be page aligned. A version of mkcramfs with appropriate support is
necessary to create such a filesystem image.
In the MMU case it may happen for a vma structure to extend beyond the
actual file size. This is notably the case in binfmt_elf.c:elf_map().
Or the file's last block is shared with other files and cannot be mapped
as is. Rather than refusing to mmap it, we do a "mixed" map and let the
regular fault handler populate the unmapped area with RAM-backed pages.
In practice the unmapped area is seldom accessed so page faults might
never occur before this area is discarded.
In the non-MMU case it is the get_unmapped_area method that is responsible
for providing the address where the actual data can be found. No mapping
is necessary of course.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 2fc886092b..9d5d0c1f7d 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -15,7 +15,10 @@
#include <linux/module.h>
#include <linux/fs.h>
+#include <linux/file.h>
#include <linux/pagemap.h>
+#include <linux/pfn_t.h>
+#include <linux/ramfs.h>
#include <linux/init.h>
#include <linux/string.h>
#include <linux/blkdev.h>
@@ -49,6 +52,7 @@ static inline struct cramfs_sb_info *CRAMFS_SB(struct super_block *sb)
static const struct super_operations cramfs_ops;
static const struct inode_operations cramfs_dir_inode_operations;
static const struct file_operations cramfs_directory_operations;
+static const struct file_operations cramfs_physmem_fops;
static const struct address_space_operations cramfs_aops;
static DEFINE_MUTEX(read_mutex);
@@ -96,6 +100,10 @@ static struct inode *get_cramfs_inode(struct super_block *sb,
case S_IFREG:
inode->i_fop = &generic_ro_fops;
inode->i_data.a_ops = &cramfs_aops;
+ if (IS_ENABLED(CONFIG_CRAMFS_PHYSMEM) &&
+ CRAMFS_SB(sb)->flags & CRAMFS_FLAG_EXT_BLOCK_POINTERS &&
+ CRAMFS_SB(sb)->linear_phys_addr)
+ inode->i_fop = &cramfs_physmem_fops;
break;
case S_IFDIR:
inode->i_op = &cramfs_dir_inode_operations;
@@ -277,6 +285,188 @@ static void *cramfs_read(struct super_block *sb, unsigned int offset,
return NULL;
}
+/*
+ * For a mapping to be possible, we need a range of uncompressed and
+ * contiguous blocks. Return the offset for the first block and number of
+ * valid blocks for which that is true, or zero otherwise.
+ */
+static u32 cramfs_get_block_range(struct inode *inode, u32 pgoff, u32 *pages)
+{
+ struct super_block *sb = inode->i_sb;
+ struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
+ int i;
+ u32 *blockptrs, blockaddr;
+
+ /*
+ * We can dereference memory directly here as this code may be
+ * reached only when there is a direct filesystem image mapping
+ * available in memory.
+ */
+ blockptrs = (u32 *)(sbi->linear_virt_addr + OFFSET(inode) + pgoff*4);
+ blockaddr = blockptrs[0] & ~CRAMFS_BLK_FLAGS;
+ i = 0;
+ do {
+ u32 expect = blockaddr + i * (PAGE_SIZE >> 2);
+ expect |= CRAMFS_BLK_FLAG_DIRECT_PTR|CRAMFS_BLK_FLAG_UNCOMPRESSED;
+ if (blockptrs[i] != expect) {
+ pr_debug("range: block %d/%d got %#x expects %#x\n",
+ pgoff+i, pgoff+*pages-1, blockptrs[i], expect);
+ if (i == 0)
+ return 0;
+ break;
+ }
+ } while (++i < *pages);
+
+ *pages = i;
+
+ /* stored "direct" block ptrs are shifted down by 2 bits */
+ return blockaddr << 2;
+}
+
+static int cramfs_physmem_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct inode *inode = file_inode(file);
+ struct super_block *sb = inode->i_sb;
+ struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
+ unsigned int pages, vma_pages, max_pages, offset;
+ unsigned long address;
+ char *fail_reason;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_MMU))
+ return vma->vm_flags & (VM_SHARED | VM_MAYSHARE) ? 0 : -ENOSYS;
+
+ if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_MAYWRITE))
+ return -EINVAL;
+
+ /* Could COW work here? */
+ fail_reason = "vma is writable";
+ if (vma->vm_flags & VM_WRITE)
+ goto fail;
+
+ vma_pages = (vma->vm_end - vma->vm_start + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ max_pages = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ fail_reason = "beyond file limit";
+ if (vma->vm_pgoff >= max_pages)
+ goto fail;
+ pages = vma_pages;
+ if (pages > max_pages - vma->vm_pgoff)
+ pages = max_pages - vma->vm_pgoff;
+
+ offset = cramfs_get_block_range(inode, vma->vm_pgoff, &pages);
+ fail_reason = "unsuitable block layout";
+ if (!offset)
+ goto fail;
+ address = sbi->linear_phys_addr + offset;
+ fail_reason = "data is not page aligned";
+ if (!PAGE_ALIGNED(address))
+ goto fail;
+
+ /* Don't map the last page if it contains some other data */
+ if (unlikely(vma->vm_pgoff + pages == max_pages)) {
+ unsigned int partial = offset_in_page(inode->i_size);
+ if (partial) {
+ char *data = sbi->linear_virt_addr + offset;
+ data += (max_pages - 1) * PAGE_SIZE + partial;
+ while ((unsigned long)data & 7)
+ if (*data++ != 0)
+ goto nonzero;
+ while (offset_in_page(data)) {
+ if (*(u64 *)data != 0) {
+ nonzero:
+ pr_debug("mmap: %s: last page is shared\n",
+ file_dentry(file)->d_name.name);
+ pages--;
+ break;
+ }
+ data += 8;
+ }
+ }
+ }
+
+ if (!pages) {
+ fail_reason = "no suitable block remaining";
+ goto fail;
+ } else if (pages != vma_pages) {
+ /*
+ * Let's create a mixed map if we can't map it all.
+ * The normal paging machinery will take care of the
+ * unpopulated vma via cramfs_readpage().
+ */
+ int i;
+ vma->vm_flags |= VM_MIXEDMAP;
+ for (i = 0; i < pages; i++) {
+ unsigned long vaddr = vma->vm_start + i*PAGE_SIZE;
+ pfn_t pfn = phys_to_pfn_t(address + i*PAGE_SIZE, PFN_DEV);
+ ret = vm_insert_mixed(vma, vaddr, pfn);
+ if (ret)
+ return ret;
+ }
+ vma->vm_ops = &generic_file_vm_ops;
+ } else {
+ ret = remap_pfn_range(vma, vma->vm_start, address >> PAGE_SHIFT,
+ pages * PAGE_SIZE, vma->vm_page_prot);
+ if (ret)
+ return ret;
+ }
+
+ pr_debug("mapped %s at 0x%08lx (%u/%u pages) to vma 0x%08lx, "
+ "page_prot 0x%llx\n", file_dentry(file)->d_name.name,
+ address, pages, vma_pages, vma->vm_start,
+ (unsigned long long)pgprot_val(vma->vm_page_prot));
+ return 0;
+
+fail:
+ pr_debug("%s: direct mmap failed: %s\n",
+ file_dentry(file)->d_name.name, fail_reason);
+
+ /* We failed to do a direct map, but normal paging is still possible */
+ vma->vm_ops = &generic_file_vm_ops;
+ return 0;
+}
+
+#ifndef CONFIG_MMU
+
+static unsigned long cramfs_physmem_get_unmapped_area(struct file *file,
+ unsigned long addr, unsigned long len,
+ unsigned long pgoff, unsigned long flags)
+{
+ struct inode *inode = file_inode(file);
+ struct super_block *sb = inode->i_sb;
+ struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
+ unsigned int pages, block_pages, max_pages, offset;
+
+ pages = (len + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ max_pages = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ if (pgoff >= max_pages || pages > max_pages - pgoff)
+ return -EINVAL;
+ block_pages = pages;
+ offset = cramfs_get_block_range(inode, pgoff, &block_pages);
+ if (!offset || block_pages != pages)
+ return -ENOSYS;
+ addr = sbi->linear_phys_addr + offset;
+ pr_debug("get_unmapped for %s ofs %#lx siz %lu at 0x%08lx\n",
+ file_dentry(file)->d_name.name, pgoff*PAGE_SIZE, len, addr);
+ return addr;
+}
+
+static unsigned cramfs_physmem_mmap_capabilities(struct file *file)
+{
+ return NOMMU_MAP_COPY | NOMMU_MAP_DIRECT | NOMMU_MAP_READ | NOMMU_MAP_EXEC;
+}
+#endif
+
+static const struct file_operations cramfs_physmem_fops = {
+ .llseek = generic_file_llseek,
+ .read_iter = generic_file_read_iter,
+ .splice_read = generic_file_splice_read,
+ .mmap = cramfs_physmem_mmap,
+#ifndef CONFIG_MMU
+ .get_unmapped_area = cramfs_physmem_get_unmapped_area,
+ .mmap_capabilities = cramfs_physmem_mmap_capabilities,
+#endif
+};
+
static void cramfs_blkdev_kill_sb(struct super_block *sb)
{
struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v3 0/2] Deprecate -nodefconfig
From: Eduardo Habkost @ 2017-10-04 20:46 UTC (permalink / raw)
To: qemu-devel; +Cc: Paolo Bonzini, Markus Armbruster, Alistair Francis
In-Reply-To: <20171004030025.7866-1-ehabkost@redhat.com>
On Wed, Oct 04, 2017 at 12:00:23AM -0300, Eduardo Habkost wrote:
> Changes v2 -> v3:
> * Move documentation to the right section of qemu-doc.texi
>
> Changes v1 -> v2:
> * Document at "Deprecated features" section in qemu-doc.texi
> (Daniel)
> * Remove documentation for the option from qemu-options.hx
> (Markus)
>
> Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
> have no default config files that would be disabled using
> -nodefconfig. This series cleans up the code, updates
> documentation, and document -nodefconfig as deprecated.
Paolo, if you are OK with it I'm queueing this series on
machine-next.
--
Eduardo
^ permalink raw reply
* Re: [PATCH] imx6ullevk: Add machine file
From: Otavio Salvador @ 2017-10-04 20:44 UTC (permalink / raw)
To: Daiane Angolini; +Cc: meta-freescale@yoctoproject.org
In-Reply-To: <1507139372-4642-1-git-send-email-daiane.angolini@nxp.com>
On Wed, Oct 4, 2017 at 2:49 PM, Daiane Angolini <daiane.angolini@nxp.com> wrote:
> CPU: Freescale i.MX6ULL rev1.0 at 396MHz
> CPU: Commercial temperature grade (0C to 95C) at 41C
> Reset cause: POR
> Board: MX6ULL 14x14 EVK
> I2C: ready
> DRAM: 512 MiB
>
> Signed-off-by: Daiane Angolini <daiane.angolini@nxp.com>
> ---
> conf/machine/imx6ullevk.conf | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 conf/machine/imx6ullevk.conf
>
> diff --git a/conf/machine/imx6ullevk.conf b/conf/machine/imx6ullevk.conf
> new file mode 100644
> index 0000000..3018c0d
> --- /dev/null
> +++ b/conf/machine/imx6ullevk.conf
> @@ -0,0 +1,28 @@
> +#@TYPE: Machine
> +#@NAME: Freescale i.MX6ULL Evaluation Kit
> +#@SOC: i.MX6ULL
> +#@DESCRIPTION: Machine configuration for Freescale i.MX6ULL EVK
> +#@MAINTAINER: Daiane Angolini <daiane.angolini@nxp.com>
> +
> +MACHINEOVERRIDES =. "mx6:mx6ull:"
> +
> +include conf/machine/include/imx-base.inc
> +include conf/machine/include/tune-cortexa7.inc
> +
> +KERNEL_DEVICETREE = "imx6ull-14x14-evk.dtb imx6ull-14x14-evk-btwifi.dtb"
> +
> +UBOOT_CONFIG ??= "sd"
> +UBOOT_CONFIG[sd] = "mx6ull_14x14_evk_config,sdcard"
> +UBOOT_CONFIG[mfgtool] = "mx6ull_14x14_evk_config"
> +
> +PREFERRED_PROVIDER_u-boot = "u-boot-imx"
> +PREFERRED_PROVIDER_virtual/bootloader = "u-boot-imx"
> +PREFERRED_PROVIDER_virtual/kernel = "linux-imx"
> +
> +SERIAL_CONSOLE = "115200 ttymxc0"
> +
> +MACHINE_FEATURES += " pci wifi bluetooth"
> +
> +IMAGE_FSTYPES = "wic.gz"
> +IMAGE_BOOT_FILES = "${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
Please see the generic definition for the boot files I sent for
imx-base.inc, it should work for this case as well.
> +WKS_FILE ?= "imx-uboot-bootpart.wks"
> --
> 2.7.4
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.