This is a re-post, I didn't send it to all relevant mailing lists before...
Original below.
Hi everyone,
I have an interesting issue with DAX and KVM - I'm trying to boot a VM
with its memory mapped to a DAX-mounted file (kernel 4.9).
The use case is a bit wacky but I'm trying to recreate somet
On Wed, Jun 29, 2016 at 4:09 AM, Dan Williams wrote:
>
> On Tue, Jun 28, 2016 at 10:58 AM, H. Peter Anvin wrote:
> > On 06/28/16 09:33, Dan Williams wrote:
> >> On Tue, Jun 28, 2016 at 1:31 AM, Yigal Korman wrote:
> >>> Before this patch, passing a range t
that actually has RAM behind it.
And if someone still needs to fake a pmem that doesn't have RAM behind
it, they can simply do memmap=XX@YY,XX!YY.
Signed-off-by: Yigal Korman
Acked-by: Dan Williams
Acked-by: Johannes Thumshirn
Tested-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 2
On Thu, Jun 23, 2016 at 8:36 PM, Kani, Toshimitsu wrote:
> On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote:
>> On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote:
>> >
>> >
>> > Currently, presence of direct_access() in block_device_operations
>&g
think QUEUE_FLAG_DAX can also help with identifying dax devices in userspace.
Perhaps you'd be willing to squash the patch below with this one or
add it to your submission?
Thanks,
Yigal
[PATCH] block: expose QUEUE_FLAG_DAX in sysfs
There's currently no way to identify DAX enabled
that actually has RAM behind it.
And if someone still needs to fake a pmem that doesn't have RAM behind
it, they can simply do memmap=XX@YY,XX!YY.
Signed-off-by: Yigal Korman
---
arch/x86/kernel/e820.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/e82
should be applied to v4.3 as well.
[1] 0f90cc6609c7 mm, dax: fix DAX deadlocks
[2] 52a2b53ffde6 mm, dax: use i_mmap_unlock_write() in do_cow_fault()
[3] 843172978bb9 dax: fix race between simultaneous faults
[4] 2e4cdab0584f mm: allow page fault handlers to perform the COW
Signed-off-by: Yigal K
On Mon, Apr 13, 2015 at 3:56 PM, Kirill A. Shutemov
wrote:
> On Sun, Apr 12, 2015 at 03:56:33PM +0300, Yigal Korman wrote:
>> Hi,
>> I've tried to mlock() a range of an ext4-dax file and got "-ENOMEM" in
>> return.
>
> Is it comes from mlock_fixup() or -
On Mon, Apr 13, 2015 at 1:45 PM, Ingo Molnar wrote:
>
> * Christoph Hellwig wrote:
>
>> On Mon, Apr 13, 2015 at 11:33:09AM +0200, Ingo Molnar wrote:
>> > Limitations: this is a regular block device, and since the pmem areas
>> > are not struct page backed, they are invisible to the rest of the
>>
On Thu, Feb 5, 2015 at 11:39 PM, Matthew Wilcox wrote:
>
> On Thu, Feb 05, 2015 at 11:16:53AM +0200, Yigal Korman wrote:
> > I have a question on a related issue (I think).
> > I've noticed that for pfn-only mappings (VM_FAULT_NOPAGE)
> > do_shared_fault only maps
On Sat, Oct 25, 2014 at 12:20 AM, Matthew Wilcox
wrote:
> Currently COW of an XIP file is done by first bringing in a read-only
> mapping, then retrying the fault and copying the page. It is much more
> efficient to tell the fault handler that a COW is being attempted (by
> passing in the pre-all
Perhaps your patch is still valid in the context of this patch:
https://lkml.org/lkml/2014/9/9/612
Part of the reason for creating it was the fact that ioremap is using
a fake virtual address mapping.
So I think we can still use set_memory_wt for memory created with
add_persistent_memory.
What do y
I think that what confused Andy (or at least me) is the documentation in
Documentation/x86/pat.txt
If it's possible, can you please update pat.txt as part of the patch?
Thank you,
Yigal
On 04/09/2014 21:57, Toshi Kani wrote:
> On Thu, 2014-09-04 at 11:57 -0700, Andy Lutomirski wrote:
>> On Thu,
13 matches
Mail list logo
