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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-12-04 at 10:31 +0000, Jan Beulich wrote:
> >>> On 04.12.13 at 11:24, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
> >>> wrote:
> > On 12/03/2013 08:07 PM, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Dec 03, 2013 at 06:36:48PM +0100, Tomasz Wroblewski wrote:
> >>> On 12/03/2013 05:09 PM, Ian Campbell wrote:
> >>>> On Tue, 2013-12-03 at 17:59 +0200, Razvan Cojocaru wrote:
> >>>>>>> The Linux domU is perfectly able to map (using xc_map_foreign_range())
> >>>>>>> pages from the Windows domU, except for pages below 1M.
> >>>>>>
> >>>>>> With no XSM how does it have the privilege to do this?
> >>>>>
> >>>>> What I meant to say is that the domU is being allowed to do this sort
> >>>>> of thing, i.e. the problem is definitely not caused by XSM.
> >>>>
> >>>> OK, so XSM is involved but you are 101% certain that it is not
> >>>> preventing the mappings?
> >>>>
> >>> 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).
> 
> I've been following this thread, with each new response making it
> less clear what is being talked about here: The original request
> was to map the MFN backing a guest's PFN below 1M. That says
> nothing about the value of the MFN (and iirc Xen doesn't allocate
> MFNs from the first 1M to any guest on x86). Yet the safe guard
> ought to be dealing with a specific MFN range only.
> 
> Can someone explain what I'm missing here?

I believe the intention is to catch domain 0's 1:1 mapping of the first
1M of host RAM.

Ian.


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