From: Elliot Berman <quic_eberman@quicinc.com>
To: Alex Elder <elder@linaro.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>,
Jonathan Corbet <corbet@lwn.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: Murali Nalajala <quic_mnalajal@quicinc.com>,
Trilok Soni <quic_tsoni@quicinc.com>,
Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>,
Carl van Schaik <quic_cvanscha@quicinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Bjorn Andersson <andersson@kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Andy Gross <agross@kernel.org>,
Jassi Brar <jassisinghbrar@gmail.com>,
<linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v11 22/26] virt: gunyah: Add proxy-scheduled vCPUs
Date: Tue, 18 Apr 2023 11:35:45 -0700 [thread overview]
Message-ID: <a6482ddd-c038-99ab-6c88-cbda31cf6fba@quicinc.com> (raw)
In-Reply-To: <1c69a301-332b-3523-caeb-5d838bb5f5d2@linaro.org>
On 4/18/2023 10:31 AM, Alex Elder wrote:
> On 4/18/23 12:18 PM, Elliot Berman wrote:
>>
>>
>> On 4/17/2023 3:41 PM, Elliot Berman wrote:
>>>
>>>
>>> On 3/31/2023 7:27 AM, Alex Elder wrote:
>>>> On 3/3/23 7:06 PM, Elliot Berman wrote:
>>>
>>> [snip]
>>>
>>>>> diff --git a/include/uapi/linux/gunyah.h b/include/uapi/linux/gunyah.h
>>>>> index caeb3b3a3e9a..e52265fa5715 100644
>>>>> --- a/include/uapi/linux/gunyah.h
>>>>> +++ b/include/uapi/linux/gunyah.h
>>>>> @@ -62,8 +62,32 @@ struct gh_vm_dtb_config {
>>>>> #define GH_VM_START _IO(GH_IOCTL_TYPE, 0x3)
>>>>> +/**
>>>>> + * GH_FN_VCPU - create a vCPU instance to control a vCPU
>>>>> + *
>>>>> + * gh_fn_desc is filled with &struct gh_fn_vcpu_arg
>>>>> + *
>>>>> + * The vcpu type will register with the VM Manager to expect to
>>>>> control
>>>>> + * vCPU number `vcpu_id`. It returns a file descriptor allowing
>>>>> interaction with
>>>>> + * the vCPU. See the Gunyah vCPU API description sections for
>>>>> interacting with
>>>>> + * the Gunyah vCPU file descriptors.
>>>>> + *
>>>>> + * Return: file descriptor to manipulate the vcpu. See GH_VCPU_*
>>>>> ioctls
>>>>> + */
>>>>> +#define GH_FN_VCPU 1
>>>>
>>>> I think you should define GH_VN_VCPU, GN_FN_IRQFD, and GN_FN_IOEVENTFD
>>>> in an enumerated type. Each has a type associated with it, and you can
>>>> add the explanation for the function in the kernel-doc comments above
>>>> thosse type definitions.
>>>>
>>>
>>> I'd like to enumify the GH_FN_* macros, but one challenge I'm facing
>>> is that it breaks the module alias implementation in patch 19.
>>>
>>> MODULE_ALIAS("ghfunc:"__stringify(_type))
>>>
>>> When the GH_FN_* are regular preprocessor macros backed by an
>>> integer, the preprocessor will make the module alias ghfunc:0 (or
>>> ghfunc:1, etc). This works well because I can do
>>>
>>> request_module("ghfunc:%d", type);
>>>
>>> If the function hasn't been registered and then gunyah_vcpu.ko gets
>>> loaded automatically.
>>>
>>> With enum, compiler knows the value of GH_FN_VCPU and preprocessor
>>> will make the module alias like ghfunc:GH_FN_VCPU.
>>>
>>
>> I still like the idea of having enum for documentation and clarity. I
>> noticed that nfnetlink.h saw the same problem for NFNL_SUBSYS_*.
>>
>> Is this compromise terrible and I should give up on the enum?
>
> You know, I've seen this pattern in the kernel and never thought
> too much about why it was done. Maybe this is exactly the reason.
>
> It sure *seems* like there might be some macro magic that might
> cause the enum symbol's numeric value to be used but I think the
> problem is that enums are C tokens, which are not evaluated at
> preprocessor time.
>
> You could probably skip the leading underscore, and do this as
> it's done for nfnetlink_groups in that same header file.
>
> Maybe somebody else can confirm, or has a better suggestion.
>
In the preprocessor macro case, the preprocessor macro GH_FN_VCPU
expands to the GH_FN_VCPU enum value and stuck back as if I didn't have
the preprocessor macro in first place. I'm not sure why the preprocessor
macros are done for nfnetlink_groups. I saw one case where enum
kvm_device_type does the same, but that might be done because it was
converting preprocessor macro to enum.
Just a guess -- maybe the preprocessor macro was preserved to support
userspace code doing this?
#ifdef KVM_DEV_TYPE_FSL_MPIC_20
...
#endif
> -Alex
>
>
>> enum gh_fn_type {
>> /* _GH_FN_* macro required for MODULE_ALIAS, otherwise __stringify()
>> trick
>> * won't work anymore */
>> #define _GH_FN_VCPU 1
>> GH_FN_VCPU = _GH_FN_VCPU,
>> #define _GH_FN_IRQFD 2
>> GH_FN_IRQFD = _GH_FN_IRQFD,
>> #define _GH_FN_IOEVENTFD 3
>> GH_FN_IOEVENTFD = _GH_FN_IOEVENTFD,
>> };
>>
>>> [snip]
>>>
>>>>> +
>>>>> +/*
>>>>> + * Gunyah presently sends max 4 bytes of exit_reason.
>>>>> + * If that changes, this macro can be safely increased without
>>>>> breaking
>>>>> + * userspace so long as struct gh_vcpu_run < PAGE_SIZE.
>>>>
>>>> Is PAGE_SIZE allowed to be anything other than 4096 bytes? Do you
>>>> expect this driver to work properly if the page size were configured
>>>> to be 16384 bytes? In other words, is this a Gunyah constant, or
>>>> is it *really* the page size configured for Linux?
>>>>
>>>
>>> Our implementations are only doing 4096 bytes. I expect the driver to
>>> work properly when using 16k pages. This really is a Linux page. It's
>>> a reflection of the alloc_page in gh_vcpu_bind().
>>>
>>> The exit reason is copied from hypervisor into field accessible by
>>> userspace directly. Gunyah makes the exit reason size dynamic --
>>> there's no architectural limitation preventing the exit reason from
>>> being a string or some lengthy data.
>>>
>>> As I was writing this response, I realized that I should be able to
>>> make this a zero-length array and ensure that reason[] doesn't
>>> overflow PAGE_SIZE...
>>>
>>> The comment was trying to explain that Linux itself imposes a
>>> limitation on the maximum exit reason size. If we need to support
>>> longer exit reason, we're OK to do so long as the total size doesn't
>>> overrun PAGE_SIZE. There aren't any plans to need longer exit reasons
>>> than the 8 bytes mentioned today.
>>>
>>> Thanks,
>>> Elliot
>
next prev parent reply other threads:[~2023-04-18 18:36 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-04 1:06 [PATCH v11 00/26] Drivers for gunyah hypervisor Elliot Berman
2023-03-04 1:06 ` [PATCH v11 01/26] docs: gunyah: Introduce Gunyah Hypervisor Elliot Berman
2023-03-04 1:06 ` [PATCH v11 02/26] dt-bindings: Add binding for gunyah hypervisor Elliot Berman
2023-03-04 1:06 ` [PATCH v11 03/26] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman
2023-03-21 14:23 ` Srinivas Kandagatla
2023-03-31 14:24 ` Alex Elder
2023-04-03 19:44 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 04/26] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman
2023-03-21 14:22 ` Srinivas Kandagatla
2023-03-31 14:24 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 05/26] virt: gunyah: Identify hypervisor version Elliot Berman
2023-03-21 15:48 ` Srinivas Kandagatla
2023-03-31 14:24 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 06/26] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman
2023-03-21 15:49 ` Srinivas Kandagatla
2023-03-31 14:25 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 07/26] mailbox: Add Gunyah message queue mailbox Elliot Berman
2023-03-21 14:22 ` Srinivas Kandagatla
2023-03-31 14:25 ` Alex Elder
2023-04-03 20:15 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 08/26] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman
2023-03-31 14:25 ` Alex Elder
2023-04-03 20:34 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 09/26] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman
2023-03-31 14:25 ` Alex Elder
2023-04-03 21:09 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 10/26] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman
2023-03-21 14:23 ` Srinivas Kandagatla
2023-03-31 14:25 ` Alex Elder
2023-04-11 20:48 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 11/26] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman
2023-03-31 14:26 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 12/26] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman
2023-03-24 18:37 ` Will Deacon
2023-04-11 20:34 ` Elliot Berman
2023-04-11 21:19 ` Will Deacon
2023-04-12 20:48 ` Elliot Berman
2023-04-13 9:54 ` Will Deacon
2023-03-31 14:26 ` Alex Elder
2023-04-11 21:04 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 13/26] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman
2023-03-21 14:24 ` Srinivas Kandagatla
2023-04-11 21:07 ` Elliot Berman
2023-04-11 21:09 ` Alex Elder
2023-03-31 14:26 ` Alex Elder
2023-04-11 21:16 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 14/26] samples: Add sample userspace Gunyah VM Manager Elliot Berman
2023-03-31 14:26 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 15/26] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman
2023-03-21 14:23 ` Srinivas Kandagatla
2023-03-22 19:17 ` Elliot Berman
2023-03-31 14:26 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 16/26] firmware: qcom_scm: Register Gunyah platform ops Elliot Berman
2023-03-21 14:24 ` Srinivas Kandagatla
2023-03-21 18:40 ` Elliot Berman
2023-03-21 20:19 ` Srinivas Kandagatla
2023-03-04 1:06 ` [PATCH v11 17/26] docs: gunyah: Document Gunyah VM Manager Elliot Berman
2023-03-04 1:06 ` [PATCH v11 18/26] virt: gunyah: Translate gh_rm_hyp_resource into gunyah_resource Elliot Berman
2023-03-31 14:26 ` Alex Elder
2023-04-18 0:25 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 19/26] gunyah: vm_mgr: Add framework to add VM Functions Elliot Berman
2023-03-31 14:26 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 20/26] virt: gunyah: Add resource tickets Elliot Berman
2023-03-31 14:27 ` Alex Elder
2023-04-17 22:57 ` Elliot Berman
2023-03-04 1:06 ` [PATCH v11 21/26] virt: gunyah: Add IO handlers Elliot Berman
2023-03-31 14:27 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 22/26] virt: gunyah: Add proxy-scheduled vCPUs Elliot Berman
2023-03-31 14:27 ` Alex Elder
2023-04-17 22:41 ` Elliot Berman
2023-04-18 12:46 ` Alex Elder
2023-04-18 17:18 ` Elliot Berman
2023-04-18 17:31 ` Alex Elder
2023-04-18 18:35 ` Elliot Berman [this message]
2023-03-04 1:06 ` [PATCH v11 23/26] virt: gunyah: Add hypercalls for sending doorbell Elliot Berman
2023-03-31 14:27 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 24/26] virt: gunyah: Add irqfd interface Elliot Berman
2023-03-31 14:27 ` Alex Elder
2023-04-17 22:55 ` Elliot Berman
2023-04-18 12:55 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 25/26] virt: gunyah: Add ioeventfd Elliot Berman
2023-03-31 14:27 ` Alex Elder
2023-03-04 1:06 ` [PATCH v11 26/26] MAINTAINERS: Add Gunyah hypervisor drivers section Elliot Berman
2023-03-31 14:24 ` [PATCH v11 00/26] Drivers for gunyah hypervisor Alex Elder
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=a6482ddd-c038-99ab-6c88-cbda31cf6fba@quicinc.com \
--to=quic_eberman@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=arnd@arndb.de \
--cc=bagasdotme@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=elder@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=jassisinghbrar@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_cvanscha@quicinc.com \
--cc=quic_mnalajal@quicinc.com \
--cc=quic_pheragu@quicinc.com \
--cc=quic_svaddagi@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).