[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 4/6] libxc: use multicall for memory-op on Linux (and Solaris)


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 22 Jun 2021 20:35:18 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • 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=UxgAPpj3Bju409mglp5pUiFnbpcpj17y4j6EuXBk8ZY=; b=JTRc/y6qnzTZ6p/KRfxXVYot6UQ9VjuwPpM06/zXjfz5e2w/bhCGp8+nNdQYyke3l4uXLMJTwuGiIWjYns1h02VcmBSt1+6wmz2O26QxRJ0XjbTRcUFIum1YJ+fuHXgdhd/09HyaV5lsNkpNuas/9e8LIhFcexdoH2GpFvZzcvXvlWLH3uAl8fRQRT7ZwIdxuZij/0bxZWET8VVn7pqBCQjSMpRJYa5c9MQhQWFkxUzJzgEKZL+0DVG4ReHSywQmpynHV9/2C32EuepKSWPUB9om0KJsdluIUNoUK7fk+zZKplBAjCMD4eRzAeow7FLdLVk+jc0lGffJn4VAnPC9GQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VRuDmQGGiwolNgS1tvThDaMYzM4IFz/J4uhkRR1tgfJ962O4FDnQH3LYww7PPh/R9tCxK2MYRuyUycqMEnWHm91ZL9HHaCnL4ZYZMHRZ6XxGl3RfguOGUjCml025ua4vzGK9BsWj9jxAeqnrJGU1tbPK/7oxVSdJQl4zabZArwadof+rp3g3Ri+ZuI+ER84LffIqzvXolKyCReePbyAWFmGRBtSlLp6e0Ccd54g1DliN9hEsCpCFOHP5PwyxafgaB6mbvQbm4Ut6GjjG8RtdxRie/txotOXwCh+WhvbPqqCTWNm9DbS/oXpYMzyuesngfIIzmVj15GRgjNp6mbP7iA==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>
  • Delivery-date: Tue, 22 Jun 2021 19:35:44 +0000
  • Ironport-hdrordr: A9a23:LpnRLqiY9iI54JcxnInN8GdxRXBQXh4ji2hC6mlwRA09TyX5ra 2TdZUgpHrJYVMqMk3I9uruBEDtex3hHP1OkOss1NWZPDUO0VHARO1fBOPZqAEIcBeOldK1u5 0AT0B/YueAd2STj6zBkXSF+wBL+qj6zEiq792usEuEVWtRGsVdB58SMHfiLqVxLjM2YqYRJd 6nyedsgSGvQngTZtTTPAh/YwCSz+e78q4PeHQ9dmca1DU=
  • Ironport-sdr: snSCV/BtX0JFjoKmblLr2umn3XiSiFDmCjovm2Hcv+gCgcWbhgdJjRuz+u76NEWq+LDEecnBI1 arFCyTuBHNDXbcRxZ+6Uu6LZho7dqgQhK3Y/OXX6atoiQID+WYv9COvV+2l5GhomKrg62EGnLH ofUyQ5fDogDg+kAzyYn7SD8k2FSBqal22BXWhJ06IxNJgElM16xlZIZt5H29m/F1FMJuna8cQF iqkfY0B+l6RQoHBMB+vdYam0FARL8ofC8ZYXYI8Jk61EzYwTrPEujWQFNwK9+jZzP56GHkVU/g 3ZE=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22/06/2021 16:19, Jan Beulich wrote:
> Some sub-functions, XENMEM_maximum_gpfn and XENMEM_maximum_ram_page in
> particular, can return values requiring more than 31 bits to represent.
> Hence we cannot issue the hypercall directly when the return value of
> ioctl() is used to propagate this value (note that this is not the case
> for the BSDs, and MiniOS already wraps all hypercalls in a multicall).

It took me 3 readings to realise you weren't saying that BSDs used
multicall (which they don't).

Instead, I'd suggest rewording it.

"Some sub-functions, XENMEM_maximum_gpfn and XENMEM_maximum_ram_page in
particular, can return values requiring more than 31 bits to represent.

The BSDs deliberately avoid using the ioctl() return value, and MiniOS
already uses a multicall.  They aren't affected.

Linux and Solaris however do use the ioctl() return value, which must be
avoided in this case to avoid truncation."

Or something similar.

With a suitable improvement along these lines, Acked-by: Andrew Cooper
<andrew.cooper3@xxxxxxxxxx>




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.