When setting the system time in VM, a RTC_CHANGE event will be reported.
However, if libvirt is restarted while the event is be reporting, the
event will be lost and we will get the old time (not the time we set in
VM) after rebooting the VM.
We save the delta time in QEMU and add a rtc-date-diff qmp to get the
delta time so that libvirt can get the latest time in VM according to
the qmp after libvirt is restarted.
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: zhangxinhao <zhangxinhao1@huawei.com>
target/arm: convert isar regs to array
target/arm: parse cpu feature related options
target/arm: register CPU features for property
target/arm: Allow ID registers to synchronize to KVM
target/arm: introduce CPU feature dependency mechanism
target/arm: introduce KVM_CAP_ARM_CPU_FEATURE
target/arm: Add CPU features to query-cpu-model-expansion
target/arm: Add more CPU features
target/arm: ignore evtstrm and cpuid CPU features
target/arm: only set ID_PFR1_EL1.GIC for AArch32 guest
target/arm: Fix write redundant values to kvm
target/arm: clear EL2 and EL3 only when kvm is not enabled
target/arm: Update the ID registers of Kunpeng-920
Signed-off-by: Chen Qun<kuhn.chenqun@huawei.com>
The values of some ID registers in Kunpeng-920 are not exactly correct.
Let's update them. The values are read from Kunpeng-920 by calling
read_sysreg_s.
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
When has_el2 and has_el3 are disabled, which is the default value for
virt machine, QEMU will clear the corresponding field in ID_PFR1_EL1 and
ID_AA64PFR0_EL1 to not expose EL3 and EL2 to guest. Because KVM doesn't
support to emulate ID registers in AArch64 before, it will not take
effect. Hence, clear EL2 and EL3 only when kvm is not enabled for
backwards compatibility.
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
After modifying the value of a ID register, we'd better to try to write
it to KVM so that we can known the value is acceptable for KVM.
Because it may modify the registers' values of KVM, it's not suitable
for other registers.
(cherry-picked from a0d7a9de807639fcfcbe1fe037cb8772d459a9cf)
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Some AArch64 CPU doesn't support AArch32 mode, and the values of AArch32
registers are all 0. Hence, We'd better not to modify AArch32 registers
in AArch64 mode.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
evtstrm and cpuid cann't be controlled by VMM:
1. evtstrm: The generic timer is configured to generate events at a
frequency of approximately 100KHz. It's controlled by the linux
kernel config CONFIG_ARM_ARCH_TIMER_EVTSTREAM.
2. cpuid: EL0 access to certain ID registers is available. It's always
set by linux kernel after 77c97b4ee2129 ("arm64: cpufeature: Expose
CPUID registers by emulation").
However, they are exposed by getauxval() and /proc/cpuinfo. Hence,
let's report and ignore the CPU features if someone set them.
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Add i8mm, bf16, and dgh CPU features for AArch64.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Add CPU features to the result of query-cpu-model-expansion so that
other applications (such as libvirt) can know the supported CPU
features.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Introduce KVM_CAP_ARM_CPU_FEATURE to check whether KVM supports to set
CPU features in ARM.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
Some CPU features are dependent on other CPU features. For example,
ID_AA64PFR0_EL1.FP field and ID_AA64PFR0_EL1.AdvSIMD must have the same
value, which means FP and ADVSIMD are dependent on each other, FPHP and
ADVSIMDHP are dependent on each other.
This commit introduces a mechanism for CPU feature dependency in
AArch64. We build a directed graph from the CPU feature dependency
relationship, each edge from->to means the `to` CPU feature is dependent
on the `from` CPU feature. And we will automatically enable/disable CPU
feature according to the directed graph.
For example, a, b, and c CPU features are in relationship a->b->c, which
means c is dependent on b and b is dependent on a. If c is enabled by
user, then a and b is enabled automatically. And if a is disabled by
user, then b and c is disabled automatically.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
There are 2 steps to synchronize the values of system registers from
CPU state to KVM:
1. write to the values of system registers from CPU state to
(index,value) list by write_cpustate_to_list;
2. write the values in (index,value) list to KVM by
write_list_to_kvmstate;
In step 1, the values of constant system registers are not allowed to
write to (index,value) list. However, a constant system register is
CONSTANT for guest but not for QEMU, which means, QEMU can set/modify
the value of constant system registers that is different from phsical
registers when startup. But if KVM is enabled, guest can not read the
values of the system registers which QEMU set unless they can be written
to (index,value) list. And why not try to write to KVM if kvm_sync is
true?
At the moment we call write_cpustate_to_list, all ID registers are
contant, including ID_PFR1_EL1 and ID_AA64PFR0_EL1 because GIC has been
initialized. Hence, let's give all ID registers a chance to write to
KVM. If the write is successful, then write to (index,value) list.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
The Arm architecture specifies a number of ID registers that are
characterized as comprising a set of 4-bit ID fields. Each ID field
identifies the presence, and possibly the level of support for, a
particular feature in an implementation of the architecture. [1]
For most of the ID fields, there is a minimum presence value, equal to
or higher than which means the corresponding CPU feature is implemented.
Hence, we can use the minimum presence value to determine whether a CPU
feature is enabled and enable a CPU feature.
To disable a CPU feature, setting the corresponding ID field to 0x0/0xf
(for unsigned/signed field) seems as a good idea. However, it maybe
lead to some problems. For example, ID_AA64PFR0_EL1.FP is a signed ID
field. ID_AA64PFR0_EL1.FP == 0x0 represents the implementation of FP
(floating-point) and ID_AA64PFR0_EL1.FP == 0x1 represents the
implementation of FPHP (half-precision floating-point). If
ID_AA64PFR0_EL1.FP is set to 0xf when FPHP is disabled (which is also
disable FP), guest kernel maybe stuck. Hence, we add a ni_value (means
not-implemented value) to disable a CPU feature safely.
[1] D13.1.3 Principles of the ID scheme for fields in ID registers in
DDI.0487
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
The implementation of CPUClass::parse_features only supports CPU
features in "feature=value" format. However, libvirt maybe send us a
CPU feature string in "+feature/-feature" format. Hence, we need to
override CPUClass::parse_features to support CPU feature string in both
"feature=value" and "+feature/-feature" format.
The logic of AArch64CPUClass::parse_features is similar to that of
X86CPUClass::parse_features.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
The isar in ARMCPU is a struct, each field of which represents an ID
register. It's not convenient for us to support CPU feature in AArch64.
So let's change it to an array first and add an enum as the index of the
array for convenience. Since we will never access high 32-bits of ID
registers in AArch32, it's harmless to change the ID registers in
AArch32 to 64-bits.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu3@huawei.com>
On AMD target, when host cache passthrough is disabled we will
emulate the guest caches with default values and initialize the
shared cpu list of the caches based on vCPU topology. However
when host cache passthrough is enabled, the shared cpu list is
consistent with host regardless what the vCPU topology is.
For example, when cache passthrough is enabled, running a guest
with vThreads=1 on a host with pThreads=2, we will get that there
are every *two* logical vCPUs sharing a L1/L2 cache, which is not
consistent with the vCPU topology (vThreads=1).
So let's reinitialize BITs[25:14] of AMD CPUID 8000_001D.EAX
based on the actual vCPU topology instead of host pCPU topology.
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
On Intel target, when host cache passthrough is disabled we will
emulate the guest caches with default values and initialize the
shared cpu list of the caches based on vCPU topology. However when
host cache passthrough is enabled, the shared cpu list is consistent
with host regardless what the vCPU topology is.
For example, when cache passthrough is enabled, running a guest
with vThreads=1 on a host with pThreads=2, we will get that there
are every *two* logical vCPUs sharing a L1/L2 cache, which is not
consistent with the vCPU topology (vThreads=1).
So let's reinitialize BITs[25:14] of Intel CPUID 4 based on the
actual vCPU topology instead of host pCPU topology.
Signed-off-by: Jian Wang <wangjian161@huawei.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
nbd/server.c: fix invalid read after client was already free
qemu-nbd: make native as the default aio mode
qemu-nbd: set timeout to qemu-nbd socket
qemu-pr: fixed ioctl failed for multipath disk
block: enable cache mode of empty cdrom
block: disallow block jobs when there is a BDRV_O_INACTIVE flag
scsi: cdrom: Fix crash after remote cdrom detached
block: bugfix: disable process AIO when attach scsi disk
block: bugfix: Don't pause vm when NOSPACE EIO happened
scsi: bugfix: fix division by zero
Signed-off-by: Chen Qun<kuhn.chenqun@huawei.com>
When backend disk is FULL and disk IO type is 'dataplane',
QEMU will pause the vm, and this may cause endless-loop in
QEMU main thread if we do the snapshot merge now.
When backend disk is FULL, only reporting an error rather
than pausing the virtual machine.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
When initializing the virtio-scsi disk, hd_geometry_guess() will
be called to process AIO. At this time, the scsi disk has not
been fully initialized, and some fields in struct SCSIDiskState,
such as vendor and version, are NULL. If processing AIO at this
time, qemu may crash down.
Add aio_disable_external() before hd_geometry_guess() to disable
processing AIO at that time.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
There is a small window between the twice blk_is_available in
scsi_disk_emulate_command which would cause crash due to the later
assertion if the remote cdrom is detached in this window.
So this patch replaces assertions with return to avoid qemu crash.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
Currently, migration will put a BDRV_O_INACTIVE flag
on bs's open_flags until another resume being called. In that case,
any IO from vm or block jobs will cause a qemu crash with an assert
'assert(!(bs->open_flags & BDRV_O_INACTIVE))' failure in bdrv_co_pwritev
function. we hereby disallow block jobs by faking a blocker.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
We use ioctl to detect multipath devices. However, we only set flags in
struct dm_ioctl (the argument to ioctl) and left other fields in random,
which may cause the failure of calling ioctl. Hence, we set other
fields to 0 to avoid the failure.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
In case of insufficient memory and kill-9,
the NBD socket cannot be processed and stuck all the time.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
When the file system is dealing with multithreading concurrent writing to a file,
the performance will be degraded because of the lock.
At present, the default AIO mode of QEMU NBD is threads. In the case of large blocks,
because IO is divided into small pieces and multiple queues, it will become multithreading
concurrent writing the same file. Due to the file system, the performance will be greatly reduced.
If you change to native mode, this problem will not exist.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
In the process of NBD equipment pressurization, executing QEMU NBD will
lead to the failure of IO distribution and go to NBD_ Out process of trip().
If two or more IO go to the out process, client NBD will release in nbd_request_put().
The user after free problem that is read again in close().
Through the NBD_ Save the value of client > closing before the out process in trip
to solve the use after free problem.
Signed-off-by: wangjian161 <wangjian161@huawei.com>
Lots of patches will use qemu_log, it will cause "make check V=1"
failure. So disable qemu_log when calling "make check V=1".
Signed-off-by: Yan Wang <wangyan122@huawei.com>
cpu: parse +/- feature to avoid failure
cpu: add Kunpeng-920 cpu support
cpu: add Cortex-A72 processor kvm target support
add Phytium's CPU models: FT-2000+ and Tengyun-S2500.
Signed-off-by: Chen Qun<kuhn.chenqun@huawei.com>
The ARM Cortex-A72 is ARMv8-A micro-architecture,
add kvm target to ARM Cortex-A72 processor definition.
Signed-off-by: Xu Yandong <xuyandong2@huawei.com>
Signed-off-by: Mingwang Li <limingwang@huawei.com>
To avoid cpu feature parse failure, +/- feature is added.
Signed-off-by: Xu Yandong <xuyandong2@huawei.com>
Signed-off-by: Mingwang Li <limingwang@huawei.com>
