qemu/docs/system/device-emulation.rst
Henrik Carlqvist 6b90a4cdc0 escc: emulate dip switch language layout settings on SUN keyboard
SUN Type 4, 5 and 5c keyboards have dip switches to choose the language layout
of the keyboard. Solaris makes an ioctl to query the value of the dipswitches
and uses that value to select keyboard layout.  Also the SUN bios like the one
in the file ss5.bin uses this value to support at least some keyboard layouts.
However, the OpenBIOS provided with qemu is hardcoded to always use an US
keyboard layout.

Before this patch, qemu allways gave dip switch value 0x21 (US keyboard),
this patch uses a command line switch like
"-global escc.chnA-sunkbd-layout=de" to select dip switch value. A table is
used to lookup values from arguments like:

-global escc.chnA-sunkbd-layout=fr
-global escc.chnA-sunkbd-layout=es

But the patch also accepts numeric dip switch values directly:

-global escc.chnA-sunkbd-layout=0x2b
-global escc.chnA-sunkbd-layout=43

Both values above are the same and select swedish keyboard as explained in
table 3-15 at
https://docs.oracle.com/cd/E19683-01/806-6642/new-43/index.html

Unless you want to do a full Solaris installation but happen to have
access to a Sun bios file, the easiest way to test that the patch works
is to:

qemu-system-sparc -global escc.chnA-sunkbd-layout=sv -bios /path/to/ss5.bin

If you already happen to have a Solaris installation in a qemu disk image
file you can easily try different keyboard layouts after this patch is
applied.

Signed-off-by: Henrik Carlqvist <hc1245@poolhem.se>
Message-Id: <20230623203007.56d3d182.hc981@poolhem.se>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[MCA edit: update unsigned char to uint8_t, fix spacing issues]
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2023-06-28 10:54:25 +01:00

99 lines
3.3 KiB
ReStructuredText

.. _device-emulation:
Device Emulation
----------------
QEMU supports the emulation of a large number of devices from
peripherals such network cards and USB devices to integrated systems
on a chip (SoCs). Configuration of these is often a source of
confusion so it helps to have an understanding of some of the terms
used to describes devices within QEMU.
Common Terms
~~~~~~~~~~~~
Device Front End
================
A device front end is how a device is presented to the guest. The type
of device presented should match the hardware that the guest operating
system is expecting to see. All devices can be specified with the
``--device`` command line option. Running QEMU with the command line
options ``--device help`` will list all devices it is aware of. Using
the command line ``--device foo,help`` will list the additional
configuration options available for that device.
A front end is often paired with a back end, which describes how the
host's resources are used in the emulation.
Device Buses
============
Most devices will exist on a BUS of some sort. Depending on the
machine model you choose (``-M foo``) a number of buses will have been
automatically created. In most cases the BUS a device is attached to
can be inferred, for example PCI devices are generally automatically
allocated to the next free address of first PCI bus found. However in
complicated configurations you can explicitly specify what bus
(``bus=ID``) a device is attached to along with its address
(``addr=N``).
Some devices, for example a PCI SCSI host controller, will add an
additional buses to the system that other devices can be attached to.
A hypothetical chain of devices might look like:
--device foo,bus=pci.0,addr=0,id=foo
--device bar,bus=foo.0,addr=1,id=baz
which would be a bar device (with the ID of baz) which is attached to
the first foo bus (foo.0) at address 1. The foo device which provides
that bus is itself is attached to the first PCI bus (pci.0).
Device Back End
===============
The back end describes how the data from the emulated device will be
processed by QEMU. The configuration of the back end is usually
specific to the class of device being emulated. For example serial
devices will be backed by a ``--chardev`` which can redirect the data
to a file or socket or some other system. Storage devices are handled
by ``--blockdev`` which will specify how blocks are handled, for
example being stored in a qcow2 file or accessing a raw host disk
partition. Back ends can sometimes be stacked to implement features
like snapshots.
While the choice of back end is generally transparent to the guest,
there are cases where features will not be reported to the guest if
the back end is unable to support it.
Device Pass Through
===================
Device pass through is where the device is actually given access to
the underlying hardware. This can be as simple as exposing a single
USB device on the host system to the guest or dedicating a video card
in a PCI slot to the exclusive use of the guest.
Emulated Devices
~~~~~~~~~~~~~~~~
.. toctree::
:maxdepth: 1
devices/can.rst
devices/ccid.rst
devices/cxl.rst
devices/ivshmem.rst
devices/keyboard.rst
devices/net.rst
devices/nvme.rst
devices/usb.rst
devices/vhost-user.rst
devices/virtio-pmem.rst
devices/vhost-user-rng.rst
devices/canokey.rst
devices/usb-u2f.rst
devices/igb.rst