t or function shall use the same
> > names
> > and type qualifiers").
> >
> > No functional changes.
> >
> > Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
>
Acked-by: Dario Faggioli
Thanks and Regards
--
Dario
On Mon, 2023-07-31 at 14:40 -0700, Stefano Stabellini wrote:
> George, Dario,
>
> Please ack
>
Looks good to me.
Acked-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://
On Thu, 2023-05-18 at 17:27 -0400, Stewart Hildebrand wrote:
> On 5/5/23 01:59, Juergen Gross wrote:
> > >
> > > Signed-off-by: Stewart Hildebrand
> >
> > Reviewed-by: Juergen Gross
>
> Thanks for the review. Does this still need a maintainer ac
On Fri, 2022-10-21 at 12:39 +0200, Juergen Gross wrote:
> Instead of directly falling back to the idle unit in case the top
> unit from the run queue happened to be not runnable, consult the run
> queue again.
>
> Suggested-by: Dario Faggioli
> Signed-off-by: Juergen Gross
&g
? 0 : notifier_to_errno(notifier_rc);
>
> Simplify the use cases by moving the handling of the success case
> into
> the functions.
>
> Signed-off-by: Juergen Gross
> ---
> ...
> xen/common/sched/core.c | 2 +-
> xen/common/sched/cpupool.c |
: don't disable scheduler on cpus
> during suspend")
> Signed-off-by: Juergen Gross
> Tested-by: Marek Marczykowski-Górecki
>
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.
On Fri, 2022-10-07 at 13:17 +0200, Juergen Gross wrote:
> On 07.10.22 12:32, Mykyta Poturai wrote:
> >
> > Signed-off-by: Juergen Gross
>
> I can't remember having written this patch. The one I remember was
> for
> x86.
>
> > Reviewed-by: Dario Faggioli
&g
no matter what the
outcome of this subthread will be. :-)
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majer
en/sched: introduce unit_runnable_state()")
> Signed-off-by: Juergen Gross
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
--
: sched: simplify ACPI S3 resume path.")
>
> This Fixes: tag is wrong. It should be:
>
> Fixes: 8a04eaa8ea83 ("xen/sched: move some per-vcpu items to struct
> sched_unit")
>
Acked-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggi
sive test, but just dom0 was enough to crash it before, and
> it
> stays working now.
>
That's very cool to hear! Thanks for testing and reporting back.
Just to be sure, did you check both Credit1 and Credit2 and do they
both work, with Juergen's patch?
Thanks again and Regards
--
Dar
On Wed, 2022-08-03 at 08:19 +0200, Jan Beulich wrote:
> On 02.08.2022 18:08, Dario Faggioli wrote:
> > > ... for it to be strictly only Dom0, you want to check d-
> > > >domain_id
> > > here.
> > >
> > Ok, I'll send an update that does that
user changes the hard-affinity.
And this could result in the vCPUs behaving differently than what the
user wanted and expects.
Fixes: dafd936dddbd ("Make credit2 the default scheduler")
Reported-by: Olaf Hering
Signed-off-by: Dario Faggioli
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
If dom0_vcpus_pin is used, make sure the pinning is only done for
dom0 vcpus, instead of for the hardware domain (which might not be
dom0 at all!).
Suggested-by: Jan Beulich
Signed-off-by: Dario Faggioli
Reviewed-by: Jan Beulich
---
Cc: George Dunlap
---
Changes from v1:
- check domain_id
, make the dom0_vcpus_pin boot parameter more precise, by
making sure that it is applied only to actual dom0's vCPUs, and not to
the vCPUs of the hardware domain, which may or may not be dom0 itself
(patch 2).
Regards
---
Dario Faggioli (2):
xen: sched: dom0_vcpus_pin should only affect dom0
xen/sched:
On Tue, 2022-08-02 at 16:56 +0200, Jan Beulich wrote:
> On 02.08.2022 15:51, Dario Faggioli wrote:
> > If dom0_vcpus_pin is used, make sure the pinning is only done for
> > dom0 vcpus, instead of for the hardware domain (which might not be
> > dom0 at all!).
>
> Hmm,
Mmm... this patch has a few hard-tabs in it! Apologies for that. :-/
I'm attaching a version without them, but I surely can resubmit the
series with this fixed, it that's easier.
Regards, and Sorry again
On Tue, 2022-08-02 at 15:51 +0200, Dario Faggioli wrote:
> Right now, affinity for d
user changes the hard-affinity.
And this could result in the vCPUs behaving differently than what the
user wanted and expects.
Fixes: dafd936ddd ("Make credit2 the default scheduler")
Reported-by: Olaf Hering
Signed-off-by: Dario Faggioli
---
Cc: Jan Beulich
Cc: George Dunlap
---
If dom0_vcpus_pin is used, make sure the pinning is only done for
dom0 vcpus, instead of for the hardware domain (which might not be
dom0 at all!).
Suggested-by: Jan Beulich
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
Difference from "RFC" [1]:
- new patch
may or may not be dom0 itself
(patch 2).
Regards
---
Dario Faggioli (2):
xen: sched: dom0_vcpus_pin should only affect dom0
xen/sched: setup dom0 vCPUs affinity only once
xen/common/sched/core.c | 63 +
1 file changed, 39 insertions(+), 24
e-test it and send
it before disappearing for a couple of weeks for vacations...
Sorry it's taking so long.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE ht
On Fri, 2022-04-29 at 14:16 +0200, Jan Beulich wrote:
> On 29.04.2022 12:52, Dario Faggioli wrote:
> > > Is that mainly
> > > to have a way to record preferences even when all preferred CPUs
> > > are
> > > offline, to be able to go back to the preferences
On Wed, 2022-04-13 at 12:00 +0200, Jan Beulich wrote:
> On 12.04.2022 18:11, Dario Faggioli wrote:
> > --- a/xen/common/sched/core.c
> > +++ b/xen/common/sched/core.c
> > @@ -572,11 +572,41 @@ int sched_init_vcpu(struct vcpu *v)
> > }
> >
> > /*
&
viewed-by: Juergen Gross
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.a
On Tue, 2022-04-12 at 16:11 +, Dario Faggioli wrote:
> + else if ( is_hardware_domain(d) )
> + {
> + /*
> + * In absence of dom0_vcpus_pin, the hard and soft affinity
> of
> + * domain-0 is controlled by the dom0_nodes paramete
On Tue, 2022-04-12 at 16:11 +, Dario Faggioli wrote:
> On Tue, 2022-04-12 at 15:48 +0000, Dario Faggioli wrote:
> > On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
> >
> >
> > And while doing that, I think we should consolidate touching the
> > affin
On Tue, 2022-04-12 at 15:48 +, Dario Faggioli wrote:
> On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
>
>
> And while doing that, I think we should consolidate touching the
> affinity only there, avoiding altering it twice. After all, we
> already
> know how it
On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
> On 08.04.2022 13:20, Dario Faggioli wrote:
> > On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote:
> > > Credit2 moving the vCPU-s off of their initially assigned ones
> > > right
> > > away of course
On Fri, 2022-04-08 at 11:20 +, Dario Faggioli wrote:
> On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote:
> >
> > Credit2 moving the vCPU-s off of their initially assigned ones
> > right
> > away of course renders sched_select_initial_cpu()'s use of
> &g
; xen/common/boot_cpupools.c or xen/common/boot-cpupools.c
> > >
> >
> > ... this one may want living there are well.
>
> Yes I agree with you all, I will rename it to xen/common/sched/boot-
> cpupool.c
> and add it in MAINTAINERS.
>
FWIW, I agree as well. Wit
e, mostly because that would mean calling
domain_update_node_affinity() for all dom0's vCPUs, which is clearly
less efficient than just calling it once at the end.
So I'm thinking that we can indeed do it like this, and add a comment.
m
> parts
> Acked-by: Jan Beulich
> Tested-by: Téo Couprie Diaz
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
--
e occasion to replace open coded scheduler search with the
> new static function in scheduler_init.
>
> Signed-off-by: Luca Fancellu
> Reviewed-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Sof
e, and I appreciate that it's not trivial and
that it's probably impossible to achieve 100% decoupling (at least not
without adding a lot more complexity)... But any step we can make in
that direction would be, IMO, a good investment.
Re
I've read that
QubesOS that it does on QubesOS, but I'm not sure if the situation
is the same...
- if it's working, how?
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs,
=0x7fe721df11b0, domid=domid@entry=0x7fe721df10a8,
ao_how=ao_how@entry=0x0, aop_console_how=aop_console_how@entry=0x7fe721df10f0)
at libxl_create.c:2075
Signed-off-by: Dario Faggioli
Tested-by: James Fehlig
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
---
This change should be backported to all
On Mon, 2022-01-17 at 15:56 +, Anthony PERARD wrote:
> On Fri, Jan 14, 2022 at 11:22:00PM +0000, Dario Faggioli wrote:
> >
> > Also, if we go that way, I guess we want to change
> > libxl_cputopology_list_free(), libxl_pcitopology_list_free(),
> &g
be a problem for PV guests, too?
>
Yeah, that's one of the things that makes it tricky
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
On Thu, 2022-01-13 at 12:05 +, Anthony PERARD wrote:
> On Wed, Jan 12, 2022 at 05:41:36PM +0100, Dario Faggioli wrote:
>
> > 2) there should be nothing to free anyway
>
> The issue here is that it doesn't appear to be true. Even if "info"
> is
> NULL, &
hat
yet.
So, if anyone wants to help with this, handing over suggestions for
potential good spots, that would help a lot.
Alternatively, we can submit the series as ARM-only... But I fear that
the x86 side of things would then be easily forgotten. :-(
Thanks again and Regards
--
On Wed, 2022-01-12 at 17:41 +0100, Dario Faggioli wrote:
> It is possible to encounter a segfault in libxl during concurrent
> domain
> create and destroy operations.
>
> This is because Placement of existing domains on the host's CPUs is
> examined
> when creating a new dom
() or
xc_vcpu_getaffinity() will start to fail, and we return back to the
caller inconsistent information, such as a NULL list of vcpus, but a
modified and not 0 any longer, number of vcpus in the list.
Signed-off-by: Dario Faggioli
Tested-by: James Fehlig
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
If libxl_vcpu_list() returned NULL, we should not call
libxl_numainfo_list_free() as:
1) it'll fail trying to (double) free() *list
2) there should be nothing to free anyway
Signed-off-by: Dario Faggioli
Tested-by: James Fehlig
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
---
tools
NULL as the list of them.
Regards
---
Dario Faggioli (2):
tools/libs/light: numa placement: don't try to free a NULL list of vcpus
tools/libs/light: don't touch nr_vcpus_out if listing vcpus and returning
NULL
tools/libs/light/libxl_domain.c | 14 --
tools/libs/light
Signed-off-by: Daniel P. Smith
> ---
> xen/arch/x86/cpu/vpmu.c | 2 +-
> xen/common/domctl.c | 2 +-
> xen/common/sched/core.c | 4 ++--
> xen/include/xen/sched.h | 5 +
>
The */sched* bits:
Acked-by: Dario Faggioli
But with a strong preference for renaming
is_system_d
ut-xl_vcpu-list
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
fnptr targets
> > x86/aepi: Annotate fnptr targets
> > x86/psr: Annotate fnptr targets
> > x86/dpci: Annotate fnptr targets
> > x86/pt: Annotate fnptr targets
> > x86/time: Annotate fnptr targets
> > x86/misc: Annotate fnptr targets
> > x86/s
On Mon, 2021-09-27 at 09:51 +0200, Jan Beulich wrote:
> On 24.09.2021 16:51, Dario Faggioli wrote:
> > On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> >
> > > There is one buggy race record, TRC_RTDS_BUDGET_BURN. As it must
> > > remain
> >
igned-off-by: Andrew Cooper
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin
ndrew Cooper
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.asc
igned-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
--
r
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<>
gt; which was absent previously.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-
, which is dropped. (The optimiser
> also spotted
> this, which is why it doesn't manifest as a binary difference.)
> * All HVMTRACE_?D() change to TRACE() as cycles is explicitly
> skipped.
>
> Signed-off-by: Andrew Cooper
>
Reviewed-by: Dario Faggioli
Regard
On Tue, 2021-09-21 at 13:03 +0200, Jan Beulich wrote:
> On 20.09.2021 19:25, Andrew Cooper wrote:
> >
> > Signed-off-by: Andrew Cooper
>
> Like for v1: Largely
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
> One remark:
>
> > @@ -717,9 +713,
g them in
just one field and decode the information in xentrace.
Of course, I can send a patch for that myself, even as a followup of
this series when it's in, as soon as we agree about the best way
forward.
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization
uncation? */ in place so
> whomever
> encounters weird behaviour from this trace record has a bit more help
> of
> where to look?
>
Sure, that's fine for me.
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/
ain().
>
> Fix that by tolerating vcpus not being allocated yet.
>
> Fixes: 70fadc41635b9b6 ("xen/cpupool: support moving domain between
> cpupools with different granularity")
> Reported-by: Bertrand Marquis
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
off-by: Juergen Gross
> Tested-by: Marek Marczykowski-Górecki
>
>
Mmm... This is an interesting one. In fact, this fix is not only
correct, it's also simple, effective and (I guess) easy enough to
backport.
Considering all these things together with the fact that we have an
open issue, I
_remove(), called by sched_destroy_vcpu().
And I agree that the unit should be offline, but null_unit_remove()
calls unit_deassign() only if the unit *is* online, so... What's going
on? :-/
Regards
--
Dario Faggioli, Ph.D
http://about.
, it's entirely possible that I'm missing something obvious here, but
what it is that is making you think that we're in null_unit_migrate() ?
Does that come from a different instance of this WARN() ?
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-08-05 at 08:31 +0200, Jan Beulich wrote:
> On 04.08.2021 19:55, Dario Faggioli wrote:
> >
> > Suggested-by: George Dunlap
> > Signed-off-by: Dario Faggioli
>
> In part based on your explanation in response to my v1 comments:
> Reviewed-by: Jan Beulic
at, during the runqueue scan, does not have enough budget for being run,
we should continue looking instead than giving up and picking the idle
unit.
Suggested-by: George Dunlap
Signed-off-by: Dario Faggioli
Cc: George Dunlap
Cc: Jan Beulich
---
Changes from v1:
* fixed the patch tags and some st
On Wed, 2021-08-04 at 17:13 +0200, Jan Beulich wrote:
> On 04.08.2021 15:28, Dario Faggioli wrote:
> >
> > So, was it this you were asking about and, if yes, does this answer
> > your concerns?
>
> Yes, it does.
>
Ok, great. :-)
> I continue to think though tha
On Wed, 2021-08-04 at 09:37 +0200, Jan Beulich wrote:
> On 03.08.2021 19:36, Dario Faggioli wrote:
> >
> > Signed-off-by: Dario Faggioli
> > Suggested-by: George Dunlap
>
> Minor remark: Generally I think the order of tags should follow the
> timeline: Suggestion
("xen: credit2:
implement utilization cap") and in 34f2ad1 ("xen: credit2: use
non-atomic cpumask and bit operations").
Suggested-by: Juergen Gross
Signed-off-by: Dario Faggioli
Cc: George Dunlap
Cc: Jan Beulich
---
This patch is only necessary for branches older than 4.
On Tue, 2021-08-03 at 19:36 +0200, Dario Faggioli wrote:
> It should, therefore, be backported and applied to all the branches
> to
> which that commit has been. About backports, it should be
> straigthforward to do that until 4.13.
>
> For 4.12 and earlier, it's trickier, bu
Err... of course, the "pli" and "bla" stuff between the [] are a
leftover of some experiments that I had to do with `stg email`, due to
mail handling changes, and should really not have been there in this
email...
Sorry. :-/
On Tue, 2021-08-03 at 19:36 +0200, Dario Fagg
at, during the runqueue scan, does not have budget to be executed, we
should continue looking instead than giving up and picking the idle
unit.
Signed-off-by: Dario Faggioli
Suggested-by: George Dunlap
Cc: George Dunlap
Cc: Jan Beulich
---
This is necessary to completely fix the bug that was
Hi George (and sorry for the delay in replying),
On Mon, 2021-06-07 at 12:10 +, George Dunlap wrote:
> > On May 28, 2021, at 4:12 PM, Dario Faggioli
> > wrote:
> > Reported-by: Michał Leszczyński
> > Reported-by: Dion Kant
> > Signed-off-by: Dario Fagg
On Tue, 2021-04-27 at 10:35 +0200, Jan Beulich wrote:
> On 19.03.2021 13:14, Dario Faggioli wrote:
> >
> > ---
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > ---
> > Despite the limited effect, it's a bug. So:
> > - it should be backported;
> >
scanning function.
Reported-by: Michał Leszczyński
Reported-by: Dion Kant
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Michał Leszczyński
Cc: Dion Kant
---
This is a bugfix and it solves the following problems, reported in
various ways:
* https://lists.xen.org/archives
early with the shim defaulting to it, SCHED_NULL must be supported at
> least there.
>
> Signed-off-by: Jan Beulich
> Acked-by: Roger Pau Monné
>
Reviewed-by: Dario Faggioli
> ---
> v2: Also drop SCHED_NULL setting from defconfig. Make SCHED_NULL the
> default when PV_SHIM_EXCLUSI
On Thu, 2021-05-20 at 14:55 +0100, Anthony PERARD wrote:
> On Tue, May 18, 2021 at 05:24:30PM +0200, Dario Faggioli wrote:
> >
> > I think we need the following commit in our QEMU: bbd2d5a812077
> > ("build: -no-pie is no functional linker flag").
>
> Hi
figure: creating ./config.status
So, what am I missing or doing wrong?
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Ra
On Wed, 2021-05-19 at 08:28 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 06:42:45PM +0200, Dario Faggioli wrote:
> > Fix the build inside our openSUSE Tumbleweed container by using
> > adding libzstd headers. While there, remove the explicit dependency
> > f
E Tumbleweed, therefore:
> > Signed-off-by: Costin Lupu
>
> Reviewed-by: Julien Grall
>
Tested-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
Fix the build inside our openSUSE Tumbleweed container by using
adding libzstd headers. While there, remove the explicit dependency
for python and python3 as the respective -devel packages will pull
them in anyway.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc
Use DOCKER_CMD from the environment (if defined) in the containers'
makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
podman is used for building the containers too.
Signed-off-by: Dario Faggioli
Acked-by: Roger Pau Monné
---
Cc: Doug Goldstein
Cc: Andrew Cooper
---
Changes
that in containerize already, through the DOCKER_CMD variable)
to the local building of the containers as well.
Thanks and Regards
---
Dario Faggioli (2):
automation: use DOCKER_CMD for building containers too
automation: fix dependencies on openSUSE Tumbleweed containers
automation/build/suse
On Tue, 2021-05-18 at 16:33 +0200, Dario Faggioli wrote:
> On Tue, 2021-05-18 at 15:20 +0200, Roger Pau Monné wrote:
> > On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> > > From: Dario Faggioli
> > >
> Mmm... this email address does not re
to use it as a base, or tell me if I can help more with it in
any other way with it.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
On Tue, 2021-05-18 at 16:26 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 02:04:07PM +0200, Dario Faggioli wrote:
> > From: Dario Faggioli
> >
> > Use DOCKER_CMD from the environment (if defined) in the containers'
> > makefile too, so that, e.g., when doin
On Tue, 2021-05-18 at 15:20 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> > From: Dario Faggioli
> >
Mmm... this email address does not really exist, and it's a mistake
that it ended up here. :-/
> > Fix the buil
From: Dario Faggioli
Fix the build inside our openSUSE Tumbleweed container by using
the proper python development packages (and adding zstd headers).
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc: Andrew Cooper
---
.../build/suse/opensuse
From: Dario Faggioli
Use DOCKER_CMD from the environment (if defined) in the containers'
makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
podman is used for building the containers too.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc: Andrew
that).
While there, extend the generalization of the container runtime to use
(we have that in containerize already, through the DOCKER_CMD variable)
to the local building of the containers as well.
Regards
---
Dario Faggioli (2):
automation: use DOCKER_CMD for building containers too
automation
t we would prefer the plugin to end up in one of
those places, rather than remaining its own project. And of course
we're up for maintaining it, wherever it lands. :-)
> We are working to make sure that the API for KernelShark plugins
> remains
> stable, so your plugins should always work t
PU.
This is pretty much arbitrary and can be changed, but it of course has
to be something that we can extract from from the trace event records
or, at least, from the trace file (e.g., as Andrew said, we do have
per-VM UUIDs, but they're currently not there).
Regards
--
Dario Faggioli, Ph.D
http:
ell you on what physical CPU
d0v5 runs. While the special 'CPU 5' plot that is "glued" to the
'd0/v5' one will tell you what tasks run on vCPU 5 of Dom0, at any
given point in time.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SU
ted in the trace-cmd
patches (but not KVM specific one). For synch'ing the Xen trace with
them, well, I don't really know... We'd have to think about it. :-P
> Perhaps we can do something like that with Xen as well.
>
Would be awesome, IMO. :-)
Thanks and Regards
--
Dario Faggioli, Ph.D
http
On Wed, 2021-04-14 at 19:11 +0100, Andrew Cooper wrote:
> On 14/04/2021 18:31, Dario Faggioli wrote:
> > > A couple of questions. Which Xen libraries do you currently use
> > > map
> > > the
> > > frames?
> > >
> > Err... If I understood
'll now leave any further comments to Giuseppe himself. :-)
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Rais
ct that we wanted to let the Xen and
KernelShark communities know about this work as soon as Giuseppe got it
working properly and reliably, to gather any kind of feedback, decide
where this should live, in the long run, (in Xen? In KS? In its own
project?), etc. :-)
Thanks and Regards
>
Oh, wow... Sorry about that. I was sure I had checked (and with gcc10),
but clearly I'm wrong.
> [...]
>
> Re-instate a special form of for_each_cpu(), experimentally "proven"
> to
> avoid the diagnostics.
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Dar
On Thu, 2021-03-18 at 19:11 +0100, Dario Faggioli wrote:
> On Mon, 2021-03-15 at 12:18 +, Ian Jackson wrote:
>
> >
> > https://bugzilla.opensuse.org/show_bug.cgi?id=1179246
> >
> So, this is mostly about the third issue, the one described in the
> openSU
) 8: [0.7] flags=2 cpu=0 credit=9991815 [w=256] load=262144 (~100%)
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
---
Despite the limited effect, it's a bug. So:
- it should be backported;
- I think it should be included in 4.15. The risk is pretty low, for
the same
of the feature prereqs
> (TSC_RELIABLE) that are required for "clocksource=tsc" to take
> any effect, afaict. I therefore would conclude that you're not
> actually running with TSC as the clock source.
>
Right. Also, isn't hpetbroadcast set to 0 by default already?
Dario
gt; BUG: credit=sched2 machine hang when using DRAKVUF
>
> Information from
> Dario Faggioli
> References
> https://lists.xen.org/archives/html/xen-devel/2020-05/msg01985.html
>
> https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01561.html
> https
On Thu, 2021-03-11 at 12:28 +0100, Jan Beulich wrote:
> On 11.03.2021 10:40, Dario Faggioli wrote:
> >
> > Removing the special casing of NR_CPUS == 1 makes things work again.
> >
> > Signed-off-by: Dario Faggioli
>
> Doesn't this want a Reported-by: Roger?
1 - 100 of 770 matches
Mail list logo
