From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932903AbbFVHKi (ORCPT ); Mon, 22 Jun 2015 03:10:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55955 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753790AbbFVHKc (ORCPT ); Mon, 22 Jun 2015 03:10:32 -0400 Date: Mon, 22 Jun 2015 09:10:27 +0200 From: Igor Mammedov To: "Michael S. Tsirkin" Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, andrey@xdel.ru Subject: Re: [PATCH 3/5] vhost: support upto 509 memory regions Message-ID: <20150622091027.582a1549@nial.brq.redhat.com> In-Reply-To: <20150619183226-mutt-send-email-mst@redhat.com> References: <20150619095515-mutt-send-email-mst@redhat.com> <5583CB62.6030405@redhat.com> <20150619100409-mutt-send-email-mst@redhat.com> <5583D85F.7090200@redhat.com> <20150619120734-mutt-send-email-mst@redhat.com> <5583F28A.9080206@redhat.com> <20150619153248-mutt-send-email-mst@redhat.com> <55843310.50403@redhat.com> <20150619181845-mutt-send-email-mst@redhat.com> <558442B3.2020900@redhat.com> <20150619183226-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 drops reference count to > > > 0. > > > > That could be forever. You certainly don't want to lockup the monitor > > forever just because a device model isn't too friendly to memory hot-unplug. > > We can defer the addition, no need to lockup the monitor. > > > That's why you need to audit them (also, it's perfectly in the device > > model's right to use address_space_unmap this way: it's the guest that's > > buggy and leaves a dangling reference to a region before unplugging it). > > > > Paolo > > Then maybe it's not too bad that the guest will crash because the memory > was unmapped. 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/received packets. That's why I prefer to merge kernel solution first as a stable and not introducing any issues solution. And work on userspace approach on top of that. Hopefully it could be done but we still would need time to iron out side effects/issues it causes or could cause so that fix became stable enough for production. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mammedov Subject: Re: [PATCH 3/5] vhost: support upto 509 memory regions Date: Mon, 22 Jun 2015 09:10:27 +0200 Message-ID: <20150622091027.582a1549@nial.brq.redhat.com> References: <20150619095515-mutt-send-email-mst@redhat.com> <5583CB62.6030405@redhat.com> <20150619100409-mutt-send-email-mst@redhat.com> <5583D85F.7090200@redhat.com> <20150619120734-mutt-send-email-mst@redhat.com> <5583F28A.9080206@redhat.com> <20150619153248-mutt-send-email-mst@redhat.com> <55843310.50403@redhat.com> <20150619181845-mutt-send-email-mst@redhat.com> <558442B3.2020900@redhat.com> <20150619183226-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, andrey@xdel.ru To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55955 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753790AbbFVHKc (ORCPT ); Mon, 22 Jun 2015 03:10:32 -0400 In-Reply-To: <20150619183226-mutt-send-email-mst@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 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 drops reference count to > > > 0. > > > > That could be forever. You certainly don't want to lockup the monitor > > forever just because a device model isn't too friendly to memory hot-unplug. > > We can defer the addition, no need to lockup the monitor. > > > That's why you need to audit them (also, it's perfectly in the device > > model's right to use address_space_unmap this way: it's the guest that's > > buggy and leaves a dangling reference to a region before unplugging it). > > > > Paolo > > Then maybe it's not too bad that the guest will crash because the memory > was unmapped. 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/received packets. That's why I prefer to merge kernel solution first as a stable and not introducing any issues solution. And work on userspace approach on top of that. Hopefully it could be done but we still would need time to iron out side effects/issues it causes or could cause so that fix became stable enough for production. -- To unsubscribe from this list: send the line "unsubscribe kvm" in