Hello Wang,
On 20.12.17 23:29, Wang, Baoqian wrote:
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 288kB init memory.
Try switching to XEN console now. Hit Ctrl-a three (six with minicom)
times, then '0'.
--
*And
tiny.config.
1) cp arch/arm/configs/tiny.conf .config
2) make olddefconfig
3) make menuconfig -> select RCAR3
the results is that ARM_SMMU will be disabled because it is already
disabled in tiny.config and CONFIG_RCAR3 won't enable it.
I've got the point.
Thank y
le
@@ -1,2 +1,2 @@
obj-y += iommu.o
-obj-y += smmu.o
+obj-$(ARM_SMMU) += smmu.o
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
qmp.o
+obj-$(CONFIG_MPSOC) += xilinx-zynqmp.o
Though, RCAR gen3 does not have the platform code yet. So nothing to
select for it now ;)
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/li
://github.com/xen-troops/meta-demo/tree/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
curious.
I guess you could implement PV I2C using FE/BE scheme. With enormous
efforts and unpredictable results.
But I'm sure it is not what you really need.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
a-rcar-gen3-xen/recipes-extended/xen/xen_git.bbappend#L17
[3] -
https://github.com/xen-troops/meta-demo/tree/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas
Sincerely,
Andrii Anisov.
2018-01-16 8:52 GMT+02:00 Ganesh H <ganes...@tataelxsi.co.in>:
> Hi,
>
>
>
>
://lists.xenproject.org/archives/html/xen-users/2017-10/msg00031.html
[3] -
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02545.html
[4] -
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02679.html
--
*Andrii Anisov
give regarding this use case
will be very helpful and valuable.
We are using PV Audio solution for such a task:
https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg02428.html
https://lkml.org/lkml/2017/8/7/115
--
*Andrii Anisov*
___
Xen
deadline misses?
Actually as per Meng's explanation and calculations the problem was on
my side - wrong DomR task/VCPU parameters.
I was running the system with dummy loads and values received from CARTS
and all seems to be ok (no deadline misses occured).
--
*Andrii Anisov
meets its deadline.
Andrii and Dario,
Do you think the assumption that one VCPU runs only one RT task is
reasonable in practice?
If it is, is there some use cases for this assumption?
No, I doubt real life use-cases would fit this scheme.
--
*Andrii Anisov
scheduler will do the job.
[1]
https://lists.linuxfoundation.org/pipermail/automotive-discussions/2018-January/005590.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen
Thank you, I'll take a look.
On 09.02.18 19:53, Meng Xu wrote:
Sure!
It's attached.
Meng
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Dario,
On 12.02.18 12:20, Andrii Anisov wrote:
Actually as per Meng's explanation and calculations the problem was on
my side - wrong DomR task/VCPU parameters.
I was running the system with dummy loads and values received from
CARTS and all seems to be ok (no deadline misses occured).
Well
ask with smaller period has larger demand.
I'll do more experiments.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
t together with getty on HVC can eat another 10% of CPU
at any moment.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
utilization is different: the task with smaller period has larger demand.
BTW, could you please share the model xml file to me?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo
demo setup. Which consists of
HW drivers in DomD, PV Drivers backends in DomD, DomA running real
Android with PV Drivers and utilizing GPU sharing, etc.
But I managed to reproduce the issue when all domains are running
generic armv8 kernel with minimal initramfses.
So I suspect an issue in R
Hello Dario,
I eventually used your old email.
Please take a look here.
On 09.02.18 14:20, Andrii Anisov wrote:
Dear Dario,
Now I'm experimenting with RTDS, in particular with "extra time"
functionality.
My experimental setup is built on Salvator-X board with H3 SOC
(runnin
From: Andrii Anisov <andrii_ani...@epam.com>
Introduce per-vcpu scheduler operations permission verification.
As long as Xvcpuinfo are in fact scheduler configuration manipulations
there is no need to introduce specific access vectors.
Signed-off-by: Andrii Anisov <andrii_ani...
is looking for some specific
properties in CPU nodes, but do not find them, because XEN creates basic
CPU nodes from the scratch.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo
Hello Bharat,
Threads [1], [2] should feed your interest about big.LITTLE support in XEN.
[1] -
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00079.html
[2] -
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01695.html
--
*Andrii Anisov
* `schedule()` is called.
Because time accounting is done by passing `now` time value to
`sched->do_schedule()` right in `schedule()`.
[1] https://github.com/LITMUS-RT/liblitmus/pull/3
[2] https://lkml.org/lkml/2011/2/10/135
--
*Andrii Anisov*
___
) Failed to convert stack to physical address
(XEN) '0' pressed -> dumping Dom0's registers
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
en) and make
> changes for vexpress, sunxi, and others in follow-up patches.
So let it be.
*ANDRII ANISOV*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Stefano,
On 27.07.18 01:46, Stefano Stabellini wrote:
On Tue, 24 Jul 2018, Andrii Anisov wrote:
On 07.07.18 02:13, Stefano Stabellini wrote:
Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
MPSOC and ALL. They enable the required options for thei
unxi.o
+obj-$(CONFIG_ALL_32) += brcm.o
+obj-$(CONFIG_ALL_32) += exynos5.o
+obj-$(CONFIG_ALL_32) += midway.o
+obj-$(CONFIG_ALL_32) += omap5.o
+obj-$(CONFIG_ALL_32) += rcar2.o
+
+obj-$(CONFIG_ALL_64) += vexpress.o
+obj-$(CONFIG_ALL_64) += sunxi.o
+obj-$(CONFIG_ALL_64) += seattle.o
+obj-$(CONFIG_ALL
but then "config ALL" should not select MPSOC_PLATFORM by itself.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
y: Stefano Stabellini
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
is removed from the .config. Next time you type "make"
the MPSOC platform files will not be built.
But vexpress, sunxi, other listed in arch/arm/platforms/Makefile and
dependent on ARM32 or ARM64 will be built anyway.
--
*Andrii Anisov*
_
Hello Stefano,
On 21.08.18 02:59, Stefano Stabellini wrote:
Add a kconfig option for Renesas Rcar2 platforms.
Signed-off-by: Stefano Stabellini
CC: iurii.konovale...@globallogic.com
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel
Hello Stefano,
On 21.08.18 02:59, Stefano Stabellini wrote:
Add a kconfig option for TI OMAP5 platforms.
Signed-off-by: Stefano Stabellini
CC: baoz...@gmail.com
--
Reviewed-by: Andrii Anisov
*Andrii Anisov
= xgene-storm.o
+obj-$(CONFIG_MPSOC_PLATFORM)+= xilinx-zynqmp.o
[1]
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00537.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
here [1]. So those who are
interested in stripped builds for their HW would come up with
correspondent patches.
[1]
https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg02451.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel
.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Stefano,
I will look through the rest of changes. But my justifications could be
wrong due to the fact that the rest of the SoC families are unfamiliar
to me.
On 21.08.18 20:24, Stefano Stabellini wrote:
On Tue, 21 Aug 2018, Andrii Anisov wrote:
Hello Stefano,
On 21.08.18 02:59
critical application does exchange some information
with other entities in the system. So they would need interdomain
communication anyway (i.e. built with event channels and shared pages, etc.)
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel
naturally fit making `memory` property similar to `reg` - the list of
values.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
still
have to handle possible crashes (reboots, shutdowns, etc.) of one of the
domains. And again, with DomB termination, you are losing an entity able
to handle the situation.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel
seattle.o
obj-y += sunxi.o
obj-$(CONFIG_ARM_64) += thunderx.o
obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
see.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
tools/xentrace/xentrace_format | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format
index 5ff85ae..323d0c2 100644
--- a/tools/xentrace/xentrace_format
From: Andrii Anisov
Allign rtds:repl_budget trace record format to the current code.
Signed-off-by: Andrii Anisov
---
tools/xentrace/formats | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index d6e7e3f..7db6d49 100644
From: Andrii Anisov
Make xentrace_format more convinient and up to date in usage.
Andrii Anisov (5):
xentrace_format: print timestamps in nanoseconds
xentrace_format: switch mhz option to float
xentrace_format: combine 64-bit LE values from traces
formats: allign trace record format
From: Andrii Anisov
In order to be able to print possible 64bit LE values from
trace records, precombine possible variants.
Signed-off-by: Andrii Anisov
---
tools/xentrace/xentrace_format | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools
From: Andrii Anisov
For convinience, print RTDS budget and deadline values as decimals.
Signed-off-by: Andrii Anisov
---
tools/xentrace/formats | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 7db6d49..cf25ab0
From: Andrii Anisov
In some systems fraction of the MHz might be a meaningful part
of the cycles frequency value. So accept MHz value as float.
Signed-off-by: Andrii Anisov
---
tools/xentrace/xentrace_format | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools
patches twice (once To
the list, and once with the list on Cc; I've dropped the To part
here, while you should drop the Cc part)?
I guess it's a result of `git send-email
--cc-cmd=scripts/get_maintainer.pl...`. I'll review my publishing steps
to avoid this.
--
*Andrii Anisov
On 11.09.18 12:33, Jan Beulich wrote:
Well, what should I say - I disagree. I would agree if it would be a
whole lot of work, but there's not that many key handlers to begin
with, and far not all of them print a time stamp in their headlines.
I'm quite ok with that.
--
*Andrii Anisov
s_time_i is reasonable.
Introducing %pt for ns granularity and %pT for ms could be an option.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
.)
Should we think about replacing PRI_stime?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/perfc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/common/perfc.c b/xen/common/perfc.c
index 0675677..0abd977 100644
--- a/xen/common/perfc.c
+++ b/xen/common/perfc.c
@@ -33,8 +33,7 @@ void
On 11.09.18 12:10, Jan Beulich wrote:
It is subjective, yes, but in such a case you even more so need to
demonstrate a change is an overall improvement.
I would phrase it as "printing timestapms in timestamp format".
--
*Andrii Anisov*
_
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/traps.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ae64ae..45fb3d5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -244,7
this, then please
uniformly everywhere - there's even a second instance right in this
same file you change, not to speak of similar ones elsewhere
I'll check through this file.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel
From: Andrii Anisov
The structure member last_run_time is used by a credit scheduler only.
So move it from a generic vcpu sctructure to the credit scheduler private
vcpu definition.
Signed-off-by: Andrii Anisov
---
xen/common/sched_credit.c | 12 +---
xen/common/schedule.c | 1
e made on the xen-devel@lists.xenproject.org
L: xen-devel@lists.xenproject.org
L: xen-devel@lists.xenproject.org
L: xen-devel@lists.xenproject.org
L: xen-devel@lists.xenproject.org
--
*Andrii Anisov*
___
Xen-devel
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 78c450e..aec10a7 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -155,7 +155,7 @@ struct
Hello George,
On 11.09.18 13:48, George Dunlap wrote:
I like the idea; but what does 'LE' mean in this context?
Little endian. Most significant 32bit word is at a higher index in the
array.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen
ble();
- if (!softirq_pending(smp_processor_id())) {
+ if (!softirq_pending(smp_processor_id()))
Same here.
Yep.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
. The scripts
add_maintainers.pl will make sure the xen-devel will be on the to.
I'll try it with the next nit.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
on.
From other hand I'm quite confused about how useful timestamps in
seconds could be for traces. As per my understanding, tracer should be
useful for debugging some rapidly changing processes.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 78c450e..aec10a7 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -155,7 +155,7 @@ struct
nt formula in
xentrace_format, but changing `%(tsc)d` to `%(tsc).9f` in formats.
BTW, I've just noticed, that reltsc is allways in cycles. And it seems
odd, as well.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject
)?
On 11.09.18 12:49, Andrii Anisov wrote:
On 11.09.18 12:30, Jan Beulich wrote:
Should we think about replacing PRI_stime?
Why not, but that would require adding another %p suffix or
introducing a construct splitting s_time_t values into two pieces
(to be used to hide the two printk() arguments required
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/traps.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ae64ae..7bfdda8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
natural to introduce platform configs which would
couple specific drivers support? With a special platform i.e. "other"
which enables all drivers and platform code.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject
passthrough in a whole could be dropped for such platforms.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
are targeting
IPMMU support upstreamed. What about IOMMU-less platforms?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
platforms with XEN would require
certification.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Can you quantify what would be the cost of keeping that code around
for IOMMU-less platform?
I'm not sure I understand your question. Do you mean a number of loc of
the passthrough feature for arm?
--
*Andrii Anisov*
___
Xen-devel mailing list
Dear All,
Any comments for the patch?
It addressed the issue mentioned here:
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00452.html
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
applicability of XEN to build systems with real-time requirements.
Then I hopefully will be on that.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
_console("hvc", 0, NULL);
+
#ifdef CONFIG_PCI
/* PCI BIOS service won't work from a PV guest. */
pci_probe &= ~PCI_PROBE_BIOS;
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ows the user not to build other unnecessary platform code.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Julien,
In case you are ordering those includes in the alphabetical order,
shouldn't be `asm/...` includes placed above `xen/...`?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org
Hello Stefano,
On 25.09.18 01:55, Stefano Stabellini wrote:
> Add a Kconfig option to select no specific platform support.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
I would say the comment was odd, not duplicated, at the place it is removed.
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
-
> 2 files changed, 8 insertions(+), 8 deletions(-)
The file xen/arch/arm/traps.c has a bunch of show functions except for
registers. For stack, trace, etc. So maybe constify their parameters
right away?
--
*Andrii Anisov*
___
Xen-deve
*/
> -dsb(sy);
> gic_hw_ops->send_SGI(sgi, SGI_TARGET_SELF, NULL);
> }
>
> @@ -331,12 +319,6 @@ void send_SGI_allbutself(enum gic_sgi sgi)
> {
> ASSERT(sgi < 16); /* There are only 16 SGIs */
>
> - /*
> -* Ensure that stores
do_IRQ(regs, irq, is_fiq);
> local_irq_disable();
> }
> else if ( is_lpi(irq) )
> {
> local_irq_enable();
> +isb();
> gic_hw_ops->do_LPI(irq);
> local_irq_disable();
> }
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
l
> ---
> xen/arch/arm/arm32/traps.c | 1 +
> xen/include/asm-arm/bug.h | 4
> xen/include/asm-arm/time.h | 2 ++
> xen/include/asm-arm/traps.h | 2 ++
> 4 files changed, 5 insertions(+), 4 deletions(-)
Reviewed-
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
1c313182bd0f49f496
> "irqchip/gic: Ensure ordering between read of INTACK and shared data".
>
> Signed-off-by: Julien Grall
>
> ---
> This patch is candidate for backporting up to Xen 4.9.
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
feel some oddness in that.
Anyway,
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Julien
On 25.10.18 17:11, Andrii Anisov wrote:
> I guess I should make a dedicated patch applicable to mainline to reveal
> the issue. I hope I'll do this nearest days.
Please find below the diff applicable to the current xenbits/smoke which
exposes the issue.
With that diff
Hello Julien,
Sorry for the previous email sent as html.
On 27.10.18 15:14, Andrii Anisov wrote:
>>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>>> index f6f6de3..985192b 100644
>>> --- a/xen/arch/arm/traps.c
>>> +++ b/xen/arch/arm/traps.c
&
the same way
> everywhere so less trouble to figure out problem.
Good point.
Actually I was confused by the reported behavior, because I overlooked
those msr's with different arguments in entry.S and assumed
enter_hypervisor_head() always runs with irqs disabled.
--
en/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -388,12 +388,14 @@ void gic_interrupt(struct cpu_user_regs *regs,
>>> int is_fiq)
>>>if ( likely(irq >= 16 && irq < 1020) )
>>>{
>>>local_irq_enable();
>>> +
On 18.10.18 16:20, Julien Grall wrote:
> At the moment, CPU Identification is spread accross cpu.c, cpufeature.c,
> processor.h, cpufeature.h. It would be better to keep everything
> together in a single place.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anis
On 18.10.18 16:20, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
) and do_IRQ().
>
> This ensure the system registers are synchronized after you
> acknowledge an interrupt.
I see.
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ndler.
>
> Based on Linux commit 39a06b67c2c1256bcf2361a1f67d2529f70ab206
> "irqchip/gic: Ensure we have an ISB between ack and ->handle_irq".
>
> Signed-off-by: Julien Grall
>
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:20, Julien Grall wrote:
> The HSR defines are pretty much self-contained and not necessary to be
> included everywhere in Xen. So move them in a new header hsr.h.
>
> Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
*A
On 18.10.18 16:20, Julien Grall wrote:
> do_unexpected_traps() is moved to traps.h while init_traps() and
> hyp_traps_vectors() are moved to setup.h.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
On 18.10.18 16:21, Julien Grall wrote:
> None of the platforms are using the p2m helpers.
>
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproje
On 18.10.18 16:21, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.10.18 16:20, Julien Grall wrote:
> Signed-off-by: Julien Grall
> ---
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
1 - 100 of 551 matches
Mail list logo
