Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SOS force reboot while launching vxworks #6799

Closed
fuzhongl opened this issue Nov 9, 2021 · 1 comment
Closed

SOS force reboot while launching vxworks #6799

fuzhongl opened this issue Nov 9, 2021 · 1 comment
Assignees
Labels
status: new The issue status: new for creation

Comments

@fuzhongl
Copy link
Contributor

fuzhongl commented Nov 9, 2021

Steps:

  1. Launch shared scenario.
  2. Generate rt script, in virtio-blk event using vxwork img directory instead.
  3. launch vxworks.

Expected result:
Launch vxworks successfully.

Actual result:
Platform force rebooted:

init virtio-blk\x0d
12,1041,17164969807,-;acrn_dm: pci init virtio-net\x0d
6,1042,17164969877,-;acrn-br0: port 3(tap_rt) entered blocking state
6,1043,17164969878,-;acrn-br0: port 3(tap_rt) entered forwarding state
12,1044,17164969921,-;acrn_dm: tpm: init_vtpm2:Invalid socket path!
12,1045,17165034012,-;acrn_dm: acrn_sw_load
12,1046,17165034365,-;acrn_dm: add_cpu
12,1047,17165189367,-;acrn_dm: out instr on NMI port (0x61) not supported
12,1048,17165189454,-;acrn_dm: out instr on NMI port (0x61) not supported
12,1049,17165244391,-;acrn_dm: out instr on NMI port (0x61) not supported
12,1050,17170973722,-;acrn_dm: out instr on NMI port (0x61) not supported
12,1051,17171023753,-;acrn_dm: out instr on NMI port (0x61) not supported
[17194017884us][cpu=8][vm2:vcpu0][sev=3][seq=362]:vlapic: Start Secondary VCPU1 for VM[2]...

@fuzhongl fuzhongl added the status: new The issue status: new for creation label Nov 9, 2021
shiqingg added a commit to shiqingg/acrn-hypervisor that referenced this issue Nov 11, 2021
Commit cbf3825 "hv: Pass-through IA32_TSC_AUX MSR to L1 guest"
lets guest own the physical MSR IA32_TSC_AUX and does not handle this MSR
in the hypervisor.
If multiple vCPUs share the same pCPU, when one vCPU reads MSR IA32_TSC_AUX,
it may get the value set by other vCPUs.

To fix this issue, this patch does:
 - initialize the MSR content to 0 for the given vCPU, which is consistent with
   the value specified in SDM Vol3 "Table 9-1. IA-32 and Intel 64 Processor
   States Following Power-up, Reset, or INIT"
 - save/restore the MSR content for the given vCPU during context switch

v1 -> v2:
 * According to Table 9-1, the content of IA32_TSC_AUX MSR is unchanged
   following INIT, v2 updates the initialization logic so that the content for
   vCPU is consistent with SDM.

Tracked-On: projectacrn#6799
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
@shiqingg
Copy link
Contributor

[External_System_ID] ACRN-7463

shiqingg added a commit to shiqingg/acrn-hypervisor that referenced this issue Nov 11, 2021
Commit cbf3825 "hv: Pass-through IA32_TSC_AUX MSR to L1 guest"
lets guest own the physical MSR IA32_TSC_AUX and does not handle this MSR
in the hypervisor.
If multiple vCPUs share the same pCPU, when one vCPU reads MSR IA32_TSC_AUX,
it may get the value set by other vCPUs.

To fix this issue, this patch does:
 - initialize the MSR content to 0 for the given vCPU, which is consistent with
   the value specified in SDM Vol3 "Table 9-1. IA-32 and Intel 64 Processor
   States Following Power-up, Reset, or INIT"
 - save/restore the MSR content for the given vCPU during context switch

v1 -> v2:
 * According to Table 9-1, the content of IA32_TSC_AUX MSR is unchanged
   following INIT, v2 updates the initialization logic so that the content for
   vCPU is consistent with SDM.

Tracked-On: projectacrn#6799
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
wenlingz pushed a commit that referenced this issue Nov 11, 2021
Commit cbf3825 "hv: Pass-through IA32_TSC_AUX MSR to L1 guest"
lets guest own the physical MSR IA32_TSC_AUX and does not handle this MSR
in the hypervisor.
If multiple vCPUs share the same pCPU, when one vCPU reads MSR IA32_TSC_AUX,
it may get the value set by other vCPUs.

To fix this issue, this patch does:
 - initialize the MSR content to 0 for the given vCPU, which is consistent with
   the value specified in SDM Vol3 "Table 9-1. IA-32 and Intel 64 Processor
   States Following Power-up, Reset, or INIT"
 - save/restore the MSR content for the given vCPU during context switch

v1 -> v2:
 * According to Table 9-1, the content of IA32_TSC_AUX MSR is unchanged
   following INIT, v2 updates the initialization logic so that the content for
   vCPU is consistent with SDM.

Tracked-On: #6799
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
wenlingz pushed a commit that referenced this issue Nov 12, 2021
Commit cbf3825 "hv: Pass-through IA32_TSC_AUX MSR to L1 guest"
lets guest own the physical MSR IA32_TSC_AUX and does not handle this MSR
in the hypervisor.
If multiple vCPUs share the same pCPU, when one vCPU reads MSR IA32_TSC_AUX,
it may get the value set by other vCPUs.

To fix this issue, this patch does:
 - initialize the MSR content to 0 for the given vCPU, which is consistent with
   the value specified in SDM Vol3 "Table 9-1. IA-32 and Intel 64 Processor
   States Following Power-up, Reset, or INIT"
 - save/restore the MSR content for the given vCPU during context switch

v1 -> v2:
 * According to Table 9-1, the content of IA32_TSC_AUX MSR is unchanged
   following INIT, v2 updates the initialization logic so that the content for
   vCPU is consistent with SDM.

Tracked-On: #6799
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
@fuzhongl fuzhongl closed this as completed Dec 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: new The issue status: new for creation
Projects
None yet
Development

No branches or pull requests

2 participants