x86: mapping from Dom0 to DomU

x86: mapping from Dom0 to DomU

[Oleksandr Andrushchenko]

Hi, all!

I am working on a zero-copy scenario for x86

and for that I am mapping pages from Dom0 to DomU

(yes, I know there are at least security concerns).

Everything is just fine, e.g. I can map grefs from Dom0 in DomU

with gnttab_map_refs, until I try to mmap those pages in DomU

with vm_insert_page and Xen starts to complain:

(XEN) mm.c:989:d1v0 pg_owner 1 l1e_owner 1, but real_pg_owner 0
(XEN) mm.c:1061:d1v0 Error getting mfn 20675a (pfn 1ac8de) from L1 entry 
800000020675a027 for l1e_owner=1, pg_owner=1

So, the offending(?) code is at [1] which doesn't allow the mapping

I want. When removed with

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f35e3116bb25..aeb93be8b529 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -980,6 +980,7 @@ get_page_from_l1e(
           * dom0, until pvfb supports granted mappings. At that time this
           * minor hack can go away.
           */
+#if 0
          if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
               xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
          {
@@ -988,6 +989,7 @@ get_page_from_l1e(
real_pg_owner?real_pg_owner->domain_id:-1);
              goto could_not_pin;
          }
+#endif
          pg_owner = real_pg_owner;
      }
I can successfully mmap and use pages from Dom0 in DomU.

Can anybody please explain why the use-case I am trying to implement

is treated as error from Xen's POV and what would be the right way to

do so?

Thank you,

Oleksandr

[1] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/mm.c;h=96bc28065076cb5c742a00fa0a5ffe07e9cd6e7c;hb=HEAD#l1001


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

Re: x86: mapping from Dom0 to DomU

[Jan Beulich]

>>> On 21.04.17 at 15:04, <andr2000@gmail.com> wrote:
> Hi, all!
> 
> I am working on a zero-copy scenario for x86
> and for that I am mapping pages from Dom0 to DomU
> (yes, I know there are at least security concerns).
> 
> Everything is just fine, e.g. I can map grefs from Dom0 in DomU
> with gnttab_map_refs, until I try to mmap those pages in DomU
> with vm_insert_page and Xen starts to complain:
> 
> (XEN) mm.c:989:d1v0 pg_owner 1 l1e_owner 1, but real_pg_owner 0
> (XEN) mm.c:1061:d1v0 Error getting mfn 20675a (pfn 1ac8de) from L1 entry 
> 800000020675a027 for l1e_owner=1, pg_owner=1
> 
> So, the offending(?) code is at [1] which doesn't allow the mapping
> I want. When removed with
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index f35e3116bb25..aeb93be8b529 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -980,6 +980,7 @@ get_page_from_l1e(
>            * dom0, until pvfb supports granted mappings. At that time this
>            * minor hack can go away.
>            */
> +#if 0
>           if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
>                xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
>           {
> @@ -988,6 +989,7 @@ get_page_from_l1e(
> real_pg_owner?real_pg_owner->domain_id:-1);
>               goto could_not_pin;
>           }
> +#endif
>           pg_owner = real_pg_owner;
>       }
> I can successfully mmap and use pages from Dom0 in DomU.
> 
> Can anybody please explain why the use-case I am trying to implement
> is treated as error from Xen's POV and what would be the right way to
> do so?

Granted pages can be mapped only through the grant-table hypercall,
see public/grant_table.h's explanation of GNTMAP_host_map used
with out without GNTMAP_contains_pte. Other mapping attempts
have to be refused, or else the accounting done by the grant table
code would be undermined.

Jan


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

Re: x86: mapping from Dom0 to DomU

[Oleksandr Andrushchenko]

Hi, Jan!

On 04/21/2017 06:55 PM, Jan Beulich wrote:
>>>> On 21.04.17 at 15:04, <andr2000@gmail.com> wrote:
>> Hi, all!
>>
>> I am working on a zero-copy scenario for x86
>> and for that I am mapping pages from Dom0 to DomU
>> (yes, I know there are at least security concerns).
>>
>> Everything is just fine, e.g. I can map grefs from Dom0 in DomU
>> with gnttab_map_refs, until I try to mmap those pages in DomU
>> with vm_insert_page and Xen starts to complain:
>>
>> (XEN) mm.c:989:d1v0 pg_owner 1 l1e_owner 1, but real_pg_owner 0
>> (XEN) mm.c:1061:d1v0 Error getting mfn 20675a (pfn 1ac8de) from L1 entry
>> 800000020675a027 for l1e_owner=1, pg_owner=1
>>
>> So, the offending(?) code is at [1] which doesn't allow the mapping
>> I want. When removed with
>>
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index f35e3116bb25..aeb93be8b529 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -980,6 +980,7 @@ get_page_from_l1e(
>>             * dom0, until pvfb supports granted mappings. At that time this
>>             * minor hack can go away.
>>             */
>> +#if 0
>>            if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
>>                 xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
>>            {
>> @@ -988,6 +989,7 @@ get_page_from_l1e(
>> real_pg_owner?real_pg_owner->domain_id:-1);
>>                goto could_not_pin;
>>            }
>> +#endif
>>            pg_owner = real_pg_owner;
>>        }
>> I can successfully mmap and use pages from Dom0 in DomU.
>>
>> Can anybody please explain why the use-case I am trying to implement
>> is treated as error from Xen's POV and what would be the right way to
>> do so?
> Granted pages can be mapped only through the grant-table hypercall,
If this is gnttab_map_refs call you mean then, yes,
I do that to map grefs
> see public/grant_table.h's explanation of GNTMAP_host_map used
> with out without GNTMAP_contains_pte.
I know about these options and according to [1] I can use
option to map with "host virtual address", e.g. without 
GNTMAP_contains_pte flag, because GNTMAP_contains_pte requires me to 
provide machine address which I don't want.
>   Other mapping attempts
> have to be refused, or else the accounting done by the grant table
> code would be undermined.
So, either I didn't understand what you mean or was not clear
to explain that I see no problem while mapping grefs with
gnttab_map_refs, but see the problem when vm_insert_page
is called to mmap the pages into user-space (vm_insert_page
internally does set_pte_at which it silently fails, but kernel
knows nothing about that because no error reported [2]).
> Jan
>
Thank you,
Oleksandr

[1] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/grant_table.h;h=e5f04ec57c5bd590b6c81799ee01028c3512aacf;hb=refs/heads/master#l331
[2] http://lxr.free-electrons.com/source/mm/memory.c#L1569

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

Re: x86: mapping from Dom0 to DomU

[Jan Beulich]

>>> On 24.04.17 at 08:10, <andr2000@gmail.com> wrote:
> On 04/21/2017 06:55 PM, Jan Beulich wrote:
>>>>> On 21.04.17 at 15:04, <andr2000@gmail.com> wrote:
>>> I am working on a zero-copy scenario for x86
>>> and for that I am mapping pages from Dom0 to DomU
>>> (yes, I know there are at least security concerns).
>>>
>>> Everything is just fine, e.g. I can map grefs from Dom0 in DomU
>>> with gnttab_map_refs, until I try to mmap those pages in DomU
>>> with vm_insert_page and Xen starts to complain:
>>>
>>> (XEN) mm.c:989:d1v0 pg_owner 1 l1e_owner 1, but real_pg_owner 0
>>> (XEN) mm.c:1061:d1v0 Error getting mfn 20675a (pfn 1ac8de) from L1 entry
>>> 800000020675a027 for l1e_owner=1, pg_owner=1
>>>
>>> Can anybody please explain why the use-case I am trying to implement
>>> is treated as error from Xen's POV and what would be the right way to
>>> do so?
>> Granted pages can be mapped only through the grant-table hypercall,
> If this is gnttab_map_refs call you mean then, yes,
> I do that to map grefs
>> see public/grant_table.h's explanation of GNTMAP_host_map used
>> with out without GNTMAP_contains_pte.
> I know about these options and according to [1] I can use
> option to map with "host virtual address", e.g. without 
> GNTMAP_contains_pte flag, because GNTMAP_contains_pte requires me to 
> provide machine address which I don't want.
>>   Other mapping attempts
>> have to be refused, or else the accounting done by the grant table
>> code would be undermined.
> So, either I didn't understand what you mean or was not clear
> to explain that I see no problem while mapping grefs with
> gnttab_map_refs, but see the problem when vm_insert_page
> is called to mmap the pages into user-space (vm_insert_page
> internally does set_pte_at which it silently fails, but kernel
> knows nothing about that because no error reported [2]).

Indeed you seem to have misunderstood: _All_ mappings of the
granted page need to be done using the grant table hypercalls,
not just the initial one. set_pte() establishes a second mapping,
and that does not use the grant table op.

Jan


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

Re: x86: mapping from Dom0 to DomU

[Oleksandr Andrushchenko]

On 04/24/2017 09:43 AM, Jan Beulich wrote:
>>>> On 24.04.17 at 08:10, <andr2000@gmail.com> wrote:
>> On 04/21/2017 06:55 PM, Jan Beulich wrote:
>>>>>> On 21.04.17 at 15:04, <andr2000@gmail.com> wrote:
>>>> I am working on a zero-copy scenario for x86
>>>> and for that I am mapping pages from Dom0 to DomU
>>>> (yes, I know there are at least security concerns).
>>>>
>>>> Everything is just fine, e.g. I can map grefs from Dom0 in DomU
>>>> with gnttab_map_refs, until I try to mmap those pages in DomU
>>>> with vm_insert_page and Xen starts to complain:
>>>>
>>>> (XEN) mm.c:989:d1v0 pg_owner 1 l1e_owner 1, but real_pg_owner 0
>>>> (XEN) mm.c:1061:d1v0 Error getting mfn 20675a (pfn 1ac8de) from L1 entry
>>>> 800000020675a027 for l1e_owner=1, pg_owner=1
>>>>
>>>> Can anybody please explain why the use-case I am trying to implement
>>>> is treated as error from Xen's POV and what would be the right way to
>>>> do so?
>>> Granted pages can be mapped only through the grant-table hypercall,
>> If this is gnttab_map_refs call you mean then, yes,
>> I do that to map grefs
>>> see public/grant_table.h's explanation of GNTMAP_host_map used
>>> with out without GNTMAP_contains_pte.
>> I know about these options and according to [1] I can use
>> option to map with "host virtual address", e.g. without
>> GNTMAP_contains_pte flag, because GNTMAP_contains_pte requires me to
>> provide machine address which I don't want.
>>>    Other mapping attempts
>>> have to be refused, or else the accounting done by the grant table
>>> code would be undermined.
>> So, either I didn't understand what you mean or was not clear
>> to explain that I see no problem while mapping grefs with
>> gnttab_map_refs, but see the problem when vm_insert_page
>> is called to mmap the pages into user-space (vm_insert_page
>> internally does set_pte_at which it silently fails, but kernel
>> knows nothing about that because no error reported [2]).
> Indeed you seem to have misunderstood: _All_ mappings of the
> granted page need to be done using the grant table hypercalls,
> not just the initial one. set_pte() establishes a second mapping,
> and that does not use the grant table op.
>
> Jan
>
thank you,
it seems like I'll have to duplicate code from gntdev [1],
so my use-case also works on x86, not only ARM

[1] http://lxr.free-electrons.com/source/drivers/xen/gntdev.c#L981

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