In the command module, the following functions are implemented:
- register_command_handler
Provide one interface to register command handler, other module
can use this interface to register multiple handler for one command.
- find_command
Provide one interface to find a command instance by name;
- dispatch_command_handlers
Provide one interface to dispatch the command and invoke registered
handler.
v1-->v2:
Add comments in head file.
v2-->v3:
Update interface name since "dm" prefix is useless.
Update some log message.
v3-->v4:
Support guest shutdown.
v4-->v5:
Refine command name and add parameter check for interface.
v5-->v6:
Remove allow s5 command.
Tracked-On: #6652
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Reviewed-by: fei1.li@intel.com
This module is to implement unix domain socket server, operator
can connect this server to send system shutdown request, or
guest shutdown command.
In the socket module, the following functions are implemented:
- open_socket
Provide one interface to open one unix domain socket server,
in this interface, initialize a socket, create one thread to
listen to client, another thread to poll message from client;
- close_socket
Provide one interface to close one unix domain socket server;
- write_socket_char
Provide one interface to send message to client.
- find_socket_client
Find socket client instance according to fd
- init_socket
Initialize a socket
- deinit_socket
Deinit a socket
v1-->v3:
Update interface name, only unix domain socket
server is implemented in this module.
v3-->v4:
Add socket client name to support guest shutdown
v4-->v6:
Add find_socket_client, init_socket, deinit_socket
Tracked-On: #6652
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Reviewed-by: fei1.li@intel.com
In the uart module, the following functions are implemented:
- init_uart_channel
Initialize each field of uart channel instance.
- create_uart_channel_dev
Create one channel device instance to store information about
one uart channel device which will be opened.
- wait_uart_channel_devs_threads
Wait uart channel devices threads to exit
- destroy_uart_channel
Destroy uart channel and release channel device instance
- listen_uart_channel_dev
Wait to connect device in uart channel
- connect_uart_channel_dev
Send sync message every 5 second
- poll_and_dispatch_uart_channel_events
Poll and dispatch message received from uart channel
- find_uart_channel_dev
Find uart channel device instance according to fd
- find_uart_channel_dev_by_name
Find uart channel device instance according to device name
- disconnect_uart_channel_dev
Disconnect uart channel device instance
- stop_listen_uart_channel_dev
Stop to listen uart channel device
- enable_uart_channel_dev_resend
Set the uart channel device resending buffer and
resending time
- enable_all_uart_channel_dev_resend
Enable resend for all connected uart channel devices
- disable_uart_channel_dev_resend
Clear the uart channel device resending buffer and
resending time
- notify_all_connected_uart_channel_dev
Send message to each connected uart channel device
- check_uart_channel_connection_list_empty
Check whether uart channel connection list is empty or not
TODO:
Will refine resending logic in the
poll_and_dispatch_uart_channel_events, and add
SYNC command resending.
v3-->v4:
Initialize each field of uart channel instance.
Add one flag indicating master channel device.
Update interface names.
v4-->v5:
Refine interface name.
v5-->v6:
Move uart channel operations from command handler module
v6-->v7:
Add enable_uart_channel_dev_resend and
disable_uart_channel_dev_resend;
Fix bugs about receiving message timeout.
v7-->v8:
Add enable_all_uart_channel_dev_resend interface.
v8-->v9:
Update error handling.
Use strlen to calculate the length of string, this will be
the parameter of send_message_by_uart.
Tracked-On: #6652
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Reviewed-by: fei1.li@intel.com
In the uart module, the following functions are implemented:
- init_uart_dev
Allocate UART device instance and initialize UART device
according to device name.
- deinit_uart_dev
Close UART devcie and free UART device instance.
- send_message_by_uart
Set handler to handle received message.
- receive_message_by_uart
Receive message and retry RETRY_RECV_TIMES time to
avoid miss message in some cases.
- get_uart_dev_fd
Get the file descriptor of a UART device
- get_uart_dev_path
Get the name of a UART device
v1-->v2:
Update sync logic between uart in service VM and uart in
user VM, lifecycle manager will not depend on VM boot order.
Add code comments.
v2-->v3:
This module only includes UART device operations, move other
logic into uart channel module.
v3-->v4:
Add parameters check for interface and refine some names.
v4-->v5:
Refine interface parameter type, error value.
v5-->v6:
Update condition check format of deinit_uart_dev.
Tracked-On: #6652
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Reviewed-by: fei1.li@intel.com
Add assert for below invalid scenario:
1. Two or more pre-launched RTVM
2. One pre-launched RTVM and one or more post-launched RTVM
Tracked-On: #6685
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
1. remove CONFIG_KATA_VM, CONFIG_MAX_KATA_VM_NUM and KATA_VM
related code.
2. remove KATA_VM in scenario xml files.
3. remove KATA vm type in UI.
4. remove UUID DB.
5. remove uuid in the launch script generation logic.
6. use vmname to identify a vm. (eg: <name>ACRN_SOS_VM</name>)
add the check logic to ensure vm name is a must-set item, not duplicated,
and the string length is [1-15] and the whitespace is not allowed.
7. enlarge the max VM num to 32.
Tracked-On: #6685
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Since the UUID is not a *must* set parameter for the standard post-launched
VM which doesn't depend on any static VM configuration. We can remove
the KATA related code from hypervisor as it belongs to such VM type.
v2-->v3:
separate the struce acrn_platform_info change of devicemodel
v1-->v2:
update the subject and commit msg
Tracked-On:#6685
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Since the UUID is not a *must* set parameter for the standard post-launched
VM which doesn't depend on any static VM configuration. We can remove
the KATA related code from hypervisor as it belongs to such VM type.
v2-->v3:
separate the struce acrn_platform_info change of devicemodel
v1-->v2:
update the subject and commit msg
Tracked-On:#6685
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
The UUID has several usages before:
1, For HV to identify the static VM configuration of post-launched VM.
2, Seed virtualization.
3, Slightly prevent launching malicous VM from SOS as lack of secure
boot.
The UUID is confused to user, user don't understand what it is. And user
don't know where to get/apply the UUID. The worst experience is user
can't launch any VMs w/o re-compile the hv. Everything needs to be
static decided in building phase.
Now we decide to remove UUID and split each usage. For 1st usage, use
vmname as the identifier of static VM configuration. For 2nd one, we
will use --vseed as the new parameter. For 3rd one, will pretect by
SOS's dm-verity.
This patch will remove the UUID parameter and support 1st&3rd usages
from DM part. For 2nd usage, another patch will be submitted later.
Tracked-On: #6685
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
With current arch design the UUID is used to identify ACRN VMs,
all VM configurations must be deployed with given UUIDs at build time.
For post-launched VMs, end user must use UUID as acrn-dm parameter
to launch specified user VM. This is not friendly for end users
that they have to look up the pre-configured UUID before launching VM,
and then can only launch the VM which its UUID in the pre-configured UUID list,
otherwise the launch will fail.Another side, VM name is much straight
forward for end user to identify VMs, whereas the VM name defined
in launch script has not been passed to hypervisor VM configuration
so it is not consistent with the VM name when user list VM
in hypervisor shell, this would confuse user a lot.
This patch will resolve these issues by removing UUID as VM identifier
and use VM name instead:
1. Hypervisor will check the VM name duplication during VM creation time
to make sure the VM name is unique.
2. If the VM name passed from acrn-dm matches one of pre-configured
VM configurations, the corresponding VM will be launched,
we call it static configured VM.
If there is no matching found, hypervisor will try to allocate one unused
VM configuration slot for this VM with given VM name and get it run
if VM number does not reach CONFIG_MAX_VM_NUM,
we will call it dynamic configured VM.
3. For dynamic configured VMs, we need a guest flag to identify them
because the VM configuration need to be destroyed
when it is shutdown or creation failed.
Tracked-On: #6685
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Victor Sun<victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
It's recommended we always use the .git extension when referring to the
git repo when cloning. Fix that in the GSG.
Also, fix a misspelling in the hld-power-management doc.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Replace platform names with link to Support Hardware page
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Replace VHM with HSM
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
Publisher of this document confirmed that VT-d spec link should be updated, and the existing link will be EOL.
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
Fix the Vulnerable coding style in xhci and pci core
Tracked-On: #6769
Signed-off-by: Liu Long <longliu@intel.com>
Reviewed-by: Huang, Yonghua <yonghua.huang@intel.com>
Generate serial configuration file for service VM according
to scenario file and vUART ports base address allocated by
config tool.
Currently, some non-standard serial ports are emulated in
hypervisor and will be used to do communication between service
VM and user VM, so need to generate serial configuration file
to configure these serial ports for service VM.
v1-->v2:
Fix some type issues
Refine script code format
Tracked-On: #6652
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
This patch moves the ssram area in ve820 tab, and reunites the
hpa1_low_part1/2 areas. The ve820 building code is refined.
before:
|<---low_1M--->|
|<---hpa1_low_part1--->|
|<---SSRAM--->|
|<---hpa1_low_part2--->|
|<---GPU_OpRegion--->|
|<---ACPI DATA--->|
|<---ACPI NVS--->|
---2G---
after:
|<---low_1M--->|
|<---hpa_low--->|
|<---SSRAM--->|
|<---GPU_OpRegion--->|
|<---ACPI DATA--->|
|<---ACPI NVS--->|
---2G---
The SSRAM area's address is described in the ACPI's RTCT/PTCT
table. To simplify the SSRAM implementation, SSRAM area was
identical mapped to GPA, and resulted in the divition of hpa_low.
Then the ve820 building logic became too complicated.
Now we managed to edit the guest's RTCT/PTCT table by offline
tools in the former patch, so we can move the guest's SSRAM
area, and reunite the hpa_low areas again.
After doing this, this patch rewrites the ve820 building code
in a much simpler way.
Tracked-On: #6674
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
The pre-rtvm uses the RTCT tab to determine it's SSRAM address.
It was origionally duplicated from the host, and keeped its address
and layout.
To move the SSRAM area in ve820, we have to modify the guest's RTCT
tab first.
This patch uses the board_inspector's RTCT module to parse the host's
RTCT tab, and calculate the offset, then modifies the SSRAM/bin enties,
and saves it to the new RTCT bin file.
Tracked-On: #6674
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
The ve820 table' hpa1_low area is divided into two parts, which
is making the code too complicated and causing problems. Moving
the entries that divides the hpa1_low could make things easier.
This patch moves the GPU OpRegion to the tail area of 2G,
consecutive to the acpi data/nvs area.
before:
|<---low_1M--->|
|<---hpa1_low_part1--->|
|<---SSRAM--->|
|<---GPU_OpRegion--->|
|<---hpa1_low_part2--->|
|<---ACPI DATA--->|
|<---ACPI NVS--->|
---2G---
after:
|<---low_1M--->|
|<---hpa1_low_part1--->|
|<---SSRAM--->|
|<---hpa1_low_part2--->|
|<---GPU_OpRegion--->|
|<---ACPI DATA--->|
|<---ACPI NVS--->|
---2G---
Tracked-On: #6674
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
The length of the ACPI data entry in ve820 tab was 960K, while the
ACPI file is 1MB. It causes the ACPI file copy failed due to reserved
ACPI regions in ve820 table is not enough when loading pre-launched
VMs. This patch changes ACPI data area to 1MB to fix the problem.
And the ACPI data length was missed when calculating
ENTRY_HPA1_LOW_PART2 length. Fixed here too.
Also adds some refinement to the hard-coded ACPI base/addr definations
Tracked-On: #6674
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Address of software SRAM configured by TCC tool shall be
page-aligned. This patch fixup these addresses if they're
not page aligned.
Tracked-On: #6778
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
The config of MAX_EFI_MMAP_ENTRIES has been removed in hypervisor, so remove
this config in config_tools;
Tracked-On: #6442
Signed-off-by: Victor Sun <victor.sun@intel.com>
Previously we prepared 32KB buffer to store guest VM boot parameters, in which
there is at most 17KB buffer for guest EFI memory map to accomodate ~400 EFI
memory descriptors. But this is uncertain to ensure working on all boards, now
change the algorithm that make the EFI mmap buffer adaptable with configured
MAX_EFI_MMAP_ENTRIES macro.
Tracked-On: #6442
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
In previous implementation we leave MAX_EFI_MMAP_ENTRIES in config tool and
let end user to configure it. However it is hard for end user to understand
how to configure it, also it is hard for board_inspector to get this value
automatically because this info is only meaningful during the kernel boot
stage and there is no such info available after boot in Linux toolset.
This patch hardcode the value to 350, and ASSERT if the board need more efi
mmap entries to run ACRN. User could modify the MAX_EFI_MMAP_ENTRIES macro
in case ASSERT occurs in DEBUG stage.
The More size of hv_memdesc[] only consume very little memory, the overhead
is (size * sizeof(struct efi_memory_desc)), i.e. (size * 40) in bytes.
Tracked-On: #6442
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
when we click the "Import XML" button to import the scenario xml file, then
click the "Export XML" to export the xml files, we will find some errors because
UI don't show the default value set in schema.
As a workaround, we call default_populator.py in UI to expand the default value
in the scenario XML file to fix the issue.
Tracked-On: #6292
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
The coding guideline rules C-TY-27 and C-TY-28, combined, requires that
assignment and arithmetic operations shall be applied only on operands of the
same kind. This patch either adds explicit type casts or adjust types of
variables to align the types of operands.
The only semantic change introduced by this patch is the promotion of the
second argument of set_vmcs_bit() and clear_vmcs_bit() to
uint64_t (formerly uint32_t). This avoids clear_vmcs_bit() to accidentally
clears the upper 32 bits of the requested VMCS field.
Other than that, this patch has no semantic change. Specifically this patch
is not meant to fix buggy narrowing operations, only to make these
operations explicit.
Tracked-On: #6776
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The coding guideline rule C-TY-24 requires that 'cast shall not be
performed on a function pointer'. This patch removes a duplicated explicit
cast on timer_expired_handler in tsc_deadline_timer.c.
This patch has no semantic impacts.
Tracked-On: #6776
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The coding guideline rule C-TY-12 requires that 'all type conversions shall
be explicit'. Especially implicit cases on the signedness of variables
shall be avoided.
This patch either adds explicit type casts or adjust local variable types
to make sure that Booleans, signed and unsigned integers are not used
mixedly.
This patch has no semantic changes.
Tracked-On: #6776
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The coding guideline rule C-TY-02 requires that 'the operands of bit
operations shall be unsigned'. This patch adds explicit casts or literal
suffixes to make explicit the type of values involved in bit operations.
Explicit casts to widen integers before shift operations are also
introduced to make explicit that the variables are expanded BEFORE it is
shifted (which is already so in C99 but implicitly).
This patch has no semantic changes.
Tracked-On: #6776
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
