Re: Rpi considerations

Liste des GroupesRevenir à cs raspberry-pi 
Sujet : Re: Rpi considerations
De : theom+news (at) *nospam* chiark.greenend.org.uk (Theo)
Groupes : comp.sys.raspberry-pi
Date : 17. Jun 2024, 11:10:19
Autres entêtes
Organisation : University of Cambridge, England
Message-ID : <dCF*IlaNz@news.chiark.greenend.org.uk>
References : 1 2 3 4 5 6 7
User-Agent : tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-28-amd64 (x86_64))
Lawrence D'Oliveiro <ldo@nz.invalid> 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

Date Sujet#  Auteur
8 Jun 24 * Re: Rpi considerations6Chris Elvidge
8 Jun 24 +- Re: Rpi considerations1Björn Lundin
14 Jun 24 `* Re: Rpi considerations4Theo
14 Jun 24  +- Re: Rpi considerations1Theo
15 Jun 24  `* Re: Rpi considerations2Lawrence D'Oliveiro
17 Jun 24   `- Re: Rpi considerations1Theo

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal