From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Razvan Cojocaru <rzvncj@gmail.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Why does xc_map_foreign_range() refuse to map pfns below 1M from a domU
Date: Tue, 3 Dec 2013 18:36:48 +0100 [thread overview]
Message-ID: <529E16B0.5010104@citrix.com> (raw)
In-Reply-To: <1386086974.13256.60.camel@kazak.uk.xensource.com>
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.
I think the goal of check was to only stop <1M mapping of its own memory in order to stop pvops kernel boot messing it, but by ricochet it
also prevents mapping of foreign domain <1M ranges...
next prev parent reply other threads:[~2013-12-03 17:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 15:06 Why does xc_map_foreign_range() refuse to map pfns below 1M from a domU Razvan Cojocaru
2013-12-03 15:51 ` Ian Campbell
2013-12-03 15:59 ` Razvan Cojocaru
2013-12-03 16:09 ` Ian Campbell
2013-12-03 17:36 ` Tomasz Wroblewski [this message]
2013-12-03 18:59 ` Razvan Cojocaru
2013-12-03 19:07 ` Konrad Rzeszutek Wilk
2013-12-04 10:24 ` Tomasz Wroblewski
2013-12-04 10:31 ` Jan Beulich
2013-12-04 10:39 ` Ian Campbell
2013-12-04 10:42 ` Jan Beulich
2013-12-04 10:45 ` Ian Campbell
2013-12-04 10:54 ` Jan Beulich
2013-12-04 11:04 ` Ian Campbell
2013-12-04 11:23 ` Tomasz Wroblewski
2013-12-04 11:36 ` Jan Beulich
2013-12-04 12:01 ` Tomasz Wroblewski
2013-12-04 12:14 ` Jan Beulich
2013-12-04 12:23 ` Ian Campbell
2013-12-04 12:39 ` Jan Beulich
2013-12-04 16:40 ` Konrad Rzeszutek Wilk
2013-12-04 17:16 ` Tomasz Wroblewski
2014-07-08 14:54 ` Mihai Donțu
2013-12-04 11:42 ` Mihai Donțu
2013-12-04 14:19 ` Tomasz Wroblewski
2013-12-04 16:15 ` Mihai Donțu
-- strict thread matches above, loose matches on Subject: below --
2013-12-03 16:18 Razvan Cojocaru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529E16B0.5010104@citrix.com \
--to=tomasz.wroblewski@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=rzvncj@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.