All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: keir@xen.org, stefano.stabellini@eu.citrix.com,
	George Dunlap <george.dunlap@eu.citrix.com>,
	tim@xen.org, xen-devel@lists.xen.org, jbeulich@suse.com
Subject: Re: [PATCH] xen: arm: fully implement multicall interface.
Date: Tue, 01 Apr 2014 13:05:19 +0100	[thread overview]
Message-ID: <533AAB7F.4070009@linaro.org> (raw)
In-Reply-To: <1396350957.8667.108.camel@kazak.uk.xensource.com>

On 04/01/2014 12:15 PM, Ian Campbell wrote:
> On Tue, 2014-04-01 at 12:00 +0100, Julien Grall wrote:
>> On 04/01/2014 11:49 AM, Ian Campbell wrote:
>>> On Tue, 2014-04-01 at 11:46 +0100, Julien Grall wrote:
>>>> On 04/01/2014 10:28 AM, Ian Campbell wrote:
>>>>> On Tue, 2014-04-01 at 10:05 +0100, Julien Grall wrote:
>>>>>> Out-of-context, I've noticed that most of trap failure will kill the 
>>>>>> domain. From the ARM ARM , if a coprocessor instruction is failing, we 
>>>>>> should 	generate an Undefined Instruction exception (see P.7.5).
>>>>>
>>>>> You mean HSR_EC_CP15_32, HSR_EC_CP15_64 and HSR_EC_SYSREG?
>>>>>
>>>>> I've not checked but I think we only ask for traps for things which we
>>>>> are supposed to be able to handle, so anything which is trapped which we
>>>>> can't handle is a bug and would indicate the guest doing something
>>>>> funky.
>>>>
>>>> Right, but if the emulation of the instruction fails (see
>>>> vtimer_emulate, do_trap_psci,...), Xen will destroy the domain instead
>>>> of sending an UNDEF exception.
>>>
>>> My point was that the emulation should never fail...
>>
>> The emulation can fail if the guest decides to write on an RO register.
> 
> Hrm yes, I'd forgotten that case.
> 
> Is that an undef or some other sort of exception? Perhaps it depends on
> the cp register whether it faults or is ignored? In either case that
> seems to suggest that it is up to the specific handler to inject the
> correct kind of exception and return an appropriate error code to the
> generic handler.

The default exception is "undefined instruction". I didn't find any
specific exception following the coprocessor. Actually the only ways to
kill the domain in traps.c:
	- we try to access in read (resp. write) on WO (resp. RO) registers
	- the hypercall tags is wrong
	- the PSCI function is not implemented

I think we can replace every (?) domain_crash_synchronous by
inject_undef*_exception.

-- 
Julien Grall

  reply	other threads:[~2014-04-01 12:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28 14:07 [PATCH] xen: arm: fully implement multicall interface Ian Campbell
2014-03-28 14:07 ` [PATCH] arm: xen: implement multicall hypercall support Ian Campbell
2014-03-28 14:51   ` Julien Grall
2014-03-28 14:58     ` Ian Campbell
2014-04-01 11:02   ` David Vrabel
2014-04-01 11:13     ` Ian Campbell
2014-03-28 14:22 ` [PATCH] xen: arm: fully implement multicall interface Julien Grall
2014-03-28 14:37   ` Ian Campbell
2014-03-28 15:03     ` Jan Beulich
2014-04-01 10:01       ` George Dunlap
2014-03-28 14:45 ` Ian Campbell
2014-03-28 15:01   ` Julien Grall
2014-03-28 15:07     ` Ian Campbell
2014-03-31 16:38       ` George Dunlap
2014-04-01  9:05         ` Julien Grall
2014-04-01  9:28           ` Ian Campbell
2014-04-01 10:46             ` Julien Grall
2014-04-01 10:49               ` Ian Campbell
2014-04-01 11:00                 ` Julien Grall
2014-04-01 11:15                   ` Ian Campbell
2014-04-01 12:05                     ` Julien Grall [this message]
2014-04-01 12:11                       ` Ian Campbell
2014-04-01 12:16                         ` Julien Grall
2014-04-01 12:16                           ` Ian Campbell
2014-04-01 12:53                             ` Julien Grall

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=533AAB7F.4070009@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --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 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.