similar to: Re: [RFC/RFT][PATCH 0 of 3] rework locking in sched_adjust

sched_sedf.c used o have its own mechanism for producing tracing-alike kind of information (domain block, wakeup, etc.). Nowadays, with an even not so high number of pCPUs/vCPUs, just trying to enable this makes the serial console completely unusable, produces tons of very hard to parse and interpreet logging and can easily livelock Dom0. Moreover, pretty much the same result this is struggling to

Hello everyone, Reposting with after having applied the (minor) fixes suggested by Wei and Jan. Allen, if you can tell us what you think about this, or suggest someone else to ask some feedback to, if you''re no longer involved with VT-d, that would be great! :-) -- As already discussed here [1], dealing with IOMMU faults in interrupt context may cause nasty things to happen, up to

On Mon, Oct 17, 2011 at 05:36:27PM +0200, Dario Faggioli wrote: > Hi everyone, > > I''m trying to setup PCI-passthrough for a network card on a testbox. > With HVM, everything seems to work, while if I try with a pv-guest the > domain crashes! > > Here''s the thing: > -- > # xl pci-list-assignable-devices > 0000:07:00.0 > 0000:07:00.1 > >

On Tue, 2012-10-30 at 15:35 +0100, Dario Faggioli wrote: > Specific information regarding testing Xen > on Fedora can be found in this Wiki page: > > http://wiki.xen.org/wiki/Fedora_Test_Days > And let me just add that we also have a Fedora-Xen LiveCD. I just finished cooking it, tested it, and it seems to be working! If you decide to try it, it will bring you into a Fedora 18

Hello, This small series deals with some weirdness in the mechanism with which the credit scheduler choses what PCPU to tickle upon a VCPU wake-up. Details are available in the changelog of the first patch. The new approach has been extensively benchmarked and proved itself either beneficial or harmless. That means it does not introduce any significant amount of overhead and/or performances

9d1fd58ff602 was bogous in not letting a new domain being created if its scheduling parameters --when running under the sedf scheduler-- were not fully specified, making creation fail like in this example here below: 2012-06-16 07:37:47 Z executing ssh ... root@10.80.248.105 xl create /etc/xen/debian.guest.osstest.cfg libxl: error: libxl.c:3619:sched_sedf_domain_set: setting domain sched sedf:

About rationale, usage and (some small bits of) API. Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> --- Changes from v7: * avoid referring to 4.2 release as "upcoming". * libxl placement disabling key explicitly mentioned. * Limit of max 16 NUMA nodes explicitly mentioned. Changes from v6: * text updated to

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski <krzk at kernel.org> ---

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski <krzk at kernel.org> ---

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski <krzk at kernel.org> ---

On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert at linux-m68k.org> wrote: > > Hi Krzysztof, > > On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote: > > On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski <krzk at kernel.org> wrote: > > > The ioread8/16/32() and others have inconsistent interface among the > >

Hi Christophe, On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy <christophe.leroy at c-s.fr> wrote: > Le 08/01/2020 ? 09:18, Krzysztof Kozlowski a ?crit : > > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert at linux-m68k.org> wrote: > >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote: > >>> On Tue, Jan 7,

On Wed, Jan 08, 2020 at 09:10:06AM +0100, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski <krzk at kernel.org> wrote: > > The ioreadX() helpers have inconsistent interface. On some architectures > > void *__iomem address argument is a pointer to const, on some not. > > > > Implementations of ioreadX() do not

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski <krzk at kernel.org> ---

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski <krzk at kernel.org> ---

Hi Krzysztof, On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski <krzk at kernel.org> wrote: > The ioread8/16/32() and others have inconsistent interface among the > architectures: some taking address as const, some not. > > It seems there is nothing really stopping all of them to take > pointer to const. Shouldn't all of them take const volatile __iomem pointers? It

On Wed, Jan 8, 2020 at 9:36 AM Christophe Leroy <christophe.leroy at c-s.fr> wrote: > Le 08/01/2020 ? 09:18, Krzysztof Kozlowski a ?crit : > > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert at linux-m68k.org> wrote: > > I'll add to this one also changes to ioreadX_rep() and add another > > patch for volatile for reads and writes. I guess your review

I've now been able to test shared-library builds: 2.0.4 2.0.5 -------------------------------------------------------------------- alpha/alpha-linux-gnu: fail: fcntl, sigint, 2c fail: sigint, 2c arm/arm-linux-gnueabi: pass pass arm/arm-linux-gnueabihf: pass pass

Hi, On Fri, Sep 22, 2023 at 2:06?PM Lyude Paul <lyude at redhat.com> wrote: > > actually very glad to see this because I think I've seen one bug in the wild > as a result of things not getting shut down :) > > Reviewed-by: Lyude Paul <lyude at redhat.com> > Tested-by: Lyude Paul <lyude at redhat.com> Any idea of where / how this patch should land. Would

Hi, On Fri, Nov 17, 2023 at 3:00?PM Doug Anderson <dianders at chromium.org> wrote: > > Hi, > > On Fri, Sep 22, 2023 at 2:06?PM Lyude Paul <lyude at redhat.com> wrote: > > > > actually very glad to see this because I think I've seen one bug in the wild > > as a result of things not getting shut down :) > > > > Reviewed-by: Lyude Paul