From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEY6H-000441-RE for qemu-devel@nongnu.org; Mon, 13 Jul 2015 03:24:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEY6C-00069z-QY for qemu-devel@nongnu.org; Mon, 13 Jul 2015 03:24:29 -0400 Received: from mail-pa0-f53.google.com ([209.85.220.53]:33778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEY6C-00069n-Kc for qemu-devel@nongnu.org; Mon, 13 Jul 2015 03:24:24 -0400 Received: by padck2 with SMTP id ck2so38119738pad.0 for ; Mon, 13 Jul 2015 00:24:24 -0700 (PDT) References: <1436525028-23963-1-git-send-email-aik@ozlabs.ru> <1436525028-23963-2-git-send-email-aik@ozlabs.ru> <20150713061539.GB4121@voom.redhat.com> From: Alexey Kardashevskiy Message-ID: <55A367A1.50707@ozlabs.ru> Date: Mon, 13 Jul 2015 17:24:17 +1000 MIME-Version: 1.0 In-Reply-To: <20150713061539.GB4121@voom.redhat.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu 1/5] vfio: Switch from TARGET_PAGE_MASK to qemu_real_host_page_mask List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 07/13/2015 04:15 PM, David Gibson wrote: > On Fri, Jul 10, 2015 at 08:43:44PM +1000, Alexey Kardashevskiy wrote: >> These started switching from TARGET_PAGE_MASK (hardcoded as 4K) to >> a real host page size: >> 4e51361d7 "cpu-all: complete "real" host page size API" and >> f7ceed190 "vfio: cpu: Use "real" page size API" >> >> This finished the transition by: >> - %s/TARGET_PAGE_MASK/qemu_real_host_page_mask/ >> - %s/TARGET_PAGE_ALIGN/REAL_HOST_PAGE_ALIGN/ >> - removing bitfield length for offsets in VFIOQuirk::data as >> qemu_real_host_page_mask is not a macro > > This does not make much sense to me. f7ceed190 moved to > REAL_HOST_PAGE_SIZE because it's back end stuff that really depends > only on the host page size. > > Here you're applying a blanket change to vfio code, in particular to > the DMA handling code, and for DMA both the host and target page size > can be relevant, depending on the details of the IOMMU implementation. 5/5 uses this listener for memory preregistration - this totally depends on the host page size. It was suggested to make this listener do memory preregistration too, not just DMA. >> This keeps using TARGET_PAGE_MASK for IOMMU regions though as it is >> the minimum page size which IOMMU regions may be using and at the moment >> memory regions do not carry the actual page size. > > And this exception also doesn't make much sense to me. Partly it's > confusing because the listener is doing different things depending on > whether we have a guest visible IOMMU or not. Yes... > In short, there doesn't seem to be a coherent explanation here of > where the page size / alignment restriction is coming from, and > therefore whether it needs to be a host page alignment, a guest page > alignment, or both. > >> Signed-off-by: Alexey Kardashevskiy >> --- >> >> In reality DMA windows are always a lot bigger than a single 4K page >> and aligned to 32/64MB, may be only use here >> qemu_real_host_page_mask? > > I don't understand this question either. The listener is called on RAM regions and DMA windows. If it is a RAM region, then host page size applies. If it is a DMA window - then 4K. So the same listener has to use different page size in different situation to check for alignments. But in reality everything will be aligned to megabytes or so. So we could enforce 64K alignment for DMA windows, for example, and make code simpler. -- Alexey