Re: Build failed in Jenkins: osv-build-nightly #1710

On Tue, Jan 8, 2019 at 2:49 PM Waldek Kozaczuk wrote: > Anybody with access to the build system could please take a look that this > fails? It seems like that configuariot bit is wrong. The test invoked upon > commit work fine. > Turns out the two different tests (on-commit and nightly) ran on t

Re: [PATCH] Refactor virtio layer to support modern PCI and mmio devices

On Wed, Jan 16, 2019 at 7:21 AM Waldemar Kozaczuk wrote: > This patch refactors virtio layer in order to support > modern PCI and mmio devices. It is essentially a step 0 > in the list of tasks to make OSv boot on AWS firecracker. > > This patch introduces virtio_device class that abstracts > vi

Re: [PATCH] Refactor virtio layer to support modern PCI and mmio devices

On Wed, Jan 16, 2019 at 5:53 PM Waldek Kozaczuk wrote: > On Wednesday, January 16, 2019 at 1:29:13 AM UTC-5, Pekka Enberg wrote: >> >> But for the overall approach: >> > ??? I thought you were going to say something more here :-) > >> >> Acked-by: Pekka Enberg >> > I think Pekka meant he "Acked"

Re: Removing assigned_virtio (--assign-net option) - give feedback if you rely on it!!!

On Wed, Jan 16, 2019 at 6:57 PM Waldek Kozaczuk wrote: > One of the virtio devices supported by OSv is assigned_virtio. To best of > my knowledge (based on what Nadav wrote) this driver has been invented in > order to better integrate OSv with seastar (see #ifdef HAVE_OSV in > https://github.com/

Re: [PATCH] Reset FPU state after saving it and upon context switch

On Wed, Dec 19, 2018 at 2:26 PM Waldemar Kozaczuk wrote: > This patch adds "emms" instruction in critical places > Thank you so much for working on this, and sorry for having delayed my review for SO long. I'm basically happy with this patch except one thing that nags me - I don't understand why

Re: [PATCH] Reset FPU state after saving it and upon context switch

On Thu, Jan 24, 2019 at 12:10 AM Nadav Har'El wrote: > On Wed, Dec 19, 2018 at 2:26 PM Waldemar Kozaczuk > wrote: > >> This patch adds "emms" instruction in critical places >> > > Thank you so much for working on this, and sorry for having delayed my &

Re: Hitting the assert in lockfree::mutex::unlock()

On Thu, Jan 24, 2019 at 5:35 AM Rick Payne wrote: > > Anyone seen a crash like this? > No, I haven't... Some thoughts below: > [backtrace] > 0x0022926a <__assert_fail+26> > 0x003d3884 > 0x0041e889 > 0x003e7aeb > 0x003e8086 <__syscall+1254> > > The par

Re: [osv-dev] Re: [PATCH] Reset FPU state after saving it and upon context switch

On Sat, Jan 26, 2019 at 1:31 AM Waldek Kozaczuk wrote: > Thanks for reviewing this patch. > > On Wednesday, January 23, 2019 at 5:10:56 PM UTC-5, Nadav Har'El wrote: >> >> >> So I'm really curious *why* this EMMS is needed beyond the one we added >> to

Re: [osv-dev] [PATCH V2] Reset FPU state after saving it and upon context switch

Thanks! I just committed your patch. It has to be a record on the number of issues fixed by a single patch :-) -- Nadav Har'El n...@scylladb.com On Tue, Jan 29, 2019 at 7:16 AM Waldemar Kozaczuk wrote: > This patch adds "emms" instruction in critical places > of OSv thr

Re: [osv-dev] [PATCH] Add scripts helping to automate testing of FPU-related bugs

On Sat, Jan 26, 2019 at 1:37 AM Waldemar Kozaczuk wrote: > THIS is just for testing -> is not meant to be applied to OSv github tree. > > Helps recreating and testing issues #536, #1010 and #1018 > Thanks. Since you said "not meant to be applied to OSv github tree", I won't :-) One thing you co

Re: [osv-dev] [PATCH] Implemented modern virtio PCI device

Thanks! I tried scripts/run.py --virtio modern with network and disk, and it seems to be working, so I've committed this series. -- Nadav Har'El n...@scylladb.com On Wed, Feb 6, 2019 at 3:29 PM Waldemar Kozaczuk wrote: > This patch implements modern virtio PCI device > and

Re: [osv-dev] [PATCH] Implemented modern virtio PCI device

On Thu, Feb 7, 2019 at 12:31 AM Waldek Kozaczuk wrote: > Also for whatever reason these patches did not trigger osv-build run. The > nightly one just completed successfully. Is something wrong with the commit > hook? > As far as I can tell, it did run, http://jenkins.cloudius-systems.com:8080/jo

Re: [osv-dev] Re: Problems with EC2?

On Tue, Feb 5, 2019 at 6:35 PM Waldek Kozaczuk wrote: > > Let me recap couple of things at least for my own sake of having better > understanding of the problem. So there are two aspects around resolv.conf - > (1) how the file is used and (2) how it constructed. As far as 1) goes > normally apps

Re: [osv-dev] Re: Problems with EC2?

Following my previous email where I outlined my comments, here are specific comments on your patch (sorry about the long delay) On Fri, Jan 25, 2019 at 6:27 PM Brian Ledbetter wrote: > Here's my first stab at solving this problem in a backwards-compatible > way, let me know what you think. I'v

Re: [osv-dev] Re: Problems with EC2?

On Thu, Feb 7, 2019 at 11:22 AM Brian Ledbetter wrote: > > > On Thursday, February 7, 2019 at 3:48:32 AM UTC-5, Nadav Har'El wrote: > >> To support the case where the /etc filesystem is read-only, we can do the >> following: In the read-only filesystem, put in /etc/r

Re: [osv-dev] Re: Problems with EC2?

On Thu, Feb 7, 2019 at 11:26 AM Brian Ledbetter wrote: > > > On Thursday, February 7, 2019 at 4:11:14 AM UTC-5, Nadav Har'El wrote: > >> Why is it possible that /etc doesn't exist yet? I think we start DHCP >> *after* mounting the root filesystem. >&g

Re: [osv-dev] Re: Problems with EC2?

On Thu, Feb 7, 2019 at 12:15 PM Brian Ledbetter wrote: > Understood, I've been really impressed with his work on rofs so far. It > makes perfect sense for an application like mine. > > I modified usr_rofs.manifest.skel to include: > > /etc/resolv.conf: ->/tmp/resolv.conf > > ...and built with fs=

Re: [osv-dev] [PATCH] Enhance scripts/test.py to pass extra arguments to run.py

On Sat, Feb 9, 2019 at 6:31 AM Waldemar Kozaczuk wrote: > This patch enhances scripts/test.py to allow passing > extra arguments to run.py. This allows executing running > unit tests with different than default parameters. > > See examples below how to run tests with different > virtio configurat

Re: [osv-dev] Ability to re-execute same app unlimited number of times

On Mon, Feb 11, 2019 at 1:33 AM Waldek Kozaczuk wrote: > Here is the scenario: > 1) Build image with some app X and httpserver API module. > 2) Start app X using REST API /app call with new_program=false (same > namespace) > 3) OSv loads app library and any dependent ones from disk and executes i

Re: [osv-dev] [RFC] Remaining work to support OSv on firecracker

On Sun, Feb 10, 2019 at 10:22 PM Waldemar Kozaczuk wrote: > - clean up modern/legacy virtio support (configurability) > - add virtio-mmio support including parsing virtio-mmio devices from > command line > - enhance boot.S and OSv boot in general to support vmlinux format > (decompressed ELF 64-b

Re: [osv-dev] Re: [RFC] Remaining work to support OSv on firecracker

On Sun, Feb 10, 2019 at 10:50 PM Waldek Kozaczuk wrote: > This patch is not meant to be applied but it serves to illustrate what is > left to make OSv boot on firecracker. As you can see it is not a daunting > amount of work anymore given modern virtio is supported now. > > In am not sure in what

Re: [osv-dev] Ability to re-execute same app unlimited number of times

On Mon, Feb 11, 2019 at 6:51 PM Waldek Kozaczuk wrote: > > I agree with you that messing at this level (loading/unloading elf) would > only complicate things more. Given that most expensive part is loading code > from the disk, maybe we could somehow optimize things at the lower level. > We would

Re: [osv-dev] [RFC] Remaining work to support OSv on firecracker

On Mon, Feb 11, 2019 at 6:55 PM Waldek Kozaczuk wrote: > > > boot_time.event("Total time"); >>> +processor::outb(123, 0x3f0); >>> >> >> What's this? >> > This simply replicates what Linux does when probing keyboard controller > and firecracker intercepts it as an exit marking end of the

Re: [osv-dev] Supporting Linux boot protocol

On Wed, Feb 13, 2019 at 7:03 AM Waldek Kozaczuk wrote: > As you know OSv supports running unmodified Linux executable as long as > they use subset of Linux API implemented by OSv. On other hand OSv kernel > is not compatible with Linux as far as boot process goes. By that I mean > one cannot boot

Re: [osv-dev] Does OSv have its own scheduler?

On Mon, Feb 18, 2019 at 8:07 PM Joe Duarte wrote: > Thanks Pekka, I'll check it out. > Good. I think this will clear some of the misconceptions you may have. > One of the advantages of KVM is supposed to be that it uses the Linux > kernel scheduler instead of having two schedulers, such as Xen

Re: [osv-dev] Does OSv have its own scheduler?

On Tue, Feb 19, 2019 at 12:21 AM Joe Duarte wrote: > > > On Monday, February 18, 2019 at 1:43:29 PM UTC-8, Nadav Har'El wrote: >> >> >> >> KVM and Xen are *hypervisors*, i.e., software which allows running >> multiple virtual-machines on one physica

Re: [osv-dev] [PATCH] Make OSv boot without ACPI present

On Tue, Feb 19, 2019 at 4:15 PM Waldemar Kozaczuk wrote: > This patch makes OSv boot without requiring ACPI > to be present which for example is the case on firecracker. > > We simply treat failure to find ACPI root pointer > as an indicator that ACPI is not available and > mark it off as such. A

Re: [osv-dev] [PATCH 2/5] libc: copy time/__tz.c from musl as is

Can you please explain the motivation of this? I thought maybe you are copying it instead of just enabling it in the Makefile because you needed to change it - but the I don't see changes in the next patches. So what's the motivation? -- Nadav Har'El n...@scylladb.com On Wed, Au

Re: [osv-dev] [PATCH 2/5] libc: copy time/__tz.c from musl as is

Oh, I now realize the *next* patch actually does change __tz.cc. And also the Makefile for the tests that I asked about the previous patch. So sorry about the spam. -- Nadav Har'El n...@scylladb.com On Wed, Aug 26, 2020 at 11:16 AM Nadav Har'El wrote: > Can you please explain t

Re: [osv-dev] [PATCH] bsd: rename __unused* macros to __bsd_unused* to avoid conflicts with musl headers

I'll commit. Of course what this means is that if one day we want to upgrade these BSD files, we'll have to do what we're doing now for Musl. But we can cross this bridge if we ever come to it :-) -- Nadav Har'El n...@scylladb.com On Thu, Aug 27, 2020 at 7:56 AM Waldemar Koz

Re: [osv-dev] [PATCH] libc: replace include/api/aarch64/bits/mman.h with a symlink to musl copy

On Sat, Aug 29, 2020 at 7:29 AM Waldemar Kozaczuk wrote: > This file and its aarch64 equivalent differs only to musl copies by > extra MAP_UNINITIALIZED macro. In order to drop this header > we create extra __mman.h headers and use them in libc/mman.cc. > I'm afraid that nobody will remember wha

Re: [osv-dev] [PATCH] libc: drop 5 more headers with symlinks to musl copies

Looks good to me, but I have some nitpicks below, on comments and stuff. On Sat, Aug 29, 2020 at 7:44 AM Waldemar Kozaczuk wrote: > Those 5 headers are mostly identical to their musl copies > except they were modified to comment out *64 macros that serve > as aliasing mechanism on musl side but

Re: [osv-dev] [PATCH] headers: get rid of fenv.h copy

Looks good, but again please add a comment on this __fenv.h why it exists. -- Nadav Har'El n...@scylladb.com On Sat, Aug 29, 2020 at 7:46 AM Waldemar Kozaczuk wrote: > Signed-off-by: Waldemar Kozaczuk > --- > arch/aarch64/feexcept.cc | 1 + > arch/x64/feexcept.cc | 1

Re: [osv-dev] Upgrading musl - I can see light in the tunnel

On Wed, Aug 26, 2020 at 7:58 AM Waldek Kozaczuk wrote: > It has been almost a month and I think I can see light in the tunnel. :-) Very nice work. > > For all the files we will have to keep changing the original musl files, I > suggest we actually store the .patch files as they make it easier

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

ly get from various tests I run and rerun. -- Nadav Har'El n...@scylladb.com On Tue, Sep 8, 2020 at 8:48 PM wrote: > See < > https://jenkins.scylladb.com/job/osv-build-nightly/2268/display/redirect> > > Changes: > > > -

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

On Tue, Sep 8, 2020 at 9:36 PM Nadav Har'El wrote: > I don't know how, but all the OSv projects directories > (/jenkins/slave/workspace/osv-* on muninn) were left with a root-owned > "scripts/__pycache__" directory, which broke this build. > > I see now that

Re: [osv-dev] [PATCH] rename musl submodule to musl_0.9.12 and add new submodule musl_1.1.24

Unfortunately, "git am" didn't really manage to do this. I suggest that you do the manual commands yourself and commit the results directly, instead of trying to send this as a patch. On Mon, Sep 21, 2020 at 7:40 AM Waldemar Kozaczuk wrote: > This patch renames existing submodule musl to musl_0

Re: [osv-dev] Re: [Question] TRACEPOINTs for modules and apps

I have to admit it's been a long while (a few years) since I looked deeply into our tracepoint implementation, so I'm quite rusty. I thought that in the past OSv tracepoints *did* work in modules - a good example is the test tests/tst-tracepoint - but I'm not sure this test actually tests everythin

Re: [osv-dev] [PATCH] rename musl submodule to musl_0.9.12 and add new submodule musl_1.1.24

Thanks. It seems to have worked - both in a manual run (I just needed to do "git submodule update --init") and also appears to have worked on Jenkins. -- Nadav Har'El n...@scylladb.com On Mon, Sep 21, 2020 at 5:30 PM Waldek Kozaczuk wrote: > I just dit it. I tested with a f

Re: [osv-dev] sigsetjmp/siglongjmp trouble with new musl

On Thu, Oct 1, 2020 at 6:41 PM Waldek Kozaczuk wrote: > I have been trying to implement missing support of sigsetjmp/siglongjmp > for aarch64 architecture which is critical (it looks) to get boost based > unit tests running. To that end, I replaced the stubs of these functions in > libc/arch/aarc

Re: [osv-dev] sigsetjmp/siglongjmp trouble with new musl

On Mon, Oct 5, 2020 at 9:48 PM Waldek Kozaczuk wrote: > > On Thursday, October 1, 2020 at 2:56:09 PM UTC-4 Nadav Har'El wrote: > >> >> I looked at the difference between the libc and musl implementation of >> sigsetjmp.s, and there are extensive differences I don

[osv-dev] [PATCH] syscall_to_function.h: simplify, and avoid C++20 extension

at all about anything which may or may not appear afterwards in parentheses. It's easier, shorter, and not C++20-specific. Fixes #1099 Signed-off-by: Nadav Har'El --- libc/syscall_to_function.h | 42 ++ 1 file changed, 15 insertions(+), 27

Re: [osv-dev] Supporting TLS descriptors

On Sun, Oct 11, 2020 at 11:44 PM Waldek Kozaczuk wrote: > As I have been researching what it would take to support TLS on aarch64, I > came across something called TLS descriptors which seems to be a default > mechanism to support Thread Local Storage on this architecture (please see > '-mtls-dia

Re: [osv-dev] [COMMIT osv master] elf: refine logging

On Fri, Oct 23, 2020 at 7:11 AM Commit Bot wrote: > From: Waldemar Kozaczuk > Committer: Waldemar Kozaczuk > Branch: master > > elf: refine logging > > This patch adds new build configuration option - `conf-debug_elf`, > intended to enable logging in dynamic linker logic. > > It also refines/ad

Re: [osv-dev] dlopen() and program::add_object() on github

On Wed, Nov 4, 2020 at 11:33 AM zero wrote: > Hi all, > > The issue is on github link > > > Then we continue the discuss. > > But I don't understand the "implicit" dependence you mention... It seems >> you mean that for some reason your applicat

Re: [osv-dev] dlopen() and program::add_object() on github

On Thu, Nov 5, 2020 at 2:23 PM zero wrote: > If step 3 were to *really* unload A, how would B's code, which is still >> loaded and may be using symbols from A, continue to work? > > > Yes step 3 will not unload A, and A is still in memory, when dlopen(A) > again, it will return a handle, and will

Re: [osv-dev] OSv in QEMU blog

On Fri, Nov 13, 2020 at 12:09 AM Fotis Xenakis wrote: > Hello everyone, > > OSv is featured in the most recent post on QEMU's blog [1], with regard to > its usage of virtio-fs. I was invited to write that post after the > virtio-fs devs showed interest in our use case. Also, I 'd like to > apolog

Re: [osv-dev] [PATCH] boot: early console code should not need symbol relocation

On Wed, Nov 25, 2020 at 7:32 AM Waldemar Kozaczuk wrote: > The arch_init_early_console() method called by premain very early in the > boot process should not require symbol relocations of any relevant > global variables as the elf::get_init() which does this is called later. > In theory we could

Re: [osv-dev] [PATCH] boot: early console code should not need symbol relocation

On Wed, Nov 25, 2020 at 5:13 PM Waldek Kozaczuk wrote: > > On Nov 25, 2020, at 02:21, Nadav Har'El wrote: > >  > > On Wed, Nov 25, 2020 at 7:32 AM Waldemar Kozaczuk > wrote: > >> Rather than annotating individual variables in source code with proper >&

Re: [osv-dev] [PATCH] boot: early console code should not need symbol relocation

able if we understood the problem, not just the solution :-) > So to simplify my patch shall we apply 'hide-symbols-flags' to all files > under arch/ and drivers/? > I don't know. It can certainly simplify the patch, but I still wish I knew what was the problem - why

Re: [osv-dev] [PATCH] vfs: add minimal implementation of unlinkat

On Sat, Dec 19, 2020 at 11:03 PM Waldemar Kozaczuk wrote: > The aarch64 version of Linux does not implement SYS_unlink. > The patch looks good, and unlinkat() will probably be needed for something else eventually so it's good to add it, so I'll commit. However, I don't understand why it's neede

Re: [osv-dev] [PATCH] aarch64: invalidate instruction cache after loading code into memory

Hi, very good job finding and solving this problem. I have some comments below, but also a question whether this works correctly on SMP: On Sun, Dec 20, 2020 at 6:43 AM Waldemar Kozaczuk wrote: > This is quite small and simple patch but it has taken me almost 2 months > researching and understan

Re: [osv-dev] [COMMIT osv master] kernel: enforce object files are compiled with '-fno-pie'

On Mon, Dec 21, 2020 at 7:11 AM Commit Bot wrote: > From: Waldemar Kozaczuk > Committer: Waldemar Kozaczuk > Branch: master > > kernel: enforce object files are compiled with '-fno-pie' > > On some Linux distributions like Ubuntu gcc compiles C/C++ files with > '-fPIC/' flags by default which I

Re: [osv-dev] [PATCH] aarch64: invalidate instruction cache after loading code into memory

On Mon, Dec 21, 2020 at 12:12 AM Waldek Kozaczuk wrote: > Hi, > > On Sunday, December 20, 2020 at 11:44:48 AM UTC-5 Nadav Har'El wrote: > >> Hi, very good job finding and solving this problem. I have some comments >> below, but also a question whether this works c

Re: [osv-dev] [PATCH] aarch64: invalidate instruction cache after loading code into memory

On Tue, Dec 22, 2020 at 5:44 PM Waldek Kozaczuk wrote: > On Monday, December 21, 2020 at 7:03:18 AM UTC-5 Nadav Har'El wrote: > >> >> This is interesting. As I said, I'm not an expert (not even close) on >> these matters, but from a few minutes I read, I t

Re: [osv-dev] [COMMIT osv master] kernel: enforce object files are compiled with '-fno-pie'

On Mon, Dec 21, 2020 at 6:36 PM Waldek Kozaczuk wrote: > > > On Monday, December 21, 2020 at 4:42:20 AM UTC-5 Nadav Har'El wrote: > >> On Mon, Dec 21, 2020 at 7:11 AM Commit Bot >> wrote: >> >>> From: Waldemar Kozaczuk >>> Committer:

Re: [osv-dev] Fedora 33 issues

On Tue, Nov 24, 2020 at 6:01 PM Waldek Kozaczuk wrote: > Even though I applied a patch that nominally adds support of Fedora 33 in > terms of setup, there are some issue I have found: > ... > 2. The lua module no longer build as Fedora 33 comes with the version 5.4 > and we rely on 5.3. We should

Re: [osv-dev] Fedora 33 issues

On Sun, Dec 27, 2020 at 7:02 PM Nadav Har'El wrote: > On Tue, Nov 24, 2020 at 6:01 PM Waldek Kozaczuk > wrote: > >> Even though I applied a patch that nominally adds support of Fedora 33 in >> terms of setup, there are some issue I have found: >> ... >>

Re: [osv-dev] Fedora 33 issues

On Sun, Dec 27, 2020 at 7:28 PM Nadav Har'El wrote: > On Sun, Dec 27, 2020 at 7:02 PM Nadav Har'El wrote: > >> On Tue, Nov 24, 2020 at 6:01 PM Waldek Kozaczuk >> wrote: >> >>> Even though I applied a patch that nominally adds support of Fedora 33 &g

[osv-dev] [PATCH] scripts/setup.py: simplify Fedora's Lua requirement

Each of the Fedora releases just installs whatever Lua version is available in this release. It is pointless to specify the specific version to install, when this is what happens by default anyway. Signed-off-by: Nadav Har'El --- scripts/setup.py | 16 +--- 1 file chang

Re: [osv-dev] Fedora 33 issues

ompatible/unavailable for that lua version. So that makefile would >> somehow need to take that into account. >> >> Sent from my iPhone >> >> On Dec 27, 2020, at 12:28, Nadav Har'El wrote: >> >>  >> >> On Sun, Dec 27, 2020 at 7:02 PM Nadav H

[osv-dev] [PATCH] musl: fix __stdio_read.c to conform to new Musl

teration increases the remaining bytes (by 1) instead of decreasing it by the number of read bytes as normal. Signed-off-by: Nadav Har'El --- libc/stdio/__stdio_read.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libc/stdio/__stdio_read.c b/libc/stdio/__stdio_read.c i

Re: [osv-dev] [PATCH] musl: fix __stdio_read.c to conform to new Musl

e very easy (a simple fread() from a directory should result in an endless loop) I will do it later. > Sent from my iPhone > > > On Dec 28, 2020, at 08:54, Nadav Har'El wrote: > > > > We have our own copy of __stdio_read.c because it was too complicated >

[osv-dev] [PATCH] Add test for fread() hang when reading from a directory

ut it. The test also passes on Linux. Signed-off-by: Nadav Har'El --- tests/tst-fread.cc | 14 ++ 1 file changed, 14 insertions(+) diff --git a/tests/tst-fread.cc b/tests/tst-fread.cc index 2da01f54..c65589ea 100644 --- a/tests/tst-fread.cc +++ b/tests/tst-fread.cc @@ -69,6 +69

Re: [osv-dev] OSv crash on pthread_start

On Mon, Jan 11, 2021 at 9:37 AM Deepak Krishnan wrote: > Hi, > > Running OSv with some Linux binaries and had a crash that I couldn't > completely understand: > > (gdb) where > #0 processor::cli_hlt () at arch/x64/processor.hh:248 > #1 0x40208fe6 in arch::halt_no_interrupts () at > arch

[osv-dev] [PATCH] pthread_create() - prefault top of stack

hat it is fixed. Signed-off-by: Nadav Har'El --- arch/aarch64/arch-switch.hh | 9 + arch/x64/arch-switch.hh | 9 + tests/tst-pthread-create.cc | 66 + modules/tests/Makefile | 3 +- 4 files changed, 86 insertions(+), 1 deletion(-) create m

Re: [osv-dev] OSv crash on pthread_start

On Mon, Jan 11, 2021 at 11:43 AM Deepak Krishnan wrote: > > > On Monday, 11 January, 2021 at 1:47:22 pm UTC+5:30 Nadav Har'El wrote: > > Interesting. Theoretically, there is no reason why we didn't reach >> preempt_enable() and enabled preemption. If we d

Re: [osv-dev] mkdir() syscall not supported?

On Mon, Jan 11, 2021 at 3:29 PM David Smith wrote: > I'm running my go application under OSv and I'm having an issue with the > mkdir() syscall (as accessed in go via os.Mkdir()). The issue appears to be > that OSv does not implement the mkdir() syscall. I've searched the > documentation and trie

Re: [osv-dev] mkdir() syscall not supported?

ir: %s\n", "dstmpat4"); > perror(""); > } > // Folder should have been created in the /tmp folder but actually gets > created in the current working folder (which appears to be the root folder) > So it sounds like there's a bug in the mkdirat() implementation

Re: [osv-dev] [PATCH] Fix mkdir syscall issue and implement mkdirat

On Tue, Jan 12, 2021 at 1:01 PM David Smith wrote: > Signed-off-by: David Smith > --- > fs/vfs/main.cc | 36 > fs/vfs/vfs.h | 1 + > fs/vfs/vfs_syscalls.cc | 27 +++ > libc/syscall_to_function.h | 2 ++

Re: [osv-dev] [PATCH v2] Fixed mkdirat bugs and improved to match other xxxat() implementations

Hi, It seems you sent an incremental patch over your previous patch, instead of sending a new version of your patch? -- Nadav Har'El n...@scylladb.com On Tue, Jan 12, 2021 at 3:35 PM David Smith wrote: > Signed-off-by: David Smith > --- > fs/vfs/main.c

Re: [osv-dev] [PATCH v2] Fixed mkdirat bugs and improved to match other xxxat() implementations

as much as possible) clean - we don't want two consecutive patches where the first is a broken implementation and the one following it is the correct implementation replacing it. We just want the correct implementation from the start. > On Thursday, January 14, 2021 at 7:24:19 AM UTC Nadav

Re: [osv-dev] [PATCH] threads: allocate stacks lazily to save memory

Thanks! I have quite a few comments below, but most of them are small points, nothing earth-shattering. On Sun, Jan 17, 2021 at 4:52 AM Waldemar Kozaczuk wrote: > As the issue #143 explains, currently applications stacks are eagerly > allocated (aka pre-populated) which may lead to substantial

Re: [osv-dev] [PATCH] include: support compiling OSv on CentOS 7

On Wed, Jan 20, 2021 at 7:29 PM Waldemar Kozaczuk wrote: > The gcc and more specifically C++ is setup on CentOS to reference obsolete > glibc isinf() and isnan() functions in the cmath header. It does so by > defining > _GLIBCXX_HAVE_OBSOLETE_ISINF and _GLIBCXX_HAVE_OBSOLETE_ISNAN macros in > bit

Re: [osv-dev] GDB stub

On Wed, Feb 3, 2021 at 1:18 AM Waldek Kozaczuk wrote: > Currently, it is only possible to connect from gdb to a running instance > of OSv on QEMU. But ideally, it would be nice to have a gdb stub in OSv > that would let one connect from gdb to OSv running on any hypervisor. > > Per this fragment

Re: [osv-dev] [PATCH] scripts: download and build arbitrary version of boost

On Fri, Feb 5, 2021 at 11:22 PM Waldemar Kozaczuk wrote: > On some distributions, like CentOS, the default version of boost > is really old. So the best option is to build a newer one from source. > Also even on Fedora or Ubuntu it might be useful to point to > different version of boost other th

Re: [osv-dev] [PATCH] scripts: allow building QEMU from sources

On Mon, Feb 8, 2021 at 5:12 AM Waldemar Kozaczuk wrote: > Add new script download_and_build_qemu.sh that allows building QEMU from > sources. It installs all necessary packages to build QEMU from sources, > downloads QEMU sources and builds both x86_64 and aarch64 versions of > it. > > Signed-off

Re: [osv-dev] [PATCH] sched: enforce tls register refresh after thread switch

On Mon, Feb 8, 2021 at 7:55 AM Waldemar Kozaczuk wrote: > On RISC architecture like aarch64 the thread register tpidr_el0 that > holds an address of thread local storage memory for current thread, > is never accessed directly in one instruction like on x86_64. Instead > compiler generates machone

Re: [osv-dev] AArch64 debug build woes

On Thu, Feb 11, 2021 at 7:42 AM Waldek Kozaczuk wrote: > > #1 0x10037954 in test_bsd_tcp1::tcp_server (this=0x206ff988) > at /home/wkozaczuk/projects/osv/tests/tst-bsd-tcp1-zsnd.cc:114 > > 114 int bytes2 = zcopy_tx(client_s, &zm); > > (gdb) p client_s > > $1 = 5 > > (gdb)

[osv-dev] Re: [PATCH 0/2] Enable cross compilation on multiarch distros

This patch seems reasonable to me, but I'd better leave it to Waldek to test that it doesn't break his own cross-compilation setup and commit it. Thanks. -- Nadav Har'El n...@scylladb.com On Sun, Feb 14, 2021 at 5:30 AM Punit Agrawal wrote: > Hi, > > Here's a c

Re: [osv-dev] AArch64 debug build woes

On Sat, Feb 13, 2021 at 6:24 PM Waldek Kozaczuk wrote: > Hi, > > On Thu, Feb 11, 2021 at 9:06 AM Nadav Har'El wrote: > >> On Thu, Feb 11, 2021 at 7:42 AM Waldek Kozaczuk >> wrote: >> >>> >>> #1 0x10037954 in test_bsd_tcp1::tc

Re: [osv-dev] AArch64 debug build woes

On Mon, Feb 15, 2021 at 7:43 AM Waldek Kozaczuk wrote: > > > On Sunday, February 14, 2021 at 2:33:16 PM UTC-5 Nadav Har'El wrote: > >> >> You seem to be pushing registers on the stack here. Where is this stack? >> In x86, we had separate stacks for exc

Re: [osv-dev] OSv page_fault assert during "bsd: initializing"?

On Mon, Feb 15, 2021 at 1:51 PM David Smith wrote: > I am running a Golang application on OSv under firecracker. Occasionally > (it's proving difficult to reproduce reliably) I see an assertion failure > early in the OSv startup sequence. The console output for my release build > is as follows: >

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

ly/detail/osv-build-nightly/2320/pipeline#log-1136>make[1]: *** [Makefile:33: upstream/jna-3.5.2.jar] Error 5 I'll prepare a patch for this and commit it. -- Nadav Har'El n...@scylladb.com On Sat, Feb 20, 2021 at 10:05 PM wrote: > See < > https:

Re: [osv-dev] [PATCH] Modifying times function to gracefully handle being passed a null pointer

Good catch - this is a Linux-specific behavior (not part of Posix) which we indeed forgot to handle. Thanks for the patch! I just have a few stylistic requests below: On Tue, Mar 9, 2021 at 9:11 PM 'Shawn Barber' via OSv Development < osv-dev@googlegroups.com> wrote: > Signed-off by: Shawn M Bar

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

to rerun the Jenkins job and see if it also succeeds the second "git pull" attempt. -- Nadav Har'El n...@scylladb.com On Sat, Mar 13, 2021 at 10:01 PM wrote: > See < > https://jenkins.scylladb.com/job/osv-buil

Re: [osv-dev] aarch64: some unit tests occasionally hang when running on QEMU in emulated mode

On Thu, Mar 11, 2021 at 9:12 PM Waldek Kozaczuk wrote: > Hi, > > In the last couple of days, I have been troubleshooting the scenarios when > some unit test would hang when running on QEMU in TCG mode. I have opened > an issue with extensive details and some findings - > https://github.com/cloudi

Re: [osv-dev] [PATCH v1] aarch64: implement reschedule_from_interrupt() in assembly

n for x86 if it's inlined and optimized. Moreover, from this discussion it's not entirely clear to me why this whole C function worked correctly in x86 - maybe it was just luck and in the future we'll need to do this for x86 as well. -- Nadav Har'El n...@scylladb.com On Mon, Mar 15

Re: [osv-dev] [PATCH 2/2] aarch64: populate image size in header

On Tue, Mar 16, 2021 at 8:06 PM 'Stewart Hildebrand' via OSv Development < osv-dev@googlegroups.com> wrote: > Depending on where the bootloader places loader.img and the DTB, there can > be a > conflict resulting in the the zero_bss loop in boot.S overwriting the DTB. > > I observed this with cert

Re: [osv-dev] [PATCH 1/2] setup.py: add xxd

On Tue, Mar 16, 2021 at 8:05 PM 'Stewart Hildebrand' via OSv Development < osv-dev@googlegroups.com> wrote: > and other pre-requisites needed for the next patch. Specifically, the next > patch > needs the following shell utilities (packages): > > readelf (binutils) > grep (grep) > awk (gawk)

Re: [osv-dev] [PATCH 2/2] aarch64: populate image size in header

On Wed, Mar 17, 2021 at 3:33 PM Stewart Hildebrand < stewart.hildebr...@dornerworks.com> wrote: > *From:* Nadav Har'El > *Sent:* Wednesday, March 17, 2021 4:37 AM > *To:* Stewart Hildebrand > *Cc:* OSv Development ; Waldek Kozaczuk < > jwkozac...@gmail.com> >

Re: [osv-dev] [PATCH] aarch64: mask interrupt and disable timer in the handler

On Fri, Mar 19, 2021 at 11:50 PM Waldemar Kozaczuk wrote: > The AArch64 Programmer's Guides Generic Timer (chapter 3.4, page 10) > states following: > > "The interrupts generated by the timer behave in a level-sensitive manner. > This means that, once the timer firing condition is reached, > th

Re: [osv-dev] aarch64: some unit tests occasionally hang when running on QEMU in emulated mode

this->write_ctl(ctl); >> + _callback->fired(); >> + } >> + } else { >> + _callback->fired(); >> +} >> } >> } >> >> So it seems that QEMU at least properly emulates the ISTA

Re: [osv-dev] [PATCH] aarch64: implement minimal PL031 support

Looks good to me, but I'm not at all an expert on these ARM devices. I only left minor comments below. On Fri, Mar 19, 2021 at 5:34 PM Waldemar Kozaczuk wrote: > This patch provides basic implementation of a subset of > functionality of the PrimeCell Real Time Clock (PL031) device > that is eno

Re: [osv-dev] aarch64: waiter.hh - should t variable be an atomic?

On Fri, Mar 26, 2021 at 6:10 AM Waldek Kozaczuk wrote: > As I have been researching a bit the SMP issue described here - > https://github.com/cloudius-systems/osv/issues/1123 - I have noticed that > the 't' variable in > https://github.com/cloudius-systems/osv/blob/master/include/osv/wait_record.

Re: [osv-dev] aarch64: waiter.hh - should t variable be an atomic?

On Sun, Apr 4, 2021 at 6:00 PM Waldek Kozaczuk wrote: > > > On Thursday, April 1, 2021 at 12:36:19 PM UTC-4 Nadav Har'El wrote: > >> On Fri, Mar 26, 2021 at 6:10 AM Waldek Kozaczuk >> wrote: >> >>> As I have been researching a bit the SMP issue desc

Re: [osv-dev] [PATCH] dynamic linker: properly handle STT_NOTYPE symbols

On Wed, Apr 28, 2021 at 4:27 AM Waldemar Kozaczuk wrote: > Some ELF files define global variables symbols with STT_NOTYPE > like in this example: > > 13030: 0243b390 0 NOTYPE GLOBAL DEFAULT 13 > v8_Default_embedded_blob_size_ > 13136: 02d09db8 0 NOTYPE GLOBAL DEFAULT

Re: [osv-dev] OSv page_fault assert during "bsd: initializing"?

On Fri, Apr 30, 2021 at 4:28 AM Waldek Kozaczuk wrote: > And I was also able to replicate it on QEMU running OSv in PVH mode on > microvm machine (similar to how firecracker runs it) again in nested > virtualization. > > ./scripts/run.py -k -p qemu_microvm --nics=0 -c 1 > > > I have used the same

Re: [osv-dev] [PATCH] aarch64: make RCU work correctly in SMP mode

Very nice detective work! I'm very rusty in this memory ordering business, so don't have a very useful review, and rather have a question below. -- Nadav Har'El n...@scylladb.com On Sun, May 9, 2021 at 11:13 PM Waldemar Kozaczuk wrote: > As the issue #1134 explains, some

Re: [osv-dev] [PATCH 1/3] libc: add strerrordesc_np

On Tue, May 25, 2021 at 8:03 AM Waldemar Kozaczuk wrote: > Per the specification, strerrordesc_np() is supposed to > return a pointer to a string that describes the error code > passed in the argument errnum just like strerror() does. > However unlike strerror(), strerrordesc_np() is NOT supposed

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