From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (NAM12-MW2-obe.outbound.protection.outlook.com [40.107.244.61]) by mx.groups.io with SMTP id smtpd.web10.33604.1591004928175818665 for ; Mon, 01 Jun 2020 02:48:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=CxUIXoiM; spf=pass (domain: vmware.com, ip: 40.107.244.61, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JnaHfaBz+SPLhPbldlP32zKTYWU5t2vBMo8sGfvwqaXMC7i/oKakENUul61Trap2tDO0epelOUe891zurthJewwRJoVbBA4/ibIvKm093IZ+Z2aLH/vjArbGmHYjewxCKsVTN4/fqFuW6JAarFwpW1WejSBXObTTfh06aEeKg9CD8mTzlCNVT6JYyPNkGogOnn6dkH7MlmOad+crMcZ0FGb+vlA4HCT7yrHDleX7xbNt3TGlxq35PNfmIhEwnd6L3WQTmk0v/weUN1fGlTTd12GaemG3fnBKMSxSD8gmSvW8n5vqHwLHdEMVgmAMzfEzkv2MzWrexjVvP/IdYfc+Hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JP+gHmTQYPYYQrDHG6OCDqU88tESCWaogM4WzvhQMoQ=; b=TkvPE11JmdeSYIcE5Mos1PnMyfEjII7j+sV7pD2UYPR39OK+zxRh+qCPkz3ZNvVxb1w5VoLI9C8/5Z5ZGd7Q43hMueHjHSNKzI4izkT68Abx0ttp6j+IeZFgkmUq1nwVfisv2+WqxMEOLySm+zCfkmJicohckHDfkaDBXBdImu8wEn/dDm/EMO2n14Y5G/wuCNiCbE1gfN0Qg/LarWEgPoWvzKgG/2hmqMs1Z52dQ8OJab16vGD3LCPFQZR0TqYXKLrwBtvS7rSpX0fiMd9Ug1VVGwi3pt8WeQla/hL5RiycLRC+O8ZSyhipnB8w+19SE6fJF7R09i51OwkSGOos5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JP+gHmTQYPYYQrDHG6OCDqU88tESCWaogM4WzvhQMoQ=; b=CxUIXoiMTmpg3X1No/VKbdTwk4smma0iGa1LtWuf+WYR4JjHvrBdDJ9hhBGMmGi6ahaMGBPKfI23SCRHiACP5sA7nJOMO9lptXETPichnlsy51Tc3p6gTzti7M8Fx6mxA4Q1RaMI+LRYkfuk6HQNvRjPBbIm1myih25bCTv5Wek= Received: from BN6PR05MB3411.namprd05.prod.outlook.com (2603:10b6:405:43::23) by BN6PR05MB2852.namprd05.prod.outlook.com (2603:10b6:404:30::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.7; Mon, 1 Jun 2020 09:48:45 +0000 Received: from BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::e1ef:31eb:c802:aef0]) by BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::e1ef:31eb:c802:aef0%3]) with mapi id 15.20.3066.007; Mon, 1 Jun 2020 09:48:45 +0000 From: "Andrei Warkentin" To: Ard Biesheuvel , Andrei Warkentin , "devel@edk2.groups.io" CC: "leif@nuviainc.com" , "pete@akeo.ie" , "philmd@redhat.com" Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Pi4: notify VPU to load xHCI firmware before XhciDxe binds Thread-Topic: [edk2-devel] [edk2-platforms][PATCH 1/1] Pi4: notify VPU to load xHCI firmware before XhciDxe binds Thread-Index: AQHWN8PGcDRborSj20GhI8UKAP4qe6jDVPiAgAAquV2AAAMlgIAAAHkg Date: Mon, 1 Jun 2020 09:48:45 +0000 Message-ID: References: <20200601032130.95634-1-andrey.warkentin@gmail.com> <3121e7a6-afb7-038e-4fcd-5a317d3194e9@arm.com> ,<33ce3c90-7675-19aa-c659-6f5d4d51c368@arm.com> In-Reply-To: <33ce3c90-7675-19aa-c659-6f5d4d51c368@arm.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [98.214.99.181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d51d78d0-f6b3-4aca-ba32-08d80610f9c4 x-ms-traffictypediagnostic: BN6PR05MB2852: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8B2GVijlmd7lBoERilcq2ru0Tds2w1UYF+7OFVdkm/pQGi9NvWDEG4eGD1GYWE42amf1mXNk3k2E9MnVTS2S2Wo4fv/PBg8/0Hd5joJ5/ybbNr8gdKPrRbgVBwZisPaMUSAp0YamizsM4jy4OYaCm+BG02fxZAkFNDWKq1ooHQJr3lMYeEJ7P6iaznFb0qimGF5fWeswg50mBGSbip5Xhh9qrZJJqVRjNsBh2nKWDIDjJEIz85+akMIGaPwXy3F/L0fP6b6lUOQgwtt5mYQ3JYRtTCOaUoHE3QA9R6lGsf0EvXY6s00gClm1U7Hezauj x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN6PR05MB3411.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(4636009)(376002)(39860400002)(396003)(346002)(366004)(136003)(7696005)(186003)(2906002)(33656002)(26005)(54906003)(316002)(8676002)(110136005)(478600001)(83380400001)(8936002)(52536014)(86362001)(71200400001)(9686003)(4326008)(76116006)(5660300002)(19627405001)(53546011)(66446008)(6506007)(64756008)(55016002)(66946007)(66556008)(66476007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata: at8tiErJkgjDjRb1E1Aq8uJnkhdhrPorK6HS1yZNrZ6OjMJbhh+u2auk2PGrgqL2T8sTUL0MMLtR6/MxXaNi87HHB2SQ8sUxRFGFnihKRcI1UlDWDxeXpKxmP9JJQHAL2mm3LCyj1kbaO91znTMOxyeBM6lPruvD43y7Cqd7mhz9WNugP7Bgj+QonIXCGYv+ZM3femEv4mdtZyW6q1cvEKGk+AMh/q3KTQh8btZpinXy8oKecWXCFkbWq7jpz+PNCWRLB9wdMe73q7oxM3rRl9EqsDCg1oGUOiOQ766s+4+Sl95POKE+aWej/ixspUEDM9VLzNh+T425fU5E+LtOJE/PT1uOt57Ck9oeiHWOVDdaTsyB8trrwMYou/B1nBSt/7MBaFnMKF0WwbzMG2Nthni71Zf94stgTdRjOngPiKt86mLEc80cwOmwNTWDuT4i7J/wikkXoPqpSOHZYXcM8inxF9ao6BGztkV6bAtJOnQ= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: d51d78d0-f6b3-4aca-ba32-08d80610f9c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 09:48:45.2298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EFACB1+v47+mcZCCuoRhtft3+Pniw85XFiUPjCbAWPCubbFnCE7If0ZXlx9K9HcX9H+qIHKPharH048FmUv4yw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2852 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR05MB341119B451440CE8A906A119B98A0BN6PR05MB3411namp_" --_000_BN6PR05MB341119B451440CE8A906A119B98A0BN6PR05MB3411namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the time when the device handle with PciIo is published? Presumably = only via the event callbacks (thus no). I see a similar approach done in Ar= mJunoDxe to populate MAC address into the PCI device. I'm up for the RpiFirmwareDxe cleanup (as fas as moving to a model where th= e TPL is raised instead of using spinlock), but could that be done separate= ly to this change? A ________________________________ From: Ard Biesheuvel Sent: Monday, June 1, 2020 4:44 AM To: Andrei Warkentin ; Andrei Warkentin ; devel@edk2.groups.io Cc: leif@nuviainc.com ; pete@akeo.ie ; phi= lmd@redhat.com Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Pi4: notify VPU to lo= ad xHCI firmware before XhciDxe binds On 6/1/20 11:37 AM, Andrei Warkentin wrote: > Hi Ard, > > The xHCI controller is initialized with its microcode by the VPU > firmware, if > I understood correctly, synchronously. When RPI_MBOX_NOTIFY_XHCI_RESET > finishes, the XHCI controller is ready to go. > I suppose there are no other agents that may consume the config space during this time, right? > So this is not any more unsafe than any of the other mailbox calls. To > be honest, I think RpiFirmwareDxe should be cleaned up to replace the > useless spinlocks (there's no multiprocessing component) with a TPL > manip (I checked SynchonizationLib and it doesn't touch the TPL) > The spinlock protects from re-entrancy: if an event callback routine (such as the one you are adding for PCI I/O protocol registration) attempts to do a firmware call while one is already in progress, it will fail. But perhaps it is indeed better to run at TPL_NOTIFY level - that way, the calls will be ordered one after the other instead of one being shot down. > Applying your other feedback now... > > A > ------------------------------------------------------------------------ > *From:* devel@edk2.groups.io on behalf of Ard > Biesheuvel via groups.io > >> + >> + Status =3D MailboxTransaction (Cmd->BufferHead.BufferSize, RPI_MBOX_V= C_CHANNEL, &Result); >> + > > So this pokes the XHCI controller via its config space? Is it safe to do > that without raising the TPL? What happens if another config space > access occurs concurrently? > > A --_000_BN6PR05MB341119B451440CE8A906A119B98A0BN6PR05MB3411namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
During the time when the device handle with PciIo is published? Presumably = only via the event callbacks (thus no). I see a similar approach done in Ar= mJunoDxe to populate MAC address into the PCI device.

I'm up for the RpiFirmwareDxe cleanup (as fas as moving to a model where th= e TPL is raised instead of using spinlock), but could that be done separate= ly to this change?

A
From: Ard Biesheuvel <ar= d.biesheuvel@arm.com>
Sent: Monday, June 1, 2020 4:44 AM
To: Andrei Warkentin <awarkentin@vmware.com>; Andrei Warkentin= <andrey.warkentin@gmail.com>; devel@edk2.groups.io <devel@edk2.gr= oups.io>
Cc: leif@nuviainc.com <leif@nuviainc.com>; pete@akeo.ie <pe= te@akeo.ie>; philmd@redhat.com <philmd@redhat.com>
Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Pi4: notify VP= U to load xHCI firmware before XhciDxe binds
 
On 6/1/20 11:37 AM, Andrei Warkentin wrote:
> Hi Ard,
>
> The xHCI controller is initialized with its microcode by the VPU
> firmware, if
> I understood correctly, synchronously. When RPI_MBOX_NOTIFY_XHCI_= RESET
> finishes, the XHCI controller is ready to go.
>

I suppose there are no other agents that may consume the config space
during this time, right?

> So this is not any more unsafe than any of the other mailbox calls. To=
> be honest, I think RpiFirmwareDxe should be cleaned up to replace the =
> useless spinlocks (there's no multiprocessing component) with a TPL > manip (I checked SynchonizationLib and it doesn't touch the TPL)
>

The spinlock protects from re-entrancy: if an event callback routine
(such as the one you are adding for PCI I/O protocol registration)
attempts to do a firmware call while one is already in progress, it will fail.

But perhaps it is indeed better to run at TPL_NOTIFY level - that way,
the calls will be ordered one after the other instead of one being shot down.


> Applying your other feedback now...
>
> A
> ----------------------------------------------------------------------= --
> *From:* devel@edk2.groups.io <devel@edk2.groups.io> on behalf of= Ard
> Biesheuvel via groups.io <ard.biesheuvel=3Darm.com@groups.io> >
>> +
>> +  Status =3D MailboxTransaction (Cmd->BufferHead.Buff= erSize, RPI_MBOX_VC_CHANNEL, &Result);
>> +
>
> So this pokes the XHCI controller via its config space? Is it safe to = do
> that without raising the TPL? What happens if another config space
> access occurs concurrently?
>
> A

--_000_BN6PR05MB341119B451440CE8A906A119B98A0BN6PR05MB3411namp_--