From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:53820)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1SulaK-0007IS-C1
	for qemu-devel@nongnu.org; Fri, 27 Jul 2012 10:32:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1SulaE-00036t-Jx
	for qemu-devel@nongnu.org; Fri, 27 Jul 2012 10:32:08 -0400
Received: from mail-pb0-f45.google.com ([209.85.160.45]:46264)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1SulaE-00036k-Dg
	for qemu-devel@nongnu.org; Fri, 27 Jul 2012 10:32:02 -0400
Received: by pbbro12 with SMTP id ro12so4938477pbb.4
	for <qemu-devel@nongnu.org>; Fri, 27 Jul 2012 07:32:01 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <50129B8A.3060102@landley.net>
References: <50129B8A.3060102@landley.net>
Date: Fri, 27 Jul 2012 15:32:01 +0100
Message-ID: <CAFEAcA_qgzOjTRDeaaWxT+_hYu_iqRR6fY9ssMOm_qD6W7ZJXA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH] Fixing sh4 serial abort
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Rob Landley <rob@landley.net>
Cc: aboriginal@lists.landley.net, qemu-devel <qemu-devel@nongnu.org>

On 27 July 2012 14:45, Rob Landley <rob@landley.net> wrote:
> I.E. sci_getreg(port, SCFCR) move to before checking whether or not
> we'll ever possibly use the result. SCFCR is 0x18 and QEMU calls abort()
> on an attempt to read from an unimplemented register.
>
> I can patch the kernel to work around this (and probably will for this
> release), but the _proper_ fix is to get qemu not to abort on a register
> read that works fine if it just returns 0.

The thing this analysis is missing is any examination of the question
"what is the hardware we are modelling documented to do?". If the hardware
is documented to have a readable register here, QEMU should be fixed.
If it is not then the kernel is buggy and should be fixed.

As it happens, the "SH7214 Group, SH7216 Group User=E2=80=99s Manual: Hardw=
are"
(which I think is the right doc for this) says the register is r/w,
so I think your suggested patch is correct.

(Aborting is a little unfriendly but our logging infrastructure
for "guest did something wrong" is not great, unfortunately.)

There are an awful lot of "#if 0"s in that source file...

-- PMM