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

Virtualization will support VxWorks7 64-bit as a GuestVM #3069

Closed
KaigeFu opened this issue May 7, 2019 · 2 comments

Comments

@KaigeFu
Copy link
Contributor

commented May 7, 2019

When configured according to provided documentation, the hypervisor will successfully boot and execute a 64-bit VxWorks7 VM image as a GuestOS.

See Informative section for expected 3rd party engagement to realize this requirement.

@KaigeFu

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

[External_System_ID] ACRN-3532

KaigeFu added a commit to KaigeFu/acrn-hypervisor that referenced this issue May 7, 2019
DM: Add one sample script to launch VxWorks as guest
This patch add one sample script to launch VxWorks as guest.

Tracked-On: projectacrn#3069
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@intel.com>
wenlingz added a commit that referenced this issue May 7, 2019
DM: Add one sample script to launch VxWorks as guest
This patch add one sample script to launch VxWorks as guest.

Tracked-On: #3069
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@intel.com>
KaigeFu added a commit to KaigeFu/acrn-hypervisor that referenced this issue Jun 14, 2019
DM: Samples: Enable VxWorks as hard-rt VM
This patch adds --lapic_pt option to launch VxWorks as hard-rt VM.

Tracked-On: projectacrn#3069
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
KaigeFu added a commit to KaigeFu/acrn-hypervisor that referenced this issue Jun 14, 2019
DM: Samples: Enable VxWorks as hard-rt VM
This patch adds --lapic_pt option to launch VxWorks as hard-rt VM.

Tracked-On: projectacrn#3069
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
wenlingz added a commit that referenced this issue Jun 14, 2019
DM: Samples: Enable VxWorks as hard-rt VM
This patch adds --lapic_pt option to launch VxWorks as hard-rt VM.

Tracked-On: #3069
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
KaigeFu added a commit to KaigeFu/acrn-hypervisor that referenced this issue Jun 18, 2019
HV: Fix OVMF hang issue when boot with lapic_pt
In hcall_inject_msi, we check vlapic state of SOS by mistake.
If the SOS's vlapic state doesn't equal to target_vm's, the OVMF will
hang when boot up. Instead, we should check the target_vm's
vlapic state.

Tracked-On: projectacrn#3069
Acked-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@intel.com>
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
wenlingz added a commit that referenced this issue Jun 19, 2019
HV: Fix OVMF hang issue when boot with lapic_pt
In hcall_inject_msi, we check vlapic state of SOS by mistake.
If the SOS's vlapic state doesn't equal to target_vm's, the OVMF will
hang when boot up. Instead, we should check the target_vm's
vlapic state.

Tracked-On: #3069
Acked-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@intel.com>
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
KaigeFu added a commit to KaigeFu/acrn-hypervisor that referenced this issue Jun 20, 2019
HV: Allow pause RTVM when its state is VM_CREATED
There are a lot of works to do between create_vm (HV will mark vm's state
as VM_CREATED at this stage) and vm_run (HV will mark vm's state as VM_STARTED),
like building mptable/acpi table, initializing mevent and vdevs. If there is
something goes wrong between create_vm and vm_run, the devicemodel will jumps
to the deinit process and will try to destroy the vm. For example, if the
vm_init_vdevs failed, the devicemodel will jumps to dev_fail and then destroy
the vm.

For normal vm in above situation, it is fine to destroy vm. And we can create and
start it next time. But for RTVM, we can't destroy the vm as the vm's state is
VM_CREATED. And we can only destroy vm when its state is VM_POWERING_OFF. So, the
vm will stay at VM_CREATED state and we will never have chance to destroy it.
Consequently, we can't create and start the vm next time.

This patch fixes it by allowing to pause and then destroy RTVM when its state is VM_CREATED.

Tracked-On: projectacrn#3069
Acked-by: Eddie Dong <eddie.dong@intel.com>
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
dongyaozu added a commit that referenced this issue Jun 20, 2019
HV: Allow pause RTVM when its state is VM_CREATED
There are a lot of works to do between create_vm (HV will mark vm's state
as VM_CREATED at this stage) and vm_run (HV will mark vm's state as VM_STARTED),
like building mptable/acpi table, initializing mevent and vdevs. If there is
something goes wrong between create_vm and vm_run, the devicemodel will jumps
to the deinit process and will try to destroy the vm. For example, if the
vm_init_vdevs failed, the devicemodel will jumps to dev_fail and then destroy
the vm.

For normal vm in above situation, it is fine to destroy vm. And we can create and
start it next time. But for RTVM, we can't destroy the vm as the vm's state is
VM_CREATED. And we can only destroy vm when its state is VM_POWERING_OFF. So, the
vm will stay at VM_CREATED state and we will never have chance to destroy it.
Consequently, we can't create and start the vm next time.

This patch fixes it by allowing to pause and then destroy RTVM when its state is VM_CREATED.

Tracked-On: #3069
Acked-by: Eddie Dong <eddie.dong@intel.com>
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
lyan3 added a commit to lyan3/acrn-hypervisor that referenced this issue Jun 21, 2019
dm: samples: use stdio as vxworks console by default
Current launch script leave stdio to OVMF console and, vxworks console to pty, so user
need to use additional toll like minicom to connect to pty device to use vxWorks.

To be more convinient, this commit changes the vxWorks to use the stdio by default, and OVMF
is not availabe by default.

Tracked-On: projectacrn#3069
Signed-off-by: Yan, Like <like.yan@intel.com>
lyan3 added a commit to lyan3/acrn-hypervisor that referenced this issue Jun 22, 2019
dm: samples: use stdio as vxworks console by default
Current launch script leaves stdio to OVMF console and, vxworks console to pty, so users
need to use additional tool like minicom to connect to pty device to use vxWorks.

To be more convinient, this commit changes the vxWorks to use the stdio by default, and OVMF
is not availabe by default.

Tracked-On: projectacrn#3069
Signed-off-by: Yan, Like <like.yan@intel.com>
dongyaozu added a commit that referenced this issue Jun 22, 2019
dm: samples: use stdio as vxworks console by default
Current launch script leaves stdio to OVMF console and, vxworks console to pty, so users
need to use additional tool like minicom to connect to pty device to use vxWorks.

To be more convinient, this commit changes the vxWorks to use the stdio by default, and OVMF
is not availabe by default.

Tracked-On: #3069
Signed-off-by: Yan, Like <like.yan@intel.com>
@Mingyuan18

This comment has been minimized.

Copy link

commented Jun 24, 2019

Vxworks as a guest has been covered in daily test and result is pass, therefore close it

@Mingyuan18 Mingyuan18 closed this Jun 24, 2019

@Mingyuan18 Mingyuan18 added this to v1.1 in Roadmap Jun 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2 participants
You can’t perform that action at this time.