On 08/17/2016 01:17 AM, Sergej Proskurin wrote:
> Signed-off-by: Sergej Proskurin
> Acked-by: Razvan Cojocaru
> ---
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: Ian Jackson
On 11 August 2016 at 21:34, Wei Liu wrote:
>
> Please send a separate patch for linux.c as we probably want to backport
> that.
>
>
It needs changes to "private.h" and other files too, so I will have to send
another patch anyway. If you see in gntshr_core.c, you will notice
flight 100530 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100530/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen c4e7a67e3a109a3d507d2617b77017e40d59f04a
baseline version:
xen
This run is configured for baseline tests only.
flight 67544 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67544/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 11 guest-start
>>> On 17.08.16 at 12:30, wrote:
> @@ -144,7 +171,11 @@ running_in_virtual_machine (void)
>
> ecx = cpuid (eax, ecx);
> if (ecx & 0x8000U)
> +{
> + if (running_in_dom0())
> + return 0;
> return 1;
> +}
> return 0;
> }
Isn't
Starting with xen-4.7 cpuid() will return with the hypervisor bit set
in a dom0 when running on an AMD system. As a result biosdevname
thinks it runs in a guest and does nothing. Detect a dom0 by looking
into xenfs. This works with classic xenlinux based kernels and with
pvops based kernels.
Hi All:
The following is our Xen vIOMMU high level design for detail
discussion. Please have a look. Very appreciate for your comments.
This design doesn't cover changes when root port is moved to hypervisor.
We may design it later.
Content:
On 17/08/16 03:19, Shanker Donthineni wrote:
Hi Julien,
Hello Shanker,
On 07/27/2016 12:09 PM, Julien Grall wrote:
Translating a VA to a IPA is expensive. Currently, Xen is assuming that
HPFAR_EL2 is only valid when the stage-2 data/instruction abort happened
during a translation table walk
On 08/17/2016 01:17 AM, Sergej Proskurin wrote:
> This commit extends xen-access by a simple test of the functionality
> provided by "xc_altp2m_change_gfn". The idea is to dynamically remap a
> trapping gfn to another mfn, which holds the same content as the
> original mfn. On success, the guest
On 17/08/16 12:51, Jan Beulich wrote:
On 17.08.16 at 12:30, wrote:
>> @@ -144,7 +171,11 @@ running_in_virtual_machine (void)
>>
>> ecx = cpuid (eax, ecx);
>> if (ecx & 0x8000U)
>> +{
>> + if (running_in_dom0())
>> + return 0;
>>
>>> On 15.08.16 at 01:07, wrote:
> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -365,7 +365,22 @@ int livepatch_elf_perform_relocs(struct livepatch_elf
> *elf)
> }
>
> if ( r->sec->sh_type == SHT_RELA )
> -rc =
>>> On 15.08.16 at 01:07, wrote:
> On x86 it works great but on ARM 32,64 not so much.
Considering the nature of the change ...
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -101,7 +101,7 @@ _uninstall:
>
> .PHONY: _debug
> _debug:
> - objdump -D -S
Add grant table userspace device mappings for
FreeBSD (enables support for qdisk backend
on FreeBSD Dom0).
Signed-off-by: Akshay Jaggi
---
Changed since v1:
* fix coding style
* remove O_CLOEXEC
* remove SET_MAX_GRANTS ioctl
* update freebsd/gntdev.h to latest
On 08/17/2016 01:17 AM, Sergej Proskurin wrote:
> This commit adds the function "altp2m_switch_vcpu_altp2m_by_id" that is
> executed after checking whether the vcpu should be switched to a
> different altp2m within the function "altp2m_check".
>
> Please note that in this commit, the function
>>> On 15.08.16 at 01:07, wrote:
> That way common code can use the same macro to access
> the most common attributes without much #ifdef.
>
> Take advantage of it right away in the livepatch code.
>
> Signed-off-by: Konrad Rzeszutek Wilk
x86
>>> On 15.08.16 at 01:07, wrote:
> xen/common/test/Makefile | 85
> ++
> xen/common/test/xen_bye_world.c| 34
> xen/common/test/xen_bye_world_func.c | 22
>
flight 100529 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100529/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 490b048b5afec06b1c78e6723530dcebd8b21612
baseline version:
ovmf
>>> On 15.08.16 at 01:07, wrote:
According to the code you mean $t instead of $p in the subject.
> --- a/xen/arch/arm/livepatch.c
> +++ b/xen/arch/arm/livepatch.c
> @@ -90,6 +90,35 @@ void arch_livepatch_unmask(void)
> local_abort_enable();
> }
>
> +int
Ported from xtf.git.
Signed-off-by: Wei Liu
---
include/asm_macros.h | 36
include/x86/asm_macros.h | 28
2 files changed, 64 insertions(+)
create mode 100644 include/asm_macros.h
create mode 100644
On 17/08/2016 02:50, Konrad Rzeszutek Wilk wrote:
+int arch_livepatch_perform_rela(struct livepatch_elf *elf,
+const struct livepatch_elf_sec *base,
+const struct livepatch_elf_sec *rela)
+{
.. snip..
+switch (
Hi Konrad,
On 17/08/2016 19:57, Konrad Rzeszutek Wilk wrote:
+void arch_livepatch_apply_jmp(struct livepatch_func *func)
+{
+uint32_t insn;
+uint32_t *old_ptr;
+uint32_t *new_ptr;
+
+BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(PATCH_INSN_SIZE !=
Hi Konrad,
On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote:
On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:
[...]
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 22806b6..fe83653 100644
--- a/xen/common/Makefile
On 17/08/2016 20:57, Julien Grall wrote:
> Hi Konrad,
>
> On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote:
>>> On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:
>
> [...]
>
diff --git a/xen/common/Makefile b/xen/common/Makefile
On 08/17/2016 06:11 AM, Julien Grall wrote:
On 17/08/16 03:19, Shanker Donthineni wrote:
Hi Julien,
Hello Shanker,
On 07/27/2016 12:09 PM, Julien Grall wrote:
Translating a VA to a IPA is expensive. Currently, Xen is assuming that
HPFAR_EL2 is only valid when the stage-2 data/instruction
>>> On 17.08.16 at 01:28, wrote:
> --- a/xen/arch/x86/cpu/mtrr/generic.c
> +++ b/xen/arch/x86/cpu/mtrr/generic.c
> @@ -520,7 +520,7 @@ int mtrr_generic_validate_add_page(unsigned long base,
> unsigned long size, unsig
>
> /* For Intel PPro stepping <= 7, must be 4 MiB
flight 100531 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100531/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 584fcb7de28b710dfcd4fbe8fe1d574c593f3009
baseline version:
ovmf
>>> On 17.08.16 at 01:28, wrote:
> --- a/xen/arch/x86/cpu/mtrr/generic.c
> +++ b/xen/arch/x86/cpu/mtrr/generic.c
> @@ -3,6 +3,7 @@
> #include
> #include
> #include
> +#include
Is this really needed, with xen/types.h already including it?
> @@ -237,7 +238,7 @@ static
On 17/08/16 14:40, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote:
>> Hello,
>>
>> Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
>>> Ported from xtf.git.
>> What is xtf.git? Does it use the same BSD licencing?
>> To my knowledge this is coming from the linux
From: Chris Patterson
The uart generates an interrupt whenever the transmit holding register is
empty and UART_IER_ETHREI is set in UART_IER. Currently, Xen's ns16550
driver does not currently mask this interrupt when transmit is stopped,
unlike other platforms such as
On Wed, Aug 17, 2016 at 01:35:14PM +0100, Wei Liu wrote:
> There are only a few differences between i386 and x86-64 linker scripts.
> Unify them into one. Re-indent the file at the same time.
>
> Construct a special rule in top-level directory to cope with the change.
> Ideally the build system
>>> On 17.08.16 at 01:28, wrote:
> The only call was always to the generic implementation.
>
> Signed-off-by: Doug Goldstein
Acked-by: Jan Beulich
___
Xen-devel mailing list
On 17/08/16 13:35, Wei Liu wrote:
> diff --git a/arch/x86/minios-x86.lds.S b/arch/x86/minios-x86.lds.S
> new file mode 100644
> index 000..65650ab
> --- /dev/null
> +++ b/arch/x86/minios-x86.lds.S
> @@ -0,0 +1,133 @@
> +#if defined(__x86_64__)
> +
> +OUTPUT_FORMAT("elf64-x86-64",
Wei Liu, on Wed 17 Aug 2016 13:35:11 +0100, wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Samuel Thibault
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 1c655a0..f21cc46 100644
>
>>> On 17.08.16 at 01:28, wrote:
> The use_intel() macro always evaluates to true so don't bother using it.
Ah, here we go. But there are indentation issues again here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
Ping?
>>> On 03.08.16 at 15:00, wrote:
> As such clearing of flags may have an impact on the selected rendezvous
> function, handle such in a central place.
>
> But don't allow such feature flags to be cleared during CPU hotplug:
> Platform and local system times may have
On Wed, Aug 17, 2016 at 03:01:07PM +0100, Andrew Cooper wrote:
> On 17/08/16 13:35, Wei Liu wrote:
> > diff --git a/include/asm_macros.h b/include/asm_macros.h
> > new file mode 100644
> > index 000..15dd377
> > --- /dev/null
> > +++ b/include/asm_macros.h
> > @@ -0,0 +1,36 @@
> > +/*
> > + *
flight 100512 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100512/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 100454
>>> On 16.08.16 at 18:13, wrote:
> On 16/08/16 17:00, Jan Beulich wrote:
> On 16.08.16 at 17:41, wrote:
>>> On 16/08/16 16:20, Jan Beulich wrote:
User mode code generally cannot be expected to invoke the PV-enabled
CPUID Xen
>>> On 17.08.16 at 00:17, wrote:
> xen/arch/arm/altp2m.c| 32
> xen/arch/x86/mm/altp2m.c | 6 ++
> xen/arch/x86/mm/p2m.c| 6 --
> xen/common/vm_event.c| 3 ++-
> xen/include/asm-arm/altp2m.h | 7
>>> On 17.08.16 at 01:28, wrote:
> There can only ever be one mtrr_if now and that is the generic
> implementation
This is only true when taking into consideration that cpu_has_mtrr
is #define-d to 1 right now. I'm not sure that's actually a good
assumption (especially when
flight 100518 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 17 guest-start/win.repeat fail REGR. vs.
100488
Regressions
>>> On 17.08.16 at 01:28, wrote:
> Unused function, gone.
>
> Signed-off-by: Doug Goldstein
Acked-by: Jan Beulich
But perhaps worth getting folded into the one dropping have_wrcomb()
(the acks for both patches can be retained for the
Fix two issues discovered by coverity.
Signed-off-by: Juergen Gross
---
lib/printf.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/lib/printf.c b/lib/printf.c
index ad6a304..f9e9d68 100644
--- a/lib/printf.c
+++ b/lib/printf.c
On 17/08/16 13:35, Wei Liu wrote:
> diff --git a/include/asm_macros.h b/include/asm_macros.h
> new file mode 100644
> index 000..15dd377
> --- /dev/null
> +++ b/include/asm_macros.h
> @@ -0,0 +1,36 @@
> +/*
> + * Macros for assembly files.
> + */
> +
> +#ifndef _ASM_MACRO_H_
> +#define
Signed-off-by: Wei Liu
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 1c655a0..f21cc46 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,7 @@
*~
*.o
*.a
+*.swp
include/list.h
mini-os
mini-os.gz
--
2.1.4
Hi Jan,
On 08/17/2016 12:05 PM, Jan Beulich wrote:
On 17.08.16 at 00:17, wrote:
>> xen/arch/arm/altp2m.c| 32
>> xen/arch/x86/mm/altp2m.c | 6 ++
>> xen/arch/x86/mm/p2m.c| 6 --
>>
On 17/08/16 13:37, Sergej Proskurin wrote:
On 08/17/2016 12:05 PM, Jan Beulich wrote:
On 17.08.16 at 00:17, wrote:
xen/arch/arm/altp2m.c| 32
xen/arch/x86/mm/altp2m.c | 6 ++
xen/arch/x86/mm/p2m.c| 6 --
>>> On 17.08.16 at 01:28, wrote:
> There are no users of the mtrr_ops struct or any of the callers on it so
> drop those.
>
> Signed-off-by: Doug Goldstein
Acked-by: Jan Beulich
___
flight 100528 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100528/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100512
>>> On 17.08.16 at 01:28, wrote:
> These weren't used so drop them.
>
> Signed-off-by: Doug Goldstein
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
>>> On 12.08.16 at 13:02, wrote:
Ping:
On 12.08.16 at 12:34, wrote:
>> On 11/08/16 19:10, Andrew Cooper wrote:
>>> On 09/08/16 11:40, Jan Beulich wrote:
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@
On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote:
> Hello,
>
> Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
> > Ported from xtf.git.
>
> What is xtf.git? Does it use the same BSD licencing?
> To my knowledge this is coming from the linux kernel source.
This:
On Wed, Aug 17, 2016 at 02:40:09PM +0100, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote:
> > Hello,
> >
> > Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
> > > Ported from xtf.git.
> >
> > What is xtf.git? Does it use the same BSD licencing?
> > To my
The semantics of alloca(3) is not very nice. If the stack overflows,
program behaviour is undefined.
Remove the use of alloca(3) and always use mmap.
Signed-off-by: Wei Liu
---
tools/libs/gnttab/linux.c | 19 ++-
1 file changed, 6 insertions(+), 13
The semantics of alloca(3) is not very nice. If the stack overflows,
program behaviour is undefined.
Remove the use of alloca(3) and always use mmap.
Signed-off-by: Wei Liu
---
tools/libs/foreignmemory/linux.c | 21 +++--
1 file changed, 7 insertions(+), 14
Wei Liu (2):
libs/gnttab: do not use alloca(3)
libs/foreignmemory: do not use alloca(3)
tools/libs/foreignmemory/linux.c | 21 +++--
tools/libs/gnttab/linux.c| 19 ++-
2 files changed, 13 insertions(+), 27 deletions(-)
--
2.1.4
On Wed, Aug 17, 2016 at 04:25:44PM +0200, Juergen Gross wrote:
> On 17/08/16 16:13, Wei Liu wrote:
> > On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
> >> Fix two issues discovered by coverity.
> >
> > I would update the commit message to make it contain more information.
> >
> >
It is useful to be able to see the hash configuration when running tests.
This patch adds a debugfs node for that purpose.
Signed-off-by: Paul Durrant
Cc: Wei Liu
---
drivers/net/xen-netback/common.h | 4 +++
drivers/net/xen-netback/hash.c | 68
This run is configured for baseline tests only.
flight 67545 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67545/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 14
>>> On 06.08.16 at 01:04, wrote:
> @@ -106,3 +121,119 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32
> trampoline)
>
> return mbi_out;
> }
> +
> +static multiboot_info_t *mbi2_mbi(u32 mbi_in)
> +{
> +const multiboot2_memory_map_t *mmap_src;
> +const
On 17/08/16 16:13, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
>> Fix two issues discovered by coverity.
>
> I would update the commit message to make it contain more information.
>
> Fix two issues discovered by Coverity:
>
> 1. properl mark one switch case
>>> On 17.08.16 at 16:02, wrote:
> From: Chris Patterson
>
> The uart generates an interrupt whenever the transmit holding register is
> empty and UART_IER_ETHREI is set in UART_IER. Currently, Xen's ns16550
> driver does not currently mask this
On 08/16/2016 06:17 PM, Sergej Proskurin wrote:
From: Tamas K Lengyel
Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only
If there are idle pcpus inside the waking vcpu's
soft-affinity mask, we should really tickle one
of them (this is one of the purposes of the
__runq_tickle() function itself!), not just
any idle pcpu.
The issue has been introduced in 02ea5031825d
("credit1: properly deal with pCPUs not in any
Hi everyone,
Here's another rather big scheduler-related series. The most of the content (as
usual, lately) is about Credit2, but there are other things, about tracing and
also about Credit1. In fact, this patch series introduces soft-affinity support
for Credit2.
The first 3 patches are indeed
In both Credit1 and Credit2, if a vcpu yields, let it...
well... yield!
In fact, context switch rate limiting has been primarily
introduced to avoid too heavy context switch rate due to
interrupts, and, in general, asynchronous events.
In a vcpu "voluntarily" yields, we really should let it
give
When a vcpu explicitly yields it is usually giving
us an advice of "let someone else run and come back
to me in a bit."
Credit2 isn't, so far, doing anything when a vcpu
yields, which means an yield is basically a NOP (well,
actually, it's pure overhead, as it causes the scheduler
kick in, but
Right now, the following scenario can occurr:
- upon vcpu v wakeup, v itself is put in the runqueue,
and pcpu X is tickled;
- pcpu Y schedules (for whatever reason), sees v in
the runqueue and picks it up.
This may seem ok (or even a good thing), but it's not.
In fact, if runq_tickle()
If wanting to migrate a vcpu that is actually running,
we need to ask the scheduler to chime in as soon as
possible, to have the vcpu itself stopped and actually
moved.
Make sure this happens by, after setting all the relevant
flags, raising the scheduler softirq.
Signed-off-by: Dario Faggioli
As far as {csched, csched2, rt}_schedule() are concerned,
an "empty" event, would already make it easier to read and
understand a trace.
But while there, add a few useful information, like
if the cpu that is going through the scheduler has
been tickled or not, if it is currently idle, etc
(they
If, when vcpu x wakes up, there are no idle pcpus in x's
soft-affinity, we just go ahead and look at its hard
affinity. This basically means that, if, in __runq_tickle(),
new_idlers_empty is true, balance_step is equal to
CSCHED_BALANCE_HARD_AFFINITY, and that calling
csched_balance_cpumask() for
If vcpu x has run for 200us, and sched_ratelimit_us is
1000us, continue running x _but_ return 1000us-200us as
the next time slice. This way, next scheduling point will
happen in 800us, i.e., exactly at the point when x crosses
the threshold, and can be descheduled (if appropriate).
Right now
With context switching ratelimiting enabled, the following
pattern is quite common in a scheduling trace:
0.000845622 |||.x||| d32768v12 csched2:runq_insert d0v13, position 0
0.000845831 |||.x||| d32768v12 csched2:runq_tickle_new d0v13,
processor = 12, credit = 10135529
There are only a few differences between i386 and x86-64 linker scripts.
Unify them into one. Re-indent the file at the same time.
Construct a special rule in top-level directory to cope with the change.
Ideally the build system should also be made more elegant, but
overhauling the build system
Use the newer ELF note interface. The generated ELF notes results in
equivalent configuration.
Also need to modify linker script to provide a note section.
Signed-off-by: Wei Liu
---
arch/x86/minios-x86_32.lds | 4
arch/x86/minios-x86_64.lds | 4
Wei Liu (4):
gitignore: ignore vim swap file
Introduce asm_macros.h
x86: switch to use elfnote
x86: use unified linker script
.gitignore | 2 +
Makefile | 6 +-
arch/x86/Makefile | 1 +
arch/x86/minios-x86.lds.S | 133
>>> On 17.08.16 at 01:28, wrote:
> For the functions that make up the interface to the MTRR code, drop the
> static keyword and prefix them all with mtrr for improved clarity when
> they're called outside this file. This also required adjusting or
> providing function
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Lan, Tianyu
> Sent: 17 August 2016 13:06
> To: Jan Beulich; Kevin Tian; Andrew Cooper; yang.zhang...@gmail.com; Jun
> Nakajima; Stefano Stabellini
> Cc: Anthony Perard; xuqu...@huawei.com; xen-
>
Hello,
Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
> Ported from xtf.git.
What is xtf.git? Does it use the same BSD licencing?
To my knowledge this is coming from the linux kernel source.
> Signed-off-by: Wei Liu
> ---
> include/asm_macros.h | 36
On 17/08/16 14:35, Wei Liu wrote:
> Use the newer ELF note interface. The generated ELF notes results in
> equivalent configuration.
>
> Also need to modify linker script to provide a note section.
>
> Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
On Wed, Aug 17, 2016 at 03:03:44PM +0100, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 03:01:07PM +0100, Andrew Cooper wrote:
> > On 17/08/16 13:35, Wei Liu wrote:
> > > diff --git a/include/asm_macros.h b/include/asm_macros.h
> > > new file mode 100644
> > > index 000..15dd377
> > > --- /dev/null
On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
> Fix two issues discovered by coverity.
I would update the commit message to make it contain more information.
Fix two issues discovered by Coverity:
1. properl mark one switch case as fall-through
2. unroll a loop that only
Hi Konrad,
On 15/08/16 16:17, Julien Grall wrote:
On 15/08/2016 01:07, Konrad Rzeszutek Wilk wrote:
+case R_AARCH64_ADR_PREL_PG_HI21:
+val = (val & ~0xfff) - ((u64)dest & ~0xfff);
+err = reloc_insn_imm(dest, val, 12, 21,
AARCH64_INSN_IMM_ADR);
+
In fact, libxc wrappers should, on error, set errno and
return -1.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libxc/xc_csched.c | 27
This is the remaining part of the plumbing (the libxl
one) necessary to be able to change the value of the
ratelimit_us parameter online, for Credit2 (like it is
already for Credit1).
Note that, so far, we were rejecting (for Credit1) a
new value of zero, despite it is a pretty nice way to
ask
The main purpose of the patch is to provide the xen-libxc
plumbing necessary to be able to change the value of the
ratelimit_us parameter online, for Credit2 (like it is
already for Credit1).
While there:
- mention in the Xen logs when rate limiting was enables
and is being disabled (and
Right now, two out of the three events related to
context switch (that is TRC_SCHED_SWITCH_INFPREV and
TRC_SCHED_SWITCH_INFNEXT) only report the domain id,
and not the vcpu id.
That's omitting a useful piece of information, and
even if we be figured that out by looking at other
records, that's
In both Credit2's trace records relative to checking
whether we want to preempt a vcpu (in runq_tickle()),
and to credits being burn, make it explicit on which
pcpu the vcpu being considered is running.
Such information isn't currently available, not even
by looking at on which pcpu the events
make it possible to use the various helpers from other
schedulers, e.g., for implementing soft affinity within
them.
Since we are touching the code, also make it start using
variables called v for struct_vcpu*, as it is preferrable.
No functional change intended.
Signed-off-by: Dario Faggioli
There are some scheduling related trace records that
are not being taken care of (and hence only dumped as
raw records).
Some of them are being introduced in this series, while
other were just neglected by previous patches.
Add support for them.
Signed-off-by: Dario Faggioli
For get_fallback_cpu(), by putting in place the "usual"
two steps (soft affinity step and hard affinity step)
loop. We just move the core logic of the function inside
the body of the loop itself.
For csched2_cpu_pick(), what is important is to find
the runqueue with the least average load.
We want is soft-affinity to play a role in load
balancing, i.e., when deciding whether or not to
push this vcpu from here to there, and/or pull that
other vcpu from there to here.
A way of doing that, is considering the following
(for both pushes and pulls, just with the roles of
current an new
If, during scheduling, we realize that the current vcpu
is running outside of its own soft-affinity, it would be
preferable to send it somewhere else.
Of course, that may not be possible, and if we're too
strict, we risk having vcpus sit in runqueues, even if
there are idle pcpus (violating
Credit2 is already event based, rather than tick
based. This means, the time at which the (i+1)-eth
scheduling decision needs to happen is computed
during the i-eth scheduling decision, and a timer
is set accordingly.
If there's nothing imminent (or, the most imminent
event is really really
By not looking at the same cpu (to check whether
we want to preempt who's running there) twice, if
the vcpu being woken up has both soft and hard
affinity.
In fact, all the cpus that are part of both soft
affinity and hard-affinity (of the waking vcpu)
are checked during the soft-affinity
This is done by means of the "usual" two steps loop:
- soft affinity balance step;
- hard affinity balance step.
The entire logic implemented in runq_tickle() is
applied, during the first step, considering only the
CPUs in the vcpu's soft affinity. In the second step,
we fall back to use all
By factoring into one (at the top) all the checks
to see whether current is the idle vcpu, and mark
it as unlikely().
In fact, if current is idle, all the logic for
dealing with yielding, context switching rate
limiting and soft-affinity, is just pure overhead,
and we better rush checking the
Last part of the wiring necessary for allowing to
change the value of the ratelimit_us parameter online,
for Credit2 (like it is already for Credit1).
Signed-off-by: Dario Faggioli
---
Cc: Ian Jackson
Cc: Wei Liu
Cc:
flight 100534 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100534/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7503cd70fb864a5663edb121c9b2488b4c69e7f5
baseline version:
ovmf
Hi Konrad,
On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:
Which is only used by Livepatch code. The purpose behind
this call is to modify the page table entries flags.
Specifically the .ro and .nx flags. The current mechanism
puts cache attributes in the flags and the .ro and .nx are
locked
1 - 100 of 130 matches
Mail list logo