Problem fixed in qemu commit 3fd74b84.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1333688
Title:
vhost-user: VHOST_USER_SET_MEM_TABLE doe
user applicaton can call
mmap() multiple times with the same FD but with different offset
(user needs to take care for offset page alignment)
Signed-off-by: Damjan Marion
---
docs/specs/vhost-user.txt | 7 ---
exec.c| 7 +++
hw/virtio/vhost-user.c| 23
On 26 Jun 2014, at 13:37, Michael S. Tsirkin wrote:
> On Thu, Jun 26, 2014 at 11:35:13AM +0000, Damjan Marion (damarion) wrote:
>>
>> On 26 Jun 2014, at 13:30, Michael S. Tsirkin wrote:
>>
>>> On Thu, Jun 26, 2014 at 12:22:59PM +0200, Damjan Marion wrote:
>&g
On 26 Jun 2014, at 13:30, Michael S. Tsirkin wrote:
> On Thu, Jun 26, 2014 at 12:22:59PM +0200, Damjan Marion wrote:
>> Old code was affected by memory gaps which
>> resulted in buffer pointers pointing to
>> address outside of the mapped regions.
>>
>
Old code was affected by memory gaps which
resulted in buffer pointers pointing to
address outside of the mapped regions.
Signed-off-by: Damjan Marion
---
docs/specs/vhost-user.txt | 7 ---
exec.c| 7 +++
hw/virtio/vhost-user.c| 23
On 26 Jun 2014, at 10:01, Michael S. Tsirkin wrote:
> On Thu, Jun 26, 2014 at 09:55:03AM +0200, Damjan Marion wrote:
>> Old code was affected by memory gaps which
>> resulted in buffer pointers pointing to
>> address outside of the mapped regions.
>>
>
On 26 Jun 2014, at 09:56, Michael S. Tsirkin wrote:
> On Thu, Jun 26, 2014 at 07:44:24AM +0000, Damjan Marion (damarion) wrote:
>>
>> On 26 Jun 2014, at 09:13, Michael S. Tsirkin wrote:
>>
>>> On Wed, Jun 25, 2014 at 09:52:09PM +, Damjan Marion (damarion) wr
Old code was affected by memory gaps which
resulted in buffer pointers pointing to
address outside of the mapped regions.
Signed-off-by: Damjan Marion
---
docs/specs/vhost-user.txt | 7 ---
exec.c| 7 +++
hw/virtio/vhost-user.c| 22
On 26 Jun 2014, at 09:13, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 09:52:09PM +0000, Damjan Marion (damarion) wrote:
>>
>> On 25 Jun 2014, at 18:44, Paolo Bonzini wrote:
>>
>>>> nregions: 4
>>>> region:
>>>>
On 25 Jun 2014, at 18:44, Paolo Bonzini wrote:
>> nregions: 4
>> region:
>> gpa = 0x1
>> size = 3221225472
>> ua = 0x2aab6ac0
>
> High memory, above 3 gigabytes.
>
>> region:
>> gpa = 0xFFFC
>> size = 262144
>> ua = 0x7fc13d20
>
> This is the
On 25 Jun 2014, at 20:18, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 09:13:36PM +0300, Nikolay Nikolaev wrote:
>> On Wed, Jun 25, 2014 at 9:07 PM, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 07:56:46PM +0300, Nikolay Nikolaev wrote:
On Wed, Jun 25, 2014 at 7:44 PM, Paolo
On 25 Jun 2014, at 17:50, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 03:46:04PM +0000, Damjan Marion (damarion) wrote:
>>
>> On 25 Jun 2014, at 17:29, Michael S. Tsirkin wrote:
>>
>>> On Wed, Jun 25, 2014 at 02:57:52PM +, Damjan Marion (damarion) wr
On 25 Jun 2014, at 17:29, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 02:57:52PM +0000, Damjan Marion (damarion) wrote:
>>
>> On 25 Jun 2014, at 16:27, Michael S. Tsirkin wrote:
>>
>>> On Wed, Jun 25, 2014 at 02:20:56PM +, Damjan Marion (damarion) wr
On 25 Jun 2014, at 16:27, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 02:20:56PM +0000, Damjan Marion (damarion) wrote:
>>
>> On 25 Jun 2014, at 16:13, Nikolay Nikolaev
>> wrote:
>>
>>>>> - it will require changes on the user side also
On 25 Jun 2014, at 16:13, Nikolay Nikolaev
wrote:
> >> - it will require changes on the user side also
> >
> > why would it?
> > format seems unchanged, right?
>
> yes, but it will happen that multiple regions have same FD so call to mmap()
> should look different, I’m still playing with this
On 25 Jun 2014, at 16:06, Nikolay Nikolaev
wrote:
> +msg.memory.regions[fd_num].memory_size = reg->memory_size;
> so this is size
> +msg.memory.regions[fd_num].guest_phys_addr =
> reg->memory_size;
> and this is size again?
mistake, i alredy noticed it. It
On 25 Jun 2014, at 15:53, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 01:45:09PM +0000, Damjan Marion (damarion) wrote:
>>
>> Michael,
>>
>> there is another issue with commited vhost-user code.
>
> I'm answering just this once, but I have a po
Signed-off-by: Damjan Marion
---
docs/specs/vhost-user.txt | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt
index 0ea767e..2641390 100644
--- a/docs/specs/vhost-user.txt
+++ b/docs/specs/vhost
Public bug reported:
vhost-user implementation doesn't provide information about all memory regions,
and in some cases client is not able to map buffer memory as he is missing
memory region information for specific address.
Same thing is implemented properly for vhost-net. Below gdb outputs ar
Both systems I mentioned above were upgraded from precise to trusty.
After reinstalling them with clean install issue disappear and VMs are
not crashing anymore.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.n
just to clarify, i was pinning my test code inside the guest with
"taskset -c 1". There was no pinning on the host side.
Also, i see the same issue with -smp 2.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.n
Originally I reported this issue to ubuntu folks, and it is documented on
the launchpad[1] but would like to bring this into attention also on this list.
Basically seems that on some occasions clock interrupts are not happening for
longer periods of time causing that some VMs are crashing (i.e
re Raymond wrote:
>> Hi again Damjan,
>>
>> On Mon, Jul 4, 2011 at 6:35 PM, Damjan Marion
>> wrote:
>>>
>>> On Jul 4, 2011, at 6:59 PM, Alexandre Raymond wrote:
>>>
>>>> Hi Damjan,
>>>>
>>>>
>>>
On Jul 4, 2011, at 6:59 PM, Alexandre Raymond wrote:
> Hi Damjan,
>
>
> Can you try applying the following two patches and see if it solves
> your problem?
>
> http://patchwork.ozlabs.org/patch/100348/
> http://patchwork.ozlabs.org/patch/100477/
>
Unfortunately same thing happens: segmentati
Public bug reported:
I have an issue when I try to run qemu-system-arm on Mac OS X.
Sometime between 1 and 15 secs after qemu is started it crashes
as shown bellow.
Same thing on linux host works fine.
Is anybody else experiencing this?
Any Hints?
Thanks,
Damjan
(gdb) run
Starting program:
fter bisection seems that this starts happening after following patch:
commit 09716e45a05cc0c93bcf55bd0c0888dd678e490f
Author: Alexander Graf
Date: Thu Jun 9 00:55:37 2011 +0200
sigfd: use pthread_sigmask
diff --git a/compatfd.c b/compatfd.c
index bd377c4..41586ce 100644
--- a/compatfd.c
On Jul 1, 2011, at 11:17 AM, Damjan Marion (damarion) wrote:
>
> Hi,
>
> I have an issue when I try to run qemu-system-arm on Mac OS X.
> Sometime between 1 and 15 secs after qemu is started it crashes
> as shown bellow.
>
> Same thing on linux host works fi
Hi,
I have an issue when I try to run qemu-system-arm on Mac OS X.
Sometime between 1 and 15 secs after qemu is started it crashes
as shown bellow.
Same thing on linux host works fine.
Is anybody else experiencing this?
Any Hints?
Thanks,
Damjan
(gdb) run
Starting program: /opt/arm-qemu/b
28 matches
Mail list logo
