similar to: [PATCH] iommu: spapr_tce: Disable compile testing to fix build on book3s_32 config

Displaying 20 results from an estimated 200 matches similar to: "[PATCH] iommu: spapr_tce: Disable compile testing to fix build on book3s_32 config"

2020 Apr 18
0
[PATCH] iommu: spapr_tce: Disable compile testing to fix build on book3s_32 config
On 04/14/2020 02:26 PM, Krzysztof Kozlowski wrote: > Although SPAPR_TCE_IOMMU itself can be compile tested on certain PowerPC > configurations, its presence makes arch/powerpc/kvm/Makefile to select > modules which do not build in such configuration. > > The arch/powerpc/kvm/ modules use kvm_arch.spapr_tce_tables which exists > only with CONFIG_PPC_BOOK3S_64. However these
2020 Apr 14
1
Build regressions/improvements in v5.7-rc1
On Tue, Apr 14, 2020 at 08:23:32PM +1000, Michael Ellerman wrote: > Geert Uytterhoeven <geert at linux-m68k.org> writes: > > On Mon, 13 Apr 2020, Geert Uytterhoeven wrote: > >> Below is the list of build error/warning regressions/improvements in > >> v5.7-rc1[1] compared to v5.6[2]. > >> > >> Summarized: > >> - build errors: +132/-3 >
2020 Apr 13
2
Build regressions/improvements in v5.7-rc1
On Mon, 13 Apr 2020, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v5.7-rc1[1] compared to v5.6[2]. > > Summarized: > - build errors: +132/-3 > - build warnings: +257/-79 > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1]
2020 Apr 13
2
Build regressions/improvements in v5.7-rc1
On Mon, 13 Apr 2020, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v5.7-rc1[1] compared to v5.6[2]. > > Summarized: > - build errors: +132/-3 > - build warnings: +257/-79 > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1]
2020 Apr 14
0
Build regressions/improvements in v5.7-rc1
Geert Uytterhoeven <geert at linux-m68k.org> writes: > On Mon, 13 Apr 2020, Geert Uytterhoeven wrote: >> Below is the list of build error/warning regressions/improvements in >> v5.7-rc1[1] compared to v5.6[2]. >> >> Summarized: >> - build errors: +132/-3 >> - build warnings: +257/-79 >> >> Happy fixing! ;-) >> >> Thanks to the
2016 Dec 06
2
[PATCH v8 2/6] powerpc: pSeries/Kconfig: Add qspinlock build config
On Mon, Dec 05, 2016 at 10:19:22AM -0500, Pan Xinhui wrote: > pSeries/powerNV will use qspinlock from now on. > > Signed-off-by: Pan Xinhui <xinhui.pan at linux.vnet.ibm.com> > --- > arch/powerpc/platforms/pseries/Kconfig | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
2016 Dec 06
2
[PATCH v8 2/6] powerpc: pSeries/Kconfig: Add qspinlock build config
On Mon, Dec 05, 2016 at 10:19:22AM -0500, Pan Xinhui wrote: > pSeries/powerNV will use qspinlock from now on. > > Signed-off-by: Pan Xinhui <xinhui.pan at linux.vnet.ibm.com> > --- > arch/powerpc/platforms/pseries/Kconfig | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
2020 Apr 22
1
[PATCH V2 0/2] mm/thp: Rename pmd_mknotpresent() as pmd_mkinvalid()
This series renames pmd_mknotpresent() as pmd_mkinvalid(). Before that it drops an existing pmd_mknotpresent() definition from powerpc platform which was never required as it defines it's pmdp_invalidate() through subscribing __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. This rename was suggested by Catalin during a previous discussion while we were trying to change
2020 Mar 20
4
[PATCH 0/2] mm/thp: Rename pmd_mknotpresent() as pmd_mknotvalid()
This series renames pmd_mknotpresent() as pmd_mknotvalid(). Before that it drops an existing pmd_mknotpresent() definition from powerpc platform which was never required as it defines it's pmdp_invalidate() through subscribing __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. This rename was suggested by Catalin during a previous discussion while we were trying to
2015 Jul 02
2
[PULL] virtio/vhost: cross endian support
On Thu, Jul 02, 2015 at 11:12:56AM +0200, Greg Kurz wrote: > On Thu, 2 Jul 2015 08:01:28 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: > > > On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > > > virtio/vhost: cross endian support
2015 Jul 02
2
[PULL] virtio/vhost: cross endian support
On Thu, Jul 02, 2015 at 11:12:56AM +0200, Greg Kurz wrote: > On Thu, 2 Jul 2015 08:01:28 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: > > > On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > > > virtio/vhost: cross endian support
2015 Jul 02
4
[PULL] virtio/vhost: cross endian support
On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: > On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > virtio/vhost: cross endian support > > Ugh. Does this really have to be dynamic? > > Can't virtio do the sane thing, and just use a _fixed_ endianness? > > Doing a unconditional byte swap is faster and simpler
2015 Jul 02
4
[PULL] virtio/vhost: cross endian support
On Wed, Jul 01, 2015 at 12:02:50PM -0700, Linus Torvalds wrote: > On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > virtio/vhost: cross endian support > > Ugh. Does this really have to be dynamic? > > Can't virtio do the sane thing, and just use a _fixed_ endianness? > > Doing a unconditional byte swap is faster and simpler
2015 Jul 07
5
[PULL] virtio/vhost: cross endian support
On Tue, Jul 07, 2015 at 06:36:53PM +0200, Thomas Huth wrote: > On Thu, 2 Jul 2015 11:32:52 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Thu, Jul 02, 2015 at 11:12:56AM +0200, Greg Kurz wrote: > > > On Thu, 2 Jul 2015 08:01:28 +0200 > > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > ... > > > >
2015 Jul 07
5
[PULL] virtio/vhost: cross endian support
On Tue, Jul 07, 2015 at 06:36:53PM +0200, Thomas Huth wrote: > On Thu, 2 Jul 2015 11:32:52 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Thu, Jul 02, 2015 at 11:12:56AM +0200, Greg Kurz wrote: > > > On Thu, 2 Jul 2015 08:01:28 +0200 > > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > ... > > > >
2015 Jul 09
2
[PATCH] KVM: Add Kconfig option to signal cross-endian guests
On 09/07/2015 09:49, Thomas Huth wrote: > The option for supporting cross-endianness legacy guests in > the vhost and tun code should only be available on systems > that support cross-endian guests. I'm sure I misunderstand something, but what happens if we use QEMU with TCG instead of KVM, i.e. a big endian powerpc kernel guest on x86_64 little endian host ? Do you forbid the use of
2015 Jul 09
2
[PATCH] KVM: Add Kconfig option to signal cross-endian guests
On 09/07/2015 09:49, Thomas Huth wrote: > The option for supporting cross-endianness legacy guests in > the vhost and tun code should only be available on systems > that support cross-endian guests. I'm sure I misunderstand something, but what happens if we use QEMU with TCG instead of KVM, i.e. a big endian powerpc kernel guest on x86_64 little endian host ? Do you forbid the use of
2006 Jul 06
0
Paging with multiple tables/models
I''m looking for a smooth way to implement paging over a combination of two tables. My application tracks which books and movies you have borrowed from me. For reasons that make sense elsewhere in the application, these are seperated out into two tables: book_borrowers and movie_borrowers and therefore 2 different activerec objects: BookBorrower and MovieBorrower This particular screen
2016 Dec 06
0
[PATCH v8 2/6] powerpc: pSeries/Kconfig: Add qspinlock build config
? 2016/12/6 08:58, Boqun Feng ??: > On Mon, Dec 05, 2016 at 10:19:22AM -0500, Pan Xinhui wrote: >> pSeries/powerNV will use qspinlock from now on. >> >> Signed-off-by: Pan Xinhui <xinhui.pan at linux.vnet.ibm.com> >> --- >> arch/powerpc/platforms/pseries/Kconfig | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git
2018 Apr 25
0
[PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU
From: Thierry Reding <treding at nvidia.com> The ARM_DMA_USE_IOMMU Kconfig option has side-effects that drivers can not opt into but have to explicitly opt out of. This can lead to subtle bugs that are difficult to track down and not immediately obvious to be related to this Kconfig option. To avoid this confusion, always enable the option to expose any lurking bugs once and allow any