Re: [Xen-devel] [PATCH v4 3/4] dom0/pvh: change the order of the MMCFG initialization
>>> On 10.08.18 at 12:04, wrote: > On Wed, Aug 08, 2018 at 06:35:47AM -0600, Jan Beulich wrote: >> >>> On 08.08.18 at 12:07, wrote: >> > So it's done before the iommu is initialized. This is required in >> > order to be able to fetch the MMCFG regions from the domain struct. >> >> Is this a useful change to make? Regions not reported through the MCFG >> table will need punching holes anyway, so why not punch holes uniformly >> in all cases, allowing the hole punching code to be tested even on systems >> without non-boot-time-available regions? > > I can add this hole-punching code to register_vpci_mmcfg_handler so I > can remove this reordering. > > I'm however struggling to find a function that will set a p2m range to > p2m_invalid. All the functions that I find to deal with this assume > that you know the memory type you are trying to remove (for example > clear_identity_p2m_entry) and fail if the current type is different > than expected. > > In this case it's quite likely that the MMCFG region is not mapped to > anything, should I introduce a new helper that sets a p2m range to > p2m_invalid regardless of the current type? Well, if there is none - why not? But really that's more like something to get George to agree to. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/4] dom0/pvh: change the order of the MMCFG initialization
On Wed, Aug 08, 2018 at 06:35:47AM -0600, Jan Beulich wrote: > >>> On 08.08.18 at 12:07, wrote: > > So it's done before the iommu is initialized. This is required in > > order to be able to fetch the MMCFG regions from the domain struct. > > Is this a useful change to make? Regions not reported through the MCFG > table will need punching holes anyway, so why not punch holes uniformly > in all cases, allowing the hole punching code to be tested even on systems > without non-boot-time-available regions? I can add this hole-punching code to register_vpci_mmcfg_handler so I can remove this reordering. I'm however struggling to find a function that will set a p2m range to p2m_invalid. All the functions that I find to deal with this assume that you know the memory type you are trying to remove (for example clear_identity_p2m_entry) and fail if the current type is different than expected. In this case it's quite likely that the MMCFG region is not mapped to anything, should I introduce a new helper that sets a p2m range to p2m_invalid regardless of the current type? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/4] dom0/pvh: change the order of the MMCFG initialization
>>> On 08.08.18 at 12:07, wrote: > So it's done before the iommu is initialized. This is required in > order to be able to fetch the MMCFG regions from the domain struct. Is this a useful change to make? Regions not reported through the MCFG table will need punching holes anyway, so why not punch holes uniformly in all cases, allowing the hole punching code to be tested even on systems without non-boot-time-available regions? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 3/4] dom0/pvh: change the order of the MMCFG initialization
So it's done before the iommu is initialized. This is required in
order to be able to fetch the MMCFG regions from the domain struct.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dom0_build.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index f0cd63b1ec..5065729106 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1100,6 +1100,13 @@ int __init dom0_construct_pvh(struct domain *d, const
module_t *image,
return rc;
}
+/*
+ * NB: MMCFG initialization needs to be performed before iommu
+ * initialization so the iommu code can fetch the MMCFG regions used by the
+ * domain.
+ */
+pvh_setup_mmcfg(d);
+
iommu_hwdom_init(d);
rc = pvh_load_kernel(d, image, image_headroom, initrd,
bootstrap_map(image),
@@ -1124,8 +1131,6 @@ int __init dom0_construct_pvh(struct domain *d, const
module_t *image,
return rc;
}
-pvh_setup_mmcfg(d);
-
printk("WARNING: PVH is an experimental mode with limited
functionality\n");
return 0;
}
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
