Re: [PATCH v2] Shared memory device with interrupt support

[Avi Kivity <avi@redhat.com>]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>> I'd strongly recommend working these patches on qemu-devel and 
>>> lkml.  I suspect Avi may disagree with me, but in order for this to 
>>> be eventually merged in either place, you're going to have 
>>> additional requirements put on you.
>>
>> I don't disagree with the fact that there will be additional 
>> requirements, but I might disagree with some of those additional 
>> requirements themselves.
>
> It actually works out better than I think you expect it to...

Can you explain why?  You haven't addressed my concerns the last time 
around.

>
> We can't use mmap() directly.  With the new RAM allocation scheme, I 
> think it's pretty reasonable to now allow portions of ram to come from 
> files that get mmap() (sort of like -mem-path).
>
> This RAM area could be setup as a BAR.

That's what Cam's patch does, and what you objected to.

>
>>   In particular I think your proposal was unimplementable; I would 
>> like to see how how you can address my concerns.
>
> I don't remember what my proposal was to be perfectly honest :-)  I 
> think I suggested registering a guest allocated portion of memory as a 
> sharable region via virtio?  

Yes.

> Why is that unimplementable?

Bad choice of words - it's implementable, just not very usable.  You 
can't share 1GB in a 256MB guest, will fragment host vmas, no guarantee 
the guest can actually allocate all that memory, doesn't work with large 
pages, what happens on freeing, etc.

>> I don't think bulk memory sharing and the current transactional 
>> virtio mechanisms are a good fit for each other; but if we were to 
>> add a BAR-like capability to virtio that would address the 
>> compatibility requirement (though it might be difficult to implement 
>> on s390 with its requirement on contiguous host virtual address space).
>
> It doesn't necessarily have to be virtio if that's not what makes sense.

The problem is not virtio, it's the transient scatter gather dma model 
that virtio supports.  If virtio were to support BARs like Christian's 
patch proposes, then it could be easily done with virtio.

Maybe we should call it something else though to avoid confusion.

>
> The QEMU bits and the device model bits are actually relatively 
> simple.  The part that I think needs more deep thought is the 
> guest-visible interface.
>
> A char device is probably not the best interface.  I think you want 
> something like tmpfs/hugetlbfs.  

Yes those are so wonderful to work with.

> Another question is whether you want a guest to be able to share a 
> portion of it's memory with another guest or have everything setup by 
> the host.
>

I think we want host setup.  That way you have symmetry among the guests.

> If everything is setup by the host, hot plug is important.

It is.

-- 
error compiling committee.c: too many arguments to function