Now we split passthrough PCI device from DM to HV, we could remove all the passthrough
PCI device unused code.
Tracked-On: #4371
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
In this case, we could handle all the passthrough PCI devices in ACRN hypervisor.
But we still need DM to initialize BAR resources and Intx for passthrough PCI
device for post-launched VM since these informations should been filled into
ACPI tables. So
1. we add a HC vm_assign_pcidev to pass the extra informations to replace the old
vm_assign_ptdev.
2. we saso remove HC vm_set_ptdev_msix_info since it could been setted by the post-launched
VM now same as SOS.
3. remove vm_map_ptdev_mmio call for PTDev in DM since ACRN hypervisor will handle these
BAR access.
4. the most important thing is to trap PCI configure space access for PTDev in HV for
post-launched VM and bypass the virtual PCI device configure space access to DM.
This patch doesn't do the clean work. Will do it in the next patch.
Tracked-On: #4371
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Add assign/deassign PCI device hypercall APIs to assign a PCI device from SOS to
post-launched VM or deassign a PCI device from post-launched VM to SOS. This patch
is prepared for spliting passthrough PCI device from DM to HV.
The old assign/deassign ptdev APIs will be discarded.
Tracked-On: #4371
Signed-off-by: Li Fei1 <fei1.li@intel.com>
1. Align the coding style for these MACROs
2. Align the values of fixed VECTORs
Tracked-On: #4348
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
is_polling_ioreq is more straightforward. Rename it.
Tracked-On: #4329
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch checks the validity of 'vdev->pdev' to
ensure physical device is linked to 'vdev'.
this check is to avoid some potential hypervisor
crash when destroying VM with crafted input.
Tracked-On: #4336
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
VM trap PCIe ECAM access in DM).
Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
platform hide PCI devices by BIOS to SOS.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Introduce two kinds of events for each vcpu,
VCPU_EVENT_IOREQ: for vcpu waiting for IO request completion
VCPU_EVENT_VIRTUAL_INTERRUPT: for vcpu waiting for virtual interrupts events
vcpu can wait for such events, and resume to run when the
event get signalled.
This patch also change IO request waiting/notifying to this way.
Tracked-On: #4329
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Before we assign a PT device to post-launched VM, we should reset the PCI device
first. However, ACRN hypervisor doesn't plan to support PCIe hot-plug and doesn't
support PCIe bridge Secondary Bus Reset. So the PT device must support FLR or PM
reset. This patch do this check when assigning a PT device to post-launched VM.
Tracked-On: #3465
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Since we restore BAR values when writing Command Register if necessary. We don't
need to trap FLR and do the BAR restore then.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
When PCIe does Conventinal Reset or FLR, almost PCIe configurations and states will
lost. So we should save the configurations and states before do the reset and restore
them after the reset. This was done well by BIOS or Guest now. However, ACRN will trap
these access and handle them properly for security. Almost of these configurations and
states will be written to physical configuration space at last except for BAR values
for now. So we should do the restore for BAR values. One way is to do restore after
one type reset is detected. This will be too complex. Another way is to do the restore
when BIOS or guest tries to write the Command Register. This could work because:
1. The I/O Space Enable bit and Memory Space Enable bits in Command Register will reset
to zero.
2. Before BIOS or guest wants to enable these bits, the BAR couldn't be accessed.
3. So we could restore the BAR values before enable these bits if reset is detected.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
- target vm_id of vuart can't be un-defined VM, nor the VM itself.
- fix potential NULL pointer dereference in find_active_target_vuart()
Tracked-On: #3854
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Structure pci_vbar is used to define the virtual BAR rather than physical BAR.
It's better to name as pci_vbar.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
ACRN hypervisor should trap guest doing PCI AF FLR. Besides, it should save some status
before doing the FLR and restore them later, only BARs values for now.
This patch will trap guest Conventional PCI Advanced Features Control Register write
operation if the device supports Conventional PCI Advanced Features Capability and
check whether it wants to do device AF FLR. If it does, call pdev_do_flr to do the job.
Tracked-On: #3465
Signed-off-by: Li Fei1 <fei1.li@intel.com>
ACRN hypervisor should trap guest doing PCIe FLR. Besides, it should save some status
before doing the FLR and restore them later, only BARs values for now.
This patch will trap guest Device Capabilities Register write operation if the device
supports PCI Express Capability and check whether it wants to do device FLR. If it does,
call pdev_do_flr to do the job.
Tracked-On: #3465
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Do vMSI-X remap only when Mask Bit in Vector Control Register for MSI-X Table Entry
is unmask.
The previous implementation also has two issues:
1. It only check whether Message Control Register for MSI-X has been modified when
guest writes MSI-X CFG space at Message Control Register offset.
2. It doesn't really disable MSI-X when guest wants to disable MSI-X.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
1. disable physical MSI before writing the virtual MSI CFG space
2. do the remap_vmsi if the guest wants to enable MSI or update MSI address or data
3. disable INTx and enable MSI after step 2.
The previous Message Control check depends on the guest write MSI Message Control
Register at the offset of Message Control Register. However, the guest could access
this register at the offset of MSI Capability ID register. This patch remove this
constraint. Also, The previous implementation didn't really disable MSI when guest
wanted to disable MSI.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Now, we support schedule inplace. And with cpu sharing, there might be
multi vcpu running on same pcpu. Reschedule request will happen when
switch the running vcpu. If the current vcpu is polling on the IO
completion, it need to be scheduled back to the polling point.
In the polling path, construct a loop for polling, and do schedule in the
loop if needed.
Tracked-On: #4178
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Name vmsi and vmsix function with verb-object style:
For external APIs, using MODULE_NAME_verb-object style;
For internal APIs, using verb-object style.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
ptirq_msix_remap doesn't do the real remap, that's the vmsi_remap and vmsix_remap_entry
does. ptirq_msix_remap only did the preparation.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
call vuart_register_io_handler function, when the parameter vuart_idx is greater
than or equal to 2, print the vuart index value which will not register the vuart.
Tracked-On: #4072
Signed-off-by: Jidong Xia <xiajidong@cmss.chinamobile.com>
After reshuffle pci_bar structrue we could write ~0U not BAR size mask to BAR
configuration space directly when do BAR sizing. In this case, we could know whether
the value in BAR configuration space is a valid base address. As a result, we could
do BAR re-programming whenever we want.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
The current code declare pci_bar structure following the PCI bar spec. However,
we could not tell whether the value in virtual BAR configuration space is valid
base address base on current pci_bar structure. We need to add more fields which
are duplicated instances of the vBAR information. Basides these fields which will
added, bar_base_mapped is another duplicated instance of the vBAR information.
This patch try to reshuffle the pci_bar structure to declare pci_bar structure
following the software implement benefit not the PCI bar spec.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
The current do PCI IO BAR remap in vdev_pt_allow_io_vbar. This patch split this
function into vdev_pt_deny_io_vbar and vdev_pt_allow_io_vbar. vdev_pt_deny_io_vbar
removes the old IO port mapping, vdev_pt_allow_io_vbar add the new IO port mapping.
Tracked-On: #3475
Signed-off-by: Li Fei1 <fei1.li@intel.com>
After adding PCI BAR remap support, mmio_node may unregister when there's others
access it. This patch add a lock to protect mmio_node access.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Concurrent access on PCI device may happened if UOS try to access PCI configuration
space on different vCPUs through IO port. This patch just adds a global PCI lock for
each VM to prevent the concurrent access.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Refine PCI CONFIG_ADDRESS Register definition as its physical layout.
In this case, we could read/write PCI CONFIG_ADDRESS Register atomically.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Unmap old mappings in vdev_pt_write_vbar explicitly before set_vbar_base.
Then map new mappings explicitly in vdev_pt_write_vbar.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Since guest could re-program PCI device MSI-X table BAR, we should add mmio
emulation handler unregister.
However, after add unregister_mmio_emulation_handler API, emul_mmio_regions
is no longer accurate. Just replace it with max_emul_mmio_regions which records
the max index of the emul_mmio_node.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
In theory, guest could re-program PCI BAR address to any address. However, ACRN
hypervisor only support [0, top_address_space) EPT memory mapping. So we need to
check whether the PCI BAR re-program address is within this scope.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- The default behaviors of PIO & MMIO handlers are same
for all VMs, no need to expose dedicated APIs to register
default hanlders for SOS and prelaunched VM.
Tracked-On: #3904
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
'info.pmsi_addr' may be written to physicall device's
PCI configuration field without initialization when
'enable' is false in 'vmsi_remap()'.
this patch is to fix above issues, 'PCIR_MSI_ADDR'
and 'PCIR_MSI_ADDR_HIGH' only be programmed when
'enable' is true.
Tracked-On: #3903
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
With cpu sharing enabled, we will map acrn_vcpu to thread_object
in scheduling. From modulization perspective, we'd better hide the
pcpu_id in acrn_vcpu and move it to thread_object.
Tracked-On: #3813
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>
Acked-by: Eddie Dong <eddie.dong@intel.com>
--remove unnecessary includes
--remove unnecssary forward-declaration for 'struct vhm_request'
Tracked-On: #861
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
The MSI Message Address and Message Data have no valid data after Power-ON. So
there's no need to initialize them by reading the data from physical PCI configuration
space.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
- update the function argument type to union
Declaring argument as pointer is not necessary since it
only does the comparison.
Tracked-On: #1842
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Initialize vBAR configure space when doing vPCI BAR initialization. At this time,
we access the physical device as we needs, no need to cache physical PCI device
BAR information beforehand.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
The orignal communication port will lose data when tx is too fast, and
the data in FIFO will be overwritten.
Now, when the FIFO is full, stop sending more data. When the FIFO is not
full, notify the vuart to send more data.
Tracked-On: #3681
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
For communication vuart, when it send data to target vuart's fifo, it
should meet the conditions:
1. MCR_LOOPBACK is not set
2. LCR_DLAB is not set
3. access reg is UART16550_THR
4. target_vu is not null
But the LCR_DLAB is missed now, and when vuart set it's UART16550_DLL,
it will be send to target by mistake as UART16550_DLL = UART16550_THR.
Add the missed condition.
DLAB in uart16550 spec:
Divisor Latch Access Bit.
1 = Allows access to the Divisor Latch Registers and reading of the FIFO
Control Register.
0 = Allows access to RBR, THR, IER and IIR registers.
Tracked-On: #3681
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
In "commit 6ebc22" the vPCI device initialize sequence is wrong changed. This patch
tries to revert it.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
In "commit 90480d" we use a pointer new_owner to point to the actual vPCI device
for post-launched VM when this device is assigned to this post-launched VM from
SOS. However, now DM will use SOS's vmsix_table_mmio_access_handler to trap vMSI-X
table mmio access for post-launched VM. So we should use the post-launched VM's
vPCI device in this case.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
vPCI device should use its virtual configure space to access its BAR after vPCI
device initialized.
This patch also remove corner case "vPCI device will use its 64 bits BAR high idx
to access its BAR base address".
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
PCI BAR physical base address will never changed. Cache it to avoid calculating
it every time when we access it.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
As the pr_dbg will access sbuf which will call stac/clac inside, so can
not put pr_dbg between stac/clac, it will case Page Fault.
acrn_print_request is a debug feature, and it calls pr_dbg. when the
loglevel is set to 6, there will be Page Fault.
So, remove the caller for acrn_print_request and mask the function as
unused, reserved for debug.
Tracked-On: #3648
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Reviewed-by: Yonghua Huang <yonghua.huang@intel.com>
Li Fei1