Change i915.domain_plane_owners and i915.avail_planes_per_pipe for
hybrid scenario;because some User vm(like:Ubuntu/Debian and WaaG)
doesn't support plane restriction; it will use PipeA by default.
Tracked-On: #3840
Signed-off-by: fuzhongl <fuzhong.liu@intel.com>
Add this vcpu_affinity[] for each VM to indicate the assignment policy.
With it, pcpu_bitmap is not needed, so remove it from vm_config.
Instead, vcpu_affinity is a must for each VM.
This patch also add some sanitize check of vcpu_affinity[]. Here are
some rules:
1) only one bit can be set for each vcpu_affinity of vcpu.
2) two vcpus in same VM cannot be set with same vcpu_affinity.
3) vcpu_affinity cannot be set to the pcpu which used by pre-launched VM.
v4: config SDC with CONFIG_MAX_KATA_VM_NUM
v5: config SDC with CONFIG_MAX_PCPU_NUM
Tracked-On: #3663
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Signed-off-by: Yu Wang <yu1.wang@intel.com>
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
There is plan that define each VM configuration statically in HV and let
DM just do VM creating and destroying. So DM need get vcpu_num
information when VM creating.
This patch return the vcpu_num via the API param. And also initial the
VMs' cpu_num for existing scenarios.
Tracked-On: #3663
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Signed-off-by: Yu Wang <yu1.wang@intel.com>
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The vCOM2 of each VM is designed for VM communication, one VM could send
command or request to another VM through this channel. The feature will
be used for system S3/S5 implementation.
On Hybird scenario, vCOM2 of pre-launched VM will connect to vCOM2 of SOS_VM;
On Industry scenario, vCOM2 of post-launched RTVM will connect to vCOM2 of
SOS_VM.
Tracked-On: #3602
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
The settings of SOS VM COM1 which is used for console is board specific,
and this result in SOS VM COM2 which used for VM communication is also
board specific, so move the configure method from Kconfig to board configs
folder. The MACRO definition will be handled by acrn-config tool in future.
Tracked-On: #3602
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
When assgined a PCI PTDev to post-launched VM from SOS, using a pointer to point to
the real struct pci_vdev. When post-launched VM access its PTDev configure space in
SOS address space, using this real struct pci_vdev.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Add emulated PCI device configure for SOS to prepare for add support for customizing
special pci operations for each emulated PCI device.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
In hybrid mode, pre-launched VM should have the highest severity to
handle platform reset, the flag should not be set in SOS VM;
Tracked-On: #3505
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
In current design, devicemodel passes VM UUID to create VMs and hypervisor
would check the UUID whether it is matched with the one in VM configurations.
Kata container would maintain few UUIDs to let ACRN launch the VM, so
hypervisor need to add these UUIDs in VM configurations for Kata running.
In the hypercall of hcall_get_platform_info(), hypervisor will report the
maximum Kata container number it will support. The patch will add a Kconfig
to indicate the maximum Kata container number that SOS could support.
In current stage, only one Kata container is supported by SOS on SDC scenario
so add one UUID for Kata container in SDC VM configuration. If we want to
support Kata on other scenarios in the future, we could follow the example
of this patch;
Tracked-On: #3402
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Hybrid scenario will run 3 VMs: one pre-launched VM, one pre-launched SOS VM
and one post-launched Standard VM.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
fuzhongl