On 06/18/2014 05:01 PM, Andreas Färber wrote:
late onto this thread: SUSE Security team has just recently
done a thorough review of QEMU ivshmem code because a customer has
requested this be supported in SLES12. Multiple security-related
patches were submitted by Stefan Hajnoczi and Sebastian Kra
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
On 06/18/2014 12:51 PM, Stefan Hajnoczi wrote:
Actually, you can avoid this memory copy using frameworks like DPDK.
I guess it's careful to allocate all packets in the mmapped BAR?
Yes.
That's fine if you can modify applications but doesn't work for
unmodified applications using regular n
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 insid
Stefan Hajnoczi writes:
> 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
Hello,
Just to add my two bits.
I will fully support getting all the necessary parts of ivshmem into tree
where appropriate, both qemu and a driver in Linux. I understand those
concerns.
I do not have the time to fully maintain ivshmem at the level needed, but I
will help as much as I can.
Sor
On Wed, Jun 18, 2014 at 10:57 PM, David Marchand
wrote:
> 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
Il 18/06/2014 16:57, David Marchand ha scritto:
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
accessin
-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 a
On Tue, Jun 17, 2014 at 11:03:32AM +0200, David Marchand wrote:
> 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.
> >
> >v
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
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 yourself to maintainers is don
On Fri, Jun 13, 2014 at 10:10 PM, Paolo Bonzini 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,
(resending, this email is missing at
http://lists.nongnu.org/archive/html/qemu-devel/2014-06/index.html)
> 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
Hello,
On 06/13/2014 11:26 AM, Vincent JARDIN wrote:
ivhsmem does not require hugetlbfs. It is optional.
> * it doesn't require ivshmem (it does require shared memory, which
> will also be added to 2.1)
Right, hugetlbfs is not required. A posix shared memory or tmpfs
can be used instead. Fo
Nahanni's poor current development coupled with virtIO's promising
expansion was what encouraged us to explore virtIO-serial [1] for
inter-virtual machine communication. Though virtIO-serial as it is
isn't helpful for inter-VM communication, some work is needed for this
purpose and this is exactly
Nahanni's poor current development coupled with virtIO's promising
expansion was what encouraged us to explore virtIO-serial [1] for
inter-virtual machine communication. Though virtIO-serial as it is isn't
helpful for inter-VM communication, some work is needed for this purpose
and this is exactly
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
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 disable
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
(+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
Some dropped quoted text restored.
Vincent JARDIN 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
22 matches
Mail list logo
