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 send/rec
On Fri, 19 Jun 2015 18:33:39 +0200
"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 a
On 19/06/2015 18:45, Michael S. Tsirkin wrote:
> > user guest QEMU
> >
> >
> > start I/O
> > '
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
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.
> > >
> > > Pa
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: de
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
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, Paol
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:
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 fre
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 addre
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.
> > >
> > > Pa
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
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_
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 effe
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 gues
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
On Thu, 18 Jun 2015 16:47:33 +0200
"Michael S. Tsirkin" 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:4
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
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 liv
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
On Thu, 18 Jun 2015 13:41:22 +0200
"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.
I'm not abandoning userspace approach e
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 use
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 majord...@v
On Thu, 18 Jun 2015 11:50:22 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote:
> > > > On Wed, 17 Jun
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 wil
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" 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" wrote:
> > >
> > > > On Wed,
On Wed, 17 Jun 2015 18:30:02 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
> > > > On Wed, 17 Jun
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, Paol
On Wed, 17 Jun 2015 18:47:18 +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 Bon
On Wed, 17 Jun 2015 18:30:02 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
> > > > On Wed, 17 Jun
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:
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 atta
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
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 me
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:09:21PM +0200, Igor Mammedov wrote:
> On Wed, 17 Jun 2015 17:38:40 +0200
> "Michael S. Tsirkin" 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" wrote:
> > >
> > > > On Wed,
On Wed, 17 Jun 2015 17:38:40 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Wed, Jun 17, 2015 at 03:20:44PM +0200, Paolo Bonzini 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" 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 userspa
On Wed, 17 Jun 2015 16:32:02 +0200
"Michael S. Tsirkin" 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 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
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
>
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" 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, 17 Jun 2015 13:51:56 +0200
"Michael S. Tsirkin" 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
> > si
On Wed, 17 Jun 2015 12:46:09 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
> > > > On Wed, 17 Jun
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" 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" wrote:
> > >
> > > > On Wed,
On Wed, 17 Jun 2015 12:11:09 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
> > > > On Wed, 17 Jun
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" 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" wrote:
> > >
> > > > On Wed,
On Wed, 17 Jun 2015 09:39:06 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
> > > > On Tue, 16 Jun
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
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" 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" wrote:
> > >
> > > > On Tue,
On Wed, 17 Jun 2015 08:34:26 +0200
"Michael S. Tsirkin" 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" wrote:
> >
> > > On Tue, Jun 16, 2015 at 06:33:37PM +0200, Igor Mammedov wrote:
> > > > since commit
>
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" 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 beca
On Tue, 16 Jun 2015 23:14:20 +0200
"Michael S. Tsirkin" 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
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
56 matches
Mail list logo
