port.developer.arm.com/case-details/?id=c921919d-97ea-e911-b862-28187887f93a>
Closed DS-5 ARM COMPILER-6 ULTIMATE FL How to rename sections using ARM
Compiler 6 tools? Oct-09-2019 Oct-11-2019
ANDRII ANISOV
Lead Systems Engineer
Office: +380 44 390 5457 x 66766 Cell:
+
tion. Do you have any code examples or
hints how to evaluate expressions on the pre-processing stage?
[1]
https://developer.arm.com/docs/100070/0612/scatter-file-syntax/expression-evaluation-in-scatter-files/expression-rules-in-scatter-files
--
Sincerely,
A
are hardcoded in scatter file.
- Rename correspondent ARM Linker defined symbols to those needed by
`symbols` tool
using steering file feature.
- ARM Compiler 6.6 tools are not able to rename sections, so we still need
GNU toolchain's objcopy for this.
Signed-off-by: And
would hate to introduce these workarounds
I hated finding and publishing these workarounds, but here we are.
The main question here is if XEN needs a tag "Support safety certified
compiler" by the cost of accepting such workarounds.
Then discuss how to reduce their stench.
--
Sinc
/expression-rules-in-scatter-files
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
RMCC block
- potentially hide the whole horrible hack behind a #define so that it
would become at the call site:
+ARMCC_DUMMY_FUNC_HACK()
This is quite reasonable.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject
On 28.10.19 16:47, Julien Grall wrote:
(+ George and Dario)
Hi,
On 11/09/2019 11:32, Andrii Anisov wrote:
From: Andrii Anisov
Call time accounting hooks from appropriate transition points
of the ARM64 code.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm64/entry.S | 39
Hello Julien
On 28.10.19 16:52, Julien Grall wrote:
Hi,
On 11/09/2019 11:32, Andrii Anisov wrote:
From: Andrii Anisov
Extend XEN_SYSCTL_getcpuinfo interface with timing information
provided by introduced time accounting infrastructure.
Signed-off-by: Andrii Anisov
---
xen/common
ion calculation.
[1]
s/transion/transition/
OK.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 81 +
xen/include/xen/sched.h | 27 +
2 files changed, 108 insertions(+)
diff --git a/xen/common/schedule.c b/x
From: Andrii Anisov
Dear All,
Here are patches to make XEN (hypervisor only) being able to be compiled for
ARMv8 with ARM Compiler 6.6.3 Long Term Maintenance. ARM compiler of that
version is safety certified, that is the reason for the choice. The chosen
compiler has a number of bugs
From: Artem Mygaiev
Still have linker issues
---
Config.mk | 8 +++-
config/StdGNU.mk | 11 ++-
config/arm32.mk | 10 ++
config/arm64.mk | 6 +-
xen/Rules.mk | 2 ++
xen/arch/arm/Rules.mk | 8
6 files changed, 38
From: Andrii Anisov
Here several ARM Compiler 6.6 issues are solved or provided a work-around:
- Scatter file is pretty primitive, it has no feature to define symbols
- ARM linker defined symbols are not counted as referred if only mentioned
in a steering file for rename or resolve, so
From: Andrii Anisov
ARM Compiler 6.6 has a proven bug: static data symbols, moved to an init
section, becomes global. Thus these symbols clash with ones defined in
gic-v2.c. The straight forward way to resolve the issue is to add the GIC
version suffix, at least for one of the conflicting side
From: Andrii Anisov
So get the code duplication with `x`-es.
Signed-off-by: Andrii Anisov
---
xen/include/asm-arm/smccc.h | 60 +
1 file changed, 60 insertions(+)
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 126399d
From: Andrii Anisov
ARM Compiler 6 has a proven bug: it compiles data only C files with
SoftVFP attributes. This leads to a failed linkage afterwards with
an error:
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible
with the image attributes.
... A64 clashes
From: Andrii Anisov
Also armclang complains about the condition always true,
because `sgi` is of type enum with all its values under 16.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/gic.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index
Hello,
On 15.10.19 14:08, Julien Grall wrote:
To be honest, those ASSERTIONs are pointless.
I'd prefer to drop them.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman
From: Andrii Anisov
ARM Compiler complains about assertion conditions being always true,
because sgi is of enum type what has all its values under 16.
In order to preserve those asserts, specify the available SGI number
right in the enum and use it for the assertions. This also eliminates
nasty
On 12.09.19 15:17, Julien Grall wrote:
This an RFC and I am sure there current state is enough to spark a discussion.
There are no need to waste time resending it and use filling up inboxes.
Please wait for more time.
Gotcha!
--
Sincerely,
Andrii Anisov
Hello Volodymyr,
On 11.09.19 20:48, Volodymyr Babchuk wrote:
Hi Andrii,
As we agreed, I'll wipe out debugging remains as well as cleanup coding style
nits and resend the series.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel
to state other than TACC_IRQ could happen until we return from nested
interrupts. IRQ time is accounted in a distinct way comparing to other states.
It is acumulated between other states transition moments, and is substracted
from the old state on states transion calculation.
Signed-off-by: Andr
From: Andrii Anisov
While the Credit2 scheduler code uses guest time from the
other pcpu, we have to use locked time accounting.
Signed-off-by: Andrii Anisov
---
xen/common/Kconfig | 1 +
xen/common/sched_credit2.c | 17 +
2 files changed, 10 insertions(+), 8
From: Andrii Anisov
The locked interface to acquire guest time by scheduling code
is introduced. It can be used by schedulers what do require
guest time from a different pcpu to take scheduling decission.
Signed-off-by: Andrii Anisov
---
xen/common/Kconfig | 3 +++
xen/common/schedule.c
From: Andrii Anisov
While the RTDS scheduler code does not use guest time from the
other pcpu, we are free to go with lockless time accounting.
Signed-off-by: Andrii Anisov
---
xen/common/sched_rt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/common/sched_rt.c
From: Andrii Anisov
While the Credit scheduler code uses guest time from the
other pcpu, we have to use locked time accounting.
Signed-off-by: Andrii Anisov
---
xen/common/Kconfig| 1 +
xen/common/sched_credit.c | 12 +---
2 files changed, 6 insertions(+), 7 deletions
From: Andrii Anisov
The lockless interface to acquire guest time by scheduling code
is introduced. It can be used by schedulers what do not require
guest time from a different pcpu to take scheduling decission.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 10 ++
xen
From: Andrii Anisov
Introduce per-pcpu time accounting what includes the following states:
TACC_HYP - the pcpu executes hypervisor code like softirq processing
(including scheduling), tasklets and context switches
TACC_GUEST - the pcpu executes guests code
TACC_IDLE - the low-power
From: Andrii Anisov
Let xentop request and show information about CPU load provided
by new time accounting infrastructure.
Signed-off-by: Andrii Anisov
---
tools/xenstat/libxenstat/src/xenstat.c | 50 +
tools/xenstat/libxenstat/src/xenstat.h | 15
From: Andrii Anisov
Extend XEN_SYSCTL_getcpuinfo interface with timing information
provided by introduced time accounting infrastructure.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 33 -
xen/common/sysctl.c | 4
xen/include
From: Andrii Anisov
Call time accounting hooks from appropriate transition points
of the ARM64 code.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm64/entry.S | 39 ---
xen/arch/arm/domain.c | 2 ++
2 files changed, 38 insertions(+), 3 deletions
From: Andrii Anisov
That is the second attempt of the changes for the time accounting in XEN.
The initial topic is here [1].
In this series it is introduced a time accounting infrastructure separated
from runstates, and made an attempt to use new infra solely for taking
scheduling decissions
it.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
From: Andrii Anisov
In the commit af156ff0859c8d362a5706640614c9d10f62adf2, it
was left unattended HPFAR_EL2 register output. Now it is printed
with 1608 digits, what is way too wide even for the biggest
monitors. So cleanup excessive paddings.
Signed-off-by: Andrii Anisov
---
xen/arch/arm
platform-specific code. I thought it is possible to alternate scheduling
behavior calling those interfaces differently.
Though, on the second thought, it would not provide enough freedom to build
something really different.
Zephyr, maybe?
OK, will look through it a bit later.
--
Sincerely,
And
On 06.08.19 16:09, Andrii Anisov wrote:
p.p.s. I'm looking through freertos as well to get wider look on the available
approaches
OK, basically Free-RTOS does not account the IRQ time separately. Yet its
scheduling is very implementation dependent.
Any ideas about other open-source examples
Hello Dario,
Please see my comments below:
On 03.08.19 03:55, Dario Faggioli wrote:
On Fri, 2019-08-02 at 16:07 +0300, Andrii Anisov wrote:
On 02.08.19 12:15, Julien Grall wrote:
From the list below it is not clear what is the split between
hypervisor time and guest time. See some
On 01.08.19 13:17, Julien Grall wrote:
All the commit message is based on "performance improvement" Now you are selling it as this is confusing.
Sorry Julien, I have no more arguments for you.
I'll drop these two patches for the next iteration.
--
Sincerely,
And
deterministic
(from my point of view) approach.
Well, I suppose we may add granularity to the time accounting, and then decide
at the scheduler level what we count for the guest execution time.
But it is so far from the end, and we are here to discuss and agree the stuff.
--
Sincerely,
Andrii Anisov
is arguable. That's why we have a discussion here to agree on the
time accounting approach, what will directly affect scheduling accuracy.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org
On 01.08.19 12:37, Julien Grall wrote:
Hi,
On 01/08/2019 07:45, Andrii Anisov wrote:
On 30.07.19 23:10, Julien Grall wrote:
In this series I think I need interrupts locked until I start time accounting
for hypervisor. Time accounting is started by `tacc_head()` function. I prefer
to have
Hello Dario
On 01.08.19 14:19, Dario Faggioli wrote:
On Thu, 2019-08-01 at 09:45 +0300, Andrii Anisov wrote:
Hello Julien,
On 30.07.19 23:10, Julien Grall wrote:
In this series I think I need interrupts locked until I start
time accounting for hypervisor. Time accounting is started
, or
somewhere else):
hyp=12%(irq=4%+softirq=1%+tasklet=5%+other=2%)
One more downside of runstate - it will not hold all that stuff.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org
not yet good
understanding about how alternatives work.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
enabled? Or processing IRQs without WA enabled is the correct way to do?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Julien,
It looks I missed answering this email. So do this now:
On 29.11.18 00:00, Julien Grall wrote:
On 28/11/2018 21:31, Andrii Anisov wrote:
From: Julien Grall
This makes function enter_hypervisor_head() being executed with
irqs locked. This also give a fine side effect
On 26.07.19 13:59, Julien Grall wrote:
Hi,
On 26/07/2019 11:37, Andrii Anisov wrote:
From: Andrii Anisov
On ARM64 we know exactly if trap happened from hypervisor or guest, so
we do not need to take that decision. This reduces a condition for
all enter_hypervisor_head calls and the function
domain reboot.
You don't want
to be able to block tasklets, you want them to run as soon as possible.
Should it really be done in the way of breaking scheduling? What if the system
has RT requirements?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing
discussing this is why I've added, apart from George, some
other x86, ARM, and core-Xen people)
Thank you.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
the need for cpumask_weight().
While there, remove as much other uses of it as we can, even if not in
hot-paths.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Andrii Anisov
---
I just realized this patch fell through the cracks! :-O
I sent it quite a while ago, I got
drii Anisov wrote:
From: Andrii Anisov
After changes introduced by 9cc0618 we are able to vmap/vunmap
7-digit is not sufficient to guarantee it will be uniq in the future. You also
want to specify the commit title.
page aligned addresses only.
So if we add a page address remainder to the ma
the time idle_vcpu
spent in RUNSTATE_blocked, and hypervisor time being the time idle_vcpu
spent in RUNSTATE_running sounds quite confusing to me.
As I said before, think of idle_vcpu as hypervisor_vcpu ;)
--
Sincerely,
Andrii Anisov.
___
Xen-devel
Hello Dario,
On 26.07.19 15:00, Dario Faggioli wrote:
On Fri, 2019-07-26 at 13:37 +0300, Andrii Anisov wrote:
From: Andrii Anisov
Currently the idle time is being accounted as a idle vcpu runtime.
This is not entirely correct, because the entity named idle vcpu is
in fact a hypervisor tasks
Sorry guys,
I was eliminating cyrillic "с" in the commit title and occasionally left this
patch in the folder.
Please ignore exactly this patch.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject
From: Andrii Anisov
Let xentop request and show information about CPU load
(hypervisor, guest and idle information)
Signed-off-by: Andrii Anisov
---
tools/xenstat/libxenstat/src/xenstat.c | 38 +
tools/xenstat/libxenstat/src/xenstat.h | 9 +++
tools
From: Andrii Anisov
On ARM64 we know exactly if trap happened from hypervisor or guest, so
we do not need to take that decision. This reduces a condition for
all enter_hypervisor_head calls and the function call for traps from
the hypervisor mode.
Currently, it is implemented for ARM64 only
From: Andrii Anisov
On ARM64 we know exactly if trap happened from hypervisor or guest, so
we do not need to take that decision. This reduces a condition for
all enter_hypervisor_head calls and the function call for traps from
the hypervisor mode.
Currently, it is implemented for ARM64 only
From: Andrii Anisov
Account for a guest:
- guest running time
- guest sync traps serving time (hypercalls, trapped emulated iomems, etc)
- vcpu jobs in leave_hypervisor_tail
Account for the hyp:
- IRQ processing
- Softirq processing
Signed-off-by: Andrii Anisov
---
xen/arch/arm/traps.c
From: Andrii Anisov
Extend XEN_SYSCTL_getcpuinfo interface with guest and hypervisor
time information.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 22 ++
xen/common/sysctl.c | 2 ++
xen/include/public/sysctl.h | 2 ++
xen/include/xen/sched.h
From: Julien Grall
This makes function enter_hypervisor_head() being executed with
irqs locked.
Signed-off-by: Julien Grall
[Andrii: add a justification commit message]
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm64/entry.S | 11 +--
xen/arch/arm/traps.c | 6 ++
2
From: Andrii Anisov
Currently the idle time is being accounted as a idle vcpu runtime.
This is not entirely correct, because the entity named idle vcpu is
in fact a hypervisor tasks worker. E.g. some softirqs are processed
by the idle vcpu.
So lets change idle vcpu time accounting and specify
From: Andrii Anisov
This is the very RFC series, which is aimed to address some of VCPU time
accounting problems which affect scheduling fairness and accuracy. Please
note that this is done for ARM64 yet.
One of the scheduling problems is a misleading CPU idle time concept. Now
for the CPU idle
site, you should read [1]. It also
refers ways to pin VCPUs to PCPUs.
[1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/big.LITTLE.txt
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
From: Andrii Anisov
Fix the comment misprint, so it refers to the exact function name.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 9e16c16..8b78293 100644
with that.
Sorry for missing this point.
--
Sincerely,
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
4557c2292854d047ba8e44a69e2d60d99533d155
to a different one. With the appropriate reasoning, e.g. aligning to Linux
kernel.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 19.07.19 12:37, Jan Beulich wrote:
On 18.07.2019 19:11, Andrii Anisov wrote:
Let vunmap align passed virtual address by PAGE_SIZE.
Despite seeing Andrew's R-b you've already got I'd like to point out
that this increases the risk of some code passing the wrong pointer
into here. {,un
mentioned it in the main body of my message.
address potentially not page aligned. Instead of fixing that in ARM code,
we let vunmap() making alignment by itself and stripping other existing
vunmap() calls from prior masking.
Yet, with your text both notes are needed.
--
Sincerely,
And
Hello Jan,
On 18.07.19 18:04, Jan Beulich wrote:
On 18.07.2019 16:12, Andrii Anisov wrote:
The scenario is quite trivial: some vcpu uptdating its runstate values
(e.g. context switching) while those values are being read by a guest using
other vcpu.
Well, that's (afaia) not an intended usage
in vm_index()
Signed-off-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
From: Andrii Anisov
Let vunmap align passed virtual address by PAGE_SIZE.
This also makes it consistent with how {,un}map_domain_page()
currently works.
With the main change, also:
- strip all existing vunmap() calls from prior masking
- replace opencoded PAGE_MASK macro in vm_index()
Signed
as well.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
0001669c, v->runstate.state_entry_time is 8018e22b1553,
new_entry_time 18e22c7bef
(XEN) delta 800010e0, v->runstate.state_entry_time is 8018e2d28e72,
new_entry_time 18e2d29f52
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
occurrence rate. Could you please provide more details about the idea?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
) )
{
mm_printk("The virtual address is not aligned to the page-size.\n");
return -EINVAL;
}
So I assumed you had some specific idea about that check.
I'd fix `xen_pt_update()` if you are ok with it.
--
Sincerely,
And
From: Andrii Anisov
After changes introduced by 9cc0618 we are able to vmap/vunmap
page aligned addresses only.
So if we add a page address remainder to the mapped virtual address,
we have to mask it out before unmapping.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/cpuerrata.c | 2 +-
1
Hello George,
The patch was also CC'ed to you, but I got:
"554 esa1.hc3370-68.iphmx.com You are being rejected because your senderbase score
is below our accepted policy."
from your server.
ps. I hope I'm not bothering you too much.
On 18.07.19 12:54, Andrii Anisov wrote:
Fr
From: Andrii Anisov
Using XEN_RUNSTATE_UPDATE mask during the process of copying runstate
values to guest causes runstate entry time to be eventually considered
negative on a calculation of the time delta. So the XEN_RUNSTATE_UPDATE
should be masked out during the calculation of the time spent
be an inline
assembly in omap5.c, or omap5.S under platform.
(Bear in mind this is likely the first time Denis works with the Xen community).
Yep:)
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
code (omap5.c).
I've nothing to add about the log. Pastebin is banned in our network.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
need clarifications about the stuff.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
hypervisor definitely has a chance to spoil the new VA space at the old address.
IMHO it should be fixed (at least documented) for the old interface.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.o
Sorry I've re-read your statement, and got another idea.
On 18.06.19 16:27, Andrii Anisov wrote:
On 18.06.19 15:54, Julien Grall wrote:
Switch to hyp-mode is fairly complex and depends on your processor.
Switch to hyp-mode depends on the processor. So it may be complex. Or not.
Hence why
to drop the footer.
I think it is impossible, it is a corporate piece of ...email.
I've missed manual removal of the footer, yet I do not use that email for
discussions normally.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel
in terms of waiting for an event and checking aux registers.
[1]
https://elixir.bootlin.com/linux/v5.1/source/arch/arm/mach-omap2/omap-headsmp.S#L62
ANDRII ANISOV
Lead Systems Engineer
Office: +380 44 390 5457 x 66766 Cell: +380 50 573 8852 Email:
andrii_ani...@epam.com
Kyiv, Ukrai
On 14.06.19 19:20, Julien Grall wrote:
Well, that a stable ABI... Even if I would love to remove it, you can't get rid
of old guests that easily...
In 5 years, as XEN did for LK 3.18?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen
ld one has no documentation about the unregistering. The implicit way is
known to us, but not known to users.
How to solve the clash?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/li
with me.
BTW, dropping the old interface implementation will be much easier in future if
it will not clash with the new one.
I am afraid we will never be able to remove the old interface.
Maybe.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
implementation in meanwhile.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
for all vcpus runstate value update, unless it is
an rw lock or doing trylock on it.
BTW, I'm a bit confused, are you OK with lock (not trylock) existing in
hypercall?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel
ould we go with trylock and
hypercall_create_continuation() in order to avoid locking but still not fail to
the guest?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Jan,
On 11.06.19 13:22, Andrii Anisov wrote:
Hello Jan,
On 11.06.19 12:10, Jan Beulich wrote:
Except when there's no need for KPTI in the guest in the first place,
as is the case for x86-64 PV guests. I think this is worthwhile clarifying.
I am not sure what is your point here. At least
R,
} guest_type;
bool in_use;
} runstate;
Did you miss runstate_guest as a member of that struct?
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
чт, 13 черв. 2019 о 11:39 Juergen Gross пише:
> github.com/jgross1/xen sched-v1-rebase
>
> Only compile tested on x86 up to now, but rebase was rather easy.
>
Cool, will take it and check for ARM.
Thank you.
Sincerely,
Andrii Anisov.
_
On 13.06.19 10:29, Juergen Gross wrote:
Thanks for the heads up, but I've rebased already. :-)
Oh, great. I'm just wondering if you put it already on your github?
I'm playing with scheduling on my site, and I have a strong feeling I should be
based on your series ;)
--
Sincerely,
Andrii
tps://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=608639ffa0a0d6f219e14ba7397ab2cc018b93c9
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
From: Andrii Anisov
The vcpu structure member last_run_time is used by credit scheduler only.
In order to get better encapsulation, it is moved from a generic
structure to the credit scheduler private vcpu definition. Also, rename
the member to last_sched_time in order to reflect
ded.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 11.06.19 18:12, Julien Grall wrote:
Acked-by: Julien Grall
Now committed, thank you!
Thank you.
--
Sincerely,
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
