From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex =?utf-8?Q?Benn=C3=A9e?= Subject: Re: [RFC PATCH v2 06/23] arm64/sve: Check SVE virtualisability Date: Fri, 16 Nov 2018 12:32:18 +0000 Message-ID: <87bm6pciel.fsf@linaro.org> References: <1538141967-15375-1-git-send-email-Dave.Martin@arm.com> <1538141967-15375-7-git-send-email-Dave.Martin@arm.com> <87in0ycpuy.fsf@linaro.org> <20181115170904.GO3505@e103592.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 57CE14A2B6 for ; Fri, 16 Nov 2018 07:32:22 -0500 (EST) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKFd2jUOkcxT for ; Fri, 16 Nov 2018 07:32:21 -0500 (EST) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id E7FD74A347 for ; Fri, 16 Nov 2018 07:32:20 -0500 (EST) Received: by mail-wm1-f68.google.com with SMTP id f1-v6so884384wmg.1 for ; Fri, 16 Nov 2018 04:32:20 -0800 (PST) In-reply-to: <20181115170904.GO3505@e103592.cambridge.arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Dave Martin Cc: Okamoto Takayuki , Christoffer Dall , Ard Biesheuvel , Marc Zyngier , Catalin Marinas , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org List-Id: kvmarm@lists.cs.columbia.edu CkRhdmUgTWFydGluIDxEYXZlLk1hcnRpbkBhcm0uY29tPiB3cml0ZXM6Cgo+IE9uIFRodSwgTm92 IDE1LCAyMDE4IGF0IDAzOjM5OjAxUE0gKzAwMDAsIEFsZXggQmVubsOpZSB3cm90ZToKPj4KPj4g RGF2ZSBNYXJ0aW4gPERhdmUuTWFydGluQGFybS5jb20+IHdyaXRlczoKPj4KPj4gPiBEdWUgdG8g dGhlIHdheSB0aGUgZWZmZWN0aXZlIFNWRSB2ZWN0b3IgbGVuZ3RoIGlzIGNvbnRyb2xsZWQgYW5k Cj4+ID4gdHJhcHBlZCBhdCBkaWZmZXJlbnQgZXhjZXB0aW9uIGxldmVscywgY2VydGFpbiBtaXNt YXRjaGVzIGluIHRoZQo+PiA+IHNldHMgb2YgdmVjdG9yIGxlbmd0aHMgc3VwcG9ydGVkIGJ5IGRp ZmZlcmVudCBwaHlzaWNhbCBDUFVzIGluIHRoZQo+PiA+IHN5c3RlbSBtYXkgcHJldmVudCBzdHJh aWdodGZvcndhcmQgdmlydHVhbGlzYXRpb24gb2YgU1ZFIGF0IHBhcml0eQo+PiA+IHdpdGggdGhl IGhvc3QuCj4+ID4KPj4gPiBUaGlzIHBhdGNoIGFuYWx5c2VzIHRoZSBleHRlbnQgdG8gd2hpY2gg U1ZFIGNhbiBiZSB2aXJ0dWFsaXNlZAo+PiA+IHNhZmVseSB3aXRob3V0IGludGVyZmVyaW5nIHdp dGggbWlncmF0aW9uIG9mIHZjcHVzIGJldHdlZW4gcGh5c2ljYWwKPj4gPiBDUFVzLCBhbmQgcmVq ZWN0cyBsYXRlIHNlY29uZGFyeSBDUFVzIHRoYXQgd291bGQgZXJvZGUgdGhlCj4+ID4gc2l0dWF0 aW9uIGZ1cnRoZXIuCj4+ID4KPj4gPiBJdCBpcyBsZWZ0IHVwIHRvIEtWTSB0byBkZWNpZGUgd2hh dCB0byBkbyB3aXRoIHRoaXMgaW5mb3JtYXRpb24uCj4+ID4KPj4gPiBTaWduZWQtb2ZmLWJ5OiBE YXZlIE1hcnRpbiA8RGF2ZS5NYXJ0aW5AYXJtLmNvbT4KPj4gPiAtLS0KPj4gPgo+PiA+IENoYW5n ZXMgc2luY2UgUkZDdjE6Cj4+ID4KPj4gPiAgKiBUaGUgYW5hbHlzaXMgZG9uZSBieSB0aGlzIHBh dGNoIGlzIHRoZSBzYW1lIGFzIGluIHRoZSBwcmV2aW91cwo+PiA+ICAgIHZlcnNpb24sIGJ1dCB0 aGUgY29tbWl0IG1lc3NhZ2UgdGhlIHByaW50a3MgZXRjLiBoYXZlIGJlZW4gcmV3b3JkZWQKPj4g PiAgICB0byBhdm9pZCB0aGUgc3VnZ2VzdGlvbiB0aGF0IEtWTSBpcyBleHBlY3RlZCB0byB3b3Jr IG9uIGEgc3lzdGVtIHdpdGgKPj4gPiAgICBtaXNtYXRjaGVkIFNWRSBpbXBsZW1lbnRhdGlvbnMu Cj4+ID4gLS0tCj4+ID4gIGFyY2gvYXJtNjQvaW5jbHVkZS9hc20vZnBzaW1kLmggfCAgMSArCj4+ ID4gIGFyY2gvYXJtNjQva2VybmVsL2NwdWZlYXR1cmUuYyAgfCAgMiArLQo+PiA+ICBhcmNoL2Fy bTY0L2tlcm5lbC9mcHNpbWQuYyAgICAgIHwgODcgKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKystLS0tLS0KPj4gPiAgMyBmaWxlcyBjaGFuZ2VkLCA3NiBpbnNlcnRpb25zKCspLCAx NCBkZWxldGlvbnMoLSkKPj4gPgo+Cj4gWy4uLl0KPgo+PiA+IGRpZmYgLS1naXQgYS9hcmNoL2Fy bTY0L2tlcm5lbC9mcHNpbWQuYyBiL2FyY2gvYXJtNjQva2VybmVsL2Zwc2ltZC5jCj4KPiBbLi4u XQo+Cj4+ID4gQEAgLTYyMywxMSArNjI5LDggQEAgaW50IHN2ZV9nZXRfY3VycmVudF92bCh2b2lk KQo+Cj4gWy4uLl0KPgo+PiA+ICsvKiBCaXRtYXBzIGZvciB0ZW1wb3Jhcnkgc3RvcmFnZSBkdXJp bmcgbWFuaXB1bGF0aW9uIG9mIHZlY3RvciBsZW5ndGggc2V0cyAqLwo+PiA+ICtzdGF0aWMgREVD TEFSRV9CSVRNQVAoc3ZlX3RtcF92cV9tYXAsIFNWRV9WUV9NQVgpOwo+Pgo+PiBUaGlzIHNlZW1z IG9kZCBhcyBhIGxvY2FsIGdsb2JhbCwgd2h5IG5vdCBkZWNsYXJlZCBsb2NhbGx5IHdoZW4gdXNl ZD8KPgo+IENvdWxkIGRvLgo+Cj4gTXkgb3JpZ2luYWwgY29uY2VybiB3YXMgdGhhdCB0aGlzIGlz ICJiaWciIGFuZCB0aGVyZWZvcmUgaXQncyBpbXBvbGl0ZQo+IHRvIGFsbG9jYXRlIGl0IG9uIHRo ZSBzdGFjay4KPgo+IEJ1dCBvbiByZWZsZWN0aW9uLCA2NCBieXRlcyBvZiBzdGFjayBpcyBubyBi aWcgZGVhbCBmb3IgYSA2NC1iaXQKPiBhcmNoaXRlY3R1cmUuICBUaGUgYWZmZWN0ZWQgZnVuY3Rp b25zIHByb2JhYmx5IHNwaWxsIG1vcmUgdGhhbiB0aGFuCj4gYWxyZWFkeSwgYW5kIHRoZXNlIGZ1 bmN0aW9ucyBhcmUgY2FsbGVkIG9uIHdlbGwtZGVmaW5lZCBwYXRocyB3aGljaAo+IHNob3VsZG4n dCBoYXZlIHN1cGVyLWRlZXAgc3RhY2tzIGFscmVhZHkuCj4KPiBbLi4uXQo+Cj4+ID4gQEAgLTY1 OCwyNCArNjYyLDYwIEBAIHZvaWQgX19pbml0IHN2ZV9pbml0X3ZxX21hcCh2b2lkKQo+PiA+ICAg Ki8KPj4gPiAgdm9pZCBzdmVfdXBkYXRlX3ZxX21hcCh2b2lkKQo+PiA+ICB7Cj4+ID4gLQlzdmVf cHJvYmVfdnFzKHN2ZV9zZWNvbmRhcnlfdnFfbWFwKTsKPj4gPiAtCWJpdG1hcF9hbmQoc3ZlX3Zx X21hcCwgc3ZlX3ZxX21hcCwgc3ZlX3NlY29uZGFyeV92cV9tYXAsIFNWRV9WUV9NQVgpOwo+PiA+ ICsJc3ZlX3Byb2JlX3ZxcyhzdmVfdG1wX3ZxX21hcCk7Cj4+ID4gKwliaXRtYXBfYW5kKHN2ZV92 cV9tYXAsIHN2ZV92cV9tYXAsIHN2ZV90bXBfdnFfbWFwLAo+PiA+ICsJCSAgIFNWRV9WUV9NQVgp Owo+PiA+ICsJYml0bWFwX29yKHN2ZV92cV9wYXJ0aWFsX21hcCwgc3ZlX3ZxX3BhcnRpYWxfbWFw LCBzdmVfdG1wX3ZxX21hcCwKPj4gPiArCQkgIFNWRV9WUV9NQVgpOwo+PiA+ICB9Cj4+Cj4+IEkn bSBub3QgcXVpdGUgZm9sbG93aW5nIHdoYXQncyBnb2luZyBvbiBoZXJlLiBUaGlzIGlzIHRyYWNr aW5nIGJvdGggdGhlCj4+IHZlY3RvciBsZW5ndGhzIGF2YWlsYWJsZSBvbiBhbGwgQ1BVcyBhbmQg dGhlIG9uZXMgYXZhaWxhYmxlIG9uIGF0IGxlYXN0Cj4+IG9uZSBDUFU/IFRoaXMgcmFpc2VzIGEg c29tZSBxdWVzdGlvbnM6Cj4+Cj4+ICAgLSBkbyBzdWNoIGZyYW5rZW4tbWFjaGluZXMgZXhpc3Qg b3IgYXJlIGV4cGVjdGVkIHRvIGV4aXQ/Cj4KPiBubywgYW5kIHllcyByZXNwZWN0aXZlbHkgKExp bnV4IGRvZXMgbm90IGVuZG9yc2UgdGhlIGxhdHRlciBmb3Igbm93LAo+IHNpbmNlIGl0IHJlc3Vs dHMgaW4gYSBub24tU01QIHN5c3RlbTogd2UgaGlkZSB0aGUgYXN5bW1ldHJpZXMgd2hlcmUKPiBw b3NzaWJsZSBieSBjbGFtcGluZyB0aGUgc2V0IG9mIGF2YWlsYWJsZSB2ZWN0b3IgbGVuZ3Rocywg YnV0IGZvcgo+IEtWTSBpdCdzIHRvbyBoYXJkIGFuZCB3ZSBkb24ndCBhaW0gdG8gc3VwcG9ydCBp dCBhdCBhbGwpLgo+Cj4gRXZlbiBpZiB3ZSBkb24ndCByZWNvbW1lbmQgZGVwbG95aW5nIGEgZ2Vu ZXJhbC1wdXJwb3NlIE9TIG9uIHN1Y2ggYQo+IHN5c3RlbSwgcGVvcGxlIHdpbGwgZXZlbnR1YWxs eSB0cnkgaXQuICBTbyBpdCdzIGJldHRlciB0byBmYWlsIHNhZmUKPiByYXRoZXIgdGhhbiBzaWxl bnRseSBkb2luZyB0aGUgd3JvbmcgdGhpbmcuCj4KPj4gICAtIGhvdyBkbyB3ZSBlbnN1cmUgdGhp cyBpcyBhbHdheXMgdXB0byBkYXRlPwo+Cj4gVGhpcyBnZXRzIHVwZGF0ZWQgZm9yIGVhY2ggZWFy bHkgc2Vjb25kYXJ5IENQVSB0aGF0IGNvbWVzIHVwLiAgKEVhcmx5Cj4gc2Vjb25kYXJpZXMnIGJv b3QgaXMgc2VyaWFsaXNlZCwgc28gd2Ugc2hvdWxkbid0IGhhdmUgdG8gd29ycnkgYWJvdXQKPiBy YWNlcyBoZXJlLikKPgo+IFRoZSBjb25maWd1cmF0aW9uIGlzIGZyb3plbiBieSB0aGUgdGltZSB3 ZSBlbnRlciB1c2Vyc3BhY2UgKGhlbmNlCj4gX19yb19hZnRlcl9pbml0KS4KPgo+IE9uY2UgYWxs IHRoZSBlYXJseSBzZWNvbmRhcmllcyBoYXZlIGNvbWUgdXAsIHdlIGNvbW1pdCB0byB0aGUgYmVz dAo+IHBvc3NpYmxlIHNldCBvZiB2ZWN0b3IgbGVuZ3RocyBmb3IgdGhlIENQVXMgdGhhdCB3ZSBr bm93IGFib3V0LCBhbmQgd2UKPiBkb24ndCBjYWxsIHRoaXMgcGF0aCBhbnkgbW9yZTogaW5zdGVh ZCwgZWFjaCBsYXRlIHNlY29uZGFyeSBnb2VzIGludG8KPiBzdmVfdmVyaWZ5X3ZxX21hcCgpIGlu c3RlYWQgdG8gY2hlY2sgdGhhdCB0aG9zZSBDUFVzIGFyZSBjb21wYXRpYmxlCj4gd2l0aCB0aGUg Y29uZmlndXJhdGlvbiB3ZSBjb21taXR0ZWQgdG8uCj4KPiBGb3IgY29udGV4dCwgdGFrZSBhIGxv b2sgYXQKPiBhcmNoL2FybTY0L2tlcm5lbC9jcHVmZWF0dXJlLmM6Y2hlY2tfbG9jYWxfY3B1X2Nh cGFiaWxpdGllcygpLCB3aGljaCBpcwo+IHRoZSBjb21tb24gZW50cnkgcG9pbnQgZm9yIGFsbCBz ZWNvbmRhcnkgQ1BVczogdGhhdCBzcGxpdHMgaW50bwo+IHVwZGF0ZV9jcHVfY2FwYWJpbGl0aWVz KCkgYW5kIHZlcmlmeV9sb2NhbF9jcHVfY2FwYWJpbGl0aWVzKCkgcGF0aHMgZm9yCj4gdGhlIHR3 byBjYXNlcyBkZXNjcmliZWQgYWJvdmUsIGNhbGxpbmcgZG93biBpbnRvIHN2ZV91cGRhdGVfdnFf bWFwKCkKPiBhbmQgc3ZlX3ZlcmlmeV92cV9tYXAoKSBhcyBhcHByb3ByaWF0ZS4KPgo+PiAgIC0g d2hhdCBoYXBwZW5zIHdoZW4gd2UgaG90cGx1ZyBhIG5ldyBDUFUgd2l0aCBsZXNzIGF2YWlsYWJs ZSBWUT8KPgo+IFdlIHJlamVjdCB0aGUgQ1BVIGFuZCB0aHJvdyBpdCBiYWNrIHRvIHRoZSBmaXJt d2FyZSAoc2VlCj4gY3B1ZmVhdHVyZS5jOnZlcmlmeV9zdmVfZmVhdHVyZXMoKSkuCj4KPiBUaGlz IGZvbGxvd3MgdGhlIHByZWNlZGVudCBhbHJlYWR5IHNldCBpbiB2ZXJpZnlfbG9jYWxfY3B1X2Nh cGFiaWxpdGllcygpCj4gZXRjLgoKSSB0aGluayBhIGZldyB3b3JkcyB0byB0aGF0IGVmZmVjdCBp biB0aGUgZnVuY3Rpb24gY29tbWVudHMgd291bGQgYmUKaGVscGZ1bDoKCiAgLyoKICAgKiBzdmVf dXBkYXRlX3ZxX21hcCBvbmx5IGNhcmVzIGFib3V0IENQVXMgYXQgYm9vdCB0aW1lIGFuZCBpcyBj YWxsZWQKICAgKiBzZXJpYWxseSBmb3IgZWFjaCBvbmUuIEFueSBDUFVzIGFkZGVkIGxhdGVyIHZp YSBob3RwbHVnIHdpbGwgZmFpbAogICAqIGF0IHN2ZV92ZXJpZnlfdnFfbWFwIGlmIHRoZXkgZG9u J3QgbWF0Y2ggd2hhdCBpcyBkZXRlY3RlZCBoZXJlLgogICAqLwoKPgo+Pgo+PiA+Cj4+ID4gIC8q IENoZWNrIHdoZXRoZXIgdGhlIGN1cnJlbnQgQ1BVIHN1cHBvcnRzIGFsbCBWUXMgaW4gdGhlIGNv bW1pdHRlZCBzZXQgKi8KPj4gPiAgaW50IHN2ZV92ZXJpZnlfdnFfbWFwKHZvaWQpCj4+ID4gIHsK Pj4gPiAtCWludCByZXQgPSAwOwo+PiA+ICsJaW50IHJldCA9IC1FSU5WQUw7Cj4+ID4gKwl1bnNp Z25lZCBsb25nIGI7Cj4+ID4KPj4gPiAtCXN2ZV9wcm9iZV92cXMoc3ZlX3NlY29uZGFyeV92cV9t YXApOwo+PiA+IC0JYml0bWFwX2FuZG5vdChzdmVfc2Vjb25kYXJ5X3ZxX21hcCwgc3ZlX3ZxX21h cCwgc3ZlX3NlY29uZGFyeV92cV9tYXAsCj4+ID4gLQkJICAgICAgU1ZFX1ZRX01BWCk7Cj4+ID4g LQlpZiAoIWJpdG1hcF9lbXB0eShzdmVfc2Vjb25kYXJ5X3ZxX21hcCwgU1ZFX1ZRX01BWCkpIHsK Pj4gPiArCXN2ZV9wcm9iZV92cXMoc3ZlX3RtcF92cV9tYXApOwo+PiA+ICsKPj4gPiArCWJpdG1h cF9jb21wbGVtZW50KHN2ZV90bXBfdnFfbWFwLCBzdmVfdG1wX3ZxX21hcCwgU1ZFX1ZRX01BWCk7 Cj4+ID4gKwlpZiAoYml0bWFwX2ludGVyc2VjdHMoc3ZlX3RtcF92cV9tYXAsIHN2ZV92cV9tYXAs IFNWRV9WUV9NQVgpKSB7Cj4+ID4gIAkJcHJfd2FybigiU1ZFOiBjcHUlZDogUmVxdWlyZWQgdmVj dG9yIGxlbmd0aChzKSBtaXNzaW5nXG4iLAo+PiA+ICAJCQlzbXBfcHJvY2Vzc29yX2lkKCkpOwo+ PiA+IC0JCXJldCA9IC1FSU5WQUw7Cj4+ID4gKwkJZ290byBlcnJvcjsKPj4KPj4gVGhlIHVzZSBv ZiBnb3RvIHNlZW1zIGEgbGl0dGxlIHByZW1hdHVyZSBjb25zaWRlcmluZyB3ZSBkb24ndCBoYXZl IGFueQo+PiBjbGVhbi11cCB0byBkby4KPgo+IEhtbSwgdGhpcyBkb2VzIGxvb2sgYSBsaXR0bGUg b3ZlcmVuZ2luZWVyZWQuICBJIHRoaW5rIGl0IG1heSBoYXZlIGJlZW4KPiBtb3JlIGNvbXBsZXgg ZHVyaW5nIGRldmVsb3BtZW50IChtYWtpbmcgdGhlIGdvdG9zIGxlc3MgcmVkdW5kYW50KSwgYnV0 Cj4gdG8gYmUgaG9uZXN0IEkgZG9uJ3QgcmVtZW1iZXIgbm93Lgo+Cj4gSSdtIGhhcHB5IHRvIGdl dCByaWQgb2YgdGhlIHJhdGhlciBwb2ludGxlc3MgcmV0IHZhcmlhYmxlIGFuZCByZXBsYWNlCj4g YWxsIHRoZSBnb3RvcyB3aXRoIHJldHVybnMgaWYgdGhhdCB3b3JrcyBmb3IgeW91Lgo+Cj4gV2hh dCBkbyB5b3UgdGhpbms/CgpZZXMgcGxlYXNlLCB0aGF0IHdvdWxkIGJlIGNsZWFuZXIuCgotLQpB bGV4IEJlbm7DqWUKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18Ka3ZtYXJtIG1haWxpbmcgbGlzdAprdm1hcm1AbGlzdHMuY3MuY29sdW1iaWEuZWR1Cmh0dHBz Oi8vbGlzdHMuY3MuY29sdW1iaWEuZWR1L21haWxtYW4vbGlzdGluZm8va3ZtYXJtCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: alex.bennee@linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=) Date: Fri, 16 Nov 2018 12:32:18 +0000 Subject: [RFC PATCH v2 06/23] arm64/sve: Check SVE virtualisability In-Reply-To: <20181115170904.GO3505@e103592.cambridge.arm.com> References: <1538141967-15375-1-git-send-email-Dave.Martin@arm.com> <1538141967-15375-7-git-send-email-Dave.Martin@arm.com> <87in0ycpuy.fsf@linaro.org> <20181115170904.GO3505@e103592.cambridge.arm.com> Message-ID: <87bm6pciel.fsf@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Dave Martin writes: > On Thu, Nov 15, 2018 at 03:39:01PM +0000, Alex Benn?e wrote: >> >> Dave Martin writes: >> >> > Due to the way the effective SVE vector length is controlled and >> > trapped at different exception levels, certain mismatches in the >> > sets of vector lengths supported by different physical CPUs in the >> > system may prevent straightforward virtualisation of SVE at parity >> > with the host. >> > >> > This patch analyses the extent to which SVE can be virtualised >> > safely without interfering with migration of vcpus between physical >> > CPUs, and rejects late secondary CPUs that would erode the >> > situation further. >> > >> > It is left up to KVM to decide what to do with this information. >> > >> > Signed-off-by: Dave Martin >> > --- >> > >> > Changes since RFCv1: >> > >> > * The analysis done by this patch is the same as in the previous >> > version, but the commit message the printks etc. have been reworded >> > to avoid the suggestion that KVM is expected to work on a system with >> > mismatched SVE implementations. >> > --- >> > arch/arm64/include/asm/fpsimd.h | 1 + >> > arch/arm64/kernel/cpufeature.c | 2 +- >> > arch/arm64/kernel/fpsimd.c | 87 +++++++++++++++++++++++++++++++++++------ >> > 3 files changed, 76 insertions(+), 14 deletions(-) >> > > > [...] > >> > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > > [...] > >> > @@ -623,11 +629,8 @@ int sve_get_current_vl(void) > > [...] > >> > +/* Bitmaps for temporary storage during manipulation of vector length sets */ >> > +static DECLARE_BITMAP(sve_tmp_vq_map, SVE_VQ_MAX); >> >> This seems odd as a local global, why not declared locally when used? > > Could do. > > My original concern was that this is "big" and therefore it's impolite > to allocate it on the stack. > > But on reflection, 64 bytes of stack is no big deal for a 64-bit > architecture. The affected functions probably spill more than than > already, and these functions are called on well-defined paths which > shouldn't have super-deep stacks already. > > [...] > >> > @@ -658,24 +662,60 @@ void __init sve_init_vq_map(void) >> > */ >> > void sve_update_vq_map(void) >> > { >> > - sve_probe_vqs(sve_secondary_vq_map); >> > - bitmap_and(sve_vq_map, sve_vq_map, sve_secondary_vq_map, SVE_VQ_MAX); >> > + sve_probe_vqs(sve_tmp_vq_map); >> > + bitmap_and(sve_vq_map, sve_vq_map, sve_tmp_vq_map, >> > + SVE_VQ_MAX); >> > + bitmap_or(sve_vq_partial_map, sve_vq_partial_map, sve_tmp_vq_map, >> > + SVE_VQ_MAX); >> > } >> >> I'm not quite following what's going on here. This is tracking both the >> vector lengths available on all CPUs and the ones available on at least >> one CPU? This raises a some questions: >> >> - do such franken-machines exist or are expected to exit? > > no, and yes respectively (Linux does not endorse the latter for now, > since it results in a non-SMP system: we hide the asymmetries where > possible by clamping the set of available vector lengths, but for > KVM it's too hard and we don't aim to support it at all). > > Even if we don't recommend deploying a general-purpose OS on such a > system, people will eventually try it. So it's better to fail safe > rather than silently doing the wrong thing. > >> - how do we ensure this is always upto date? > > This gets updated for each early secondary CPU that comes up. (Early > secondaries' boot is serialised, so we shouldn't have to worry about > races here.) > > The configuration is frozen by the time we enter userspace (hence > __ro_after_init). > > Once all the early secondaries have come up, we commit to the best > possible set of vector lengths for the CPUs that we know about, and we > don't call this path any more: instead, each late secondary goes into > sve_verify_vq_map() instead to check that those CPUs are compatible > with the configuration we committed to. > > For context, take a look at > arch/arm64/kernel/cpufeature.c:check_local_cpu_capabilities(), which is > the common entry point for all secondary CPUs: that splits into > update_cpu_capabilities() and verify_local_cpu_capabilities() paths for > the two cases described above, calling down into sve_update_vq_map() > and sve_verify_vq_map() as appropriate. > >> - what happens when we hotplug a new CPU with less available VQ? > > We reject the CPU and throw it back to the firmware (see > cpufeature.c:verify_sve_features()). > > This follows the precedent already set in verify_local_cpu_capabilities() > etc. I think a few words to that effect in the function comments would be helpful: /* * sve_update_vq_map only cares about CPUs at boot time and is called * serially for each one. Any CPUs added later via hotplug will fail * at sve_verify_vq_map if they don't match what is detected here. */ > >> >> > >> > /* Check whether the current CPU supports all VQs in the committed set */ >> > int sve_verify_vq_map(void) >> > { >> > - int ret = 0; >> > + int ret = -EINVAL; >> > + unsigned long b; >> > >> > - sve_probe_vqs(sve_secondary_vq_map); >> > - bitmap_andnot(sve_secondary_vq_map, sve_vq_map, sve_secondary_vq_map, >> > - SVE_VQ_MAX); >> > - if (!bitmap_empty(sve_secondary_vq_map, SVE_VQ_MAX)) { >> > + sve_probe_vqs(sve_tmp_vq_map); >> > + >> > + bitmap_complement(sve_tmp_vq_map, sve_tmp_vq_map, SVE_VQ_MAX); >> > + if (bitmap_intersects(sve_tmp_vq_map, sve_vq_map, SVE_VQ_MAX)) { >> > pr_warn("SVE: cpu%d: Required vector length(s) missing\n", >> > smp_processor_id()); >> > - ret = -EINVAL; >> > + goto error; >> >> The use of goto seems a little premature considering we don't have any >> clean-up to do. > > Hmm, this does look a little overengineered. I think it may have been > more complex during development (making the gotos less redundant), but > to be honest I don't remember now. > > I'm happy to get rid of the rather pointless ret variable and replace > all the gotos with returns if that works for you. > > What do you think? Yes please, that would be cleaner. -- Alex Benn?e