Re: [Qemu-devel] Towards an ivshmem 2.0?

[Jan Kiszka <jan.kiszka@web.de>]

On 2017-01-30 09:02, Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@web.de> writes:
> 
>> On 2017-01-29 15:00, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Sun, Jan 29, 2017 at 12:44 PM Jan Kiszka <jan.kiszka@web.de
>>> <mailto:jan.kiszka@web.de>> wrote:
>>>
>>>     >> Of course, I'm careful with investing much time into expanding the
>>>     >> existing, for Jailhouse possibly sufficient design if there no real
>>>     >> interest in continuing the ivshmem support in QEMU - because of
>>>     >> vhost-pci or other reasons. But if that interest exists, it would be
>>>     >> beneficial for us to have QEMU supporting a compatible version
>>>     and using
>>>     >> the same guest drivers. Then I would start looking into concrete
>>>     patches
>>>     >> for it as well.
>>>     >
>>>     > Interest is difficult for me to gauge, not least because alternatives
>>>     > are still being worked on.
>>>
>>>     I'm considering to suggest this as GSoC project now.
>>>
>>>
>>> It's better for a student and for the community if the work get accepted
>>> in the end.
> 
> Yes.
> 
>>> So, I think that could be an intersting GSoC (implementing your ivshmem
>>> 2 proposal). However, if the qemu community isn't ready to accept a new
>>> ivshmem, and would rather have vhost-pci based solution, I would suggest
>>> a different project (hopefully Wei Wang can help define it and mentor):
>>> work on a vhost-pci using dedicated shared PCI BARs (and kernel support
>>> to avoid extra copy - if I understand the extra copy situation correctly).
>>
>> It's still open if vhost-pci can replace ivshmem (not to speak of being
>> desirable for Jailhouse - I'm still studying). In that light, having
>> both implementations available to do real comparisons is valuable IMHO.
> 
> Yes, but is it appropriate for GSoC?
> 
>> That said, we will play with open cards, explain the student the
>> situation and let her/him decide knowingly.
> 
> Both the student and the QEMU project need to consider the situation
> carefully.
> 
>> Jan
>>
>> PS: We have a mixed history /wrt actually merging student projects.
> 
> Yes, but having screwed up is no license to screw up some more :)
> 

After having received multiple feedbacks in this direction, I will drop
that proposal from our list. So, don't worry. ;)

Jan