vmm.h has some unused definitions.
Keep the useful definitions and delete vmm.h
Tracked-On: #6282
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
return value 'err' of mmio_rb_lookup() being 0 ensures
'entry' is not NULL, hence checking it before 'free(entry)'
is unnecessary.
Tracked-On: #6157
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Only free rb_entry when we remove this entry from the rb tree, otherwise, a
page fault would trigger when next rb itreation would access the freed rb_entry.
Tracked-On: #6056
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Use acrn-dm logger function instread of printf,
this helps the stability testing log capture.
Tracked-On: #4098
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Cao Minggui <minggui.cao@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
cleanup 'assert' usage to avoid possible software vulnerabilities.
Tracked-On: #3252
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Shuo A Liu <shuo.a.liu@intel.com>
This patch is to fix some potential memory leak issues
1, free mrp if the mmio_rb_lookup() function return 0;
2, free memory allocated by strdup in some error case handling.
Tracked-On: #3277
Signed-off-by: Tianhua Sun <tianhuax.s.sun@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
mmio_hint in mem.c can potentially be accessed concurrently in
emulate_mem() because it only holds a read lock. Use a local variable to
make sure the same entry address is used throughout the function. Since
it only serves as a hint, it's okay if the function does not use the
most up-to-date version of mmio_hint, as long as mmio_hint is accessed
atomically.
Explicitly enforce natural alignment on mmio_hint to guarantee atomic
accesses on x86 and increase code portability, even though compilers
most likely always do it.
Entries in the RB tree are only removed in unregister_mem_int() while
holding a write lock, so accessing mmio_hint while holding a read lock
is safe.
Tracked-On: #2902
Signed-off-by: Peter Fang <peter.fang@intel.com>
Reviewed-by: Shuo A Liu <shuo.a.liu@intel.com>
Following up on d648df766c, surgically
remove all the functions related to enable_bar()/disable_bar() that got
introduced in 8787b65fde.
Tracked-On: #2902
Signed-off-by: Peter Fang <peter.fang@intel.com>
Reviewed-by: Shuo A Liu <shuo.a.liu@intel.com>
There is a deadlock when emulate_mem is called on the memory region
of PCI extended configuration space. The call trace is something like:
emulate_mem
-> pci_emul_ecfg_handler
-> pci_cfgrw
-> pci_emul_cmdsts_write
-> unregister_bar/register_bar
-> modify_bar_registration
-> unregister_mem/register_mem
mmio_rwlock is hold in emulate_mem when calling unregister_mem/
register_mem which is trying to acquire mmio_rwlock again, and deadlock
happened.
It is possible that bar address is changed just between a on-going
MMIO access which can bring a race condition in theroy. Guest needs to
take care of the serial operation between bar addess update and MMIO
access of that bar.
Tracked-On: #2962
Signed-off-by: Yu Wang <yu1.wang@intel.com>
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Signed-off-by: Liu Shuo A <shuo.a.liu@intel.com>
Acked-by: Yin Fengwei <fengwei.yin@intel.com>
- use strncmp() instead of comparing string pointers to make no
assumptions about the toolchain's literal pool
- re-shuffle the functions so they're consistent with mem.h
- make non-public functions static
- increase code re-use
Tracked-On: #2792
Signed-off-by: Peter Fang <peter.fang@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Acked-by: Yin Fengwei <fengwei.yin@intel.com>
vHPET is used as a source of system timer by UEFI (e.g. OVMF).
This provides an alternative to using vPIT, which OVMF assumes is always
connected to vPIC.
This is ported from Bhyve, with a few changes:
- move to user space, using acrn_timer
- enable timers only when necessary
Origin: FreeBSD
License: BSD-3-Clause
URL: https://svnweb.freebsd.org/
commit: 326257
Purpose: Adding vHPET support.
Maintained-by: External
Tracked-On: #2319
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
According to PCI spec 3.0 section 6.2.2 "Device Control", guest
could write the command register to control device response to
io/mem access.
The origial code register/unregister the memory range which is
not suitable because it can't handle the sequence:
1. disble the device response to specific memory range
2. reboot guest (DM will try to free the memory range which
was freed in step 1 already)
Tracked-On: #1277
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Two memory ranges are allocated:
- PCI ECFG
- PCI hole
They should be released when deinit_pci. Old code mark
this two ranges not unregistered. Which is wrong for
warm reboot case. Make them could be unregistered.
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
