From: Souvik Chakravarty <Souvik.Chakravarty@arm.com> To: Russell King - ARM Linux admin <linux@armlinux.org.uk>, Peter Hilber <peter.hilber@opensynergy.com> Cc: "virtio-dev@lists.oasis-open.org" <virtio-dev@lists.oasis-open.org>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, "virtio-comment@lists.oasis-open.org" <virtio-comment@lists.oasis-open.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Sudeep Holla <Sudeep.Holla@arm.com>, "alex.bennee@linaro.org" <alex.bennee@linaro.org>, Cristian Marussi <Cristian.Marussi@arm.com> Subject: RE: [PATCH v6] Add virtio SCMI device specification Date: Tue, 16 Feb 2021 16:48:30 +0000 [thread overview] Message-ID: <DBBPR08MB4790802EA436661E4AEEEFF682879@DBBPR08MB4790.eurprd08.prod.outlook.com> (raw) In-Reply-To: <20210216161208.GA1463@shell.armlinux.org.uk> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk> > Sent: Tuesday, February 16, 2021 4:12 PM > > On Fri, Feb 12, 2021 at 10:59:20AM +0100, Peter Hilber wrote: > > This patch proposes a new virtio device for the Arm SCMI protocol. > > > > The device provides a simple transport for the Arm SCMI protocol[1]. > > The *S*ystem *C*ontrol and *M*anagement *I*nterface protocol allows > > speaking to system controllers that allow orchestrating things like > > power management, system state management and sensor access. The > SCMI > > protocol is used on SoCs where multiple cores and co-processors need > > access to these resources. > > > > The virtio transport allows making use of this protocol in virtualized > > systems. > > > > [1] https://developer.arm.com/docs/den0056/c > > > > Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> > > I'm not too familiar with SCMI, but I think this question is worth asking... > > If the SCMI protocol can be used to control system level power management, > and if the intention is to expose this firmware interface to virtualised guests, > what prevents a guest from controlling the power settings for stuff it should > not have access to? > > For example, if it's possible to tell the system to power down a critical host > component through SCMI, what would prevent a guest requesting that > critical component from having its power cut? Short summary: SCMI as a protocol has built in requirements where only the resources (specific clock, sensor etc.) which are specifically needed by a VM are exposed to it. Resources are mapped by Identifiers and if the VM tries to access an identifier which it does not have access to, the SCMI backend can simply ignore or return DENIED. At no point is direct access to any power mgmt. hardware granted to any VM, nor is a VM supposed to have global access to all system resources. There is always a firmware backend which controls the hardware and services SCMI command requests from agents/guests, after due validation. The SCMI device/firmware which implements the SCMI backend, is responsible for implementing these resource isolation guarantees. Regards, Souvik > > I hope I'm barking up the wrong tree... > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Souvik Chakravarty <Souvik.Chakravarty@arm.com> To: Russell King - ARM Linux admin <linux@armlinux.org.uk>, Peter Hilber <peter.hilber@opensynergy.com> Cc: "virtio-comment@lists.oasis-open.org" <virtio-comment@lists.oasis-open.org>, "virtio-dev@lists.oasis-open.org" <virtio-dev@lists.oasis-open.org>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, Cristian Marussi <Cristian.Marussi@arm.com>, Sudeep Holla <Sudeep.Holla@arm.com>, "alex.bennee@linaro.org" <alex.bennee@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: [virtio-comment] RE: [PATCH v6] Add virtio SCMI device specification Date: Tue, 16 Feb 2021 16:48:30 +0000 [thread overview] Message-ID: <DBBPR08MB4790802EA436661E4AEEEFF682879@DBBPR08MB4790.eurprd08.prod.outlook.com> (raw) In-Reply-To: <20210216161208.GA1463@shell.armlinux.org.uk> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk> > Sent: Tuesday, February 16, 2021 4:12 PM > > On Fri, Feb 12, 2021 at 10:59:20AM +0100, Peter Hilber wrote: > > This patch proposes a new virtio device for the Arm SCMI protocol. > > > > The device provides a simple transport for the Arm SCMI protocol[1]. > > The *S*ystem *C*ontrol and *M*anagement *I*nterface protocol allows > > speaking to system controllers that allow orchestrating things like > > power management, system state management and sensor access. The > SCMI > > protocol is used on SoCs where multiple cores and co-processors need > > access to these resources. > > > > The virtio transport allows making use of this protocol in virtualized > > systems. > > > > [1] https://developer.arm.com/docs/den0056/c > > > > Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> > > I'm not too familiar with SCMI, but I think this question is worth asking... > > If the SCMI protocol can be used to control system level power management, > and if the intention is to expose this firmware interface to virtualised guests, > what prevents a guest from controlling the power settings for stuff it should > not have access to? > > For example, if it's possible to tell the system to power down a critical host > component through SCMI, what would prevent a guest requesting that > critical component from having its power cut? Short summary: SCMI as a protocol has built in requirements where only the resources (specific clock, sensor etc.) which are specifically needed by a VM are exposed to it. Resources are mapped by Identifiers and if the VM tries to access an identifier which it does not have access to, the SCMI backend can simply ignore or return DENIED. At no point is direct access to any power mgmt. hardware granted to any VM, nor is a VM supposed to have global access to all system resources. There is always a firmware backend which controls the hardware and services SCMI command requests from agents/guests, after due validation. The SCMI device/firmware which implements the SCMI backend, is responsible for implementing these resource isolation guarantees. Regards, Souvik > > I hope I'm barking up the wrong tree... > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2021-02-16 16:50 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-12 9:59 [PATCH v6] Add virtio SCMI device specification Peter Hilber 2021-02-12 9:59 ` [virtio-comment] " Peter Hilber 2021-02-15 13:20 ` Cristian Marussi 2021-02-16 15:11 ` Peter Hilber 2021-02-16 15:11 ` [virtio-comment] " Peter Hilber 2021-02-16 16:23 ` Cristian Marussi 2021-02-16 16:12 ` Russell King - ARM Linux admin 2021-02-16 16:48 ` Souvik Chakravarty [this message] 2021-02-16 16:48 ` [virtio-comment] " Souvik Chakravarty 2021-02-16 16:57 ` Russell King - ARM Linux admin 2021-02-16 17:31 ` Souvik Chakravarty 2021-02-16 17:31 ` [virtio-comment] " Souvik Chakravarty 2021-02-16 19:26 ` Peter Hilber 2021-02-16 19:26 ` [virtio-comment] " Peter Hilber 2021-03-11 17:19 ` Peter Hilber 2021-03-11 17:19 ` [virtio-comment] " Peter Hilber
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=DBBPR08MB4790802EA436661E4AEEEFF682879@DBBPR08MB4790.eurprd08.prod.outlook.com \ --to=souvik.chakravarty@arm.com \ --cc=Cristian.Marussi@arm.com \ --cc=Sudeep.Holla@arm.com \ --cc=alex.bennee@linaro.org \ --cc=jean-philippe@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@armlinux.org.uk \ --cc=peter.hilber@opensynergy.com \ --cc=virtio-comment@lists.oasis-open.org \ --cc=virtio-dev@lists.oasis-open.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.