Re: [Xen-devel] [PATCH RFC] pvh: set need_iommu early

[Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>]

On Thu, Jan 22, 2015 at 07:08:22AM +0000, Tian, Kevin wrote:
> > From: Elena Ufimtseva [mailto:elena.ufimtseva@xxxxxxxxxx]
> > Sent: Thursday, January 22, 2015 4:53 AM
> > 
> > need_iommu has to be set earler for dom0 pvh specific init
> > functions. If not enabled, mmio regions are not mapped with iommu
> > during domain construction.
> > 
> > This was discovered when working on booting problems of pvh dom0
> > on two different machines (ThinkCentre M and Dell 5600T).
> > On ThinkCentre during pvh dom0 booting process, IOMMU would report
> > Page fault with EPT not present. The memory address of the page fault
> > suggested that is mmio region for USB host controllers. The faulting
> > address marked as Reserved in e820 map and is not part of any rmrr
> > region reported by ACPI.
> 
> Need more understanding here. If iommu hasn't been setup for dom0 yet, 
> why is there iommu page fault at that point?

Hi Kevin

Wrong wording.
The page faults happen after iommu drhd are enabled.
need_iommu only determines if the mapping will happed for mmio
regions during pvh dom0 construction.

> 
> > These USB Host controllers have debugging devices which do behave
> > strangely and obviously use these mmio addresses for IO.
> > In pv dom0 case, all mmio regions are mappped with IOMMUF_readable and
> > IOMMUF_writable flags.
> > 
> > The other part of equation for mmio pvh region mappings is that these are
> > typed with p2m_mmio_direct.  When requesting iommu flags based on
> > memory
> > type in ept_set_entry, it returns 0 and the EPT are not being mapped with
> > iommu. To have correct mapping set, p2m_mmio_direct has to map to
> > IOMMUF_readable and IOMMUF_writable. This RFC patch is to follow.
> 
> I didn't see below patch doing anything related to above...

Looks like I did not fully succeded on sending two different and at the
same time related patches.

> 
> > 
> > Problem discussed in thread
> > http://lists.xenproject.org/archives/html/xen-devel
> > /2014-12/msg01956.html was also solved by this change and correct memory
> > type
> > to iommu flags setting.
> 
> iirc that thread has a different phenomenon hanging on a iommu reg access.
> there is a disconnect how that problem is solved with logic explained in this
> patch.

At this point it may be better to just disregard the problem described
on that thread (hanging machine).
Moreover, I did not reliably diagnozed the issue (as I would like to).


> 
> > 
> > I would like to ask for comments and opinions as there maybe a better way to
> > make these changes.
> > 
> > Signed-off-by: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>
> > ---
> >  xen/arch/x86/domain_build.c     | 4 +++-
> >  xen/drivers/passthrough/iommu.c | 2 +-
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
> > index 7993b17..cf8e776 100644
> > --- a/xen/arch/x86/domain_build.c
> > +++ b/xen/arch/x86/domain_build.c
> > @@ -1500,7 +1500,9 @@ int __init construct_dom0(
> > 
> >      if ( is_pvh_domain(d) )
> >      {
> > -        /* finally, fixup the page table, replacing mfns with pfns */
> > +   d->need_iommu = 1;
> > +
> > +   /* finally, fixup the page table, replacing mfns with pfns */
> >          pvh_fixup_page_tables_for_hap(v, v_start, v_end);
> > 
> >          /* the pt has correct pfn for si, now update the mfn in the p2m */
> > diff --git a/xen/drivers/passthrough/iommu.c
> > b/xen/drivers/passthrough/iommu.c
> > index cc12735..d7012cb 100644
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -154,7 +154,7 @@ void __hwdom_init iommu_hwdom_init(struct domain
> > *d)
> >          return;
> > 
> >      register_keyhandler('o', &iommu_p2m_table);
> > -    d->need_iommu = !!iommu_dom0_strict;
> > +    d->need_iommu |= !!iommu_dom0_strict;
> >      if ( need_iommu(d) && !iommu_use_hap_pt(d) )
> >      {
> >          struct page_info *page;
> > --
> > 2.1.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel