Displaying 7 results from an estimated 7 matches for "virtio_f_is_pci_device".
2018 Jun 13
3
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...at the
> architecture gets a say in the matter.
I don't think we can actually use dma_direct_ops. It still allows
architectures to override parts of the dma setup, which virtio seems
to blindly assume phys == dma and not cache flushing.
I think the right way forward is to either add a new
VIRTIO_F_IS_PCI_DEVICE (or redefine the existing iommu flag if deemed
possible). And then make sure recent qemu always sets it.
2018 Jun 13
3
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...at the
> architecture gets a say in the matter.
I don't think we can actually use dma_direct_ops. It still allows
architectures to override parts of the dma setup, which virtio seems
to blindly assume phys == dma and not cache flushing.
I think the right way forward is to either add a new
VIRTIO_F_IS_PCI_DEVICE (or redefine the existing iommu flag if deemed
possible). And then make sure recent qemu always sets it.
2018 Jun 13
0
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...gt; to blindly assume phys == dma and not cache flushing.
By direct ops I didn't mean *the* dma_direct_ops but a virtio-local
variants that effectively reproduces the existing expectations (ie,
virtio-dma-legacy-ops or something).
> I think the right way forward is to either add a new
> VIRTIO_F_IS_PCI_DEVICE (or redefine the existing iommu flag if deemed
> possible). And then make sure recent qemu always sets it.
Ben.
2018 Jun 13
2
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...-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 ?
Cheers,
Ben.
>
> > I think the right way forward is to either add a new
> > VIRTIO_F_IS_PCI_DEVICE (or redefine the existing iommu flag if deemed
> > possible). And then make sure recent qemu always sets it.
>
> Ben.
2018 Jun 13
2
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...-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 ?
Cheers,
Ben.
>
> > I think the right way forward is to either add a new
> > VIRTIO_F_IS_PCI_DEVICE (or redefine the existing iommu flag if deemed
> > possible). And then make sure recent qemu always sets it.
>
> Ben.
2018 May 31
7
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
On Thu, May 31, 2018 at 09:09:24AM +0530, Anshuman Khandual wrote:
> 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
2018 May 31
7
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
On Thu, May 31, 2018 at 09:09:24AM +0530, Anshuman Khandual wrote:
> 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