Re: [PATCH] virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM

2020-06-27 Thread Jason Wang
@@ -385,7 +385,7 @@ static irqreturn_t vu_req_interrupt(int irq, void *data) } break; case VHOST_USER_SLAVE_IOTLB_MSG: - /* not supported - VIRTIO_F_IOMMU_PLATFORM */ + /* not supported - VIRTIO_F_ACCESS_PLATFORM */ case

Re: [PATCH v2 1/2] virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM

2020-06-24 Thread David Hildenbrand
0644 > --- a/arch/um/drivers/virtio_uml.c > +++ b/arch/um/drivers/virtio_uml.c > @@ -385,7 +385,7 @@ static irqreturn_t vu_req_interrupt(int irq, void *data) > } > break; > case VHOST_USER_SLAVE_IOTLB_MSG: > -

[PATCH v2 1/2] virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM

2020-06-24 Thread Michael S. Tsirkin
, void *data) } break; case VHOST_USER_SLAVE_IOTLB_MSG: - /* not supported - VIRTIO_F_IOMMU_PLATFORM */ + /* not supported - VIRTIO_F_ACCESS_PLATFORM */ case VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG: /* not

[PATCH] virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM

2020-06-24 Thread Michael S. Tsirkin
, void *data) } break; case VHOST_USER_SLAVE_IOTLB_MSG: - /* not supported - VIRTIO_F_IOMMU_PLATFORM */ + /* not supported - VIRTIO_F_ACCESS_PLATFORM */ case VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG: /* not

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-24 Thread Jason Wang
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-24 Thread Jason Wang
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-24 Thread Halil Pasic
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-24 Thread Michael S. Tsirkin
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 > > > > > &

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-24 Thread Jason Wang
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 to make the guest linux use the DMA API, which in

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-23 Thread Michael S. Tsirkin
6 +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 gu

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-23 Thread Jason Wang
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 guest decides to turn itself into a protected one

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-23 Thread David Gibson
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 guest decides to turn itself into

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-23 Thread David Gibson
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-23 Thread Michael S. Tsirkin
ds 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 me

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-23 Thread Jason Wang
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 guest decides to turn itself into a protected one. This however makes no sense due to multiple reasons: * The device is not changed by the fact that the guest

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-21 Thread Christoph Hellwig
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-21 Thread Halil Pasic
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_PLATF

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-21 Thread Halil Pasic
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 de

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-21 Thread Halil Pasic
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-20 Thread Jason Wang
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-20 Thread Michael S. Tsirkin
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

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-20 Thread Michael S. Tsirkin
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 >

Re: [PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-20 Thread Michael S. Tsirkin
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

[PATCH 0/2] virtio: decouple protected guest RAM form VIRTIO_F_IOMMU_PLATFORM

2020-02-20 Thread Halil Pasic
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

Re: [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

2017-07-24 Thread Gerd Hoffmann
terlist of addresses to be exact) to the host. So, I think no, this isn't going to work with the current code. Should be possible to fix though. We need to define what "guest physical address" should be with VIRTIO_F_IOMMU_PLATFORM enabled (probably guest pci bus address) and add s

Re: [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

2017-07-21 Thread Michael S. Tsirkin
-legacy=on,iommu_platform=true,disable-modern=off,scsi=off > >>... > >> > >> Cc: Jordan Justen > >> Cc: Laszlo Ersek > >> Cc: Jason Wang > >> Cc: Michael S. Tsirkin > >> Contributed-under: TianoCore Contribution Agreement 1.0 >

[RFC PATCH kvmtool 11/15] virtio: set VIRTIO_F_IOMMU_PLATFORM when necessary

2017-04-07 Thread Jean-Philippe Brucker
Pass the VIRTIO_F_IOMMU_PLATFORM to tell the guest when a device is behind an IOMMU. Other feature bits in virtio do not depend on the device type and could be factored the same way. For instance our vring implementation always supports indirect descriptors (VIRTIO_RING_F_INDIRECT_DESC), so we

Re: VIRTIO_F_IOMMU_PLATFORM

2016-10-10 Thread Michael S. Tsirkin
> > > > Hi Michael, > > > > > > > > In commit 1a937693993f ("virtio: new feature to detect IOMMU device > > > > quirk"), > > > > you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe > > > > whether > > >

Re: VIRTIO_F_IOMMU_PLATFORM

2016-10-10 Thread Michael S. Tsirkin
irtio: new feature to detect IOMMU device > > > quirk"), > > > you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether > > > or not a given virtio device requires physical address or bus addresses. > > > > > > Is there a plan to get t

Re: VIRTIO_F_IOMMU_PLATFORM

2016-10-10 Thread Will Deacon
On Fri, Oct 07, 2016 at 07:24:34AM +0300, Michael S. Tsirkin wrote: > On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote: > > Hi Michael, > > > > In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"), > > you added a new fea

Re: VIRTIO_F_IOMMU_PLATFORM

2016-10-06 Thread Michael S. Tsirkin
On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote: > Hi Michael, > > In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"), > you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether > or not a given virtio device require

VIRTIO_F_IOMMU_PLATFORM

2016-09-27 Thread Will Deacon
Hi Michael, In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"), you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether or not a given virtio device requires physical address or bus addresses. Is there a plan to get this incorporated into