<Wizzup>
silly question: is kvm support on the neo900?
<Wizzup>
supported*
sparetire_ has joined #neo900
louisdk has quit [Ping timeout: 255 seconds]
jonsger has joined #neo900
louisdk has joined #neo900
ozero has joined #neo900
<DocScrutinizer05>
is KVM supported on N900?
<DocScrutinizer05>
no joke, I simply don't know
<bencoh>
I doubt there is any usable virt instruction set in those omap3
<bencoh>
(complete enough for a KVM driver)
<DocScrutinizer05>
well, in HS devices there is quite some 'virtualization'
<DocScrutinizer05>
of course not exactly usable to the mere mortal developer
<DocScrutinizer05>
but indeed you could say N9 HARM runs in a VM
<bencoh>
that's not a proper hypervisor at cpu level :)
<drathir>
kvm i pretty sure no, but qemu i guess should be if able build...
<DocScrutinizer05>
err trustzone/M-shield for sure is even better than a mere hypervisor
<DocScrutinizer05>
M-Shield implements hardware separation between secure (hypervisor) and normal land, by a special signal on address bus
<DocScrutinizer05>
I don't know how much of the linux kernel runs as 'hypervisor' in HARM, and how much is simply a client asking for resources at M-Shield monitor which gets loaded by bootloader (dunno which stage) and clearly runs as hypervisor
<DocScrutinizer05>
this whole trustzone stuff is pretty complex
<DocScrutinizer05>
anyway I *guess* OMAP3/ARM_v7(?) has sufficient virt instructions
<bencoh>
I highly doubt it
<bencoh>
not that it does or doesnt offer a "more secure" framework, just that it doesnt allow you to switch between virtual machine contexts without a significant perf hit
<DocScrutinizer05>
calling monitor is a lightweight process
<DocScrutinizer05>
however that only switches from normal to secure land
<bencoh>
which is not exactly what you need for a complete "hypervisor" solution (kvm and friends)
<bencoh>
or you'd need to keep the baremetal hypervisor code running in secure land, and make a copy of every virtual machine (running in "normal land") context for every vm context switch
<DocScrutinizer05>
well, what's "virtualization"? Basically just separation of process contexts. There's not a big difference between normal process switching e.g. in linux and hypervisor context switching between several VM instances
<bencoh>
there is no conceptual difference :)
<bencoh>
(at least not that much)
<bencoh>
it's just about perf and what's being taken care of by the cpu
<DocScrutinizer05>
it probably gets nasty when your noth contexts concurrently want to mess with e.g. DSP or GPU
<DocScrutinizer05>
both*
<DocScrutinizer05>
but that's not much different no matter which thr CPU in your system
<DocScrutinizer05>
and usually it's simply forbidden
<DocScrutinizer05>
e.g all VMs on linux I know just offer a videocard emulation
<DocScrutinizer05>
oooh, I recall I've seen some VMware(?) running on N800(?)
<DocScrutinizer05>
never really got to market
<FIQ>
<DocScrutinizer05> e.g all VMs on linux I know just offer a videocard emulation
<FIQ>
if you have multiple graphics cards, you can give control over one to a guest
<DocScrutinizer05>
soooo, seems there's just enough "virt instructions" to make that fly
<bencoh>
DocScrutinizer05: kqemu/x86 has existed long before intel released vmx/VT, so ... it is possible to make something "work"
<bencoh>
it's just not the same as saying "we have virt instructions"
<bencoh>
(or "we can make kvm work")
<bencoh>
(and the purpose of kvm is exposing hardware virtualization features/instructions to userspace through kernel, not re-implementing kqemu)
<DocScrutinizer05>
whatever
<DocScrutinizer05>
when you understood your question on the level similar to "does Neo900 provide nvidia drivers?" then I missed the topic. sorry for that
<DocScrutinizer05>
I took it as "does virtualization work on Neo900"
<bencoh>
and I'd say "not the hw virtualization you hear of these days" :)
<DocScrutinizer05>
well, VMware is VMware
arcean has quit [Read error: Connection reset by peer]
<DocScrutinizer05>
and tbh I don't care too much if I use paravirtualization or whatever, as long as it works
<DocScrutinizer05>
aiui there are several tools that can convert a VM image between all known virtualization implementations
<FIQ>
isn't qemu just emulation?
<FIQ>
hence the name
<DocScrutinizer05>
sure
<FIQ>
e.g. equavilent to DOSbox (for example)
<DocScrutinizer05>
an emulation also is a container and thus some sort of virtualization
<bencoh>
plain qemu is just emulation
<DocScrutinizer05>
inside the emu only the resources the emu imports and exposes are available
<DocScrutinizer05>
see vagrant and which "providers" it supports
<DocScrutinizer05>
for example. Or VMM
<DocScrutinizer05>
first question: what you wanna do? Then see what tools provide a solution
<DocScrutinizer05>
and yes, I think there are tools to provide solutions around 'virtualization' at large, on maemo
<DocScrutinizer05>
and for sure on OMAP3
<DocScrutinizer05>
see Windows-NT-4.0-running-on-N900!.html which alas is 404 now, but it worked, though quite unbearably slow
<DocScrutinizer05>
they even booted macOS, also pretty slow
<DocScrutinizer05>
but it wouldn't be any faster on a P-II @ 300MHz, with only 250MB RAM
<DocScrutinizer05>
not even when run genuine
<DocScrutinizer05>
with twice the CPU clock, 1.6 times the RAM clock, and 4 times the amount of RAM, that should speed up a bit though
<ozero>
Hi all. Any known advantages of maemo 5 vs replicant/cyanogen security-wise? From what I've found LUKS option is limited to /home. And this is supposed to be default OS for neo900?..
<drathir>
FIQ: pci passthrought/gpu passthrought with ms almost native m$ speed and 3d gpu acceleration in vm...
Guest62377 has quit [Ping timeout: 256 seconds]
<FIQ>
drathir: I'm not sure if I can properly parse that sentence, but yes, I was talking about passthrough
<drathir>
and emulation vs kvm hv acceleration are diff things...
<FIQ>
(mainly the "with ms almost native m$ speed" part)
<drathir>
win 98 able to run even at e51 ^^
<Pali>
armv7 does not support virtualization, so no kvm or xen support
<Pali>
armv8 has that support
<DocScrutinizer05>
please move it over to #maemo!
<DocScrutinizer05>
OP did crossposting
<DocScrutinizer05>
oops, you're discussing virt
<DocScrutinizer05>
not maemo5
<drathir>
yes what i hear some arm support hw kvm acceleration, but not sure if arm or x86...
<DocScrutinizer05>
nm
<drathir>
k
<DocScrutinizer05>
ok, no xen on armv7 is sth I may buy instantly
<bencoh>
no kvm either
<DocScrutinizer05>
yes, after I learned what's kvm that is obviously true
<bencoh>
:]
<DocScrutinizer05>
though I still think the security monitor *could* implement such XEN hypervisor
<DocScrutinizer05>
it really creates a second system on top of the system
<DocScrutinizer05>
with completely isolated $everything
<DocScrutinizer05>
so this monitor could declare one hw timer as secure, initilize an tick IRQ on it, and then run the userland as a child process that has no way to access any resurces in secure land and can't block the secure monitor's tick IRQ either
<DocScrutinizer05>
in my book that should suffice to implement true virtualization
<DocScrutinizer05>
but then, I'm not an expert for that virt stuff
Guest62377 has joined #neo900
<bencoh>
DocScrutinizer05: you want to run several concurrent virtual machines
<DocScrutinizer05>
well, it's the supervisor to run them, no?
<DocScrutinizer05>
and it's the supervisor to allow acces to certain RAM addr as well as any other resources to the VM
<bencoh>
sure but you still need to save some context and prevent them from accessing each other (either by copying stuff around, or redefining some mem mapping/acess perms, or both)
<DocScrutinizer05>
so the hypervisor (not super...) is the instance to keep several VM's segregated
<DocScrutinizer05>
((redefining some mem mapping/acess perms)) that's exactly how this stuff works
<DocScrutinizer05>
all under exclusive control of the hypervisor
<DocScrutinizer05>
aka security monitor
<DocScrutinizer05>
the only thing the monitor/hypervisor copies around are the CPU registers themselves, aiui
<DocScrutinizer05>
since those are kept when transition normal -> secure mode happens
<DocScrutinizer05>
so monitor first of all stores the registers to some stack or other scratchpad area before it starts doing anything else
<DocScrutinizer05>
and the M-Shield is exactly excelling in "redefining access perms"
<DocScrutinizer05>
the access permissions are handled on a hw level
<DocScrutinizer05>
basically everything can get assigned to either normal mode or secure mode access only, or access by both
<bencoh>
you'd need to do it on every (vm) context switch
<DocScrutinizer05>
implemented by a special address line that signals if CPU is in secure mode or normal mode, and the peripheral system grants access accordingly. Be it RAM or any IO or registers or whatever. And the registers that decide who can access a resource are also just resources that obviously usually are under control of secure mode
<DocScrutinizer05>
you always need to do that on every VM switch
<DocScrutinizer05>
I wouldn't know of any other way to implement that
<DocScrutinizer05>
that's how context switching works on a computer
<DocScrutinizer05>
it's done usually a 50 to 1000 times per second, on any arbitrary multitasking system
<DocScrutinizer05>
some CPUs support context switching by providing several parallel identical sets of registers
<DocScrutinizer05>
M-Shield doesn't
<DocScrutinizer05>
however even 'huge' CPUs wouldn't provide more than maybe 8 such concurrent 'contexts'
<DocScrutinizer05>
and it got quite obsolete with fast ram anyway
<DocScrutinizer05>
heck, there are CPU architectures that basically have no registers at all anymore, doing everything in RAM
<drathir>
DocScrutinizer05: the qemu should workin, but speed not good...
<DocScrutinizer05>
drathir: sure, qemu is emulating even the CPU
<DocScrutinizer05>
this hardly can be as fast as the original CPU
<drathir>
also hear somethin the arm should have soon x86 kvm hw acceleration buildin for qemu to speedup x86 no idea how or its still planned...
<DocScrutinizer05>
this is related to ARMs visions about server business
lexik has quit [Ping timeout: 250 seconds]
<drathir>
DocScrutinizer05: yes some kind of low power and cost magic linux vm-s i guess...
<DocScrutinizer05>
:nod:
<drathir>
low power=low power comsumption*
<DocScrutinizer05>
ACPI in linux comes from same direction
<DocScrutinizer05>
s/linux/ARM/
ozero has quit [Quit: bye]
<DocScrutinizer05>
for servers you would probably want some sort of X86 support and ACPI, no matter if it's an X86 or ARM CPU in your server blade
<drathir>
DocScrutinizer05: the ARM primary adventage is posibbility to shutdown unused cores...
lexik has joined #neo900
lexik has quit [Remote host closed the connection]
<drathir>
that save power a lot...
lexik has joined #neo900
<DocScrutinizer05>
quite possible. I didn't look into that stuff in depth
<DocScrutinizer05>
but yes, energy savings are the major selling point for ARM based servers aiui
<DocScrutinizer05>
Intel CPU doesn't know zero-clock afaik
<drathir>
DocScrutinizer05: /me too not familiar with but ARM have a lot of magic, even with "big cores/low cores" or somethin like that, but i know thats looks nice...
<DocScrutinizer05>
in good old times students had a maybe 5 seconds CPU time allowance per month. So they would ponder how to keep clock cycle count low on their programs. Nowadays a common view on this is "the CPU is running anyway, so why not use it for something? Even when it's mere silly polling"
<drathir>
yes all x86_64 no possibility to shutdown to save power they have steppings, but not shuting unused...
<DocScrutinizer05>
:nod:
<drathir>
DocScrutinizer05: linux is still a lot better than m$, even in tot using 3d in desktop ;p
<drathir>
tot/not*
lexik has quit [Remote host closed the connection]
<drathir>
linux in idle is cold pc, m$ in idle always have a load ;/
<DocScrutinizer05>
yes
lexik has joined #neo900
<DocScrutinizer05>
though I can't speak for m$
<DocScrutinizer05>
I have one windows machine since ~6 months and I'm rarely ever using it
lexik has quit [Remote host closed the connection]
<DocScrutinizer05>
but I notice it's *always* busy when powered up
<DocScrutinizer05>
even the HDD
lobito1 has quit [Read error: Connection reset by peer]
lexik has joined #neo900
<drathir>
DocScrutinizer05: i often configuring ppl dual boot linux/m$ and in every config maded m$ in idle have load and warming compare to linux in idle was really idle and cold... that i guess its looks like hw independent yhing...
<DocScrutinizer05>
I think I already disabled that silly desktop indexing, doesn't help much though
<DocScrutinizer05>
anyway, have to run for some food and stuff. BBL
<drathir>
DocScrutinizer05: correct i always at all drives at m$ disable indexing of data on it...
<drathir>
no difference at all...
<drathir>
DocScrutinizer05: good taste...
<DocScrutinizer05>
thanks :-)
lobito has joined #neo900
<drathir>
and about hdd last time at clean installed m$ was funny the drive in desktop almost led not workin, when CRT sleeped by m$ the hdd led go crazy and the hdd almost not run out case, when pulpit come by mouse touch hdd go again silent ;p
<drathir>
m4 fo me is one big unpredictable somethin scary... its not like linux the some things always are the same steps in m$ is nothing possible to known for sure...
<drathir>
even installation is lottery if os mess with other hdds or not...
tomeff has joined #neo900
<drathir>
there are no rules or behaviour keeped ;/
rjeffries has quit [Ping timeout: 260 seconds]
<drathir>
but ppl maybe slowly aweake from blindness and discover other os..
lexik has quit [Remote host closed the connection]
lexik has joined #neo900
timclassic has joined #neo900
rjeffries has joined #neo900
louisdk has quit [Ping timeout: 250 seconds]
rjeffries has quit [Ping timeout: 250 seconds]
rjeffries has joined #neo900
dal has joined #neo900
louisdk has joined #neo900
paulk-aldrin has quit [Remote host closed the connection]
louisdk has quit [Ping timeout: 252 seconds]
louisdk has joined #neo900
vakkov has quit [Ping timeout: 268 seconds]
jonsger has quit [Remote host closed the connection]
jonsger has joined #neo900
louisdk has quit [Ping timeout: 250 seconds]
vakkov has joined #neo900
lexik has quit [Remote host closed the connection]
lexik has joined #neo900
lexik has quit [Remote host closed the connection]
<Arch-TK>
DocScrutinizer05: so these serial AT command things... a lot of things use them?
<DocScrutinizer05>
well hayes command set is standard for modem control since... 1978 maybe
<Arch-TK>
apparently the ESP8266 (a small wifi microcontroller thing) uses them
<Arch-TK>
that makes me wonder, does my wifi card probably use this stuff?
tomeff has quit [Quit: tomeff]
paulk-collins has quit [Quit: Quitte]
Guest62377 has quit [Ping timeout: 256 seconds]
<DocScrutinizer05>
no, WiFi and Hayes AT are two things I never heard in same context
Guest62377 has joined #neo900
<DocScrutinizer05>
WiFi is about channel selection, about encryption and authentication and so on. All these are topics genuinely unknown to AT which came from circuit switched telephone landlines and basically always was about telephone only
<DocScrutinizer05>
the AT command syntax is probably flexible enough so you theoretically could control WiFi or stitching machines or a AirBus A380 with it, but I never heard of either ;-)
jonsger has quit [Quit: jonsger]
<DocScrutinizer05>
then OTOH Hayes AT is a very poor and bad standard since it works mostly asynchronous and more often than not you have to guess a wait period to listen for command replies. Also there's no real link between command and reply, so sending more than one command concurrently gets terribly messy
<DocScrutinizer05>
as mentioned above, the Hayes AT cmd "standard" was defined in a time where you couldn't send/receive more than ~30 chars/bytes per second, and the command execution times were system-immanently in the range of several seconds