14.05.2014 10:06, Sergey Fedorov пишет:
> On 13.05.2014 20:15, Fabian Aggeler wrote:
>> From: Sergey Fedorov
>>
>> CPACR register allows to control access rights to coprocessor 0-13
>> interfaces. Bits corresponding to unimplemented coprocessors should be
>> RAZ/WI. QEMU implements only VFP copro
14.05.2014 18:42, Greg Bellows пишет:
> On 14 May 2014 00:53, Sergey Fedorov 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
>>> Signed-
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
On 12/22/2013 05:08 AM, Peter Crosthwaite wrote:
> On Sat, Dec 21, 2013 at 12:33 AM, Peter Maydell
> wrote:
>> On 20 December 2013 14:12, Fedorov Sergey wrote:
>>> I've briefly looked at the v8 ARM ARM. As I can see there is no banked
>>> system control regi
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 wrote:
>>> I've briefly looked at the v8 ARM ARM. As I can see there is no banked
>>> system control registers in AArch64.
On 12/20/2013 06:33 PM, Peter Maydell wrote:
> On 20 December 2013 14:12, Fedorov Sergey 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 reg
On 12/19/2013 03:38 PM, Peter Maydell wrote:
On 19 December 2013 07:27, Fedorov Sergey 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 there is a trade-off between state
On 12/19/2013 04:44 PM, Peter Crosthwaite wrote:
On Thu, Dec 19, 2013 at 9:38 PM, Peter Maydell wrote:
On 19 December 2013 07:27, Fedorov Sergey wrote:
Yes, this banking scheme makes state changing events quite heavy. But
maintaining the active copies allows to keep translation table
On 12/19/2013 08:37 AM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov 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
Coprocessor register bank
On 12/19/2013 08:31 AM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov 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 will submit this patch se
On 12/19/2013 07:12 AM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov 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 extension registers. S
On 12/17/2013 01:40 PM, Peter Crosthwaite wrote:
On Tue, Dec 17, 2013 at 7:20 PM, Sergey Fedorov 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 to an object casting. S
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 wrote:
Current implementation is not accurate according to ARMv7-AR reference
manual. See "
On 12/04/2013 03:13 PM, Peter Maydell wrote:
On 4 December 2013 10:08, Fedorov Sergey 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 into mainstream. What
s
On 12/04/2013 03:18 PM, Peter Maydell wrote:
On 4 December 2013 10:58, Peter Crosthwaite
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 be, because of the wrinkle th
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/03/2013 04:51 PM, Peter Maydell wrote:
On 3 December 2013 12:20, Peter Crosthwaite
wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov wrote:
From: Svetlana Fedoseeva
Define CPU monitor mode. Adjust core registers banking. Adjust CPU VM
state info. Provide CPU mode name for monitor
On 12/03/2013 04:17 PM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov wrote:
From: Svetlana Fedoseeva
Signed-off-by: Svetlana Fedoseeva
Signed-off-by: Sergey Fedorov
---
target-arm/helper.c |4
1 file changed, 4 insertions(+)
diff --git a/target-arm/h
On 12/03/2013 04:15 PM, Peter Crosthwaite wrote:
On Tue, Dec 3, 2013 at 6:48 PM, Sergey Fedorov 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
---
target-arm/helper.c
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 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
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/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/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 at
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/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/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
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 r
30 matches
Mail list logo
