All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Luca Fancellu <Luca.Fancellu@arm.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Wei Chen" <Wei.Chen@arm.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>, "Wei Liu" <wl@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Nick Rosbrook" <rosbrookn@gmail.com>,
	"Anthony PERARD" <anthony.perard@citrix.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Christian Lindig" <christian.lindig@citrix.com>,
	"David Scott" <dave@recoil.org>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"Henry Wang" <Henry.Wang@arm.com>,
	"Community Manager" <community.manager@xenproject.org>
Subject: Re: [PATCH v5 00/12] SVE feature for arm guests
Date: Tue, 18 Apr 2023 13:13:26 +0000	[thread overview]
Message-ID: <08BE4F94-C4B5-4B05-AD92-61C5C5D24F39@arm.com> (raw)
In-Reply-To: <20230412094938.2693890-1-luca.fancellu@arm.com>

Hi Luca,

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.

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.

- coherently stop if the parameter value is not supported (including if sve is
not supported)

- always disable SVE if the parameter value is not supported.

To be honest I am not quite sure which solution is better but I am not happy with
the different kind of behaviour we have right now.

What are your thoughts ?

Regards
Bertrand



  parent reply	other threads:[~2023-04-18 13:14 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12  9:49 [PATCH v5 00/12] SVE feature for arm guests Luca Fancellu
2023-04-12  9:49 ` [PATCH v5 01/12] xen/arm: enable SVE extension for Xen Luca Fancellu
2023-04-13 12:47   ` Bertrand Marquis
2023-04-14 13:28     ` Luca Fancellu
2023-04-14 13:38       ` Bertrand Marquis
2023-04-12  9:49 ` [PATCH v5 02/12] xen/arm: add SVE vector length field to the domain Luca Fancellu
2023-04-13 12:47   ` Bertrand Marquis
2023-04-17  9:20     ` Jan Beulich
2023-04-13 12:57   ` Julien Grall
2023-04-13 13:24     ` Luca Fancellu
2023-04-13 13:30       ` Julien Grall
2023-04-13 14:05         ` Luca Fancellu
2023-04-13 16:10           ` Luca Fancellu
2023-04-13 19:53             ` Julien Grall
2023-04-13 19:52           ` Julien Grall
2023-04-14 11:07             ` Luca Fancellu
2023-04-14 17:16               ` Julien Grall
2023-04-12  9:49 ` [PATCH v5 03/12] xen/arm: Expose SVE feature to the guest Luca Fancellu
2023-04-13 12:47   ` Bertrand Marquis
2023-04-12  9:49 ` [PATCH v5 04/12] xen/arm: add SVE exception class handling Luca Fancellu
2023-04-13 13:02   ` Julien Grall
2023-04-13 13:27     ` Luca Fancellu
2023-04-14  8:40   ` Bertrand Marquis
2023-04-12  9:49 ` [PATCH v5 05/12] arm/sve: save/restore SVE context switch Luca Fancellu
2023-04-13 13:11   ` Julien Grall
2023-04-13 14:35     ` Luca Fancellu
2023-04-13 19:54       ` Julien Grall
2023-04-18 12:40   ` Bertrand Marquis
2023-04-19  7:09     ` Luca Fancellu
2023-04-19  7:13       ` Bertrand Marquis
2023-04-20  7:43         ` Luca Fancellu
2023-04-20  7:55           ` Bertrand Marquis
2023-04-20  7:58             ` Luca Fancellu
2023-04-20  8:33               ` Bertrand Marquis
2023-04-12  9:49 ` [PATCH v5 06/12] xen/common: add dom0 xen command line argument for Arm Luca Fancellu
2023-04-14  8:47   ` Bertrand Marquis
2023-04-12  9:49 ` [PATCH v5 07/12] xen: enable Dom0 to use SVE feature Luca Fancellu
2023-04-17  9:41   ` Jan Beulich
2023-04-20  6:25     ` Luca Fancellu
2023-04-20  7:56       ` Jan Beulich
2023-04-18 12:47   ` Bertrand Marquis
2023-04-19  6:34     ` Jan Beulich
2023-04-19  7:15     ` Luca Fancellu
2023-04-19  7:21       ` Bertrand Marquis
2023-04-19  7:41         ` Luca Fancellu
2023-04-20  8:46           ` Luca Fancellu
2023-04-20 12:00             ` Bertrand Marquis
2023-04-20 12:29             ` Julien Grall
2023-04-20 12:43               ` Luca Fancellu
2023-04-20 13:08                 ` Julien Grall
2023-04-20 13:18                   ` Luca Fancellu
2023-04-12  9:49 ` [PATCH v5 08/12] xen/physinfo: encode Arm SVE vector length in arch_capabilities Luca Fancellu
2023-04-18 12:49   ` Bertrand Marquis
2023-04-12  9:49 ` [PATCH v5 09/12] tools: add physinfo arch_capabilities handling for Arm Luca Fancellu
2023-04-12  9:49 ` [PATCH v5 10/12] xen/tools: add sve parameter in XL configuration Luca Fancellu
2023-04-12  9:49 ` [PATCH v5 11/12] xen/arm: add sve property for dom0less domUs Luca Fancellu
2023-04-18 12:55   ` Bertrand Marquis
2023-04-18 13:21     ` Bertrand Marquis
2023-04-12  9:49 ` [PATCH v5 12/12] xen/changelog: Add SVE and "dom0" options to the changelog for Arm Luca Fancellu
2023-04-12  9:53   ` Henry Wang
2023-04-18 12:56   ` Bertrand Marquis
2023-04-19  7:11     ` Luca Fancellu
2023-04-19  7:16       ` Bertrand Marquis
2023-04-18 13:13 ` Bertrand Marquis [this message]
2023-04-18 14:25   ` [PATCH v5 00/12] SVE feature for arm guests Julien Grall
2023-04-18 14:38     ` Bertrand Marquis
2023-04-18 14:41       ` Luca Fancellu
2023-04-18 15:00         ` Bertrand Marquis
2023-04-19  6:28     ` Jan Beulich
2023-04-19  7:31       ` Bertrand Marquis
2023-04-19  7:46         ` Julien Grall
2023-04-19  7:52         ` Jan Beulich
2023-04-19  8:20           ` Bertrand Marquis
2023-04-20 12:30             ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=08BE4F94-C4B5-4B05-AD92-61C5C5D24F39@arm.com \
    --to=bertrand.marquis@arm.com \
    --cc=Henry.Wang@arm.com \
    --cc=Luca.Fancellu@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=Wei.Chen@arm.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=christian.lindig@citrix.com \
    --cc=community.manager@xenproject.org \
    --cc=dave@recoil.org \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=marmarek@invisiblethingslab.com \
    --cc=roger.pau@citrix.com \
    --cc=rosbrookn@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.