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] 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] mprotect: page-align len parameter instead of returning error

Hi, thanks, I committed this patch because indeed the mprotect manual pages, in both Linux and posix, both talk about (possible) errors if addr is not aligned, but keep suspiciously silent about len. But I'm curious, how did you find this issue? Did it break actual code that tried to use unaligned

Re: [osv-dev] [PATCH] procfs: populate maps file with i-node numbers

Looks good to me, but I wonder, together with the inode, shouldn't we also save the device id, so we can print that too (that is the 00:00 we print now)? -- Nadav Har'El n...@scylladb.com On Sun, Jun 30, 2019 at 7:14 AM Waldemar Kozaczuk wrote: > This patch refines the implementat

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

On Fri, Jun 28, 2019 at 4:36 PM 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 and incrementing it > when wrap around is detected. > > Signed-off-by: Waldemar Kozaczuk >

Re: [osv-dev] [PATCH] hpet: Enhance 64-bit hpet clock to handle non-monotonic reads of the main counter

On Fri, Jun 28, 2019 at 7:04 AM Waldemar Kozaczuk wrote: > This patch hardens the implementation of hpet clock with 64-bit counter > by enforcing that every read of the main counter is NOT less than > the previous value. > > Fixes #382 > Hi, While one of the ideas raised in #382 was that

Re: [osv-dev] OSv and C applications

On Mon, Jul 1, 2019 at 4:01 PM DOR Nelly wrote: > Hello, > > I'm trying to use OSv with non-included C programs, so I naturally tried > running OSv with one of the applications that are present in the OSv bundle > first (eg groonga, cassandra, the java hello example, etc). To see a really

Re: [osv-dev] [PATCH] procfs: populate maps file with i-node numbers

unique in a single device, but not necessarily across different devices (e.g., two disk drives), so the inode number alone is not enough. >> Sent from my iPhone >> >> On Jun 30, 2019, at 04:34, Nadav Har'El wrote: >> >> Looks good to me, but I wonder, together with

Re: [osv-dev] OSv Linux compatibility

On Wed, Apr 10, 2019 at 10:38 PM Waldek Kozaczuk wrote: > Given that: > >- https://github.com/cloudius-systems/osv/issues/213 > > > (closed) >-

Re: [osv-dev] Improving Capstan

On Wed, Apr 24, 2019 at 3:16 PM Waldek Kozaczuk wrote: > Now that we have full control of Capstan let us try to improve it a > little. Here is my wish list or things I would like to do in short-term: > >- Add ability to pull kernel and mpm packages from github >- Add diagnostic option to

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

On Tue, Apr 23, 2019 at 6:55 PM Waldek Kozaczuk wrote: > Hi, > > Could someone clean build tree on the build machine - './scripts/build > clean'? > I'll clean it to solve the problem this time, but since this is a script you're familiar with, can you please fix it? (see below my notes on what

Re: [osv-dev] Resurrecting ARM support

On Thu, Jun 27, 2019 at 3:25 PM Waldek Kozaczuk wrote: > Hi, > > Hopefully, soon I will be cutting new release of OSv. But thinking about > what next, I was wondering if anyone is interested in collaborating on > getting OSv to run on ARM. > > It is my understanding that OSv at least builds for

Re: [osv-dev] [PATCH] procfs: populate maps file with i-node numbers

e 8-bit fs type must be put in the low bits of fsid[1] * because that's where other Solaris filesystems put it. */ I'm not sure how any of this is supposed to correspond to major and minor numbers. I'm not sure it even matters, really, as long as the st_dev (and its representation as majo

Re: [osv-dev] [PATCH] syscall: provide limited implementation of tgkil

On Tue, Jul 2, 2019 at 3:03 PM Waldemar Kozaczuk wrote: > This patch provides very limited implementation of the Linux > specific system call tgkill(). For now it only handles SIGINT > which is interpreted as a request to shutdown the app and OSv. > You could make it a little less hacky if

Re: [osv-dev] [PATCH] hpet: Enhance 64-bit hpet clock to handle non-monotonic reads of the main counter

On Tue, Jul 2, 2019 at 6:35 AM Waldek Kozaczuk wrote: > No, I have never been able to reproduce this issue for a year or so. I > would typically happen in a nested virtualization scenario. > > My understanding was that for some reason the hypervisor (in this case > qemu without KVM) would

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,

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/display/re

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

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 ./scr

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] [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 o

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

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

42 >> #5 0x11702bf2 in PosixSemaphore::trywait() () >> *#6 0x1121aab4 in VM_HandshakeAllThreads::doit() ()* >> #7 0x1198a8d7 in VM_Operation::evaluate() () >> #8 0x000011990706 in VMThread::evaluate_operation(VM_Operation*) >> [clone .constpr

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

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, Aug 4

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

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 > > (forev

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 generate

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

nks 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: >> >> >>

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 kernel co

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

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] [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] 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 ||

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 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: >> >>> >>> >>> On

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, Waldek Ko

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

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

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 &

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 mempoo

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] 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

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

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

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 seco

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=0xa12d4

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] 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 >

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

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

g 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 cool, it comes

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

le 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 3b5c6285..71b3340d

[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 | 53

[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 30. Fi

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] Re: [PATCH] cpiod: stop using boost::program_options

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 Nadav Har'El wrote

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

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.cc b/core/elf.cc

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 list,

Re: [osv-dev] [PATCH] Move kernel to 0x40200000 address (1 GiB higher) in virtual memory

On Sun, Jun 16, 2019 at 4:37 PM Waldek Kozaczuk wrote: > > +# virtual address space 1 GiB at a time > +# The very 1st entry maps 1st GiB 1:1 by pointing to ident_pt_l2 > table > +# that specifies addresses of every one of 512 2MiB slots of > physical memory > +

Re: [osv-dev] [PATCH] Move kernel to 0x40200000 address (1 GiB higher) in virtual memory

On Sun, Jun 16, 2019 at 8:05 AM Waldemar Kozaczuk wrote: > This patch provides all necessary changes to move OSv kernel by 1 GiB > higher > in virtual memory space to start at 0x4020. Most changes involve adding > or substracting 0x4000 (OSV_KERNEL_VM_SHIFT) in all relevant places. >

Re: [osv-dev] [PATCH] Move kernel to 0x40200000 address (1 GiB higher) in virtual memory

On Sun, Jun 16, 2019 at 3:24 PM Waldek Kozaczuk wrote: > > > On Sunday, June 16, 2019 at 8:22:03 AM UTC-4, Waldek Kozaczuk wrote: >> >> >> >> On Sunday, June 16, 2019 at 5:40:46 AM UTC-4, Nadav Har'El wrote: >>> >>> On Sun, J

Re: [osv-dev] [PATCH] Move kernel to 0x40200000 address (1 GiB higher) in virtual memory

On Sun, Jun 16, 2019 at 3:22 PM Waldek Kozaczuk wrote: > > > On Sunday, June 16, 2019 at 5:40:46 AM UTC-4, Nadav Har'El wrote: >> >> On Sun, Jun 16, 2019 at 8:05 AM Waldemar Kozaczuk >> wrote: >> >>> This patch provides all necessary changes to move OSv

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

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

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.yml > &g

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

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"

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] Lazily allocating thread stacks WIP

af38e5312fd3c27d9 > . > > 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 this email

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_medium=notification > . > > Great job, Mason! > Very nice > On Friday, December 6, 2019 at

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 more. &

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

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 ( >

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

t 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 is dead now, r

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

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

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] 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

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 >

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,

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

ilesystem 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 Kozaczuk >> wrote: >> >>> >>> >>

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 Kozaczuk &

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

[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 | 2 +- 1 file

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

is a function pointer, not a function, so its name already points to the function's code - there is no reason to take 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 Signed-off-by: Nadav Har'El

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

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 +- 1 file changed, 1

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

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

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

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 >

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

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

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,

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

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 one >

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-api/globa

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 changed, 46

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

that 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/elf.cc index

<    3   4   5   6   7   8   9   10   11   12   >