* 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: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: Caraman Mihai Claudiu-B02008 @ 2013-05-09 11:34 UTC (permalink / raw)
To: tiejun.chen
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <518B7913.6010302@windriver.com>
PiA+PiBWRiBzdGFuZHMgZm9yIHZpcnR1YWxpemF0aW9uIGZhdWx0IHNlZSBNQVM4W1ZGXSBhbmQg
d2UgbWF5IHVzZSBpdCBmb3INCj4gdmlydHVhbGl6ZWQNCj4gDQo+IExvb2tzIEtWTSBQUEMgaGF2
ZSBubyB0aGlzIG1lY2hhbmlzbSBjdXJyZW50bHkgc2luY2UgSSBkb24ndCBmaW5kIE1BUzhfVkYN
Cj4gaXMNCj4gdXNlZCBpbiBrZXJuZWwsIHJpZ2h0Pw0KDQpZZXMgYnV0ICd3ZSBtYXkgdXNlIGl0
JyBpbiB0aGUgZmVhdHVyZSwgSSBoYXZlIGEgZnVuY3Rpb25hbCBQT0Mgd2l0aCBWRi4NCk5vdyB3
ZSBjYXB0dXJlIHZpcnR1YWxpemVkIE1NSU8gYWNjZXNzZXMgYXMgVExCIG1pc3NlcyAod2UgZG9u
J3Qgd3JpdGUNCmludG8gSFcgVExCIGd1ZXN0IHRyYW5zbGF0aW9uIG91dHNpZGUgdmlzaWJsZSBt
ZW1zbG90cykuDQoNCi1NaWtlDQo=
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 11:35 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: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E9C1@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 07:21 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>> Sent: Thursday, May 09, 2013 3:48 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 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 :)
>
> __replay_interrupt() from arch_local_irq_enable() will take us to ret_from_except/lite :)
> There all pending interrupts are replayed one by one before we hard-enable and soft-enable interrupts.
Yes, but a point needs to be corrected,
_replay_interrupt() is following set_soft_enabled(1), so __replay_interrupt()
can go the exception entry to call the handler.
Tiejun
^ permalink raw reply
* Re: [PATCH 20/21] powerpc/ps3: remove inline marking of EXPORT_SYMBOL functions
From: Geoff Levand @ 2013-05-09 11:35 UTC (permalink / raw)
To: Denis Efremov; +Cc: ldv-project, trivial, linuxppc-dev, linux-kernel
In-Reply-To: <1368095819-11011-9-git-send-email-yefremov.denis@gmail.com>
On Thu, 2013-05-09 at 14:36 +0400, Denis Efremov wrote:
> 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(-)
Looks good, thanks.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: tiejun.chen @ 2013-05-09 11:40 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: <300B73AA675FCE4A93EB4FC1D42459FF3F7FBE@039-SN2MPN1-012.039d.mgd.msft.net>
On 05/09/2013 07:34 PM, Caraman Mihai Claudiu-B02008 wrote:
>>>> VF stands for virtualization fault see MAS8[VF] and we may use it for
>> virtualized
>>
>> Looks KVM PPC have no this mechanism currently since I don't find MAS8_VF
>> is
>> used in kernel, right?
>
> Yes but 'we may use it' in the feature, I have a functional POC with VF.
Any IO performance to be improved with this POC?
> Now we capture virtualized MMIO accesses as TLB misses (we don't write
> into HW TLB guest translation outside visible memslots).
Yes.
Tiejun
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Benjamin Herrenschmidt @ 2013-05-09 12:26 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, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130509082112.GE2263@pek-khao-d1.corp.ad.wrs.com>
On Thu, 2013-05-09 at 16:21 +0800, Kevin Hao wrote:
> > 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.
This is one of the primary reason why we implemented lazy disabling in
the first place and why I recently reworked it to decrease the periods
where we are hard disabled.
The other reasons are that storing bytes to the PACA is faster than
manipulating EE on many processors.
Cheers,
Ben.
^ permalink raw reply
* RE: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: Caraman Mihai Claudiu-B02008 @ 2013-05-09 12:36 UTC (permalink / raw)
To: tiejun.chen
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <518B8B2A.1020103@windriver.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0aWVqdW4uY2hlbiBbbWFpbHRv
OnRpZWp1bi5jaGVuQHdpbmRyaXZlci5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMDksIDIw
MTMgMjo0MCBQTQ0KPiBUbzogQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwOA0KPiBDYzogV29v
ZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBhZ3JhZkBzdXNl
LmRlOyBrdm0tDQo+IHBwY0B2Z2VyLmtlcm5lbC5vcmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4g
U3ViamVjdDogUmU6IFt2MV1bS1ZNXVtQQVRDSCAxLzFdIGt2bTpwcGM6Ym9vZWh2OiBkaXJlY3Qg
SVNJIGV4Y2VwdGlvbiB0bw0KPiBHdWVzdA0KPiANCj4gT24gMDUvMDkvMjAxMyAwNzozNCBQTSwg
Q2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwOCB3cm90ZToNCj4gPj4+PiBWRiBzdGFuZHMgZm9y
IHZpcnR1YWxpemF0aW9uIGZhdWx0IHNlZSBNQVM4W1ZGXSBhbmQgd2UgbWF5IHVzZSBpdA0KPiBm
b3INCj4gPj4gdmlydHVhbGl6ZWQNCj4gPj4NCj4gPj4gTG9va3MgS1ZNIFBQQyBoYXZlIG5vIHRo
aXMgbWVjaGFuaXNtIGN1cnJlbnRseSBzaW5jZSBJIGRvbid0IGZpbmQNCj4gTUFTOF9WRg0KPiA+
PiBpcw0KPiA+PiB1c2VkIGluIGtlcm5lbCwgcmlnaHQ/DQo+ID4NCj4gPiBZZXMgYnV0ICd3ZSBt
YXkgdXNlIGl0JyBpbiB0aGUgZmVhdHVyZSwgSSBoYXZlIGEgZnVuY3Rpb25hbCBQT0Mgd2l0aA0K
PiBWRi4NCj4gDQo+IEFueSBJTyBwZXJmb3JtYW5jZSB0byBiZSBpbXByb3ZlZCB3aXRoIHRoaXMg
UE9DPw0KDQpWRiBhcHByb2FjaCBwdXRzIG1vcmUgc3RyZXNzIG9uIEhXIFRMQiBzbyBJIGRpZCBu
b3QgYWR2YW5jZSB3aXRoIHBlcmZvcm1hbmNlDQptZWFzdXJlbWVudHMgdGhvdWdoIGl0IG1heSB3
b3J0aCB0byBkbyBpdC4NCg0KLU1pa2UNCg==
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Benjamin Herrenschmidt @ 2013-05-09 12:37 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,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <518B7014.1090508@windriver.com>
On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
>
> Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I
> recall.
Only if directed to the hypervisor.
> > 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?
The external interrupt line is level sensitive normally, so we have to
mask MSR:EE in that case or the interrupt would keep re-occurring (note
that FSL has this concept of auto-acked interrupts via the on die MPIC
for which you can potentially use PACA_IRQ_EE_EDGE instead and avoid
having to mask MSR:EE).
> I don't understand "the interrupt condition on device is cleared"
> here.
Well, the external interrupt line will remain asserted until the device
(via the PIC) stops interrupting the processor :-) Either because we
mask at the PIC level (or raise the priority) or because the condition
goes away.
> I think regardless if you clear the device interrupt status, the
> system still receive a pending interrupt once EE or GS = 1.
Why ? Depends on your PIC actually but if it's a sane one, it won't
"remember" a level interrupt that is gone. An edge interrupt is a
different matter and is latched.
Some MPIC implementations tend to generate a spurrious IRQ in the case
of level IRQs going away. IE. they still remember an event occurred and
interrupt the processor, but on IACK return the spurious vector. However
that isn't guaranteed to be the case and it is perfectly ok (and a good
idea) for the PIC to just stop asserting the external interrupt line if
the original device interrupt goes away (and it's configured as level
sensitive).
You might notice that we try to re-hard-enable (while still soft
disabled) as soon as we have gone get_irq in do_IRQ. This is because
fetching the interrupt normally also masks it (either by masking at the
source or by raisin the processor interrupt priority depending on the
specific PIC) so we know we can re-hard enable.
> > -> local_irq_enable() - This checks that irq_happened is set, and
> replays
>
> ret_from_except also check to replay.
ret_from_except checks because it essentially can act as an implicit
local_irq_enable.
> > 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.
Right. We move the decrementer to its maximum value however since on
most implementations, it will continue interrupting the processor while
it's top bit is set (and effectively act as a level sensitive
interrupt).
Again, the goal here is to run as much as possible with interrupts hard
enabled which allow better perf sampling.
> > -> 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?
It replays one interrupt, but interrupt are still disabled during the
replay. Upon return from the replayed interrupt, the ret_from_except
will see the other one and replay it too.
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: David Laight @ 2013-05-09 13:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, kvm, Wood Scott-B07421, agraf,
kvm-ppc, Bhushan Bharat-R65777, linuxppc-dev
In-Reply-To: <1368103062.25488.193.camel@pasglop>
> Some MPIC implementations tend to generate a spurrious IRQ in the case
> of level IRQs going away. IE. they still remember an event occurred =
and
> interrupt the processor, but on IACK return the spurious vector. =
However
> that isn't guaranteed to be the case and it is perfectly ok (and a =
good
> idea) for the PIC to just stop asserting the external interrupt line =
if
> the original device interrupt goes away (and it's configured as level
> sensitive).
That will happen if the IRQ goes away while the cpu is performing
the IACK sequence.
If the IRQ goes away while the cpu has interrupts masked then
the cpu won't start the interrupt sequence and then try to
read a vector when no interrupt is pending.
David
^ permalink raw reply
* RE: [PATCH] powerpc/pci: Support per-aperture memory offset
From: Sethi Varun-B16395 @ 2013-05-09 13:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Cc: Thomas Petazzoni, Wood Scott-B07421, linux-pci@vger.kernel.org,
Bjorn Helgaas, Andrew Murray
In-Reply-To: <1367823016.15842.22.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogTW9uZGF5
LCBNYXkgMDYsIDIwMTMgMTI6MjAgUE0NCj4gVG86IGxpbnV4cHBjLWRldg0KPiBDYzogS3VtYXIg
R2FsYTsgV29vZCBTY290dC1CMDc0MjE7IFNldGhpIFZhcnVuLUIxNjM5NTsgVGhvbWFzIFBldGF6
em9uaTsNCj4gQW5kcmV3IE11cnJheTsgQmpvcm4gSGVsZ2FhczsgbGludXgtcGNpQHZnZXIua2Vy
bmVsLm9yZw0KPiBTdWJqZWN0OiBbUEFUQ0hdIHBvd2VycGMvcGNpOiBTdXBwb3J0IHBlci1hcGVy
dHVyZSBtZW1vcnkgb2Zmc2V0DQo+IA0KPiBUaGUgUENJIGNvcmUgc3VwcG9ydHMgYW4gb2Zmc2V0
IHBlciBhcGVydHVyZSBub3dhZGF5cyBidXQgb3VyIGFyY2ggY29kZQ0KPiBzdGlsbCBoYXMgYSBz
aW5nbGUgb2Zmc2V0IHBlciBob3N0IGJyaWRnZSByZXByZXNlbnRpbmcgdGhlIGRpZmZlcmVuY2UN
Cj4gYmV0d2VuIENQVSBtZW1vcnkgYWRkcmVzc2VzIGFuZCBQQ0kgTU1JTyBhZGRyZXNzZXMuDQo+
IA0KPiBUaGlzIGlzIGEgcHJvYmxlbSBhcyBuZXcgbWFjaGluZXMgYW5kIGh5cGVydmlzb3IgdmVy
c2lvbnMgYXJlIGNvbWluZyBvdXQNCj4gd2hlcmUgdGhlIDY0LWJpdCB3aW5kb3dzIHdpbGwgaGF2
ZSBhIGRpZmZlcmVudCBvZmZzZXQgKGJhc2ljYWxseSBtYXBwZWQNCj4gMToxKSBmcm9tIHRoZSAz
Mi1iaXQgd2luZG93cy4NCj4gDQo+IFRoaXMgZml4ZXMgaXQgYnkgdXNpbmcgc2VwYXJhdGUgb2Zm
c2V0cy4gSW4gdGhlIGxvbmcgcnVuLCB3ZSBwcm9iYWJseQ0KPiB3YW50IHRvIGdldCByaWQgb2Yg
dGhhdCBpbnRlcm1lZGlhcnkgc3RydWN0IHBjaV9jb250cm9sbGVyIGFuZCBoYXZlIHRob3NlDQo+
IGRpcmVjdGx5IHN0b3JlZCBpbnRvIHRoZSBwY2lfaG9zdF9icmlkZ2UgYXMgdGhleSBhcmUgcGFy
c2VkIGJ1dCB0aGlzIHdpbGwNCj4gYmUgYSBtb3JlIGludmFzaXZlIGNoYW5nZS4NCj4gDQo+IFNp
Z25lZC1vZmYtYnk6IEJlbmphbWluIEhlcnJlbnNjaG1pZHQgPGJlbmhAa2VybmVsLmNyYXNoaW5n
Lm9yZz4NCj4gLS0tDQo+IA0KPiBOb3csIHRoaXMgaXMgYSBiaWcgb25lIGJ1dCBJJ2QgbGlrZSB0
byBzdGlsbCBtZXJnZSBpdCBmb3IgMy4xMCBiZWNhdXNlDQo+IHdlJ3JlIGhhdmluZyBuZXcgbWFj
aGluZSBjb21pbmcgdXAgKGFuZCBuZXcgdmVyc2lvbnMgb2YgcEh5cCBvbiBleGlzdGluZw0KPiBt
YWNoaW5lcykgdGhhdCBhcmUgZ29pbmcgdG8gZXhwb3NlIE1NSU8gd2luZG93cyB3aXRoIGRpZmZl
cmVudCBvZmZzZXRzDQo+IChiYXNpY2FsbHkgb3VyIDY0LWJpdCB3aW5kb3dzIGFyZSAxOjEgYW5k
IG91ciAzMi1iaXQgd2luZG93cyByZW1hcHBlZCkuDQo+IA0KPiBJJ20gbm90IGV4cGVjdGluZyBh
bnkgbWFqb3IgaXNzdWUgd2l0aCB0aGUgcGF0Y2gsIEkndmUgdGVzdGVkIGl0IG9uIHNvbWUNCj4g
b2Ygb3VyIG1hY2hpbmVzIGhlcmUgYW5kIHdpbGwgdGVzdCBpdCBtb3JlIGR1cmluZyB0aGUgbmV4
dCBjb3VwbGUgb2YgZGF5cw0KPiB0aGUgbm90YWJsZSB0aGluZyBpcyB0aGUgcmVtb3ZhbCBvZiBh
ICJ3b3JrYXJvdW5kIiAvIGZhbGxiYWNrIG9uIDMyLWJpdA0KPiB0aGF0IEkgc3VzcGVjdCBvbmx5
IGV2ZXIgbWF0dGVyZWQgZm9yIG1hY2hpbmVzIGxvbmcgdW5zdXBwb3J0ZWQgKFBSZVAgPykNCj4g
YXMgSSBkb24ndCB0aGluayB3ZSBoYXZlIGFueXRoaW5nIHRoYXQgZG9lc24ndCBwb3B1bGF0ZSB0
aGUgYnJpZGdlDQo+IHJlc291cmNlcyBhbmQgZXhwZWN0cyB0byB3b3JrIG5vd2FkYXlzIChvdGhl
ciBzdHVmZiB3b3VsZCBicmVhayBhbnl3YXkpLg0KPiANCj4gVGhpcyBpcyBhbHNvIHdoeSBJJ20g
TkFLJ2luZyB0aGUgcGF0Y2ggbWFraW5nDQo+IHBjaV9wcm9jZXNzX2JyaWRnZV9PRl9yYW5nZXMo
KSBnZW5lcmljIHNpbmNlIEkgbmVlZCB0byBjaGFuZ2UgaXQgZm9yDQo+IHBvd2VycGMgYW5kIHRo
aXMgaXNuJ3QgdGhlIHJpZ2h0IGxvbmcgdGVybSBhcHByb2FjaCAod2Ugc2hvdWxkICJtZXJnZSIN
Cj4gcGNpX2NvbnRyb2xsZXIgJiBwY2lfaG9zdF9icmlkZ2UgaW5zdGVhZCBhbmQgZGlyZWN0bHkg
cG9wdWxhdGUgdGhlDQo+IHBjaV9ob3N0X2JyaWRnZSBhcGVydHVyZXMpLg0KPiANCj4gSWYgSSBz
ZWUgbm8gbWFqb3IgaXNzdWUgd2l0aCB0aGUgcGF0Y2ggZHVyaW5nIHRoZSBuZXh0IGZldyBkYXlz
LCBJJ2xsDQo+IHNlbmQgaXQgdG8gTGludXMgd2l0aCBteSBuZXh0IHB1bGwgcmVxdWVzdCwgcHJv
YmFibHkgYXQgLXJjMS4NCj4gDQo+IEt1bWFyLCBTY290dCwgU2V0aGksIHBsZWFzZSB0ZXN0IG9u
IEZTTCBIVy4gSSdsbCB0YWtlIGNhcmUgb2YgbWFjcyBhbmQNCj4gNHh4IGluIGFkZGl0aW9uIHRv
IHRoZSB2YXJpb3VzIElCTSBwcGM2NCBwbGF0Zm9ybXMuDQo+IA0KW1NldGhpIFZhcnVuLUIxNjM5
NV0gVGVzdGVkIHBhdGNoIG9uIEZTTCBUNDI0MCwgUDQwODAsIFA1MDQwIGFuZCBQMTAyMCBib2Fy
ZHMuDQoNCi1WYXJ1bg0K
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Chen, Tiejun @ 2013-05-09 14:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368103062.25488.193.camel@pasglop>
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]=20
> Sent: Thursday, May 09, 2013 8:38 PM
> To: Chen, Tiejun
> Cc: Bhushan Bharat-R65777; Caraman Mihai Claudiu-B02008; Wood=20
> Scott-B07421; linuxppc-dev@lists.ozlabs.org; agraf@suse.de;=20
> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64:=20
> soft-disable interrupts
>=20
> On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
> >=20
> > Actually in the case GS=3D1 even if EE=3D0, EXT/DEC/DBELL still=20
> occur as I=20
> > recall.
>=20
> Only if directed to the hypervisor.
Yes, this is our current booehv design with EPCR[EXTGS] =3D 0.
>=20
> > > Case 1)
> > > -> Local_irq_disable() will set soft_enabled =3D 0
> > > -> Now Externel interrupt happens, there we set PACA_IRQ_EE in
> > irq_happened, Also clears EE in SRR1 and rfi. So interrupts=20
> are hard=20
> > disabled. No more other interrupt gated by MSR.EE can happen. Looks=20
> > like the idea here is to not let a device keep on inserting=20
> interrupt=20
> > till the interrupt condition on device is cleared, right?
>=20
> The external interrupt line is level sensitive normally, so=20
> we have to mask MSR:EE in that case or the interrupt would=20
> keep re-occurring (note that FSL has this concept of=20
> auto-acked interrupts via the on die MPIC for which you can=20
> potentially use PACA_IRQ_EE_EDGE instead and avoid having to=20
> mask MSR:EE).
>=20
> > I don't understand "the interrupt condition on device is cleared"
> > here.
>=20
> Well, the external interrupt line will remain asserted until=20
> the device (via the PIC) stops interrupting the processor :-)=20
Yes, the device keeps on interrupting the interrupt until the device clear =
its interrupted condition.
> Either because we mask at the PIC level (or raise the=20
> priority) or because the condition goes away.
> =20
> > I think regardless if you clear the device interrupt status, the=20
> > system still receive a pending interrupt once EE or GS =3D 1.
>=20
> Why ? Depends on your PIC actually but if it's a sane one, it=20
> won't "remember" a level interrupt that is gone. An edge=20
> interrupt is a different matter and is latched.
But the interrupt controller like MPIC should leave this irq as pending if =
we don't ACK/EOI this irq at all if we just clear the device, right?
>=20
> Some MPIC implementations tend to generate a spurrious IRQ in=20
> the case of level IRQs going away. IE. they still remember an=20
> event occurred and interrupt the processor, but on IACK=20
> return the spurious vector. However that isn't guaranteed to=20
Yes, this is just what I mean. No matter if this vector is still valid, the=
external interrupt exception always occur once EE =3D 1 again.
> be the case and it is perfectly ok (and a good
> idea) for the PIC to just stop asserting the external=20
> interrupt line if the original device interrupt goes away=20
> (and it's configured as level sensitive).
I don't remember MPIC can work with this way. So I'd like to look the manua=
l again :)
Tiejun=
^ permalink raw reply
* [PATCH] rapidio/switches: remove tsi500 driver
From: Alexandre Bounine @ 2013-05-09 14:20 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Remove the driver for Tsi500 Parallel RapidIO switch because this device is
not available for several years. Since the first introduction of Tsi500,
the parallel RapidIO interface was replaced by the serial RapidIO (sRIO)
and therefore there is no value in keeping this driver.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
---
drivers/rapidio/switches/Kconfig | 7 ---
drivers/rapidio/switches/Makefile | 1 -
drivers/rapidio/switches/tsi500.c | 78 -------------------------------------
3 files changed, 0 insertions(+), 86 deletions(-)
delete mode 100644 drivers/rapidio/switches/tsi500.c
diff --git a/drivers/rapidio/switches/Kconfig b/drivers/rapidio/switches/Kconfig
index f47fee5..62d4a06 100644
--- a/drivers/rapidio/switches/Kconfig
+++ b/drivers/rapidio/switches/Kconfig
@@ -26,10 +26,3 @@ config RAPIDIO_CPS_GEN2
default n
---help---
Includes support for ITD CPS Gen.2 serial RapidIO switches.
-
-config RAPIDIO_TSI500
- bool "Tsi500 Parallel RapidIO switch support"
- depends on RAPIDIO
- default n
- ---help---
- Includes support for IDT Tsi500 parallel RapidIO switch.
diff --git a/drivers/rapidio/switches/Makefile b/drivers/rapidio/switches/Makefile
index c4d3acc..051cc6b 100644
--- a/drivers/rapidio/switches/Makefile
+++ b/drivers/rapidio/switches/Makefile
@@ -5,5 +5,4 @@
obj-$(CONFIG_RAPIDIO_TSI57X) += tsi57x.o
obj-$(CONFIG_RAPIDIO_CPS_XX) += idtcps.o
obj-$(CONFIG_RAPIDIO_TSI568) += tsi568.o
-obj-$(CONFIG_RAPIDIO_TSI500) += tsi500.o
obj-$(CONFIG_RAPIDIO_CPS_GEN2) += idt_gen2.o
diff --git a/drivers/rapidio/switches/tsi500.c b/drivers/rapidio/switches/tsi500.c
deleted file mode 100644
index 914eddd..0000000
--- a/drivers/rapidio/switches/tsi500.c
+++ /dev/null
@@ -1,78 +0,0 @@
-/*
- * RapidIO Tsi500 switch support
- *
- * Copyright 2009-2010 Integrated Device Technology, Inc.
- * Alexandre Bounine <alexandre.bounine@idt.com>
- * - Modified switch operations initialization.
- *
- * Copyright 2005 MontaVista Software, Inc.
- * Matt Porter <mporter@kernel.crashing.org>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/rio.h>
-#include <linux/rio_drv.h>
-#include <linux/rio_ids.h>
-#include "../rio.h"
-
-static int
-tsi500_route_add_entry(struct rio_mport *mport, u16 destid, u8 hopcount, u16 table, u16 route_destid, u8 route_port)
-{
- int i;
- u32 offset = 0x10000 + 0xa00 + ((route_destid / 2)&~0x3);
- u32 result;
-
- if (table == 0xff) {
- rio_mport_read_config_32(mport, destid, hopcount, offset, &result);
- result &= ~(0xf << (4*(route_destid & 0x7)));
- for (i=0;i<4;i++)
- rio_mport_write_config_32(mport, destid, hopcount, offset + (0x20000*i), result | (route_port << (4*(route_destid & 0x7))));
- }
- else {
- rio_mport_read_config_32(mport, destid, hopcount, offset + (0x20000*table), &result);
- result &= ~(0xf << (4*(route_destid & 0x7)));
- rio_mport_write_config_32(mport, destid, hopcount, offset + (0x20000*table), result | (route_port << (4*(route_destid & 0x7))));
- }
-
- return 0;
-}
-
-static int
-tsi500_route_get_entry(struct rio_mport *mport, u16 destid, u8 hopcount, u16 table, u16 route_destid, u8 *route_port)
-{
- int ret = 0;
- u32 offset = 0x10000 + 0xa00 + ((route_destid / 2)&~0x3);
- u32 result;
-
- if (table == 0xff)
- rio_mport_read_config_32(mport, destid, hopcount, offset, &result);
- else
- rio_mport_read_config_32(mport, destid, hopcount, offset + (0x20000*table), &result);
-
- result &= 0xf << (4*(route_destid & 0x7));
- *route_port = result >> (4*(route_destid & 0x7));
- if (*route_port > 3)
- ret = -1;
-
- return ret;
-}
-
-static int tsi500_switch_init(struct rio_dev *rdev, int do_enum)
-{
- pr_debug("RIO: %s for %s\n", __func__, rio_name(rdev));
- rdev->rswitch->add_entry = tsi500_route_add_entry;
- rdev->rswitch->get_entry = tsi500_route_get_entry;
- rdev->rswitch->clr_table = NULL;
- rdev->rswitch->set_domain = NULL;
- rdev->rswitch->get_domain = NULL;
- rdev->rswitch->em_init = NULL;
- rdev->rswitch->em_handle = NULL;
-
- return 0;
-}
-
-DECLARE_RIO_SWITCH_INIT(RIO_VID_TUNDRA, RIO_DID_TSI500, tsi500_switch_init);
--
1.7.8.4
^ permalink raw reply related
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Scott Wood @ 2013-05-09 21:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368103062.25488.193.camel@pasglop>
On 05/09/2013 07:37:42 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
> >
> > Actually in the case GS=3D1 even if EE=3D0, EXT/DEC/DBELL still occur =20
> as I
> > recall.
>=20
> Only if directed to the hypervisor.
This is always the case with KVM, right? At least on booke...
> > > Case 1)
> > > -> Local_irq_disable() will set soft_enabled =3D 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 =20
> interrupt
> > till the interrupt condition on device is cleared, right?
>=20
> The external interrupt line is level sensitive normally, so we have to
> mask MSR:EE in that case or the interrupt would keep re-occurring =20
> (note
> that FSL has this concept of auto-acked interrupts via the on die MPIC
> for which you can potentially use PACA_IRQ_EE_EDGE instead and avoid
> having to mask MSR:EE).
Note that if we do this, we can no longer leave the interrupt vector in =20
EPR, and would have to track (potentially multiple different) pending =20
external interrupts in software.
-Scott=
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Benjamin Herrenschmidt @ 2013-05-09 22:01 UTC (permalink / raw)
To: David Laight
Cc: Wood Scott-B07421, kvm, Caraman Mihai Claudiu-B02008, agraf,
kvm-ppc, tiejun.chen, Bhushan Bharat-R65777, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B722F@saturn3.aculab.com>
On Thu, 2013-05-09 at 14:28 +0100, David Laight wrote:
> That will happen if the IRQ goes away while the cpu is performing
> the IACK sequence.
> If the IRQ goes away while the cpu has interrupts masked then
> the cpu won't start the interrupt sequence and then try to
> read a vector when no interrupt is pending.
Right, and get a spurrious vector which shouldn't be a big deal.
We tend to call that a "short interrupt". There have been many other
cases of short interrupts in the past, for example on some MPICs, when
distribution is enabled, they occasionally shoot an interrupt to more
than one CPU at once :-)
Cheers,
Ben.
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 13/05/2013)
From: Michael Barry @ 2013-05-09 22:02 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 13/05/2013.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 105, Issue 55" sent on 09/05/2013 23:01:55.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Benjamin Herrenschmidt @ 2013-05-09 22:07 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368134856.654.11@snotra>
On Thu, 2013-05-09 at 16:27 -0500, Scott Wood wrote:
> On 05/09/2013 07:37:42 AM, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
> > >
> > > Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur
> > as I
> > > recall.
> >
> > Only if directed to the hypervisor.
>
> This is always the case with KVM, right? At least on booke...
Hrm, on A2 we could choose iirc. Well not DEC but EXT at least, I don't
remember about DBELL.
> > > > 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?
> >
> > The external interrupt line is level sensitive normally, so we have to
> > mask MSR:EE in that case or the interrupt would keep re-occurring
> > (note
> > that FSL has this concept of auto-acked interrupts via the on die MPIC
> > for which you can potentially use PACA_IRQ_EE_EDGE instead and avoid
> > having to mask MSR:EE).
>
> Note that if we do this, we can no longer leave the interrupt vector in
> EPR, and would have to track (potentially multiple different) pending
> external interrupts in software.
Right, you can have a little queue in the PACA and leave EE disabled if
it's full. You can probably get away with a queue of 1 though :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/pci: Support per-aperture memory offset
From: Benjamin Herrenschmidt @ 2013-05-09 22:07 UTC (permalink / raw)
To: Sethi Varun-B16395
Cc: Thomas Petazzoni, Wood Scott-B07421, linux-pci@vger.kernel.org,
Bjorn Helgaas, Andrew Murray, linuxppc-dev
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D4F01D0@039-SN2MPN1-013.039d.mgd.msft.net>
On Thu, 2013-05-09 at 13:47 +0000, Sethi Varun-B16395 wrote:
> [Sethi Varun-B16395] Tested patch on FSL T4240, P4080, P5040 and P1020
> boards.
Thanks.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Scott Wood @ 2013-05-09 22:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368137220.3715.14.camel@pasglop>
On 05/09/2013 05:07:00 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-09 at 16:27 -0500, Scott Wood wrote:
> > On 05/09/2013 07:37:42 AM, Benjamin Herrenschmidt wrote:
> > > On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
> > > >
> > > > Actually in the case GS=3D1 even if EE=3D0, EXT/DEC/DBELL still =20
> occur
> > > as I
> > > > recall.
> > >
> > > Only if directed to the hypervisor.
> >
> > This is always the case with KVM, right? At least on booke...
>=20
> Hrm, on A2 we could choose iirc. Well not DEC but EXT at least, I =20
> don't
> remember about DBELL.
As for as the hardware goes we can choose on e500mc as well -- we just =20
don't support it in KVM, because we can't distinguish between guest and =20
host interrupts without routing the latter to critical, which is way =20
too much of a pain for Linux (we did it in our standalone hypervisor, =20
though).
-Scott=
^ permalink raw reply
* [PATCH v2 2/4] kvm/ppc/booke64: Fix lazy ee handling in kvmppc_handle_exit()
From: Scott Wood @ 2013-05-10 3:09 UTC (permalink / raw)
To: Alexander Graf, Benjamin Herrenschmidt
Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1368155384-11035-1-git-send-email-scottwood@freescale.com>
EE is hard-disabled on entry to kvmppc_handle_exit(), so call
hard_irq_disable() so that PACA_IRQ_HARD_DIS is set, and soft_enabled
is unset.
Without this, we get warnings such as arch/powerpc/kernel/time.c:300,
and sometimes host kernel hangs.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kvm/booke.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1020119..705fc5c 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -833,6 +833,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
int r = RESUME_HOST;
int s;
+#ifdef CONFIG_PPC64
+ WARN_ON(local_paca->irq_happened != 0);
+#endif
+ hard_irq_disable();
+
/* update before a new last_exit_type is rewritten */
kvmppc_update_timing_stats(vcpu);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 4/4] kvm/ppc: IRQ disabling cleanup
From: Scott Wood @ 2013-05-10 3:09 UTC (permalink / raw)
To: Alexander Graf, Benjamin Herrenschmidt
Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1368155384-11035-1-git-send-email-scottwood@freescale.com>
Simplify the handling of lazy EE by going directly from fully-enabled
to hard-disabled. This replaces the lazy_irq_pending() check
(including its misplaced kvm_guest_exit() call).
As suggested by Tiejun Chen, move the interrupt disabling into
kvmppc_prepare_to_enter() rather than have each caller do it. Also
move the IRQ enabling on heavyweight exit into
kvmppc_prepare_to_enter().
Don't move kvmppc_fix_ee_before_entry() into kvmppc_prepare_to_enter(),
so that the caller can avoid marking interrupts enabled earlier than
necessary (e.g. book3s_pr waits until after FP save/restore is done).
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/include/asm/kvm_ppc.h | 6 ++++++
arch/powerpc/kvm/book3s_pr.c | 12 +++---------
arch/powerpc/kvm/booke.c | 9 ++-------
arch/powerpc/kvm/powerpc.c | 21 ++++++++-------------
4 files changed, 19 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index 6885846..e4474f8 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -404,6 +404,12 @@ static inline void kvmppc_fix_ee_before_entry(void)
trace_hardirqs_on();
#ifdef CONFIG_PPC64
+ /*
+ * To avoid races, the caller must have gone directly from having
+ * interrupts fully-enabled to hard-disabled.
+ */
+ WARN_ON(local_paca->irq_happened != PACA_IRQ_HARD_DIS);
+
/* Only need to enable IRQs by hard enabling them after this */
local_paca->irq_happened = 0;
local_paca->soft_enabled = 1;
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 0b97ce4..e61e39e 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -884,14 +884,11 @@ program_interrupt:
* and if we really did time things so badly, then we just exit
* again due to a host external interrupt.
*/
- local_irq_disable();
s = kvmppc_prepare_to_enter(vcpu);
- if (s <= 0) {
- local_irq_enable();
+ if (s <= 0)
r = s;
- } else {
+ else
kvmppc_fix_ee_before_entry();
- }
}
trace_kvm_book3s_reenter(r, vcpu);
@@ -1121,12 +1118,9 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
* really did time things so badly, then we just exit again due to
* a host external interrupt.
*/
- local_irq_disable();
ret = kvmppc_prepare_to_enter(vcpu);
- if (ret <= 0) {
- local_irq_enable();
+ if (ret <= 0)
goto out;
- }
/* Save FPU state in stack */
if (current->thread.regs->msr & MSR_FP)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index eb89b83..f7c0111 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -666,10 +666,8 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
return -EINVAL;
}
- local_irq_disable();
s = kvmppc_prepare_to_enter(vcpu);
if (s <= 0) {
- local_irq_enable();
ret = s;
goto out;
}
@@ -1148,14 +1146,11 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
* aren't already exiting to userspace for some other reason.
*/
if (!(r & RESUME_HOST)) {
- local_irq_disable();
s = kvmppc_prepare_to_enter(vcpu);
- if (s <= 0) {
- local_irq_enable();
+ if (s <= 0)
r = (s << 2) | RESUME_HOST | (r & RESUME_FLAG_NV);
- } else {
+ else
kvmppc_fix_ee_before_entry();
- }
}
return r;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 4e05f8c..f8659aa 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -64,12 +64,14 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
{
int r = 1;
- WARN_ON_ONCE(!irqs_disabled());
+ WARN_ON(irqs_disabled());
+ hard_irq_disable();
+
while (true) {
if (need_resched()) {
local_irq_enable();
cond_resched();
- local_irq_disable();
+ hard_irq_disable();
continue;
}
@@ -95,7 +97,7 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
local_irq_enable();
trace_kvm_check_requests(vcpu);
r = kvmppc_core_check_requests(vcpu);
- local_irq_disable();
+ hard_irq_disable();
if (r > 0)
continue;
break;
@@ -108,21 +110,14 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
}
#ifdef CONFIG_PPC64
- /* lazy EE magic */
- hard_irq_disable();
- if (lazy_irq_pending()) {
- /* Got an interrupt in between, try again */
- local_irq_enable();
- local_irq_disable();
- kvm_guest_exit();
- continue;
- }
+ WARN_ON(lazy_irq_pending());
#endif
kvm_guest_enter();
- break;
+ return r;
}
+ local_irq_enable();
return r;
}
#endif /* CONFIG_KVM_BOOK3S_64_HV */
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 0/4] kvm/ppc: interrupt disabling fixes
From: Scott Wood @ 2013-05-10 3:09 UTC (permalink / raw)
To: Alexander Graf, Benjamin Herrenschmidt; +Cc: linuxppc-dev, kvm, kvm-ppc
v2:
- Split into separate changes
- Rebase on top of (and fix a bug in) powerpc: Make hard_irq_disable()
do the right thing vs. irq tracing
- Move interrupt diasbling/enabling into kvmppc_handle_exit
Based on Ben's next branch.
Scott Wood (4):
powerpc: hard_irq_disable(): Call trace_hardirqs_off after disabling
kvm/ppc/booke64: Fix lazy ee handling in kvmppc_handle_exit()
kvm/ppc: Call trace_hardirqs_on before entry
kvm/ppc: IRQ disabling cleanup
arch/powerpc/include/asm/hw_irq.h | 5 +++--
arch/powerpc/include/asm/kvm_ppc.h | 17 ++++++++++++++---
arch/powerpc/kvm/book3s_pr.c | 16 +++++-----------
arch/powerpc/kvm/booke.c | 18 +++++++++---------
arch/powerpc/kvm/powerpc.c | 23 ++++++++---------------
5 files changed, 39 insertions(+), 40 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH v2 1/4] powerpc: hard_irq_disable(): Call trace_hardirqs_off after disabling
From: Scott Wood @ 2013-05-10 3:09 UTC (permalink / raw)
To: Alexander Graf, Benjamin Herrenschmidt
Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1368155384-11035-1-git-send-email-scottwood@freescale.com>
lockdep.c has this:
/*
* So we're supposed to get called after you mask local IRQs,
* but for some reason the hardware doesn't quite think you did
* a proper job.
*/
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
return;
Since irqs_disabled() is based on soft_enabled(), that (not just the
hard EE bit) needs to be 0 before we call trace_hardirqs_off.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/include/asm/hw_irq.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index d615b28..ba713f1 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -96,11 +96,12 @@ static inline bool arch_irqs_disabled(void)
#endif
#define hard_irq_disable() do { \
+ u8 _was_enabled = get_paca()->soft_enabled; \
__hard_irq_disable(); \
- if (local_paca->soft_enabled) \
- trace_hardirqs_off(); \
get_paca()->soft_enabled = 0; \
get_paca()->irq_happened |= PACA_IRQ_HARD_DIS; \
+ if (_was_enabled) \
+ trace_hardirqs_off(); \
} while(0)
static inline bool lazy_irq_pending(void)
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 3/4] kvm/ppc: Call trace_hardirqs_on before entry
From: Scott Wood @ 2013-05-10 3:09 UTC (permalink / raw)
To: Alexander Graf, Benjamin Herrenschmidt
Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1368155384-11035-1-git-send-email-scottwood@freescale.com>
Currently this is only being done on 64-bit. Rather than just move it
out of the 64-bit ifdef, move it to kvm_lazy_ee_enable() so that it is
consistent with lazy ee state, and so that we don't track more host
code as interrupts-enabled than necessary.
Rename kvm_lazy_ee_enable() to kvm_fix_ee_before_entry() to reflect
that this function now has a role on 32-bit as well.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/include/asm/kvm_ppc.h | 11 ++++++++---
arch/powerpc/kvm/book3s_pr.c | 4 ++--
arch/powerpc/kvm/booke.c | 4 ++--
arch/powerpc/kvm/powerpc.c | 2 --
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index a5287fe..6885846 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -394,10 +394,15 @@ static inline void kvmppc_mmu_flush_icache(pfn_t pfn)
}
}
-/* Please call after prepare_to_enter. This function puts the lazy ee state
- back to normal mode, without actually enabling interrupts. */
-static inline void kvmppc_lazy_ee_enable(void)
+/*
+ * Please call after prepare_to_enter. This function puts the lazy ee and irq
+ * disabled tracking state back to normal mode, without actually enabling
+ * interrupts.
+ */
+static inline void kvmppc_fix_ee_before_entry(void)
{
+ trace_hardirqs_on();
+
#ifdef CONFIG_PPC64
/* Only need to enable IRQs by hard enabling them after this */
local_paca->irq_happened = 0;
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index bdc40b8..0b97ce4 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -890,7 +890,7 @@ program_interrupt:
local_irq_enable();
r = s;
} else {
- kvmppc_lazy_ee_enable();
+ kvmppc_fix_ee_before_entry();
}
}
@@ -1161,7 +1161,7 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
if (vcpu->arch.shared->msr & MSR_FP)
kvmppc_handle_ext(vcpu, BOOK3S_INTERRUPT_FP_UNAVAIL, MSR_FP);
- kvmppc_lazy_ee_enable();
+ kvmppc_fix_ee_before_entry();
ret = __kvmppc_vcpu_run(kvm_run, vcpu);
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 705fc5c..eb89b83 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -673,7 +673,7 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
ret = s;
goto out;
}
- kvmppc_lazy_ee_enable();
+ kvmppc_fix_ee_before_entry();
kvm_guest_enter();
@@ -1154,7 +1154,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
local_irq_enable();
r = (s << 2) | RESUME_HOST | (r & RESUME_FLAG_NV);
} else {
- kvmppc_lazy_ee_enable();
+ kvmppc_fix_ee_before_entry();
}
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 6316ee3..4e05f8c 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -117,8 +117,6 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
kvm_guest_exit();
continue;
}
-
- trace_hardirqs_on();
#endif
kvm_guest_enter();
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH v2 3/4] kvm/ppc: Call trace_hardirqs_on before entry
From: Bhushan Bharat-R65777 @ 2013-05-10 3:34 UTC (permalink / raw)
To: Wood Scott-B07421, Alexander Graf, Benjamin Herrenschmidt
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <1368155384-11035-4-git-send-email-scottwood@freescale.com>
> -----Original Message-----
> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Beh=
alf Of
> Scott Wood
> Sent: Friday, May 10, 2013 8:40 AM
> To: Alexander Graf; Benjamin Herrenschmidt
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozla=
bs.org;
> Wood Scott-B07421
> Subject: [PATCH v2 3/4] kvm/ppc: Call trace_hardirqs_on before entry
>=20
> Currently this is only being done on 64-bit. Rather than just move it
> out of the 64-bit ifdef, move it to kvm_lazy_ee_enable() so that it is
> consistent with lazy ee state, and so that we don't track more host
> code as interrupts-enabled than necessary.
>=20
> Rename kvm_lazy_ee_enable() to kvm_fix_ee_before_entry() to reflect
> that this function now has a role on 32-bit as well.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/include/asm/kvm_ppc.h | 11 ++++++++---
> arch/powerpc/kvm/book3s_pr.c | 4 ++--
> arch/powerpc/kvm/booke.c | 4 ++--
> arch/powerpc/kvm/powerpc.c | 2 --
> 4 files changed, 12 insertions(+), 9 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> index a5287fe..6885846 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -394,10 +394,15 @@ static inline void kvmppc_mmu_flush_icache(pfn_t pf=
n)
> }
> }
>=20
> -/* Please call after prepare_to_enter. This function puts the lazy ee st=
ate
> - back to normal mode, without actually enabling interrupts. */
> -static inline void kvmppc_lazy_ee_enable(void)
> +/*
> + * Please call after prepare_to_enter. This function puts the lazy ee an=
d irq
> + * disabled tracking state back to normal mode, without actually enablin=
g
> + * interrupts.
> + */
> +static inline void kvmppc_fix_ee_before_entry(void)
> {
> + trace_hardirqs_on();
> +
> #ifdef CONFIG_PPC64
> /* Only need to enable IRQs by hard enabling them after this */
> local_paca->irq_happened =3D 0;
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index bdc40b8..0b97ce4 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -890,7 +890,7 @@ program_interrupt:
> local_irq_enable();
> r =3D s;
> } else {
> - kvmppc_lazy_ee_enable();
> + kvmppc_fix_ee_before_entry();
> }
> }
>=20
> @@ -1161,7 +1161,7 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
> kvm_vcpu *vcpu)
> if (vcpu->arch.shared->msr & MSR_FP)
> kvmppc_handle_ext(vcpu, BOOK3S_INTERRUPT_FP_UNAVAIL, MSR_FP);
>=20
> - kvmppc_lazy_ee_enable();
> + kvmppc_fix_ee_before_entry();
>=20
> ret =3D __kvmppc_vcpu_run(kvm_run, vcpu);
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 705fc5c..eb89b83 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -673,7 +673,7 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct k=
vm_vcpu
> *vcpu)
> ret =3D s;
> goto out;
> }
> - kvmppc_lazy_ee_enable();
> + kvmppc_fix_ee_before_entry();
local_irq_disable() is called before kvmppc_prepare_to_enter().
Now we put the irq_happend and soft_enabled back to previous state without =
checking for any interrupt happened in between. If any interrupt happens in=
between, will not that be lost?
-Bharat
>=20
> kvm_guest_enter();
>=20
> @@ -1154,7 +1154,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
> kvm_vcpu *vcpu,
> local_irq_enable();
> r =3D (s << 2) | RESUME_HOST | (r & RESUME_FLAG_NV);
> } else {
> - kvmppc_lazy_ee_enable();
> + kvmppc_fix_ee_before_entry();
> }
> }
>=20
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 6316ee3..4e05f8c 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -117,8 +117,6 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
> kvm_guest_exit();
> continue;
> }
> -
> - trace_hardirqs_on();
> #endif
>=20
> kvm_guest_enter();
> --
> 1.7.10.4
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 2/2 V8] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
From: Jia Hongtao-B38951 @ 2013-05-10 4:00 UTC (permalink / raw)
To: galak@kernel.crashing.org
Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472, Jia Hongtao-B38951
In-Reply-To: <1367514224.24411.10@snotra>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, May 03, 2013 1:04 AM
> > To: Jia Hongtao-B38951
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Wood
> > Scott- B07421; segher@kernel.crashing.org; Li Yang-R58472; Jia
> > Hongtao-B38951
> > Subject: Re: [PATCH 2/2 V8] powerpc/85xx: Add machine check handler to
> > fix PCIe erratum on mpc85xx
> >
> > On 04/28/2013 12:20:08 AM, Jia Hongtao wrote:
> > > A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
> > > goes down. when the link goes down, Non-posted transactions issued
> > > via the ATMU requiring completion result in an instruction stall.
> > > At the same time a machine-check exception is generated to the core
> > > to allow further processing by the handler. We implements the
> > > handler which skips the instruction caused the stall.
> > >
> > > This patch depends on patch:
> > > powerpc/85xx: Add platform_device declaration to fsl_pci.h
> > >
> > > Signed-off-by: Zhao Chenhui <b35336@freescale.com>
> > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> > > Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> > > ---
> > > V8:
> > > * Add A variant load instruction emulation.
> >
> > ACK
> >
> > -Scott
>=20
> Thanks for the review.
>=20
> Hi Kumar,
>=20
> Could you please review these MSI and PCI hang errata patches?
> http://patchwork.ozlabs.org/patch/233211/
> http://patchwork.ozlabs.org/patch/235276/
> http://patchwork.ozlabs.org/patch/240238/
> http://patchwork.ozlabs.org/patch/240239/ (This patch)
>=20
> Thanks.
> -Hongtao
Hi Kumar,
I'm really appreciated if you have time to review these patches?
Thanks.
-Hongtao
^ 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