search for: papr

...pport PCI > emulation. For the (upcoming) kvm case, this is quite difficult to do > because the preferred HV mode for the host kernel does not allow MMIO > emulation (a hardware limitation). > > Therefore, to support virtio devices, we implement a new virtio setup > protocol for PAPR guests. This is based loosely on the s390 and lguest > methods, using the PAPR hcalls for the virtio primitive operations, > and the PAPR device tree to advertise the virtio device resources to the > guest. > > This patch includes support for the virtio block, network, serial, and...

...pport PCI > emulation. For the (upcoming) kvm case, this is quite difficult to do > because the preferred HV mode for the host kernel does not allow MMIO > emulation (a hardware limitation). > > Therefore, to support virtio devices, we implement a new virtio setup > protocol for PAPR guests. This is based loosely on the s390 and lguest > methods, using the PAPR hcalls for the virtio primitive operations, > and the PAPR device tree to advertise the virtio device resources to the > guest. > > This patch includes support for the virtio block, network, serial, and...

...rnv/pci-ioda-tce.c index f923359d8afc..8eba6ece7808 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c +++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c @@ -15,6 +15,7 @@ #include <asm/iommu.h> #include <asm/tce.h> +#include <asm/hvcall.h> /* share error returns with PAPR */ #include "pci.h" unsigned long pnv_ioda_parse_tce_sizes(struct pnv_phb *phb) -- 2.23.0

Signed-off-by: Nicholas Piggin <npiggin at gmail.com> --- arch/powerpc/include/asm/paravirt.h | 61 +++++++++++++++++++++++++++++ arch/powerpc/include/asm/spinlock.h | 24 +----------- arch/powerpc/lib/locks.c | 12 +++--- 3 files changed, 68 insertions(+), 29 deletions(-) create mode 100644 arch/powerpc/include/asm/paravirt.h diff --git a/arch/powerpc/include/asm/paravirt.h

...0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append 'panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm' qemu: fatal: This KVM version does not support PAPR NIP 0000000000000000 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 MSR 0000000000000000 HID0 0000000000000000 HF 0000000000000000 idx 0 TB 00000000 00000000 DECR 00000000 GPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR04 0000000000000000 00000000000...

...if and only if the weak barriers bit is set on > systems that are missing the new DT binding. "New DT bindings" doesn't mean much ... how do we change DT bindings on existing machines with a FW in flash ? What about partition <-> partition virtio such as what we could do on PAPR systems. That would have the weak barrier bit. Ben.

...if and only if the weak barriers bit is set on > systems that are missing the new DT binding. "New DT bindings" doesn't mean much ... how do we change DT bindings on existing machines with a FW in flash ? What about partition <-> partition virtio such as what we could do on PAPR systems. That would have the weak barrier bit. Ben.

...set this bit ? qemu ? Under what circumstances ? > > I don't really care who sets what. The implementation might not even > involved qemu. > > It is your job to write a coherent interface specification that does > not depend on the used components. The hypervisor might be PAPR, > Linux + qemu, VMware, Hyperv or something so secret that you'd have > to shoot me if you had to tell me. The guest might be Linux, FreeBSD, > AIX, OS400 or a Hipster project of the day in Rust. As long as we > properly specify the interface it simplify does not matter. That...

...set this bit ? qemu ? Under what circumstances ? > > I don't really care who sets what. The implementation might not even > involved qemu. > > It is your job to write a coherent interface specification that does > not depend on the used components. The hypervisor might be PAPR, > Linux + qemu, VMware, Hyperv or something so secret that you'd have > to shoot me if you had to tell me. The guest might be Linux, FreeBSD, > AIX, OS400 or a Hipster project of the day in Rust. As long as we > properly specify the interface it simplify does not matter. That...

On Tue, 2015-11-10 at 15:44 -0800, Andy Lutomirski wrote: > > > What about partition <-> partition virtio such as what we could do on > > PAPR systems. That would have the weak barrier bit. > > > > Is it partition <-> partition, bypassing IOMMU? No. > I think I'd settle for just something that doesn't regress > non-experimental setups that actually work today and that allow new > setups (x86 with fixe...

On Tue, 2015-11-10 at 15:44 -0800, Andy Lutomirski wrote: > > > What about partition <-> partition virtio such as what we could do on > > PAPR systems. That would have the weak barrier bit. > > > > Is it partition <-> partition, bypassing IOMMU? No. > I think I'd settle for just something that doesn't regress > non-experimental setups that actually work today and that allow new > setups (x86 with fixe...

On 7/6/20 12:35 AM, Nicholas Piggin wrote: > v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you). > > Thanks, > Nick > > Nicholas Piggin (6): > powerpc/powernv: must include hvcall.h to get PAPR defines > powerpc/pseries: move some PAPR paravirt functions to their own file > powerpc: move spinlock implementation to simple_spinlock > powerpc/64s: implement queued spinlocks and rwlocks > powerpc/pseries: implement paravirt qspinlocks for SPLPAR > powerpc/qspinlo...

v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you). Thanks, Nick Nicholas Piggin (6): powerpc/powernv: must include hvcall.h to get PAPR defines powerpc/pseries: move some PAPR paravirt functions to their own file powerpc: move spinlock implementation to simple_spinlock powerpc/64s: implement queued spinlocks and rwlocks powerpc/pseries: implement paravirt qspinlocks for SPLPAR powerpc/qspinlock: optimised atomic_try_cmpxc...

v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you). Thanks, Nick Nicholas Piggin (6): powerpc/powernv: must include hvcall.h to get PAPR defines powerpc/pseries: move some PAPR paravirt functions to their own file powerpc: move spinlock implementation to simple_spinlock powerpc/64s: implement queued spinlocks and rwlocks powerpc/pseries: implement paravirt qspinlocks for SPLPAR powerpc/qspinlock: optimised atomic_try_cmpxc...

Hi Rich I'm able to solve the problem regarding PAPR in libguestfs on my powerpc ubuntu.By default the libguestfs was configuring pseries machine and afterwards I changed it to my original machine i.e ppce500 .The changes are performed in ./src/guestfs-internal.h file. Thanks On Tue, Jun 10, 2014 at 7:58 PM, Richard W.M. Jones <rjones@redhat.co...

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 qemu side and doesn't need > > to), to be forced to use some custom DMA ops on the VM side. > > >

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 qemu side and doesn't need > > to), to be forced to use some custom DMA ops on the VM side. > > >

...bit is set on >> systems that are missing the new DT binding. > > "New DT bindings" doesn't mean much ... how do we change DT bindings on > existing machines with a FW in flash ? > > What about partition <-> partition virtio such as what we could do on > PAPR systems. That would have the weak barrier bit. > Is it partition <-> partition, bypassing IOMMU? I think I'd settle for just something that doesn't regress non-experimental setups that actually work today and that allow new setups (x86 with fixed QEMU and maybe something more com...

On Nov 10, 2015 4:44 PM, "Benjamin Herrenschmidt" <benh at kernel.crashing.org> wrote: > > On Tue, 2015-11-10 at 15:44 -0800, Andy Lutomirski wrote: > > > > > What about partition <-> partition virtio such as what we could do on > > > PAPR systems. That would have the weak barrier bit. > > > > > > > Is it partition <-> partition, bypassing IOMMU? > > No. > > > I think I'd settle for just something that doesn't regress > > non-experimental setups that actually work today and that...

...nschmidt wrote: > Who would set this bit ? qemu ? Under what circumstances ? I don't really care who sets what. The implementation might not even involved qemu. It is your job to write a coherent interface specification that does not depend on the used components. The hypervisor might be PAPR, Linux + qemu, VMware, Hyperv or something so secret that you'd have to shoot me if you had to tell me. The guest might be Linux, FreeBSD, AIX, OS400 or a Hipster project of the day in Rust. As long as we properly specify the interface it simplify does not matter. > What would be the effe...