[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 13/24] arm/acpi: Map all other tables for Dom0
On Tue, 1 Mar 2016, Stefano Stabellini wrote: > On Tue, 1 Mar 2016, Shannon Zhao wrote: > > On 2016/2/29 22:15, Stefano Stabellini wrote: > > > On Sun, 28 Feb 2016, Shannon Zhao wrote: > > >> > From: Shannon Zhao <shannon.zhao@xxxxxxxxxx> > > >> > > > >> > Map all other tables to Dom0 using 1:1 mappings. > > >> > > > >> > Signed-off-by: Shannon Zhao <shannon.zhao@xxxxxxxxxx> > > >> > --- > > >> > v4: fix commit message > > >> > --- > > >> > xen/arch/arm/domain_build.c | 26 ++++++++++++++++++++++++++ > > >> > 1 file changed, 26 insertions(+) > > >> > > > >> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > > >> > index 64e48ae..6ad420c 100644 > > >> > --- a/xen/arch/arm/domain_build.c > > >> > +++ b/xen/arch/arm/domain_build.c > > >> > @@ -1357,6 +1357,30 @@ static int prepare_dtb(struct domain *d, struct > > >> > kernel_info *kinfo) > > >> > } > > >> > > > >> > #ifdef CONFIG_ACPI > > >> > +static void acpi_map_other_tables(struct domain *d) > > >> > +{ > > >> > + int i; > > >> > + unsigned long res; > > >> > + u64 addr, size; > > >> > + > > >> > + /* Map all other tables to Dom0 using 1:1 mappings. */ > > >> > + for( i = 0; i < acpi_gbl_root_table_list.count; i++ ) > > >> > + { > > >> > + addr = acpi_gbl_root_table_list.tables[i].address; > > >> > + size = acpi_gbl_root_table_list.tables[i].length; > > >> > + res = map_regions(d, > > >> > + paddr_to_pfn(addr & PAGE_MASK), > > >> > + DIV_ROUND_UP(size, PAGE_SIZE), > > >> > + paddr_to_pfn(addr & PAGE_MASK)); > > >> > + if ( res ) > > >> > + { > > >> > + panic(XENLOG_ERR "Unable to map 0x%"PRIx64 > > >> > + " - 0x%"PRIx64" in domain \n", > > >> > + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1); > > >> > + } > > >> > + } > > >> > +} > > > The problem with this function is that it is mapping all other tables to > > > the guest, including the unmodified FADT and MADT. This way dom0 is > > > going to find two different versions of the FADT and MADT, isn't that > > > right? > > > > > We've replaced the entries of XSDT table with new value. That means XSDT > > points to new table. Guest will not see the old ones. > > All right. Of course it would be best to avoid mapping the original FADT > and MADT at all, but given that they are not likely to be page aligned, > it wouldn't be easy to do. > > Reviewed-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> However I have one more question: given that map_regions maps the memory read-only to Dom0, isn't it possible that one or more of the DSDT functions could not work as expected? I would imagine that the ACPI bytecode is allowed to change its own memory, right? Note that I am not suggesting to change map_regions to map memory read-write, because that would be undesirable from a security perspective. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |