| Message ID | 20170424115201.96963-2-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> Roger Pau Monne <roger.pau@citrix.com> 04/24/17 1:52 PM >>> >--- a/xen/arch/x86/dom0_build.c >+++ b/xen/arch/x86/dom0_build.c >@@ -18,6 +18,8 @@ >#include <asm/p2m.h> >#include <asm/setup.h> > >+#include "x86_64/mmconfig.h" Not just but also because of this I'd prefer if this was taken care of in the MMCFG code itself, also covering ranges which are being added post- boot. Presumably in/from pci_mmcfg_arch_{en,dis}able(). Jan
On Fri, Jun 30, 2017 at 05:27:06AM -0600, Jan Beulich wrote: > >>> Roger Pau Monne <roger.pau@citrix.com> 04/24/17 1:52 PM >>> > >--- a/xen/arch/x86/dom0_build.c > >+++ b/xen/arch/x86/dom0_build.c > >@@ -18,6 +18,8 @@ > >#include <asm/p2m.h> > >#include <asm/setup.h> > > > >+#include "x86_64/mmconfig.h" > > Not just but also because of this I'd prefer if this was taken care of in the > MMCFG code itself, also covering ranges which are being added post- > boot. Presumably in/from pci_mmcfg_arch_{en,dis}able(). The problem with this approach is that at the point in the boot where pci_mmcfg_arch_enable gets called (from acpi_mmcfg_init) the domain has not yet been created, so it's not possible to call iomem_deny_access, and in any case the iomem ranges are initialized in dom0_setup_permissions, so that would get overwritten. Roger.
>>> On 30.06.17 at 17:33, <roger.pau@citrix.com> wrote: > On Fri, Jun 30, 2017 at 05:27:06AM -0600, Jan Beulich wrote: >> >>> Roger Pau Monne <roger.pau@citrix.com> 04/24/17 1:52 PM >>> >> >--- a/xen/arch/x86/dom0_build.c >> >+++ b/xen/arch/x86/dom0_build.c >> >@@ -18,6 +18,8 @@ >> >#include <asm/p2m.h> >> >#include <asm/setup.h> >> > >> >+#include "x86_64/mmconfig.h" >> >> Not just but also because of this I'd prefer if this was taken care of in the >> MMCFG code itself, also covering ranges which are being added post- >> boot. Presumably in/from pci_mmcfg_arch_{en,dis}able(). > > The problem with this approach is that at the point in the boot where > pci_mmcfg_arch_enable gets called (from acpi_mmcfg_init) the domain > has not yet been created, so it's not possible to call > iomem_deny_access, and in any case the iomem ranges are initialized in > dom0_setup_permissions, so that would get overwritten. I understand that; a new helper function would be needed. Jan
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c index 3996d9dd12..481a899afe 100644 --- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -18,6 +18,8 @@ #include <asm/p2m.h> #include <asm/setup.h> +#include "x86_64/mmconfig.h" + static long __initdata dom0_nrpages; static long __initdata dom0_min_nrpages; static long __initdata dom0_max_nrpages = LONG_MAX; @@ -452,6 +454,22 @@ int __init dom0_setup_permissions(struct domain *d) rc |= rangeset_add_singleton(mmio_ro_ranges, mfn); } + /* For PVH prevent access to the MMCFG areas. */ + if ( dom0_pvh && pci_mmcfg_config_num ) + { + unsigned int i; + + for ( i = 0; i < pci_mmcfg_config_num; i++ ) + { + paddr_t addr = pci_mmcfg_config[i].address + + (pci_mmcfg_config[i].start_bus_number << 20); + size_t size = (pci_mmcfg_config[i].end_bus_number - + pci_mmcfg_config[i].start_bus_number + 1) << 20; + + rc |= iomem_deny_access(d, PFN_DOWN(addr), PFN_UP(addr + size)); + } + } + return rc; }
They are emulated by Xen, so they must not be mapped into Dom0 p2m. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Cc: Jan Beulich <jbeulich@suse.com> Cc: Andrew Cooper <andrew.cooper3@citrix.com> --- xen/arch/x86/dom0_build.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)