Re: [PATCH v5 5/9] monitor: ARM SMC events

From: Tamas K Lengyel <tamas@tklengyel.com>
To: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Steve Capper <Steve.Capper@arm.com>
Subject: Re: [PATCH v5 5/9] monitor: ARM SMC events
Date: Sat, 4 Jun 2016 11:40:40 -0600	[thread overview]
Message-ID: <CABfawh=uNi=paxdV1kJVikm4izfU4jdevGDviuwn620k1OhMOQ@mail.gmail.com> (raw)
In-Reply-To: <20160604090352.GA16305@toto>

On Sat, Jun 4, 2016 at 3:03 AM, Edgar E. Iglesias
<edgar.iglesias@gmail.com> wrote:
> On Fri, Jun 03, 2016 at 09:34:20AM -0600, Tamas K Lengyel wrote:
>> On Fri, Jun 3, 2016 at 9:27 AM, Tamas K Lengyel <tamas@tklengyel.com> wrote:
>> >>>  > Furthermore, I think the vm_event app should only received SMCs whose
>> >>> condition has succeeded, because they will be actual SMC. The others
>> >>> should just be ignored.
>> >>>  >
>> >>>  > IHMO, the vm_event should only contain the immediate. The rest only
>> >>> matters for the hypervisor.
>> >>>
>> >>> Absolutely not! The primary usecase I have for SMC trapping is kernel
>> >>> execution monitoring by manually writing it into arbitrary kernel code
>> >>> locations and hiding them from the guest with mem_access. If some SMCs
>> >>> may silently get swallowed by the hypervisor the whole thing becomes
>> >>> unreliable.
>> >>
>> >>
>> >> Please read what I wrote, on ARMv8, a conditional SMC issued in AArch32
>> >> state *may* trap even if the condition has failed. I.e an implementer can
>> >> design its CPU to not trap them (see D1-1506 on ARM DDI 0487A.i).
>> >>
>> >> On ARMv7, only unconditional SMC and conditional SMC *which pass the
>> >> condition test* will be trapped. The others will be ignored.
>> >>
>> >> So even if the hypervisor send an event for each SMC trapped, you may not
>> >> receive all the SMCs. This is already unreliable by the architecture.
>> >>
>> >> If you want something reliable, you will have to inject unconditional SMC or
>> >> HVC which are always unconditional.
>> >
>> > Can you tell me how a conditional SMC would look like in memory? Would
>> > it be a variant of the instruction with the condition code mnemonic
>> > embedded in it, or the condition code is like another instruction
>> > following the SMC? From the ARM ARM it's not entirely clear to me
>> > (SMC{cond} #imm4). If it's the latter then we indeed need more work
>> > done during trapping since we would need to be aware of the context of
>> > where we are writing SMC and make sure the following condition check
>> > is also disabled. Otherwise we can just inject unconditional SMCs and
>> > case closed. Either way, we can swallow the SMCs with failed condition
>> > checks, but if it already trapped to the hypervisor, we might as well
>> > forward it to the vm_event subscriber if there is one and let it
>> > decide what it wants to do next (jump over the instruction or crash
>> > the domain being the only paths available).
>> >
>>
>> Never mind, found the info "This condition is encoded in ARM
>> instructions". So yes, we are always injecting unconditional SMCs for
>> monitoring so SMCs with failed condition checks are of no interest. My
>> comment above still stands though, we might as well forward these too
>> if they trapped to the VMM.
>>
>
> Hi,
>
> Forwarding SMC events for SMC insns that didn't pass the condition tests
> doesn't make any sense to me. It'll just make the receivers job harder.
> Why would a receiver want to do anything else than drop these?
> If it actually does look at them it'll be looking at implementation
> defined HW behaviour that may vary between CPU implementations.

If for no other purposes it may be useful to log them to be able to
study the CPU implementation's behavior.

Tamas

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