vhost checked the counter within the refcnt before decrementing. It
really wanted to know that it is the one that has the last reference, as
a way to batch freeing resources a bit more efficiently.
Note: we only let refcount go to 0 on device release.
This works well but we now access the ref
vhost_zerocopy_callback accesses VQ right after it drops a ubuf
reference. In theory, this could race with device removal which waits
on the ubuf kref, and crash on use after free.
Do all accesses within rcu read side critical section, and synchronize
on release.
Since callbacks are always
On 02/13/2014 05:45 PM, Michael S. Tsirkin wrote:
vhost_zerocopy_callback accesses VQ right after it drops a ubuf
reference. In theory, this could race with device removal which waits
on the ubuf kref, and crash on use after free.
Do all accesses within rcu read side critical section, and
On 02/13/2014 05:42 PM, Michael S. Tsirkin wrote:
vhost checked the counter within the refcnt before decrementing. It
really wanted to know that it is the one that has the last reference, as
a way to batch freeing resources a bit more efficiently.
Note: we only let refcount go to 0 on device
On Wed, 2014-02-12 at 14:05 -0800, Luis R. Rodriguez wrote:
I meant the PV protocol extension which allows guests (netfront) to
register to receive multicast frames across the PV ring -- i.e. for
multicast to work from the guests PoV.
Not quite sure I understand, ipv6 works on guests so
On 02/13/2014 04:45 AM, Fengguang Wu wrote:
Greetings,
I find that when running
qemu-system-x86_64 -cpu qemu64,+smep,+smap
Some kernels will 100% produce this error, where the error code
-13,-14 are -EACCES and -EFAULT:
Any ideas?
I notice this is a non-SMAP kernel:
#
On 02/13/2014 06:55 AM, H. Peter Anvin wrote:
On 02/13/2014 04:45 AM, Fengguang Wu wrote:
Greetings,
I find that when running
qemu-system-x86_64 -cpu qemu64,+smep,+smap
Some kernels will 100% produce this error, where the error code
-13,-14 are -EACCES and -EFAULT:
Any ideas?
On 02/13/2014 06:55 AM, H. Peter Anvin wrote:
On 02/13/2014 04:45 AM, Fengguang Wu wrote:
Greetings,
I find that when running
qemu-system-x86_64 -cpu qemu64,+smep,+smap
Some kernels will 100% produce this error, where the error code
-13,-14 are -EACCES and -EFAULT:
Any ideas?
On 12.02.2014 12:54, Peter Zijlstra wrote:
On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
Something else here I run a kernel with CONFIG_PREEMPT not set and NR_CPUS
limited to 8 (for the 32bit kernel). So the default apic driver is used.
Since
default_send_IPI_mask_logical is
On Thu, Feb 13, 2014 at 06:00:19PM +0100, Stefan Bader wrote:
On 12.02.2014 12:54, Peter Zijlstra wrote:
On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
Something else here I run a kernel with CONFIG_PREEMPT not set and NR_CPUS
limited to 8 (for the 32bit kernel). So the
On Thu, Feb 13, 2014 at 07:03:56PM +0100, Stefan Bader wrote:
Yeah... not sure the interleaved source helps or not ...
It did, thanks!
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, Feb 13, 2014 at 06:00:19PM +0100, Stefan Bader wrote:
On 12.02.2014 12:54, Peter Zijlstra wrote:
On Wed, Feb 12, 2014 at 12:09:29PM +0100, Stefan Bader wrote:
Something else here I run a kernel with CONFIG_PREEMPT not set and NR_CPUS
limited to 8 (for the 32bit kernel). So the
Il 11/02/2014 12:45, Christian Borntraeger ha scritto:
From: Michael Mueller m...@linux.vnet.ibm.com
Commit s390/kvm: Use common waitqueue caused a performance regression
on s390. It turned out that a yield candidate was missed by just a simple
test on its non-empty waitqueue. If an interrupt
On 13/02/14 23:37, Paolo Bonzini wrote:
Il 11/02/2014 12:45, Christian Borntraeger ha scritto:
From: Michael Mueller m...@linux.vnet.ibm.com
Commit s390/kvm: Use common waitqueue caused a performance regression
on s390. It turned out that a yield candidate was missed by just a simple
test on
Il 13/02/2014 23:54, Christian Borntraeger ha scritto:
We had several variants but in the end we tried to come up with a patch that
does not
influence other architectures. Your proposal would certainly be fine for s390,
but what impact does it have on x86, arm, arm64? Will it cause performance
From: Michael S. Tsirkin m...@redhat.com
Date: Thu, 13 Feb 2014 11:42:05 +0200
vhost checked the counter within the refcnt before decrementing. It
really wanted to know that it is the one that has the last reference, as
a way to batch freeing resources a bit more efficiently.
Note: we only
From: Michael S. Tsirkin m...@redhat.com
Date: Thu, 13 Feb 2014 11:45:11 +0200
vhost_zerocopy_callback accesses VQ right after it drops a ubuf
reference. In theory, this could race with device removal which waits
on the ubuf kref, and crash on use after free.
Do all accesses within rcu
-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Wednesday, February 12, 2014 3:42 PM
To: Zhang, Yang Z
Cc: kvm@vger.kernel.org; Liu, RongrongX
Subject: Re: hyper-v support in KVM
On Wed, 2014-02-12 at 01:33 +, Zhang, Yang Z wrote:
Vadim Rozenfeld
On Fri, 2014-02-14 at 02:35 +, Liu, RongrongX wrote:
-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Wednesday, February 12, 2014 3:42 PM
To: Zhang, Yang Z
Cc: kvm@vger.kernel.org; Liu, RongrongX
Subject: Re: hyper-v support in KVM
On Wed,
These days hv_clock allocation is memblock based (i.e. the percpu
allocator is not involved), which means that the physical address
of each of the per-cpu hv_clock areas is guaranteed to remain
unchanged through all its lifetime and we do not need to update
its location after CPU bring-up.
20 matches
Mail list logo
