* Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: tiejun.chen @ 2013-05-08 1:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <1367970043.3398.39@snotra>
On 05/08/2013 07:40 AM, Scott Wood wrote:
> On 05/07/2013 06:06:30 AM, Tiejun Chen wrote:
>> We also can direct ISI exception to Guest like DSI.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>> ---
>> arch/powerpc/kvm/booke_emulate.c | 3 +++
>> arch/powerpc/kvm/e500mc.c | 3 ++-
>> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> Are you seeing a real performance improvement from this? This will interfere
No. But after we reduce the exit to host, shouldn't this improve performance?
> somewhat with using the VF bit, if we were to ever do so, since VF only affects
Sorry, what is the VF you said?
Tiejun
^ permalink raw reply
* [PATCH] powerpc/rtas_flash: Fix validate_flash buffer overflow issue
From: Vasant Hegde @ 2013-05-08 2:54 UTC (permalink / raw)
To: benh, linuxppc-dev; +Cc: paulus, linux-kernel
ibm,validate-flash-image RTAS call output buffer contains 150 - 200
bytes of data on latest system. Presently we have output
buffer size as 64 bytes and we use sprintf to copy data from
RTAS buffer to local buffer. This causes kernel oops (see below
call trace).
This patch increases local buffer size to 256 and also uses
snprintf instead of sprintf to copy data from RTAS buffer.
Kernel call trace :
-------------------
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: nfs fscache lockd auth_rpcgss nfs_acl sunrpc fuse loop dm_mod ipv6 ipv6_lib usb_storage ehea(X) sr_mod qlge ses cdrom enclosure st be2net sg ext3 jbd mbcache usbhid hid ohci_hcd ehci_hcd usbcore qla2xxx usb_common sd_mod crc_t10dif scsi_dh_hp_sw scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh lpfc scsi_transport_fc scsi_tgt ipr(X) libata scsi_mod
Supported: Yes
NIP: 4520323031333130 LR: 4520323031333130 CTR: 0000000000000000
REGS: c0000001b91779b0 TRAP: 0400 Tainted: G X (3.0.13-0.27-ppc64)
MSR: 8000000040009032 <EE,ME,IR,DR> CR: 44022488 XER: 20000018
TASK = c0000001bca1aba0[4736] 'cat' THREAD: c0000001b9174000 CPU: 36
GPR00: 4520323031333130 c0000001b9177c30 c000000000f87c98 000000000000009b
GPR04: c0000001b9177c4a 000000000000000b 3520323031333130 2032303133313031
GPR08: 3133313031350a4d 000000000000009b 0000000000000000 c0000000003664a4
GPR12: 0000000022022448 c000000003ee6c00 0000000000000002 00000000100e8a90
GPR16: 00000000100cb9d8 0000000010093370 000000001001d310 0000000000000000
GPR20: 0000000000008000 00000000100fae60 000000000000005e 0000000000000000
GPR24: 0000000010129350 46573738302e3030 2046573738302e30 300a4d4720323031
GPR28: 333130313520554e 4b4e4f574e0a4d47 2032303133313031 3520323031333130
NIP [4520323031333130] 0x4520323031333130
LR [4520323031333130] 0x4520323031333130
Call Trace:
[c0000001b9177c30] [4520323031333130] 0x4520323031333130 (unreliable)
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
arch/powerpc/kernel/rtas_flash.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index 5b30224..2f3cdb0 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -89,6 +89,7 @@
/* Array sizes */
#define VALIDATE_BUF_SIZE 4096
+#define VALIDATE_MSG_LEN 256
#define RTAS_MSG_MAXLEN 64
/* Quirk - RTAS requires 4k list length and block size */
@@ -466,7 +467,7 @@ static void validate_flash(struct rtas_validate_flash_t *args_buf)
}
static int get_validate_flash_msg(struct rtas_validate_flash_t *args_buf,
- char *msg)
+ char *msg, int msglen)
{
int n;
@@ -474,7 +475,8 @@ static int get_validate_flash_msg(struct rtas_validate_flash_t *args_buf,
n = sprintf(msg, "%d\n", args_buf->update_results);
if ((args_buf->update_results >= VALIDATE_CUR_UNKNOWN) ||
(args_buf->update_results == VALIDATE_TMP_UPDATE))
- n += sprintf(msg + n, "%s\n", args_buf->buf);
+ n += snprintf(msg + n, msglen - n, "%s\n",
+ args_buf->buf);
} else {
n = sprintf(msg, "%d\n", args_buf->status);
}
@@ -486,11 +488,11 @@ static ssize_t validate_flash_read(struct file *file, char __user *buf,
{
struct rtas_validate_flash_t *const args_buf =
&rtas_validate_flash_data;
- char msg[RTAS_MSG_MAXLEN];
+ char msg[VALIDATE_MSG_LEN];
int msglen;
mutex_lock(&rtas_validate_flash_mutex);
- msglen = get_validate_flash_msg(args_buf, msg);
+ msglen = get_validate_flash_msg(args_buf, msg, VALIDATE_MSG_LEN);
mutex_unlock(&rtas_validate_flash_mutex);
return simple_read_from_buffer(buf, count, ppos, msg, msglen);
^ permalink raw reply related
* [PATCH] powerpc/powernv: Properly drop characters if console is closed
From: Benjamin Herrenschmidt @ 2013-05-08 4:15 UTC (permalink / raw)
To: linuxppc-dev list
If the firmware returns an error such as "closed" (or hardware
error), we should drop characters.
Currently we only do that when a firmware compatible with OPAL v2
APIs is detected, in the code that calls opal_console_write_buffer_space(),
which didn't exist with OPAL v1 (or didn't work).
However, when enabling early debug consoles, the flag indicating
that v2 is supported isn't set yet, causing us, in case of errors
or closed console, to spin forever.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/powernv/opal.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index ade4463..12d9846 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -144,6 +144,13 @@ int opal_put_chars(uint32_t vtermno, const char *data, int total_len)
rc == OPAL_BUSY_EVENT || rc == OPAL_SUCCESS)) {
len = total_len;
rc = opal_console_write(vtermno, &len, data);
+
+ /* Closed or other error drop */
+ if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
+ rc != OPAL_BUSY_EVENT) {
+ written = total_len;
+ break;
+ }
if (rc == OPAL_SUCCESS) {
total_len -= len;
data += len;
^ permalink raw reply related
* RE: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: Caraman Mihai Claudiu-B02008 @ 2013-05-08 9:20 UTC (permalink / raw)
To: tiejun.chen, Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <5189B02E.3000109@windriver.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBrdm0tb3duZXJAdmdlci5rZXJu
ZWwub3JnIFttYWlsdG86a3ZtLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24NCj4gQmVoYWxmIE9m
IHRpZWp1bi5jaGVuDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA4LCAyMDEzIDQ6NTQgQU0NCj4g
VG86IFdvb2QgU2NvdHQtQjA3NDIxDQo+IENjOiBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIu
a2VybmVsLm9yZzsga3ZtQHZnZXIua2VybmVsLm9yZzsNCj4gbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFt2MV1bS1ZNXVtQQVRDSCAxLzFdIGt2bTpwcGM6Ym9v
ZWh2OiBkaXJlY3QgSVNJIGV4Y2VwdGlvbiB0bw0KPiBHdWVzdA0KPiANCj4gT24gMDUvMDgvMjAx
MyAwNzo0MCBBTSwgU2NvdHQgV29vZCB3cm90ZToNCj4gPiBPbiAwNS8wNy8yMDEzIDA2OjA2OjMw
IEFNLCBUaWVqdW4gQ2hlbiB3cm90ZToNCj4gPj4gV2UgYWxzbyBjYW4gZGlyZWN0IElTSSBleGNl
cHRpb24gdG8gR3Vlc3QgbGlrZSBEU0kuDQo+ID4+DQo+ID4+IFNpZ25lZC1vZmYtYnk6IFRpZWp1
biBDaGVuIDx0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tPg0KPiA+PiAtLS0NCj4gPj4gIGFyY2gv
cG93ZXJwYy9rdm0vYm9va2VfZW11bGF0ZS5jIHwgICAgMyArKysNCj4gPj4gIGFyY2gvcG93ZXJw
Yy9rdm0vZTUwMG1jLmMgICAgICAgIHwgICAgMyArKy0NCj4gPj4gIDIgZmlsZXMgY2hhbmdlZCwg
NSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+ID4NCj4gPiBBcmUgeW91IHNlZWluZyBh
IHJlYWwgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnQgZnJvbSB0aGlzPyAgVGhpcyB3aWxsDQo+IGlu
dGVyZmVyZQ0KPiANCj4gTm8uIEJ1dCBhZnRlciB3ZSByZWR1Y2UgdGhlIGV4aXQgdG8gaG9zdCwg
c2hvdWxkbid0IHRoaXMgaW1wcm92ZQ0KPiBwZXJmb3JtYW5jZT8NCg0KV2UgbG9zZSBzb21lIGZs
ZXhpYmlsaXR5IGZvciB0aGlzIHNvIGl0IG1ha2Ugc2Vuc2Ugb25seSBpZiB3ZSBnYWluDQptZWFz
dXJhYmxlIGltcHJvdmVtZW50cy4NCg0KPiANCj4gPiBzb21ld2hhdCB3aXRoIHVzaW5nIHRoZSBW
RiBiaXQsIGlmIHdlIHdlcmUgdG8gZXZlciBkbyBzbywgc2luY2UgVkYgb25seQ0KPiBhZmZlY3Rz
DQo+IA0KPiBTb3JyeSwgd2hhdCBpcyB0aGUgVkYgeW91IHNhaWQ/DQoNClZGIHN0YW5kcyBmb3Ig
dmlydHVhbGl6YXRpb24gZmF1bHQgc2VlIE1BUzhbVkZdIGFuZCB3ZSBtYXkgdXNlIGl0IGZvciB2
aXJ0dWFsaXplZA0KTU1JTy4gVGhlIGh5cGVydmlzb3Igc2hvdWxkIGRlbnkgZXhlY3V0ZSBhY2Nl
c3Mgb24gcGFnZXMgbWFya2VkIHdpdGggVkYuIEFjY29yZGluZ2x5DQppbiB0aGlzIGNhc2UgZ3Vl
c3QgSVNJIGV4Y2VwdGlvbnMgc2hvdWxkIGJlIGhhbmRsZWQgYnkgdGhlIGh5cGVydmlzb3IuDQoN
Ci1NaWtlDQoNCg==
^ permalink raw reply
* Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: tiejun.chen @ 2013-05-08 9:28 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3EFA26@039-SN2MPN1-013.039d.mgd.msft.net>
On 05/08/2013 05:20 PM, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
>> Behalf Of tiejun.chen
>> Sent: Wednesday, May 08, 2013 4:54 AM
>> To: Wood Scott-B07421
>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
>> linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to
>> Guest
>>
>> On 05/08/2013 07:40 AM, Scott Wood wrote:
>>> On 05/07/2013 06:06:30 AM, Tiejun Chen wrote:
>>>> We also can direct ISI exception to Guest like DSI.
>>>>
>>>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>>>> ---
>>>> arch/powerpc/kvm/booke_emulate.c | 3 +++
>>>> arch/powerpc/kvm/e500mc.c | 3 ++-
>>>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>>
>>> Are you seeing a real performance improvement from this? This will
>> interfere
>>
>> No. But after we reduce the exit to host, shouldn't this improve
>> performance?
>
> We lose some flexibility for this so it make sense only if we gain
> measurable improvements.
Sounds we have much more works to do.
>
>>
>>> somewhat with using the VF bit, if we were to ever do so, since VF only
>> affects
>>
>> Sorry, what is the VF you said?
>
> VF stands for virtualization fault see MAS8[VF] and we may use it for virtualized
I almost forget this point :)
> MMIO. The hypervisor should deny execute access on pages marked with VF. Accordingly
> in this case guest ISI exceptions should be handled by the hypervisor.
Thanks for your information.
Tiejun
^ permalink raw reply
* Re: [PATCH] powerpc: fix numa distance for form0 device tree
From: Luis Henriques @ 2013-05-08 10:29 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Anton Blanchard, stable
In-Reply-To: <1367898574-20594-1-git-send-email-michael@ellerman.id.au>
On Tue, May 07, 2013 at 01:49:34PM +1000, Michael Ellerman wrote:
> From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
>
> Commit 7122beeee7bc1757682049780179d7c216dd1c83 upstream.
Thanks, I'm queuing it for the 3.5 kernel.
Cheers,
--
Luis
^ permalink raw reply
* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Anthony Foiani @ 2013-05-08 12:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Scott Wood, Robert P.J.Day, linuxppc-dev@lists.ozlabs.org,
Li Yang-R58472, Adrian Bunk
In-Reply-To: <87a9odrinu.fsf@hum.int.foiani.com>
Anthony Foiani <tkil@scrye.com> writes:
> Maybe I need to call ata_set_sata_spd as well. Can I do that before
> discovery, or should it be a part of the port_start callback? And
> if the latter, shouldn't it be handled within the ata core, instead
> of expecting each host driver to do that call?
My final version calls sata_set_spd from within the hard reset
callback for the fsl sata driver.
If there's a better place to put it, please let me know.
With this patch (and an appropriate entry in the device tree), the
machine comes up and reports:
# cd /sys/devices/e0000000.immr/e0019000.sata
# find * -name '*_spd*' -print | xargs grep .
ata2/link2/ata_link/link2/sata_spd:1.5 Gbps
ata2/link2/ata_link/link2/hw_sata_spd_limit:1.5 Gbps
ata2/link2/ata_link/link2/sata_spd_limit:1.5 Gbps
Which is what I needed to see.
Thanks for the hints!
Best regards,
Anthony Foiani
--
>From 357c96b4f31b457eca0b96147c749c21d0f4f086 Mon Sep 17 00:00:00 2001
From: Anthony Foiani <anthony.foiani@gmail.com>
Date: Wed, 8 May 2013 05:24:20 -0600
Subject: [PATCH] sata: fsl: allow device tree to limit sata speed.
There used to be an "orphan" config symbol (CONFIG_MPC8315_DS) that
would artificially limit SATA speed to generation 1 (1.5Gbps).
Since that config symbol got lost whenever any sort of configuration
was done, we instead extract the limitation from the device tree,
using a new name "sata-spd-limit".
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
---
.../devicetree/bindings/powerpc/fsl/board.txt | 23 ++++++++++++++++++
drivers/ata/sata_fsl.c | 28 +++++++++++-----------
2 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e..9c9fed4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,26 @@ Example:
gpio-controller;
};
};
+
+* Maximum SATA Generation workaround
+
+Some boards advertise SATA speeds that they cannot actually achieve.
+Previously, this was dealt with via the orphaned config symbol
+CONFIG_MPC8315_DS. We now have a device tree property
+"sata-spd-limit" to control this. It should live within the "sata"
+block.
+
+Example:
+
+ sata@18000 {
+ compatible = "fsl,mpc8315-sata", "fsl,pq-sata";
+ reg = <0x18000 0x1000>;
+ cell-index = <1>;
+ interrupts = <44 0x8>;
+ interrupt-parent = <&ipic>;
+ sata-spd-limit = <1>;
+ };
+
+By default, there is no limitation; if a value is given, it indicates
+the maximum "generation" that should be negotiated. Gen 1 is 1.5Gbps,
+Gen 2 is 3.0Gbps.
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..9e3f3ec 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -726,20 +726,6 @@ static int sata_fsl_port_start(struct ata_port *ap)
VPRINTK("HControl = 0x%x\n", ioread32(hcr_base + HCONTROL));
VPRINTK("CHBA = 0x%x\n", ioread32(hcr_base + CHBA));
-#ifdef CONFIG_MPC8315_DS
- /*
- * Workaround for 8315DS board 3gbps link-up issue,
- * currently limit SATA port to GEN1 speed
- */
- sata_fsl_scr_read(&ap->link, SCR_CONTROL, &temp);
- temp &= ~(0xF << 4);
- temp |= (0x1 << 4);
- sata_fsl_scr_write(&ap->link, SCR_CONTROL, temp);
-
- sata_fsl_scr_read(&ap->link, SCR_CONTROL, &temp);
- dev_warn(dev, "scr_control, speed limited to %x\n", temp);
-#endif
-
return 0;
}
@@ -836,6 +822,11 @@ try_offline_again:
*/
ata_msleep(ap, 1);
+ /* if the device tree forces a speed limit, set it here. */
+ ata_link_info(link, "setting speed (in hard reset)\n");
+ DPRINTK("setting spd_limit\n");
+ sata_set_spd(link);
+
/*
* Now, bring the host controller online again, this can take time
* as PHY reset and communication establishment, 1st D2H FIS and
@@ -1444,6 +1435,15 @@ static int sata_fsl_probe(struct platform_device *ofdev)
goto error_exit_with_cleanup;
}
+ /* record speed limit if requested by device tree */
+ if (!of_property_read_u32(ofdev->dev.of_node, "sata-spd-limit",
+ &temp)) {
+ int i;
+ for (i = 0; i < SATA_FSL_MAX_PORTS; ++i)
+ host->ports[i]->link.hw_sata_spd_limit = temp;
+ dev_warn(&ofdev->dev, "speed limit set to gen %u\n", temp);
+ }
+
/* host->iomap is not used currently */
host->private_data = host_priv;
--
1.8.1.4
^ permalink raw reply related
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Caraman Mihai Claudiu-B02008 @ 2013-05-08 13:14 UTC (permalink / raw)
To: Wood Scott-B07421, tiejun.chen
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <1367892390.3398.12@snotra>
> > This only disable soft interrupt for kvmppc_restart_interrupt() that
> > restarts interrupts if they were meant for the host:
> >
> > a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
> > BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>=20
> Those aren't the only exceptions that can end up going to the host. We
> could get a TLB miss that results in a heavyweight MMIO exit, etc.
>
> > And shouldn't we handle kvmppc_restart_interrupt() like the original
> > HOST flow?
> >
> > #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
> > ack) \
> >
> > START_EXCEPTION(label); \
> > NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
> > PROLOG_ADDITION_MASKABLE)\
> > EXCEPTION_COMMON(trapnum, PACA_EXGEN,
> > *INTS_DISABLE*) \
> > ...
>=20
> Could you elaborate on what you mean?
I think Tiejun was saying that host has flags and replays only EE/DEC/DBELL
interrupts. There is special macro masked_interrupt_book3e in those excepti=
on
handlers that sets paca->irq_happened.
The list of replied interrupts is limited to asynchronous noncritical
interrupts which can be masked by MSR[EE] (therefore no TLB miss). Now
on KVM book3e we don't want to put them in the irq_happened lazy state
but rather to execute them directly, so there is no reason for exception
handling symmetry between host and guest.
-Mike
^ permalink raw reply
* [PATCH] rapidio/tsi721: fix bug in MSI interrupt handling
From: Alexandre Bounine @ 2013-05-08 13:31 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Fix bug in MSI interrupt handling which causes loss of event notifications.
Typical indication of lost MSI interrupts are stalled message and doorbell
transfers between RapidIO endpoints. To avoid loss of MSI interrupts all
interrupts from the device must be disabled on entering the interrupt handler
routine and re-enabled when exiting it. Re-enabling device interrupts will
trigger new MSI message(s) if Tsi721 registered new events since entering
interrupt handler routine.
This patch is applicable to kernel versions starting from v3.2.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
---
drivers/rapidio/devices/tsi721.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 6faba40..a8b2c23 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -471,6 +471,10 @@ static irqreturn_t tsi721_irqhandler(int irq, void *ptr)
u32 intval;
u32 ch_inte;
+ /* For MSI mode disable all device-level interrupts */
+ if (priv->flags & TSI721_USING_MSI)
+ iowrite32(0, priv->regs + TSI721_DEV_INTE);
+
dev_int = ioread32(priv->regs + TSI721_DEV_INT);
if (!dev_int)
return IRQ_NONE;
@@ -560,6 +564,14 @@ static irqreturn_t tsi721_irqhandler(int irq, void *ptr)
}
}
#endif
+
+ /* For MSI mode re-enable device-level interrupts */
+ if (priv->flags & TSI721_USING_MSI) {
+ dev_int = TSI721_DEV_INT_SR2PC_CH | TSI721_DEV_INT_SRIO |
+ TSI721_DEV_INT_SMSG_CH | TSI721_DEV_INT_BDMA_CH;
+ iowrite32(dev_int, priv->regs + TSI721_DEV_INTE);
+ }
+
return IRQ_HANDLED;
}
--
1.7.8.4
^ permalink raw reply related
* [PATCH v5, part4 31/41] mm/ppc: prepare for removing num_physpages and simplify mem_init()
From: Jiang Liu @ 2013-05-08 15:51 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, James Bottomley, David Howells, Jiang Liu,
Wen Congyang, linux-mm, Mark Salter, linux-kernel, Michal Hocko,
Minchan Kim, Paul Mackerras, Mel Gorman, David Rientjes,
linuxppc-dev, Sergei Shtylyov, KAMEZAWA Hiroyuki, Jianguo Wu
In-Reply-To: <1368028298-7401-1-git-send-email-jiang.liu@huawei.com>
Prepare for removing num_physpages and simplify mem_init().
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
arch/powerpc/mm/mem.c | 56 +++++++++++--------------------------------------
1 file changed, 12 insertions(+), 44 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index b890245..4e24f1c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -299,46 +299,27 @@ void __init paging_init(void)
void __init mem_init(void)
{
-#ifdef CONFIG_NEED_MULTIPLE_NODES
- int nid;
-#endif
- pg_data_t *pgdat;
- unsigned long i;
- struct page *page;
- unsigned long reservedpages = 0, codesize, initsize, datasize, bsssize;
-
#ifdef CONFIG_SWIOTLB
swiotlb_init(0);
#endif
- num_physpages = memblock_phys_mem_size() >> PAGE_SHIFT;
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
#ifdef CONFIG_NEED_MULTIPLE_NODES
- for_each_online_node(nid) {
- if (NODE_DATA(nid)->node_spanned_pages != 0) {
- printk("freeing bootmem node %d\n", nid);
- free_all_bootmem_node(NODE_DATA(nid));
- }
+ {
+ pg_data_t *pgdat;
+
+ for_each_online_pgdat(pgdat)
+ if (pgdat->node_spanned_pages != 0) {
+ printk("freeing bootmem node %d\n",
+ pgdat->node_id);
+ free_all_bootmem_node(pgdat);
+ }
}
#else
max_mapnr = max_pfn;
free_all_bootmem();
#endif
- for_each_online_pgdat(pgdat) {
- for (i = 0; i < pgdat->node_spanned_pages; i++) {
- if (!pfn_valid(pgdat->node_start_pfn + i))
- continue;
- page = pgdat_page_nr(pgdat, i);
- if (PageReserved(page))
- reservedpages++;
- }
- }
-
- codesize = (unsigned long)&_sdata - (unsigned long)&_stext;
- datasize = (unsigned long)&_edata - (unsigned long)&_sdata;
- initsize = (unsigned long)&__init_end - (unsigned long)&__init_begin;
- bsssize = (unsigned long)&__bss_stop - (unsigned long)&__bss_start;
#ifdef CONFIG_HIGHMEM
{
@@ -348,13 +329,9 @@ void __init mem_init(void)
for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT;
struct page *page = pfn_to_page(pfn);
- if (memblock_is_reserved(paddr))
- continue;
- free_highmem_page(page);
- reservedpages--;
+ if (!memblock_is_reserved(paddr))
+ free_highmem_page(page);
}
- printk(KERN_DEBUG "High memory: %luk\n",
- totalhigh_pages << (PAGE_SHIFT-10));
}
#endif /* CONFIG_HIGHMEM */
@@ -367,16 +344,7 @@ void __init mem_init(void)
(mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) - 1;
#endif
- printk(KERN_INFO "Memory: %luk/%luk available (%luk kernel code, "
- "%luk reserved, %luk data, %luk bss, %luk init)\n",
- nr_free_pages() << (PAGE_SHIFT-10),
- num_physpages << (PAGE_SHIFT-10),
- codesize >> 10,
- reservedpages << (PAGE_SHIFT-10),
- datasize >> 10,
- bsssize >> 10,
- initsize >> 10);
-
+ mem_init_print_info(NULL);
#ifdef CONFIG_PPC32
pr_info("Kernel virtual memory layout:\n");
pr_info(" * 0x%08lx..0x%08lx : fixmap\n", FIXADDR_START, FIXADDR_TOP);
--
1.7.9.5
^ permalink raw reply related
* Re: Invalid perf_branch_entry.to entries question
From: Peter Zijlstra @ 2013-05-08 15:59 UTC (permalink / raw)
To: Michael Neuling; +Cc: Linux PPC dev, linux-kernel, eranian, Anshuman Khandual
In-Reply-To: <25394.1367890528@ale.ozlabs.ibm.com>
On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote:
> Peter & Stephane,
>
> We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
> struct perf_branch_entry.
>
> Sometimes on POWER8 we may not be able to fill out the "to" address.
Just because I'm curious.. however does that happen? Surely the CPU knows where
next to fetch instructions?
> We
> initially thought of just making this 0, but it's feasible that this
> could be a valid address to branch to.
Right, while highly unlikely, x86 actually has some cases where 0 address is
valid *shudder*..
> The other logical value to indicate an invalid entry would be all 1s
> which is not possible (on POWER at least).
>
> Do you guys have a preference as to what we should use as an invalid
> entry? This would have some consequences for the userspace tool also.
>
> The alternative would be to add a flag alongside mispred/predicted to
> indicate the validity of the "to" address.
Either would work with me I suppose.. Stephane do you have any preference?
^ permalink raw reply
* Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: Scott Wood @ 2013-05-08 19:09 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <5189B02E.3000109@windriver.com>
On 05/07/2013 08:53:50 PM, tiejun.chen wrote:
> On 05/08/2013 07:40 AM, Scott Wood wrote:
>> On 05/07/2013 06:06:30 AM, Tiejun Chen wrote:
>>> We also can direct ISI exception to Guest like DSI.
>>>=20
>>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>>> ---
>>> arch/powerpc/kvm/booke_emulate.c | 3 +++
>>> arch/powerpc/kvm/e500mc.c | 3 ++-
>>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>=20
>> Are you seeing a real performance improvement from this? This will =20
>> interfere
>=20
> No. But after we reduce the exit to host, shouldn't this improve =20
> performance?
Not if ISIs are too rare to matter.
-Scott=
^ permalink raw reply
* Re: Invalid perf_branch_entry.to entries question
From: Stephane Eranian @ 2013-05-08 21:33 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Linux PPC dev, Michael Neuling, LKML, Anshuman Khandual
In-Reply-To: <20130508155929.GA8459@dyad.programming.kicks-ass.net>
On Wed, May 8, 2013 at 5:59 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote:
>> Peter & Stephane,
>>
>> We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
>> struct perf_branch_entry.
>>
>> Sometimes on POWER8 we may not be able to fill out the "to" address.
>
> Just because I'm curious.. however does that happen? Surely the CPU knows where
> next to fetch instructions?
>
>> We
>> initially thought of just making this 0, but it's feasible that this
>> could be a valid address to branch to.
>
> Right, while highly unlikely, x86 actually has some cases where 0 address is
> valid *shudder*..
>
>> The other logical value to indicate an invalid entry would be all 1s
>> which is not possible (on POWER at least).
>>
>> Do you guys have a preference as to what we should use as an invalid
>> entry? This would have some consequences for the userspace tool also.
>>
>> The alternative would be to add a flag alongside mispred/predicted to
>> indicate the validity of the "to" address.
>
> Either would work with me I suppose.. Stephane do you have any preference?
But if the 'to' is bogus, why not just drop the sample?
That happens on x86 if the HW captured branches which do not correspond to
user filter settings (due to bug).
^ permalink raw reply
* Re: Invalid perf_branch_entry.to entries question
From: Michael Neuling @ 2013-05-08 22:39 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Linux PPC dev, linux-kernel, eranian, Anshuman Khandual
In-Reply-To: <20130508155929.GA8459@dyad.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote:
> > Peter & Stephane,
> >
> > We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
> > struct perf_branch_entry.
> >
> > Sometimes on POWER8 we may not be able to fill out the "to" address.
>
> Just because I'm curious.. however does that happen? Surely the CPU
> knows where next to fetch instructions?
For computed gotos (ie. branch to a register value), the hardware gives
you the from and to address in the branch history buffer.
For branches where the branch target address is an immediate encoded in
the instruction, the hardware only logs the from address. It assumes
that software (perf irq handler in this case) can read this branch
instruction, calculate the corresponding offset and hence the
to/target address.
It's entirely possible that when the perf IRQ handler happens, the
instruction in question is not readable or is no longer a branch (self
modifying code). Hence we aren't able to calculate a valid to address.
Mikey
>
> > We
> > initially thought of just making this 0, but it's feasible that this
> > could be a valid address to branch to.
>
> Right, while highly unlikely, x86 actually has some cases where 0 address is
> valid *shudder*..
>
> > The other logical value to indicate an invalid entry would be all 1s
> > which is not possible (on POWER at least).
> >
> > Do you guys have a preference as to what we should use as an invalid
> > entry? This would have some consequences for the userspace tool also.
> >
> > The alternative would be to add a flag alongside mispred/predicted to
> > indicate the validity of the "to" address.
>
> Either would work with me I suppose.. Stephane do you have any preference?
>
^ permalink raw reply
* Re: Invalid perf_branch_entry.to entries question
From: Michael Neuling @ 2013-05-08 22:45 UTC (permalink / raw)
To: Stephane Eranian; +Cc: Peter Zijlstra, Linux PPC dev, LKML, Anshuman Khandual
In-Reply-To: <CABPqkBRSMxQK8LJWhD39yo8EQZBd3-dRkeMqvwhWwLiHa6m66g@mail.gmail.com>
Stephane Eranian <eranian@google.com> wrote:
> On Wed, May 8, 2013 at 5:59 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote:
> >> Peter & Stephane,
> >>
> >> We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
> >> struct perf_branch_entry.
> >>
> >> Sometimes on POWER8 we may not be able to fill out the "to" address.
> >
> > Just because I'm curious.. however does that happen? Surely the CPU knows where
> > next to fetch instructions?
> >
> >> We
> >> initially thought of just making this 0, but it's feasible that this
> >> could be a valid address to branch to.
> >
> > Right, while highly unlikely, x86 actually has some cases where 0 address is
> > valid *shudder*..
> >
> >> The other logical value to indicate an invalid entry would be all 1s
> >> which is not possible (on POWER at least).
> >>
> >> Do you guys have a preference as to what we should use as an invalid
> >> entry? This would have some consequences for the userspace tool also.
> >>
> >> The alternative would be to add a flag alongside mispred/predicted to
> >> indicate the validity of the "to" address.
> >
> > Either would work with me I suppose.. Stephane do you have any preference?
>
> But if the 'to' is bogus, why not just drop the sample?
> That happens on x86 if the HW captured branches which do not correspond to
> user filter settings (due to bug).
We can I guess but it seems useful to log the from address when
possible.
Can we log it and userspace tools can ignore it if it's not useful?
Mikey
^ permalink raw reply
* Re: Invalid perf_branch_entry.to entries question
From: Michael Ellerman @ 2013-05-09 0:02 UTC (permalink / raw)
To: Michael Neuling
Cc: Peter Zijlstra, Linux PPC dev, LKML, Stephane Eranian,
Anshuman Khandual
In-Reply-To: <15099.1368053151@ale.ozlabs.ibm.com>
On Thu, 2013-05-09 at 08:45 +1000, Michael Neuling wrote:
> Stephane Eranian <eranian@google.com> wrote:
>
> > On Wed, May 8, 2013 at 5:59 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Tue, May 07, 2013 at 11:35:28AM +1000, Michael Neuling wrote:
> > >> Peter & Stephane,
> > >>
> > >> We are plumbing the POWER8 Branch History Rolling Buffer (BHRB) into
> > >> struct perf_branch_entry.
> > >>
> > >> Sometimes on POWER8 we may not be able to fill out the "to" address.
> > >
> > > Just because I'm curious.. however does that happen? Surely the CPU knows where
> > > next to fetch instructions?
> > >
> > >> We
> > >> initially thought of just making this 0, but it's feasible that this
> > >> could be a valid address to branch to.
> > >
> > > Right, while highly unlikely, x86 actually has some cases where 0 address is
> > > valid *shudder*..
> > >
> > >> The other logical value to indicate an invalid entry would be all 1s
> > >> which is not possible (on POWER at least).
> > >>
> > >> Do you guys have a preference as to what we should use as an invalid
> > >> entry? This would have some consequences for the userspace tool also.
> > >>
> > >> The alternative would be to add a flag alongside mispred/predicted to
> > >> indicate the validity of the "to" address.
> > >
> > > Either would work with me I suppose.. Stephane do you have any preference?
> >
> > But if the 'to' is bogus, why not just drop the sample?
> > That happens on x86 if the HW captured branches which do not correspond to
> > user filter settings (due to bug).
>
> We can I guess but it seems useful to log the from address when
> possible.
Yeah I think it is useful. Knowing that you were there, but the to
address is invalid, is better than wondering why you never hit the code
at all.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: fix numa distance for form0 device tree
From: Michael Ellerman @ 2013-05-09 0:04 UTC (permalink / raw)
To: Luis Henriques; +Cc: linuxppc-dev, Anton Blanchard, stable
In-Reply-To: <20130508102934.GA3763@hercules>
On Wed, 2013-05-08 at 11:29 +0100, Luis Henriques wrote:
> On Tue, May 07, 2013 at 01:49:34PM +1000, Michael Ellerman wrote:
> > From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> >
> > Commit 7122beeee7bc1757682049780179d7c216dd1c83 upstream.
>
> Thanks, I'm queuing it for the 3.5 kernel.
Thanks, I didn't know you guys were maintaining a 3.5 stable branch.
cheers
^ permalink raw reply
* [PATCH] powerpc: Update currituck pci/usb fixup for new board revision
From: Alistair Popple @ 2013-05-09 0:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alistair Popple
The currituck board uses a different IRQ for the pci usb host
controller depending on the board revision. This patch adds support
for newer board revisions by retrieving the board revision from the
FPGA and mapping the appropriate IRQ.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
arch/powerpc/boot/dts/currituck.dts | 5 ++++
arch/powerpc/platforms/44x/currituck.c | 39 ++++++++++++++++++++++++++++++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/currituck.dts b/arch/powerpc/boot/dts/currituck.dts
index b801dd0..cd3247e 100644
--- a/arch/powerpc/boot/dts/currituck.dts
+++ b/arch/powerpc/boot/dts/currituck.dts
@@ -103,6 +103,11 @@
interrupts = <34 2>;
};
+ FPGA0: fpga@50000000 {
+ compatible = "ibm,currituck-fpga";
+ reg = <0x50000000 0x1>;
+ };
+
IIC0: i2c@00000000 {
compatible = "ibm,iic-currituck", "ibm,iic";
reg = <0x0 0x00000014>;
diff --git a/arch/powerpc/platforms/44x/currituck.c b/arch/powerpc/platforms/44x/currituck.c
index ecd3890..c52e1b3 100644
--- a/arch/powerpc/platforms/44x/currituck.c
+++ b/arch/powerpc/platforms/44x/currituck.c
@@ -176,13 +176,48 @@ static int __init ppc47x_probe(void)
return 1;
}
+static int board_rev = -1;
+static int __init ppc47x_get_board_rev(void)
+{
+ u8 fpga_reg0;
+ void *fpga;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,currituck-fpga");
+ if (!np)
+ goto fail;
+
+ fpga = of_iomap(np, 0);
+ of_node_put(np);
+ if (!fpga)
+ goto fail;
+
+ fpga_reg0 = ioread8(fpga);
+ board_rev = fpga_reg0 & 0x03;
+ pr_info("%s: Found board revision %d\n", __func__, board_rev);
+ iounmap(fpga);
+ return 0;
+
+fail:
+ pr_info("%s: Unable to find board revision\n", __func__);
+ return 0;
+}
+machine_arch_initcall(ppc47x, ppc47x_get_board_rev);
+
/* Use USB controller should have been hardware swizzled but it wasn't :( */
static void ppc47x_pci_irq_fixup(struct pci_dev *dev)
{
if (dev->vendor == 0x1033 && (dev->device == 0x0035 ||
dev->device == 0x00e0)) {
- dev->irq = irq_create_mapping(NULL, 47);
- pr_info("%s: Mapping irq 47 %d\n", __func__, dev->irq);
+ if (board_rev == 0) {
+ dev->irq = irq_create_mapping(NULL, 47);
+ pr_info("%s: Mapping irq %d\n", __func__, dev->irq);
+ } else if (board_rev == 2) {
+ dev->irq = irq_create_mapping(NULL, 49);
+ pr_info("%s: Mapping irq %d\n", __func__, dev->irq);
+ } else {
+ pr_alert("%s: Unknown board revision\n", __func__);
+ }
}
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] powerpc: Update currituck pci/usb fixup for new board revision
From: Alistair Popple @ 2013-05-09 0:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1368057988-7353-1-git-send-email-alistair@popple.id.au>
The currituck board uses a different IRQ for the pci usb host
controller depending on the board revision. This patch adds support
for newer board revisions by retrieving the board revision from the
FPGA and mapping the appropriate IRQ.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
Sorry - I had forgotten to commit a minor fix to the device tree
changes in the last patch. Corrected patch below.
arch/powerpc/boot/dts/currituck.dts | 5 ++++
arch/powerpc/platforms/44x/currituck.c | 39 ++++++++++++++++++++++++++++++--
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/currituck.dts b/arch/powerpc/boot/dts/currituck.dts
index b801dd0..d2c8a87 100644
--- a/arch/powerpc/boot/dts/currituck.dts
+++ b/arch/powerpc/boot/dts/currituck.dts
@@ -103,6 +103,11 @@
interrupts = <34 2>;
};
+ FPGA0: fpga@50000000 {
+ compatible = "ibm,currituck-fpga";
+ reg = <0x50000000 0x4>;
+ };
+
IIC0: i2c@00000000 {
compatible = "ibm,iic-currituck", "ibm,iic";
reg = <0x0 0x00000014>;
diff --git a/arch/powerpc/platforms/44x/currituck.c b/arch/powerpc/platforms/44x/currituck.c
index ecd3890..c52e1b3 100644
--- a/arch/powerpc/platforms/44x/currituck.c
+++ b/arch/powerpc/platforms/44x/currituck.c
@@ -176,13 +176,48 @@ static int __init ppc47x_probe(void)
return 1;
}
+static int board_rev = -1;
+static int __init ppc47x_get_board_rev(void)
+{
+ u8 fpga_reg0;
+ void *fpga;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,currituck-fpga");
+ if (!np)
+ goto fail;
+
+ fpga = of_iomap(np, 0);
+ of_node_put(np);
+ if (!fpga)
+ goto fail;
+
+ fpga_reg0 = ioread8(fpga);
+ board_rev = fpga_reg0 & 0x03;
+ pr_info("%s: Found board revision %d\n", __func__, board_rev);
+ iounmap(fpga);
+ return 0;
+
+fail:
+ pr_info("%s: Unable to find board revision\n", __func__);
+ return 0;
+}
+machine_arch_initcall(ppc47x, ppc47x_get_board_rev);
+
/* Use USB controller should have been hardware swizzled but it wasn't :( */
static void ppc47x_pci_irq_fixup(struct pci_dev *dev)
{
if (dev->vendor == 0x1033 && (dev->device == 0x0035 ||
dev->device == 0x00e0)) {
- dev->irq = irq_create_mapping(NULL, 47);
- pr_info("%s: Mapping irq 47 %d\n", __func__, dev->irq);
+ if (board_rev == 0) {
+ dev->irq = irq_create_mapping(NULL, 47);
+ pr_info("%s: Mapping irq %d\n", __func__, dev->irq);
+ } else if (board_rev == 2) {
+ dev->irq = irq_create_mapping(NULL, 49);
+ pr_info("%s: Mapping irq %d\n", __func__, dev->irq);
+ } else {
+ pr_alert("%s: Unknown board revision\n", __func__);
+ }
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/pmu: Fix order of interpreting BHRB target entries
From: Michael Neuling @ 2013-05-09 1:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Anshuman Khandual
The current Branch History Rolling Buffer (BHRB) code misinterprets the order
of entries in the hardware buffer. It assumes that a branch target address
will be read _after_ its corresponding branch. In reality the branch target
comes before (lower mfbhrb entry) it's corresponding branch.
This is a rewrite of the code to take this into account.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/perf/core-book3s.c | 86 ++++++++++++++++++++-------------------
1 file changed, 45 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index c627843..2d81372 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1463,66 +1463,70 @@ void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
{
u64 val;
u64 addr;
- int r_index, u_index, target, pred;
+ int r_index, u_index, pred;
r_index = 0;
u_index = 0;
while (r_index < ppmu->bhrb_nr) {
/* Assembly read function */
- val = read_bhrb(r_index);
-
- /* Terminal marker: End of valid BHRB entries */
- if (val == 0) {
+ val = read_bhrb(r_index++);
+ if (!val)
+ /* Terminal marker: End of valid BHRB entries */
break;
- } else {
- /* BHRB field break up */
+ else {
addr = val & BHRB_EA;
pred = val & BHRB_PREDICTION;
- target = val & BHRB_TARGET;
- /* Probable Missed entry: Not applicable for POWER8 */
- if ((addr == 0) && (target == 0) && (pred == 1)) {
- r_index++;
+ if (!addr)
+ /* invalid entry */
continue;
- }
- /* Real Missed entry: Power8 based missed entry */
- if ((addr == 0) && (target == 1) && (pred == 1)) {
- r_index++;
- continue;
- }
-
- /* Reserved condition: Not a valid entry */
- if ((addr == 0) && (target == 1) && (pred == 0)) {
- r_index++;
- continue;
- }
+ /* Branches are read most recent first (ie. mfbhrb 0 is
+ * the most recent branch).
+ * There are two types of valid entries:
+ * 1) a target entry which is the to address of a
+ * computed goto like a blr,bctr,btar. The next
+ * entry read from the bhrb will be branch
+ * corresponding to this target (ie. the actual
+ * blr/bctr/btar instruction).
+ * 2) a from address which is an actual branch. If a
+ * target entry proceeds this, then this is the
+ * matching branch for that target. If this is not
+ * following a target entry, then this is a branch
+ * where the target is given as an immediate field
+ * in the instruction (ie. an i or b form branch).
+ * In this case we need to read the instruction from
+ * memory to determine the target/to address.
+ */
- /* Is a target address */
if (val & BHRB_TARGET) {
- /* First address cannot be a target address */
- if (r_index == 0) {
- r_index++;
- continue;
- }
-
- /* Update target address for the previous entry */
- cpuhw->bhrb_entries[u_index - 1].to = addr;
- cpuhw->bhrb_entries[u_index - 1].mispred = pred;
- cpuhw->bhrb_entries[u_index - 1].predicted = ~pred;
+ /* Target branches use two entries
+ * (ie. computed gotos/XL form)
+ */
+ cpuhw->bhrb_entries[u_index].to = addr;
+ cpuhw->bhrb_entries[u_index].mispred = pred;
+ cpuhw->bhrb_entries[u_index].predicted = ~pred;
- /* Dont increment u_index */
- r_index++;
+ /* Get from address in next entry */
+ val = read_bhrb(r_index++);
+ addr = val & BHRB_EA;
+ if (val & BHRB_TARGET) {
+ /* Shouldn't have two targets in a
+ row.. Reset index and try again */
+ r_index--;
+ addr = 0;
+ }
+ cpuhw->bhrb_entries[u_index].from = addr;
} else {
- /* Update address, flags for current entry */
+ /* Branches to immediate field
+ (ie I or B form) */
cpuhw->bhrb_entries[u_index].from = addr;
+ cpuhw->bhrb_entries[u_index].to = 0;
cpuhw->bhrb_entries[u_index].mispred = pred;
cpuhw->bhrb_entries[u_index].predicted = ~pred;
-
- /* Successfully popullated one entry */
- u_index++;
- r_index++;
}
+ u_index++;
+
}
}
cpuhw->bhrb_stack.nr = u_index;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] powerpc/perf: Fix setting of "to" addresses for BHRB
From: Michael Neuling @ 2013-05-09 1:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Anshuman Khandual
In-Reply-To: <1368064009-13255-1-git-send-email-mikey@neuling.org>
Currently we only set the "to" address in the branch stack when the CPU
explicitly gives us a value. Unfortunately it only does this for XL form
branches (eg blr, bctr, bctar) and not I and B form branches (eg b, bc).
Fortunately if we read the instruction from memory we can extract the offset of
a branch and calculate the target address.
This adds a function power_pmu_bhrb_to() to calculate the target/to address of
the corresponding I and B form branches. It handles branches in both user and
kernel spaces. It also plumbs this into the perf brhb reading code.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/perf/core-book3s.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 2d81372..37f652f 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -13,11 +13,13 @@
#include <linux/perf_event.h>
#include <linux/percpu.h>
#include <linux/hardirq.h>
+#include <linux/uaccess.h>
#include <asm/reg.h>
#include <asm/pmc.h>
#include <asm/machdep.h>
#include <asm/firmware.h>
#include <asm/ptrace.h>
+#include <asm/code-patching.h>
#define BHRB_MAX_ENTRIES 32
#define BHRB_TARGET 0x0000000000000002
@@ -1458,6 +1460,33 @@ struct pmu power_pmu = {
.flush_branch_stack = power_pmu_flush_branch_stack,
};
+/* Calculate the to address for a branch */
+static __u64 power_pmu_bhrb_to(u64 addr)
+{
+ unsigned int instr;
+ int ret;
+ __u64 target;
+
+ if (is_kernel_addr(addr))
+ return branch_target((unsigned int *)addr);
+
+ /* Userspace: need copy instruction here then translate it */
+ pagefault_disable();
+ ret = __get_user_inatomic(instr, (unsigned int *)addr);
+ if (ret) {
+ pagefault_enable();
+ return 0;
+ }
+ pagefault_enable();
+
+ target = branch_target(&instr);
+ if ((!target) || (instr & BRANCH_ABSOLUTE))
+ return target;
+
+ /* Translate relative branch target from kernel to user address */
+ return target - (unsigned long)&instr + addr;
+}
+
/* Processing BHRB entries */
void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
{
@@ -1521,7 +1550,8 @@ void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
/* Branches to immediate field
(ie I or B form) */
cpuhw->bhrb_entries[u_index].from = addr;
- cpuhw->bhrb_entries[u_index].to = 0;
+ cpuhw->bhrb_entries[u_index].to =
+ power_pmu_bhrb_to(addr);
cpuhw->bhrb_entries[u_index].mispred = pred;
cpuhw->bhrb_entries[u_index].predicted = ~pred;
}
--
1.7.10.4
^ permalink raw reply related
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 7:33 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008, Wood Scott-B07421, tiejun.chen
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3F00D0@039-SN2MPN1-013.039d.mgd.msft.net>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Car=
aman
> Mihai Claudiu-B02008
> Sent: Wednesday, May 08, 2013 6:44 PM
> To: Wood Scott-B07421; tiejun.chen
> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org=
;
> kvm@vger.kernel.org
> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interru=
pts
>=20
> > > This only disable soft interrupt for kvmppc_restart_interrupt() that
> > > restarts interrupts if they were meant for the host:
> > >
> > > a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
> > > BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
> >
> > Those aren't the only exceptions that can end up going to the host.
> > We could get a TLB miss that results in a heavyweight MMIO exit, etc.
> >
> > > And shouldn't we handle kvmppc_restart_interrupt() like the original
> > > HOST flow?
> > >
> > > #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
> > > ack) \
> > >
> > > START_EXCEPTION(label); \
> > > NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
> > > PROLOG_ADDITION_MASKABLE)\
> > > EXCEPTION_COMMON(trapnum, PACA_EXGEN,
> > > *INTS_DISABLE*) \
> > > ...
> >
> > Could you elaborate on what you mean?
>=20
> I think Tiejun was saying that host has flags and replays only EE/DEC/DBE=
LL
> interrupts. There is special macro masked_interrupt_book3e in those excep=
tion
> handlers that sets paca->irq_happened.
>=20
> The list of replied interrupts is limited to asynchronous noncritical int=
errupts
> which can be masked by MSR[EE] (therefore no TLB miss).
Embedded Perfmon interrupt is also asynchronous, Why that is not in the lis=
t of masked interruts.
-Bharat
=20
> Now on KVM book3e we
> don't want to put them in the irq_happened lazy state but rather to execu=
te them
> directly, so there is no reason for exception handling symmetry between h=
ost and
> guest.
>=20
> -Mike
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 7:47 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E50E@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: Linuxppc-dev [mailto:linuxppc-dev-
>> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of Caraman
>> Mihai Claudiu-B02008
>> Sent: Wednesday, May 08, 2013 6:44 PM
>> To: Wood Scott-B07421; tiejun.chen
>> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>>>> This only disable soft interrupt for kvmppc_restart_interrupt() that
>>>> restarts interrupts if they were meant for the host:
>>>>
>>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
>>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>>>
>>> Those aren't the only exceptions that can end up going to the host.
>>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
>>>
>>>> And shouldn't we handle kvmppc_restart_interrupt() like the original
>>>> HOST flow?
>>>>
>>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
>>>> ack) \
>>>>
>>>> START_EXCEPTION(label); \
>>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
>>>> PROLOG_ADDITION_MASKABLE)\
>>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
>>>> *INTS_DISABLE*) \
>>>> ...
>>>
>>> Could you elaborate on what you mean?
>>
>> I think Tiejun was saying that host has flags and replays only EE/DEC/DBELL
>> interrupts. There is special macro masked_interrupt_book3e in those exception
>> handlers that sets paca->irq_happened.
>>
>> The list of replied interrupts is limited to asynchronous noncritical interrupts
>> which can be masked by MSR[EE] (therefore no TLB miss).
>
> Embedded Perfmon interrupt is also asynchronous, Why that is not in the list of masked interruts.
Are you saying perfmon? If so, its also in that list:
START_EXCEPTION(perfmon);
NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_MONITOR,
PROLOG_ADDITION_NONE)
EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
Tiejun
>
> -Bharat
>
>> Now on KVM book3e we
>> don't want to put them in the irq_happened lazy state but rather to execute them
>> directly, so there is no reason for exception handling symmetry between host and
>> guest.
>>
>> -Mike
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 7:51 UTC (permalink / raw)
To: tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <518B54A6.1070505@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA5
LCAyMDEzIDE6MTggUE0NCj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogQ2FyYW1h
biBNaWhhaSBDbGF1ZGl1LUIwMjAwODsgV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiBk
ZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5v
cmc7DQo+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFU
Q0ggMS8xXSBrdm06cHBjOmJvb2tlLTY0OiBzb2Z0LWRpc2FibGUgaW50ZXJydXB0cw0KPiANCj4g
T24gMDUvMDkvMjAxMyAwMzozMyBQTSwgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3IHdyb3RlOg0KPiA+
DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTGludXhw
cGMtZGV2IFttYWlsdG86bGludXhwcGMtZGV2LQ0KPiA+PiBib3VuY2VzK2JoYXJhdC5iaHVzaGFu
PWZyZWVzY2FsZS5jb21AbGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+IGJvdW5j
ZXMrQ2FyYW1hbg0KPiA+PiBNaWhhaSBDbGF1ZGl1LUIwMjAwOA0KPiA+PiBTZW50OiBXZWRuZXNk
YXksIE1heSAwOCwgMjAxMyA2OjQ0IFBNDQo+ID4+IFRvOiBXb29kIFNjb3R0LUIwNzQyMTsgdGll
anVuLmNoZW4NCj4gPj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBhZ3JhZkBz
dXNlLmRlOw0KPiA+PiBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZnZXIua2VybmVsLm9y
Zw0KPiA+PiBTdWJqZWN0OiBSRTogW1JGQ11bS1ZNXVtQQVRDSCAxLzFdIGt2bTpwcGM6Ym9va2Ut
NjQ6IHNvZnQtZGlzYWJsZQ0KPiA+PiBpbnRlcnJ1cHRzDQo+ID4+DQo+ID4+Pj4gVGhpcyBvbmx5
IGRpc2FibGUgc29mdCBpbnRlcnJ1cHQgZm9yIGt2bXBwY19yZXN0YXJ0X2ludGVycnVwdCgpDQo+
ID4+Pj4gdGhhdCByZXN0YXJ0cyBpbnRlcnJ1cHRzIGlmIHRoZXkgd2VyZSBtZWFudCBmb3IgdGhl
IGhvc3Q6DQo+ID4+Pj4NCj4gPj4+PiBhLiBTT0ZUX0RJU0FCTEVfSU5UUygpIG9ubHkgZm9yIEJP
T0tFX0lOVEVSUlVQVF9FWFRFUk5BTCB8DQo+ID4+Pj4gQk9PS0VfSU5URVJSVVBUX0RFQ1JFTUVO
VEVSIHwgQk9PS0VfSU5URVJSVVBUX0RPT1JCRUxMDQo+ID4+Pg0KPiA+Pj4gVGhvc2UgYXJlbid0
IHRoZSBvbmx5IGV4Y2VwdGlvbnMgdGhhdCBjYW4gZW5kIHVwIGdvaW5nIHRvIHRoZSBob3N0Lg0K
PiA+Pj4gV2UgY291bGQgZ2V0IGEgVExCIG1pc3MgdGhhdCByZXN1bHRzIGluIGEgaGVhdnl3ZWln
aHQgTU1JTyBleGl0LCBldGMuDQo+ID4+Pg0KPiA+Pj4+IEFuZCBzaG91bGRuJ3Qgd2UgaGFuZGxl
IGt2bXBwY19yZXN0YXJ0X2ludGVycnVwdCgpIGxpa2UgdGhlDQo+ID4+Pj4gb3JpZ2luYWwgSE9T
VCBmbG93Pw0KPiA+Pj4+DQo+ID4+Pj4gI2RlZmluZSBNQVNLQUJMRV9FWENFUFRJT04odHJhcG51
bSwgaW50bnVtLCBsYWJlbCwgaGRsciwNCj4gPj4+PiBhY2spICAgICAgICAgICBcDQo+ID4+Pj4N
Cj4gPj4+PiBTVEFSVF9FWENFUFRJT04obGFiZWwpOyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KPiA+Pj4+ICAgICAgICAgIE5PUk1BTF9FWENFUFRJT05fUFJPTE9H
KHRyYXBudW0sIGludG51bSwNCj4gPj4+PiBQUk9MT0dfQURESVRJT05fTUFTS0FCTEUpXA0KPiA+
Pj4+ICAgICAgICAgIEVYQ0VQVElPTl9DT01NT04odHJhcG51bSwgUEFDQV9FWEdFTiwNCj4gPj4+
PiAqSU5UU19ESVNBQkxFKikgICAgICAgICAgICAgXA0KPiA+Pj4+IAkuLi4NCj4gPj4+DQo+ID4+
PiBDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4/DQo+ID4+DQo+ID4+IEkgdGhp
bmsgVGllanVuIHdhcyBzYXlpbmcgdGhhdCBob3N0IGhhcyBmbGFncyBhbmQgcmVwbGF5cyBvbmx5
DQo+ID4+IEVFL0RFQy9EQkVMTCBpbnRlcnJ1cHRzLiBUaGVyZSBpcyBzcGVjaWFsIG1hY3JvDQo+
ID4+IG1hc2tlZF9pbnRlcnJ1cHRfYm9vazNlIGluIHRob3NlIGV4Y2VwdGlvbiBoYW5kbGVycyB0
aGF0IHNldHMgcGFjYS0NCj4gPmlycV9oYXBwZW5lZC4NCj4gPj4NCj4gPj4gVGhlIGxpc3Qgb2Yg
cmVwbGllZCBpbnRlcnJ1cHRzIGlzIGxpbWl0ZWQgdG8gYXN5bmNocm9ub3VzIG5vbmNyaXRpY2Fs
DQo+ID4+IGludGVycnVwdHMgd2hpY2ggY2FuIGJlIG1hc2tlZCBieSBNU1JbRUVdICh0aGVyZWZv
cmUgbm8gVExCIG1pc3MpLg0KPiA+DQo+ID4gRW1iZWRkZWQgUGVyZm1vbiBpbnRlcnJ1cHQgaXMg
YWxzbyBhc3luY2hyb25vdXMsIFdoeSB0aGF0IGlzIG5vdCBpbiB0aGUgbGlzdA0KPiBvZiBtYXNr
ZWQgaW50ZXJydXRzLg0KPiANCj4gQXJlIHlvdSBzYXlpbmcgcGVyZm1vbj8gSWYgc28sIGl0cyBh
bHNvIGluIHRoYXQgbGlzdDoNCj4gDQo+ICAgICAgICAgIFNUQVJUX0VYQ0VQVElPTihwZXJmbW9u
KTsNCj4gICAgICAgICAgTk9STUFMX0VYQ0VQVElPTl9QUk9MT0coMHgyNjAsIEJPT0tFX0lOVEVS
UlVQVF9QRVJGT1JNQU5DRV9NT05JVE9SLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBQUk9MT0dfQURESVRJT05fTk9ORSkNCj4gICAgICAgICAgRVhDRVBUSU9OX0NPTU1PTigw
eDI2MCwgUEFDQV9FWEdFTiwgSU5UU19ESVNBQkxFKQ0KDQpXaGVyZSBpdCBpcyByZWNvcmRlZCBp
biBwYWNhLT5pcnFfaGFwcG5lZCB0byBiZSByZXBsYXllZCBsYXRlciA/DQoNCj4gDQo+IFRpZWp1
bg0KPiANCj4gPg0KPiA+IC1CaGFyYXQNCj4gPg0KPiA+PiBOb3cgb24gS1ZNIGJvb2szZSB3ZQ0K
PiA+PiBkb24ndCB3YW50IHRvIHB1dCB0aGVtIGluIHRoZSBpcnFfaGFwcGVuZWQgbGF6eSBzdGF0
ZSBidXQgcmF0aGVyIHRvDQo+ID4+IGV4ZWN1dGUgdGhlbSBkaXJlY3RseSwgc28gdGhlcmUgaXMg
bm8gcmVhc29uIGZvciBleGNlcHRpb24gaGFuZGxpbmcNCj4gPj4gc3ltbWV0cnkgYmV0d2VlbiBo
b3N0IGFuZCBndWVzdC4NCj4gPj4NCj4gPj4gLU1pa2UNCj4gDQoNCg==
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 8:04 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E563@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 03:51 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>> Sent: Thursday, May 09, 2013 1:18 PM
>> To: Bhushan Bharat-R65777
>> Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
>> dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>> On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Linuxppc-dev [mailto:linuxppc-dev-
>>>> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of
>>>> bounces+Caraman
>>>> Mihai Claudiu-B02008
>>>> Sent: Wednesday, May 08, 2013 6:44 PM
>>>> To: Wood Scott-B07421; tiejun.chen
>>>> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
>>>> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
>>>> interrupts
>>>>
>>>>>> This only disable soft interrupt for kvmppc_restart_interrupt()
>>>>>> that restarts interrupts if they were meant for the host:
>>>>>>
>>>>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
>>>>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>>>>>
>>>>> Those aren't the only exceptions that can end up going to the host.
>>>>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
>>>>>
>>>>>> And shouldn't we handle kvmppc_restart_interrupt() like the
>>>>>> original HOST flow?
>>>>>>
>>>>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
>>>>>> ack) \
>>>>>>
>>>>>> START_EXCEPTION(label); \
>>>>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
>>>>>> PROLOG_ADDITION_MASKABLE)\
>>>>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
>>>>>> *INTS_DISABLE*) \
>>>>>> ...
>>>>>
>>>>> Could you elaborate on what you mean?
>>>>
>>>> I think Tiejun was saying that host has flags and replays only
>>>> EE/DEC/DBELL interrupts. There is special macro
>>>> masked_interrupt_book3e in those exception handlers that sets paca-
>>> irq_happened.
>>>>
>>>> The list of replied interrupts is limited to asynchronous noncritical
>>>> interrupts which can be masked by MSR[EE] (therefore no TLB miss).
>>>
>>> Embedded Perfmon interrupt is also asynchronous, Why that is not in the list
>> of masked interruts.
>>
>> Are you saying perfmon? If so, its also in that list:
>>
>> START_EXCEPTION(perfmon);
>> NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_MONITOR,
>> PROLOG_ADDITION_NONE)
>> EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
>
> Where it is recorded in paca->irq_happned to be replayed later ?
In stead of PROLOG_ADDITION_MASKABLE, actually we have nothing to do with
PROLOG_ADDITION_NONE for perfmon, so perfmon can be executed without lazy state.
Tiejun
>
>>
>> Tiejun
>>
>>>
>>> -Bharat
>>>
>>>> Now on KVM book3e we
>>>> don't want to put them in the irq_happened lazy state but rather to
>>>> execute them directly, so there is no reason for exception handling
>>>> symmetry between host and guest.
>>>>
>>>> -Mike
>>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox