Re: [PATCH 01/20] kernel/dma/direct: take DMA offset into account in dma_direct_supported

ween 40 and 64 bits, and some of these will not work "out of the box" if the offseted top of memory is beyond the mask limit. Or am I missing something ? Cheers, Ben. > Signed-off-by: Christoph Hellwig Reviewed-by: Benjamin Herrenschmidt > --- > kernel/dma/direct.c | 6 +++--- > 1 file

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Wed, 2018-08-08 at 23:31 +0300, Michael S. Tsirkin wrote: > On Wed, Aug 08, 2018 at 11:18:13PM +1000, Benjamin Herrenschmidt wrote: > > Sure, but all of this is just the configuration of the iommu. But I > > think we agree here, and your point remains valid, indeed my pr

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Wed, 2018-08-08 at 05:30 -0700, Christoph Hellwig wrote: > On Wed, Aug 08, 2018 at 08:07:49PM +1000, Benjamin Herrenschmidt wrote: > > Qemu virtio bypasses that iommu when the VIRTIO_F_IOMMU_PLATFORM flag > > is not set (default) but there's nothing in the device-tree to tel

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, 2018-08-07 at 23:31 -0700, Christoph Hellwig wrote: > > You don't need to set them the time you go secure. You just need to > set the flag from the beginning on any VM you might want to go secure. > Or for simplicity just any VM - if the DT/ACPI tables exposed by > qemu are good enough

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, 2018-08-07 at 06:55 -0700, Christoph Hellwig wrote: > On Tue, Aug 07, 2018 at 04:42:44PM +1000, Benjamin Herrenschmidt wrote: > > Note that I can make it so that the same DMA ops (basically standard > > swiotlb ops without arch hacks) work for both "direct virtio&

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Mon, 2018-08-06 at 23:27 -0700, Christoph Hellwig wrote: > On Tue, Aug 07, 2018 at 08:13:56AM +1000, Benjamin Herrenschmidt wrote: > > It would be indeed ideal if all we had to do was setup some kind of > > bus_dma_mask on all PCI devices and have virtio automagically insert &

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Mon, 2018-08-06 at 23:21 -0700, Christoph Hellwig wrote: > On Tue, Aug 07, 2018 at 05:52:12AM +1000, Benjamin Herrenschmidt wrote: > > > It is your job to write a coherent interface specification that does > > > not depend on the used components. The hypervisor might

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, 2018-08-07 at 02:45 +0300, Michael S. Tsirkin wrote: > > OK well, assuming Christoph can solve the direct case in a way that > > also work for the virtio !iommu case, we still want some bit of logic > > somewhere that will "switch" to swiotlb based ops if the DMA mask is > > limited. > >

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Mon, 2018-08-06 at 23:35 +0300, Michael S. Tsirkin wrote: > On Tue, Aug 07, 2018 at 05:56:59AM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2018-08-06 at 16:46 +0300, Michael S. Tsirkin wrote: > > > > > > > Right, we'll need some quirk to disable balloons

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, 2018-08-07 at 08:13 +1000, Benjamin Herrenschmidt wrote: > > OK well, assuming Christoph can solve the direct case in a way that > also work for the virtio !iommu case, we still want some bit of logic > somewhere that will "switch" to swiotlb based ops if the

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, 2018-08-07 at 00:46 +0300, Michael S. Tsirkin wrote: > On Tue, Aug 07, 2018 at 07:26:35AM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2018-08-06 at 23:35 +0300, Michael S. Tsirkin wrote: > > > > As I said replying to Christoph, we are "leaking" into

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Mon, 2018-08-06 at 23:35 +0300, Michael S. Tsirkin wrote: > > As I said replying to Christoph, we are "leaking" into the interface > > something here that is really what's the VM is doing to itself, which > > is to stash its memory away in an inaccessible place. > > > > Cheers, > > Ben. > > I

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Mon, 2018-08-06 at 16:46 +0300, Michael S. Tsirkin wrote: > > > Right, we'll need some quirk to disable balloons in the guest I > > suppose. > > > > Passing something from libvirt is cumbersome because the end user may > > not even need to know about secure VMs. There are use cases where the

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Mon, 2018-08-06 at 02:42 -0700, Christoph Hellwig wrote: > On Mon, Aug 06, 2018 at 07:16:47AM +1000, Benjamin Herrenschmidt wrote: > > Who would set this bit ? qemu ? Under what circumstances ? > > I don't really care who sets what. The implementation might not even

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Mon, 2018-08-06 at 07:16 +1000, Benjamin Herrenschmidt wrote: > I'm trying to understand because the limitation is not a device side > limitation, it's not a qemu limitation, it's actually more of a VM > limitation. It has most of its memory pages made inaccessible for > secu

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Sun, 2018-08-05 at 00:29 -0700, Christoph Hellwig wrote: > On Sun, Aug 05, 2018 at 11:10:15AM +1000, Benjamin Herrenschmidt wrote: > > - One you have rejected, which is to have a way for "no-iommu" virtio > > (which still doesn't use an iommu on the q

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Sun, 2018-08-05 at 03:22 +0300, Michael S. Tsirkin wrote: > I see the allure of this, but I think down the road you will > discover passing a flag in libvirt XML saying > "please use a secure mode" or whatever is a good idea. > > Even thought it is probably not required to address this >

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Sun, 2018-08-05 at 03:09 +0300, Michael S. Tsirkin wrote: > It seems that the fact that within guest it's implemented using a bounce > buffer and that it's easiest to do by switching virtio to use the DMA API > isn't something virtio spec concerns itself with. Right, this is my reasoning as

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Sat, 2018-08-04 at 01:21 -0700, Christoph Hellwig wrote: > No matter if you like it or not (I don't!) virtio is defined to bypass > dma translations, it is very clearly stated in the spec. It has some > ill-defined bits to bypass it, so if you want the dma mapping API > to be used you'll have

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Sat, 2018-08-04 at 01:15 -0700, Christoph Hellwig wrote: > b) a way to document in a virtio-related spec how the bus handles > dma for Ben's totally fucked up hypervisor. Without that there > is not way we'll get interoperable implementations. Christoph, this isn't a totally

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Fri, 2018-08-03 at 22:08 +0300, Michael S. Tsirkin wrote: > > > > Please go through these patches and review whether this approach broadly > > > > makes sense. I will appreciate suggestions, inputs, comments regarding > > > > the patches or the approach in general. Thank you. > > > > > > Jason

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Fri, 2018-08-03 at 22:07 +0300, Michael S. Tsirkin wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-pro

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Fri, 2018-08-03 at 22:07 +0300, Michael S. Tsirkin wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-pro

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Fri, 2018-08-03 at 22:07 +0300, Michael S. Tsirkin wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-pro

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Fri, 2018-08-03 at 22:07 +0300, Michael S. Tsirkin wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-pro

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Fri, 2018-08-03 at 09:02 -0700, Christoph Hellwig wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-provided >

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > 2- Make virtio use the DMA API with our custom platform-provided > > swiotlb callbacks when needed, that is when not using IOMMU *and* > > running on a secure VM in our case. > > And total NAK the customer platform-provided part of

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Thu, 2018-08-02 at 23:52 +0300, Michael S. Tsirkin wrote: > > Yes, this is the purpose of Anshuman original patch (I haven't looked > > at the details of the patch in a while but that's what I told him to > > implement ;-) : > > > > - Make virtio always use DMA ops to simplify the code path

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Thu, 2018-08-02 at 20:19 +0300, Michael S. Tsirkin wrote: > > I see. So yes, given that device does not know or care, using > virtio features is an awkward fit. > > So let's say as a quick fix for you maybe we could generalize the > xen_domain hack, instead of just checking xen_domain check

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Thu, 2018-08-02 at 18:41 +0300, Michael S. Tsirkin wrote: > > > I don't completely agree: > > > > 1 - VIRTIO_F_IOMMU_PLATFORM is a property of the "other side", ie qemu > > for example. It indicates that the peer bypasses the normal platform > > iommu. The platform code in the guest has no

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Thu, 2018-08-02 at 00:56 +0300, Michael S. Tsirkin wrote: > > but it's not, VMs are > > created in "legacy" mode all the times and we don't know at VM creation > > time whether it will become a secure VM or not. The way our secure VMs > > work is that they start as a normal VM, load a secure

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Wed, 2018-08-01 at 01:36 -0700, Christoph Hellwig wrote: > We just need to figure out how to deal with devices that deviate > from the default. One things is that VIRTIO_F_IOMMU_PLATFORM really > should become VIRTIO_F_PLATFORM_DMA to cover the cases of non-iommu > dma tweaks (offsets, cache

Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, 2018-07-31 at 10:30 -0700, Christoph Hellwig wrote: > > However the question people raise is that DMA API is already full of > > arch-specific tricks the likes of which are outlined in your post linked > > above. How is this one much worse? > > None of these warts is visible to the

Re: [PATCH v3] PCI: Data corruption happening due to race condition

On Fri, 2018-07-27 at 17:25 -0500, Bjorn Helgaas wrote: > > As for the powerpc bits, I'm probably the one who wrote them, however, > > I'm on vacation this week and right now, no bandwidth to context switch > > all that back in :-) So give me a few days and/or ping me next week. > > OK, here's a

Re: [PATCH 4/7] x86,tlb: make lazy TLB mode lazier

On Thu, 2018-07-19 at 10:04 -0700, Andy Lutomirski wrote: > On Thu, Jul 19, 2018 at 9:45 AM, Andy Lutomirski wrote: > > [I added PeterZ and Vitaly -- can you see any way in which this would > > break something obscure? I don't.] Added Nick and Aneesh. We do have HW remote flushes on powerpc. >

Re: [PATCH v3] PCI: Data corruption happening due to race condition

On Thu, 2018-07-19 at 20:55 +0200, Lukas Wunner wrote: > On Thu, Jul 19, 2018 at 9:48 AM, Benjamin Herrenschmidt > > Indeed. However I'm not fan of the solution. Shouldn't we instead have > > some locking for the content of pci_dev? I've always been wary of us > > havin

Re: [PATCH v3] PCI: Data corruption happening due to race condition

On Wed, 2018-07-18 at 18:29 -0500, Bjorn Helgaas wrote: > [+cc Paul, Michael, linuxppc-dev] > /... > > Debugging revealed a race condition between pcie core driver > > enabling is_added bit(pci_bus_add_device()) and nvme driver > > reset work-queue enabling is_busmaster bit (by

Re: Several suspected memory leaks

On Tue, 2018-07-10 at 17:17 +0200, Paul Menzel wrote: > Dear Liunx folks, > > > On a the IBM S822LC (8335-GTA) with Ubuntu 18.04 I built Linux master > – 4.18-rc4+, commit 092150a2 (Merge branch 'for-linus' > of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) – with > kmemleak. Several

Re: [PATCH] powerpc: Replaced msleep with usleep_range

On Mon, 2018-07-09 at 15:57 +0200, Daniel Klamt wrote: > Replaced msleep for less than 10ms with usleep_range because will > often sleep longer than intended. > For original explanation see: > Documentation/timers/timers-howto.txt Why ? This is pointless. The original code is smaller and more

Re: powerpc: 32BIT vs. 64BIT (PPC32 vs. PPC64)

On Thu, 2018-07-05 at 14:30 -0700, Randy Dunlap wrote: > Hi, > > Is there a good way (or a shortcut) to do something like: > > $ make ARCH=powerpc O=PPC32 [other_options] allmodconfig > to get a PPC32/32BIT allmodconfig > > and also be able to do: > > $make ARCH=powerpc O=PPC64

Re: [PATCH 2/3] powerpc/powernv: DMA operations for discontiguous allocation

On Fri, 2018-06-29 at 17:34 +1000, Russell Currey wrote: > DMA pseudo-bypass is a new set of DMA operations that solve some issues for > devices that want to address more than 32 bits but can't address the 59 > bits required to enable direct DMA. One thing you may need to add (I didn't see it

Re: [PATCH 65/65] powerpc/mm/radix: Cputable update for radix

On Fri, 2016-04-01 at 15:04 +0530, Aneesh Kumar K.V wrote: > > commit 9c9d8b4f6a2c2210c90cbb3f5c6d33b2a642e8d2 > Author: Aneesh Kumar K.V > Date: Mon Feb 15 13:44:01 2016 +0530 > > powerpc/mm/radix: Cputable update for radix > > With P9 Radix we need to do > > * set UPRT

Re: [PATCH v3 00/12] macintosh: Resolve various PMU driver problems

On Wed, 2018-06-27 at 13:08 +1000, Michael Ellerman wrote: > > I will rewrite patch 10/12 after Arnd's fixes and this series have all > > made their way through both powerpc and m68k trees, and submit it > > separately. > > drivers/macintosh is supposedly maintained by Ben, but I'm not sure

Re: [PATCH] arch: powerpc: pci-common: fix wrong return value check on phd_id

On Thu, 2018-06-21 at 10:28 +1000, Michael Ellerman wrote: > > That's true, though I think yours is the first report we've had of > problems. > > The old behaviour relied on device tree ordering in nearly all cases, so > you basically get whatever order your firmware happened to flatten the >

Re: [git pull] Please pull powerpc.git next branch

On Wed, 2018-06-20 at 07:58 +0900, Linus Torvalds wrote: > On Wed, Jun 20, 2018 at 5:23 AM Benjamin Herrenschmidt > wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > > I love the alleged line removal, but there's nothing in that 'me

[git pull] Please pull powerpc.git next branch

nce commit 45d7f32c7a43cbb9592886d38190e379e2eb2226: Linus Torvalds (1): Merge git://git.kernel.org/.../cmetcalf/linux-tile are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Benjamin Herrenschmidt (4): powerpc: Trim defconfigs mem

Re: [git pull] Please pull powerpc.git next branch

On Mon, 2010-08-09 at 14:11 +1000, Benjamin Herrenschmidt wrote: > Hi Linus ! > > Here's a few misc things for .36. The big bit is that I trimmed all the > defconfigs using make savedefconfig. > > Then there's a revert for a change to the appletouch driver that went > i

Re: [PATCH kernel 2/2] powerpc/powernv: Define PHB4 type and enable sketchy bypass on POWER9

On Mon, 2018-06-18 at 12:13 +1000, Alexey Kardashevskiy wrote: > On Sat, 16 Jun 2018 11:05:19 +1000 > Benjamin Herrenschmidt wrote: > > > On Fri, 2018-06-01 at 18:10 +1000, Alexey Kardashevskiy wrote: > > > These are found in POWER9 chips. Right now these PHBs have unknow

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Fri, 2018-06-15 at 02:16 -0700, Christoph Hellwig wrote: > On Wed, Jun 13, 2018 at 11:11:01PM +1000, Benjamin Herrenschmidt wrote: > > Actually ... the stuff in lib/dma-direct.c seems to be just it, no ? > > > > There's no cache flushing and there's no architecture hoo

Re: [PATCH kernel 2/2] powerpc/powernv: Define PHB4 type and enable sketchy bypass on POWER9

On Fri, 2018-06-01 at 18:10 +1000, Alexey Kardashevskiy wrote: > These are found in POWER9 chips. Right now these PHBs have unknown type > so changing it to PHB4 won't make much of a difference except enabling > sketchy bypass for POWER9 as this does below. And that will break on multi-chip

Re: [PATCH kernel 1/2] powerpc/powernv: Reuse existing TCE code for sketchy bypass

On Fri, 2018-06-01 at 18:10 +1000, Alexey Kardashevskiy wrote: > The existing sketchy bypass ignores the existing default 32bit TCE table > (created by default for every PE at boot time or after being used by > VFIO) and it allocates another table instead without updating PE DMA > config

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Wed, 2018-06-13 at 22:25 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-06-13 at 00:41 -0700, Christoph Hellwig wrote: > > On Mon, Jun 11, 2018 at 01:29:18PM +1000, Benjamin Herrenschmidt wrote: > > > At the risk of repeating myself, let's just do the first pass which

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Wed, 2018-06-13 at 00:41 -0700, Christoph Hellwig wrote: > On Mon, Jun 11, 2018 at 01:29:18PM +1000, Benjamin Herrenschmidt wrote: > > At the risk of repeating myself, let's just do the first pass which is > > to switch virtio over to always using the DMA API in the actual dat

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Mon, 2018-06-11 at 06:28 +0300, Michael S. Tsirkin wrote: > > > However if the administrator > > ignores/forgets/deliberatey-decides/is-constrained to NOT enable the > > flag, virtio will not be able to pass control to the DMA ops associated > > with the virtio devices. Which means, we have no

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Sun, 2018-06-10 at 19:39 -0700, Ram Pai wrote: > > However if the administrator > ignores/forgets/deliberatey-decides/is-constrained to NOT enable the > flag, virtio will not be able to pass control to the DMA ops associated > with the virtio devices. Which means, we have no opportunity to

Re: [RFC PATCH] powerpc/64s: remove POWER9 DD1 support

On Mon, 2018-06-11 at 11:37 +1000, Nicholas Piggin wrote: > > > > - > > > /* Perform the acknowledge OS to register cycle. */ > > > ack = be16_to_cpu(__x_readw(__x_tima + TM_SPC_ACK_OS_REG)); > > > > > > @@ -105,7 +93,7 @@ static void GLUE(X_PFX,source_eoi)(u32 hw_irq, > > > struct

Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

On Sun, 2018-06-10 at 21:12 +1200, Michael Schmitz wrote: > Hi Geert, Top posting, sorry ... We are painting that bike shed with way too many coats.. We can keep the existing definitions, stick a comment on them stating "obsolete" and use new number if/when needed. Ben. > Am 10.06.2018 um

Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

On Sat, 2018-06-09 at 22:21 +1000, Finn Thain wrote: > In anycase, the "v1" and "v2" scheme is obviously inadequate when you > consider the range of m68k powerbook models. Also, consider the > out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has > this ABI break: > > diff

[PATCH] powerpc: Don't let userspace trigger a kernel WARN_ON

ut we move it back to after the VMA has been found. Signed-off-by: Benjamin Herrenschmidt --- diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c index c01d627e687a..20384445ca44 100644 --- a/arch/powerpc/mm/fault.c +++ b/arch/powerpc/mm/fault.c @@ -416,9 +416,6 @@ static int __do_page_fa

Re: [RFC PATCH kernel 0/5] powerpc/P9/vfio: Pass through NVIDIA Tesla V100

On Thu, 2018-06-07 at 18:34 -0600, Alex Williamson wrote: > > We *can* allow individual GPUs to be passed through, either if somebody > > designs a system without cross links, or if the user is ok with the > > security risk as the guest driver will not enable them if it doesn't > > "find" both

Re: [RFC PATCH kernel 0/5] powerpc/P9/vfio: Pass through NVIDIA Tesla V100

On Thu, 2018-06-07 at 16:15 -0600, Alex Williamson wrote: > On Fri, 08 Jun 2018 07:54:02 +1000 > Benjamin Herrenschmidt wrote: > > > On Thu, 2018-06-07 at 11:04 -0600, Alex Williamson wrote: > > > > > > Can we back up and discuss whether the IOMMU grouping

Re: [RFC PATCH kernel 0/5] powerpc/P9/vfio: Pass through NVIDIA Tesla V100

On Thu, 2018-06-07 at 11:04 -0600, Alex Williamson wrote: > > Can we back up and discuss whether the IOMMU grouping of NVLink > connected devices makes sense? AIUI we have a PCI view of these > devices and from that perspective they're isolated. That's the view of > the device used to generate

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Mon, 2018-06-04 at 19:21 +0300, Michael S. Tsirkin wrote: > > > > > - First qemu doesn't know that the guest will switch to "secure mode" > > > > in advance. There is no difference between a normal and a secure > > > > partition until the partition does the magic UV call to "enter secure > > >

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Mon, 2018-06-04 at 05:55 -0700, Christoph Hellwig wrote: > On Mon, Jun 04, 2018 at 03:43:09PM +0300, Michael S. Tsirkin wrote: > > Another is that given the basic functionality is in there, optimizations > > can possibly wait until per-device quirks in DMA API are supported. > > We have had

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Mon, 2018-06-04 at 15:43 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > >

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Mon, 2018-06-04 at 18:57 +1000, David Gibson wrote: > > > - First qemu doesn't know that the guest will switch to "secure mode" > > in advance. There is no difference between a normal and a secure > > partition until the partition does the magic UV call to "enter secure > > mode" and qemu

Re: [PATCH v2] cpuidle/powernv : Add Description for cpuidle state

On Mon, 2018-06-04 at 13:47 +0530, Abhishek Goel wrote: > + if (of_property_read_string_array(power_mgt, > + "ibm,cpu-idle-state-descs", descs, dt_idle_states) < 0) { > + of_property_read_string_array(power_mgt, > +

[RFC PATCH 07/11] powerpc/prom_init: Move ibm_arch_vec to __prombss

Make the existing initialized definition constant and copy it to a __prombss copy Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel

[RFC PATCH] powerpc: Add support for adding an ESM blob to the zImage wrapper

Image wrapper itself to retrieve and if necessary relocate the blob, and pass its address to Linux via the device-tree, to be later consumed by prom_init. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/boot/main.c | 41 ++ arch/powerpc/boot/ops.h|

[RFC PATCH 05/11] powerpc/prom_init: Remove support for OPAL v2

We removed support for running under any OPAL version earlier than v3 in 2015 (they never saw the light of day anyway), but we kept some leftovers of this support in prom_init.c, so let's take it out. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 147

[RFC PATCH 04/11] powerpc/prom_init: Replace __initdata with __prombss when applicable

This replaces all occurrences of __initdata for uninitialized data with a new __prombss Currently __promdata is defined to be __initdata but we'll eventually change that. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 55 + 1 file

[RFC PATCH 09/11] powerpc/prom_init: Move a few remaining statics to appropriate sections

Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index 67df2758a4e2..f54177a84dbc 100644 --- a/arch/powerpc/kernel/prom_init.c

[RFC PATCH 08/11] powerpc/prom_init: Move const structures to __initconst

As they are no longer used past the end of prom_init Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index 8bb6740e3262

[RFC PATCH 11/11] powerpc: Check prom_init for disallowed sections

prom_init.c must not modify the kernel image outside of the .bss.prominit section. Thus make sure that prom_init.o doesn't have anything in any of these: .data .bss .init.data Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init_check.sh | 16

[RFC PATCH 10/11] powerpc/prom_init: Move __prombss to it's own section and store it in .bss

This makes __prombss its own section, and for now store it in .bss. This will give us the ability later to store it elsewhere and/or free it after boot (it's about 8KB). Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 2 +- arch/powerpc/kernel/vmlinux.lds.S | 3

[RFC PATCH 06/11] powerpc/prom_init: Move prom_radix_disable to __prombss

Initialize it dynamically instead of statically Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index 7c3d285750ad..6a7549f64e28

[RFC PATCH 03/11] powerpc/prom_init: Make "default_colors" const

It's never modified either Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index 158f9ece064e..860d2dbb6634 100644 --- a/arch/powerpc

[RFC PATCH 02/11] powerpc/prom_init: Make "fake_elf" const

It is never modified Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index d6f52cc141c3..158f9ece064e 100644 --- a/arch/powerpc/kernel

[RFC PATCH 01/11] powerpc/prom_init: Make of_workarounds static

It's not used anywhere else Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/prom_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index f9d6befb55a6..d6f52cc141c3 100644 --- a/arch/powerpc

[no subject]

prom_init is a rather "special" bit of code. Run once when booting from Open Firmware as pretty much the very first thing we do, it will perform all communications with OF before it gets killed and extract the device-tree for the kernel use. It will then re-enter the kernel at its main entry point

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Tue, 2018-05-29 at 07:03 -0700, Christoph Hellwig wrote: > On Tue, May 29, 2018 at 09:56:24AM +1000, Benjamin Herrenschmidt wrote: > > I don't think forcing the addition of an emulated iommu in the middle > > just to work around the fact that virtio "cheats" and do

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Tue, 2018-05-29 at 09:48 +1000, Benjamin Herrenschmidt wrote: > > Well it's not supposed to be much slower for the static case. > > > > vhost has a cache so should be fine. > > > > A while ago Paolo implemented a translation cache which should be > > perf

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Fri, 2018-05-25 at 20:45 +0300, Michael S. Tsirkin wrote: > On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > > > > > I re-read that discussion and I'm still unclear on the > >

Re: [PATCH] powerpc/64: Fix build failure with GCC 8.1

On Mon, 2018-05-28 at 16:37 +, Christophe Leroy wrote: > CC arch/powerpc/kernel/nvram_64.o > arch/powerpc/kernel/nvram_64.c: In function 'nvram_create_partition': > arch/powerpc/kernel/nvram_64.c:1042:2: error: 'strncpy' specified bound 12 > equals destination size

Re: [PATCH] powerpc/64s: Clear PCR on boot

On Sat, 2018-05-26 at 20:45 -0700, Guenter Roeck wrote: > > I already have a patch, or at least one that does the trick for me. > Getting qemu patched was not the problem. I just want to be sure that > the problem is indeed a qemu problem. Hey Guenter ! It's not quite the right patch though.

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

On Wed, 2018-05-23 at 21:50 +0300, Michael S. Tsirkin wrote: > I re-read that discussion and I'm still unclear on the > original question, since I got several apparently > conflicting answers. > > I asked: > > Why isn't setting VIRTIO_F_IOMMU_PLATFORM on the > hypervisor side

Re: [PATCH] powerpc: Ensure gcc doesn't move around cache flushing in __patch_instruction

On Thu, 2018-05-17 at 14:23 -0500, Segher Boessenkool wrote: > Hi! > > On Thu, May 17, 2018 at 01:06:10PM +1000, Benjamin Herrenschmidt wrote: > > The current asm statement in __patch_instruction() for the cache flushes > > doesn't have a "volatile" statement an

Re: [PATCH v2 5/5] powerpc/lib: inline memcmp() for small constant sizes

On Thu, 2018-05-17 at 15:21 +0200, Christophe LEROY wrote: > > > +static inline int __memcmp8(const void *p, const void *q, int off) > > > +{ > > > + s64 tmp = be64_to_cpu(*(u64*)(p + off)) - be64_to_cpu(*(u64*)(q + > > > off)); > > > > I always assumed 64bits unaligned access would

Re: [PATCH v2 2/2] powerpc/32be: use stmw/lmw for registers save/restore in asm

On Thu, 2018-05-17 at 22:10 +1000, Michael Ellerman wrote: > Christophe Leroy writes: > > arch/powerpc/Makefile activates -mmultiple on BE PPC32 configs > > in order to use multiple word instructions in functions entry/exit > > True, though that could be a lot simpler

[PATCH] powerpc: Ensure gcc doesn't move around cache flushing in __patch_instruction

nd by code inspection, no actual bug reported. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- --- a/arch/powerpc/lib/code-patching.c +++ b/arch/powerpc/lib/code-patching.c @@ -32,8 +32,9 @@ static int __patch_instruction(unsigned int *exec_addr, unsigned int instr,

Re: [PATCH] powerpc/64s/radix: reset mm_cpumask for single thread process when possible

On Wed, 2018-05-09 at 16:56 +1000, Nicholas Piggin wrote: > When a single-threaded process has a non-local mm_cpumask and requires > a full PID tlbie invalidation, use that as an opportunity to reset the > cpumask back to the current CPU we're running on. > > No other thread can concurrently

Re: [PATCH] cxl: disable the lazy approach for irqs in POWERVM environment.

On Mon, 2018-05-07 at 18:02 +0200, christophe lombard wrote: > > To answer to your questions, here is the timeline in the cxl driver > >1. call disable_irq() > >2. call plpar_hcall9() to attach a process element > During this phase, phyp (as described in CAPI PAPR document) >

Re: [PATCH 4/4] powerpc/xive: prepare all hcalls to support long busy delays

On Fri, 2018-05-04 at 20:42 +1000, Michael Ellerman wrote: > Cédric Le Goater writes: > > > This is not the case for the moment, but future releases of pHyp might > > need to introduce some synchronisation routines under the hood which > > would make the XIVE hcalls longer to

Re: [PATCH 08/15] powerpc/powernv: implement opal_put_chars_atomic

that is used, the better chance there > is that a crash can be debugged. Same comment I already had :-) "atomic" in Linux tends to mean something else (ie, atomic context), so I'd rather have something like opal_put_chars_sync() or such... > Cc: Benjamin Herrenschmidt <b...@ke

Re: [PATCH] powerpc64s: Print exception vector name alongside the trap number

On Wed, 2018-04-18 at 14:32 +0530, Naveen N. Rao wrote: > > +#ifdef CONFIG_PPC_BOOK3S_64 > +static char *print_trap(unsigned long trapno) > +{ > + trapno &= 0xff0; > + switch (trapno) { > + case 0x100: return "SRESET"; > + case 0x200: return "MCE"; > +

Re: [PATCH 1/3] powerpc/xive: Fix trying to "push" an already active pool VP

On Wed, 2018-04-11 at 15:17 +1000, Benjamin Herrenschmidt wrote: > When setting up a CPU, we "push" (activate) a pool VP for it. > > However it's an error to do so if it already has an active > pool VP. > > This happens when doing soft CPU hotplug on powernv since

[PATCH 2/3] powerpc/xive: Remove now useless pr_debug statements

Those overly verbose statement in the setup of the pool VP aren't particularly useful (esp. considering we don't actually use the pool, we configure it bcs HW requires it only). So remove them which improves the code readability. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.

[PATCH 3/3] powerpc/xive: Remove xive_kexec_teardown_cpu()

It's identical to xive_teardown_cpu() so just use the latter Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/xive.h| 1 - arch/powerpc/platforms/powernv/setup.c | 2 +- arch/powerpc/platforms/pseries/kexec.c | 2 +- arch/powerpc/

[PATCH 1/3] powerpc/xive: Fix trying to "push" an already active pool VP

tics. Fix this by making sure to "pull" out any already active pool first. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/sysdev/xive/native.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/

Re: [RFC PATCH 4/5] KVM: PPC: Book3S HV: handle need_tlb_flush in C before low-level guest entry

On Tue, 2018-04-10 at 22:48 +1000, Nicholas Piggin wrote: > > + /* > +* Do we need to flush the TLB for the LPAR? (see TLB comment above) > + * On POWER9, individual threads can come in here, but the > + * TLB is shared between the 4 threads in a core, hence > +

<    1   2   3   4   5   6   7   8   9   10   >