2018-08-08 09:58:31 +08:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 2011 NetApp, Inc.
|
|
|
|
* Copyright (c) 2018 Intel Corporation
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY NETAPP, INC ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL NETAPP, INC OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* $FreeBSD$
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
/*_
|
|
|
|
* Emulate a PCI Host bridge:
|
|
|
|
* Intel Corporation Celeron N3350/Pentium N4200/Atom E3900
|
|
|
|
* Series Host Bridge (rev 0b)
|
|
|
|
*/
|
|
|
|
|
2019-02-25 16:44:07 +08:00
|
|
|
#include <vm.h>
|
|
|
|
#include <pci.h>
|
2019-03-22 07:45:57 +08:00
|
|
|
#include "vpci_priv.h"
|
HV: inject physical PCIEXBAR to SOS vhostbridge
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-07-23 15:19:27 +08:00
|
|
|
#include <vacpi.h>
|
2019-05-14 09:26:13 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @pre vdev != NULL
|
|
|
|
* @pre vdev->vpci != NULL
|
|
|
|
*/
|
HV: inject physical PCIEXBAR to SOS vhostbridge
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-07-23 15:19:27 +08:00
|
|
|
/* The chart below shows the hostbridge DID high-byte of the platform later than broadwell, whose PCIEXBAR are always
|
|
|
|
located in the PCI hostbridge config space at the offset 0x60. This chart may need further extension in the future
|
|
|
|
--------------------------------------------------------------------------------------
|
|
|
|
platform | hostbridge DID high-byte
|
|
|
|
--------------------------------------------------------------------------------------
|
|
|
|
SKL(6-gen) | 0x19
|
|
|
|
APL(6-gen Atom) | 0x5a
|
|
|
|
KBL(7/8-gen) | 0x59
|
|
|
|
CFL/CFL-R(8/9-gen) | 0x3e
|
|
|
|
ICL(10-gen) | 0x9b
|
2020-09-01 10:29:48 +08:00
|
|
|
EHL(11-gen) | 0x45
|
|
|
|
TGL(11-gen) | 0x9a
|
HV: inject physical PCIEXBAR to SOS vhostbridge
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-07-23 15:19:27 +08:00
|
|
|
--------------------------------------------------------------------------------------
|
|
|
|
*/
|
2020-09-01 10:29:48 +08:00
|
|
|
static const uint32_t hostbridge_did_highbytes[] = {0x19U, 0x5aU, 0x59U, 0x3eU, 0x9aU, 0x45U, 0x9bU};
|
HV: inject physical PCIEXBAR to SOS vhostbridge
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-07-23 15:19:27 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
The vhostbridge we currently emulated is "Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge",
|
|
|
|
which belongs to Intel Appollo Lake processors family, and the device id is 5af0
|
|
|
|
|
|
|
|
TODO:
|
|
|
|
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one
|
|
|
|
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, listed below:
|
|
|
|
|
|
|
|
----------------------------------------------------------------------------------------------------------------
|
|
|
|
reg | offset | length | current status | remark
|
|
|
|
----------------------------------------------------------------------------------------------------------------
|
|
|
|
STATUS_COMMAND | 0x8 | dword | unemulated | pci status and command
|
|
|
|
SVID_SID | 0x2C | dword | unemulated | subsys id and subsys vendor id
|
|
|
|
MCHBAR | 0x48 | qword | hard-coded | BAR of memory controller hub
|
|
|
|
GGC | 0x50 | dword | hard-coded | graphics & mem controller hub graphics CR
|
|
|
|
DEVEN | 0x54 | dword | hard-coded | device enable register
|
|
|
|
PAVPC | 0x58 | dword | hard-coded | protected audio video path control
|
|
|
|
TOUUD | 0xA8 | qword | hard-coded | top of upper usable DRAM
|
|
|
|
BDSM | 0xB0 | dword | hard-coded | base of data stolen memory
|
|
|
|
BGSM | 0xB4 | dword | hard-coded | base of graphics stolen memory
|
|
|
|
TSEGMB | 0xB8 | dword | hard-coded | top segmentmemory base
|
|
|
|
TOLUD | 0xBC | dword | hard-coded | top of lower usable dram
|
|
|
|
SKPD | 0xDC | dword | unemulated | scratchpad
|
|
|
|
CAPID0_CAPCTRL0 | 0xe0 | dword | hard-coded | capability 0 control
|
|
|
|
----------------------------------------------------------------------------------------------------------------
|
|
|
|
*/
|
2019-07-11 17:43:47 +08:00
|
|
|
static void init_vhostbridge(struct pci_vdev *vdev)
|
2018-08-08 09:58:31 +08:00
|
|
|
{
|
HV: inject physical PCIEXBAR to SOS vhostbridge
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-07-23 15:19:27 +08:00
|
|
|
union pci_bdf hostbridge_bdf = {.value = 0x0U};
|
|
|
|
uint32_t pciexbar_low = 0x0U, pciexbar_high = 0x0U, phys_did, i;
|
2019-07-11 17:43:47 +08:00
|
|
|
/* PCI config space */
|
2020-03-09 13:05:09 +08:00
|
|
|
pci_vdev_write_vcfg(vdev, PCIR_VENDOR, 2U, 0x8086U);
|
|
|
|
pci_vdev_write_vcfg(vdev, PCIR_DEVICE, 2U, 0x5af0U);
|
|
|
|
pci_vdev_write_vcfg(vdev, PCIR_REVID, 1U, 0xbU);
|
|
|
|
pci_vdev_write_vcfg(vdev, PCIR_HDRTYPE, 1U, (PCIM_HDRTYPE_NORMAL | PCIM_MFDEV));
|
|
|
|
pci_vdev_write_vcfg(vdev, PCIR_CLASS, 1U, PCIC_BRIDGE);
|
|
|
|
pci_vdev_write_vcfg(vdev, PCIR_SUBCLASS, 1U, PCIS_BRIDGE_HOST);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x34U, 1U, 0xe0U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x3cU, 1U, 0xe0U);
|
2020-07-20 17:37:20 +08:00
|
|
|
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x48U, 4U, 0xfed10001U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x50U, 4U, 0x000002c1U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x54U, 4U, 0x00000033U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x58U, 4U, 0x7ff00007U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xa8U, 4U, 0x80000000U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xacU, 4U, 0x00000002U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xb0U, 4U, 0x7c000001U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xb4U, 4U, 0x7b800001U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xb8U, 4U, 0x7b000001U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xbcU, 4U, 0x80000001U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xe0U, 4U, 0x010c0009U);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0xf4U, 4U, 0x011c0f00U);
|
2020-05-07 09:44:07 +08:00
|
|
|
|
HV: inject physical PCIEXBAR to SOS vhostbridge
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-07-23 15:19:27 +08:00
|
|
|
if (is_prelaunched_vm(container_of(vdev->vpci, struct acrn_vm, vpci))) {
|
2020-08-31 14:16:17 +08:00
|
|
|
/* For pre-launched VMs, we only need to write an GPA that's reserved in guest ve820,
|
|
|
|
* and UOS_VIRT_PCI_MMCFG_BASE(0xE0000000) is fine. The trailing 1 is a ECAM enable-bit
|
|
|
|
*/
|
|
|
|
pciexbar_low = UOS_VIRT_PCI_MMCFG_BASE | 0x1U;
|
HV: inject physical PCIEXBAR to SOS vhostbridge
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-07-23 15:19:27 +08:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
/*Inject physical ECAM value to SOS vhostbridge since SOS may check PCIe-MMIO Base Address with it */
|
|
|
|
phys_did = pci_pdev_read_cfg(hostbridge_bdf, PCIR_DEVICE, 2);
|
|
|
|
for (i = 0U; i < (sizeof(hostbridge_did_highbytes) / sizeof(uint32_t)); i++){
|
|
|
|
if (((phys_did & 0xff00U) >> 8) == hostbridge_did_highbytes[i]) {
|
|
|
|
/* The offset of PCIEXBAR register is 0x60 on Intel platforms, and no counter-case is encountered yet */
|
|
|
|
pciexbar_low = pci_pdev_read_cfg(hostbridge_bdf, 0x60U, 4);
|
|
|
|
pciexbar_high = pci_pdev_read_cfg(hostbridge_bdf, 0x64U, 4);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x60U, 4, pciexbar_low);
|
|
|
|
pci_vdev_write_vcfg(vdev, 0x64U, 4, pciexbar_high);
|
2020-05-07 09:44:07 +08:00
|
|
|
vdev->parent_user = NULL;
|
|
|
|
vdev->user = vdev;
|
2018-08-08 09:58:31 +08:00
|
|
|
}
|
|
|
|
|
2019-07-11 17:43:47 +08:00
|
|
|
static void deinit_vhostbridge(__unused struct pci_vdev *vdev)
|
2018-08-08 09:58:31 +08:00
|
|
|
{
|
2020-05-07 09:44:07 +08:00
|
|
|
vdev->parent_user = NULL;
|
|
|
|
vdev->user = NULL;
|
2018-08-08 09:58:31 +08:00
|
|
|
}
|
|
|
|
|
2019-05-14 09:26:13 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @pre vdev != NULL
|
|
|
|
* @pre vdev->vpci != NULL
|
|
|
|
*/
|
2020-03-04 15:28:40 +08:00
|
|
|
static int32_t read_vhostbridge_cfg(const struct pci_vdev *vdev, uint32_t offset,
|
2018-08-08 09:58:31 +08:00
|
|
|
uint32_t bytes, uint32_t *val)
|
|
|
|
{
|
2020-03-09 13:05:09 +08:00
|
|
|
*val = pci_vdev_read_vcfg(vdev, offset, bytes);
|
2019-07-11 17:43:47 +08:00
|
|
|
return 0;
|
2018-08-08 09:58:31 +08:00
|
|
|
}
|
|
|
|
|
2019-05-14 09:26:13 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @pre vdev != NULL
|
|
|
|
* @pre vdev->vpci != NULL
|
|
|
|
*/
|
2020-03-04 15:28:40 +08:00
|
|
|
static int32_t write_vhostbridge_cfg(struct pci_vdev *vdev, uint32_t offset,
|
2018-08-08 09:58:31 +08:00
|
|
|
uint32_t bytes, uint32_t val)
|
|
|
|
{
|
2019-07-11 17:43:47 +08:00
|
|
|
if (!is_bar_offset(PCI_BAR_COUNT, offset)) {
|
2020-03-09 13:05:09 +08:00
|
|
|
pci_vdev_write_vcfg(vdev, offset, bytes, val);
|
2018-08-29 07:47:55 +08:00
|
|
|
}
|
2019-07-11 17:43:47 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2018-08-08 09:58:31 +08:00
|
|
|
|
2019-08-07 23:29:18 +08:00
|
|
|
const struct pci_vdev_ops vhostbridge_ops = {
|
2019-07-11 17:43:47 +08:00
|
|
|
.init_vdev = init_vhostbridge,
|
|
|
|
.deinit_vdev = deinit_vhostbridge,
|
2020-03-04 15:28:40 +08:00
|
|
|
.write_vdev_cfg = write_vhostbridge_cfg,
|
|
|
|
.read_vdev_cfg = read_vhostbridge_cfg,
|
2019-07-11 17:43:47 +08:00
|
|
|
};
|