[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>
- From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
- Date: Tue, 18 Apr 2023 14:38:36 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=0EljlqRfyBN5u+AH1HiyHn2aQySznZuUmDSCl1CQLBk=; b=T8uFi8y9Q8DzJ1/KYjhPu6Yjn4LTi7qKHKanKjhxTMeCB1wR688EtFPdvFpLpFRACraPCRUf3G2SCCe9EAG6VrZmXwbY0/O2cMJsw/ATmBwWfr1uksc2mbssep6M5vWW24rDmDH5bLkaDQw05R1YVaDzM6+nGba4waCD9Hj2ScIAE/+M1dvq1on0Ubp7Ky/Ou5hFNTeDUqhMLjLB4lr7GI16ppVRycTHTXGvfp5mug0yq5GKiuD5Vx8iIrKGhYst6qNWG8LRAUhLLuUPUjQuSnYQnYK4D/+NDt5qjENqh5yrgzGJvw2a/vn19vUWt48fqjKk20FRrjegAa2crQDmsQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RJQLbCLWUn9N0l2FtTkWuWDoi2XLZluyPrjtfa0w2wDmnF2nB+UKTAzQOWFRgRE6hw5+LaE+PLNqd1a8QRfz/ihVozllX7LI2NQnQ335ik1Ymb9bS1GB93SncBD9HEfmTcDk2nA+9hc9u4iHqAqfDl0UylUiwlfPIOjy823SDMmQfKt8ayndDtRAhZriwzptguQfUvluMmJWNT3aaybMZ+2wuP61ljv064bdxxx7WnWA+pTAwvtct2kD2qyjLrp1eecFEXHfEvmoWgX9Ii8HKekT3WVE/2FcxZ0FA2QqKIkL5Mc2BgjbHhgfsPVuM+jHA7c9VScMMFvx6o4cSrRLng==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: Luca Fancellu <Luca.Fancellu@xxxxxxx>, 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>, Jan Beulich <jbeulich@xxxxxxxx>, 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: Tue, 18 Apr 2023 14:39:15 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Thread-index: AQHZbSQqKlfgrZX3xkqta7+H+1gq3K8xFMoAgAAUHYCAAAOtgA==
- Thread-topic: [PATCH v5 00/12] SVE feature for arm guests
Hi Julien,
> On 18 Apr 2023, at 16:25, Julien Grall <julien@xxxxxxx> wrote:
>
>
>
> On 18/04/2023 14:13, Bertrand Marquis wrote:
>> Hi Luca,
>
> Hi,
>
>> 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...
Good point
>
>> - 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 agree: we should not silently ignore configuration parameters or try to "fix"
them.
Cheers
Bertrand
|
