On Fri, 19 Jun 2015 18:33:39 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jun 19, 2015 at 06:26:27PM +0200, Paolo Bonzini wrote:
On 19/06/2015 18:20, Michael S. Tsirkin wrote:
We could, but I/O is just an example. It can be I/O, a network ring,
whatever. We cannot
On 22/06/2015 09:10, Igor Mammedov wrote:
So far HVA is unusable even if we will make this assumption and let guest
crash.
virt_net doesn't work with it anyway,
translation of GPA to HVA for descriptors works as expected (correctly)
but vhost+HVA hack backed virtio still can't
On Fri, Jun 19, 2015 at 12:44:26PM +0200, Paolo Bonzini wrote:
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it.
On Thu, Jun 18, 2015 at 06:02:46PM +0200, Paolo Bonzini wrote:
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
However, with Igor's patches a memory_region_del_subregion will cause a
mmap(MAP_NORESERVE), which _does_ have the effect of making the hva go
away.
I guess one way to do
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap releases it.
Paolo
Confused. So can we call mmap(MAP_NORESERVE) in address_space_unmap
after we detect
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap
On Fri, Jun 19, 2015 at 09:57:22AM +0200, Paolo Bonzini wrote:
On 19/06/2015 09:56, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 06:02:46PM +0200, Paolo Bonzini wrote:
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
However, with Igor's patches a memory_region_del_subregion will
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap releases
it.
Paolo
On 19/06/2015 09:56, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 06:02:46PM +0200, Paolo Bonzini wrote:
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
However, with Igor's patches a memory_region_del_subregion will cause a
mmap(MAP_NORESERVE), which _does_ have the effect of making
On 19/06/2015 15:34, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 12:44:26PM +0200, Paolo Bonzini wrote:
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction
On Fri, Jun 19, 2015 at 05:19:44PM +0200, Paolo Bonzini wrote:
On 19/06/2015 15:34, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 12:44:26PM +0200, Paolo Bonzini wrote:
On 19/06/2015 12:14, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 18:20, Michael S. Tsirkin wrote:
We could, but I/O is just an example. It can be I/O, a network ring,
whatever. We cannot audit all address_space_map uses.
No need to audit them all: defer device_add using an hva range until
address_space_unmap drops using hvas in range
On Fri, Jun 19, 2015 at 10:52:47AM +0200, Paolo Bonzini wrote:
On 19/06/2015 10:05, Michael S. Tsirkin wrote:
No, only destruction of the memory region frees it. address_space_map
takes a reference to the memory region and address_space_unmap releases
it.
Paolo
On 19/06/2015 18:33, Michael S. Tsirkin wrote:
On Fri, Jun 19, 2015 at 06:26:27PM +0200, Paolo Bonzini wrote:
On 19/06/2015 18:20, Michael S. Tsirkin wrote:
We could, but I/O is just an example. It can be I/O, a network ring,
whatever. We cannot audit all address_space_map uses.
No
On 19/06/2015 18:45, Michael S. Tsirkin wrote:
user guest QEMU
start I/O
On Fri, Jun 19, 2015 at 06:26:27PM +0200, Paolo Bonzini wrote:
On 19/06/2015 18:20, Michael S. Tsirkin wrote:
We could, but I/O is just an example. It can be I/O, a network ring,
whatever. We cannot audit all address_space_map uses.
No need to audit them all: defer device_add
On 18/06/2015 13:41, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
Lets leave decision upto users instead of making them live with
crashing guests.
Come on, let's fix it in userspace.
It's not trivial to fix it in userspace. Since QEMU uses RCU
On Thu, 18 Jun 2015 13:41:22 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
Lets leave decision upto users instead of making them live with
crashing guests.
Come on, let's fix it in userspace.
I'm not abandoning userspace
On Thu, Jun 18, 2015 at 01:50:32PM +0200, Paolo Bonzini wrote:
On 18/06/2015 13:41, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
Lets leave decision upto users instead of making them live with
crashing guests.
Come on, let's fix it in
On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
Lets leave decision upto users instead of making them live with
crashing guests.
Come on, let's fix it in userspace.
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 18/06/2015 15:19, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 01:50:32PM +0200, Paolo Bonzini wrote:
On 18/06/2015 13:41, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
Lets leave decision upto users instead of making them live with
On Thu, 18 Jun 2015 11:50:22 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 18, 2015 at 11:12:24AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 18:30:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote:
On
On Thu, Jun 18, 2015 at 03:46:14PM +0200, Paolo Bonzini wrote:
On 18/06/2015 15:19, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 01:50:32PM +0200, Paolo Bonzini wrote:
On 18/06/2015 13:41, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 01:39:12PM +0200, Igor Mammedov wrote:
On Thu, 18 Jun 2015 16:47:33 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 18, 2015 at 03:46:14PM +0200, Paolo Bonzini wrote:
On 18/06/2015 15:19, Michael S. Tsirkin wrote:
On Thu, Jun 18, 2015 at 01:50:32PM +0200, Paolo Bonzini wrote:
On 18/06/2015 13:41,
On 18/06/2015 16:47, Michael S. Tsirkin wrote:
However, with Igor's patches a memory_region_del_subregion will cause a
mmap(MAP_NORESERVE), which _does_ have the effect of making the hva go away.
I guess one way to do it would be to alias the same page in two places,
one for use by vhost
On 18/06/2015 11:50, Michael S. Tsirkin wrote:
But lets assume that there are tools that do this so
how about instead of hardcoding limit make it a module parameter
with default set to 64. That would allow users to set higher limit
if they need it and nor regress old tools. it will also
On Thu, Jun 18, 2015 at 11:12:24AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 18:30:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 17:38:40 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, 17 Jun 2015 18:30:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 17:38:40 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
On
On Wed, Jun 17, 2015 at 06:47:18PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:41, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:38:25PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
On Wed, 17 Jun 2015 18:30:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 17:38:40 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
On
On Wed, 17 Jun 2015 18:47:18 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
On 17/06/2015 18:41, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:38:25PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo
On Wed, 17 Jun 2015 12:46:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:37:42PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 12:11:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On
On Wed, 17 Jun 2015 13:51:56 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 01:48:03PM +0200, Igor Mammedov wrote:
So far it's kernel limitation and this patch fixes crashes
that users see now, with the rest of patches enabling performance
not to regress.
On Wed, Jun 17, 2015 at 01:48:03PM +0200, Igor Mammedov wrote:
So far it's kernel limitation and this patch fixes crashes
that users see now, with the rest of patches enabling performance
not to regress.
When I say regression I refer to an option to limit the array
size again after
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:14:20 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 16, 2015 at 06:33:37PM +0200, Igor Mammedov wrote:
since commit
1d4e7e3 kvm: x86: increase user memory slots to 509
it became
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:14:20 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 16, 2015 at 06:33:37PM +0200, Igor Mammedov wrote:
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:14:20 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, 17 Jun 2015 12:11:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On
On Wed, Jun 17, 2015 at 12:37:42PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 12:11:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On 17/06/2015 08:34, Michael S. Tsirkin wrote:
Also - 509?
userspace memory slots in terms of KVM, I made it match
KVM's allotment of memory slots for userspace side.
Maybe KVM has its reasons for this #.
Nice power of two (512) - number of reserved slots required by Intel's
On 17/06/2015 15:13, Michael S. Tsirkin wrote:
Considering userspace can be malicious, I guess yes.
I don't think it's a valid concern in this case,
setting limit back from 509 to 64 will not help here in any way,
userspace still can create as many vhost instances as it needs
to
On Wed, Jun 17, 2015 at 02:23:39PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 13:51:56 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 01:48:03PM +0200, Igor Mammedov wrote:
So far it's kernel limitation and this patch fixes crashes
that users see now,
On Wed, Jun 17, 2015 at 03:20:44PM +0200, Paolo Bonzini wrote:
On 17/06/2015 15:13, Michael S. Tsirkin wrote:
Considering userspace can be malicious, I guess yes.
I don't think it's a valid concern in this case,
setting limit back from 509 to 64 will not help here in any way,
On Wed, 17 Jun 2015 16:32:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 03:20:44PM +0200, Paolo Bonzini wrote:
On 17/06/2015 15:13, Michael S. Tsirkin wrote:
Considering userspace can be malicious, I guess yes.
I don't think it's a valid concern in
On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 16:32:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 03:20:44PM +0200, Paolo Bonzini wrote:
On 17/06/2015 15:13, Michael S. Tsirkin wrote:
Considering userspace can
On Wed, Jun 17, 2015 at 06:38:25PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:30, Michael S. Tsirkin wrote:
Meanwhile old tools are vulnerable to OOM attacks.
For each
On 17/06/2015 18:41, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:38:25PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:30, Michael S. Tsirkin wrote:
Meanwhile old tools
On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 17:38:40 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 16:32:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On 17/06/2015 18:30, Michael S. Tsirkin wrote:
Meanwhile old tools are vulnerable to OOM attacks.
For each vhost device there will be likely one tap interface, and I
suspect that it takes way, way more than 16KB of memory.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:30, Michael S. Tsirkin wrote:
Meanwhile old tools are vulnerable to OOM attacks.
For each vhost device there will be likely one tap interface, and I
suspect that it takes way, way more than 16KB of memory.
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:30, Michael S. Tsirkin wrote:
Meanwhile old tools are vulnerable to OOM attacks.
For each vhost device there will be likely one tap interface, and I
suspect that
On Wed, 17 Jun 2015 17:38:40 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 16:32:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 03:20:44PM +0200, Paolo Bonzini wrote:
On Tue, Jun 16, 2015 at 06:33:37PM +0200, Igor Mammedov wrote:
since commit
1d4e7e3 kvm: x86: increase user memory slots to 509
it became possible to use a bigger amount of memory
slots, which is used by memory hotplug for
registering hotplugged memory.
However QEMU crashes if it's used
On Tue, 16 Jun 2015 23:14:20 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 16, 2015 at 06:33:37PM +0200, Igor Mammedov wrote:
since commit
1d4e7e3 kvm: x86: increase user memory slots to 509
it became possible to use a bigger amount of memory
slots, which is used by
56 matches
Mail list logo
