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>
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>
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 creates vm_event support in HV, including:
1. Create vm_event data type.
2. Add vm_event sbuf and its initializer. The sbuf will be allocated by
DM in Service VM. Its page address will then be share to HV through
hypercall.
3. Add an API to send the HV generated event.
Tracked-On: #8547
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Currently ivshmem device can only be configurated as single function
device(bdf.f = 0) on bus 0. This greatly limits the number of ivshmem
devices we can create. This patch is to enable multiple function bit in
HEADER_TYPE config register, so that we can create many more ivshmem
devices by using different function numbers on one bus:dev.
The multi function device bit is to be set on ivshmem devices whose function
number equls 0. PCI spec describe it as: ‘When Set, indicates that the
Device may contain multiple Functions, but not necessarily.’, So if this
dev is the only one on the bus:dev, it is still OK.
Tracked-On: #8520
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Per BVT (Borrowed Virtual Time) scheduler design, following per thread
parameters are required to tune scheduling behaviour.
- weight
The time sharing of a thread on CPU.
- warp
Boost value of virtual time of a thread (time borrowed from future) to
reduce Effective Virtual Time to prioritize the thread.
- warp_limit
Max warp time in one warp.
- unwarp_period
Min unwarp time after a warp.
As of now, only weight is in use to tune virtual time ratio of VCPU
threads from different VMs. Others parameters are for future extension.
Tracked-On: #8500
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
Add four per-vm bvt parameters as the initial bvt parameter values for
vCPU threads.
- bvt_weight
The time sharing of a thread on CPU.
- bvt_warp_value
Boost value of virtual time of a thread (time borrowed from future) to
reduce Effective Virtual Time to prioritize the thread.
- bvt_warp_limit
Max warp time in one warp.
- bvt_unwarp_period
Min unwarp time after a warp.
Tracked-On: #8500
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
Abstract out schedulers config data for vCPU threads and other hypervisor
threads to sched_params structure. And it's used to initialize per
thread scheduler private data. The sched_params for vCPU threads come
from vm_config generated by config tools while other hypervisor threads
need give them explicitly.
Tracked-On: #8500
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
make_request sets the request bit, and signal_event wakes the vcpu
thread. If we signal_event comes first, the target vCPU has a chance to
sleep again before processing the request bit.
Tracked-On: #8507
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
When all vCPU threads on one pCPU are put to sleep (e.g., when all
guests execute HLT), hv would schedule to idle thread. Currently the
idle thread executes PAUSE which does not enter any c-state and consumes
a lot of power. This patch is to support HLT in the idle thread.
When we switch to HLT, we have to make sure events that would wake a
vCPU must also be able to wake the pCPU. Those events are either
generated by local interrupt or issued by other pCPUs followed by an
ipi kick.
Each of them have an interrupt involved, so they are also able to wake
the halted pCPU. Except when the pCPU has just scheduled to idle thread
but not yet halted, interrupts could be missed.
sleep-------schedule to idle------IRQ ON---HLT--(kick missed)
^
wake---kick|
This areas should be protected. This is done by a safe halt
mechanism leveraging STI instruction’s delay effect (same as Linux).
vCPUs with lapic_pt or hv with CONFIG_KEEP_IRQ_DISABLED=y does not allow
interrupts in root mode, so they could never wake from HLT (INIT kick
does not wake HLT in root mode either). They should continue using PAUSE
in idle.
Tracked-On: #8507
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
When bvt scheduler picks up a thread to run, it sets up a counter
‘run_countdown’ to determine how many ticks it should remain running.
Then the timer will decrease run_countdown by 1 on every 1000Hz tick
interrupt, until it reaches 0. The tick interrupt consumes a lot of
power during idle (if we are using HLT in idle thread).
This patch is to switch the 1000 HZ timer to a dynamic one, which only
interrupt on run_countdown expires.
Tracked-On: #8507
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
ACRN boot fails when size of ivshmem device is
configured to 512MB, this patch allocates this memory
from E820 table instead of reserving in hypervisor.
Tracked-On: #8502
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
~0UL is widely used to specify the maximum memory size
when calling e820_alloc_memory(), this patch to define
a MACRO for it to avoid using this magic number.
Tracked-On: #8502
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
For a pdev which allocated to prelaunched VM or owned by HV, we need to check
whether it is a multifuction dev at function 0. If yes we have to emulate a
dummy function dev in Service VM, otherwise the sub-function devices will be
lost in guest OS pci probe process.
Tracked-On: #8492
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
Signed-off-by: Victor Sun <victor.sun@intel.com>
When we do init_all_dev_config() in pci.c, the pdevs added to pci dev_config
will be exposed to Service VM or passthru to prelauched VM. The original code
would find service VM config in every pci pdev init loop, this is unnecessary
and definitely impact performance. Here we generate Service VM config pointer
with config tool so that init_one_dev_config() could refer service VM config
directly.
Tracked-On: #8491
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
Signed-off-by: Victor Sun <victor.sun@intel.com>
Rename is_allocated_to_prelaunched_vm to allocate_to_prelaunched_vm as
it not only checks whether the PCI device is allocated to a Pre-launched
VM but also associate it with Pre-launched VM's dev_config.
Tracked-On: #8491
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
On some platforms, the last e820 entry may not be of type E820_TYPE_RAM,
such as E820_TYPE_ACPI_NVS which may also be used by Service VM.
So we need take all e820 entry types into account when finding the upper
bound of Service VM EPT mapping.
Tracked-On: #8495
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
The ivshmem spec define the BAR0 offset > 16 are reserved.
So ACRN need ignore all operation when offset out of range.
Tracked-On: #8487
Signed-off-by: Zhang Chen <chen.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Add the ivshmem_dev_lock to protect races between release
and allocations.
Tracked-On: ##8486
Signed-off-by: Zhang Chen <chen.zhang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
ACRN sets the ivposition to the VM_ID in ivshmem_server_bind_peer().
This value should be saved in the ivshmem_device until unbind.
It is wrong to clear ivs_dev->mmio in the ivshmem_vbar_map(),
Instead, it should clear the ivshmem_device structure in the
create_ivshmem_device to ensure the same initial states
after VM reboot case.
Tracked-On: #8485
Signed-off-by: Zhang Chen <chen.zhang@intel.com>
Reviewed-by: Junjie Mao <Junjie.mao@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>
The Hardware Feedback Interface (HFI) and Intel® Thread Director (ITD)
features require OS to provide a physical page address to
IA32_HW_FEEDBACK_PTR. Then the hardware will update the processor
information to the page address. The issue is that guest VM will program
its GPA to that MSR, causing great risk of tempering memory.
So HFI and ITD should be made invisible to guests, until we provide
proper virtulization of those features.
Tracked-On: #8463
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
arch/x86/guest/nested.c, where nested_vmexit_handler() is defined, is
only compiled when CONFIG_NVMX_ENABLED is enabled. Define a dummy
function in include/arch/x86/asm/guest/nested.h to fix the undefined
reference linker error.
Tracked-On: #8465
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
ffs64() returns INVALID_BIT_INDEX (0xffffU) when it tries to deal with
zero input value. This may happen In calculate_logical_dest_mask() when
the guest tries to write some illegal destination IDs to MSI config
registers of a pt-device. The ffs64() return value is used as per_cpu
array index, and it would cause a page fault.
This patch adds protection to the per_cpu array, making this function
return zero on illegal value. As in logical destination's definition, a
zero logical designation would point to no CPU.
Fixes: 89d11d91e
Tracked-On: #8454
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
According to SDM Vol3 11.12.10, in x2APIC mode, Logical Destination has
two parts:
- Cluster ID (LDR[31:16])
- Logical ID (LDR[15:0])
Cluster ID is a numerical address, while Logical ID is a 16bit mask. We
can only use Logical ID to address multi destinations within a Cluster.
So we can't just 'or' all the Logical Destination in LDR registers to
get one mask for all target pCPUs. This would get a wrong destination
mask if the target Destinations are from different Clusters.
For example in ADL/RPL x2APIC LDRs for core 2-5 are 0x10001 0x10100
0x20001 0x20100. If we 'or' them together, we would get a Logical
Destination of 0x30101, which points to core 6 and another core.
If core 6 is running a RTVM, then the irq is unable to get to
core 2-5, causing the guest on core 2-5 driver fail.
Guests working in xAPIC mode may use 'Flat Model' to select an
arbitrary list of CPUs as its irq destination. HV may not be able to
include them all when transfering to physical destinations, because
the HW is working in x2APIC mode and can only use 'Cluster Model'.
There would be no perfect fix for this issue. This patch is a simple
fix, by just keep the first Cluster of all target Logical Destinations.
Tracked-On: #8435
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
On x86 platform, the upper 16 bit of I/O BAR should be initialized to
zero by BIOS. Howerever, some buggy BIOS still programs the upper 16
bits to non-zero, which causes error in check_pt_dev_pio_bars(). Since
I/O BAR reprogramming by VM is currently unsupported, this patch
ignores such I/O BARs when creating vpci devices to make VM boot.
Tracked-On: #8373
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Guests bootloader may read MSR_PLATFORM_INFO to get TSC frequency for
time measurement, so injecting #GP on read may crash the vm on boot.
This patch emulates MSR_PLATFORM_INFO with 0, same behavior in kvm, to
tell the guest it's a virtualized environment.
Tracked-On: #8406
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Thermal events are delivered through lapic thermal LVT. Currently
ACRN does not support delivering those interrupts to guests by
virtual lapic. They need to be virtualized to provide guests some
thermal management abilities. Currently we just hide thermal
lvt from guests, including:
1. Thermal LVT:
There is no way to hide thermal LVT from guests. But we need do
something to make sure no interrupt can be actually trigered:
- skip thermal LVT in vlapic_trigger_lvt()
- trap-and-emulate thermal LVT in lapic-pt mode
2. As We have plan to introduce virtualization of thermal monitor in the
future, we use a vm flag GUEST_FLAG_VTM which is default 0 to control
the access to it. So that it can help enabling VTM in the future.
Tracked-On: #8414
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
When VHWP enabled, return 0 and px_cnt = 0 on ACRN_PMCMD_GET_PX_CNT,
so that DM will write _CPC to guests' ACPI.
Tracked-On: #8414
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Changes made by this patch includes:
1. Emulate HWP and pstate MSRs/CPUIDs. Those are exposed to guest when
the GUEST_FLAG_VHWP is set:
- CPUID[6].EAX[7,9,10]: MSR_IA32_PM_ENABLE(enabled by hv, always read
1), MSR_IA32_HWP_CAPABILITIES, MSR_IA32_HWP_REQUEST,
MSR_IA32_HWP_STATUS,
- CPUID[6].ECX[0]: MSR_IA32_MPERF, MSR_IA32_APERF
- MSR_IA32_PERF_STATUS(read as base frequency when not owning pCPU)
- MSR_IA32_PERF_CTL(ignore writes)
2. Always hide HWP interrupt and package control MSRs/CPUIDs:
- CPUID[6].EAX[8]: MSR_IA32_HWP_INTERRUPT(currently ACRN is not able
to deliver thermal LVT virtual interrupt to guests)
- CPUID[6].EAX[11,22]: MSR_IA32_HWP_REQUEST_PKG, MSR_IA32_HWP_CTL
Tracked-On: #8414
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Currently CPU frequency control is hidden to guests, and controlled
by hypervisor. While it is sufficient in most cases, some guest OS may
still need CPU performance info to make multi-core scheduling decisions.
This is seen on Linux kernel, which uses HWP highest performance level
as CPU core's priority in multi-core scheduling (CONFIG_SCHED_MC_PRIO).
Enabling this kernel feature could improve performance as single thread
workloads are scheduled on the highest performance cores. This is
significantly useful for guests with hybrid cores.
The concept is to expose performance interface to guest who exclusively
owns pCPU assigned to it. So that Linux guest can load intel_pstate
driver which will then provide the kernel with each core's schedule
priority.
Intel_pstate driver also relies on CONFIG_ACPI_CPPC_LIB to implement
this mechanic, this means we also need to provide ACPI _CPC in DM.
This patch sets up a guest flag GUEST_FLAG_VHWP to indicate whether
the guest can have VHWP feature.
Tracked-On: #8414
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
This patch refactors partition_epc() to make the code easier to
understand, also fixes the maybe-uninitialized warning for gcc-13.
Initializing 'vm_config' to get_vm_config(0) is okay here as scenario
validator ensures CONFIG_MAX_VM_NUM to be always larger than 0.
Tracked-On: #8413
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
This patch emulates the PLATFORM_INFO MSR in hypervisor to make it
only visible to Service VM, and only processor ratios (bit 15:8,
47:40 and 55:48) and sample part bit (27) are exponsed. This is
intended to prevent Service VM from changing processor parameters
like turbo ratio.
Tracked-On: #8406
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
When assigning a physical interrupt to a Post-launched VM, if it has
been assigned to ServiceVM, we should remove that mapping first to reset
ioapic pin state and rte, and build new mapping for the Post-launched
VM.
Tracked-On: #8370
Signed-off-by: Qiang Zhang <qiang4.zhang@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
ptirq_remapping_info records which physical interrupt is mapped to
the virtual interrupt in a VM. As we need to knonw whether a physical
sid has been mapped to a VM and whether a virtual sid in a VM has been
used, there should be two hash tables to link and iterate
ptirq_remapping_info:
- One is used to lookup from physical sid, linking phys_link.
- The other is used to lookup from virtual sid in a VM, linking virt_link
Without this patch, phys_link or virt_link from different
ptirq_remapping_info was linked by one hash list head if they got the
same hash value, as shown in following diagram.
When looking for a ptirq_remapping_info from physical sid, the original
code took all hash list node as phys_link and failed to get
ptirq_remapping_info linked with virt_link and later references
to its members are wrong.
The same problem also occurred when looking for a ptirq_remapping_info
from virtual sid and vm.
---------- <- hash table
|hlist_head| --actual ptirq_remapping_info address
---------- --------- / --used as ptirq_remapping_info
| ... | |phys_link| ___/
---------- --------- --------- / ---------
|hlist_head| -> |phys_link| <-> |virt_link| <-> |phys_link|
---------- --------- --------- ---------
| ... | |virt_link| | other | |virt_link|
---------- --------- | members | ---------
| other | --------- | other |
| members | | members |
--------- ---------
Tracked-On: #8370
Signed-off-by: Qiang Zhang <qiang4.zhang@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
to enable early print output by pci uart, which has mmio address
above 4G, add the early pagetable map for the MMIO range.
we make an assumption that only map it with 2MB page, since platform
with 39bit memory width have no 1G huge page feature and we cannot
get the capacity at runtime, since it is a very early code stage.
v2->v1:
1. add hva2hpa_early
2. add process when *pdpte is not present
Signed-off-by: hangliu1 <hang1.liu@linux.intel.com>
Reviewed-by: fei1.li <fei1.li@intel.com>
Tracked-On: #6690
The version info is mainly used to tell the user when and where the binary is
compiled and built, this will change the hv version format.
The hv follows the format:
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 '(tag-current_commit_id)' is optional, it exits only when there are
tags for current commit.
e.g.
with tag:
ACRN:\>version
HV: 3.1-stable-release_3.1-2022-09-27-11:15:42-7fad37e02-dirty DBG(tag: v3.1)
scenario3.1@my_desk_3.1 build by zhangwei 2022-11-16 07:02:37
without tag:
ACRN:\>version
HV: 3.2-unstable-master-2022-11-16-14:34:49-11f53d849-dirty DBG
scenario3.1@my_desk_3.1 build by zhangwei 2022-11-16 06:49:44
Tracked-On #8303
Signed-off-by: Zhangwei6 <wei6.zhang@intel.com>
When CPU support MONITOR/MWAIT, OS prefer to use it enter
deeper C-state.
Now ACRN pass through MONITOR/MWAIT to guest.
For vCPUs (ie vCPU A and vCPU B) share a pCPU, if vCPU A uses MWait to enter C state,
vCPU B could run only after the time slice of vCPU A is expired. This time slice of
vCPU A is gone to waste.
For Local APIC pass-through (used for RTVM), the guest pay more attention to
timeliness than power saving.
So this patch hides MONITOR/MWAIT by:
1. Clear vCPUID.05H, vCPUID.01H:ECX.[bit 3] and
MSR_IA32_MISC_ENABLE_MONITOR_ENA to tell the guest VM's vCPU
does not support MONITOR/MAIT.
2. Enable MSR_IA32_MISC_ENABLE_MONITOR_ENA bit for
MSR_IA32_MISC_ENABLE inject 'GP'.
3. Trap instruction 'MONITOR' and 'MWAIT' and inject 'UD'.
4. Clear vCPUID.07H:ECX.[bit 5] to hide 'UMONITOR/UMWAIT'.
5. Clear "enable user wait and pause" VM-execution control, so
UMONITOR/MWAIT causes an 'UD'.
Tracked-On: #8253
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@linux.intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Exclude "GUEST_FLAG_PMU_PASSTHROUGH" from DM_OWNED_GUEST_FLAG_MASK
in case device model rewrite the value in release mode, reserve it
in debug mode.
Signed-off-by: hangliu1 <hang1.liu@linux.intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Tracked-On:#6690
The current code would write 'BAR address & size_maks' into PCIe virtual
BAR before updating the virtual BAR's base address when guest writing a
PCIe device's BAR. If the size of a PCIe device's BAR is larger than 4G,
the low 32 bits size_mask for this 64 bits BAR is zero. When ACRN updating
the virtual BAR's base address, the low 32 bits sizing information would
be lost.
This patch saves whether a BAR writing is sizing or not before updating the
virtual BAR's base address.
Tracked-On: #8267
Signed-off-by: Fei Li <fei1.li@intel.com>
The targets "clean" and "distclean" are special as they do not need BOARD
or SCENARIO from users. This patch stops the guesswork of BOARD and
SCENARIO if any of those two targets are specified.
It is assumed that "clean" or "distclean" is not invoked with other targets
at the same time.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
In the current config.mk board and scenario XMLs are only copied to the
build directory when they do not exist. That prevents users from using XML
files they have edited, probably to fix previously reported validation
errors, for a rebuild unless the former build directory is totally removed.
This patch adds the user-given paths to XML files (if they exist) as
dependencies of the copied files in the build directory, so that users can
now provide new board and/or scenario XMLs to an existing build to
automatically trigger a complete rebuild.
Building without explicitly specifying BOARD and SCENARIO is still
supported if a build directory already exists. In that case the copied
board and scenario XMLs will not be modified.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
ACRN config tools generate source files, scripts and binaries based on
users' inputs in the configurations files, i.e., board and scenario
XMLs. Those generation activities all assume that users' inputs are
properly validated, so that all assumptions they have on such inputs are
hold.
Unfortunately, not all dependencies on validated user inputs are explicitly
stated in the Makefiles today. That will cause random error messages
(typically a Python stack trace) to be printed along with validation errors
when an invalid scenario XML is given, and such messages confuse users
about the root causes of the failure.
This patch decouples scenario validation from genconf.sh and make that step
as a separate target that depends on the board and scenario XMLs. One
timestamp file is generated only when the validation succeeds so that
targets requiring validated XMLs can refer that file in its dependency list
to make it explicit.
Dependencies of the following targets are also updated accordingly:
* $(HV_ALLOCATION_XML), which is the allocation XML including static
allocation results, now also depends on validated XMLs.
* $(HV_CONFIG_TIMESTAMP), which records when the config source files are
generated, now also depends on validated XMLs.
* $(SERIAL_CONF), which is the serial conf for the service VM, depends on
the allocation XML.
By the way, the missing dependency on HV_CONFIG_DIR for touching
HV_DIFFCONFIG_LIST is added to fix the "file not found" issue.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Phony targets are mostly for recipes that are expected to be invoked
directly from the command line as a target and will always be executed. As
a result, it is in most cases not appropriate for a real file target to to
depend on a phony one, as that means the file will always be regenerated.
In the Makefile today, however, dependencies on phony targets are common
and cause the hypervisor to be fully rebuilt regardless of whether an
existing build exists or not.
This patch cleans up the following phony targets which are not meant to be
targets from the command line.
- pre_build: This target has three outputs, namely the prebuild checker,
the ACPI tables for pre-launched VMs and the serial.conf. It is split
into three targets, one for each output.
- headers: This target is an alias of dynamically-generated header
files. It is replaced with a variable so that targets depending on
"header" now depends on the actual header files generated.
With this patch, make will only rebuild modified files and targets
depending on them directly or indirectly.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The target "default" in hypervisor/Makefile is just an alias of the target
"all" in order to make "all" being the default goal. This patch replaces
that duplicate target and specifies the default goal by defining the
variable .DEFAULT_GOAL instead.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
