Re: [Xen-devel] Why does xc_map_foreign_range() refuse to map pfns below 1M from a domU

[Mihai DonÈu <mihai.dontu@xxxxxxxxx>]

On Wed, 4 Dec 2013 11:24:21 +0100 Tomasz Wroblewski wrote:
> >> We've ran into this issue in xenclient recently too, when we
> >> finally upgraded stubdomain's kernel to pvops version. It seems
> >> pvops kernel contains safeguard to only allow <1M mappings if it's
> >> dom0 (xen_initial_domain()). This check is placed in
> >> arch/x86/xen/mmu.c:
> >>
> >> static pte_t xen_make_pte(pteval_t pte)
> >> {
> >>          phys_addr_t addr = (pte & PTE_PFN_MASK);
> >>
> >> ...
> >>          /*
> >>           * Unprivileged domains are allowed to do IOMAPpings for
> >>           * PCI passthrough, but not map ISA space.  The ISA
> >>           * mappings are just dummy local mappings to keep other
> >>           * parts of the kernel happy.
> >>           */
> >>          if (unlikely(pte & _PAGE_IOMAP) &&
> >>              (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
> >>                  pte = iomap_pte(pte);
> >>          } else {
> >>                  pte &= ~_PAGE_IOMAP;
> >>                  pte = pte_pfn_to_mfn(pte);
> >>          }
> >>
> >>          return native_make_pte(pte);
> >> }
> >>
> >> We patched this out (in a fugly and probably not very correct way),
> >> for our stubdomain kernel, since we needed our stubdomain qemu vms
> >> to be able to map windows guest <1M range (since qemu needs to be
> >> able to write data and read data there in order to chat with
> >> seabios etc). Maybe Konrad (CC'ed) knows why the check is there in
> >> guest kernel, and a good way to solve this.
> >
> > For PV domU guests the ISA are usually RAM - so you don't want
> > during early bootup of a PV guest for it to scan MFNs it does not
> > have access to. Granted it does not have access to them but it
> > would have the MFNs coded in and any access to that area will
> > result in .. Xen "fixing" up the PTEs (I can't recall exaclty how).
> >
> > If you boot a PV Guest and remove the:
> >               (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
> >
> > do you see anything that in the Xen console?
> >
> I recall I wasn't seeing anything, the pv domU was just hanging super
> early in the boot then. The way we worked around it is via attached
> patch (applied to PV domU's kernel, in our case stubdom hosting qemu
> process). It keeps the <1M safeguard for local mapping but allows
> foreign mappings (detected via _PAGE_SPECIAL flag).
> 
> Razvan, you can try attached patch as well applied to your pv domU
> kernel to see if it helps you.
> 

Razvan and I are working together to find a solution to this. I took
your patch for a spin and while that code path is taken when invoking
xc_map_foreign_range(), the call still fails with EINVAL. I haven't yet
determined if the call stops in the domU kernel or it reaches xen and
gets terminated there. I've tried this on Ubuntu's 3.8. on top of
XenServer's xen-4.3.1.

Thanks,

-- 
Mihai DonÈu

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