On 14.01.20 15:59, Ralf Ramsauer wrote:
On 1/14/20 3:37 PM, Jan Kiszka wrote:
On 14.01.20 15:26, Ralf Ramsauer wrote:
[...]
On 1/6/20 1:18 PM, Jan Kiszka wrote:
diff --git a/include/jailhouse/cell-config.h
b/include/jailhouse/cell-config.h
index a62fa1ee..f82bbe8d 100644
--- a/include/jailhouse/cell-config.h
+++ b/include/jailhouse/cell-config.h
@@ -129,6 +129,15 @@ struct jailhouse_memory {
__u64 flags;
} __attribute__((packed));
+#define JAILHOUSE_SHMEM_NET_REGIONS(start, dev_id) \
+ { \
+ .phys_start = start, \
+ .virt_start = start, \
+ .size = 0x100000, \
+ .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | \
+ JAILHOUSE_MEM_ROOTSHARED, \
+ }
+
In the end of the series, this makes calculation of .num_memory_region
unintuitive: the macro will eventually roll out to four memory regions.
Would it make sense to introduce a macro that denotes the number of
regions that are created by JAILHOUSE_SHMEM_NET_REGIONS?
What exactly do you propose? JAILHOUSE_SHMEM_NET_FOUR_REGIONS?
#define THREE 3
... No. This macro will change as soon as we have support for more than
two peers. If I understood the code correctly, then the number of
regions depends on the number of peers.
e.g.:
#define JAILHOUSE_SHMEM_NO_REGIONS(peers) (2 + peers)
[...]
.num_memory_regions = [123 + JAILHOUSE_SHMEM_NO_REGIONS(2) + ...]
Ah, ok. Feel free to propose that on top, at least the helper with one
or two users. The hard part of that is always editing the configs. I've
edited too many in the recent weeks...
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/0d310b2b-d421-2fe1-f650-64b801244fa2%40siemens.com.
