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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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