izzy/xemu
0
0
Fork 0
mirror of https://github.com/izzy2lost/xemu.git synced 2026-07-06 00:20:22 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20200227' into staging

Browse Source 
Includes a headers update against 5.6-current.
- add missing vcpu reset functionality
- rstfy some s390 documentation
- fixes and enhancements

# gpg: Signature made Thu 27 Feb 2020 11:50:08 GMT
# gpg:                using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg:                issuer "cohuck@redhat.com"
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [marginal]
# gpg:                 aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cohuck@kernel.org>" [marginal]
# gpg:                 aka "Cornelia Huck <cohuck@redhat.com>" [marginal]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20200227:
  s390x: Rename and use constants for short PSW address and mask
  docs: rstfy vfio-ap documentation
  docs: rstfy s390 dasd ipl documentation
  s390/sclp: improve special wait psw logic
  s390x: Add missing vcpu reset functions
  linux-headers: update
  target/s390x/translate: Fix RNSBG instruction

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell
2020-02-27 19:56:37 +00:00
parent 8b6b68e05b b6c2dbd721
commit 430f63e250
33 changed files with 620 additions and 446 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MAINTAINERS
+2 -2
View File
@@ -1259,7 +1259,7 @@ S: Supported
F: hw/s390x/ipl.*
F: pc-bios/s390-ccw/
F: pc-bios/s390-ccw.img
F: docs/devel/s390-dasd-ipl.txt
F: docs/devel/s390-dasd-ipl.rst
T: git https://github.com/borntraeger/qemu.git s390-next
L: qemu-s390x@nongnu.org
@@ -1570,7 +1570,7 @@ F: hw/s390x/ap-bridge.c
F: include/hw/s390x/ap-device.h
F: include/hw/s390x/ap-bridge.h
F: hw/vfio/ap.c
F: docs/vfio-ap.txt
F: docs/system/vfio-ap.rst
L: qemu-s390x@nongnu.org
vhost
docs/devel/index.rst
+1
View File
@@ -25,3 +25,4 @@ Contents:
tcg-plugins
bitops
reset
s390-dasd-ipl
docs/devel/s390-dasd-ipl.txt → docs/devel/s390-dasd-ipl.rst
+61 -56
View File
@@ -1,49 +1,55 @@
*****************************
***** s390 hardware IPL *****
*****************************
Booting from real channel-attached devices on s390x
===================================================
s390 hardware IPL
-----------------
The s390 hardware IPL process consists of the following steps.
1. A READ IPL ccw is constructed in memory location 0x0.
This ccw, by definition, reads the IPL1 record which is located on the disk
at cylinder 0 track 0 record 1. Note that the chain flag is on in this ccw
so when it is complete another ccw will be fetched and executed from memory
location 0x08.
1. A READ IPL ccw is constructed in memory location ``0x0``.
This ccw, by definition, reads the IPL1 record which is located on the disk
at cylinder 0 track 0 record 1. Note that the chain flag is on in this ccw
so when it is complete another ccw will be fetched and executed from memory
location ``0x08``.
2. Execute the Read IPL ccw at 0x00, thereby reading IPL1 data into 0x00.
IPL1 data is 24 bytes in length and consists of the following pieces of
information: [psw][read ccw][tic ccw]. When the machine executes the Read
IPL ccw it read the 24-bytes of IPL1 to be read into memory starting at
location 0x0. Then the ccw program at 0x08 which consists of a read
ccw and a tic ccw is automatically executed because of the chain flag from
the original READ IPL ccw. The read ccw will read the IPL2 data into memory
and the TIC (Transfer In Channel) will transfer control to the channel
program contained in the IPL2 data. The TIC channel command is the
equivalent of a branch/jump/goto instruction for channel programs.
NOTE: The ccws in IPL1 are defined by the architecture to be format 0.
2. Execute the Read IPL ccw at ``0x00``, thereby reading IPL1 data into ``0x00``.
IPL1 data is 24 bytes in length and consists of the following pieces of
information: ``[psw][read ccw][tic ccw]``. When the machine executes the Read
IPL ccw it read the 24-bytes of IPL1 to be read into memory starting at
location ``0x0``. Then the ccw program at ``0x08`` which consists of a read
ccw and a tic ccw is automatically executed because of the chain flag from
the original READ IPL ccw. The read ccw will read the IPL2 data into memory
and the TIC (Transfer In Channel) will transfer control to the channel
program contained in the IPL2 data. The TIC channel command is the
equivalent of a branch/jump/goto instruction for channel programs.
NOTE: The ccws in IPL1 are defined by the architecture to be format 0.
3. Execute IPL2.
The TIC ccw instruction at the end of the IPL1 channel program will begin
the execution of the IPL2 channel program. IPL2 is stage-2 of the boot
process and will contain a larger channel program than IPL1. The point of
IPL2 is to find and load either the operating system or a small program that
loads the operating system from disk. At the end of this step all or some of
the real operating system is loaded into memory and we are ready to hand
control over to the guest operating system. At this point the guest
operating system is entirely responsible for loading any more data it might
need to function. NOTE: The IPL2 channel program might read data into memory
location 0 thereby overwriting the IPL1 psw and channel program. This is ok
as long as the data placed in location 0 contains a psw whose instruction
address points to the guest operating system code to execute at the end of
the IPL/boot process.
NOTE: The ccws in IPL2 are defined by the architecture to be format 0.
The TIC ccw instruction at the end of the IPL1 channel program will begin
the execution of the IPL2 channel program. IPL2 is stage-2 of the boot
process and will contain a larger channel program than IPL1. The point of
IPL2 is to find and load either the operating system or a small program that
loads the operating system from disk. At the end of this step all or some of
the real operating system is loaded into memory and we are ready to hand
control over to the guest operating system. At this point the guest
operating system is entirely responsible for loading any more data it might
need to function.
NOTE: The IPL2 channel program might read data into memory
location ``0x0`` thereby overwriting the IPL1 psw and channel program. This is ok
as long as the data placed in location ``0x0`` contains a psw whose instruction
address points to the guest operating system code to execute at the end of
the IPL/boot process.
NOTE: The ccws in IPL2 are defined by the architecture to be format 0.
4. Start executing the guest operating system.
The psw that was loaded into memory location 0 as part of the ipl process
should contain the needed flags for the operating system we have loaded. The
psw's instruction address will point to the location in memory where we want
to start executing the operating system. This psw is loaded (via LPSW
instruction) causing control to be passed to the operating system code.
The psw that was loaded into memory location ``0x0`` as part of the ipl process
should contain the needed flags for the operating system we have loaded. The
psw's instruction address will point to the location in memory where we want
to start executing the operating system. This psw is loaded (via LPSW
instruction) causing control to be passed to the operating system code.
In a non-virtualized environment this process, handled entirely by the hardware,
is kicked off by the user initiating a "Load" procedure from the hardware
@@ -54,18 +60,17 @@ written immediately after the special "Read IPL" ccw, the IPL1 channel program
will be executed immediately (the special read ccw has the chaining bit turned
on). The TIC at the end of the IPL1 channel program will cause the IPL2 channel
program to be executed automatically. After this sequence completes the "Load"
procedure then loads the psw from 0x0.
procedure then loads the psw from ``0x0``.
**********************************************************
***** How this all pertains to QEMU (and the kernel) *****
**********************************************************
How this all pertains to QEMU (and the kernel)
----------------------------------------------
In theory we should merely have to do the following to IPL/boot a guest
operating system from a DASD device:
1. Place a "Read IPL" ccw into memory location 0x0 with chaining bit on.
2. Execute channel program at 0x0.
3. LPSW 0x0.
1. Place a "Read IPL" ccw into memory location ``0x0`` with chaining bit on.
2. Execute channel program at ``0x0``.
3. LPSW ``0x0``.
However, our emulation of the machine's channel program logic within the kernel
is missing one key feature that is required for this process to work:
@@ -89,32 +94,31 @@ Lastly, in some cases (the zipl bootloader for example) the IPL2 program also
transfers control to another channel program segment immediately after reading
it from the disk. So we need to be able to handle this case.
**************************
***** What QEMU does *****
**************************
What QEMU does
--------------
Since we are forced to live with prefetch we cannot use the very simple IPL
procedure we defined in the preceding section. So we compensate by doing the
following.
1. Place "Read IPL" ccw into memory location 0x0, but turn off chaining bit.
2. Execute "Read IPL" at 0x0.
1. Place "Read IPL" ccw into memory location ``0x0``, but turn off chaining bit.
2. Execute "Read IPL" at ``0x0``.
So now IPL1's psw is at 0x0 and IPL1's channel program is at 0x08.
So now IPL1's psw is at ``0x0`` and IPL1's channel program is at ``0x08``.
4. Write a custom channel program that will seek to the IPL2 record and then
3. Write a custom channel program that will seek to the IPL2 record and then
execute the READ and TIC ccws from IPL1. Normally the seek is not required
because after reading the IPL1 record the disk is automatically positioned
to read the very next record which will be IPL2. But since we are not reading
both IPL1 and IPL2 as part of the same channel program we must manually set
the position.
5. Grab the target address of the TIC instruction from the IPL1 channel program.
4. Grab the target address of the TIC instruction from the IPL1 channel program.
This address is where the IPL2 channel program starts.
Now IPL2 is loaded into memory somewhere, and we know the address.
6. Execute the IPL2 channel program at the address obtained in step #5.
5. Execute the IPL2 channel program at the address obtained in step #4.
Because this channel program can be dynamic, we must use a special algorithm
that detects a READ immediately followed by a TIC and breaks the ccw chain
@@ -126,8 +130,9 @@ following.
channel program from executing properly.
Now the operating system code is loaded somewhere in guest memory and the psw
in memory location 0x0 will point to entry code for the guest operating
in memory location ``0x0`` will point to entry code for the guest operating
system.
7. LPSW 0x0.
6. LPSW ``0x0``
LPSW transfers control to the guest operating system and we're done.
docs/system/index.rst
+1
View File
@@ -15,3 +15,4 @@ Contents:
:maxdepth: 2
qemu-block-drivers
vfio-ap
docs/vfio-ap.txt → docs/system/vfio-ap.rst
+407 -367
View File
File diff suppressed because it is too large Load Diff
hw/s390x/ipl.c
+1 -1
View File
@@ -179,7 +179,7 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
/* if not Linux load the address of the (short) IPL PSW */
ipl_psw = rom_ptr(4, 4);
if (ipl_psw) {
pentry = be32_to_cpu(*ipl_psw) & 0x7fffffffUL;
pentry = be32_to_cpu(*ipl_psw) & PSW_MASK_SHORT_ADDR;
} else {
error_setg(&err, "Could not get IPL PSW");
goto error;
include/standard-headers/drm/drm_fourcc.h
+24
View File
@@ -409,6 +409,30 @@ extern "C" {
#define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
/*
* Intel color control surfaces (CCS) for Gen-12 render compression.
*
* The main surface is Y-tiled and at plane index 0, the CCS is linear and
* at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
* main surface. In other words, 4 bits in CCS map to a main surface cache
* line pair. The main surface pitch is required to be a multiple of four
* Y-tile widths.
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
/*
* Intel color control surfaces (CCS) for Gen-12 media compression
*
* The main surface is Y-tiled and at plane index 0, the CCS is linear and
* at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
* main surface. In other words, 4 bits in CCS map to a main surface cache
* line pair. The main surface pitch is required to be a multiple of four
* Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
* Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
* planes 2 and 3 for the respective CCS.
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
include/standard-headers/linux/ethtool.h
+11
View File
@@ -593,6 +593,9 @@ struct ethtool_pauseparam {
* @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
* @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
* @ETH_SS_PHY_TUNABLES: PHY tunable names
* @ETH_SS_LINK_MODES: link mode names
* @ETH_SS_MSG_CLASSES: debug message class names
* @ETH_SS_WOL_MODES: wake-on-lan modes
*/
enum ethtool_stringset {
ETH_SS_TEST = 0,
@@ -604,6 +607,12 @@ enum ethtool_stringset {
ETH_SS_TUNABLES,
ETH_SS_PHY_STATS,
ETH_SS_PHY_TUNABLES,
ETH_SS_LINK_MODES,
ETH_SS_MSG_CLASSES,
ETH_SS_WOL_MODES,
/* add new constants above here */
ETH_SS_COUNT
};
/**
@@ -1688,6 +1697,8 @@ static inline int ethtool_validate_duplex(uint8_t duplex)
#define WAKE_MAGICSECURE (1 << 6) /* only meaningful if WAKE_MAGIC */
#define WAKE_FILTER (1 << 7)
#define WOL_MODE_COUNT 8
/* L2-L4 network traffic flow types */
#define TCP_V4_FLOW 0x01 /* hash or spec (tcp_ip4_spec) */
#define UDP_V4_FLOW 0x02 /* hash or spec (udp_ip4_spec) */
include/standard-headers/linux/input.h
+1
View File
@@ -31,6 +31,7 @@ struct input_event {
unsigned long __sec;
#if defined(__sparc__) && defined(__arch64__)
unsigned int __usec;
unsigned int __pad;
#else
unsigned long __usec;
#endif
include/standard-headers/linux/pci_regs.h
+1
View File
@@ -676,6 +676,7 @@
#define PCI_EXP_LNKCTL2_TLS_32_0GT 0x0005 /* Supported Speed 32GT/s */
#define PCI_EXP_LNKCTL2_ENTER_COMP 0x0010 /* Enter Compliance */
#define PCI_EXP_LNKCTL2_TX_MARGIN 0x0380 /* Transmit Margin */
#define PCI_EXP_LNKCTL2_HASD 0x0020 /* HW Autonomous Speed Disable */
#define PCI_EXP_LNKSTA2 50 /* Link Status 2 */
#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 52 /* v2 endpoints with link end here */
#define PCI_EXP_SLTCAP2 52 /* Slot Capabilities 2 */
linux-headers/asm-arm/unistd-common.h
+2
View File
@@ -390,5 +390,7 @@
#define __NR_fspick (__NR_SYSCALL_BASE + 433)
#define __NR_pidfd_open (__NR_SYSCALL_BASE + 434)
#define __NR_clone3 (__NR_SYSCALL_BASE + 435)
#define __NR_openat2 (__NR_SYSCALL_BASE + 437)
#define __NR_pidfd_getfd (__NR_SYSCALL_BASE + 438)
#endif /* _ASM_ARM_UNISTD_COMMON_H */
linux-headers/asm-arm64/kvm.h
+10 -2
View File
@@ -220,10 +220,18 @@ struct kvm_vcpu_events {
#define KVM_REG_ARM_PTIMER_CVAL ARM64_SYS_REG(3, 3, 14, 2, 2)
#define KVM_REG_ARM_PTIMER_CNT ARM64_SYS_REG(3, 3, 14, 0, 1)
/* EL0 Virtual Timer Registers */
/*
* EL0 Virtual Timer Registers
*
* WARNING:
* KVM_REG_ARM_TIMER_CVAL and KVM_REG_ARM_TIMER_CNT are not defined
* with the appropriate register encodings. Their values have been
* accidentally swapped. As this is set API, the definitions here
* must be used, rather than ones derived from the encodings.
*/
#define KVM_REG_ARM_TIMER_CTL ARM64_SYS_REG(3, 3, 14, 3, 1)
#define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2)
#define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2)
#define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2)
/* KVM-as-firmware specific pseudo-registers */
#define KVM_REG_ARM_FW (0x0014 << KVM_REG_ARM_COPROC_SHIFT)
linux-headers/asm-arm64/unistd.h
+1
View File
@@ -19,5 +19,6 @@
#define __ARCH_WANT_NEW_STAT
#define __ARCH_WANT_SET_GET_RLIMIT
#define __ARCH_WANT_TIME32_SYSCALLS
#define __ARCH_WANT_SYS_CLONE3
#include <asm-generic/unistd.h>
linux-headers/asm-generic/mman-common.h
+2
View File
@@ -11,6 +11,8 @@
#define PROT_WRITE 0x2 /* page can be written */
#define PROT_EXEC 0x4 /* page can be executed */
#define PROT_SEM 0x8 /* page may be used for atomic ops */
/* 0x10 reserved for arch-specific use */
/* 0x20 reserved for arch-specific use */
#define PROT_NONE 0x0 /* page can not be accessed */
#define PROT_GROWSDOWN 0x01000000 /* mprotect flag: extend change to start of growsdown vma */
#define PROT_GROWSUP 0x02000000 /* mprotect flag: extend change to end of growsup vma */
linux-headers/asm-generic/unistd.h
+6 -1
View File
@@ -851,8 +851,13 @@ __SYSCALL(__NR_pidfd_open, sys_pidfd_open)
__SYSCALL(__NR_clone3, sys_clone3)
#endif
#define __NR_openat2 437
__SYSCALL(__NR_openat2, sys_openat2)
#define __NR_pidfd_getfd 438
__SYSCALL(__NR_pidfd_getfd, sys_pidfd_getfd)
#undef __NR_syscalls
#define __NR_syscalls 436
#define __NR_syscalls 439
/*
* 32 bit systems traditionally used different
linux-headers/asm-mips/unistd_n32.h
+2
View File
@@ -365,6 +365,8 @@
#define __NR_fspick (__NR_Linux + 433)
#define __NR_pidfd_open (__NR_Linux + 434)
#define __NR_clone3 (__NR_Linux + 435)
#define __NR_openat2 (__NR_Linux + 437)
#define __NR_pidfd_getfd (__NR_Linux + 438)
#endif /* _ASM_MIPS_UNISTD_N32_H */
linux-headers/asm-mips/unistd_n64.h
+2
View File
@@ -341,6 +341,8 @@
#define __NR_fspick (__NR_Linux + 433)
#define __NR_pidfd_open (__NR_Linux + 434)
#define __NR_clone3 (__NR_Linux + 435)
#define __NR_openat2 (__NR_Linux + 437)
#define __NR_pidfd_getfd (__NR_Linux + 438)
#endif /* _ASM_MIPS_UNISTD_N64_H */
linux-headers/asm-mips/unistd_o32.h
+2
View File
@@ -411,6 +411,8 @@
#define __NR_fspick (__NR_Linux + 433)
#define __NR_pidfd_open (__NR_Linux + 434)
#define __NR_clone3 (__NR_Linux + 435)
#define __NR_openat2 (__NR_Linux + 437)
#define __NR_pidfd_getfd (__NR_Linux + 438)
#endif /* _ASM_MIPS_UNISTD_O32_H */
linux-headers/asm-powerpc/unistd_32.h
+2
View File
@@ -418,6 +418,8 @@
#define __NR_fspick 433
#define __NR_pidfd_open 434
#define __NR_clone3 435
#define __NR_openat2 437
#define __NR_pidfd_getfd 438
#endif /* _ASM_POWERPC_UNISTD_32_H */
linux-headers/asm-powerpc/unistd_64.h
+2
View File
@@ -390,6 +390,8 @@
#define __NR_fspick 433
#define __NR_pidfd_open 434
#define __NR_clone3 435
#define __NR_openat2 437
#define __NR_pidfd_getfd 438
#endif /* _ASM_POWERPC_UNISTD_64_H */

Some files were not shown because too many files have changed in this diff Show More