* Re: [PATCH 7/7] powerpc/eeh: Add eeh_force_recover to debugfs
From: Michael Ellerman @ 2019-02-11 2:24 UTC (permalink / raw)
To: Oliver; +Cc: linuxppc-dev
In-Reply-To: <CAOSf1CFJqFaAwE34GFU4cwWkhGd-jwUPGANadAcNNwp3H2mvqg@mail.gmail.com>
Oliver <oohall@gmail.com> writes:
> On Fri, Feb 8, 2019 at 11:32 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Oliver O'Halloran <oohall@gmail.com> writes:
>>
>> > This patch adds a debugfs interface to force scheduling a recovery event.
>> > This can be used to recover a specific PE or schedule a "special" recovery
>> > even that checks for errors at the PHB level.
>> > To force a recovery of a normal PE, use:
>> >
>> > echo '<#pe>:<#phb>' > /sys/kernel/debug/powerpc/eeh_force_recover
>> >
>> > To force a scan broken PHBs:
>> >
>> > echo 'null' > /sys/kernel/debug/powerpc/eeh_force_recover
>>
>> Why 'null', that seems like an odd choice. Why not "all" or "scan" or
>> something?
>
> When an EEH event occurs the bit that is sent to the event handler is
> just a pointer the the struct eeh_pe. If the pointer is null it's then
> treated as a special event which indicates a PHB failure. I agree it's
> a bit dumb, but I don't really expect anyone except me or samb to use
> this interface so I went with what would make sense to someone
> familiar with the internals.
Yeah, nah. Let's use something that's at least vaguely self documenting
so people like me can have some clue what it's doing.
cheers
^ permalink raw reply
* RE: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for powerpc64
From: Peng Ma @ 2019-02-11 2:33 UTC (permalink / raw)
To: Vinod Koul
Cc: Wen He, Leo Li, Scott Wood, Zhang Wei, dmaengine@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190204072741.GK4296@vkoul-mobl>
Hi Vinod,
Got it.
Best Regards
Peng
>-----Original Message-----
>From: Vinod Koul <vkoul@kernel.org>
>Sent: 2019年2月4日 15:28
>To: Peng Ma <peng.ma@nxp.com>
>Cc: Scott Wood <oss@buserror.net>; Leo Li <leoyang.li@nxp.com>; Zhang Wei
><zw@zh-kernel.org>; linuxppc-dev@lists.ozlabs.org;
>dmaengine@vger.kernel.org; Wen He <wen.he_1@nxp.com>
>Subject: Re: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for
>powerpc64
>
>On 25-01-19, 05:54, Peng Ma wrote:
>> Hi Vinod,
>>
>> Sorry to replay late.
>> 1:This patch has already send to the patchwork.
>> Please see the patch link:
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
>>
>chwork.kernel.org%2Fpatch%2F10741521%2F&data=02%7C01%7Cpeng.
>ma%40n
>>
>xp.com%7C5d169e9bc5684a9d14c008d68a727589%7C686ea1d3bc2b4c6fa92
>cd99c5c
>>
>301635%7C0%7C0%7C636848621546833095&sdata=q1sTaC%2F4SqEtM
>yFymzyvXe
>> qBOhCnBjyMcjPz8A9QRI4%3D&reserved=0
>> 2:I have already compile the fsl patches on arm and powerpc after patched
>https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
>work.kernel.org%2Fpatch%2F10741521%2F&data=02%7C01%7Cpeng.ma
>%40nxp.com%7C5d169e9bc5684a9d14c008d68a727589%7C686ea1d3bc2b4c
>6fa92cd99c5c301635%7C0%7C0%7C636848621546833095&sdata=q1sTa
>C%2F4SqEtMyFymzyvXeqBOhCnBjyMcjPz8A9QRI4%3D&reserved=0
>> The compile will successful, please let me know the reported regression
>results, thanks very much.
>
>And I thought there were further comments on this patch. I have applied this,
>please watch for failures reported if any..
>--
>~Vinod
^ permalink raw reply
* Re: [PATCH 06/19] KVM: PPC: Book3S HV: add a GET_ESB_FD control to the XIVE native device
From: David Gibson @ 2019-02-11 2:38 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, linuxppc-dev
In-Reply-To: <8c915ed7-5aa5-1276-6598-d5dcd115dd56@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 4507 bytes --]
On Sat, Feb 09, 2019 at 10:41:38AM +0100, Cédric Le Goater wrote:
> On 2/8/19 10:53 PM, Paul Mackerras wrote:
> > On Fri, Feb 08, 2019 at 08:58:14AM +0100, Cédric Le Goater wrote:
> >> On 2/8/19 6:15 AM, David Gibson wrote:
> >>> On Thu, Feb 07, 2019 at 10:03:15AM +0100, Cédric Le Goater wrote:
> >>>> That's the plan I have in mind as suggested by Paul if I understood it well.
> >>>> The mechanics are more complex than the patch zapping the PTEs from the VMA
> >>>> but it's also safer.
> >>>
> >>> Well, yes, where "safer" means "has the possibility to be correct".
> >>
> >> Well, the only problem with the kernel approach is keeping a pointer on
> >> the VMA. If we could call find_vma(), it would be perfectly safe and much
> >> more simpler.
> >
> > You seem to be assuming that the kernel can easily work out a single
> > virtual address which will be the only place where a given set of
> > interrupt pages are mapped. But that is really not possible in the
> > general case, because userspace could have mapped the fd at many
> > different offsets in many different places.
> >
> > QEMU doesn't do that; in QEMU, the mmaps are sufficiently limited that
> > it can work out a single virtual address that needs to be changed.
> > The way that QEMU should tell the kernel what that address is and what
> > the mapping should be changed to, is via the existing munmap()/mmap()
> > interface.
>
> Yes. We agreed on that. QEMU should handle these mappings somewhere in
> VFIO. It's me grumbling, that's all.
>
> The discussion has moved to the mmap() interface of the KVM device. The
> current proposal adds controls on the device creating fds to mmap() the
> TIMA pages and the ESB pages. David is proposing to use directly the fd
> of the KVM device to mmap() these pages with a different offset for each
> set.
>
> I think that should work pretty well, for passthrough also. The fault
> handler should take care of populating the VMA(s) with the appropriate
> pages.
>
> We might support END notification one day, so we should have room for
> these pages. And nested might require IRQ space extensions at L1.
> something to keep in mind.
I had some more thoughts on this topic. I think there's been some
confusion because there are more ways of tackling this than I
previously realized:
1) All in kernel
The offset always maps directly to guest irq number and the kernel
somehow binds it either to an IPI or a host irq as necessary.
Cédric's original code attempts this, but the mechanism of keeping a
pointer to the VMA can't work.
But.. remapping the irqs should be sufficiently infrequent that it
might be ok to consider simply stepping through all the hosting
process's VMAs to do this.
2) Remapped in qemu (using memory regions)
I _think_ (in hindsight) was Cédric's been discussing as the
alternative in more recent posts.
Qemu maps the IPI pages at one place and the passthrough IRQ pages
somewhere else. The IPIs are mapped into the guest as one memory
region, then any passthrough IRQ pages are mapped over that using
overlapping memory regions.
I don't think this approach will work well, because it could require a
bunch of separate KVM memory slots, which are fairly scarce.
3) Remapped in qemu (using mmap())
This is the approach I (and I think Paul) have been suggested in
contrast to (1).
Qemu maps the IPI pages and maps those into the guest. When we need
to set up a passthrough IRQ, qemu mmap()s its pages directly over the
IPI pages, and it remains mapped into the guest with the same memory
region / memslot as the IPIs are already using. If the passthrough
device is removed we have to remap the IPI pages back into place.
4) Dedicated irq numbers
We never re-use regular guest irq numbers for passthrough irqs,
instead we put them somewhere else and keep those mapped to the
passthrough irq pages.
I was favouring this approach, but it does mean there will be a guest
visible difference between kernel_irqchip=on and off which isn't
great.
(1) is the most elegant _interface_, but as we've seen it's
problematic to implement. Looking at the for_all_vmas() approach
could be interesting, but otherwise option (3) might be the most
practical.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 03/16] powerpc/32: move LOAD_MSR_KERNEL() into head_32.h and use it
From: Christophe Leroy @ 2019-02-11 6:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Nicholas Piggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <749f719a0881531cad2071a7011dc5e894812d3d.camel@kernel.crashing.org>
Le 11/02/2019 à 01:21, Benjamin Herrenschmidt a écrit :
> On Fri, 2019-02-08 at 12:52 +0000, Christophe Leroy wrote:
>> /*
>> + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE.
>> + */
>> +.macro __LOAD_MSR_KERNEL r, x
>> +.if \x >= 0x8000
>> + lis \r, (\x)@h
>> + ori \r, \r, (\x)@l
>> +.else
>> + li \r, (\x)
>> +.endif
>> +.endm
>> +#define LOAD_MSR_KERNEL(r, x) __LOAD_MSR_KERNEL r, x
>> +
>
> You changed the limit from >= 0x10000 to >= 0x8000 without a
> corresponding explanation as to why...
Yes, the existing LOAD_MSR_KERNEL() was buggy because 'li' takes a
signed u16, ie between -0x8000 and 0x7999.
By chance it was working because until now nobody was trying to set
MSR_KERNEL | MSR_EE.
Christophe
^ permalink raw reply
* Re: [PATCH 06/19] KVM: PPC: Book3S HV: add a GET_ESB_FD control to the XIVE native device
From: Benjamin Herrenschmidt @ 2019-02-11 6:42 UTC (permalink / raw)
To: David Gibson, Cédric Le Goater; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20190211023842.GE7230@umbus.fritz.box>
On Mon, 2019-02-11 at 13:38 +1100, David Gibson wrote:
>
> 1) All in kernel
>
> The offset always maps directly to guest irq number and the kernel
> somehow binds it either to an IPI or a host irq as necessary.
> Cédric's original code attempts this, but the mechanism of keeping a
> pointer to the VMA can't work.
Why do you need a pointer to the VMA anyway ? unmap_mapping_range()
doesn't need a VMA for the unmap part, and faults/mmaps have the VMA.
> But.. remapping the irqs should be sufficiently infrequent that it
> might be ok to consider simply stepping through all the hosting
> process's VMAs to do this.
Which unmap_mapping_range() does for you as I explained previously. You
only need the address space. See how spufs does it (among others).
> 2) Remapped in qemu (using memory regions)
>
> I _think_ (in hindsight) was Cédric's been discussing as the
> alternative in more recent posts.
>
> Qemu maps the IPI pages at one place and the passthrough IRQ pages
> somewhere else. The IPIs are mapped into the guest as one memory
> region, then any passthrough IRQ pages are mapped over that using
> overlapping memory regions.
>
> I don't think this approach will work well, because it could require a
> bunch of separate KVM memory slots, which are fairly scarce.
>
> 3) Remapped in qemu (using mmap())
>
> This is the approach I (and I think Paul) have been suggested in
> contrast to (1).
>
> Qemu maps the IPI pages and maps those into the guest. When we need
> to set up a passthrough IRQ, qemu mmap()s its pages directly over the
> IPI pages, and it remains mapped into the guest with the same memory
> region / memslot as the IPIs are already using. If the passthrough
> device is removed we have to remap the IPI pages back into place.
>
> 4) Dedicated irq numbers
>
> We never re-use regular guest irq numbers for passthrough irqs,
> instead we put them somewhere else and keep those mapped to the
> passthrough irq pages.
>
> I was favouring this approach, but it does mean there will be a guest
> visible difference between kernel_irqchip=on and off which isn't
> great.
>
>
> (1) is the most elegant _interface_, but as we've seen it's
> problematic to implement. Looking at the for_all_vmas() approach
> could be interesting, but otherwise option (3) might be the most
> practical.
>
> --
^ permalink raw reply
* Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
From: Ingo Molnar @ 2019-02-11 7:11 UTC (permalink / raw)
To: Waiman Long
Cc: linux-ia64, linux-sh, Peter Zijlstra, Will Deacon, H. Peter Anvin,
sparclinux, linux-arch, Davidlohr Bueso, linux-hexagon, x86,
Ingo Molnar, linux-xtensa, Arnd Bergmann, linuxppc-dev,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Linus Torvalds, linux-kernel, linux-alpha, Andrew Morton,
Tim Chen
In-Reply-To: <a610aeb2-b1cb-0d57-8078-97d1051481f9@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> On 02/10/2019 09:00 PM, Waiman Long wrote:
> > As the generic rwsem-xadd code is using the appropriate acquire and
> > release versions of the atomic operations, the arch specific rwsem.h
> > files will not be that much faster than the generic code as long as the
> > atomic functions are properly implemented. So we can remove those arch
> > specific rwsem.h and stop building asm/rwsem.h to reduce maintenance
> > effort.
> >
> > Currently, only x86, alpha and ia64 have implemented architecture
> > specific fast paths. I don't have access to alpha and ia64 systems for
> > testing, but they are legacy systems that are not likely to be updated
> > to the latest kernel anyway.
> >
> > By using a rwsem microbenchmark, the total locking rates on a 4-socket
> > 56-core 112-thread x86-64 system before and after the patch were as
> > follows (mixed means equal # of read and write locks):
> >
> > Before Patch After Patch
> > # of Threads wlock rlock mixed wlock rlock mixed
> > ------------ ----- ----- ----- ----- ----- -----
> > 1 27,373 29,409 28,170 28,773 30,164 29,276
> > 2 7,697 14,922 1,703 7,435 15,167 1,729
> > 4 6,987 14,285 1,490 7,181 14,438 1,330
> > 8 6,650 13,652 761 6,918 13,796 718
> > 16 6,434 15,729 713 6,554 16,030 625
> > 32 5,590 15,312 552 6,124 15,344 471
> > 64 5,980 15,478 61 5,668 15,509 58
> >
> > There were some run-to-run variations for the multi-thread tests. For
> > x86-64, using the generic C code fast path seems to be a liitle bit
> > faster than the assembly version especially for read-lock and when lock
> > contention is low. Looking at the assembly version of the fast paths,
> > there are assembly to/from C code wrappers that save and restore all
> > the callee-clobbered registers (7 registers on x86-64). The assembly
> > generated from the generic C code doesn't need to do that. That may
> > explain the slight performance gain here.
> >
> > The generic asm rwsem.h can also be merged into kernel/locking/rwsem.h
> > as no other code other than those under kernel/locking needs to access
> > the internal rwsem macros and functions.
> >
> > Signed-off-by: Waiman Long <longman@redhat.com>
>
> I have decided to break the rwsem patchset that I sent out on last
> Thursday into 3 parts. This patch is part 0 as it touches a number of
> arch specific files and so have the widest distribution. I would like to
> get it merged first. Part 1 will be patches 1-10 (except 4) of my
> original rwsem patchset. This part moves things around, adds more
> debugging capability and lays the ground work for the next part. Part 2
> will contains the remaining patches which are the real beef of the whole
> patchset.
Sounds good to me - I've merged this patch, will push it out after
testing.
Thanks,
Ingo
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christian Zigotzky @ 2019-02-11 7:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev
In-Reply-To: <0042290A-2939-4EBA-A638-D404FA2055ED@xenosoft.de>
Hi Christoph,
Mario successfully tested a kernel from your Git [1] on his T2080rdb today.
Link to the log:
https://gitlab.com/oshw-powerpc-notebook/T2080customizations/blob/master/kernel/dma_fix/kernel_dma_fix_log.txt
He wrote:
Please, note that all of the above kernel runs just fine with the T2080rdb, however did not had the time to test extensively (tested: login into MATE graphical desktop environment, used ArctiFox for opening couple of websites, then played Neverball).
——
Cheers,
Christian
[1] http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christoph Hellwig @ 2019-02-11 7:38 UTC (permalink / raw)
To: Christian Zigotzky
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <4e7137db-e600-0d20-6fb2-6d0f9739aca3@xenosoft.de>
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
> I tested the whole series today. The kernels boot and the P.A. Semi
> Ethernet works! :-) Thanks a lot!
>
> I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
> kernel crashes.
This looks like a patch I fixed in mainline a while ago, but which
the powerpc tree didn't have yet.
I've cherry picked this commit
("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
and added it to the powerpc-dma.6 tree, please retry with that one.
^ permalink raw reply
* Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
From: Ingo Molnar @ 2019-02-11 7:38 UTC (permalink / raw)
To: Waiman Long
Cc: linux-ia64, linux-sh, Peter Zijlstra, Will Deacon, H. Peter Anvin,
sparclinux, linux-arch, Davidlohr Bueso, linux-hexagon, x86,
Ingo Molnar, linux-xtensa, Arnd Bergmann, linuxppc-dev,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Linus Torvalds, linux-kernel, linux-alpha, Andrew Morton,
Tim Chen
In-Reply-To: <45b7bbb8-c953-9951-ae6f-e2c3202e5cf2@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> On 02/07/2019 02:51 PM, Davidlohr Bueso wrote:
> > On Thu, 07 Feb 2019, Waiman Long wrote:
> >> 30 files changed, 1197 insertions(+), 1594 deletions(-)
> >
> > Performance numbers on numerous workloads, pretty please.
> >
> > I'll go and throw this at my mmap_sem intensive workloads
> > I've collected.
> >
> > Thanks,
> > Davidlohr
>
> Thanks for getting some of the performance numbers. This is the initial
> draft after more than 1 years of hibernation. I will also get other
> performance numbers in subsequent revision of the patch.
If you could sort all the invariant preparatory patches to the head of
the series I can merge them to reduce overall complexity and simplify
performance testing and review of the rest.
Thanks,
Ingo
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christoph Hellwig @ 2019-02-11 7:41 UTC (permalink / raw)
To: Darren Stevens
Cc: linuxppc-dev, Christoph Hellwig, Julian Margetson,
Christian Zigotzky
In-Reply-To: <4d5302a8b75.61849dba@auth.smtp.1and1.co.uk>
On Sat, Feb 09, 2019 at 09:10:58PM +0000, Darren Stevens wrote:
> Hello Christoph
>
> On 08/02/2019, Christoph Hellwig wrote:
> > On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote:
> >> Hi Christoph,
> >>
> >> Your new patch fixes the problems with the P.A. Semi Ethernet! :-)
> >
> > Thanks a lot once again for testing!
> >
> > Now can you test with this patch and the whole series?
> >
> > I've updated the powerpc-dma.6 branch to include this fix.
>
> Update: I found the following in my dmesg, think it points to an of-by-one error in the pfn selection:
I don't think this is an off by one, it is just that the FSL e500-ish
SOCs have a very odd memory map.
^ permalink raw reply
* [PATCH kernel] powerpc/powernv/ioda: Store correct amount of memory used for table
From: Alexey Kardashevskiy @ 2019-02-11 7:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson
We store 2 multilevel tables in iommu_table - one for the hardware and
one with the corresponding userspace addresses. Before allocating
the tables, the iommu_table_group_ops::get_table_size() hook returns
the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts
the locked_vm counter correctly. When the table is actually allocated,
the amount of allocated memory is stored in iommu_table::it_allocated_size
and used to adjust the locked_vm counter when we release the memory used
by the table; .get_table_size() and .create_table() calculate it
independently but the result is expected to be the same.
Unfortunately the allocator does not add the userspace table size to
::it_allocated_size so when we destroy the table because of VFIO PCI
unplug (i.e. VFIO container is gone but the userspace keeps running),
we decrement locked_vm by just a half of size of memory we are releasing.
As the result, we leak locked_vm and may not be able to allocate more
IOMMU tables after few iterations of hotplug/unplug.
This adjusts it_allocated_size if the userspace addresses table was
requested (total_allocated_uas is initialized by zero).
Fixes: 090bad39b "powerpc/powernv: Add indirect levels to it_userspace"
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index 697449a..58146e1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -313,7 +313,7 @@ long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 bus_offset,
page_shift);
tbl->it_level_size = 1ULL << (level_shift - 3);
tbl->it_indirect_levels = levels - 1;
- tbl->it_allocated_size = total_allocated;
+ tbl->it_allocated_size = total_allocated + total_allocated_uas;
tbl->it_userspace = uas;
tbl->it_nid = nid;
--
2.17.1
^ permalink raw reply related
* [PATCH kernel] vfio/spapr_tce: Skip unsetting already unset table
From: Alexey Kardashevskiy @ 2019-02-11 7:49 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Alex Williamson, kvm, kvm-ppc, David Gibson
VFIO TCE IOMMU v2 owns IOMMU tables so when detach a IOMMU group from
a container, we need to unset those from a group so we call unset_window()
so do we unconditionally. We also unset tables when removing a DMA window
via the VFIO_IOMMU_SPAPR_TCE_REMOVE ioctl.
The window removal checks if the table actually exists (hidden inside
tce_iommu_find_table()) but the group detaching does not so the user
may see duplicating messages:
pci 0009:03 : [PE# fd] Removing DMA window #0
pci 0009:03 : [PE# fd] Removing DMA window #1
pci 0009:03 : [PE# fd] Removing DMA window #0
pci 0009:03 : [PE# fd] Removing DMA window #1
At the moment this is not a problem as the second invocation
of unset_window() writes zeroes to the HW registers again and exits early
as there is no table.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
When doing VFIO PCI hot unplug, first we remove the DMA window and
set container->tables[num] - this is a first couple of messages.
Then we detach the group and then we see another couple of the same
messages which confused myself.
---
drivers/vfio/vfio_iommu_spapr_tce.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index c424913..8dbb270 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1235,7 +1235,8 @@ static void tce_iommu_release_ownership_ddw(struct tce_container *container,
}
for (i = 0; i < IOMMU_TABLE_GROUP_MAX_TABLES; ++i)
- table_group->ops->unset_window(table_group, i);
+ if (container->tables[i])
+ table_group->ops->unset_window(table_group, i);
table_group->ops->release_ownership(table_group);
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 1/7] dump_stack: Support adding to the dump stack arch description
From: Sergey Senozhatsky @ 2019-02-11 7:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-arch, pmladek, sergey.senozhatsky, linux-kernel,
linuxppc-dev, tj, akpm, dyoung
In-Reply-To: <20190208185515.r6vkrezbd3odhpxt@home.goodmis.org>
On (02/08/19 13:55), Steven Rostedt wrote:
[..]
> > + if (len) {
> > + /*
> > + * Order the stores above in vsnprintf() vs the store of the
> > + * space below which joins the two strings. Note this doesn't
> > + * make the code truly race free because there is no barrier on
> > + * the read side. ie. Another CPU might load the uninitialised
> > + * tail of the buffer first and then the space below (rather
> > + * than the NULL that was there previously), and so print the
> > + * uninitialised tail. But the whole string lives in BSS so in
> > + * practice it should just see NULLs.
> > + */
> > + smp_wmb();
>
> This shows me that this can be called at a time when more than one CPU is
> active. What happens if we have two CPUs calling dump_stack_add_arch_desc() at
> the same time? Can't that corrupt the dump_stack_arch_desc_str?
Can overwrite part of it, I guess (but it seems that Michael
is OK with this). The string is still NULL terminated.
The worst case scenario I can think of is not the one when
two CPUs call dump_stack_add_arch_desc(), but when CPUA calls
dump_stack_add_arch_desc() to append some data and at the
same time CPUB calls dump_stack_set_arch_desc() and simply
overwrites dump_stack_arch_desc_str. Not sure if this is
critical (or possible).
-ss
^ permalink raw reply
* Re: [PATCH v1 03/16] powerpc/32: move LOAD_MSR_KERNEL() into head_32.h and use it
From: Benjamin Herrenschmidt @ 2019-02-11 8:06 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Michael Ellerman,
Nicholas Piggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <b074648b-8896-5591-16fe-3ecaf5c7553a@c-s.fr>
On Mon, 2019-02-11 at 07:26 +0100, Christophe Leroy wrote:
>
> Le 11/02/2019 à 01:21, Benjamin Herrenschmidt a écrit :
> > On Fri, 2019-02-08 at 12:52 +0000, Christophe Leroy wrote:
> > > /*
> > > + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE.
> > > + */
> > > +.macro __LOAD_MSR_KERNEL r, x
> > > +.if \x >= 0x8000
> > > + lis \r, (\x)@h
> > > + ori \r, \r, (\x)@l
> > > +.else
> > > + li \r, (\x)
> > > +.endif
> > > +.endm
> > > +#define LOAD_MSR_KERNEL(r, x) __LOAD_MSR_KERNEL r, x
> > > +
> >
> > You changed the limit from >= 0x10000 to >= 0x8000 without a
> > corresponding explanation as to why...
>
> Yes, the existing LOAD_MSR_KERNEL() was buggy because 'li' takes a
> signed u16, ie between -0x8000 and 0x7999.
Ah yes, I was only looking at the "large" case which is fine...
> By chance it was working because until now nobody was trying to set
> MSR_KERNEL | MSR_EE.
>
> Christophe
^ permalink raw reply
* Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
From: Peter Zijlstra @ 2019-02-11 9:36 UTC (permalink / raw)
To: Waiman Long
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, linux-sh, linux-hexagon, x86, Will Deacon,
linux-kernel, Linus Torvalds, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-alpha, sparclinux, Thomas Gleixner,
linuxppc-dev, Andrew Morton, linux-arm-kernel
In-Reply-To: <1549850450-10171-1-git-send-email-longman@redhat.com>
On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
> index bad2bca..067e265 100644
> --- a/kernel/locking/rwsem.h
> +++ b/kernel/locking/rwsem.h
> @@ -32,6 +32,26 @@
> # define DEBUG_RWSEMS_WARN_ON(c)
> #endif
>
> +/*
> + * R/W semaphores originally for PPC using the stuff in lib/rwsem.c.
> + * Adapted largely from include/asm-i386/rwsem.h
> + * by Paul Mackerras <paulus@samba.org>.
> + */
> +
> +/*
> + * the semaphore definition
> + */
> +#ifdef CONFIG_64BIT
> +# define RWSEM_ACTIVE_MASK 0xffffffffL
> +#else
> +# define RWSEM_ACTIVE_MASK 0x0000ffffL
> +#endif
> +
> +#define RWSEM_ACTIVE_BIAS 0x00000001L
> +#define RWSEM_WAITING_BIAS (-RWSEM_ACTIVE_MASK-1)
> +#define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
> +#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
> +
> #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
> /*
> * All writes to owner are protected by WRITE_ONCE() to make sure that
> @@ -132,3 +152,113 @@ static inline void rwsem_clear_reader_owned(struct rw_semaphore *sem)
> {
> }
> #endif
> +
> +#ifdef CONFIG_RWSEM_XCHGADD_ALGORITHM
> +/*
> + * lock for reading
> + */
> +static inline void __down_read(struct rw_semaphore *sem)
> +{
> + if (unlikely(atomic_long_inc_return_acquire(&sem->count) <= 0))
> + rwsem_down_read_failed(sem);
> +}
> +
> +static inline int __down_read_killable(struct rw_semaphore *sem)
> +{
> + if (unlikely(atomic_long_inc_return_acquire(&sem->count) <= 0)) {
> + if (IS_ERR(rwsem_down_read_failed_killable(sem)))
> + return -EINTR;
> + }
> +
> + return 0;
> +}
> +
> +static inline int __down_read_trylock(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + while ((tmp = atomic_long_read(&sem->count)) >= 0) {
> + if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
> + tmp + RWSEM_ACTIVE_READ_BIAS)) {
> + return 1;
That really wants to be:
if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
tmp + RWSEM_ACTIVE_READ_BIAS))
> + }
> + }
> + return 0;
> +}
> +
> +/*
> + * lock for writing
> + */
> +static inline void __down_write(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + tmp = atomic_long_add_return_acquire(RWSEM_ACTIVE_WRITE_BIAS,
> + &sem->count);
> + if (unlikely(tmp != RWSEM_ACTIVE_WRITE_BIAS))
> + rwsem_down_write_failed(sem);
> +}
> +
> +static inline int __down_write_killable(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + tmp = atomic_long_add_return_acquire(RWSEM_ACTIVE_WRITE_BIAS,
> + &sem->count);
> + if (unlikely(tmp != RWSEM_ACTIVE_WRITE_BIAS))
> + if (IS_ERR(rwsem_down_write_failed_killable(sem)))
> + return -EINTR;
> + return 0;
> +}
> +
> +static inline int __down_write_trylock(struct rw_semaphore *sem)
> +{
> + long tmp;
tmp = RWSEM_UNLOCKED_VALUE;
> +
> + tmp = atomic_long_cmpxchg_acquire(&sem->count, RWSEM_UNLOCKED_VALUE,
> + RWSEM_ACTIVE_WRITE_BIAS);
> + return tmp == RWSEM_UNLOCKED_VALUE;
return atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
RWSEM_ACTIVE_WRITE_BIAS);
> +}
> +
> +/*
> + * unlock after reading
> + */
> +static inline void __up_read(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + tmp = atomic_long_dec_return_release(&sem->count);
> + if (unlikely(tmp < -1 && (tmp & RWSEM_ACTIVE_MASK) == 0))
> + rwsem_wake(sem);
> +}
> +
> +/*
> + * unlock after writing
> + */
> +static inline void __up_write(struct rw_semaphore *sem)
> +{
> + if (unlikely(atomic_long_sub_return_release(RWSEM_ACTIVE_WRITE_BIAS,
> + &sem->count) < 0))
> + rwsem_wake(sem);
> +}
> +
> +/*
> + * downgrade write lock to read lock
> + */
> +static inline void __downgrade_write(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + /*
> + * When downgrading from exclusive to shared ownership,
> + * anything inside the write-locked region cannot leak
> + * into the read side. In contrast, anything in the
> + * read-locked region is ok to be re-ordered into the
> + * write side. As such, rely on RELEASE semantics.
> + */
> + tmp = atomic_long_add_return_release(-RWSEM_WAITING_BIAS, &sem->count);
> + if (tmp < 0)
> + rwsem_downgrade_wake(sem);
> +}
> +
> +#endif /* CONFIG_RWSEM_XCHGADD_ALGORITHM */
^ permalink raw reply
* Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
From: Peter Zijlstra @ 2019-02-11 9:40 UTC (permalink / raw)
To: Waiman Long
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, linux-sh, linux-hexagon, x86, Will Deacon,
linux-kernel, Linus Torvalds, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-alpha, sparclinux, Thomas Gleixner,
linuxppc-dev, Andrew Morton, linux-arm-kernel
In-Reply-To: <20190211093601.GT32511@hirez.programming.kicks-ass.net>
On Mon, Feb 11, 2019 at 10:36:01AM +0100, Peter Zijlstra wrote:
> On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > +{
> > + long tmp;
> > +
> > + while ((tmp = atomic_long_read(&sem->count)) >= 0) {
> > + if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
> > + tmp + RWSEM_ACTIVE_READ_BIAS)) {
> > + return 1;
>
> That really wants to be:
>
> if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
> tmp + RWSEM_ACTIVE_READ_BIAS))
>
> > + }
> > + }
> > + return 0;
> > +}
Also, the is the one case where LL/SC can actually do 'better'. Do you
have benchmarks for say PowerPC or ARM64 ?
^ permalink raw reply
* Re: [RFC PATCH 5/5] powerpc: sstep: Add selftests for addc[.] instruction
From: Sandipan Das @ 2019-02-11 10:14 UTC (permalink / raw)
To: Daniel Axtens; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <878syn3zqz.fsf@dja-thinkpad.axtens.net>
On 11/02/19 6:30 AM, Daniel Axtens wrote:
> Hi Sandipan,
>
>> + {
>> + .descr = "RA = LONG_MIN | INT_MIN, RB = LONG_MIN | INT_MIN",
>> + .instr = PPC_INST_ADDC | ___PPC_RT(20) | ___PPC_RA(21) | ___PPC_RB(22),
>> + .regs =
>> + {
>> + .gpr[21] = LONG_MIN | (uint) INT_MIN,
>> + .gpr[22] = LONG_MIN | (uint) INT_MIN,
>> + }
>> + }
> I don't know what this bit pattern is supposed to represent - is it
> supposed to be the smallest 32bit integer and the smallest 64bit
> integer 8000000080000000 - so you test 32 and 64 bit overflow at the
> same time?
>
Yes, exactly.
>
> For the series:
> Tested-by: Daniel Axtens <dja@axtens.net> # Power8 LE
>
> I notice the output is quite verbose, and doesn't include a line when it
> starts:
>
> [ 0.826181] Running code patching self-tests ...
> [ 0.826607] Running feature fixup self-tests ...
> [ 0.826615] nop : R0 = LONG_MAX [PASS]
> [ 0.826617] add : RA = LONG_MIN, RB = LONG_MIN [PASS]
>
> Maybe it would be good to include a line saying "Running single-step
> emulation self-tests" and perhaps by default on printing when there is a
> failure.
>
That makes sense. Will include it in the next revision.
> Finally, I think you might be able to squash patches 1 and 2 and patches
> 4 and 5, but that's just my personal preference.
>
> Regards,
> Daniel
>
^ permalink raw reply
* Re: [RFC PATCH 3/5] powerpc: sstep: Add instruction emulation selftests
From: Sandipan Das @ 2019-02-11 10:15 UTC (permalink / raw)
To: Daniel Axtens; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <87bm3j40cv.fsf@dja-thinkpad.axtens.net>
On 11/02/19 6:17 AM, Daniel Axtens wrote:
> Hi Sandipan,
>
> I'm not really confident to review the asm, but I did have a couple of
> questions about the C:
>
>> +#define MAX_INSNS 32
> This doesn't seem to be used...
>
True. Thanks for pointing this out.
>> +int execute_instr(struct pt_regs *regs, unsigned int instr)
>> +{
>> + extern unsigned int exec_instr_execute[];
>> + extern int exec_instr(struct pt_regs *regs);
>
> These externs sit inside the function scope. This feels less than ideal
> to me - is there a reason not to have these at global scope?
>
Currently, execute_instr() is the only consumer. So, I thought I'd keep
them local for now.
>> +
>> + if (!regs || !instr)
>> + return -EINVAL;
>> +
>> + /* Patch the NOP with the actual instruction */
>> + patch_instruction(&exec_instr_execute[0], instr);
>> + if (exec_instr(regs)) {
>> + pr_info("execution failed, opcode = 0x%08x\n", instr);
>> + return -EFAULT;
>> + }
>> +
>> + return 0;
>> +}
>
>> +late_initcall(run_sstep_tests);
> A design question: is there a reason to run these as an initcall rather
> than as a module that could either be built in or loaded separately? I'm
> not saying you have to do this, but I was wondering if you had
> considered it?
>
I did. As of now, there are some existing tests in test_emulate_step.c
which use the same approach. So, I thought I'd stick with that approach
to start off. This is anyway controlled by a Kconfig option.
> Lastly, snowpatch reports some checkpatch issues for this and your
> remaining patches: https://patchwork.ozlabs.org/patch/1035683/ (You are
> allowed to violate checkpatch rules with justification, FWIW)
>
Will look into them.
> Regards,
> Daniel
>> --
>> 2.19.2
>
^ permalink raw reply
* Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
From: Ingo Molnar @ 2019-02-11 10:39 UTC (permalink / raw)
To: Waiman Long
Cc: linux-ia64, linux-sh, Peter Zijlstra, Will Deacon, H. Peter Anvin,
sparclinux, linux-arch, Davidlohr Bueso, linux-hexagon, x86,
Ingo Molnar, linux-xtensa, Arnd Bergmann, linuxppc-dev,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Linus Torvalds, linux-kernel, linux-alpha, Andrew Morton,
Tim Chen
In-Reply-To: <20190211071159.GA55579@gmail.com>
* Ingo Molnar <mingo@kernel.org> wrote:
> Sounds good to me - I've merged this patch, will push it out after
> testing.
Based on Peter's feedback I'm delaying this - performance testing on at
least one key ll/sc arch would be nice indeed.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
From: Will Deacon @ 2019-02-11 10:52 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-ia64, linux-sh, Peter Zijlstra, H. Peter Anvin, sparclinux,
linux-arch, Davidlohr Bueso, linux-hexagon, x86, Ingo Molnar,
Waiman Long, linux-xtensa, Arnd Bergmann, linuxppc-dev,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Linus Torvalds, linux-kernel, linux-alpha, Andrew Morton,
Tim Chen
In-Reply-To: <20190211103927.GA118071@gmail.com>
On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
> > Sounds good to me - I've merged this patch, will push it out after
> > testing.
>
> Based on Peter's feedback I'm delaying this - performance testing on at
> least one key ll/sc arch would be nice indeed.
Once Waiman has posted a new version, I can take it for a spin on some
arm64 boxen if he shares his workload.
Will
^ permalink raw reply
* Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
From: Ingo Molnar @ 2019-02-11 10:55 UTC (permalink / raw)
To: Will Deacon
Cc: linux-ia64, linux-sh, Peter Zijlstra, H. Peter Anvin, sparclinux,
linux-arch, Davidlohr Bueso, linux-hexagon, x86, Ingo Molnar,
Waiman Long, linux-xtensa, Arnd Bergmann, linuxppc-dev,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel,
Linus Torvalds, linux-kernel, linux-alpha, Andrew Morton,
Tim Chen
In-Reply-To: <20190211105214.GA30880@fuggles.cambridge.arm.com>
* Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
> >
> > * Ingo Molnar <mingo@kernel.org> wrote:
> >
> > > Sounds good to me - I've merged this patch, will push it out after
> > > testing.
> >
> > Based on Peter's feedback I'm delaying this - performance testing on at
> > least one key ll/sc arch would be nice indeed.
>
> Once Waiman has posted a new version, I can take it for a spin on some
> arm64 boxen if he shares his workload.
Cool, thanks!
Ingo
^ permalink raw reply
* Re: [PATCH v3 1/2] drivers/mtd: Use mtd->name when registering nvmem device
From: Aneesh Kumar K.V @ 2019-02-11 10:56 UTC (permalink / raw)
To: Boris Brezillon; +Cc: linuxppc-dev, Alban Bedel, linux-mtd@lists.infradead.org
In-Reply-To: <20190210135552.65f532bb@collabora.com>
On 2/10/19 6:25 PM, Boris Brezillon wrote:
> Hello Aneesh,
>
> On Fri, 8 Feb 2019 20:44:18 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
>
>> With this patch, we use the mtd->name instead of concatenating the name with '0'
>>
>> Fixes: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API")
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>
> You forgot to Cc the MTD ML and maintainers. Can you please send a new
> version?
>
linux-mtd list is on CC: Is that not sufficient?
-aneesh
^ permalink raw reply
* Re: [PATCH] locking/rwsem: Remove arch specific rwsem files
From: Peter Zijlstra @ 2019-02-11 10:57 UTC (permalink / raw)
To: Waiman Long
Cc: linux-arch, linux-xtensa, Davidlohr Bueso, linux-ia64, Tim Chen,
Arnd Bergmann, linux-sh, linux-hexagon, x86, Will Deacon,
linux-kernel, Linus Torvalds, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, linux-alpha, sparclinux, Thomas Gleixner,
linuxppc-dev, Andrew Morton, linux-arm-kernel
In-Reply-To: <20190211094044.GG32534@hirez.programming.kicks-ass.net>
On Mon, Feb 11, 2019 at 10:40:44AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 10:36:01AM +0100, Peter Zijlstra wrote:
> > On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> > > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > > +{
> > > + long tmp;
> > > +
> > > + while ((tmp = atomic_long_read(&sem->count)) >= 0) {
> > > + if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
> > > + tmp + RWSEM_ACTIVE_READ_BIAS)) {
> > > + return 1;
> >
> > That really wants to be:
> >
> > if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
> > tmp + RWSEM_ACTIVE_READ_BIAS))
> >
> > > + }
> > > + }
> > > + return 0;
> > > +}
>
> Also, the is the one case where LL/SC can actually do 'better'. Do you
> have benchmarks for say PowerPC or ARM64 ?
Ah, I see they already used asm-generic/rwsem.h which has similar code
to the above.
^ permalink raw reply
* Re: [PATCH v3 1/2] drivers/mtd: Use mtd->name when registering nvmem device
From: Boris Brezillon @ 2019-02-11 11:16 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, Alban Bedel, linux-mtd@lists.infradead.org
In-Reply-To: <2f3cae2b-32d2-0651-29ef-2359221de4ef@linux.ibm.com>
On Mon, 11 Feb 2019 16:26:38 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> On 2/10/19 6:25 PM, Boris Brezillon wrote:
> > Hello Aneesh,
> >
> > On Fri, 8 Feb 2019 20:44:18 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> >
> >> With this patch, we use the mtd->name instead of concatenating the name with '0'
> >>
> >> Fixes: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API")
> >> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> >
> > You forgot to Cc the MTD ML and maintainers. Can you please send a new
> > version?
> >
>
> linux-mtd list is on CC: Is that not sufficient?
Not in your original email, I added it in my reply.
^ permalink raw reply
* [PATCH] powerpc/configs: Enable CONFIG_USB_XHCI_HCD by default
From: Thomas Huth @ 2019-02-11 11:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Laurent Vivier, Paul Mackerras, David Gibson
Recent versions of QEMU provide a XHCI device by default these
days instead of an old-fashioned OHCI device:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
So to get the keyboard working in the graphical console there again,
we should now include XHCI support in the kernel by default, too.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
arch/powerpc/configs/pseries_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index ea79c51..62e12f6 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -217,6 +217,7 @@ CONFIG_USB_MON=m
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_HCD_PPC_OF is not set
CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_XHCI_HCD=y
CONFIG_USB_STORAGE=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox