Re: [Xen-devel] [PATCH v2 09/48] xen/sched: move some per-vcpu items to struct sched_unit

On 09.09.19 08:55, Jan Beulich wrote: On 09.09.2019 08:39, Juergen Gross wrote: On 04.09.19 16:16, Jan Beulich wrote: On 09.08.2019 16:57, Juergen Gross wrote: V2: - move affinity_broken back to struct vcpu (Jan Beulich) But this alone won't work: Now a 2nd vCPU in a unit will clobber what a

[Xen-devel] [PATCH v6 0/5] xen: debugtrace cleanup and per-cpu buffer support

Another debugtrace enhancement I needed for core scheduling debugging, plus some cleanup. Changes in V6: - some comments by Jan addressed - added patch 5 Changes in V5: - several comments by Jan addressed (code: patches 1 and 4, commit message of patch 3) Changes in V4: - replaced patch 1 (ori

[Xen-devel] [PATCH v6 1/5] xen: fix debugtrace clearing

After dumping the debugtrace buffer it is cleared. This results in some entries not being printed in case the buffer is dumped again before having wrapped. While at it remove the trailing zero byte in the buffer as it is no longer needed. Commit b5e6e1ee8da59f introduced passing the number of char

[Xen-devel] [PATCH v6 3/5] xen: refactor debugtrace data

As a preparation for per-cpu buffers do a little refactoring of the debugtrace data: put the needed buffer admin data into the buffer as it will be needed for each buffer. In order not to limit buffer size switch the related fields from unsigned int to unsigned long, as on huge machines with RAM in

[Xen-devel] [PATCH v6 4/5] xen: add per-cpu buffer option to debugtrace

debugtrace is normally writing trace entries into a single trace buffer. There are cases where this is not optimal, e.g. when hunting a bug which requires writing lots of trace entries and one cpu is stuck. This will result in other cpus filling the trace buffer and finally overwriting the interest

[Xen-devel] [PATCH v6 5/5] xen: add debugtrace entry when entry count is wrapping

The debugtrace entry count is a 32 bit variable, so it can wrap when lots of trace entries are being produced. Making it wider would result in a waste of buffer space as the printed count value would consume more bytes when not wrapping. So instead of letting the count value grow to huge values le

[Xen-devel] [PATCH v6 2/5] xen: move debugtrace coding to common/debugtrace.c

Instead of living in drivers/char/console.c move the debugtrace related coding to a new file common/debugtrace.c No functional change, code movement only. Signed-off-by: Juergen Gross Acked-by: Jan Beulich --- xen/common/Makefile| 1 + xen/common/debugtrace.c| 180 +++

Re: [Xen-devel] [PATCH v6 1/5] xen: fix debugtrace clearing

On 09.09.2019 09:35, Juergen Gross wrote: > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -1173,6 +1173,7 @@ static char*debugtrace_buf; /* Debug-trace > buffer */ > static unsigned int debugtrace_prd; /* Producer index */ > static unsigned int debugtrace_k

Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

> -Original Message- [snip] > > === x86 === > > * PV-IOMMU (v7) > - Paul Durrant This is not happening, but I will be posting v9 of my "add per-domain IOMMU control" series fairly shortly. Paul ___ Xen-devel mailing list Xen-devel@lists

Re: [Xen-devel] [PATCH 1/3] hv_ballon: Avoid calling dummy function __online_page_set_limits()

On 07.09.19 23:47, Souptick Joarder wrote: > __online_page_set_limits() is a dummy function and an extra call > to this function can be avoided. > > Signed-off-by: Souptick Joarder > --- > drivers/hv/hv_balloon.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/hv/hv_balloon.c b/

Re: [Xen-devel] [PATCH 3/3] mm/memory_hotplug.c: Remove __online_page_set_limits()

On 07.09.19 23:47, Souptick Joarder wrote: > As both the callers of this dummy __online_page_set_limits() > is removed, this can be removed permanently. > > Signed-off-by: Souptick Joarder > --- > include/linux/memory_hotplug.h | 1 - > mm/memory_hotplug.c| 5 - > 2 files changed

Re: [Xen-devel] [PATCH 2/3] xen/ballon: Avoid calling dummy function __online_page_set_limits()

On 07.09.19 23:47, Souptick Joarder wrote: > __online_page_set_limits() is a dummy function and an extra call > to this function can be avoided. > > Signed-off-by: Souptick Joarder > --- > drivers/xen/balloon.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/xen/balloon.c b/driv

Re: [Xen-devel] [PATCH v6 4/5] xen: add per-cpu buffer option to debugtrace

On 09.09.2019 09:35, Juergen Gross wrote: > debugtrace is normally writing trace entries into a single trace > buffer. There are cases where this is not optimal, e.g. when hunting > a bug which requires writing lots of trace entries and one cpu is > stuck. This will result in other cpus filling the

Re: [Xen-devel] Looking for Semester long Project

+Andrew, Lars, Stefano and Wei On 9/5/19 11:23 PM, Julian Tuminaro wrote: Hi, Hello, Thank you for you interest on Xen. I have CCed few more person that should be able to answer your questions below. We (a group of 2 students) are interested in doing a hypervisor related project for the

Re: [Xen-devel] [PATCH v6 4/5] xen: add per-cpu buffer option to debugtrace

On 09.09.2019 09:59, Jan Beulich wrote: > On 09.09.2019 09:35, Juergen Gross wrote: >> debugtrace is normally writing trace entries into a single trace >> buffer. There are cases where this is not optimal, e.g. when hunting >> a bug which requires writing lots of trace entries and one cpu is >> stu

Re: [Xen-devel] [PATCH v6 1/5] xen: fix debugtrace clearing

On 09.09.2019 09:53, Jan Beulich wrote: > On 09.09.2019 09:35, Juergen Gross wrote: >> --- a/xen/drivers/char/console.c >> +++ b/xen/drivers/char/console.c >> @@ -1173,6 +1173,7 @@ static char*debugtrace_buf; /* Debug-trace >> buffer */ >> static unsigned int debugtrace_prd; /* Producer i

Re: [Xen-devel] [PATCH 0/3] Remove __online_page_set_limits()

On Sun 08-09-19 03:17:01, Souptick Joarder wrote: > __online_page_set_limits() is a dummy function and an extra call > to this can be avoided. > > As both of the callers are now removed, __online_page_set_limits() > can be removed permanently. > > Souptick Joarder (3): > hv_ballon: Avoid callin

Re: [Xen-devel] [PATCH v6 4/5] xen: add per-cpu buffer option to debugtrace

On 09.09.19 10:04, Jan Beulich wrote: On 09.09.2019 09:59, Jan Beulich wrote: On 09.09.2019 09:35, Juergen Gross wrote: debugtrace is normally writing trace entries into a single trace buffer. There are cases where this is not optimal, e.g. when hunting a bug which requires writing lots of trac

[Xen-devel] Xen on RPI3

I have tried booting xen on rpi3 using ubuntu 18.04 as dom0 , I have successfully installed xen hypervisor packages as well as tools using apt-get . finally grub setting is done to add xen option in one of the grub menu , When I try to boot rpi3 with xen enabled ubuntu I get the following error "s

Re: [Xen-devel] [PATCH v6 5/5] xen: add debugtrace entry when entry count is wrapping

On 09.09.2019 09:35, Juergen Gross wrote: > @@ -173,10 +177,23 @@ void debugtrace_printk(const char *fmt, ...) > nr = vsnprintf(buf, sizeof(buf), fmt, args); > va_end(args); > > +if ( count == DEBUGTRACE_COUNT_WRAP ) > +{ > +count = 0; > +wrap_cnt++; > +} > +

Re: [Xen-devel] [PATCH v6 1/5] xen: fix debugtrace clearing

On 09.09.19 09:53, Jan Beulich wrote: On 09.09.2019 09:35, Juergen Gross wrote: --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -1173,6 +1173,7 @@ static char*debugtrace_buf; /* Debug-trace buffer */ static unsigned int debugtrace_prd; /* Producer index */ s

Re: [Xen-devel] [PATCH v6 5/5] xen: add debugtrace entry when entry count is wrapping

On 09.09.19 10:19, Jan Beulich wrote: On 09.09.2019 09:35, Juergen Gross wrote: @@ -173,10 +177,23 @@ void debugtrace_printk(const char *fmt, ...) nr = vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); +if ( count == DEBUGTRACE_COUNT_WRAP ) +{ +count = 0; +

Re: [Xen-devel] Running xenstored in Linux stubdom

On 06.09.19 20:01, Daniel Smith wrote: On Wed, Sep 4, 2019 at 1:26 PM Daniel Smith wrote: On Wed, Sep 4, 2019 at 12:12 PM Juergen Gross wrote: The stubdom gets an event channel to use for dom0 xenbstore connection via commandline parameter ("--event "). This needs to be used in the stubdom

[Xen-devel] [PATCH v7 3/5] xen: refactor debugtrace data

As a preparation for per-cpu buffers do a little refactoring of the debugtrace data: put the needed buffer admin data into the buffer as it will be needed for each buffer. In order not to limit buffer size switch the related fields from unsigned int to unsigned long, as on huge machines with RAM in

[Xen-devel] [PATCH v7 4/5] xen: add per-cpu buffer option to debugtrace

debugtrace is normally writing trace entries into a single trace buffer. There are cases where this is not optimal, e.g. when hunting a bug which requires writing lots of trace entries and one cpu is stuck. This will result in other cpus filling the trace buffer and finally overwriting the interest

[Xen-devel] [PATCH v7 5/5] xen: add debugtrace entry when entry count is wrapping

The debugtrace entry count is a 32 bit variable, so it can wrap when lots of trace entries are being produced. Making it wider would result in a waste of buffer space as the printed count value would consume more bytes when not wrapping. So instead of letting the count value grow to huge values le

[Xen-devel] [PATCH v7 0/5] xen: debugtrace cleanup and per-cpu buffer support

Another debugtrace enhancement I needed for core scheduling debugging, plus some cleanup. Changes in V7: - some comments by Jan addressed Changes in V6: - some comments by Jan addressed - added patch 5 Changes in V5: - several comments by Jan addressed (code: patches 1 and 4, commit message of

[Xen-devel] [PATCH v7 2/5] xen: move debugtrace coding to common/debugtrace.c

Instead of living in drivers/char/console.c move the debugtrace related coding to a new file common/debugtrace.c No functional change, code movement only. Signed-off-by: Juergen Gross Acked-by: Jan Beulich --- xen/common/Makefile| 1 + xen/common/debugtrace.c| 180 +++

[Xen-devel] [PATCH v7 1/5] xen: fix debugtrace clearing

After dumping the debugtrace buffer it is cleared. This results in some entries not being printed in case the buffer is dumped again before having wrapped. While at it remove the trailing zero byte in the buffer as it is no longer needed. Commit b5e6e1ee8da59f introduced passing the number of char

[Xen-devel] [PATCH v3 3/4] xen/sched: add minimalistic idle scheduler for free cpus

Instead of having a full blown scheduler running for the free cpus add a very minimalistic scheduler for that purpose only ever scheduling the related idle vcpu. This has the big advantage of not needing any per-cpu, per-domain or per-scheduling unit data for free cpus and in turn simplifying movin

[Xen-devel] [PATCH v3 0/4] xen/sched: use new idle scheduler for free cpus

These three patches have been carved out from my core scheduling series as they are sufficiently independent to be applied even without the big series. Without this little series there are messages like the following to be seen on the console when booting with smt=0: (XEN) Adding cpu 1 to runqueu

[Xen-devel] [PATCH v3 4/4] xen/sched: switch to debugtrace in cpupool handling

Instead of having a cpupool_dprintk() define just use debugtrace. Signed-off-by: Juergen Gross --- xen/common/cpupool.c | 48 +++- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c index 15e7004

[Xen-devel] [PATCH v3 1/4] xen/sched: populate cpupool0 only after all cpus are up

Simplify cpupool initialization by populating cpupool0 with cpus only after all cpus are up. This avoids having to call the cpu notifier directly for cpu 0. With that in place there is no need to create cpupool0 earlier, so do that just before assigning the cpus. Initialize free cpus with all onli

[Xen-devel] [PATCH v3 2/4] xen/sched: remove cpu from pool0 before removing it

Today a cpu which is removed from the system is taken directly from Pool0 to the offline state. This will conflict with the new idle scheduler, so remove it from Pool0 first. Additionally accept removing a free cpu instead of requiring it to be in Pool0. For the resume failed case we need to call

Re: [Xen-devel] [PATCH v8] x86/emulate: Send vm_event from emulate

On 06.09.2019 18:46, Jan Beulich wrote: > On 03.09.2019 16:01, Alexandru Stefan ISAILA wrote: >> A/D bit writes (on page walks) can be considered benign by an introspection >> agent, so receiving vm_events for them is a pessimization. We try here to >> optimize by filtering these events out. >> C

Re: [Xen-devel] [PATCH v7 4/5] xen: add per-cpu buffer option to debugtrace

On 09.09.2019 11:25, Juergen Gross wrote: > debugtrace is normally writing trace entries into a single trace > buffer. There are cases where this is not optimal, e.g. when hunting > a bug which requires writing lots of trace entries and one cpu is > stuck. This will result in other cpus filling the

Re: [Xen-devel] [PATCH v7 5/5] xen: add debugtrace entry when entry count is wrapping

On 09.09.2019 11:25, Juergen Gross wrote: > The debugtrace entry count is a 32 bit variable, so it can wrap when > lots of trace entries are being produced. Making it wider would result > in a waste of buffer space as the printed count value would consume > more bytes when not wrapping. > > So ins

Re: [Xen-devel] [PATCH v3 1/2] sysctl: report existing physcaps on ARM

Hi, Title NIT: s/ARM/Arm/ On 9/6/19 3:30 PM, Roger Pau Monne wrote: Current physcaps in XEN_SYSCTL_physinfo are only used by x86, albeit the capabilities themselves are not x86 specific. This patch adds support for also reporting the current capabilities on ARM hardware. Note that on ARM PHYSC

Re: [Xen-devel] [PATCH v3 2/2] sysctl/libxl: choose a sane default for HAP

Hi, On 9/6/19 3:30 PM, Roger Pau Monne wrote: Current libxl code will always enable Hardware Assisted Paging (HAP), expecting that the hypervisor will fallback to shadow if HAP is not available. With the changes to the domain builder that's not the case any longer, and the hypervisor will raise

[Xen-devel] [linux-4.19 test] 141150: trouble: blocked/broken/starved

flight 141150 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141150/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops broken build-arm64-xsm

Re: [Xen-devel] [PATCH v3 0/2] libxl: choose a sane default for HAP

Hi, On 9/6/19 3:30 PM, Roger Pau Monne wrote: Hello, First patch is a preparatory change to also make use of the physcaps on ARM, second patch introduces a new physcap (HAP) in order for the toolstack to decide whether to use HAP if the user hasn't made a selection. Thanks, Roger. Roger Pau M

[Xen-devel] [ovmf test] 141158: trouble: blocked/broken

flight 141158 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/141158/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-amd64

[Xen-devel] [PATCH] x86/boot: Improve code generation from bootsym()

The code generation for bootsym() is atrocious, and unnecesserily complicated. Given the appropriate physical address, all we need is to construct a virtual address of the appropriate type. add/remove: 0/0 grow/shrink: 0/9 up/down: 0/-4256 (-4256) Function

[Xen-devel] [PATCH] x86: Misc trivial cleanup of bootsym_phys()

In smpboot, there is no need to abstract setup_trampoline() away. Drop the define and use bootsym_phys() directly. In tboot, the 3 size calculations are invariant of their bootsym_phys()/__pa() transformations, but the compiler can't tell this. Drop the tranformations, which simplifies the compi

Re: [Xen-devel] [PATCH v8] x86/emulate: Send vm_event from emulate

On 09.09.2019 12:01, Alexandru Stefan ISAILA wrote: > On 06.09.2019 18:46, Jan Beulich wrote: >> On 03.09.2019 16:01, Alexandru Stefan ISAILA wrote: >>> } >>> +/* Check if eny vm_event was sent */ >> >> "any" and please add blank line ahead of your addition. > > I will correct this. > >

Re: [Xen-devel] [PATCH] x86/boot: Improve code generation from bootsym()

On 09.09.2019 12:43, Andrew Cooper wrote: > The code generation for bootsym() is atrocious, and unnecesserily > complicated. Given the appropriate physical address, all we need is to > construct a virtual address of the appropriate type. > > add/remove: 0/0 grow/shrink: 0/9 up/down: 0/-4256 (-4

Re: [Xen-devel] [PATCH v3] x86emul: fix test harness and fuzzer build dependencies

On 05/09/2019 15:09, Jan Beulich wrote: > Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the > userspace test harnesses") didn't account for the dependencies of > cpuid-autogen.h to potentially change between incremental builds. In > particular the harness has a "run" goal which is s

Re: [Xen-devel] [PATCH RFC] x86/HVM: use single (atomic) MOV for aligned emulated writes

On 05/09/2019 15:07, Jan Beulich wrote: > Using memcpy() may result in multiple individual byte accesses > (dependening how memcpy() is implemented and how the resulting insns, > e.g. REP MOVSB, get carried out in hardware), which isn't what we > want/need for carrying out guest insns as correctly

Re: [Xen-devel] [PATCH] docs/sphinx: todo/wishlist

Andrew Cooper writes ("Re: [PATCH] docs/sphinx: todo/wishlist"): > It has been pointed out that calling this the wishlist is a poor name.  > A better name would be the technical debt list.  I won't resend for just > this, but please bear it in mind when considering the suggestion. I approve of the

Re: [Xen-devel] [PATCH v8] x86/emulate: Send vm_event from emulate

On 09.09.2019 13:49, Jan Beulich wrote: > On 09.09.2019 12:01, Alexandru Stefan ISAILA wrote: >> On 06.09.2019 18:46, Jan Beulich wrote: >>> On 03.09.2019 16:01, Alexandru Stefan ISAILA wrote: } +/* Check if eny vm_event was sent */ >>> >>> "any" and please add blank line ahe

Re: [Xen-devel] [PATCH v8] x86/emulate: Send vm_event from emulate

On 09.09.2019 13:03, Alexandru Stefan ISAILA wrote: > > > On 09.09.2019 13:49, Jan Beulich wrote: >> On 09.09.2019 12:01, Alexandru Stefan ISAILA wrote: >>> On 06.09.2019 18:46, Jan Beulich wrote: On 03.09.2019 16:01, Alexandru Stefan ISAILA wrote: >} > +/* Check if eny v

Re: [Xen-devel] [PATCH v8] x86/emulate: Send vm_event from emulate

On 09.09.2019 14:15, Jan Beulich wrote: > On 09.09.2019 13:03, Alexandru Stefan ISAILA wrote: >> >> >> On 09.09.2019 13:49, Jan Beulich wrote: >>> On 09.09.2019 12:01, Alexandru Stefan ISAILA wrote: On 06.09.2019 18:46, Jan Beulich wrote: > On 03.09.2019 16:01, Alexandru Stefan ISAILA wr

[Xen-devel] [freebsd-master test] 141161: regressions - trouble: blocked/fail

flight 141161 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/141161/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141004 Tests which did

Re: [Xen-devel] [PATCH v3] x86emul: fix test harness and fuzzer build dependencies

On 09.09.2019 13:01, Andrew Cooper wrote: > On 05/09/2019 15:09, Jan Beulich wrote: >> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the >> userspace test harnesses") didn't account for the dependencies of >> cpuid-autogen.h to potentially change between incremental builds. In >> pa

Re: [Xen-devel] [PATCH v3] x86emul: fix test harness and fuzzer build dependencies

On 09.09.2019 13:01, Andrew Cooper wrote: > On 05/09/2019 15:09, Jan Beulich wrote: >> Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the >> userspace test harnesses") didn't account for the dependencies of >> cpuid-autogen.h to potentially change between incremental builds. In >> pa

Re: [Xen-devel] [PATCH V3 1/8] iommu/arm: Add iommu_helpers.c file to keep common for IOMMUs stuff

Hi Oleksandr, On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Introduce a separate file to keep various helpers which could be used by more than one IOMMU driver in order not to duplicate code. The first candidates to be moved to the new file are SMMU driver's "map_

Re: [Xen-devel] [PATCH] x86: Misc trivial cleanup of bootsym_phys()

On 09.09.2019 12:44, Andrew Cooper wrote: > In smpboot, there is no need to abstract setup_trampoline() away. Drop the > define and use bootsym_phys() directly. > > In tboot, the 3 size calculations are invariant of their bootsym_phys()/__pa() > transformations, but the compiler can't tell this.

Re: [Xen-devel] [PATCH RFC] x86/HVM: use single (atomic) MOV for aligned emulated writes

On 09.09.2019 13:02, Andrew Cooper wrote: > On 05/09/2019 15:07, Jan Beulich wrote: >> Using memcpy() may result in multiple individual byte accesses >> (dependening how memcpy() is implemented and how the resulting insns, >> e.g. REP MOVSB, get carried out in hardware), which isn't what we >> want

Re: [Xen-devel] [PATCH] docs/sphinx: todo/wishlist

On 09/09/2019 12:02, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH] docs/sphinx: todo/wishlist"): >> It has been pointed out that calling this the wishlist is a poor name.  >> A better name would be the technical debt list.  I won't resend for just >> this, but please bear it in mind when

[Xen-devel] [PATCH] x86/IRQ: make 'i' debug output more tabular again

Since the affinity values are no longer of uniform width, move them further to the right such that as much of the output as possible comes out aligned with one another. Signed-off-by: Jan Beulich --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2397,9 +2397,9 @@ static void dump_irqs(unsign

Re: [Xen-devel] [PATCH V3 2/8] iommu/arm: Add ability to handle deferred probing request

Hi Oleksandr, The code looks code, few comments below. On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds minimal required support to General IOMMU framework to be able to handle a case when IOMMU driver requesting deferred probing for a device. In ord

Re: [Xen-devel] [PATCH] x86/IRQ: make 'i' debug output more tabular again

On 09/09/2019 13:07, Jan Beulich wrote: > Since the affinity values are no longer of uniform width, move them > further to the right such that as much of the output as possible comes > out aligned with one another. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper _

Re: [Xen-devel] [PATCH V3 6/8] iommu: Add of_xlate callback

Hi, On 8/27/19 4:11 PM, Jan Beulich wrote: On 27.08.2019 16:59, Oleksandr wrote: There was a preference to introduce callback in a separate patch [2]. Anyway, shall I fold it? Hmm, I disagree with Julien here. I don't think we should have unused hooks in the tree, not even intermediately. I

Re: [Xen-devel] [PATCH v2] tools/libs: put common Makefile parts into new libs.mk

Juergen Gross writes ("[PATCH v2] tools/libs: put common Makefile parts into new libs.mk"): > The Makefile below tools/libs have a lot in common. Put those common > parts into a new libs.mk and include that from the specific Makefiles. ... > tools/libs/call/Makefile | 86 ++--

Re: [Xen-devel] RFC: Criteria for checking in core scheduling series

... using Dario's correct mail address On 06.09.19 13:09, George Dunlap wrote: There was a discussion on the community call about the core scheduling series being developed by Juergen Gross [1]. The conclusion can be summarized as follows: * We normally wait to check in series until they are q

Re: [Xen-devel] [PATCH v2] tools/libs: put common Makefile parts into new libs.mk

On 09.09.19 14:41, Ian Jackson wrote: Juergen Gross writes ("[PATCH v2] tools/libs: put common Makefile parts into new libs.mk"): The Makefile below tools/libs have a lot in common. Put those common parts into a new libs.mk and include that from the specific Makefiles. ... tools/libs/call/M

Re: [Xen-devel] [PATCH v3] x86emul: fix test harness and fuzzer build dependencies

Jan Beulich writes ("Re: [PATCH v3] x86emul: fix test harness and fuzzer build dependencies"): > you had been particularly unhappy about the v2 approach. While > not strictly required for committing, I'd still prefer to have > your agreement with this approach (or, of course, suggestions > for imp

Re: [Xen-devel] [PATCH v2 07/48] xen/sched: move per cpu scheduler private data into struct sched_resource

On Thu, 2019-09-05 at 09:38 +0200, Jan Beulich wrote: > On 05.09.2019 09:13, Juergen Gross wrote: > > On 04.09.19 15:48, Jan Beulich wrote: > > > On 09.08.2019 16:57, Juergen Gross wrote: > > > > > > > > -/* > > > > - * vcpu is urgent if vcpu is polling event channel > > > > - * > > > > - * if u

[Xen-devel] [PATCH] tools/ocaml: Fix xenctrl ABI and introduce build-time checks

c/s f089fddd941 broke the Ocaml ABI by renumering XEN_SYSCTL_PHYSCAP_directio without adjusting the Ocaml physinfo_cap_flag enumeration. Fix this by inserting CAP_PV between CAP_HVM and CAP_DirectIO. c/s 82239182eb3 extended the XEN_SYSCTL_PHYSCAP_* ABI with a HAP bit. Extend the physinfo_cap_fl

Re: [Xen-devel] [PATCH] tools/ocaml: Fix xenctrl ABI and introduce build-time checks

On 09/09/2019 14:32, Andrew Cooper wrote: > c/s f089fddd941 broke the Ocaml ABI by renumering XEN_SYSCTL_PHYSCAP_directio > without adjusting the Ocaml physinfo_cap_flag enumeration. Fix this by > inserting CAP_PV between CAP_HVM and CAP_DirectIO. > > c/s 82239182eb3 extended the XEN_SYSCTL_PHYSCA

Re: [Xen-devel] [PATCH v2 19/48] xen: add sched_unit_pause_nosync() and sched_unit_unpause()

On 09.08.2019 16:58, Juergen Gross wrote: > The credit scheduler calls vcpu_pause_nosync() and vcpu_unpause() > today. Add sched_unit_pause_nosync() and sched_unit_unpause() to > perform the same operations on scheduler units instead. And by placing them in sched-if.h you mean to indicate that the

Re: [Xen-devel] [PATCH v2 20/48] xen: let vcpu_create() select processor

On 09.08.2019 16:58, Juergen Gross wrote: > --- a/xen/common/schedule.c > +++ b/xen/common/schedule.c > @@ -368,14 +368,52 @@ static struct sched_unit *sched_alloc_unit(struct vcpu > *v) > return NULL; > } > > -int sched_init_vcpu(struct vcpu *v, unsigned int processor) > +static unsigned

[Xen-devel] [PATCH v2] tools/ocaml: Fix xenctrl ABI and introduce build-time checks

c/s f089fddd941 broke the Ocaml ABI by renumering XEN_SYSCTL_PHYSCAP_directio without adjusting the Ocaml physinfo_cap_flag enumeration. Fix this by inserting CAP_PV between CAP_HVM and CAP_DirectIO. Factor out the bitmap-to-list conversion logic into a helper, to avoid an opencoded truncation of

[Xen-devel] [PATCH] fixup sysctl/libxl: choose a sane default for HAP

This delta wants folding to keep the Ocaml stubs in line. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Roger Pau Monné CC: Christian Lindig CC: Rob Hoes --- tools/ocaml/libs/xc/xenctrl.ml | 1 + tools/ocaml/libs/xc/xenctrl.mli | 1 + tools/ocaml/libs/xc/xenctrl_

Re: [Xen-devel] [PATCH v3 2/2] sysctl/libxl: choose a sane default for HAP

Roger Pau Monne writes ("[PATCH v3 2/2] sysctl/libxl: choose a sane default for HAP"): > Current libxl code will always enable Hardware Assisted Paging (HAP), > expecting that the hypervisor will fallback to shadow if HAP is not > available. With the changes to the domain builder that's not the ca

Re: [Xen-devel] [PATCH V3 1/8] iommu/arm: Add iommu_helpers.c file to keep common for IOMMUs stuff

On 09.09.19 14:45, Julien Grall wrote: Hi Oleksandr, Hi, Julien On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Introduce a separate file to keep various helpers which could be used by more than one IOMMU driver in order not to duplicate code. The first candi

Re: [Xen-devel] [PATCH v2 21/48] xen/sched: use sched_resource cpu instead smp_processor_id in schedulers

On 09.08.2019 16:58, Juergen Gross wrote: > Especially in the do_schedule() functions of the different schedulers > using smp_processor_id() for the local cpu number is correct only if > the sched_unit is a single vcpu. As soon as larger sched_units are > used most uses should be replaced by the cp

Re: [Xen-devel] [PATCH V3 2/8] iommu/arm: Add ability to handle deferred probing request

On 09.09.19 15:24, Julien Grall wrote: Hi Oleksandr, Hi, Julien The code looks code, few comments below. On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds minimal required support to General IOMMU framework to be able to handle a case when IOMMU

Re: [Xen-devel] [PATCH v2] tools/ocaml: Fix xenctrl ABI and introduce build-time checks

Andrew Cooper writes ("[PATCH v2] tools/ocaml: Fix xenctrl ABI and introduce build-time checks"): > c/s f089fddd941 broke the Ocaml ABI by renumering XEN_SYSCTL_PHYSCAP_directio > without adjusting the Ocaml physinfo_cap_flag enumeration. Fix this by > inserting CAP_PV between CAP_HVM and CAP_Dir

Re: [Xen-devel] [PATCH V3 6/8] iommu: Add of_xlate callback

On 09.09.19 15:37, Julien Grall wrote: Hi, Hi, all. On 8/27/19 4:11 PM, Jan Beulich wrote: On 27.08.2019 16:59, Oleksandr wrote: There was a preference to introduce callback in a separate patch [2]. Anyway, shall I fold it? Hmm, I disagree with Julien here. I don't think we should hav

Re: [Xen-devel] [PATCH v2 25/48] xen/sched: add runstate counters to struct sched_unit

On 09.08.2019 16:58, Juergen Gross wrote: > Add counters to struct sched_unit summing up runstates of associated > vcpus. What use are they (going to be)? Some justification of their introduction and the associated (however small or large) overhead of maintaining them would be nice here. Jan ___

Re: [Xen-devel] [PATCH] fixup sysctl/libxl: choose a sane default for HAP

Andrew Cooper writes ("[PATCH] fixup sysctl/libxl: choose a sane default for HAP"): > This delta wants folding to keep the Ocaml stubs in line. Gnagh. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenpr

[Xen-devel] [PATCH v4 0/5] enhance lock debugging

While hunting a locking problem in my core scheduling series I have added some debugging aids to spinlock handling making it easier to find the root cause for the problem. Making use of the already existing lock profiling and enhancing it a little bit produces some really valuable diagnostic data

[Xen-devel] [PATCH v4 2/5] xen: add new CONFIG_DEBUG_LOCKS option

Instead of enabling debugging for debug builds only add a dedicated Kconfig option for that purpose which defaults to DEBUG. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- V2: - rename to CONFIG_DEBUG_LOCKS (Jan Beulich) --- xen/Kconfig.debug | 7 +++ xen/common/spinlock

[Xen-devel] [PATCH v4 1/5] xen/spinlocks: in debug builds store cpu holding the lock

Add the cpu currently holding the lock to struct lock_debug. This makes analysis of locking errors easier and it can be tested whether the correct cpu is releasing a lock again. Signed-off-by: Juergen Gross --- V2: - adjust types (Jan Beulich) V4: - add define for bitfield size to store cpu numbe

[Xen-devel] [PATCH v4 3/5] xen: print lock profile info in panic()

Print the lock profile data when the system crashes and add some more information for each lock data (lock address, cpu holding the lock). While at it use the PRI_stime format specifier for printing time data. This is especially beneficial for watchdog triggered crashes in case of deadlocks. In o

[Xen-devel] [PATCH v4 4/5] xen: modify lock profiling interface

Today adding locks located in a struct to lock profiling requires a unique type index for each structure. This makes it hard to add any new structure as the related sysctl interface needs to be changed, too. Instead of using an index the already existing struct name specified in lock_profile_regis

[Xen-devel] [PATCH v4 5/5] xen: add function name to lock profiling data

A spinlock defined via DEFINE_SPINLOCK() as a static variable local to a function shows up in lock profiling just with its local variable name. This results in multiple locks just named "lock". In order to be able to distinguish those locks in the lock profiling output add the function name to str

Re: [Xen-devel] [PATCH V3 8/8] iommu/arm: Add Renesas IPMMU-VMSA support

On 02.09.19 10:04, Yoshihiro Shimoda wrote: Hi Oleksandr-san, Hi, Shimoda-san From: Oleksandr, Sent: Thursday, August 29, 2019 7:56 PM About this hardware handling, this patch seems good to me. But, since I'm not familiar about Xen passthrough framework, I think I cannot add my Reviewe

Re: [Xen-devel] [PATCH v2 22/48] xen/sched: switch schedule() from vcpus to sched_units

On 09.08.2019 16:58, Juergen Gross wrote: > --- a/xen/common/schedule.c > +++ b/xen/common/schedule.c > @@ -248,6 +248,20 @@ static inline void vcpu_runstate_change( > v->runstate.state = new_state; > } > > +static inline void sched_unit_runstate_change(struct sched_unit *unit, > +bool

Re: [Xen-devel] [PATCH V3 5/8] iommu/arm: Add lightweight iommu_fwspec support

Hi Oleksandr, On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko We need to have some abstract way to add new device to the IOMMU based on the generic IOMMU DT bindings [1] which can be used for both DT (right now) and ACPI (in future). For that reason we can borrow th

[Xen-devel] [qemu-mainline test] 141156: trouble: blocked/broken

flight 141156 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/141156/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops broken build-i386

Re: [Xen-devel] [PATCH V3 5/8] iommu/arm: Add lightweight iommu_fwspec support

On 09.09.19 17:36, Julien Grall wrote: Hi Oleksandr, Hi, Julien On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko We need to have some abstract way to add new device to the IOMMU based on the generic IOMMU DT bindings [1] which can be used for both DT (right now

[Xen-devel] [Vote] XCP-ng subproject proposal

Hello everyone, Olivier had posted an RFC for this proposal on xen-devel@- see https://xen.markmail.org/thread/ermnrb3ps3okvnjr The proposal also has been discussed by the Advisory Board and was approved However, for the proposal to fully pas

Re: [Xen-devel] [PATCH v4 1/5] xen/spinlocks: in debug builds store cpu holding the lock

On 09.09.2019 16:31, Juergen Gross wrote: > --- a/xen/include/xen/spinlock.h > +++ b/xen/include/xen/spinlock.h > @@ -5,15 +5,24 @@ > #include > #include > > +#define SPINLOCK_CPU_BITS 12 > + > #ifndef NDEBUG > -struct lock_debug { > -s16 irq_safe; /* +1: IRQ-safe; 0: not IRQ-safe; -1:

Re: [Xen-devel] [PATCH v4 1/5] xen/spinlocks: in debug builds store cpu holding the lock

On 09.09.19 16:50, Jan Beulich wrote: On 09.09.2019 16:31, Juergen Gross wrote: --- a/xen/include/xen/spinlock.h +++ b/xen/include/xen/spinlock.h @@ -5,15 +5,24 @@ #include #include +#define SPINLOCK_CPU_BITS 12 + #ifndef NDEBUG -struct lock_debug { -s16 irq_safe; /* +1: IRQ-saf

Re: [Xen-devel] [PATCH V3 7/8] iommu/arm: Introduce iommu_add_dt_device API

Hi Oleksandr, On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds new iommu_add_dt_device API for adding DT device to the IOMMU using generic IOMMU DT bindings [1] and previously added "iommu_fwspec" support and "add_device/of_xlate" callbacks. New funct

Re: [Xen-devel] [PATCH v2 24/48] xen: switch from for_each_vcpu() to for_each_sched_unit()

On 09.08.2019 16:58, Juergen Gross wrote: > @@ -504,22 +511,21 @@ int sched_move_domain(struct domain *d, struct cpupool > *c) > if ( IS_ERR(domdata) ) > return PTR_ERR(domdata); > > -vcpu_priv = xzalloc_array(void *, d->max_vcpus); > -if ( vcpu_priv == NULL ) > +unit_p

Re: [Xen-devel] [PATCH v2] tools/ocaml: Fix xenctrl ABI and introduce build-time checks

On 09/09/2019 15:25, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH v2] tools/ocaml: Fix xenctrl ABI and introduce > build-time checks"): >> c/s f089fddd941 broke the Ocaml ABI by renumering XEN_SYSCTL_PHYSCAP_directio >> without adjusting the Ocaml physinfo_cap_flag enumeration. Fix this by

[Xen-devel] [linux-linus test] 141157: trouble: blocked/broken

flight 141157 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/141157/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-arm64-pvops

  1   2   >