14.05.2014 18:42, Greg Bellows пишет:
On 14 May 2014 00:53, Sergey Fedorov serge.f...@gmail.com wrote:
On 13.05.2014 20:15, Fabian Aggeler wrote:
arm_is_secure() function allows to determine CPU security state
if the CPU implements Security Extensions.
Signed-off-by: Sergey Fedorov
14.05.2014 10:06, Sergey Fedorov пишет:
On 13.05.2014 20:15, Fabian Aggeler wrote:
From: Sergey Fedorov s.fedo...@samsung.com
CPACR register allows to control access rights to coprocessor 0-13
interfaces. Bits corresponding to unimplemented coprocessors should be
RAZ/WI. QEMU implements
On 12/22/2013 05:08 AM, Peter Crosthwaite wrote:
On Sat, Dec 21, 2013 at 12:33 AM, Peter Maydell
peter.mayd...@linaro.org wrote:
On 20 December 2013 14:12, Fedorov Sergey s.fedo...@samsung.com wrote:
I've briefly looked at the v8 ARM ARM. As I can see there is no banked
system control
On 12/20/2013 06:33 PM, Peter Maydell wrote:
This sounds like it could work, though there are some wrinkles for
registers with readfns/writefns -- do we have extra s vs ns read/write
functions, or just one set of functions which has to look in env-ns to
figure out whether to use the S or NS
On 12/19/2013 03:38 PM, Peter Maydell wrote:
On 19 December 2013 07:27, Fedorov Sergey s.fedo...@samsung.com wrote:
Yes, this banking scheme makes state changing events quite heavy. But
maintaining the active copies allows to keep translation table walking code
untouched. I think
On 12/20/2013 06:33 PM, Peter Maydell wrote:
On 20 December 2013 14:12, Fedorov Sergey s.fedo...@samsung.com wrote:
I've briefly looked at the v8 ARM ARM. As I can see there is no banked
system control registers in AArch64. Seems the concept is changed to provide
separate registers for each
On 12/20/2013 06:38 PM, Fedorov Sergey wrote:
On 12/20/2013 06:33 PM, Peter Maydell wrote:
On 20 December 2013 14:12, Fedorov Sergey s.fedo...@samsung.com wrote:
I've briefly looked at the v8 ARM ARM. As I can see there is no banked
system control registers in AArch64. Seems the concept
On 12/19/2013 04:44 PM, Peter Crosthwaite wrote:
On Thu, Dec 19, 2013 at 9:38 PM, Peter Maydell peter.mayd...@linaro.org wrote:
On 19 December 2013 07:27, Fedorov Sergey s.fedo...@samsung.com wrote:
Yes, this banking scheme makes state changing events quite heavy. But
maintaining the active
On 12/19/2013 07:12 AM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov s.fedo...@samsung.com wrote:
Define a new ARM CP register info list for TrustZone Security Extension
feature. Register that list only for ARM cores with TrustZone support.
SCR and VBAR are security
On 12/19/2013 08:31 AM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov s.fedo...@samsung.com wrote:
Use c13_context field instead of c13_fcse for CONTEXTIDR register
definition.
This a standalone (I.E. not TZ related) bug?
Regards,
peter
Yes, I think so. Then I
On 12/19/2013 08:37 AM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov s.fedo...@samsung.com wrote:
Banked coprocessor registers are switched on two cases:
1) Entering or leaving CPU monitor mode with SCR.NS bit set;
2) Setting SCR.NS bit not from CPU monitor mode
On 12/17/2013 01:40 PM, Peter Crosthwaite wrote:
On Tue, Dec 17, 2013 at 7:20 PM, Sergey Fedorov s.fedo...@samsung.com wrote:
A single cast cache is used for both an object casting and a class
casting. In case of interface presence a class cast result may be not
the same pointer as opposite
This patch is a prerequisite for the following up TrustZone support patches.
Thanks.
Best regards,
Sergey Fedorov
On 12/10/2013 12:57 PM, Peter Maydell wrote:
On 10 December 2013 06:41, Sergey Fedorov s.fedo...@samsung.com wrote:
Current implementation is not accurate according to ARMv7-AR
On 12/03/2013 04:15 PM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov s.fedo...@samsung.com wrote:
TTBCR has additional fields PD0 and PD1 when using Short-descriptor
translation table format on a CPU with TrustZone feature support.
Signed-off-by: Sergey Fedorov
On 12/03/2013 04:17 PM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov s.fedo...@samsung.com wrote:
From: Svetlana Fedoseeva s.fedose...@samsung.com
Signed-off-by: Svetlana Fedoseeva s.fedose...@samsung.com
Signed-off-by: Sergey Fedorov s.fedo...@samsung.com
---
On 12/03/2013 04:51 PM, Peter Maydell wrote:
On 3 December 2013 12:20, Peter Crosthwaite
peter.crosthwa...@xilinx.com wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov s.fedo...@samsung.com wrote:
From: Svetlana Fedoseeva s.fedose...@samsung.com
Define CPU monitor mode. Adjust core
On 12/03/2013 12:48 PM, Sergey Fedorov wrote:
This patch set implements a basic support of CPU core TrustZone feature. The
following major functionalities are implemented:
* CPU monitor mode
* Separate code translation for each secure state
* CPACR NSACR co-processor access control
On 12/04/2013 03:18 PM, Peter Maydell wrote:
On 4 December 2013 10:58, Peter Crosthwaite
peter.crosthwa...@xilinx.com wrote:
So what im proposing is just a slightly more general patch. Is it
really any more complicated than just applying your change pattern for
the hyp mode?
I think it would
On 12/04/2013 03:13 PM, Peter Maydell wrote:
On 4 December 2013 10:08, Fedorov Sergey s.fedo...@samsung.com wrote:
On 12/03/2013 12:48 PM, Sergey Fedorov wrote:
This patch set implements a basic support of CPU core TrustZone feature.
We'd like this patch series finally to be merged
On 10/29/2013 06:55 PM, Stefan Hajnoczi wrote:
On Mon, Oct 21, 2013 at 03:44:46PM +0400, Fedorov Sergey wrote:
After our discussion about this patch I decided to keep my patch in
our branch until rebase onto a new release. Recently I have rebased
our branch onto v1.5.3 and reverted my patch
On 10/21/2013 03:52 PM, Fedorov Sergey wrote:
On 10/21/2013 03:44 PM, Fedorov Sergey wrote:
On 04/23/2013 04:00 PM, Stefan Hajnoczi wrote:
On Tue, Apr 23, 2013 at 11:41:42AM +0400, Fedorov Sergey wrote:
Beyond that, we also want to avoid growing net queues
indefinitely. If
the hub does
On 04/23/2013 04:00 PM, Stefan Hajnoczi wrote:
On Tue, Apr 23, 2013 at 11:41:42AM +0400, Fedorov Sergey wrote:
Beyond that, we also want to avoid growing net queues indefinitely. If
the hub does not implement .can_receive() then it relies on growing
queues (keeping packets buffered in memory
On 10/21/2013 03:44 PM, Fedorov Sergey wrote:
On 04/23/2013 04:00 PM, Stefan Hajnoczi wrote:
On Tue, Apr 23, 2013 at 11:41:42AM +0400, Fedorov Sergey wrote:
Beyond that, we also want to avoid growing net queues
indefinitely. If
the hub does not implement .can_receive() then it relies
On 04/22/2013 08:09 PM, Paolo Bonzini wrote:
Il 22/04/2013 17:27, Fedorov Sergey ha scritto:
E.g. network hub has 3 ports. Suppose when iterating through port list
in net_hub_port_can_receive() a packet is successfully delivered to the
first port, and then is queued in the source port queue
On 04/23/2013 10:58 AM, Stefan Hajnoczi wrote:
On Mon, Apr 22, 2013 at 07:27:21PM +0400, Fedorov Sergey wrote:
On 04/22/2013 06:57 PM, Stefan Hajnoczi wrote:
On Mon, Apr 22, 2013 at 04:26:16PM +0400, Fedorov Sergey wrote:
On 04/22/2013 03:47 PM, Stefan Hajnoczi wrote:
On Thu, Apr 18, 2013
On 04/23/2013 10:58 AM, Stefan Hajnoczi wrote:
On Mon, Apr 22, 2013 at 07:27:21PM +0400, Fedorov Sergey wrote:
On 04/22/2013 06:57 PM, Stefan Hajnoczi wrote:
On Mon, Apr 22, 2013 at 04:26:16PM +0400, Fedorov Sergey wrote:
On 04/22/2013 03:47 PM, Stefan Hajnoczi wrote:
On Thu, Apr 18, 2013
On 04/23/2013 03:48 PM, Stefan Hajnoczi wrote:
On Tue, Apr 23, 2013 at 01:32:11PM +0400, Fedorov Sergey wrote:
On 04/23/2013 10:58 AM, Stefan Hajnoczi wrote:
On Mon, Apr 22, 2013 at 07:27:21PM +0400, Fedorov Sergey wrote:
On 04/22/2013 06:57 PM, Stefan Hajnoczi wrote:
On Mon, Apr 22, 2013
On 04/23/2013 04:00 PM, Stefan Hajnoczi wrote:
On Tue, Apr 23, 2013 at 11:41:42AM +0400, Fedorov Sergey wrote:
Beyond that, we also want to avoid growing net queues indefinitely. If
the hub does not implement .can_receive() then it relies on growing
queues (keeping packets buffered in memory
On 04/22/2013 03:47 PM, Stefan Hajnoczi wrote:
On Thu, Apr 18, 2013 at 03:31:55PM +0400, Sergey Fedorov wrote:
Network hub should always receive incoming packets. Then forward them to
the appropriate port queue and let the qemu_send_packet() do the right
things. If the destination queue cannot
On 04/22/2013 06:57 PM, Stefan Hajnoczi wrote:
On Mon, Apr 22, 2013 at 04:26:16PM +0400, Fedorov Sergey wrote:
On 04/22/2013 03:47 PM, Stefan Hajnoczi wrote:
On Thu, Apr 18, 2013 at 03:31:55PM +0400, Sergey Fedorov wrote:
Network hub should always receive incoming packets. Then forward them
30 matches
Mail list logo
