All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Corneliu ZUZU <czuzu@bitdefender.com>,
	Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Keir Fraser <keir@xen.org>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] vm_event: Implement ARM SMC events
Date: Wed, 13 Apr 2016 11:52:22 +0100	[thread overview]
Message-ID: <570E24E6.8030207@arm.com> (raw)
In-Reply-To: <570E0967.3070600@bitdefender.com>

Hello Corneliu,

On 13/04/16 09:55, Corneliu ZUZU wrote:
> On 4/12/2016 8:24 PM, Tamas K Lengyel wrote:
> Another issue came to my mind: "HVC #imm", if handled through the
> hvm-ops code, currently requires setting other registers to predefined
> values before the HVC is actually issued. That would imply additional
> effort to save/restore those registers if an external privileged domain
> would want to set guest breakpoints. Given that, if we were to use HVC
> for sw-bkpts, IMO it would be nice if the hvm-ops code architecture
> would be slightly changed such that -lone- "HVM #imm" calls would be
> achievable for some use cases, such as this.

That is not true. All the hypercalls are using the same #imm 
(XEN_HYPERCALL_TAG = 0xEA1), which indeed requires specific value in 
various registers to differentiate the HVM-ops.

It's up to us to define the requirements for the other #imm. For 
instance there are some #imm allocated for debugging (see do_debug_trap) 
that will dump the content of the registers.

>
>>
>> So what I will do instead of issuing a software_breakpoint vm_event
>> for SMCs, I'll introduce a new type, say
>> VM_EVENT_REASON_PRIVILEGED_CALL, that can be used to forward both
>> hypercalls and SMCs to a monitoring guest. This would also allow us to
>> use the software_breakpoint type for the actual software breakpoint
>> events in the future.
>>
>> Tamas
>
> Isn't the HVC-part already achieved by guest-request vm-events? Maybe
> tying this vm-event specifically to SMC (in which case the name could be
> something like VM_EVENT_REASON_SECURE_CALL) and thus making it
> ARM-specific would avoid that redundancy?

I would create 2 distinct events for HVC and SMC. It would make easier 
to differentiate them in userspace.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-04-13 10:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-11 19:47 [PATCH] vm_event: Implement ARM SMC events Tamas K Lengyel
2016-04-12  4:31 ` Jan Beulich
2016-04-12  5:35   ` Razvan Cojocaru
2016-04-12 15:08     ` Tamas K Lengyel
2016-04-12 15:05   ` Tamas K Lengyel
2016-04-12 15:58     ` Julien Grall
2016-04-12 17:58       ` Tamas K Lengyel
2016-04-12  7:51 ` Corneliu ZUZU
2016-04-12 15:01   ` Tamas K Lengyel
2016-04-12 16:24     ` Julien Grall
2016-04-12 17:05       ` Corneliu ZUZU
2016-04-12 17:24         ` Tamas K Lengyel
2016-04-13  8:55           ` Corneliu ZUZU
2016-04-13 10:17             ` Andrew Cooper
2016-04-13 10:53               ` Corneliu ZUZU
2016-04-13 12:02                 ` Andrew Cooper
2016-04-13 13:25                   ` Tamas K Lengyel
2016-04-13 15:06                     ` Lars Kurth
2016-04-13 15:13                       ` Tamas K Lengyel
2016-04-13 10:52             ` Julien Grall [this message]
2016-04-13 11:02               ` Corneliu ZUZU
2016-04-13 15:32             ` Tamas K Lengyel
2016-04-12 14:55 ` Konrad Rzeszutek Wilk
2016-04-12 15:22   ` Tamas K Lengyel

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=570E24E6.8030207@arm.com \
    --to=julien.grall@arm.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=czuzu@bitdefender.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=rcojocaru@bitdefender.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas.k.lengyel@gmail.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.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.