[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.
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 :)
- 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 <=
- Re: [Qemu-devel] Towards an ivshmem 2.0?, Jan Kiszka, 2017/01/30
- 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