OSDev.org

The Place to Start for Operating System Developers
It is currently Sun Apr 21, 2019 12:16 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: The Terrific Tell and Talk Thread
PostPosted: Thu Apr 04, 2019 9:32 pm 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 pm
Posts: 33
A picture is worth a thousand words, or 3396 posts. But "As the Chinese say, 1001 words is worth more than a picture." This is the thread for your 1001 words!

Have you recently added a new feature to your OS, or accomplished some milestone? Well we'd love to hear about it! This aims to be an in-depth counterpart to the screenshot thread, where here you can go into detail about what you worked on. We encourage you to talk about challenges you faced, fun or interesting things you learned in the process. Even how you managed to solve the problem.

The motive here is to stimulate conversation not on abstract ideas or designs, but things you yourself got working in your OS. Where you can discuss the pros and cons of your choices, alternate ideas and share results and ideas with the community. Whether you want to expose yourself to alternate views, inspire ideas in others, or are just proud of some really cool thing you did, we want your words!

To those working on their own OS, we encourage you to start with an introduction to your project. Tell us a little bit about it, and over time share your progress.
To those just curious or in-between projects, feel free to join in and ask questions and get involved.

_________________
Image is my operating system.

"...not because [it is] easy, but because [it is] hard; because that goal will serve to organize and measure the best of [my] energies and skills..."


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Fri Apr 05, 2019 10:24 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 564
I guess I will start this thread :D.

In the last two weeks, I did an overhaul of my microkernel's memory management. The features that I support now are:
  • Evicting pages from the page cache on a least recently used (LRU) basis
  • Memory locking: locking pages so that they cannot be evicted
  • Writeback of dirty pages back to disk
  • And, finally, copy on write (CoW)

Out of all those features, CoW is the most interesting one. Managarm actually did support CoW some years ago but I had to disable it due to the lack of support for memory locking. The interaction of CoW and locking is crucial for correctness: locked paged have to be copied eagerly during fork(); is this is not honored, the CoW mechanism would change the physical address of a page while it is already locked (and that makes programs not see the result of DMA operations or miss futex wakeups). I'm glad that this works now. It only gave a moderate improvement in performance (copying memory is really not that slow) but a huge improvement in memory consumption (from about 1GiB to 600MiB to boot to Weston).

_________________
managarm: A microkernel-based OS that is capable of running a Wayland desktop


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Fri Apr 05, 2019 7:09 pm 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 pm
Posts: 33
Korona wrote:
I guess I will start this thread :D.

In the last two weeks, I did an overhaul of my microkernel's memory management. The features that I support now are:
  • Evicting pages from the page cache on a least recently used (LRU) basis
  • Memory locking: locking pages so that they cannot be evicted
  • Writeback of dirty pages back to disk
  • And, finally, copy on write (CoW)

Out of all those features, CoW is the most interesting one. Managarm actually did support CoW some years ago but I had to disable it due to the lack of support for memory locking. The interaction of CoW and locking is crucial for correctness: locked paged have to be copied eagerly during fork(); is this is not honored, the CoW mechanism would change the physical address of a page while it is already locked (and that makes programs not see the result of DMA operations or miss futex wakeups). I'm glad that this works now. It only gave a moderate improvement in performance (copying memory is really not that slow) but a huge improvement in memory consumption (from about 1GiB to 600MiB to boot to Weston).


Cool! So this page cache is for pages originating from files? Or more generally to handle swap and shared memory? Whose able to lock pages, I imagine its limited to kernel stuff?

Aside: I like seeing another C++ OS that embraces Modern™ C++ and not just C with classes, at least from a quick look. And I may have spent way too long laughing at one line, imagining a Jersey guy saying "friggin' make a shared cow chain, get smarter and allocate a shared cow mapping already


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Sat Apr 06, 2019 3:33 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 564
pat wrote:
Cool! So this page cache is for pages originating from files? Or more generally to handle swap and shared memory? Whose able to lock pages, I imagine its limited to kernel stuff?

Aside: I like seeing another C++ OS that embraces Modern™ C++ and not just C with classes, at least from a quick look. And I may have spent way too long laughing at one line, imagining a Jersey guy saying "friggin' make a shared cow chain, get smarter and allocate a shared cow mapping already

Thanks :). Yes, the page cache is for pages originating from files (it's basically the pages that get mapped to userspace on mmap()). I do not have swapping yet, but the mechanisms will probably be similar. Right now, only the kernel locks memory, but I will also make this available for userspace drivers and to implement mlock().

_________________
managarm: A microkernel-based OS that is capable of running a Wayland desktop


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Sat Apr 06, 2019 2:26 pm 
Offline
Member
Member
User avatar

Joined: Sun Feb 20, 2011 2:01 pm
Posts: 54
I've been thinking about NUMA and caching in view to doing a proper pmmngr.
Getting NUMA information is conceptually simple, just consult SRAT if it exists. Ofc, there's the DSDT processor objects, but my understanding is that they shouldn't be required at boot.

Caching is a bit more interesting, seeing as ARM big.LITTLE configurations can have cache lines of different sizes. The best approach that I can think of to store this is to store an object representing each cache, and have each CPU object refer to it. Of course, getting the complete heirarchy needs the code to run on each processor, as described in an Intel document. The problem with big.LITTLE is that the CPUs are switched on the fly, so code that depends on line size can break, no matter how much conceptual information you posess.

The solution of course is to work in lcms of all cache line sizes in the system (after all, powers of two are fairly popular). AMP can get messy!

_________________
Whoever said you can't do OS development on Windows?


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Sun Apr 07, 2019 7:29 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 553
Location: USA
Okay, I have a few minutes and will contribute to this thread. I think this thread is probably a good idea, so that the ScreenShot thread doesn't get over-run with non-screen shot posts.

Anyway, I have had a few generous readers send in bug reports which have got me working on some of my stuff.

For example, a fellow reader sent in a bug report just today stating that I had a bug in my MBR.asm source at line 162.
Rather than being:
Code:
   jne  short part_done
he suggested that it should be:
Code:
   jne   short part_walk_next
This is a good point. However, and for the purpose of this thread, the code at that link is a bit old. I have since added TPM support to simply create the hash value for the boot. By doing so, because of the 512-byte size restraint, I had to size optimize the other code which, unknowingly to me, fixed the issue he pointed out. (smile).

Another reader tried my OS on a couple of his 64-bit machines and was (very) unsuccessful. Now, before I go to much further, my OS is targeted to 32-bit machines so I didn't think too much about until I got looking. Come to find out, the way I was organizing Mem-Mapped devices was causing an issue and returning a physical memory address of +0x80 passed the value it should have for certain devices. Unknown why, it just was. After a re-write of this Mem-Mapped organizer code, we started seeing a much more successful run of my OS on his machines.

However, the initial point of his intrigue was to see if my OS would recognize his xHCI controller and attached devices. Come to find out, my OS does not successfully enumerate the devices on his laptop. I have not tried my OS on a 64-bit machine with a 64-bit capable xHCI controller, so I needed to check that I was clearing the high order dword of all my addresses. After looking over my code, I found a few other small bugs/issues as well.

Unfortunately, I still haven't found the issue why it isn't working on his machine(s). Since my code works on all controllers I have tested it with, noting that they are all 32-bit only controllers on 32-bit machines, I have to guess that it is something to do with it being a 64-bit machine with a 64-bit capable controller, though it could be something else as well. Thank you to this reader's help, I have been able to narrow it down to a few things and hope to have it fixed soon. (My code retrieves the first 8 bytes of the descriptor, but fails when trying to set the address of the device)

I send him an email stating that I have a new bootable image for him to try, he boots it, takes a picture of the screen, and sends me a JPEG of the screen where the error is shown. It has been very helpful, and I thank him for it.

Granted, it would be a lot easier if he could send me the log file, but since his keyboard is attached to the xHCI root hub, and this root hub is the current issue, there is no way for him to type to save the log, nor can I hard code it to save the log since the target media device is also attached to this root hub. uuurrrgggg. :-) He has been very kind and patient by sending the pics.

I also have an issue with my EHCI code that I cannot put my finger on. It only happens every once in a while.

On a different note, the thing I am currently working on is PCI IRQ routing. I am trying to re-write my code so that from the device driver, I can request an IRQ number from the system software, accounting for PCI interrupt Pin and Interrupt Line values, PCI bridges, etc. For example, I recently hard coded an IRQ value of 5 to a PCI device and couldn't figure out why I wasn't getting interrupts. Come to find out, the value of 5 was not part of the Pin/Line combination of the PCI bridge/host it was attached to. No physical line to use IRQ 5. :-)

Well, this is my story and progress. If any of you wish to try my stuff, a (USB) bootable image can be found at http://www.fysnet.net/zips/fysos.zip (7.0 Meg) or the stripped down version that I have been sending to the reader mentioned above can be found at http://www.fysnet.net/temp/tempfysos.zip (450k). To repay the favor, if you have a (USB) bootable image, let me know and I will test it out on a few of my machines.

Thank you all for comments, the hosts of this forum, and any contributors here. This is a fun and interesting hobby.
Ben
- http://www.fysnet.net/osdesign_book_series.htm

P.S. The current build in the two links given have the graphics turned off. i.e.: It is text only. This makes it much faster and easier to test something that doesn't require graphics. After I fix the issue with the xHCI I spoke of above, I will re-build it with the graphics code where you can then run the GUI if you wish.


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Wed Apr 10, 2019 2:00 am 
Offline
Member
Member
User avatar

Joined: Wed Jul 13, 2011 7:38 pm
Posts: 548
This is a pretty neat idea for a thread.

I've never actually really posted about my project on the forums. It's come up in discussion and in passing in #osdev on Freenode, since I spent a lot more time hanging around there than I do posting here, but I don't think I've ever explained what it *is*. Put simply, I'm designing and developing a router.

Okay, it's a bit more complex than that. I'm not a programmer by trade or by formal education; I'm a network engineer. I work on networks all day long, touching everything from straightforward campus ethernet and IP networks to multinational WANs utilizing multipoint VPN protocols living on multiple types of transports. My project is intended to produce a relatively simple environment that can be used to turn spare hardware into a solid device that can route between IP networks, and be configured without needing to look up piles of conf file documentation.

Now, of course, it'd be fun to be the person saying "heck yeah I'm going to take on $incumbent_router_manufacturer" but I have no expectation of being able to do that. I can't write and maintain enterprise-grade routing software in my spare time. I can't design and fab up IP forwarding ASICs. Hell, I don't even know where I'd go about OEMing some 1U x86-based routers. What I'm doing is mostly just for my own entertainment and also to get a bit more lower-than-low-level knowledge of networking, in case it might come in handy in my career. But as far as this hobby goes, it serves as being something relatively unique. I can't recall ever seeing a hobby OS project that's designed to be a router.

I'm a big proponent of setting real-world usability goals in the more advanced "levels" of hobby operating systems development. This is mine.

What have I been working on recently? Well, eliminating stability problems and loss issues, recently. I've taken a few weeks off from working on it, so coming back to the issues I had before (5-8% packet loss, mass forwarding failures after too high traffic spikes) with a fresh set of troubleshooting plans has done wonders. Currently, doing incredible naïve forwarding including full routing table lookups, MAC table lookups, packet copying, and input/output queue processing for every packet, I'm maintaining a 1200 byte packet forwarding rate of about 120 Mbps when testing with ESXi 6.5 and its relatively terrible Intel NIC emulation. This is honestly pretty damn slow, but considering there's effectively no forwarding optimization going on here, and I'm fairly certain I'm being limited by the sheer number of VMEXITs that are being done, it's not bad.

Theoretically, the forwarding engine is capable of being used in production for my lab network. However, I'm not quite sure of its stability. I'm leaving it forwarding as fast as it can overnight to see if it holds up. If it can stay alive overnight, I'll add a third interface to the router VM, put it on my production vSwitch in ESXi, and configure the interface in my OS to have an IP on my "production" home network. Then we'll see how it handles traffic from real machines.

My next goals are:
  • Reduce the amount of time I spent in the forwarding process by caching MAC header rewrites, implementing a FIB, reducing copy amounts.
  • Acquire more real machines so I don't have to rely on emulated NICs and be constrained by VMEXIT performance.
  • Implement network address translation.


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Fri Apr 12, 2019 4:06 am 
Offline
Member
Member

Joined: Mon Jul 25, 2016 6:54 pm
Posts: 166
Location: Adelaide, Australia
I'm quite excited to see this thread I think it's a good idea to have a place on the forums where people can just discuss what their working on without necessarily asking a question or anything. It's just in time for me personally too, as my project has finally crossed the border (in my mind) from bare metal 386 executable to operating system, so I finally have something to say about it.

Today, for the first time I have a system where an arbitrary number of unprivileged ELF binaries (in GRUB modules) can run indefinitely side by side in separate address spaces with the kernel switching between them. Technically I have user mode applications running on an operating system. yay!

To get to this point, I have implemented physical and virtual memory management (including kernel heap), process control, interrupt handling (including some syscalls) and the ability to load a subset of ELFs. From here I feel things open up, almost a scary amount! Of course this is hardly ground breaking stuff, but it's quite thrilling to hit this point for the first time.


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Fri Apr 12, 2019 9:36 am 
Offline
Member
Member
User avatar

Joined: Sun Feb 20, 2011 2:01 pm
Posts: 54
StudlyCaps wrote:
I'm quite excited to see this thread I think it's a good idea to have a place on the forums where people can just discuss what their working on without necessarily asking a question or anything. It's just in time for me personally too, as my project has finally crossed the border (in my mind) from bare metal 386 executable to operating system, so I finally have something to say about it.

Today, for the first time I have a system where an arbitrary number of unprivileged ELF binaries (in GRUB modules) can run indefinitely side by side in separate address spaces with the kernel switching between them. Technically I have user mode applications running on an operating system. yay!

To get to this point, I have implemented physical and virtual memory management (including kernel heap), process control, interrupt handling (including some syscalls) and the ability to load a subset of ELFs. From here I feel things open up, almost a scary amount! Of course this is hardly ground breaking stuff, but it's quite thrilling to hit this point for the first time.

Nice progress! An HDD driver could be a good next step, ditch the module requirement. Ofc, the proliferation of SATA makes that a bit more fun.

_________________
Whoever said you can't do OS development on Windows?


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Fri Apr 12, 2019 12:42 pm 
Offline
Member
Member

Joined: Wed Jun 17, 2015 9:40 am
Posts: 496
Location: Athens, Greece
Hi,


StudlyCaps wrote:
Today, for the first time I have a system where an arbitrary number of unprivileged ELF binaries (in GRUB modules) can run indefinitely side by side in separate address spaces with the kernel switching between them. Technically I have user mode applications running on an operating system. yay!

To get to this point, I have implemented physical and virtual memory management (including kernel heap), process control, interrupt handling (including some syscalls) and the ability to load a subset of ELFs. From here I feel things open up, almost a scary amount! Of course this is hardly ground breaking stuff, but it's quite thrilling to hit this point for the first time.
Congratulations on your progress! I'd say it's definitely an operating system now, even if you are using a ramdisk or similar modules. Now, as you said, things open up. You can go in several directions: storage, filesystems, networking, graphics, audio, userspace, porting (if applicable), etc. Do whatever you like! :-)

bellezzasolo wrote:
Nice progress! An HDD driver could be a good next step, ditch the module requirement. Ofc, the proliferation of SATA makes that a bit more fun.
Or an ATAPI driver, it depends where are you booting from. But one would probably also need a filesystem driver too in order for a storage driver to be useful.


Regards,
glauxosdever


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Fri Apr 12, 2019 8:52 pm 
Offline
Member
Member

Joined: Mon Jul 25, 2016 6:54 pm
Posts: 166
Location: Adelaide, Australia
Thanks for the kind words guys! I'm currently adding a basic serial port driver to make debugging a bit easier, but I like the idea of adding drive support next, from there I can load programs at run time, then I think a user shell makes sense.

Though I'm booting from cdrom, I might go straight for AHCI and then implementing ATAPI support from there, then SATA.


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Sun Apr 14, 2019 7:28 pm 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 pm
Posts: 33
Kazinsal wrote:
Okay, it's a bit more complex than that. I'm not a programmer by trade or by formal education; I'm a network engineer. I work on networks all day long, touching everything from straightforward campus ethernet and IP networks to multinational WANs utilizing multipoint VPN protocols living on multiple types of transports. My project is intended to produce a relatively simple environment that can be used to turn spare hardware into a solid device that can route between IP networks, and be configured without needing to look up piles of conf file documentation.


This is a cool project. I wonder what the performance implications are of designing and owning the entire stack for one explicit purpose, or what doing so would allow one to do that otherwise couldn't.

StudlyCaps wrote:
o get to this point, I have implemented physical and virtual memory management (including kernel heap), process control, interrupt handling (including some syscalls) and the ability to load a subset of ELFs. From here I feel things open up, almost a scary amount! Of course this is hardly ground breaking stuff, but it's quite thrilling to hit this point for the first time.


Welcome aboard! I'd agree with glauxosdever, getting to full memory and cpu management crosses the line from bootable program to the beginnings of an operating system. Exciting times will be a plenty now. If you start to feel a bit of analysis paralysis about where to go next, pick one thing that you'd like to define your project with and start going down that path.

@Kazinsal and StudlyCaps do you have your projects on Github or somewhere you'd like to share?


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Mon Apr 15, 2019 6:14 am 
Offline
Member
Member

Joined: Wed Oct 26, 2011 12:00 pm
Posts: 185
Great idea for a thread! I'll happily share one of my more recent troubles that took me atleast a week to fix. I've spent the last few months making sure that my graphic stack is running smoothly on 64 bit as it were on 32 bit, which meant getting LLVM and Mesa3D to play nicely together with my operating system, and during rendering I kept getting a strange memory fault in dlfree (dlmalloc), it seamed that memory were being corrupted.

By further inspection i then found out memory were not being corrupted, but rather LLVM was calling free on an invalid address. The address being freed was 32 bytes larger than the address that was returned by malloc. So i then had to dig down into both mesa3d and LLVM to figure out where the address was being allocated, why the wrong address was being freed and where it was being used. It took me atleast one or two days to figure out that the address was both allocated correctly and used correctly, BUT it actually were during initialization of a stack object due.

Due to optimizations it used XMM6 and XMM7 registers to initialize the stack objects since they were very large in size, which I first thought was weird, why not use XMM0 and XMM1? Well by researching this I then found out that XMM6 and XMM7 are non-volatile, while XMM0-5 are volatile, which the function relied on being empty suddenly contained various addresses.

This immediately made me suspecious about usage of my memcpy where I've written both SSE and SSE2 versions that use these registers, and correctly enough it was due to not saving XMM6 and XMM7 registers in 64 bit mode, which resulted in me overwriting the cleared XMM6 register. This caused the object to be initialized with existing values instead of being initialized with zeros.

This was also an issue in the 32 bit versions, but the optimizer did not use those registers when building the 32 bit image.
What'd you know.

_________________
Github
Website


Top
 Profile  
 
 Post subject: Re: The Terrific Tell and Talk Thread
PostPosted: Tue Apr 16, 2019 11:01 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 564
Kazinsal wrote:
What have I been working on recently? Well, eliminating stability problems and loss issues, recently. I've taken a few weeks off from working on it, so coming back to the issues I had before (5-8% packet loss, mass forwarding failures after too high traffic spikes) with a fresh set of troubleshooting plans has done wonders. Currently, doing incredible naïve forwarding including full routing table lookups, MAC table lookups, packet copying, and input/output queue processing for every packet, I'm maintaining a 1200 byte packet forwarding rate of about 120 Mbps when testing with ESXi 6.5 and its relatively terrible Intel NIC emulation. This is honestly pretty damn slow, but considering there's effectively no forwarding optimization going on here, and I'm fairly certain I'm being limited by the sheer number of VMEXITs that are being done, it's not bad.

Your project sounds very interesting. Have you considered implementing a driver for a paravirtualized NIC (such a virtio-net)? I do not know what ESXi supports in that direction; for qemu/kvm, however, the virtio interfaces give a huge performance boost.

_________________
managarm: A microkernel-based OS that is capable of running a Wayland desktop


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group