Re: 回复:Re: 回复:Re: The design of vCPU.

2014-06-12 Thread shenyouren
Sent via Xiaomi On Gedare Bloom , Jun 12, 2014 11:54 PM wrote: > > On Thu, Jun 12, 2014 at 11:37 AM, shenyouren wrote: > > > >> >> > >> >> Hi, > >> >> > >> >> can you please evaluate, which pieces already implemented in > >> >> pok/kernel/* can be reu

Re: 回复:Re: 回复:Re: The design of vCPU.

2014-06-12 Thread Gedare Bloom
On Thu, Jun 12, 2014 at 11:37 AM, shenyouren wrote: > >> >> >> >> Hi, >> >> >> >> can you please evaluate, which pieces already implemented in >> >> pok/kernel/* can be reused to build the vCPU structure? >> > I don't think there are lot of code which can be reused. The vCPU is a >> > new concept

回复:Re: 回复:Re: The design of vCPU.

2014-06-12 Thread shenyouren
> >> > >> Hi, > >> > >> can you please evaluate, which pieces already implemented in > >> pok/kernel/* can be reused to build the vCPU structure? > > I don't think there are lot of code which can be reused. The vCPU is a > > new concept in POK. I can only figure out that the context store/re

Re: 回复:Re: The design of vCPU.

2014-06-12 Thread Philipp Eppelt
On 06/12/2014 04:34 PM, shenyouren wrote: > Philipp Eppelt >于 2014年6月12日 下午9:50 > 写道: >> >> Hi, >> >> can you please evaluate, which pieces already implemented in >> pok/kernel/* can be reused to build the vCPU structure? > I don't think there are lot o

Re: [PATCH] score: PR2181: Add _Thread_Yield()

2014-06-12 Thread Gedare Bloom
Good. On Thu, Jun 12, 2014 at 10:19 AM, Sebastian Huber wrote: > The _Scheduler_Yield() was called by the executing thread with thread > dispatching disabled and interrupts enabled. The rtems_task_suspend() > is explicitly allowed in ISRs: > > http://rtems.org/onlinedocs/doc-current/share/rtems/

Re: 回复:Re: The design of vCPU.

2014-06-12 Thread Gedare Bloom
On Thu, Jun 12, 2014 at 10:34 AM, shenyouren wrote: > Philipp Eppelt 于 2014年6月12日 下午9:50写道: > > >> >> Hi, >> >> can you please evaluate, which pieces already implemented in >> pok/kernel/* can be reused to build the vCPU structure? > I don't think there are lot of code which can be reused. The vCP

回复:Re: The design of vCPU.

2014-06-12 Thread shenyouren
Philipp Eppelt 于 2014年6月12日 下午9:50写道: > > Hi, > > can you please evaluate, which pieces already implemented in > pok/kernel/* can be reused to build the vCPU structure? I don't think there are lot of code which can be reused. The vCPU is a new concept in PO

[PATCH] score: PR2181: Add _Thread_Yield()

2014-06-12 Thread Sebastian Huber
The _Scheduler_Yield() was called by the executing thread with thread dispatching disabled and interrupts enabled. The rtems_task_suspend() is explicitly allowed in ISRs: http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/Interrupt-Manager-Directives-Allowed-from-an-ISR.html#Interrup

Re: The design of vCPU.

2014-06-12 Thread Philipp Eppelt
Hi, can you please evaluate, which pieces already implemented in pok/kernel/* can be reused to build the vCPU structure? Also, how the vCPU structure can be build on top of / merged into the partition structure. Cheers, Philipp On 06/12/2014 12:00 PM, Philipp Eppelt wrote: > Hi, > > I think we

RE: [PATCH 3/3] smpschedsem01: New test Test to verify task priority is inherited from a semaphore.

2014-06-12 Thread Jennifer Averett
All the *.doc and *.scn are incorrect. They will be updated to match the tests. > -Original Message- > From: Jennifer Averett > Sent: Thursday, June 12, 2014 8:15 AM > To: Jennifer Averett; Sebastian Huber > Cc: rtems-de...@rtems.org > Subject: RE: [PATCH 3/3] smpschedsem01: New test Te

RE: [PATCH 3/3] smpschedsem01: New test Test to verify task priority is inherited from a semaphore.

2014-06-12 Thread Jennifer Averett
Sorry looking at the wrong test. This test is one that Joel asked me to add for each Schedulers that just verifies that priority is inherited from a higher priority semaphore when it is obtained. I thought I had fixed the doc files for the tests but must have missed this one. > -Origina

RE: [PATCH 3/3] smpschedsem01: New test Test to verify task priority is inherited from a semaphore.

2014-06-12 Thread Jennifer Averett
The test verifies that when you start a task with affinity of core X it runs on core X. It's a c version of one of the scenarios that test the affinity scheduler. > -Original Message- > From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] > Sent: Thursday, June 12, 2014 8:07

Re: [PATCH 3/3] smpschedsem01: New test Test to verify task priority is inherited from a semaphore.

2014-06-12 Thread Sebastian Huber
On 2014-06-11 21:18, jennifer wrote: +++ b/testsuites/smptests/smpschedsem01/smpschedsem01.doc @@ -0,0 +1,11 @@ +This file describes the directives and concepts tested by this test set. + +test set name: smpschedaffinity01 + +directives: + + - XXX + +concepts: + + - Ensure that affinity is hono

[PATCH 2/3] smptests: Add simple tests for affinity priority scheduler. Tests for setting affinity of primary and secondary tasks.

2014-06-12 Thread jennifer
From: Jennifer Averett --- testsuites/smptests/Makefile.am| 3 + testsuites/smptests/configure.ac | 3 + testsuites/smptests/smpschedaffinity02/Makefile.am | 19 ++ testsuites/smptests/smpschedaffinity02/init.c | 230 + .../smps

[PATCH 3/3] smpschedsem01: New test Test to verify task priority is inherited from a semaphore.

2014-06-12 Thread jennifer
From: Jennifer Averett --- testsuites/smptests/Makefile.am| 1 + testsuites/smptests/configure.ac | 1 + testsuites/smptests/smpschedsem01/Makefile.am | 19 + testsuites/smptests/smpschedsem01/init.c | 94 ++ .../smpt

[PATCH 1/3] smpschedaffinity01: New test. This test verifies that affinity is honored when set prior to task start.

2014-06-12 Thread jennifer
From: Jennifer Averett --- testsuites/smptests/Makefile.am| 1 + testsuites/smptests/configure.ac | 1 + testsuites/smptests/smpschedaffinity01/Makefile.am | 19 +++ testsuites/smptests/smpschedaffinity01/init.c | 173 + .../smp

Re: The design of vCPU.

2014-06-12 Thread Philipp Eppelt
Hi, I think we have to chose the 'host model'. In order to provide separation POK puts (at least some) device drivers (network card) into their own partitions and offers a kernel supervised communication interface. (If this is new, read the POK paper by Julien.) This also implies some restriction