* Linux'es free_initmem() on Xen
@ 2016-02-02 12:44 Jan Beulich
2016-02-02 13:30 ` David Vrabel
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2016-02-02 12:44 UTC (permalink / raw)
To: David Vrabel, Boris Ostrovsky, Konrad Rzeszutek Wilk; +Cc: xen-devel
All,
while looking into some of the DEBUG_WX issues I came across
aforementioned function and started wondering how pv-ops gets
away without the unmapping XenoLinux has always been doing
(in free_init_pages()). Inspecting
/sys/kernel/debug/kernel_page_tables, I indeed see the area
mapped (and even r/w) in both the kernel VA range and the 1:1
mapping. While I could see page table creation code (as being
arch specific) to know of this and update both mappings when
needed (albeit I can't seem to find respective code), I don't think
the balloon driver or code exchanging pages to guarantee
address restrictions can be expected to special case this. For my
education - what am I overlooking (or is there an actual issue)?
Thanks, Jan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux'es free_initmem() on Xen
2016-02-02 12:44 Linux'es free_initmem() on Xen Jan Beulich
@ 2016-02-02 13:30 ` David Vrabel
2016-02-02 14:10 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: David Vrabel @ 2016-02-02 13:30 UTC (permalink / raw)
To: Jan Beulich, David Vrabel, Boris Ostrovsky, Konrad Rzeszutek Wilk
Cc: xen-devel
On 02/02/16 12:44, Jan Beulich wrote:
> All,
>
> while looking into some of the DEBUG_WX issues I came across
> aforementioned function and started wondering how pv-ops gets
> away without the unmapping XenoLinux has always been doing
> (in free_init_pages()).
Um. I'm not sure why you think something needs to be unmapped. This is
freeing the pages back to the page allocator -- thus the pages still
need to be mapped.
David
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux'es free_initmem() on Xen
2016-02-02 13:30 ` David Vrabel
@ 2016-02-02 14:10 ` Jan Beulich
2016-02-02 15:09 ` David Vrabel
0 siblings, 1 reply; 5+ messages in thread
From: Jan Beulich @ 2016-02-02 14:10 UTC (permalink / raw)
To: David Vrabel; +Cc: xen-devel, Boris Ostrovsky
>>> On 02.02.16 at 14:30, <david.vrabel@citrix.com> wrote:
> On 02/02/16 12:44, Jan Beulich wrote:
>> All,
>>
>> while looking into some of the DEBUG_WX issues I came across
>> aforementioned function and started wondering how pv-ops gets
>> away without the unmapping XenoLinux has always been doing
>> (in free_init_pages()).
>
> Um. I'm not sure why you think something needs to be unmapped. This is
> freeing the pages back to the page allocator -- thus the pages still
> need to be mapped.
In the 1:1 mapping, yes. But the secondary mapping in the kernel
VA range is not needed anymore, and (unless accounted for) would
get in the way of said operations.
Jan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux'es free_initmem() on Xen
2016-02-02 14:10 ` Jan Beulich
@ 2016-02-02 15:09 ` David Vrabel
2016-02-04 7:36 ` Jan Beulich
0 siblings, 1 reply; 5+ messages in thread
From: David Vrabel @ 2016-02-02 15:09 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Boris Ostrovsky
On 02/02/16 14:10, Jan Beulich wrote:
>>>> On 02.02.16 at 14:30, <david.vrabel@citrix.com> wrote:
>> On 02/02/16 12:44, Jan Beulich wrote:
>>> All,
>>>
>>> while looking into some of the DEBUG_WX issues I came across
>>> aforementioned function and started wondering how pv-ops gets
>>> away without the unmapping XenoLinux has always been doing
>>> (in free_init_pages()).
>>
>> Um. I'm not sure why you think something needs to be unmapped. This is
>> freeing the pages back to the page allocator -- thus the pages still
>> need to be mapped.
>
> In the 1:1 mapping, yes. But the secondary mapping in the kernel
> VA range is not needed anymore, and (unless accounted for) would
> get in the way of said operations.
The PMDs are shared between the two mappings. See
xen_setup_kernel_pagetable().
David
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux'es free_initmem() on Xen
2016-02-02 15:09 ` David Vrabel
@ 2016-02-04 7:36 ` Jan Beulich
0 siblings, 0 replies; 5+ messages in thread
From: Jan Beulich @ 2016-02-04 7:36 UTC (permalink / raw)
To: David Vrabel; +Cc: xen-devel, Boris Ostrovsky
>>> On 02.02.16 at 16:09, <david.vrabel@citrix.com> wrote:
> On 02/02/16 14:10, Jan Beulich wrote:
>>>>> On 02.02.16 at 14:30, <david.vrabel@citrix.com> wrote:
>>> On 02/02/16 12:44, Jan Beulich wrote:
>>>> All,
>>>>
>>>> while looking into some of the DEBUG_WX issues I came across
>>>> aforementioned function and started wondering how pv-ops gets
>>>> away without the unmapping XenoLinux has always been doing
>>>> (in free_init_pages()).
>>>
>>> Um. I'm not sure why you think something needs to be unmapped. This is
>>> freeing the pages back to the page allocator -- thus the pages still
>>> need to be mapped.
>>
>> In the 1:1 mapping, yes. But the secondary mapping in the kernel
>> VA range is not needed anymore, and (unless accounted for) would
>> get in the way of said operations.
>
> The PMDs are shared between the two mappings. See
> xen_setup_kernel_pagetable().
I see. While a neat solution of keeping the two in sync, doesn't
this create a small(?) problem, in that it subverts
change_page_attr_set_clr()'s suppression of the 1:1 map
updating when e.g. a kernel or module va range gets just its NX
bit altered (in particular when the bit gets set)?
Jan
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-04 7:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-02 12:44 Linux'es free_initmem() on Xen Jan Beulich
2016-02-02 13:30 ` David Vrabel
2016-02-02 14:10 ` Jan Beulich
2016-02-02 15:09 ` David Vrabel
2016-02-04 7:36 ` Jan Beulich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).