From: "Arnd Bergmann" <arnd@arndb.de> To: "Elliot Berman" <quic_eberman@quicinc.com>, "Bjorn Andersson" <quic_bjorande@quicinc.com>, "Dmitry Baryshkov" <dmitry.baryshkov@linaro.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>, "Prakruthi Deepak Heragu" <quic_pheragu@quicinc.com>, "Andy Gross" <agross@kernel.org>, "Jassi Brar" <jassisinghbrar@gmail.com>, linux-arm-kernel@lists.infradead.org, "Mark Rutland" <mark.rutland@arm.com>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Sudeep Holla" <sudeep.holla@arm.com>, "Marc Zyngier" <maz@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Jonathan Corbet" <corbet@lwn.net>, "Will Deacon" <will@kernel.org>, "Catalin Marinas" <catalin.marinas@arm.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>, "Amol Maheshwari" <amahesh@qti.qualcomm.com>, "Kalle Valo" <kvalo@kernel.org>, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 13/21] gunyah: vm_mgr: Introduce basic VM Manager Date: Thu, 03 Nov 2022 10:39:21 +0100 [thread overview] Message-ID: <a3754259-9989-495e-a6bd-5501daff06a2@app.fastmail.com> (raw) In-Reply-To: <7c59a115-36c5-c954-5610-ef5ef1dbb83e@quicinc.com> On Wed, Nov 2, 2022, at 19:44, Elliot Berman wrote: > On 11/2/2022 12:31 AM, Arnd Bergmann wrote: >>> +static long gh_dev_ioctl_create_vm(unsigned long arg) >>> +{ >>> + struct gunyah_vm *ghvm; >>> + struct file *file; >>> + int fd, err; >>> + >>> + /* arg reserved for future use. */ >>> + if (arg) >>> + return -EINVAL; >> >> Do you have something specific in mind here? If 'create' >> is the only command you support, and it has no arguments, >> it would be easier to do it implicitly during open() and >> have each fd opened from /dev/gunyah represent a new VM. >> > > I'd like the argument here to support different types of virtual > machines. I want to leave open what "different types" can be in case > something new comes up in the future, but immediately "different type" > would correspond to a few different authentication mechanisms for > virtual machines that Gunyah supports. > > In this series, I'm only supporting unauthenticated virtual machines > because they are the simplest to get up and running from a Linux > userspace. When I introduce the other authentication mechanisms, I'll > expand much more on how they work, but I'll give quick overview here. > Other authentication mechanisms that are currently supported by Gunyah > are "protected VM" and, on Qualcomm platforms, "PIL/carveout VMs". > Protected VMs are *loosely* similar to the protected firmware design for > KVM and intended to support Android virtualization use cases. > PIL/carevout VMs are special virtual machines that can run on Qualcomm > firmware which authenticate in a way similar to remoteproc firmware (MDT > loader). Ok, thanks for the background. Having different types of virtual machines does mean that you may need some complexity, but I would still lean towards using the simpler context management of opening the /dev/gunyah device node to get a new context, and then using ioctls on each fd to manage that context, instead of going through the extra indirection of having a secondary 'open context' command that always requires opening two file descriptors. >> I'm correct, you can just turn the entire bus/device/driver >> structure within your code into simple function calls, where >> the main code calls vm_mgr_probe() as an exported function >> instead of creating a device. > > Ack. I can do this, although I am nervous about this snowballing into a > situation where I have a mega-module. > > > Please stop beating everything in a single module. > > https://lore.kernel.org/all/250945d2-3940-9830-63e5-beec5f44010b@linaro.org/ I see you concern, but I wasn't suggesting having everything in one module either. There are three common ways of splitting things into separate modules: - I suggested having the vm_mgr module as a library block that exports a few symbols which get used by the core module. The module doesn't do anything on its own, but loading the core module forces loading the vm_mgr. - Alternatively one can do the opposite, and have symbols exported by the core module, with the vm_mgr module using it. This would make sense if you commonly have the core module loaded on virtual machines that do not need to manage other VMs. - The method you have is to have a lower "bus" level that abstracts device providers from consumers, with both sides hooking into the bus. This makes sense for physical buses like PCI or USB where both the host driver and the function driver are unaware of implementation details of the other, but in your case it does not seem like a good fit. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: "Arnd Bergmann" <arnd@arndb.de> To: "Elliot Berman" <quic_eberman@quicinc.com>, "Bjorn Andersson" <quic_bjorande@quicinc.com>, "Dmitry Baryshkov" <dmitry.baryshkov@linaro.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>, "Prakruthi Deepak Heragu" <quic_pheragu@quicinc.com>, "Andy Gross" <agross@kernel.org>, "Jassi Brar" <jassisinghbrar@gmail.com>, linux-arm-kernel@lists.infradead.org, "Mark Rutland" <mark.rutland@arm.com>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Sudeep Holla" <sudeep.holla@arm.com>, "Marc Zyngier" <maz@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Jonathan Corbet" <corbet@lwn.net>, "Will Deacon" <will@kernel.org>, "Catalin Marinas" <catalin.marinas@arm.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>, "Amol Maheshwari" <amahesh@qti.qualcomm.com>, "Kalle Valo" <kvalo@kernel.org>, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 13/21] gunyah: vm_mgr: Introduce basic VM Manager Date: Thu, 03 Nov 2022 10:39:21 +0100 [thread overview] Message-ID: <a3754259-9989-495e-a6bd-5501daff06a2@app.fastmail.com> (raw) In-Reply-To: <7c59a115-36c5-c954-5610-ef5ef1dbb83e@quicinc.com> On Wed, Nov 2, 2022, at 19:44, Elliot Berman wrote: > On 11/2/2022 12:31 AM, Arnd Bergmann wrote: >>> +static long gh_dev_ioctl_create_vm(unsigned long arg) >>> +{ >>> + struct gunyah_vm *ghvm; >>> + struct file *file; >>> + int fd, err; >>> + >>> + /* arg reserved for future use. */ >>> + if (arg) >>> + return -EINVAL; >> >> Do you have something specific in mind here? If 'create' >> is the only command you support, and it has no arguments, >> it would be easier to do it implicitly during open() and >> have each fd opened from /dev/gunyah represent a new VM. >> > > I'd like the argument here to support different types of virtual > machines. I want to leave open what "different types" can be in case > something new comes up in the future, but immediately "different type" > would correspond to a few different authentication mechanisms for > virtual machines that Gunyah supports. > > In this series, I'm only supporting unauthenticated virtual machines > because they are the simplest to get up and running from a Linux > userspace. When I introduce the other authentication mechanisms, I'll > expand much more on how they work, but I'll give quick overview here. > Other authentication mechanisms that are currently supported by Gunyah > are "protected VM" and, on Qualcomm platforms, "PIL/carveout VMs". > Protected VMs are *loosely* similar to the protected firmware design for > KVM and intended to support Android virtualization use cases. > PIL/carevout VMs are special virtual machines that can run on Qualcomm > firmware which authenticate in a way similar to remoteproc firmware (MDT > loader). Ok, thanks for the background. Having different types of virtual machines does mean that you may need some complexity, but I would still lean towards using the simpler context management of opening the /dev/gunyah device node to get a new context, and then using ioctls on each fd to manage that context, instead of going through the extra indirection of having a secondary 'open context' command that always requires opening two file descriptors. >> I'm correct, you can just turn the entire bus/device/driver >> structure within your code into simple function calls, where >> the main code calls vm_mgr_probe() as an exported function >> instead of creating a device. > > Ack. I can do this, although I am nervous about this snowballing into a > situation where I have a mega-module. > > > Please stop beating everything in a single module. > > https://lore.kernel.org/all/250945d2-3940-9830-63e5-beec5f44010b@linaro.org/ I see you concern, but I wasn't suggesting having everything in one module either. There are three common ways of splitting things into separate modules: - I suggested having the vm_mgr module as a library block that exports a few symbols which get used by the core module. The module doesn't do anything on its own, but loading the core module forces loading the vm_mgr. - Alternatively one can do the opposite, and have symbols exported by the core module, with the vm_mgr module using it. This would make sense if you commonly have the core module loaded on virtual machines that do not need to manage other VMs. - The method you have is to have a lower "bus" level that abstracts device providers from consumers, with both sides hooking into the bus. This makes sense for physical buses like PCI or USB where both the host driver and the function driver are unaware of implementation details of the other, but in your case it does not seem like a good fit. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-11-03 9:39 UTC|newest] Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-26 18:58 [PATCH v6 00/21] Drivers for gunyah hypervisor Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 01/21] docs: gunyah: Introduce Gunyah Hypervisor Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-02 12:35 ` Bagas Sanjaya 2022-11-02 12:35 ` Bagas Sanjaya 2022-10-26 18:58 ` [PATCH v6 02/21] dt-bindings: Add binding for gunyah hypervisor Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-27 19:57 ` Krzysztof Kozlowski 2022-10-27 19:57 ` Krzysztof Kozlowski 2022-10-28 2:33 ` Jassi Brar 2022-10-28 2:33 ` Jassi Brar 2022-11-01 3:19 ` Elliot Berman 2022-11-01 3:19 ` Elliot Berman 2022-11-01 16:23 ` Jassi Brar 2022-11-01 16:23 ` Jassi Brar 2022-11-01 20:35 ` Elliot Berman 2022-11-01 20:35 ` Elliot Berman 2022-11-01 21:58 ` Jassi Brar 2022-11-01 21:58 ` Jassi Brar 2022-11-02 0:12 ` Elliot Berman 2022-11-02 0:12 ` Elliot Berman 2022-11-02 2:01 ` Jassi Brar 2022-11-02 2:01 ` Jassi Brar 2022-11-02 18:05 ` Elliot Berman 2022-11-02 18:05 ` Elliot Berman 2022-11-02 18:24 ` Jassi Brar 2022-11-02 18:24 ` Jassi Brar 2022-11-02 23:23 ` Elliot Berman 2022-11-02 23:23 ` Elliot Berman 2022-11-03 3:21 ` Jassi Brar 2022-11-03 3:21 ` Jassi Brar 2022-11-03 19:45 ` Elliot Berman 2022-11-03 19:45 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 03/21] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 19:47 ` Dmitry Baryshkov 2022-10-26 19:47 ` Dmitry Baryshkov 2022-10-26 18:58 ` [PATCH v6 04/21] arm64: smccc: Include alternative-macros.h Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 19:46 ` Dmitry Baryshkov 2022-10-26 19:46 ` Dmitry Baryshkov 2022-10-26 20:23 ` Elliot Berman 2022-10-26 20:23 ` Elliot Berman 2022-10-26 20:39 ` Dmitry Baryshkov 2022-10-26 20:39 ` Dmitry Baryshkov 2022-10-26 18:58 ` [PATCH v6 05/21] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 06/21] virt: gunyah: Identify hypervisor version Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 07/21] mailbox: Allow direct registration to a channel Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 08/21] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 09/21] mailbox: Add Gunyah message queue mailbox Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-27 13:55 ` Pavan Kondeti 2022-10-27 13:55 ` Pavan Kondeti 2022-11-01 17:44 ` Elliot Berman 2022-11-01 17:44 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 10/21] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-01 18:02 ` Greg Kroah-Hartman 2022-11-01 18:02 ` Greg Kroah-Hartman 2022-11-02 0:12 ` Elliot Berman 2022-11-02 0:12 ` Elliot Berman 2022-11-02 2:53 ` Greg Kroah-Hartman 2022-11-02 2:53 ` Greg Kroah-Hartman 2022-11-02 18:04 ` Elliot Berman 2022-11-02 18:04 ` Elliot Berman 2022-11-03 0:22 ` Greg Kroah-Hartman 2022-11-03 0:22 ` Greg Kroah-Hartman 2022-11-03 22:07 ` Elliot Berman 2022-11-03 22:07 ` Elliot Berman 2022-11-03 22:09 ` Elliot Berman 2022-11-03 22:09 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 11/21] gunyah: rsc_mgr: Add subdevices bus Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 12/21] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 13/21] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-02 5:14 ` Greg Kroah-Hartman 2022-11-02 5:14 ` Greg Kroah-Hartman 2022-11-02 18:45 ` Elliot Berman 2022-11-02 18:45 ` Elliot Berman 2022-11-03 0:24 ` Greg Kroah-Hartman 2022-11-03 0:24 ` Greg Kroah-Hartman 2022-11-04 0:11 ` Elliot Berman 2022-11-04 0:11 ` Elliot Berman 2022-11-04 8:10 ` Arnd Bergmann 2022-11-04 8:10 ` Arnd Bergmann 2022-11-04 22:38 ` Elliot Berman 2022-11-04 22:38 ` Elliot Berman 2022-11-05 4:19 ` Trilok Soni 2022-11-05 4:19 ` Trilok Soni 2022-11-11 0:03 ` Elliot Berman 2022-11-11 0:03 ` Elliot Berman 2022-11-11 6:24 ` Greg Kroah-Hartman 2022-11-11 6:24 ` Greg Kroah-Hartman 2022-11-11 17:08 ` Elliot Berman 2022-11-11 17:08 ` Elliot Berman 2022-11-02 7:31 ` Arnd Bergmann 2022-11-02 7:31 ` Arnd Bergmann 2022-11-02 18:44 ` Elliot Berman 2022-11-02 18:44 ` Elliot Berman 2022-11-03 0:20 ` Greg Kroah-Hartman 2022-11-03 0:20 ` Greg Kroah-Hartman 2022-11-03 22:33 ` Elliot Berman 2022-11-03 22:33 ` Elliot Berman 2022-11-03 9:39 ` Arnd Bergmann [this message] 2022-11-03 9:39 ` Arnd Bergmann 2022-11-03 22:10 ` Elliot Berman 2022-11-03 22:10 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 14/21] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 15/21] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 16/21] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 17/21] samples: Add sample userspace Gunyah VM Manager Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 18/21] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 19/21] firmware: qcom_scm: Use fixed width src vm bitmap Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 20/21] firmware: qcom_scm: Register Gunyah platform ops Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 21:32 ` kernel test robot 2022-10-26 18:58 ` [PATCH v6 21/21] docs: gunyah: Document Gunyah VM Manager Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-02 13:05 ` Bagas Sanjaya 2022-11-02 13:05 ` Bagas Sanjaya 2022-11-02 18:04 ` Elliot Berman 2022-11-02 18:04 ` Elliot Berman
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=a3754259-9989-495e-a6bd-5501daff06a2@app.fastmail.com \ --to=arnd@arndb.de \ --cc=agross@kernel.org \ --cc=amahesh@qti.qualcomm.com \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=jassisinghbrar@gmail.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=kvalo@kernel.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=lorenzo.pieralisi@arm.com \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=quic_bjorande@quicinc.com \ --cc=quic_cvanscha@quicinc.com \ --cc=quic_eberman@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=sudeep.holla@arm.com \ --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: linkBe 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.