Thomas Huth [Fri, 25 Sep 2020 15:40:18 +0000 (16:40 +0100)]
travis.yml: Update Travis to use Bionic and Focal instead of Xenial
According to our support policy, we do not support Xenial anymore.
Time to switch the bigger parts of the builds to Focal instead.
Some few jobs have to be updated to Bionic instead, since they are
currently still failing on Focal otherwise. Also "--disable-pie" is
causing linker problems with newer versions of Ubuntu ... so remove
that switch from the jobs now (we still test it in a gitlab CI job,
so we don't lose much test coverage here).
Thomas Huth [Fri, 25 Sep 2020 15:40:17 +0000 (16:40 +0100)]
travis.yml: Drop the default softmmu builds
The total runtime of all Travis jobs is very long and we are testing
all softmmu targets in the gitlab-CI already - so we can speed up the
Travis testing a little bit by not testing the softmmu targets here
anymore.
Thomas Huth [Fri, 25 Sep 2020 15:40:16 +0000 (16:40 +0100)]
migration: Silence compiler warning in global_state_store_running()
GCC 9.3.0 on Ubuntu complains:
In file included from /usr/include/string.h:495,
from /home/travis/build/huth/qemu/include/qemu/osdep.h:87,
from ../migration/global_state.c:13:
In function ‘strncpy’,
inlined from ‘global_state_store_running’ at ../migration/global_state.c:47:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
‘__builtin_strncpy’ specified bound 100 equals destination size [-Werror=stringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... but we apparently really want to do a strncpy here - the size is already
checked with the assert() statement right in front of it. To silence the
warning, simply replace it with our strpadcpy() function.
* remotes/jsnow-gitlab/tags/ide-pull-request:
ide: cancel pending callbacks on SRST
ide: clear interrupt on command write
ide: remove magic constants from the device register
ide: reorder set/get sector functions
ide: model HOB correctly
ide: don't tamper with the device register
ide: rename cmd_write to ctrl_write
hw/ide/ahci: Do not dma_memory_unmap(NULL)
MAINTAINERS: Update my git address
John Snow [Fri, 24 Jul 2020 05:23:00 +0000 (01:23 -0400)]
ide: cancel pending callbacks on SRST
The SRST implementation did not keep up with the rest of IDE; it is
possible to perform a weak reset on an IDE device to remove the BSY/DRQ
bits, and then issue writes to the control/device registers which can
cause chaos with the state machine.
Fix that by actually performing a real reset.
Reported-by: Alexander Bulekov <[email protected]> Fixes: https://bugs.launchpad.net/qemu/+bug/1878253 Fixes: https://bugs.launchpad.net/qemu/+bug/1887303 Fixes: https://bugs.launchpad.net/qemu/+bug/1887309 Signed-off-by: John Snow <[email protected]>
John Snow [Fri, 24 Jul 2020 05:22:58 +0000 (01:22 -0400)]
ide: remove magic constants from the device register
(In QEMU, we call this the "select" register.)
My memory isn't good enough to memorize what these magic runes
do. Label them to prevent mixups from happening in the future.
Side note: I assume it's safe to always set 0xA0 even though ATA2 claims
these bits are reserved, because ATA3 immediately reinstated that these
bits should be always on. ATA4 and subsequent specs only claim that the
fields are obsolete, so I assume it's safe to leave these set and that
it should work with the widest array of guests.
John Snow [Fri, 24 Jul 2020 05:22:56 +0000 (01:22 -0400)]
ide: model HOB correctly
I have been staring at this FIXME for years and I never knew what it
meant. I finally stumbled across it!
When writing to the command registers, the old value is shifted into a
HOB copy of the register and the new value is written into the primary
register. When reading registers, the value retrieved is dependent on
the HOB bit in the CONTROL register.
By setting bit 7 (0x80) in CONTROL, any register read will, if it has
one, yield the HOB value for that register instead.
Our code has a problem: We were using bit 7 of the DEVICE register to
model this. We use bus->cmd roughly as the control register already, as
it stores the value from ide_ctrl_write.
Lastly, all command register writes reset the HOB, so fix that, too.
John Snow [Fri, 24 Jul 2020 05:22:55 +0000 (01:22 -0400)]
ide: don't tamper with the device register
In real ISA operation, register writes go out to an entire bus channel
and all listening devices receive the write. The devices do not toggle
the DEV bit based on their own configuration, nor does the HBA
intermediate or tamper with that value.
The reality of the matter is that DEV0/DEV1 accordingly will react to
command register writes based on whether or not the device was selected.
This does not fix a known bug, but it makes the code slightly simpler
and more obvious.
This is because we don't check the return value from dma_memory_map()
which can return NULL, then we call dma_memory_unmap(NULL) which is
illegal. Fix by only unmap if the value is not NULL (and the size is
not the expected one).
Peter Maydell [Thu, 1 Oct 2020 15:41:30 +0000 (16:41 +0100)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20201001' into staging
target-arm queue:
* Make isar_feature_aa32_fp16_arith() handle M-profile
* Fix SVE splice
* Fix SVE LDR/STR
* Remove ignore_memory_transaction_failures on the raspi2
* raspi: Various cleanup/refactoring
* remotes/pmaydell/tags/pull-target-arm-20201001:
hw/arm/raspi: Remove use of the 'version' value in the board code
hw/arm/raspi: Use RaspiProcessorId to set the firmware load address
hw/arm/raspi: Introduce RaspiProcessorId enum
hw/arm/raspi: Use more specific machine names
hw/arm/raspi: Avoid using TypeInfo::class_data pointer
hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState
hw/arm/raspi: Load the firmware on the first core
hw/arm/raspi: Display the board revision in the machine description
hw/arm/raspi: Remove ignore_memory_transaction_failures on the raspi2
hw/arm/bcm2835: Add more unimplemented peripherals
hw/arm/raspi: Define various blocks base addresses
target/arm: Fix SVE splice
target/arm: Fix sve ldr/str
target/arm: Make isar_feature_aa32_fp16_arith() handle M-profile
target/arm: Add ID register values for Cortex-M0
hw/intc/armv7m_nvic: Only show ID register values for Main Extension CPUs
target/arm: Move id_pfr0, id_pfr1 into ARMISARegisters
target/arm: Replace ARM_FEATURE_PXN with ID_MMFR0.VMSA check
hw/arm/raspi: Remove use of the 'version' value in the board code
We expected the 'version' ID to match the board processor ID,
but this is not always true (for example boards with revision
id 0xa02042/0xa22042 are Raspberry Pi 2 with a BCM2837 SoC).
This was not important because we were not modelling them, but
since the recent refactor now allow to model these boards, it
is safer to check the processor id directly. Remove the version
check.
As we only support a reduced set of the REV_CODE_PROCESSOR id
encoded in the board revision, define the PROCESSOR_ID values
as an enum. We can simplify the board_soc_type and cores_count
methods.
Now that we can instantiate different machines based on their
board_rev register value, we can have various raspi2 and raspi3.
In commit fc78a990ec103 we corrected the machine description.
Correct the machine names too. For backward compatibility, add
an alias to the previous generic name.
hw/arm/raspi: Avoid using TypeInfo::class_data pointer
Using class_data pointer to create a MachineClass is not
the recommended way anymore. The correct way is to open-code
the MachineClass::fields in the class_init() method.
We can not use TYPE_RASPI_MACHINE::class_base_init() because
it is called *before* each machine class_init(), therefore the
board_rev field is not populated. We have to manually call
raspi_machine_class_common_init() for each machine.
The 'first_cpu' is more a QEMU accelerator-related concept
than a variable the machine requires to use.
Since the machine is aware of its CPUs, directly use the
first one to load the firmware.
hw/arm/raspi: Remove ignore_memory_transaction_failures on the raspi2
Commit 1c3db49d39 added the raspi3, which uses the same peripherals
than the raspi2 (but with different ARM cores). The raspi3 was
introduced without the ignore_memory_transaction_failures flag.
Almost 2 years later, the machine is usable running U-Boot and
Linux.
In commit 00cbd5bd74 we mapped a lot of unimplemented devices,
commit d442d95f added thermal block and commit 0e5bbd7406 the
system timer.
As we are happy with the raspi3, let's remove this flag on the
raspi2.
hw/arm/bcm2835: Add more unimplemented peripherals
The bcm2835-v3d is used since Linux 4.7, see commit 49ac67e0c39c ("ARM: bcm2835: Add VC4 to the device tree"),
and the bcm2835-txp since Linux 4.19, see commit b7dd29b401f5 ("ARM: dts: bcm283x: Add Transposer block").
hw/arm/raspi: Define various blocks base addresses
The Raspberry firmware is closed-source. While running it, it
accesses various I/O registers. Logging these accesses as UNIMP
(unimplemented) help to understand what the firmware is doing
(ideally we want it able to boot a Linux kernel).
Peter Maydell [Thu, 10 Sep 2020 17:38:55 +0000 (18:38 +0100)]
target/arm: Make isar_feature_aa32_fp16_arith() handle M-profile
The M-profile definition of the MVFR1 ID register differs slightly
from the A-profile one, and in particular the check for "does the CPU
support fp16 arithmetic" is not the same.
We don't currently implement any M-profile CPUs with fp16 arithmetic,
so this is not yet a visible bug, but correcting the logic now
disarms this beartrap for when we eventually do.
Peter Maydell [Thu, 10 Sep 2020 17:38:54 +0000 (18:38 +0100)]
target/arm: Add ID register values for Cortex-M0
Give the Cortex-M0 ID register values corresponding to its
implemented behaviour. These will not be guest-visible but will be
used to govern the behaviour of QEMU's emulation. We use the same
values that the Cortex-M3 does.
Peter Maydell [Thu, 10 Sep 2020 17:38:53 +0000 (18:38 +0100)]
hw/intc/armv7m_nvic: Only show ID register values for Main Extension CPUs
M-profile CPUs only implement the ID registers as guest-visible if
the CPU implements the Main Extension (all our current CPUs except
the Cortex-M0 do).
Currently we handle this by having the Cortex-M0 leave the ID
register values in the ARMCPU struct as zero, but this conflicts with
our design decision to make QEMU behaviour be keyed off ID register
fields wherever possible.
Explicitly code the ID registers in the NVIC to return 0 if the Main
Extension is not implemented, so we can make the M0 model set the
ARMCPU struct fields to obtain the correct behaviour without those
values becoming guest-visible.
Peter Maydell [Thu, 10 Sep 2020 17:38:52 +0000 (18:38 +0100)]
target/arm: Move id_pfr0, id_pfr1 into ARMISARegisters
Move the id_pfr0 and id_pfr1 fields into the ARMISARegisters
sub-struct. We're going to want id_pfr1 for an isar_features
check, and moving both at the same time avoids an odd
inconsistency.
Changes other than the ones to cpu.h and kvm64.c made
automatically with:
perl -p -i -e 's/cpu->id_pfr/cpu->isar.id_pfr/' target/arm/*.c hw/intc/armv7m_nvic.c
Peter Maydell [Thu, 10 Sep 2020 17:38:51 +0000 (18:38 +0100)]
target/arm: Replace ARM_FEATURE_PXN with ID_MMFR0.VMSA check
The ARM_FEATURE_PXN bit indicates whether the CPU supports the PXN
bit in short-descriptor translation table format descriptors. This
is indicated by ID_MMFR0.VMSA being at least 0b0100. Replace the
feature bit with an ID register check, in line with our preference
for ID register checks over feature bits.
* remotes/kraxel/tags/microvm-20200930-pull-request:
tests/acpi: update expected data files
acpi/gpex: no reason to use a method for _CRS
tests/acpi: add microvm pcie test
tests/acpi: factor out common microvm test setup
tests/acpi: add empty tests/data/acpi/microvm/DSDT.pcie file
tests/acpi: allow updates for expected data files
microvm/pcie: add 64bit mmio window
microvm: add pcie support
microvm: add irq table
arm: use acpi_dsdt_add_gpex
acpi: add acpi_dsdt_add_gpex
move MemMapEntry
* remotes/bonzini-gitlab/tags/for-upstream: (86 commits)
hw/net/can: Correct Kconfig dependencies
hw/net/can: Documentation for CTU CAN FD IP open hardware core emulation.
hw/net/can: CTU CAN FD IP open hardware core emulation.
hw/net/can/ctucafd: Add CTU CAN FD core register definitions.
net/can: Add can_dlc2len and can_len2dlc for CAN FD.
hw/net/can: sja1000 ignore CAN FD frames
net/can: Initial host SocketCan support for CAN FD.
target/i386: kvm: do not use kvm_check_extension to find paravirtual capabilities
bios-tables-test: Remove kernel-irqchip=off option
target/i386: always create kvmclock device
target/i386: Fix VM migration when interrupt based APF is enabled
helper_syscall x86_64: clear exception_is_int
checkpatch: Detect '%#' or '%0#' in printf-style format strings
typedefs: Restrict PCMachineState to 'hw/i386/pc.h'
hw/xen: Split x86-specific declaration from generic hardware ones
stubs: Split accelerator / hardware related stubs
sysemu/xen: Add missing 'exec/cpu-common.h' header for ram_addr_t type
hw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()
docs: Move object.h overview doc comment to qom.rst
docs: Create docs/devel/qom.rst
...
Pavel Pisa [Mon, 14 Sep 2020 08:13:42 +0000 (10:13 +0200)]
hw/net/can: Correct Kconfig dependencies
The original CAN_PCI config option enables multiple SJA1000 PCI boards
emulation build. These boards bridge SJA1000 into I/O or memory
address space of the host CPU and depend on SJA1000 emulation.
Jan Charvat [Mon, 14 Sep 2020 08:13:40 +0000 (10:13 +0200)]
hw/net/can: CTU CAN FD IP open hardware core emulation.
The implementation of the model of complete open-source/design/hardware
CAN FD controller. The IP core project has been started and is maintained
by Ondrej Ille at Czech Technical University in Prague.
CTU CAN FD project pages:
https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core
CAN bus CTU FEE Projects Listing page:
http://canbus.pages.fel.cvut.cz/
The core is mapped to PCIe card same as on one of its real hardware
adaptations. The device implementing two CTU CAN FD ip cores
is instantiated after CAN bus definition
Paolo Bonzini [Wed, 23 Sep 2020 03:01:39 +0000 (23:01 -0400)]
target/i386: kvm: do not use kvm_check_extension to find paravirtual capabilities
Paravirtualized features have been listed in KVM_GET_SUPPORTED_CPUID since
Linux 2.6.35 (commit 84478c829d0f, "KVM: x86: export paravirtual cpuid flags
in KVM_GET_SUPPORTED_CPUID", 2010-05-19). It has been more than 10 years,
so remove the fallback code.
We don't need to use kernel-irqchip=off for irq0 override if IRQ
routing is supported by the host, which is the case since 2009
(IRQ routing was added to KVM in Linux v2.6.30).
This is a more straightforward fix for Launchpad bug #1896263, as
it doesn't require increasing the complexity of the MSR code.
kernel-irqchip=off is for debugging only and there's no need to
increase the complexity of the code just to work around an issue
that was already fixed in the kernel.
QEMU's kvmclock device is only created when KVM PV feature bits for
kvmclock (KVM_FEATURE_CLOCKSOURCE/KVM_FEATURE_CLOCKSOURCE2) are
exposed to the guest. With 'kvm=off' cpu flag the device is not
created and we don't call KVM_GET_CLOCK/KVM_SET_CLOCK upon migration.
It was reported that without these call at least Hyper-V TSC page
clocksouce (which can be enabled independently) gets broken after
migration.
Switch to creating kvmclock QEMU device unconditionally, it seems
to always make sense to call KVM_GET_CLOCK/KVM_SET_CLOCK on migration.
Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits.
Douglas Crosher [Tue, 22 Sep 2020 04:17:56 +0000 (14:17 +1000)]
helper_syscall x86_64: clear exception_is_int
The exception_is_int flag may be set on entry to helper_syscall,
e.g. after a prior interrupt that has returned, and processing
EXCP_SYSCALL as an interrupt causes it to fail so clear this flag.
checkpatch: Detect '%#' or '%0#' in printf-style format strings
According to the coding style document, we should use literal '0x' prefix
instead of printf's '#' flag (which appears as '%#' or '%0#' in the format
string). Add a checkpatch rule to enforce that.
Note that checkpatch already had a similar rule for trace-events files.
Example usage:
$ scripts/checkpatch.pl --file chardev/baum.c
...
ERROR: Don't use '#' flag of printf format ('%#') in format strings, use '0x' prefix instead
#366: FILE: chardev/baum.c:366:
+ DPRINTF("Broken packet %#2x, tossing\n", req); \
...
ERROR: Don't use '#' flag of printf format ('%#') in format strings, use '0x' prefix instead
#472: FILE: chardev/baum.c:472:
+ DPRINTF("unrecognized request %0#2x\n", req);
...
sysemu/xen: Add missing 'exec/cpu-common.h' header for ram_addr_t type
As this header use the ram_addr_t type, it has to include
"exec/cpu-common.h" to avoid odd errors such:
include/sysemu/xen.h:35:44: error: unknown type name 'ram_addr_t'; did you mean 'in_addr_t'?
35 | static inline void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
| ^~~~~~~~~~
| in_addr_t
The qemu_chr_write_buffer() method sends data to the chardev backend for
writing, and then also writes to the log file. In case the chardev
backend only writes part of the data buffer, we need to make sure we
only log the same subset. qemu_chr_write_buffer() will be invoked again
later to write the rest of the buffer.
In the case the chardev backend returns an error though, no further
attempts to likely to be made to write the data. We must therefore write
the entire buffer to the log immediately.
An example where this is important is with the socket backend. This will
return -1 for all writes if no client is currently connected. We still
wish to write data to the log file when no client is present though.
This used to work because the chardev would return "len" to pretend it
had written all data when no client is connected, but this changed to
return an error in
Igor Mammedov [Fri, 11 Sep 2020 13:32:02 +0000 (09:32 -0400)]
smp: drop support for deprecated (invalid topologies)
it's was deprecated since 3.1
Support for invalid topologies is removed, the user must ensure
that topologies described with -smp include all possible cpus,
i.e. (sockets * cores * threads) == maxcpus or QEMU will
exit with error.
Paolo Bonzini [Mon, 21 Sep 2020 14:34:47 +0000 (10:34 -0400)]
tests/tcg: reinstate or replace desired parts of rules.mak
Commit 660f79309303d696531ffb394719dfab3e0c42c0 was a bit overzealous
with respect to tests/tcg, which needed quiet-command and $(BUILD_DIR).
Reinstate quiet-command, and replace $(BUILD_DIR) with just the
current directory.
The order of the add_project_link_arguments calls impacts which
arguments are placed between --start-group and --end-group.
OSS-Fuzz coverage builds seem to just add these to CFLAGS:
-fprofile-instr-generate -fcoverage-mapping pthread -Wl,--no-as-needed
-Wl,-ldl -Wl,-lm Wno-unused-command-line-argument
The -Wl,-ldl flag that is enough to shift the fork_fuzz.ld linker-script
back into the linker group. Move the linker-script meson call before the
other calls to make sure the flag is placed correctly.
Running checkpatch on a directory that contains a cover letter reports
this error:
Checking /tmp/tmpbnngauy3/0000-cover-letter.patch...
ERROR: Does not appear to be a unified-diff format patch
total: 1 errors, 0 warnings, 0 lines checked
Let's skip cover letter as it is already done in the Linux kernel
commits 06330fc40e3f ("checkpatch: avoid NOT_UNIFIED_DIFF errors
on cover-letter.patch files") and a08ffbef4ab7 ("checkpatch: fix
ignoring cover-letter logic").
Last uses of memory_region_clear_global_locking() have been
removed in commit 7070e085d4 ("acpi: mark PMTIMER as unlocked")
and commit 08565552f7 ("cputlb: Move NOTDIRTY handling from I/O
path to TLB path").
Remove memory_region_clear_global_locking() and the now unused
'global_locking' field in MemoryRegion.
hw/i386/q35: Remove unreachable Xen code on Q35 machine
Xen accelerator requires specific changes to a machine to be able
to use it. See for example the 'Xen PC' machine configure its PCI
bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine
declared. This code was probably added while introducing the Q35
machine, based on the existing PC machine (see commit df2d8b3ed4
"Introduce q35 pc based chipset emulator"). Remove the unreachable
code to simplify this file.
Paolo Bonzini [Tue, 18 Aug 2020 10:17:01 +0000 (12:17 +0200)]
configure: use a platform-neutral prefix
Now that the installation is relocatable, there is no need to compile a
Windows-format prefix into Win32 binaries. Instead, the prefix will
only be used to compute installation-relative paths, and it can be
any string.
Drop the "Program Files" path completely: it is only usable on English
versions of Windows; therefore, using the NSIS installer to get the
"correct" path to the Program Files folder is recommended, and NSIS
works just as well with any prefix.
Paolo Bonzini [Tue, 18 Aug 2020 10:00:59 +0000 (12:00 +0200)]
oslib-posix: default exec_dir to bindir
If the exec_dir cannot be retrieved, just assume it's the installation
directory that was specified at configure time. This makes it simpler
to reason about what the callers will do if they get back an empty
path.
Paolo Bonzini [Mon, 31 Aug 2020 11:58:10 +0000 (07:58 -0400)]
fuzz: use qemu_get_exec_dir
Make things consistent with how softmmu/vl.c uses os_find_datadir.
Initializing the path to the executables will also be needed for
get_relocatable_path to work.
Paolo Bonzini [Tue, 18 Aug 2020 10:11:02 +0000 (12:11 +0200)]
oslib: do not call g_strdup from qemu_get_exec_dir
Just return the directory without requiring the caller to free it.
This also removes a bogus check for NULL in os_find_datadir and
module_load_one; g_strdup of a static variable cannot return NULL.
Paolo Bonzini [Wed, 16 Sep 2020 19:31:11 +0000 (15:31 -0400)]
meson: report accelerator support
Note that the "real" support is reported. A configuration like
--disable-system --enable-kvm will report "no" for "KVM support" because
no KVM-supported target is being compiled.
Paolo Bonzini [Fri, 4 Sep 2020 14:06:06 +0000 (10:06 -0400)]
mtest2make: add support for introspected test dependencies
Right now all "make check" targets depend blindly on "all". If Meson
is 0.56.0 or newer, we can use the correct dependencies using the new
"depends" entry in "meson introspect --tests".
Paolo Bonzini [Wed, 16 Sep 2020 09:00:53 +0000 (05:00 -0400)]
meson: qtest: set "depends" correctly
This does not have any effect on Meson's behavior itself, since "meson test"
always rebuilds everything (that is one reason why we are not using it...).
However, mtest2make can use this information to do a selective rebuild
for the requested suite.
Paolo Bonzini [Tue, 1 Sep 2020 15:34:18 +0000 (11:34 -0400)]
configure: do not limit Hypervisor.framework test to Darwin
Because the target/i386/hvf/meson.build rule culls hvf support
on non-Darwin systems, a --enable-hvf build is succeeding.
To fix this, just try the compilation test every time someone
passes --enable-hvf.
Paolo Bonzini [Tue, 1 Sep 2020 15:15:30 +0000 (11:15 -0400)]
configure: move malloc_trim/tcmalloc/jemalloc to meson
Because LIBS is not used anymore, tcmalloc/jemalloc does
not work with binaries whose description is in Meson.
The fix is simply to move them to Meson too.
For consistency with other configure options, specifying
--enable-malloc-trim together with --enable-{tc,je}malloc
becomes a fatal error.
Xiaoyao Li [Thu, 16 Jul 2020 08:20:18 +0000 (16:20 +0800)]
i386/cpu: Clear FEAT_XSAVE_COMP_{LO,HI} when XSAVE is not available
Per Intel SDM vol 1, 13.2, if CPUID.1:ECX.XSAVE[bit 26] is 0, the
processor provides no further enumeration through CPUID function 0DH.
QEMU does not do this for "-cpu host,-xsave".
Li Qiang [Sat, 15 Aug 2020 14:19:40 +0000 (07:19 -0700)]
hw: megasas: consider 'iov_count=0' is an error in megasas_map_sgl
Currently in 'megasas_map_sgl' when 'iov_count=0' will just return
success however the 'cmd' doens't contain any iov. This will cause
the assert in 'scsi_dma_complete' failed. This is because in
'dma_blk_cb' the 'dbs->sg_cur_index == dbs->sg->nsg' will be true
and just call 'dma_complete'. However now there is no aiocb returned.
Li Qiang [Sat, 15 Aug 2020 14:19:39 +0000 (07:19 -0700)]
hw: megasas: return -1 when 'megasas_map_sgl' fails
The caller of 'megasas_map_sgl' will only check if the return
is zero or not. If it return 0 it means success, as in the next
patch we will consider 'iov_count=0' is an error, so let's
return -1 to indicate a failure.
Dmitry Fomichev [Tue, 11 Aug 2020 22:51:22 +0000 (07:51 +0900)]
scsi-generic: Fix HM-zoned device scan
Several important steps during device scan depend on SCSI type of the
device. For example, max_transfer property is only determined and
assigned if the device has the type of TYPE_DISK.
Host-managed ZBC disks retain most of the properties of regular SCSI
drives, but they have their own SCSI device type, 0x14. This prevents
the proper assignment of max_transfer property for HM-zoned devices in
scsi-generic driver leading to I/O errors if the maximum i/o size
calculated at the guest exceeds the host value.
To fix this, define TYPE_ZBC to have the standard value from SCSI ZBC
standard spec. Several scan steps that were previously done only for
TYPE_DISK devices, are now performed for the SCSI devices having
TYPE_ZBC too.
The serial_mm_read/write() handlers from the TYPE_SERIAL_MM device
call the serial_ioport_read/write() handlers with shifted offset.
When looking at the trace events from this MMIO device, it is
confusing to read the accesses as I/O. Simplify using generic
trace event names which make sense the various uses.
projects / qemu.git / log