home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   RBERRYPI      Support for the Raspberry Pi device      21,939 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 20,116 of 21,939   
   Theo to Lawrence D'Oliveiro   
   Re: Rpi considerations   
   17 Jun 24 11:10:19   
   
   INTL 3:770/1 3:770/3   
   REPLYADDR theom+news@chiark.greenend.org.uk   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  f82dec2c   
   REPLY:  142bf51d   
   PID: SoupGate-Win32 v1.05   
   Lawrence D'Oliveiro  wrote:   
   > On 14 Jun 2024 09:59:17 +0100 (BST), Theo wrote:   
   >   
   > > Pi OS images are designed to be relashed to a Pi SD card, so don't UEFI   
   > > which is probably the way KVM/QEMU wants to boot them.   
   >   
   > Note the difference between KVM and QEMU: KVM is the virtualization   
   > architecture built into the Linux kernel, which allows it to run virtual   
   > machines of the same architecture type as the physical hardware it’s on,   
   > using the virtualization capabilities of that same hardware.   
   >   
   > QEMU is a collection of software emulators for a whole lot of different   
   > architectures, regardless of the actual hardware you run it on. It offers   
   > sufficient fidelity to the original hardware to support booting of OSes   
   > that were specifically written for that hardware. But being software-   
   > based, it will usually be slower than the actual hardware.   
   >   
   > When QEMU is asked to emulate architecture X when the physical hardware is   
   > that same architecture X, then you can ask it to bring in KVM to run the   
   > emulated OS at something close to native hardware speed. Note this is not   
   > something that happens automatically, if you don’t ask for it.   
      
   QEMU is not purely a collection of software emulators, although it does   
   contain those.   
      
   QEMU is the frontend, ie the thing that implements all the various I/O   
   devices and options like video drivers, virtual networking, USB passthrough,   
   all that stuff.   
      
   QEMU supports a number of virtualisation backends.  These just take care of   
   virtualising CPU instructions and providing the memory model - accesses to   
   I/O are trapped and passed through to QEMU to emulate.  There are three   
   popular ones:   
      
   1. KVM is Linux's virtualistion backend, which only works if   
   host architecture == guest architecture   
      
   2. Apple's virtualisation and hypervisor frameworks do a similar thing on Macs   
      
   3. QEMU contains its own cross-architecture emulation backend called TCG.   
   If you want to run one arch on another it's probably using TCG.   
      
   If you're running KVM on Linux then you're likely to be running QEMU in the   
   frontend to implement your I/O and interface with the world.  Orchestration   
   tools like virt-manager and libvirt mean you may not be touching QEMU   
   directly, but there is a QEMU running further down the stack.  ie KVM   
   almost certainly implies QEMU but QEMU doesn't imply KVM.   
      
      
   (QEMU also does user-mode emulation, using TCG to run individual Linux   
   binaries of one arch on another.  That's something else entirely)   
      
   Theo   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 10/0 1 90/1 103/705 105/81 106/201 124/5016 128/260 129/305   
   SEEN-BY: 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1 6 360   
   SEEN-BY: 226/17 30 100 227/114 229/110 111 112 113 200 206 300 317   
   SEEN-BY: 229/400 426 428 470 550 616 664 700 240/1120 266/512 267/800   
   SEEN-BY: 282/1038 291/111 292/854 301/1 113 812 310/31 320/219 322/757   
   SEEN-BY: 335/364 341/66 342/200 396/45 460/58 633/280 712/848 770/1   
   SEEN-BY: 770/3 100 330 340 772/210 220 230 5020/400 1042 5058/104   
   SEEN-BY: 5075/35   
   PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca