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>
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>
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>
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>
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>
Currently lpc emulates all the supported COM ports no matter it is
configured or not in command line. Change the behavior to only emulate
those specified in command line.
Tracked-On: #8537
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Extend the devicemodel lpc uart emulation support to COM4. Since
COM1 is usually used for hv console and COM2 is taken by S5 feature,
only COM1 and COM2 is not enough.
Tracked-On: #8537
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Currently only devices on usb bus 0-4, port 0-19 can be passthrough to
the emulated XHCI controller. Remove this unnecessary limit.
Some unused definitions are also removed.
Tracked-On: #8506
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Host doorbell array write can be asynchronous, so add an async thread
which is used to deal doorbell write.
Tracked-On: #8504
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
doxygen will warn that documented return type is found for functions
that does not return anything in 1.9.4 or later versions. 'None' is
not a special keyword in doxyge, it will recognize it as description
to the return value that does not exist in void functions.
Tracked-On: #8425
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Currently the DSM (Data of Stolen Memory) size was hardcoded to 64M in
ACRN, meaning that users must set "DVMT Pre-Allocated" to 64M in order
to make IGD passthrough (GVT-d) to work. This patch reads the BIOS-
configured memory size from GGC (GMCH Graphics Control, 0x50) register
and passthrough corresponding area to guest.
Tracked-On: #8432
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
The register index and data format of BDSM (Base Data of Stolen Memory)
of Intel integrated graphics is changed in GPU Gen 11. Currently ACRN
uses a long device list for Gen11+ devices. This patch introduces a new
device allowlist for IGD passthrough in igd_pciids.h, covering IGD
device ids from Skylake, and handles passthrough by its generation.
If a device is not listed, it will be treated as a gen 11 device and a
warning will be printed, developers should add the new device to the
list if it is verified to work.
Tracked-On: #8432
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Since Intel Processor Graphics Gen11, Base Data of Stolen Memory (BDSM)
register is extended to 64 bit, allowing BIOS to assign an above 4G
address. This patch changes the type of hpa/gpa variables to uint64_t
to properly handle such case.
Tracked-On: #8432
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
In virtio_gpu_cmd_create_blob() and virtio_gpu_cmd_resource_attach_
backing(), entries may be accessed before initialization. Fix it by
using calloc() to allocate it instead of malloc().
Tracked-On: #8439
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
strcasestr() returns NULL if specified substring is not found, which
should be handled when parsing the command line options.
Tracked-On: #8439
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch checks the romfile path length in command line to avoid
possible buffer overflow, maximum path supported is 255 characters.
Tracked-On: #8439
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
This patch fix several issues that NULL pointers possibly be
dereferenced in display module.
Tracked-On: #8439
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
Pointer 'vsock->vhost_vsock' returned from call to function
'vhost_vsock_init' may be NULL and will be dereferenced when
calling 'vhost_vsock_set_guest_cid()'.
Tracked-On: #8439
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
The optional object _CPC declares an interface that allows OSPM to
transition the processor into a performance state based on a continuous
range of allowable values.
It is associated with HWP on intel CPUs. Although Linux intel_pstate driver
can have its performance managing abilities without _CPC, it may still
need this _CPC table to implement some features such as providing the kernel
multi-core scheduler with core priority info.
As currently we are giving guests a vHWP interface for the multi-core
scheduler, this patch adds _CPC to the guest ACPI. _CPC is written only
when the hypervisor decides the guest should have vHWP, using the
existing pm hypercall ACRN_PMCMD_GET_PX_CNT. The idea is:
- If the VM supports vHWP, then the guest is having continuous p-state.
Thus it doesn't have a specific px_cnt. The hypercall returns success
and px_cnt = 0.
- If the VM's p-state is hidden or hv doesn't have its p-state info,
the hypercall returns fail.
Tracked-On: #8414
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Jian Jun Chen <jian.jun.chen@intel.com>
gvt_init_config() may perform out-of-range read on host_config, add
bound check before accessing it.
Tracked-On: #8382
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.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>
Currently we use configurator to generate sample launch scripts and
configuration code, remove old ones and put all generated launch scripts
into generic_board.
Tracked-On: #6690
Signed-off-by: Xie, nanlin <nanlin.xie@intel.com>
Add the new parameter for register ioevent function, let the vhost
vq and viothread vq can share the register ioevent common API.
Tracked-On: #8323
Signed-off-by: Liu Long <long.liu@linux.intel.com>
Reviewed-by: Conghui <conghui.chen@intel.com>
To avoid assertions in devicemodel, remove all the assert() in vga.c,
use print error message to check errors.
All the behavior of registers follow this spec:
https://wiki.osdev.org/VGA_Hardware#Graphics_Mode
Tracked-On: #8125
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Huang, Yonghua <yonghua.huang@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Add a new flag in ioeventfd ioctl to support asyncio. After that, the IO
request will be processed in asyncio path by kernel and hypervisor.
Tracked-On: #8209
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@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>
Add the option of "romfile=file_location" to specify the rom file for rombar
Tracked-On: #8175
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Wang Yu <yu1.wang@intel.com>
The pci_reg 0x30 of PCI config_space is used to check whether the PCI rom
bar is supported. When the PCI rom is supported for the device in guest vm,
the 0x30 pci_reg is emulated and it can return the addr/enable bit.
Tracked-On: #8175
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
PCI ROM is the firmware specific to PCI device and it is provided by
the device vendor. The PCI rom resides in 0x30 offset of PCI config space.
This can be used to check whether the PCI rom exists. And when it exists,
it can load the firmware from the addr that is obtained from ROM bar addr.
For the user-vm, it will try to load the rom_file for the given PCI device and
enable the VM to access the firmware that is defined in rom_file.
BTW: The emulated rom_file is converted from efi image by using EfiRom. It has
no dependency on the ROM bar of physical PCI devices. Of course if the physical
PCI devices supports the ROM bar, the rom_file can also be dumped from the PCI
rom.
Now this is limited to PCI display device.
V2->V3: Add the function of pci_load_rombar/pci_release_rombar to handle the
rombar in course of passthrough_init/deinit.
Tracked-On: #8175
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Wang Yu <yu1.wang@intel.com>
Now the device model only supports the 0..5 PCI bar for PCI/PCIE devices.
This tries to allocate the PCI_MEM32 resource for PCI ROM bar.
V1->V2: Use the PCI_ROMBAR as bar index and PCIBAR_ROM bar type when calling
the pci_emul_alloc_bar to allocate the guest physical addr for PCI ROM bar.
And it will allocate the resource from PCIBAR_MEM32 region.
V2->V3: Add more comments that describes the parameter of pci_emul_alloc_bar.
Tracked-On: #8175
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Wang Yu <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>
Because of the iteration of i as is, the condition i <= XHCI_MAX_DEVS
always results as true and thus is unnecessary.
When compiling with cflag -Werror this condition will result in a
compilation failure.
Tracked-On: #8114
Signed-off-by: Marius Rodi <marius.rodi@linutronix.de>
Change virtio-i2c from legacy to modern device according to virtio spec v1.2.
Tracked-On: #8055
Signed-off-by: Liu Long <long.liu@linux.intel.com>
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
When no geometry parameter is passed for virtio-gpu, it should not be started.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Wang Yu <yu1.wang@intel.com>
When multi-display window is initialied/configured, it should report the correct number
to virtio-gpu devides so that it can notify that the Guest_VM can use multi-display.
Otherwise the Guest VM still gets only one display.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Wang Yu <yu1.wang@intel.com>
When virtio-gpu is used for guest_vm, ACRN uses the libSDL API to render the framebuffer
submitted from guest virtio-gpu device. The libSDL will cache some op/states related with
3D internally and skip some 3D API. This works well for one display. When multi displays
are enabled, ACRN will create one SDL_Renderer/SDL_window for each display_window.
As the libSDL caches some states, it can't select the correct 3D shader and show
the garbage when switching among multi SDL_Renderer.
This is one limitation in libSDL.
So one small texture(32x32) is created and rendered so that each time it can reconfigure
the internal state for target texture. This is used to workaround the display issue.
Tracked-On: #7988
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Wang Yu <yu1.wang@intel.com>
Qiang Zhang