xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: mpohlack@amazon.de, Ross Lagerwall <ross.lagerwall@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Jan Beulich <JBeulich@suse.com>,
	sasha.levin@oracle.com
Subject: Re: [PATCH v7 07/24] x86/mm: Introduce modify_xen_mappings()
Date: Mon, 11 Apr 2016 14:00:03 +0100	[thread overview]
Message-ID: <570B9FD3.1060208@citrix.com> (raw)
In-Reply-To: <CAFLBxZYrLdvvxUi_1iM_K44DzUjWSBmMgtPA2QMqR4fSBU9+Aw@mail.gmail.com>

On 11/04/16 13:51, George Dunlap wrote:
> On Sun, Apr 10, 2016 at 10:14 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> From: Andrew Cooper <andrew.cooper3@citrix.com>
>>
>> To simply change the permissions on existing Xen mappings.  The existing
>> destroy_xen_mappings() is altered to support a change the PTE permissions.
>>
>> A new destroy_xen_mappings() is introduced, as the special case of not passing
>> _PAGE_PRESENT to modify_xen_mappings().
> This part looks correct to me.
>
>> As cleanup (and an ideal functional test), the boot logic which remaps Xen's
>> code and data with reduced permissions is altered to use
>> modify_xen_mappings(), rather than map_pages_to_xen() passing the same mfn's
>> back in.
> This seems like a very good idea; I've just got one comment...
>
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index 22dc148..b867242 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1220,23 +1220,19 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>      if ( !using_2M_mapping() )
>>      {
>>          /* Mark .text as RX (avoiding the first 2M superpage). */
>> -        map_pages_to_xen(XEN_VIRT_START + MB(2),
>> -                         PFN_DOWN(__pa(XEN_VIRT_START + MB(2))),
>> -                         PFN_DOWN(__2M_text_end -
>> -                                  (const char *)(XEN_VIRT_START + MB(2))),
>> -                         PAGE_HYPERVISOR_RX);
>> +        modify_xen_mappings(XEN_VIRT_START + MB(2),
>> +                            (unsigned long)&__2M_text_end,
>> +                            _PAGE_PRESENT);
>>
>>          /* Mark .rodata as RO. */
>> -        map_pages_to_xen((unsigned long)&__2M_rodata_start,
>> -                         PFN_DOWN(__pa(__2M_rodata_start)),
>> -                         PFN_DOWN(__2M_rodata_end - __2M_rodata_start),
>> -                         PAGE_HYPERVISOR_RO);
>> +        modify_xen_mappings((unsigned long)&__2M_rodata_start,
>> +                            (unsigned long)&__2M_rodata_end,
>> +                            _PAGE_NX | _PAGE_PRESENT);
>>
>>          /* Mark .data and .bss as RW. */
>> -        map_pages_to_xen((unsigned long)&__2M_rwdata_start,
>> -                         PFN_DOWN(__pa(__2M_rwdata_start)),
>> -                         PFN_DOWN(__2M_rwdata_end - __2M_rwdata_start),
>> -                         PAGE_HYPERVISOR_RW);
>> +        modify_xen_mappings((unsigned long)&__2M_rwdata_start,
>> +                            (unsigned long)&__2M_rwdata_end,
>> +                            _PAGE_NX | _PAGE_RW | _PAGE_PRESENT);
> The only thing here is that you're changing from the centrally-defined
> PAGE_HYPERVISOR_$TYPE flags to what might be called "magic
> combinations" of flags.  I realize this is because
> modify_xen_mappings() only allows you to pass RW, PRESENT, and NX, but
> it's still somewhat sub-optimal.
>
> Alternatives that come to mind:
> 1. Mask out the other bits at the caller (i.e., PAGE_HYPERVISOR_RX &
> MAP_PAGES_MASK)
> 2. Have modify_xen_mappings() filter out the bits it doesn't want to change
> 3. Extend modify_xen_mappings() to be able to modify other bits.
> 4. Have modify_xen_mappings() assert that the only bits which are
> *changing* are the FLAGS_MASK bits
>
> Thoughts?

I suppose I could change the entry requirements and have "nf &=
FLAGS_MASK" rather than the ASSERT()?

That would allow the caller to pass the regular PAGE_HYPERVISOR_xxx,
which I guess is what you mean by 2)

1) is a little nastly. 3) is hard.  Most other bits you can't safely do
blanket changes like this with.  4 is not possible).  Over the range you
might have different caching, different A/D bits or different global
settings, which want to be kept as-are.

~Andrew

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

  reply	other threads:[~2016-04-11 13:00 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-10 21:14 [PATCH v7] xSplice v1 design and implementation Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 01/24] xsplice: Design document Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 02/24] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 03/24] libxc: Implementation of XEN_XSPLICE_op in libxc Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 04/24] xen-xsplice: Tool to manipulate xsplice payloads Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 05/24] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 06/24] arm/x86/vmap: Add vmalloc_xen, vfree_xen and vm_init_type Konrad Rzeszutek Wilk
2016-04-11  9:39   ` Andrew Cooper
2016-04-11 13:29     ` Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 07/24] x86/mm: Introduce modify_xen_mappings() Konrad Rzeszutek Wilk
2016-04-11 12:51   ` George Dunlap
2016-04-11 13:00     ` Andrew Cooper [this message]
2016-04-11 14:04     ` [PATCH v7.1 " Andrew Cooper
2016-04-11 15:21       ` George Dunlap
2016-04-11 17:18       ` Jan Beulich
2016-04-11 17:33         ` Andrew Cooper
2016-04-11 17:46         ` [PATCH v7.2 " Andrew Cooper
2016-04-11 17:54           ` Jan Beulich
2016-04-12  9:08             ` Andrew Cooper
2016-04-10 21:14 ` [PATCH v7 08/24] xsplice: Add helper elf routines Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 09/24] xsplice: Implement payload loading Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 10/24] xsplice: Implement support for applying/reverting/replacing patches Konrad Rzeszutek Wilk
2016-04-11 10:14   ` Andrew Cooper
2016-04-11 13:29     ` Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 11/24] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version' Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 12/24] xsplice, symbols: Implement symbol name resolution on address Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 13/24] x86, xsplice: Print payload's symbol name and payload name in backtraces Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 14/24] xsplice: Add support for bug frames Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 15/24] xsplice: Add support for exception tables Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 16/24] xsplice: Add support for alternatives Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 17/24] build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
2016-04-11 12:17   ` Andrew Cooper
2016-04-11 13:31     ` Konrad Rzeszutek Wilk
2016-04-11 13:35       ` Andrew Cooper
2016-04-10 21:14 ` [PATCH v7 18/24] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 19/24] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 20/24] xsplice: Print build_id in keyhandler and on bootup Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 21/24] xsplice: Stacking build-id dependency checking Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 22/24] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 23/24] xsplice: Prevent duplicate payloads from being loaded Konrad Rzeszutek Wilk
2016-04-10 21:14 ` [PATCH v7 24/24] MAINTAINERS/xsplice: Add myself and Ross as the maintainers Konrad Rzeszutek Wilk
2016-04-11 14:32 ` [PATCH v7] xSplice v1 design and implementation Konrad Rzeszutek Wilk
2016-04-11 15:43   ` Konrad Rzeszutek Wilk
2016-04-12  8:10     ` Ross Lagerwall
2016-04-12 20:59   ` Konrad Rzeszutek Wilk
2016-04-12 20:59     ` [PATCH v7 25/24] symbols/xsplice: Implement fast symbol names -> virtual addresses lookup Konrad Rzeszutek Wilk
2016-04-13  2:03       ` Konrad Rzeszutek Wilk
2016-04-13  2:17         ` Konrad Rzeszutek Wilk

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=570B9FD3.1060208@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=mpohlack@amazon.de \
    --cc=ross.lagerwall@citrix.com \
    --cc=sasha.levin@oracle.com \
    --cc=xen-devel@lists.xenproject.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 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).