Re: linux-next: Tree for Jan 25 (arch/x86/xen/mmu_pv.o)

[Randy Dunlap]

On 1/24/24 19:43, Stephen Rothwell wrote:
> Hi all,
> 
> News: there will be no linux-next release on Friday
> 
> Changes since 20240124:
> 

on x86_64:
when CONFIG_VMCORE_INFO is not set:


ld: arch/x86/xen/mmu_pv.o: in function `paddr_vmcoreinfo_note':
mmu_pv.c:(.text+0x468d): undefined reference to `vmcoreinfo_note'
ld: mmu_pv.c:(.text+0x4699): undefined reference to `vmcoreinfo_note'


Full randconfig file is attached.

-- 
#Randy

config-r5869.gz
Description: application/gzip

Re: [PATCH] xen/xenbus: client: fix kernel-doc comments

[Randy Dunlap]

On 12/7/23 01:27, Juergen Gross wrote:
> On 06.12.23 19:17, Randy Dunlap wrote:
>> Correct function kernel-doc notation to prevent warnings from
>> scripts/kernel-doc.
>>

>>
>> Signed-off-by: Randy Dunlap 
>> Cc: Juergen Gross 
>> Cc: Stefano Stabellini 
>> Cc: Oleksandr Tyshchenko 
>> Cc: xen-devel@lists.xenproject.org
> 
> Reviewed-by: Juergen Gross 
> 
> with one nit below (can be fixed while committing) ...

Ah yes, thanks.

-- 
~Randy

[PATCH] xen/xenbus: client: fix kernel-doc comments

[Randy Dunlap]

Correct function kernel-doc notation to prevent warnings from
scripts/kernel-doc.

xenbus_client.c:134: warning: No description found for return value of 
'xenbus_watch_path'
xenbus_client.c:177: warning: No description found for return value of 
'xenbus_watch_pathfmt'
xenbus_client.c:258: warning: missing initial short description on line:
 * xenbus_switch_state
xenbus_client.c:267: warning: No description found for return value of 
'xenbus_switch_state'
xenbus_client.c:308: warning: missing initial short description on line:
 * xenbus_dev_error
xenbus_client.c:327: warning: missing initial short description on line:
 * xenbus_dev_fatal
xenbus_client.c:350: warning: This comment starts with '/**', but isn't a 
kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Equivalent to xenbus_dev_fatal(dev, err, fmt, args), but helps
xenbus_client.c:457: warning: This comment starts with '/**', but isn't a 
kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Allocate an event channel for the given xenbus_device, assigning the newly
xenbus_client.c:486: warning: expecting prototype for Free an existing event 
channel. Returns 0 on success or(). Prototype was for xenbus_free_evtchn() 
instead
xenbus_client.c:502: warning: missing initial short description on line:
 * xenbus_map_ring_valloc
xenbus_client.c:517: warning: No description found for return value of 
'xenbus_map_ring_valloc'
xenbus_client.c:602: warning: missing initial short description on line:
 * xenbus_unmap_ring
xenbus_client.c:614: warning: No description found for return value of 
'xenbus_unmap_ring'
xenbus_client.c:715: warning: missing initial short description on line:
 * xenbus_unmap_ring_vfree
xenbus_client.c:727: warning: No description found for return value of 
'xenbus_unmap_ring_vfree'
xenbus_client.c:919: warning: missing initial short description on line:
 * xenbus_read_driver_state
xenbus_client.c:926: warning: No description found for return value of 
'xenbus_read_driver_state'

Signed-off-by: Randy Dunlap 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Oleksandr Tyshchenko 
Cc: xen-devel@lists.xenproject.org
---
 drivers/xen/xenbus/xenbus_client.c |   59 +++
 1 file changed, 34 insertions(+), 25 deletions(-)

diff -- a/drivers/xen/xenbus/xenbus_client.c 
b/drivers/xen/xenbus/xenbus_client.c
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -119,11 +119,13 @@ EXPORT_SYMBOL_GPL(xenbus_strstate);
  * @callback: callback to register
  *
  * Register a @watch on the given path, using the given xenbus_watch structure
- * for storage, and the given @callback function as the callback.  Return 0 on
- * success, or -errno on error.  On success, the given @path will be saved as
- * @watch->node, and remains the caller's to free.  On error, @watch->node will
+ * for storage, and the given @callback function as the callback.  On success,
+ * the given @path will be saved as @watch->node, and remains the
+ * caller's to free.  On error, @watch->node will
  * be NULL, the device will switch to %XenbusStateClosing, and the error will
  * be saved in the store.
+ *
+ * Returns: %0 on success or -errno on error
  */
 int xenbus_watch_path(struct xenbus_device *dev, const char *path,
  struct xenbus_watch *watch,
@@ -160,12 +162,14 @@ EXPORT_SYMBOL_GPL(xenbus_watch_path);
  * @pathfmt: format of path to watch
  *
  * Register a watch on the given @path, using the given xenbus_watch
- * structure for storage, and the given @callback function as the callback.
- * Return 0 on success, or -errno on error.  On success, the watched path
- * (@path/@path2) will be saved as @watch->node, and becomes the caller's to
- * kfree().  On error, watch->node will be NULL, so the caller has nothing to
+ * structure for storage, and the given @callback function as the
+ * callback.  On success, the watched path (@path/@path2) will be saved
+ * as @watch->node, and becomes the caller's to kfree().
+ * On error, watch->node will be NULL, so the caller has nothing to
  * free, the device will switch to %XenbusStateClosing, and the error will be
  * saved in the store.
+ *
+ * Returns: %0 on success or -errno on error
  */
 int xenbus_watch_pathfmt(struct xenbus_device *dev,
 struct xenbus_watch *watch,
@@ -255,13 +259,15 @@ abort:
 }
 
 /**
- * xenbus_switch_state
+ * xenbus_switch_state - save the new state of a driver
  * @dev: xenbus device
  * @state: new state
  *
  * Advertise in the store a change of the given driver to the given new_state.
- * Return 0 on success, or -errno on error.  On error, the device will switch
- * to XenbusStateClosing, and the error will be saved in the store.
+ * On error, the device will switch to XenbusStateClosing, and the error
+ * will be saved in the store.
+ *
+ * Returns: %0 on success or -errno on error
  */
 int xenbus_switch_state(struct xenbus_device *dev, enum xenbus_s

[PATCH] xen/shbuf: eliminate 17 kernel-doc warnings

[Randy Dunlap]

Don't use kernel-doc markers ("/**") for comments that are not in
kernel-doc format. This prevents multiple kernel-doc warnings:

xen-front-pgdir-shbuf.c:25: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * This structure represents the structure of a shared page
xen-front-pgdir-shbuf.c:37: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Shared buffer ops which are differently implemented
xen-front-pgdir-shbuf.c:65: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Get granted reference to the very first page of the
xen-front-pgdir-shbuf.c:85: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Map granted references of the shared buffer.
xen-front-pgdir-shbuf.c:106: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Unmap granted references of the shared buffer.
xen-front-pgdir-shbuf.c:127: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Free all the resources of the shared buffer.
xen-front-pgdir-shbuf.c:154: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Get the number of pages the page directory consumes itself.
xen-front-pgdir-shbuf.c:164: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Calculate the number of grant references needed to share the buffer
xen-front-pgdir-shbuf.c:176: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Calculate the number of grant references needed to share the buffer
xen-front-pgdir-shbuf.c:194: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Unmap the buffer previously mapped with grant references
xen-front-pgdir-shbuf.c:242: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Map the buffer with grant references provided by the backend.
xen-front-pgdir-shbuf.c:324: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Fill page directory with grant references to the pages of the
xen-front-pgdir-shbuf.c:354: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Fill page directory with grant references to the pages of the
xen-front-pgdir-shbuf.c:393: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Grant references to the frontend's buffer pages.
xen-front-pgdir-shbuf.c:422: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Grant all the references needed to share the buffer.
xen-front-pgdir-shbuf.c:470: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Allocate all required structures to mange shared buffer.
xen-front-pgdir-shbuf.c:510: warning: This comment starts with '/**', but isn't 
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
 * Allocate a new instance of a shared buffer.

Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Closes: lore.kernel.org/r/202311060203.yqrppzhm-...@intel.com
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Oleksandr Tyshchenko 
Cc: xen-devel@lists.xenproject.org
---
 drivers/xen/xen-front-pgdir-shbuf.c |   34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff -- a/drivers/xen/xen-front-pgdir-shbuf.c 
b/drivers/xen/xen-front-pgdir-shbuf.c
--- a/drivers/xen/xen-front-pgdir-shbuf.c
+++ b/drivers/xen/xen-front-pgdir-shbuf.c
@@ -21,7 +21,7 @@
 
 #include 
 
-/**
+/*
  * This structure represents the structure of a shared page
  * that contains grant references to the pages of the shared
  * buffer. This structure is common to many Xen para-virtualized
@@ -33,7 +33,7 @@ struct xen_page_directory {
grant_ref_t gref[]; /* Variable length */
 };
 
-/**
+/*
  * Shared buffer ops which are differently implemented
  * depending on the allocation mode, e.g. if the buffer
  * is allocated by the corresponding backend or frontend.
@@ -61,7 +61,7 @@ struct xen_front_pgdir_shbuf_ops {
int (*unmap)(struct xen_front_pgdir_shbuf *buf);
 };
 
-/**
+/*
  * Get granted reference to the very first page of the
  * page directory. Usually this is passed to the backend,
  * so it can find/fill the grant references to the buffer's
@@ -

Re: [PATCH] arch: change variable types to match those of what is assigned to them

[Randy Dunlap]

Hi,

Please look at
  
https://lore.kernel.org/lkml/caa42ikx2f2lsaq9c5rxnctphob6n+l35winc5wk1k2eysaj...@mail.gmail.com/T/#u

and see if that matches what you thought you sent as a patch.

The gmail web interface is notorious for dropping tabs in emails.


On 12/13/22 09:35, Seija K. wrote:
> There are many places where "int len = strlen(foo);" is written, just
> for len to be passed as a parameter of size_t. This causes truncation
> and then expansion back from int to size_t. Not to mention this is
> poor logic and needless truncations can add extra unneeded
> instructions.
> 
> This patch aims to fix the worst offenders.
> 
> Signed-off-by: Seija Kijin 
> ---
>  arch/arm/mm/mmu.c  | 30 +-
>  arch/arm/probes/kprobes/test-core.c|  8 +++
>  arch/arm/vfp/vfpmodule.c   |  4 ++--
>  arch/arm/xen/p2m.c |  4 ++--
>  arch/mips/alchemy/common/irq.c |  2 +-
>  arch/mips/alchemy/common/prom.c|  2 +-
>  arch/mips/alchemy/devboards/bcsr.c |  2 +-
>  arch/mips/alchemy/devboards/platform.c |  8 +++
>  arch/mips/ar7/prom.c   |  4 ++--
>  arch/mips/boot/compressed/dbg.c| 14 +---
>  arch/mips/fw/arc/cmdline.c |  4 ++--
>  arch/xtensa/platforms/iss/console.c|  4 ++--
>  12 files changed, 41 insertions(+), 45 deletions(-)
> 


-- 
~Randy

Re: [RFC PATCH 27/30] Code tagging based latency tracking

[Randy Dunlap]

On 8/30/22 14:49, Suren Baghdasaryan wrote:
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index b7d03afbc808..b0f86643b8f0 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1728,6 +1728,14 @@ config LATENCYTOP
> Enable this option if you want to use the LatencyTOP tool
> to find out which userspace is blocking on what kernel operations.
>  
> +config CODETAG_TIME_STATS
> + bool "Code tagging based latency measuring"
> + depends on DEBUG_FS
> + select TIME_STATS
> + select CODE_TAGGING
> + help
> +   Enabling this option makes latency statistics available in debugfs

Missing period at the end of the sentence.

-- 
~Randy

Re: [RFC PATCH 22/30] Code tagging based fault injection

[Randy Dunlap]

On 8/30/22 14:49, Suren Baghdasaryan wrote:
> From: Kent Overstreet 
> 
> This adds a new fault injection capability, based on code tagging.
> 
> To use, simply insert somewhere in your code
> 
>   dynamic_fault("fault_class_name")
> 
> and check whether it returns true - if so, inject the error.
> For example
> 
>   if (dynamic_fault("init"))
>   return -EINVAL;
> 
> There's no need to define faults elsewhere, as with
> include/linux/fault-injection.h. Faults show up in debugfs, under
> /sys/kernel/debug/dynamic_faults, and can be selected based on
> file/module/function/line number/class, and enabled permanently, or in
> oneshot mode, or with a specified frequency.
> 
> Signed-off-by: Kent Overstreet 

Missing Signed-off-by: from Suren.
See Documentation/process/submitting-patches.rst:

When to use Acked-by:, Cc:, and Co-developed-by:


The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.


-- 
~Randy

Re: [PATCH 24/30] panic: Refactor the panic path

[Randy Dunlap]

On 4/27/22 15:49, Guilherme G. Piccoli wrote:
> + crash_kexec_post_notifiers
> + This was DEPRECATED - users should always prefer the

This is DEPRECATED - users should always prefer the

> + parameter "panic_notifiers_level" - check its entry
> + in this documentation for details on how it works.
> + Setting this parameter is exactly the same as setting
> + "panic_notifiers_level=4".

-- 
~Randy

[PATCH v2] xen: update missing ioctl magic numers documentation

[Randy Dunlap]

Add missing ioctl "magic numbers" for various Xen interfaces
(xenbus_dev.h, gntalloc.h, gntdev.h, and privcmd.h).

Signed-off-by: Randy Dunlap 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org
---
v2: fix copy-pasta error: change 'E' to 'G' (thanks, Juergen)

 Documentation/userspace-api/ioctl/ioctl-number.rst |3 +++
 1 file changed, 3 insertions(+)

--- linux-next-20220128.orig/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ linux-next-20220128/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -115,6 +115,7 @@ Code  Seq#Include File
 'B'   00-1F  linux/cciss_ioctl.h conflict!
 'B'   00-0F  include/linux/pmu.h conflict!
 'B'   C0-FF  advanced bbus   
<mailto:maas...@uni-freiburg.de>
+'B'   00-0F  xen/xenbus_dev.hconflict!
 'C'   alllinux/soundcard.h   conflict!
 'C'   01-2F  linux/capi.hconflict!
 'C'   F0-FF  drivers/net/wan/cosa.h  conflict!
@@ -134,6 +135,7 @@ Code  Seq#Include File
 'F'   80-8F  linux/arcfb.h   conflict!
 'F'   DD video/sstfb.h   conflict!
 'G'   00-3F  drivers/misc/sgi-gru/grulib.h   conflict!
+'G'   00-0F  xen/gntalloc.h, xen/gntdev.hconflict!
 'H'   00-7F  linux/hiddev.h  conflict!
 'H'   00-0F  linux/hidraw.h  conflict!
 'H'   01 linux/mei.h conflict!
@@ -176,6 +178,7 @@ Code  Seq#Include File
 'P'   60-6F  sound/sscape_ioctl.hconflict!
 'P'   00-0F  drivers/usb/class/usblp.c   conflict!
 'P'   01-09  drivers/misc/pci_endpoint_test.cconflict!
+'P'   00-0F  xen/privcmd.h   conflict!
 'Q'   alllinux/soundcard.h
 'R'   00-1F  linux/random.h  conflict!
 'R'   01 linux/rfkill.h  conflict!

Re: [PATCH] xen: update missing ioctl magic numers documentation

[Randy Dunlap]

Hi--

On 1/30/22 22:55, Juergen Gross wrote:
> On 30.01.22 20:23, Randy Dunlap wrote:
>> Add missing ioctl "magic numbers" for various Xen interfaces
>> (xenbus_dev.h, gntalloc.h, gntdev.h, and privcmd.h).
>>
>> Signed-off-by: Randy Dunlap 
>> Cc: Boris Ostrovsky 
>> Cc: Juergen Gross 
>> Cc: Stefano Stabellini 
>> Cc: xen-devel@lists.xenproject.org
>> ---
>>   Documentation/userspace-api/ioctl/ioctl-number.rst |    3 +++
>>   1 file changed, 3 insertions(+)
>>
>> --- 
>> linux-next-20220128.orig/Documentation/userspace-api/ioctl/ioctl-number.rst
>> +++ linux-next-20220128/Documentation/userspace-api/ioctl/ioctl-number.rst
>> @@ -115,6 +115,7 @@ Code  Seq#    Include File
>>   'B'   00-1F  linux/cciss_ioctl.h 
>> conflict!
>>   'B'   00-0F  include/linux/pmu.h 
>> conflict!
>>   'B'   C0-FF  advanced bbus   
>> <mailto:maas...@uni-freiburg.de>
>> +'B'   00-0F  xen/xenbus_dev.h    
>> conflict!
> 
> Hmm, shouldn't xenbus_dev.h be moved to include/uapi/xen ?

Probably. That should be done in a different patch and probably/preferably
done using git (which I am not using). So if someone else could take care
of that, that would be good.

> 
>>   'C'   all    linux/soundcard.h   
>> conflict!
>>   'C'   01-2F  linux/capi.h    
>> conflict!
>>   'C'   F0-FF  drivers/net/wan/cosa.h  
>> conflict!
>> @@ -134,6 +135,7 @@ Code  Seq#    Include File
>>   'F'   80-8F  linux/arcfb.h   
>> conflict!
>>   'F'   DD video/sstfb.h   
>> conflict!
>>   'G'   00-3F  drivers/misc/sgi-gru/grulib.h   
>> conflict!
>> +'E'   00-0F  xen/gntalloc.h, xen/gntdev.h    
>> conflict!
> 
> Should be 'G' IMO.

Indeed it should. I'll send a v2.

> 
>>   'H'   00-7F  linux/hiddev.h  
>> conflict!
>>   'H'   00-0F  linux/hidraw.h  
>> conflict!
>>   'H'   01 linux/mei.h 
>> conflict!
>> @@ -176,6 +178,7 @@ Code  Seq#    Include File
>>   'P'   60-6F  sound/sscape_ioctl.h    
>> conflict!
>>   'P'   00-0F  drivers/usb/class/usblp.c   
>> conflict!
>>   'P'   01-09  drivers/misc/pci_endpoint_test.c    
>> conflict!
>> +'P'   00-0F  xen/privcmd.h   
>> conflict!
>>   'Q'   all    linux/soundcard.h
>>   'R'   00-1F  linux/random.h  
>> conflict!
>>   'R'   01 linux/rfkill.h  
>> conflict!
>>
> 
> 
> Juergen

thanks.
-- 
~Randy

Re: [PATCH] xen: xenbus_dev.h: delete incorrect file name

[Randy Dunlap]

On 1/30/22 22:46, Juergen Gross wrote:
> On 30.01.22 20:17, Randy Dunlap wrote:
>> It is better/preferred not to include file names in source files
>> because (a) they are not needed and (b) they can be incorrect,
>> so just delete this incorrect file name.
>>
>> Signed-off-by: Randy Dunlap 
>> Cc: Boris Ostrovsky 
>> Cc: Juergen Gross 
>> Cc: Stefano Stabellini 
>> Cc: xen-devel@lists.xenproject.org
>> ---
>>   include/xen/xenbus_dev.h |    1 -
>>   1 file changed, 1 deletion(-)
>>
>> --- linux-next-20220128.orig/include/xen/xenbus_dev.h
>> +++ linux-next-20220128/include/xen/xenbus_dev.h
>> @@ -1,5 +1,4 @@
>>   
>> /**
>> - * evtchn.h
> 
> I think the following line should be deleted, too (can be done while
> committing).
> 

Sounds good. Thanks.

>>    *
>>    * Interface to /dev/xen/xenbus_backend.
>>    *
>>
> 
> Reviewed-by: Juergen Gross 
> 
> 
> Juergen

-- 
~Randy

[PATCH] xen: update missing ioctl magic numers documentation

[Randy Dunlap]

Add missing ioctl "magic numbers" for various Xen interfaces
(xenbus_dev.h, gntalloc.h, gntdev.h, and privcmd.h).

Signed-off-by: Randy Dunlap 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org
---
 Documentation/userspace-api/ioctl/ioctl-number.rst |3 +++
 1 file changed, 3 insertions(+)

--- linux-next-20220128.orig/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ linux-next-20220128/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -115,6 +115,7 @@ Code  Seq#Include File
 'B'   00-1F  linux/cciss_ioctl.h conflict!
 'B'   00-0F  include/linux/pmu.h conflict!
 'B'   C0-FF  advanced bbus   
<mailto:maas...@uni-freiburg.de>
+'B'   00-0F  xen/xenbus_dev.hconflict!
 'C'   alllinux/soundcard.h   conflict!
 'C'   01-2F  linux/capi.hconflict!
 'C'   F0-FF  drivers/net/wan/cosa.h  conflict!
@@ -134,6 +135,7 @@ Code  Seq#Include File
 'F'   80-8F  linux/arcfb.h   conflict!
 'F'   DD video/sstfb.h   conflict!
 'G'   00-3F  drivers/misc/sgi-gru/grulib.h   conflict!
+'E'   00-0F  xen/gntalloc.h, xen/gntdev.hconflict!
 'H'   00-7F  linux/hiddev.h  conflict!
 'H'   00-0F  linux/hidraw.h  conflict!
 'H'   01 linux/mei.h conflict!
@@ -176,6 +178,7 @@ Code  Seq#Include File
 'P'   60-6F  sound/sscape_ioctl.hconflict!
 'P'   00-0F  drivers/usb/class/usblp.c   conflict!
 'P'   01-09  drivers/misc/pci_endpoint_test.cconflict!
+'P'   00-0F  xen/privcmd.h   conflict!
 'Q'   alllinux/soundcard.h
 'R'   00-1F  linux/random.h  conflict!
 'R'   01 linux/rfkill.h  conflict!

[PATCH] xen: xenbus_dev.h: delete incorrect file name

[Randy Dunlap]

It is better/preferred not to include file names in source files
because (a) they are not needed and (b) they can be incorrect,
so just delete this incorrect file name.

Signed-off-by: Randy Dunlap 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: xen-devel@lists.xenproject.org
---
 include/xen/xenbus_dev.h |1 -
 1 file changed, 1 deletion(-)

--- linux-next-20220128.orig/include/xen/xenbus_dev.h
+++ linux-next-20220128/include/xen/xenbus_dev.h
@@ -1,5 +1,4 @@
 /**
- * evtchn.h
  *
  * Interface to /dev/xen/xenbus_backend.
  *

Re: [PATCH V2] ARM: xen/mm.c: A mundane typo fix

[Randy Dunlap]

On 3/24/21 9:35 PM, Bhaskar Chowdhury wrote:
> s/acrros/across/
> 
> Plus some words need prural version...so did it.(page->pages)
> 
> Signed-off-by: Bhaskar Chowdhury 

Acked-by: Randy Dunlap 

> ---
>  Changes from V1:
>   Randy's findings incorporated.
> 
>  arch/arm/xen/mm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index 467fa225c3d0..8596dd32dcd5 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -105,8 +105,8 @@ bool xen_arch_need_swiotlb(struct device *dev,
>*  - The Linux page refers to foreign memory
>*  - The device doesn't support coherent DMA request
>*
> -  * The Linux page may be spanned acrros multiple Xen page, although
> -  * it's not possible to have a mix of local and foreign Xen page.
> +  * The Linux page may be spanned across multiple Xen pages, although
> +  * it's not possible to have a mix of local and foreign Xen pages.
>* Furthermore, range_straddles_page_boundary is already checking
>* if buffer is physically contiguous in the host RAM.
>*
> --


-- 
~Randy

Re: [PATCH] ARM: xen/mm.c: A mundane typo fix

[Randy Dunlap]

On 3/24/21 11:55 AM, Stefano Stabellini wrote:
> On Wed, 24 Mar 2021, Bhaskar Chowdhury wrote:
>> s/acrros/across/
>>
>> Signed-off-by: Bhaskar Chowdhury 
> 
> Reviewed-by: Stefano Stabellini 
> 
> 

Hi,
It seems to me like some of those "page" should be "pages".

>> ---
>>  arch/arm/xen/mm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
>> index 467fa225c3d0..be7c942c74bf 100644
>> --- a/arch/arm/xen/mm.c
>> +++ b/arch/arm/xen/mm.c
>> @@ -105,7 +105,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
>>   *  - The Linux page refers to foreign memory
>>   *  - The device doesn't support coherent DMA request
>>   *
>> - * The Linux page may be spanned acrros multiple Xen page, although>> + 
>>  * The Linux page may be spanned across multiple Xen page, although

 pages,

>>   * it's not possible to have a mix of local and foreign Xen page.

pages.

>>   * Furthermore, range_straddles_page_boundary is already checking
>>   * if buffer is physically contiguous in the host RAM.
>> --


-- 
~Randy

Re: Linux 5.11-rc6 compile error

[Randy Dunlap]

On 2/3/21 11:58 AM, Shuah Khan wrote:
> I am seeing the following compile error on Linux 5.11-rc6.
> No issues on 5.11.0-rc5 with the same config.
> 
> ld: arch/x86/built-in.a: member arch/x86/kernel/pci-swiotlb.o in archive is 
> not an object
> make: *** [Makefile:1170: vmlinux] Error 1
> 
> CONFIG_SWIOTLB_XEN=y
> CONFIG_SWIOTLB=y

Those config settings in allmodconfig builds for me.


> I can debug further later on today. Checking to see if there are any
> known problems.


-- 
~Randy

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

[Randy Dunlap]

On 11/13/20 3:52 PM, Daniel Kiper wrote:
> Hey,
> 
> 
> Here is the description (pseudocode) of the structures which will be
> used to store the log data.
> 
> Anyway, I am aware that this is not specification per se.


Yes, you have caveats here. I'm sure that you either already know
or would learn soon enough that struct struct bf_log has some
padding added to it (for alignment) unless it is packed.
Or you could rearrange the order of some of its fields
and save 8 bytes per struct on x86_64.


>   struct bf_log
>   {
> uint32_t   version;
> char   producer[64];
> uint64_t   flags;
> uint64_t   next_bf_log_addr;
> uint32_t   next_msg_off;
> bf_log_msg msgs[];
>   }
> 
>   struct bf_log_msg
>   {
> uint32_t size;
> uint64_t ts_nsec;
> uint32_t level;
> uint32_t facility;
> uint32_t msg_off;
> char strings[];
>   }


cheers.
-- 
~Randy

Re: Duplicated ABI entries - Was: Re: [PATCH v2 20/39] docs: ABI: testing: make the files compatible with ReST output

[Randy Dunlap]

On 11/9/20 11:26 PM, Mauro Carvalho Chehab wrote:
> Hi Jonathan,
> 
> Let's view ABI from the PoV of a system admin that doesn't know
> yet about a certain ABI symbol.
> 
> He'll try to seek for the symbol, more likely using the HTML 
> documentation. Only very senior system admins might try to take
> a look at the Kernel.

FWIW, I think that the likely search methods are $search_engine
and 'grep'.

Have a good few days off.

-- 
~Randy

Re: [PATCH] x86/pci: fix xen.c build error when CONFIG_ACPI is not set

[Randy Dunlap]

Hi Konrad,

ping.

I am still seeing this build error. It looks like this is
in your territory to merge...


On 8/13/20 4:00 PM, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix build error when CONFIG_ACPI is not set/enabled:
> 
> ../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
> ../arch/x86/pci/xen.c:410:2: error: implicit declaration of function 
> ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? 
> [-Werror=implicit-function-declaration]
>   acpi_noirq_set();
> 
> Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
> Signed-off-by: Randy Dunlap 
> Cc: Andy Shevchenko 
> Cc: Bjorn Helgaas 
> Cc: Konrad Rzeszutek Wilk 
> Cc: xen-devel@lists.xenproject.org
> Cc: linux-...@vger.kernel.org
> ---
>  arch/x86/pci/xen.c |1 +
>  1 file changed, 1 insertion(+)
> 
> --- linux-next-20200813.orig/arch/x86/pci/xen.c
> +++ linux-next-20200813/arch/x86/pci/xen.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  static int xen_pcifront_enable_irq(struct pci_dev *dev)
> 


thanks.
-- 
~Randy

[PATCH] x86/pci: fix xen.c build error when CONFIG_ACPI is not set

[Randy Dunlap]

From: Randy Dunlap 

Fix build error when CONFIG_ACPI is not set/enabled:

../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function 
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? 
[-Werror=implicit-function-declaration]
  acpi_noirq_set();

Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
Signed-off-by: Randy Dunlap 
Cc: Andy Shevchenko 
Cc: Bjorn Helgaas 
Cc: Konrad Rzeszutek Wilk 
Cc: xen-devel@lists.xenproject.org
Cc: linux-...@vger.kernel.org
---
 arch/x86/pci/xen.c |1 +
 1 file changed, 1 insertion(+)

--- linux-next-20200813.orig/arch/x86/pci/xen.c
+++ linux-next-20200813/arch/x86/pci/xen.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static int xen_pcifront_enable_irq(struct pci_dev *dev)

Re: linux-next: Tree for Aug 12 (x86: xen/pci)

[Randy Dunlap]

On 8/12/20 7:57 AM, Randy Dunlap wrote:
> On 8/11/20 9:22 PM, Stephen Rothwell wrote:
>> Hi all,
>>
> 
> 
> on x86_64:
> 
> ../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
> ../arch/x86/pci/xen.c:410:2: error: implicit declaration of function 
> ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? 
> [-Werror=implicit-function-declaration]
>   acpi_noirq_set();
>   ^~

(still seeing this one)

# CONFIG_ACPI is not set/enabled.

> 
> Full randconfig file is attached.
> 


-- 
~Randy
Reported-by: Randy Dunlap 

[PATCH] xen: hypercall.h: fix duplicated word

[Randy Dunlap]

Change the repeated word "as" to "as a".

Signed-off-by: Randy Dunlap 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/include/asm/xen/hypercall.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200720.orig/arch/x86/include/asm/xen/hypercall.h
+++ linux-next-20200720/arch/x86/include/asm/xen/hypercall.h
@@ -82,7 +82,7 @@ struct xen_dm_op_buf;
  * - clobber the rest
  *
  * The result certainly isn't pretty, and it really shows up cpp's
- * weakness as as macro language.  Sorry.  (But let's just give thanks
+ * weakness as a macro language.  Sorry.  (But let's just give thanks
  * there aren't more than 5 arguments...)
  */
 

[PATCH] xen/gntdev: gntdev.h: drop a duplicated word

[Randy Dunlap]

Drop the repeated word "of" in a comment.

Signed-off-by: Randy Dunlap 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-devel@lists.xenproject.org
---
 include/uapi/xen/gntdev.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200717.orig/include/uapi/xen/gntdev.h
+++ linux-next-20200717/include/uapi/xen/gntdev.h
@@ -66,7 +66,7 @@ struct ioctl_gntdev_map_grant_ref {
 
 /*
  * Removes the grant references from the mapping table of an instance of
- * of gntdev. N.B. munmap() must be called on the relevant virtual address(es)
+ * gntdev. N.B. munmap() must be called on the relevant virtual address(es)
  * before this ioctl is called, or an error will result.
  */
 #define IOCTL_GNTDEV_UNMAP_GRANT_REF \

Re: linux-next: Tree for Jun 2 (x86/xen)

[Randy Dunlap]

On 6/2/20 3:37 AM, Stephen Rothwell wrote:
> Hi all,
> 
> News: The merge window has opened, so please do *not* add v5.9 material
> to your linux-next included branches until after v5.8-rc1 has been
> released.
> 
> Changes since 20200529:
> 

on x86_64:

  CC  arch/x86/xen/suspend_hvm.o
In file included from ../include/xen/interface/hvm/params.h:24:0,
 from ../include/xen/hvm.h:6,
 from ../arch/x86/xen/suspend_hvm.c:5:
../include/xen/interface/hvm/hvm_op.h:29:5: error: unknown type name ‘domid_t’
 domid_t  domid;/* IN */
 ^~~
../include/xen/interface/hvm/hvm_op.h:33:1: warning: data definition has no 
type or storage class
 DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_param);
 ^~
../include/xen/interface/hvm/hvm_op.h:33:1: error: type defaults to ‘int’ in 
declaration of ‘DEFINE_GUEST_HANDLE_STRUCT’ [-Werror=implicit-int]
../include/xen/interface/hvm/hvm_op.h:33:1: warning: parameter names (without 
types) in function declaration
../include/xen/interface/hvm/hvm_op.h:39:5: error: unknown type name ‘domid_t’
 domid_t  domid;
 ^~~
../include/xen/interface/hvm/hvm_op.h:44:1: warning: data definition has no 
type or storage class
 DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_pagetable_dying_t);
 ^~
../include/xen/interface/hvm/hvm_op.h:44:1: error: type defaults to ‘int’ in 
declaration of ‘DEFINE_GUEST_HANDLE_STRUCT’ [-Werror=implicit-int]
../include/xen/interface/hvm/hvm_op.h:56:5: error: unknown type name ‘domid_t’
 domid_t domid;
 ^~~
../include/xen/interface/hvm/hvm_op.h:63:1: warning: data definition has no 
type or storage class
 DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_get_mem_type);
 ^~
../include/xen/interface/hvm/hvm_op.h:63:1: error: type defaults to ‘int’ in 
declaration of ‘DEFINE_GUEST_HANDLE_STRUCT’ [-Werror=implicit-int]
../include/xen/interface/hvm/hvm_op.h:63:1: warning: parameter names (without 
types) in function declaration


Full randconfig file is attached.

-- 
~Randy
Reported-by: Randy Dunlap 
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.7.0 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc (SUSE Linux) 7.5.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70500
CONFIG_LD_VERSION=23200
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_WATCH_QUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_GENERIC_IRQ_INJECTION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_DEBUGFS=y
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem

CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_HAVE_SCHED_AVG_IRQ=y
# CONFIG_SCHED_THERMAL_PRESSURE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting

# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
# end of RC

Re: [Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info

[Randy Dunlap]

On 10/10/19 2:43 AM, Daniel Kiper wrote:
> On Wed, Oct 09, 2019 at 05:43:31PM -0700, Randy Dunlap wrote:
>> Hi,
>>
>> Questions and comments below...
>> Thanks.
>>
>> On 10/9/19 3:53 AM, Daniel Kiper wrote:
>>
>>> Suggested-by: H. Peter Anvin 
>>> Signed-off-by: Daniel Kiper 
>>> Reviewed-by: Konrad Rzeszutek Wilk 
>>> Reviewed-by: Ross Philipson 
>>> ---
>>
>>> ---
>>>  Documentation/x86/boot.rst | 121 
>>> +
>>>  arch/x86/boot/Makefile |   2 +-
>>>  arch/x86/boot/compressed/Makefile  |   4 +-
>>>  arch/x86/boot/compressed/kernel_info.S |  17 +
>>>  arch/x86/boot/header.S |   1 +
>>>  arch/x86/boot/tools/build.c|   5 ++
>>>  arch/x86/include/uapi/asm/bootparam.h  |   1 +
>>>  7 files changed, 148 insertions(+), 3 deletions(-)
>>>  create mode 100644 arch/x86/boot/compressed/kernel_info.S
>>>
>>> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
>>> index 08a2f100c0e6..d5323a39f5e3 100644
>>> --- a/Documentation/x86/boot.rst
>>> +++ b/Documentation/x86/boot.rst
>>> @@ -68,8 +68,25 @@ Protocol 2.12(Kernel 3.8) Added the xloadflags field 
>>> and extension fields
>>>  Protocol 2.13  (Kernel 3.14) Support 32- and 64-bit flags being set in
>>> xloadflags to support booting a 64-bit kernel from 32-bit
>>> EFI
>>> +
>>> +Protocol 2.14: BURNT BY INCORRECT COMMIT 
>>> ae7e1238e68f2a472a125673ab506d49158c1889
>>> +   (x86/boot: Add ACPI RSDP address to setup_header)
>>> +   DO NOT USE!!! ASSUME SAME AS 2.13.
>>> +
>>> +Protocol 2.15: (Kernel 5.5) Added the kernel_info.
>>>  =  
>>> 
>>>
>>> +.. note::
>>> + The protocol version number should be changed only if the setup header
>>> + is changed. There is no need to update the version number if 
>>> boot_params
>>> + or kernel_info are changed. Additionally, it is recommended to use
>>> + xloadflags (in this case the protocol version number should not be
>>> + updated either) or kernel_info to communicate supported Linux kernel
>>> + features to the boot loader. Due to very limited space available in
>>> + the original setup header every update to it should be considered
>>> + with great care. Starting from the protocol 2.15 the primary way to
>>> + communicate things to the boot loader is the kernel_info.
>>> +
>>>
>>>  Memory Layout
>>>  =
>>> @@ -207,6 +224,7 @@ Offset/Size Proto   Name
>>> Meaning
>>>  0258/8 2.10+   pref_addressPreferred 
>>> loading address
>>>  0260/4 2.10+   init_size   Linear memory 
>>> required during initialization
>>>  0264/4 2.11+   handover_offset Offset of 
>>> handover entry point
>>> +0268/4 2.15+   kernel_info_offset  Offset of the 
>>> kernel_info
>>>  ====   
>>> 
>>>
>>>  .. note::
>>> @@ -855,6 +873,109 @@ Offset/size:  0x264/4
>>>
>>>See EFI HANDOVER PROTOCOL below for more details.
>>>
>>> +   ==
>>> +Field name:kernel_info_offset
>>> +Type:  read
>>> +Offset/size:   0x268/4
>>> +Protocol:  2.15+
>>> +   ==
>>> +
>>> +  This field is the offset from the beginning of the kernel image to the
>>> +  kernel_info. It is embedded in the Linux image in the uncompressed
>>   ^^
>>What does  It   refer to, please?
> 
> s/It/The kernel_info structure/ Is it better?

Yes.

>>> +  protected mode region.
>>> +
>>> +
>>> +The kernel_info
>>> +===
>>> +
>>> +The relationships between the headers are analogous to the various data
>>> +sections:
>>> +
>>> +  setup_header = .data
>>> +  boot_params/setup_data = .bss
>>> +
>>> +What is missing from the above list? That's right:
>>> +
>>> +  kernel_

Re: [Xen-devel] [PATCH v3 1/3] x86/boot: Introduce the kernel_info

[Randy Dunlap]

Hi,

Questions and comments below...
Thanks.


On 10/9/19 3:53 AM, Daniel Kiper wrote:

> Suggested-by: H. Peter Anvin 
> Signed-off-by: Daniel Kiper 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Ross Philipson 
> ---

> ---
>  Documentation/x86/boot.rst | 121 
> +
>  arch/x86/boot/Makefile |   2 +-
>  arch/x86/boot/compressed/Makefile  |   4 +-
>  arch/x86/boot/compressed/kernel_info.S |  17 +
>  arch/x86/boot/header.S |   1 +
>  arch/x86/boot/tools/build.c|   5 ++
>  arch/x86/include/uapi/asm/bootparam.h  |   1 +
>  7 files changed, 148 insertions(+), 3 deletions(-)
>  create mode 100644 arch/x86/boot/compressed/kernel_info.S
> 
> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> index 08a2f100c0e6..d5323a39f5e3 100644
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -68,8 +68,25 @@ Protocol 2.12  (Kernel 3.8) Added the xloadflags field 
> and extension fields
>  Protocol 2.13(Kernel 3.14) Support 32- and 64-bit flags being set in
>   xloadflags to support booting a 64-bit kernel from 32-bit
>   EFI
> +
> +Protocol 2.14:   BURNT BY INCORRECT COMMIT 
> ae7e1238e68f2a472a125673ab506d49158c1889
> + (x86/boot: Add ACPI RSDP address to setup_header)
> + DO NOT USE!!! ASSUME SAME AS 2.13.
> +
> +Protocol 2.15:   (Kernel 5.5) Added the kernel_info.
>  =
> 
>  
> +.. note::
> + The protocol version number should be changed only if the setup header
> + is changed. There is no need to update the version number if boot_params
> + or kernel_info are changed. Additionally, it is recommended to use
> + xloadflags (in this case the protocol version number should not be
> + updated either) or kernel_info to communicate supported Linux kernel
> + features to the boot loader. Due to very limited space available in
> + the original setup header every update to it should be considered
> + with great care. Starting from the protocol 2.15 the primary way to
> + communicate things to the boot loader is the kernel_info.
> +
>  
>  Memory Layout
>  =
> @@ -207,6 +224,7 @@ Offset/Size   Proto   Name
> Meaning
>  0258/8   2.10+   pref_addressPreferred 
> loading address
>  0260/4   2.10+   init_size   Linear memory 
> required during initialization
>  0264/4   2.11+   handover_offset Offset of 
> handover entry point
> +0268/4   2.15+   kernel_info_offset  Offset of the 
> kernel_info
>  ===  =   
> 
>  
>  .. note::
> @@ -855,6 +873,109 @@ Offset/size:0x264/4
>  
>See EFI HANDOVER PROTOCOL below for more details.
>  
> + ==
> +Field name:  kernel_info_offset
> +Type:read
> +Offset/size: 0x268/4
> +Protocol:2.15+
> + ==
> +
> +  This field is the offset from the beginning of the kernel image to the
> +  kernel_info. It is embedded in the Linux image in the uncompressed
  ^^
   What does  It   refer to, please?

> +  protected mode region.
> +
> +
> +The kernel_info
> +===
> +
> +The relationships between the headers are analogous to the various data
> +sections:
> +
> +  setup_header = .data
> +  boot_params/setup_data = .bss
> +
> +What is missing from the above list? That's right:
> +
> +  kernel_info = .rodata
> +
> +We have been (ab)using .data for things that could go into .rodata or .bss 
> for
> +a long time, for lack of alternatives and -- especially early on -- inertia.
> +Also, the BIOS stub is responsible for creating boot_params, so it isn't
> +available to a BIOS-based loader (setup_data is, though).
> +
> +setup_header is permanently limited to 144 bytes due to the reach of the
> +2-byte jump field, which doubles as a length field for the structure, 
> combined
> +with the size of the "hole" in struct boot_params that a protected-mode 
> loader
> +or the BIOS stub has to copy it into. It is currently 119 bytes long, which
> +leaves us with 25 very precious bytes. This isn't something that can be fixed
> +without revising the boot protocol entirely, breaking backwards 
> compatibility.
> +
> +boot_params proper is limited to 4096 bytes, but can be arbitrarily extended
> +by adding setup_data entries. It cannot be used to communicate properties of
> +the kernel image, because it is .bss and has no image-provided content.
> +
> +kernel_info solves this by providing an extensible place for information 
> about
> +the kernel image. It is readonly, because the kernel cannot rely on a
> +bootloader copying its contents anywhere, but that 

Re: [Xen-devel] [PATCH 1/9] mm: Introduce new vm_insert_range API

[Randy Dunlap]

On 11/16/18 12:15 AM, Souptick Joarder wrote:
> On Fri, Nov 16, 2018 at 12:11 PM Matthew Wilcox  wrote:
>>
>> On Fri, Nov 16, 2018 at 11:00:30AM +0530, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 11:44 PM Randy Dunlap  wrote:
>>>> On 11/15/18 7:45 AM, Souptick Joarder wrote:
>>>> What is the opposite of vm_insert_range() or even of vm_insert_page()?
>>>> or is there no need for that?
>>>
>>> There is no opposite function of vm_insert_range() / vm_insert_page().
>>> My understanding is, in case of any error, mmap handlers will return the
>>> err to user process and user space will decide the next action. So next
>>> time when mmap handler is getting invoked it will map from the beginning.
>>> Correct me if I am wrong.
>>
>> The opposite function, I suppose, is unmap_region().
>>
>>>> s/no./number/
>>>
>>> I didn't get it ??
>>
>> This is a 'sed' expression.  's' is the 'substitute' command; the /
>> is a separator, 'no.' is what you wrote, and 'number' is what Randy
>> is recommending instead.
> 
> Ok. Will change it in v2.

Thanks.

>>>>> + for (i = 0; i < page_count; i++) {
>>>>> + ret = vm_insert_page(vma, uaddr, pages[i]);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>
>>>> For a non-trivial value of page_count:
>>>> Is it a problem if vm_insert_page() succeeds for several pages
>>>> and then fails?
>>>
>>> No, it will be considered as total failure and mmap handler will return
>>> the err to user space.
>>
>> I think what Randy means is "What happens to the inserted pages?" and
>> the answer is that mmap_region() jumps to the 'unmap_and_free_vma'
>> label, which is an accurate name.

which says:

/* Undo any partial mapping done by a device driver. */
unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);

and that is what I was missing.  Thanks.

> Sorry for incorrect understanding of the question.

No problem.


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/9] mm: Introduce new vm_insert_range API

[Randy Dunlap]

On 11/15/18 7:45 AM, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
> 
> As this pattern is common across different drivers, it can
> be generalized by creating a new function and use it across
> the drivers.
> 
> vm_insert_range is the new API which will be used to map a
> range of kernel memory/pages to user vma.
> 
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Matthew Wilcox 
> ---
>  include/linux/mm_types.h |  3 +++
>  mm/memory.c  | 28 
>  mm/nommu.c   |  7 +++
>  3 files changed, 38 insertions(+)

Hi,

What is the opposite of vm_insert_range() or even of vm_insert_page()?
or is there no need for that?


> diff --git a/mm/memory.c b/mm/memory.c
> index 15c417e..da904ed 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1478,6 +1478,34 @@ static int insert_page(struct vm_area_struct *vma, 
> unsigned long addr,
>  }
>  
>  /**
> + * vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @addr: target user address of this page
> + * @pages: pointer to array of source kernel pages
> + * @page_count: no. of pages need to insert into user vma

s/no./number/

> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma. This is a generic function which drivers can use
> + * rather than using their own way of mapping range of kernel pages into
> + * user vma.
> + */
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + unsigned long uaddr = addr;
> + int ret = 0, i;
> +
> + for (i = 0; i < page_count; i++) {
> + ret = vm_insert_page(vma, uaddr, pages[i]);
> + if (ret < 0)
> + return ret;

For a non-trivial value of page_count:
Is it a problem if vm_insert_page() succeeds for several pages
and then fails?

> + uaddr += PAGE_SIZE;
> + }
> +
> + return ret;
> +}
> +
> +/**
>   * vm_insert_page - insert single page into user vma
>   * @vma: user vma to map to
>   * @addr: target user address of this page


thanks.
-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

[Randy Dunlap]

On 07/23/2018 02:48 PM, Mark Railton wrote:
> On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote:
>> On 07/23/2018 02:40 PM, Mark Railton wrote:
>>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
>>>> On 07/23/2018 02:34 PM, Mark Railton wrote:
>>>>> Fixed issue with multi line comment
>>>>
>>>> Fix [not Fixed]
>>>>
>>>>>
>>>>> Signed-off-by: Mark Railton 
>>>>> ---
>>>>>  drivers/xen/xlate_mmu.c | 5 +++--
>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>>>> index 23f1387b3ef7..3b03bc1641ed 100644
>>>>> --- a/drivers/xen/xlate_mmu.c
>>>>> +++ b/drivers/xen/xlate_mmu.c
>>>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct 
>>>>> *vma,
>>>>>   struct remap_data data;
>>>>>   unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>>>>>  
>>>>> - /* Kept here for the purpose of making sure code doesn't break
>>>>> -x86 PVOPS */
>>>>> + /* Kept here for the purpose of making sure code doesn't
>>>>> +  * break x86 PVOPS
>>>>> +  */
>>>>
>>>> That is still not the preferred kernel multi-line comment style.
>>>> Documentation/process/coding-style.rst says:
>>>>
>>>>/*
>>>> * This is the preferred style for multi-line
>>>> * comments in the Linux kernel source code.
>>>> * Please use it consistently.
>>>> *
>>>> * Description:  A column of asterisks on the left side,
>>>> * with beginning and ending almost-blank lines.
>>>> */
>>>>
>>>> although Networking code has a slightly different preferred style (as in
>>>> your patch).
>>>>
>>>>>   BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>>>>>  
>>>>>   data.fgfn = gfn;
>>>>>
>>>>
>>>>
>>>> -- 
>>>> ~Randy
>>>
>>> Thank's for the feedback, I'll get that updated now.
>>>
>>> I'm still kinda new to this, I assume I need to send the new patch via
>>> git send-email?
>>
>> That is one option.  Use whatever works for you.
>>
>> There are several email clients that also work well.
>> See Documentation/process/email-clients.rst.
>>
>>
>> -- 
>> ~Randy
> 
> From 57c8104d2a30020005be16df2ca69ed66f6c4ae9 Mon Sep 17 00:00:00 2001
> From: Mark Railton 
> Date: Mon, 23 Jul 2018 22:28:53 +0100
> Subject: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
> 
> Fixed issue with multi line comment
> 
> Signed-off-by: Mark Railton 
> ---
>  drivers/xen/xlate_mmu.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 23f1387b3ef7..2b77c79f8ce7 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -151,8 +151,10 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>   struct remap_data data;
>   unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
> 
> - /* Kept here for the purpose of making sure code doesn't break
> -x86 PVOPS */
> + /*
> +  * Kept here for the purpose of making sure code doesn't
> +  * break x86 PVOPS
> +  */
>   BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> 
>   data.fgfn = gfn;
> --
> 2.17.1


Hi,

a.  The subject and the patch description should be in present tense, i.e.,
Fix instead of Fixed.

b.  Ideally you start a new email thread for new versions of a patch (but Cc:
the interested parties).

For the patch itself:
Acked-by: Randy Dunlap 

Thanks.

-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

[Randy Dunlap]

On 07/23/2018 02:40 PM, Mark Railton wrote:
> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
>> On 07/23/2018 02:34 PM, Mark Railton wrote:
>>> Fixed issue with multi line comment
>>
>> Fix [not Fixed]
>>
>>>
>>> Signed-off-by: Mark Railton 
>>> ---
>>>  drivers/xen/xlate_mmu.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>> index 23f1387b3ef7..3b03bc1641ed 100644
>>> --- a/drivers/xen/xlate_mmu.c
>>> +++ b/drivers/xen/xlate_mmu.c
>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct 
>>> *vma,
>>> struct remap_data data;
>>> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>>>  
>>> -   /* Kept here for the purpose of making sure code doesn't break
>>> -  x86 PVOPS */
>>> +   /* Kept here for the purpose of making sure code doesn't
>>> +* break x86 PVOPS
>>> +*/
>>
>> That is still not the preferred kernel multi-line comment style.
>> Documentation/process/coding-style.rst says:
>>
>>  /*
>>   * This is the preferred style for multi-line
>>   * comments in the Linux kernel source code.
>>   * Please use it consistently.
>>   *
>>   * Description:  A column of asterisks on the left side,
>>   * with beginning and ending almost-blank lines.
>>   */
>>
>> although Networking code has a slightly different preferred style (as in
>> your patch).
>>
>>> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>>>  
>>> data.fgfn = gfn;
>>>
>>
>>
>> -- 
>> ~Randy
> 
> Thank's for the feedback, I'll get that updated now.
> 
> I'm still kinda new to this, I assume I need to send the new patch via
> git send-email?

That is one option.  Use whatever works for you.

There are several email clients that also work well.
See Documentation/process/email-clients.rst.


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout

[Randy Dunlap]

On 07/23/2018 02:34 PM, Mark Railton wrote:
> Fixed issue with multi line comment

Fix [not Fixed]

> 
> Signed-off-by: Mark Railton 
> ---
>  drivers/xen/xlate_mmu.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 23f1387b3ef7..3b03bc1641ed 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>   struct remap_data data;
>   unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>  
> - /* Kept here for the purpose of making sure code doesn't break
> -x86 PVOPS */
> + /* Kept here for the purpose of making sure code doesn't
> +  * break x86 PVOPS
> +  */

That is still not the preferred kernel multi-line comment style.
Documentation/process/coding-style.rst says:

/*
 * This is the preferred style for multi-line
 * comments in the Linux kernel source code.
 * Please use it consistently.
 *
 * Description:  A column of asterisks on the left side,
 * with beginning and ending almost-blank lines.
 */

although Networking code has a slightly different preferred style (as in
your patch).

>   BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>  
>   data.fgfn = gfn;
> 


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Randy Dunlap]

On 05/23/2018 03:01 PM, Thomas Garnier wrote:
> On Wed, May 23, 2018 at 2:27 PM Randy Dunlap <rdun...@infradead.org> wrote:
> 
>> Hi,
> 
>> (for several patches in this series:)
>> The commit message is confusing.  See below.
> 
> Thanks for the edits, I will change the different commit messages.
> 
> 
> 
>> On 05/23/2018 12:54 PM, Thomas Garnier wrote:
>>> Adapt module loading to support PIE relocations. Generate dynamic GOT if
>>> a symbol requires it but no entry exist in the kernel GOT.
> 
>>  exists
> 
>>>
>>> Position Independent Executable (PIE) support will allow to extended the
> 
>>  will allow us to extend
> the
> 
>>> KASLR randomization range below the -2G memory limit.
> 
>> Does that say "below th negative 2G memory limit"?
>> I don't get it.
> 
> Yes, below 0x8000 basically. I think I will just say that.

Yes, please, that's much better.

> 
> 
>>>
>>> Signed-off-by: Thomas Garnier <thgar...@google.com>
>>> ---
>>>  arch/x86/Makefile   |   4 +
>>>  arch/x86/include/asm/module.h   |  11 ++
>>>  arch/x86/include/asm/sections.h |   4 +
>>>  arch/x86/kernel/module.c| 181 +++-
>>>  arch/x86/kernel/module.lds  |   3 +
>>>  5 files changed, 198 insertions(+), 5 deletions(-)
>>>  create mode 100644 arch/x86/kernel/module.lds
> 
> 
>> Thanks,
>> --
>> ~Randy
> 
> 
> 


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Randy Dunlap]

Hi,

(for several patches in this series:)
The commit message is confusing.  See below.


On 05/23/2018 12:54 PM, Thomas Garnier wrote:
> Adapt module loading to support PIE relocations. Generate dynamic GOT if
> a symbol requires it but no entry exist in the kernel GOT.

exists

> 
> Position Independent Executable (PIE) support will allow to extended the

will allow us to extend the

> KASLR randomization range below the -2G memory limit.

Does that say "below th negative 2G memory limit"?
I don't get it.


> 
> Signed-off-by: Thomas Garnier 
> ---
>  arch/x86/Makefile   |   4 +
>  arch/x86/include/asm/module.h   |  11 ++
>  arch/x86/include/asm/sections.h |   4 +
>  arch/x86/kernel/module.c| 181 +++-
>  arch/x86/kernel/module.lds  |   3 +
>  5 files changed, 198 insertions(+), 5 deletions(-)
>  create mode 100644 arch/x86/kernel/module.lds


Thanks,
-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 16/27] compiler: Option to add PROVIDE_HIDDEN replacement for weak symbols

[Randy Dunlap]

On 05/23/2018 12:54 PM, Thomas Garnier wrote:
> Provide an option to have a PROVIDE_HIDDEN (linker script) entry for
> each weak symbol. This option solve an error in x86_64 where the linker

solves

> optimizes pie generate code to be non-pie because --emit-relocs was used

generated

> instead of -pie (to reduce dynamic relocations).
> 
> Signed-off-by: Thomas Garnier 
> ---
>  init/Kconfig|  7 +++
>  scripts/link-vmlinux.sh | 14 ++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 0fc3a58d9f2f..2866cca86b4a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1954,6 +1954,13 @@ config ASN1
> inform it as to what tags are to be expected in a stream and what
> functions to call on what tags.
>  
> +config WEAK_PROVIDE_HIDDEN
> + bool
> + help
> +   Generate linker script PROVIDE_HIDDEN entries for all weak symbols. It
> +   allows to prevent non-pie code being replaced by the linker if the

non-PIE

> +   emit-relocs option is used instead of pie (useful for x86_64 pie).

PIEPIE).

> +


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH -resend 01/27] linkage: new macros for assembler symbols

[Randy Dunlap]

On 05/10/2018 01:06 AM, Jiri Slaby wrote:

> ---
>  Documentation/asm-annotations.rst | 218 
>  arch/x86/include/asm/linkage.h|  10 +-
>  include/linux/linkage.h   | 257 
> --
>  3 files changed, 475 insertions(+), 10 deletions(-)
>  create mode 100644 Documentation/asm-annotations.rst
> 
> diff --git a/Documentation/asm-annotations.rst 
> b/Documentation/asm-annotations.rst
> new file mode 100644
> index ..3e9b426347f0
> --- /dev/null
> +++ b/Documentation/asm-annotations.rst
> @@ -0,0 +1,218 @@
> +Assembler Annotations
> +=
> +
> +Copyright (c) 2017 Jiri Slaby

[snip]

> +This is not only important for debugging purposes. When we have properly
> +marked objects like this, we can run tools on them and let the tools generate
> +more useful information. In particular, on properly marked objects, we can 
> run
> +``objtool`` and let it check and fix the object if needed. Currently, it can
> +report missing frame pointer setup/destruction in functions. It can also
> +automatically generate annotations for *ORC unwinder* (cf.
> +) for most code. Both of this is

Both of these are

> +especially important to support reliable stack traces which are in turn
> +necessary for *Kernel live patching* (see
> +).
> +
> +Caveat and Discussion
> +-
> +As one might realize, there were only three macros previously. That is indeed
> +insufficient to cover all the combinations of cases:
> +
> +* standard/non-standard function
> +* code/data
> +* global/local symbol
> +
> +We had a discussion_ and instead of extending the current ``ENTRY/END*``
> +macros, it was decided that we shoould introduce brand new macros instead::

  should

> +
> +So how about using macro names that actually show the purpose, instead
> +of importing all the crappy, historic, essentially randomly chosen
> +debug symbol macro names from the binutils and older kernels?
> +
> +.. _discussion: https://marc.info/?i=20170217104757.28588-1-jslaby%40suse.cz
> +
> +Macros Description
> +--
> +
> +The new macros are prefixed with the ``SYM_`` prefix and can be divided into
> +three main groups:
> +
> +1. ``SYM_FUNC_*`` -- to annotate C-like functions. This means functions with
> +   standard C calling conventions, i.e. the stack contains a return address 
> at
> +   the predefined place and a return from the function can happen in a
> +   standard way. When frame pointers are enabled, save/restore of frame
> +   pointer shall happen at the start/end of a function, respectively, too.
> +
> +   Checking tools like ``objtool`` should ensure such marked functions 
> conform
> +   to these rules. The tools can also easily annotate these functions with
> +   debugging information (like *ORC data*) automatically.
> +
> +2. ``SYM_CODE_*`` -- special functions called with special stack. Be it
> +   interrupt handlers with special stack content, trampolines, or startup
> +   functions.
> +
> +   Checking tools mostly ignore checking of these functions. But some debug
> +   information still can be generated automatically. For correct debug data,
> +   this code needs hints like ``UNWIND_HINT_REGS`` provided by developers.
> +
> +3. ``SYM_DATA*`` -- obviosly data belonging to ``.data`` sections and not to

   obviously

> +   ``.text``. Data do not contain instructions, so they have to be treated
> +   specially by the tools: they should not treat the bytes as instructions,
> +   neither assign any debug information to them.

  nor assign

> +
> +Instruction Macros
> +~~
> +This section covers ``SYM_FUNC_*`` and ``SYM_CODE_*`` enumerated above.
> +

[snip]

> +
> +Data Macros
> +~~~
> +Similar to instructions, we have a couple of macros to describe data in the
> +assembly. Again, they help debuggers to understand the layout of the 
> resulting
> +object files.
> +
> +* ``SYM_DATA_START`` and ``SYM_DATA_START_LOCAL`` mark the start of some data
> +  and shall be in couple with either ``SYM_DATA_END``, or

(maybe:) and shall be used in conjunction with either

> +  ``SYM_DATA_END_LABEL``. The latter adds also a label to the end, so that
> +  people can use ``lstack`` and (local) ``lstack_end`` in the following
> +  example::
> +
> +SYM_DATA_START_LOCAL(lstack)
> +.skip 4096
> +SYM_DATA_END_LABEL(lstack, SYM_L_LOCAL, lstack_end)
> +
> +* ``SYM_DATA`` and ``SYM_DATA_LOCAL`` are variants for simple, mostly 
> one-line
> +  data::
> +
> +SYM_DATA(HEAP, .long rm_heap)
> +SYM_DATA(heap_end, .long rm_stack)
> +
> +  In the end, they expand to ``SYM_DATA_START`` with ``SYM_DATA_END``
> +  internally.
> +
> +Support Macros
> +~~
> +All the above reduce themselves to some invocation of ``SYM_START``,
> +``SYM_END``, or ``SYM_ENTRY`` at last. Normally, 

Re: [Xen-devel] [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Randy Dunlap]

Hi,

On 03/20/2018 12:18 PM, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH

 than

> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson 
> ---
>  arch/x86/Kconfig  | 7 +++
>  arch/x86/kernel/head_64.S | 4 ++--
>  arch/x86/xen/Kconfig  | 3 ++-
>  3 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..58831320b5d2 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,13 @@ config KVM_GUEST
> underlying device model, the host provides the guest with
> timing infrastructure such as time of day, and system time
>  
> +config PVH
> + bool "Support for running PVH guests"
> + def_bool n

You don't need two (2) "bool"s here. And 'n' is already the default, so just
drop the second line.

> + ---help---
> +   This option enables the PVH entry point for guest virtual machines
> +   as specified in the x86/HVM direct boot ABI.
> +
>  config KVM_DEBUG_FS
>   bool "Enable debug information for KVM Guests in debugfs"
>   depends on KVM_GUEST && DEBUG_FS


-- 
~Randy

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel