From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Cc: Volodymyr Babchuk <vlad.babchuk@gmail.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls
Date: Thu, 9 Feb 2017 21:01:26 +0100 [thread overview]
Message-ID: <20170209200126.GR12995@toto> (raw)
In-Reply-To: <CABfawhmmWAB-PDXuW4Mx-KO+_bWRwhVr7DZLU2AUA=Uy_fMMbQ@mail.gmail.com>
On Thu, Feb 09, 2017 at 12:42:09PM -0700, Tamas K Lengyel wrote:
> On Thu, Feb 9, 2017 at 11:39 AM, Julien Grall <julien.grall@arm.com> wrote:
> > Hi Tamas,
> >
> > On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:
> >>
> >> On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall <julien.grall@arm.com> wrote:
> >>>
> >>> On 08/02/2017 23:28, Tamas K Lengyel wrote:
> >>>>
> >>>> On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall <julien.grall@arm.com>
> >>>> wrote:
> >>>
> >>> You haven't understood my point. Xen is currently emulating PSCI call for
> >>> the guest to allow powering up and down the CPUs and other stuff. If you
> >>> decide to trap all the SMCs, you would have to handle them.
> >>
> >>
> >> Sure, it's more work on the monitor side, but other then that, what's
> >> the problem?
> >
> >
> > Because you will have to introduce hypercalls to get all the necessary
> > information from Xen that will not be available from outside.
>
> > Given that SMC has been designed to target different services (PSCI, Trusted
> > OS...) it would be normal to have monitor app only monitoring a certain set
> > of SMC call. You cannot deny a such use case as it would avoid an monitor
> > app to handle every single call that would be consumed by XEN but not
> > forwarded to the secure firmware.
> >
>
> I have nothing against introducing a fine-tune option to the SMC
> monitoring system so the monitor app can determine if it wants all
> SMCs or only a subset. At the moment I don't know of any usecase that
> would require this option. I certainly don't need it. If this option
> gets implemented by someone, I would be happy to take it.
Well, the reason it would be useful is the other way around.
On for example ZynqMP, enabling the monitor is useless since it will
turn off the ability to use the vital FW APIs needed for device
passthrough.
So the monitor only works for PV guests that call SMC APIs to some
imaginary Firmware.
While a monitor that didn't insist in consuming all SMC calls,
could very well be useful for monitoring/tracing purposes or
other stuff even with guests that actually use a "real" FW API.
I don't think we need to implement support for the latter right away,
we can incrementally add support for these things (I hope).
Cheers,
Edgar
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-09 20:01 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 19:41 [RFC v2 0/6] zynqmp: Add forwarding of platform specific firmware calls Edgar E. Iglesias
2017-02-07 19:42 ` [RFC v2 1/6] xen/arm: traps: Reorder early overwrite of FID Edgar E. Iglesias
2017-02-13 22:06 ` Stefano Stabellini
2017-02-07 19:42 ` [RFC v2 2/6] xen/arm: Introduce platform_hvc Edgar E. Iglesias
2017-02-13 22:08 ` Stefano Stabellini
2017-07-31 21:30 ` Edgar E. Iglesias
2017-02-07 19:42 ` [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls Edgar E. Iglesias
2017-02-07 20:38 ` Tamas K Lengyel
2017-02-07 20:51 ` Julien Grall
2017-02-08 0:24 ` Tamas K Lengyel
2017-02-08 8:31 ` Edgar E. Iglesias
2017-02-08 16:40 ` Tamas K Lengyel
2017-02-08 16:58 ` Julien Grall
2017-02-08 17:21 ` Tamas K Lengyel
2017-02-08 17:29 ` Edgar E. Iglesias
2017-02-08 19:40 ` Edgar E. Iglesias
2017-02-08 20:15 ` Tamas K Lengyel
2017-02-08 22:04 ` Julien Grall
2017-02-08 23:28 ` Tamas K Lengyel
2017-02-09 0:08 ` Julien Grall
2017-02-09 1:20 ` Stefano Stabellini
2017-02-09 9:12 ` Edgar E. Iglesias
2017-02-09 9:27 ` Edgar E. Iglesias
2017-02-09 18:22 ` Stefano Stabellini
2017-02-09 18:25 ` Tamas K Lengyel
2017-02-09 18:43 ` Stefano Stabellini
2017-02-09 19:32 ` Tamas K Lengyel
2017-07-31 22:23 ` Edgar E. Iglesias
2017-08-01 10:37 ` Julien Grall
2017-08-01 11:40 ` Edgar E. Iglesias
2017-02-09 16:46 ` Volodymyr Babchuk
2017-02-09 18:11 ` Tamas K Lengyel
2017-02-09 18:39 ` Julien Grall
2017-02-09 19:42 ` Tamas K Lengyel
2017-02-09 20:01 ` Edgar E. Iglesias [this message]
2017-02-09 20:36 ` Tamas K Lengyel
2017-02-09 14:46 ` Edgar E. Iglesias
2017-02-07 19:42 ` [RFC v2 4/6] xen/arm: Introduce call_smcc64 Edgar E. Iglesias
2017-02-13 22:11 ` Stefano Stabellini
2017-02-07 19:42 ` [RFC v2 5/6] xen/arm: zynqmp: Forward plaform specific firmware calls Edgar E. Iglesias
2017-02-14 0:02 ` Stefano Stabellini
2017-02-17 18:47 ` Julien Grall
2017-02-07 19:42 ` [RFC v2 6/6] xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node Edgar E. Iglesias
2017-02-14 0:03 ` Stefano Stabellini
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=20170209200126.GR12995@toto \
--to=edgar.iglesias@xilinx.com \
--cc=edgar.iglesias@gmail.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=tamas.k.lengyel@gmail.com \
--cc=vlad.babchuk@gmail.com \
--cc=xen-devel@lists.xen.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).