> >
> > This patch adds prefix 'v' in disk name for virtio pmem.
> > This differentiates virtio-pmem disks from the pmem disks.
>
> I don't think the small matter that this device does not support
> MAP_SYNC warrants a separate naming scheme. That said I do think we
> need to export this attrib
On Fri, Aug 16, 2019 at 08:54:30AM +0200, Christoph Hellwig wrote:
> Hi Dan and Jason,
>
> Bharata has been working on secure page management for kvmppc guests,
> and one I thing I noticed is that he had to fake up a struct device
> just so that it could be passed to the devm_memremap_pages
> inst
This patch set is to fix some dax kmem driver issues and then it can
support to use pmem as normal RAM in arm64 qemu guest.
Jia He (2):
drivers/dax/kmem: use default numa_mem_id if target_node is invalid
drivers/dax/kmem: give a warning if CONFIG_DEV_DAX_PMEM_COMPAT is
enabled
drivers/d
In some platforms(e.g arm64 guest), the NFIT info might not be ready.
Then target_node might be -1. But if there is a default numa_mem_id(),
we can use it to avoid unnecessary fatal EINVL error.
devm_memremap_pages() also uses this logic if nid is invalid, we can
keep the same page with it.
Signe
commit c221c0b0308f ("device-dax: "Hotplug" persistent memory for use
like normal RAM") helps to add persistent memory as normal RAM blocks.
But this driver doesn't work if CONFIG_DEV_DAX_PMEM_COMPAT is enabled.
Here is the debugging call trace when CONFIG_DEV_DAX_PMEM_COMPAT is
enabled.
[4.44
On Fri, Aug 16, 2019 at 08:54:30AM +0200, Christoph Hellwig wrote:
> Hi Dan and Jason,
>
> Bharata has been working on secure page management for kvmppc guests,
> and one I thing I noticed is that he had to fake up a struct device
> just so that it could be passed to the devm_memremap_pages
> inst
> > Changes since v1:
> > - don't overload devm_request_free_mem_region
> > - export the memremap_pages and munmap_pages as kvmppc can be a module
>
> What tree do we want this to go through? Dan are you running a pgmap
> tree still? Do we know of any conflicts?
The last changes in this area we
On Fri, Aug 16, 2019 at 02:36:07PM +0200, Christoph Hellwig wrote:
> > > Changes since v1:
> > > - don't overload devm_request_free_mem_region
> > > - export the memremap_pages and munmap_pages as kvmppc can be a module
> >
> > What tree do we want this to go through? Dan are you running a pgmap
On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote:
> > > Hello!
> > >
> > > On Fri 09-08-19 15:58:14, ira.we...@intel.com wrote:
> > > > Pre-requisites
> > > > ==
> > > >
Hi, Yi,
Yi Zhang writes:
> Hi Dan
>
> As subject, I found it failed from bellow commit[1], steps list here
> [2] and I've attached the full dmesg, let me know if you need more
> info, thanks.
>
> [1]
> commit a3619190d62ed9d66416891be2416f6bea2b3ca4 (refs/bisect/bad)
> Author: Dan Williams
> Da
Dan Williams writes:
> In the process of debugging a system with an NVDIMM that was failing to
> unlock it was found that the kernel is reporting 'locked' while the DIMM
> security interface is 'frozen'. Unfortunately the security state is
> tracked internally as an enum which prevents it from co
Dan Williams writes:
> The blanket blocking of all security operations while the DIMM is in
> active use in a region is too restrictive. The only security operations
> that need to be aware of the ->busy state are those that mutate the
> state of data, i.e. erase and overwrite.
>
> Refactor the -
Dan Williams writes:
> The security operations are exported from libnvdimm/security.c to
> libnvdimm/dimm_devs.c, and libnvdimm/security.c is optionally compiled
> based on the CONFIG_NVDIMM_KEYS config symbol.
>
> Rather than export the operations across compile objects, just move the
> __securi
On Fri, 16 Aug 2019 08:54:34 +0200 Christoph Hellwig wrote:
> The kvmppc ultravisor code wants a device private memory pool that is
> system wide and not attached to a device. Instead of faking up one
> provide a low-level memremap_pages for it. Note that this function is
> not exported, and do
On Fri, 16 Aug 2019 08:54:31 +0200 Christoph Hellwig wrote:
> Just add a simple macro that passes a NULL dev argument to
> dev_request_free_mem_region, and call request_mem_region in the
> function for that particular case.
Nit:
> +struct resource *request_free_mem_region(struct resource *base,
On Fri, Aug 16, 2019 at 1:49 PM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > The blanket blocking of all security operations while the DIMM is in
> > active use in a region is too restrictive. The only security operations
> > that need to be aware of the ->busy state are those that mutate the
emap_pages+0x894/0xc70:
devm_memremap_pages at mm/memremap.c:307
[ 32.074412][ T294] WARNING: CPU: 31 PID: 294 at mm/kasan/init.c:496
kasan_add_zero_shadow.cold.2+0xc/0x39
[ 32.077448][ T294] Modules linked in:
[ 32.078614][ T294] CPU: 31 PID: 294 Comm: kworker/u97:1 Not tainted 5.3.0-
rc4-nex
On Fri, Aug 16, 2019 at 2:36 PM Qian Cai wrote:
>
> Every so often recently, booting Intel CPU server on linux-next triggers this
> warning. Trying to figure out if the commit 7cc7867fb061
> ("mm/devm_memremap_pages: enable sub-section remap") is the culprit here.
>
> # ./scripts/faddr2line vmlin
On Fri, Aug 16, 2019 at 12:05:28PM -0700, 'Ira Weiny' wrote:
> On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> > On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote:
> > > > Hello!
> > > >
> > > > On Fri 09-08-19 15:58:14, ira.we...
On Fri, Aug 16, 2019 at 08:54:30AM +0200, Christoph Hellwig wrote:
> Hi Dan and Jason,
>
> Bharata has been working on secure page management for kvmppc guests,
> and one I thing I noticed is that he had to fake up a struct device
> just so that it could be passed to the devm_memremap_pages
> inst
On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote:
> On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote:
> > On Wed 14-08-19 11:08:49, Ira Weiny wrote:
> > > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote:
> 2) Second reason is that I thought I did not have a good way to tel
> On Aug 16, 2019, at 5:48 PM, Dan Williams wrote:
>
> On Fri, Aug 16, 2019 at 2:36 PM Qian Cai wrote:
>>
>> Every so often recently, booting Intel CPU server on linux-next triggers this
>> warning. Trying to figure out if the commit 7cc7867fb061
>> ("mm/devm_memremap_pages: enable sub-sect
On Fri, Aug 16, 2019 at 8:34 PM Qian Cai wrote:
>
>
>
> > On Aug 16, 2019, at 5:48 PM, Dan Williams wrote:
> >
> > On Fri, Aug 16, 2019 at 2:36 PM Qian Cai wrote:
> >>
> >> Every so often recently, booting Intel CPU server on linux-next triggers
> >> this
> >> warning. Trying to figure out if
23 matches
Mail list logo
