Re: [RFC 2/4] virtio: Override device's DMA OPS with virtio_direct_dma_ops selectively

[Michael S. Tsirkin]

On Sat, Jul 28, 2018 at 02:26:24PM +0530, Anshuman Khandual wrote:
> On 07/20/2018 09:29 AM, Anshuman Khandual wrote:
> > Now that virtio core always needs all virtio devices to have DMA OPS, we
> > need to make sure that the structure it points is the right one. In the
> > absence of VIRTIO_F_IOMMU_PLATFORM flag QEMU expects GPA from guest kernel.
> > In such case, virtio device must use default virtio_direct_dma_ops DMA OPS
> > structure which transforms scatter gather buffer addresses as GPA. This
> > DMA OPS override must happen as early as possible during virtio device
> > initializatin sequence before virtio core starts using given device's DMA
> > OPS callbacks for I/O transactions. This change detects device's IOMMU flag
> > and does the override in case the flag is cleared.
> > 
> > Signed-off-by: Anshuman Khandual 
> > ---
> >  drivers/virtio/virtio.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > index 7907ad3..6b13987 100644
> > --- a/drivers/virtio/virtio.c
> > +++ b/drivers/virtio/virtio.c
> > @@ -166,6 +166,8 @@ void virtio_add_status(struct virtio_device *dev, 
> > unsigned int status)
> >  }
> >  EXPORT_SYMBOL_GPL(virtio_add_status);
> > 
> > +const struct dma_map_ops virtio_direct_dma_ops;
> > +
> >  int virtio_finalize_features(struct virtio_device *dev)
> >  {
> > int ret = dev->config->finalize_features(dev);
> > @@ -174,6 +176,9 @@ int virtio_finalize_features(struct virtio_device *dev)
> > if (ret)
> > return ret;
> 
> 
> The previous patch removed the code block for XEN guests which forced
> the use of DMA API all the time irrespective of VIRTIO_F_IOMMU_PLATFORM
> flag on the device. Here is what I have removed with patch 2/4 which
> breaks the existing semantics on XEN guests.
> 
> -static bool vring_use_dma_api(struct virtio_device *vdev)
> -{
> - if (!virtio_has_iommu_quirk(vdev))
> - return true;
> -
> - /* Otherwise, we are left to guess. */
> - /*
> -  * In theory, it's possible to have a buggy QEMU-supposed
> -  * emulated Q35 IOMMU and Xen enabled at the same time.  On
> -  * such a configuration, virtio has never worked and will
> -  * not work without an even larger kludge.  Instead, enable
> -  * the DMA API if we're a Xen guest, which at least allows
> -  * all of the sensible Xen configurations to work correctly.
> -  */
> - if (xen_domain())
> - return true;
> -
> - return false;
> -}
> 
> XEN guests would not like override with virtio_direct_dma_ops in any
> case irrespective of the flag VIRTIO_F_IOMMU_PLATFORM. So the existing
> semantics can be preserved with something like this. It just assumes
> that dev->dma_ops is non-NULL and a valid one set by the architecture.
> If required we can add those tests here before skipping the override.
> 
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 7907ad3..6b13987 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -166,6 +166,8 @@ void virtio_add_status(struct virtio_device *dev, 
> unsigned int status)
>  }
>  EXPORT_SYMBOL_GPL(virtio_add_status);
> 
> +const struct dma_map_ops virtio_direct_dma_ops;
> +
>  int virtio_finalize_features(struct virtio_device *dev)
>  {
>   int ret = dev->config->finalize_features(dev);
> @@ -174,6 +176,9 @@ int virtio_finalize_features(struct virtio_device *dev)
>   if (ret)
>   return ret;
> +
> + if (xen_domain())
> + goto skip_override;
> +
> + if (virtio_has_iommu_quirk(dev))
> + set_dma_ops(dev->dev.parent, &virtio_direct_dma_ops);
> +
> + skip_override:
> +

I prefer normal if scoping as opposed to goto spaghetti pls.
Better yet move vring_use_dma_api here and use it.
Less of a chance something will break.

>   if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1))
>   return 0
> 
> Will incorporate these changes in the next version.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Call for Workshops Proposals - WorldCIST'19, La Toja Island, Spain

[Maria Lemos]

- CALL FOR WORKSHOPS PROPOSALS 
WorldCIST'19 - 7th World Conference on Information Systems and Technologies
  16th-19th of April 2019, La Toja Island, Galicia, Spain
   http://www.worldcist.org/ 

---


The Information Systems and Technologies research and industrial community is 
invited to submit proposals for the organization of Workshops at WorldCist'19 - 
7th World Conference on Information Systems and Technologies, to be held at La 
Toja Island, Galicia, Spain, 16 - 19 April 2019. WorldCist is a global forum 
for researchers and practitioners to present and discuss the most recent 
innovations, trends, results, experiences and concerns in the several 
perspectives of Information Systems and Technologies.


###
WORKSHOP FORMAT
###

Workshops should focus on a specific scientific subject on the scope of 
WorldCist'19 but not directly included on the main conference areas. Each 
workshop will be coordinated by an Organizing Committee composed of, at least, 
two researchers in the field, preferably from different institutions and 
different countries. The organizers should create an international Program 
Committee for the Workshop, with recognized researchers within the specific 
Workshop scientific area. Each workshop should have at least ten submissions 
and five accepted papers in order to be conducted at WorldCist'19.

The selection of Workshops will be performed by WorldCist'19 
Conference/Workshop Chairs. Workshops full and short papers will be published 
in the conference main proceedings in specific Workshop chapters published by 
Springer in a book of the AISC series. Proceedings will be submitted for 
indexation by ISI Thomson, SCOPUS, DBLP, EI-Compendex among several other 
scientific databases. Extended versions of best selected papers will be 
published in journals indexed by ISI/SCI, SCOPUS and DBLP. Detailed and 
up-to-date information may be found at WorldCist'19 website: 
http://www.worldcist.org/ 


#
WORKSHOP ORGANIZATION
#

The Organizing Committee of each Workshop will be responsible for:

- Producing and distributing the Workshop Call for Papers (CFP);
- Coordinating the review and selection process for the papers submitted to the 
Workshop, as Workshop chairs (on the paper submission system to be installed);
- Delivering the final versions of the papers accepted for the Workshop in 
accordance with the guidelines and deadlines defined by WorldCist'19 organizers;
- Coordinating and chairing the Workshop sessions at the conference.

WorldCist'19 organizers reserve the right to cancel any Workshop if deadlines 
are missed or if the number of registered attendees is too low to support the 
costs associated with the Workshop.



PROPOSAL CONTENT


Workshop proposals should contain the following information:

- Workshop title;
- Brief description of the specific scientific scope of the Workshop;
- List of topics of interest (max 15 topics);
- Reasons the Workshop should be held within WorldCist’19;
- Name, postal address, phone and email of all the members of the Workshop 
Organizing Committee;
- Preliminary proposal for the Workshop Program Committee (Names and 
affiliations).

Proposals should be submitted at 
https://easychair.org/conferences/?conf=worldcist-workshops2019 
 in PDF (in 
English), by September 10, 2018.


###
IMPORTANT DATES
###

- Deadline for Workshop proposals: September 10, 2018
- Notification of Workshop acceptance: September 20, 2018
- Workshop Final Information and Program Committee: October 10, 2018
- Deadline for paper submission: November 30, 2018
- Notification of paper acceptance: January 6, 2019
- Deadline for final versions and conference registration: January 20, 2019
- Conference dates: April 16-19, 2019


#
CHAIR
#

Luis Paulo Reis, AISTI, IEEE & University of Porto, Portugal


WorldCIST'19 Website: http://www.worldcist.org/ 


---
This email has been checked for viruses by AVG.
https://www.avg.com
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC 2/4] virtio: Override device's DMA OPS with virtio_direct_dma_ops selectively

[Anshuman Khandual]

On 07/20/2018 09:29 AM, Anshuman Khandual wrote:
> Now that virtio core always needs all virtio devices to have DMA OPS, we
> need to make sure that the structure it points is the right one. In the
> absence of VIRTIO_F_IOMMU_PLATFORM flag QEMU expects GPA from guest kernel.
> In such case, virtio device must use default virtio_direct_dma_ops DMA OPS
> structure which transforms scatter gather buffer addresses as GPA. This
> DMA OPS override must happen as early as possible during virtio device
> initializatin sequence before virtio core starts using given device's DMA
> OPS callbacks for I/O transactions. This change detects device's IOMMU flag
> and does the override in case the flag is cleared.
> 
> Signed-off-by: Anshuman Khandual 
> ---
>  drivers/virtio/virtio.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 7907ad3..6b13987 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -166,6 +166,8 @@ void virtio_add_status(struct virtio_device *dev, 
> unsigned int status)
>  }
>  EXPORT_SYMBOL_GPL(virtio_add_status);
> 
> +const struct dma_map_ops virtio_direct_dma_ops;
> +
>  int virtio_finalize_features(struct virtio_device *dev)
>  {
>   int ret = dev->config->finalize_features(dev);
> @@ -174,6 +176,9 @@ int virtio_finalize_features(struct virtio_device *dev)
>   if (ret)
>   return ret;


The previous patch removed the code block for XEN guests which forced
the use of DMA API all the time irrespective of VIRTIO_F_IOMMU_PLATFORM
flag on the device. Here is what I have removed with patch 2/4 which
breaks the existing semantics on XEN guests.

-static bool vring_use_dma_api(struct virtio_device *vdev)
-{
-   if (!virtio_has_iommu_quirk(vdev))
-   return true;
-
-   /* Otherwise, we are left to guess. */
-   /*
-* In theory, it's possible to have a buggy QEMU-supposed
-* emulated Q35 IOMMU and Xen enabled at the same time.  On
-* such a configuration, virtio has never worked and will
-* not work without an even larger kludge.  Instead, enable
-* the DMA API if we're a Xen guest, which at least allows
-* all of the sensible Xen configurations to work correctly.
-*/
-   if (xen_domain())
-   return true;
-
-   return false;
-}

XEN guests would not like override with virtio_direct_dma_ops in any
case irrespective of the flag VIRTIO_F_IOMMU_PLATFORM. So the existing
semantics can be preserved with something like this. It just assumes
that dev->dma_ops is non-NULL and a valid one set by the architecture.
If required we can add those tests here before skipping the override.

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 7907ad3..6b13987 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -166,6 +166,8 @@ void virtio_add_status(struct virtio_device *dev, unsigned 
int status)
 }
 EXPORT_SYMBOL_GPL(virtio_add_status);

+const struct dma_map_ops virtio_direct_dma_ops;
+
 int virtio_finalize_features(struct virtio_device *dev)
 {
int ret = dev->config->finalize_features(dev);
@@ -174,6 +176,9 @@ int virtio_finalize_features(struct virtio_device *dev)
if (ret)
return ret;
+
+   if (xen_domain())
+   goto skip_override;
+
+   if (virtio_has_iommu_quirk(dev))
+   set_dma_ops(dev->dev.parent, &virtio_direct_dma_ops);
+
+ skip_override:
+
if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1))
return 0

Will incorporate these changes in the next version.

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC 0/4] Virtio uses DMA API for all devices

[Anshuman Khandual]

On 07/27/2018 05:01 PM, Michael S. Tsirkin wrote:
> On Wed, Jul 25, 2018 at 08:56:23AM +0530, Anshuman Khandual wrote:
>> Results with and without the patches are similar.
> 
> Thanks! And another thing to try is virtio-net with
> a fast NIC backend (40G and up). Unfortunately
> at this point loopback tests stress the host
> scheduler too much.
> 

Sure. Will look around for a 40G NIC system. BTW I have been testing
virtio-net with a TAP device as back end.

ip tuntap add dev tap0 mode tap user $(whoami)
ip link set tap0 master virbr0
ip link set dev virbr0 up
ip link set dev tap0 up

which is exported into the guest as follows

-device virtio-net,netdev=network0,mac=52:55:00:d1:55:01 \
-netdev tap,id=network0,ifname=tap0,script=no,downscript=no \

But I have not run any network benchmarks on it though.

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization