nbd/client: fix error messages in nbd_handle_reply_err
1. NBD_REP_ERR_INVALID is not only about length, so, make message more
general
2. hex format is not very good: it's hard to read something like
"option a (set meta context)", so switch to dec.
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Message-Id: <1518702707[email protected]>
[eblake: expand scope of patch: ALL uses of nbd_opt_lookup and
nbd_rep_lookup are now decimal] Signed-off-by: Eric Blake <[email protected]>
Expose the new constants and structs that will be used by both
server and client implementations of NBD_CMD_BLOCK_STATUS (the
command is currently experimental at
https://github.com/NetworkBlockDevice/nbd/blob/extension-blockstatus/doc/proto.md
but will hopefully be stabilized soon).
Eric Blake [Thu, 15 Feb 2018 03:29:05 +0000 (21:29 -0600)]
nbd: Honor server's advertised minimum block size
Commit 79ba8c98 (v2.7) changed the setting of request_alignment
to occur only during bdrv_refresh_limits(), rather than at at
bdrv_open() time; but at the time, NBD was unaffected, because
it still used sector-based callbacks, so the block layer
defaulted NBD to use 512 request_alignment.
Later, commit 70c4fb26 (also v2.7) changed NBD to use byte-based
callbacks, without setting request_alignment. This resulted in
NBD using request_alignment of 1, which works great when the
server supports it (as is the case for qemu-nbd), but falls apart
miserably if the server requires alignment (but only if qemu
actually sends a sub-sector request; qemu-io can do it, but
most qemu operations still perform on sectors or larger).
Even later, the NBD protocol was updated to document that clients
should learn the server's minimum alignment during NBD_OPT_GO;
and recommended that clients should assume a minimum size of 512
unless the server understands NBD_OPT_GO and replied with a smaller
size. Commit 081dd1fe (v2.10) attempted to do that, by assigning
request_alignment to whatever was learned from the server; but
it has two flaws: the assignment is done during bdrv_open() so
it gets unconditionally wiped out back to 1 during any later
bdrv_refresh_limits(); and the code is not using a default of 512
when the server did not report a minimum size.
Fix these issues by moving the assignment to request_alignment
to the right function, and by using a sane default when the
server does not advertise a minimum size.
Peter Maydell [Thu, 1 Mar 2018 17:08:16 +0000 (17:08 +0000)]
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20180301-v2' into staging
- add query-cpus-fast and deprecate query-cpus, while adding s390 cpu
information
- remove s390x memory hotplug implementation, which is not useable in
this form
- add boot menu support in the s390-ccw bios
- expose s390x guest crash information
- fixes and cleaups
* remotes/cohuck/tags/s390x-20180301-v2: (27 commits)
s390x/tcg: fix loading 31bit PSWs with the highest bit set
s390x: remove s390_get_memslot_count
s390x/sclp: remove memory hotplug support
s390x/cpumodel: document S390FeatDef.bit not applicable
hmp: change hmp_info_cpus to use query-cpus-fast
qemu-doc: deprecate query-cpus
qmp: add architecture specific cpu data for query-cpus-fast
qmp: add query-cpus-fast
qmp: expose s390-specific CPU info
s390x/tcg: add various alignment checks
s390x/tcg: fix disabling/enabling DAT
s390/stattrib: Make SaveVMHandlers data static
s390x/cpu: expose the guest crash information
pc-bios/s390: Rebuild the s390x firmware images with the boot menu changes
s390-ccw: interactive boot menu for scsi
s390-ccw: use zipl values when no boot menu options are present
s390-ccw: set cp_receive mask only when needed and consume pending service irqs
s390-ccw: read user input for boot index via the SCLP console
s390-ccw: print zipl boot menu
s390-ccw: read stage2 boot loader data to find menu
...
Peter Maydell [Thu, 1 Mar 2018 15:37:31 +0000 (15:37 +0000)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180301' into staging
target-arm queue:
* update MAINTAINERS for Alistair's new email address
* add Arm v8.2 FP16 arithmetic extension for linux-user
* implement display connector emulation for vexpress board
* xilinx_spips: Enable only two slaves when reading/writing with stripe
* xilinx_spips: Use 8 dummy cycles with the QIOR/QIOR4 commands
* hw: register: Run post_write hook on reset
* remotes/pmaydell/tags/pull-target-arm-20180301: (42 commits)
MAINTAINERS: Update my email address
linux-user: Report AArch64 FP16 support via hwcap bits
target/arm: Enable ARM_V8_FP16 feature bit for the AArch64 "any" CPU
arm/translate-a64: add all single op FP16 to handle_fp_1src_half
arm/translate-a64: implement simd_scalar_three_reg_same_fp16
arm/translate-a64: add all FP16 ops in simd_scalar_pairwise
arm/translate-a64: add FP16 FMOV to simd_mod_imm
arm/translate-a64: add FP16 FRSQRTE to simd_two_reg_misc_fp16
arm/helper.c: re-factor rsqrte and add rsqrte_f16
arm/translate-a64: add FP16 FSQRT to simd_two_reg_misc_fp16
arm/translate-a64: add FP16 FRCPX to simd_two_reg_misc_fp16
arm/translate-a64: add FP16 FRECPE
arm/helper.c: re-factor recpe and add recepe_f16
arm/translate-a64: add FP16 FNEG/FABS to simd_two_reg_misc_fp16
arm/translate-a64: add FP16 SCVTF/UCVFT to simd_two_reg_misc_fp16
arm/translate-a64: add FP16 FCMxx (zero) to simd_two_reg_misc_fp16
arm/translate-a64: add FCVTxx to simd_two_reg_misc_fp16
arm/translate-a64: add FP16 FPRINTx to simd_two_reg_misc_fp16
arm/translate-a64: initial decode for simd_two_reg_misc_fp16
arm/translate-a64: add FP16 x2 ops for simd_indexed
...
s390x/tcg: fix loading 31bit PSWs with the highest bit set
Let's also put the 31-bit hack in front of the REAL MMU, otherwise right
now we get errors when loading a PSW where the highest bit is set (e.g.
via s390-netboot.img). The highest bit is not masked away, therefore we
inject addressing exceptions into the guest.
The proper fix will later be to do all address wrapping before accessing
the MMU - so we won't get any "wrong" entries in there (which makes
flushing also easier). But that will require more work (wrapping in
load_psw, wrapping when incrementing the PC, wrapping every memory
access).
Alex Bennée [Thu, 1 Mar 2018 11:05:55 +0000 (11:05 +0000)]
arm/helper.c: re-factor rsqrte and add rsqrte_f16
Much like recpe the ARM ARM has simplified the pseudo code for the
calculation which is done on a fixed point 9 bit integer maths. So
while adding f16 we can also clean this up to be a little less heavy
on the floating point and just return the fractional part and leave
the calle's to do the final packing of the result.
Alex Bennée [Thu, 1 Mar 2018 11:05:54 +0000 (11:05 +0000)]
arm/helper.c: re-factor recpe and add recepe_f16
It looks like the ARM ARM has simplified the pseudo code for the
calculation which is done on a fixed point 9 bit integer maths. So
while adding f16 we can also clean this up to be a little less heavy
on the floating point and just return the fractional part and leave
the calle's to do the final packing of the result.
Alex Bennée [Thu, 1 Mar 2018 11:05:54 +0000 (11:05 +0000)]
arm/translate-a64: add FP16 FNEG/FABS to simd_two_reg_misc_fp16
Neither of these operations alter the floating point status registers
so we can do a pure bitwise operation, either squashing any sign
bit (ABS) or inverting it (NEG).
Alex Bennée [Thu, 1 Mar 2018 11:05:54 +0000 (11:05 +0000)]
arm/translate-a64: add FP16 SCVTF/UCVFT to simd_two_reg_misc_fp16
I've re-factored the handle_simd_intfp_conv helper to properly handle
half-precision as well as call plain conversion helpers when we are
not doing fixed point conversion.
The difference between the two is covered by a combination of Q (bit
30) and S (bit 28). Notably the FRINTx instructions are only
available in the vector form.
This is just the decode skeleton which will be filled out by later
patches.
Alex Bennée [Thu, 1 Mar 2018 11:05:52 +0000 (11:05 +0000)]
arm/translate-a64: add FP16 x2 ops for simd_indexed
A bunch of the vectorised bitwise operations just operate on larger
chunks at a time. We can do the same for the new half-precision
operations by introducing some TWOHALFOP helpers which work on each
half of a pair of half-precision operations at once.
Hopefully all this hoop jumping will get simpler once we have
generically vectorised helpers here.
This implements the half-precision variants of the across vector
reduction operations. This involves a re-factor of the reduction code
which more closely matches the ARM ARM order (and handles 8 element
reductions).
Alex Bennée [Thu, 1 Mar 2018 11:05:47 +0000 (11:05 +0000)]
target/arm/helper: pass explicit fpst to set_rmode
As the rounding mode is now split between FP16 and the rest of
floating point we need to be explicit when tweaking it. Instead of
passing the CPU env we now pass the appropriate fpst pointer directly.
Half-precision flush to zero behaviour is controlled by a separate
FZ16 bit in the FPCR. To handle this we pass a pointer to
fp_status_fp16 when working on half-precision operations. The value of
the presented FPCR is calculated from an amalgam of the two when read.
Alex Bennée [Thu, 1 Mar 2018 11:05:46 +0000 (11:05 +0000)]
include/exec/helper-head.h: support f16 in helper calls
This allows us to explicitly pass float16 to helpers rather than
assuming uint32_t and dealing with the result. Of course they will be
passed in i32 sized registers by default.
This adds the SiI9022 (and implicitly EDID I2C) device to the ARM
Versatile Express machine, and selects the two I2C devices necessary
in the arm-softmmu.mak configuration so everything will build
smoothly.
I am implementing proper handling of the graphics in the Linux
kernel and adding proper emulation of SiI9022 and EDID makes the
driver probe as nicely as before, retrieving the resolutions
supported by the "QEMU monitor" and overall just working nice.
Linus Walleij [Thu, 1 Mar 2018 11:05:45 +0000 (11:05 +0000)]
hw/sii9022: Add support for Silicon Image SII9022
This adds support for emulating the Silicon Image SII9022 DVI/HDMI
bridge. It's not very clever right now, it just acknowledges
the switch into DDC I2C mode and back. Combining this with the
existing DDC I2C emulation gives the right behavior on the Versatile
Express emulation passing through the QEMU EDID to the emulated
platform.
Linus Walleij [Thu, 1 Mar 2018 11:05:45 +0000 (11:05 +0000)]
hw/i2c-ddc: Do not fail writes
The tx function of the DDC I2C slave emulation was returning 1
on all writes resulting in NACK in the I2C bus. Changing it to
0 makes the DDC I2C work fine with bit-banged I2C such as the
versatile I2C.
I guess it was not affecting whatever I2C controller this was
used with until now, but with the Versatile I2C it surely
does not work.
xilinx_spips: Use 8 dummy cycles with the QIOR/QIOR4 commands
Use 8 dummy cycles (4 dummy bytes) with the QIOR/QIOR4 commands in legacy mode
for matching what is expected by Micron (Numonyx) flashes (the default target
flash type of the QSPI).
Ensure that the post write hook is called during reset. This allows us
to rely on the post write functions instead of having to call them from
the reset() function.
Peter Maydell [Thu, 1 Mar 2018 10:13:21 +0000 (10:13 +0000)]
Merge remote-tracking branch 'remotes/stefanberger/tags/pull-tpm-2018-02-21-2' into staging
Merge tpm 2018/02/21 v2
# gpg: Signature made Tue 27 Feb 2018 13:50:28 GMT
# gpg: using RSA key 75AD65802A0B4211
# gpg: Good signature from "Stefan Berger <[email protected]>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: B818 B9CA DF90 89C2 D5CE C66B 75AD 6580 2A0B 4211
* remotes/stefanberger/tags/pull-tpm-2018-02-21-2:
tests: add test for TPM TIS device
tests: Move common TPM test code into tpm-emu.c
Mark Cave-Ayland [Fri, 23 Feb 2018 11:10:17 +0000 (11:10 +0000)]
loader: don't perform overlapping address check for memory region ROM images
All memory region ROM images have a base address of 0 which causes the overlapping
address check to fail if more than one memory region ROM image is present, or an
existing ROM image is loaded at address 0.
Make sure that we ignore the overlapping address check in
rom_check_and_register_reset() if this is a memory region ROM image. In particular
this fixes the "rom: requested regions overlap" error on startup when trying to
run qemu-system-sparc with a -kernel image since commit 7497638642: "tcx: switch to
load_image_mr() and remove prom_addr hack".
* remotes/kraxel/tags/usb-20180227-pull-request:
usb-mtp: Advertise SendObjectInfo for write support
usb-mtp: Introduce write support for MTP objects
usb-mtp: Support delete of mtp objects
usb-mtp: print parent path in IN_IGNORED trace fn
usb-mtp: Add one more argument when building results
* tag 'tags/s390-ccw-bios-2018-02-26':
pc-bios/s390: Rebuild the s390x firmware images with the boot menu changes
s390-ccw: interactive boot menu for scsi
s390-ccw: use zipl values when no boot menu options are present
s390-ccw: set cp_receive mask only when needed and consume pending service irqs
s390-ccw: read user input for boot index via the SCLP console
s390-ccw: print zipl boot menu
s390-ccw: read stage2 boot loader data to find menu
s390-ccw: set up interactive boot menu parameters
s390-ccw: parse and set boot menu options
s390-ccw: move auxiliary IPL data to separate location
s390-ccw: update libc
s390-ccw: refactor IPL structs
s390-ccw: refactor eckd_block_num to use CHS
s390-ccw: refactor boot map table code
Peter Maydell [Tue, 27 Feb 2018 10:14:31 +0000 (10:14 +0000)]
Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-2.12-pull-request' into staging
# gpg: Signature made Sun 25 Feb 2018 17:54:21 GMT
# gpg: using RSA key F30C38BD3F2FBE3C
# gpg: Good signature from "Laurent Vivier <[email protected]>"
# gpg: aka "Laurent Vivier <[email protected]>"
# gpg: aka "Laurent Vivier (Red Hat) <[email protected]>"
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C
* remotes/vivier2/tags/linux-user-for-2.12-pull-request:
linux-user: MIPS set cpu to r6 CPU if binary is R6
linux-user, m68k: select CPU according to ELF header values
linux-user: introduce functions to detect CPU type
linux-user: Move CPU type name selection to a function
Dave Airlie [Fri, 23 Feb 2018 02:38:14 +0000 (12:38 +1000)]
virtio-gpu-3d: add support for second capability set (v4)
Due to a kernel bug we can never increase the size of capability
set 1, so introduce a new capability set in parallel, old userspace
will continue to use the old set, new userspace will start using
the new one when it detects a fixed kernel.
v2: don't use a define from virglrenderer, just probe it.
v3: fix compilation when virglrenderer disabled
v4: fix style warning, just use ?: op instead.
From an architecture point of view, nothing can be mapped into the address
space on s390x. All there is is memory. Therefore there is also not really
an interface to communicate such information to the guest. All we can do is
specify the maximum ram address and guests can probe in that range if
memory is available and usable (TPROT).
Also memory hotplug is strange. The guest can decide at some point in
time to add / remove memory in some range. While the hypervisor can deny
to online an increment, all increments have to be predefined and there is
no way of telling the guest about a newly "hotplugged" increment. So if we
specify right now e.g.
-m 2G,slots=2,maxmem=20G
An ordinary fedora guest will happily online (hotplug) all memory,
resulting in a guest consuming 20G. So it really behaves rather like
-m 22G
There is no way to hotplug memory from the outside like on other
architectures. This is of course bad for upper management layers.
As the guest can create/delete memory regions while it is running, of
course migration support is not available and tricky to implement.
With virtualization, it is different. We might want to map something
into guest address space (e.g. fake DAX devices) and not detect it
automatically as memory. So we really want to use the maxmem and slots
parameter just like on all other architectures. Such devices will have
to expose the applicable memory range themselves. To finally be able to
provide memory hotplug to guests, we will need a new paravirtualized
interface to do that (e.g. something into the direction of virtio-mem).
This implies, that maxmem cannot be used for s390x memory hotplug
anymore and has to go. This simplifies the code quite a bit.
As migration support is not working, this change cannot really break
migration as guests without slots and maxmem don't see the SCLP
features. Also, the ram size calculation does not change.
Halil Pasic [Wed, 21 Feb 2018 16:56:28 +0000 (17:56 +0100)]
s390x/cpumodel: document S390FeatDef.bit not applicable
The 'bit' field of the 'S390FeatDef' structure is not applicable to all
its instances. Currently this field is not applicable, and remains
unused, iff the feature is of type S390_FEAT_TYPE_MISC. Having the value 0
specified for multiple such feature definitions was a little confusing,
as it's a perfectly legit bit value, and as the value of the bit
field is usually ought to be unique for each feature of a given
feature type.
Let us introduce a specialized macro for defining features of type
S390_FEAT_TYPE_MISC so, that one does not have to specify neither bit nor
type (as the latter is implied).
qmp: add architecture specific cpu data for query-cpus-fast
The s390 CPU state can be retrieved without interrupting the
VM execution. Extendend the CpuInfoFast union with architecture
specific data and an implementation for s390.
Return data looks like this:
[
{"thread-id":64301,"props":{"core-id":0},
"arch":"s390","cpu-state":"operating",
"qom-path":"/machine/unattached/device[0]","cpu-index":0},
{"thread-id":64302,"props":{"core-id":1},
"arch":"s390","cpu-state":"operating",
"qom-path":"/machine/unattached/device[1]","cpu-index":1}
]
Luiz Capitulino [Fri, 16 Feb 2018 16:08:38 +0000 (17:08 +0100)]
qmp: add query-cpus-fast
The query-cpus command has an extremely serious side effect:
it always interrupts all running vCPUs so that they can run
ioctl calls. This can cause a huge performance degradation for
some workloads. And most of the information retrieved by the
ioctl calls are not even used by query-cpus.
This commit introduces a replacement for query-cpus called
query-cpus-fast, which has the following features:
o Never interrupt vCPUs threads. query-cpus-fast only returns
vCPU information maintained by QEMU itself, which should be
sufficient for most management software needs
o Drop "halted" field as it can not be retrieved in a fast
way on most architectures
o Drop irrelevant fields such as "current", "pc" and "arch"
o Rename some fields for better clarification & proper naming
standard
Presently s390x is the only architecture not exposing specific
CPU information via QMP query-cpus. Upstream discussion has shown
that it could make sense to report the architecture specific CPU
state, e.g. to detect that a CPU has been stopped.
With this change the output of query-cpus will look like this on
s390:
Currently, all memory accesses go via the MMU of the address space
(primary, secondary, ...). This is bad, because we don't flush the TLB
when disabling/enabling DAT. So we could add a tlb flush. However it
is easier to simply select the MMU we already have in place for real
memory access.
All we have to do is point at the right MMU and allow to execute these
pages.
This patch is the s390 implementation of guest crash information,
similar to commit d187e08dc4 ("i386/cpu: add crash-information QOM
property") and the related commits. We will detect several crash
reasons, with the "disabled wait" being the most important one, since
this is used by all s390 guests as a "panic like" notification.
Demonstrate these ways with examples as follows.
1. crash-information QOM property;
Run qemu with -qmp unix:qmp-sock,server, then use utility "qmp-shell"
to execute "qom-get" command, and might get the result like,
Run qemu with a socket option, and telnet or nc to that,
-chardev socket,id=qmp,port=4444,host=localhost,server \
-mon chardev=qmp,mode=control,pretty=on \
Negotiating the mode by { "execute": "qmp_capabilities" }, and the crash
information will be reported on a guest crash event like,
Bandan Das [Fri, 23 Feb 2018 16:48:29 +0000 (11:48 -0500)]
usb-mtp: Advertise SendObjectInfo for write support
This patch implements a dummy ObjectInfo structure so that
it's easy to typecast the incoming data. If the metadata is
valid, write_pending is set. Also, the incoming filename
is utf-16, so, instead of depending on external libraries, just
implement a simple function to get the filename
Bandan Das [Fri, 23 Feb 2018 16:48:28 +0000 (11:48 -0500)]
usb-mtp: Introduce write support for MTP objects
Allow write operations on behalf of the initiator. The
precursor to write is the sending of the write metadata
that consists of the ObjectInfo dataset. This patch introduces
a flag that is set when the responder is ready to receive
write data based on a previous SendObjectInfo operation by
the initiator (The SendObjectInfo implementation is in a
later patch)
Bandan Das [Fri, 23 Feb 2018 16:48:27 +0000 (11:48 -0500)]
usb-mtp: Support delete of mtp objects
Write of existing objects by the initiator is acheived by
making a temporary buffer with the new changes, deleting the
old file and then writing a new file with the same name.
Also, add a "readonly" property which needs to be set to false
for deletion to work.
Bandan Das [Fri, 23 Feb 2018 16:48:26 +0000 (11:48 -0500)]
usb-mtp: print parent path in IN_IGNORED trace fn
Fix a possible null dereference when deleting a folder and
its contents. An ignored event might be received for its contents
after the parent folder is deleted which will return a null object.
Thomas Huth [Mon, 26 Feb 2018 10:02:43 +0000 (11:02 +0100)]
pc-bios/s390: Rebuild the s390x firmware images with the boot menu changes
Provide a new s390-ccw.img binary with the boot menu patches by Collin.
Though there should not be any visible changes for the network booting,
the s390-netboot.img binary has been rebuilt, too, since some of the
changes affected the shared source files.
s390-ccw: use zipl values when no boot menu options are present
If no boot menu options are present, then flag the boot menu to
use the zipl options that were set in the zipl configuration file
(and stored on disk by zipl). These options are found at some
offset prior to the start of the zipl boot menu banner. The zipl
timeout value is limited to a 16-bit unsigned integer and stored
as seconds, so we take care to convert it to milliseconds in order
to conform to the rest of the boot menu functionality. This is
limited to CCW devices.
For reference, the zipl configuration file uses the following
fields in the menu section:
prompt=1 enable the boot menu
timeout=X set the timeout to X seconds
To explicitly disregard any boot menu options, then menu=off or
<bootmenu enable='no' ... /> must be specified.
s390-ccw: set cp_receive mask only when needed and consume pending service irqs
It is possible while waiting for multiple types of external
interrupts that we might have pending irqs remaining between
irq consumption and irq-type disabling. Those interrupts
could potentially propagate to the guest after IPL completes
and cause unwanted behavior.
As it is today, the SCLP will only recognize write events that
are enabled by the control program's send and receive masks. To
limit the window for, and prevent further irqs from, ASCII
console events (specifically keystrokes), we should only enable
the control program's receive mask when we need it.
While we're at it, remove assignment of the (non control program)
send and receive masks, as those are actually set by the SCLP.
s390-ccw: read user input for boot index via the SCLP console
Implements an sclp_read function to capture input from the
console and a wrapper function that handles parsing certain
characters and adding input to a buffer. The input is checked
for any erroneous values and is handled appropriately.
A prompt will persist until input is entered or the timeout
expires (if one was set). Example:
Please choose (default will boot in 10 seconds):
Correct input will boot the respective boot index. If the
user's input is empty, 0, or if the timeout expires, then
the default zipl entry will be chosen. If the input is
within the range of available boot entries, then the
selection will be booted. Any erroneous input will cancel
the timeout and re-prompt the user.
When the boot menu options are present and the guest's
disk has been configured by the zipl tool, then the user
will be presented with an interactive boot menu with
labeled entries. An example of what the menu might look
like:
s390-ccw: read stage2 boot loader data to find menu
Read the stage2 boot loader data block-by-block. We scan the
current block for the string "zIPL" to detect the start of the
boot menu banner. We then load the adjacent blocks (previous
block and next block) to account for the possibility of menu
data spanning multiple blocks.
s390-ccw: move auxiliary IPL data to separate location
The s390-ccw firmware needs some information in support of the
boot process which is not available on the native machine.
Examples are the netboot firmware load address and now the
boot menu parameters.
While storing that data in unused fields of the IPL parameter block
works, that approach could create problems if the parameter block
definition should change in the future. Because then a guest could
overwrite these fields using the set IPLB diagnose.
In fact the data in question is of more global nature and not really
tied to an IPL device, so separating it is rather logical.
This commit introduces a new structure to hold firmware relevant
IPL parameters set by QEMU. The data is stored at location 204 (dec)
and can contain up to 7 32-bit words. This area is available to
programming in the z/Architecture Principles of Operation and
can thus safely be used by the firmware until the IPL has completed.
ECKD DASDs have different IPL structures for CDL and LDL
formats. The current Ipl1 and Ipl2 structs follow the CDL
format, so we prepend "EckdCdl" to them. Boot info for LDL
has been moved to a new struct: EckdLdlIpl1.
Some ECKD bootmap code was using structs designed for SCSI.
Even though this works, it confuses readability. Add a new
BootMapTable struct to assist with readability in bootmap
entry code. Also:
- replace ScsiMbr in ECKD code with appropriate structs
- fix read_block messages to reflect BootMapTable
- fixup ipl_scsi to use BootMapTable (referred to as Program Table)
- defined value for maximum table entries
Laurent Vivier [Tue, 20 Feb 2018 17:33:06 +0000 (18:33 +0100)]
linux-user, m68k: select CPU according to ELF header values
M680x0 doesn't support the same set of instructions
as ColdFire, so we can't use "any" CPU type to execute
m68020 instructions.
We select CPU type ("m68040" or "any" for ColdFire)
according to the ELF header. If we can't, we
use by default the value used until now: "any".
Laurent Vivier [Tue, 20 Feb 2018 17:33:04 +0000 (18:33 +0100)]
linux-user: Move CPU type name selection to a function
Instead of a sequence of "#if ... #endif" move the
selection to a function in linux-user/*/target_elf.h
We can't add them in linux-user/*/target_cpu.h
because we will need to include "elf.h" to
use ELF flags with eflags, and including
"elf.h" in "target_cpu.h" introduces some
conflicts in elfload.c
Peter Maydell [Thu, 22 Feb 2018 15:41:24 +0000 (15:41 +0000)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180222' into staging
* New "raspi3" machine emulating RaspberryPi 3
* Fix bad register definitions for VMIDR and VMPIDR (which caused
assertions for 64-bit guest CPUs with EL2 on big-endian hosts)
* hw/char/stm32f2xx_usart: fix TXE/TC bit handling
* Fix ast2500 protection register emulation
* Lots of SD card emulation cleanups and bugfixes
* remotes/pmaydell/tags/pull-target-arm-20180222: (32 commits)
sdcard: simplify SD_SEND_OP_COND (ACMD41)
sdcard: simplify SEND_IF_COND (CMD8)
sdcard: warn if host uses an incorrect address for APP CMD (CMD55)
sdcard: check the card is in correct state for APP CMD (CMD55)
sdcard: handles more commands in SPI mode
sdcard: use a more descriptive label 'unimplemented_spi_cmd'
sdcard: handle the Security Specification commands
sdcard: handle CMD54 (SDIO)
sdcard: use the registerfields API for the CARD_STATUS register masks
sdcard: use the correct masked OCR in the R3 reply
sdcard: simplify using the ldst API
sdcard: remove commands from unsupported old MMC specification
sdcard: clean the SCR register and add few comments
sdcard: fix the 'maximum data transfer rate' to 25MHz
sdcard: update the CSD CRC register regardless the CSD structure version
sdcard: Don't always set the high capacity bit
sdcard: use the registerfields API to access the OCR register
sdcard: use G_BYTE from cutils
sdcard: define SDMMC_CMD_MAX instead of using the magic '64'
sdcard: add more trace events
...
projects / qemu.git / log