Travis test #1
Closed
Travis test #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix a couple of wrong assignments to D_SRCS and C_SRCS. Signed-off-by: Geoffroy Van Cutsem <[email protected]>
Add 'CPU_PAGE_MASK' used for calculate address, Change IA32E_REF_MASK from 0x7ffffffffffff000 to 0x000ffffffffff000 for MMU/EPT entry, bit62:52(ignore) bit63(VE/XD) if we want to obtain the address from the MMU/EPT entry,need to clear bit63:52 by IA32E_REF_MASK Signed-off-by: Mingqiang Chi <[email protected]>
1. refine multiboot related code, move to /boot. 2. firmware files and ramdisk can be stitched in iasImage; and they will be loaded as multiboot modules. Signed-off-by: Minggui Cao <[email protected]>
the variable 'table_present' is redundant in function(map_mem_region) Signed-off-by: Mingqiang Chi <[email protected]>
…ails in vmresume It is possible that the vm-entry fails in vmresume instr under some scenarios. It will pass to next instruction following vmresume. In such case it will call the vmlaunch again. Signed-off-by: Zhao Yakui <[email protected]>
info->phys_pin need be used by ptdev_build_native_rte when updating entry TODO: currently ptdev entry is virtual based, the better solution should be physical based. Signed-off-by: Jason Chen CJ <[email protected]>
According to the explaination for pref_address in Documentation/x86/boot.txt, a relocating bootloader should attempt to load kernel at pref_address if possible. But due to a non-relocatable kernel will unconditionally move itself and to run at perf address, no need to copy kernel to perf_address by bootloader. Signed-off-by: Zheng, Gen <[email protected]>
rename 'PT_HOST' to 'PTT_HOST' rename 'PT_EPT' to 'PTT_EPT' rename 'ept_type' to 'table_type' Signed-off-by: Mingqiang Chi <[email protected]>
If you build for a platform (e.g. uefi) and right after that for
another platform ('sbl'), the new build will fail and a version.h
file is left in the tree (bsp/uefi/include/bsp/version.h or
bsp/sbl/include/bsp/version.h depending on the order you built one
after the other). This commit makes git ignore any of those in case
it is there. Note that 'make clean' with the corresponding
PLATFORM variable will clean this file.
Signed-off-by: Geoffroy Van Cutsem <[email protected]>
we added uefi stub for hv, and want vm0 continue running under uefi env to boot other uefi payload (osloader or bzImage). during this, the uefi timer irq need be handled elegantly. there are 3 types for uefi timer: 1. 8254 based on IRQ0 of PIC 2. HPET based on IOAPIC 3. HPET based on MSI currently, we only support type 3 (HPET+MSI). But we are following a in-correct flow to handle this timer interrupt: - we set VMX_ENTRY_INT_INFO_FIELD directly if a timer interrupt happened before vcpu launching, this will make its vlapic mess up, which finally cause hpet timer stop. this patch remove this in-correct approach, the new approach patch will be followed by next patch. Signed-off-by: Jason Chen CJ <[email protected]>
this patch save native lapic configuration and restore it to vm0's vlapic before its running, then doing hpet timer interrupt injection through vlapic interface -- this will not mess up vlapic and we can see hpet timer interrupt coming continuously. Signed-off-by: Jason Chen CJ <[email protected]>
Signed-off-by: Li, Fei1 <[email protected]>
Enable the Travis CI testing for all combinations of variables
that can be set at compile-time. I.e. RELEASE={0|1} and
PLATFORM={0|1}
Signed-off-by: Geoffroy Van Cutsem <[email protected]>
gvancuts
pushed a commit
that referenced
this pull request
May 9, 2018
makefile: install the demo scripts
gvancuts
pushed a commit
that referenced
this pull request
Aug 22, 2019
The policy of vART is that software in native can run in
VM too. And in native side, the relationship between the
ART hardware and TSC is:
pTSC = (pART * M) / N + pAdjust
The vART solution is:
- Present the ART capability to guest through CPUID leaf
15H for M/N which identical to the physical values.
- PT devices see the pART (vART = pART).
- Guest expect: vTSC = vART * M / N + vAdjust.
- VMCS.OFFSET = vTSC - pTSC = vAdjust - pAdjust.
So to support vART, we should do the following:
1. if vAdjust and vTSC are changed by guest, we should change
VMCS.OFFSET accordingly.
2. Make the assumption that the pAjust is never touched by ACRN.
For #1, commit "a958fea hv: emulate IA32_TSC_ADJUST MSR" has implementation
it. And for #2, acrn never touch pAdjust.
--
v2 -> v3:
- Add comment when handle guest TSC_ADJUST and TSC accessing.
- Initialize the VMCS.OFFSET = vAdjust - pAdjust.
v1 -> v2
Refine commit message to describe the whole vART solution.
Tracked-On: projectacrn#3501
Signed-off-by: Kaige Fu <[email protected]>
Acked-by: Eddie Dong <[email protected]>
gvancuts
pushed a commit
that referenced
this pull request
Apr 8, 2020
value among RDT resources. This patch identifies the least common supported clos value from multiple RDT resource. This is done so as to have consistent capabilities across all resource allocations. From SDM, "The number of CLOS supported for the MBA feature may or may not align with other resources such as L3 CAT. In cases where the RDT features support different numbers of CLOS the lowest numerical CLOS support the common set of features, while higher CLOS may support a subset. For instance, if L3 CAT supports 8 CLOS while MBA supports 4 CLOS, all 8 CLOS would have L3 CAT masks available for cache control, but the upper 4 CLOS would not offer MBA support. In this case the upper 4 CLOS would not be subject to any throttling control. Software can manage supported resources / CLOS in order to either have 1) consistent capabilities across CLOS by using the common subset or 2) enable more flexibility by selectively applying resource control where needed based on careful CLOS and thread mapping". We decided to go with option #1, as it will be more consistent and less prone to user errorw hen programming the resource mask MSRs. Tracked-On: projectacrn#3715 Signed-off-by: Vijay Dhanraj <[email protected]> Acked-by: Victor Sun <[email protected]>
gvancuts
pushed a commit
that referenced
this pull request
Aug 20, 2020
OpRegion: 8KB(0x2000) [ OpRegion Header ] Offset: 0x0 [ Mailbox #1: ACPI ] Offset: 0x100 [ Mailbox #2: SWSCI ] Offset: 0x200 [ Mailbox #3: ASLE ] Offset: 0x300 [ Mailbox #4: VBT ] Offset: 0x400 [ Mailbox #5: ASLE EXT ] Offset: 0x1C00 Extended OpRegion: 8KB(0x2000) [ Raw VBT ] Offset: 0x0 Generally VBT stores in MailBox4 in OpRegion which max size is 6KB. If VBT larger than 6KB, it will be stored in extended OpRegion which is neighborhood with legacy OpRegion. In this case, we need to passthrough extended OpRegion also to support GVT-d feature. The OpRegion size that we passthrough should be (OpRegion+Extended)=16KB ASLE.rvda stores the location of VBT. For OpRegion 2.1+: ASLE.rvda = offset to OpRegion base address For OpRegion 2.0: ASLE.rvda = physical address To-do: Add support for OpRegion on some platforms(eg. APL) Tracked-On: projectacrn#5029 Signed-off-by: Sun Peng <[email protected]>
gvancuts
pushed a commit
that referenced
this pull request
Oct 26, 2021
In commit of 7cc9c8f the pre-launched VM was set to ACPI HW Reduced platform, then the IRQ would be allocated from 0 for PCI MSI devices. The Intel igb/igc driver might get IRQ 8 when do request irq which would conflict with the irq of RTC device: [ 14.264954] genirq: Flags mismatch irq 8. 00000000 (enp0s8-TxRx-3) vs. 00000000 (rtc0) [ 14.265411] ------------[ cut here ]------------ [ 14.265508] kernel BUG at drivers/pci/msi.c:376! [ 14.265610] invalid opcode: 0000 [#1] PREEMPT SMP [ 14.265710] CPU: 0 PID: 296 Comm: connmand Not tainted 5.10.52-acrn-sos -dirty projectacrn#72 [ 14.265863] RIP: 0010:free_msi_irqs+0x182/0x1b0 This patch will specify some legacy PnP device like UART and RTC in ACPI DSDT table of pre-launched VM, so that IRQs from IOAPIC pin 4/3/8 could be preserved before MSI device requesting IRQs. Tracked-On: projectacrn#6704 Signed-off-by: Victor Sun <[email protected]>
gvancuts
pushed a commit
that referenced
this pull request
Mar 10, 2022
'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 projectacrn#9 in mevent_drain_del_list () at core/mevent.c:348 ===> 1st LOCK projectacrn#10 in mevent_dispatch () at core/mevent.c:472 projectacrn#11 in main at core/main.c:1110 So the root cause is: mevent_mutex lock is recursively locked by mevent thread itself (projectacrn#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: projectacrn#7133 Signed-off-by: Yonghua Huang <[email protected]> Acked-by: Yu Wang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.