search for: qdio

...> > > As virtio-ccw devices are channel devices, we need to use the dma area > > > for any communication with the hypervisor. > > > > > > This patch addresses the most basic stuff (mostly what is required for > > > virtio-ccw), and does take care of QDIO or any devices. > > > > "does not take care of QDIO", surely? > > I did not bother making the QDIO library code use dma memory for > anything that is conceptually dma memory. AFAIK QDIO is out of scope for > prot virt for now. If one were to do some emulated...

...> > > As virtio-ccw devices are channel devices, we need to use the dma area > > > for any communication with the hypervisor. > > > > > > This patch addresses the most basic stuff (mostly what is required for > > > virtio-ccw), and does take care of QDIO or any devices. > > > > "does not take care of QDIO", surely? > > I did not bother making the QDIO library code use dma memory for > anything that is conceptually dma memory. AFAIK QDIO is out of scope for > prot virt for now. If one were to do some emulated...

...00 Halil Pasic <pasic at linux.ibm.com> wrote: > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > This patch addresses the most basic stuff (mostly what is required for > virtio-ccw), and does take care of QDIO or any devices. "does not take care of QDIO", surely? (Also, what does "any devices" mean? Do you mean "every arbitrary device", perhaps?) > > An interesting side effect is that virtio structures are now going to > get allocated in 31 bit addressable storag...

...00 Halil Pasic <pasic at linux.ibm.com> wrote: > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > This patch addresses the most basic stuff (mostly what is required for > virtio-ccw), and does take care of QDIO or any devices. "does not take care of QDIO", surely? (Also, what does "any devices" mean? Do you mean "every arbitrary device", perhaps?) > > An interesting side effect is that virtio structures are now going to > get allocated in 31 bit addressable storag...

...s virtio-ccw devices are channel devices, we need to use the dma area > > > > for any communication with the hypervisor. > > > > > > > > This patch addresses the most basic stuff (mostly what is required for > > > > virtio-ccw), and does take care of QDIO or any devices. > > > > > > "does not take care of QDIO", surely? > > > > I did not bother making the QDIO library code use dma memory for > > anything that is conceptually dma memory. AFAIK QDIO is out of scope for > > prot virt for now. I...

...nux.ibm.com> wrote: > > > As virtio-ccw devices are channel devices, we need to use the dma area > > for any communication with the hypervisor. > > > > This patch addresses the most basic stuff (mostly what is required for > > virtio-ccw), and does take care of QDIO or any devices. > > "does not take care of QDIO", surely? I did not bother making the QDIO library code use dma memory for anything that is conceptually dma memory. AFAIK QDIO is out of scope for prot virt for now. If one were to do some emulated qdio with prot virt guests, one w...

...25,7 @@ config S390 > select HAVE_CMPXCHG_DOUBLE > select HAVE_CMPXCHG_LOCAL > select HAVE_DEBUG_KMEMLEAK > + select HAVE_DMA_ATTRS > select HAVE_DYNAMIC_FTRACE > select HAVE_DYNAMIC_FTRACE_WITH_REGS > select HAVE_FTRACE_MCOUNT_RECORD > @@ -580,7 +582,6 @@ config QDIO > > menuconfig PCI > bool "PCI support" > - select HAVE_DMA_ATTRS > select PCI_MSI > help > Enable PCI support. Hm. Further down in this file, there's config HAS_DMA def_bool P...

...25,7 @@ config S390 > select HAVE_CMPXCHG_DOUBLE > select HAVE_CMPXCHG_LOCAL > select HAVE_DEBUG_KMEMLEAK > + select HAVE_DMA_ATTRS > select HAVE_DYNAMIC_FTRACE > select HAVE_DYNAMIC_FTRACE_WITH_REGS > select HAVE_FTRACE_MCOUNT_RECORD > @@ -580,7 +582,6 @@ config QDIO > > menuconfig PCI > bool "PCI support" > - select HAVE_DMA_ATTRS > select PCI_MSI > help > Enable PCI support. Hm. Further down in this file, there's config HAS_DMA def_bool P...

...shared. > > > > In this context, does 'hypervisor' always mean 'QEMU/KVM'? If Other > > Hypervisors implement protected virtualization, we probably need to > > make sure that all common I/O layer control blocks are in the dma area > > (including e.g. QDIO), not just what virtio-ccw devices use. > > > > Hypervisor could theoretically be something different than QEMU/KVM. Yet, > as stated before, this series is about getting virtio-ccw working > (modulo the TODOs). Sure, just wanted to point it out. If this is "enable the...

...Thu, 23 May 2019 18:22:04 +0200 Michael Mueller <mimu at linux.ibm.com> wrote: > From: Halil Pasic <pasic at linux.ibm.com> > > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > It handles neither QDIO in the common code, nor any device type specific > stuff (like channel programs constructed by the DASD driver). > > An interesting side effect is that virtio structures are now going to > get allocated in 31 bit addressable storage. > > Signed-off-by: Halil Pasic <pasic at l...

...Thu, 23 May 2019 18:22:04 +0200 Michael Mueller <mimu at linux.ibm.com> wrote: > From: Halil Pasic <pasic at linux.ibm.com> > > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > It handles neither QDIO in the common code, nor any device type specific > stuff (like channel programs constructed by the DASD driver). > > An interesting side effect is that virtio structures are now going to > get allocated in 31 bit addressable storage. > > Signed-off-by: Halil Pasic <pasic at l...

...gt; > > >> As virtio-ccw devices are channel devices, we need to use the dma area > >> for any communication with the hypervisor. > >> > >> This patch addresses the most basic stuff (mostly what is required for > >> virtio-ccw), and does take care of QDIO or any devices. > > > > "does not take care of QDIO", surely? (Also, what does "any devices" > > mean? Do you mean "every arbitrary device", perhaps?) > > > >> > >> An interesting side effect is that virtio structures are now...

...at linux.ibm.com> wrote: > >> As virtio-ccw devices are channel devices, we need to use the dma area >> for any communication with the hypervisor. >> >> This patch addresses the most basic stuff (mostly what is required for >> virtio-ccw), and does take care of QDIO or any devices. > > "does not take care of QDIO", surely? (Also, what does "any devices" > mean? Do you mean "every arbitrary device", perhaps?) > >> >> An interesting side effect is that virtio structures are now going to >> get allocat...

...e that we do not need to use that area for control blocks directly referenced by instructions, e.g. the orb." ...although I'm still not particularly confident about the actual distinction here? I'm trusting you that you actually have tested it, though :) > > It handles neither QDIO in the common code, nor any device type specific > stuff (like channel programs constructed by the DASD driver). > > An interesting side effect is that virtio structures are now going to > get allocated in 31 bit addressable storage. > > Signed-off-by: Halil Pasic <pasic at l...

...e that we do not need to use that area for control blocks directly referenced by instructions, e.g. the orb." ...although I'm still not particularly confident about the actual distinction here? I'm trusting you that you actually have tested it, though :) > > It handles neither QDIO in the common code, nor any device type specific > stuff (like channel programs constructed by the DASD driver). > > An interesting side effect is that virtio structures are now going to > get allocated in 31 bit addressable storage. > > Signed-off-by: Halil Pasic <pasic at l...

...m> wrote: > > > > > From: Halil Pasic <pasic at linux.ibm.com> > > > > > > As virtio-ccw devices are channel devices, we need to use the dma area > > > for any communication with the hypervisor. > > > > > > It handles neither QDIO in the common code, nor any device type specific > > > stuff (like channel programs constructed by the DASD driver). > > > > > > An interesting side effect is that virtio structures are now going to > > > get allocated in 31 bit addressable storage. > > &g...

...m> wrote: > > > > > From: Halil Pasic <pasic at linux.ibm.com> > > > > > > As virtio-ccw devices are channel devices, we need to use the dma area > > > for any communication with the hypervisor. > > > > > > It handles neither QDIO in the common code, nor any device type specific > > > stuff (like channel programs constructed by the DASD driver). > > > > > > An interesting side effect is that virtio structures are now going to > > > get allocated in 31 bit addressable storage. > > &g...

...ch specific code to flush in/out memory accesses for > synchronization with the hypervisor? > > I went over s390 arch code and it seems to me the answer is no > (except of course for virtio). Correct. Guest to host communication either uses instructions which imply a memory barrier or QDIO which uses atomics. > But I also see a lot of weirdness on this architecture. Mostly historical, s390 actually is one of the easiest architectures in regard to memory barriers. > I found these calls: > > arch/s390/include/asm/bitops.h: smp_mb__before_atomic(); > arch/s390/include...

...ch specific code to flush in/out memory accesses for > synchronization with the hypervisor? > > I went over s390 arch code and it seems to me the answer is no > (except of course for virtio). Correct. Guest to host communication either uses instructions which imply a memory barrier or QDIO which uses atomics. > But I also see a lot of weirdness on this architecture. Mostly historical, s390 actually is one of the easiest architectures in regard to memory barriers. > I found these calls: > > arch/s390/include/asm/bitops.h: smp_mb__before_atomic(); > arch/s390/include...

....com> wrote: > On Thu, 16 May 2019 08:29:28 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Wed, 15 May 2019 22:51:58 +0200 > > Halil Pasic <pasic at linux.ibm.com> wrote: > Don't like the second sentence. How about "It handles neither QDIO > in the common code, nor any device type specific stuff (like channel > programs constructed by the DADS driver)." Sounds good to me (with s/DADS/DASD/ :) > > > A side note: making the subchannel device 'own' the DMA stuff of a > > > ccw device (something tha...