doc: update param spelling from VM to vm #2
Merged
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
doxygen comments for @param VM must match the actual parameter name vm (lowercase) Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
gvancuts
referenced
this pull request
in gvancuts/acrn-hypervisor
Apr 4, 2018
Merge latest changes from Intel
yonghuah
added a commit
to yonghuah/acrn-hypervisor
that referenced
this pull request
Oct 25, 2018
route GSI number#2 to PIC IRQ#0, as by default IRQ for 8254 timer is connected to I/O APIC Pin projectacrn#2 and PIC Pin #0 Tracked-On projectacrn#861 Signed-off-by: Yonghua Huang <yonghua.huang@intel.com> Reviewed-by: Eddie Dong <eddie.dong@intel.com> Acked-by: Anthony Xu <anthony.xu@intel.com>
yonghuah
added a commit
to yonghuah/acrn-hypervisor
that referenced
this pull request
Oct 25, 2018
route GSI number#2 to PIC IRQ#0, as by default IRQ for 8254 timer is connected to I/O APIC Pin projectacrn#2 and PIC Pin #0 Tracked-On projectacrn#861 Signed-off-by: Yonghua Huang <yonghua.huang@intel.com> Reviewed-by: Eddie Dong <eddie.dong@intel.com> Acked-by: Anthony Xu <anthony.xu@intel.com>
yonghuah
added a commit
to yonghuah/acrn-hypervisor
that referenced
this pull request
Oct 25, 2018
route GSI number#2 to PIC IRQ#0, as by default IRQ for 8254 timer is connected to I/O APIC Pin projectacrn#2 and PIC Pin #0 Tracked-On: projectacrn#861 Signed-off-by: Yonghua Huang <yonghua.huang@intel.com> Reviewed-by: Eddie Dong <eddie.dong@intel.com> Acked-by: Anthony Xu <anthony.xu@intel.com>
Merged
Merged
KaigeFu
added a commit
to KaigeFu/acrn-hypervisor
that referenced
this pull request
Jul 31, 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 projectacrn#1, commit "a958fea hv: emulate IA32_TSC_ADJUST MSR" has implementation
it. And for projectacrn#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 <kaige.fu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
acrnsi
pushed a commit
that referenced
this pull request
Jul 31, 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: #3501
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This was referenced Oct 22, 2019
This was referenced Aug 10, 2021
This was referenced Oct 25, 2021
This was referenced Nov 2, 2021
yonghuah
added a commit
to yonghuah/acrn-hypervisor
that referenced
this pull request
Feb 21, 2022
'mevent_lmutex' is initialized as default type 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: projectacrn#1 in mevent_qlock () at core/mevent.c:93 projectacrn#2 in mevent_delete_even at core/mevent.c:357 ===>Recursively LOCK projectacrn#3 in mevent_delete_close at core/mevent.c:387 projectacrn#4 in acrn_timer_deinit at core/timer.c:106 projectacrn#5 in virtio_reset_dev at hw/pci/virtio/virtio.c:171 projectacrn#6 in virtio_console_reset at hw/pci/virtio/virtio_console.c:196 projectacrn#7 in virtio_console_destroy at hw/pci/virtio/virtio_console.c:1015 projectacrn#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 projectacrn#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 <yonghua.huang@intel.com> Acked-by: Yu Wang <yu1.wang@intel.com>
yonghuah
added a commit
to yonghuah/acrn-hypervisor
that referenced
this pull request
Feb 21, 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: projectacrn#1 in mevent_qlock () at core/mevent.c:93 projectacrn#2 in mevent_delete_even at core/mevent.c:357 ===>Recursively LOCK projectacrn#3 in mevent_delete_close at core/mevent.c:387 projectacrn#4 in acrn_timer_deinit at core/timer.c:106 projectacrn#5 in virtio_reset_dev at hw/pci/virtio/virtio.c:171 projectacrn#6 in virtio_console_reset at hw/pci/virtio/virtio_console.c:196 projectacrn#7 in virtio_console_destroy at hw/pci/virtio/virtio_console.c:1015 projectacrn#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 projectacrn#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 <yonghua.huang@intel.com> Acked-by: Yu Wang <yu1.wang@intel.com>
acrnsi-robot
pushed a commit
that referenced
this pull request
Feb 21, 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 #9 in mevent_drain_del_list () at core/mevent.c:348 ===> 1st LOCK #10 in mevent_dispatch () at core/mevent.c:472 #11 in main at core/main.c:1110 So the root cause is: mevent_mutex lock is recursively locked by mevent thread itself (#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: #7133 Signed-off-by: Yonghua Huang <yonghua.huang@intel.com> Acked-by: Yu Wang <yu1.wang@intel.com>
liuhang-bit
pushed a commit
to liuhang-bit/acrn-hypervisor
that referenced
this pull request
Feb 28, 2022
add dp4 enabling patch for r2.5
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.
doxygen comments for @param VM must match the actual parameter name vm
(lowercase)
Signed-off-by: David B. Kinder david.b.kinder@intel.com