e JTAG which understands virtualization, and allows
you to debug DomU.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
the
kernel crashed in earliest stages.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
oid/' shows nothing, but using 'Ctrl + 5' or 'Ctrl + ]' closes the
console. Am I missing something here?
What kernel do you use for DomU? Please make sure you have in that
kernel configuration XEN support enabled (together with hypervisor
console support).
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Dear Oleksandr,
Please consider my `Reviewed-by: Andrii Anisov `
for all patches.
What you missed after extracting this stuff from github.
On 09.11.17 19:09, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
--
*Andrii Anisov
main 4:unable
to add disk devices
libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain
4:Non-existant domain
libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain
4:Unable to destroy guest
libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain
4:Destruction of domain failed
/
Any input would be highly appreciated
BTW, what is your dom0 system? Does it have bash?
Long time ago, we had busybox in dom0, and used
https://marc.info/?l=xen-devel&m=146358920813936&w=4 to workaround block
device creation issues.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
From: Andrii Anisov
/var/log could be a tmpfs mount point, so create xen subfolder at runtime.
Signed-off-by: Andrii Anisov
Reviewed-by: Volodymyr Babchuk
Reviewed-by: Oleksandr Andrushchenko
---
tools/hotplug/Linux/init.d/xencommons.in | 1 +
1 file changed, 1 insertion(+)
diff --git a
cores,
partitioning would be a significant resources wasting for described
scenario.
How feasible is it from your point of view?
BTW, are you targeting XEN 4.10 with this patch series?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel
Hello Dario,
On 28.09.17 19:01, Dario Faggioli wrote:
On Thu, 2017-09-28 at 12:18 +0300, Andrii Anisov wrote:
- Could you please provide an example input xml for CARTS
described a
system with 2 RT domains with 2 VCPUs each, running on a 2PCPUs,
with gEDF
scheduling at VMM level (for XEN
alculation for all periods in between, but did not provide the
best period to get system schedulable.
You should set them to the same value.
Ok, how to chose the value for some taskset in a component?
--
*Andrii Anisov*
___
Xen-devel mailing list
/os_scheduler in CARTS description files. If I have them
different, CARTS gives calculation for all periods in between, but did
not provide the best period to get system schedulable.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
description? My intention is to have a set of generated
input xml's, feed them to CARTS and get models ready to be parsed to
receive domains configuration for each test case.
[1] https://rtg.cis.upenn.edu/carts/docs/userguide.pdf
--
*Andrii Anisov*
_
[1].
[1]
https://github.com/xen-troops/linux/commit/b4eec1abd5e683133ce8e326ced1986e7c65976a
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
following:
(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch
input to DOM0)
Then you can press 'h' for seeing installed key handlers.
But all of this requires XEN to be running somehow.
--
*Andrii Anisov*
_
w.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 21.08.17 11:07, Andrii Anisov wrote:
Hello Meng Xu,
On 18.08.17 23:43, Meng Xu wrote:
The Section 4.1 and 4.2 in [1] explained the whole experiment steps.
If you have any question or confusion on a specific step, please feel
free to let me know.
From the document it is not really clear if
simultaneously for your experiments.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hello Edgar,
I'm just wondering if you have had a chance to play with SCF?
Please do not hesitate to come up with questions and comments. We are
extremely interested in them to make the thing better.
--
*Andrii Anisov*
___
Xen-devel mailing
r 4GB.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
cally lack of DMA-able RAM can lead
to network malfunction.
So the question is if it's a real cause, and why XEN does not allocate
whole under-4GB RAM to dom0.
--
*Andrii Anisov*
*
*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lis
how to resume Dom0, i.e. how to hand over control to Dom0?
+
+==
+References
+==
+
+[1] Power State Coordination Interface (ARM):
+http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
+
--
*Andrii Anisov*
_
On 03.08.17 16:58, Andrii Anisov wrote:
Let me check with a block device root.
It does work with root on mmcblk1p1.
So I suggest to George to update his XEN by moving to 4.9 or by
backporting mentioned patch.
Not sure what is broken for nfs-root. Would not deal with it now, maybe
later
x27;m not comparing, just checked on my table with my current setup.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 03.08.17 16:38, Andrii Anisov wrote:
If I recall correctly related issue was fixed in 4.9.
It's ugly.
I've reproduced the setup on my table, with the current master. It does
not work.
XEN allocated Dom0 memory properly:
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading k
RAM under 4GB mark and the rest 3GB
above.
Moreover 128MB from the RAM below 4GB mark are taken for secure world.
If I recall correctly related issue was fixed in 4.9.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
tps://github.com/xen-troops/xen/blob/vgpu-dev/xen/arch/arm/coproc/coproc.h#L81
[3] https://github.com/xen-troops/xen/tree/vgpu-dev
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
t take too much efforts.
I'll have a look, thanks!
Do not hesitate to contact us in case you need any help or clarification.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
above is feasible even with current SCF
code and will not take too much efforts.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01935.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
017-07/msg02124.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hello Meng Xu,
I've get back to this stuff.
On 03.07.17 17:58, Andrii Anisov wrote:
That's why we are going to keep configuration (of guests and
workloads) close to [1] for evaluation, but on our target SoC.
I'm wondering if there are known issues or specifics for
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm32/debug-8250.inc | 12 +++--
xen/arch/arm/arm32/debug-exynos4210.inc | 12 +++--
xen/arch/arm/arm32/debug-pl011.inc | 18 +---
xen/arch/arm/arm32/debug-scif.inc | 6 ++-
xen/arch/arm/arm32/debug.S
From: Andrii Anisov
Introduce an earlyprintk configuration for R-Car Gen3 SoC based development
boards, like:
- Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X]
- M3ULCB [http://elinux.org/R-Car/Boards/M3SK]
- H3ULCB [http://elinux.org/R-Car/Boards/H3SK]
Signed-off-by: Iurii
From: Iurii Konovalenko
Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs.
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
Signed-off-by: Andrii Anisov
---
Changes in v2:
- fixed register names in comments and their coding style
---
xen/arch/arm
for reserved memory as this will not be managed by the memory allocator.
So that is the question to the reserved-memory support design. And
should be considered during the choosing the approach (manage it with
existing allocator, or implement something aside)
--
*Andrii A
de an example of a security impact?
Furthermore, using the weakest one would imply cache maintenance when
the region is assigned/deassigned to/from a domain to prevent leaking
data.
Could you please provide an example scenario for data leakage?
--
*Andrii A
your point.
write-back cacheable is quite weak attribute for stage-2. Is that safe?
I guess the domain should drive the resultant cacheability because it
knows how that memory region will be used. So the weakest write-back
cacheability is the right choice. Is my understanding correct?
--
*A
Hello Julien,
On 26.07.17 18:33, Julien Grall wrote:
On 26/07/17 16:25, Andrii Anisov wrote:
+ Stefano as a maintainer.
Dear all,
Any objections on this patch?
I would have appreciated to be CC as well...
Somewhy I though you are in the thread of this patch as well.
Sorry for my miss
+ Stefano as a maintainer.
Dear all,
Any objections on this patch?
On 05.07.17 19:29, Andrii Anisov wrote:
From: Andrii Anisov
Introduce an earlyprintk configuration for R-Car Gen3 SoC based development
boards, like:
- Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X]
- M3ULCB
+ Stefano as a maintainer.
Dear all,
Any objections on this patch?
On 05.07.17 19:29, Andrii Anisov wrote:
From: Iurii Konovalenko
Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs.
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
Signed-off-by
emory node. But from
this point of view, it is not clear if the size of the reserved region
should be accounted during RAM space allocation for the domain.
Another question: what caching attributes do they need in the stage2 mapping?
I guess Write-Back Cacheable should be sufficient.
--
*And
move in that direction instead of pushing changes into hypervisor.
If the vendor is not willing to do it, then we can discuss about
implementing a fix in Xen.
I had it in my mind as a generic stuff. Partially inspired by LK approach.
--
*Andrii A
this until we get rid of the
Xen specific R-Car device tree on the wiki.
IMO, we it should appear correspondent functionality in XEN first, and
latter get rid of specific device tree on the wiki. So that we will have
the wiki steps adequate to the current master.
--
*And
early mentioned options:
On 25.07.17 15:24, Andrii Anisov wrote:
* ignore next duplicating (overlapping) memory node in favor of one
already in a memory banks list
* merge duplicating (overlapping), even neighboring, memory banks
On 25.07.17 19:23, Andrew Cooper wrote:
It might be the case
ience there were no
good result.
[1]
https://github.com/xen-troops/meta-demo/tree/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas
[2]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X#Running_the_system
--
*Andrii A
or an advice.
[1]
https://github.com/xen-troops/meta-demo/blob/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas/r8a7795-salvator-x-xen.dts#L61
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
uring
* compatible regions are merged) after the addition.
*
* RETURNS:
* 0 on success, -errno on failure.
*/
IMO the function description is pretty straight-forward.
But let us wait for device tree guys feedback.
--
*Andrii A
* existing regions. @type is guaranteed to be minimal (all
neighbouring
* compatible regions are merged) after the addition.
*
* RETURNS:
* 0 on success, -errno on failure.
*/
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ion to the clang-format. Could you please point us to the
mailing list thread where details are discussed.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
)
Well, actually I supposed HYP mode is not enabled. It was tricky some
time ago, not sure if it was upstreamed to u-boot.
But yep, mentioned print is after HYP mode check.
IMHO the log starting from the board power on moment will provide more
precise info about the situation.
--
*Andrii Anisov
use solely, it can share that
display to other domains using displif protocol [1].
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00470.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
Dear All,
During the developers summit a Shared Coprocessor Framework (SCF)
concept was presented. One of the topics discussed was a shared
coprocessor configuration.
The SCF itself is intended to share coprocessor (i.e. GPU, DPS, FPGA,
whatever) resources to guest domains [1][2].
We are t
. DSP running
different FW for different domains, etc).
- If someone is willing to take a part in SCF design and
development (core, API)?
- If someone is willing to implement their coprocessor support
(driver) for SCF?
I look forward to hearing from you.
--
*Andrii Anisov
Dear Ajeesh,
I'm just courious, are you using an updated wiki [1]?
[1]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
tree and
use it. Also do not forget to update ATF on the board.
This should be enough.
What all should i look in a Hardware to run XEN in it?
If we are speaking about ARM, then:
- SoC should be VE/EL2 capable
- Bootloader should be able to start XEN in HYP/EL2.
--
*Andrii Anisov
From: Andrii Anisov
Both Renesas R-Car Gen2(ARM32) and Gen3(ARM64) are utilizing SCIF IP,
so make its serial driver built by default for ARM.
Signed-off-by: Andrii Anisov
---
xen/drivers/char/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/char
hree years ago.
BTW, I'm really surprised you have an OMAP5 based board. Which actually
do you have?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Dear Christopher,
On 18.07.17 12:08, Andrii Anisov wrote:
In order to build the required system, a board candidate should:
- have a CPU able to switch to EL2/Virtualization mode
- have a public bootloader sources able to switch CPU to
EL2/Virtualizaiotn mode
- have a Linux system
ar h3 board.?
It really depends on the setup you need.
GPU sharing is not strictly tied to display sharing. So you could split
DUs between domains, or utilize some PV Display driver implementing [1].
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg00470.html
--
*Andrii A
reely available
- have an Android sources freely available
Jacinto6 EVM is known to me as a board satisfying all the above. It is
built around SoC utilizing CA15. The pitfall here is that the board
itself is not freely available and is far too expensive.
--
*Andrii A
roject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hello Meng Xu,
On 07.07.17 21:43, Meng Xu wrote:
Andrii,
If you encountered any question/difficulty in choosing the proper VCPU
parameters for your workload, please don't hesitate to ping me and
Dario.
Thank you. I'll keep you in touch when we have something specified.
--
*And
On 07.07.17 13:55, Julien Grall wrote:
You can say it is supported and listing known limitations, not saying
it is fully supported. As you said, there is a long way to end up
fully support.
Got it.
--
*Andrii Anisov*
___
Xen-devel mailing list
tches to the BSP.
Having required changes in the official BSP will take much more time.
[1]
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner#Bootloader
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.
oes out of bootloader in
Hypervisor mode/EL2? So no changes to FW/bootloader should be ever done
for supported boards?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
es the false impression that Xen upstream is fully
supported on Renesas, whilst from what you said this is not true and
change are required in the BSP.
I would say in different words: XEN upstream is fully supported on
Renesas, but due to XEN functionality gaps the BSP shoul
t will not work.
BSP with mentioned layer will do SMC due to OP-TEE integration and will
not boot.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Julien,
On 05.07.17 19:34, Julien Grall wrote:
I'd like to have my comments (see the discussion on "Xen Community
Call 21/07/16 meeting minutes") before considering acking those two
patches.
Its clear. It is just the first step.
Taking all discussed actions will take more tim
On 05.07.17 16:59, Julien Grall wrote:
I would send an updated patch today.
I've pushed the stuff [1]. Sorry I missed cc-ing you.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00533.html
--
*Andrii Anisov*
___
Xen-
These patches add SCIF earlyprintk support as well as a configuration
suitable for R-Car Gen3 SoCs based development boards.
[PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk
[PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards
___
From: Andrii Anisov
Introduce an earlyprintk configuration for R-Car Gen3 SoC based development
boards, like:
- Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X]
- M3ULCB [http://elinux.org/R-Car/Boards/M3SK]
- H3ULCB [http://elinux.org/R-Car/Boards/H3SK]
Signed-off-by: Iurii
From: Iurii Konovalenko
Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs.
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm64/debug-scif.inc | 51 +++
1 file changed
hypervisor.
Our preliminary plan is to prepare another distilled yocto layer which
would introduce minimal required changes to BSP only and update the wiki
page appropriately.
Will it work for you?
[3]
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01955.html
--
s have the same console
configuration.
I would send an updated patch today.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg00594.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
s' parameters.
Thank you for suggestions.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
FLASK: Denying unknown domctl_scheduler_op: 2.
libxl: error: libxl_sched.c:663:sched_rtds_vcpu_set_all: Domain 2:Setting
vcpu sched rtds: Operation not permitted
libxl_vcpu_sched_params_set_all failed.
Which version of Xen or commit point did you use?
We have our stuff based on top of 4
On 03.07.17 16:03, Wei Liu wrote:
This is a bit strange, fc658208e026242420b9924a9e4bfa581479e1f5 seems to
imply xentop should work on ARM.
Yep it is built.
But yocto missed its installation. That issue is on our site :)
--
*Andrii Anisov
ched.c:663:sched_rtds_vcpu_set_all: Domain
2:Setting vcpu sched rtds: Operation not permitted
libxl_vcpu_sched_params_set_all failed.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
more suitable list to ask server side questions.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
s.
[raisin] I don't know distro unknown. It might be missing packages.
[raisin] I don't know distro unknown. Cannot install packages.
[1] http://elinux.org/R-Car/Boards/Yocto-Gen3
[2] https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test
--
*Andrii Anisov*
hacks.
On 23.05.17 15:53, George John wrote:
Thanks for the reply. we are using renesas rcar h3 board. Does it
supports?
XEN passthrough functionality relies on IOMMU. The R-Car Gen3 SoCs have
a custom IOMMU named IPMMU. XEN does not support IPMMU yet.
--
*Andrii A
s.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg01581.html
[2] http://elinux.org/R-Car/Boards/M3SK
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
From: Andrii Anisov
Initialise *size in default branch to prevent certain compilers (i.e.
Linaro GCC 5.2-2015.11-2) from reporting "variable may be used uninitialized"
errors in caller function.
Signed-off-by: Julien Grall
---
tools/libxl/libxl_arm_acpi.c | 1 +
1 file changed, 1
ble may be used uninitialized"
compilation
error in a caller function, fired by some compilers under
circumstances.
If I'm right, would it be better to set *size to 0 in the default
branch?
Agree.
--
*Andrii Anisov*
___
Xen-de
CC Ian Jakson and Wei Liu as maintainers.
Sincerely,
Andrii Anisov.
2017-05-16 13:23 GMT+03:00 Andrii Anisov :
> From: Andrii Anisov
>
> Some compilers do not (validly?) detect that size will always be
> initialized when (rc > 0), so implicitly initialize it.
>
> Signed
s.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg01540.html
[2] http://elinux.org/R-Car/Boards/M3SK
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
From: Andrii Anisov
Some compilers do not (validly?) detect that size will always be
initialized when (rc > 0), so implicitly initialize it.
Signed-off-by: Julien Grall
---
tools/libxl/libxl_arm_acpi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/to
ome light stubdomain) which will be scheduled
right when it is needed - this is much easier task.
At least, this is my vision of vcoproc driver problem. Andrii can
correct me, if I'm terribly wrong.
All above is correct enough.
--
*Andrii Anisov*
.
I'm going to submit a patch, is it ok for you I put your signed-off?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
struct acpi_table_rsdp);
But your code seems to be leaner.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
tee or mshield - proprietary one.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg00381.html
[2]
https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg01966.html
[3]
https://lists.xenproject.org/archives/html/xen-dev
Hello Julien,
On 10.05.17 20:40, Julien Grall wrote:
Have you tried to define an interface using C structure?
Not yet.
If not, my suggestion would be to first do that so we can discuss on
other alternative.
Going to take this action soon.
--
*Andrii Anisov
eally interesting to me both from native app prospective as
well as SCF point of view.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
ound, actions to configure SCF are taken.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
t ideas will come up.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
cessary to evoke the context switch at the
moment.
So the number of context switches is rather matter of the scheduling
algorithm I guess.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
icitly, "the" guest) - as if there could only be one.
Surely this is wrong ?
Yep, several domains (domU) could be created using the same partial
device tree describing a configuration of virtual coprocessors.
[1]
https://lists.xenproject.
Hello Julien,
On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of
attack
from a domain privileged enough to
unclarity here to get the decision postponed.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
of using EL0 apps are:
- scheduled deterministically
- faster context switch
- lower and deterministic latency
- EL0 apps execution time is accounted appropriately to the guest that
they are servicing
Can't the EL0 app be servicing XEN itself?
*
*
*
*
*Andrii Anisov*
___
o spawn virtual coprocessors for guest
domains from your point of view?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
1 - 100 of 226 matches
Mail list logo
