During init of hugetlb we check and create /run/hugepage/acrn folder.
Concurrent acrn-dm instances might race between the time of check and
create.
This commit ignore EEXIST error when creating directory.
Tracked-On: #8764
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
1. Enable Service VM to power off or restart the whole platform even when RTVM is running.
2. Allow Service VM stop the RTVM using acrnctl tool with option "stop -f".
3. Add 'Service VM supervisor role enabled' option in ACRN configurator
Tracked-On: #8618
Signed-off-by: YuanXin-Intel <xin.yuan@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
For an elf-loaded or beImage-loaded User VM, acrn-dm is responsible for
handling s3 related matters.
After resume from S3, acrn-dm should read waking_vector and set related
registers to make guest to resume.
Tracked-On: #8536
Signed-off-by: Haiwei Li <haiwei.li@intel.com>
For ovmf-booted User VM, we should set CMOS shutdown status register
(index 0xF) as S3_resume(0xFE). So ovmf will read it and start S3 resume
at POST entry.
And ovmf will read waking vector from FACS table and transfer control to
guest.
Tracked-On: #8624
Signed-off-by: Haiwei Li <haiwei.li@intel.com>
iothreads are created by emulated block devices like virtio. These
devices are resetted on vm reset, but these iothreads are not freed,
causing a resource leak. Fix it by deinit all iothreads on vm reset.
Tracked-On: #8612
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch updates the `iothread` option to specify the CPU affinity
of the iothread. Setting the iothread's CPU affinity could benefit the
Service VM's CPU utilization when Service VM owns limited dedicated CPUs.
It could be helpful to ensure the I/O mediator Quality of Service (QoS).
Once the performance tuning is done, the specific CPU affinity config could
pass to acrn-dm directly, letting the deployment more easily.
The format looks like below:
iothread=<num_iothread>@<cpu_affinity>
"@" is used to separate the following two settings:
- the number of iothread instances
- the CPU affinity settings for each iothread instance.
The format of `cpu_affinity` looks like below:
<cpu_affinity_0>/<cpu_affinity_1>/<cpu_affinity_2>/...
1. "/" is used to separate the CPU affinity setting for each iothread instance
(sequentially).
2. char '*' can be used to skip the setting for the specific iothread instance.
3. the number of cpu_affinity_x vs. the number of iothread instances
- If # of cpu_affinity_x is less than # of iothread instances,
no CPU affinity settings for the last few iothread instances.
- If # of cpu_affinity_x is more than # of iothread instances,
the extra cpu_affinity_x are discarded.
4. ":" is used to separate different CPU cores for each CPU affinity setting.
Examples to specify the CPU affinity of the iothread:
1. iothread=3@0:1:2/0:1
`add_virtual_device 9 virtio-blk iothread=3@0:1:2/0:1,mq=3,/dev/nvme1n1`
a) 3 iothread instances are created.
b) CPU affinity of iothread instances for this virtio-blk device:
- 1st iothread instance <-> pins to Service VM CPU 0,1,2
- 2nd iothread instance <-> pins to Service VM CPU 0,1
- 3rd iothread instance <-> No CPU affinity settings
2. iothread=3@0/*/1
`add_virtual_device 9 virtio-blk iothread=3@0/*/1,mq=3,/dev/nvme1n1`
a) 3 iothread instances are created.
b) CPU affinity of iothread instances for this virtio-blk device:
- 1st iothread instance <-> pins to Service VM CPU 0
- 2nd iothread instance <-> No CPU affinity settings
- 3rd iothread instance <-> pins to Service VM CPU 1
v1 -> v2:
* encapsulate one API in iothread.c to parse the iothread options, so that
other BE can also use it.
v2 -> v3:
* introduce one API iothread_free_options to free the elements that
are allocated dynamically in iothread_parse_options().
Tracked-On: #8612
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
This patch renames the iothread for better readability. For instance,
the new name of the iothread for virtio-blk device looks like `iothr-0-blk9:0`.
It could be helpful when tuning the performance and the CPU utilization.
v1 -> v2:
* add `const` qualifier for the input parameter of `iothread_create`
Tracked-On: #8612
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
To improve the performance of the virtual device who utilizes iothread
(such as virtio-blk), this patch sets iothread nice value to PRIO_MIN,
so that it could get higher priority on scheduling.
This patch does:
- introduce `set_thread_priority` to set the priority of the current running
thread.
The priority could be any value in the range PRIO_MIN to PRIO_MAX.
Lower numerical value causes more favorable scheduling.
- set iothread nice value to PRIO_MIN.
Tracked-On: #8612
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Prior to this patch, one single iothread instance is created and initialized
in the `main` function. This single iothread monitors all the registered fds
and handles all the corresponding requests. It leads to the limited flexibility
of the iothread support.
To improve the flexibility of the iothread support, this patch does:
- add the support of multiple iothread instances.
`iothread_create` is introduced to create a certain number of iothread
instances. It shall be called at first by each virtual device owner (such as
virtio-blk BE) on initialization phase. Then, `iothread_add` can be called
to add the to be monitored fd to the specified iothread.
- update virtio-blk BE to let the acrn-dm option `iothread` accept a number
as the number of iothread instances to be created.
If `iothread` is contained in the parameters, but the number is not specified,
one iothread instance would be created by default.
Examples to specify the number of iothread instances:
1. Create 2 iothread instances
`add_virtual_device 9 virtio-blk iothread=2,mq=2,/dev/nvme1n1,writeback,aio=io_uring`
2. Create 1 iothread instances (by default)
`add_virtual_device 9 virtio-blk iothread,mq=2,/dev/nvme1n1,writeback,aio=io_uring`
- update virtio-blk BE to separate the request handling of different virtqueues
to different iothreads.
The request from one or more virtqueues can be handled in one iothread.
The mapping between virtqueues and iothreads is based on round robin.
v1 -> v2:
* add a mutex to protect the free ioctx slot allocation
Tracked-On: #8612
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
io_uring is a high-performance asynchronous I/O framework, primarily designed
to improve the efficiency of input and output (I/O) operations in user-space
applications.
This patch enables io_uring in block_if module. It utilizes the interfaces
provided by the user-space library `liburing` to interact with io_uring
in kernel-space.
To build the acrn-dm with io_uring support, `liburing-dev` package needs to be
installed. For example, it can be installed like below in Ubuntu 22.04.
sudo apt install liburing-dev
In order to support both the thread pool mechanism and the io_uring mechanism,
an acrn-dm option `aio` is introduced. By default, thread pool mechanism is
selected.
- Example to use io_uring:
`add_virtual_device 9 virtio-blk iothread,mq=2,/dev/nvme1n1,writeback,aio=io_uring`
- Example to use thread pool:
`add_virtual_device 9 virtio-blk iothread,mq=2,/dev/nvme1n1,writeback,aio=threads`
- Example to use thread pool (by default):
`add_virtual_device 9 virtio-blk iothread,mq=2,/dev/nvme1n1,writeback`
v2 -> v3:
* Update iothread_handler
- Use the unified eventfd interfaces to read the counter value of the
ioeventfd.
- Remove the while loop to read the ioeventfd. It is not necessary
because one read would reset the counter value to 0.
* Update iou_submit_sqe to return an error code
The caller of iou_submit_sqe shall check the return value.
If there is NO available submission queue entry in the submission queue,
need to break the while loop. Request can only be submitted when SQE is
available.
v1 -> v2:
* move the logic of reading out ioeventfd from iothread.c to virtio.c, because
it is specific to the virtqueue handling.
Tracked-On: #8612
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Virtio-blk can support multiple virtqueues (mq) which is negotiated
between FE and BE by the feature bit VIRTIO_BLK_F_MQ. The virtqueue
number of virtio-blk can be specified by "mq=x" in the parameter.
For example: "virtio-blk,iothread,mq=2,..."
Tracked-On: #8612
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
When a guest OS performs an RTC change action, we wish this event be
captured by developers, and then they can decide what to do with it.
(e.g., whether to change physical RTC)
There are some facts that makes RTC change event a bit complicated:
- There are 7 RTC date/time regs (year, month…). They can only be
updated one by one.
- RTC time is not reliable before date/time update is finished.
- Guests can update RTC date/time regs in any order.
- Guests may update RTC date/time regs during either RTC halted or not
halted.
A single date/time update event is not reliable. We have to wait for
the guest to finish the update process. So the DM's event handler
sets up a timer, and wait for some time (1 second). If no more change
happens befor the timer expires, we can conclude that the RTC
change has been done. Then the rtc change event is emitted.
This logic of event handler can be used to process HV vrtc time change
event too.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
The idea of event throttle is to allow only curtain mounts of vm_events
to be emitted per second. This feature is implemented with an event
counter and a timer_fd periodic timer. Event counter increases until it
reaches the throttle rate limit, then the periodic timer resets the
counter in each time window.
Events exceed the throttle rate are dropped.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
The default event handler generates the vm_event message in json format,
then emit it through command monitor.
The event data json txt is currently leaved as blank. When a specific
event type is implemented, its event data generate handler can be added
correspondingly.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch added vm_event support in command monitor, so that vm_event
can be sent to a client (e.g., Libvirt) through the monitor.
As the command monitor works in socket server mode, the vm_event sending
process is designed in this way:
1. If a client wishes to receive vm_event, it issues a
REGISTER_VM_EVENT_CLIENT command to the monitor.
2. Command monitor then handles the REGISTER_VM_EVENT_CLIENT command. If
it is legitimate, the client is registered as as vm_event receiver.
The command monitor then send a ACK to the client, and keeps the socket
connection.
3. When a vm_event is generated, the command monitor send it out through
the socket connection.
4. Only one event client is allowed.
5. The registration is cancelled on socket disconnection.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch creates a thread for vm_event delivery. The thread uses epoll
to poll event notifications, then read out the msg data queued in sbuf.
An event handler is called upon success receiving. Both HV and DM event
sources share the same process.
Also vm_event tx API for DM event source is added in this patch.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch adds vm_event sbuf and notification initialization.
We have 2 types of event source: DM and HV, and they are slightly
different:
- Sbuf for DM event source is a memery page shared between threads.
Event notifications are delivered by userspace eventfd.
- While for hv event source, sbuf is a memery page shared with HV. Its
address(GPA) is shared to HV through hypercall. Its notifications
are generated by HV upcall, then delivered by kernel/userspace eventfd.
A sbuf message path acts like a one way ‘tunnel’, so a data structure
‘vm_event_tunnel’ is created to organize those sbufs.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
The sbuf will be used by DM to send and receive vm_events.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Remove the common interface for sbuf setup, as it is not accept by
kernel side. Instead, use dedicate setup function for asyncio to init
its sbuf.
Tracked-On: #8209
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
The version info is mainly used to tell the user when and where the binary is
compiled and built, this will change the dm version format.
The dm follows the format:
major.minor-stable/unstable-remote_branch-acrn-commit_date-commit_id-dirty
(tag-current_commit_id) build by author date.
Compare to the hv version, which is:
major.minor-stable/unstable-remote_branch-acrn-commit_date-commit_id-dirty
DBG/REL(tag-current_commit_id) scenario@board build by author date.
The dm doesn't contain DBG/REL because it's given in configurator-tool
only for hv. also not contain scenario and board info.
e.g.
with tag:
$acrn-dm -v
DM: 3.1-stable-release_3.1-2022-09-27-11:15:42-7fad37e02-dirty(tag: v3.1)
build by zhangwei@2022-11-16 07:02:35
without tag:
$acrn-dm -v
DM: 3.2-unstable-master-2022-11-16-14:34:49-11f53d849-dirty
build by zhangwei@2022-11-16 06:49:43
Tracked-On: #8303
Signed-off-by: Zhangwei6 <wei6.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
asyncio is a new mechanism in ACRN, which is special for these devices
which need high IO performance. ACRN hypervisor would process the IO
request from User VM in an async mode.
Just like the original IOReq shared page, the devicemodel also create a
page for fastio requests. As the asyncio use the ioeventfd, so the
reuqests are handled in kernel, devicemodel only need to provide the
page.
Tracked-On: #8209
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Fix the bug in iothread handler, the event should be read out so that the
next epoll_wait not return directly as the fd can still readable.
Tracked-On: #8181
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
As the type of pthread_t is unsigned long, so the init value for it
should not be '-1'. When the tid is '-1', it will continue to call
pthread_kill/pthread_join. This is incorrect.
Tracked-On: #7960
Signed-off-by: Conghui <conghui.chen@intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Supply a decidate thread, which can moniter a set of fds with epoll,
when the data is ready, call the corresponding callback.
This iothread will be created automatically with the first successful
call to iothread_add, and will be destroyed in iothread_deinit if it
was created.
Note, currenlty only support one iothread.
Tracked-On: #7940
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Modified the copyright year range in code, and corrected "int32_tel"
into "Intel" in two "hypervisor/include/debug/profiling.h" and
"hypervisor/include/debug/profiling_internal.h".
Tracked-On: #7559
Signed-off-by: Ziheng Li <ziheng.li@intel.com>
This patch does:
- define IASL_MIN_VER in the top-level Makefile and pass it Device Model
- verify the "iasl" version at run time
if "iasl" version is older than IASL_MIN_VER, refuse to launch the
post-launched VM and exit directly.
Tracked-On: #7880
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
At run time (on the *target* machine), acrn-dm depends on "iasl" to build
the ACPI tables for post-launched VMs.
This patch does:
- remove the dependency on ASL_COMPILER, which would only be used at build time
- add a new acrn-dm parameter "--iasl <iasl_compiler_path>"
If "--iasl <iasl_compiler_path>" is specified as the acrn-dm parameter,
acrn-dm uses <iasl_compiler_path> as the path to the "iasl" compiler;
otherwise, "which iasl" is used to detect the "iasl" compiler.
If "iasl" is not found at run time, refuse to launch the post-launched VM
and exit directly.
v2 -> v3:
- use "strlen" rather than "strncmp" to check whether asl_compiler
has been set or not
v1 -> v2:
- remove "iasl_param" and "with_iasl_param" to simplify the logic
Tracked-On: #7880
Signed-off-by: Victor Sun <victor.sun@intel.com>
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Virtual display is component which based on native window system.
This feature depended phisical monitor connected and graphic driver in
SOS running correctly. If these dependencies fail, it is a fatal error
for virtual display. We have to terminate the device model to let user
fix runtime environment issue for graphics.
Tracked-On: #7672
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
This patch checks the change of "-s" sub parameters, which was
obsoleted or moved and the print some warnings msg or show the new
format.
The following obsoleted parameters are covered:
-s ,pci-gvt
-s ,virtio-hdcp
-s ,npk
-s ,virtio-coreu
--mac_seed
Reviewed-by: VanCutsem Geoffroy <geoffroy.vancutsem@intel.com>
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
This patch checks the obsoleted parameters and print some warnings
instead of exiting the acrn-dm directly. The following obsoleted
parameters are covered:
-i, --ioc_node
-G, --gvtargs
-Y, --mptgen
--vsbl
--part_info
--pm_by_vuart
--pm_notify_channel
Tracked-On: #6690
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
The guest memory is allocated through hugetlb. Huge page fault is
triggered by writing a byte to the starting address for each huge page.
In hugetlb_fault(), The physical pages are allocated and *clear*.
So no need to erasing the memory again after hugetlb setup. This will
bring about 130ms (changes with platform) latency for each 1G memory.
Notice: this means we depends on kernel to erase the memory in huge page
fault!
Tracked-On: #7298
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Many of the license and Intel copyright headers include the "All rights
reserved" string. It is not relevant in the context of the BSD-3-Clause
license that the code is released under. This patch removes those strings
throughout the code (hypervisor, devicemodel and misc).
Tracked-On: #7254
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
The DMABuf sharing is based on the BLOB feature. This will
check the attribute of system memory for guest_vm and udmabuf.list_limit
parameter. If it meets with the requirement, export the BLOB feature
so that the FE driver in guest_vm can send the blob cmd.
VIRTIO_GPU_CMD_CREATE_BLOB:
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB:
VIRTIO_GPU_CMD_SET_FLUSH(BLOB)
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
After using the memfd to allocate memory for guest vm, it needs to
query the offset in memfd for the given GPA. In order to search the
memfd/offset, the added memory_region from memfd needs to be kept in
one arrary.
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The ACRN-DM uses the explicit hugetlb file to allocate the memory
for guest and the 2M/1G hugetlb can be used. This is based on mounting
hugetlb filesystem.
Now the Linux provides one flexbile memfd mechanism to allocate the memory
and this can make it possible to create the udmabuf for sharing. And the
memfd still can be based on Hugetlb 1G/2M policy. This can bring the below
benefits besides the 1G/2M hugetlb support.
a. memfd is based on anonymous file
b. possible dmabuf mechanism
v2->v3: After completing the mmap for memfd, it will call the ftruncate to
set the desired size and then add the F_SEAL_SEAL flag.
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Now the memory region is aligned down to 2M if 2M hugetlb is supported.
Maybe some contents are dropped if it is not aligned.
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Legacy VGA & VBE interface as a common interface is supported by
many legacy and modern OS. Many installer of OS distribution use
this interface to display the GUI of installer when setup a refresh
new installation on bare-metal. Besides, Windows OS always use this
interface to display it's BSOD, recovery mode & safe mode GUI. It
is need because Windows don't include virtio-gpu driver as their
in-box driver, VGA interface will be used before the virtio-gpu
driver been installed.
To be compatiable with the PCI bar layout of legacy VGA, the layout
is refined to meet with the requirement of legacy VGA and modern
virtio-gpu.
BAR0: VGA Framebuffer memory, 16 MB in size.
BAR2: MMIO Space
[0x0000~0x03ff] EDID data blob
[0x0400~0x041f] VGA ioports registers
[0x0500~0x0516] bochs display interface registers
[0x1000~0x17ff] Virtio common configuration registers
[0x1800~0x1fff] Virtio ISR state registers
[0x2000~0x2fff] Virtio device configuration registers
[0x3000~0x3fff] Virtio notification registers
BAR4: MSI/MSI-X
BAR5: Virtio port io
Tracked-On: #7210
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao, yakui <yakui.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
ACRN virtual monitor shown as a GUI system window of service vm.
It can display graphic outputs of guest vm which is stored in
service vm's buffers by virtio-gpu. Display operation is accelerated
by Intel GPU PF(SRIOV) device with SDL(OpenGL ES 2.0 backend) API.
This provides one generic display solution. When the virtio-gpu is
added, it will firstly try to setup the connection to graphics system
and then display the framebuffer from the guest vm in the created
window region.
Tracked-On: #7210
Signed-off-by: Sun, Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao, yakui <yakui.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
This reverts commit 6750d5a277.
the bug is root caused and fixed, so recovery the original patch.
Tracked-On: #6966
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
DM dynamic param '-A' has been removed.
For compability, add a warning for `-A` instead of terminate the launch
process.
Tracked-On:#6690
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@linux.intel.com>
This reverts commit 811992ee2b.
There could be some conflict with current configure tool. will fix it
later.
Tracked-On: #6966
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
for CPU core partition VM, like RTVM, set PMU passthrough
flag for vtune/perf to run in guest VM.
Tracked-On: #6966
Acked-by: Anthony Xu <anthony.xu@intel.com>
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Previous commit introduced the "use physical APIC IDs as vLAPIC IDs for VMs" change,
but it didn't update the apic_id in mptable. Changed the mptable code to also
set apic_id to physical APIC ID to fix the bug
Tracked-On: #7146
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
'mevent_lmutex' is initialized as default type,
while attempting to recursively lock on this
kind of mutext results in undefined behaviour.
Recursively lock on 'mevent_lmutex' can be detected
in mevent thread when user tries to trigger system
reset from user VM, in this case, user VM reboot hang.
The backtrace for this issue:
#1 in mevent_qlock () at core/mevent.c:93
#2 in mevent_delete_even at core/mevent.c:357
===>Recursively LOCK
#3 in mevent_delete_close at core/mevent.c:387
#4 in acrn_timer_deinit at core/timer.c:106
#5 in virtio_reset_dev at hw/pci/virtio/virtio.c:171
#6 in virtio_console_reset at
hw/pci/virtio/virtio_console.c:196
#7 in virtio_console_destroy at
hw/pci/virtio/virtio_console.c:1015
#8 in virtio_console_teardown_backend at
hw/pci/virtio/virtio_console.c:1042
#9 in mevent_drain_del_list () at
core/mevent.c:348 ===> 1st LOCK
#10 in mevent_dispatch () at core/mevent.c:472
#11 in main at core/main.c:1110
So the root cause is:
mevent_mutex lock is recursively locked by mevent thread
itself (#9 for this first lock and #2 for recursively lock),
which is not allowed for mutex with default attribute.
This patch changes the mutex type of 'mevent_lmutex'
from default to "PTHREAD_MUTEX_RECURSIVE", because
recrusively lock shall be allowed as user of mevent
may call mevent functions (where mutex lock maybe required)
in teardown callbacks.
Tracked-On: #7133
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
The current code does not always check the return value of function
ioctl called in ACRN userspace, and lack of error message printing
to help debug.
This code fixes it by checking the return value of ioctl, and adding
function errormsg to return a string describing of the error code.
Tracked-On: #7029
Signed-off-by: Wen Qian <qian.wen@intel.com>
Signed-off-by: Li Fei <fei1.li@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Libvirt or kata container needs to send some commands
(such as VM destory command) to the DM instance of User VM
through command monitor socket, they will specify the socket
path and pass this path name to DM instance through DM parameter.
In this patch, add new DM parameter (cmd_monitor) to get socket
path from libvirt or kata container. If cmd_monitor is specified,
it initialize and deinitialize command monitor in DM main loop.
v2-->v3:
Include command monitor initialization and deinitialization.
Tracked-On: #5921
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
This monitor module is to initialize socket intance, register
handlers to handle command from socket message, close socket,
free socket instance:
init_cmd_monitor: initialize socket intance and register handlers
to handle command.
deinit_cmd_monitor: close socket and free socket instance.
In this patch DM makefile is updated to build command monitor.
v1--v2:
Update socket path and update log message format.
Parse JSON format command message using libcjson lib APIs.
v2-->v3:
Use socket path length MACRO.
Update JSON format command message to {"command": "xxx"}.
Tracked-On: #5921
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
The command handler is to implement handlers for each command,
currently, two handler is implemented for command monitor:
user_vm_destroy_handler: the handler is for user VM destroy command,
which shuts down to standard post-launched user VM forcefully.
user_vm_blkrescan_handler: the handler is for user VM blkrescan
command, which rescan virtio-blk device to revalidate and update
the backend file for user VM.
v1--v2:
Update log message format.
Generate JSON format ack message using libcjson lib APIs.
v2-->v3:
Update ACK message to {"ack": 0} or {"ack": -1}
Tracked-On: #5921
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
