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:42 +0000, Jan Beulich wrote:
> >>> On 04.12.13 at 11:39, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > 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.
> 
> But iirc Razvan started out with wanting to map PFNs inside a
> Windows guest.

Correct. The check for mapping domain 0's 1:1 map is overly broad I
think, and erroneously prevents a domU from mapping a foreign PFN < 1M.

Ian.


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