On 9/17/2020 1:30 PM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 15:59 +, Stewart Hildebrand wrote:
>> On Thursday, September 17, 2020 11:20 AM, Dario Faggioli wrote:
>>> On Thu, 2020-09-17 at 15:10 +, Stewart Hildebrand wrote:
> It might be worth to consider using just the core
On 9/17/2020 1:57 PM, Stewart Hildebrand wrote:
> On Thursday, September 17, 2020 12:19 PM, Andrew Cooper wrote:
>> On 17/09/2020 15:57, Stewart Hildebrand wrote:
>>> On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
>>>> On 16/09/2
On 9/17/2020 10:16 AM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 10:12 +0200, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> @@ -517,27 +516,35 @@ static const struct scheduler
>>> sched_arinc653_def = {
>>> .sch
On 9/17/2020 10:17 AM, Andrew Cooper wrote:
> On 17/09/2020 09:12, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> @@ -517,27 +516,35 @@ static const struct scheduler sched_arinc653_def = {
>>> .sched_id = XEN_SCHEDULER_ARINC653,
>
On 9/17/2020 10:17 AM, Andrew Cooper wrote:
> On 17/09/2020 09:12, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> @@ -517,27 +516,35 @@ static const struct scheduler sched_arinc653_def = {
>>> .sched_id = XEN_SCHEDULER_ARINC653,
>
On 9/17/2020 10:40 AM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 10:09 +0200, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> --- a/xen/common/sched/arinc653.c
>>> +++ b/xen/common/sched/arinc653.c
>>> @@ -119,10 +119,
>On Thu, 2020-09-17 at 13:09 +0100, Andrew Cooper wrote:
>> On 16/09/2020 19:18, Jeff Kubascik wrote:
>>> diff --git a/xen/common/sched/arinc653.c
>>> b/xen/common/sched/arinc653.c
>>> index 7bb75ffe2b..d8a23730c3 100644
>>> --- a/xen/common/sched/ari
On 9/17/2020 9:24 AM, Andrew Cooper wrote:
> On 16/09/2020 19:18, Jeff Kubascik wrote:
>> -/**
>> - * Retrieve the idle UNIT for a given physical CPU
>> +/*
>> + * Retrieve the idle UNIT for a given pCPU
>> */
>
> /** is also acceptable. We've inheri
The arinc653 module has function header comment blocks and other comment
inconsistencies not in line with the Xen coding style. This change
cleans up the code to better match the Xen coding style, and has no
functional changes.
Signed-off-by: Jeff Kubascik
---
xen/common/sched/arinc653.c | 229
with a
debugger.
- Added support for UNIT migration, which allows for pinning.
- In a653sched_adjust_global, removed a large structure from the stack,
moved a653sched_private dereference here.
Signed-off-by: Jeff Kubascik
---
xen/common/sched/arinc653.c | 844 +---
1 file
. The tests above were re-run and
no problems were identified. I'm looking for feedback on the patch set to so
that it may be accepted into the Xen code base.
Jeff Kubascik (5):
sched/arinc653: Clean up comments
sched/arinc653: Rename scheduler private structs
sched/arinc653: Clean up function
Function definitions in the arinc653 module did not follow the Xen
coding style. Furthermore, a few function names used a different prefix.
This change cleans up the definitions to be consistent with the Xen
coding style, and has no functional changes.
Signed-off-by: Jeff Kubascik
---
xen
This change is in preperation for an overhaul of the arinc653 module. It
groups functions in a logical order and fills out the sched_arinc653_def
structure. There are no functional changes.
Signed-off-by: Jeff Kubascik
---
xen/common/sched/arinc653.c | 239
The arinc653 module uses typedef struct with post fix tags for internal
structure definitions, which is not consistent with the Xen coding
style. This change cleans up the code to better match the style used
elsewhere in the Xen scheduler code, and has no functional changes.
Signed-off-by: Jeff
Thank you Juergen and Dario!
On 4/16/2020 12:09 PM, Dario Faggioli wrote:
> On Wed, 2020-04-15 at 11:08 +0200, Jürgen Groß wrote:
>> On 27.03.20 20:30, Jeff Kubascik wrote:
>>> For each UNIT, sched_set_affinity is called before unit->priv is
>>> updated
>>&g
, Jeff Kubascik wrote:
> For each UNIT, sched_set_affinity is called before unit->priv is updated
> to the new cpupool private UNIT data structure. The issue is
> sched_set_affinity will call the adjust_affinity method of the cpupool.
> If defined, the new cpupool may use unit->
still references the old cpupool private UNIT data structure.
This change fixes the bug by moving the switch of unit->priv earler in
the function.
Signed-off-by: Jeff Kubascik
---
Hello,
I've been working on updating the arinc653 scheduler to support
multicore for a few months now. In th
Hey Julien,
On 2/8/2020 7:05 AM, Julien Grall wrote:
> Hi Jeff,
>
> As you now handle GICR register, I would drop "dist" from the title.
>
Good catch, I missed this in the title.
> On 04/02/2020 19:51, Jeff Kubascik wrote:
>> Per the ARM Generic Interrupt Contro
-by: Jeff Kubascik
---
Changes in v3:
- Fixed spelling error in commit message
- Dropped misleading comments that were added in v2
- Added printk back in for default case
- Implemented RAZ/WI for the redist registers as well
- Update commit message to include GICR scope
---
xen/arch/arm/vgic-v3.c
Hey Julien,
On 2/1/2020 6:45 AM, Julien Grall wrote:
> Hi,
>
> On 31/01/2020 20:10, Jeff Kubascik wrote:
>> Per the ARM Generic Interrupt Controller Architecture Specification (ARM
>> IHI 0069E), reserved registers should generally be treated as RAZ/WI.
>> To
Per the ARM Generic Interrupt Controller Architecture Specification (ARM
IHI 0069E), reserved registers should generally be treated as RAZ/WI.
To simplify the VGICv3 design and improve guest compatability, treat the
default case for GICD registers as read_as_zero/write_ignore.
Signed-off-by: Jeff
Hello Julien,
On 1/29/2020 4:27 PM, Julien Grall wrote:
> Hi Jeff,
>
> On 21/01/2020 14:39, Jeff Kubascik wrote:
>> The VGICv3 module does not implement security extensions for guests.
>> Furthermore, per the ARM Generic Interrupt Controller Architecture
>> Specificati
On 1/23/2020 7:32 AM, Julien Grall wrote:
> Hi,
>
> On 21/01/2020 15:07, Jeff Kubascik wrote:
>> The physical timer traps apply an offset so that time starts at 0 for
>> the guest. However, this offset is not currently applied to the physical
>> counter. Per the ARMv
a physical timer. This removes the offset to make the timer and
counter consistent.
This also cleans up the physical timer implementation to better match
the virtual timer - both cval's now hold the hardware value.
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vtimer.c
-by: Jeff Kubascik
---
xen/arch/arm/vtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 0c78a65863..fed89498a9 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -211,7 +211,7 @@ static bool vtimer_cntp_tval
ges in v4:
- Improved commit message for patch #2, as suggested/provided by Julien
Jeff Kubascik (2):
xen/arm: remove physical timer offset
xen/arm: Sign extend TimerValue when computing the CompareValue
xen/arch/arm/vtimer.c| 34 ++
xen/include/asm-
On 1/18/2020 6:49 AM, Julien Grall wrote:
> On 17/01/2020 21:29, Jeff Kubascik wrote:
>> On 12/18/2019 9:24 AM, Julien Grall wrote:
>>> Hi Jeff,
>>>
>>> On 11/12/2019 21:13, Jeff Kubascik wrote:
>>>> Per the ARMv8 Reference Manual (ARM DDI 0487E.a)
the GICD_IGRPMODR register for guest VMs as RAZ/WI, to
avoid a data abort in the case the guest attempts to read or write the
register.
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vgic-v3.c| 8
xen/include/asm-arm/gic_v3_defs.h | 2 ++
2 files changed, 10 insertions(+)
diff --git
On 12/18/2019 9:24 AM, Julien Grall wrote:
> Hi Jeff,
>
> On 11/12/2019 21:13, Jeff Kubascik wrote:
>> Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4
>> specifies that the values in the TimerValue view of the timers are
>> signed in standard two's co
On 12/18/2019 9:20 AM, Julien Grall wrote:
> Hi Jeff,
>
> On 11/12/2019 21:13, Jeff Kubascik wrote:
>> The physical timer traps apply an offset so that time starts at 0 for
>> the guest. However, this offset is not currently applied to the physical
>> counter. Per the
; On 11/12/2019 21:13, Jeff Kubascik wrote:
>> This patch set improves the emulation of the physical timer by removing the
>> physical timer offset and sign extend the TimerValue to better match the
>> behavior described in the ARMv8 Reference Manual (ARM DDI 0487E.a), section
>&
= (Counter[63:0] + SignExtend(TimerValue))[63:0]
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 21b98ec20a..872181d9b6 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm
a physical timer. This removes the offset to make the timer and
counter consistent.
This also cleans up the physical timer implementation to better match
the virtual timer - both cval's now hold the hardware value.
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vtimer.c
this
Changes in v3:
- Split TimerValue sign extension fix into separate patch
- Update commit message to mention physical timer cleanup
- Removed physical timer cval initialization line
- Changed TimerValue sign extension to (uint64_t)(int32_t)*r
- Account for condition where cval < boot_count
J
On 12/5/2019 3:28 PM, Julien Grall wrote:
> Hi,
>
> On 05/12/2019 19:17, Jeff Kubascik wrote:
>> On 12/3/2019 1:04 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 26/11/2019 21:13, Jeff Kubascik wrote:
>>>> The physical timer traps apply an offse
On 12/3/2019 1:04 PM, Julien Grall wrote:
> Hi,
>
> On 26/11/2019 21:13, Jeff Kubascik wrote:
>> The physical timer traps apply an offset so that time starts at 0 for
>> the guest. However, this offset is not currently applied to the physical
>> counter. Per the ARMv
described by the equation
CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0]
Signed-off-by: Jeff Kubascik
---
Changes in v2:
- Update commit message to specify reference manual version and section
- Change physical timer cval to hold hardware value
- Make sure to sign extend TimerValue
On 11/26/2019 3:34 PM, Julien Grall wrote:
> Hi,
>
> On 26/11/2019 20:27, Jeff Kubascik wrote:
>> Add some background information on the BSP and instructions on how to
>> run the ticker application.
>>
>> Change-Id: I05050a335a938f00cc59bae69a014c5f04e05d23
>
Add some background information on the BSP and instructions on how to
run the ticker application.
Change-Id: I05050a335a938f00cc59bae69a014c5f04e05d23
---
bsps/arm/xen/README | 130 ++--
1 file changed, 64 insertions(+), 66 deletions(-)
diff --git
On 11/25/2019 5:07 PM, Julien Grall wrote:
> Hi,
>
> On 25/11/2019 16:14, Jeff Kubascik wrote:
>> The physical timer traps apply an offset so that time starts at 0 for
>> the guest. However, this offset is not currently applied to the physical
>> counter. Per the
On 11/25/2019 5:17 PM, Julien Grall wrote:
> Hi,
>
> On 25/11/2019 20:58, Jeff Kubascik wrote:
>> The tx/rx fifo flags were not set when the vpl011 is initialized. This
>> is a problem for certain guests that are operating in polled mode, as a
>> guest will generally c
pl011: Unexpected IN ring buffer empty" before the first valid
character is received. This initializes the flag status register to the
default specified in the PL011 technical reference manual.
Signed-off-by: Jeff Kubascik
Changes in v2:
- Moved uartfr initialization to later point in func
Hello,
On 11/25/2019 2:20 PM, Julien Grall wrote:
> Hi,
>
> On 25/11/2019 18:35, Jeff Kubascik wrote:
>> The tx/rx fifo flags were not set when the vpl011 is initialized. This
>> is a problem for certain guests that are operating in polled mode, as a
>> guest will
pl011: Unexpected IN ring buffer empty" before the first valid
character is received. This initializes the flag status register to the
default specified in the PL011 technical reference manual.
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vpl011.c | 2 ++
1 file changed, 2 insertions(+)
and counter consistent.
Xen time is at offset boot_count from the physical counter, so we need
to take this into account when reading/writing to CNTP_CVAL.
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vtimer.c| 18 ++
xen/include/asm-arm/domain.h | 3 ---
2 files changed, 6
On 11/21/2019 10:06 AM, Julien Grall wrote:> Hi,
>
> On 21/11/2019 14:31, Jeff Kubascik wrote:
>> On 11/19/2019 7:48 AM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 17/11/2019 22:32, Stewart Hildebrand wrote:
>>>> CC'ing Julien's new email add
On 11/19/2019 7:48 AM, Julien Grall wrote:
> Hi,
>
> On 17/11/2019 22:32, Stewart Hildebrand wrote:
>> CC'ing Julien's new email address
>
> For Xen-devel, I have filter to get in my inbox all e-mails where my
> @arm.com is CCed :).
>
>>
>> On Thursday, N
code in Xen to trap access to CNTPCT and
applying the offset - I can submit the patch if there is interest. However, I
was curious if there was an reason for not trapping/ emulating access to the
physical counter register and applying the offset?
Sinc
> On 8/30/19 10:28 AM, Wei Liu wrote:
>>> On Fri, Aug 23, 2019 at 10:08:55AM -0400, Jeff Kubascik wrote:
>>>> We would like to have a common maintainers email address for DornerWorks
>>>> maintained code, which currently is the ARINC653 scheduler. This will
&
On 8/23/2019 10:11 AM, George Dunlap wrote:
> CAUTION: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>> On Aug 23, 2019, at 3:08 PM, Jeff Kubascik
>> wr
We would like to have a common maintainers email address for DornerWorks
maintained code, which currently is the ARINC653 scheduler. This will
enable us to better monitor and respond to the Xen community. This patch
adds a maintainer line with the DornerWorks maintainers email address.
---
51 matches
Mail list logo
