Age | Commit message (Collapse) | Author | Files | Lines |
|
This is aiming qemu 5.0.
This is equal to 20191206, however that was a partial
backport for regression happened in qemu 4.2 and
that got the 20191209 tag which will take over
20191206 when updated although that would be a downgrade
so we need a bigger tag.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The previous approach to merge the QEMU FDT into the existing tree and
then patch it turned to be broken as we patch properties based on their
names only so we patch not just what QEMU provides (which was
the intention) but also all properties SLOF created. This breaks one of
them - "interrupt-map" - it is created by QEMU for a PHB but SLOF creates
it for PCI bridges and since they have different sizes, patching phandles
at fixed offset fails.
Rather than skipping certain nodes in the SLOF tree, this uses different
approach: now we read the QEMU FDT in 3 passes:
1. find all phandle/linux-phandle properties and store these in the SLOF
internal tree to allow phandle->node lookup later;
2. walk through all FDT properties, patch them if needed using
phandles from the SLOF tree and save patched values in SLOF properties;
3. delete phandle/linux-phandle properties created in 1. This is safe
as SLOF does not create these properties anyway.
Fixes: 44d06f9e68cf ("fdt: Update phandles after H_CAS")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
fdt-fix-cas-node returns the end address after it's finished which
the caller (ibm,client-architecture-support) does not use or drop.
This renames fdt-fix-cas-node to (fdt-fix-cas-node) and adds a wrapper
on top of that which does the drop. This will be used later for 2-pass
tree patching.
While at this, exit the function if memory allocation failed.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
When QEMU is started with iommu_platform=on, the guest driver must accept
it or the device will fail.
This enables IOMMU support for virtio-net, -scsi, -block, -serial, -9p
devices. -serial and -9p are only compile tested though.
For virtio-net we map all RX buffers once and TX when xmit() is called
and unmap older pages when we are about to reuse the VQ descriptor.
As all other devices are synchronous, we unmap IOMMU pages right after
completion of a transaction.
This depends on QEMU's:
https://patchwork.ozlabs.org/patch/1194067/
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Tested-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
Changes:
v5:
* fixed queue size calculation
* reworked virtio_free_desc() to only unmap what is has mapped
v4:
* ditched vqs->id in virtio_queue_init_vq
v2:
* added Mike's fs/dma-instance-function.fs
* total rework
|
|
They call parent node (which is a device) methods.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
Every virtio device negotiates virtio protocol features before setting
up internal queue descriptors with one exception which is virtio-net.
This moves virtio_queue_init_vq() later to have feature negotiation
happened sooner. This is going to be used for IOMMU setup later.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
At the moment desc/avail/used pointers are read from the device every
time we need them. This works for now unless iommu_platform=on is used,
desc/avail/used stored in the config space are bus addresses while
SLOF should keep using the guest physical addresses.
virtio-net stores queue descriptors already, virtio-serial does it in
global statics, move them into virtio_device.
The next patch will use this to allow IOMMU.
While at this, move repeating avail->flags/idx setup into
virtio_queue_init_vq() except virtio-serial which vq_rx->avail->idx is
setup differently.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
Changes:
v4:
* removed vqs::id as it is not really used
* replaced vq_size with vq->size in virtio-serial.c
|
|
The immediate problem with the code is that it relies on memory allocator
aligning addresses to the size. This is true for SLOF but not for GRUB
and in unaligned situations we end up mapping more pages than bm-alloc
allocated.
This fixes the problem by calculating aligned DMA size before calling
bm-alloc.
While at this, simplify the code by removing global variables. Also
replace 1000/fff (the default 4K IOMMU page size) with tce-ps/mask.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
Changes:
v4:
* fixed code comments, tab/spaces
* fixed bm-alloc failure handling
|
|
This fixes these:
sloffs.c:466:2: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
read(fd, data, header_len);
^~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* size_t -> ssize_t
* %ld for size_t -> %zd
* changed error handling in sloffs_header() - now it frees sloffs->name
|
|
For ages both vmlinux and zImage accepted the initramdisk location
in r3/r4 [1] [2]. If r3==r4==0, vmlinux looks at the device tree for
/chosen/linux,initrd-{start|end} but zImage does not so the QEMU user
can only pass vmlinux via -kernel if -initrd is passed as well.
This initializes r3/r4 to point to the initramdisk location when present.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/prom_init.c?h=v5.3#n3230
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/boot/of.c?h=v5.3#n89
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* improved readability
|
|
It is never called outside of virtio, make it static.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
This silences multiple gcc warnings; no functional change otherwise.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
This includes fixes for fullFDT render on CAS and gcc9.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
GCC 9 introduced some new compiler warnings that occur when taking the
address of a packed struct, e.g.:
lib/libnet/icmpv6.c:173:21: warning: taking address of packed member of
‘struct ip6hdr’ may result in an unaligned pointer value [-Waddress-of-packed-member]
173 | rtr = find_router (&(ip6h->src));
| ^~~~~~~~~~~~
Since these warnings are mainly about the ip6_addr_t values that are
embedded in these packed structs, and ip6_addr_t is reasonable small
(just 128 bit), let's fix it by passing around the IPv6 addresses by
value instead of pointer, which looks a little bit nicer anyway.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
gcc9 enforces -Waddress-of-packed-member, fix this.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
During the ibm,client-architecture-support client call, we rely on QEMU
providing a full device tree which SLOF then merged into its internal
tree so we rely on both SLOF and QEMU using the same node names for
devices of the same type.
This changes device tree node names to what QEMU uses.
The change was triggered by "(unknown-)legacy-device" which is used by
virtio-balloon; other changes either fix typos or remove devices which
are very unlikely to be implemented by QEMU for pseries, or even if they
are, we are ok with using generic class names anyway.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
This is another update for QEMU 4.2; the correct USB host node names
are aimed to help with full FDT rebuild on CAS.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
QEMU creates nodes for PCI devices and preserves the node names with
one exception for USB hosts; this fixes it.
Fixes: be9b2fa44c73 ("pci: Use QEMU created PCI device nodes")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
|
|
This is another update for QEMU 4.2.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The current if-condition can never be true.
Buglink: https://bugs.launchpad.net/qemu/+bug/1840646
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
At the moment SLOF generates phandles except a few exceptions such as
an interrupt controller (XICS/XIVE) and NVLink-related nodes. For these
nodes QEMU generates phandles which SLOF later detects and replaces with
the node addresses (which are phandles in SLOF).
However we are missing these updates when processing
the ibm,client-architecture-support client interface call - SLOF calls
QEMU with H_CAS to get an update for the device tree, and if that blob
contains phandles, they make it to the final tree unchanged with
undefined results.
This calls fdt-fix-phandles for the H_CAS update blob.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The Firmware Assisted Non-Maskable Interrupts Option (FWNMI) feature
requires some space for RTAS log which is in the RTAS blob area.
This expands the RTAS blob size to 2k.
More details here: https://patchwork.ozlabs.org/patch/1146765/
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
This is for QEMU 4.2.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
We implement RTAS as a simple binary blob which calls directly into QEMU
via a custom hcall. So far we were relying on QEMU putting the RTAS blob
to the guest memory with its location in linux,rtas-base/rtas-size.
The problems with this are:
1. we need to peek a location in the guest ram in addition to slof, FDT
and sometime kernel and init ram disk; having one less image makes QEMU's
life easier.
2. for secure VMs, it is yet another image which needs to be signed and
verified.
This implements "instantiate-rtas" completely in SLOF, including KVM PR
support ("broken sc1").
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
|
|
This is for QEMU 4.1.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
I recently noticed that if you start QEMU with two NICs, and only
want to boot from the second NIC, SLOF only tries to get an IP
address via DHCPv6 instead of trying both, DHCPv4 and DHCPv6. For
example:
$ qemu-system-ppc64 -nic hubport,hubid=1 \
-nic user,model=virtio,tftp=/.../tftp,bootfile=zImage.pseries
[...]
Trying to load: from: /vdevice/l-lan@71000002 ...
Initializing NIC
Reading MAC address from device: 52:54:00:12:34:56
Requesting information via DHCP: 007
Aborted
E3001 (net) Could not get IP address
Trying to load: from: /pci@800000020000000/ethernet@0 ...
Initializing NIC
Reading MAC address from device: 52:54:00:12:34:57
Requesting information via DHCPv6: done
Using IPv6 address: fec0::5254:ff:fe12:3457
The problem is that we never re-initialize the "ip_version" variable
anymore, so once it has been set to 6, it stays at 6 for the second
network boot attempt, too. Thus reset the variable to 4 at the beginning
of the netload() function.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
This is for QEMU 4.0.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The spapr-vscsi device of QEMU supports multiple channels (a.k.a. buses).
But when QEMU is started with a device on a bus > 0, SLOF fails to detect
the device, so that the boot fails. For example:
qemu-system-ppc64 -nodefaults -nographic -serial stdio -device spapr-vscsi \
-blockdev driver=file,filename=/path/to/cdrom.iso,node-name=d1,read-only=on \
-device scsi-cd,id=cd1,drive=d1,channel=6,scsi-id=5,lun=1
Thus SLOF should scan the various channels for bootable SCSI devices, too.
Since the common SLOF code for scanning SCSI devices has no meaning of
"channels" or "bus", we simply fake the bus ID to be part of the target
ID, so instead of supporting 64 targets = 64 devices, we now support
8 channel * 64 targets = 512 devices instead.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1663160
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
QEMU supports up the 64 SCSI IDs on the vscsi "bus", see the string
"max_target = 63" in the source file hw/scsi/spapr_vscsi.c of QEMU.
However, SLOF currently only checks the first 9 IDs on the vscsi adaptor,
so when you try to boot from a CD-ROM like this, the boot fails:
qemu-system-ppc64 ... -device spapr-vscsi,id=scsi0,reg=0x2000 \
-drive file=/path/to/cdrom.iso,format=raw,if=none,id=dr1,readonly=on \
-device scsi-cd,bus=scsi0.0,channel=0,scsi-id=63,lun=1,drive=dr1,id=scd1
Thus let's change the amount of IDs that we scan in SLOF to 64, too, to
match the ID range that QEMU provides.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The only missing parts were to manage the transfer direction in
do-bulk-command and to copy the data to the buffer before the
write operation.
This is needed as GRUB2 wants to write the grubenv file at start
and hangs because the data are not provided to the disk controller.
I've checked the file is correctly modified by modifying an environment
variable in GRUB2 with "set saved_entry=2" then "save_env saved_entry"
and checking the result in linux with "grub2-editenv list".
Fixes: Fixes: a0b96fe66fcd991b407c1d67ca842921e477a6fd
(Provide "write" function in the disk-label package)
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
to prepare write implementation
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The NVIDIA driver for NVLink2-capable GPU NVIDIA V100 discovers topology
between GPU/NPUs/GPURAM via the device tree which needs to have cross
references between device tree nodes.
This adds patching of the nodes needed for the driver to initialize.
As all these properties only contain phandles and nothing else, there is
no risc of accidendal damage.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
* added the commit log
|
|
We generate a fake XICS phandle in QEMU and SLOF replaces that phandle
with the real one (i.e. SLOF's node address) in interrupt-parent and
interrupt-map properties. These properties are handled differently -
the interrupt-map is fixed in place while interrupt-parent is
decoded+encoded+set as a property.
This changes interrupt-parent fixing code to do what the interrupt-map
code does because soon we are going to have more phandles to fix and some
contain an array of phandles (such as "ibm,npu").
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v2:
* removed fdt-replace-l,
|
|
This will allow SLOF to print the appropriate name instead of "unknown"
for PCI classes 0xd to 0x11.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The DRIVER_NAME environment variable is not set up correctly for the
build_romfs tool in case we build from a git tree, so the field in the
rom header did not contain much useful data. Let's use the revision
string from git as DRIVER_NAME in this case.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
GCC 8 complains about the following usages of strncpy, too:
create_crc.c:86:3: warning: ‘strncpy’ specified bound 16 equals destination
size [-Wstringop-truncation]
strncpy(uHeader.stHeader.version, pcVersion, 16);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
create_crc.c:84:3: warning: ‘strncpy’ specified bound 16 equals destination
size [-Wstringop-truncation]
strncpy(uHeader.stHeader.version, pcVersion, 16);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Let's work around the issue by using memcpy instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
GCC 8.1 introduce some new warnings which affect create_crc.c. One of
them is:
create_crc.c: In function ‘createHeaderImage’:
create_crc.c:110:2: warning: ‘strncpy’ output truncated before terminating nul
copying 8 bytes from a string of the same length [-Wstringop-truncation]
strncpy(uHeader.stHeader.magic, FLASHFS_MAGIC, 8);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Initialize the header struct statically here instead to silence the warning.
Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
Accessing the struct with memset and memcpy can also be done without the
union wrapper. While we're at it, also remove the FLASHFS_HEADER_DATA_SIZE
macre and use sizeof(stHeader) instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
With the new GCC 8, the asynchronous-unwind-tables are always enabled.
We don't need this for SLOF, so disable them to save 32 kiB in the
boot_rom.bin.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
This is aimed to go to QEMU v3.0.
Compared to 20180621, this fixes a couple issues related to gcc8.1.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
When compiling with a very recent toolchain, I get these warnings:
../../llfw/boot_abort.S: Assembler messages:
../../llfw/boot_abort.S:76: Warning: invalid register expression
and:
stage2_head.S: Assembler messages:
stage2_head.S:57: Warning: invalid register expression
The first one is using the wrong opcode, we should use "and" instead of
"andi" here. The second one is using a register instead of a constant
for load-immediate, which is non-sense, too. Fix it to use the right
constant instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
When compiling SLOF with GCC 8.1, I currently get a lot of these errors:
ERROR: Unhandled relocation (A) type 26
Type 26 is the "relative 32-bit" relocation. We can simply ignore it
(like the other relative relocations - REL14, REL24 and REL64) to
shut up these error messages.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
This is aimed to go to QEMU v3.0.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
There are two small bugs in the pxelinux.cfg parser:
1. If the file does not end with a '\n', the code set 'eol = cfg + cfgsize'
and later wrote a NUL character to *eol, i.e. it wrote the NUL character
beyond the end of the buffer. We've got to use 'eol = cfg + cfgsize - 1'
instead.
2. The code always replaced the last byte of the buffer with a NUL character
to get a proper termination. If the config file ends with a required character
(e.g. the last line is a KERNEL or INITRD line and the file does not have
a '\n' at the end), the last character got lost. Move the obligation for the
terminating NUL character to the caller instead so that we can be sure to
have a proper terminated buffer in pxelinux_parse_cfg() without the need to
blindly overwrite the last character here.
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
The pxelinux_load_cfg() function always tried to load one byte less than
its parameter said (so that we've got space for a terminating NUL-character
later). This is not very intuitive, let's better ask for one byte less
when we call the function. While we're at it, add a sanity check that
the function really did not load more bytes than requested.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
... useful for "this should never happen" situations, where
you want to make sure that it really never happens.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
[aik: removed extra ';' and empty line]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
Retrieve the UUID from the device tree and pass it to the pxelinux.cfg
function, so that we can look there for UUID-based file names, too.
Signed-off-by: Thomas Huth <thuth@redhat.com>
[aik: removed trailing space]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
We will need to retrieve the UUID of the VM in the libnet code, so we
need a function to get the contents from a device tree property.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|
|
There are two dedicated DHCP options for loading PXELINUX config files,
option 209 (config file name) and 210 (path prefix). We should support
them, too, in case some users want to configure their boot flow this way.
See RFC 5071 and the following URL for more details:
https://www.syslinux.org/wiki/index.php?title=PXELINUX#DHCP_options
Unlike most other strings in libnet, I've chosen to not use fixed-size
arrays for these two strings, but to allocate the memory via malloc here.
We always have to make sure not to overflow the stack in Paflof, so
adding 2 * 256 byte arrays to struct filename_ip sounded just too
dangerous to me.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
|