From owner-dev-commits-src-all@freebsd.org Thu Aug 12 16:44:02 2021 Return-Path: Delivered-To: dev-commits-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 75B5B66EFDF; Thu, 12 Aug 2021 16:44:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Glsw22dF1z3H5Y; Thu, 12 Aug 2021 16:44:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id C84BE25984; Thu, 12 Aug 2021 16:44:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: git: f4c6843ec2b9 - main - xen: use correct cache attributes for Xen specific memory regions To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org References: <202108120724.17C7OJ8h043708@gitrepo.freebsd.org> From: John Baldwin Message-ID: <32e784a3-9c96-9818-8fc3-a5ad85643f2c@FreeBSD.org> Date: Thu, 12 Aug 2021 09:43:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: dev-commits-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 16:44:02 -0000 On 8/12/21 8:53 AM, Roger Pau Monné wrote: > On Thu, Aug 12, 2021 at 08:20:51AM -0700, John Baldwin wrote: >> On 8/12/21 12:24 AM, Roger Pau Monné wrote: >>> The branch main has been updated by royger: >>> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=f4c6843ec2b9aa5eff475778fb000ed6278c5b77 >>> >>> commit f4c6843ec2b9aa5eff475778fb000ed6278c5b77 >>> Author: Roger Pau Monné >>> AuthorDate: 2021-04-09 09:31:44 +0000 >>> Commit: Roger Pau Monné >>> CommitDate: 2021-08-12 07:18:32 +0000 >>> >>> xen: use correct cache attributes for Xen specific memory regions >>> bus_activate_resource maps memory regions as uncacheable on x86, which >>> is more strict than required for regions allocated using xenmem_alloc, >>> so don't rely on bus_activate_resource and instead map the region >>> using pmap_mapdev_attr and VM_MEMATTR_XEN as the cache attribute. >>> Sponsored by: Citrix Systems R&D >> >> It would probably be cleaner to use bus_map_resource() for this instead. It >> would mean you would have to use a structure that writes to as the argument >> to bus_read/write_* instead of using the resource directly. > > Those regions are usually handled to other subsystems of the kernel. > They are mostly used to map memory from other domains and then perform > IO on their behalf (like blkback and netback do), so it's not really > possible to assert that all users of the regions would use > bus_read/write_* to access them. > > I could however switch to using bus_map_resource if I can pass the > desired memory cache attribute and get a linear address back. It looks > like resource_map_request parameter allows to select the cache > attribute. Yes, one of the use case for bus_map_resource is to permit passing a non-default memory attribute. (It also permits mapping sub-ranges, but that isn't applicable in this case.) The 'r_vaddr' in the resource_map is the equivalent of rman_get_addr. It'd be a little cleaner (and perhaps friendly to future changes in this area) if your clients used the 'r_vaddr' from the resource_map directly instead of using rman_set_virtual() on the original resource. (At some point I would like to have each 'struct resource' keep a list of all the mappings created from it and to forcefully invalidate/free any existing mappings that still remain when a 'struct resource' is freed. I imagine as part of that I might end up with some assertions about the embedded resource fields in the 'struct resource' being self-consistent). -- John Baldwin