Choi
>
> Reviewed-by: Stewart Hildebrand
>
Ok, cool, there were versions of these series that my filters did miss,
and that's why I replied to v1. :-/
Well, scratch that email, and sorry for the noise.
Regards,
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualizati
se according to my knowledge of periodic real-time scheduling.
I think the patch can have my:
Acked-by: Dario Faggioli
With the only caveat that I don't have any specific knowledge or
experience with the details of the ARINC653 algorithms, and hence I
cannot tell for sure whether or not the new
clude:: qemu-block-drivers.rst.inc
system/images.rst:.. include:: qemu-block-drivers.rst.inc
How can we deal with this?
Thanks and Regards,
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
--
ing patches, etc)... So let me know what I
can do. :-)
Regards,
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.as
rm in which it appears in that email) still correct?
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
Description: This is a digitally signed message part
> ---
> > MAINTAINERS | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6ba7d2765f..cc40c0be9d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -490,6 +490,7 @@ F: xen/common/sched/rt.c
On Fri, 2024-05-31 at 11:16 +0100, Joao Martins wrote:
> On 30/05/2024 18:00, Dario Faggioli via Devel wrote:
> >
> > IIUIC, it's a matter of number of bits available in the I/O APIC
> > IRQ
> > destination register. Like, with only that available, and it being
&g
load
> would be able to use VM as intended.
>
Ok. But then why Libvirt does not let me define a VM with more than 255
vCPUs and no vIOMMU ?
I mean, basing on what you're saying, it seems that such should depend
(but, if yes, I'm not sure how) on guest OS too... doesn't it
cgi?id=1219977
[2] well, I actually reverted a6ed6b701f0a57db0569ab98b0661c12a6ec3ff8
too, for convenience
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
hall 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
Keep the old limit of 288 for machine versions 7.2 and earlier.
Signed-off-by: Dario Faggioli
---
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: "Michael S. Tsirkin"
Cc: Marcel Apfelbaum
---
Changes from v1:
- fix actually keeping the old max value for the 7.2 ma
Well...
On Thu, 2022-11-17 at 16:27 +0100, Dario Faggioli wrote:
> Keep the old limit of 288 for machine versions 7.2 and earlier.
>
...At least, this was the idea...
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -386,6 +386,7 @@ static void
> pc_q35_7_1_machine_optio
Keep the old limit of 288 for machine versions 7.2 and earlier.
Signed-off-by: Dario Faggioli
---
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
Cc: "Michael S. Tsirkin"
Cc: Marcel Apfelbaum
---
This is related to:
https://lore.kernel.org/
ent in pc_q35_machine_options() ? Or do we want a new
version of the machine type or something like that?
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
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 |
ed: 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:/
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 Faggiol
ct and should be applied, 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/
---
407e7772 ("xen/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/
--
0b04 ("xen: 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
ves: https://gitlab.com/qemu-project/qemu/-/issues/1193
>
> [...]
>
> This reverts commit e2848bc574fe2715c694bf8fe9a1ba7f78a1125a
> and 77e3f038af1764983087e3551a0fde9951952c4d.
>
> Signed-off-by: Sam Li
>
Tested-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
htt
ves: https://gitlab.com/qemu-project/qemu/-/issues/1193
>
> [...]
>
> This reverts commit e2848bc574fe2715c694bf8fe9a1ba7f78a1125a
> and 77e3f038af1764983087e3551a0fde9951952c4d.
>
> Signed-off-by: Sam Li
>
Tested-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
htt
nsive 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
ed 52, it's a problem.
But maybe this is not something that should be solved at this level, as
it's probably the job of `virsh cpu-baseline`? Does that includes and
takes into account this aspect (phys-bits) already?
So, yeah, if that check was too much policying, I think it&#
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 tha
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 Be
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 to
atch 2).
While there, 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 onl
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, affi
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
---
Ch
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
rdware 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: setup dom0 vCPUs affinity only once
xen/common/sched/core.c | 63 +
1 file changed,
it, re-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 Lab
do fork all helpers, and
then "clear" the cookie for it.
But I guess that would be even worse...
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
problem.
The correct way to use module_kconfig is by passing the Kconfig option
to module_kconfig (or the *config-devices.mak without CONFIG_).
Signed-off-by: Jose R. Ziviani
Signed-off-by: Dario Faggioli
---
Cc: Gerd Hoffmann
Cc: John Snow
Cc: Cleber Rosa
Cc: Paolo Bonzini
Cc: qemu-s3
From: Jose R. Ziviani
This patch changes the way modinfo is generated and built. Instead of
one modinfo.c it generates one modinfo--softmmu.c per target. It
aims a fine-tune control of modules by configuring Kconfig.
Signed-off-by: Jose R. Ziviani
Signed-off-by: Dario Faggioli
---
Cc: Gerd
Hello,
This is a RESEND of patch series "[PATCH v3 0/2] modules: Improve modinfo.c
support", from Sept 2021.
Message-ID: <20210928204628.20001-1-jzivi...@suse.de>
https://lore.kernel.org/qemu-devel/20210928204628.20001-1-jzivi...@suse.de/
Jose sent it because we were having issues building QEMU
way around, i.e., someone already has
more info on the subject that I've not been able to find, feel free to
ping me. :-)
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
Since commit 3d2f73ef75e ("build: use "meson test" as the test harness"),
check-report.tap is no more, and we have check-report.junit.xml.
Update the output of 'make check-help', which was still listing
'check-report.tap', accordingly.
Fixes: 3d2f73ef7
On Fri, 2022-05-27 at 10:18 +0200, Claudio Fontana wrote:
> On 5/27/22 9:26 AM, Dario Faggioli wrote:
> > >
> > Yes, this kind of matches what I've also seen and reported about in
> > <5bcb5ceb44dd830770d66330e27de6a4345fcb69.ca...@suse.com>. If
> >
;. If
enable/run just one of:
- reconnect
- flags_mismatch
- connect_fail
I see no issues.
As soon as two of those are run, one after the other, the problem
starts to appear.
However, Claudio, AFAIUI, you're seeing this with an older GCC and
without LTO, right?
Regards
--
Dario Faggioli, Ph.D
http://a
On Thu, 2022-05-26 at 14:01 +0200, Dario Faggioli wrote:
> Thoughts?
>
Oh, and there are even a couple of other (potential) use case, for
having an (even more!) fine grained control of core-scheduling.
So, right now, giving a virtual topology to a VM, pretty much only
makes sense if the
or all... E.g.,
we can offer it as an higher SLA, and ask more money for a VM that has
it.
Thoughts?
In any case, even if we decide that we do want per-VM core-scheduling,
e.g., for the above mentioned reasons, I guess it can come later, as a
further improvement (and I'd be happy to help
On Wed, 2022-05-25 at 09:40 +, Dario Faggioli wrote:
> On Wed, 2022-05-25 at 07:41 +0100, Alex Bennée wrote:
>
>
> > Does it still trigger errors with my latest virtio cleanup series
> > (which
> > adds more tests to qos-test):
> >
> > Subject: [P
On Wed, 2022-05-25 at 07:41 +0100, Alex Bennée wrote:
> Dario Faggioli writes:
> > I'll try to dig further. Any idea/suggestion anyone has, feel free.
> > :-)
>
> Sounds like there are still memory corruption/not initialised issues
> that are affected by moving thi
On Wed, 2022-05-25 at 08:32 +0200, Gerd Hoffmann wrote:
> On Tue, May 24, 2022 at 01:49:41PM +0200, Dario Faggioli wrote:
> > Hello! Sorry for bringing up an old thread, but I'd have a question
> > about this series.
> >
> > As far as I can see, the patches were fi
On Mon, 2022-05-23 at 19:19 +, Dario Faggioli wrote:
> As soon as I get rid of _both_ "-flto=auto" _and_ "--enable-lto", the
> above tests seem to work fine.
>
> When they fail, they fail immediately, while creating the graph, like
> this:
>
> MALLOC
|| continue
> > res=$(./$qemu -nodefaults -display none -accel tcg -M none
> > -device help 2>&1 | grep "Failed to" > /dev/null; echo $?)
> > [[ $res -eq 0 ]] &&
people/distros that have, say, QEMU
6.2 and Libvirt 8.0.0, or something like that), there's basically
nothing they can do... Except perhaps command line passthrough [1], but
that's really rather tricky!
So, I personally don't know where any default should be set and how,
but the abov
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 parameter. At
> this p
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
> > affinity
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
instead of calling sched_set_affinity(), we call
vcpu_set_affinity().
I'm therefore wondering if we should try to just do that... But I'm not
sure, mostly because that would mean calling
domain_update_node_affinity() for all dom0
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
the code, 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
ve Cc-ed Marek, because I think 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/dari
ve Cc-ed Marek, because I think 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/dari
nfig@entry=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 backpor
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
l.
> And wouldn't that 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
> NU
could not do that
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 a
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 ne
tinfo() 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: Jue
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
---
turns 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 --
t
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
e-lakeside-output-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
> >
t;
> Signed-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/
---
<> (Rais
f-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 Majere)
sig
t;
> 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/
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/
---
<>
endering
> 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/
a nested tb_init_done check, 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
>
R
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
Virtualiz
* TODO: truncation? */ 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, P
gt;
> 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
-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 iss
null_unit_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.
, 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
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 trickie
1 - 100 of 3437 matches
Mail list logo
