On Thu, 14 Mar 2024 22:14:57 +0000, MitchAlsup1 wrote:

> Lawrence D'Oliveiro wrote:
>
>> On Thu, 14 Mar 2024 00:11:55 GMT, Scott Lurndal wrote:
>
>>> The architectural features supporting virtualization are designed to
>>> isolate guests from both the hypervisor and other guests.
>
>> Providing an entire separate kernel for each VM is often unnecessary.
>> If you need separation at the level of entire subsystems, as opposed to
>> individual processes, then that’s what containers are for.
>
> If you are running k Linuxes under a single HyperVisor, you should be
> able to share all the Linux code after giving each of them their own VaS
> for data.

Unnecessary to set up complete separation only to poke holes (particularly
big holes) in it to share stuff. Simpler just to create a separation setup
that only separates what needs to be separate.

mitchalsup@aol.com (MitchAlsup1) writes:
>Lawrence D'Oliveiro wrote:
>
>> On Thu, 14 Mar 2024 00:11:55 GMT, Scott Lurndal wrote:
>
>>> The architectural features supporting virtualization are designed to
>>> isolate guests from both the hypervisor and other guests.
>
>> Providing an entire separate kernel for each VM is often unnecessary. If
>> you need separation at the level of entire subsystems, as opposed to
>> individual processes, then that’s what containers are for.
>
>
>If you are running k Linuxes under a single HyperVisor, you should be able
>to share all the Linux code after giving each of them their own VaS for data.

Bad idea. Single point of failure. Impossible to update one without
updating all. Linux does update code dynamically when loading and
unloading kernel modules.

On 3/14/2024 3:47 PM, Lawrence D'Oliveiro wrote:
> On Thu, 14 Mar 2024 22:11:41 +0000, MitchAlsup1 wrote:
>
>> There is no-one to take over.......and deal with the GuestOS
>> crash.......
>
> You can have a management process in the host that watches for these sorts
> of events, easily enough.

Watchdog, tick tick... ;^)

On Thu, 14 Mar 2024 17:21:29 -0700, Chris M. Thomasson wrote:

> On 3/14/2024 3:47 PM, Lawrence D'Oliveiro wrote:
>
>> On Thu, 14 Mar 2024 22:11:41 +0000, MitchAlsup1 wrote:
>>
>>> There is no-one to take over.......and deal with the GuestOS
>>> crash.......
>>
>> You can have a management process in the host that watches for these
>> sorts of events, easily enough.
>
> Watchdog, tick tick... ;^)

Event-driven would be more efficient and more responsive than periodic
polling.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 14 Mar 2024 17:21:29 -0700, Chris M. Thomasson wrote:
>
>> On 3/14/2024 3:47 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 14 Mar 2024 22:11:41 +0000, MitchAlsup1 wrote:
>>>
>>>> There is no-one to take over.......and deal with the GuestOS
>>>> crash.......
>>>
>>> You can have a management process in the host that watches for these
>>> sorts of events, easily enough.
>>
>> Watchdog, tick tick... ;^)
>
>Event-driven would be more efficient and more responsive than periodic
>polling.

That assumes that an event can be generated, which may not be possible
with a guest os crash (if, for example, it was in an infinite loop
with interrupts disabled).

On Fri, 15 Mar 2024 14:39:52 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>Event-driven would be more efficient and more responsive than periodic
>>polling.
>
> That assumes that an event can be generated, which may not be possible
> with a guest os crash (if, for example, it was in an infinite loop with
> interrupts disabled).

It wouldn’t be a “guest OS”, it would be a “guest container”. Remember,
the processes in the container are isolated from the host, but the host
continues to have full visibility into the guest.

For a container, guest termination is synonymous with termination of its
guest-specific “init” (container-internal PID 1) process. A host watcher
process can monitor several of these at once via the Linux pidfd mechanism
<https://manpages.debian.org/2/pidfd_open.en.html>.

On 3/15/2024 2:14 PM, Lawrence D'Oliveiro wrote:
> On Fri, 15 Mar 2024 14:39:52 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> Event-driven would be more efficient and more responsive than periodic
>>> polling.
>>
>> That assumes that an event can be generated, which may not be possible
>> with a guest os crash (if, for example, it was in an infinite loop with
>> interrupts disabled).
>
> It wouldn’t be a “guest OS”, it would be a “guest container”. Remember,
> the processes in the container are isolated from the host, but the host
> continues to have full visibility into the guest.
>
> For a container, guest termination is synonymous with termination of its
> guest-specific “init” (container-internal PID 1) process. A host watcher
> process can monitor several of these at once via the Linux pidfd mechanism
> <https://manpages.debian.org/2/pidfd_open.en.html>.

Akin to the logic that is used to make robust mutexes work. EOWNDERDEAD
in POSIX or WAIT_ABANDONED over on windows...

On 3/14/2024 4:40 PM, Chris M. Thomasson wrote:
> On 3/13/2024 10:32 PM, BGB wrote:
> [...]
>> Like, there isn't that huge of a gap between the technologies I had
>> used in my 3D engines, and those I am using in BJX2 and TestKern. Many
>> similar sorts of technologies end up being needed in both cases (say,
>> for example, hierarchical filesystems capable of dealing with mount
>> points, ...).
>
> Sounds good, BGB. BTW, do you mind if I pick your brain on some of this
> from time to time? I might even make a new thread so we can do it in
> public. Or on email. My address is working. Fwiw, here is some of my
> older modern opengl work:
>
> https://youtu.be/n13GHyYEfLA
>

Yeah. Kinda artsy...

Feel free to ask anything you want.

I haven't done as much serious graphics stuff recently, nor used much
outside of GL 1.x and 2.x functionality. If anything, my usage of newer
features had shrank.

> I made the music in one of my older MIDI programs. ;^D
>

My case, not much of a musician.

To what extent I had made "music", it was mostly filling out notes based
on numeric sequences and similar. A musical composition strategy that I
had seen mentioned in videos by both ViHart and Cyriak.

Also doesn't need to be a musical instrument per se, one of my older
examples had used DTMF tones (but, not seen a whole lot of music based
around using DTMF tones or similar as notes).

Well, that, or a few times transcribing notes from more traditional
songs into a MIDI program, and "if by magic" it plays some rendition of
the song (though, in these cases, had more often ended up messing with
Tracker technology).

Also have noted that I apparently have a sort of reverse slope hearing
impairment and don't seem to hear all that much below around 1-2 kHz (at
least in terms of sine waves or similar; can hear lots of other stuff
though, *).

This may effect how my hearing compares to others. Though, possibly, I
may not be the best judge of what others' will find pleasing.

*: I can hear what people are saying, just not over the telephone.
I can hear square and triangle waves and similar at low frequencies,
just seemingly not sine waves (tuning forks and similar are basically
silent).

Seemingly, for speech, one can discard everything below 2 kHz and it
still sounds fairly normal and intelligible, but if one discards
everything over 4 kHz, it is unintelligible (seemingly, most of what I
rely on here seems to be between 4 kHz and 8 kHz).

Also there are seemingly a lot of things that make sounds that other
people hear, but to me are basically silent.

Like, it is kinda weird, like everything sounds normal enough to me, but
there is seemingly a whole range of sounds for which, seemingly, I am
essentially deaf (and I seem to "hear" a lot of stuff seemingly
indirectly via harmonics; and if there are no harmonics, it is silent;
but when the harmonics are present, it sounds as-if the fundamental
frequency is present as well, even if these lower frequencies are
entirely absent in a plot of the spectrum).

Some theory would seem to imply that I should experience more
significant impairment though.

....

But, yeah, had implemented FM synthesis for my stuff, but admittedly
getting decent sounding music playback is a little harder.

Granted, I suspect in my case the lackluster music is either a
limitation of my MIDI playback code, or the design for my "sound chip"
cutting too many corners vs the design of the Yamaha chips.

So, general design:
16 channels, FM;
Has the OPL waveforms, but may use triangle waves rather than sine
waves, also has a few other PSG-like waveforms (square, sawtooth, ...);
Waveform is generated using a fixed-point accumulator operating at a
fixed frequency (IIRC, 20-bits operating at 64 kHz).

Internally, it actually updates channels at 1 MHz, but it updates each
FM channel one at a time (in the hardware, there is only actually a
single channel), so, say, 1 MHz / 16 -> ~ 64kHz.

My initial mock-ups had sounded more like an OPL than the final design,
but this could have been because the E3.F3 values used for volume
control aren't quite sufficient or similar. If it mattered more, could
fiddle more with it.

Had also experimented with wavetable music (with the design having been
extended to potentially also support MOD and S3M playback; with each FM
channel also able to function as a PCM channel), but my initial attempts
at throwing together a collection of General MIDI wavetable patches from
"free" sound effects, left something to be desired (it was a case of
trying to find sound effects that were a "close enough" match to the
various MIDI instruments, and maybe getting creative, or just reusing
the same patches for different instruments).

Though, with these limitations, and some audio-editing issues, generally
managed to sound worse than both the FM Synth and some patches derived
from the original GUS set.

Well, and as can be noted, Doom and friends don't use MOD or S3M music.

Have also noted that the music playback in ROTT sounds kinda horrid (not
yet figured this out).

Also some songs in Doom and Doom 2 seem to have issues with stuck notes,
implying there may be some bugs in my MIDI backend code as well (well,
either this, or missing NoteOff events).

....

Busily working away on adding capabilities to the current project, and
decided to add the operating mode / privilege ring (two bits) to the
capabilities instead of 'permit access system registers' (one bit).

I think this makes it possible for capabilities to work outside of the
current operating mode. The 'permit access system registers' was within
the current operating mode. Adding the operating mode makes the
capability mode agnostic.

However, I am unsure of the access implications. One could then give a
capability with the highest privilege mode to a user app.

I was going to try and eliminate the operating mode concept from the
current project and rely on capabilities instead. But there are
different levels of instructions and registers that could be allowed in
a capability. Using the operating mode acts as an indirect means to
specify these.

On 3/14/24 7:47 PM, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>> Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 14 Mar 2024 00:11:55 GMT, Scott Lurndal wrote:
>>
>>>> The architectural features supporting virtualization are designed to
>>>> isolate guests from both the hypervisor and other guests.
>>
>>> Providing an entire separate kernel for each VM is often unnecessary. If
>>> you need separation at the level of entire subsystems, as opposed to
>>> individual processes, then that’s what containers are for.
>>
>>
>> If you are running k Linuxes under a single HyperVisor, you should be able
>> to share all the Linux code after giving each of them their own VaS for data.
>
> Bad idea. Single point of failure.

Sharing the memory would mean that a single uncorrectable error
would apply to all sharers. Replicating it in the cheaper storage
layer (SSD?) would allow the hypervisor to reload an "independent"
copy, but providing higher redundancy/ECC 'single' instance
storage might be more effective. At some point system faults would
seem to present opportunity for all guest OSes to fail.

Interestingly, an uncorrectable memory error would be activated by
different guests at different times (unless perhaps there was some
kind of paravirtualization where the hypervisor could inform a
guest of such a latent error — one might be able to 'fake' it as
an asynchronous writeback error, though that could confuse an OS
[how did a dirty cache block occur for a read-only page??], or
perhaps hardware prefetching/memory scanning could inform the OS
of such an error and a hypervisor could present the error to the
guest as such a hardware-activated error).

> Impossible to update one without
> updating all. Linux does update code dynamically when loading and
> unloading kernel modules.

Presumably the hypervisor can use copy-on-write. I seem to recall
reading that at one time hashes of memory pages were generated by
virtualization systems to reduce the overhead of checking for page
duplication, so not only could a new page be separated as non-
duplicate but it might happen to be duplicate. This would seem
problematic when using huge pages in both guest — which makes
sense for some OS memory — and hypervisor — which generally makes
sense because guests are relatively large and this reduces page
table overhead.

I do not love pure virtualization (probably in part because I like
the idea of communicating across abstraction boundaries beyond the
bare minimum) and I am uncomfortable with the overheads of nested
paging, but there are significant advantages to both.

Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 14 Mar 2024 00:11:55 GMT, Scott Lurndal wrote:
>>
>>>> The architectural features supporting virtualization are designed to
>>>> isolate guests from both the hypervisor and other guests.
>>
>>> Providing an entire separate kernel for each VM is often unnecessary. If
>>> you need separation at the level of entire subsystems, as opposed to
>>> individual processes, then that’s what containers are for.
>>
>>
>>If you are running k Linuxes under a single HyperVisor, you should be able
>>to share all the Linux code after giving each of them their own VaS for data.

> Bad idea. Single point of failure. Impossible to update one without
> updating all. Linux does update code dynamically when loading and
> unloading kernel modules.

I actually have a 4-level system:: HyperVisor is the only layer that is not
allowed to crash (RISC-V calls this machine). Progressing towards less privilege
is GuestHV, GuestOS, and Application. Hypervisor provides only memory, timing,
and device identification services. GuestHV provides what most would call the
HyperVisor, GuestOS woudl be LINUX, and everybody knows what an application is.

mitchalsup@aol.com (MitchAlsup1) writes:
>Scott Lurndal wrote:
>>mitchalsup@aol.com (MitchAlsup1) writes:

>>>If you are running k Linuxes under a single HyperVisor, you should be able
>>>to share all the Linux code after giving each of them their own VaS for data.

>> Bad idea. Single point of failure. Impossible to update one without
>> updating all. Linux does update code dynamically when loading and
>> unloading kernel modules.
>
>I actually have a 4-level system::

That is completely orthogonal to the idea of sharing linux code between
guests.

ARMv8 has a similar 4-level (5, if your counting the machine layer):

- Machine (secure) (e.g. SMM)
- Hypervisor (non-secure)
- Nested Hypervisor (non-secure) [Optional, and not yet widely used]
- Guest OS (or Bare metal if there is no hypervisor)
- User mode

> HyperVisor is the only layer that is not
>allowed to crash (RISC-V calls this machine).

> Progressing towards less privilege
>is GuestHV, GuestOS, and Application. Hypervisor provides only memory, timing,
>and device identification services.

Absent universal SR-IOV, the hypervisor also needs to manage shared
I/O access (keyboard controller, graphics, disk and networking)
and with SR-IOV, creation and assignment of virtual functions.