Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Michael Kelley <mikelley@microsoft.com>
To:     "Andrea Parri (Microsoft)" <parri.andrea@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC:     KY Srinivasan <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        Dexuan Cui <decui@microsoft.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        vkuznets <vkuznets@redhat.com>
Subject: RE: [PATCH 03/11] Drivers: hv: vmbus: Replace the per-CPU channel
 lists with a global array of channels
Thread-Topic: [PATCH 03/11] Drivers: hv: vmbus: Replace the per-CPU channel
 lists with a global array of channels
Thread-Index: AQHWC6iqE6sDRgLYPEmmKtjFGljjoqhyo0CA
Date:   Fri, 10 Apr 2020 17:29:43 +0000
Message-ID: <MW2PR2101MB10524E75CD610DFB4EBEF091D7DE0@MW2PR2101MB1052.namprd21.prod.outlook.com>
References: <20200406001514.19876-1-parri.andrea@gmail.com>
 <20200406001514.19876-4-parri.andrea@gmail.com>
In-Reply-To: <20200406001514.19876-4-parri.andrea@gmail.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mikelley@ntdev.microsoft.com;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-10T17:29:41.1776214Z;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure
 Information Protection;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7933173e-a323-488d-ba6c-e9f3f7cf2aef;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=mikelley@microsoft.com; 
x-originating-ip: [24.22.167.197]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8f8e10d3-a43d-4857-6760-08d7dd74c1c9
x-ms-traffictypediagnostic: MW2PR2101MB1050:|MW2PR2101MB1050:|MW2PR2101MB1050:
x-ms-exchange-transport-forked: True
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <MW2PR2101MB10504BE2BCB44CAED4E5CB33D7DE0@MW2PR2101MB1050.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0369E8196C
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW2PR2101MB1052.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(10019020)(4636009)(346002)(366004)(136003)(376002)(39860400002)(396003)(478600001)(55016002)(86362001)(7696005)(82950400001)(4326008)(8676002)(5660300002)(9686003)(64756008)(316002)(8936002)(81156014)(82960400001)(110136005)(186003)(2906002)(71200400001)(10290500003)(66476007)(66946007)(33656002)(66556008)(54906003)(76116006)(66446008)(52536014)(26005)(8990500004)(6506007)(966005);DIR:OUT;SFP:1102;
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bG6UkR94SqUSagu/myeufarLuShGth9li4wAsHp5ZiDVTCpyco8puNW/1SfU3OPJjhrAfjMDNvMalmT8YEjCDrDYXjBtFWYPgkpVWCP89tg5PxJ0uOg4rN8g6eqbPxQNUwWboeTdLArzoVu5hbDIIdMzSMvN7O2kPjM/aKo1pSF2n46pHdqThKb1c7tl2VjuJNiu+agQ6NJo5DsyvfhZnBRyQY+pQzDd0WqWquu0woWWbXSeww0wU59r8+JvKGE+N4MuChq+uQCcoqjxn+UWIdvvVerU3UNQ6keeMEceof4YK+XTacFRp37Cj0VdJtxRO2uxphyerCEQuOg7Hr1sGX5kJ/9ALNKEqRbL+/fMkbdGnIyol4htaDGW1MSfGFlBiwDibsy7CKTfjyHOp0LviPnjjRyjDoJuHZhzIhrpQnhSwvac94zu/5q92Lac9lPhrXDM5J0yeJq4HQN9tb2jIJV8tlm8cp3ljIRLA+yvqaHbo4Fq/G7NDUgdZ/mWG2zK6qWXoTvnvFvUQWc+fuUf2g==
x-ms-exchange-antispam-messagedata: J1PypgPHAORIuhYVvNXB9IpvH4ILWm0/uUCLpHPCZfTc6j+Zz9JMwxJZbOQq+nkhXdOoZ818ziI3jpraTd+noOxmhlY6TSpP6EgjGLDCeci+sDiUG9U6mvnm5r+wjT2fGsgir3McQ10b/r8UL+KwCg==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f8e10d3-a43d-4857-6760-08d7dd74c1c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2020 17:29:43.2181
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: T6Qq31Ub+GJK4TvLxEsE2EjiJZsXo0Z5Oj0eI/B4HZId8x2xM+/QG3XeKWnkIv/FrbtB2kS/2oEgjvSdp9sLANlP7OjhZM05Sz7AQOV7HKM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1050
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Sent: Sunday, April=
 5, 2020 5:15 PM
>=20
> When Hyper-V sends an interrupt to the guest, the guest has to figure
> out which channel the interrupt is associated with.  Hyper-V sets a bit
> in a memory page that is shared with the guest, indicating a particular
> "relid" that the interrupt is associated with.  The current Linux code
> then uses a set of per-CPU linked lists to map a given "relid" to a
> pointer to a channel structure.
>=20
> This design introduces a synchronization problem if the CPU that Hyper-V
> will interrupt for a certain channel is changed.  If the interrupt comes
> on the "old CPU" and the channel was already moved to the per-CPU list
> of the "new CPU", then the relid -> channel mapping will fail and the
> interrupt is dropped.  Similarly, if the interrupt comes on the new CPU
> but the channel was not moved to the per-CPU list of the new CPU, then
> the mapping will fail and the interrupt is dropped.
>=20
> Relids are integers ranging from 0 to 2047.  The mapping from relids to
> channel structures can be done by setting up an array with 2048 entries,
> each entry being a pointer to a channel structure (hence total size ~16K
> bytes, which is not a problem).  The array is global, so there are no
> per-CPU linked lists to update.  The array can be searched and updated
> by loading from/storing to the array at the specified index.  With no
> per-CPU data structures, the above mentioned synchronization problem is
> avoided and the relid2channel() function gets simpler.
>=20
> Suggested-by: Michael Kelley <mikelley@microsoft.com>
> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
> ---
> NOTE.  The inline comment in vmbus_channel_map_relid() follows the argume=
nt
> discussed in the RFC [1].  An attempt has been made to make this argument
> more 'explicit' (and, hopefully, more 'robust' against future changes) by
> adding a full memory barrier in vmbus_channel_map_relid(): the barrier ta=
kes
> the role of the 'implicit' full memory barriers from queue_work() and fro=
m
> check_ready_for_resume_event() referred to in the RFC.
>=20
> [1] https://lore.kernel.org/linux-hyperv/20200403133826.GA25401@andrea/
>=20
>  drivers/hv/channel_mgmt.c | 179 ++++++++++++++++++++++++--------------
>  drivers/hv/connection.c   |  38 +++-----
>  drivers/hv/hv.c           |   2 -
>  drivers/hv/hyperv_vmbus.h |  14 +--
>  drivers/hv/vmbus_drv.c    |  48 ++++++----
>  include/linux/hyperv.h    |   5 --
>  6 files changed, 160 insertions(+), 126 deletions(-)
>=20

Reviewed-by: Michael Kelley <mikelley@microsoft.com>