[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [Qemu-devel] Towards an ivshmem 2.0?
Date: Mon, 30 Jan 2017 09:02:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Jan Kiszka <address@hidden> writes:

> On 2017-01-29 15:00, Marc-André Lureau wrote:
>> Hi
>> On Sun, Jan 29, 2017 at 12:44 PM Jan Kiszka <address@hidden
>> <mailto:address@hidden>> 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.


>> 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

> 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 :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]