search for: virtio_f_ring_shmem_addr

...on is that we'd like to keep the hypervisor as small as possible. I wouldn't exclude such an approach categorically, but we have to weigh the costs (lines of code, additional hypervisor interface) carefully against the gain (existing specifications and guest driver infrastructure). Back to VIRTIO_F_RING_SHMEM_ADDR (which you once brought up in an MCA working group discussion): What speaks against introducing an alternative encoding of addresses inside virtio data structures? The idea of this flag was to replace guest-physical addresses with offsets into a shared memory region associated with or part of a vir...

...on is that we'd like to keep the hypervisor as small as possible. I wouldn't exclude such an approach categorically, but we have to weigh the costs (lines of code, additional hypervisor interface) carefully against the gain (existing specifications and guest driver infrastructure). Back to VIRTIO_F_RING_SHMEM_ADDR (which you once brought up in an MCA working group discussion): What speaks against introducing an alternative encoding of addresses inside virtio data structures? The idea of this flag was to replace guest-physical addresses with offsets into a shared memory region associated with or part of a vir...

...onsole on top of ivshmem - see how i can get a virtio console to work between guests on shared memory Is anyone already using something like that? I guess zero-copy virtio devices in Xen would be a similar case. I read a suggestion from may 2010 to introduce a virtio feature bit for shared memory (VIRTIO_F_RING_SHMEM_ADDR). But that did not make it into the virtio-spec. regards, Henning [1] jailhouse https://github.com/siemens/jailhouse [2] ivshmem https://gitorious.org/nahanni

...onsole on top of ivshmem - see how i can get a virtio console to work between guests on shared memory Is anyone already using something like that? I guess zero-copy virtio devices in Xen would be a similar case. I read a suggestion from may 2010 to introduce a virtio feature bit for shared memory (VIRTIO_F_RING_SHMEM_ADDR). But that did not make it into the virtio-spec. regards, Henning [1] jailhouse https://github.com/siemens/jailhouse [2] ivshmem https://gitorious.org/nahanni

...r interface) carefully against the gain (existing > specifications and guest driver infrastructure). Reasonable, but I think you'll find it is about the minimal implementation in practice. Unfortunately, I don't have time during the next 6 months to implement it myself :( > Back to VIRTIO_F_RING_SHMEM_ADDR (which you once brought up in an MCA > working group discussion): What speaks against introducing an > alternative encoding of addresses inside virtio data structures? The > idea of this flag was to replace guest-physical addresses with offsets > into a shared memory region associated w...

...e gain (existing >> specifications and guest driver infrastructure). > > Reasonable, but I think you'll find it is about the minimal > implementation in practice. Unfortunately, I don't have time during the > next 6 months to implement it myself :( > >> Back to VIRTIO_F_RING_SHMEM_ADDR (which you once brought up in an MCA >> working group discussion): What speaks against introducing an >> alternative encoding of addresses inside virtio data structures? The >> idea of this flag was to replace guest-physical addresses with offsets >> into a shared memory reg...

...e gain (existing >> specifications and guest driver infrastructure). > > Reasonable, but I think you'll find it is about the minimal > implementation in practice. Unfortunately, I don't have time during the > next 6 months to implement it myself :( > >> Back to VIRTIO_F_RING_SHMEM_ADDR (which you once brought up in an MCA >> working group discussion): What speaks against introducing an >> alternative encoding of addresses inside virtio data structures? The >> idea of this flag was to replace guest-physical addresses with offsets >> into a shared memory reg...

...ls of IPC: - vhost-user -> networking use case specific - ivshmem -> framework to be generic to have shared memory for many use cases (HPC, in-memory-database, a network too like memnic). Later one, some news services will be needed for shared memory. virtio will come in picture (see VIRTIO_F_RING_SHMEM_ADDR's threads). Currently, ivhsmem is the only "stable" option since there remains many unsolved issues with virtio and shared memory. > * it doesn't require hugetlbfs (which only enabled shared memory by > chance in older QEMU releases, that was never documented) ivhsmem...

Some dropped quoted text restored. Vincent JARDIN <vincent.jardin at 6wind.com> writes: > Markus, > > see inline (I am not on all mailing list, please, keep the cc list). > >> Sure! The reasons for my dislike range from practical to >> philosophical. >> >> My practical concerns include: >> >> 1. ivshmem code needs work, but has no maintainer

Some dropped quoted text restored. Vincent JARDIN <vincent.jardin at 6wind.com> writes: > Markus, > > see inline (I am not on all mailing list, please, keep the cc list). > >> Sure! The reasons for my dislike range from practical to >> philosophical. >> >> My practical concerns include: >> >> 1. ivshmem code needs work, but has no maintainer