[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Towards an ivshmem 2.0?
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] Towards an ivshmem 2.0? |
Date: |
Mon, 30 Jan 2017 09:05:40 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2017-01-30 09:02, Markus Armbruster wrote:
> 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.
>
> 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
- Re: [Qemu-devel] Towards an ivshmem 2.0?, (continued)
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Stefan Hajnoczi, 2017/01/16
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/23
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/25
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/27
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/29
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Marc-André Lureau, 2017/01/29
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/29
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/30
- Re: [Qemu-devel] Towards an ivshmem 2.0?,
Jan Kiszka <=
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Wang, Wei W, 2017/01/30
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/30
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/30
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Markus Armbruster, 2017/01/30
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/30