On 2020/2/24 下午9:40, Michael S. Tsirkin wrote:
Subject: [PATCH] vhost: do not set VIRTIO_F_IOMMU_PLATFORM when IOMMU is not
used
We enable device IOTLB unconditionally when VIRTIO_F_IOMMU_PLATFORM is
negotiated. This lead unnecessary IOTLB miss/update transactions when
IOMMU is used. This pat
On 2020/2/24 下午9:56, Halil Pasic wrote:
On Mon, 24 Feb 2020 17:26:20 +0800
Jason Wang wrote:
That's better.
How about attached?
Thanks
Thanks Jason! It does avoid the translation overhead in vhost.
Tested-by: Halil Pasic
Regarding the code, you fence it in virtio-net.c, but AFAIU this f
On Mon, 24 Feb 2020 17:26:20 +0800
Jason Wang wrote:
> That's better.
>
> How about attached?
>
> Thanks
Thanks Jason! It does avoid the translation overhead in vhost.
Tested-by: Halil Pasic
Regarding the code, you fence it in virtio-net.c, but AFAIU this feature
has relevance for other vho
On Mon, Feb 24, 2020 at 05:26:20PM +0800, Jason Wang wrote:
>
> On 2020/2/24 下午3:48, Michael S. Tsirkin wrote:
> > On Mon, Feb 24, 2020 at 02:45:03PM +0800, Jason Wang wrote:
> > > On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
> > > > On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
>
On 2020/2/24 下午3:48, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 02:45:03PM +0800, Jason Wang wrote:
On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
Ja
On Mon, Feb 24, 2020 at 02:45:03PM +0800, Jason Wang wrote:
>
> On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
> > On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
> > > On 2020/2/21 下午10:56, Halil Pasic wrote:
> > > > On Fri, 21 Feb 2020 14:22:26 +0800
> > > > Jason Wang wrote:
> > >
On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory protect
On Fri, Feb 21, 2020 at 03:56:02PM +0100, Halil Pasic wrote:
> On Fri, 21 Feb 2020 14:22:26 +0800
> Jason Wang wrote:
>
> >
> > On 2020/2/21 上午12:06, Halil Pasic wrote:
> > > Currently if one intends to run a memory protection enabled VM with
> > > virtio devices and linux as the guest OS, one n
On Fri, Feb 21, 2020 at 05:41:51PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 04:33:35PM -0500, Michael S. Tsirkin wrote:
> > So it sounds like a host issue: the emulation of s390 unnecessarily
> > complicated.
> > Working around it by the guest looks wrong ...
>
> Yes. If your ho
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
>
> On 2020/2/21 下午10:56, Halil Pasic wrote:
> > On Fri, 21 Feb 2020 14:22:26 +0800
> > Jason Wang wrote:
> >
> > > On 2020/2/21 上午12:06, Halil Pasic wrote:
> > > > Currently if one intends to run a memory protection enabled VM with
> >
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify the
VIRTIO_F_IOMMU_PLATFOR
On Thu, Feb 20, 2020 at 04:33:35PM -0500, Michael S. Tsirkin wrote:
> So it sounds like a host issue: the emulation of s390 unnecessarily
> complicated.
> Working around it by the guest looks wrong ...
Yes. If your host (and I don't care if you split hypervisor, ultravisor
and megavisor out in y
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
>
> On 2020/2/21 上午12:06, Halil Pasic wrote:
> > Currently if one intends to run a memory protection enabled VM with
> > virtio devices and linux as the guest OS, one needs to specify the
> > VIRTIO_F_IOMMU_PLATFORM flag for each virtio device
On Thu, 20 Feb 2020 16:33:35 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> > For vhost-net the feature VIRTIO_F_IOMMU_PLATFORM has the following side
> > effect The vhost code assumes it the addresses on the virtio descriptor
> > ring are not g
On Thu, 20 Feb 2020 16:29:50 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> > * This usage is not congruent with standardised semantics of
> > VIRTIO_F_IOMMU_PLATFORM. Guest memory protected is an orthogonal reason
> > for using DMA API in virt
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify the
VIRTIO_F_IOMMU_PLATFORM flag for each virtio device to make the guest
linux use the DMA API, which in turn handles the m
On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> For vhost-net the feature VIRTIO_F_IOMMU_PLATFORM has the following side
> effect The vhost code assumes it the addresses on the virtio descriptor
> ring are not guest physical addresses but iova's, and insists on doing a
> translation
On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> * This usage is not congruent with standardised semantics of
> VIRTIO_F_IOMMU_PLATFORM. Guest memory protected is an orthogonal reason
> for using DMA API in virtio (orthogonal with respect to what is
> expressed by VIRTIO_F_IOMMU_PLAT
On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> Currently if one intends to run a memory protection enabled VM with
> virtio devices and linux as the guest OS, one needs to specify the
> VIRTIO_F_IOMMU_PLATFORM flag for each virtio device to make the guest
> linux use the DMA API, wh
Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify the
VIRTIO_F_IOMMU_PLATFORM flag for each virtio device to make the guest
linux use the DMA API, which in turn handles the memory
encryption/protection stuff if the gue
20 matches
Mail list logo
