On 12/29/2011 02:39 PM, Isaku Yamahata wrote:
> > > ioctl commands:
> > >
> > > UMEM_DEV_CRATE_UMEM: create umem device for qemu
> > > UMEM_DEV_LIST: list created umem devices
> > > UMEM_DEV_REATTACH: re-attach the created umem device
> > > UMEM_DEV_LIST and UMEM_DEV_REATTACH are used when
> > > the process that services page fault disappears or get stack.
> > > Then, administrator can list the umem devices and unblock
> > > the process which is waiting for page.
> >
> > Ah, I asked about this in my patch comments. I think this is done
> > better by using SCM_RIGHTS to pass fds along, or asking qemu to launch a
> > new process.
>
> Can you please elaborate? I think those ways you are suggesting doesn't solve
> the issue. Let me clarify the problem.
>
> process A (typically incoming qemu)
> |
> | mmap("/dev/umem") and access those pages triggering page faults
> | (the file descriptor might be closed after mmap() before page faults)
> |
> V
> /dev/umem
> ^
> |
> |
> daemon X resolving page faults triggered by process A
> (typically this daemon forked from incoming qemu:process A)
>
> If daemon X disappears accidentally, there is no one that resolves
> page faults of process A. At this moment process A is blocked due to page
> fault. There is no file descriptor available corresponding to the VMA.
> Here there is no way to kill process A, but system reboot.
qemu can have an extra thread that wait4()s the daemon, and relaunch
it. This extra thread would not be blocked by the page fault. It can
keep the fd so it isn't lost.
The unkillability of process A is a security issue; it could be done on
purpose. Is it possible to change umem to sleep with
TASK_INTERRUPTIBLE, so it can be killed?
> > Introducing a global namespace has a lot of complications attached.
> >
> > >
> > > UMEM_GET_PAGE_REQUEST: retrieve page fault of qemu process
> > > UMEM_MARK_PAGE_CACHED: mark the specified pages pulled from the source
> > > for daemon
> > >
> > > UMEM_MAKE_VMA_ANONYMOUS: make the specified vma in the qemu process
> > > This is _NOT_ implemented yet.
> > > anonymous I'm not sure whether this can be implemented
> > > or not.
> >
> > How do we find out? This is fairly important, stuff like transparent
> > hugepages and ksm only works on anonymous memory.
>
> I agree that this is important.
> At KVM-forum 2011, Andrea said THP and KSM works with non-anonymous VMA.
> (Or at lease he'll look into those stuff. My memory is vague, though.
> Please correct me if I'm wrong)
+= Andrea (who can also provide feedback on umem in general)
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
