From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::71f]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6DDB61A1DF8 for ; Wed, 10 Aug 2016 14:06:40 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0292.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 10 Aug 2016 21:06:36 +0000 Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) with mapi id 15.01.0549.025; Wed, 10 Aug 2016 21:06:36 +0000 From: "Cohen, Eugene" To: Evan Lloyd , Ard Biesheuvel , Heyi Guo CC: Alexei Fedorov , "edk2-devel@lists.01.org" , "Andrew Fish (afish@apple.com)" , Leif Lindholm Thread-Topic: [edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt Thread-Index: AQHR77wChUqQlDPPikqPhQBsdmEhTaA+3v8AgAAB14CAAAJkAIAAAQKAgAAA+4CAAABHgIAAAjIAgAAAjACAAAIqAIAAAHqAgAAMAwCAABT+UIAACgwAgAACYYCAA2QngIAAE5UggAAcwACAAAc44A== Date: Wed, 10 Aug 2016 21:06:36 +0000 Message-ID: References: <20160805165911.14744-1-evan.lloyd@arm.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eugene@hp.com; x-originating-ip: [15.65.254.4] x-ms-office365-filtering-correlation-id: e6c5145b-2862-4bb3-ac25-08d3c1623766 x-microsoft-exchange-diagnostics: 1; AT5PR84MB0292; 6:3EyEzIJbREVmrtq7NcefDPm4QTfmUfNuydRIIBKoovqNRp1W1VzAvSxQ23HptWAKkDSUCe9R2FMeV/TN9afyKK7E2R8HLFxzQ3IQ6uinVUdbxMB48c/6rtxKE+6Mkw91bWn8IT0bFDu4Tw/3B+hWlSxFCdLtCpOwIHjsL1MKjCuG/9cHcqWLd7TzWkg1/H3v8WjWhxKxOW5FsvWYzKXH+evchbA3CqOA876ofjkfpYKGgD5IUmr7q3FOOPYtCLjcLGLRjOd1GTClSddIj7XWiNUCWfO72xpKqajAA1sQKDc=; 5:QRsVWDMFuNNZ3dxvZYHXmFA4+hlg4MYkivnyqXV2WPIcGQb5zWwwpNdoTS16MkGtOSvMiQzfmdR4Zx3yhxkOd34ukcmTBFUJ9RiLvrJG62wYNs/ddexcXj9EZah3FjN5NGCUY2bM10L02RZmGXrCcQ==; 24:U4i+J78UiJKqOaWX1+xQsLoebOFy+kTKM4BRDhF/cbo+vP5Id990txZcBE9XrVh2SeOQBggwkTWhl+oKqboJPoeskOfu7EH14VgrDgaDuCI=; 7:23hyfIhdyjPeCT9ulYOZYwUdbclg96npAtoXM5foff5QRfYsLu669NiVrM0NEhwJ+6RnMgGad00o+lo8QIMmB+QJ1/Y/adIOuIgSLPCiYJpQoPZ+PiULNpoDonxB/4RLn04H6CqgkcL2O7bWA20PCT1FM4qDfxiBiNneceE1dyDlsbUBY9NV89kjJVyOAMbrMtzWzU1utuwD7XCsId8Cgc+AisG+VePD/QrJJHXrxw583xuAnDQ4R+vV7OEJx9xi x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AT5PR84MB0292; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0292; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(6602003)(54356999)(76176999)(50986999)(86362001)(33656002)(106356001)(101416001)(106116001)(99286002)(10400500002)(87936001)(3280700002)(4326007)(8676002)(7736002)(5002640100001)(92566002)(66066001)(586003)(102836003)(6116002)(8936002)(74316002)(7846002)(81156014)(7696003)(81166006)(77096005)(305945005)(68736007)(3846002)(3660700001)(2906002)(105586002)(11100500001)(9686002)(97736004)(5001770100001)(2900100001)(122556002)(2950100001)(93886004)(189998001)(8666005)(7059030)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0292; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2016 21:06:36.8221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0292 Subject: Re: [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 21:06:40 -0000 Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > My description was not very clear, and the point is academic if you are > happy with the solution. I think it's important that we're aligned on how the GIC works so thanks fo= r humoring me. > However: > The GIC spec has a state machine diagram (Figure 4.3), where: > Transition D, pending to active and pending > This transition occurs on acknowledgement of the interrupt by the PE > for level-sensitive SPIs, SGIs, > and PPIs. > Transition B1 or B2, remove pending state > This transition occurs when the interrupt has been deasserted by the > peripheral, if the interrupt is a > level-sensitive interrupt, or when software has changed the pending > state. > Transition E1 or E2, remove active state > This transition occurs when software deactivates an interrupt for SPIs, > SGIs, and PPIs. >=20 > I suspect that because we EOI ("deactivate" for E1/E2) without > "deasserting" the peripheral interrupt then the GIC may restore the > pending state (transition E2 instead of B2 then E1), which will look > remarkably like a latch. But no latching will occur because, for a level sensitive interrupt, the EO= I-before deassert should manifest as transition E2 (caused by EOI) followed= by transition B1 (caused by clearing the source). This is per the text th= at transition B1 occurs if "the level-sensitive interrupt is pending only b= ecause of the assertion of an input signal, and that signal is deasserted".= So the transition is Active+Pending -> Pending -> Inactive for this odd o= rdering versus the more sensible Active+Pending -> Active -> Inactive. > That looks like a pretty sensible way forward. I'll vote for EFI_SUCCESS= , > white lies are sometimes needed. Okay, what's the worst that can happen? :) Perhaps the real test would be that a driver that uses HwInterrupt is shown= to work equally well on a fake-EOI interface system as well as a real-EOI = interface system. I doubt if we have any common peripherals (timer block o= r serial port or whatever) to really test this. Eugene