Hello,
On top of "[PATCH 0/3] kvmtool: tiny init fox x86_64" I sent.
I simply can't understand why kvmtool always overwrites /virt/init.
This doesn't look right, especially because you can't pass "init="
kernel argument without another patch "[PATCH] kvmtool/run: append
cfg.kernel_cmdline at the
setup_guest_init() only
if make_dir(guestfs_name) creates the new/empty dir.
Signed-off-by: Oleg Nesterov
---
builtin-setup.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-setup.c b/builtin-setup.c
index 1e5b1e4..8be8d62 100644
--- a/builtin-setup.c
+++ b/builtin-s
and has no effect.
We need to clear MS_RDONLY from root_mountflags, this is what the
"standalone" kernel parameter correctly does.
Signed-off-by: Oleg Nesterov
---
builtin-run.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin-run.c b/builtin-run.c
ind
add lkvm-static to gitignore
Signed-off-by: Oleg Nesterov
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 697a63f..a16a97f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,5 @@
/lkvm
+/lkvm-static
/vm
*.o
*.d
--
2.4.3
--
To unsubscribe
Hi Pekka,
On 10/22, Pekka Enberg wrote:
>
> The series looks good to me:
>
> Acked-by: Pekka Enberg
Thanks! I'll try to send some cleanups later.
But let me send another simple series first.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ma
According to git grep they can be static.
term_got_escape can be static too, and we can even move it into
term_getc().
"int term_escape_char" doesn't make sense at least until we allow
to redefine it, turn it into preprocessor constant.
Signed-off-by: Oleg Nesterov
---
include/
_param(name, val) to make this all more consistent;
it should only append "name=val" to real_cmdline if cfg.kernel_cmdline
doesn't include this paramater.
Signed-off-by: Oleg Nesterov
---
builtin-run.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --g
- build $ARCH_PRE_INIT as guest/guest_pre_init.o and embed it
into lkvm the same as we do with guest/guest_init.o
This also means that ARCH_PRE_INIT case doesn't depend on glibc-static,
we can relax the SOURCE_STATIC check later.
Signed-off-by: Oleg Nesterov
---
.gitignore | 1 +
lkvm shouldn't abuse the "init="
kernel parameter at all.
TODO: x86/init.S doesn't handle i386, should be simple to add.
Signed-off-by: Oleg Nesterov
---
Makefile| 1 +
builtin-run.c | 4
builtin-setup.c | 14 +-
guest/init.c| 2
Turn kvm_setup_guest_init(guestfs_name) into a more generic helper,
extract_file(guestfs_name, filename, data, size) and reimplement
kvm_setup_guest_init() as a trivial wrapper.
Signed-off-by: Oleg Nesterov
---
builtin-setup.c | 24 ++--
1 file changed, 14 insertions(+), 10
Hello,
Yesterday I discovered kvmtool and it looks really cool! Thanks!
Looks like, it does exactly what I need.
But the static /virt/init doesn't look good. This series lessens
the size of lkvm binary from 1045952 to 196200 bytes on x86_64,
but this is minor. I want to write my /virt/init in she
its to restore per-process rwsem. They will be re-applied
> for the v4.4-rc1 merge window.
>
> Signed-off-by: Tejun Heo
> Link: http://lkml.kernel.org/g/55f8097a.7000...@de.ibm.com
> Reported-by: Christian Borntraeger
> Cc: Oleg Nesterov
> Cc: "Paul E. McKenney"
On 09/16, Paolo Bonzini wrote:
>
>
> On 16/09/2015 14:22, Oleg Nesterov wrote:
> > > The issue is that rcu_sync doesn't eliminate synchronize_sched,
> >
> > Yes, but it eliminates _expedited(). This is good, but otoh this means
> > that (say) individual
On 09/16, Paolo Bonzini wrote:
>
>
> On 16/09/2015 10:57, Christian Borntraeger wrote:
> > Am 16.09.2015 um 10:32 schrieb Paolo Bonzini:
> >>
> >>
> >> On 15/09/2015 19:38, Paul E. McKenney wrote:
> >>> Excellent points!
> >>>
> >>> Other options in such situations include the following:
> >>>
> >>
On 05/02, NeilBrown wrote:
>
> All the calls in md.c are in a kernel thread so safe, but I'd rather have an
> explicit "uninterruptible, but no load-average" wait
Could you please explain why md_thread() does allow_signal(SIGKILL) ?
I am just curious. It looks as if we want to allow user-spac
On 02/15, Raghavendra K T wrote:
>
> * Raghavendra K T [2015-02-15 11:25:44]:
>
> Resending the V5 with smp_mb__after_atomic() change without bumping up
> revision
Reviewed-by: Oleg Nesterov
Of course, this needs the acks from maintainers. And I agree that SLOWPATH
in .head
Well, I regret I mentioned the lack of barrier after enter_slowpath ;)
On 02/15, Raghavendra K T wrote:
>
> @@ -46,7 +46,8 @@ static __always_inline bool static_key_false(struct
> static_key *key);
>
> static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
> {
> - set_bit(0, (vol
On 02/15, Raghavendra K T wrote:
>
> On 02/13/2015 09:02 PM, Oleg Nesterov wrote:
>
>>> @@ -772,7 +773,8 @@ __visible void kvm_lock_spinning(struct arch_spinlock
>>> *lock, __ticket_t want)
>>> * check again make sure it didn't become
On 02/13, Oleg Nesterov wrote:
>
> On 02/13, Raghavendra K T wrote:
> >
> > @@ -772,7 +773,8 @@ __visible void kvm_lock_spinning(struct arch_spinlock
> > *lock, __ticket_t want)
> > * check again make sure it didn't become free while
> > * w
On 02/13, Raghavendra K T wrote:
>
> @@ -164,7 +161,7 @@ static inline int arch_spin_is_locked(arch_spinlock_t
> *lock)
> {
> struct __raw_tickets tmp = READ_ONCE(lock->tickets);
>
> - return tmp.tail != tmp.head;
> + return tmp.tail != (tmp.head & ~TICKET_SLOWPATH_FLAG);
> }
Well
On 02/11, Jeremy Fitzhardinge wrote:
>
> On 02/11/2015 09:24 AM, Oleg Nesterov wrote:
> > I agree, and I have to admit I am not sure I fully understand why
> > unlock uses the locked add. Except we need a barrier to avoid the race
> > with the enter_slowpath() users, of cou
Damn, sorry for noise, forgot to mention...
On 02/12, Raghavendra K T wrote:
>
> +static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock,
> + __ticket_t head)
> +{
> + if (head & TICKET_SLOWPATH_FLAG) {
> + arc
On 02/12, Raghavendra K T wrote:
>
> @@ -191,8 +189,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t
> *lock)
>* We need to check "unlocked" in a loop, tmp.head == head
>* can be false positive because of overflow.
>*/
> - if
On 02/12, Raghavendra K T wrote:
>
> @@ -772,7 +773,8 @@ __visible void kvm_lock_spinning(struct arch_spinlock
> *lock, __ticket_t want)
>* check again make sure it didn't become free while
>* we weren't looking.
>*/
> - if (ACCESS_ONCE(lock->tickets.head) == want) {
>
On 02/11, Raghavendra K T wrote:
>
> On 02/10/2015 06:56 PM, Oleg Nesterov wrote:
>
>> In this case __ticket_check_and_clear_slowpath() really needs to cmpxchg
>> the whole .head_tail. Plus obviously more boring changes. This needs a
>> separate patch even _if_ this
On 02/10, Jeremy Fitzhardinge wrote:
>
> On 02/10/2015 05:26 AM, Oleg Nesterov wrote:
> > On 02/10, Raghavendra K T wrote:
> >> Unfortunately xadd could result in head overflow as tail is high.
> >>
> >> The other option was repeated cmpxchg which is bad I be
On 02/10, Denys Vlasenko wrote:
>
> # define HEAD_MASK (TICKET_SLOWPATH_FLAG-1)
>
> ...
> unlock_again:
>
> val = xadd((&lock->ticket.head_tail, TICKET_LOCK_INC);
> if (unlikely(!(val & HEAD_MASK))) {
> /* overflow. we inadvertently incremented the tail word.
> * tail's lsb is TICKET_SLOWP
On 02/10, Raghavendra K T wrote:
>
> On 02/10/2015 06:23 AM, Linus Torvalds wrote:
>
>> add_smp(&lock->tickets.head, TICKET_LOCK_INC);
>> if (READ_ONCE(lock->tickets.tail) & TICKET_SLOWPATH_FLAG) ..
>>
>> into something like
>>
>> val = xadd((&lock->ticket.head_tail, TICK
On 02/09, Raghavendra K T wrote:
>
> +static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock)
> +{
> + arch_spinlock_t old, new;
> + __ticket_t diff;
> +
> + old.tickets = READ_ONCE(lock->tickets);
> + diff = (old.tickets.tail & ~TICKET_SLOWPATH_FLAG) - old.ticke
On 02/06, Sasha Levin wrote:
>
> Can we modify it slightly to avoid potentially accessing invalid memory:
>
> diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
> index 5315887..cd22d73 100644
> --- a/arch/x86/include/asm/spinlock.h
> +++ b/arch/x86/include/asm/spinlock
On 01/15, Christian Borntraeger wrote:
>
> Am 15.01.2015 um 20:38 schrieb Oleg Nesterov:
> > On 01/15, Christian Borntraeger wrote:
> >>
> >> --- a/arch/x86/include/asm/spinlock.h
> >> +++ b/arch/x86/include/asm/spinlock.h
> >> @@ -186,7 +186,7 @
On 01/15, Christian Borntraeger wrote:
>
> --- a/arch/x86/include/asm/spinlock.h
> +++ b/arch/x86/include/asm/spinlock.h
> @@ -186,7 +186,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t
> *lock)
> __ticket_t head = ACCESS_ONCE(lock->tickets.head);
>
> for (;;) {
> -
On 04/28, Andrea Arcangeli wrote:
>
> On Mon, Apr 28, 2014 at 01:06:05PM +0200, Paolo Bonzini wrote:
> > Patch 1 will be for 3.16 only, I'd like a review from Marcelo or Andrea
> > though (that's "KVM: async_pf: kill the unnecessary use_mm/unuse_mm
> > async_pf_execute()" for easier googling).
>
>
async_pf_execute() passes tsk == current to gup(), this is doesn't
hurt but unnecessary and misleading. "tsk" is only used to account
the number of faults and current is the random workqueue thread.
Signed-off-by: Oleg Nesterov
---
virt/kvm/async_pf.c |2 +-
1 files change
On 04/24, Christian Borntraeger wrote:
>
> On 21/04/14 15:25, Oleg Nesterov wrote:
> > Hello.
> >
> > Completely untested and I know nothing about kvm ;) Please review.
> >
> > But use_mm() really looks misleading, and the usage of mm_users looks
> > &qu
On 04/22, Christian Borntraeger wrote:
>
> On 22/04/14 22:15, Christian Borntraeger wrote:
> > On 21/04/14 15:25, Oleg Nesterov wrote:
> >> async_pf_execute() has no reasons to adopt apf->mm, gup(current, mm)
> >> should work just fine even if current has another
Hello.
Completely untested and I know nothing about kvm ;) Please review.
But use_mm() really looks misleading, and the usage of mm_users looks
"obviously wrong". I already sent this change while we were discussing
vmacache, but it was ignored. Since then kvm_async_page_present_sync()
was added i
m_count too but this case looks
fine at first glance, it seems that this ->mm is only used to verify that
current->mm == kvm->mm.
Signed-off-by: Oleg Nesterov
---
virt/kvm/async_pf.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/async_pf.c b/v
async_pf_execute() has no reasons to adopt apf->mm, gup(current, mm)
should work just fine even if current has another or NULL ->mm.
Recently kvm_async_page_present_sync() was added insedie the "use_mm"
section, but it seems that it doesn't need current->mm too.
Sign
On 08/01, Michael S. Tsirkin wrote:
>
> Oleg, I mean Ack the exporting of get/set affinity.
Ah, I misunderstood.
Yes, I believe the exporting is the lesser evil. Please feel free
to add my ack.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to m
Sorry for the delay, I can't be responsive these days...
On 07/27, Michael S. Tsirkin wrote:
>
> On Mon, Jul 26, 2010 at 08:08:34PM +0200, Oleg Nesterov wrote:
> > On 07/26, Sridhar Samudrala wrote:
> > >
> > > I have been testing out a similar patc
On 07/26, Sridhar Samudrala wrote:
>
> I have been testing out a similar patch that uses kernel_thread() without
> CLONE_FILES
> flag rather than create_kthread() and then closing the files.
!CLONE_FILES can't help. copy_files() does dup_fd() in this case.
The child still inherits the files.
> E
On 07/14, Sridhar Samudrala wrote:
>
> OK. So we want to create a thread that is a child of kthreadd, but inherits
> the cgroup/cpumask
> from the caller. How about an exported kthread function
> kthread_create_in_current_cg()
> that does this?
Well. I must admit, this looks a bit strange to me
On 07/02, Peter Zijlstra wrote:
>
> On Fri, 2010-07-02 at 11:01 -0700, Sridhar Samudrala wrote:
> >
> > Does it (Tejun's kthread_clone() patch) also inherit the
> > cgroup of the caller?
>
> Of course, its a simple do_fork() which inherits everything just as you
> would expect from a similar sys
On 07/01, Tejun Heo wrote:
>
> All that's necessary is shortcutting indirection through kthreadd.
> ie. An exported function which looks like the following,
>
> struct kthread_clone_or_whatever(int (*threadfn).)
> {
> struct kthread_create_info create;
> int pid;
>
> INIT cr
On 07/01, Peter Zijlstra wrote:
>
> On Thu, 2010-07-01 at 16:08 +0300, Michael S. Tsirkin wrote:
> > Maybe it makes sense to add kthread_clone (in addition to
> > kthread_create) that would do what you suggest?
> > If yes, any hints on an implementation?
>
> I think that's called kernel_thread() se
On 05/31, Tejun Heo wrote:
>
> On 05/31/2010 04:39 PM, Oleg Nesterov wrote:
>
> > What I can't understand is why we do have ->queue_seq and ->done_seq.
> >
> > Isn't the single "bool poll->active" enough? vhost_poll_queue() sets
> > -
On 05/30, Tejun Heo wrote:
>
> This conversion is to make each vhost use a dedicated kthread so that
> resource control via cgroup can be applied.
Personally, I agree. I think This is better than play with workqueue thread.
A couple of simple questions after the quick glance at the unapplied patc
What I am actually worried about is Tejun's rework, I am not sure
cmwq has the "this thread services that wq" property...
On 05/27, Sridhar Samudrala wrote:
>
> On Thu, 2010-05-27 at 14:44 +0200, Oleg Nesterov wrote:
> >
> > Instead, cgroup.c (or whoever need
On 05/27, Michael S. Tsirkin wrote:
>
> On Thu, May 27, 2010 at 02:44:48PM +0200, Oleg Nesterov wrote:
> > On 05/27, Michael S. Tsirkin wrote:
> > >
> > > On Tue, May 18, 2010 at 05:04:51PM -0700, Sridhar Samudrala wrote:
> > > > Add a new kernel API to
On 05/27, Michael S. Tsirkin wrote:
>
> On Tue, May 18, 2010 at 05:04:51PM -0700, Sridhar Samudrala wrote:
> > Add a new kernel API to create a singlethread workqueue and attach it's
> > task to current task's cgroup and cpumask.
> >
> > Signed-off-by: Sridhar Samudrala
>
> Could someone familiar
On 07/21, Oleg Nesterov wrote:
>
> On 07/20, Roland McGrath wrote:
> >
> > You do need to clear si_overrun there to be correct in the usual case
> > (not already queued).
>
> Indeed, I missed that. Can't we do this in send_sigqueue() ?
The more I look at the
On 07/20, Roland McGrath wrote:
>
> > Yes, thanks, I see. But does it have any meaning for the user-space?
> [si_sys_private]
>
> No, it's not part of the user ABI. It's not even copied out (see
> copy_siginfo_to_user).
Heh, I didn't know, thanks.
> > Let me repeat. Can't we make a simple fix fo
On 07/20, Oleg Nesterov wrote:
>
> Suppose that the signal was already dequeued but sigq->info wasn't copied
> to the user-space.
To avoid a possible confusion: this is of course fine by itself, the content
of sigq->info was already copied to the local siginfo.
Oleg.
--
To u
On 07/19, Roland McGrath wrote:
>
> I think the solution we want is to make sure that a timer whose
> expiration signal is still pending never gets a second notification.
>
> POSIX says, "The effect of disarming or resetting a timer with pending
> expiration notifications is unspecified." This giv
On 07/18, Mark McLoughlin wrote:
>
> On Thu, 2008-07-17 at 17:55 +0400, Oleg Nesterov wrote:
>
> > I forgot (if ever knew ;) this code completely, but can't we make a simpler
> > fix? posix_timer_event() can check list_empty() lockless,
> &g
On 07/17, Mark McLoughlin wrote:
>
> On Wed, 2008-07-16 at 20:21 +0400, Oleg Nesterov wrote:
> > On 07/16, Mark McLoughlin wrote:
> > >
> > > When a timer fires, posix_timer_event() zeroes out its
> > > pre-allocated siginfo structure, initialises it a
s better to modify posix_timer_event()
to check !list_empty()?
Add Thomas.
Oleg.
> Manually sending the process a SIGALRM
> kicks it out of this state.
>
> The fix is simple - only modify the pre-allocated sigqueue
> once we're sure that it hasn't already been q
58 matches
Mail list logo
