block_if is the backend of ahci and virtio-blk. Only one queue is
supported by block_if now. Several worker threads are created as
the thread pool for the queue. One BIG mutex is used for the queue
and thread operation. With this patch block_if can support multiple
queues and each queue is backed by several worker threads. blockif_req
can be submited/enqueued into one specified queue. By spliting into
several queues contention from the BIG mutex can be relieved/eliminated.
This is used to support virtio-blk multiple queues feature.
Tracked-On: #8612
Signed-off-by: Jian Jun Chen <jian.jun.chen@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>
Virtio legacy device (ver < 1.0) uses a single PIO for all virtqueues.
Notifications from different virtqueues are implemented by writing
virtqueue index to the PIO. Writing different values to the same addr
needs to be mapped to different eventfds by asyncio. This is called
data match feature of asyncio.
v3 -> v4:
* Update the definition of `struct asyncio_desc`
Use `struct acrn_asyncio_info` inside it, instaed of defining the duplicated
fileds.
* Update `add_asyncio` to use `memcpy_s` rather than assigning all the fields
using 5 assignment statements.
* Update `asyncio_is_conflict` for coding style
120-character line is sufficient to write all conditions.
* Update the checks related to `wildcard`
Because we require every conditional clause to have a Boolean type
in the coding guideline.
v2 -> v3:
No change
v1 -> v2:
No change
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>
ACRN virtio devices are using a per device mutex to protect the
concurrent operations on the device's PIO/MMIO. This introduces
big contention in fast IO hence downgrades the IO performance,
for example virtio-blk with asyncio enabled. This patch introduces
per queue mutex to relieve such issues. Currently the per queue
mutex is only used in the asycio path when iothread is enabled.
Tracked-On: #8612
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
ACRN_IOEVENTFD_FLAG_ASYNCIO is not set when unregister ioeventfd
in the current implementation which will cause the old asyncio_desc
will be remained in hypervisor link list when switching from OVMF to
kernel.
Tracked-On: #8612
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
The create function of hv-emulated device must check the return value
of vpci_init_vdev() as it returns NULL pointer on failure, and that
function should be called atomically.
Also, the destory function should deinit the vpci devices created to
prevent resource leak.
Tracked-On: #8590
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
In devicemodel, a passthrough device is deassigned and then assigned to
guest on guest reboot. Each time hypervisor allocates a new pci_vdev
structure to keep its info. As it was stored in a statically-allocated
array, it will eventually use up all slots, resulting both resource
leak and out-of-bounds access.
Fix it by clearing the corresponding vdev structure on device deassign,
thus a bitmap is introduced to track the usage, replacing the existing
array count.
Tracked-On: #8590
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
The vulnerability was scanned by Trivy on May 28,2024.
Vulnerability ID is GHSA-xphf-cx8h-7q9g and severity is medium,
with title iFrames Bypass Origin Checks for Tauri API Access Control.
I fixed the crash and checked by build-install-launch procedure, I confirm it was solved.
Signed-off-by: dongpingx <dongpingx.wu@intel.com>
Tracked-On: #8613
P-cores and E-cores accessing leaf 0x2U/0x14U/0x16U/0x18U/0x1A/0x1C/0x80000006U
will have different information in hybrid architecture.
So add them to per-cpu list in hybrid architecture and directly return
the physical value.
Note: 0x14U is hided and return 0.
Tracked-On: #8608
Signed-off-by: Haiwei Li <haiwei.li@intel.com>
Leaf 0x6 returns thermal and power management information. In
hybrid architecture, P-cores and E-cores have different information.
Add leaf 0x6 to per-cpu list in hybrid architecture and handle specific
cpuid access.
Tracked-On: #8608
Signed-off-by: Haiwei Li <haiwei.li@intel.com>
Leaf 0x4 returns deterministic cache parameters for each level. In
hybrid architecture, P-cores and E-cores have different cache
information.
Add leaf 0x4 to per-cpu list in hybrid architecture and handle specific
cpuid access.
Tracked-On: #8608
Signed-off-by: Haiwei Li <haiwei.li@intel.com>
CPUID returns processor identification and feature information.
Different pcpus may return different infos. That is, the info is
per-cpu.
In hybrid architecture, per-cpu leaf is different from the previous. So
introduce a struct percpu_cpuids to indicate the per-cpu leaf. struct
percpu_cpuids will consist of two parts: generic percpu leaves and
hybrid related percpu leaves.
This patch is just to add generic percpu leaves.
Tracked-On: #8608
Signed-off-by: Haiwei Li <haiwei.li@intel.com>
CPUID leaf 1f is preferred superset of leaf 0b, currently ACRN exposes
leaf 0b but leaf 1f is empty so the 2 leaves mismatch, and so
application will follow the SDM to check 1f first.
Tracked-On: #8608
Signed-off-by: Xin Zhang <xin.x.zhang@intel.com>
I make this change during recent building configurator but got a failure.
The change is to fix the problem caused by vue3's strictly syntax chacking.
It is reported for newly releases only and before v3.2.25 it is a warning.
I follow the error message and suggestion to change the code.
Error message said "v-model cannot be used on a prop,
because local prop bindings are not writable".
Suggestion said "Use v-bind binding combined with v-on listener to emit update"
I ran the build & install procedure to verify the problem was solved.
Signed-off-by: dongpingx <dongpingx.wu@intel.com>
Tracked-On: #8596
This patch can fetch the thermal lvt irq and propagate
it to VM.
At this stage we support the case that there is only one VM
governing thermal. And we pass the hardware thermal irq to this VM.
First, we register the handler for thermal lvt interrupt, its irq
vector is THERMAL_VECTOR and the handler is thermal_irq_handler().
Then, when a thermal irq occurs, it flags the SOFTIRQ_THERMAL bit
of softirq_pending, This bit triggers the thermal_softirq() function.
And this function will inject the virtual thermal irq to VM.
Tracked-On: #8595
Signed-off-by: Zhangwei6 <wei6.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
In this phase, we only use one VM to control thermal.
So we make thermal MSRs readable and writable by this VM.
This VM is flagged with GUEST_FLAG_VTM, and can
read/write thermal MSRs.
For the VMs not flagged with GUEST_FLAG_VTM,
can only read these thermal MSRs to get current status.
Tracked-On: #8595
Signed-off-by: Zhangwei6 <wei6.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
In hv, we implement the feature of thermal virtualization,
We want to use this GUEST_FLAG_VTM flag to enable and
disable this feature. So we mark this flag in config
tools.
Tracked-On: #8595
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Signed-off-by: Zhangwei6 <wei6.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
`version_find_latest` is removed in grub 2.12, replace it with
`sort -V -r` for maximum compatibility.
Tracked-On: #8576
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Python 3.12 adds escape sequence check in strings, if it is invalid,
a SyntaxWarning will be given. Fix it by using raw string notation
in regular expressions, and changing comments in unused string literal
to normal comments.
Tracked-On: #8588
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Reported by dependabot and scanned by Trivy, there are two dependancies
for Rust crates and one for JavaScript 3rd-party library.
Select the correct versions to fix the issue and verify already.
Tracked-On: #8592
When RX FIFO is not empty and Receive Data Available interrupt is
enabled, vUART should report a Receive Data Available (IIR_RXRDY) in IIR
instead of a Timeout Interrupt Pending (IIR_RXTOUT).
Tracked-On: #8583
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
The break key (key value 0x0) was used as switch key from guest serial
to hv console and guest serial could not receive break key. This blocked
some guest debugging features like KGDB/KDB, sysrq, etc.
This patch leverages escape sequence "<escape> + <break>" to send break to
guest and "<escape> + e" to switch from guest serial to hv console.
Tracked-On: #8583
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
The meaning of lpc_uart_vdev::enabled was changed from runtime enablement
status of UARTs to user configuration in commit 852f10cc3. So it's
incorrect to clear it in lpc_deinit() which will cause UARTs disabled
after reboot.
Tracked-On: #8537
Fixes: 852f10cc3 ("dm: lpc: only emulate COM ports specified in command line")
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
In hcall_vm_intr_monitor(), the default case for intr_hdr->cmd is a
wrong case. So, it should return error code back. But it returns success
code 0 in current codes.
Tracked-On: #8580
Reviewed-by: Fei Li <fei1.li@intel.com>
Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
Leave canary of stack protector untouched on pCPU
if it has been initialized, instead of generating a new one.
Tracked-On: #8577
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
1) region ID shall be configured by user via config tool.
2) region ID is programmed to "Subsystem ID" of PCI config space.
2) "Subsystem Vendor ID" is harded coded as 0x8086
Parameters to configure dm-land IVSHMEM device example generated
by config tool as below:
`add_virtual_device 8 ivshmem hv:/shm_region_0,256,2`
Tracked-On: #8566
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
1) region ID shall be configured by user via config tool.
2) region ID is programmed to "Subsystem ID" of PCI config space.
2) "Subsystem Vendor ID" is harded coded as 0x8086
Tracked-On: #8566
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
This patch adds ivshmem region ID configuration support when user
configure ACRN IVSHMEM devices via ACRN config tool, this ID provides
VMs with a stable identification of multiple shared memory regions.
Also add logic to generate launch script with region ID configured
as below:
`add_virtual_device 8 ivshmem hv:/shm_region_0,256,1`
Tracked-On: #8566
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
ppt_page_pool.bitmap should be zero-initialized. Also fixes the wrong
indention in allocate_ppt_pages().
Tracked-On: #8559
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Add a new option CONSOLE_VM in scenario to set the default vm to be
outputted in hv console, when it is not set, acrn console will be
used (current behavior). This is intended for debugging vm boot issues.
Tracked-On: #8518
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
For uart console, some control keys are defined as byte sequences,
such as:
* up arrow - 0x1b/0x5b/0x41
* F8 - 0x1b/0x5b/0x31/0x39/0x7e
Currently hv console only read one char per poll.
When guest vuart console is active, those byte sequences may not be sent
to guest vuart in good timing due to the poll interval. Thus control keys
such as up/down can not be used in shell or vim.
The solution is to read all input chars in one poll, so that control keys
can be received by guest OS properly.
Tracked-On: #8564
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
sbuf_put copies sbuf->ele_size of data, and puts into ring. Currently
this function assumes that data size from caller is no less than
sbuf->ele_size.
But as sbuf->ele_size is usually setup by some sources outside of the HV
(e.g., the service VM), it is not meant to be trusted. So caller should
provide the max length of the data for safety reason. sbuf_put() will
return UINT32_MAX if max_len of data is less than element size.
Additionally, a helper function sbuf_put_many() is added for putting
multiple entries.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Current acpi table adopts the DWordAddressSpace to
present the PCI hole above 4G. It is not correct,
because DWordAddressSpace is used to present the
mem space below 4G.
Follow the ACPI spec, modify to QWordAddressSpace here.
Refer: 19.6.22. CreateQWordField (Create 64-Bit Buffer Field)
Tracked-On: #8552
Signed-off-by: Zhangwei6 <wei6.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
When LAML or LASA of TPM2 event log is 0, the log area is invalid. It
should not be configured in mmiodevs of vm_configurations.c.
Tracked-On: #8540
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Some DM's virtual timer devices use CLOCK_REALTIME as either clock
counter source or period timer source. Including:
- virtual RTC
- virtual PIT
- virtual HPET
According to Linux Manual, CLOCK_REALTIME is the 'wall clock' which is
affected by discontinuous jumps in the system time.
The issue is that service VM system time could be changed, either by
root user manually or by NTP automatically calibration.
When that happens, DM's virtual timer devices which relays on
CLOCK_REALTIME will experience discontinuous time jump, and become
inaccurate. It would affect both time stamp read value and period timer.
Especially when service VM system time is moved backwards, WaaG's system
software will lost response and be stalled for quite a long time.
To solve this issue, we need to switch CLOCK_REALTIME to
CLOCK_MONOTONIC. As it represents:
'A nonsettable monotonically increasing clock that measures time from
some unspecified point in the past that does not change after system
startup'
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
In the triple fault handler, post-launched VMs are instantly turned
off. Now a vm event is generated simultaneously. So that
developers can capture the event and decide what to do with it. (e.g.,
logging and populating diagnostics, or poweroff VM)
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
When the virtual PM port is written, we can infer that guest has just
initiated a poweroff action. So we send a poweroff event upon this port
write. The DM event handler will try to emit it (to Libvirt).
Developers can write app/script to decide what to do with this event.
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 support for HV vrtc vm_event.
RTC change event is sent upon each date/time reg write. Those events
will be handled in DM. DM will try to emit an RTC change event(to
Libvirt) based on its strategy. Only support post-launched VMs.
The DM event handler has already implemented the rtc chanage event.
Those events will be processed the same way as vrtc events from DM vrtc.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@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 dm vrtc has been using time(NULL) as the vrtc base time. When
service VM system time is adjusted, the vrtc will experience time jump
which will make the vrtc time inaccurate. Change the source of base
time to monotonic time can resolve this issue, as the monotonic time is
not setable.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Through it is best to halt the RTC before changing date/time, still some
OSes just write date/time while RTC is not halted. Currently the DM vRTC
has already dealt the situation where openBSD writes century byte out
side of vRTC halt by updating vRTC time on century byte writes.
Now WaaG is found writing all date/time regs outside of vRTC halt.
Because those date/time writes are not updated instantly, WaaG’s vRTC
time is not actually changed.
This bug has not affected anything till now when we are adding support
to RTC change vm_event.
To make WaaG’s vRTC work properly, this patch adds vRTC time update on
all date/time writes outside of vRTC halt.
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>
