search for: virito

On 05/24/2018 12:51 PM, Ram Pai wrote: > On Wed, May 23, 2018 at 09:50:02PM +0300, Michael S. Tsirkin wrote: >> subj: s/virito/virtio/ >> > ..snip.. >>> machine_subsys_initcall_sync(pseries, tce_iommu_bus_notifier_init); >>> + >>> +bool platform_forces_virtio_dma(struct virtio_device *vdev) >>> +{ >>> + /* >>> + * On protected guest platforms, force virtio co...

On Thu, 13 Nov 2014 13:52:53 +0800 Jason Wang <jasowang at redhat.com> wrote: typo in subject-prefix: s/virito/virtio/ > Buggy host may advertised buggy host features (a usual case is that host > advertise a feature whose dependencies were missed). In this case, driver > should detect and disable the buggy features by itself. > > This patch introduces driver specific fix_features() method w...

On 07/20/2018 06:45 PM, Michael S. Tsirkin wrote: > On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >> Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for >> virito devices > > s/virito/virtio/ Oops, will fix it. Thanks for pointing out. > >> This adds a hook which a platform can define in order to allow it to >> override virtio device's DMA OPS irrespective of whether it has the >> flag VIRTIO_F_IOMMU_PLATFORM set or not. We...

subj: s/virito/virtio/ On Tue, May 22, 2018 at 12:03:17PM +0530, Anshuman Khandual wrote: > This adds a hook which a platform can define in order to allow it to > force the use of the DMA API for all virtio devices even if they don't > have the VIRTIO_F_IOMMU_PLATFORM flag set. We want to use this...

We need to drop refcnt to xdp_page if we see a gso packet. Otherwise it will be leaked. Fixing this by moving the check of gso packet above the linearizing logic. Cc: John Fastabend <john.fastabend at gmail.com> Fixes: 72979a6c3590 ("virtio_net: xdp, add slowpath case for non contiguous buffers") Signed-off-by: Jason Wang <jasowang at redhat.com> ---

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 > > original question, since I got several apparently > > conflicting answers. > > > > I asked: > > > > Why isn't setting

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 per-device dma_ops for quite a while.

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 per-device dma_ops for quite a while. I've asked Ansuman to start with a patch

On Thu, May 31, 2018 at 08:43:58PM +0300, Michael S. Tsirkin wrote: > Pls work on a long term solution. Short term needs can be served by > enabling the iommu platform in qemu. So, I spent some time looking at converting virtio to dma ops overrides, and the current virtio spec, and the sad through I have to tell is that both the spec and the Linux implementation are complete and utterly

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 share > the I/O buffers with the hypervisor/qemu. > > How do you suggest, we

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 data > > flow code, with a hook at initialization time that replaces the DMA ops > > with

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 hooks that I can > see other than the AMD security stuff which is probably fine. > > Or am I missing something ? You are missing the __phys_to_dma arch hook that allows

On Mon, Jul 02, 2018 at 11:57:28PM +0530, Souptick Joarder wrote: > The fault handler code is commented since v4.2. > If there is no plan to enable the fault handler > code in future, we can remove this dead code. Indeed, but please without tyops in the $subject line. cheers, Gerd

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 per-device dma_ops for quite a while.

On Thu, 13 Nov 2014 17:11:30 +0800 Jason Wang <jasowang at redhat.com> wrote: > On 11/13/2014 04:46 PM, Cornelia Huck wrote: > > On Thu, 13 Nov 2014 13:52:53 +0800 > > Jason Wang <jasowang at redhat.com> wrote: > >> +static inline void virtio_disable_feature(struct virtio_device *vdev, > >> + unsigned int fbit)

Jason Wang <jasowang at redhat.com> writes: > Buggy host may advertised buggy host features (a usual case is that host > advertise a feature whose dependencies were missed). In this case, driver > should detect and disable the buggy features by itself. Sorry, I've been focussing elsewhere. I would really prefer that drivers offer a "feature_depends" table, which can

On 11/13/2014 04:46 PM, Cornelia Huck wrote: > On Thu, 13 Nov 2014 13:52:53 +0800 > Jason Wang <jasowang at redhat.com> wrote: > > typo in subject-prefix: s/virito/virtio/ > Will correct this. >> Buggy host may advertised buggy host features (a usual case is that host >> advertise a feature whose dependencies were missed). In this case, driver >> should detect and disable the buggy features by itself. >> >> This patch introdu...

On 11/13/2014 04:46 PM, Cornelia Huck wrote: > On Thu, 13 Nov 2014 13:52:53 +0800 > Jason Wang <jasowang at redhat.com> wrote: > > typo in subject-prefix: s/virito/virtio/ > Will correct this. >> Buggy host may advertised buggy host features (a usual case is that host >> advertise a feature whose dependencies were missed). In this case, driver >> should detect and disable the buggy features by itself. >> >> This patch introdu...

On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for > virito devices s/virito/virtio/ > This adds a hook which a platform can define in order to allow it to > override virtio device's DMA OPS irrespective of whether it has the > flag VIRTIO_F_IOMMU_PLATFORM set or not. We want to use this to do > bounce-buffering of data on the new secure p...

On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for > virito devices s/virito/virtio/ > This adds a hook which a platform can define in order to allow it to > override virtio device's DMA OPS irrespective of whether it has the > flag VIRTIO_F_IOMMU_PLATFORM set or not. We want to use this to do > bounce-buffering of data on the new secure p...