Now that we have the mechanisms in here, allow shared memory in a
postcopy.
Note that QEMU can't tell who all the users of shared regions are
and thus can't tell whether all the users of the shared regions
have appropriate support for postcopy. Those devices that explicitly
support shared memory (e.g. vhost-user) must check, but it doesn't
stop weirder configurations causing problems.
This message is sent just before the end of postcopy to get the
client to stop using userfault since we wont respond to any more
requests. It should close userfaultfd so that any other pages
get mapped to the backing file automatically by the kernel, since
at this point we know we've received everything.
Add a hook to allow a client userfaultfd to be 'woken'
when a page arrives, and a walker that calls that
hook for relevant clients given a RAMBlock and offset.
Provide a helper to send a 'wake' request on a userfaultfd for
a shared process.
The address in the clients address space is specified together
with the RAMBlock it was resolved to.
# gpg: Signature made Mon 19 Mar 2018 20:07:14 GMT
# gpg: using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <[email protected]>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/machine-next-pull-request:
i386: Disable Intel PT if packets IP payloads have LIP values
cpu: drop unnecessary NULL check and cpu_common_class_by_name()
cpu: get rid of unused cpu_init() defines
Use cpu_create(type) instead of cpu_init(cpu_model)
cpu: add CPU_RESOLVING_TYPE macro
tests: add machine 'none' with -cpu test
nios2: 10m50_devboard: replace cpu_model with cpu_type
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7efe20417a38 in __interceptor_calloc (/lib64/libasan.so.4+0xdea38)
#1 0x7efe1f7b2f75 in g_malloc0 ../glib/gmem.c:124
#2 0x7efe1f7b3249 in g_malloc0_n ../glib/gmem.c:355
#3 0x558272879162 in sev_get_info /home/elmarco/src/qemu/target/i386/sev.c:414
#4 0x55827285113b in hmp_info_sev /home/elmarco/src/qemu/target/i386/monitor.c:684
#5 0x5582724043b8 in handle_hmp_command /home/elmarco/src/qemu/monitor.c:3333
zhangjixiang [Sun, 25 Feb 2018 01:47:51 +0000 (09:47 +0800)]
HMP: Initialize err before using
When bdrv_snapshot_delete return fail, the errp will not be
assigned a valid value in error_propagate as errp didn't be
initialized in hmp_delvm, then error_reportf_err will use an
uninitialized value(call by hmp_delvm), and qemu crash.
Michael Clark [Mon, 19 Mar 2018 21:18:49 +0000 (14:18 -0700)]
RISC-V: Fix riscv_isa_string memory size bug
This version uses a constant size memory buffer sized for
the maximum possible ISA string length. It also uses g_new
instead of g_new0, uses more efficient logic to append
extensions and adds manual zero termination of the string.
Peter Maydell [Tue, 20 Mar 2018 09:51:49 +0000 (09:51 +0000)]
Merge remote-tracking branch 'remotes/ericb/tags/pull-qapi-2018-03-12-v4' into staging
qapi patches for 2018-03-12, 2.12 softfreeze
- Marc-André Lureau: 0/4 qapi: generate a literal qobject for introspection
- Max Reitz: 0/7 block: Handle null backing link
- Daniel P. Berrange: chardev: tcp: postpone TLS work until machine done
- Peter Xu: 00/23 QMP: out-of-band (OOB) execution support
- Vladimir Sementsov-Ogievskiy: 0/2 block latency histogram
- Eric Blake: qapi: Pass '-u' when doing non-silent diff
# gpg: Signature made Mon 19 Mar 2018 19:59:04 GMT
# gpg: using RSA key A7A16B4A2527436A
# gpg: Good signature from "Eric Blake <[email protected]>"
# gpg: aka "Eric Blake (Free Software Programmer) <[email protected]>"
# gpg: aka "[jpeg image of size 6874]"
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* remotes/ericb/tags/pull-qapi-2018-03-12-v4: (38 commits)
qapi: Pass '-u' when doing non-silent diff
qapi: add block latency histogram interface
block/accounting: introduce latency histogram
tests: qmp-test: add oob test
tests: qmp-test: verify command batching
qmp: add command "x-oob-test"
monitor: enable IO thread for (qmp & !mux) typed
qmp: isolate responses into io thread
qmp: support out-of-band (oob) execution
qapi: introduce new cmd option "allow-oob"
monitor: send event when command queue full
qmp: add new event "command-dropped"
monitor: separate QMP parser and dispatcher
monitor: let suspend/resume work even with QMPs
monitor: let suspend_cnt be thread safe
monitor: introduce monitor_qmp_respond()
qmp: introduce QMPCapability
monitor: allow using IO thread for parsing
monitor: let mon_list be tail queue
monitor: unify global init
...
Laurent Vivier [Mon, 19 Mar 2018 11:35:44 +0000 (12:35 +0100)]
target/m68k: add a mechanism to automatically free TCGv
SRC_EA() and gen_extend() can return either a temporary
TCGv or a memory allocated one. Mark them when they are
allocated, and free them automatically at end of the
instruction translation.
We want to free locally allocated TCGv to avoid
overflow in sequence like:
That can fill a lot of TCGv entries in a sequence,
especially since 15fa08f845 ("tcg: Dynamically allocate TCGOps")
we have no limit to fill the TCGOps cache and we can fill
the entire TCG variables array and overflow it.
vhost+postcopy: Helper to send requests to source for shared pages
Provide a helper to be used by shared waker functions to request
shared pages from the source.
The last_rb pointer is moved into the incoming state since this
helper can update it as well as the main fault thread function.
We need a better way, but at the moment we need the address of the
mappings sent back to qemu so it can interpret the messages on the
userfaultfd it reads.
This is done as a 3 stage set:
QEMU -> client
set_mem_table
mmap stuff, get addresses
client -> qemu
here are the addresses
qemu -> client
OK - now you can use them
That ensures that qemu has registered the new addresses in it's
userfault code before the client starts accessing them.
Note: We don't ask for the default 'ack' reply since we've got our own.
postcopy+vhost-user: Split set_mem_table for postcopy
Split the set_mem_table routines in both qemu and libvhost-user
because the postcopy versions are going to be quite different
once changes in the later patches are added. However, this patch
doesn't produce any functional change, just the split.
migrate: Update ram_block_discard_range for shared
The choice of call to discard a block is getting more complicated
for other cases. We use fallocate PUNCH_HOLE in any file cases;
it works for both hugepage and for tmpfs.
We use the DONTNEED for non-hugepage cases either where they're
anonymous or where they're private.
Care should be taken when trying other backing files.
Haozhong Zhang [Sun, 11 Mar 2018 03:02:14 +0000 (11:02 +0800)]
tests/bios-tables-test: add test cases for DIMM proximity
QEMU now builds one SRAT memory affinity structure for each PC-DIMM
and NVDIMM device presented at boot time with the proximity domain
specified in the device option 'node', rather than only one SRAT
memory affinity structure covering the entire hotpluggable address
space with the proximity domain of the last node.
Add test cases on PC and Q35 machines with 4 proximity domains, and
one PC-DIMM and one NVDIMM attached to the 2nd and 3rd proximity
domains respectively. Check whether the QEMU-built SRAT tables match
with the expected ones.
The following ACPI tables need to be added for this test:
tests/acpi-test-data/pc/APIC.dimmpxm
tests/acpi-test-data/pc/DSDT.dimmpxm
tests/acpi-test-data/pc/NFIT.dimmpxm
tests/acpi-test-data/pc/SRAT.dimmpxm
tests/acpi-test-data/pc/SSDT.dimmpxm
tests/acpi-test-data/q35/APIC.dimmpxm
tests/acpi-test-data/q35/DSDT.dimmpxm
tests/acpi-test-data/q35/NFIT.dimmpxm
tests/acpi-test-data/q35/SRAT.dimmpxm
tests/acpi-test-data/q35/SSDT.dimmpxm
New APIC and DSDT are needed because of the multiple processors
configuration. New NFIT and SSDT are needed because of NVDIMM.
Haozhong Zhang [Sun, 11 Mar 2018 03:02:13 +0000 (11:02 +0800)]
hw/acpi-build: build SRAT memory affinity structures for DIMM devices
ACPI 6.2A Table 5-129 "SPA Range Structure" requires the proximity
domain of a NVDIMM SPA range must match with corresponding entry in
SRAT table.
The address ranges of vNVDIMM in QEMU are allocated from the
hot-pluggable address space, which is entirely covered by one SRAT
memory affinity structure. However, users can set the vNVDIMM
proximity domain in NFIT SPA range structure by the 'node' property of
'-device nvdimm' to a value different than the one in the above SRAT
memory affinity structure.
In order to solve such proximity domain mismatch, this patch builds
one SRAT memory affinity structure for each DIMM device present at
boot time, including both PC-DIMM and NVDIMM, with the proximity
domain specified in '-device pc-dimm' or '-device nvdimm'.
The remaining hot-pluggable address space is covered by one or multiple
SRAT memory affinity structures with the proximity domain of the last
node as before.
Haozhong Zhang [Sun, 11 Mar 2018 03:02:12 +0000 (11:02 +0800)]
qmp: distinguish PC-DIMM and NVDIMM in MemoryDeviceInfoList
It may need to treat PC-DIMM and NVDIMM differently, e.g., when
deciding the necessity of non-volatile flag bit in SRAT memory
affinity structures.
A new field 'nvdimm' is added to the union type MemoryDeviceInfo for
such purpose. Its type is currently PCDIMMDeviceInfo and will be
updated when necessary in the future.
It also fixes "info memory-devices"/query-memory-devices which
currently show nvdimm devices as dimm devices since
object_dynamic_cast(obj, TYPE_PC_DIMM) happily cast nvdimm to
TYPE_PC_DIMM which it's been inherited from.
Haozhong Zhang [Sun, 11 Mar 2018 03:02:11 +0000 (11:02 +0800)]
pc-dimm: make qmp_pc_dimm_device_list() sort devices by address
Make qmp_pc_dimm_device_list() return sorted by start address
list of devices so that it could be reused in places that
would need sorted list*. Reuse existing pc_dimm_built_list()
to get sorted list.
While at it hide recursive callbacks from callers, so that:
Luwei Kang [Tue, 13 Mar 2018 19:26:31 +0000 (03:26 +0800)]
i386: Disable Intel PT if packets IP payloads have LIP values
Intel processor trace should be disabled when
CPUID.(EAX=14H,ECX=0H).ECX.[bit31] is set.
Generated packets which contain IP payloads will have LIP
values when this bit is set, or IP payloads will have RIP
values.
Currently, The information of CPUID 14H is constant to make
live migration safty and this bit is always 0 in guest even
if host support LIP values.
Guest sees the bit is 0 will expect IP payloads with RIP
values, but the host CPU will generate IP payloads with
LIP values if this bit is set in HW.
To make sure the value of IP payloads correctly, Intel PT
should be disabled when bit[31] is set.
Eric Blake [Thu, 15 Mar 2018 12:51:16 +0000 (07:51 -0500)]
qapi: Pass '-u' when doing non-silent diff
Ed-script diffs are awful compared to context diffs. Fix another
'diff -q' while in the area (if the files are different, being
noisy makes it easier to diagnose why).
While at it, diff .err before .out, because if a test fails, .err
is more likely to contain the most important information for
fixing the failure.
Introduce latency histogram statics for block devices.
For each accounted operation type, the latency region [0, +inf) is
divided into subregions by several points. Then, calculate
hits for each subregion.
Peter Xu [Fri, 9 Mar 2018 09:00:06 +0000 (17:00 +0800)]
tests: qmp-test: add oob test
Test the new OOB capability. Here we used the new "x-oob-test" command.
First, we send a lock=true and oob=false command to hang the main
thread. Then send another lock=false and oob=true command (which will
be run inside parser this time) to free that hanged command.
Peter Xu [Fri, 9 Mar 2018 09:00:02 +0000 (17:00 +0800)]
qmp: isolate responses into io thread
For those monitors who have enabled IO thread, we'll offload the
responding procedure into IO thread. The main reason is that chardev is
not thread safe, and we need to do all the read/write IOs in the same
thread. For use_io_thr=true monitors, that thread is the IO thread.
We do this isolation in similar pattern as what we have done to the
request queue: we first create one response queue for each monitor, then
instead of replying directly in the main thread, we queue the responses
and kick the IO thread to do the rest of the job for us.
A funny thing after doing this is that, when the QMP clients send "quit"
to QEMU, it's possible that we close the IOThread even earlier than
replying to that "quit". So another thing we need to do before cleaning
up the monitors is that we need to flush the response queue (we don't
need to do that for command queue; after all we are quitting) to make
sure replies for handled commands are always flushed back to clients.
Peter Xu [Sun, 11 Mar 2018 02:38:05 +0000 (20:38 -0600)]
qmp: support out-of-band (oob) execution
Having "allow-oob":true for a command does not mean that this command
will always be run in out-of-band mode. The out-of-band quick path will
only be executed if we specify the extra "run-oob" flag when sending the
QMP request:
The "control" key is introduced to store this extra flag. "control"
field is used to store arguments that are shared by all the commands,
rather than command specific arguments. Let "run-oob" be the first.
Note that in the patch I exported qmp_dispatch_check_obj() to be used to
check the request earlier, and at the same time allowed "id" field to be
there since actually we always allow that.
This new "allow-oob" boolean will be exposed by "query-qmp-schema" as
well for command entries, so that QMP clients can know which commands
can be used in out-of-band calls. For example the command "migrate"
originally looks like:
Peter Xu [Fri, 9 Mar 2018 08:59:59 +0000 (16:59 +0800)]
monitor: send event when command queue full
Set maximum QMP command queue length to 8. If the queue is full,
instead of queuing the command, we directly return a "command-dropped"
event, telling the client that a specific command is dropped.
Note that this flow control mechanism is only valid if OOB is enabled.
If it's not, the effective queue length will always be 1, which strictly
follows original behavior of QMP command handling (which never drops
messages).
Peter Xu [Fri, 9 Mar 2018 08:59:56 +0000 (16:59 +0800)]
monitor: let suspend/resume work even with QMPs
This patches allows QMP monitors to be suspended/resumed.
One thing to mention is that for QMPs that are using IOThreads, we need
an explicit kick for the IOThread in case it is sleeping.
Meanwhile, we need to take special care on non-interactive HMPs.
Currently only gdbserver is using that. For these monitors, we still
don't allow suspend/resume operations.
Peter Xu [Fri, 9 Mar 2018 08:59:53 +0000 (16:59 +0800)]
qmp: introduce QMPCapability
There were no QMP capabilities defined. Define the first capability,
"oob", to allow out-of-band messages.
After this patch, we will allow QMP clients to enable QMP capabilities
when sending the first "qmp_capabilities" command. Originally we are
starting QMP session with no arguments like:
{ "execute": "qmp_capabilities" }
Now we can enable some QMP capabilities using (take OOB as example,
which is the only capability that we support):
When the "arguments" key is not provided, no capability is enabled.
For capability "oob", the monitor needs to be run on a dedicated IO
thread, otherwise the command will fail. For example, trying to enable
OOB on a MUXed typed QMP monitor will fail.
One thing to mention is that QMP capabilities are per-monitor, and also
when the connection is closed due to some reason, the capabilities will
be reset.
Peter Xu [Fri, 9 Mar 2018 08:59:52 +0000 (16:59 +0800)]
monitor: allow using IO thread for parsing
For each Monitor, add one field "use_io_thr" to show whether it will be
using the dedicated monitor IO thread to handle input/output. When set,
monitor IO parsing work will be offloaded to the dedicated monitor IO
thread, rather than the original main loop thread.
This only works for QMP. HMP will always be run on the main loop
thread.
Currently we're still keeping use_io_thr off always. Will turn it on
later at some point.
One thing to mention is that we cannot set use_io_thr for every QMP
monitor. The problem is that MUXed typed chardevs may not work well
with it now. When MUX is used, frontend of chardev can be the monitor
plus something else. The only thing we know would be safe to be run
outside main thread so far is the monitor frontend. All the rest of the
frontends should still be run in main thread only.
Peter Xu [Fri, 9 Mar 2018 08:59:50 +0000 (16:59 +0800)]
monitor: unify global init
There are many places where the monitor initializes its globals:
- monitor_init_qmp_commands() at the very beginning
- single function to init monitor_lock
- in the first entry of monitor_init() using "is_first_init"
Unify them a bit.
monitor_lock is not used before monitor_init() (as confirmed by code
analysis and gdb watchpoints); so we are safe delaying what was a
constructor-time initialization of the mutex into the later first call
to monitor_init().
Peter Xu [Fri, 9 Mar 2018 08:59:49 +0000 (16:59 +0800)]
monitor: move the cur_mon hack deeper for QMP
In monitor_qmp_read(), we have the hack to temporarily replace the
cur_mon pointer. Now we move this hack deeper inside the QMP dispatcher
routine since the Monitor pointer can be actually obtained using
container_of() upon the parser object, just like most of the other JSON
parser users do.
This does not make much sense as a single patch. However, this will be
a big step for the next patch, when the QMP dispatcher routine will be
split from the QMP parser.
chardev: tcp: postpone TLS work until machine done
TLS handshake may create background GSource tasks, while we won't know
the correct GMainContext until the whole chardev (including frontend)
inited. Let's postpone the initial TLS handshake until machine done.
For dynamically created tcp chardev, we don't postpone that by checking
the init_machine_done variable.
Max Reitz [Sat, 10 Mar 2018 22:14:36 +0000 (16:14 -0600)]
qapi: Make more of qobject_to()
This patch reworks some places which use either qobject_type() checks
plus qobject_to(), where the latter alone is sufficient, or NULL checks
plus qobject_type() checks where we can simply do a qobject_to() != NULL
check.
Max Reitz [Sat, 24 Feb 2018 15:40:28 +0000 (16:40 +0100)]
qapi: Add qobject_to()
This is a dynamic casting macro that, given a QObject type, returns an
object as that type or NULL if the object is of a different type (or
NULL itself).
The macro uses lower-case letters because:
1. There does not seem to be a hard rule on whether qemu macros have to
be upper-cased,
2. The current situation in qapi/qmp is inconsistent (compare e.g.
QINCREF() vs. qdict_put()),
3. qobject_to() will evaluate its @obj parameter only once, thus it is
generally not important to the caller whether it is a macro or not,
4. I prefer it aesthetically.
The macro parameter order is chosen with typename first for
consistency with other QAPI macros like QAPI_CLONE(), as well as
for legibility (read it as "qobject to" type "applied to" obj).
Peter Maydell [Mon, 19 Mar 2018 19:20:45 +0000 (19:20 +0000)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180319' into staging
target-arm queue:
* fsl-imx6: Fix incorrect Ethernet interrupt defines
* dump: Update correct kdump phys_base field for AArch64
* char: i.MX: Add support for "TX complete" interrupt
* bcm2836/raspi: Fix various bugs resulting in panics trying
to boot a Debian Linux kernel on raspi3
* remotes/pmaydell/tags/pull-target-arm-20180319:
hw/arm/raspi: Provide spin-loop code for AArch64 CPUs
hw/arm/bcm2836: Hardcode correct CPU type
hw/arm/bcm2836: Use correct affinity values for BCM2837
hw/arm/bcm2836: Create proper bcm2837 device
hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x
hw/arm/bcm2386: Fix parent type of bcm2386
hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCE
hw/arm/boot: assert that secure_boot and secure_board_setup are false for AArch64
hw/arm/raspi: Don't do board-setup or secure-boot for raspi3
char: i.MX: Add support for "TX complete" interrupt
char: i.MX: Simplify imx_update()
dump: Update correct kdump phys_base field for AArch64
fsl-imx6: Swap Ethernet interrupt defines
Peter Maydell [Tue, 13 Mar 2018 15:34:58 +0000 (15:34 +0000)]
hw/arm/raspi: Provide spin-loop code for AArch64 CPUs
The raspi3 has AArch64 CPUs, which means that our smpboot
code for keeping the secondary CPUs in a pen needs to have
a version for A64 as well as A32. Without this, the
secondary CPUs go into an infinite loop of taking undefined
instruction exceptions.
Peter Maydell [Tue, 13 Mar 2018 15:34:57 +0000 (15:34 +0000)]
hw/arm/bcm2836: Hardcode correct CPU type
Now we have separate types for BCM2386 and BCM2387, we might as well
just hard-code the CPU type they use rather than having it passed
through as an object property. This then lets us put the initialization
of the CPU object in init rather than realize.
Note that this change means that it's no longer possible on
the command line to use -cpu to ask for a different kind of
CPU than the SoC supports. This was never a supported thing to
do anyway; we were just not sanity-checking the command line.
This does require us to only build the bcm2837 object on
TARGET_AARCH64 configs, since otherwise it won't instantiate
due to the missing cortex-a53 device and "make check" will fail.
Peter Maydell [Tue, 13 Mar 2018 15:34:56 +0000 (15:34 +0000)]
hw/arm/bcm2836: Use correct affinity values for BCM2837
The BCM2837 sets the Aff1 field of the MPIDR affinity values for the
CPUs to 0, whereas the BCM2836 uses 0xf. Set this correctly, as it
is required for Linux to boot.
Peter Maydell [Tue, 13 Mar 2018 15:34:55 +0000 (15:34 +0000)]
hw/arm/bcm2836: Create proper bcm2837 device
The bcm2837 is pretty similar to the bcm2836, but it does have
some differences. Notably, the MPIDR affinity aff1 values it
sets for the CPUs are 0x0, rather than the 0xf that the bcm2836
uses, and if this is wrong Linux will not boot.
Rather than trying to have one device with properties that
configure it differently for the two cases, create two
separate QOM devices for the two SoCs. We use the same approach
as hw/arm/aspeed_soc.c and share code and have a data table
that might differ per-SoC. For the moment the two types don't
actually have different behaviour.
Peter Maydell [Tue, 13 Mar 2018 15:34:54 +0000 (15:34 +0000)]
hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x
Our BCM2836 type is really a generic one that can be any of
the bcm283x family. Rename it accordingly. We change only
the names which are visible via the header file to the
rest of the QEMU code, leaving private function names
in bcm2836.c as they are.
This is a preliminary to making bcm283x be an abstract
parent class to specific types for the bcm2836 and bcm2837.
Peter Maydell [Tue, 13 Mar 2018 15:34:53 +0000 (15:34 +0000)]
hw/arm/bcm2386: Fix parent type of bcm2386
The TypeInfo and state struct for bcm2386 disagree about what the
parent class is -- the TypeInfo says it's TYPE_SYS_BUS_DEVICE,
but the BCM2386State struct only defines the parent_obj field
as DeviceState. This would have caused problems if anything
actually tried to treat the object as a TYPE_SYS_BUS_DEVICE.
Fix the TypeInfo to use TYPE_DEVICE as the parent, since we don't
need any of the additional functionality TYPE_SYS_BUS_DEVICE
provides.
Peter Maydell [Tue, 13 Mar 2018 15:34:52 +0000 (15:34 +0000)]
hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCE
If we're directly booting a Linux kernel and the CPU supports both
EL3 and EL2, we start the kernel in EL2, as it expects. We must also
set the SCR_EL3.HCE bit in this situation, so that the HVC
instruction is enabled rather than UNDEFing. Otherwise at least some
kernels will panic when trying to initialize KVM in the guest.
Peter Maydell [Tue, 13 Mar 2018 15:34:51 +0000 (15:34 +0000)]
hw/arm/boot: assert that secure_boot and secure_board_setup are false for AArch64
Add some assertions that if we're about to boot an AArch64 kernel,
the board code has not mistakenly set either secure_boot or
secure_board_setup. It doesn't make sense to set secure_boot,
because all AArch64 kernels must be booted in non-secure mode.
It might in theory make sense to set secure_board_setup, but
we don't currently support that, because only the AArch32
bootloader[] code calls this hook; bootloader_aarch64[] does not.
Since we don't have a current need for this functionality, just
assert that we don't try to use it. If it's needed we'll add
it later.
Peter Maydell [Tue, 13 Mar 2018 15:34:50 +0000 (15:34 +0000)]
hw/arm/raspi: Don't do board-setup or secure-boot for raspi3
For the rpi1 and 2 we want to boot the Linux kernel via some
custom setup code that makes sure that the SMC instruction
acts as a no-op, because it's used for cache maintenance.
The rpi3 boots AArch64 kernels, which don't need SMC for
cache maintenance and always expect to be booted non-secure.
Don't fill in the aarch32-specific parts of the binfo struct.
Andrey Smirnov [Thu, 15 Mar 2018 19:11:40 +0000 (12:11 -0700)]
char: i.MX: Simplify imx_update()
Code of imx_update() is slightly confusing since the "flags" variable
doesn't really corespond to anything in real hardware and server as a
kitchensink accumulating events normally reported via USR1 and USR2
registers.
Change the code to explicitly evaluate state of interrupts reported
via USR1 and USR2 against corresponding masking bits and use the to
detemine if IRQ line should be asserted or not.
NOTE: Check for UTS1_TXEMPTY being set has been dropped for two
reasons:
1. Emulation code implements a single character FIFO, so this flag
will always be set since characters are trasmitted as a part of
the code emulating "push" into the FIFO
2. imx_update() is really just a function doing ORing and maksing
of reported events, so checking for UTS1_TXEMPTY should happen,
if it's ever really needed should probably happen outside of
it.
Wei Huang [Fri, 9 Mar 2018 17:03:23 +0000 (12:03 -0500)]
dump: Update correct kdump phys_base field for AArch64
For guest kernel that supports KASLR, the load address can change every
time when guest VM runs. To find the physical base address correctly,
current QEMU dump searches VMCOREINFO for the string "NUMBER(phys_base)=".
However this string pattern is only available on x86_64. AArch64 uses a
different field, called "NUMBER(PHYS_OFFSET)=". This patch makes sure
QEMU dump uses the correct string on AArch64.
Guenter Roeck [Sat, 10 Mar 2018 23:04:50 +0000 (15:04 -0800)]
fsl-imx6: Swap Ethernet interrupt defines
The sabrelite machine model used by qemu-system-arm is based on the
Freescale/NXP i.MX6Q processor. This SoC has an on-board ethernet
controller which is supported in QEMU using the imx_fec.c module
(actually called imx.enet for this model.)
The include/hw/arm/fsm-imx6.h file defines the interrupt vectors for the
imx.enet device like this:
According to https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf,
page 225, in Table 3-1. ARM Cortex A9 domain interrupt summary,
interrupts are as follows.
150 ENET MAC 0 IRQ
151 ENET MAC 0 1588 Timer interrupt
where
150 - 32 == 118
151 - 32 == 119
In other words, the vector definitions in the fsl-imx6.h file are reversed.
Fixing the interrupts alone causes problems with older Linux kernels:
The Ethernet interface will fail to probe with Linux v4.9 and earlier.
Linux v4.1 and earlier will crash due to a bug in Ethernet driver probe
error handling. This is a Linux kernel problem, not a qemu problem:
the Linux kernel only worked by accident since it requested both interrupts.
For backward compatibility, generate the Ethernet interrupt on both interrupt
lines. This was shown to work from all Linux kernel releases starting with
v3.16.
Igor Mammedov [Wed, 7 Feb 2018 14:30:57 +0000 (15:30 +0100)]
cpu: drop unnecessary NULL check and cpu_common_class_by_name()
both do nothing as for the first all callers
parse_cpu_model() and qmp_query_cpu_model_()
should provide non NULL value, so just abort if it's not so.
While at it drop cpu_common_class_by_name() which is not need
any more as every target has CPUClass::class_by_name callback
by now, though abort in case a new arch will forget to define one.
Igor Mammedov [Wed, 7 Feb 2018 10:40:26 +0000 (11:40 +0100)]
Use cpu_create(type) instead of cpu_init(cpu_model)
With all targets defining CPU_RESOLVING_TYPE, refactor
cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model)
so that callers won't have to know internal resolving cpu
type. Place it in exec.c so it could be called from both
target independed vl.c and *-user/main.c.
That allows us to stop abusing cpu type from
MachineClass::default_cpu_type
as resolver class in vl.c which were confusing part of
cpu_parse_cpu_model().
Also with new parse_cpu_model(), the last users of cpu_init()
in null-machine.c and bsd/linux-user targets could be switched
to cpu_create() API and cpu_init() API will be removed by
follow up patch.
With no longer users left remove MachineState::cpu_model field,
new code should use MachineState::cpu_type instead and
leave cpu_model parsing to generic code in vl.c.
Igor Mammedov [Wed, 7 Feb 2018 10:40:25 +0000 (11:40 +0100)]
cpu: add CPU_RESOLVING_TYPE macro
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.
Along with change add target to null-machine tests, so
that when switch to CPU_RESOLVING_TYPE happens,
it would ensure that null-machine usecase still works.
projects / qemu.git / log