xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, keir@xen.org, Ian.Campbell@citrix.com,
	andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, david.vrabel@citrix.com
Subject: Re: [PATCH] xen: make some constants usable for assembler
Date: Tue, 16 Feb 2016 15:10:25 +0100	[thread overview]
Message-ID: <56C32DD1.8080204@suse.com> (raw)
In-Reply-To: <56C33A9402000078000D2A9A@suse.com>

On 16/02/16 15:04, Jan Beulich wrote:
>>>> On 16.02.16 at 14:02, <JGross@suse.com> wrote:
>> Some constants defined in xen/include/public/xen.h are not usable in
>> assembler sources as they are either defined with "U" or "UL" suffixes
>> or they are inside #ifndef __ASSEMBLY__ areas.
>>
>> Change this as grub2 could make use of those definitions.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>>  xen/include/public/xen.h | 58 ++++++++++++++++++++++++++----------------------
>>  1 file changed, 31 insertions(+), 27 deletions(-)
>>
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 7b629b1..e29a12a 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -52,6 +52,19 @@ DEFINE_XEN_GUEST_HANDLE(void);
>>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
>>  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>>  DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>> +
>> +/* Turn a plain number into a C unsigned (long) constant. */
>> +#define __mk_unsigned(x)      x ## U
>> +#define __mk_unsigned_long(x) x ## UL
>> +#define mk_unsigned(x)        __mk_unsigned(x)
>> +#define mk_unsigned_long(x)   __mk_unsigned_long(x)
>> +
>> +#else
>> +
>> +/* In assembly code we cannot use C numeric constant suffixes. */
>> +#define mk_unsigned(x)      x
>> +#define mk_unsigned_long(x) x
>> +
>>  #endif
> 
> I realize that you're just moving up the mis-named
> mk_unsigned_long(). That alone I guess we'd have to tolerate, but
> since you also add another variant thereof, the name space issue
> needs fixing imo (even more so since they can't be #undef-d at the
> end of the header): Both should carry Xen in their name in some
> way. Maybe xen_mk_uint() and xen_mk_ulong()?

I'm fine with this.

> 
>> @@ -451,13 +464,13 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>>  /* When specifying UVMF_MULTI, also OR in a pointer to a CPU bitmap.   */
>>  /* UVMF_LOCAL is merely UVMF_MULTI with a NULL bitmap pointer.         */
>>  /* ` enum uvm_flags { */
>> -#define UVMF_NONE               (0UL<<0) /* No flushing at all.   */
>> -#define UVMF_TLB_FLUSH          (1UL<<0) /* Flush entire TLB(s).  */
>> -#define UVMF_INVLPG             (2UL<<0) /* Flush only one entry. */
>> -#define UVMF_FLUSHTYPE_MASK     (3UL<<0)
>> -#define UVMF_MULTI              (0UL<<2) /* Flush subset of TLBs. */
>> -#define UVMF_LOCAL              (0UL<<2) /* Flush local TLB.      */
>> -#define UVMF_ALL                (1UL<<2) /* Flush all TLBs.       */
>> +#define UVMF_NONE            mk_unsigned_long(0<<0) /* No flushing at all.   */
>> +#define UVMF_TLB_FLUSH       mk_unsigned_long(1<<0) /* Flush entire TLB(s).  */
>> +#define UVMF_INVLPG          mk_unsigned_long(2<<0) /* Flush only one entry. */
>> +#define UVMF_FLUSHTYPE_MASK  mk_unsigned_long(3<<0)
>> +#define UVMF_MULTI           mk_unsigned_long(0<<2) /* Flush subset of TLBs. */
>> +#define UVMF_LOCAL           mk_unsigned_long(0<<2) /* Flush local TLB.      */
>> +#define UVMF_ALL             mk_unsigned_long(1<<2) /* Flush all TLBs.       */
> 
> These all look wrong - I think you mean
> 
> #define UVMF_ALL             (mk_unsigned_long(1)<<2)
> 
> etc, even if the difference is benign.

Oops, you are right. Sorry.

> 
>> @@ -504,15 +517,11 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>>  #define MAX_VMASST_TYPE                  3
>>  #endif
>>  
>> -#ifndef __ASSEMBLY__
>> -
>> -typedef uint16_t domid_t;
>> -
>>  /* Domain ids >= DOMID_FIRST_RESERVED cannot be used for ordinary domains. 
>> */
>> -#define DOMID_FIRST_RESERVED (0x7FF0U)
>> +#define DOMID_FIRST_RESERVED mk_unsigned(0x7FF0)
>>  
>>  /* DOMID_SELF is used in certain contexts to refer to oneself. */
>> -#define DOMID_SELF (0x7FF0U)
>> +#define DOMID_SELF           mk_unsigned(0x7FF0)
>>  
>>  /*
>>   * DOMID_IO is used to restrict page-table updates to mapping I/O memory.
>> @@ -523,7 +532,7 @@ typedef uint16_t domid_t;
>>   * This only makes sense in MMUEXT_SET_FOREIGNDOM, but in that context can
>>   * be specified by any calling domain.
>>   */
>> -#define DOMID_IO   (0x7FF1U)
>> +#define DOMID_IO             mk_unsigned(0x7FF1)
>>  
>>  /*
>>   * DOMID_XEN is used to allow privileged domains to map restricted parts of
>> @@ -531,17 +540,21 @@ typedef uint16_t domid_t;
>>   * This only makes sense in MMUEXT_SET_FOREIGNDOM, and is only permitted if
>>   * the caller is privileged.
>>   */
>> -#define DOMID_XEN  (0x7FF2U)
>> +#define DOMID_XEN            mk_unsigned(0x7FF2)
>>  
>>  /*
>>   * DOMID_COW is used as the owner of sharable pages */
>> -#define DOMID_COW  (0x7FF3U)
>> +#define DOMID_COW            mk_unsigned(0x7FF3)
>>  
>>  /* DOMID_INVALID is used to identify pages with unknown owner. */
>> -#define DOMID_INVALID (0x7FF4U)
>> +#define DOMID_INVALID        mk_unsigned(0x7FF4)
>>  
>>  /* Idle domain. */
>> -#define DOMID_IDLE (0x7FFFU)
>> +#define DOMID_IDLE           mk_unsigned(0x7FFF)
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +typedef uint16_t domid_t;
> 
> It's hard to see why domain IDs would be needed in assembly code,
> but well ...

grub2 does: it is calling __HYPERVISOR_mmuext_op with DOMID_SELF from
assembly for activating the loaded kernel with it's new page tables.


Juergen

      parent reply	other threads:[~2016-02-16 14:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 13:02 [PATCH] xen: make some constants usable for assembler Juergen Gross
2016-02-16 14:04 ` Jan Beulich
     [not found] ` <56C33A9402000078000D2A9A@suse.com>
2016-02-16 14:10   ` Juergen Gross [this message]

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=56C32DD1.8080204@suse.com \
    --to=jgross@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --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 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).