* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 11:21 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: <518B77E5.9020809@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA5
LCAyMDEzIDM6NDggUE0NCj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogQ2FyYW1h
biBNaWhhaSBDbGF1ZGl1LUIwMjAwODsgV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiBk
ZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5v
cmc7DQo+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFU
Q0ggMS8xXSBrdm06cHBjOmJvb2tlLTY0OiBzb2Z0LWRpc2FibGUgaW50ZXJydXB0cw0KPiANCj4g
T24gMDUvMDkvMjAxMyAwNjowMCBQTSwgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3IHdyb3RlOg0KPiA+
DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdGllanVu
LmNoZW4gW21haWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiA+PiBTZW50OiBUaHVy
c2RheSwgTWF5IDA5LCAyMDEzIDM6MTUgUE0NCj4gPj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3
Nw0KPiA+PiBDYzogQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwODsgV29vZCBTY290dC1CMDc0
MjE7IGxpbnV4cHBjLQ0KPiA+PiBkZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsg
a3ZtLXBwY0B2Z2VyLmtlcm5lbC5vcmc7DQo+ID4+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4gPj4g
U3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFUQ0ggMS8xXSBrdm06cHBjOmJvb2tlLTY0OiBzb2Z0
LWRpc2FibGUNCj4gPj4gaW50ZXJydXB0cw0KPiA+Pg0KPiA+PiBPbiAwNS8wOS8yMDEzIDA0OjIz
IFBNLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IExpbnV4cHBjLWRldiBbbWFp
bHRvOmxpbnV4cHBjLWRldi0NCj4gPj4+PiBib3VuY2VzK2JoYXJhdC5iaHVzaGFuPWZyZWVzY2Fs
ZS5jb21AbGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+Pj4gYm91bmNlcytDYXJh
bWFuDQo+ID4+Pj4gTWloYWkgQ2xhdWRpdS1CMDIwMDgNCj4gPj4+PiBTZW50OiBXZWRuZXNkYXks
IE1heSAwOCwgMjAxMyA2OjQ0IFBNDQo+ID4+Pj4gVG86IFdvb2QgU2NvdHQtQjA3NDIxOyB0aWVq
dW4uY2hlbg0KPiA+Pj4+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZA
c3VzZS5kZTsNCj4gPj4+PiBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZnZXIua2VybmVs
Lm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJFOiBbUkZDXVtLVk1dW1BBVENIIDEvMV0ga3ZtOnBwYzpi
b29rZS02NDogc29mdC1kaXNhYmxlDQo+ID4+Pj4gaW50ZXJydXB0cw0KPiA+Pj4+DQo+ID4+Pj4+
PiBUaGlzIG9ubHkgZGlzYWJsZSBzb2Z0IGludGVycnVwdCBmb3Iga3ZtcHBjX3Jlc3RhcnRfaW50
ZXJydXB0KCkNCj4gPj4+Pj4+IHRoYXQgcmVzdGFydHMgaW50ZXJydXB0cyBpZiB0aGV5IHdlcmUg
bWVhbnQgZm9yIHRoZSBob3N0Og0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IGEuIFNPRlRfRElTQUJMRV9J
TlRTKCkgb25seSBmb3IgQk9PS0VfSU5URVJSVVBUX0VYVEVSTkFMIHwNCj4gPj4+Pj4+IEJPT0tF
X0lOVEVSUlVQVF9ERUNSRU1FTlRFUiB8IEJPT0tFX0lOVEVSUlVQVF9ET09SQkVMTA0KPiA+Pj4+
Pg0KPiA+Pj4+PiBUaG9zZSBhcmVuJ3QgdGhlIG9ubHkgZXhjZXB0aW9ucyB0aGF0IGNhbiBlbmQg
dXAgZ29pbmcgdG8gdGhlIGhvc3QuDQo+ID4+Pj4+IFdlIGNvdWxkIGdldCBhIFRMQiBtaXNzIHRo
YXQgcmVzdWx0cyBpbiBhIGhlYXZ5d2VpZ2h0IE1NSU8gZXhpdCwgZXRjLg0KPiA+Pj4+Pg0KPiA+
Pj4+Pj4gQW5kIHNob3VsZG4ndCB3ZSBoYW5kbGUga3ZtcHBjX3Jlc3RhcnRfaW50ZXJydXB0KCkg
bGlrZSB0aGUNCj4gPj4+Pj4+IG9yaWdpbmFsIEhPU1QgZmxvdz8NCj4gPj4+Pj4+DQo+ID4+Pj4+
PiAjZGVmaW5lIE1BU0tBQkxFX0VYQ0VQVElPTih0cmFwbnVtLCBpbnRudW0sIGxhYmVsLCBoZGxy
LA0KPiA+Pj4+Pj4gYWNrKSAgICAgICAgICAgXA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFNUQVJUX0VY
Q0VQVElPTihsYWJlbCk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
DQo+ID4+Pj4+PiAgICAgICAgICAgTk9STUFMX0VYQ0VQVElPTl9QUk9MT0codHJhcG51bSwgaW50
bnVtLA0KPiA+Pj4+Pj4gUFJPTE9HX0FERElUSU9OX01BU0tBQkxFKVwNCj4gPj4+Pj4+ICAgICAg
ICAgICBFWENFUFRJT05fQ09NTU9OKHRyYXBudW0sIFBBQ0FfRVhHRU4sDQo+ID4+Pj4+PiAqSU5U
U19ESVNBQkxFKikgICAgICAgICAgICAgXA0KPiA+Pj4+Pj4gCS4uLg0KPiA+Pj4+Pg0KPiA+Pj4+
PiBDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4/DQo+ID4+Pj4NCj4gPj4+PiBJ
IHRoaW5rIFRpZWp1biB3YXMgc2F5aW5nIHRoYXQgaG9zdCBoYXMgZmxhZ3MgYW5kIHJlcGxheXMg
b25seQ0KPiA+Pj4+IEVFL0RFQy9EQkVMTCBpbnRlcnJ1cHRzLiBUaGVyZSBpcyBzcGVjaWFsIG1h
Y3JvDQo+ID4+Pj4gbWFza2VkX2ludGVycnVwdF9ib29rM2UgaW4gdGhvc2UgZXhjZXB0aW9uIGhh
bmRsZXJzIHRoYXQgc2V0cyBwYWNhLQ0KPiA+Pj4gaXJxX2hhcHBlbmVkLg0KPiA+Pj4+DQo+ID4+
Pj4gVGhlIGxpc3Qgb2YgcmVwbGllZCBpbnRlcnJ1cHRzIGlzIGxpbWl0ZWQgdG8gYXN5bmNocm9u
b3VzDQo+ID4+Pj4gbm9uY3JpdGljYWwgaW50ZXJydXB0cyB3aGljaCBjYW4gYmUgbWFza2VkIGJ5
IE1TUltFRV0gKHRoZXJlZm9yZSBubyBUTEINCj4gbWlzcykuDQo+ID4+Pj4gTm93IG9uIEtWTSBi
b29rM2Ugd2UgZG9uJ3Qgd2FudCB0byBwdXQgdGhlbSBpbiB0aGUgaXJxX2hhcHBlbmVkDQo+ID4+
Pj4gbGF6eSBzdGF0ZSBidXQgcmF0aGVyIHRvIGV4ZWN1dGUgdGhlbSBkaXJlY3RseSwgc28gdGhl
cmUgaXMgbm8NCj4gPj4+PiByZWFzb24gZm9yIGV4Y2VwdGlvbiBoYW5kbGluZyBzeW1tZXRyeSBi
ZXR3ZWVuIGhvc3QgYW5kIGd1ZXN0Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBbm90aGVyIFF1ZXN0
aW9uOg0KPiA+Pj4NCj4gPj4+IFRoZSBjYXNlIGlzOg0KPiA+Pj4NCj4gPj4NCj4gPj4gQWN0dWFs
bHkgaW4gdGhlIGNhc2UgR1M9MSBldmVuIGlmIEVFPTAsIEVYVC9ERUMvREJFTEwgc3RpbGwgb2Nj
dXIgYXMgSQ0KPiByZWNhbGwuDQo+ID4+DQo+ID4+PiBDYXNlIDEpDQo+ID4+PiAgICAtPiBMb2Nh
bF9pcnFfZGlzYWJsZSgpICB3aWxsIHNldCBzb2Z0X2VuYWJsZWQgPSAwDQo+ID4+PiAgICAtPiBO
b3cgRXh0ZXJuZWwgaW50ZXJydXB0IGhhcHBlbnMsIHRoZXJlIHdlIHNldCBQQUNBX0lSUV9FRSBp
bg0KPiA+Pj4gaXJxX2hhcHBlbmVkLA0KPiA+PiBBbHNvIGNsZWFycyBFRSBpbiBTUlIxIGFuZCBy
ZmkuIFNvIGludGVycnVwdHMgYXJlIGhhcmQgZGlzYWJsZWQuIE5vDQo+ID4+IG1vcmUgb3RoZXIg
aW50ZXJydXB0IGdhdGVkIGJ5IE1TUi5FRSBjYW4gaGFwcGVuLiBMb29rcyBsaWtlIHRoZSBpZGVh
DQo+ID4+IGhlcmUgaXMgdG8gbm90IGxldCBhIGRldmljZSBrZWVwIG9uIGluc2VydGluZyBpbnRl
cnJ1cHQgdGlsbCB0aGUNCj4gPj4gaW50ZXJydXB0IGNvbmRpdGlvbiBvbiBkZXZpY2UgaXMgY2xl
YXJlZCwgcmlnaHQ/DQo+ID4+DQo+ID4+IEkgZG9uJ3QgdW5kZXJzdGFuZCAidGhlIGludGVycnVw
dCBjb25kaXRpb24gb24gZGV2aWNlIGlzIGNsZWFyZWQiIGhlcmUuDQo+ID4+DQo+ID4+IEkgdGhp
bmsgcmVnYXJkbGVzcyBpZiB5b3UgY2xlYXIgdGhlIGRldmljZSBpbnRlcnJ1cHQgc3RhdHVzLCB0
aGUNCj4gPj4gc3lzdGVtIHN0aWxsIHJlY2VpdmUgYSBwZW5kaW5nIGludGVycnVwdCBvbmNlIEVF
IG9yIEdTID0gMS4NCj4gPg0KPiA+IE9uY2UgeWVzLCBidXQgSSB0aGluayB0byBhdm9pZCBmbG9v
ZCBvZiBkZXZpY2UgaW50ZXJydXB0IHdlIGRpc2FibGUgTVNSLkVFDQo+IHdoZW4gc29mdC1kaXNh
YmxlZC4NCj4gDQo+IEJ1dCB3ZSBuZWl0aGVyIEFDSyBub3Igc2VuZCBFT0kgdG8gdGhhdCBpcnEg
aW4gdGhlIGludGVycnVwdCBjb250cm9sbGVyLCBzbyB0aGF0DQo+IHNob3VsZCBiZSBpbiBwZW5k
aW5nIHN0YXRlLg0KPiANCj4gPg0KPiA+Pg0KPiA+Pj4gICAgLT4gbG9jYWxfaXJxX2VuYWJsZSgp
IC0gVGhpcyBjaGVja3MgdGhhdCBpcnFfaGFwcGVuZWQgaXMgc2V0LCBhbmQNCj4gPj4+IHJlcGxh
eXMNCj4gPj4NCj4gPj4gcmV0X2Zyb21fZXhjZXB0IGFsc28gY2hlY2sgdG8gcmVwbGF5Lg0KPiA+
Pg0KPiA+Pj4NCj4gPj4+IE5vdyB0aGUgY2FzZSAyKQ0KPiA+Pj4gQ2FzZSAyKQ0KPiA+Pj4gLT4g
TG9jYWxfaXJxX2Rpc2FibGUoKSAgd2lsbCBzZXQgc29mdF9lbmFibGVkID0gMA0KPiA+Pj4gICAg
LT4gTm93IERFQyBpbnRlcnJ1cHQgaGFwcGVucy4gV2Ugc2V0IFBBQ0FfSVJRX0RFQyBpbg0KPiA+
Pj4gaXJxX2hhcHBlbmVkLCBCdXQgZG8NCj4gPj4gbm90IGNsZWFyIEVFIGluIFNSUjEgYW5kIHJm
aS4gU28gaW50ZXJydXB0cyBhcmUgbm90IGhhcmQgZGlzYWJsZWQuDQo+ID4+PiAgICAtPiBOb3cg
c2F5IEVFIGludGVycnVwdCBoYXBwZW5zLCB0aGVyZSB3ZSBzZXQgUEFDQV9JUlFfRUUgaW4NCj4g
Pj4+IGlycV9oYXBwZW5lZCwNCj4gPj4gQWxzbyBjbGVhcnMgRUUgaW4gU1JSMSBhbmQgcmZpLiBT
byBpbnRlcnJ1cHRzIGFyZSBoYXJkIGRpc2FibGVkLg0KPiA+Pj4gICAgLT4gbG9jYWxfaXJxX2Vu
YWJsZSgpIC0gVGhpcyBjaGVja3MgdGhhdCBpcnFfaGFwcGVuZWQgaXMgc2V0Lg0KPiA+Pj4gSUlV
QywgaXQgcmVwbGF5cyBvbmx5IG9uZSBpbnRlcnJ1cHQ/IGlzIG5vdCBpdD8NCj4gPj4NCj4gPj4g
QWZ0ZXIgYW55b25lIGlzIHJlcGxheWVkIGluIGFyY2hfbG9jYWxfaXJxX3Jlc3RvcmUoKSwgd2Ug
d2lsbCBzZXQNCj4gPj4gc29mdC9oYXJkIGludGVycnVwdCB0aGVyZToNCj4gPj4NCj4gPj4gc2V0
X3NvZnRfZW5hYmxlZCgxKTsNCj4gPj4gX19oYXJkX2lycV9lbmFibGUoKTsNCj4gPj4NCj4gPj4g
VGhlbiBhbnkgcGVuZGluZyBpbnRlcnJ1cHQgY2FuIGJlIGV4ZWN1dGVkIG5vdy4NCj4gPg0KPiA+
IERvIHlvdSBtZWFuIHRoYXQgdGhlIGludGVycnVwdCBzaG91bGQgZmlyZSBhZ2Fpbj8NCj4gDQo+
IEkgbWVhbnMgdGhlIHBlbmRpbmcgZXhjZXB0aW9uIGluY2x1ZGluZyBleHRlcm5hbCBpbnRlcnJ1
cHQsIHRoZSBkZWNyZW1lbnRlcg0KPiBleGNlcHRpb24gYW5kIHRoZSBkb29yYmVsbCBleGNlcHRp
b24sIGNhbiB0cmFwIENQVSBvbmNlIEVFPTEgd2l0aA0KPiBfX2hhcmRfaXJxX2VuYWJsZSgpIGhl
cmUuIFRoZW4gdGhlIGtlcm5lbCBjYW4gaGFuZGxlIHRob3NlIGV4Y2VwdGlvbiBzaW5jZSBzb2Z0
DQo+IGVuYWJsZSBpcyBhbHNvIDEgbm93Lg0KPiANCj4gPg0KPiA+Pg0KPiA+PiBBZGRpdGlvbmFs
bHksIHJldF9mcm9tX2V4Y2VwdCBwcm9iYWJseSBjaGVjayB0byByZXBsYXkgYWxsLg0KPiA+DQo+
ID4gTG9jYWxfaXJxX2VuYWJsZSgpIHdpbGwgbm90IHRha2UgdXMgdG8gcmV0X2Zyb21fZXhjZXB0
Lg0KPiANCj4gWWVzLiBJIGp1c3Qgc2F5IHJldF9mcm9tX2V4Y2VwdCBjYW4gcHJvdmlkZSBhbiBh
cHByb2FjaCB0byByZXBsYXkgYWxsIDopDQoNCl9fcmVwbGF5X2ludGVycnVwdCgpIGZyb20gYXJj
aF9sb2NhbF9pcnFfZW5hYmxlKCkgd2lsbCB0YWtlIHVzIHRvIHJldF9mcm9tX2V4Y2VwdC9saXRl
IDopDQpUaGVyZSBhbGwgcGVuZGluZyBpbnRlcnJ1cHRzIGFyZSByZXBsYXllZCBvbmUgYnkgb25l
IGJlZm9yZSB3ZSBoYXJkLWVuYWJsZSBhbmQgc29mdC1lbmFibGUgaW50ZXJydXB0cy4NCg0KLUJo
YXJhdA0KDQo+IA0KPiBUaWVqdW4NCg0K
^ permalink raw reply
* Re: [PATCH] powerpc/fsl: add property 'reg' to pcie@0 node
From: Kevin Hao @ 2013-05-09 10:41 UTC (permalink / raw)
To: Minghuan Lian; +Cc: linuxppc-dev, Zang Roy-R61911
In-Reply-To: <1368004641-12405-1-git-send-email-Minghuan.Lian@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]
On Wed, May 08, 2013 at 05:17:21PM +0800, Minghuan Lian wrote:
> The property 'reg' is used to identify the PCIe device. if there is
> no 'reg' the PCI driver can not find PCI device node corresponding
> to PCI controller, and can not map the interrupts. So all the INTx
> interrupts can not be used.
The fix for this issue has already been merged into upstream kernel.
commit 9e2ecdbba3b0745f9ed454ab86961e3ccf9dc224
Author: Kevin Hao <haokexin@gmail.com>
Date: Sun Apr 14 13:40:13 2013 +0800
powerpc/fsl-booke: add the reg prop for pci bridge device node for T4/B4
The reg property in the pci bridge device node is used to bind this
device node to the pci bridge device. Then all the pci devices under
this bridge could use the interrupt maps defined in this device node
to do the irq translation. So if this property is missed, the pci
traditional irq mechanism will not work.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Thanks,
Kevin
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> index 7399154..d82c8da 100644
> --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> @@ -49,6 +49,7 @@
> interrupts = <20 2 0 0>;
> fsl,iommu-parent = <&pamu0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> index bd611a9..3a6179f 100644
> --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> @@ -48,6 +48,7 @@
> bus-range = <0x0 0xff>;
> interrupts = <20 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> @@ -74,6 +75,7 @@
> bus-range = <0 0xff>;
> interrupts = <21 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> @@ -100,6 +102,7 @@
> bus-range = <0x0 0xff>;
> interrupts = <22 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> @@ -126,6 +129,7 @@
> bus-range = <0x0 0xff>;
> interrupts = <23 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> --
> 1.8.1.2
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH 20/21] powerpc/ps3: remove inline marking of EXPORT_SYMBOL functions
From: Denis Efremov @ 2013-05-09 10:36 UTC (permalink / raw)
To: Geoff Levand
Cc: ldv-project, trivial, Denis Efremov, linuxppc-dev, linux-kernel
In-Reply-To: <1368086241-9357-1-git-send-email-yefremov.denis@gmail.com>
EXPORT_SYMBOL and inline directives are contradictory to each other.
The patch fixes this inconsistency.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
---
arch/powerpc/platforms/ps3/spu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
index e17fa14..a0bca05 100644
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -143,7 +143,7 @@ static void _dump_areas(unsigned int spe_id, unsigned long priv2,
pr_debug("%s:%d: shadow: %lxh\n", func, line, shadow);
}
-inline u64 ps3_get_spe_id(void *arg)
+u64 ps3_get_spe_id(void *arg)
{
return spu_pdata(arg)->spe_id;
}
--
1.8.1.4
^ permalink raw reply related
* Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: tiejun.chen @ 2013-05-09 10:23 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: <518A1AD8.3090103@windriver.com>
On 05/08/2013 05:28 PM, tiejun.chen wrote:
> 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 :)
Looks KVM PPC have no this mechanism currently since I don't find MAS8_VF is
used in kernel, right?
If I'm missing something please correct me.
Tiejun
>
>> 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.
>
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 10:18 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: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E85D@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 06:00 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>> Sent: Thursday, May 09, 2013 3:15 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 04:23 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).
>>>> 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.
>>>
>>>
>>> Another Question:
>>>
>>> The case is:
>>>
>>
>> Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I recall.
>>
>>> Case 1)
>>> -> Local_irq_disable() will set soft_enabled = 0
>>> -> Now Externel interrupt happens, there we set PACA_IRQ_EE in irq_happened,
>> Also clears EE in SRR1 and rfi. So interrupts are hard disabled. No more other
>> interrupt gated by MSR.EE can happen. Looks like the idea here is to not let a
>> device keep on inserting interrupt till the interrupt condition on device is
>> cleared, right?
>>
>> I don't understand "the interrupt condition on device is cleared" here.
>>
>> I think regardless if you clear the device interrupt status, the system still
>> receive a pending interrupt once EE or GS = 1.
>
> Once yes, but I think to avoid flood of device interrupt we disable MSR.EE when soft-disabled.
But we neither ACK nor send EOI to that irq in the interrupt controller, so that
should be in pending state.
>
>>
>>> -> local_irq_enable() - This checks that irq_happened is set, and
>>> replays
>>
>> ret_from_except also check to replay.
>>
>>>
>>> Now the case 2)
>>> Case 2)
>>> -> Local_irq_disable() will set soft_enabled = 0
>>> -> Now DEC interrupt happens. We set PACA_IRQ_DEC in irq_happened, But do
>> not clear EE in SRR1 and rfi. So interrupts are not hard disabled.
>>> -> Now say EE interrupt happens, there we set PACA_IRQ_EE in irq_happened,
>> Also clears EE in SRR1 and rfi. So interrupts are hard disabled.
>>> -> local_irq_enable() - This checks that irq_happened is set.
>>> IIUC, it replays only one interrupt? is not it?
>>
>> After anyone is replayed in arch_local_irq_restore(), we will set soft/hard
>> interrupt there:
>>
>> set_soft_enabled(1);
>> __hard_irq_enable();
>>
>> Then any pending interrupt can be executed now.
>
> Do you mean that the interrupt should fire again?
I means the pending exception including external interrupt, the decrementer
exception and the doorbell exception, can trap CPU once EE=1 with
__hard_irq_enable() here. Then the kernel can handle those exception since soft
enable is also 1 now.
>
>>
>> Additionally, ret_from_except probably check to replay all.
>
> Local_irq_enable() will not take us to ret_from_except.
Yes. I just say ret_from_except can provide an approach to replay all :)
Tiejun
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 10:00 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: <518B7014.1090508@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA5
LCAyMDEzIDM6MTUgUE0NCj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogQ2FyYW1h
biBNaWhhaSBDbGF1ZGl1LUIwMjAwODsgV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiBk
ZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5v
cmc7DQo+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFU
Q0ggMS8xXSBrdm06cHBjOmJvb2tlLTY0OiBzb2Z0LWRpc2FibGUgaW50ZXJydXB0cw0KPiANCj4g
T24gMDUvMDkvMjAxMyAwNDoyMyBQTSwgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3IHdyb3RlOg0KPiA+
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+PiBOb3cgb24gS1ZNIGJvb2szZSB3ZSBkb24ndCB3YW50IHRv
IHB1dCB0aGVtIGluIHRoZSBpcnFfaGFwcGVuZWQgbGF6eQ0KPiA+PiBzdGF0ZSBidXQgcmF0aGVy
IHRvIGV4ZWN1dGUgdGhlbSBkaXJlY3RseSwgc28gdGhlcmUgaXMgbm8gcmVhc29uIGZvcg0KPiA+
PiBleGNlcHRpb24gaGFuZGxpbmcgc3ltbWV0cnkgYmV0d2VlbiBob3N0IGFuZCBndWVzdC4NCj4g
Pg0KPiA+DQo+ID4gQW5vdGhlciBRdWVzdGlvbjoNCj4gPg0KPiA+IFRoZSBjYXNlIGlzOg0KPiA+
DQo+IA0KPiBBY3R1YWxseSBpbiB0aGUgY2FzZSBHUz0xIGV2ZW4gaWYgRUU9MCwgRVhUL0RFQy9E
QkVMTCBzdGlsbCBvY2N1ciBhcyBJIHJlY2FsbC4NCj4gDQo+ID4gQ2FzZSAxKQ0KPiA+ICAgLT4g
TG9jYWxfaXJxX2Rpc2FibGUoKSAgd2lsbCBzZXQgc29mdF9lbmFibGVkID0gMA0KPiA+ICAgLT4g
Tm93IEV4dGVybmVsIGludGVycnVwdCBoYXBwZW5zLCB0aGVyZSB3ZSBzZXQgUEFDQV9JUlFfRUUg
aW4gaXJxX2hhcHBlbmVkLA0KPiBBbHNvIGNsZWFycyBFRSBpbiBTUlIxIGFuZCByZmkuIFNvIGlu
dGVycnVwdHMgYXJlIGhhcmQgZGlzYWJsZWQuIE5vIG1vcmUgb3RoZXINCj4gaW50ZXJydXB0IGdh
dGVkIGJ5IE1TUi5FRSBjYW4gaGFwcGVuLiBMb29rcyBsaWtlIHRoZSBpZGVhIGhlcmUgaXMgdG8g
bm90IGxldCBhDQo+IGRldmljZSBrZWVwIG9uIGluc2VydGluZyBpbnRlcnJ1cHQgdGlsbCB0aGUg
aW50ZXJydXB0IGNvbmRpdGlvbiBvbiBkZXZpY2UgaXMNCj4gY2xlYXJlZCwgcmlnaHQ/DQo+IA0K
PiBJIGRvbid0IHVuZGVyc3RhbmQgInRoZSBpbnRlcnJ1cHQgY29uZGl0aW9uIG9uIGRldmljZSBp
cyBjbGVhcmVkIiBoZXJlLg0KPiANCj4gSSB0aGluayByZWdhcmRsZXNzIGlmIHlvdSBjbGVhciB0
aGUgZGV2aWNlIGludGVycnVwdCBzdGF0dXMsIHRoZSBzeXN0ZW0gc3RpbGwNCj4gcmVjZWl2ZSBh
IHBlbmRpbmcgaW50ZXJydXB0IG9uY2UgRUUgb3IgR1MgPSAxLg0KDQpPbmNlIHllcywgYnV0IEkg
dGhpbmsgdG8gYXZvaWQgZmxvb2Qgb2YgZGV2aWNlIGludGVycnVwdCB3ZSBkaXNhYmxlIE1TUi5F
RSB3aGVuIHNvZnQtZGlzYWJsZWQuDQoNCj4gDQo+ID4gICAtPiBsb2NhbF9pcnFfZW5hYmxlKCkg
LSBUaGlzIGNoZWNrcyB0aGF0IGlycV9oYXBwZW5lZCBpcyBzZXQsIGFuZA0KPiA+IHJlcGxheXMN
Cj4gDQo+IHJldF9mcm9tX2V4Y2VwdCBhbHNvIGNoZWNrIHRvIHJlcGxheS4NCj4gDQo+ID4NCj4g
PiBOb3cgdGhlIGNhc2UgMikNCj4gPiBDYXNlIDIpDQo+ID4gLT4gTG9jYWxfaXJxX2Rpc2FibGUo
KSAgd2lsbCBzZXQgc29mdF9lbmFibGVkID0gMA0KPiA+ICAgLT4gTm93IERFQyBpbnRlcnJ1cHQg
aGFwcGVucy4gV2Ugc2V0IFBBQ0FfSVJRX0RFQyBpbiBpcnFfaGFwcGVuZWQsIEJ1dCBkbw0KPiBu
b3QgY2xlYXIgRUUgaW4gU1JSMSBhbmQgcmZpLiBTbyBpbnRlcnJ1cHRzIGFyZSBub3QgaGFyZCBk
aXNhYmxlZC4NCj4gPiAgIC0+IE5vdyBzYXkgRUUgaW50ZXJydXB0IGhhcHBlbnMsIHRoZXJlIHdl
IHNldCBQQUNBX0lSUV9FRSBpbiBpcnFfaGFwcGVuZWQsDQo+IEFsc28gY2xlYXJzIEVFIGluIFNS
UjEgYW5kIHJmaS4gU28gaW50ZXJydXB0cyBhcmUgaGFyZCBkaXNhYmxlZC4NCj4gPiAgIC0+IGxv
Y2FsX2lycV9lbmFibGUoKSAtIFRoaXMgY2hlY2tzIHRoYXQgaXJxX2hhcHBlbmVkIGlzIHNldC4N
Cj4gPiBJSVVDLCBpdCByZXBsYXlzIG9ubHkgb25lIGludGVycnVwdD8gaXMgbm90IGl0Pw0KPiAN
Cj4gQWZ0ZXIgYW55b25lIGlzIHJlcGxheWVkIGluIGFyY2hfbG9jYWxfaXJxX3Jlc3RvcmUoKSwg
d2Ugd2lsbCBzZXQgc29mdC9oYXJkDQo+IGludGVycnVwdCB0aGVyZToNCj4gDQo+IHNldF9zb2Z0
X2VuYWJsZWQoMSk7DQo+IF9faGFyZF9pcnFfZW5hYmxlKCk7DQo+IA0KPiBUaGVuIGFueSBwZW5k
aW5nIGludGVycnVwdCBjYW4gYmUgZXhlY3V0ZWQgbm93Lg0KDQpEbyB5b3UgbWVhbiB0aGF0IHRo
ZSBpbnRlcnJ1cHQgc2hvdWxkIGZpcmUgYWdhaW4/DQoNCj4gDQo+IEFkZGl0aW9uYWxseSwgcmV0
X2Zyb21fZXhjZXB0IHByb2JhYmx5IGNoZWNrIHRvIHJlcGxheSBhbGwuDQoNCkxvY2FsX2lycV9l
bmFibGUoKSB3aWxsIG5vdCB0YWtlIHVzIHRvIHJldF9mcm9tX2V4Y2VwdC4NCg0KLUJoYXJhdA0K
DQo+IA0KPiBUaWVqdW4NCg0K
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 9:44 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: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E64A@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 04:23 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). 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.
>
>
> Another Question:
>
> The case is:
>
Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I recall.
> Case 1)
> -> Local_irq_disable() will set soft_enabled = 0
> -> Now Externel interrupt happens, there we set PACA_IRQ_EE in irq_happened, Also clears EE in SRR1 and rfi. So interrupts are hard disabled. No more other interrupt gated by MSR.EE can happen. Looks like the idea here is to not let a device keep on inserting interrupt till the interrupt condition on device is cleared, right?
I don't understand "the interrupt condition on device is cleared" here.
I think regardless if you clear the device interrupt status, the system still
receive a pending interrupt once EE or GS = 1.
> -> local_irq_enable() - This checks that irq_happened is set, and replays
ret_from_except also check to replay.
>
> Now the case 2)
> Case 2)
> -> Local_irq_disable() will set soft_enabled = 0
> -> Now DEC interrupt happens. We set PACA_IRQ_DEC in irq_happened, But do not clear EE in SRR1 and rfi. So interrupts are not hard disabled.
> -> Now say EE interrupt happens, there we set PACA_IRQ_EE in irq_happened, Also clears EE in SRR1 and rfi. So interrupts are hard disabled.
> -> local_irq_enable() - This checks that irq_happened is set.
> IIUC, it replays only one interrupt? is not it?
After anyone is replayed in arch_local_irq_restore(), we will set soft/hard
interrupt there:
set_soft_enabled(1);
__hard_irq_enable();
Then any pending interrupt can be executed now.
Additionally, ret_from_except probably check to replay all.
Tiejun
^ permalink raw reply
* [PATCH] powerpc/fsl: add property 'reg' to pcie@0 node
From: Minghuan Lian @ 2013-05-08 9:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Minghuan Lian, Zang Roy-R61911
The property 'reg' is used to identify the PCIe device. if there is
no 'reg' the PCI driver can not find PCI device node corresponding
to PCI controller, and can not map the interrupts. So all the INTx
interrupts can not be used.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
---
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..d82c8da 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -49,6 +49,7 @@
interrupts = <20 2 0 0>;
fsl,iommu-parent = <&pamu0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index bd611a9..3a6179f 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -48,6 +48,7 @@
bus-range = <0x0 0xff>;
interrupts = <20 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -74,6 +75,7 @@
bus-range = <0 0xff>;
interrupts = <21 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -100,6 +102,7 @@
bus-range = <0x0 0xff>;
interrupts = <22 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -126,6 +129,7 @@
bus-range = <0x0 0xff>;
interrupts = <23 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
--
1.8.1.2
^ permalink raw reply related
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 8:26 UTC (permalink / raw)
To: tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, Kevin Hao, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <518B5B9B.6020901@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA5
LCAyMDEzIDE6NDggUE0NCj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogS2V2aW4g
SGFvOyBDYXJhbWFuIE1paGFpIENsYXVkaXUtQjAyMDA4OyBrdm1Admdlci5rZXJuZWwub3JnOyBX
b29kIFNjb3R0LQ0KPiBCMDc0MjE7IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1JGQ11b
S1ZNXVtQQVRDSCAxLzFdIGt2bTpwcGM6Ym9va2UtNjQ6IHNvZnQtZGlzYWJsZSBpbnRlcnJ1cHRz
DQo+IA0KPiBPbiAwNS8wOS8yMDEzIDA0OjEyIFBNLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3Jv
dGU6DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t
OiBLZXZpbiBIYW8gW21haWx0bzpoYW9rZXhpbkBnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IFRodXJz
ZGF5LCBNYXkgMDksIDIwMTMgMTozOCBQTQ0KPiA+PiBUbzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3
DQo+ID4+IENjOiB0aWVqdW4uY2hlbjsgQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwODsga3Zt
QHZnZXIua2VybmVsLm9yZzsNCj4gPj4gV29vZCBTY290dC0gQjA3NDIxOyBhZ3JhZkBzdXNlLmRl
OyBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsNCj4gPj4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFi
cy5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFUQ0ggMS8xXSBrdm06cHBjOmJv
b2tlLTY0OiBzb2Z0LWRpc2FibGUNCj4gPj4gaW50ZXJydXB0cw0KPiA+Pg0KPiA+PiBPbiBUaHUs
IE1heSAwOSwgMjAxMyBhdCAwNzo1MTowOUFNICswMDAwLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcg
d3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+Pj4+IEZyb206IHRpZWp1bi5jaGVuIFttYWlsdG86dGllanVuLmNoZW5Ad2luZHJpdmVyLmNv
bV0NCj4gPj4+PiBTZW50OiBUaHVyc2RheSwgTWF5IDA5LCAyMDEzIDE6MTggUE0NCj4gPj4+PiBU
bzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4+Pj4gQ2M6IENhcmFtYW4gTWloYWkgQ2xhdWRp
dS1CMDIwMDg7IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51eHBwYy0NCj4gPj4+PiBkZXZAbGlzdHMu
b3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5vcmc7DQo+ID4+
Pj4ga3ZtQHZnZXIua2VybmVsLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbUkZDXVtLVk1dW1BB
VENIIDEvMV0ga3ZtOnBwYzpib29rZS02NDogc29mdC1kaXNhYmxlDQo+ID4+Pj4gaW50ZXJydXB0
cw0KPiA+Pj4+DQo+ID4+Pj4gT24gMDUvMDkvMjAxMyAwMzozMyBQTSwgQmh1c2hhbiBCaGFyYXQt
UjY1Nzc3IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IExpbnV4cHBjLWRldiBbbWFpbHRvOmxpbnV4cHBj
LWRldi0NCj4gPj4+Pj4+IGJvdW5jZXMrYmhhcmF0LmJodXNoYW49ZnJlZXNjYWxlLmNvbUBsaXN0
cy5vemxhYnMub3JnXSBPbiBCZWhhbGYNCj4gPj4+Pj4+IGJvdW5jZXMrT2YgQ2FyYW1hbg0KPiA+
Pj4+Pj4gTWloYWkgQ2xhdWRpdS1CMDIwMDgNCj4gPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5
IDA4LCAyMDEzIDY6NDQgUE0NCj4gPj4+Pj4+IFRvOiBXb29kIFNjb3R0LUIwNzQyMTsgdGllanVu
LmNoZW4NCj4gPj4+Pj4+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZA
c3VzZS5kZTsNCj4gPj4+Pj4+IGt2bS1wcGNAdmdlci5rZXJuZWwub3JnOyBrdm1Admdlci5rZXJu
ZWwub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSRTogW1JGQ11bS1ZNXVtQQVRDSCAxLzFdIGt2bTpw
cGM6Ym9va2UtNjQ6IHNvZnQtZGlzYWJsZQ0KPiA+Pj4+Pj4gaW50ZXJydXB0cw0KPiA+Pj4+Pj4N
Cj4gPj4+Pj4+Pj4gVGhpcyBvbmx5IGRpc2FibGUgc29mdCBpbnRlcnJ1cHQgZm9yIGt2bXBwY19y
ZXN0YXJ0X2ludGVycnVwdCgpDQo+ID4+Pj4+Pj4+IHRoYXQgcmVzdGFydHMgaW50ZXJydXB0cyBp
ZiB0aGV5IHdlcmUgbWVhbnQgZm9yIHRoZSBob3N0Og0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBh
LiBTT0ZUX0RJU0FCTEVfSU5UUygpIG9ubHkgZm9yIEJPT0tFX0lOVEVSUlVQVF9FWFRFUk5BTCB8
DQo+ID4+Pj4+Pj4+IEJPT0tFX0lOVEVSUlVQVF9ERUNSRU1FTlRFUiB8IEJPT0tFX0lOVEVSUlVQ
VF9ET09SQkVMTA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhvc2UgYXJlbid0IHRoZSBvbmx5IGV4
Y2VwdGlvbnMgdGhhdCBjYW4gZW5kIHVwIGdvaW5nIHRvIHRoZSBob3N0Lg0KPiA+Pj4+Pj4+IFdl
IGNvdWxkIGdldCBhIFRMQiBtaXNzIHRoYXQgcmVzdWx0cyBpbiBhIGhlYXZ5d2VpZ2h0IE1NSU8g
ZXhpdCwgZXRjLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEFuZCBzaG91bGRuJ3Qgd2UgaGFuZGxl
IGt2bXBwY19yZXN0YXJ0X2ludGVycnVwdCgpIGxpa2UgdGhlDQo+ID4+Pj4+Pj4+IG9yaWdpbmFs
IEhPU1QgZmxvdz8NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gI2RlZmluZSBNQVNLQUJMRV9FWENF
UFRJT04odHJhcG51bSwgaW50bnVtLCBsYWJlbCwgaGRsciwNCj4gPj4+Pj4+Pj4gYWNrKSAgICAg
ICAgICAgXA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBTVEFSVF9FWENFUFRJT04obGFiZWwpOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiA+Pj4+Pj4+PiAgICAg
ICAgICAgTk9STUFMX0VYQ0VQVElPTl9QUk9MT0codHJhcG51bSwgaW50bnVtLA0KPiA+Pj4+Pj4+
PiBQUk9MT0dfQURESVRJT05fTUFTS0FCTEUpXA0KPiA+Pj4+Pj4+PiAgICAgICAgICAgRVhDRVBU
SU9OX0NPTU1PTih0cmFwbnVtLCBQQUNBX0VYR0VOLA0KPiA+Pj4+Pj4+PiAqSU5UU19ESVNBQkxF
KikgICAgICAgICAgICAgXA0KPiA+Pj4+Pj4+PiAJLi4uDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBD
b3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g
SSB0aGluayBUaWVqdW4gd2FzIHNheWluZyB0aGF0IGhvc3QgaGFzIGZsYWdzIGFuZCByZXBsYXlz
IG9ubHkNCj4gPj4+Pj4+IEVFL0RFQy9EQkVMTCBpbnRlcnJ1cHRzLiBUaGVyZSBpcyBzcGVjaWFs
IG1hY3JvDQo+ID4+Pj4+PiBtYXNrZWRfaW50ZXJydXB0X2Jvb2szZSBpbiB0aG9zZSBleGNlcHRp
b24gaGFuZGxlcnMgdGhhdCBzZXRzDQo+ID4+Pj4+PiBwYWNhLQ0KPiA+Pj4+PiBpcnFfaGFwcGVu
ZWQuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIGxpc3Qgb2YgcmVwbGllZCBpbnRlcnJ1cHRzIGlz
IGxpbWl0ZWQgdG8gYXN5bmNocm9ub3VzDQo+ID4+Pj4+PiBub25jcml0aWNhbCBpbnRlcnJ1cHRz
IHdoaWNoIGNhbiBiZSBtYXNrZWQgYnkgTVNSW0VFXSAodGhlcmVmb3JlDQo+ID4+Pj4+PiBubyBU
TEINCj4gPj4gbWlzcykuDQo+ID4+Pj4+DQo+ID4+Pj4+IEVtYmVkZGVkIFBlcmZtb24gaW50ZXJy
dXB0IGlzIGFsc28gYXN5bmNocm9ub3VzLCBXaHkgdGhhdCBpcyBub3QNCj4gPj4+Pj4gaW4gdGhl
IGxpc3QNCj4gPj4+PiBvZiBtYXNrZWQgaW50ZXJydXRzLg0KPiA+Pj4+DQo+ID4+Pj4gQXJlIHlv
dSBzYXlpbmcgcGVyZm1vbj8gSWYgc28sIGl0cyBhbHNvIGluIHRoYXQgbGlzdDoNCj4gPj4+Pg0K
PiA+Pj4+ICAgICAgICAgICBTVEFSVF9FWENFUFRJT04ocGVyZm1vbik7DQo+ID4+Pj4gICAgICAg
ICAgIE5PUk1BTF9FWENFUFRJT05fUFJPTE9HKDB4MjYwLA0KPiBCT09LRV9JTlRFUlJVUFRfUEVS
Rk9STUFOQ0VfTU9OSVRPUiwNCj4gPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgUFJPTE9HX0FERElUSU9OX05PTkUpDQo+ID4+Pj4gICAgICAgICAgIEVYQ0VQVElPTl9DT01N
T04oMHgyNjAsIFBBQ0FfRVhHRU4sIElOVFNfRElTQUJMRSkNCj4gPj4+DQo+ID4+PiBXaGVyZSBp
dCBpcyByZWNvcmRlZCBpbiBwYWNhLT5pcnFfaGFwcG5lZCB0byBiZSByZXBsYXllZCBsYXRlciA/
DQo+ID4+DQo+ID4+IEFjdHVhbGx5IHdlIGRvbid0IHdhbnQgcmVwbGF5IHRoZSBwZXJmbW9uIGlu
dGVycnVwdCBsYXRlci4gV2Ugd291bGQNCj4gPj4gcnVuIGl0IGV2ZW4gc29mdCBpcnEgaXMgZGlz
YWJsZWQgYW5kIGp1c3QgdHJlYXQgaXQgYXMgTk1JLiBQbGVhc2Ugc2VlDQo+ID4+IHRoZSBmb2xs
b3dpbmcgZnVuY3Rpb24gcXVvdGVkIGZyb20gYXJjaC9wb3dlcnBjL3BlcmYvY29yZS1mc2wtZW1i
LmM6DQo+ID4+ICAgIC8qDQo+ID4+ICAgICAqIElmIGludGVycnVwdHMgd2VyZSBzb2Z0LWRpc2Fi
bGVkIHdoZW4gYSBQTVUgaW50ZXJydXB0IG9jY3VycywgdHJlYXQNCj4gPj4gICAgICogaXQgYXMg
YW4gTk1JLg0KPiA+PiAgICAgKi8NCj4gPj4gICAgc3RhdGljIGlubGluZSBpbnQgcGVyZl9pbnRy
X2lzX25taShzdHJ1Y3QgcHRfcmVncyAqcmVncykNCj4gPj4gICAgew0KPiA+PiAgICAjaWZkZWYg
X19wb3dlcnBjNjRfXw0KPiA+PiAgICAgICAgICAgIHJldHVybiAhcmVncy0+c29mdGU7DQo+ID4+
ICAgICNlbHNlDQo+ID4+ICAgICAgICAgICAgcmV0dXJuIDA7DQo+ID4+ICAgICNlbmRpZg0KPiA+
PiAgICB9DQo+ID4NCj4gPiBJcyBpdCBiZWNhdXNlIHRoYXQgd2UgY2Fubm90IGFmZm9yZCB0byBs
b3NlIHBlcmZtb24gaW50ZXJydXB0IGZvciBtb3JlDQo+IGFjY3VyYXRlIGNhcHR1cmluZyBvZiBk
YXRhID8NCj4gDQo+ICAgICAgcG93ZXJwYy9wZXJmOiBlNTAwIHN1cHBvcnQNCj4gDQo+ICAgICAg
VGhpcyBpbXBsZW1lbnRzIHBlcmZfZXZlbnQgc3VwcG9ydCBmb3IgdGhlIEZyZWVzY2FsZSBlbWJl
ZGRlZCBwZXJmb3JtYW5jZQ0KPiAgICAgIG1vbml0b3IsIGJhc2VkIG9uIHRoZSBleGlzdGluZyBw
ZXJmX2V2ZW50LmMgdGhhdCBzdXBwb3J0cyBzZXJ2ZXIvY2xhc3NpYw0KPiAgICAgIGNoaXBzLg0K
PiANCj4gICAgICBTb21lIGxpbWl0YXRpb25zOg0KPiAgICAgIC0gUGVyZm9ybWFuY2UgbW9uaXRv
ciBpbnRlcnJ1cHRzIGFyZSByZWd1bGFyIEVFIGludGVycnVwdHMsIGFuZCB0aHVzIHlvdQ0KPiAg
ICAgICAgY2FuJ3QgcHJvZmlsZSBwbGFjZXMgd2l0aCBpbnRlcnJ1cHRzIGRpc2FibGVkLiAgV2Ug
bWF5IHdhbnQgdG8gaW1wbGVtZW50DQo+ICAgICAgICBzb2Z0IElSUS1kaXNhYmxpbmcsIHdpdGgg
cGVyZm1vbiBpbnRlcnJ1cHRzIGV4ZW1wdGVkIGFuZCB0cmVhdGVkIGFzIE5NSXMuDQoNCkFoaCwg
dGhhdCBnaXZlcyB0aGUgYW5zd2VyIGFuZCBzYW1lIGFzIEkgZXhwZWN0ZWQgOikNCg0KLUJoYXJh
dA0KDQo+IA0KPiBUaWVqdW4NCj4gDQo+ID4NCj4gPiAtQmhhcmF0DQo+ID4NCj4gPj4NCj4gPj4g
VGhhbmtzLA0KPiA+PiBLZXZpbg0KPiA+Pg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+IFRpZWp1bg0K
PiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IC1CaGFyYXQNCj4gPj4+Pj4NCj4gPj4+Pj4+IE5vdyBv
biBLVk0gYm9vazNlIHdlDQo+ID4+Pj4+PiBkb24ndCB3YW50IHRvIHB1dCB0aGVtIGluIHRoZSBp
cnFfaGFwcGVuZWQgbGF6eSBzdGF0ZSBidXQgcmF0aGVyDQo+ID4+Pj4+PiB0byBleGVjdXRlIHRo
ZW0gZGlyZWN0bHksIHNvIHRoZXJlIGlzIG5vIHJlYXNvbiBmb3IgZXhjZXB0aW9uDQo+ID4+Pj4+
PiBoYW5kbGluZyBzeW1tZXRyeSBiZXR3ZWVuIGhvc3QgYW5kIGd1ZXN0Lg0KPiA+Pj4+Pj4NCj4g
Pj4+Pj4+IC1NaWtlDQo+ID4+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gTGludXhwcGMtZGV2IG1haWxpbmcgbGlz
dA0KPiA+Pj4gTGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPj4+IGh0dHBzOi8vbGlz
dHMub3psYWJzLm9yZy9saXN0aW5mby9saW51eHBwYy1kZXYNCj4gPg0KPiA+DQo+ID4NCj4gDQoN
Cg==
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 8:23 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). 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.
Another Question:=20
The case is:=20
Case 1)
-> Local_irq_disable() will set soft_enabled =3D 0
-> Now Externel interrupt happens, there we set PACA_IRQ_EE in irq_happene=
d, Also clears EE in SRR1 and rfi. So interrupts are hard disabled. No more=
other interrupt gated by MSR.EE can happen. Looks like the idea here is to=
not let a device keep on inserting interrupt till the interrupt condition =
on device is cleared, right?
-> local_irq_enable() - This checks that irq_happened is set, and replays
Now the case 2)
Case 2)
-> Local_irq_disable() will set soft_enabled =3D 0
-> Now DEC interrupt happens. We set PACA_IRQ_DEC in irq_happened, But do =
not clear EE in SRR1 and rfi. So interrupts are not hard disabled.=20
-> Now say EE interrupt happens, there we set PACA_IRQ_EE in irq_happened,=
Also clears EE in SRR1 and rfi. So interrupts are hard disabled.=20
-> local_irq_enable() - This checks that irq_happened is set.
IIUC, it replays only one interrupt? is not it?
-Bharat
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Kevin Hao @ 2013-05-09 8:21 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E5F5@039-SN2MPN1-011.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]
On Thu, May 09, 2013 at 08:12:51AM +0000, Bhushan Bharat-R65777 wrote:
>
>
> > -----Original Message-----
> > From: Kevin Hao [mailto:haokexin@gmail.com]
> > Sent: Thursday, May 09, 2013 1:38 PM
> > To: Bhushan Bharat-R65777
> > Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood Scott-
> > B07421; agraf@suse.de; kvm-ppc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
> >
> > On Thu, May 09, 2013 at 07:51:09AM +0000, 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
> > > > >> bounces+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)
> > >
> > > Where it is recorded in paca->irq_happned to be replayed later ?
> >
> > Actually we don't want replay the perfmon interrupt later. We would run it even
> > soft irq is disabled and just treat it as NMI. Please see the following function
> > quoted from arch/powerpc/perf/core-fsl-emb.c:
> > /*
> > * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> > * it as an NMI.
> > */
> > static inline int perf_intr_is_nmi(struct pt_regs *regs)
> > {
> > #ifdef __powerpc64__
> > return !regs->softe;
> > #else
> > return 0;
> > #endif
> > }
>
> Is it because that we cannot afford to lose perfmon interrupt for more accurate capturing of data ?
Yes, I think this will definitely improve the perf sample quality.
Thanks,
Kevin
>
> -Bharat
>
> >
> > Thanks,
> > Kevin
> >
> > >
> > > >
> > > > 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
> > > >
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 8:17 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, Kevin Hao, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E5F5@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 04:12 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: Kevin Hao [mailto:haokexin@gmail.com]
>> Sent: Thursday, May 09, 2013 1:38 PM
>> To: Bhushan Bharat-R65777
>> Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood Scott-
>> B07421; agraf@suse.de; kvm-ppc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>> On Thu, May 09, 2013 at 07:51:09AM +0000, 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
>>>>>> bounces+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)
>>>
>>> Where it is recorded in paca->irq_happned to be replayed later ?
>>
>> Actually we don't want replay the perfmon interrupt later. We would run it even
>> soft irq is disabled and just treat it as NMI. Please see the following function
>> quoted from arch/powerpc/perf/core-fsl-emb.c:
>> /*
>> * If interrupts were soft-disabled when a PMU interrupt occurs, treat
>> * it as an NMI.
>> */
>> static inline int perf_intr_is_nmi(struct pt_regs *regs)
>> {
>> #ifdef __powerpc64__
>> return !regs->softe;
>> #else
>> return 0;
>> #endif
>> }
>
> Is it because that we cannot afford to lose perfmon interrupt for more accurate capturing of data ?
powerpc/perf: e500 support
This implements perf_event support for the Freescale embedded performance
monitor, based on the existing perf_event.c that supports server/classic
chips.
Some limitations:
- Performance monitor interrupts are regular EE interrupts, and thus you
can't profile places with interrupts disabled. We may want to implement
soft IRQ-disabling, with perfmon interrupts exempted and treated as NMIs.
Tiejun
>
> -Bharat
>
>>
>> Thanks,
>> Kevin
>>
>>>
>>>>
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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: Bhushan Bharat-R65777 @ 2013-05-09 8:12 UTC (permalink / raw)
To: Kevin Hao
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130509080813.GD2263@pek-khao-d1.corp.ad.wrs.com>
> -----Original Message-----
> From: Kevin Hao [mailto:haokexin@gmail.com]
> Sent: Thursday, May 09, 2013 1:38 PM
> To: Bhushan Bharat-R65777
> Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood =
Scott-
> B07421; agraf@suse.de; kvm-ppc@vger.kernel.org; linuxppc-dev@lists.ozlabs=
.org
> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interru=
pts
>=20
> On Thu, May 09, 2013 at 07:51:09AM +0000, 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=3Dfreescale.com@lists.ozlabs.org] On Behalf
> > > >> bounces+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 hos=
t.
> > > >>> 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 n=
o 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_M=
ONITOR,
> > > PROLOG_ADDITION_NONE)
> > > EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
> >
> > Where it is recorded in paca->irq_happned to be replayed later ?
>=20
> Actually we don't want replay the perfmon interrupt later. We would run i=
t even
> soft irq is disabled and just treat it as NMI. Please see the following f=
unction
> quoted from arch/powerpc/perf/core-fsl-emb.c:
> /*
> * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> * it as an NMI.
> */
> static inline int perf_intr_is_nmi(struct pt_regs *regs)
> {
> #ifdef __powerpc64__
> return !regs->softe;
> #else
> return 0;
> #endif
> }
Is it because that we cannot afford to lose perfmon interrupt for more accu=
rate capturing of data ?
-Bharat
>=20
> Thanks,
> Kevin
>=20
> >
> > >
> > > 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
> > >
> >
> > _______________________________________________
> > 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: Kevin Hao @ 2013-05-09 8:08 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E563@039-SN2MPN1-011.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 4122 bytes --]
On Thu, May 09, 2013 at 07:51:09AM +0000, 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 ?
Actually we don't want replay the perfmon interrupt later. We would run it
even soft irq is disabled and just treat it as NMI. Please see the following
function quoted from arch/powerpc/perf/core-fsl-emb.c:
/*
* If interrupts were soft-disabled when a PMU interrupt occurs, treat
* it as an NMI.
*/
static inline int perf_intr_is_nmi(struct pt_regs *regs)
{
#ifdef __powerpc64__
return !regs->softe;
#else
return 0;
#endif
}
Thanks,
Kevin
>
> >
> > 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
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ 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
* 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 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: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
* [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
* [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
* 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] 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: 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
* 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: 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
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