similar to: Regarding Ivshmem support

Hello, friends. I encounter a problem when i use ivshmem with my guest, my ivshmem server is not start, and output a error : Example code, do not use in production ,cannot bind. Detail distribution: Today, I know ivshmem from a topic "QEMU version 2.10.93 User Documentation", Ivshmem: it can create a shared memory that guest device use, so we can use this memory to do something

Il 13/06/2014 15:41, Vincent JARDIN ha scritto: >> Fine, however Red Hat would also need a way to test ivshmem code, with >> proper quality assurance (that also benefits upstream, of course). With >> ivshmem this is not possible without the out-of-tree packages. > > You did not reply to my question: how to get the list of things that > are/will be disabled by Redhat? I

Il 13/06/2014 15:41, Vincent JARDIN ha scritto: >> Fine, however Red Hat would also need a way to test ivshmem code, with >> proper quality assurance (that also benefits upstream, of course). With >> ivshmem this is not possible without the out-of-tree packages. > > You did not reply to my question: how to get the list of things that > are/will be disabled by Redhat? I

Il 13/06/2014 11:26, Vincent JARDIN ha scritto: >> Markus especially referred to parts *outside* QEMU: the server, the >> uio driver, etc. These out-of-tree, non-packaged parts of ivshmem >> are one of the reasons why Red Hat has disabled ivshmem in RHEL7. > > You made the right choices, these out-of-tree packages are not required. > You can use QEMU's ivshmem

Il 13/06/2014 11:26, Vincent JARDIN ha scritto: >> Markus especially referred to parts *outside* QEMU: the server, the >> uio driver, etc. These out-of-tree, non-packaged parts of ivshmem >> are one of the reasons why Red Hat has disabled ivshmem in RHEL7. > > You made the right choices, these out-of-tree packages are not required. > You can use QEMU's ivshmem

Hello all, On 06/17/2014 04:54 AM, Stefan Hajnoczi wrote: > ivshmem has a performance disadvantage for guest-to-host > communication. Since the shared memory is exposed as PCI BARs, the > guest has to memcpy into the shared memory. > > vhost-user can access guest memory directly and avoid the copy inside the guest. Actually, you can avoid this memory copy using frameworks like

Hello all, On 06/17/2014 04:54 AM, Stefan Hajnoczi wrote: > ivshmem has a performance disadvantage for guest-to-host > communication. Since the shared memory is exposed as PCI BARs, the > guest has to memcpy into the shared memory. > > vhost-user can access guest memory directly and avoid the copy inside the guest. Actually, you can avoid this memory copy using frameworks like

Henning Schild <henning.schild at siemens.com> writes: > On Thu, 12 Jun 2014 08:48:04 +0200 > Markus Armbruster <armbru at redhat.com> wrote: > >> Vincent JARDIN <vincent.jardin at 6wind.com> writes: >> >> > On 10/06/2014 18:48, Henning Schild wrote:> Hi, >> >> In a first prototype i implemented a ivshmem[2] device for the >>

Henning Schild <henning.schild at siemens.com> writes: > On Thu, 12 Jun 2014 08:48:04 +0200 > Markus Armbruster <armbru at redhat.com> wrote: > >> Vincent JARDIN <vincent.jardin at 6wind.com> writes: >> >> > On 10/06/2014 18:48, Henning Schild wrote:> Hi, >> >> In a first prototype i implemented a ivshmem[2] device for the >>

On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote: > Il 17/06/2014 11:03, David Marchand ha scritto: > >>Unless someone steps up and maintains ivshmem, I think it should be > >>deprecated and dropped from QEMU. > > > >Then I can maintain ivshmem for QEMU. > >If this is ok, I will send a patch for MAINTAINERS file. > > Typically, adding

On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote: > Il 17/06/2014 11:03, David Marchand ha scritto: > >>Unless someone steps up and maintains ivshmem, I think it should be > >>deprecated and dropped from QEMU. > > > >Then I can maintain ivshmem for QEMU. > >If this is ok, I will send a patch for MAINTAINERS file. > > Typically, adding

Hi, I am trying to create a VM with the IVSHMEM feature, and I specify the device using qemu command line argument in my XML by using the pass through tag as follows: <qemu:commandline> <qemu:arg value='-device ivshmem,size=2048M,shm=fd:/mnt/huge/map_1:0x0:0x40000000:/dev/zero:0x0:0x3fffc000:/var/run/.ivshmem_metadata_config_2:0x0:0x4000'/>

Hello Stefan, On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote: > One more thing to add to the list: > > static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) > > The "flags" argument should be "size". Size should be checked before > accessing buf. You are welcome to send a fix and I will review it. > > Please also see the bug fixes in

Hello Stefan, On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote: > One more thing to add to the list: > > static void ivshmem_read(void *opaque, const uint8_t * buf, int flags) > > The "flags" argument should be "size". Size should be checked before > accessing buf. You are welcome to send a fix and I will review it. > > Please also see the bug fixes in

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

> Fine, however Red Hat would also need a way to test ivshmem code, with > proper quality assurance (that also benefits upstream, of course). With > ivshmem this is not possible without the out-of-tree packages. You did not reply to my question: how to get the list of things that are/will be disabled by Redhat? About Redhat's QA, I do not care. About Qemu's QA, I do care ;) I

(+merging with Paolo's email because of overlaps) >> see inline (I am not on all mailing list, please, keep the cc list). >> >>> 1. ivshmem code needs work, but has no maintainer >> See David's contributions: >> http://patchwork.ozlabs.org/patch/358750/ > > We're grateful for David's patch for qemu-char.c, but this isn't ivshmem >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 18.06.2014 12:48, schrieb Stefan Hajnoczi: > On Tue, Jun 17, 2014 at 11:44:11AM +0200, Paolo Bonzini wrote: >> Il 17/06/2014 11:03, David Marchand ha scritto: >>>> Unless someone steps up and maintains ivshmem, I think it >>>> should be deprecated and dropped from QEMU. >>> >>> Then I can maintain

On Fri, Jun 13, 2014 at 10:10 PM, Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 13/06/2014 15:41, Vincent JARDIN ha scritto: >> I do repeat this use case that you had removed because vhost-user does >> not solve it yet: >> >>>> - ivshmem -> framework to be generic to have shared memory for many >>>> use cases (HPC, in-memory-database, a