From: Jan Beulich <jbeulich@suse.com>
To: Wei Liu <wl@xen.org>
Cc: "Wei Liu" <liuwe@microsoft.com>, "Paul Durrant" <paul@xen.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Michael Kelley" <mikelley@microsoft.com>,
"Ross Lagerwall" <ross.lagerwall@citrix.com>,
"Xen Development List" <xen-devel@lists.xenproject.org>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/7] x86: provide executable fixmap facility
Date: Tue, 28 Jan 2020 16:38:42 +0100 [thread overview]
Message-ID: <345b5392-2f89-0a37-bac8-e88b0714028c@suse.com> (raw)
In-Reply-To: <20200128151520.al3xp7yxntdpq5el@debian>
On 28.01.2020 16:15, Wei Liu wrote:
> On Thu, Jan 23, 2020 at 12:04:00PM +0100, Jan Beulich wrote:
>> On 22.01.2020 21:23, Wei Liu wrote:
>>> This allows us to set aside some address space for executable mapping.
>>> This fixed map range starts from XEN_VIRT_END so that it is within reach
>>> of the .text section.
>>>
>>> Shift the percpu stub range and livepatch range accordingly.
>>
>> Hmm, the livepatch range gets shrunk, not shifted, but yes. Is there
>> a particular reason why you move the stubs area down? It looks as if
>> the patch would be smaller overall if you didn't. (Possibly down
>> the road the stubs area could be made part of the FIXADDR_X range
>> anyway.)
>
> I think having a well-known fixed address is more useful for debugging.
>
> Going the other way around would mean the hypercall page location
> becomes dependent on the number of CPUs configured.
Depending on how future insertions are done into
enum fixed_addresses_x, the address also won't be "well-known fixed".
>>> --- a/xen/include/asm-x86/fixmap.h
>>> +++ b/xen/include/asm-x86/fixmap.h
>>> @@ -15,6 +15,9 @@
>>> #include <asm/page.h>
>>>
>>> #define FIXADDR_TOP (VMAP_VIRT_END - PAGE_SIZE)
>>> +#define FIXADDR_X_TOP (XEN_VIRT_END - PAGE_SIZE)
>>> +/* This constant is derived from enum fixed_addresses_x below */
>>> +#define MAX_FIXADDR_X_SIZE (2 << PAGE_SHIFT)
>>
>> If this can't be properly derived, then a BUILD_BUG_ON() is needed.
>> But didn't we discuss on irc already possible approaches of how to
>> derive it from the enum? Did none of this work?
>
> The only option I remember discussing was to define macros instead of
> using enum. I said at the time at would make us lose the ability to
> dynamically size this area.
>
> If there are other ways that I missed, let me know.
I seem to recall recommending to export absolute symbols from
assembly code. The question is how easily usable they would
be from C, or how clumsy the resulting code would look.
>>> @@ -89,6 +92,31 @@ static inline unsigned long virt_to_fix(const unsigned long vaddr)
>>> return __virt_to_fix(vaddr);
>>> }
>>>
>>> +enum fixed_addresses_x {
>>> + /* Index 0 is reserved since fix_x_to_virt(0) == FIXADDR_X_TOP. */
>>> + FIX_X_RESERVED,
>>> +#ifdef CONFIG_HYPERV_GUEST
>>> + FIX_X_HYPERV_HCALL,
>>> +#endif
>>> + __end_of_fixed_addresses_x
>>> +};
>>> +
>>> +#define FIXADDR_X_SIZE (__end_of_fixed_addresses_x << PAGE_SHIFT)
>>> +#define FIXADDR_X_START (FIXADDR_X_TOP - FIXADDR_X_SIZE)
>>> +
>>> +extern void __set_fixmap_x(
>>> + enum fixed_addresses_x idx, unsigned long mfn, unsigned long flags);
>>> +
>>> +#define set_fixmap_x(idx, phys) \
>>> + __set_fixmap_x(idx, (phys)>>PAGE_SHIFT, PAGE_HYPERVISOR_RX | MAP_SMALL_PAGES)
>>
>> Can't __set_fixmap() be used here, making its implementation derive
>> which one is mean from whether _PAGE_NX is set in the passed in flags?
>
> __set_fixmap and __set_fixmap_x take different enum types for their
> first argument. I would prefer type safety and explicitness here.
Well, okay then. Duplication like this simply makes me a little
nervous, and even more so when it extends our set of name space
violations.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-28 15:39 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 20:23 [Xen-devel] [PATCH v4 0/7] More Hyper-V infrastructure Wei Liu
2020-01-22 20:23 ` [Xen-devel] [PATCH v4 1/7] x86: provide executable fixmap facility Wei Liu
2020-01-22 20:56 ` Andrew Cooper
2020-01-28 15:09 ` Wei Liu
2020-01-23 11:04 ` Jan Beulich
2020-01-28 15:15 ` Wei Liu
2020-01-28 15:38 ` Jan Beulich [this message]
2020-01-29 14:42 ` Wei Liu
2020-01-29 14:59 ` Jan Beulich
2020-01-29 16:37 ` Wei Liu
2020-01-22 20:23 ` [Xen-devel] [PATCH v4 2/7] x86/hyperv: setup hypercall page Wei Liu
2020-01-22 21:31 ` Andrew Cooper
2020-01-23 10:04 ` Jan Beulich
2020-01-28 15:19 ` Wei Liu
2020-01-23 1:35 ` Michael Kelley
2020-01-28 15:20 ` Wei Liu
2020-01-23 11:18 ` Jan Beulich
2020-01-23 15:20 ` Michael Kelley
2020-01-28 15:30 ` Wei Liu
2020-01-28 15:41 ` Jan Beulich
2020-01-22 20:23 ` [Xen-devel] [PATCH v4 3/7] x86/hyperv: provide Hyper-V hypercall functions Wei Liu
2020-01-22 21:57 ` Andrew Cooper
2020-01-23 10:13 ` Jan Beulich
2020-01-29 18:25 ` Wei Liu
2020-01-23 11:28 ` Jan Beulich
2020-01-29 18:37 ` Wei Liu
2020-01-30 8:12 ` Jan Beulich
2020-01-30 11:55 ` Wei Liu
2020-01-22 20:23 ` [Xen-devel] [PATCH v4 4/7] DO NOT APPLY: x86/hyperv: issue an hypercall Wei Liu
2020-01-22 20:23 ` [Xen-devel] [PATCH v4 5/7] x86/hyperv: provide percpu hypercall input page Wei Liu
2020-01-23 15:45 ` Jan Beulich
2020-01-28 15:50 ` Wei Liu
2020-01-28 16:15 ` Jan Beulich
2020-01-28 16:52 ` Wei Liu
2020-01-22 20:23 ` [Xen-devel] [PATCH v4 6/7] x86/hyperv: retrieve vp_index from Hyper-V Wei Liu
2020-01-23 15:48 ` Jan Beulich
2020-01-28 15:55 ` Wei Liu
2020-01-28 16:18 ` Jan Beulich
2020-01-28 16:33 ` Durrant, Paul
2020-01-28 16:53 ` Wei Liu
2020-01-28 17:01 ` Durrant, Paul
2020-01-22 20:23 ` [Xen-devel] [PATCH v4 7/7] x86/hyperv: setup VP assist page Wei Liu
2020-01-22 22:05 ` Andrew Cooper
2020-01-23 15:50 ` Jan Beulich
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=345b5392-2f89-0a37-bac8-e88b0714028c@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=liuwe@microsoft.com \
--cc=mikelley@microsoft.com \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--cc=ross.lagerwall@citrix.com \
--cc=wl@xen.org \
--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).