* Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
From: Marcelo Tosatti @ 2018-10-06 20:27 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Wanpeng Li, Florian Weimer, Juergen Gross, Arnd Bergmann,
Radim Krcmar, Peter Zijlstra, X86 ML, LKML, Linux Virtualization,
Stephen Boyd, John Stultz, devel, Paolo Bonzini, Thomas Gleixner,
Matt Rickard
In-Reply-To: <CALCETrXNKCNZzUXj=2sp1vBd_o7HHzfW6RwyY5v3-wMfbVaZnQ@mail.gmail.com>
On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> For better or for worse, I'm trying to understand this code. So far,
> I've come up with this patch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf
>
> Is it correct, or am I missing some subtlety?
The master clock, when initialized, has a pair
masterclockvalues=(TSC value, time-of-day data).
When updating the guest clock, we only update relative to (TSC value)
that was read on masterclock initialization.
See the following comment on x86.c:
/*
*
* Assuming a stable TSC across physical CPUS, and a stable TSC
* across virtual CPUs, the following condition is possible.
* Each numbered line represents an event visible to both
* CPUs at the next numbered event.
...
When updating the "masterclockvalues" pair, all vcpus are
stopped.
^ permalink raw reply
* Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
From: Marcelo Tosatti @ 2018-10-06 20:49 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Wanpeng Li, Florian Weimer, Juergen Gross, Arnd Bergmann,
Radim Krcmar, Peter Zijlstra, X86 ML, LKML, Linux Virtualization,
Stephen Boyd, John Stultz, devel, Paolo Bonzini, Thomas Gleixner,
Matt Rickard
In-Reply-To: <CALCETrXNKCNZzUXj=2sp1vBd_o7HHzfW6RwyY5v3-wMfbVaZnQ@mail.gmail.com>
On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> For better or for worse, I'm trying to understand this code. So far,
> I've come up with this patch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf
>
> Is it correct, or am I missing some subtlety?
"In the non-fallback case, a bunch of gnarly arithmetic is done: a
hopefully matched pair of (TSC, boot time) is read, then all locks
are dropped, then the TSC frequency is read, a branch new multiplier
and shift is read, and the result is turned into a time.
This seems quite racy to me. Because locks are not held, I don't
see what keeps TSC frequency used in sync with the master clock
data."
If tsc_khz changes, the host TSC clocksource will not be used, which
disables masterclock:
if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
(val == CPUFREQ_POSTCHANGE && freq->old >
freq->new)) {
*lpj = cpufreq_scale(loops_per_jiffy_ref, ref_freq,
freq->new);
tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq,
freq->new);
if (!(freq->flags & CPUFREQ_CONST_LOOPS))
mark_tsc_unstable("cpufreq changes");
In which case it ends up in:
- spin_lock(&ka->pvclock_gtod_sync_lock);
- if (!ka->use_master_clock) {
- spin_unlock(&ka->pvclock_gtod_sync_lock);
- return ktime_get_boot_ns() + ka->kvmclock_offset;
- }
masterclock -> non masterclock transition sets
a REQUEST bit on each vCPU, so as to invalidate any previous
clock reads.
static void kvm_gen_update_masterclock(struct kvm *kvm)
{
#ifdef CONFIG_X86_64
int i;
struct kvm_vcpu *vcpu;
struct kvm_arch *ka = &kvm->arch;
spin_lock(&ka->pvclock_gtod_sync_lock);
kvm_make_mclock_inprogress_request(kvm);
/* no guest entries from this point */
pvclock_update_vm_gtod_copy(kvm);
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
/* guest entries allowed */
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu);
spin_unlock(&ka->pvclock_gtod_sync_lock);
#endif
/*
* If the host uses TSC clock, then passthrough TSC as stable
* to the guest.
*/
host_tsc_clocksource = kvm_get_time_and_clockread(
&ka->master_kernel_ns,
&ka->master_cycle_now);
ka->use_master_clock = host_tsc_clocksource && vcpus_matched
&& !ka->backwards_tsc_observed
&& !ka->boot_vcpu_runs_old_kvmclock;
^ permalink raw reply
* Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
From: Andy Lutomirski @ 2018-10-06 22:28 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Wanpeng Li, Florian Weimer, Juergen Gross, Arnd Bergmann,
Radim Krcmar, Peter Zijlstra, X86 ML, LKML, Linux Virtualization,
Stephen Boyd, John Stultz, Andrew Lutomirski, devel,
Paolo Bonzini, Thomas Gleixner, Matt Rickard
In-Reply-To: <20181006202731.GC7129@amt.cnet>
On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti@redhat.com> wrote:
>
> On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > For better or for worse, I'm trying to understand this code. So far,
> > I've come up with this patch:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf
> >
> > Is it correct, or am I missing some subtlety?
>
> The master clock, when initialized, has a pair
>
> masterclockvalues=(TSC value, time-of-day data).
>
> When updating the guest clock, we only update relative to (TSC value)
> that was read on masterclock initialization.
I don't see the problem. The masterclock data is updated here:
host_tsc_clocksource = kvm_get_time_and_clockread(
&ka->master_kernel_ns,
&ka->master_cycle_now);
kvm_get_time_and_clockread() gets those values from
do_monotonic_boot(), which, barring bugs, should cause
get_kvmclock_ns() to return exactly the same thing as
ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather
roundabout manner.
So what am I missing? Is there actually something wrong with my patch?
>
> See the following comment on x86.c:
I read that comment, and it's not obvious to me how it's related.
^ permalink raw reply
* PROPOSAL: Extend inline asm syntax with size spec
From: Borislav Petkov @ 2018-10-07 9:18 UTC (permalink / raw)
To: gcc, Richard Biener, Michael Matz
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Thomas Gleixner, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Josh Poimboeuf, Alok Kataria,
Juergen Gross, Chris Zankel, Max Filippov, Greg Kroah-Hartman,
linux-kernel, Philippe Ombredanne, Linus Torvalds
In-Reply-To: <20181003213100.189959-1-namit@vmware.com>
Hi people,
this is an attempt to see whether gcc's inline asm heuristic when
estimating inline asm statements' cost for better inlining can be
improved.
AFAIU, the problematic arises when one ends up using a lot of inline
asm statements in the kernel but due to the inline asm cost estimation
heuristic which counts lines, I think, for example like in this here
macro:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/cpufeature.h#n162
the resulting code ends up not inlining the functions themselves which
use this macro. I.e., you see a CALL <function> instead of its body
getting inlined directly.
Even though it should be because the actual instructions are only a
couple in most cases and all those other directives end up in another
section anyway.
The issue is explained below in the forwarded mail in a larger detail
too.
Now, Richard suggested doing something like:
1) inline asm ("...")
2) asm ("..." : : : : <size-expr>)
3) asm ("...") __attribute__((asm_size(<size-expr>)));
with which user can tell gcc what the size of that inline asm statement
is and thus allow for more precise cost estimation and in the end better
inlining.
And FWIW 3) looks pretty straight-forward to me because attributes are
pretty common anyways.
But I'm sure there are other options and I'm sure people will have
better/different ideas so feel free to chime in.
Thx.
On Wed, Oct 03, 2018 at 02:30:50PM -0700, Nadav Amit wrote:
> This patch-set deals with an interesting yet stupid problem: kernel code
> that does not get inlined despite its simplicity. There are several
> causes for this behavior: "cold" attribute on __init, different function
> optimization levels; conditional constant computations based on
> __builtin_constant_p(); and finally large inline assembly blocks.
>
> This patch-set deals with the inline assembly problem. I separated these
> patches from the others (that were sent in the RFC) for easier
> inclusion. I also separated the removal of unnecessary new-lines which
> would be sent separately.
>
> The problem with inline assembly is that inline assembly is often used
> by the kernel for things that are other than code - for example,
> assembly directives and data. GCC however is oblivious to the content of
> the blocks and assumes their cost in space and time is proportional to
> the number of the perceived assembly "instruction", according to the
> number of newlines and semicolons. Alternatives, paravirt and other
> mechanisms are affected, causing code not to be inlined, and degrading
> compilation quality in general.
>
> The solution that this patch-set carries for this problem is to create
> an assembly macro, and then call it from the inline assembly block. As
> a result, the compiler sees a single "instruction" and assigns the more
> appropriate cost to the code.
>
> To avoid uglification of the code, as many noted, the macros are first
> precompiled into an assembly file, which is later assembled together
> with the C files. This also enables to avoid duplicate implementation
> that was set before for the asm and C code. This can be seen in the
> exception table changes.
>
> Overall this patch-set slightly increases the kernel size (my build was
> done using my Ubuntu 18.04 config + localyesconfig for the record):
>
> text data bss dec hex filename
> 18140829 10224724 2957312 31322865 1ddf2f1 ./vmlinux before
> 18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+0.1%)
>
> The number of static functions in the image is reduced by 379, but
> actually inlining is even better, which does not always shows in these
> numbers: a function may be inlined causing the calling function not to
> be inlined.
>
> I ran some limited number of benchmarks, and in general the performance
> impact is not very notable. You can still see >10 cycles shaved off some
> syscalls that manipulate page-tables (e.g., mprotect()), in which
> paravirt caused many functions not to be inlined. In addition this
> patch-set can prevent issues such as [1], and improves code readability
> and maintainability.
>
> Update: Rasmus recently caused me (inadvertently) to become paranoid
> about the dependencies. To clarify: if any of the headers changes, any c
> file which uses macros that are included in macros.S would be fine as
> long as it includes the header as well (as it should). Adding an
> assertion to check this is done might become slightly ugly, and nobody
> else is concerned about it. Another minor issue is that changes of
> macros.S would not trigger a global rebuild, but that is pretty similar
> to changes of the Makefile that do not trigger a rebuild.
>
> [1] https://patchwork.kernel.org/patch/10450037/
>
> v8->v9: * Restoring the '-pipe' parameter (Rasmus)
> * Adding Kees's tested-by tag (Kees)
>
> v7->v8: * Add acks (Masahiro, Max)
> * Rebase on 4.19 (Ingo)
>
> v6->v7: * Fix context switch tracking (Ingo)
> * Fix xtensa build error (Ingo)
> * Rebase on 4.18-rc8
>
> v5->v6: * Removing more code from jump-labels (PeterZ)
> * Fix build issue on i386 (0-day, PeterZ)
>
> v4->v5: * Makefile fixes (Masahiro, Sam)
>
> v3->v4: * Changed naming of macros in 2 patches (PeterZ)
> * Minor cleanup of the paravirt patch
>
> v2->v3: * Several build issues resolved (0-day)
> * Wrong comments fix (Josh)
> * Change asm vs C order in refcount (Kees)
>
> v1->v2: * Compiling the macros into a separate .s file, improving
> readability (Linus)
> * Improving assembly formatting, applying most of the comments
> according to my judgment (Jan)
> * Adding exception-table, cpufeature and jump-labels
> * Removing new-line cleanup; to be submitted separately
>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Alok Kataria <akataria@vmware.com>
> Cc: Christopher Li <sparse@chrisli.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Jan Beulich <JBeulich@suse.com>
> Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Kate Stewart <kstewart@linuxfoundation.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: linux-sparse@vger.kernel.org
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Philippe Ombredanne <pombredanne@nexb.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: virtualization@lists.linux-foundation.org
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: x86@kernel.org
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: linux-xtensa@linux-xtensa.org
>
> Nadav Amit (10):
> xtensa: defining LINKER_SCRIPT for the linker script
> Makefile: Prepare for using macros for inline asm
> x86: objtool: use asm macro for better compiler decisions
> x86: refcount: prevent gcc distortions
> x86: alternatives: macrofy locks for better inlining
> x86: bug: prevent gcc distortions
> x86: prevent inline distortion by paravirt ops
> x86: extable: use macros instead of inline assembly
> x86: cpufeature: use macros instead of inline assembly
> x86: jump-labels: use macros instead of inline assembly
>
> Makefile | 9 ++-
> arch/x86/Makefile | 7 ++
> arch/x86/entry/calling.h | 2 +-
> arch/x86/include/asm/alternative-asm.h | 20 ++++--
> arch/x86/include/asm/alternative.h | 11 +--
> arch/x86/include/asm/asm.h | 61 +++++++---------
> arch/x86/include/asm/bug.h | 98 +++++++++++++++-----------
> arch/x86/include/asm/cpufeature.h | 82 ++++++++++++---------
> arch/x86/include/asm/jump_label.h | 77 ++++++++------------
> arch/x86/include/asm/paravirt_types.h | 56 +++++++--------
> arch/x86/include/asm/refcount.h | 74 +++++++++++--------
> arch/x86/kernel/macros.S | 16 +++++
> arch/xtensa/kernel/Makefile | 4 +-
> include/asm-generic/bug.h | 8 +--
> include/linux/compiler.h | 56 +++++++++++----
> scripts/Kbuild.include | 4 +-
> scripts/mod/Makefile | 2 +
> 17 files changed, 331 insertions(+), 256 deletions(-)
> create mode 100644 arch/x86/kernel/macros.S
>
> --
> 2.17.1
>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Borislav Petkov @ 2018-10-07 14:13 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Thomas Gleixner, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Chris Zankel, Michael Matz,
Josh Poimboeuf, Alok Kataria, Juergen Gross, gcc, Richard Biener,
Max Filippov, Greg Kroah-Hartman, linux-kernel, Philippe
In-Reply-To: <20181007132228.GJ29268@gate.crashing.org>
On Sun, Oct 07, 2018 at 08:22:28AM -0500, Segher Boessenkool wrote:
> GCC already estimates the *size* of inline asm, and this is required
> *for correctness*.
I didn't say it didn't - but the heuristic could use improving.
> So I guess the real issue is that the inline asm size estimate for x86
> isn't very good (since it has to be pessimistic, and x86 insns can be
> huge)?
Well, the size thing could be just a "parameter" or "hint" of sorts, to
tell gcc to inline the function X which is inlining the asm statement
into the function Y which is calling function X. If you look at the
patchset, it is moving everything to asm macros where gcc is apparently
able to do better inlining.
> > 3) asm ("...") __attribute__((asm_size(<size-expr>)));
>
> Eww.
Why?
> More precise *size* estimates, yes. And if the user lies he should not
> be surprised to get assembler errors, etc.
Yes.
Another option would be if gcc parses the inline asm directly and
does a more precise size estimation. Which is a lot more involved and
complicated solution so I guess we wanna look at the simpler ones first.
:-)
> I don't like 2) either. But 1) looks interesting, depends what its
> semantics would be? "Don't count this insn's size for inlining decisions",
> maybe?
Or simply "this asm statement has a size of 1" to mean, inline it
everywhere. Which has the same caveats as above.
> Another option is to just force inlining for those few functions where
> GCC currently makes an inlining decision you don't like. Or are there
> more than a few?
I'm afraid they're more than a few and this should work automatically,
if possible.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH net V2] vhost-vsock: fix use after free
From: Jason Wang @ 2018-10-08 2:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, sergei.shtylyov, netdev, linux-kernel, virtualization,
stefanha
In-Reply-To: <20180927194734-mutt-send-email-mst@kernel.org>
On 2018年09月28日 07:50, Michael S. Tsirkin wrote:
> On Fri, Sep 28, 2018 at 07:37:37AM +0800, Jason Wang wrote:
>>
>> On 2018年09月28日 01:04, Michael S. Tsirkin wrote:
>>> On Thu, Sep 27, 2018 at 08:22:04PM +0800, Jason Wang wrote:
>>>> The access of vsock is not protected by vhost_vsock_lock. This may
>>>> lead to use after free since vhost_vsock_dev_release() may free the
>>>> pointer at the same time.
>>>>
>>>> Fix this by holding the lock during the access.
>>>>
>>>> Reported-by:syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
>>>> Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
>>>> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
>>>> Cc: Stefan Hajnoczi<stefanha@redhat.com>
>>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>>> Wow is that really the best we can do?
>> For net/stable, probably yes.
>>
>>> A global lock on a data path
>>> operation?
>> It's already there,
> &vhost_vsock_lock? were is it takes on data path?
Ok, but the current code use list which means a global lock is needed
anyway here.
>
>> and the patch only increase the critical section.
>>
>>> Granted use after free is nasty but Stefan said he sees
>>> a way to fix it using a per socket refcount. He's on vacation
>>> until Oct 4 though ...
>>>
>> Stefan has acked the pacth, so I think it's ok? We can do optimization for
>> -next on top.
>>
>> Thanks
>
> Well on high SMP serializing can drop performance as much as x100 so I'm
> not sure it's appropriate - seems to fix a bug but can introduce a
> regression. Let's see how does a proper fix look first?
>
It looks to me hlist + RCU is better. But I'm not sure it's suitable for
-net/-stable.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Ingo Molnar @ 2018-10-08 5:58 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Thomas Gleixner, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Chris Zankel, Michael Matz,
Borislav Petkov, Josh Poimboeuf, Alok Kataria, Juergen Gross, gcc,
Richard Biener, Max Filippov, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20181007151427.GK29268@gate.crashing.org>
* Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > > More precise *size* estimates, yes. And if the user lies he should not
> > > be surprised to get assembler errors, etc.
> >
> > Yes.
> >
> > Another option would be if gcc parses the inline asm directly and
> > does a more precise size estimation. Which is a lot more involved and
> > complicated solution so I guess we wanna look at the simpler ones first.
> >
> > :-)
>
> Which is *impossible* to do. Inline assembler is free-form text.
"Impossible" is false: only under GCC's model and semantics of inline
asm that is, and only under the (false) assumption that the semantics
of the asm statement (which is a GCC extension to begin with) cannot
be changed like it has been changed multiple times in the past.
"Difficult", "not worth our while", perhaps.
Thanks,
Ingo
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Ingo Molnar @ 2018-10-08 6:13 UTC (permalink / raw)
To: Michael Matz
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Thomas Gleixner, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Segher Boessenkool, Chris Zankel,
Borislav Petkov, Josh Poimboeuf, Alok Kataria, Juergen Gross, gcc,
Richard Biener, Max Filippov, Greg Kroah-Hartman
In-Reply-To: <alpine.LSU.2.21.1810071534220.7867@wotan.suse.de>
* Michael Matz <matz@suse.de> wrote:
> (without an built-in assembler which hopefully noone proposes).
There are disadvantages (the main one is having to implement it), but a built-in assembler has
numerous advantages as well:
- Better optimizations: for example -Os could more accurately estimate true instruction size.
- Better inlining: as the examples in this thread are showing.
- Better padding/alignment: right now GCC has no notion about the precise cache layout of the
assembly code it generates and the code alignment options it has are crude. It got away with
this so far because the x86 rule of thumb is that dense code is usually the right choice.
- Better compiler performance: it would be faster as well to immediately emit assembly
instructions, just like GCC's preprocessor library use speeds up compilation *significantly*
instead of creating a separate preprocessor task.
- Better future integration of assembly blocks: GCC could begin to actually understand the
assembly statements in inline asm and allow more user-friendly extensions to its
historically complex and difficult to master inline asm syntax.
I mean, it's a fact that the GNU project has *already* defined their own assembly syntax which
departs from decades old platform assembly syntax - and how the assembler is called by the
compiler is basically an implementation detail, not a conceptual choice. The random
multi-process unidirectional assembler choice of the past should not be treated as orthodoxy.
Thanks,
Ingo
^ permalink raw reply
* [RFC] VSOCK: About Virtio-vsock support "Multiqueue" feature ?
From: jiangyiwen @ 2018-10-08 7:06 UTC (permalink / raw)
To: stefanha; +Cc: netdev, kvm, virtualization
Hi Stefan & All:
Now virtio-vsock only supports two vqs(tx and rx), that means
if multiple sockets in the guest will use the same vq to transmit
the message and get the response. In this way, the bandwidth will
be limited to ~700MB/s. So if there are multiple applications in
the guest, we should support "Multiqueue" feature for Virtio-vsock.
I want to know whether we already have plans to support multiqueue
or already have simple demo that can be used. If not, I will try
to implement this feature.
Thanks,
Yiwen.
^ permalink raw reply
* Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
From: Marcelo Tosatti @ 2018-10-08 15:26 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Wanpeng Li, Florian Weimer, Juergen Gross, Arnd Bergmann,
Radim Krcmar, Peter Zijlstra, X86 ML, LKML, Linux Virtualization,
Stephen Boyd, John Stultz, devel, Paolo Bonzini, Thomas Gleixner,
Matt Rickard
In-Reply-To: <CALCETrWqze2mifOdFc0GJYHtHGKiKX2Zdi5Kz87OyUogbqD15w@mail.gmail.com>
On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti@redhat.com> wrote:
> >
> > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > > For better or for worse, I'm trying to understand this code. So far,
> > > I've come up with this patch:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf
> > >
> > > Is it correct, or am I missing some subtlety?
> >
> > The master clock, when initialized, has a pair
> >
> > masterclockvalues=(TSC value, time-of-day data).
> >
> > When updating the guest clock, we only update relative to (TSC value)
> > that was read on masterclock initialization.
>
> I don't see the problem. The masterclock data is updated here:
>
> host_tsc_clocksource = kvm_get_time_and_clockread(
> &ka->master_kernel_ns,
> &ka->master_cycle_now);
>
> kvm_get_time_and_clockread() gets those values from
> do_monotonic_boot(), which, barring bugs, should cause
> get_kvmclock_ns() to return exactly the same thing as
> ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather
> roundabout manner.
>
> So what am I missing? Is there actually something wrong with my patch?
For the bug mentioned in the comment not to happen, you must only read
TSC and add it as offset to (TSC value, time-of-day data).
Its more than "a roundabout manner".
Read the comment again.
>
>
> >
> > See the following comment on x86.c:
>
> I read that comment, and it's not obvious to me how it's related.
^ permalink raw reply
* RE: PROPOSAL: Extend inline asm syntax with size spec
From: David Laight @ 2018-10-08 16:24 UTC (permalink / raw)
To: 'Michael Matz', Segher Boessenkool
Cc: Kate Stewart, Peter Zijlstra, Christopher Li,
virtualization@lists.linux-foundation.org, Masahiro Yamada,
Nadav Amit, Jan Beulich, H. Peter Anvin, Sam Ravnborg,
Thomas Gleixner, x86@kernel.org, linux-sparse@vger.kernel.org,
Ingo Molnar, linux-xtensa@linux-xtensa.org, Kees Cook,
Chris Zankel, Borislav Petkov, Josh Poimboeuf, Alok Kataria,
Juergen Gross, gcc@gcc.gnu.org, Richard
In-Reply-To: <alpine.LSU.2.21.1810071534220.7867@wotan.suse.de>
From: Michael Matz
> Sent: 07 October 2018 16:53
...
> I think the examples I saw from Boris were all indirect inlines:
>
> static inline void foo() { asm("large-looking-but-small-asm"); }
> static void bar1() { ... foo() ... }
> static void bar2() { ... foo() ... }
> void goo (void) { bar1(); } // bar1 should have been inlined
>
> So, while the immediate asm user was marked as always inline that in turn
> caused users of it to become non-inlined. I'm assuming the kernel guys
> did proper measurements that they _really_ get some non-trivial speed
> benefit by inlining bar1/bar2, but for some reasons (I didn't inquire)
> didn't want to mark them all as inline as well.
Could you add a 'size' attribute to the 'always inlined' foo() above
rather than trying to add one to the asm() statement itself.
Then add a warning in the documentation that small size attributes
might make the assembly fail due to limited branch offsets (etc).
Size '1' probably ought to be reserved for things that definitely
fit in a delay slot.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
From: Andy Lutomirski @ 2018-10-08 17:38 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Wanpeng Li, Florian Weimer, Juergen Gross, Arnd Bergmann,
Radim Krcmar, Peter Zijlstra, X86 ML, LKML, Linux Virtualization,
Stephen Boyd, John Stultz, Andrew Lutomirski, devel,
Paolo Bonzini, Thomas Gleixner, Matt Rickard
In-Reply-To: <20181008152650.GB27822@amt.cnet>
On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti@redhat.com> wrote:
>
> On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > >
> > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > > > For better or for worse, I'm trying to understand this code. So far,
> > > > I've come up with this patch:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf
> > > >
> > > > Is it correct, or am I missing some subtlety?
> > >
> > > The master clock, when initialized, has a pair
> > >
> > > masterclockvalues=(TSC value, time-of-day data).
> > >
> > > When updating the guest clock, we only update relative to (TSC value)
> > > that was read on masterclock initialization.
> >
> > I don't see the problem. The masterclock data is updated here:
> >
> > host_tsc_clocksource = kvm_get_time_and_clockread(
> > &ka->master_kernel_ns,
> > &ka->master_cycle_now);
> >
> > kvm_get_time_and_clockread() gets those values from
> > do_monotonic_boot(), which, barring bugs, should cause
> > get_kvmclock_ns() to return exactly the same thing as
> > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather
> > roundabout manner.
> >
> > So what am I missing? Is there actually something wrong with my patch?
>
> For the bug mentioned in the comment not to happen, you must only read
> TSC and add it as offset to (TSC value, time-of-day data).
>
> Its more than "a roundabout manner".
>
> Read the comment again.
>
I read the comment three more times and even dug through the git
history. It seems like what you're saying is that, under certain
conditions (which arguably would be bugs in the core Linux timing
code), actually calling ktime_get_boot_ns() could be non-monotonic
with respect to the kvmclock timing. But get_kvmclock_ns() isn't used
for VM timing as such -- it's used for the IOCTL interfaces for
updating the time offset. So can you explain how my patch is
incorrect?
--Andy
^ permalink raw reply
* Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
From: Marcelo Tosatti @ 2018-10-08 19:36 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Wanpeng Li, Florian Weimer, Juergen Gross, Arnd Bergmann,
Radim Krcmar, Peter Zijlstra, X86 ML, LKML, Linux Virtualization,
Stephen Boyd, John Stultz, devel, Paolo Bonzini, Thomas Gleixner,
Matt Rickard
In-Reply-To: <CALCETrVY6VHPLs0GXZM4+VYraTa1+xs=iRJoRa++OHX9Wq+ieg@mail.gmail.com>
On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti@redhat.com> wrote:
> >
> > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote:
> > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > > >
> > > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote:
> > > > > For better or for worse, I'm trying to understand this code. So far,
> > > > > I've come up with this patch:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf
> > > > >
> > > > > Is it correct, or am I missing some subtlety?
> > > >
> > > > The master clock, when initialized, has a pair
> > > >
> > > > masterclockvalues=(TSC value, time-of-day data).
> > > >
> > > > When updating the guest clock, we only update relative to (TSC value)
> > > > that was read on masterclock initialization.
> > >
> > > I don't see the problem. The masterclock data is updated here:
> > >
> > > host_tsc_clocksource = kvm_get_time_and_clockread(
> > > &ka->master_kernel_ns,
> > > &ka->master_cycle_now);
> > >
> > > kvm_get_time_and_clockread() gets those values from
> > > do_monotonic_boot(), which, barring bugs, should cause
> > > get_kvmclock_ns() to return exactly the same thing as
> > > ktime_get_boot_ns() + ka->kvmclock_offset, albeit in a rather
> > > roundabout manner.
> > >
> > > So what am I missing? Is there actually something wrong with my patch?
> >
> > For the bug mentioned in the comment not to happen, you must only read
> > TSC and add it as offset to (TSC value, time-of-day data).
> >
> > Its more than "a roundabout manner".
> >
> > Read the comment again.
> >
>
> I read the comment three more times and even dug through the git
> history. It seems like what you're saying is that, under certain
> conditions (which arguably would be bugs in the core Linux timing
> code),
I don't see that as a bug. Its just a side effect of reading two
different clocks (one is CLOCK_MONOTONIC and the other is TSC),
and using those two clocks to as a "base + offset".
As the comment explains, if you do that, can't guarantee monotonicity.
> actually calling ktime_get_boot_ns() could be non-monotonic
> with respect to the kvmclock timing. But get_kvmclock_ns() isn't used
> for VM timing as such -- it's used for the IOCTL interfaces for
> updating the time offset. So can you explain how my patch is
> incorrect?
ktime_get_boot_ns() has frequency correction applied, while
reading masterclock + TSC offset does not.
So the clock reads differ.
^ permalink raw reply
* [PATCH net-next V3] virtio_net: ethtool tx napi configuration
From: Jason Wang @ 2018-10-09 2:06 UTC (permalink / raw)
To: mst, jasowang, davem
Cc: netdev, Willem de Bruijn, linux-kernel, virtualization
Implement ethtool .set_coalesce (-C) and .get_coalesce (-c) handlers.
Interrupt moderation is currently not supported, so these accept and
display the default settings of 0 usec and 1 frame.
Toggle tx napi through setting tx-frames. So as to not interfere
with possible future interrupt moderation, value 1 means tx napi while
value 0 means not.
Only allow the switching when device is down for simplicity.
Link: https://patchwork.ozlabs.org/patch/948149/
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V2:
- only allow the switching when device is done
- remove unnecessary global variable and initialization
Changes from V1:
- try to synchronize with datapath to allow changing mode when
interface is up.
- use tx-frames 0 as to disable tx napi while tx-frames 1 to enable tx napi
---
drivers/net/virtio_net.c | 50 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 765920905226..751f385f4e0a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2181,6 +2181,54 @@ static int virtnet_get_link_ksettings(struct net_device *dev,
return 0;
}
+static int virtnet_set_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ec)
+{
+ struct ethtool_coalesce ec_default = {
+ .cmd = ETHTOOL_SCOALESCE,
+ .rx_max_coalesced_frames = 1,
+ };
+ struct virtnet_info *vi = netdev_priv(dev);
+ int i, napi_weight;
+ bool running = netif_running(dev);
+
+ if (ec->tx_max_coalesced_frames > 1)
+ return -EINVAL;
+
+ ec_default.tx_max_coalesced_frames = ec->tx_max_coalesced_frames;
+ napi_weight = ec->tx_max_coalesced_frames ? NAPI_POLL_WEIGHT : 0;
+
+ /* disallow changes to fields not explicitly tested above */
+ if (memcmp(ec, &ec_default, sizeof(ec_default)))
+ return -EINVAL;
+
+ if (napi_weight ^ vi->sq[0].napi.weight) {
+ if (dev->flags & IFF_UP)
+ return -EBUSY;
+ for (i = 0; i < vi->max_queue_pairs; i++)
+ vi->sq[i].napi.weight = napi_weight;
+ }
+
+ return 0;
+}
+
+static int virtnet_get_coalesce(struct net_device *dev,
+ struct ethtool_coalesce *ec)
+{
+ struct ethtool_coalesce ec_default = {
+ .cmd = ETHTOOL_GCOALESCE,
+ .rx_max_coalesced_frames = 1,
+ };
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ memcpy(ec, &ec_default, sizeof(ec_default));
+
+ if (vi->sq[0].napi.weight)
+ ec->tx_max_coalesced_frames = 1;
+
+ return 0;
+}
+
static void virtnet_init_settings(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -2219,6 +2267,8 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
.get_ts_info = ethtool_op_get_ts_info,
.get_link_ksettings = virtnet_get_link_ksettings,
.set_link_ksettings = virtnet_set_link_ksettings,
+ .set_coalesce = virtnet_set_coalesce,
+ .get_coalesce = virtnet_get_coalesce,
};
static void virtnet_freeze_down(struct virtio_device *vdev)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] VMCI: Resource wildcard match fixed
From: Jorgen S. Hansen @ 2018-10-09 8:27 UTC (permalink / raw)
To: Greg KH
Cc: pv-drivers, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <20181002223502.GA31116@kroah.com>
[-- Attachment #1.1: Type: text/plain, Size: 1986 bytes --]
On 3 Oct 2018, at 00:35, Greg KH <gregkh@linuxfoundation.org<mailto:gregkh@linuxfoundation.org>> wrote:
On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote:
When adding a VMCI resource, the check for an existing entry
would ignore that the new entry could be a wildcard. This could
result in multiple resource entries that would match a given
handle. One disastrous outcome of this is that the
refcounting used to ensure that delayed callbacks for VMCI
datagrams have run before the datagram is destroyed can be
wrong, since the refcount could be increased on the duplicate
entry. This in turn leads to a use after free bug. This issue
was discovered by Hangbin Liu using KASAN and syzkaller.
Fixes: bc63dedb7d46 ("VMCI: resource object implementation")
Reported-by: Hangbin Liu <liuhangbin@gmail.com<mailto:liuhangbin@gmail.com>>
Reviewed-by: Adit Ranadive <aditr@vmware.com<mailto:aditr@vmware.com>>
Reviewed-by: Vishnu Dasa <vdasa@vmware.com<mailto:vdasa@vmware.com>>
Signed-off-by: Jorgen Hansen <jhansen@vmware.com<mailto:jhansen@vmware.com>>
---
drivers/misc/vmw_vmci/vmci_driver.c | 2 +-
drivers/misc/vmw_vmci/vmci_resource.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c b/drivers/misc/vmw_vmci/vmci_driver.c
index d7eaf1eb11e7..003bfba40758 100644
--- a/drivers/misc/vmw_vmci/vmci_driver.c
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface.");
-MODULE_VERSION("1.1.5.0-k");
+MODULE_VERSION("1.1.6.0-k");
MODULE_LICENSE("GPL v2");
You do know MODULE_VERSION means nothing, right? Please just remove it.
Sure. Do you want a new version of this patch with it removed ? (The reason for asking is that I already got a couple of notifications about the patch being added to char-misc and char-misc-next).
Thanks,
Jorgen
[-- Attachment #1.2: Type: text/html, Size: 5322 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply related
* Re: [PATCH] VMCI: Resource wildcard match fixed
From: Greg KH @ 2018-10-09 8:43 UTC (permalink / raw)
To: Jorgen S. Hansen
Cc: pv-drivers, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <A99A1956-D875-4E55-A344-ED1F3B4FD1E5@vmware.com>
On Tue, Oct 09, 2018 at 08:27:41AM +0000, Jorgen S. Hansen wrote:
>
>
> On 3 Oct 2018, at 00:35, Greg KH <gregkh@linuxfoundation.org<mailto:gregkh@linuxfoundation.org>> wrote:
>
> On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote:
> When adding a VMCI resource, the check for an existing entry
> would ignore that the new entry could be a wildcard. This could
> result in multiple resource entries that would match a given
> handle. One disastrous outcome of this is that the
> refcounting used to ensure that delayed callbacks for VMCI
> datagrams have run before the datagram is destroyed can be
> wrong, since the refcount could be increased on the duplicate
> entry. This in turn leads to a use after free bug. This issue
> was discovered by Hangbin Liu using KASAN and syzkaller.
>
> Fixes: bc63dedb7d46 ("VMCI: resource object implementation")
> Reported-by: Hangbin Liu <liuhangbin@gmail.com<mailto:liuhangbin@gmail.com>>
> Reviewed-by: Adit Ranadive <aditr@vmware.com<mailto:aditr@vmware.com>>
> Reviewed-by: Vishnu Dasa <vdasa@vmware.com<mailto:vdasa@vmware.com>>
> Signed-off-by: Jorgen Hansen <jhansen@vmware.com<mailto:jhansen@vmware.com>>
> ---
> drivers/misc/vmw_vmci/vmci_driver.c | 2 +-
> drivers/misc/vmw_vmci/vmci_resource.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/vmw_vmci/vmci_driver.c b/drivers/misc/vmw_vmci/vmci_driver.c
> index d7eaf1eb11e7..003bfba40758 100644
> --- a/drivers/misc/vmw_vmci/vmci_driver.c
> +++ b/drivers/misc/vmw_vmci/vmci_driver.c
> @@ -113,5 +113,5 @@ module_exit(vmci_drv_exit);
>
> MODULE_AUTHOR("VMware, Inc.");
> MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface.");
> -MODULE_VERSION("1.1.5.0-k");
> +MODULE_VERSION("1.1.6.0-k");
> MODULE_LICENSE("GPL v2");
>
> You do know MODULE_VERSION means nothing, right? Please just remove it.
>
> Sure. Do you want a new version of this patch with it removed ? (The reason for asking is that I already got a couple of notifications about the patch being added to char-misc and char-misc-next).
Just send a follow-on patch that removes it please.
thanks,
greg k-h
^ permalink raw reply
* Call for Workshops - CISTI'2019 - Coimbra, Portugal
From: Maria Lemos @ 2018-10-09 11:21 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 5280 bytes --]
*** Articles indexed by ISI, Scopus, IEEE, etc.
----------------------------------------------------
Call for Workshops:
CISTI'2019 - 14th Iberian Conference on Information Systems and Technologies,
19th and 22th of June 2019, Coimbra, Portugal
http://www.cisti.eu/ <http://www.cisti.eu/>
----------------------------------------------------------------------------------------------------------------
Workshop Format
The Information Systems and Technologies research and industrial community is invited to submit proposals of Workshops for CISTI 2019 – 14th Iberian Conference on Information Systems and Technologies to be held at Coimbra, Portugal, June 19–22, 2019. Two types of Workshops may be proposed: Regular Workshops and Project Workshops.
Regular Workshops should focus on a specific scientific subject on the scope of CISTI 2019 but not directly included on the main conference areas. Each regular workshop will be coordinated by an Organizing Committee composed of, at least, two researchers in the field, preferably from different institutions and different countries. The organizers should create an international Program Committee for the Workshop, with recognized researchers within the specific Workshop scientific area. Each workshop should have at least 10 submissions and 5 accepted papers in order to be conducted at CISTI.
Project Workshops are intended to promote the dissemination and facilitate the future exploitation of EU Latin-American and national project results such as EU/FP7, EU/Horizon2020, CSIC, FCT, QREN, Portugal 2020, Fund. Gulbenkian, CYTED, CAPES, CNPq, FINEP and other Projects/funding sources. The results to be disseminated may be preliminary project results (for unfinished projects) or the project final results (for already finished projects). Each project workshop should be directly related to a Project funded in a competitive manner by a National/International Science Organization. The Workshop should be coordinated by an Organizing Committee composed by at least two researchers including the Principal Investigator of the project. Each Workshop will have 1 article offered for 5 articles with paid subscription, 2 articles offered for 15 articles with paid subscription, and 3 articles offered for 30 articles with paid subscription. The selection of Workshops will be performed by CISTI 2019 Conference Chairs. Workshops full papers will be published in the conference main proceedings in specific Workshop chapters. Proceedings will be submitted for indexation by ISI, SCOPUS, EI-Conpendex, INSPEC and Google Scholar. Detailed and up-to-date information may be found at CISTI 2019 website: http://www.cisti.eu/ <http://www.cisti.eu/>.
Workshop Organization
The Organizing Committee of each Workshop will be responsible for:
* Producing and distributing the Workshop Call for Papers (CFP);
* Coordinating the review and selection process for the papers submitted to the Workshop, as Workshop chairs (on the paper submission system installed for all the Workshops);
* Delivering the final versions of the papers accepted for the Workshop in accordance with the guidelines and deadlines defined by CISTI 2019 organizers;
* Coordinating and chairing the Workshop sessions at the conference.
CISTI 2019 organizers reserve the right to cancel any Workshop if deadlines are missed or if the number of registered attendees is too low to support the costs associated with the Workshop.
Proposal Contents
Regular Workshop proposals should contain the following information:
* Workshop title;
* Brief description of the specific scientific scope of the Workshop;
* List of topics of interest (max 15 topics);
* Reasons the Workshop should be held within CISTI’2019;
* Name, postal address, phone and email of all the members of the Workshop Organizing Committee;
* Proposal for the Workshop Program Committee (Names and affiliations).
Project Workshop proposals should contain the following information:
* Workshop title;
* Project Title, Reference, Principal Investigator, Funding Organization, Total Funding, Consortium, Abstract and Objectives;
* Reasons the Workshop should be held within CISTI’2019;
* Name, postal address, phone and email of all the members of the Workshop Organizing Committee.
Proposals should be submitted electronically (in Word or compatible format) at https://easychair.org/conferences/?conf=cisti2019workshops <https://easychair.org/conferences/?conf=cisti2019workshops>, in English, Portuguese and/or Spanish, by November 26, 2017.
Important Dates
* Deadline for Workshop proposals: November 11, 2018
* Notification of Workshop acceptance: November 18, 2018
* Deadline for paper submission: February 24, 2019
* Notification of paper acceptance: March 26, 2019
* Deadline for final versions and conference registration: April 1, 2019
* Deadline for Workshop final papers delivery to CISTI organizers: April 8, 2019
* Conference dates: June 19-22, 2019
Website of CISTI'2019: http://www.cisti.eu/ <http://www.cisti.eu/>
Kind regards,
AISTI
http://www.aisti.eu/ <http://www.aisti.eu/>
---
This email has been checked for viruses by AVG.
https://www.avg.com
[-- Attachment #1.2: Type: text/html, Size: 7469 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
From: Andy Lutomirski @ 2018-10-09 20:09 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Wanpeng Li, Florian Weimer, Juergen Gross, Arnd Bergmann,
Radim Krcmar, Peter Zijlstra, X86 ML, LKML, Linux Virtualization,
Stephen Boyd, John Stultz, Andrew Lutomirski, devel,
Paolo Bonzini, Thomas Gleixner, Matt Rickard
In-Reply-To: <20181008193632.GA31729@amt.cnet>
On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti <mtosatti@redhat.com> wrote:
>
> On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > I read the comment three more times and even dug through the git
> > history. It seems like what you're saying is that, under certain
> > conditions (which arguably would be bugs in the core Linux timing
> > code),
>
> I don't see that as a bug. Its just a side effect of reading two
> different clocks (one is CLOCK_MONOTONIC and the other is TSC),
> and using those two clocks to as a "base + offset".
>
> As the comment explains, if you do that, can't guarantee monotonicity.
>
> > actually calling ktime_get_boot_ns() could be non-monotonic
> > with respect to the kvmclock timing. But get_kvmclock_ns() isn't used
> > for VM timing as such -- it's used for the IOCTL interfaces for
> > updating the time offset. So can you explain how my patch is
> > incorrect?
>
> ktime_get_boot_ns() has frequency correction applied, while
> reading masterclock + TSC offset does not.
>
> So the clock reads differ.
>
Ah, okay, I finally think I see what's going on. In the kvmclock data
exposed to the guest, tsc_shift and tsc_to_system_mul come from
tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from
CLOCK_BOOTTIME. So the kvmclock and kernel clock drift apart at a
rate given by the frequency shift and then suddenly agree again every
time the pvclock data is updated.
Is there a reason to do it this way?
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Ingo Molnar @ 2018-10-10 6:35 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Thomas Gleixner, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Chris Zankel, Michael Matz,
Borislav Petkov, Josh Poimboeuf, Alok Kataria, Juergen Gross, gcc,
Richard Biener, Max Filippov, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20181009145330.GT29268@gate.crashing.org>
* Segher Boessenkool <segher@kernel.crashing.org> wrote:
> On Mon, Oct 08, 2018 at 11:07:46AM +0200, Richard Biener wrote:
> > On Mon, 8 Oct 2018, Segher Boessenkool wrote:
> > > On Sun, Oct 07, 2018 at 03:53:26PM +0000, Michael Matz wrote:
> > > > On Sun, 7 Oct 2018, Segher Boessenkool wrote:
> > > > > On Sun, Oct 07, 2018 at 11:18:06AM +0200, Borislav Petkov wrote:
> > > > > > Now, Richard suggested doing something like:
> > > > > >
> > > > > > 1) inline asm ("...")
> > > > >
> > > > > What would the semantics of this be?
> > > >
> > > > The size of the inline asm wouldn't be counted towards the inliner size
> > > > limits (or be counted as "1").
> > >
> > > That sounds like a good option.
> >
> > Yes, I also like it for simplicity. It also avoids the requirement
> > of translating the number (in bytes?) given by the user to
> > "number of GIMPLE instructions" as needed by the inliner.
>
> This patch implements this, for C only so far. And the syntax is
> "asm inline", which is more in line with other syntax.
>
> How does this look?
Cool, thanks for implementing this!
In the kernel we'd likely wrap this in some "asm_inline()" type of construct to be
compatible with older toolchains and other compilers.
Thanks,
Ingo
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Ingo Molnar @ 2018-10-10 7:22 UTC (permalink / raw)
To: Richard Biener
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Thomas Gleixner, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Segher Boessenkool, Chris Zankel,
Michael Matz, Borislav Petkov, Josh Poimboeuf, Alok Kataria,
Juergen Gross, gcc, Max Filippov, Greg Kroah-Hartman
In-Reply-To: <alpine.LSU.2.20.1810100909140.16707@zhemvz.fhfr.qr>
* Richard Biener <rguenther@suse.de> wrote:
> Can kernel folks give this a second and third thought please so we
> don't implement sth that in the end won't satisfy you guys?
So this basically passes '0 size' to the inliner, which should be better
than passing in the explicit size, as we'd inevitably get it wrong
in cases.
I also like 'size 0' for the reason that we tend to write assembly code
and mark it 'inline' if we really think it matters to performance,
so making it more likely to be inlined when used within another inline
function is a plus as well.
Does anyone have any concerns about this?
Thanks,
Ingo
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Borislav Petkov @ 2018-10-10 8:19 UTC (permalink / raw)
To: Segher Boessenkool, Ingo Molnar
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Thomas Gleixner, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Chris Zankel, Michael Matz,
Josh Poimboeuf, Alok Kataria, Juergen Gross, gcc, Richard Biener,
Max Filippov, Greg Kroah-Hartman, linux-kernel, Philippe
In-Reply-To: <20181010080324.GV29268@gate.crashing.org>
On Wed, Oct 10, 2018 at 03:03:25AM -0500, Segher Boessenkool wrote:
> The code immediately after this makes it size 1, even for things like
> asm(""), I suppose this works better for the inliner. But that's a detail
> (and it might change); the description says "consider this asm as minimum
> length and cost for inlining decisions", which works for either 0 or 1.
Thanks for implementing this, much appreciated. If you need people to
test stuff, lemme know.
> You can think of it as meaning "we want this asm inlined always", and then
> whether that actually happens depends on if the function around it is
> inlined or not.
My only concern is how we would catch the other extremity where the
inline asm grows too big and we end up inlining it everywhere and thus
getting fat. The 0day bot already builds tinyconfigs but we should be
looking at vmlinux size growth too.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH net-next v2 0/5] virtio: support packed ring
From: Michael S. Tsirkin @ 2018-10-10 14:36 UTC (permalink / raw)
To: Jason Wang; +Cc: virtio-dev, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <98d6bd4d-45e2-4207-e961-782f649e0139@redhat.com>
On Thu, Sep 13, 2018 at 05:47:29PM +0800, Jason Wang wrote:
>
>
> On 2018年09月13日 16:59, Tiwei Bie wrote:
> > > If what you say is true then we should take a careful look
> > > and not supporting these generic things with packed layout.
> > > Once we do support them it will be too late and we won't
> > > be able to get performance back.
> > I think it's a good point that we don't need to support
> > everything in packed ring (especially these which would
> > hurt the performance), as the packed ring aims at high
> > performance. I'm also wondering about the features. Is
> > there any possibility that we won't support the out of
> > order processing (at least not by default) in packed ring?
> > If I didn't miss anything, the need to support out of order
> > processing in packed ring will make the data structure
> > inside the driver not cache friendly which is similar to
> > the case of the descriptor table in the split ring (the
> > difference is that, it only happens in driver now).
>
> Out of order is not the only user, DMA is another one. We don't have used
> ring(len), so we need to maintain buffer length somewhere even for in order
> device.
For a bunch of systems dma unmap is a nop so we do not really
need to maintain it. It's a question of an API to detect that
and optimize for it. I posted a proposed patch for that -
want to try using that?
> But if it's not too late, I second for a OUT_OF_ORDER feature.
> Starting from in order can have much simpler code in driver.
>
> Thanks
It's tricky to change the flag polarity because of compatibility
with legacy interfaces. Why is this such a big deal?
Let's teach drivers about IN_ORDER, then if devices
are in order it will get enabled by default.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Borislav Petkov @ 2018-10-10 19:14 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Kate Stewart, Peter Zijlstra, Christopher Li, virtualization,
Masahiro Yamada, Nadav Amit, Jan Beulich, H. Peter Anvin,
Sam Ravnborg, Ingo Molnar, x86, linux-sparse, Ingo Molnar,
linux-xtensa, Kees Cook, Chris Zankel, Michael Matz,
Josh Poimboeuf, Alok Kataria, Juergen Gross, gcc, Richard Biener,
Max Filippov, Greg Kroah-Hartman, linux-kernel, Thomas Gleixner
In-Reply-To: <20181010185432.GB29268@gate.crashing.org>
On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote:
> It would be great to hear from kernel people if it works adequately for
> what you guys want it for :-)
Sure, ping me when you have the final version and I'll try to build gcc
with it and do some size comparisons.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH net-next V3] virtio_net: ethtool tx napi configuration
From: David Miller @ 2018-10-11 5:34 UTC (permalink / raw)
To: jasowang; +Cc: netdev, willemb, virtualization, linux-kernel, mst
In-Reply-To: <20181009020626.31723-1-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 9 Oct 2018 10:06:26 +0800
> Implement ethtool .set_coalesce (-C) and .get_coalesce (-c) handlers.
> Interrupt moderation is currently not supported, so these accept and
> display the default settings of 0 usec and 1 frame.
>
> Toggle tx napi through setting tx-frames. So as to not interfere
> with possible future interrupt moderation, value 1 means tx napi while
> value 0 means not.
>
> Only allow the switching when device is down for simplicity.
>
> Link: https://patchwork.ozlabs.org/patch/948149/
> Suggested-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Changes from V2:
> - only allow the switching when device is done
> - remove unnecessary global variable and initialization
> Changes from V1:
> - try to synchronize with datapath to allow changing mode when
> interface is up.
> - use tx-frames 0 as to disable tx napi while tx-frames 1 to enable tx napi
Applied, with...
> + bool running = netif_running(dev);
this unused variable removed.
^ permalink raw reply
* IEEE Record # 45039 CTEMS 2018, KLS Gogte Institute of Technology - CFP
From: Dr. S K Niranjan Aradhya @ 2018-10-11 6:30 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 1528 bytes --]
*<< Apologies for cross-postings >> <<< Please circulate among your
friends, peers and researchers >>>*
IEEE Conference Record No.: # 45039
*2018 International Conference on Computational Techniques, Electronics and
Mechanical Systems (CTEMS)*
*KLS Gogte Institute of Technology*
Conference Date : 21-23 December 2018
Submission Deadline: 20 October 2018
Submission Link: http://itekcmsonline.com/ctems/index.php/ctems/ctems/login
IEEE ISBN : 978-1-5386-7709-4
IEEE Part No. : CFP18R14-ART
Selected, accepted and extended papers will be published in the UGC
approved International Journal of Advances in Arts, Sciences and
Engineering (IJOOASE)
All accepted and presented papers will be submitted to the IEEE for
possible publication in IEEE Xplore Digital Library
If you like to join the TPC or propose a special session or symposiums
please write to: secretariat@ctems-conference.org
<http://secretariat@icatcct.org>
General Chair(s)
CTEMS'18 Conference
----------------------
Disclaimer: We have clearly mentioned the subject lines and your email
address won't be misleading in any form. We have found your mail address
through our own efforts on the web search and not through any illegal way.
If you wish to remove your information from our mailing list or no longer
receive future announcements, please email with REMOVE in subject. Your
request to opt-out will be effective within a reasonable amount of time.
ctems-CFP.pdf
<https://drive.google.com/file/d/1ZHlYY48VISZHaEerxuzm7NU6ssKz_0AD/view?usp=drive_web>
[-- Attachment #1.2: Type: text/html, Size: 3290 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox