[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] drivers/xen/hypervisor: Expose Xen SIF flags to userspace
- To: Juergen Gross <jgross@xxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>
- From: Per Bilse <Per.Bilse@xxxxxxxxxx>
- Date: Mon, 12 Dec 2022 13:35:22 +0000
- Accept-language: en-US
- 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Fw4pn4Vmxe/Jmd55iy0zRjWURCdaOD7uS/rGwpRXV4c=; b=ZjfBqdvjsCsFarvDOfOy7PL7wvBvGKcex660Hg4OF8nSCD10QoPluc83k92/TZX/6zxTp2CNN2gMs+WKJ8VQGVTWRIYzo7WVCdyM4Lt9bzqqvLFztbRXqqEKLjmTi5jbQH2MSrGQcmYPIBlHToUJM3HhSqPgUjVnY/85OjR7WzpqnkVH4dGVGAud74cjdPxATznggHysURREi8t8Ar4z4IGEOtbybxaZgKYqL+aSAgk0E8Rndc1utY3R+Dkv4rqUTaqh/cv5vwAx1AUl0njIaXhDftttEgcfknEdZvsnrsBgNZBVf21DSUsoOZzbpSU3W6jUVeWLAo77go8UI2MQIQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TKT9qQcGDKN3mIeseOJIfcBNUzCt/d9YZIHXkvklbur1uaPuvU8/EekNHVB+Bej4c8DrIDUVL1tRdqWrn9uvqi/elsuw+TpGz9ACoQdvYLiMYzblQsWGt8w5PM49d0wLXmm+VKfxqL0tFEnptxJtvFWWWAjKp1z+HbcIkyclkBgfslvOxy+kLQdjM26tLDO6QurJOFqF0dCWoqlkH5l/CW2tp8RFon2LwE1BAqaptu8vZ17ECoK7vAe2N40Yby8+8kaHYVyG6JQtOiqgsvfY+15jV+773uA3eEM28fxo6xrNe3bACcdn8bBxBCpvcC7BYcouwwTH7m6usJOGl0uwVw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, "moderated list:XEN HYPERVISOR INTERFACE" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 12 Dec 2022 13:35:56 +0000
- Ironport-data: A9a23:aA2QGaz9/Dqb6blnjuJ6t+fbxyrEfRIJ4+MujC+fZmUNrF6WrkVUx zFLXm/VaP+OZWH9LY0nOdjl8EwEsZ7Xzd5hHAY6qyAxQypGp/SeCIXCJC8cHc8wwu7rFxs7s ppEOrEsCOhuExcwcz/0auCJQUFUjP3OHfykTbaeYUidfCc8IA85kxVvhuUltYBhhNm9Emult Mj75sbSIzdJ4RYtWo4vw//F+U0HUMja4mtC5AVkPKoT5TcyqlFOZH4hDfDpR5fHatE88t6SH 47r0Ly/92XFyBYhYvvNfmHTKxBirhb6ZGBiu1IOM0SQqkEqSh8ai87XAME0e0ZP4whlqvgqo Dl7WT5cfi9yVkHEsLx1vxC1iEiSN4UekFPMCSDXXcB+UyQq2pYjqhljJBheAGEWxgp4KTBM+ cUSKAI/VBOa1+uI+O+WZtFHh/12eaEHPKtH0p1h5RfwKK9/BLzmHeDN79Ie2yosjMdTG/qYf 9AedTdkcBXHZVtIJ0sTD5U92uyvgxETcRUB8A7T+fVxvjeVlVMsuFTuGIO9ltiifchP2GyZo nnL12/4HgsbJJqUzj/tHneE1rCTx32lCdN6+LuQx9A0hk+K+mMqEwQaEnr8sOjirF/hRIcKQ 6AT0m90xUQoz2SpQcP6RAaQu2Ofs1gXXN84O+k77hydj6nZ+QCUAkAaQTNbLt8rrsk7QXotz FDht8jyGTVlvbmRSHSc3rSZtzW/PW4SN2BqTSgAQAge6t/vurYvnwnPRdZuFq2yptDtEDS2y DePxAAuirNWgcMV2qGT+VHcnynqtpXPVhQy5AjcQiSi9AwRWWK+T4mh6Fye4fMeKo+cFwCFp CJdxJXY6/0SB5aQkiDLWP8KALyi+/eCNnvbnEJrGJ4isT+q/hZPYLxt3d23H28xWu5sRNMjS Ba7Vd95jHOLAEaXUA==
- Ironport-hdrordr: A9a23:7HHRJ6Eqpd3w0AQJpLqE4MeALOsnbusQ8zAXPhZKOHlom6uj5q KTdZUgpHzJYVMqMk3I9ursBEDtex/hHP1OgbX5X43NYOCOggLBR72KhrGC/9SPIULDHl8379 YFT5RD
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZDh1gTv+e/HYXHUu042upYlMPeq5lPlCAgAUCnwA=
- Thread-topic: [PATCH] drivers/xen/hypervisor: Expose Xen SIF flags to userspace
On 09/12/2022 09:04, Juergen Gross wrote:
> On 02.12.22 19:22, Per Bilse wrote:
>> +Description: If running under Xen:
>> + All bits in Xen's start-flags are represented as
>> + boolean files, returning '1' if set, '0' otherwise.
>
> I think at least the files which want to be used by e.g. systemd
> ("initdomain" as replacement for the "control_d" string in capabilities,
> but I think "privileged" as well) should be explicitly added to this
> description, as those are meant to be used as a stable ABI.
OK, yes, it's a bit vague as is.
>> +static struct hyp_sysfs_attr flag_attrs[FLAG_COUNT] = {
>> + [ilog2(SIF_PRIVILEGED)] = {
>> + .attr = { .name = "privileged", .mode = 0444 },
>> + .show = flag_show,
>> + .hyp_attr_value = SIF_PRIVILEGED
>> + },
>
> What about:
>
> #define FLAG_NODE(bit, node) \
> [ilog2(bit)] = { \
> .attr = { .name = #node, .mode = 0444 }, \
> .show = flag_show, \
> .hyp_attr_value = bit \
> }
Yes ... I was thinking that maybe flags wouldn't normally share most
characteristics, but they probably do.
> In order to avoid a consumer having to look into the sources for any other
> set flag, maybe add names for currently defined flags, too? Or just skip >
> the other flags and add a single additional node ("flags"?) with the
whole
> value of xen_start_flags either in hex or binary form?
The current format is as suggested by Andrew Cooper in email about a
previous incarnation
(https://lore.kernel.org/lkml/92300a81-b97b-f5d6-e3e8-363d8a7d3742@xxxxxxxxxx/);
specifically, that of the known flags only initdomain and privileged are
relevant outside a kernel context, and that all other flags be exposed
individually.
> Please note that this is a suggestion only, I'm not insisting on it.
Please, many thanks for the feedback, it's always good to hear other
people's thoughts.
Best,
-- Per
|