[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/12] SVE feature for arm guests
- To: Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Luca Fancellu <Luca.Fancellu@xxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 19 Apr 2023 08:28:16 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zppZioHxju2k1rOcyDNlXjKuHYmML04feaRLOpSEdxY=; b=FZL9ZCZE6Hg/wUXSyx6mRWXHHWichmXfaX5YHia9DhH0R0RyF8dZ1Cy1A8p7Qaos0jbfXtOJ/MupaE7x42WkVUeDilupu0N/Y4LEVKkY3HUFdXNnA2SX+GB9aoBO3wIzKnccTQmeYFAzOflbz5T0Gn1uroFOfo2iPhItkAGGOhxx5cCz50LEEnowO7DcrrZI2YWBSRdNrWQIY6zmWHwUpdDvcMNISU+mCGt484YI68uzH+YEyU0SnwuS7vmzNk3zRcCQPm6qbqCbQr2Fip37bPHW4DEvCaA6HtRWwocU06x0IyPdG22XNb4Twi+TP0QINLLcljk+d5F2dQKkaTvCCQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IBGDIOjIgDDsr0umM0Ohv3XrvY3yeflntmmBwrmzRJDsBAHwqbzOETlSpZ+PrtYsMrLKFWw6SITHGJ/YSlze9WBUWh6wZ5gyUjX/j1uKQJjOPJb+CRk7+ULap8VGB/9JWgmadoeRwfpx+Z/yF9bjYSz0MFxg/X3DkorrOtwg9AYTN/5aG3SwwMSmD/2/odgOxTpp1JZqE6W/8bnFqyLqKm4pBrE0TPDmmOrgpfkLm9KWGqeh0h1N5fXu/f3bvG4xf+2KvjPlBdaYjRoSoK1j58e9sTovDym/extkrngexgajjnI3XYsKA6suhvEKhylMz1NZv4XlqTvenZOw39mLrQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Nick Rosbrook <rosbrookn@xxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Christian Lindig <christian.lindig@xxxxxxxxxx>, David Scott <dave@xxxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>, Community Manager <community.manager@xxxxxxxxxxxxxx>
- Delivery-date: Wed, 19 Apr 2023 06:28:41 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 18.04.2023 16:25, Julien Grall wrote:
> On 18/04/2023 14:13, Bertrand Marquis wrote:
>> On this serie I would like to open a discussion on how to handle the vector
>> size
>> and the corresponding command line / configuration / device tree parameters.
>>
>> In general the user must either give a vector size it wants or has a
>> solution to
>> just request the maximum supported size.
>>
>> In the current implementation if a size bigger than the supported one is
>> provided:
>> - we silently disable SVE for dom0
>> - we silently disable SVE for dom0less
>> - we do not create a guest when done through tools
>>
>> This is not completely coherent and i think we should aim for a coherent
>> behaviour
>> unless we have arguments for this status.
>
> +1.
>
>> Is there any good reason to silently disable for Dom0 and dom0less only ?
>>
>> I see some possible solutions here:
>>
>> - modify parameter behaviour to use the supported size if parameter is
>> bigger than
>> it. This would at least keep SVE enabled if a VM depends on it and could
>> simplify
>> some of the handling by using 2048 to use the maximum supported size.
>
> My concern with this approach and the third one is the user may take
> some time to realize the problem in the xl.cfg. So...
>
>>
>> - coherently stop if the parameter value is not supported (including if sve
>> is
>> not supported)
>
> ... this is my preferred approach because it would be clear that the
> value passed to Xen is bogus.
I did say earlier on that this comes with its own downside of preventing
boot to complete for no real reason. It's all Arm code, so you're fine
to ignore me, but in similar situations elsewhere (sorry, don't recall a
concrete example off the top of my head) we've aimed to allow the system
to boot, for the admin to then take corrective action if/as needed.
Jan
|
