I saw the architecture code about mips&= nbsp;in the qemu and kvm modules, so it= is no doubt that mips cpu can be&= nbsp;supported.

But I wonder if anyone have used q= emu/kvm virtualization with China loongson proces= sor (MIPS architecture) without modification of&n= bsp;qemu/kvm code.

All the infomation I have searched in&n= bsp;the Internet can't answer my question. <= /DIV>

If anyone have done that before, let&nb= sp;me know it will not =20 be a dead end.

Thanks

Sangfor VT

------=_001_NextPart578133651256_=------ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiBob-0006du-Je for qemu-devel@nongnu.org; Tue, 14 Apr 2015 21:08:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiBoY-0005NL-7b for qemu-devel@nongnu.org; Tue, 14 Apr 2015 21:08:29 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:33583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiBoY-0005N0-2o for qemu-devel@nongnu.org; Tue, 14 Apr 2015 21:08:26 -0400 Received: by paboj16 with SMTP id oj16so31153110pab.0 for ; Tue, 14 Apr 2015 18:08:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201504131929543844171@sangfor.com.cn> References: <201504131929543844171@sangfor.com.cn> Date: Tue, 14 Apr 2015 20:08:24 -0500 Message-ID: From: Rob Landley Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: vt Cc: qemu-devel On Mon, Apr 13, 2015 at 6:29 AM, vt wrote: > Hi, guys > > I saw the architecture code about mips in the qemu and kvm modules, so it is > no doubt that mips cpu can be supported. It looks like the 32 bit one should work fine. I haven't played with 64 bit yet but there's some support for it in the tree, give it a try? http://en.wikipedia.org/wiki/Loongson Heh. The background on the "4 patented instructions" mentioned above is mips' lawsuit against Lexra many years ago: http://landley.net/notes-2009.html#14-12-2009 If you were wondering why mips had a lost decade where most of its customers switched over to arm, convincing the world you're a patent troll will do that. But it's been well over a decade and most people seem to have forgotten now. And china never cared about US intellectual property infighting anyway... > But I wonder if anyone have used qemu/kvm virtualization with China loongson > processor (MIPS architecture) without modification of qemu/kvm code. > All the infomation I have searched in the Internet can't answer my question. I have a mips r4k system emulation working fine at: http://landley.net/aboriginal/bin/system-image-mips.tar.gz (That's based off of linux 3.18 I think, I have 3.19 building locally, 4.0 is on the todo list.) I haven't tried 64 bit yet but: $ qemu-system-mips64 -cpu ? | grep Loongson MIPS 'Loongson-2E' MIPS 'Loongson-2F' It's apparently there... Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiEOo-0004g0-2n for qemu-devel@nongnu.org; Tue, 14 Apr 2015 23:54:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiEOk-00072m-Rh for qemu-devel@nongnu.org; Tue, 14 Apr 2015 23:54:02 -0400 Received: from smtp.sangfor.com.cn ([58.251.49.30]:57417 helo=mail.sangfor.com.cn) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiEOk-0006ko-1j for qemu-devel@nongnu.org; Tue, 14 Apr 2015 23:53:58 -0400 Date: Wed, 15 Apr 2015 11:53:47 +0800 From: vt References: <201504131929543844171@sangfor.com.cn>, Mime-Version: 1.0 Message-ID: <201504151153471388130@sangfor.com.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart716185363028_=----" Subject: Re: [Qemu-devel] [Question]Support of China loogson processor Reply-To: vt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: qemu-devel This is a multi-part message in MIME format. ------=_001_NextPart716185363028_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMjAxNS80LzE1IDk6MDgsIFJvYiBMYW5kbGV5ICB3cm90ZToNCj4gT24gTW9uLCBBcHIgMTMs IDIwMTUgYXQgNjoyOSBBTSwgdnQgPHZ0QHNhbmdmb3IuY29tLmNuPiB3cm90ZToNCj4+IEhpLCBn dXlzDQo+Pg0KPj4gSSBzYXcgdGhlIGFyY2hpdGVjdHVyZSBjb2RlIGFib3V0IG1pcHMgaW4gdGhl IHFlbXUgYW5kIGt2bSBtb2R1bGVzLCBzbyBpdCBpcw0KPj4gbm8gZG91YnQgdGhhdCBtaXBzIGNw dSBjYW4gYmUgc3VwcG9ydGVkLg0KPg0KPiBJdCBsb29rcyBsaWtlIHRoZSAzMiBiaXQgb25lIHNo b3VsZCB3b3JrIGZpbmUuIEkgaGF2ZW4ndCBwbGF5ZWQgd2l0aA0KPiA2NCBiaXQgeWV0IGJ1dCB0 aGVyZSdzIHNvbWUgc3VwcG9ydCBmb3IgaXQgaW4gdGhlIHRyZWUsIGdpdmUgaXQgYSB0cnk/DQo+ DQo+ICAgaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Mb29uZ3Nvbg0KPg0KPiBIZWguIFRo ZSBiYWNrZ3JvdW5kIG9uIHRoZSAiNCBwYXRlbnRlZCBpbnN0cnVjdGlvbnMiIG1lbnRpb25lZCBh Ym92ZQ0KPiBpcyBtaXBzJyBsYXdzdWl0IGFnYWluc3QgTGV4cmEgbWFueSB5ZWFycyBhZ286DQo+ DQo+ICAgaHR0cDovL2xhbmRsZXkubmV0L25vdGVzLTIwMDkuaHRtbCMxNC0xMi0yMDA5DQo+DQo+ IElmIHlvdSB3ZXJlIHdvbmRlcmluZyB3aHkgbWlwcyBoYWQgYSBsb3N0IGRlY2FkZSB3aGVyZSBt b3N0IG9mIGl0cw0KPiBjdXN0b21lcnMgc3dpdGNoZWQgb3ZlciB0byBhcm0sIGNvbnZpbmNpbmcg dGhlIHdvcmxkIHlvdSdyZSBhIHBhdGVudA0KPiB0cm9sbCB3aWxsIGRvIHRoYXQuIEJ1dCBpdCdz IGJlZW4gd2VsbCBvdmVyIGEgZGVjYWRlIGFuZCBtb3N0IHBlb3BsZQ0KPiBzZWVtIHRvIGhhdmUg Zm9yZ290dGVuIG5vdy4gQW5kIGNoaW5hIG5ldmVyIGNhcmVkIGFib3V0IFVTDQo+IGludGVsbGVj dHVhbCBwcm9wZXJ0eSBpbmZpZ2h0aW5nIGFueXdheS4uLg0KPg0KPj4gQnV0IEkgd29uZGVyIGlm IGFueW9uZSBoYXZlIHVzZWQgcWVtdS9rdm0gdmlydHVhbGl6YXRpb24gd2l0aCBDaGluYSBsb29u Z3Nvbg0KPj4gcHJvY2Vzc29yIChNSVBTIGFyY2hpdGVjdHVyZSkgd2l0aG91dCBtb2RpZmljYXRp b24gb2YgcWVtdS9rdm0gY29kZS4NCj4+IEFsbCB0aGUgaW5mb21hdGlvbiBJIGhhdmUgc2VhcmNo ZWQgaW4gdGhlIEludGVybmV0IGNhbid0IGFuc3dlciBteSBxdWVzdGlvbi4NCj4NCj4gSSBoYXZl IGEgbWlwcyByNGsgc3lzdGVtIGVtdWxhdGlvbiB3b3JraW5nIGZpbmUgYXQ6DQo+DQo+ICAgaHR0 cDovL2xhbmRsZXkubmV0L2Fib3JpZ2luYWwvYmluL3N5c3RlbS1pbWFnZS1taXBzLnRhci5neg0K Pg0KPiAoVGhhdCdzIGJhc2VkIG9mZiBvZiBsaW51eCAzLjE4IEkgdGhpbmssIEkgaGF2ZSAzLjE5 IGJ1aWxkaW5nIGxvY2FsbHksDQo+IDQuMCBpcyBvbiB0aGUgdG9kbyBsaXN0LikNCj4NCj4gSSBo YXZlbid0IHRyaWVkIDY0IGJpdCB5ZXQgYnV0Og0KPg0KPiAkIHFlbXUtc3lzdGVtLW1pcHM2NCAt Y3B1ID8gfCBncmVwIExvb25nc29uDQo+IE1JUFMgJ0xvb25nc29uLTJFJw0KPiBNSVBTICdMb29u Z3Nvbi0yRicNCj4NCj4gSXQncyBhcHBhcmVudGx5IHRoZXJlLi4uDQo+DQo+IFJvYg0KPg0KDQpS b2IsIFRoYW5rcyBmb3IgeW91ciBoZWxwLg0KDQpTYW5nZm9yIFZU ------=_001_NextPart716185363028_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF

On 2015/4/15 9:08, Rob Landley wrote:

> On Mon, Apr 13, 2015 at 6:29&= nbsp;AM, vt <vt@sangfor.com.cn> wrote:

>> Hi, guys

>> I saw the architecture code ab= out mips in the qemu and kvm modules,&n= bsp;so it is

>> no doubt that mips cpu can&nbs= p;be supported.

> It looks like the 32 bit one&= nbsp;should work fine. I haven't played with=

> 64 bit yet but there's some s= upport for it in the tree, give it = ;a try?

> http://en.wikipedia.org/wiki/Loongson

> Heh. The background on the "4 = ;patented instructions" mentioned above

> is mips' lawsuit against Lexra man= y years ago:

> http://landley.net/notes-2009.html#14-12-2009

> If you were wondering why mips&nbs= p;had a lost decade where most of its

> customers switched over to arm, co= nvincing the world you're a patent

> troll will do that. But it's = been well over a decade and most people=

> seem to have forgotten now. And&nb= sp;china never cared about US

> intellectual property infighting anyway...

>> But I wonder if anyone have&nb= sp;used qemu/kvm virtualization with China loongs= on

>> processor (MIPS architecture) without&nb= sp;modification of qemu/kvm code.

>> All the infomation I have sear= ched in the Internet can't answer my qu= estion.

> I have a mips r4k system emul= ation working fine at:

> http://landley.net/aboriginal/bin/system-image-= mips.tar.gz

> (That's based off of linux 3.18&nb= sp;I think, I have 3.19 building locally,

> 4.0 is on the todo list.)

> I haven't tried 64 bit yet bu= t:

> $ qemu-system-mips64 -cpu ? | grep= Loongson

> MIPS 'Loongson-2E'

> MIPS 'Loongson-2F'

> It's apparently there...

> Rob

Rob, Thanks for your help.

Sangfor VT

------=_001_NextPart716185363028_=------ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJTl-0004Qh-ID for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:19:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiJTd-00060c-QV for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:19:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45339 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJTd-00060C-Jw for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:19:21 -0400 Message-ID: <552E2D16.7030104@suse.de> Date: Wed, 15 Apr 2015 11:19:18 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: Leon Alrae , qemu-devel , vt Am 15.04.2015 um 03:08 schrieb Rob Landley: > On Mon, Apr 13, 2015 at 6:29 AM, vt wrote: >> I saw the architecture code about mips in the qemu and kvm modules, so= it is >> no doubt that mips cpu can be supported. >=20 > It looks like the 32 bit one should work fine. I haven't played with > 64 bit yet but there's some support for it in the tree, give it a try? [...] >> But I wonder if anyone have used qemu/kvm virtualization with China lo= ongson >> processor (MIPS architecture) without modification of qemu/kvm code. >> All the infomation I have searched in the Internet can't answer my que= stion. >=20 > I have a mips r4k system emulation working fine at: [...] > I haven't tried 64 bit yet but: >=20 > $ qemu-system-mips64 -cpu ? | grep Loongson > MIPS 'Loongson-2E' > MIPS 'Loongson-2F' >=20 > It's apparently there... Note that the question was about KVM virtualization, not emulation (unless it was misphrased). CC'ing Leon as MIPS maintainer. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=C3=BCrnberg) From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJji-0004r1-16 for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:36:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiJjd-0004fN-1A for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:35:57 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:57731 helo=imgpgp01.kl.imgtec.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiJjc-0004ev-PH for qemu-devel@nongnu.org; Wed, 15 Apr 2015 05:35:52 -0400 Message-ID: <552E30F5.2020207@imgtec.com> Date: Wed, 15 Apr 2015 10:35:49 +0100 From: James Hogan MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> In-Reply-To: <201504131929543844171@sangfor.com.cn> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="To1bOhSUPcC0wKP4iWupVbiBdU8fVWARx" Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: vt , qemu-devel --To1bOhSUPcC0wKP4iWupVbiBdU8fVWARx Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: quoted-printable On 13/04/15 12:29, vt wrote: > Hi, guys > =20 > I saw the architecture code about mips in the qemu and kvm modules, so = it is no doubt that mips cpu can be supported. > But I wonder if anyone have used qemu/kvm virtualization with China loo= ngson processor (MIPS architecture) without modification of qemu/kvm code= =2E > All the infomation I have searched in the Internet can't answer my ques= tion.=20 > =20 > If anyone have done that before, let me know it will not be a dead end= =2E > =20 > Thanks > Sangfor VT I haven't attempted it on Loongson yet, but it'd be interesting to see whether it works. You'd still have to emulate a Malta guest at the moment. Getting it to work on the Ingenic XBurst cores required a little effort in the kernel due to slight incompatibilities with the MIPS32r2 spec, so its possible there'll be problems with Loongson too. I presume Loongson may use highmem, if so you'll want to disable it. I still need to get those patches sorted out. Let us know how it goes or if you hit problems! Cheers James --To1bOhSUPcC0wKP4iWupVbiBdU8fVWARx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBAgAGBQJVLjD1AAoJEGwLaZPeOHZ6WRQP+NELsfMBWlXhWlVZQJHBDzWo OKKQJMR+GxfiXchZ3v0TbTIkT0tmrjYHCubh/UYYQn8MKh8xtxeSX3UcrqS6K5iQ X7HUVMzSPPNEHrysOPOXz+zlMNbrCBrEWnfEljbsqzZlWA1us5aKUUFsOMIbmRB8 +/mx8vg9Cjp5Kd5CC5dhAgWToAt549enjweXgbMcZ34eqofRy50X1vdLulpm8C21 f2S85Hl+o0ZeJs/XybYqx2gm9t+gnZfG3zoDmvPxE7g4XdNztsvTu1FZ1xVAgLXq t0qrFDQQfRFMoZPb0wq9leIfkA+db/ea3YTfZpTkfrgDCQ9t2j37J5eQZiEStBY7 wY7+ocQf03Xua2r4eRDe1wDsSr9r7AoyViVnWHF9DhZQXLUJzZhz5lRr6RvxJ9+P S3M+nQ7Rfl2rumY+vLTAl6haDWhQGBdPNo48Vo5ZpLMl19VVX+HvM/xs/EhC9Ya6 vErdRhIQo7bHRvPqUowVnIMaTK8r4TfUfInKU5xUXbQMHdW2rn1blA6qBBKluH8p 468DmrlVJkhKIlN1/nNQ0WUkp0HJyALUJzDmWwKHz6/HGBuAIzo0y5oLpYAGcAqS NYyPB2WTjQJv7tTRJKSAst+mD7iF/uX/uG4//bxBoQi2YneyvBcV8QGroA+0K9y5 8QGwxjJl5r5YL/UvvVY= =x/mF -----END PGP SIGNATURE----- --To1bOhSUPcC0wKP4iWupVbiBdU8fVWARx-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiheC-0004O3-4g for qemu-devel@nongnu.org; Thu, 16 Apr 2015 07:07:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yihe8-0002E5-0j for qemu-devel@nongnu.org; Thu, 16 Apr 2015 07:07:51 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:33079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yihe7-0002Dx-Ru for qemu-devel@nongnu.org; Thu, 16 Apr 2015 07:07:47 -0400 Message-ID: <552F97FF.4000109@imgtec.com> Date: Thu, 16 Apr 2015 12:07:43 +0100 From: Leon Alrae MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> <552E30F5.2020207@imgtec.com> In-Reply-To: <552E30F5.2020207@imgtec.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: James Hogan , vt , qemu-devel On 15/04/2015 10:35, James Hogan wrote: > On 13/04/15 12:29, vt wrote: >> Hi, guys >> >> I saw the architecture code about mips in the qemu and kvm modules, so it is no doubt that mips cpu can be supported. >> But I wonder if anyone have used qemu/kvm virtualization with China loongson processor (MIPS architecture) without modification of qemu/kvm code. >> All the infomation I have searched in the Internet can't answer my question. >> >> If anyone have done that before, let me know it will not be a dead end. >> >> Thanks >> Sangfor VT > > I haven't attempted it on Loongson yet, but it'd be interesting to see > whether it works. You'd still have to emulate a Malta guest at the > moment. Getting it to work on the Ingenic XBurst cores required a little > effort in the kernel due to slight incompatibilities with the MIPS32r2 > spec, so its possible there'll be problems with Loongson too. > > I presume Loongson may use highmem, if so you'll want to disable it. I > still need to get those patches sorted out. > > Let us know how it goes or if you hit problems! Since I also haven't had a chance to test Loongson emulation, I thought I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine). Good news is that I'm able to get to the login prompt using ancient QEMU v1.0, kernel 2.6.33 (with additional patch from https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and some old debian image I had handy. However, in any newer version starting from v1.1.0 of QEMU something goes horribly wrong and it just segfaults somewhere inside hw/bonito.c quite early during kernel booting. I haven't looked deeper, but it seems it's not in the best shape... Leon From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiiUk-00065g-41 for qemu-devel@nongnu.org; Thu, 16 Apr 2015 08:02:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiiUg-0006sP-Tf for qemu-devel@nongnu.org; Thu, 16 Apr 2015 08:02:10 -0400 Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:36785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiiUg-0006sI-N1 for qemu-devel@nongnu.org; Thu, 16 Apr 2015 08:02:06 -0400 Received: by wizk4 with SMTP id k4so191750930wiz.1 for ; Thu, 16 Apr 2015 05:02:06 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <552FA4B9.4070204@redhat.com> Date: Thu, 16 Apr 2015 14:02:01 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> <552E30F5.2020207@imgtec.com> <552F97FF.4000109@imgtec.com> In-Reply-To: <552F97FF.4000109@imgtec.com> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leon Alrae , James Hogan , vt , qemu-devel On 16/04/2015 13:07, Leon Alrae wrote: > Since I also haven't had a chance to test Loongson emulation, I thought > I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine). > > Good news is that I'm able to get to the login prompt using ancient QEMU > v1.0, kernel 2.6.33 (with additional patch from > https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and > some old debian image I had handy. However, in any newer version > starting from v1.1.0 of QEMU something goes horribly wrong and it just > segfaults somewhere inside hw/bonito.c quite early during kernel > booting. Where exactly? If it's related to the memory API conversion, it may be easy to fix. I can look at a backtrace (or you can just put the Debian image somewhere I can grab it). Paolo > I haven't looked deeper, but it seems it's not in the best shape... From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YilM0-0003Hj-Be for qemu-devel@nongnu.org; Thu, 16 Apr 2015 11:05:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YilLp-0000W3-8p for qemu-devel@nongnu.org; Thu, 16 Apr 2015 11:05:20 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:20883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YilLo-0000M8-RB for qemu-devel@nongnu.org; Thu, 16 Apr 2015 11:05:09 -0400 Message-ID: <552FCF9F.4020500@imgtec.com> Date: Thu, 16 Apr 2015 16:05:03 +0100 From: Leon Alrae MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> <552E30F5.2020207@imgtec.com> <552F97FF.4000109@imgtec.com> <552FA4B9.4070204@redhat.com> In-Reply-To: <552FA4B9.4070204@redhat.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , James Hogan , vt , qemu-devel On 16/04/2015 13:02, Paolo Bonzini wrote: > > > On 16/04/2015 13:07, Leon Alrae wrote: >> Since I also haven't had a chance to test Loongson emulation, I thought >> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine). >> >> Good news is that I'm able to get to the login prompt using ancient QEMU >> v1.0, kernel 2.6.33 (with additional patch from >> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and >> some old debian image I had handy. However, in any newer version >> starting from v1.1.0 of QEMU something goes horribly wrong and it just >> segfaults somewhere inside hw/bonito.c quite early during kernel >> booting. > > Where exactly? If it's related to the memory API conversion, it may be > easy to fix. I can look at a backtrace (or you can just put the Debian > image somewhere I can grab it). Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093 Crash occurs during the first access, below there is backtrace from working and not working case: Bad: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffefe27700 (LWP 10929)] 0x00005555557a2278 in bonito_readl (opaque=0x5555564fb690, addr=24, size=4) at qemu/hw/bonito.c:299 299 return s->regs[saddr]; (gdb) bt #0 0x00005555557a2278 in bonito_readl (opaque=0x5555564fb690, addr=24, size=4) at qemu/hw/bonito.c:299 #1 0x00005555557d6e03 in memory_region_read_accessor (opaque=0x5555564fbb60, addr=24, value=0x7fffefe265d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314 #2 0x00005555557d6fa9 in access_with_adjusted_size (addr=24, value=0x7fffefe265d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6daa , opaque=0x5555564fbb60) at qemu/memory.c:359 #3 0x00005555557d9796 in memory_region_dispatch_read1 (mr=0x5555564fbb60, addr=24, size=4) at qemu/memory.c:860 #4 0x00005555557d9886 in memory_region_dispatch_read (mr=0x5555564fbb60, addr=24, size=4) at qemu/memory.c:892 #5 0x00005555557dc306 in io_mem_read (io_index=6, addr=24, size=4) at qemu/memory.c:1492 #6 0x00005555557aed0d in subpage_read (opaque=0x5555564ed790, addr=24, len=4) at qemu/exec.c:3351 #7 0x00005555557d6e03 in memory_region_read_accessor (opaque=0x5555564ed790, addr=280, value=0x7fffefe267d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314 #8 0x00005555557d6fa9 in access_with_adjusted_size (addr=280, value=0x7fffefe267d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6daa , opaque=0x5555564ed790) at qemu/memory.c:359 #9 0x00005555557d9796 in memory_region_dispatch_read1 (mr=0x5555564ed790, addr=280, size=4) at qemu/memory.c:860 #10 0x00005555557d9886 in memory_region_dispatch_read (mr=0x5555564ed790, addr=280, size=4) at qemu/memory.c:892 #11 0x00005555557dc306 in io_mem_read (io_index=7, addr=280, size=4) at qemu/memory.c:1492 #12 0x00005555557f523e in io_readl (physaddr=280, addr=18446744072633712920, retaddr=0x4023335e) at qemu/softmmu_template.h:78 #13 0x00005555557f5335 in __ldl_mmu (addr=18446744072633712920, mmu_idx=0) at qemu/softmmu_template.h:114 Good: Breakpoint 1, bonito_readl (opaque=0x55555646e450, addr=280, size=4) at qemu/hw/bonito.c:288 288 { (gdb) bt #0 bonito_readl (opaque=0x55555646e450, addr=280, size=4) at qemu/hw/bonito.c:288 #1 0x00005555557d6b83 in memory_region_read_accessor (opaque=0x55555646e920, addr=280, value=0x7fffefe265d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314 #2 0x00005555557d6d29 in access_with_adjusted_size (addr=280, value=0x7fffefe265d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6b2a , opaque=0x55555646e920) at qemu/memory.c:359 #3 0x00005555557d9516 in memory_region_dispatch_read1 (mr=0x55555646e920, addr=280, size=4) at qemu/memory.c:860 #4 0x00005555557d9606 in memory_region_dispatch_read (mr=0x55555646e920, addr=280, size=4) at qemu/memory.c:892 #5 0x00005555557dc086 in io_mem_read (io_index=6, addr=280, size=4) at qemu/memory.c:1492 #6 0x00005555557aeba5 in subpage_read (opaque=0x555556543730, addr=280, len=4) at qemu/exec.c:3343 #7 0x00005555557d6b83 in memory_region_read_accessor (opaque=0x555556543730, addr=280, value=0x7fffefe267d0, size=4, shift=0, mask=4294967295) at qemu/memory.c:314 #8 0x00005555557d6d29 in access_with_adjusted_size (addr=280, value=0x7fffefe267d0, size=4, access_size_min=1, access_size_max=4, access=0x5555557d6b2a , opaque=0x555556543730) at qemu/memory.c:359 #9 0x00005555557d9516 in memory_region_dispatch_read1 (mr=0x555556543730, addr=280, size=4) at qemu/memory.c:860 #10 0x00005555557d9606 in memory_region_dispatch_read (mr=0x555556543730, addr=280, size=4) at qemu/memory.c:892 #11 0x00005555557dc086 in io_mem_read (io_index=7, addr=280, size=4) at qemu/memory.c:1492 #12 0x00005555557f4fbe in io_readl (physaddr=280, addr=18446744072633712920, retaddr=0x40232bde) at qemu/softmmu_template.h:78 #13 0x00005555557f50b5 in __ldl_mmu (addr=18446744072633712920, mmu_idx=0) at qemu/softmmu_template.h:114 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YilXl-0004Sf-QL for qemu-devel@nongnu.org; Thu, 16 Apr 2015 11:17:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YilXh-0007pb-NI for qemu-devel@nongnu.org; Thu, 16 Apr 2015 11:17:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YilXh-0007p9-5N for qemu-devel@nongnu.org; Thu, 16 Apr 2015 11:17:25 -0400 Message-ID: <552FD278.5040303@redhat.com> Date: Thu, 16 Apr 2015 17:17:12 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> <552E30F5.2020207@imgtec.com> <552F97FF.4000109@imgtec.com> <552FA4B9.4070204@redhat.com> <552FCF9F.4020500@imgtec.com> In-Reply-To: <552FCF9F.4020500@imgtec.com> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leon Alrae , James Hogan , vt , qemu-devel On 16/04/2015 17:05, Leon Alrae wrote: > On 16/04/2015 13:02, Paolo Bonzini wrote: >> >> >> On 16/04/2015 13:07, Leon Alrae wrote: >>> Since I also haven't had a chance to test Loongson emulation, I thought >>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine). >>> >>> Good news is that I'm able to get to the login prompt using ancient QEMU >>> v1.0, kernel 2.6.33 (with additional patch from >>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and >>> some old debian image I had handy. However, in any newer version >>> starting from v1.1.0 of QEMU something goes horribly wrong and it just >>> segfaults somewhere inside hw/bonito.c quite early during kernel >>> booting. >> >> Where exactly? If it's related to the memory API conversion, it may be >> easy to fix. I can look at a backtrace (or you can just put the Debian >> image somewhere I can grab it). > > Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093 > > Crash occurs during the first access, below there is backtrace from > working and not working case: This is my best guess... diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c index 8bdd569..8134d0b 100644 --- a/hw/pci-host/bonito.c +++ b/hw/pci-host/bonito.c @@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr, uint32_t saddr; int reset = 0; - saddr = (addr - BONITO_REGBASE) >> 2; + saddr = addr >> 2; DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr); switch (saddr) { @@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr, PCIBonitoState *s = opaque; uint32_t saddr; - saddr = (addr - BONITO_REGBASE) >> 2; + saddr = addr >> 2; DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr); switch (saddr) { Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YipQA-0006yi-5y for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:25:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YipQ5-0005PK-Rg for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:25:54 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:37348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YipQ5-0005Oj-MB for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:25:49 -0400 Message-ID: <55300CAC.20103@imgtec.com> Date: Thu, 16 Apr 2015 20:25:32 +0100 From: Leon Alrae MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> <552E30F5.2020207@imgtec.com> <552F97FF.4000109@imgtec.com> <552FA4B9.4070204@redhat.com> <552FCF9F.4020500@imgtec.com> <552FD278.5040303@redhat.com> In-Reply-To: <552FD278.5040303@redhat.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: James Hogan , qemu-devel , vt On 16/04/15 16:17, Paolo Bonzini wrote: > > > On 16/04/2015 17:05, Leon Alrae wrote: >> On 16/04/2015 13:02, Paolo Bonzini wrote: >>> >>> >>> On 16/04/2015 13:07, Leon Alrae wrote: >>>> Since I also haven't had a chance to test Loongson emulation, I thought >>>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine). >>>> >>>> Good news is that I'm able to get to the login prompt using ancient QEMU >>>> v1.0, kernel 2.6.33 (with additional patch from >>>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and >>>> some old debian image I had handy. However, in any newer version >>>> starting from v1.1.0 of QEMU something goes horribly wrong and it just >>>> segfaults somewhere inside hw/bonito.c quite early during kernel >>>> booting. >>> >>> Where exactly? If it's related to the memory API conversion, it may be >>> easy to fix. I can look at a backtrace (or you can just put the Debian >>> image somewhere I can grab it). >> >> Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093 >> >> Crash occurs during the first access, below there is backtrace from >> working and not working case: > > This is my best guess... > > diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c > index 8bdd569..8134d0b 100644 > --- a/hw/pci-host/bonito.c > +++ b/hw/pci-host/bonito.c > @@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr, > uint32_t saddr; > int reset = 0; > > - saddr = (addr - BONITO_REGBASE) >> 2; > + saddr = addr >> 2; > > DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr); > switch (saddr) { > @@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr, > PCIBonitoState *s = opaque; > uint32_t saddr; > > - saddr = (addr - BONITO_REGBASE) >> 2; > + saddr = addr >> 2; > > DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr); > switch (saddr) { > Nice. Thanks! Would you send the patch or should I do this? With this fix fulong2e machine is brought back to life. It would be great to have it in 2.3. Leon From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YipeJ-0002iu-AH for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:40:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YipeG-0001EL-4O for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:40:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YipeF-0001EE-M1 for qemu-devel@nongnu.org; Thu, 16 Apr 2015 15:40:27 -0400 Message-ID: <5530101F.4060100@redhat.com> Date: Thu, 16 Apr 2015 21:40:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <201504131929543844171@sangfor.com.cn> <552E30F5.2020207@imgtec.com> <552F97FF.4000109@imgtec.com> <552FA4B9.4070204@redhat.com> <552FCF9F.4020500@imgtec.com> <552FD278.5040303@redhat.com> <55300CAC.20103@imgtec.com> In-Reply-To: <55300CAC.20103@imgtec.com> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leon Alrae Cc: James Hogan , qemu-devel , vt On 16/04/2015 21:25, Leon Alrae wrote: > On 16/04/15 16:17, Paolo Bonzini wrote: >> >> >> On 16/04/2015 17:05, Leon Alrae wrote: >>> On 16/04/2015 13:02, Paolo Bonzini wrote: >>>> >>>> >>>> On 16/04/2015 13:07, Leon Alrae wrote: >>>>> Since I also haven't had a chance to test Loongson emulation, I thought >>>>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine). >>>>> >>>>> Good news is that I'm able to get to the login prompt using ancient QEMU >>>>> v1.0, kernel 2.6.33 (with additional patch from >>>>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and >>>>> some old debian image I had handy. However, in any newer version >>>>> starting from v1.1.0 of QEMU something goes horribly wrong and it just >>>>> segfaults somewhere inside hw/bonito.c quite early during kernel >>>>> booting. >>>> >>>> Where exactly? If it's related to the memory API conversion, it may be >>>> easy to fix. I can look at a backtrace (or you can just put the Debian >>>> image somewhere I can grab it). >>> >>> Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093 >>> >>> Crash occurs during the first access, below there is backtrace from >>> working and not working case: >> >> This is my best guess... >> >> diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c >> index 8bdd569..8134d0b 100644 >> --- a/hw/pci-host/bonito.c >> +++ b/hw/pci-host/bonito.c >> @@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr, >> uint32_t saddr; >> int reset = 0; >> >> - saddr = (addr - BONITO_REGBASE) >> 2; >> + saddr = addr >> 2; >> >> DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr); >> switch (saddr) { >> @@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr, >> PCIBonitoState *s = opaque; >> uint32_t saddr; >> >> - saddr = (addr - BONITO_REGBASE) >> 2; >> + saddr = addr >> 2; >> >> DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr); >> switch (saddr) { >> > > Nice. Thanks! > > Would you send the patch or should I do this? With this fix fulong2e > machine is brought back to life. It would be great to have it in 2.3. You can send a pull request directly (add my Signed-off-by and Cc: qemu-stable@nongnu.org, please), but it is possible Peter will tell you to wait for 2.3.1. It's been broken for a few years already. :) Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yirpt-0007Em-C9 for qemu-devel@nongnu.org; Thu, 16 Apr 2015 18:00:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yirpp-0007ll-2u for qemu-devel@nongnu.org; Thu, 16 Apr 2015 18:00:37 -0400 Received: from mail-ie0-f170.google.com ([209.85.223.170]:32876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yirpo-0007ld-VB for qemu-devel@nongnu.org; Thu, 16 Apr 2015 18:00:33 -0400 Received: by iecrt8 with SMTP id rt8so49878938iec.0 for ; Thu, 16 Apr 2015 15:00:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <552FD278.5040303@redhat.com> References: <201504131929543844171@sangfor.com.cn> <552E30F5.2020207@imgtec.com> <552F97FF.4000109@imgtec.com> <552FA4B9.4070204@redhat.com> <552FCF9F.4020500@imgtec.com> <552FD278.5040303@redhat.com> From: Peter Maydell Date: Thu, 16 Apr 2015 23:00:12 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [Question]Support of China loogson processor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: James Hogan , Leon Alrae , qemu-devel , vt On 16 April 2015 at 16:17, Paolo Bonzini wrote: > > > On 16/04/2015 17:05, Leon Alrae wrote: >> On 16/04/2015 13:02, Paolo Bonzini wrote: >>> >>> >>> On 16/04/2015 13:07, Leon Alrae wrote: >>>> Since I also haven't had a chance to test Loongson emulation, I thought >>>> I'd give it a try (TCG only, Loongson-2E cpu and fulong2e machine). >>>> >>>> Good news is that I'm able to get to the login prompt using ancient QEMU >>>> v1.0, kernel 2.6.33 (with additional patch from >>>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02566.html) and >>>> some old debian image I had handy. However, in any newer version >>>> starting from v1.1.0 of QEMU something goes horribly wrong and it just >>>> segfaults somewhere inside hw/bonito.c quite early during kernel >>>> booting. >>> >>> Where exactly? If it's related to the memory API conversion, it may be >>> easy to fix. I can look at a backtrace (or you can just put the Debian >>> image somewhere I can grab it). >> >> Bisect points at: 5312bd8b3152f8d4fcf9389ba54e32b09f4b4093 >> >> Crash occurs during the first access, below there is backtrace from >> working and not working case: > > This is my best guess... > > diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c > index 8bdd569..8134d0b 100644 > --- a/hw/pci-host/bonito.c > +++ b/hw/pci-host/bonito.c > @@ -233,7 +233,7 @@ static void bonito_writel(void *opaque, hwaddr addr, > uint32_t saddr; > int reset = 0; > > - saddr = (addr - BONITO_REGBASE) >> 2; > + saddr = addr >> 2; > > DPRINTF("bonito_writel "TARGET_FMT_plx" val %x saddr %x\n", addr, val, saddr); > switch (saddr) { > @@ -295,7 +295,7 @@ static uint64_t bonito_readl(void *opaque, hwaddr addr, > PCIBonitoState *s = opaque; > uint32_t saddr; > > - saddr = (addr - BONITO_REGBASE) >> 2; > + saddr = addr >> 2; > > DPRINTF("bonito_readl "TARGET_FMT_plx"\n", addr); > switch (saddr) { Wow, I thought we'd fixed all those "non-page-aligned mmio region broke when the memory core was fixed to actual pass the correct address to it" bugs years ago. I wonder if there's a way to find out if we have any more (coccinelle search pattern?) Incidentally, this device will happily let the guest overwrite arbitrary chunks of its state struct via bonito_cop_writel and bonito_ldma_writel, so I hope nobody runs untrusted guests on this model :-) (Its realize function maps its own MMIO regions into system memory, too, which is a huge style error these days.) -- PMM