[V1] *** struct jailhouse_system attribute refactor ***

2016-06-23 Thread Xuguo Wang 
***
In the config of the jailhouse_system, the attribute named
root_cell actually is the config of the root_cell, so the
root_cell_config is better, special in the cell file,
like:
.root_cell_config = {
***

Xuguo Wang (1):
  struct jailhouse_system: The attribute of this struct named
"root_config".

 configs/bananapi.c | 2 +-
 configs/f2a88xm-hd3.c  | 2 +-
 configs/h87i.c | 2 +-
 configs/imb-a180.c | 2 +-
 configs/jetson-tk1.c   | 2 +-
 configs/qemu-vm.c  | 2 +-
 configs/vexpress.c | 2 +-
 driver/main.c  | 8 
 hypervisor/control.c   | 4 ++--
 hypervisor/include/jailhouse/cell-config.h | 6 +++---
 hypervisor/setup.c | 2 +-
 11 files changed, 17 insertions(+), 17 deletions(-)

-- 
2.5.0

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v3 00/13] preparatory patch series for Jailhouse AArch64 support

2016-06-23 Thread Jan Kiszka 
On 2016-06-23 20:37, Jan Kiszka wrote:
> On 2016-06-23 10:27, Jan Kiszka wrote:
>> I've merged this series with two modifications (build fix for patch 8,
>> slight refactoring of patch 10) into next. I've also rebased my
>> wip/arm64 mirror with the remaining patches on top (trivial conflict in
>> .travis.yml). Still works on ARM, tests on the Seattle pending.
> 
> Bad news: there seems to be a regression with my branch compared to a
> state from February: interrupts no longer work for the second NIC when
> assigned to a non-root Linux cell. Does this work for you?

Interestingly, the UART does generate some:

# cat /proc/interrupts
   CPU0   CPU1
  1:  0  0   GIC  29 Edge  arch_timer
  2:   1263   1307   GIC  30 Edge  arch_timer
  3:104  0   GIC 360 Level uart-pl011
  4:  0  0   GIC 354 Level eth0-pcs
  5:  0  0   GIC 356 Level eth0
  6:  0  0   GIC 373 Edge  eth0-TxRx-0
  7:  0  0   GIC 374 Edge  eth0-TxRx-1

Please cross-check, then we can decide who may do some bisecting... :-/

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Interrupt limit

2016-06-23 Thread Jan Kiszka 
On 2016-06-23 13:47, Valentine Sinitsyn wrote:
> On 23.06.2016 14:35, Jan Kiszka wrote:
>> On 2016-06-23 13:28, Valentine Sinitsyn wrote:
>>> Hi Jan,
>>>
>>> On 23.06.2016 13:53, Jan Kiszka wrote:
 On 2016-06-23 11:33, Valentine Sinitsyn wrote:
> Hi all,
>
> What is the semantics of system_config->interrupt_limit field?
>
> Am I right that this is a maximum number of distinct interrupt
> messages
> a board is allowed to generate? Or is it an architectural limit for
> the
> number of vectors?

 In practice, it is the maximum number of distinct interrupt sources to
 expect on Intel systems, used to size the IR table appropriately (on
 AMD, they are device-bound, so you shouldn't have a need for this). As
 we have no SMMU for ARM yet, I'm not sure if there will be a reuse. If
 not, we can make it x86-only.
>>> I'm inclined to have a single shared interrupt table on AMD as well. We
>>> don't have a subpage allocator in Jailhouse (I've sketched one last
>>> night, but it didn't go really well), and handing off page-sized tables
>>> to devices needing only a single IRTE seems to be a waste. So knowing
>>> the size of the table in advance is also convenient.
>>
>> Ah, you have per-device table references, but they could point to a
>> single table. Then the limit would be relevant for AMD as well.
>>
>> But how would you identify / filter the sources then? In contrast to
>> VT-d IRTEs, you do not seem to have source ID matching with AMD IRTEs,
>> do you?
> That's true. I think I'll store a reverse mapping from bdf to the offset
> within single table, much like amd_iommu driver does in the Linux kernel.

So you will have one forward table per cell in order to achieve
partitioning? That may work... In Intel, there is a single table for
them all, and source matching is used for partitioning.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[siemens/jailhouse] 7d6808: ci: Update CA certificates to unbreak Coverity bui...

2016-06-23 Thread GitHub 
  Branch: refs/heads/coverity_scan
  Home:   https://github.com/siemens/jailhouse
  Commit: 7d68082e71d8747c8111656e550ebd0950e7e87f
  
https://github.com/siemens/jailhouse/commit/7d68082e71d8747c8111656e550ebd0950e7e87f
  Author: Jan Kiszka 
  Date:   2016-06-23 (Thu, 23 Jun 2016)

  Changed paths:
M .travis.yml

  Log Message:
  ---
  ci: Update CA certificates to unbreak Coverity build

See https://github.com/travis-ci/docs-travis-ci-com/pull/617

Signed-off-by: Jan Kiszka 


-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.