* Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c
From: Arnaldo Carvalho de Melo @ 2016-11-09 14:44 UTC (permalink / raw)
To: Adrian Hunter
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kernel, Andi Kleen
In-Reply-To: <344fddd4-718b-ecf3-75f0-585eda90df6f@intel.com>
Em Wed, Nov 09, 2016 at 04:01:12PM +0200, Adrian Hunter escreveu:
> On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu:
> > +++ b/tools/perf/Documentation/intel-pt.txt
> > @@ -546,6 +546,18 @@ mode by using the --per-thread option.
> > Privileged vs non-privileged users
> > ----------------------------------
> > +The v4.2 kernel introduced support for a context switch metadata event,
> > +PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
> > +are scheduled out and in, just not by whom, which is left for the
> > +PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
> > +which in turn requires CAP_SYS_ADMIN.
> > +
> > +Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
> > +switches") commit, that introduces these metadata events for further info.
> > +
> > +When working with kernels < v4.2, the following considerations must be taken,
> > +as the sched:sched_switch tracepoints will be used to receive such information:
> > +
> > Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
> > have memory limits imposed upon them. That affects what buffer sizes they can
> > have as outlined above.
> Maybe put that last paragraph about memory limits above the new text.
Ok, adding your Acked-by, it now stands as, please ack:
commit c955ced680270b95a3de6a2434311befaeaea948
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Wed Nov 9 11:04:05 2016 -0300
perf intel-pt: Update documentation about context switch events
Since the unprivileged sched switch event was added in perf, PT doesn't
need need perf_event_paranoid=-1 anymore for per cpu decoding.
Add a note stating that that is only needed for kernels < 4.2.
Reported-by: Andi Kleen <ak@linux.intel.com>
Report-link: http://lkml.kernel.org/r/http://lkml.kernel.org/n/tip-x2ybghpqxxn3zu0m8o7qi42r@git.kernel.org
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context switches")
Link: http://lkml.kernel.org/n/tip-x2ybghpqxxn3zu0m8o7qi42r@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt
index c6c8318e38a2..b0b3007d3c9c 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -550,6 +550,18 @@ Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
have memory limits imposed upon them. That affects what buffer sizes they can
have as outlined above.
+The v4.2 kernel introduced support for a context switch metadata event,
+PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
+are scheduled out and in, just not by whom, which is left for the
+PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
+which in turn requires CAP_SYS_ADMIN.
+
+Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
+switches") commit, that introduces these metadata events for further info.
+
+When working with kernels < v4.2, the following considerations must be taken,
+as the sched:sched_switch tracepoints will be used to receive such information:
+
Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users are
not permitted to use tracepoints which means there is insufficient side-band
information to decode Intel PT in per-cpu mode, and potentially workload-only
@@ -564,8 +576,11 @@ sched_switch tracepoint
-----------------------
The sched_switch tracepoint is used to provide side-band data for Intel PT
-decoding. sched_switch events are automatically added. e.g. the second event
-shown below
+decoding in kernels where the PERF_RECORD_SWITCH metadata event isn't
+available.
+
+The sched_switch events are automatically added. e.g. the second event shown
+below:
$ perf record -vv -e intel_pt//u uname
------------------------------------------------------------
^ permalink raw reply related
* Re: [PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:44 UTC (permalink / raw)
To: Lorenzo Pieralisi, iommu
Cc: Will Deacon, Hanjun Guo, Marc Zyngier, Joerg Roedel,
Rafael J. Wysocki, Tomasz Nowicki, Jon Masters, Eric Auger,
Sinan Kaya, Nate Watterson, Prem Mallappa, Dennis Chen,
linux-acpi, linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20161109141948.19244-7-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU v3 driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index e6f9b2d..fef9f60 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1723,13 +1723,14 @@ static struct platform_driver arm_smmu_driver;
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1765,7 +1766,7 @@ static int arm_smmu_add_device(struct device *dev)
> master = fwspec->iommu_priv;
> smmu = master->smmu;
> } else {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> if (!smmu)
> return -ENODEV;
> master = kzalloc(sizeof(*master), GFP_KERNEL);
> @@ -2634,7 +2635,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> return ret;
>
> /* And we're up. Go go go! */
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> +
> #ifdef CONFIG_PCI
> if (pci_bus_type.iommu_ops != &arm_smmu_ops) {
> pci_request_acs();
>
^ permalink raw reply
* [PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-7-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU v3 driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index e6f9b2d..fef9f60 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1723,13 +1723,14 @@ static struct platform_driver arm_smmu_driver;
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1765,7 +1766,7 @@ static int arm_smmu_add_device(struct device *dev)
> master = fwspec->iommu_priv;
> smmu = master->smmu;
> } else {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> if (!smmu)
> return -ENODEV;
> master = kzalloc(sizeof(*master), GFP_KERNEL);
> @@ -2634,7 +2635,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> return ret;
>
> /* And we're up. Go go go! */
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> +
> #ifdef CONFIG_PCI
> if (pci_bus_type.iommu_ops != &arm_smmu_ops) {
> pci_request_acs();
>
^ permalink raw reply
* Re: [PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:44 UTC (permalink / raw)
To: Lorenzo Pieralisi,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Marc Zyngier, Will Deacon,
Rafael J. Wysocki, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Sinan Kaya, Dennis Chen,
Tomasz Nowicki, Prem Mallappa, Jon Masters
In-Reply-To: <20161109141948.19244-7-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU v3 driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> Tested-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Tested-by: Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
> Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Cc: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index e6f9b2d..fef9f60 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1723,13 +1723,14 @@ static struct platform_driver arm_smmu_driver;
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1765,7 +1766,7 @@ static int arm_smmu_add_device(struct device *dev)
> master = fwspec->iommu_priv;
> smmu = master->smmu;
> } else {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> if (!smmu)
> return -ENODEV;
> master = kzalloc(sizeof(*master), GFP_KERNEL);
> @@ -2634,7 +2635,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> return ret;
>
> /* And we're up. Go go go! */
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> +
> #ifdef CONFIG_PCI
> if (pci_bus_type.iommu_ops != &arm_smmu_ops) {
> pci_request_acs();
>
^ permalink raw reply
* [U-Boot] [PATCH 0/7] sunxi: Add support for the CHIP Pro
From: Maxime Ripard @ 2016-11-09 14:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <5822D480.4040308@denx.de>
Hi Heiko,
On Wed, Nov 09, 2016 at 08:47:12AM +0100, Heiko Schocher wrote:
> Am 08.11.2016 um 17:21 schrieb Maxime Ripard:
> > The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an
> > AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND.
> >
> > Since the first Allwinner device coming whit an SLC NAND that doesn't have
> > the shortcomings (and breakages) the MLC NAND has, we can finally enable
> > the NAND support on a board by default.
> >
> > This is the occasion to introduce a bunch of additions needed imo to be
> > able to come up with a sane NAND support for our users.
> >
> > The biggest pain point is that the BROM uses a different ECC and randomizer
> > configuration than for the rest of the NAND. In order to lessen the number
> > of bitflips, you also need to pad with random data the SPL image.
> >
> > Since it's quite tedious to do right (and most users won't be able to
> > figure it out) and since if it is not done right, it will eventually turn
> > into an unusable system (which is bad UX), we think that the best solution
> > is to generate an SPL image that already embeds all this. We'll possible
> > have to do the same thing for the U-Boot image (at least for the random
> > padding) on MLC NANDs.
> >
> > The only drawback from that is that you need to flash it raw, instead of
> > using the usual nand write, but it's just a different command, nothing
> > major anyway.
> >
> > In order to flash it, from a device switched in FEL, on your host:
> > sunxi-fel spl spl/sunxi-spl.bin
> > sunxi-fel write 0x4a000000 u-boot-dtb.bin
> > sunxi-fel write 0x43000000 spl/sunxi-spl-with-ecc.bin
> > sunxi-fel exe 0x4a000000
> >
> > And on the board, once u-boot is running (assuming the NAND is already
> > erased):
> >
> > nand write.raw.noverify 0x43000000 0 40
> > nand write.raw.noverify 0x43000000 0x400000 40
> >
> > nand write 0x4a000000 0x800000 0xc0000
> >
> > I also encountered some weird bug in the private libgcc that prevents
> > U-Boot from loading. Disabling CONFIG_USE_PRIVATE_LIBGCC fixes that.
>
> What was the problem?
It has been reported here:
http://lists.denx.de/pipermail/u-boot/2016-August/264513.html
> >
> > Let me know what you think,
> > Maxime
> >
> > Boris Brezillon (1):
> > mtd: nand: add support for the TC58NVG2S0H chip
> >
> > Hans de Goede (1):
> > sunxi: Enable UBI and NAND support
> >
> > Maxime Ripard (5):
> > sunxi: Sync GR8 DTS and AXP209 with the kernel
> > tools: sunxi: Add spl image builder
> > nand: sunxi: Add options for the SPL NAND configuration
> > scripts: sunxi: Build an raw SPL image
> > sunxi: Add support for the CHIP Pro
> >
> > Makefile | 3 +-
> > arch/arm/dts/Makefile | 1 +-
> > arch/arm/dts/axp209.dtsi | 6 +-
> > arch/arm/dts/ntc-gr8-chip-pro.dts | 266 +++++++-
> > arch/arm/dts/ntc-gr8.dtsi | 1132 ++++++++++++++++++++++++++++++-
> > configs/CHIP_pro_defconfig | 27 +-
> > drivers/mtd/nand/Kconfig | 16 +-
> > drivers/mtd/nand/nand_ids.c | 3 +-
> > include/configs/sunxi-common.h | 26 +-
> > scripts/Makefile.spl | 12 +-
> > tools/.gitignore | 1 +-
> > tools/Makefile | 1 +-
> > tools/sunxi-spl-image-builder.c | 1113 +++++++++++++++++++++++++++++-
> > 13 files changed, 2603 insertions(+), 4 deletions(-)
> > create mode 100644 arch/arm/dts/ntc-gr8-chip-pro.dts
> > create mode 100644 arch/arm/dts/ntc-gr8.dtsi
> > create mode 100644 configs/CHIP_pro_defconfig
> > create mode 100644 tools/sunxi-spl-image-builder.c
> >
> > base-commit: d8bdfc80da39211d95f10d24e79f2e867305f71b
>
> Can you please add a README file, where the above things are explained?
Sure, where do you want me to put it? in doc/README.* or somewhere
else?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161109/81e15a11/attachment.sig>
^ permalink raw reply
* Re: [PATCH 1/2] i2c: octeon: Fix register access
From: Jan Glauber @ 2016-11-09 14:43 UTC (permalink / raw)
To: Paul Burton; +Cc: linux-i2c, linux-mips, David Daney, Wolfram Sang, stable
In-Reply-To: <10136944.jCslgNClvG@np-p-burton>
On Wed, Nov 09, 2016 at 02:09:38PM +0000, Paul Burton wrote:
> On Tuesday, 8 November 2016 08:13:37 GMT Jan Glauber wrote:
> > On Mon, Nov 07, 2016 at 08:09:20PM +0000, Paul Burton wrote:
> > > Commit 70121f7f3725 ("i2c: octeon: thunderx: Limit register access
> > > retries") attempted to replace potentially infinite loops with ones
> > > which will time out using readq_poll_timeout, but in doing so it
> > > inverted the condition for exiting this loop.
> > >
> > > Tested on a Rhino Labs UTM-8 with Octeon CN7130.
> > >
> > > Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> > > Cc: Jan Glauber <jglauber@cavium.com>
> > > Cc: David Daney <david.daney@cavium.com>
> > > Cc: Wolfram Sang <wsa@the-dreams.de>
> > > Cc: linux-i2c@vger.kernel.org
> > >
> > > ---
> >
> > Acked-by: Jan Glauber <jglauber@cavium.com>
> >
> > Thanks for spotting this. I think this should go into stable too for
> > 4.8, so adding Cc: stable@vger.kernel.org.
>
> Hi Jan,
>
> ...but the bad patch was only merged for v4.9-rc1?
true, I've misread it.
> Thanks,
> Paul
>
> >
> > > drivers/i2c/busses/i2c-octeon-core.h | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-octeon-core.h
> > > b/drivers/i2c/busses/i2c-octeon-core.h index 1db7c83..d980406 100644
> > > --- a/drivers/i2c/busses/i2c-octeon-core.h
> > > +++ b/drivers/i2c/busses/i2c-octeon-core.h
> > > @@ -146,8 +146,9 @@ static inline void octeon_i2c_reg_write(struct
> > > octeon_i2c *i2c, u64 eop_reg, u8>
> > > __raw_writeq(SW_TWSI_V | eop_reg | data, i2c->twsi_base +
> SW_TWSI(i2c));
> > >
> > > - readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp, tmp &
> SW_TWSI_V,
> > > - I2C_OCTEON_EVENT_WAIT, i2c->adap.timeout);
> > > + readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > > + i2c->adap.timeout);
> > >
> > > }
> > >
> > > #define octeon_i2c_ctl_write(i2c, val) \
> > >
> > > @@ -173,7 +174,7 @@ static inline int octeon_i2c_reg_read(struct
> > > octeon_i2c *i2c, u64 eop_reg,>
> > > __raw_writeq(SW_TWSI_V | eop_reg | SW_TWSI_R, i2c->twsi_base +
> > > SW_TWSI(i2c));
> > >
> > > ret = readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > >
> > > - tmp & SW_TWSI_V, I2C_OCTEON_EVENT_WAIT,
> > > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > >
> > > i2c->adap.timeout);
> > >
> > > if (error)
> > >
> > > *error = ret;
>
^ permalink raw reply
* Re: [PATCH 1/2] i2c: octeon: Fix register access
From: Jan Glauber @ 2016-11-09 14:43 UTC (permalink / raw)
To: Paul Burton; +Cc: linux-i2c, linux-mips, David Daney, Wolfram Sang, stable
In-Reply-To: <10136944.jCslgNClvG@np-p-burton>
On Wed, Nov 09, 2016 at 02:09:38PM +0000, Paul Burton wrote:
> On Tuesday, 8 November 2016 08:13:37 GMT Jan Glauber wrote:
> > On Mon, Nov 07, 2016 at 08:09:20PM +0000, Paul Burton wrote:
> > > Commit 70121f7f3725 ("i2c: octeon: thunderx: Limit register access
> > > retries") attempted to replace potentially infinite loops with ones
> > > which will time out using readq_poll_timeout, but in doing so it
> > > inverted the condition for exiting this loop.
> > >
> > > Tested on a Rhino Labs UTM-8 with Octeon CN7130.
> > >
> > > Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> > > Cc: Jan Glauber <jglauber@cavium.com>
> > > Cc: David Daney <david.daney@cavium.com>
> > > Cc: Wolfram Sang <wsa@the-dreams.de>
> > > Cc: linux-i2c@vger.kernel.org
> > >
> > > ---
> >
> > Acked-by: Jan Glauber <jglauber@cavium.com>
> >
> > Thanks for spotting this. I think this should go into stable too for
> > 4.8, so adding Cc: stable@vger.kernel.org.
>
> Hi Jan,
>
> ...but the bad patch was only merged for v4.9-rc1?
true, I've misread it.
> Thanks,
> Paul
>
> >
> > > drivers/i2c/busses/i2c-octeon-core.h | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-octeon-core.h
> > > b/drivers/i2c/busses/i2c-octeon-core.h index 1db7c83..d980406 100644
> > > --- a/drivers/i2c/busses/i2c-octeon-core.h
> > > +++ b/drivers/i2c/busses/i2c-octeon-core.h
> > > @@ -146,8 +146,9 @@ static inline void octeon_i2c_reg_write(struct
> > > octeon_i2c *i2c, u64 eop_reg, u8>
> > > __raw_writeq(SW_TWSI_V | eop_reg | data, i2c->twsi_base +
> SW_TWSI(i2c));
> > >
> > > - readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp, tmp &
> SW_TWSI_V,
> > > - I2C_OCTEON_EVENT_WAIT, i2c->adap.timeout);
> > > + readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > > + i2c->adap.timeout);
> > >
> > > }
> > >
> > > #define octeon_i2c_ctl_write(i2c, val) \
> > >
> > > @@ -173,7 +174,7 @@ static inline int octeon_i2c_reg_read(struct
> > > octeon_i2c *i2c, u64 eop_reg,>
> > > __raw_writeq(SW_TWSI_V | eop_reg | SW_TWSI_R, i2c->twsi_base +
> > > SW_TWSI(i2c));
> > >
> > > ret = readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > >
> > > - tmp & SW_TWSI_V, I2C_OCTEON_EVENT_WAIT,
> > > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > >
> > > i2c->adap.timeout);
> > >
> > > if (error)
> > >
> > > *error = ret;
>
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
From: Andre Przywara @ 2016-11-09 14:43 UTC (permalink / raw)
To: Andrew Jones
Cc: kvm, kvmarm, qemu-devel, qemu-arm, peter.maydell, marc.zyngier,
eric.auger, pbonzini, alex.bennee, christoffer.dall
In-Reply-To: <20161109130815.6gploizgpmfdmmbw@kamzik.brq.redhat.com>
Hi,
On 09/11/16 13:08, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 12:35:48PM +0000, Andre Przywara wrote:
> [...]
>>> diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
>>> new file mode 100644
>>> index 000000000000..03321f8c860f
>>> --- /dev/null
>>> +++ b/lib/arm/asm/gic-v3.h
>>> @@ -0,0 +1,92 @@
>>> +/*
>>> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
>>> + *
>>> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
>>> + *
>>> + * This work is licensed under the terms of the GNU LGPL, version 2.
>>> + */
>>> +#ifndef _ASMARM_GIC_V3_H_
>>> +#define _ASMARM_GIC_V3_H_
>>> +
>>> +#ifndef _ASMARM_GIC_H_
>>> +#error Do not directly include <asm/gic-v3.h>. Include <asm/gic.h>
>>> +#endif
>>> +
>>> +#define GICD_CTLR 0x0000
>>> +#define GICD_TYPER 0x0004
>>
>> So if we share the distributor register definition with GICv2, these
>> shouldn't be here, but in gic.h.
>> But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
>>
>> Now this gets interesting with your wish to both share the definitions
>> for the GICv2 and GICv3 distributors, but also stick to the names the
>> kernel uses (because they differ between the two) ;-)
>> So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
>> for instance.
>
> Well, we just have the same offset with two names (giving us two
> symbols to grep). I put them here, vs. asm/gic.h, because the kernel
> only uses theses symbols for gicv3. Now, nothing stops a unit test
> from using them with gicv2 tests, though, because unit tests include
> gic.h, which includes both gic-v2.h and gic-v3.h, and thus it gets
> both. I know, it's sounding messy... Shouldn't we post some churn to
> the kernel? :-)
Well, on top of that the distributor registers are slightly different
(check CTLR and TYPER, for instance). So it's churn plus a stretch, I
guess Marc won't like that.
So if greppability is important, should we revert to separate
definitions in separate header files then, like in v3?
I don't think we actually share _code_ between the two GIC revisions, do we?
> Note, I tried to only add defines to asm/gic.h that are actually
> shared in the kernel between v2 and v3, e.g. GIC_DIST_ENABLE_SET.
Huh? GICv3 uses GICD_ISENABLER for that register.
> Actually, GIC_DIST_CTRL and GIC_DIST_CTR may be the only exceptions
> we have so far.
Note that it's GIC_DIST_CTLR (L and R swapped), one reason more to dump
_CTR ;-)
>>
>>> +#define GICD_IGROUPR 0x0080
>>> +
>>> +#define GICD_CTLR_RWP (1U << 31)
>>> +#define GICD_CTLR_ARE_NS (1U << 4)
>>> +#define GICD_CTLR_ENABLE_G1A (1U << 1)
>>> +#define GICD_CTLR_ENABLE_G1 (1U << 0)
>>> +
>>> +#define GICR_TYPER 0x0008
>>> +#define GICR_IGROUPR0 GICD_IGROUPR
>>> +#define GICR_TYPER_LAST (1U << 4)
>>> +
>>> +
>>> +#include <asm/arch_gicv3.h>
>>> +
>>> +#ifndef __ASSEMBLY__
>>> +#include <asm/setup.h>
>>> +#include <asm/smp.h>
>>> +#include <asm/processor.h>
>>> +#include <asm/io.h>
>>> +
>>> +struct gicv3_data {
>>> + void *dist_base;
>>> + void *redist_base[NR_CPUS];
>>> + unsigned int irq_nr;
>>> +};
>>> +extern struct gicv3_data gicv3_data;
>>> +
>>> +#define gicv3_dist_base() (gicv3_data.dist_base)
>>> +#define gicv3_redist_base() (gicv3_data.redist_base[smp_processor_id()])
>>> +#define gicv3_sgi_base() (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
>>> +
>>> +extern int gicv3_init(void);
>>> +extern void gicv3_enable_defaults(void);
>>> +
>>> +static inline void gicv3_do_wait_for_rwp(void *base)
>>> +{
>>> + int count = 100000; /* 1s */
>>> +
>>> + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
>>> + if (!--count) {
>>> + printf("GICv3: RWP timeout!\n");
>>> + abort();
>>> + }
>>> + cpu_relax();
>>> + udelay(10);
>>> + };
>>> +}
>>> +
>>> +static inline void gicv3_dist_wait_for_rwp(void)
>>> +{
>>> + gicv3_do_wait_for_rwp(gicv3_dist_base());
>>> +}
>>> +
>>> +static inline void gicv3_redist_wait_for_rwp(void)
>>> +{
>>> + gicv3_do_wait_for_rwp(gicv3_redist_base());
>>> +}
>>> +
>>> +static inline u32 mpidr_compress(u64 mpidr)
>>> +{
>>> + u64 compressed = mpidr & MPIDR_HWID_BITMASK;
>>> +
>>> + compressed = (((compressed >> 32) & 0xff) << 24) | compressed;
>>> + return compressed;
>>> +}
>>> +
>>> +static inline u64 mpidr_uncompress(u32 compressed)
>>> +{
>>> + u64 mpidr = ((u64)compressed >> 24) << 32;
>>> +
>>> + mpidr |= compressed & MPIDR_HWID_BITMASK;
>>> + return mpidr;
>>> +}
>>> +
>>> +#endif /* !__ASSEMBLY__ */
>>> +#endif /* _ASMARM_GIC_V3_H_ */
>>> diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
>>> index 328e078a9ae1..4897bc592cdd 100644
>>> --- a/lib/arm/asm/gic.h
>>> +++ b/lib/arm/asm/gic.h
>>> @@ -7,6 +7,7 @@
>>> #define _ASMARM_GIC_H_
>>>
>>> #include <asm/gic-v2.h>
>>> +#include <asm/gic-v3.h>
>>>
>>> #define GIC_CPU_CTRL 0x00
>>> #define GIC_CPU_PRIMASK 0x04
>>> diff --git a/lib/arm/gic.c b/lib/arm/gic.c
>>> index 91d78c9a0cc2..af58a11ea13e 100644
>>> --- a/lib/arm/gic.c
>>> +++ b/lib/arm/gic.c
>>> @@ -8,9 +8,11 @@
>>> #include <asm/io.h>
>>>
>>> struct gicv2_data gicv2_data;
>>> +struct gicv3_data gicv3_data;
>>>
>>> /*
>>> * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
>>> + * Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
>>> */
>>> static bool
>>> gic_get_dt_bases(const char *compatible, void **base1, void **base2)
>>> @@ -48,10 +50,18 @@ int gicv2_init(void)
>>> &gicv2_data.dist_base, &gicv2_data.cpu_base);
>>> }
>>>
>>> +int gicv3_init(void)
>>> +{
>>> + return gic_get_dt_bases("arm,gic-v3", &gicv3_data.dist_base,
>>> + &gicv3_data.redist_base[0]);
>>> +}
>>> +
>>> int gic_init(void)
>>> {
>>> if (gicv2_init())
>>> return 2;
>>> + else if (gicv3_init())
>>> + return 3;
>>> return 0;
>>> }
>>>
>>> @@ -73,3 +83,49 @@ void gicv2_enable_defaults(void)
>>> writel(GICC_INT_PRI_THRESHOLD, cpu_base + GIC_CPU_PRIMASK);
>>> writel(GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
>>> }
>>> +
>>> +void gicv3_set_redist_base(void)
>>> +{
>>> + u32 aff = mpidr_compress(get_mpidr());
>>> + void *ptr = gicv3_data.redist_base[0];
>>> + u64 typer;
>>> +
>>> + do {
>>> + typer = gicv3_read_typer(ptr + GICR_TYPER);
>>> + if ((typer >> 32) == aff) {
>>> + gicv3_redist_base() = ptr;
>>> + return;
>>> + }
>>> + ptr += SZ_64K * 2; /* skip RD_base and SGI_base */
>>> + } while (!(typer & GICR_TYPER_LAST));
>>> + assert(0);
>>> +}
>>> +
>>> +void gicv3_enable_defaults(void)
>>> +{
>>> + void *dist = gicv3_dist_base();
>>> + void *sgi_base;
>>> + unsigned int i;
>>> +
>>> + gicv3_data.irq_nr = GICD_TYPER_IRQS(readl(dist + GICD_TYPER));
>>> + if (gicv3_data.irq_nr > 1020)
>>> + gicv3_data.irq_nr = 1020;
>>> +
>>> + writel(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
>>> + dist + GICD_CTLR);
>>> + gicv3_dist_wait_for_rwp();
>>> +
>>> + if (!gicv3_redist_base())
>>> + gicv3_set_redist_base();
>>> + sgi_base = gicv3_sgi_base();
>>> +
>>> + writel(~0, sgi_base + GICR_IGROUPR0);
>>
>> This is mixing redist setup with distributor setup. Is it that what you
>> meant with:
>> " - simplify enable by not caring if we reinit the distributor [drew]"?
>
> Yes, but, TBH, I wasn't sure I could get away with it. I tested and it
> worked, and I figured you'd yell at me if I was wrong :-)
>
>>
>> Also if you set the group for the SGIs, you should set it for SPIs as
>> well (like the kernel does). This was done in v3 of the series.
>
> OK, I was also simplifying by removing everything and then adding stuff
> back until it worked :-) I can certainly add this back for completeness
> though.
So you did need IGROUP0?
Actually the VGIC implements a single security state, where those
registers are supposed to be RAZ/WI, if I get the spec correctly.
And KVM implements them as RAO/WI, both for GICR_IGROUPR0 and GICD_IGROUPRn.
But the kernel sets both of them up (because it drives real hardware),
so I'd trust Marc's wisdom more here ;-)
If we don't need this GROUPR setup for proper functionality, we could
move it from the generic setup into an actual test.
>> What about you finish the per-CPU setup first, then bail out with:
>>
>> if (smp_processor_id() != 0)
>> return;
>>
>> and then do the distributor setup (only on the first core).
>
> Sure, if it's necessary. I actually like not having to worry about
> a particular core or a particular order/number of times this enable
> gets called. Does it hurt to just do it each time?
Shouldn't really, so we could let it stay in there until someone
complains ...
Cheers,
Andre.
^ permalink raw reply
* [PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-6-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 8f72814..8a3c2a4 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1379,13 +1379,14 @@ static bool arm_smmu_capable(enum iommu_cap cap)
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1403,7 +1404,7 @@ static int arm_smmu_add_device(struct device *dev)
> if (ret)
> goto out_free;
> } else if (fwspec && fwspec->ops == &arm_smmu_ops) {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> } else {
> return -ENODEV;
> }
> @@ -2007,7 +2008,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> }
> }
>
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> platform_set_drvdata(pdev, smmu);
> arm_smmu_device_reset(smmu);
>
>
^ permalink raw reply
* Re: [PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:43 UTC (permalink / raw)
To: Lorenzo Pieralisi, iommu
Cc: Will Deacon, Hanjun Guo, Marc Zyngier, Joerg Roedel,
Rafael J. Wysocki, Tomasz Nowicki, Jon Masters, Eric Auger,
Sinan Kaya, Nate Watterson, Prem Mallappa, Dennis Chen,
linux-acpi, linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20161109141948.19244-6-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 8f72814..8a3c2a4 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1379,13 +1379,14 @@ static bool arm_smmu_capable(enum iommu_cap cap)
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1403,7 +1404,7 @@ static int arm_smmu_add_device(struct device *dev)
> if (ret)
> goto out_free;
> } else if (fwspec && fwspec->ops == &arm_smmu_ops) {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> } else {
> return -ENODEV;
> }
> @@ -2007,7 +2008,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> }
> }
>
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> platform_set_drvdata(pdev, smmu);
> arm_smmu_device_reset(smmu);
>
>
^ permalink raw reply
* Re: [PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage
From: Robin Murphy @ 2016-11-09 14:43 UTC (permalink / raw)
To: Lorenzo Pieralisi,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Marc Zyngier, Will Deacon,
Rafael J. Wysocki, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Sinan Kaya, Dennis Chen,
Tomasz Nowicki, Prem Mallappa, Jon Masters
In-Reply-To: <20161109141948.19244-6-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> Current ARM SMMU driver rely on the struct device.of_node pointer for
> device look-up and iommu_ops retrieval.
>
> In preparation for ACPI probing enablement, convert the driver to use
> the struct device.fwnode member for device and iommu_ops look-up so that
> the driver infrastructure can be used also on systems that do not
> associate an of_node pointer to a struct device (eg ACPI), making the
> device look-up and iommu_ops retrieval firmware agnostic.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> Tested-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Tested-by: Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
> Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Cc: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/iommu/arm-smmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 8f72814..8a3c2a4 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1379,13 +1379,14 @@ static bool arm_smmu_capable(enum iommu_cap cap)
>
> static int arm_smmu_match_node(struct device *dev, void *data)
> {
> - return dev->of_node == data;
> + return dev->fwnode == data;
> }
>
> -static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
> +static
> +struct arm_smmu_device *arm_smmu_get_by_fwnode(struct fwnode_handle *fwnode)
> {
> struct device *dev = driver_find_device(&arm_smmu_driver.driver, NULL,
> - np, arm_smmu_match_node);
> + fwnode, arm_smmu_match_node);
> put_device(dev);
> return dev ? dev_get_drvdata(dev) : NULL;
> }
> @@ -1403,7 +1404,7 @@ static int arm_smmu_add_device(struct device *dev)
> if (ret)
> goto out_free;
> } else if (fwspec && fwspec->ops == &arm_smmu_ops) {
> - smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
> + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
> } else {
> return -ENODEV;
> }
> @@ -2007,7 +2008,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> }
> }
>
> - of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> + fwnode_iommu_set_ops(dev->fwnode, &arm_smmu_ops);
> platform_set_drvdata(pdev, smmu);
> arm_smmu_device_reset(smmu);
>
>
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
From: Andre Przywara @ 2016-11-09 14:43 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, marc.zyngier, qemu-devel, qemu-arm, pbonzini, kvmarm
In-Reply-To: <20161109130815.6gploizgpmfdmmbw@kamzik.brq.redhat.com>
Hi,
On 09/11/16 13:08, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 12:35:48PM +0000, Andre Przywara wrote:
> [...]
>>> diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
>>> new file mode 100644
>>> index 000000000000..03321f8c860f
>>> --- /dev/null
>>> +++ b/lib/arm/asm/gic-v3.h
>>> @@ -0,0 +1,92 @@
>>> +/*
>>> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
>>> + *
>>> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
>>> + *
>>> + * This work is licensed under the terms of the GNU LGPL, version 2.
>>> + */
>>> +#ifndef _ASMARM_GIC_V3_H_
>>> +#define _ASMARM_GIC_V3_H_
>>> +
>>> +#ifndef _ASMARM_GIC_H_
>>> +#error Do not directly include <asm/gic-v3.h>. Include <asm/gic.h>
>>> +#endif
>>> +
>>> +#define GICD_CTLR 0x0000
>>> +#define GICD_TYPER 0x0004
>>
>> So if we share the distributor register definition with GICv2, these
>> shouldn't be here, but in gic.h.
>> But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
>>
>> Now this gets interesting with your wish to both share the definitions
>> for the GICv2 and GICv3 distributors, but also stick to the names the
>> kernel uses (because they differ between the two) ;-)
>> So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
>> for instance.
>
> Well, we just have the same offset with two names (giving us two
> symbols to grep). I put them here, vs. asm/gic.h, because the kernel
> only uses theses symbols for gicv3. Now, nothing stops a unit test
> from using them with gicv2 tests, though, because unit tests include
> gic.h, which includes both gic-v2.h and gic-v3.h, and thus it gets
> both. I know, it's sounding messy... Shouldn't we post some churn to
> the kernel? :-)
Well, on top of that the distributor registers are slightly different
(check CTLR and TYPER, for instance). So it's churn plus a stretch, I
guess Marc won't like that.
So if greppability is important, should we revert to separate
definitions in separate header files then, like in v3?
I don't think we actually share _code_ between the two GIC revisions, do we?
> Note, I tried to only add defines to asm/gic.h that are actually
> shared in the kernel between v2 and v3, e.g. GIC_DIST_ENABLE_SET.
Huh? GICv3 uses GICD_ISENABLER for that register.
> Actually, GIC_DIST_CTRL and GIC_DIST_CTR may be the only exceptions
> we have so far.
Note that it's GIC_DIST_CTLR (L and R swapped), one reason more to dump
_CTR ;-)
>>
>>> +#define GICD_IGROUPR 0x0080
>>> +
>>> +#define GICD_CTLR_RWP (1U << 31)
>>> +#define GICD_CTLR_ARE_NS (1U << 4)
>>> +#define GICD_CTLR_ENABLE_G1A (1U << 1)
>>> +#define GICD_CTLR_ENABLE_G1 (1U << 0)
>>> +
>>> +#define GICR_TYPER 0x0008
>>> +#define GICR_IGROUPR0 GICD_IGROUPR
>>> +#define GICR_TYPER_LAST (1U << 4)
>>> +
>>> +
>>> +#include <asm/arch_gicv3.h>
>>> +
>>> +#ifndef __ASSEMBLY__
>>> +#include <asm/setup.h>
>>> +#include <asm/smp.h>
>>> +#include <asm/processor.h>
>>> +#include <asm/io.h>
>>> +
>>> +struct gicv3_data {
>>> + void *dist_base;
>>> + void *redist_base[NR_CPUS];
>>> + unsigned int irq_nr;
>>> +};
>>> +extern struct gicv3_data gicv3_data;
>>> +
>>> +#define gicv3_dist_base() (gicv3_data.dist_base)
>>> +#define gicv3_redist_base() (gicv3_data.redist_base[smp_processor_id()])
>>> +#define gicv3_sgi_base() (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
>>> +
>>> +extern int gicv3_init(void);
>>> +extern void gicv3_enable_defaults(void);
>>> +
>>> +static inline void gicv3_do_wait_for_rwp(void *base)
>>> +{
>>> + int count = 100000; /* 1s */
>>> +
>>> + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
>>> + if (!--count) {
>>> + printf("GICv3: RWP timeout!\n");
>>> + abort();
>>> + }
>>> + cpu_relax();
>>> + udelay(10);
>>> + };
>>> +}
>>> +
>>> +static inline void gicv3_dist_wait_for_rwp(void)
>>> +{
>>> + gicv3_do_wait_for_rwp(gicv3_dist_base());
>>> +}
>>> +
>>> +static inline void gicv3_redist_wait_for_rwp(void)
>>> +{
>>> + gicv3_do_wait_for_rwp(gicv3_redist_base());
>>> +}
>>> +
>>> +static inline u32 mpidr_compress(u64 mpidr)
>>> +{
>>> + u64 compressed = mpidr & MPIDR_HWID_BITMASK;
>>> +
>>> + compressed = (((compressed >> 32) & 0xff) << 24) | compressed;
>>> + return compressed;
>>> +}
>>> +
>>> +static inline u64 mpidr_uncompress(u32 compressed)
>>> +{
>>> + u64 mpidr = ((u64)compressed >> 24) << 32;
>>> +
>>> + mpidr |= compressed & MPIDR_HWID_BITMASK;
>>> + return mpidr;
>>> +}
>>> +
>>> +#endif /* !__ASSEMBLY__ */
>>> +#endif /* _ASMARM_GIC_V3_H_ */
>>> diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
>>> index 328e078a9ae1..4897bc592cdd 100644
>>> --- a/lib/arm/asm/gic.h
>>> +++ b/lib/arm/asm/gic.h
>>> @@ -7,6 +7,7 @@
>>> #define _ASMARM_GIC_H_
>>>
>>> #include <asm/gic-v2.h>
>>> +#include <asm/gic-v3.h>
>>>
>>> #define GIC_CPU_CTRL 0x00
>>> #define GIC_CPU_PRIMASK 0x04
>>> diff --git a/lib/arm/gic.c b/lib/arm/gic.c
>>> index 91d78c9a0cc2..af58a11ea13e 100644
>>> --- a/lib/arm/gic.c
>>> +++ b/lib/arm/gic.c
>>> @@ -8,9 +8,11 @@
>>> #include <asm/io.h>
>>>
>>> struct gicv2_data gicv2_data;
>>> +struct gicv3_data gicv3_data;
>>>
>>> /*
>>> * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
>>> + * Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
>>> */
>>> static bool
>>> gic_get_dt_bases(const char *compatible, void **base1, void **base2)
>>> @@ -48,10 +50,18 @@ int gicv2_init(void)
>>> &gicv2_data.dist_base, &gicv2_data.cpu_base);
>>> }
>>>
>>> +int gicv3_init(void)
>>> +{
>>> + return gic_get_dt_bases("arm,gic-v3", &gicv3_data.dist_base,
>>> + &gicv3_data.redist_base[0]);
>>> +}
>>> +
>>> int gic_init(void)
>>> {
>>> if (gicv2_init())
>>> return 2;
>>> + else if (gicv3_init())
>>> + return 3;
>>> return 0;
>>> }
>>>
>>> @@ -73,3 +83,49 @@ void gicv2_enable_defaults(void)
>>> writel(GICC_INT_PRI_THRESHOLD, cpu_base + GIC_CPU_PRIMASK);
>>> writel(GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
>>> }
>>> +
>>> +void gicv3_set_redist_base(void)
>>> +{
>>> + u32 aff = mpidr_compress(get_mpidr());
>>> + void *ptr = gicv3_data.redist_base[0];
>>> + u64 typer;
>>> +
>>> + do {
>>> + typer = gicv3_read_typer(ptr + GICR_TYPER);
>>> + if ((typer >> 32) == aff) {
>>> + gicv3_redist_base() = ptr;
>>> + return;
>>> + }
>>> + ptr += SZ_64K * 2; /* skip RD_base and SGI_base */
>>> + } while (!(typer & GICR_TYPER_LAST));
>>> + assert(0);
>>> +}
>>> +
>>> +void gicv3_enable_defaults(void)
>>> +{
>>> + void *dist = gicv3_dist_base();
>>> + void *sgi_base;
>>> + unsigned int i;
>>> +
>>> + gicv3_data.irq_nr = GICD_TYPER_IRQS(readl(dist + GICD_TYPER));
>>> + if (gicv3_data.irq_nr > 1020)
>>> + gicv3_data.irq_nr = 1020;
>>> +
>>> + writel(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
>>> + dist + GICD_CTLR);
>>> + gicv3_dist_wait_for_rwp();
>>> +
>>> + if (!gicv3_redist_base())
>>> + gicv3_set_redist_base();
>>> + sgi_base = gicv3_sgi_base();
>>> +
>>> + writel(~0, sgi_base + GICR_IGROUPR0);
>>
>> This is mixing redist setup with distributor setup. Is it that what you
>> meant with:
>> " - simplify enable by not caring if we reinit the distributor [drew]"?
>
> Yes, but, TBH, I wasn't sure I could get away with it. I tested and it
> worked, and I figured you'd yell at me if I was wrong :-)
>
>>
>> Also if you set the group for the SGIs, you should set it for SPIs as
>> well (like the kernel does). This was done in v3 of the series.
>
> OK, I was also simplifying by removing everything and then adding stuff
> back until it worked :-) I can certainly add this back for completeness
> though.
So you did need IGROUP0?
Actually the VGIC implements a single security state, where those
registers are supposed to be RAZ/WI, if I get the spec correctly.
And KVM implements them as RAO/WI, both for GICR_IGROUPR0 and GICD_IGROUPRn.
But the kernel sets both of them up (because it drives real hardware),
so I'd trust Marc's wisdom more here ;-)
If we don't need this GROUPR setup for proper functionality, we could
move it from the generic setup into an actual test.
>> What about you finish the per-CPU setup first, then bail out with:
>>
>> if (smp_processor_id() != 0)
>> return;
>>
>> and then do the distributor setup (only on the first core).
>
> Sure, if it's necessary. I actually like not having to worry about
> a particular core or a particular order/number of times this enable
> gets called. Does it hurt to just do it each time?
Shouldn't really, so we could let it stay in there until someone
complains ...
Cheers,
Andre.
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Daniel P. Berrange @ 2016-11-09 14:42 UTC (permalink / raw)
To: Dave Anderson; +Cc: Dave Young, bhe, lersek, qemu-devel
In-Reply-To: <1365301332.14030682.1478702168917.JavaMail.zimbra@redhat.com>
On Wed, Nov 09, 2016 at 09:36:08AM -0500, Dave Anderson wrote:
>
>
> ----- Original Message -----
> > On 11/09/16 at 11:58am, Wen Congyang wrote:
> > > On 11/09/2016 11:17 AM, Dave Young wrote:
> > > > Drop qiaonuohan, seems the mail address is wrong..
> > > >
> > > > On 11/09/16 at 11:01am, Dave Young wrote:
> > > >> Hi,
> > > >>
> > > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> > > >> addresses, we had some effort to support kexec/kdump so that crash
> > > >> utility can still works in case crashed kernel has kaslr enabled.
> > > >>
> > > >> But according to Dave Anderson virsh dump does not work, quoted messages
> > > >> from Dave below:
> > > >>
> > > >> """
> > > >> with virsh dump, there's no way of even knowing that KASLR
> > > >> has randomized the kernel __START_KERNEL_map region, because there is no
> > > >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
> > > >> vmcoreinfo data to compare against the vmlinux file symbol value.
> > > >> Unless virsh dump can export some basic virtual memory data, which
> > > >> they say it can't, I don't see how KASLR can ever be supported.
> > > >> """
> > > >>
> > > >> I assume virsh dump is using qemu guest memory dump facility so it
> > > >> should be first addressed in qemu. Thus post this query to qemu devel
> > > >> list. If this is not correct please let me know.
> > >
> > > IIRC, 'virsh dump --memory-only' uses dump-guest-memory, and 'virsh dump'
> > > uses migration to dump.
> >
> > Do they need different fixes? Dave, I guess you mean --memory-only, but
> > could you clarify and confirm it?
>
> As I understand it, the "--memory-only" option uses a new "dump-guest-memory"
> QEMU monitor command that creates an ELF kdump vmcore clone.
IIRC, the use of the traditional 'virsh dump' (which just splats out the
QEMU migration data stream) is no longer supported with crash and everyone
should be using the --memory-only flag to ensure the ELF format core.
IOW, I think we can just ignore the historical migration based dump and
focus exclusively on the dump-guest-memory based impl.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply
* Re: [PATCH 3/3] ipmi/bt-bmc: add a sysfs file to configure a maximum response time
From: Cédric Le Goater @ 2016-11-09 14:42 UTC (permalink / raw)
To: minyard, openipmi-developer, Joel Stanley
Cc: devicetree, Rob Herring, linux-arm-kernel, Arnd Bergmann
In-Reply-To: <3a1f8e6d-c935-3404-ffa0-81b19d170731@acm.org>
On 11/07/2016 07:37 PM, Corey Minyard wrote:
> Sorry, I was at Plumbers and extra busy with other stuff. Just getting around to reviewing this.
>
> On 11/02/2016 02:57 AM, Cédric Le Goater wrote:
>> We could also use an ioctl for that purpose. sysfs seems a better
>> approach.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index e751e4a754b7..d7146f0e900e 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -84,6 +84,33 @@ struct bt_bmc {
>> static atomic_t open_count = ATOMIC_INIT(0);
>> +static ssize_t bt_bmc_show_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> +
>> + return snprintf(buf, PAGE_SIZE - 1, "%d\n", bt_bmc->response_time);
>> +}
>> +
>> +static ssize_t bt_bmc_set_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> + unsigned long val;
>> + int err;
>> +
>> + err = kstrtoul(buf, 0, &val);
>> + if (err)
>> + return err;
>> + bt_bmc->response_time = val;
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR(response_time, 0644,
>> + bt_bmc_show_response_time, bt_bmc_set_response_time);
>> +
>> static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
>> {
>> return ioread8(bt_bmc->base + reg);
>> @@ -572,6 +599,10 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> + rc = device_create_file(&pdev->dev, &dev_attr_response_time);
>> + if (rc)
>> + dev_warn(&pdev->dev, "can't create response_time file\n");
>> +
>
> You added an extra space here.
yes. I will remove it in the next version.
The patch raises a few questions on the "BT Interface Capabilities" :
- should we use sysfs or a specific ioctl to configure the driver ?
- should the driver handle directly the response to the "Get BT
Interface Capabilities" command ?
What is your opinion ?
Thanks,
C.
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] ipmi/bt-bmc: add a sysfs file to configure a maximum response time
From: Cédric Le Goater @ 2016-11-09 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3a1f8e6d-c935-3404-ffa0-81b19d170731@acm.org>
On 11/07/2016 07:37 PM, Corey Minyard wrote:
> Sorry, I was at Plumbers and extra busy with other stuff. Just getting around to reviewing this.
>
> On 11/02/2016 02:57 AM, C?dric Le Goater wrote:
>> We could also use an ioctl for that purpose. sysfs seems a better
>> approach.
>>
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index e751e4a754b7..d7146f0e900e 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -84,6 +84,33 @@ struct bt_bmc {
>> static atomic_t open_count = ATOMIC_INIT(0);
>> +static ssize_t bt_bmc_show_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> +
>> + return snprintf(buf, PAGE_SIZE - 1, "%d\n", bt_bmc->response_time);
>> +}
>> +
>> +static ssize_t bt_bmc_set_response_time(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(dev);
>> + unsigned long val;
>> + int err;
>> +
>> + err = kstrtoul(buf, 0, &val);
>> + if (err)
>> + return err;
>> + bt_bmc->response_time = val;
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR(response_time, 0644,
>> + bt_bmc_show_response_time, bt_bmc_set_response_time);
>> +
>> static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
>> {
>> return ioread8(bt_bmc->base + reg);
>> @@ -572,6 +599,10 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> + rc = device_create_file(&pdev->dev, &dev_attr_response_time);
>> + if (rc)
>> + dev_warn(&pdev->dev, "can't create response_time file\n");
>> +
>
> You added an extra space here.
yes. I will remove it in the next version.
The patch raises a few questions on the "BT Interface Capabilities" :
- should we use sysfs or a specific ioctl to configure the driver ?
- should the driver handle directly the response to the "Get BT
Interface Capabilities" command ?
What is your opinion ?
Thanks,
C.
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>
>
^ permalink raw reply
* Re: Postinsts question
From: Vuille, Martin (Martin) @ 2016-11-09 14:41 UTC (permalink / raw)
To: Burton, Ross, Khem Raj; +Cc: yocto@yoctoproject.org
In-Reply-To: <CAJTo0Lbd-K4aJFd5RFqa+hgrgjBZLz=TCzEDoA3-Qg+CtSbtdw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
Thanks Ross, Khem
It looks like we aren’t setting ‘read-only-rootfs’
Our images and init are very customized, so we missed that.
Will look into it.
Regards,
MV
From: Burton, Ross [mailto:ross.burton@intel.com]
Sent: November 09, 2016 08:19
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Postinsts question
On 8 November 2016 at 23:23, Vuille, Martin (Martin) <vmartin@avaya.com<mailto:vmartin@avaya.com>> wrote:
We are running with our rootfs mounted read-only.
Consequently, any postinsts that get deferred to first boot fail.
Is there a way to fail the build for any postinsts that can’t
be performed during the build and have to be deferred?
I was looking at some other selftests today and a test suggested that this already happens, and it's true.
If you add 'read-only-rootfs' to IMAGE_FEATURES then delayed postists are fatal:
ERROR: core-image-sato-base-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['postinst-test-delayed']
ERROR: core-image-sato-base-1.0-r0 do_rootfs: Function failed: do_rootfs
Ross
[-- Attachment #2: Type: text/html, Size: 6069 bytes --]
^ permalink raw reply
* Re: [PATCH] virtio: tx with can_push when VERSION_1 is set
From: Maxime Coquelin @ 2016-11-09 14:42 UTC (permalink / raw)
To: Pierre Pfister (ppfister); +Cc: dev@dpdk.org
In-Reply-To: <1FAE01C3-B03F-443A-A77C-579254A07E0E@cisco.com>
Hi Pierre,
On 11/09/2016 01:42 PM, Pierre Pfister (ppfister) wrote:
> Hello Maxime,
>
> Sorry for the late reply.
>
>
>> Le 8 nov. 2016 à 10:44, Maxime Coquelin <maxime.coquelin@redhat.com> a écrit :
>>
>> Hi Pierre,
>>
>> On 11/08/2016 10:31 AM, Pierre Pfister (ppfister) wrote:
>>> Current virtio driver advertises VERSION_1 support,
>>> but does not handle device's VERSION_1 support when
>>> sending packets (it looks for ANY_LAYOUT feature,
>>> which is absent).
>>>
>>> This patch enables 'can_push' in tx path when VERSION_1
>>> is advertised by the device.
>>>
>>> This significantly improves small packets forwarding rate
>>> towards devices advertising VERSION_1 feature.
>> I think it depends whether offloading is enabled or not.
>> If no offloading enabled, I measured significant drop.
>> Indeed, when no offloading is enabled, the Tx path in Virtio
>> does not access the virtio header before your patch, as the header is memset to zero at device init time.
>> With your patch, it gets memset to zero at every transmit in the hot
>> path.
>
> Right. On the virtio side that is true, but on the device side, we have to access the header anyway.
No more now, if no offload features have been negotiated.
I have done a patch that landed in v16.11 not to parse header in this case.
That said, we still have to access its descriptor.
> And accessing two descriptors (with the address resolution and memory fetch which comes with it)
> is a costy operation compared to a single one.
> In the case indirect descriptors are used, this is 1 desc access instead or 3.
> And in the case chained descriptors are used, this doubles the number of packets that you can put in your queue.
>
> Those are the results in my PHY -> VM (testpmd) -> PHY setup
> Traffic is flowing bidirectionally. Numbers are for lossless-rates.
>
> When chained buffers are used for dpdk's TX: 2x2.13Mpps
> When indirect descriptors are used for dpdk's TX: 2x2.38Mpps
> When shallow buffers are used for dpdk's TX (with this patch): 2x2.42Mpps
When I tried it, I also did PVP 0% benchmark, and I got opposite
results. Chained and indirect cases were significantly better.
My PVP setup was using a single NIC and single Virtio PMD, and NIC2VM
forwarding was IO mode done with testpmd on host, and Rx->Tx forwarding
was macswap mode on guest side.
That said, if I'm the only one seeing a performance regression, maybe
something is wrong with my setup.
Yuanhan, did you made some benchmarks when you implemented your
any_layout enabling series?
>
> I must also note that qemu 2.5 does not seem to deal with VERSION_1 and ANY_LAYOUT correctly.
> The patch I am proposing here works for qemu 2.7, but with qemu 2.5, testpmd still behaves as if ANY_LAYOUT (or VERSION_1) was not available. This is not catastrophic. But just note that you will not see performance in some cases with qemu 2.5.
Thanks for the info.
Regards,
Maxime
^ permalink raw reply
* Re: linux-next: build failure after merge of the sound-asoc tree
From: Mark Brown @ 2016-11-09 14:41 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Stephen Rothwell, Liam Girdwood, linux-next, linux-kernel
In-Reply-To: <CAGb2v64S_YzHDOeRfHKRTrti8jZThuxfexRApjDAqzmJYR_N7Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
On Tue, Nov 08, 2016 at 11:18:29AM +0800, Chen-Yu Tsai wrote:
> sound-asoc is missing patch
> ASoC: sun4i-codec: Add support for optional reset control to quirks
> http://www.spinics.net/lists/alsa-devel/msg56289.html
> which commit 8d9e4c9e993f ("ASoC: sun4i-codec: Add support for A31 playback
> through headphone output") depends on. This was part of the same series that
> I posted:
I don't have that...
> A new version of the remaining patches was posted yesterday:
> http://www.spinics.net/lists/alsa-devel/msg56443.html
Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH] weston: upgrade from 1.11.1 to 1.12.0
From: Fathi Boudra @ 2016-11-09 14:41 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LZhZi+hgbUvd87E413nEOKP3g5uGY2eqZB5yX2ydHZKGA@mail.gmail.com>
On 9 November 2016 at 14:15, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 8 November 2016 at 13:54, Fathi Boudra <fathi.boudra@linaro.org> wrote:
>>
>> FILES_${PN}-xwayland = "${libdir}/${BPN}/xwayland.so"
>
>
> Because you didn't fix this patch the weston-xwayland package is never
> built, buildhistory is huge and core-image-weston with X11 enabled doesn't
> build.
I'll spin a v2 with Jussi suggested split.
^ permalink raw reply
* Re: disable hugepages
From: Keren Hochman @ 2016-11-09 14:40 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: dev
In-Reply-To: <CAATJJ0LNAAbT9qnWgp-OtXeE-dX6irG0WxAwMW_euKiaVfEoVQ@mail.gmail.com>
I need this option only for testing. How can I use rte_mempool_create if I
use --no-huge?
Thank you, Keren
On Wed, Nov 9, 2016 at 3:40 PM, Christian Ehrhardt <
christian.ehrhardt@canonical.com> wrote:
>
> On Wed, Nov 9, 2016 at 1:55 PM, Keren Hochman <
> keren.hochman@lightcyber.com> wrote:
>
>> how can I create mempool without hugepages?My application is running on a
>> pcap file so no huge pages is needed ?
>>
>
> Not sure if that is what you really want (Debug use only), but in general
> no-huge is available as EAL arg
>
> From http://pktgen.readthedocs.io/en/latest/usage_eal.html :
>
> EAL options for DEBUG use only:
> --no-huge : Use malloc instead of hugetlbfs
>
>
>
>
^ permalink raw reply
* Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-09 14:40 UTC (permalink / raw)
To: Lorenzo Pieralisi, iommu
Cc: Will Deacon, Hanjun Guo, Joerg Roedel, Marc Zyngier,
Rafael J. Wysocki, Tomasz Nowicki, Jon Masters, Eric Auger,
Sinan Kaya, Nate Watterson, Prem Mallappa, Dennis Chen,
linux-acpi, linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20161109141948.19244-5-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> The of_iommu_{set/get}_ops() API is used to associate a device
> tree node with a specific set of IOMMU operations. The same
> kernel interface is required on systems booting with ACPI, where
> devices are not associated with a device tree node, therefore
> the interface requires generalization.
>
> The struct device fwnode member represents the fwnode token
> associated with the device and the struct it points at is firmware
> specific; regardless, it is initialized on both ACPI and DT systems
> and makes an ideal candidate to use it to associate a set of IOMMU
> operations to a given device, through its struct device.fwnode member
> pointer.
>
> Convert the DT specific of_iommu_{set/get}_ops() interface to
> use struct device.fwnode as a look-up token, making the interface
> usable on ACPI systems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/iommu/iommu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/of_iommu.c | 39 ---------------------------------------
> include/linux/iommu.h | 14 ++++++++++++++
> include/linux/of_iommu.h | 12 ++++++++++--
> 4 files changed, 66 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9a2f196..5c97c01 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1615,6 +1615,48 @@ int iommu_request_dm_for_dev(struct device *dev)
> return ret;
> }
>
> +struct iommu_fwentry {
:)
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + const struct iommu_ops *ops;
> +};
> +static LIST_HEAD(iommu_fwentry_list);
> +static DEFINE_SPINLOCK(iommu_fwentry_lock);
> +
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> + struct iommu_fwentry *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> +
> + if (WARN_ON(!iommu))
> + return;
> +
> + if (is_of_node(fwnode))
Nit: this check is actually redundant, since to_of_node() already does
the right thing and of_node_get() is NULL-safe - iommu_fwspec_init()
already works that way. On the other hand, though, it is perhaps more
intuitive to see it explicitly, and since to_of_node() is inline it
ought to result in the same object code (I've not checked, though).
Either way:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> + of_node_get(to_of_node(fwnode));
> +
> + INIT_LIST_HEAD(&iommu->list);
> + iommu->fwnode = fwnode;
> + iommu->ops = ops;
> + spin_lock(&iommu_fwentry_lock);
> + list_add_tail(&iommu->list, &iommu_fwentry_list);
> + spin_unlock(&iommu_fwentry_lock);
> +}
> +
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + struct iommu_fwentry *node;
> + const struct iommu_ops *ops = NULL;
> +
> + spin_lock(&iommu_fwentry_lock);
> + list_for_each_entry(node, &iommu_fwentry_list, list)
> + if (node->fwnode == fwnode) {
> + ops = node->ops;
> + break;
> + }
> + spin_unlock(&iommu_fwentry_lock);
> + return ops;
> +}
> +
> int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops)
> {
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5b82862..0f57ddc 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -struct of_iommu_node {
> - struct list_head list;
> - struct device_node *np;
> - const struct iommu_ops *ops;
> -};
> -static LIST_HEAD(of_iommu_list);
> -static DEFINE_SPINLOCK(of_iommu_lock);
> -
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> -{
> - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> -
> - if (WARN_ON(!iommu))
> - return;
> -
> - of_node_get(np);
> - INIT_LIST_HEAD(&iommu->list);
> - iommu->np = np;
> - iommu->ops = ops;
> - spin_lock(&of_iommu_lock);
> - list_add_tail(&iommu->list, &of_iommu_list);
> - spin_unlock(&of_iommu_lock);
> -}
> -
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> -{
> - struct of_iommu_node *node;
> - const struct iommu_ops *ops = NULL;
> -
> - spin_lock(&of_iommu_lock);
> - list_for_each_entry(node, &of_iommu_list, list)
> - if (node->np == np) {
> - ops = node->ops;
> - break;
> - }
> - spin_unlock(&of_iommu_lock);
> - return ops;
> -}
> -
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> struct of_phandle_args *iommu_spec = data;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 436dc21..15d5478 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -351,6 +351,9 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops);
> void iommu_fwspec_free(struct device *dev);
> int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops);
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode);
>
> #else /* CONFIG_IOMMU_API */
>
> @@ -580,6 +583,17 @@ static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> return -ENODEV;
> }
>
> +static inline void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> +}
> +
> +static inline
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + return NULL;
> +}
> +
> #endif /* CONFIG_IOMMU_API */
>
> #endif /* __LINUX_IOMMU_H */
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index e80b9c7..7681007 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -31,8 +31,16 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> +static inline void of_iommu_set_ops(struct device_node *np,
> + const struct iommu_ops *ops)
> +{
> + fwnode_iommu_set_ops(&np->fwnode, ops);
> +}
> +
> +static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> +{
> + return fwnode_iommu_get_ops(&np->fwnode);
> +}
>
> extern struct of_device_id __iommu_of_table;
>
>
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-09 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-5-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> The of_iommu_{set/get}_ops() API is used to associate a device
> tree node with a specific set of IOMMU operations. The same
> kernel interface is required on systems booting with ACPI, where
> devices are not associated with a device tree node, therefore
> the interface requires generalization.
>
> The struct device fwnode member represents the fwnode token
> associated with the device and the struct it points at is firmware
> specific; regardless, it is initialized on both ACPI and DT systems
> and makes an ideal candidate to use it to associate a set of IOMMU
> operations to a given device, through its struct device.fwnode member
> pointer.
>
> Convert the DT specific of_iommu_{set/get}_ops() interface to
> use struct device.fwnode as a look-up token, making the interface
> usable on ACPI systems.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/iommu/iommu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/of_iommu.c | 39 ---------------------------------------
> include/linux/iommu.h | 14 ++++++++++++++
> include/linux/of_iommu.h | 12 ++++++++++--
> 4 files changed, 66 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9a2f196..5c97c01 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1615,6 +1615,48 @@ int iommu_request_dm_for_dev(struct device *dev)
> return ret;
> }
>
> +struct iommu_fwentry {
:)
> + struct list_head list;
> + struct fwnode_handle *fwnode;
> + const struct iommu_ops *ops;
> +};
> +static LIST_HEAD(iommu_fwentry_list);
> +static DEFINE_SPINLOCK(iommu_fwentry_lock);
> +
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> + struct iommu_fwentry *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> +
> + if (WARN_ON(!iommu))
> + return;
> +
> + if (is_of_node(fwnode))
Nit: this check is actually redundant, since to_of_node() already does
the right thing and of_node_get() is NULL-safe - iommu_fwspec_init()
already works that way. On the other hand, though, it is perhaps more
intuitive to see it explicitly, and since to_of_node() is inline it
ought to result in the same object code (I've not checked, though).
Either way:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> + of_node_get(to_of_node(fwnode));
> +
> + INIT_LIST_HEAD(&iommu->list);
> + iommu->fwnode = fwnode;
> + iommu->ops = ops;
> + spin_lock(&iommu_fwentry_lock);
> + list_add_tail(&iommu->list, &iommu_fwentry_list);
> + spin_unlock(&iommu_fwentry_lock);
> +}
> +
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + struct iommu_fwentry *node;
> + const struct iommu_ops *ops = NULL;
> +
> + spin_lock(&iommu_fwentry_lock);
> + list_for_each_entry(node, &iommu_fwentry_list, list)
> + if (node->fwnode == fwnode) {
> + ops = node->ops;
> + break;
> + }
> + spin_unlock(&iommu_fwentry_lock);
> + return ops;
> +}
> +
> int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops)
> {
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5b82862..0f57ddc 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -struct of_iommu_node {
> - struct list_head list;
> - struct device_node *np;
> - const struct iommu_ops *ops;
> -};
> -static LIST_HEAD(of_iommu_list);
> -static DEFINE_SPINLOCK(of_iommu_lock);
> -
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> -{
> - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> -
> - if (WARN_ON(!iommu))
> - return;
> -
> - of_node_get(np);
> - INIT_LIST_HEAD(&iommu->list);
> - iommu->np = np;
> - iommu->ops = ops;
> - spin_lock(&of_iommu_lock);
> - list_add_tail(&iommu->list, &of_iommu_list);
> - spin_unlock(&of_iommu_lock);
> -}
> -
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> -{
> - struct of_iommu_node *node;
> - const struct iommu_ops *ops = NULL;
> -
> - spin_lock(&of_iommu_lock);
> - list_for_each_entry(node, &of_iommu_list, list)
> - if (node->np == np) {
> - ops = node->ops;
> - break;
> - }
> - spin_unlock(&of_iommu_lock);
> - return ops;
> -}
> -
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> struct of_phandle_args *iommu_spec = data;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 436dc21..15d5478 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -351,6 +351,9 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> const struct iommu_ops *ops);
> void iommu_fwspec_free(struct device *dev);
> int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops);
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode);
>
> #else /* CONFIG_IOMMU_API */
>
> @@ -580,6 +583,17 @@ static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> return -ENODEV;
> }
>
> +static inline void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> + const struct iommu_ops *ops)
> +{
> +}
> +
> +static inline
> +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> +{
> + return NULL;
> +}
> +
> #endif /* CONFIG_IOMMU_API */
>
> #endif /* __LINUX_IOMMU_H */
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index e80b9c7..7681007 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -31,8 +31,16 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>
> #endif /* CONFIG_OF_IOMMU */
>
> -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> +static inline void of_iommu_set_ops(struct device_node *np,
> + const struct iommu_ops *ops)
> +{
> + fwnode_iommu_set_ops(&np->fwnode, ops);
> +}
> +
> +static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> +{
> + return fwnode_iommu_get_ops(&np->fwnode);
> +}
>
> extern struct of_device_id __iommu_of_table;
>
>
^ permalink raw reply
* [PATCH v2 11/11] docs: Describe PVHv2's VCPU hotplug procedure
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v2:
* New patch
docs/misc/hvmlite.markdown | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..0045d22 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,15 @@ info structure that's passed at boot time (field rsdp_paddr).
Description of paravirtualized devices will come from XenStore, just as it's
done for HVM guests.
+
+## VCPU hotplug ##
+
+VCPU hotplug (e.g. 'xl vcpu-set <domain> <num_vcpus>') for PVHv2 guests
+follows ACPI model where change in domain's number of VCPUS (stored in
+arch_domain.avail_vcpus) results in an SCI being sent to the guest. The
+guest then executes DSDT's PRSC method, updating MADT enable status for
+the affected VCPU.
+
+This is achieved by having the toolstack call XEN_DOMCTL_set_avail_vcpus
+which sets appropriate bits in ACPI GPE0 enable and status registers followed
+by sending VIRQ_SCI to the guest.
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 10/11] pvh: Send an SCI on VCPU hotplug event
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
.. and update GPE0 registers.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v2:
* Use has_ioreq_cpuhp() instead of ioreq_gmfn.mask==0 as check
for PVH guest
xen/arch/x86/domctl.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index b736d4c..07c8247 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1443,6 +1443,18 @@ long arch_do_domctl(
break;
d->arch.avail_vcpus = num;
+
+ /*
+ * For PVH guests we need to send an SCI and set enable/status
+ * bits in GPE block (DSDT specifies _E02, so it's bit 2).
+ */
+ if ( is_hvm_domain(d) && !has_ioreq_cpuhp(d) )
+ {
+ d->arch.hvm_domain.acpi_io.gpe[2] =
+ d->arch.hvm_domain.acpi_io.gpe[0] = 4;
+ send_guest_vcpu_virq(d->vcpu[0], VIRQ_SCI);
+ }
+
ret = 0;
break;
}
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 09/11] events/x86: Define SCI virtual interrupt
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.
We also move VIRQ_MCA definition out of xen-mca.h to
keep all x86-specific VIRQ_ARCH_* in one place.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
xen/include/asm-x86/event.h | 3 ++-
xen/include/public/arch-x86/xen-mca.h | 2 --
xen/include/public/arch-x86/xen.h | 3 +++
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index a82062e..9cad8e3 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -38,9 +38,10 @@ static inline void local_event_delivery_enable(void)
vcpu_info(current, evtchn_upcall_mask) = 0;
}
-/* No arch specific virq definition now. Default to global. */
static inline int arch_virq_is_global(uint32_t virq)
{
+ if ( virq == VIRQ_SCI )
+ return 0;
return 1;
}
diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
index a97e821..b76c53c 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -91,8 +91,6 @@
#ifndef __ASSEMBLY__
-#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
-
/*
* Machine Check Architecure:
* structs are read-only and used to report all kinds of
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 350bc66..4750ba7 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -296,6 +296,9 @@ struct xen_arch_domainconfig {
};
#endif
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+#define VIRQ_SCI VIRQ_ARCH_1 /* V. (PVH) ACPI interrupt */
+
#endif /* !__ASSEMBLY__ */
/*
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
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.