Displaying 7 results from an estimated 7 matches for "plartform_translation".
2018 Jun 07
2
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...ly curious how for example the
> Intel virtio based NIC is going to work on any of those
> plaforms.
SEV guys report that they just set the iommu flag and then it all works.
I guess if there's translation we can think of this as a kind of iommu.
Maybe we should rename PLATFORM_IOMMU to PLARTFORM_TRANSLATION?
And apparently some people complain that just setting that flag makes
qemu check translation on each access with an unacceptable performance
overhead. Forcing same behaviour for everyone on general principles
even without the flag is unlikely to make them happy.
> b) coherency
>
>...
2018 Jun 07
2
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...ly curious how for example the
> Intel virtio based NIC is going to work on any of those
> plaforms.
SEV guys report that they just set the iommu flag and then it all works.
I guess if there's translation we can think of this as a kind of iommu.
Maybe we should rename PLATFORM_IOMMU to PLARTFORM_TRANSLATION?
And apparently some people complain that just setting that flag makes
qemu check translation on each access with an unacceptable performance
overhead. Forcing same behaviour for everyone on general principles
even without the flag is unlikely to make them happy.
> b) coherency
>
>...
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
2018 Jun 08
0
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...> > Intel virtio based NIC is going to work on any of those
> > plaforms.
>
> SEV guys report that they just set the iommu flag and then it all works.
> I guess if there's translation we can think of this as a kind of iommu.
> Maybe we should rename PLATFORM_IOMMU to PLARTFORM_TRANSLATION?
VIRTIO_F_BEHAVES_LIKE_A_REAL_PCI_DEVICE_DONT_TRY_TO_OUTSMART_ME
as said it's not just translations, it is cache coherence as well.
> And apparently some people complain that just setting that flag makes
> qemu check translation on each access with an unacceptable performance
> over...
2018 Jun 11
0
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
..., make it happen?
>
I don't see a flexibility argument. I just don't think new platforms
should use workarounds that we put in place for old ones.
> > I guess if there's translation we can think of this as a kind of iommu.
> > Maybe we should rename PLATFORM_IOMMU to PLARTFORM_TRANSLATION?
> >
> > And apparently some people complain that just setting that flag makes
> > qemu check translation on each access with an unacceptable performance
> > overhead. Forcing same behaviour for everyone on general principles
> > even without the flag is unlikely to...
2018 Jun 11
1
[RFC V2] virtio: Add platform specific DMA API translation for virito devices
...I don't see a flexibility argument. I just don't think new platforms
> should use workarounds that we put in place for old ones.
>
>
> > > I guess if there's translation we can think of this as a kind of iommu.
> > > Maybe we should rename PLATFORM_IOMMU to PLARTFORM_TRANSLATION?
> > >
> > > And apparently some people complain that just setting that flag makes
> > > qemu check translation on each access with an unacceptable performance
> > > overhead. Forcing same behaviour for everyone on general principles
> > > even without...