All of lore.kernel.org
 help / color / mirror / Atom feed
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/


  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: 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.