From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ujwdm-0002Nh-Q5 for qemu-devel@nongnu.org; Tue, 04 Jun 2013 15:11:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ujwdl-0005ZW-8d for qemu-devel@nongnu.org; Tue, 04 Jun 2013 15:11:30 -0400 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:52239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ujwdl-0005ZC-3a for qemu-devel@nongnu.org; Tue, 04 Jun 2013 15:11:29 -0400 Received: by mail-wi0-f180.google.com with SMTP id hn14so548456wib.7 for ; Tue, 04 Jun 2013 12:11:28 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51AE3BD4.8070007@redhat.com> Date: Tue, 04 Jun 2013 21:11:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1370348041-6768-1-git-send-email-pbonzini@redhat.com> <1370348041-6768-7-git-send-email-pbonzini@redhat.com> <51ADDE1A.4030709@redhat.com> <51ADEAA6.2050509@redhat.com> <51AE1AE8.5000300@redhat.com> <1370368034.30975.431.camel@ul30vt.home> In-Reply-To: <1370368034.30975.431.camel@ul30vt.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 06/17] sysbus: add sysbus_pass_mmio List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Peter Maydell , qemu-devel@nongnu.org Il 04/06/2013 19:47, Alex Williamson ha scritto: > We'll see about that ;) At the very least you broke the tie. :) > It's true that it's simply a mental model of > doing the required steps, then optimizing that makes vfio need a > sprinkling of set ownership calls. Paolo, your patch to move the > PCI/VGA registration later solves this and completely hides memory > region ownership from vfio. That's great, but as Peter is arguing, > leaves a hole that I'm not even aware that an owner is required for a > memory region and the API still leaves me lots of opportunities to get > it wrong. So, I have to go back to Rusty's API design guidelines that > an API should difficult to use incorrectly. From what I see, I'm not > sure we have that here. An ugly compromise might be a runtime checks > for orphan memory regions after a device is initialized, but that has > it's own set of problems. Thanks, Then I'll hunt for the 800 owners. In the meanwhile, patch 2/3/4/14/15/16/17 won't change from this series to the next, so a review of those is welcome. :) Paolo