From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 23 16:32:26 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35685C47 for ; Sun, 23 Mar 2014 16:32:26 +0000 (UTC) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E832FBA2 for ; Sun, 23 Mar 2014 16:32:25 +0000 (UTC) Received: by mail-yk0-f169.google.com with SMTP id 142so12046069ykq.0 for ; Sun, 23 Mar 2014 09:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=ffkJ8ItGkVv7lUlswzoALL6N0RyXXDiuvhJTnL0arT0=; b=rS7Iw2Ss2etBPGWm6HUHTCm4zxceIrgPW8B95GeknJhtH+AT6wSE5/Jhp4+MvCKUJU mxClWXgsO7IYhRtKIuriFQDZT5m8whJzJlh1lKmNzWCGOqpTWyY4a6DkSTmTI5wZHDMB zrBBXsnTALEA2UkuvTVQpAAY597O3K1bbCLRyh/rVhdOwbzQKki1Wyv1MGaoWH/DTnQY 4PLask3mPujSDMZ3EBS5k2rzd76Qa/6v/71CXXGjcpG1SRGTLQ2QtGQp9YUdAVnY3k4g 42E6vpM40bAlgvDoW/EsN0CypwU/qHT9ubSSFcyO0HjRBO+MoWd57EBmcPQozEPt9MC4 QCxg== X-Received: by 10.236.130.178 with SMTP id k38mr528622yhi.132.1395592345177; Sun, 23 Mar 2014 09:32:25 -0700 (PDT) Received: from zhabar.att.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id e5sm19018010yhj.14.2014.03.23.09.32.23 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 23 Mar 2014 09:32:23 -0700 (PDT) Date: Sun, 23 Mar 2014 09:32:04 -0700 From: Justin Hibbits To: Konstantin Belousov Subject: Re: set_mcontext()/grab_mcontext() Message-ID: <20140323093204.203a4a48@zhabar.att.net> In-Reply-To: <20140323160046.GU21331@kib.kiev.ua> References: <20140319221325.13f4b7c2@zhabar.att.net> <20140323160046.GU21331@kib.kiev.ua> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/5Am3ReSmCSUN2T7atzeQP3V"; protocol="application/pgp-signature" Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 16:32:26 -0000 --Sig_/5Am3ReSmCSUN2T7atzeQP3V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 23 Mar 2014 18:00:46 +0200 Konstantin Belousov wrote: > On Wed, Mar 19, 2014 at 10:13:25PM -0700, Justin Hibbits wrote: > > Running into problems with X exiting during a sigreturn(2) on my G4 > > PowerBooks, it seems sometimes bit 10 is set in the mc_srr1 field, > > which, from the documentation, can only be set by hardware on an > > external interrupt. > >=20 > > Looking at the references closer, bits 1-4, 10-15 (ppc32), also > > numbered as bits 33-36, 42-47 (ppc64) are for exception-specific > > information only. I'm wondering if it makes sense to mask these off > > when setting and getting the context, as those bits are useless > > upon an rfi. > >=20 > > I know this is probably simply a band-aid for possible corruption > > in X, but to me it makes sense, as the context data is useful only > > when entering the interrupt context, not when context is restored > > (bits are localized, not restored to MSR). >=20 > Late reply, I saw that you already committed r263464. >=20 > Traditionally, the sigreturn(2)/setcontext(2) are strict, in > particular, on FreeBSD. E.g., on i386/amd64 any reserved bit in > %{e.r}flags, which is closest analog of PPC msr, or even a reserved > flag in the software-defined mc_flags field, cause EINVAL. Due to the > construction of the signal trampoline code, return from sigreturn(2) > without applying passed context causes trap. >=20 > I think it is useful to keep this behaviour consistent between > architectures. I understand, and agree. The difference, however, is that on AIM architecture (Book-E does it differently) the bits I listed above are only in srr1. They're not propogated back to the MSR. They're not even marked as reserved in the MSR, because some of them overlap (bit 12(ppc32) is the POW bit in MSR, but anything in srr1, for example). After discussing with Nathan, we decided that masking these bits is appropriate. In your opinion, would a more appropriate route be to mask these bits out in grab_mcontext() instead, and keep the formerly strict checking in set_mcontext()? As I mentioned before, those bits are checked only on entry to the trap, to decide how to handle the trap. Once that's done, they're completely useless in srr1, and srr1 (ergo, tf->srr1) gets overwritten on every exception. - Justin --Sig_/5Am3ReSmCSUN2T7atzeQP3V Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTLwyRAAoJEDDHhY43vi25wZkIAMmCfZrh6V2yjcQs3BQetkbN Nw4WSwYH5gQfju6I4lq0IMYrs80sffmlbqp96YbfuvY8wFsK1vxK29osgi74iGAw 3fQyOvyocqeah7V2Jv6kD5vdOmJ6rJ+nfLNgPGBwOdq72oc4OBtpCbMzYAKo998f /Gh5n1D+hyTeP6St0asa+XWo1ULT7SXkuZqumUv06YtDo0GpB1c0FsQFfBhIkOUL C5w6AgC6TBtYB0pYzJvrYgp/h/EXWi2Dmg/14mEFzPZU0E4noYs9U3wM0r7bPP01 k/TSp4yum8LhEKW/JkF979ZHVGyGrvuDZc1W+VkExs0joDdzeSP5vKXAkQJsxpw= =ngnU -----END PGP SIGNATURE----- --Sig_/5Am3ReSmCSUN2T7atzeQP3V--