Call for Workshops Proposals - CISTI'2021, Chaves, Portugal

[Maria Lemos]

* Articles indexed by Scopus, WoS, Inspec, Google Scholar, etc.

* Conference with a Google Scholar H5-Index = 17

* Conference with a SCImago H-Index = 13



--

Call for Workshops Proposals

CISTI'2021 - 16th Iberian Conference on Information Systems and Technologies

23 - 26 June 2021, Chaves, Portugal

http://cisti.eu/ 





Workshop Format

The Information Systems and Technologies research and industrial community is 
invited to submit proposals of Workshops for CISTI 2021 – 16th Iberian 
Conference on Information Systems and Technologies to be held at Chaves, 
Portugal, June 23–26, 2021. Two types of Workshops may be proposed: Regular 
Workshops and Project Workshops.

Regular Workshops should focus on a specific scientific subject on the scope of 
CISTI 2021 but not directly included on the main conference areas. Each regular 
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 10 submissions and 
5 accepted papers in order to be conducted at CISTI.

Project Workshops are intended to promote the dissemination and facilitate the 
future exploitation of EU Latin-American and national project results such as 
EU/FP7, EU/Horizon2020, CSIC, FCT, QREN, Portugal 2020, Fund. Gulbenkian, 
CYTED, CAPES, CNPq, FINEP and other Projects/funding sources. The results to be 
disseminated may be preliminary project results (for unfinished projects) or 
the project final results (for already finished projects). Each project 
workshop should be directly related to a Project funded in a competitive manner 
by a National/International Science Organization. The Workshop should be 
coordinated by an Organizing Committee composed by at least two researchers 
including the Principal Investigator of the project. Each Workshop will have 1 
article offered for 10 articles with paid registration, 2 articles offered for 
20 articles with paid registration, and 3 articles offered for 40 articles with 
paid registration. The selection of Workshops will be performed by CISTI 2021 
Conference Chairs. Workshops full papers will be published in the conference 
main proceedings in specific Workshop chapters. Proceedings will be submitted 
for indexation by ISI, SCOPUS, EI-Conpendex, INSPEC and Google Scholar. 
Detailed and up-to-date information may be found at CISTI 2021 website: 
http://www.cisti.eu/ .



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 installed for all 
the Workshops);
* Delivering the final versions of the papers accepted for the Workshop in 
accordance with the guidelines and deadlines defined by CISTI 2021 organizers;
* Coordinating and chairing the Workshop sessions at the conference.


CISTI 2021 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 Contents

Regular 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 CISTI’2021;
* Name, postal address, phone and email of all the members of the Workshop 
Organizing Committee;
* Proposal for the Workshop Program Committee (Names and affiliations).


Project Workshop proposals should contain the following information:

* Workshop title;
* Project Title, Reference, Principal Investigator, Funding Organization, Total 
Funding, Consortium, Abstract and Objectives;
* Reasons the Workshop should be held within CISTI’2021;
* Name, postal address, phone and email of all the members of the Workshop 
Organizing Committee.


Proposals should be submitted electronically (in Word or compatible format) at 
https://easychair.org/conferences/?conf=cisti2021workshops 
, in English, 
Portuguese and/or Spanish, by November 1, 2020.



Important Dates

* Deadline for Workshop proposals: November 1, 2020
* Notification of Workshop acceptance: November 8, 2020
* Deadline for paper submission: February 28, 2021
* Notification of paper acceptance: March 28, 2021
* Deadline for final versions and conference 

Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory

[Sam Ravnborg]

Hi Thomas.

On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
> 
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for the type of memory and call the rsp
> fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
> internally by DRM's fbdev helper.
> 
> For drivers that employ a shadow buffer, fbdev's blit function retrieves
> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
> interfaces to access the buffer.
> 
> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
> I/O memory and avoid a HW exception. With the introduction of struct
> dma_buf_map, this is not required any longer. The patch removes the rsp
> code from both, bochs and fbdev.
> 
> v5:
>   * implement fb_read/fb_write internally (Daniel, Sam)
> v4:
>   * move dma_buf_map changes into separate patch (Daniel)
>   * TODO list: comment on fbdev updates (Daniel)
> 
> Signed-off-by: Thomas Zimmermann 
> Tested-by: Sam Ravnborg 
Reviewed-by: Sam Ravnborg 

But see a few comments below on naming for you to consider.

Sam

> ---
>  Documentation/gpu/todo.rst|  19 ++-
>  drivers/gpu/drm/bochs/bochs_kms.c |   1 -
>  drivers/gpu/drm/drm_fb_helper.c   | 227 --
>  include/drm/drm_mode_config.h |  12 --
>  4 files changed, 230 insertions(+), 29 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7e6fc3c04add..638b7f704339 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>  
>  
>  Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
> -expects the framebuffer in system memory (or system-like memory).
> +atomic modesetting and GEM vmap support. Historically, generic fbdev 
> emulation
> +expected the framebuffer in system memory or system-like memory. By employing
> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
> +as well.
>  
>  Contact: Maintainer of the driver you plan to convert
>  
>  Level: Intermediate
>  
> +Reimplement functions in drm_fbdev_fb_ops without fbdev
> +---
> +
> +A number of callback functions in drm_fbdev_fb_ops could benefit from
> +being rewritten without dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
>  drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
>  -
>  
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 13d0d04c4457..853081d186d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
>   bochs->dev->mode_config.preferred_depth = 24;
>   bochs->dev->mode_config.prefer_shadow = 0;
>   bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> - bochs->dev->mode_config.fbdev_use_iomem = true;
>   bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>  
>   bochs->dev->mode_config.funcs = _mode_funcs;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 6212cd7cde1d..1d3180841778 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct 
> work_struct *work)
>  }
>  
>  static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
> -   struct drm_clip_rect *clip)
> +   struct drm_clip_rect *clip,
> +   struct dma_buf_map *dst)
>  {
>   struct drm_framebuffer *fb = fb_helper->fb;
>   unsigned int cpp = fb->format->cpp[0];
>   size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
>   void *src = fb_helper->fbdev->screen_buffer + offset;
> - void *dst = fb_helper->buffer->map.vaddr + offset;
>   size_t len = (clip->x2 - clip->x1) * cpp;
>   unsigned int y;
>  
> - for (y = clip->y1; y < clip->y2; y++) {
> - if (!fb_helper->dev->mode_config.fbdev_use_iomem)
> - memcpy(dst, src, len);
> - else
> - memcpy_toio((void __iomem *)dst, src, len);
> + dma_buf_map_incr(dst, offset); /* go to first pixel within clip rect */
>  
> + for (y = clip->y1; y < clip->y2; y++) {
> + 

Re: [PATCH] virtio_ring: use DMA when memory encryption is active

[Sebastian Hofmann]

> Michael S. Tsirkin  hat am 23.10.2020 17:49 geschrieben:
> 
>  
> On Fri, Oct 23, 2020 at 11:00:54AM +0200, Sebastian Hofmann wrote:
> > > Michael S. Tsirkin  hat am 22.10.2020 13:39 geschrieben:
> > > 
> > >  
> > > On Wed, Oct 21, 2020 at 05:14:25PM +0200, Sebastian Hofmann wrote:
> > > > virtio_ring does not work with active memory encryption because the 
> > > > host cannot read it. Fix this by enforcing the use of DMA which uses 
> > > > shared (unencrypted) memory pages.
> > > > 
> > > > Signed-off-by: Sebastian Hofmann 
> > > 
> > > 
> > > Sorry, no.
> > > host which can not access all of driver memory must set 
> > > VIRTIO_F_ACCESS_PLATFORM.
> > > 
> > > Not worth it to work around broken hosts.
> > > 
> > > Xen is an exception we carry around since it predates the
> > > introduction of VIRTIO_F_ACCESS_PLATFORM.
> > > 
> > > 
> > 
> > Thanks for pointing out VIRTIO_F_ACCESS_PLATFORM which I was not aware of. 
> > Maybe that patch was a bit naïve.
> > 
> > Basically I'm looking for a way to use vsock with qemu on AMD SEV. When I 
> > try to use IOMMU for vsock I get an EOPNOTSUPP out of 
> > vhost_vsock_set_features.
> > 
> > Is there a reason why vhost_vsock_set_features doesn't use 
> > vhost_init_device_iotlb as done in the net device? Because that would have 
> > been my next attempt.
> > I would appreciate a short comment on this idea or a recommendation for 
> > another solution that is better than the patch below.
> 
> Not sure I understand the problem. Are you using qemu? If so just add
> iommu_platform=on and you are done.
> 

That would be nice, but once I set iommu_platform=on (using Linux 5.4 as host 
and guest, qemu 5.1.0):
qemu-system-x86_64 -enable-kvm -cpu host -machine q35 -nographic 
-no-user-config -nodefaults -serial stdio \
-global virtio-mmio.force-legacy=off \
-device vhost-vsock-pci,guest-cid=3,disable-legacy=on,iommu_platform=on \
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 \
-machine dump-guest-core=off,memory-encryption=sev0 \
[some more arguments...]

...
qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)
qemu-system-x86_64: Error starting vhost: 95
...

Therefore my question if it would be enough to use vhost_init_device_iotlb 
instead of returning EOPNOTSUPP in vhost_vsock_set_features when 
VIRTIO_F_ACCESS_PLATFORM is passed. Equivalent to what I see in 
vhost_net_set_features.
Or maybe I'm missing something important?

> > > > ---
> > > >  drivers/virtio/virtio_ring.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > > index becc77697960..8c68c475ec21 100644
> > > > --- a/drivers/virtio/virtio_ring.c
> > > > +++ b/drivers/virtio/virtio_ring.c
> > > > @@ -12,6 +12,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  
> > > >  #ifdef DEBUG
> > > >  /* For development, we want to crash whenever the ring is screwed. */
> > > > @@ -255,6 +256,10 @@ static bool vring_use_dma_api(struct virtio_device 
> > > > *vdev)
> > > > if (xen_domain())
> > > > return true;
> > > >  
> > > > +   /* Memory encryption requires DMA */
> > > > +   if (mem_encrypt_active())
> > > > +   return true;
> > > > +
> > > > return false;
> > > >  }
> > > >  
> > > > -- 
> > > > 2.25.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization