Re: [osv-dev] GraalVM isolates working on OSv

On Tue, Jul 9, 2019 at 7:33 AM Waldek Kozaczuk wrote: > With a couple of fairly trivial patches applied recently I finally got > GraalVM isolates working properly on OSv. The GraalVM isolates seem to > provide in-process isolation or some sort of "multi-tenant VM instances > within the same app"

Re: [osv-dev] [PATCH] Support PVH/HVM direct kernel boot

On Sun, Jul 7, 2019 at 7:22 AM Waldemar Kozaczuk wrote: > QEMU 4.0 and later supports new way of booting Linux by > specifying 64-bit vmlinux ELF. Please see this for details - > https://patchwork.kernel.org/patch/10741013/. > > This patch enhances OSv boot logic and loader.elf to support this >

Re: [osv-dev] OSv strace utility

On Thu, Jul 11, 2019 at 12:37 AM Waldek Kozaczuk wrote: > OSv comes with pretty sophisticated tracing and profiling capabilities and > can be used as described on this Wiki pages - > https://github.com/cloudius-systems/osv/wiki/Trace-analysis-using-trace.py > and > https://github.com/cloudius-sy

Re: [osv-dev] Running Docker images on OSv

On Wed, Jul 10, 2019 at 4:07 PM Waldek Kozaczuk wrote: > OSv cannot run Docker containers and probably never will. But It turns out > one could quite easily build tooling around running Docker images. If you > think about it in order to un an image as a container, docker has to > "unflatten" it i

Re: [osv-dev] [PATCH] Enhance scripts/build to allow passing arguments to modules/apps

On Sat, Jul 20, 2019 at 11:41 PM Waldemar Kozaczuk wrote: > This patch enhances scripts/build to allow passing arguments to > modules/apps > makefiles like so: > > ./script/build m_JAVA_VERSION=11 > m_JAVA_MODULES=ava.base,java.sql,java.logging,java.xml,jdk.unsupported > image=openjdk-zulu-9-and-

Re: [osv-dev] Re: Potential deadlock when running latest Java 12

On Sat, Jul 20, 2019 at 8:01 PM Waldek Kozaczuk wrote: > I am thinking we might simply have a bug in core/semaphore.cc. Based on > these two lines: > > semaphore::trywait (this=0xa12d4680, units=units@entry=1) at > core/semaphore.cc:64 -> from VM Thread > This is interesting. trywait()

Re: [osv-dev] Re: Potential deadlock when running latest Java 12

On Sun, Jul 21, 2019 at 11:30 AM Nadav Har'El wrote: > > On Sat, Jul 20, 2019 at 8:01 PM Waldek Kozaczuk > wrote: > >> I am thinking we might simply have a bug in core/semaphore.cc. Based on >> these two lines: >> >> semaphore::trywait (this=0xa000

Re: [osv-dev] Re: Potential deadlock when running latest Java 12

On Sat, Jul 20, 2019 at 8:41 AM Waldek Kozaczuk wrote: > Are we properly handling the EINTR scenario, where thread blocked on > sem_wait() or sem_timed_wait() should get interrupted if signal sent to it? > No, I believe we do not support this correctly. Please see my other mail on some pointers

Re: [osv-dev] [PATCH V2] Upgrade cli, lua and httpserver-api modules to use OpenSSL 1.1 and Lua 5.3

Hi, thanks! I have some comments and questions inline below: On Sun, Aug 4, 2019 at 6:33 PM Waldemar Kozaczuk wrote: > As the issue #1022 explains, building the default OSv image that > implicitly adds cli module that in turn implicitly pulls httpserver-api > and cli modules, requires some biza

Re: [osv-dev] OSv and IncludeOS

On Tue, Aug 6, 2019 at 7:21 PM Joe Duarte wrote: > Hi all, > > Has anyone tested both OSv and IncludeOS , or > evaluated them as alternatives? I'd be curious to know the results of your > evaluation. > I have no experience with IncludeOS, but I can comment on your OSv

Re: [osv-dev] Re: Compiler optimization flags to improve OSv performance

On Wed, Aug 7, 2019 at 8:30 PM Waldek Kozaczuk wrote: > Hi, > > On Tuesday, August 6, 2019 at 12:45:09 PM UTC-4, Joe Duarte wrote: >> >> Hi all, >> >> I think there might be an opportunity for good speedups in OSv if modern >> compiler optimization options are used. >> > Before you start discussi

Re: [osv-dev] [PATCH] scheduler: Initialize _cpu field in detached_state struct

om the bot saying that a proposed patch was already committed. Thanks! -- Nadav Har'El n...@scylladb.com On Thu, Aug 8, 2019 at 8:05 AM Waldemar Kozaczuk wrote: > The patch 97fe8aa3d2d8f2c938fcaa379c44ae5a80dfbf33 enhanced > OSv to start using physical memory below 2MiB. The second

Re: [osv-dev] [COMMIT osv-apps master] java: add standard /usr/bin/java executable to jdk apps

On Sat, Aug 10, 2019 at 4:36 PM Commit Bot wrote: > From: Waldemar Kozaczuk > Committer: Waldemar Kozaczuk > Branch: master > > java: add standard /usr/bin/java executable to jdk apps > > This patch tweaks openjdk* makefiles to retain > bin/java executable and makes module.py create > a symlink

Re: [osv-dev] [PATCH] semaphores: fix sem_trywait

Wow, great catch. Committed. Thanks. -- Nadav Har'El n...@scylladb.com On Sat, Aug 10, 2019 at 7:09 AM Waldemar Kozaczuk wrote: > This patch fixes a subtle but critical bug in sem_trywait() > underlying implementation (semaphore.cc) which > for example prevented new version

Re: [osv-dev] [PATCH] pthreads: implement pthread_attr_getdetachstate

On Sat, Aug 10, 2019 at 7:29 AM Waldemar Kozaczuk wrote: > This function is used by Java when enabling logging at trace level > > Signed-off-by: Waldemar Kozaczuk > --- > libc/pthread.cc | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/libc/pthread.cc b/libc/pthread.cc > index e8

Re: [osv-dev] Re: Potential deadlock when running latest Java 12

lude/c++/8/bits/unique_ptr.h:342 >> #5 0x11702bf2 in PosixSemaphore::trywait() () >> *#6 0x1121aab4 in VM_HandshakeAllThreads::doit() ()* >> #7 0x1198a8d7 in VM_Operation::evaluate() () >> #8 0x11990706 in VMThread::evaluate_operation(VM_Operat

Re: [osv-dev] [PATCH V2] Upgrade cli, lua and httpserver-api modules to use OpenSSL 1.1 and Lua 5.3

On Tue, Aug 6, 2019 at 6:26 PM Waldek Kozaczuk wrote: > Thanks for the review! > > On Tuesday, August 6, 2019 at 10:13:15 AM UTC-4, Nadav Har'El wrote: >> >> Hi, thanks! >> >> I have some comments and questions inline below: >> >> On Sun,

Re: [osv-dev] [PATCH V2] hpet: handle wrap-around with 32-bit counter

In Sat, Jul 6, 2019 at 6:37 AM Waldemar Kozaczuk wrote: > This patch enhances the hpet clock with 32-bit main > counter to handle wrap-arounds. It does it by maintaining > separate upper 32-bit counter per-cpu and incrementing it > when wrap around is detected. > I have a few comments below, but

Re: [osv-dev] Build failed in Jenkins: osv-build #1501

"Failed to load object: /usr/lib/jvm/java/bin/java. Powering off." Waldek, can you please take a look at that? Thanks. -- Nadav Har'El n...@scylladb.com On Mon, Aug 12, 2019 at 6:40 AM wrote: > See < > https://jenkins.scylladb.com/job/osv-build/1501/displ

Re: [osv-dev] [PATCH V3] Upgrade cli, lua and httpserver-api modules to use OpenSSL 1.1 and Lua 5.3

Thanks, I tested this on Fedora 29 and it is working well (on Fedora 30, I can't build because of the unrelated https://github.com/cloudius-systems/osv/issues/1040) and I finally don't need that "compat" library - thanks. Commited! On Tue, Aug 13, 2019 at 6:33 AM Waldemar Kozaczuk wrote: > As t

Re: [osv-dev] Build failed in Jenkins: osv-build #1503

On Thu, Aug 15, 2019 at 2:04 PM wrote: > See < > https://jenkins.scylladb.com/job/osv-build/1503/display/redirect?page=changes > > > + sudo ./scripts/setup.py Dependencies resolved. > > > Package

Re: [osv-dev] Build failed in Jenkins: osv-build #1503

On Thu, Aug 15, 2019 at 2:13 PM Nadav Har'El wrote: > > On Thu, Aug 15, 2019 at 2:04 PM wrote: > >> See < >> https://jenkins.scylladb.com/job/osv-build/1503/display/redirect?page=changes >> > >> + sudo

Re: [osv-dev] [PATCH V3] Upgrade cli, lua and httpserver-api modules to use OpenSSL 1.1 and Lua 5.3

On Thu, Aug 15, 2019 at 2:29 PM Waldek Kozaczuk wrote: > Hi, > > Thanks for applying the patch (BTW as I feared it failed on the Jenkins > machine due to some x86_64 vs i686 conflict, any ideas how to fix it?). Thanks. I saw it is most likely a Fedora 27 bug, which takes the wrong package (a i6

Re: [osv-dev] [COMMIT osv master] docs: Updated main README to make it better reflect current state of OSv

Thanks for spending time on modernizing this README. I know you already committed it, but still, some comments below. On Mon, Aug 19, 2019 at 6:57 AM Commit Bot wrote: > From: Waldemar Kozaczuk > Committer: Waldemar Kozaczuk > Branch: master > > docs: Updated main README to make it better refl

Re: [osv-dev] [PATCH] Ignore missing symbols when processing certain relocation types on load

On Tue, Aug 20, 2019 at 7:20 AM Waldemar Kozaczuk wrote: > The commit > https://github.com/cloudius-systems/osv/commit/f5cc12d56dd986d2c7982c5738b1f859702b07fb > addressed the issue #993 to relax handling of missing symbols in > relocate_pltgot() > when loading ELF objects with BIND_NOW. This pat

Re: [osv-dev] [PATCH] Ignore missing symbols when processing certain relocation types on load

for the review. You can hopefully find some more related background > info in this group post from a couple of days ago - > https://groups.google.com/forum/#!msg/osv-dev/kmkqlZt2DRY/ijpde19DDQAJ > > On Tuesday, August 20, 2019 at 9:19:12 AM UTC-4, Nadav Har'El wrote: >> >&g

Re: [osv-dev] Re: [PATCH] Fix bug in arch_setup_free_memory

On Wed, Aug 21, 2019 at 6:04 AM Waldek Kozaczuk wrote: > This patch definitely fixes an apparent bug I introduced myself in the > past. I have tested that issue #1048 goes away with 4,5,6, 7 or 8GB of > memory. I have also verified using cli module that free memory is reported > properly now. >

Re: [osv-dev] Re: [PATCH] Fix bug in arch_setup_free_memory

On Wed, Aug 21, 2019 at 10:09 AM Rick Payne wrote: > > Thanks for this - I was hitting a wierd page fault issue on our > application as we've recently moved from 0.52 to the latest OSv. > Something like this, which occurs early on in startup: > > Assertion failed: ef->rflags & processor::rflags_i

Re: [osv-dev] Re: [PATCH] Fix bug in arch_setup_free_memory

On Wed, Aug 21, 2019 at 2:21 PM Waldek Kozaczuk wrote: > Hi, > > Thanks for committing this patch. But unfortunately the tst-huge.so > problem is going to make the unit tests fails. > As bad this is, better one unit failing than a lot of real use cases (which unfortunately none of the unit tests

Re: [osv-dev] Re: [PATCH] Fix bug in arch_setup_free_memory

On Wed, Aug 21, 2019 at 10:21 PM Rick Payne wrote: > On Wed, 2019-08-21 at 12:22 +0300, Nadav Har'El wrote: > > I am guessing (need to verify...) that our rwlock implementation is > > not recursive - a thread already holding the write lock needs to wait > > (forever)

Re: [osv-dev] Re: [PATCH] Fix bug in arch_setup_free_memory

On Thu, Aug 22, 2019 at 9:53 AM Rick Payne wrote: > On Wed, 2019-08-21 at 13:21 +0300, Nadav Har'El wrote: > > > > This is often not the problem itself, but rather a result of an > > earlier bug, which caused > > us to want to print an error message and that gen

Re: [osv-dev] Re: [PATCH] Fix bug in arch_setup_free_memory

On Thu, Aug 22, 2019 at 12:07 PM Rick Payne wrote: > On Thu, 2019-08-22 at 10:47 +0300, Nadav Har'El wrote: > > Do you know how to get a backtrace from gdb? > > Yes, see below. It wasn't running out of memory: > > (gdb) osv mem > Total Memory: 8589392896 Byte

Re: [osv-dev] Re: [PATCH] Fix bug in arch_setup_free_memory

On Thu, Aug 22, 2019 at 12:12 PM Rick Payne wrote: > On Thu, 2019-08-22 at 10:33 +0300, Nadav Har'El wrote: > > You're right, it seems there's should be a "return" in the recursive > > case! > > That being said, I think the spurious wakeup doesn'

Re: [osv-dev] [PATCH] memory: enforce physical free memory ranges do not start at 0

On Sat, Aug 24, 2019 at 7:14 AM Waldemar Kozaczuk wrote: > Most of the time the kernel code references memory using virtual addresses. > However some allocated system structures like page tables use physical > addresses. > For that reason it is critical that physical addresses are never 0 which >

Re: [osv-dev] [PATCH] memory: enforce physical free memory ranges do not start at 0

On Sat, Aug 24, 2019 at 7:02 PM Waldek Kozaczuk wrote: > > > On Saturday, August 24, 2019 at 5:34:22 AM UTC-4, Nadav Har'El wrote: >> >> >> On Sat, Aug 24, 2019 at 7:14 AM Waldemar Kozaczuk >> wrote: >> >>> Most of the time the kern

Re: [osv-dev] [PATCH] pthreads: provide minimal implementation to handle SCHED_OTHER policy

On Thu, Aug 22, 2019 at 4:43 AM Waldemar Kozaczuk wrote: > This patch provides minimal implementation of following > 4 functions to handle SCHED_OTHER policy: > - sched_get_priority_min > - sched_get_priority_max > - pthread_getschedparam > - pthread_setschedparam > > This implementation of these

Re: [osv-dev] [PATCH] pthreads: provide minimal implementation to handle SCHED_OTHER policy

On Sat, Aug 24, 2019 at 5:16 PM Waldek Kozaczuk wrote: > I looked at number of patches sent years ago that fully implemented the > scheduler policies including the real time one Yes, I actually spent quite a bit of effort in the past to add to our scheduler (a big part of) the machinary needed

Re: [osv-dev] [PATCH] pthreads: provide minimal implementation to handle SCHED_OTHER policy

Yes, it's fine. Thanks. -- Nadav Har'El n...@scylladb.com On Mon, Aug 26, 2019 at 12:07 AM Waldek Kozaczuk wrote: > I have just committed this patch by accident. But I hope it addressed your > suggestions accurately. > > On Sunday, August 25, 2019 at 1:22:14 PM UTC-4,

Re: [osv-dev] [PATCH] memory: enforce physical free memory ranges do not start at 0

On Mon, Aug 26, 2019 at 6:25 AM Waldek Kozaczuk wrote: > > > On Saturday, August 24, 2019 at 3:26:15 PM UTC-4, Nadav Har'El wrote: >> >> >> On Sat, Aug 24, 2019 at 7:02 PM Waldek Kozaczuk >> wrote: >> >>> >>> >>&g

Re: [osv-dev] [PATCH] Ignore missing symbols when processing certain relocation types on load

On Sun, Aug 25, 2019 at 8:37 AM Waldek Kozaczuk wrote: > +void * const MISSING_SYMBOL_INDICATOR = (void*)0x; > >> Can you please remind me why this is an invalid pointer? Does it not have enough f's in the beginning to be a valid pointer? >>> I tried to pick somethi

Re: [osv-dev] Re: x265, libnuma and versioned symbols

On Thu, Aug 29, 2019 at 1:28 AM Waldek Kozaczuk wrote: > Here is this bit from https://www.akkadia.org/drepper/symbol-versioning: > > "If the highest bit (no. 15) of the version symbol value is set, the > > object is hidden and must not be used. In this case the linker must > treat the symbol as

Re: [osv-dev] Re: x265, libnuma and versioned symbols

On Thu, Aug 29, 2019 at 2:50 PM Waldek Kozaczuk wrote: > Musl treats DT_VERSYM as an array of int16_t (signed) instead of what we > do and should do - Elf64_Versym aka uint16_t. And then the simply check > if that version number is negative: > > int16_t *versym; > > ... > > (!dso->versym || dso->

Re: [osv-dev] [COMMIT osv master] syscall: add set_mempolicy and sched_setaffinity needed by libnuma

On Fri, Aug 30, 2019 at 10:04 PM Commit Bot wrote: > From: Waldemar Kozaczuk > Committer: Waldemar Kozaczuk > Branch: master > > syscall: add set_mempolicy and sched_setaffinity needed by libnuma > > Signed-off-by: Waldemar Kozaczuk > > --- > diff --git a/linux.cc b/linux.cc > --- a/linux.cc >

Re: [osv-dev] Demand paging for malloc

On Mon, Sep 9, 2019 at 2:41 PM wrote: > Hi, > I found malloc returns physical address in mempool area and does not > perform demand paging (only mmap does). > Is there any reason for the design choice? > I guess you're not really asking about *demand* paging ("swapping") because this feature is

Re: [osv-dev] Demand paging for malloc

On Tue, Sep 10, 2019 at 5:15 PM Waldek Kozaczuk wrote: > > > On Tuesday, September 10, 2019 at 2:52:52 AM UTC-4, Nadav Har'El wrote: >> >> >> On Mon, Sep 9, 2019 at 2:41 PM wrote: >> >>> Hi, >>> I found malloc returns physical address in m

Re: [osv-dev] Next OSv release 0.55 - proposal

On Thu, Sep 26, 2019 at 12:44 AM Waldek Kozaczuk wrote: > Hi, > > Given 0.54 has been released, I figured it might be a good time to talk > about the next one. > Thanks. Nice list, and I wish I could have more time to be more involved in actually coding some of these fixes... For me, the most i

Re: [osv-dev] Next OSv release 0.55 - proposal

On Thu, Sep 26, 2019 at 10:39 AM Nadav Har'El wrote: > On Thu, Sep 26, 2019 at 12:44 AM Waldek Kozaczuk > wrote: > >> Hi, >> >> Given 0.54 has been released, I figured it might be a good time to talk >> about the next one. >> > > Thanks. Nice

[osv-dev] [PATCH] cpiod: stop using boost::program_options

recently become a problem on recent distributions of Boost that hide their symbols (see issue #1040). Fixes #980 (cpiod.so is now 200K instead of 300K) Refs #1040 (it fixes the main problem: OSv now builds on Fedora 30!) Signed-off-by: Nadav Har'El --- tools/cpiod/cpiod.cc

[osv-dev] Re: [PATCH] cpiod: stop using boost::program_options

he kernel still uses boost program options (yuck!) and still may or may not export symbols from it - depending on the Boost version. But since cpiod.so with this patch, no longer relies on those symbols, everything just works. -- Nadav Har'El n...@scylladb.com On Thu, Sep 26, 2019 at 4:38 PM

[osv-dev] [PATCH] scripts/manifest_from_host.sh: write errors to stderr

l be visible instead of having "scripts/build" silently fail. Signed-off-by: Nadav Har'El --- scripts/manifest_from_host.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/scripts/manifest_from_host.sh b/scripts/manifest_from_host.sh index 3b5c

[osv-dev] Re: [PATCH] cpiod: stop using boost::program_options

On Thu, Sep 26, 2019 at 4:42 PM Nadav Har'El wrote: > > Waldek, while this patch doesn't quite solve all the issues mentioned in > #1040, it does solve the original problem - which OSv couldn't be build on > Fedora 30. > With this patch, it builds fine on Fedora

Re: [osv-dev] Next OSv release 0.55 - proposal

On Thu, Sep 26, 2019 at 3:29 PM Waldek Kozaczuk wrote: > > > On Thursday, September 26, 2019 at 8:11:04 AM UTC-4, Nadav Har'El wrote: >> >> On Thu, Sep 26, 2019 at 10:39 AM Nadav Har'El wrote: >> >>> On Thu, Sep 26, 2019 at 12:44 AM Waldek Kozaczuk

[osv-dev] [PATCH] elf.cc: if Boost libraries aren't visible to applications, don't report them

mbols in these libraries are *not* available to the application. So if Boost is 1.69.0 or later, we shouldn't claim that the kernel contains these libraries. Refs #1040. Signed-off-by: Nadav Har'El --- core/elf.cc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/core/elf.c

Re: [osv-dev] Re: [PATCH] cpiod: stop using boost::program_options

ng or just writing it from scratch (it's not that complicated...) and use it from httpserver-api, cpiod, and perhaps even the kernel itself. > On Thursday, September 26, 2019 at 9:38:49 AM UTC-4, Nadav Har'El wrote: >> >> While (some people think that) boost::program_options is

Re: [osv-dev] [PATCH 1/4] options: implement light and simple alternative to boost program options

On Thu, Oct 3, 2019 at 7:24 AM Waldemar Kozaczuk wrote: > This patch provides simple and light alternative to boost program options > library. It adds handful of utility functions that are aimed > to help parse command line options and intended to be used > by kernel loader and the utility apps l

Re: [osv-dev] [PATCH 2/4] loader: replace boost program_options with light options utility functions

Reviewed-by: Nadav Har'El -- Nadav Har'El n...@scylladb.com On Thu, Oct 3, 2019 at 7:24 AM Waldemar Kozaczuk wrote: > This patch changes loader.cc to use light options utility > instead of boost program options. > > This patch partially addresses #1014 and together with

Re: [osv-dev] [PATCH 3/4] cpiod: reduce cpiod size by replacing boost program options with the custom light alternative

Reviewed-by: Nadav Har'El -- Nadav Har'El n...@scylladb.com On Thu, Oct 3, 2019 at 7:25 AM Waldemar Kozaczuk wrote: > Fixes #980 > > Signed-off-by: Waldemar Kozaczuk > --- > tools/cpiod/cpiod.cc | 69 +--- > 1 file c

Re: [osv-dev] [PATCH 4/4] httpserver: replace boost program_options with light options utility functions

Reviewed-by: Nadav Har'El -- Nadav Har'El n...@scylladb.com On Thu, Oct 3, 2019 at 7:25 AM Waldemar Kozaczuk wrote: > Fixes #1053 > > Signed-off-by: Waldemar Kozaczuk > --- > modules/httpserver-api/global_server.cc | 30 - > modules/httpserver

Re: [osv-dev] [PATCH 1/4] options: implement light and simple alternative to boost program options

Since I only had tiny comments, I'll commit your patches as-is, and if you want, please send (or commit yourself) followup patches. Thanks for fixing this! Fedora 30 users everywhere thank you :-) -- Nadav Har'El n...@scylladb.com On Thu, Oct 3, 2019 at 10:41 AM Nadav Har'El wro

[osv-dev] [PATCH] build: stop including libboost_program_options

it's no longer used, we can stop compiling it into the kernel, or pretending (in elf.cc) that it is included in the kernel. Signed-off-by: Nadav Har'El --- core/elf.cc | 2 -- Makefile| 3 +-- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/core/elf.cc b/core/el

[osv-dev] [PATCH v2] elf.cc: if Boost libraries aren't visible to applications, don't report them

mbols in this library are *not* available to the application. So if Boost is 1.69.0 or later, we shouldn't claim that the kernel contains this library. Refs #1040. Signed-off-by: Nadav Har'El --- core/elf.cc | 9 + 1 file changed, 9 insertions(+) diff --git a/core/elf.cc b/co

Re: [osv-dev] Can't download "large" files using python3 on top of Firecracker: ...virtio/net.rs:257] Receiving buffer is too small to hold frame of current size

On Fri, Oct 4, 2019 at 10:28 PM Waldek Kozaczuk wrote: > Hi, > > So there were a couple of issues with my and your patch: > 1) We should NOT be using straight *malloc*() to allocate 17 pages of > memory. It needs to be page-aligned, so *aligned_alloc()* is the correct > choice. > Even better, pl

Re: [osv-dev] Re: [COMMIT osv master] elf.cc: if Boost libraries aren't visible to applications, don't report them

On Fri, Oct 4, 2019 at 7:14 AM Waldek Kozaczuk wrote: > I do not understand why cpiod.so linked against boost 1.69 and above does > NOT reference symbols from libboost_system.so. But it does reference > symbols from with older boost (< 1.69). Are the symbols found in > libboost_system.so < 1.69 n

Re: [osv-dev] does osv support numa?

On Mon, Oct 28, 2019 at 9:08 AM Lewis Tian wrote: > Hi, everyone, > I want to know whether osv supports numa > Not really. There is minimal support for applications that want to inquire about their NUMA configuration and learn that there is just one NUMA node. But there is no support for feature

Re: [osv-dev] Trying to run .NET Core hello world on OSv - help needed!

On Tue, Nov 12, 2019 at 7:11 AM Waldek Kozaczuk wrote: > > The second issue was related to some old version symbols from the standard > C++ library (yes like Java, .NET Core is implemented in C++). More > specifically OSv would crash due to failing to find a symbol: > > /libhostfxr.so: failed loo

Re: [osv-dev] CI Implementation/Contribution

On Wed, Nov 20, 2019 at 7:29 AM Matthew Pabst wrote: > Hi, > > A couple of peers and I from the University of Texas at Austin are > interested in contributing to OSv, and we thought a good place to start > would be implementing some basic CI infrastructure ( > https://github.com/cloudius-systems/

Re: [osv-dev] [COMMIT osv master] makefile: introduce loader_options.ld as a better way to pass APP_LOCAL_EXEC_TLS_SIZE to the linker script

On Fri, Nov 22, 2019 at 11:47 PM Commit Bot wrote: > From: Waldemar Kozaczuk > Committer: Waldemar Kozaczuk > Branch: master > > makefile: introduce loader_options.ld as a better way to pass > APP_LOCAL_EXEC_TLS_SIZE to the linker script > Hi, You didn't explain what is "better" about this way

Re: [osv-dev] [COMMIT osv master] makefile: introduce loader_options.ld as a better way to pass APP_LOCAL_EXEC_TLS_SIZE to the linker script

On Sun, Nov 24, 2019 at 12:13 AM Waldek Kozaczuk wrote: > > On Friday, November 22, 2019 at 5:30:36 PM UTC-5, Nadav Har'El wrote: >> >> >> >> On Fri, Nov 22, 2019 at 11:47 PM Commit Bot >> wrote: >> >>> From: Waldemar Kozacz

Re: [osv-dev] OSv boots in 3ms on QEMU microvm machine

On Fri, Nov 22, 2019 at 3:34 PM Waldek Kozaczuk wrote: > As you may have heard QEMU developers added new machine type: microvm - > https://github.com/qemu/qemu/blob/master/docs/microvm.rst. It has been > merged into master but not part of any official QEMU release. So if you > want to try you nee

Re: [osv-dev] [COMMIT osv master] power down: cause triple fault if keyboard controller method did not work on non-acpi hypervisors

I'm not too happy with this patch. My review is too late, but better late than never... On Fri, Nov 22, 2019 at 7:15 AM Commit Bot wrote: > From: Waldemar Kozaczuk > Committer: Waldemar Kozaczuk > Branch: master > > power down: cause triple fault if keyboard controller method did not work > on

Re: [osv-dev] Trying to run .NET Core hello world on OSv - help needed!

On Thu, Nov 21, 2019 at 6:01 AM Waldek Kozaczuk wrote: > Before I go into details of what I have found out and what the remedy > might be, let me say that I have managed to run simple 'hello world' C# app > on dotnet core on OSv. I have also made good progress on running httpserver > example as w

Re: [osv-dev] Re: Is it possible to run GUI apps as OSv Unikernels?

On Tue, Nov 12, 2019 at 12:49 AM Waldek Kozaczuk wrote: > First of OSv comes with a simple VGA console driver that allows apps like > rogue run (see apps/rogue). > > As far as X11 apps I had not tried to run them before you asked so I had > no idea they would work. So I actually spent some time p

Re: [osv-dev] Fedora 30/31 and Ubuntu 19.10

It seems fine on Fedora 30 (I seem to remember there were some specific modules that had problems because of the Boost mess, but not the tests). I didn't move to Fedora 31 yet. (I should). On Tue, Nov 26, 2019 at 3:39 PM Waldek Kozaczuk wrote: > Has anybody tried to build and run OSv on any of

Re: [osv-dev] Booting Bare Metal

On Tue, Nov 26, 2019 at 2:51 AM Matthew Weekley wrote: > I am looking to boot the kernel I generated from the build script. > > How would one recommend doing so using grub? I have noticed that OSv > doesn't support multiboot, or so it seems to me. I am not a grub expert by > any means so that's w

Re: [osv-dev] OSv boots in 3ms on QEMU microvm machine

t; First please note that this and other old (5ms) firecracker boot times >> were recorded when running on my old 2013 MacBook Pro with 4-way 2.3GHz i7 >> cpu with Ubuntu 19.04 on it. I think it still a decent laptop and the cpus >> have not gotten that much faster (Moore's law

Re: [osv-dev] Unikernels as highly isolated processes and an idea to implement limited fork/execve in OSv

On Tue, Nov 26, 2019 at 12:44 AM Waldek Kozaczuk wrote: > Sometimes it might be more useful to think of unikernels as highly > isolated processes instead of microVMs with a specialised guest OS. See > Nabla processes - > https://acmsocc.github.io/2018/slides/socc18-slides-williams.pdf. > > So giv

Re: [osv-dev] [PATCH] osv: fix keyboard reset, add pci reset

Hi, thanks for the patch! I have some questions: On Wed, Nov 27, 2019 at 3:46 PM 'YuChen Qian' via OSv Development < osv-dev@googlegroups.com> wrote: > The original keyboard reset does not wait a for short period, so we see > the triple fault being triggered even if the keyboard reset is > succes

Re: [osv-dev] Some boost based unit tests failing on Fedora 30 when linked with boost from host - 1.69.0

On Thu, Nov 28, 2019 at 8:00 AM Waldek Kozaczuk wrote: > I have been trying to upgrade unit tests to use boost from host instead of > depending on externals. One one the previous patches I sent fixed > compilation errors. > > However when I update the tests makefile and manifest file I see that s

[osv-dev] [PATCH] tests: fix warning in tst-mmap.cc

rong... func is a function pointer, not a function, so its name already points to the function's code - there is no reason to take &func. I'm not even sure how this works. After this patch, the warning is gone, and the relevant test (tst-elf-permissions.so) still passes. Refs #976 Si

[osv-dev] [PATCH] tests: fix warning in tst-symlink

The compiler correctly warns that we can't fill 4097 bytes of an array size 4096 (=PATH_MAX). I don't know why this code had 4097 in the first place. The test still passes with this fix, and the warning is gone. Refs #976. Signed-off-by: Nadav Har'El --- tests/tst-symlink.cc

[osv-dev] [PATCH] tests: fix compilation warning in tests/tst-run.cc

hes a polymorphic type by value. In the specific case fixed here, the warning is spurious, because the caught exception isn't even used. But it's trivial to fix it, and get rid of one more warning during test compilation. Refs #976 Signed-off-by: Nadav Har'El --- tests/tst-run.cc | 2 +

Re: [osv-dev] [PATCH] osv: fix keyboard reset, add pci reset

On Thu, Nov 28, 2019 at 4:03 PM wrote: > Thanks for the comment :) Please see my reply in the comments. > > On 27.11.19 15:43, Nadav Har'El wrote: > > > +u8 v = processor::inb(0x0cf9) & ~6; >> +processor::outb(v|2, 0x0cf9); // request hard reset >

Re: [osv-dev] [PATCH] osv: fix keyboard reset, add pci reset

On Thu, Nov 28, 2019 at 4:29 PM 'YuChen Qian' via OSv Development < osv-dev@googlegroups.com> wrote: > From: yuchenq > > The original keyboard reset does not wait a for short period, so we see > the triple fault being triggered even if the keyboard reset is > successful sometimes. Added a wait th

Re: [osv-dev] Some boost based unit tests failing on Fedora 30 when linked with boost from host - 1.69.0

On Thu, Nov 28, 2019 at 10:04 PM Waldek Kozaczuk wrote: > > >>> >>> >>> Please note I have removed this line from the tests Makefile: > -$(boost-tests:%=$(out)/tests/%): CXXFLAGS += -D_GLIBCXX_USE_CXX11_ABI=0 \ > I do not fully understand the significance of it nor the reasons for it in > the fir

Re: [osv-dev] Re: Ancient libgcc_s.so from external

On Sat, Nov 30, 2019 at 11:49 PM Waldek Kozaczuk wrote: > We the extra debug printouts the crash looks like this: > > ELF [tid:42, /usr/lib/libgcc_s.so.1]: Instantiated > ELF [tid:42, /usr/lib/libgcc_s.so.1]: The base set to: 0x000a7000 > and end: 0x000c0450 > ELF [tid:42, /usr/li

Re: [osv-dev] Some boost based unit tests failing on Fedora 30 when linked with boost from host - 1.69.0

d boost_filesystem directly. So we can't unload boost_filesystem just yet... And need to delay its unload. > What do you think? > > On Thursday, November 28, 2019 at 3:19:57 PM UTC-5, Nadav Har'El wrote: >> >> On Thu, Nov 28, 2019 at 10:04 PM Waldek Koz

Re: [osv-dev] Lazily allocating thread stacks WIP

On Tue, Dec 3, 2019 at 9:09 AM Matthew Pabst wrote: > I've been working on this issue > for the past couple > days, and I have a couple questions as well as a WIP solution. > > I figured I would start by implementing a simple solution that acce

Re: [osv-dev] [PATCH] Added base travis to test build

x27;t know if you in fact want to close this issue, though). -- Nadav Har'El n...@scylladb.com On Tue, Dec 3, 2019 at 9:19 AM Mason Davis wrote: > Signed-off-by: Mason Davis > --- > .travis.yml | 9 + > 1 file changed, 9 insertions(+) > create mode 100644 .travis.y

Re: [osv-dev] Lazily allocating thread stacks WIP

On Tue, Dec 3, 2019 at 5:56 PM Matthew Pabst wrote: > Thanks for the response. > > I've been trying to think through the logic for this change more, and I'm > don't completely understand the proposed solution. > > For example, say the program faults on a stack page. Then before disabling > interr

Re: [osv-dev] Lazily allocating thread stacks WIP

216d98fc0baf38e5312fd3c27d9 > . > > Testing these changes will be fun :-) I would start with unit tests and > especially use tst-pipe to run it 100 or more times to verify things do not > break. Then it would nice to measure the improvements of memory > utilizations - please see t

Re: [osv-dev] Re: [PATCH] osv: parse acpi interrupt source override table

On Fri, Dec 6, 2019 at 11:09 PM Waldek Kozaczuk wrote: > Hi, > > Thanks for the patch! > > Could you please elaborate on what is the purpose of the "interrupt source > overrides"? If you can maybe point to some spec or article in the commit > message that explains it a bit that would be great. I

Re: [osv-dev] Re: [COMMIT osv master] Add bare .travis.yml for testing build

On Fri, Dec 6, 2019 at 5:30 PM Waldek Kozaczuk wrote: > And the 1st successful Travis build of OSv is here - > https://travis-ci.org/cloudius-systems/osv/builds/621447399?utm_source=github_status&utm_medium=notification > . > > Great job, Mason! > Very nice > On Friday, December 6, 2019 at 12

Re: [osv-dev] Lazily allocating thread stacks WIP

On Sun, Dec 8, 2019 at 4:10 PM Waldek Kozaczuk wrote: > > > On Sun, Dec 8, 2019 at 07:32 Nadav Har'El wrote: > >> >> On Sat, Dec 7, 2019 at 6:07 AM Waldek Kozaczuk >> wrote: >> >>> On second thought, let me tweak my suggestions and add some mo

Re: [osv-dev] how to find missing symbols if it doesn't print the name

On Mon, Dec 9, 2019 at 10:51 PM zhiting zhu wrote: > Hey, > > I'm encountering this when I'm using some tensorflow functions: > > /lib/python3.6/tensorflow/python/_pywrap_tensorflow_internal.so: failed > looking up symbol > This is interesting, because the "failed looking up symbol" message is a

Re: [osv-dev] [PATCH] Signed-off-by: BassMatt

On Fri, Dec 13, 2019 at 10:02 AM Pekka Enberg wrote: > On Thu, Dec 12, 2019 at 10:02 PM BassMatt wrote: > > > > Main scripts in scripts/ folder updated to use Python3 > > > > I went through the scripts detailed in scripts/README and updated them > to use Python3. I used the Python "Future" modul

Re: [osv-dev] [PATCH] zfs: do not import extra pools unless requested

On Sun, Dec 22, 2019 at 5:05 PM Waldemar Kozaczuk wrote: > This patch makes OSv not to try to import extra ZFS (beyond the root one) > unless specifically requested by passing new '--extra-zfs-pools' boot > parameter. > > This improves the OSv boot time with ZFS image by ~50% (around 200ms on > Q

Re: [osv-dev] [PATCH] zfs: do not import extra pools unless requested

On Mon, Dec 23, 2019 at 12:30 PM Nadav Har'El wrote: > > On Sun, Dec 22, 2019 at 5:05 PM Waldemar Kozaczuk > wrote: > >> This patch makes OSv not to try to import extra ZFS (beyond the root one) >> unless specifically requested by passing new '--extra-zfs-po

Re: [osv-dev] [PATCH] zfs: default device name to vblk0.1 if vdev_path different than /dev/vblk*

On Sun, Dec 22, 2019 at 5:05 PM Waldemar Kozaczuk wrote: > This patch allows mounting OSv zfs image on Linux host and/or modifying and > using again to boot OSv. It also allows mounting ZFS disks created on Linux > host. > > Typically when mounting OSv image on Linux, the zpool utility would > ch

Re: [osv-dev] [PATCH] kvm: keep wall clock in sync with host

In general I think this is a good approach - "good enough" for clock synchronization and won't hurt performance - but I have a few requests below. On Thu, Dec 19, 2019 at 7:03 PM Waldemar Kozaczuk wrote: > This patch is an updated version of the one originally > authored by Rick Payne over year

[osv-dev] [PATCH 16/18] simple Inherited Thread-Local variables

oing this is not recommended. Instead use the general inherited thread-local variables offered by the next patch. We correctly support inherited thread-local variables in both the OSv core, and in shared objects (the latter is especially useful for the tests :-)). Signed-off-by: "Nadav Har

<    1   2   3   4   5   6   7   8   9   10   >