This patch introduces PCIPASIDOps for IOMMU related operations.
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg00078.htmlhttps://lists.gnu.org/archive/html/qemu-devel/2018-03/msg00940.html
So far, to setup virt-SVA for assigned SVA capable device, needs to
configure host translation structures for specific pasid. (e.g. bind
guest page table to host and enable nested translation in host).
Besides, vIOMMU emulator needs to forward guest's cache invalidation
to host since host nested translation is enabled. e.g. on VT-d, guest
owns 1st level translation table, thus cache invalidation for 1st
level should be propagated to host.
This patch adds two functions: alloc_pasid and free_pasid to support
guest pasid allocation and free. The implementations of the callbacks
would be device passthru modules. Like vfio.
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Yi Sun <yi.y.sun@linux.intel.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit a72ba82a9dbcf6b5baa3b9f212fd14ec23fc5832)
This header is meant to exposes data types used by
several IOMMU devices such as struct for SVA and
nested stage configuration.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit c9e0fbc4c125a3630d6aa71225ee4a6bac119a99)
This new API allows to inject @count iommu_faults into
the IOMMU memory region.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit ecfcf5f4e9723e9477ec5ef2528ccce4b688d9e1)
We introduce a new IOMMU Memory Region attribute, IOMMU_ATTR_MSI_TRANSLATE
which tells whether the virtual IOMMU translates MSIs. ARM SMMU
will expose this attribute since, as opposed to Intel DMAR, MSIs
are translated as any other DMA requests.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 850ae26a9a2e75f30785c69a1ffc8a41d91aa461)
We introduce a new IOMMU Memory Region attribute,
IOMMU_ATTR_VFIO_NESTED that tells whether the virtual IOMMU
requires HW nested paging for VFIO integration.
Current Intel virtual IOMMU device supports "Caching
Mode" and does not require 2 stages at physical level to be
integrated with VFIO. However SMMUv3 does not implement such
"caching mode" and requires to use HW nested paging.
As such SMMUv3 is the first IOMMU device to advertise this
attribute.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit f526fefda07d10fd540f9ac04efddb92112e1078)
NH_ALL/NSNH_ALL corresponds to a domain granularity invalidation,
ie. all the notifier range gets invalidation, whatever the ASID.
So let's set the granularity to IOMMU_INV_GRAN_DOMAIN to allow
the consumer to benefit from the info if it can.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Suggested-by: chenxiang (M) <chenxiang66@hisilicon.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 68904c523de49807997db96134a0e016641647bd)
At the moment ASID invalidation command (CMD_TLBI_NH_ASID) is
propagated as a domain invalidation (the whole notifier range
is invalidated independently on any ASID information).
The new granularity field now allows to be more precise and
restrict the invalidation to a peculiar ASID. Set the corresponding
fields and flag.
We still keep the iova and addr_mask settings for consumers that
do not support the new fields, like VHOST.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 7e255ba2a5a40cb16f311e7be000419f39e30c5e)
The current IOTLBEntry becomes too simple to interact with
some physical IOMMUs. IOTLBs can be invalidated with different
granularities: domain, pasid, addr. Current IOTLB entry only offers
page selective invalidation. Let's add a granularity field
that conveys this information.
TLB entries are usually tagged with some ids such as the asid
or pasid. When propagating an invalidation command from the
guest to the host, we need to pass those IDs.
Also we add a leaf field which indicates, in case of invalidation
notification, whether only cache entries for the last level of
translation are required to be invalidated.
A flag field is introduced to inform whether those fields are set.
To enforce all existing users do not use those new fields,
initialize the IOMMUTLBEvents when needed.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 2fa8c817167816f22c951308e3edbd0bc7370ecd)
Update the script to import the new iommu.h uapi header.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 683ab306ab1d149c11d4326e5459a5312405c4de)
The new capability VFIO_DIRTY_LOG_MANUAL_CLEAR and the new ioctl
VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP_NOCLEAR and
VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP have been introduced in
the kernel, tweak the userspace side to use them.
Check if the kernel supports VFIO_DIRTY_LOG_MANUAL_CLEAR and
provide the log_clear() hook for vfio_memory_listener. If the
kernel supports it, deliever the clear message to kernel.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit eb15c358d8310a03e5eb4cf957f30314fa41d4a0)
When synchronizing dirty bitmap from kernel VFIO we do it in a
per-iova-range fashion and we allocate the userspace bitmap for each of the
ioctl. This patch introduces `struct VFIODMARange` to describe a range of
the given DMA mapping with respect to a VFIO_IOMMU_MAP_DMA operation, and
make the bitmap cache of this range be persistent so that we don't need to
g_try_malloc0() every time. Note that the new structure is almost a copy of
`struct vfio_iommu_type1_dma_map` but only internally used by QEMU.
More importantly, the cached per-iova-range dirty bitmap will be further
used when we want to add support for the CLEAR_BITMAP and this cached
bitmap will be used to guarantee we don't clear any unknown dirty bits
otherwise that can be a severe data loss issue for migration code.
It's pretty intuitive to maintain a bitmap per container since we perform
log_sync at this granule. But I don't know how to deal with things like
memory hot-{un}plug, sparse DMA mappings, etc. Suggestions welcome.
* yet something to-do:
- can't work with guest viommu
- no locks
- etc
[ The idea and even the commit message are largely inherited from kvm side.
See commit 9f4bf4baa8b820c7930e23c9566c9493db7e1d25. ]
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Kunkun Jiang <jinagkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 54787195fc22365d254d8843f6d154fb0ee07ee9)
The new capability VFIO_DIRTY_LOG_MANUAL_CLEAR and the new ioctl
VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP_NOCLEAR and
VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP have been introduced in
the kernel, update the header to add them.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 7518c53b639053d5535b3c4e3aeb4a21950f9042)
log: Add some logs on VM runtime path
qdev/monitors: Fix reundant error_setg of qdev_add_device
bios-tables-test: Allow changes to q35/SSDT.dimmpxm file
smbios: Add missing member of type 4 for smbios 3.0
bios-tables-test: Update expected q35/SSDT.dimmpxm file
net: eepro100: validate various address valuesi(CVE-2021-20255)
pci: check bus pointer before dereference
ide: ahci: add check to avoid null dereference (CVE-2019-12067)
tap: return err when tap TUNGETIFF fail
xhci: check reg to avoid OOB read
monitor: Discard BLOCK_IO_ERROR event when VM rebooted
monitor: limit io error qmp event to at most once per 60s
Signed-off-by: Chen Qun<kuhn.chenqun@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 3cc842b5237fe9681d6eb2f59fca0652eb0ab0c3)
The speed of BLOCK IO ERROR event maybe very high (thousands per
second). If we report all BLOCK IO ERRORs, the log file will be flooded
with BLOCK IO ERROR event. So throttle it to at most once per 60s.
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 381b95fdf20ab5326ca1811155134a23fbc2046e)
Throttled event like QAPI_EVENT_BLOCK_IO_ERROR may be queued
to limit event rate. Event may be delivered when VM is rebooted
if the event was queued in the *monitor_qapi_event_state* hash table.
Which may casue VM pause and other related problems.
Such as seabios blocked during virtio-scsi initialization:
vring_add_buf(vq, sg, out_num, in_num, 0, 0);
vring_kick(vp, vq, 1);
------------> VM paused here <-----------
/* Wait for reply */
while (!vring_more_used(vq)) usleep(5);
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 42aa18057deead287b570fc44caa8ed4f897c878)
Add a sanity check to fix OOB read access.
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 9d077b427a8779826def993be0c36f365e072f67)
When hotplug ovs kernel netcard, even tap TUNGETIFF failed,
the hotplug would go on and would lead to qemu assert.
The failure should lead to the free_fail.
Signed-off-by: miaoyubo <miaoyubo@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit fcfc664bacbb7d51d667dd6d0c20ce088bc7effe)
Fix CVE-2019-12067
AHCI emulator while committing DMA buffer in ahci_commit_buf()
may do a NULL dereference if the command header 'ad->cur_cmd'
is null. Add check to avoid it.
Reported-by: Bugs SysSec <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Signed-off-by: Jiajie Li <lijiajie11@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 51b23b8b7cc4aac66e472f5ac448084981b0cc3b)
fix CVE-2020-25742
patch link: https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg05294.html
While mapping IRQ level in pci_change_irq_level() routine,
it does not check if pci_get_bus() returned a valid pointer.
It may lead to a NULL pointer dereference issue. Add check to
avoid it.
-> https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Flsi_nullptr1
==1183858==Hint: address points to the zero page.
#0 pci_change_irq_level hw/pci/pci.c:259
#1 pci_irq_handler hw/pci/pci.c:1445
#2 pci_set_irq hw/pci/pci.c:1463
#3 lsi_set_irq hw/scsi/lsi53c895a.c:488
#4 lsi_update_irq hw/scsi/lsi53c895a.c:523
#5 lsi_script_scsi_interrupt hw/scsi/lsi53c895a.c:554
#6 lsi_execute_script hw/scsi/lsi53c895a.c:1149
#7 lsi_reg_writeb hw/scsi/lsi53c895a.c:1984
#8 lsi_io_write hw/scsi/lsi53c895a.c:2146
...
Reported-by: Ruhr-University <bugs-syssec@rub.de>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit da4953b1dfdacc1a60c48e5de2146795725e1155)
According to smbios 3.0 spec, for processor information (type 4),
it adds three new members (Core Count 2, Core enabled 2, thread count 2) for 3.0, Without this three members, we can not get correct cpu frequency from dmi,
Because it will failed to check the length of Processor Infomation in DMI.
The corresponding codes in kernel is like:
if (dm->type == DMI_ENTRY_PROCESSOR &&
dm->length >= DMI_ENTRY_PROCESSOR_MIN_LENGTH) {
u16 val = (u16)get_unaligned((const u16 *)
(dmi_data + DMI_PROCESSOR_MAX_SPEED));
*mhz = val > *mhz ? val : *mhz;
}
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 457ab195e6fed9e1971e10547e1a6d550c0d0b3a)
List test/data/acpi/q35/SSDT.dimmpxm as the expected files allowed to
be changed in tests/qtest/bios-tables-test-allowed-diff.h
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit bbbc6a1a9ca0ae046d5f43e5e5005dbe00796cd6)
There is an extra log "error_setg" in qdev_add_device(). When
hot-plug a device, if the corresponding bus doesn't exist, it
will trigger an asseration "assert(*errp == NULL)".
Fixes: 515a7970490 (log: Add some logs on VM runtime path)
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 4a946ee5713758ec120126384e76e8eb8f6059a0)
Add logs on VM runtime path, to make it easier to do trouble shooting.
Signed-off-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit dfca9d4ba6b13b1b939a97fa7127821799593185)
Using CONFIG_DISABLE_QEMU_LOG macro to control
qemu_log function.
Signed-off-by: Yan Wang <wangyan122@huawei.com>
Signed-off-by: imxcc <xingchaochao@huawei.com>
(cherry picked from commit 0cea596fd445015a851dbd2bfe634644ae30883a)
seabios-convert-value-of-be16_to_cpu-to-u64-before-s.patch:
be16_to_cpu(scsi_lun->lun[i]) is 16 bits and left shifting by more than 16
will have undefined behaviour. convert it to u64 before shifting.
seabios-do-not-give-back-high-ram.patch:
fix bug of Oracle 6 and 7 series virtual machines using the high ram returned by
sebios.
seabios-drop-yield-in-smp_setup.patch:
Fix SeaBIOS stuck problem becuase SeaBIOS open hardware interrupt
by invoking yield(). That's dangerous and unnecessary. Let's drop
it, and make the processing of setup smp more security in SeaBIOS.
seabios-fix-memory-leak-when-pci-check.patch:
fix code memory leak when pci check failed
free busses memory when pci_bios_check_devices function returns error in pci_setup()
seabios-increase-the-seabios-high-mem-zone-size.patch:
In terms of version and specification, under the maximum configuration
specification of the number of vcpus, virtio blocks and other features,
there exists bottleneck in seabios high_mem_zone, which results in the
memory application failure and causes the vm to fail to start.
Increase BUILD_MAX_HIGHTABLE to 512k.
seabios-increase-the-seabios-minibiostable.patch:
Increase the BUILD_MIN_BIOSTABLE to 4096;
support 25 virtio-blk(data) + 1 virtio-scsi(sys) + 1 virtio-net
Increase the BUILD_MIN_BIOSTABLE to 5120;
support 18 virtio-scsi while vm starts with IDE boot disk
Signed-off-by: jiangdongxu <jiangdongxu1@huawei.com>
Since filemonitor testcase requires that host kernel being a LTS version,
we cannot guarantee that on OBS system. Lets disable it by default.
Signed-off-by: Ying Fang <fangying1@huawei.com>
Signed-off-by: Jinhao Gao <gaojinhao@huawei.com>
Reduce the vpcu cost by set a lower FRAME_TIMER_FREQ of the UHCI
when VNC client disconnected. This can reduce about 3% cost of
vcpu thread.
Signed-off-by: eillon <yezhenyu2@huawei.com>
freeclock: add qmp command to get time offset of vm in seconds
freeclock: set rtc_date_diff for arm
freeclock: set rtc_date_diff for X86
Signed-off-by: Chen Qun<kuhn.chenqun@huawei.com>
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>
