[Xen-devel] Completing a modprobe on xen-netback.ko

[#PATHANGI JANARDHANAN JATINSHRAVAN#]

Hi,
 Sorry for the blank email previously.


 I am trying to modify netback.c in the Linux Kernel and Observe the 
changes. I've cloned the latest Linux Kernel with Git, checked out version 
4.7.0 and compiled it with the config options listed here: 
https://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs for dom0 
support. Then I installed the modules and the kernel and I had a file 
'xen-netback.ko' present in /lib/modules/4.7.0/kernel/drivers/net/xen-netback.

When I tried a modprobe on this file, I got an error "modprobe: ERROR: could 
not insert 'xen_netback': No such device."


I wanted to know how to resolve this error. Should I build Xen from the source 
code or is it enough to just install the xen-hypervisor via apt-get (Ubuntu)?


Thanks
Jatin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Completing a modprobe on xen-netback.ko

[#PATHANGI JANARDHANAN JATINSHRAVAN#]

Hi,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 100993: tolerable FAIL - PUSHED

[osstest service owner]

flight 100993 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100993/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100966
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100966
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100966

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuue3571ae30cd26d19efd4554c25e32ef64d6a36b3
baseline version:
 qemuu8212ff86f4405b6128d89dd1d97ff2d6cfcf9842

Last test of basis   100966  2016-09-15 10:45:30 Z1 days
Failing since100971  2016-09-15 17:22:22 Z1 days5 attempts
Testing same since   100993  2016-09-16 20:48:24 Z0 days1 attempts


People who touched revisions under test:
  Alex Williamson 
  Andrew Dutcher 
  Ashijeet Acharya 
  Aurelien Jarno 
  Cao jin 
  Daniel P. Berrange 
  David Gibson 
  Eduardo Habkost 
  Fam Zheng 
  Gerd Hoffmann 
  Guan Xuetao 
  Hans Petter Selasky 
  Isaac Lozano <109loza...@gmail.com>
  John Arbuckle 
  Ladi Prosek 
  Laurent Vivier 
  Li Qiang 
  Lin Ma 
  Marc-André Lureau 
  Marc-André Lureau 
  Markus Armbruster 
  Md Haris Iqbal 
  Michael Tokarev 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Maydell 
  Pranith Kumar 
  Prasad J Pandit 
  Programmingkid 
  Reda Sallahi 
  Richard Henderson 
  Stanislav Shmarov 

Re: [Xen-devel] [for-4.8][PATCH v2 14/23] xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> The function p2m_cache_flush can be re-implemented using the generic
> function p2m_get_entry by iterating over the range and using the mapping
> order given by the callee.
> 
> As the current implementation, no preemption is implemented, although
> the comment in the current code claimed it. As the function is called by
> a DOMCTL with a region of 1GB maximum, I think the preemption can be
> left unimplemented for now.
> 
> Finally drop the operation CACHEFLUSH in apply_one_level as nobody is
> using it anymore. Note that the function could have been dropped in one
> go at the end, however I find easier to drop the operations one by one
> avoiding a big deletion in the patch that convert the last operation.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> The loop pattern will be very similar for the reliquish function.
> It might be possible to extract it in a separate function.
> 
> Changes in v2:
> - Introduce and use gfn_next_boundary
> - Flush all the mapping in a superpage rather than page by page.
> - Update doc
> ---
>  xen/arch/arm/p2m.c | 83 
> --
>  1 file changed, 50 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ddee258..fa58f1a 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -62,6 +62,22 @@ static inline void p2m_write_lock(struct p2m_domain *p2m)
>  write_lock(>lock);
>  }
>  
> +/*
> + * Return the start of the next mapping based on the order of the
> + * current one.
> + */
> +static inline gfn_t gfn_next_boundary(gfn_t gfn, unsigned int order)
> +{
> +/*
> + * The order corresponds to the order of the mapping (or invalid
> + * range) in the page table. So we need to align the GFN before
> + * incrementing.
> + */
> +gfn = _gfn(gfn_x(gfn) & ~((1UL << order) - 1));
> +
> +return gfn_add(gfn, 1UL << order);
> +}
> +
>  static void p2m_flush_tlb(struct p2m_domain *p2m);
>  
>  static inline void p2m_write_unlock(struct p2m_domain *p2m)
> @@ -734,7 +750,6 @@ enum p2m_operation {
>  INSERT,
>  REMOVE,
>  RELINQUISH,
> -CACHEFLUSH,
>  MEMACCESS,
>  };
>  
> @@ -993,36 +1008,6 @@ static int apply_one_level(struct domain *d,
>   */
>  return P2M_ONE_PROGRESS;
>  
> -case CACHEFLUSH:
> -if ( !p2m_valid(orig_pte) )
> -{
> -*addr = (*addr + level_size) & level_mask;
> -return P2M_ONE_PROGRESS_NOP;
> -}
> -
> -if ( level < 3 && p2m_table(orig_pte) )
> -return P2M_ONE_DESCEND;
> -
> -/*
> - * could flush up to the next superpage boundary, but would
> - * need to be careful about preemption, so just do one 4K page
> - * now and return P2M_ONE_PROGRESS{,_NOP} so that the caller will
> - * continue to loop over the rest of the range.
> - */
> -if ( p2m_is_ram(orig_pte.p2m.type) )
> -{
> -unsigned long offset = paddr_to_pfn(*addr & ~level_mask);
> -flush_page_to_ram(orig_pte.p2m.base + offset);
> -
> -*addr += PAGE_SIZE;
> -return P2M_ONE_PROGRESS;
> -}
> -else
> -{
> -*addr += PAGE_SIZE;
> -return P2M_ONE_PROGRESS_NOP;
> -}
> -
>  case MEMACCESS:
>  if ( level < 3 )
>  {
> @@ -1571,12 +1556,44 @@ int p2m_cache_flush(struct domain *d, gfn_t start, 
> unsigned long nr)
>  {
>  struct p2m_domain *p2m = >arch.p2m;
>  gfn_t end = gfn_add(start, nr);
> +gfn_t next_gfn;
> +p2m_type_t t;
> +unsigned int order;
>  
>  start = gfn_max(start, p2m->lowest_mapped_gfn);
>  end = gfn_min(end, p2m->max_mapped_gfn);
>  
> -return apply_p2m_changes(d, CACHEFLUSH, start, nr, INVALID_MFN,
> - 0, p2m_invalid, d->arch.p2m.default_access);
> +/*
> + * The operation cache flush will invalidate the RAM assigned to the
> + * guest in a given range. It will not modify the page table and
> + * flushing the cache whilst the page is used by another CPU is
> + * fine. So using read-lock is fine here.
> + */
> +p2m_read_lock(p2m);
> +
> +for ( ; gfn_x(start) < gfn_x(end); start = next_gfn )
> +{
> +mfn_t mfn = p2m_get_entry(p2m, start, , NULL, );
> +
> +next_gfn = gfn_next_boundary(start, order);
> +
> +/* Skip hole and non-RAM page */
> +if ( mfn_eq(mfn, INVALID_MFN) || !p2m_is_ram(t) )
> +continue;
> +
> +/* XXX: Implement preemption */
> +while ( gfn_x(start) < gfn_x(next_gfn) )
> +{
> +flush_page_to_ram(mfn_x(mfn));
> +
> +start = gfn_add(start, 1);
> +mfn = mfn_add(mfn, 1);
> +}
> +}
> +
> +p2m_read_unlock(p2m);
> +
> +

Re: [Xen-devel] [for-4.8][PATCH v2 12/23] xen/arm: p2m: Introduce p2m_get_entry and use it to implement __p2m_lookup

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> Currently, for a given GFN, the function __p2m_lookup will only return
> the associated MFN and the p2m type of the mapping.
> 
> In some case we need the order of the mapping and the memaccess
> permission. Rather than providing a separate function for this purpose,
> it is better to implement a generic function to return all the
> information.
> 
> To avoid passing dummy parameter, a caller that does not need a
> specific information can use NULL instead.
> 
> The list of the informations retrieved is based on the x86 version. All
> of them will be used in follow-up patches.
> 
> It might have been possible to extend __p2m_lookup, however I choose to
> reimplement it from scratch to allow sharing some helpers with the
> function that will update the P2M (will be added in a follow-up patch).
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Export p2m_get_entry
> - Fix the computation of the order when there is no mapping
> - Use level_orders rather than level_shifts - PAGE_SHIFT
> - Update documentation
> - Fix typoes
> - The definition of level_orders has been moved in an earlier
> patch
> ---
>  xen/arch/arm/p2m.c| 188 
> +++---
>  xen/include/asm-arm/p2m.h |   8 ++
>  2 files changed, 154 insertions(+), 42 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index b2a29ad..6e56b97 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -238,28 +238,104 @@ static lpae_t *p2m_get_root_pointer(struct p2m_domain 
> *p2m,
>  
>  /*
>   * Lookup the MFN corresponding to a domain's GFN.
> + * Lookup mem access in the ratrix tree.
> + * The entries associated to the GFN is considered valid.
> + */
> +static p2m_access_t p2m_mem_access_radix_get(struct p2m_domain *p2m, gfn_t 
> gfn)
> +{
> +void *ptr;
> +
> +if ( !p2m->mem_access_enabled )
> +return p2m->default_access;
> +
> +ptr = radix_tree_lookup(>mem_access_settings, gfn_x(gfn));
> +if ( !ptr )
> +return p2m_access_rwx;
> +else
> +return radix_tree_ptr_to_int(ptr);
> +}
> +
> +#define GUEST_TABLE_MAP_FAILED 0
> +#define GUEST_TABLE_SUPER_PAGE 1
> +#define GUEST_TABLE_NORMAL_PAGE 2
> +
> +static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry,
> +int level_shift);
> +
> +/*
> + * Take the currently mapped table, find the corresponding GFN entry,
> + * and map the next table, if available. The previous table will be
> + * unmapped if the next level was mapped (e.g GUEST_TABLE_NORMAL_PAGE
> + * returned).
>   *
> - * There are no processor functions to do a stage 2 only lookup therefore we
> - * do a a software walk.
> + * The read_only parameters indicates whether intermediate tables should
> + * be allocated when not present.
> + *
> + * Return values:
> + *  GUEST_TABLE_MAP_FAILED: Either read_only was set and the entry
> + *  was empty, or allocating a new page failed.
> + *  GUEST_TABLE_NORMAL_PAGE: next level mapped normally
> + *  GUEST_TABLE_SUPER_PAGE: The next entry points to a superpage.
>   */
> -static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
> +static int p2m_next_level(struct p2m_domain *p2m, bool read_only,
> +  lpae_t **table, unsigned int offset)
>  {
> -struct p2m_domain *p2m = >arch.p2m;
> -const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
> -const unsigned int offsets[4] = {
> -zeroeth_table_offset(paddr),
> -first_table_offset(paddr),
> -second_table_offset(paddr),
> -third_table_offset(paddr)
> -};
> -const paddr_t masks[4] = {
> -ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
> -};
> -lpae_t pte, *map;
> +lpae_t *entry;
> +int ret;
> +mfn_t mfn;
> +
> +entry = *table + offset;
> +
> +if ( !p2m_valid(*entry) )
> +{
> +if ( read_only )
> +return GUEST_TABLE_MAP_FAILED;
> +
> +ret = p2m_create_table(p2m, entry, /* not used */ ~0);
> +if ( ret )
> +return GUEST_TABLE_MAP_FAILED;
> +}
> +
> +/* The function p2m_next_level is never called at the 3rd level */
> +if ( p2m_mapping(*entry) )
> +return GUEST_TABLE_SUPER_PAGE;
> +
> +mfn = _mfn(entry->p2m.base);
> +
> +unmap_domain_page(*table);
> +*table = map_domain_page(mfn);
> +
> +return GUEST_TABLE_NORMAL_PAGE;
> +}
> +
> +/*
> + * Get the details of a given gfn.
> + *
> + * If the entry is present, the associated MFN will be returned and the
> + * access and type filled up. The page_order will correspond to the
> + * order of the mapping in the page table (i.e it could be a superpage).
> + *
> + * If the entry is not present, INVALID_MFN will be returned and the
> + * page_order will be set according to the order of the 

Re: [Xen-devel] [for-4.8][PATCH v2 11/23] xen/arm: p2m: Introduce p2m_get_root_pointer and use it in __p2m_lookup

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> Mapping the root table is always done the same way. To avoid duplicating
> the code in a later patch, move the code in a separate helper.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Use level_orders rather than level_shifts - PAGE_SHIFT
> - Move the definition of level_orders in this patch
> * use uint8_t rather than unsigned
> * define *_ORDER in term of *_SHIFT
> ---
>  xen/arch/arm/p2m.c | 55 
> +++---
>  xen/include/asm-arm/page.h |  4 
>  2 files changed, 41 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 413780b..b2a29ad 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -36,6 +36,8 @@ static const paddr_t level_masks[] =
>  { ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
>  static const uint8_t level_shifts[] =
>  { ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
> +static const uint8_t level_orders[] =
> +{ ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
>  
>  static bool_t p2m_valid(lpae_t pte)
>  {
> @@ -204,6 +206,37 @@ static void p2m_flush_tlb_sync(struct p2m_domain *p2m)
>  }
>  
>  /*
> + * Find and map the root page table. The caller is responsible for
> + * unmapping the table.
> + *
> + * The function will return NULL if the offset of the root table is
> + * invalid.
> + */
> +static lpae_t *p2m_get_root_pointer(struct p2m_domain *p2m,
> +gfn_t gfn)
> +{
> +unsigned int root_table;
> +
> +if ( P2M_ROOT_PAGES == 1 )
> +return __map_domain_page(p2m->root);
> +
> +/*
> + * Concatenated root-level tables. The table number will be the
> + * offset at the previous level. It is not possible to
> + * concatenate a level-0 root.
> + */
> +ASSERT(P2M_ROOT_LEVEL > 0);
> +
> +root_table = gfn_x(gfn) >> (level_orders[P2M_ROOT_LEVEL - 1]);
> +root_table &= LPAE_ENTRY_MASK;
> +
> +if ( root_table >= P2M_ROOT_PAGES )
> +return NULL;
> +
> +return __map_domain_page(p2m->root + root_table);
> +}
> +
> +/*
>   * Lookup the MFN corresponding to a domain's GFN.
>   *
>   * There are no processor functions to do a stage 2 only lookup therefore we
> @@ -226,7 +259,7 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
> p2m_type_t *t)
>  mfn_t mfn = INVALID_MFN;
>  paddr_t mask = 0;
>  p2m_type_t _t;
> -unsigned int level, root_table;
> +unsigned int level;
>  
>  ASSERT(p2m_is_locked(p2m));
>  BUILD_BUG_ON(THIRD_MASK != PAGE_MASK);
> @@ -236,22 +269,9 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
> p2m_type_t *t)
>  
>  *t = p2m_invalid;
>  
> -if ( P2M_ROOT_PAGES > 1 )
> -{
> -/*
> - * Concatenated root-level tables. The table number will be
> - * the offset at the previous level. It is not possible to
> - * concatenate a level-0 root.
> - */
> -ASSERT(P2M_ROOT_LEVEL > 0);
> -root_table = offsets[P2M_ROOT_LEVEL - 1];
> -if ( root_table >= P2M_ROOT_PAGES )
> -goto err;
> -}
> -else
> -root_table = 0;
> -
> -map = __map_domain_page(p2m->root + root_table);
> +map = p2m_get_root_pointer(p2m, gfn);
> +if ( !map )
> +return INVALID_MFN;
>  
>  ASSERT(P2M_ROOT_LEVEL < 4);
>  
> @@ -286,7 +306,6 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
> p2m_type_t *t)
>  *t = pte.p2m.type;
>  }
>  
> -err:
>  return mfn;
>  }
>  
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 05d9f82..a43b0fa 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -457,15 +457,19 @@ static inline int gva_to_ipa(vaddr_t va, paddr_t 
> *paddr, unsigned int flags)
>  #define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
>  
>  #define THIRD_SHIFT(PAGE_SHIFT)
> +#define THIRD_ORDER(THIRD_SHIFT - PAGE_SHIFT)
>  #define THIRD_SIZE ((paddr_t)1 << THIRD_SHIFT)
>  #define THIRD_MASK (~(THIRD_SIZE - 1))
>  #define SECOND_SHIFT   (THIRD_SHIFT + LPAE_SHIFT)
> +#define SECOND_ORDER   (SECOND_SHIFT - PAGE_SHIFT)
>  #define SECOND_SIZE((paddr_t)1 << SECOND_SHIFT)
>  #define SECOND_MASK(~(SECOND_SIZE - 1))
>  #define FIRST_SHIFT(SECOND_SHIFT + LPAE_SHIFT)
> +#define FIRST_ORDER(FIRST_SHIFT - PAGE_SHIFT)
>  #define FIRST_SIZE ((paddr_t)1 << FIRST_SHIFT)
>  #define FIRST_MASK (~(FIRST_SIZE - 1))
>  #define ZEROETH_SHIFT  (FIRST_SHIFT + LPAE_SHIFT)
> +#define ZEROETH_ORDER  (ZEROETH_SHIFT - PAGE_SHIFT)
>  #define ZEROETH_SIZE   ((paddr_t)1 << ZEROETH_SHIFT)
>  #define ZEROETH_MASK   (~(ZEROETH_SIZE - 1))
>  
> -- 
> 1.9.1
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [for-4.8][PATCH v2 09/23] xen/arm: p2m: Change the type of level_shifts from paddr_t to uint8_t

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> The level shift can be encoded with 8-bit. So it is not necessary to
> use paddr_t (i.e 64-bit).
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Use uint8_t rather than unsigned int
> - Replaced paddr_t by uint8_t in p2m_shatter_page
> ---
>  xen/arch/arm/p2m.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index b53d4cf..b4f75e8 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -687,14 +687,14 @@ static const paddr_t level_sizes[] =
>  { ZEROETH_SIZE, FIRST_SIZE, SECOND_SIZE, THIRD_SIZE };
>  static const paddr_t level_masks[] =
>  { ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
> -static const paddr_t level_shifts[] =
> +static const uint8_t level_shifts[] =
>  { ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
>  
>  static int p2m_shatter_page(struct p2m_domain *p2m,
>  lpae_t *entry,
>  unsigned int level)
>  {
> -const paddr_t level_shift = level_shifts[level];
> +const uint8_t level_shift = level_shifts[level];
>  int rc = p2m_create_table(p2m, entry, level_shift - PAGE_SHIFT);
>  
>  if ( !rc )
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [for-4.8][PATCH v2 07/23] xen/arm: traps: Check the P2M before injecting a data/instruction abort

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> A data/instruction abort may have occurred if another CPU was playing
> with the stage-2 page table when following the break-before-make
> sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly
> the fault to the guest, we need to check whether the mapping exists. If
> it exists, return to the guest to replay the instruction.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Remove spurious change
> - Fix typoes
> ---
>  xen/arch/arm/traps.c | 37 -
>  1 file changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 76e4152..d73d29a 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2405,6 +2405,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  register_t gva = READ_SYSREG(FAR_EL2);
>  uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
>  paddr_t gpa;
> +mfn_t mfn;
>  
>  if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
>  gpa = get_faulting_ipa(gva);
> @@ -2418,6 +2419,11 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>   */
>  flush_tlb_local();
>  
> +/*
> + * We may not be able to translate because someone is
> + * playing with the Stage-2 page table of the domain.
> + * Return to the guest.
> + */
>  rc = gva_to_ipa(gva, , GV2M_READ);
>  if ( rc == -EFAULT )
>  return; /* Try again */
> @@ -2438,8 +2444,17 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  /* Trap was triggered by mem_access, work here is done */
>  if ( !rc )
>  return;
> +break;
>  }
> -break;
> +case FSC_FLT_TRANS:
> +/*
> + * The PT walk may have failed because someone was playing
> + * with the Stage-2 page table. Walk the Stage-2 PT to check
> + * if the entry exists. If it's the case, return to the guest
> + */
> +mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(gpa)), NULL);
> +if ( !mfn_eq(mfn, INVALID_MFN) )
> +return;
>  }
>  
>  inject_iabt_exception(regs, gva, hsr.len);
> @@ -2484,6 +2499,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  int rc;
>  mmio_info_t info;
>  uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
> +mfn_t mfn;
>  
>  info.dabt = dabt;
>  #ifdef CONFIG_ARM_32
> @@ -2497,6 +2513,11 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  else
>  {
>  rc = gva_to_ipa(info.gva, , GV2M_READ);
> +/*
> + * We may not be able to translate because someone is
> + * playing with the Stage-2 page table of the domain.
> + * Return to the guest.
> + */
>  if ( rc == -EFAULT )
>  return; /* Try again */
>  }
> @@ -2520,11 +2541,25 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  break;
>  }
>  case FSC_FLT_TRANS:
> +/*
> + * Attempt first to emulate the MMIO as the data abort will
> + * likely happen in an emulated region.
> + */
>  if ( try_handle_mmio(regs, ) )
>  {
>  advance_pc(regs, hsr);
>  return;
>  }
> +
> +/*
> + * The PT walk may have failed because someone was playing
> + * with the Stage-2 page table. Walk the Stage-2 PT to check
> + * if the entry exists. If it's the case, return to the guest
> + */
> +mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(info.gpa)), 
> NULL);
> +if ( !mfn_eq(mfn, INVALID_MFN) )
> +return;
> +
>  break;
>  default:
>  gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [for-4.8][PATCH v2 06/23] xen/arm: traps: Move MMIO emulation code in a separate helper

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> Currently, a stage-2 fault translation will likely access an emulated
> region. All the checks are pre-sanitity check for MMIO emulation.
> 
> A follow-up patch will handle a new case that could lead to a stage-2
> translation. To improve the clarity of the code and the changes, the
> current implementation is move in a separate helper.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Keep the break in FSC_FLT_TRANS
> - Use bool instead of bool_t
> ---
>  xen/arch/arm/traps.c | 57 
> ++--
>  1 file changed, 33 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index a5a5384..76e4152 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2445,6 +2445,38 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  inject_iabt_exception(regs, gva, hsr.len);
>  }
>  
> +static bool try_handle_mmio(struct cpu_user_regs *regs,
> +mmio_info_t *info)
> +{
> +const struct hsr_dabt dabt = info->dabt;
> +int rc;
> +
> +/* stage-1 page table should never live in an emulated MMIO region */
> +if ( dabt.s1ptw )
> +return false;
> +
> +/* All the instructions used on emulated MMIO region should be valid */
> +if ( !dabt.valid )
> +return false;
> +
> +/*
> + * Erratum 766422: Thumb store translation fault to Hypervisor may
> + * not have correct HSR Rt value.
> + */
> +if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
> + dabt.write )
> +{
> +rc = decode_instruction(regs, >dabt);
> +if ( rc )
> +{
> +gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
> +return false;
> +}
> +}
> +
> +return !!handle_mmio(info);
> +}
> +
>  static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
>   const union hsr hsr)
>  {
> @@ -2488,29 +2520,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  break;
>  }
>  case FSC_FLT_TRANS:
> -if ( dabt.s1ptw )
> -goto bad_data_abort;
> -
> -/* XXX: Decode the instruction if ISS is not valid */
> -if ( !dabt.valid )
> -goto bad_data_abort;
> -
> -/*
> - * Erratum 766422: Thumb store translation fault to Hypervisor may
> - * not have correct HSR Rt value.
> - */
> -if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
> - dabt.write )
> -{
> -rc = decode_instruction(regs, );
> -if ( rc )
> -{
> -gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
> -goto bad_data_abort;
> -}
> -}
> -
> -if ( handle_mmio() )
> +if ( try_handle_mmio(regs, ) )
>  {
>  advance_pc(regs, hsr);
>  return;
> @@ -2521,7 +2531,6 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  hsr.bits, dabt.dfsc);
>  }
>  
> -bad_data_abort:
>  gdprintk(XENLOG_DEBUG, "HSR=0x%x pc=%#"PRIregister" gva=%#"PRIvaddr
>   " gpa=%#"PRIpaddr"\n", hsr.bits, regs->pc, info.gva, info.gpa);
>  inject_dabt_exception(regs, info.gva, hsr.len);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [for-4.8][PATCH v2 05/23] xen/arm: p2m: Add a back pointer to domain in p2m_domain

[Stefano Stabellini]

On Thu, 15 Sep 2016, Julien Grall wrote:
> The back pointer will be usefult later to get the domain when we only
> have the p2m in hand.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Patch added
> ---
>  xen/arch/arm/p2m.c| 1 +
>  xen/include/asm-arm/p2m.h | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 950a607..5cf136f 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1391,6 +1391,7 @@ int p2m_init(struct domain *d)
>  if ( rc != 0 )
>  return rc;
>  
> +p2m->domain = d;
>  p2m->max_mapped_gfn = _gfn(0);
>  p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
>  
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index b9269e4..b27a3a1 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -81,6 +81,9 @@ struct p2m_domain {
>   * enough available bits to store this information.
>   */
>  struct radix_tree_root mem_access_settings;
> +
> +/* back pointer to domain */
> +struct domain *domain;
>  };
>  
>  /*
> -- 
> 1.9.1
> 

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

[Xen-devel] [xen-unstable test] 100992: tolerable FAIL - PUSHED

[osstest service owner]

flight 100992 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100992/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100982
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 100982
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100982
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100982
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100982
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100982
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100982

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  6559a686ae77bca2539d826120c9f3bd0d75cdf8
baseline version:
 xen  115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8

Last test of basis   100982  2016-09-16 06:18:50 Z0 days
Testing same since   100992  2016-09-16 17:43:16 Z0 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern  

[Xen-devel] boot-wrapped xen image barfs with overlapped sections

[Jun Sun]

Hi, all,

I have been following the instructions at
https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation
to build xen for arm64.

When I tried to use the latest kernel instead of v3.13 as suggested, I
failed when building boot-wrapped image.  See below.

===
jsun@ubuntu:~/work/xen/linaro-2014-guide/boot-wrapper-aarch64$ make
CROSS_COMPILE=aarch64-linux-gnu- FDT_SRC=foundation-v8.dts xen-system.axf
aarch64-linux-gnu-ld -o xen-system.axf --script=model.xen.lds
aarch64-linux-gnu-ld: section .xen loaded at
[80a0,80ac061f] overlaps section .kernel loaded at
[8008,80c50dff]
Makefile:78: recipe for target 'xen-system.axf' failed
make: *** [xen-system.axf] Error 1
===

Obviously the issue is that linker script gives about 8.5MB space for
kernel which is too small. If I modify the linker script to give more space
to kernel, the xen will halt during boot up right before Dom0 starts:

==
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 8008
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x00a000-0x00c000 (512MB)
(XEN) Grant table range: 0x00ffe0-0x00ffe5e000
(XEN) Loading zImage from 8008 to
a008-a088
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0xa800-0xa8000fe7
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input
to Xen)
(XEN) Freed 276kB init memory.
==

Any pointers on the right way to get modern kernel working with xen on
ARM64?

Thanks.

Jun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [seabios baseline-only test] 67723: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67723 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67723/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 67703
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67703
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67703

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 seabios  dc2433e35bde0120e1765d8643cdf9e66e496661
baseline version:
 seabios  642db1905ab133007d7427b6758a2103fb09a19a

Last test of basis67703  2016-09-13 03:19:50 Z3 days
Testing same since67723  2016-09-16 15:48:41 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Igor Mammedov 
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit dc2433e35bde0120e1765d8643cdf9e66e496661
Author: Gerd Hoffmann 
Date:   Fri Sep 16 13:01:46 2016 +0200

virtio: fix virtio-pci

virtio-pci calls pci_enable_{io,mem}bar with the bar number,
but the functions expect the bar base register offset.

Reported-by: Igor Mammedov 
Tested-by: Igor Mammedov 
Signed-off-by: Gerd Hoffmann 

commit 8d8d483d524c5a16641b16ad6beab5850cc5a15c
Author: Kevin O'Connor 
Date:   Mon Sep 12 10:43:30 2016 -0400

kbd: Move extended and release events out of special key detection switch

Move checking for extended scancodes and key release to the top of
__process_key().

Signed-off-by: Kevin O'Connor 

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

[Xen-devel] stack size limit issues with xen + qemu + rbd

[Chris Patterson]

I have spent some time investigating a case where qemu is failing to
register xenstore watches for a PV guest once I enable vfb (and
thereby triggering the creation of a qemu instance).

The qemu logs show something along the lines of:
xen be core: xen be core: xen be: watching backend path
(backend/console/3) failed
xen be: watching backend path (backend/console/3) failed
xen be core: xen be core: xen be: watching backend path (backend/vkbd/3) failed
xen be: watching backend path (backend/vkbd/3) failed
xen be core: xen be core: xen be: watching backend path (backend/qdisk/3) failed
xen be: watching backend path (backend/qdisk/3) failed
xen be core: xen be core: xen be: watching backend path (backend/qusb/3) failed
xen be: watching backend path (backend/qusb/3) failed
xen be core: xen be core: xen be: watching backend path (backend/vfb/3) failed
xen be: watching backend path (backend/vfb/3) failed
xen be core: xen be core: xen be: watching backend path (backend/qnic/3) failed
xen be: watching backend path (backend/qnic/3) failed

I have tested qemu master, qemu-xen in the master xen tree, as well as
a few tags all with the same issue.

I came across a similar issue reported by Juergen Gross:
https://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg03341.html

Sure enough, the thread stack size was the culprit.  I had been
testing with qemu with the associated fix "vnc-tight: fix regression
with libxenstore" as it is in master, so that wasn't it...

I did some basic analysis of the qemu binary and the libraries it is pulling in:

for lib in $(ldd /usr/local/bin/qemu-system-i386 | grep -o '/.* '); do
echo "lib=$lib"; readelf -S "$lib" | grep -e tbss -e tdata -A1 ; done

The largest consumers were:
lib=/usr/lib/x86_64-linux-gnu/librbd.so.1
  [17] .tbss NOBITS   0088fed0  0068fed0
   1820   WAT   0 0 8
lib=/usr/lib/x86_64-linux-gnu/librados.so.2
  [17] .tbss NOBITS   00718600  00518600
   0aa0   WAT   0 0 8

IIUC, librbd & librados are using nearly 9k of the 16k alone (I am
assuming this thread-local storage must be consumed as part of the
thread's stack)?

I narrowed that down to Ceph's usage of __thread in stringify() in
src/include/stringify.h.

To make things functional, the options were either to:
(a) disable rbd at configure time for qemu
(b) reduce the level of thread-local storage in dependencies
(particularly ceph's stringify)
(c) increase the stack size specified in xenstore's xs.c

Is there is any precedent/policy with regards to expected TLS and/or
stack usage for dependencies?  Is the best course of action (b)? Or
perhaps reconsider the default size for (c)?

Thoughts? :)

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

Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

[Konrad Rzeszutek Wilk]

On Mon, Sep 12, 2016 at 10:18:16PM +0200, Daniel Kiper wrote:
> Currently ELF end of image address is calculated using first line from
> "nm -nr xen/xen-syms" output. However, today usually it contains random
> symbol address not related to end of image in any way. So, it looks

Weird. The -n says:

"  -n
   -v
   --numeric-sort
   Sort symbols numerically by their addresses, rather than 
alphabetically by their names.
"

And you are right. It is ignoring it:

[konrad@char xen]$ nm -nr xen/xen-syms| sort | head -1
82d08000 T __image_base__
[konrad@char xen]$ nm -nr xen/xen-syms | head -1
82d08033d000 B efi

[konrad@char xen]$ nm -nr xen/xen-syms| sort | tail -5
82d08033cb00 B _end
82d08033cb00 B __per_cpu_data_end
82d08033d000 B __2M_rwdata_end
82d08033d000 B efi
 U _GLOBAL_OFFSET_TABLE_

> that for years that stuff have been working just by lucky coincidence.
> Hence, it have to be changed to something more reliable. So, let's take
> ELF end of image address by reading _end symbol address from nm output.
> 
> Signed-off-by: Daniel Kiper 
> ---
>  xen/arch/x86/Makefile |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index d3875c5..a4fe740 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -91,7 +91,7 @@ endif
>  
>  $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
>   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
> - `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
> + `$(NM) -nr $(TARGET)-syms | awk '$$3 == "_end" {print "0x"$$1}'`
>  

Something is off with your tabs/spaces.


I would also modify the arch/x86/xen.lds.S and put a comment
around _end = .; to mention this dependency - in case somebody adds some 
extra things after _end.


>  .PHONY: tests
>  tests:
> -- 
> 1.7.10.4
> 

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

[Xen-devel] [qemu-mainline test] 100989: trouble: broken/fail/pass

[osstest service owner]

flight 100989 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100989/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  3 host-install(3)broken REGR. vs. 100966

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100966
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100966
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100966

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuuebc231d7daf1f41b23d8b6a6d1234800b86e5fe2
baseline version:
 qemuu8212ff86f4405b6128d89dd1d97ff2d6cfcf9842

Last test of basis   100966  2016-09-15 10:45:30 Z1 days
Failing since100971  2016-09-15 17:22:22 Z1 days4 attempts
Testing same since   100989  2016-09-16 14:19:16 Z0 days1 attempts


People who touched revisions under test:
  Alex Williamson 
  Andrew Dutcher 
  Ashijeet Acharya 
  Aurelien Jarno 
  Cao jin 
  Daniel P. Berrange 
  David Gibson 
  Eduardo Habkost 
  Fam Zheng 
  Gerd Hoffmann 
  Guan Xuetao 
  Hans Petter Selasky 
  Isaac Lozano <109loza...@gmail.com>
  John Arbuckle 
  Ladi Prosek 
  Laurent Vivier 
  Li Qiang 
  Lin Ma 
  Marc-André Lureau 
  Marc-André Lureau 
  Markus Armbruster 
  Md Haris Iqbal 
  Michael Tokarev 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Maydell 
  Prasad J Pandit 
  Programmingkid 
  Reda Sallahi 
  Richard Henderson 
  Stanislav Shmarov 
  Stefan Hajnoczi 

[Xen-devel] [xen-unstable baseline-only test] 67721: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67721 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67721/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 67718

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67718
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67718
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67718
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67718
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67718
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67718
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67718
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67718
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67718
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67718
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67718
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67718
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67718
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67718

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 xen  115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8
baseline version:
 xen  3ab5fb9a9eeb2b610d5d74419e0b1ffaf18484f2

Last test of basis67718  2016-09-15 16:14:16 Z1 days
Testing same since

[Xen-devel] [PATCH v4] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.

The intended use-case for this feature is for a monitor application to be able
insert tap-points into the domU kernel-code. For this task only unconditional
SMC instruction should be used.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
Acked-by: Razvan Cojocaru 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v4: Style fixes

Note: previous discussion around this patch proposed filtering SMCs with failed
  condition checks. As that patch is yet-to-be implemented and the 4.8
  code-freeze rapidly approaching I would like this patch to get included.
  In this patch a proper warning is placed in the public header for
  potential users not to rely on SMCs with failed condition checks being
  trapped. As the intended use-case for this feature doesn't use
  conditional SMCs this warning should be sufficient. Hardware that does
  issue events for SMCs with failed condition checks doesn't pose a problem
  for a monitor application in any way. The xen-access test tool illustrates
  how SMCs issued by the guest can be safely handled for all cases.
---
 tools/libxc/include/xenctrl.h   |  2 +
 tools/libxc/xc_monitor.c| 14 +++
 tools/tests/xen-access/xen-access.c | 32 ++-
 xen/arch/arm/Makefile   |  1 +
 xen/arch/arm/monitor.c  | 80 +
 xen/arch/arm/traps.c| 16 +++-
 xen/include/asm-arm/domain.h|  5 +++
 xen/include/asm-arm/monitor.h   | 18 +++--
 xen/include/public/domctl.h |  1 +
 xen/include/public/vm_event.h   |  7 
 10 files changed, 160 insertions(+), 16 deletions(-)
 create mode 100644 xen/arch/arm/monitor.c

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 560ce7b..eb53172 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2168,6 +2168,8 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id,
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 4298813..15a7c32 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -185,6 +185,20 @@ int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, 
bool enable)
 return do_domctl(xch, );
 }
 
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index ed18c71..cadeae1 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -338,6 +338,8 @@ void usage(char* progname)
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
 fprintf(stderr, 
"|breakpoint|altp2m_write|altp2m_exec|debug|cpuid");
+#elif defined(__arm__) || defined(__aarch64__)
+fprintf(stderr, "|privcall");
 #endif
 fprintf(stderr,
 "\n"
@@ -362,6 +364,7 @@ int main(int argc, char *argv[])
 int required = 0;
 int breakpoint = 0;
 int shutting_down = 0;
+int privcall = 0;
 int altp2m = 0;
 int debug = 0;
 int cpuid = 0;
@@ -431,6 +434,11 @@ int main(int argc, char *argv[])
 {
 cpuid = 1;
 }
+#elif defined(__arm__) || defined(__aarch64__)
+else if ( !strcmp(argv[0], "privcall") )
+{
+privcall = 1;
+}
 #endif
 else
 {
@@ -563,6 +571,16 @@ int main(int argc, char *argv[])
 }
 }
 
+if ( privcall )
+{
+rc = xc_monitor_privileged_call(xch, domain_id, 1);
+if ( rc < 0 )
+{
+ERROR("Error %d setting privileged call trapping with vm_event\n", 
rc);
+goto exit;
+}
+}
+
 /* 

[Xen-devel] [xen-unstable-smoke test] 100991: tolerable all pass - PUSHED

[osstest service owner]

flight 100991 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100991/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  6559a686ae77bca2539d826120c9f3bd0d75cdf8
baseline version:
 xen  115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8

Last test of basis   100968  2016-09-15 13:02:22 Z1 days
Testing same since   100991  2016-09-16 16:02:30 Z0 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=6559a686ae77bca2539d826120c9f3bd0d75cdf8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
6559a686ae77bca2539d826120c9f3bd0d75cdf8
+ branch=xen-unstable-smoke
+ revision=6559a686ae77bca2539d826120c9f3bd0d75cdf8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x6559a686ae77bca2539d826120c9f3bd0d75cdf8 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 39a05fd..cf58fd5 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -41,6 +41,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "decode.h"
>>  #include "vtimer.h"
>> @@ -2527,6 +2528,16 @@ bad_data_abort:
>>  inject_dabt_exception(regs, info.gva, hsr.len);
>>  }
>>
>> +static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
>> +{
>> +int rc = 0;
>
>
> Missing blank line.
>
>> +if ( current->domain->arch.monitor.privileged_call_enabled )
>> +rc = monitor_smc();
>> +
>> +if ( rc != 1 )
>> +inject_undef_exception(regs, hsr);
>
>
> It would be worth mentioning somewhere that you expect the monitor app
> skipping the instruction.
>

Not necessarily. If it's an SMC the guest issues by itself then yes,
it can be safely turned effectively into a NOP by incrementing PC. But
there are other things the monitor application can do as well. For
example, during malware analysis if we want to remain stealthy we
would still want to inject an undefined instruction exception, or even
destroy the guest altogether, otherwise the NOP-d SMC would reveal the
presence of the monitor application. For SMC's that the monitor
application itself injects, just incrementing the PC would not be
enough either as we overwrote an instruction that should be executed
to continue normal execution. That problem can also be solved, and
also not by incrementing the PC.

Tamas

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

Re: [Xen-devel] [PATCH v4 08/16] livepatch: Move test-cases to their own sub-directory in test.

[Konrad Rzeszutek Wilk]

On Fri, Sep 16, 2016 at 12:38:20PM -0400, Konrad Rzeszutek Wilk wrote:
> So they can be shared with ARM64 (but not yet, so they
> are only built on x86).
> 
> No functional change.
> 
> We also need to tweak the MAINTAINERS and .gitignore file.
> 
> Also we need to update SUBDIRS to include the new 'test'
> directory so 'cscope' can show the example livepatches.
> 
> Acked-by: Jan Beulich  [for directory]
> Signed-off-by: Konrad Rzeszutek Wilk 
> 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> 
> v1: First submission
> v2: Move to test/livepatch per Jan's recommendation
> v3: Sort MAINTAINERS for livepatch.
> Add Jan's Acked-by.
> Added on the SUBDIRS the 'test' directory
> Change title of patch (common-> own sub-directory)
> ---
>  .gitignore  |  8 +--
>  MAINTAINERS |  1 +
>  xen/Makefile|  5 +-
>  xen/arch/arm/Makefile   |  3 -
>  xen/arch/x86/Makefile   |  5 --
>  xen/arch/x86/test/Makefile  | 85 
> -
>  xen/arch/x86/test/xen_bye_world.c   | 34 
>  xen/arch/x86/test/xen_bye_world_func.c  | 22 
>  xen/arch/x86/test/xen_hello_world.c | 67 ---
>  xen/arch/x86/test/xen_hello_world_func.c| 39 -
>  xen/arch/x86/test/xen_replace_world.c   | 33 ---
>  xen/arch/x86/test/xen_replace_world_func.c  | 22 
>  xen/test/Makefile   |  9 +++
>  xen/test/livepatch/Makefile | 85 
> +
>  xen/test/livepatch/xen_bye_world.c  | 34 
>  xen/test/livepatch/xen_bye_world_func.c | 22 
>  xen/test/livepatch/xen_hello_world.c| 67 +++
>  xen/test/livepatch/xen_hello_world_func.c   | 39 +
>  xen/test/livepatch/xen_replace_world.c  | 33 +++
>  xen/test/livepatch/xen_replace_world_func.c | 22 
>  20 files changed, 319 insertions(+), 316 deletions(-)
>  delete mode 100644 xen/arch/x86/test/Makefile
>  delete mode 100644 xen/arch/x86/test/xen_bye_world.c
>  delete mode 100644 xen/arch/x86/test/xen_bye_world_func.c
>  delete mode 100644 xen/arch/x86/test/xen_hello_world.c
>  delete mode 100644 xen/arch/x86/test/xen_hello_world_func.c
>  delete mode 100644 xen/arch/x86/test/xen_replace_world.c
>  delete mode 100644 xen/arch/x86/test/xen_replace_world_func.c
>  create mode 100644 xen/test/Makefile
>  create mode 100644 xen/test/livepatch/Makefile
>  create mode 100644 xen/test/livepatch/xen_bye_world.c
>  create mode 100644 xen/test/livepatch/xen_bye_world_func.c
>  create mode 100644 xen/test/livepatch/xen_hello_world.c
>  create mode 100644 xen/test/livepatch/xen_hello_world_func.c
>  create mode 100644 xen/test/livepatch/xen_replace_world.c
>  create mode 100644 xen/test/livepatch/xen_replace_world_func.c


ARGH!!!

There has to be some .gitconfig parameter for this.

In the meantime please ignore this patch and instead see this one:


From 50f28785cff34a060ae528dc21493ee41ad55cdd Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 12 Aug 2016 15:27:58 -0400
Subject: [PATCH v5] livepatch: Move test-cases to their own sub-directory in
 test.

So they can be shared with ARM64 (but not yet, so they
are only built on x86).

No functional change.

We also need to tweak the MAINTAINERS and .gitignore file.

Also we need to update SUBDIRS to include the new 'test'
directory so 'cscope' can show the example livepatches.

Acked-by: Jan Beulich  [for directory]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v1: First submission
v2: Move to test/livepatch per Jan's recommendation
v3: Sort MAINTAINERS for livepatch.
Add Jan's Acked-by.
Added on the SUBDIRS the 'test' directory
Change title of patch (common-> own sub-directory)
---
 .gitignore | 8 
 MAINTAINERS| 1 +
 xen/Makefile   | 5 +++--
 xen/arch/arm/Makefile  | 3 ---
 xen/arch/x86/Makefile  | 5 -
 xen/test/Makefile  | 9 +
 xen/{arch/x86/test => test/livepatch}/Makefile | 0
 xen/{arch/x86/test => test/livepatch}/xen_bye_world.c  | 0
 xen/{arch/x86/test => test/livepatch}/xen_bye_world_func.c | 0
 

[Xen-devel] [PATCH v4 07/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

[Konrad Rzeszutek Wilk]

Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are suppose
to help the final linker to make any adjustments (such as
add an veneer). But more importantly - we do not compile Xen
with any Thumb instructions (which are variable length) - and
if we find these mapping symbols we should disallow such payload.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v3: New submission.
Use [i] instead of sym (as that will always be NULL).
v4: Use bool instead of int for return
Update comment in common code about ARM odd symbols.
s/_check/_deny/ to make it more clear.
---
 xen/arch/arm/livepatch.c| 14 ++
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch_elf.c  |  7 +++
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 30 insertions(+)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index a87d48c..13d6c10 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+#ifdef CONFIG_ARM_32
+/*
+ * Xen does not use Thumb instructions - and we should not see any of
+ * them. If we do, abort.
+ */
+if ( sym->name && *sym->name == '$' && sym->name[1] == 't' )
+return true;
+#endif
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index efc487a..79be833 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -125,6 +125,13 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index 79c290e..a4f6794 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -251,6 +251,13 @@ static int elf_get_sym(struct livepatch_elf *elf, const 
void *data)
 
 sym[i].sym = s;
 sym[i].name = strtab_sec->data + delta;
+/* e.g. On ARM we should NEVER see $t* symbols. */
+if ( arch_livepatch_symbol_deny(elf, [i]) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Symbol '%s' should not be in 
payload!\n",
+elf->name, sym[i].name);
+return -EINVAL;
+}
 }
 elf->nsym = nsym;
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 03abc5b..d107a75 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -50,6 +50,8 @@ bool_t is_patch(const void *addr);
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf);
 bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
   const struct livepatch_elf_sym *sym);
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym);
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela);
-- 
2.5.5


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

[Xen-devel] [PATCH v4 06/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

[Konrad Rzeszutek Wilk]

Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.

Either way - we can ignore these symbols.

Reviewed-by: Andrew Cooper  [x86 bits]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v1: First submission
v2: Update the order of symbols, fix title
Add {} in after the first if - per Jan's recommendation.
v3: Add Andrew's Review tag
Make the function return an bool_t.
Skip check for '$t'
Fix spelling of comments.
s/arch_is_payload_symbol/arch_livepatch_symbol_ok/
v4: s/bool_t/bool/
---
 xen/arch/arm/livepatch.c| 33 +
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch.c  |  2 +-
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index b4b4b6c..a87d48c 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -84,6 +84,39 @@ void arch_livepatch_unmask(void)
 local_abort_enable();
 }
 
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym)
+{
+/*
+ * - Mapping symbols - denote the "start of a sequence of bytes of the
+ *   appropriate type" to mark certain features - such as start of region
+ *   containing data ($d); ARM ($a), or A64 ($x) instructions.
+ *   We ignore Thumb instructions ($t) as we shouldn't have them.
+ *
+ * The format is either short: '$x' or long: '$x.'. We do not
+ * need this and more importantly - each payload will contain this
+ * resulting in symbol collisions.
+ */
+if ( *sym->name == '$' && sym->name[1] != '\0' )
+{
+char p = sym->name[1];
+size_t len = strlen(sym->name);
+
+if ( (len >= 3 && ( sym->name[2] == '.' )) || (len == 2) )
+{
+if ( p == 'd' ||
+#ifdef CONFIG_ARM_32
+ p == 'a'
+#else
+ p == 'x'
+#endif
+   )
+return false;
+}
+}
+return true;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index d4ac61f..efc487a 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -118,6 +118,13 @@ int arch_livepatch_verify_elf(const struct livepatch_elf 
*elf)
 return 0;
 }
 
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return true;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 38260b9..25d9865 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -744,7 +744,7 @@ static bool_t is_payload_symbol(const struct livepatch_elf 
*elf,
  !strncmp(sym->name, ".L", 2) )
 return 0;
 
-return 1;
+return arch_livepatch_symbol_ok(elf, sym);
 }
 
 static int build_symbol_table(struct payload *payload,
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 6ea92b5..03abc5b 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -48,6 +48,8 @@ bool_t is_patch(const void *addr);
 
 /* Arch hooks. */
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf);
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym);
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela);
-- 
2.5.5


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

[Xen-devel] [PATCH v4 12/16] bug/x86/arm: Align bug_frames sections.

[Konrad Rzeszutek Wilk]

Most of the WARN_ON or BUG_ON sections are properly aligned on
x86. However on ARM and on x86 assembler the macros don't include
any aligment information - hence they end up being the default
byte granularity.

On ARM32 it is paramount that the aligment is word-size (4)
otherwise if one tries to use (uint32_t*) access (such
as livepatch ELF relocations) we get a Data Abort.

Enforcing bug_frames to have the proper aligment across all
architectures and in both C and x86 makes them all the same.

Furthermore on x86 the bloat-o-meter detects that with this
change:

add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
function old new   delta

On ARM32:
add/remove: 1/0 grow/shrink: 0/1 up/down: 384/-288 (96)
function old new   delta
gnttab_unpopulate_status_frames- 384+384
do_grant_table_op  10808   10520-288

And ARM64:
add/remove: 1/2 grow/shrink: 0/1 up/down: 4164/-4236 (-72)
function old new   delta
gnttab_map_grant_ref   -4164   +4164
do_grant_table_op   98929836 -56
grant_map_exists 300   --300
__gnttab_map_grant_ref  3880   -   -3880

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: First submission. Replaces the "livepatch/elf: Adjust section aligment to 
word"
patch.
v4: Remove the .ALIGN(4) in xen.lds.S for x86 (the only place needing
that change).
Update the commit description with correct x86 results
Remove the . = ALIGN(4); in linker filer on x86 [the only file needing the 
change]
---
 xen/arch/x86/xen.lds.S| 1 -
 xen/include/asm-arm/bug.h | 1 +
 xen/include/asm-x86/bug.h | 1 +
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d903c31..7676de9 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -79,7 +79,6 @@ SECTIONS
   .rodata : {
_srodata = .;
/* Bug frames table */
-   . = ALIGN(4);
__start_bug_frames = .;
*(.bug_frames.0)
__stop_bug_frames_0 = .;
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
index 68353e1..773d63e 100644
--- a/xen/include/asm-arm/bug.h
+++ b/xen/include/asm-arm/bug.h
@@ -52,6 +52,7 @@ struct bug_frame {
  ".popsection\n"\
  ".pushsection .bug_frames." __stringify(type) ", \"a\", %progbits\n"\
  "4:\n" \
+ ".align 4\n"   \
  ".long (1b - 4b)\n"\
  ".long (2b - 4b)\n"\
  ".long (3b - 4b)\n"\
diff --git a/xen/include/asm-x86/bug.h b/xen/include/asm-x86/bug.h
index c5d2d4c..9bb4a19 100644
--- a/xen/include/asm-x86/bug.h
+++ b/xen/include/asm-x86/bug.h
@@ -98,6 +98,7 @@ extern const struct bug_frame __start_bug_frames[],
 .popsection
 
 .pushsection .bug_frames.\type, "a", @progbits
+.p2align 2
 .L\@bf:
 .long (.L\@ud - .L\@bf) + \
((\line >> BUG_LINE_LO_WIDTH) << BUG_DISP_WIDTH)
-- 
2.5.5


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

[Xen-devel] [PATCH v4 04/16] livepatch: Initial ARM64 support.

[Konrad Rzeszutek Wilk]

As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.

Since we are doing vmap we may fail, hence the
arch_livepatch_quiesce was changed (see "x86,arm:
Change arch_livepatch_quiesce() declaration") to return
an error value which will be bubbled in payload->rc and
provided to the user (along with messages in the ring buffer).

The livepatch virtual address space (where the new functions
are) needs to be close to the hypervisor virtual address
so that the trampoline can reach it. As such we re-use
the BOOT_RELOC_VIRT_START which is not used after bootup
(alternatively we can also use the space after the _end to
FIXMAP_ADDR(0), but that may be too small).

The ELF relocation engine at the start was coded from
the "ELF for the ARM 64-bit Architecture (AArch64)"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf)
but after a while of trying to write the correct bit shifting
and masking from scratch I ended up borrowing from Linux, the
'reloc_insn_imm' (Linux v4.7 arch/arm64/kernel/module.c function.
See 257cb251925f854da435cbf79b140984413871ac "arm64: Loadable modules")

And while at it - we also utilize code from Linux to construct
the right branch instruction (see "arm64/insn: introduce
aarch64_insn_gen_{nop|branch_imm}() helper functions").

In the livepatch payload loading code we tweak the #ifdef to
only exclude ARM_32. The exceptions are not part of ARM 32/64 hence
they are still behind the #ifdef.

We also expand the MAINTAINERS file to include the arm64 and arm32
platform specific livepatch file.

Acked-by: Jan Beulich  [non-arm parts]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc  Jan Beulich 
Cc: Andrew Cooper 

RFC: Wholy cow! It works!
v1: Finished the various TODOs and reviews outlined by Julien in RFC.
v2: Call check_for_livepatch_work in leave_hypervisor_tail not in
reset_stack_and_jump
   - Move ARM 32 components in other patch
   - Blacklist platform options in Kconfig
   - Added R_AARCH64_LDST128_ABS_LO12_NC, R_AARCH64_TSTBR14, and
 R_AARCH64_ADR_PREL_PG_HI21_NC
   - Added do_reloc and reloc_data along with overflow checks from Linux.
   - Use apply_alternatives without any #ifdef
   - Use leave_hypervisor_tail to call check_for_livepatch_work
   - Add ASSERT that isns is not AARCH64_BREAK_FAULT
   - Spun out arch_livepatch_quiesce changes in seperate patch.
   - Spun out changes to config.h (document ones) to seperate patch.
   - Move the livepatch.h to include/xen/asm-arm.
   - Add LIVEPATCH_VMAP_END and LIVEPATCH_VMAP_START in config.h
   - In arch_livepatch_secure use switch for va_type.
   - Drop the #ifndef CONFIG_ARM for .ex_table (see
 "arm/x86: Add HAS_ALTERNATIVE and HAS_EX_TABLE")
   - Piggyback on "x86: change modify_xen_mappings to return error"
  so that arch_livepatch_secure can return errors.
   - Moves comment about branch predictor out of this patch.
v3: Fix StyleGuide violations (switch statements)
   - Fix incorrect cast of addr when reverting.
   - Drop old_ptr variable.
   - Use bool_t values instead of numbers.
   - Sprinkle \n as requested by Julien.
   - In arch_livepatch_quiesce use 1U instead of 1.
   - Use C99 #defines for [U,]INT[16,32]_[MIN,MAX] instead of Linux
 kernel ones ([S,U][16,32]_[MIN,MAX]).
   - Include the ELF relocations for R_AARCH64_[ABS,PRE]16, and
 all the various groupings for R_AARCH64_MOVW_[UABS,SABS,PREL]_*
 family.
   - Redo the NOP patching to use more of the opaque size (so up to 7
 instructions in one go).
   - Drop the cpu_to_le32 macros as they are not needed (and can allow
 use to share more code with ARM32).
   - Flush out func->old_addr instead of vmap pointer when reverting.
v4: Added Jan's Ack
   s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
   s/arch_livepatch_insn_len/livepatch_insn_len/
---
 MAINTAINERS |   1 +
 xen/arch/arm/Makefile   |  13 +-
 xen/arch/arm/arm32/Makefile |   1 +
 xen/arch/arm/arm32/livepatch.c  |  38 
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/livepatch.c  | 477 
 xen/arch/arm/domain.c   |   6 +
 xen/arch/arm/livepatch.c| 103 +++--
 xen/arch/arm/traps.c|   6 +
 xen/common/Kconfig  |   2 +-
 xen/include/asm-arm/config.h|   5 +
 xen/include/asm-arm/livepatch.h |  28 +++
 xen/include/xen/elfstructs.h|  57 -
 xen/include/xen/types.h |   9 +
 14 files changed, 722 insertions(+), 25 deletions(-)
 create mode 100644 xen/arch/arm/arm32/livepatch.c
 create 

[Xen-devel] [PATCH v4 09/16] livepatch: tests: Make them compile under ARM64

[Konrad Rzeszutek Wilk]

We need to two things:
1) Wrap the platform-specific objcopy parameters in defines
   The input and output parameters for $(OBJCOPY) are different
   based on the platforms. As such provide them in the
   OBJCOPY_MAGIC define and use that.

2) The alternative is a bit different and there are no
   exceptions under ARM (but there are under ARM 64).
   Also use one of the first config options for the CPU
   field feature.

We are not yet attempting to build them under ARM32 so
that is still ifdefed out.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v1: First submission
v2: Corrected description by Julien
Add #ifeq instead of #else for ARM case.
v3: Moved 'asm(alter..)' by one space to the left.
v4: Rebase on top of "livepatch/tests: Make .livepatch.depends be read-only"
---
 xen/test/Makefile |  2 +-
 xen/test/livepatch/Makefile   | 12 ++--
 xen/test/livepatch/xen_hello_world_func.c |  8 +++-
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/xen/test/Makefile b/xen/test/Makefile
index 8c53040..95c1755 100644
--- a/xen/test/Makefile
+++ b/xen/test/Makefile
@@ -1,6 +1,6 @@
 .PHONY: tests
 tests:
-ifeq ($(XEN_TARGET_ARCH),x86_64)
+ifneq $(XEN_TARGET_ARCH),arm32)
$(MAKE) -f $(BASEDIR)/Rules.mk -C livepatch livepatch
 endif
 
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 48ff843..5db4d9c 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -1,5 +1,12 @@
 include $(XEN_ROOT)/Config.mk
 
+ifeq ($(XEN_TARGET_ARCH),x86_64)
+OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
+endif
+ifeq ($(XEN_TARGET_ARCH),arm64)
+OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
+endif
+
 CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
 CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
 
@@ -54,8 +61,9 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
 .PHONY: note.o
 note.o:
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@.bin
-   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
+  --rename-section=.data=.livepatch.depends -S $@.bin $@
rm -f $@.bin
 
 #
@@ -65,7 +73,7 @@ note.o:
 .PHONY: hello_world_note.o
 hello_world_note.o: $(LIVEPATCH)
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH) 
$@.bin
-   $(OBJCOPY)  -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
rm -f $@.bin
 
diff --git a/xen/test/livepatch/xen_hello_world_func.c 
b/xen/test/livepatch/xen_hello_world_func.c
index 03d6b84..6f53ab4 100644
--- a/xen/test/livepatch/xen_hello_world_func.c
+++ b/xen/test/livepatch/xen_hello_world_func.c
@@ -6,14 +6,17 @@
 #include 
 
 #include 
+#ifdef CONFIG_X86
 #include 
 #include 
 
 static unsigned long *non_canonical_addr = (unsigned long 
*)0xdeadULL;
+#endif
 
 /* Our replacement function for xen_extra_version. */
 const char *xen_hello_world(void)
 {
+#ifdef CONFIG_X86
 unsigned long tmp;
 int rc;
 
@@ -24,7 +27,10 @@ const char *xen_hello_world(void)
  */
 rc = __get_user(tmp, non_canonical_addr);
 BUG_ON(rc != -EFAULT);
-
+#endif
+#ifdef CONFIG_ARM_64
+asm(ALTERNATIVE("nop", "nop", ARM64_WORKAROUND_CLEAN_CACHE));
+#endif
 return "Hello World";
 }
 
-- 
2.5.5


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

[Xen-devel] [PATCH v4 15/16] livepatch: arm[32, 64], x86: NOP test-case

[Konrad Rzeszutek Wilk]

The test-case is quite simple - we NOP the 'xen_minor_version'.
The amount of NOPs depends on the architecture.

On x86 the function is 11 bytes long:

   55  push   %rbp  <- NOP
   48 89 e5mov%rsp,%rbp <- NOP
   b8 04 00 00 00  mov$0x4,%eax <- NOP
   5d  pop%rbp  <- NOP
   c3  retq

We can NOP everything but the last instruction (so 10 bytes).

On ARM64 its 8 bytes:

  52800100mov w0, #0x8 <- NOP
  d65f03c0ret

We can NOP the first instruction.

While on ARM32 there are 24 bytes:

  e52db004push{fp}
  e28db000add fp, sp, #0 <- NOP
  e3a8mov r0, #8 <- NOP
  e24bd000sub sp, fp, #0 <- NOP
  e49db004pop {fp}
  e12fff1ebx  lr

And we can NOP instruction 2,3, and 4.

Granted this code may be different per compiler!

Hence if anybody does run this test-case - they should
verify that the assumptions made here are correct.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: New submission.
---
 xen/test/livepatch/Makefile  | 15 +-
 xen/test/livepatch/xen_nop.c | 49 
 2 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 xen/test/livepatch/xen_nop.c

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 4d66a40..d7a4735 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -18,6 +18,7 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ 
print "0x"$$2}')
 LIVEPATCH := xen_hello_world.livepatch
 LIVEPATCH_BYE := xen_bye_world.livepatch
 LIVEPATCH_REPLACE := xen_replace_world.livepatch
+LIVEPATCH_NOP := xen_nop.livepatch
 
 default: livepatch
 
@@ -25,10 +26,12 @@ install: livepatch
$(INSTALL_DATA) $(LIVEPATCH) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH)
$(INSTALL_DATA) $(LIVEPATCH_BYE) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_BYE)
$(INSTALL_DATA) $(LIVEPATCH_REPLACE) 
$(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_REPLACE)
+   $(INSTALL_DATA) $(LIVEPATCH_NOP) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_NOP)
 uninstall:
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_BYE)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_REPLACE)
+   rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_NOP)
 
 .PHONY: clean
 clean::
@@ -41,9 +44,13 @@ clean::
 .PHONY: config.h
 config.h: OLD_CODE_SZ=$(call CODE_SZ,$(BASEDIR)/xen-syms,xen_extra_version)
 config.h: NEW_CODE_SZ=$(call CODE_SZ,$<,xen_hello_world)
+config.h: MINOR_VERSION_SZ=$(call 
CODE_SZ,$(BASEDIR)/xen-syms,xen_minor_version)
+config.h: MINOR_VERSION_ADDR=$(call 
CODE_ADDR,$(BASEDIR)/xen-syms,xen_minor_version)
 config.h: xen_hello_world_func.o
(set -e; \
 echo "#define NEW_CODE_SZ $(NEW_CODE_SZ)"; \
+echo "#define MINOR_VERSION_SZ $(MINOR_VERSION_SZ)"; \
+echo "#define MINOR_VERSION_ADDR $(MINOR_VERSION_ADDR)"; \
 echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
 
 xen_hello_world.o: config.h
@@ -92,5 +99,11 @@ xen_replace_world.o: config.h
 $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o note.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^
 
+xen_nop.o: config.h
+
+.PHONY: $(LIVEPATCH_NOP)
+$(LIVEPATCH_NOP): xen_nop.o note.o
+   $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^
+
 .PHONY: livepatch
-livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE)
+livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
diff --git a/xen/test/livepatch/xen_nop.c b/xen/test/livepatch/xen_nop.c
new file mode 100644
index 000..3827979
--- /dev/null
+++ b/xen/test/livepatch/xen_nop.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include "config.h"
+#include 
+
+#include 
+
+/*
+ * All of the .new_size and .old_addr are based on assumptions that the
+ * code for 'xen_minor_version' is compiled in specific way. Before
+ * running this test-case you MUST verify that the assumptions are
+ * correct (Hint: make debug and look in xen.s).
+ */
+struct livepatch_func __section(".livepatch.funcs") livepatch_nop = {
+.version = LIVEPATCH_PAYLOAD_VERSION,
+.old_size = MINOR_VERSION_SZ,
+
+#ifdef CONFIG_X86
+.old_addr = (void *)MINOR_VERSION_ADDR,
+/* Everything but the last instruction: "req". */
+.new_size = MINOR_VERSION_SZ-1,
+#endif
+
+#ifdef CONFIG_ARM_64
+.old_addr = (void *)MINOR_VERSION_ADDR,
+/* Replace the first one: "mov w0, #0x8".  */
+.new_size = 4,
+#endif
+
+#ifdef CONFIG_ARM_32
+/* Skip the first instruction: "push {fp}". */
+.old_addr = (void *)(MINOR_VERSION_ADDR + 4),
+/* And replace the next 

[Xen-devel] [PATCH v4 16/16] livepatch: In xen_nop test-case remove the .bss and .data sections

[Konrad Rzeszutek Wilk]

As they are not needed for the livepatch to work.

Also this allows us to properly test:
"livepatch: Disallow applying after an revert" as the livepatch
will now only have the minimalistic sections:

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .note.gnu.build-i NOTE   0040
   0024     A   0 0 4
  [ 2] .text PROGBITS 0024  0064
       AX   0 0 4
  [ 3] .livepatch.depend PROGBITS   0064
   0024     A   0 0 1
  [ 4] .livepatch.funcs  PROGBITS   00a0
   0040    WA   0 0 32
  [ 5] .note.GNU-stack   PROGBITS   00e0
        X   0 0 1
  [ 6] .comment  PROGBITS   00e0
   002d  0001  MS   0 0 1
  [ 7] .shstrtab STRTAB     010d
   0071     0 0 1
  [ 8] .symtab   SYMTAB     0400
   00c0  0018   9 7 8
  [ 9] .strtab   STRTAB     04c0
   000f     0 0 1

In which only .livepatch.funcs is write-able.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v4: New submission
---
 xen/test/livepatch/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index d7a4735..41ad59d 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -104,6 +104,8 @@ xen_nop.o: config.h
 .PHONY: $(LIVEPATCH_NOP)
 $(LIVEPATCH_NOP): xen_nop.o note.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^
+   $(OBJCOPY) --remove-section=.bss --remove-section=.data $@
+   $(OBJCOPY) --strip-unneeded $@
 
 .PHONY: livepatch
 livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
-- 
2.5.5


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

[Xen-devel] [PATCH v4 05/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr

[Konrad Rzeszutek Wilk]

If the distance is too great we are in trouble - as our relocation
distance can surely be clipped, or still have a valid width - but
cause an overflow of distance.

On various architectures the maximum displacement for a unconditional
branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while x86
for 32-bit relocations is +/- 2G.

Note: On x86 we could use the 64-bit jmpq instruction which
would provide much bigger displacement to do a jump, but we would
still have issues with the new function not being able to reach
any of the old functions (as all the relocations would assume 32-bit
displacement). And "furthermore would require an register or
memory location to load/store the address to." (From Jan).

On ARM the conditional branch supports even a smaller displacement
but fortunatly we are not using that.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v3: New submission.
v4: s/arch_livepatch_verify_distance/livepatch_verify_distance/
s/LIVEPATCH_ARCH_RANGE/ARCH_LIVEPATCH_RANGE/
v5: Updated commit description with Jan's comment
Ditch the casting of long on calculating offset.
---
 docs/misc/livepatch.markdown| 14 +-
 xen/arch/arm/arm64/livepatch.c  |  1 +
 xen/common/livepatch.c  |  4 
 xen/include/asm-arm/livepatch.h | 11 +++
 xen/include/asm-x86/livepatch.h |  3 +++
 xen/include/xen/livepatch.h | 19 +--
 6 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 9e72897..5baaa0a 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -1100,7 +1100,7 @@ and no .data or .bss sections.
 The hypervisor should verify that the in-place patching would fit within
 the code or data.
 
-### Trampoline (e9 opcode)
+### Trampoline (e9 opcode), x86
 
 The e9 opcode used for jmpq uses a 32-bit signed displacement. That means
 we are limited to up to 2GB of virtual address to place the new code
@@ -1134,3 +1134,15 @@ that in the hypervisor is advised.
 The tool for generating payloads currently does perform a compile-time
 check to ensure that the function to be replaced is large enough.
 
+The hypervisor also checks the displacement during loading of the payload.
+
+ Trampoline (ea opcode), ARM
+
+The 0xea00 instruction (with proper offset) is used for an unconditional
+branch to the new code. This means we are limited on ARM32 to +/- 32MB
+displacement and on ARM64 to +/- 128MB displacement.
+
+The new code is placed in the 8M - 10M virtual address space while the
+Xen code is in 2M - 4M. That gives us enough space.
+
+The hypervisor also checks the displacement during loading of the payload.
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 49eb69b..7d593b2 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -40,6 +40,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
 else
 insn = aarch64_insn_gen_nop();
 
+/* Verified in livepatch_verify_distance. */
 ASSERT(insn != AARCH64_BREAK_FAULT);
 
 new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index a4ce8c7..38260b9 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -540,6 +540,10 @@ static int prepare_payload(struct payload *payload,
 rc = resolve_old_address(f, elf);
 if ( rc )
 return rc;
+
+rc = livepatch_verify_distance(f);
+if ( rc )
+return rc;
 }
 
 sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.load");
diff --git a/xen/include/asm-arm/livepatch.h b/xen/include/asm-arm/livepatch.h
index 929c7d9..482d74f 100644
--- a/xen/include/asm-arm/livepatch.h
+++ b/xen/include/asm-arm/livepatch.h
@@ -6,6 +6,8 @@
 #ifndef __XEN_ARM_LIVEPATCH_H__
 #define __XEN_ARM_LIVEPATCH_H__
 
+#include  /* For SZ_* macros. */
+
 /* On ARM32,64 instructions are always 4 bytes long. */
 #define ARCH_PATCH_INSN_SIZE 4
 
@@ -15,6 +17,15 @@
  */
 extern void *vmap_of_xen_text;
 
+/* These ranges are only for unconditional branches. */
+#ifdef CONFIG_ARM_32
+/* ARM32: A4.3 IN ARM DDI 0406C.j -  we are using only ARM instructions in 
Xen.*/
+#define ARCH_LIVEPATCH_RANGE SZ_32M
+#else
+/* ARM64: C1.3.2 in ARM DDI 0487A.j */
+#define ARCH_LIVEPATCH_RANGE SZ_128M
+#endif
+
 #endif /* __XEN_ARM_LIVEPATCH_H__ */
 
 /*
diff --git a/xen/include/asm-x86/livepatch.h b/xen/include/asm-x86/livepatch.h
index 5e04aa1..7dfc2e7 100644
--- a/xen/include/asm-x86/livepatch.h
+++ b/xen/include/asm-x86/livepatch.h
@@ -6,7 +6,10 @@
 #ifndef __XEN_X86_LIVEPATCH_H__
 #define __XEN_X86_LIVEPATCH_H__
 
+#include  /* For SZ_* macros. */
+
 #define ARCH_PATCH_INSN_SIZE 5
+#define ARCH_LIVEPATCH_RANGE 

[Xen-devel] [PATCH v4 08/16] livepatch: Move test-cases to their own sub-directory in test.

[Konrad Rzeszutek Wilk]

So they can be shared with ARM64 (but not yet, so they
are only built on x86).

No functional change.

We also need to tweak the MAINTAINERS and .gitignore file.

Also we need to update SUBDIRS to include the new 'test'
directory so 'cscope' can show the example livepatches.

Acked-by: Jan Beulich  [for directory]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v1: First submission
v2: Move to test/livepatch per Jan's recommendation
v3: Sort MAINTAINERS for livepatch.
Add Jan's Acked-by.
Added on the SUBDIRS the 'test' directory
Change title of patch (common-> own sub-directory)
---
 .gitignore  |  8 +--
 MAINTAINERS |  1 +
 xen/Makefile|  5 +-
 xen/arch/arm/Makefile   |  3 -
 xen/arch/x86/Makefile   |  5 --
 xen/arch/x86/test/Makefile  | 85 -
 xen/arch/x86/test/xen_bye_world.c   | 34 
 xen/arch/x86/test/xen_bye_world_func.c  | 22 
 xen/arch/x86/test/xen_hello_world.c | 67 ---
 xen/arch/x86/test/xen_hello_world_func.c| 39 -
 xen/arch/x86/test/xen_replace_world.c   | 33 ---
 xen/arch/x86/test/xen_replace_world_func.c  | 22 
 xen/test/Makefile   |  9 +++
 xen/test/livepatch/Makefile | 85 +
 xen/test/livepatch/xen_bye_world.c  | 34 
 xen/test/livepatch/xen_bye_world_func.c | 22 
 xen/test/livepatch/xen_hello_world.c| 67 +++
 xen/test/livepatch/xen_hello_world_func.c   | 39 +
 xen/test/livepatch/xen_replace_world.c  | 33 +++
 xen/test/livepatch/xen_replace_world_func.c | 22 
 20 files changed, 319 insertions(+), 316 deletions(-)
 delete mode 100644 xen/arch/x86/test/Makefile
 delete mode 100644 xen/arch/x86/test/xen_bye_world.c
 delete mode 100644 xen/arch/x86/test/xen_bye_world_func.c
 delete mode 100644 xen/arch/x86/test/xen_hello_world.c
 delete mode 100644 xen/arch/x86/test/xen_hello_world_func.c
 delete mode 100644 xen/arch/x86/test/xen_replace_world.c
 delete mode 100644 xen/arch/x86/test/xen_replace_world_func.c
 create mode 100644 xen/test/Makefile
 create mode 100644 xen/test/livepatch/Makefile
 create mode 100644 xen/test/livepatch/xen_bye_world.c
 create mode 100644 xen/test/livepatch/xen_bye_world_func.c
 create mode 100644 xen/test/livepatch/xen_hello_world.c
 create mode 100644 xen/test/livepatch/xen_hello_world_func.c
 create mode 100644 xen/test/livepatch/xen_replace_world.c
 create mode 100644 xen/test/livepatch/xen_replace_world_func.c

diff --git a/.gitignore b/.gitignore
index cc64fc9..eeabe0b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -254,10 +254,6 @@ xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
 xen/arch/x86/efi/mkreloc
-xen/arch/x86/test/config.h
-xen/arch/x86/test/xen_hello_world.livepatch
-xen/arch/x86/test/xen_bye_world.livepatch
-xen/arch/x86/test/xen_replace_world.livepatch
 xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
@@ -274,6 +270,10 @@ xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
+xen/test/livepatch/config.h
+xen/test/livepatch/xen_bye_world.livepatch
+xen/test/livepatch/xen_hello_world.livepatch
+xen/test/livepatch/xen_replace_world.livepatch
 xen/tools/kconfig/.tmp_gtkcheck
 xen/tools/kconfig/.tmp_qtcheck
 xen/tools/symbols
diff --git a/MAINTAINERS b/MAINTAINERS
index ae0b6bc..edc8603 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -272,6 +272,7 @@ F:  xen/arch/*/livepatch*
 F:  xen/arch/*/*/livepatch*
 F:  xen/common/livepatch*
 F:  xen/include/xen/livepatch*
+F:  xen/test/livepatch/*
 
 MACHINE CHECK (MCA) & RAS
 M: Christoph Egger 
diff --git a/xen/Makefile b/xen/Makefile
index 012509b..e989a20 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -80,7 +80,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 
 .PHONY: _tests
 _tests:
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) tests
+   $(MAKE) -f $(BASEDIR)/Rules.mk -C test tests
 
 .PHONY: _uninstall
 _uninstall: D=$(DESTDIR)
@@ -114,6 +114,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+   $(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) clean
find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 

[Xen-devel] [PATCH v4 01/16] arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]

[Konrad Rzeszutek Wilk]

x86 implements all of them by default - and we just
add two extra HAS_ variables to be declared in autoconf.h.

ARM 64 only has alternative while ARM 32 has none of them.

And while at it change the livepatch common code that
would benefit from this.

Suggested-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Doug Goldstein 

v2: First submission
v3: Move the config options to common code
Don't include  in the file.
Don't even include  in the file as xen/Rules.mk automatically
includes the config.h for every GCC invocation.
v4: Depend on "arm64: s/ALTERNATIVE/HAS_ALTERNATIVE/"
Remove the extra newline in arch/x86/Kconfig
---
 xen/arch/arm/Kconfig   | 3 ---
 xen/arch/x86/Kconfig   | 2 ++
 xen/common/Kconfig | 6 ++
 xen/common/livepatch.c | 4 +++-
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index b188293..2e023d1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -42,9 +42,6 @@ config ACPI
  Advanced Configuration and Power Interface (ACPI) support for Xen is
  an alternative to device tree on ARM64.
 
-config HAS_ALTERNATIVE
-   bool
-
 config HAS_GICV3
bool
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 265fd79..96ca2bf 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -7,8 +7,10 @@ config X86
select ACPI_LEGACY_TABLES_LOOKUP
select COMPAT
select CORE_PARKING
+   select HAS_ALTERNATIVE
select HAS_CPUFREQ
select HAS_EHCI
+   select HAS_EX_TABLE
select HAS_GDBSX
select HAS_IOPORTS
select HAS_KEXEC
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 4331874..81e0017 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -11,9 +11,15 @@ config COMPAT
 config CORE_PARKING
bool
 
+config HAS_ALTERNATIVE
+   bool
+
 config HAS_DEVICE_TREE
bool
 
+config HAS_EX_TABLE
+   bool
+
 config HAS_MEM_ACCESS
bool
 
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 3729409..c9ceeb0 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -638,7 +638,7 @@ static int prepare_payload(struct payload *payload,
   sizeof(*region->frame[i].bugs);
 }
 
-#ifndef CONFIG_ARM
+#ifdef CONFIG_HAS_ALTERNATIVE
 sec = livepatch_elf_sec_by_name(elf, ".altinstructions");
 if ( sec )
 {
@@ -669,7 +669,9 @@ static int prepare_payload(struct payload *payload,
 }
 apply_alternatives(start, end);
 }
+#endif
 
+#ifdef CONFIG_HAS_EX_TABLE
 sec = livepatch_elf_sec_by_name(elf, ".ex_table");
 if ( sec )
 {
-- 
2.5.5


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

[Xen-devel] [PATCH v4 14/16] livepatch, arm[32|64]: Share arch_livepatch_revert_jmp

[Konrad Rzeszutek Wilk]

It is exactly the same in both platforms.

No functional change.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v3: New submission.
v4: s/arch_livepatch_insn_len/livepatch_insn_len/
s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
---
 xen/arch/arm/arm32/livepatch.c | 19 +--
 xen/arch/arm/arm64/livepatch.c | 19 +--
 xen/arch/arm/livepatch.c   | 19 +++
 3 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 6ad0ce5..606a00c 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -66,24 +66,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(func->old_addr, sizeof(*new_ptr) * 
len);
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int i, len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-len = livepatch_insn_len(func) / sizeof(uint32_t);
-for ( i = 0; i < len; i++ )
-{
-uint32_t insn;
-
-memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
-/* PATCH! */
-*(new_ptr + i) = insn;
-}
-
-clean_and_invalidate_dcache_va_range(func->old_addr, sizeof(*new_ptr) * 
len);
-}
+/* arch_livepatch_revert_jmp shared with ARM 64. */
 
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index d53fe59..89d061e 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -53,24 +53,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(new_ptr, sizeof(*new_ptr) * len);
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int i, len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-len = livepatch_insn_len(func) / sizeof(uint32_t);
-for ( i = 0; i < len; i++ )
-{
-uint32_t insn;
-
-memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
-/* PATCH! */
-*(new_ptr + i) = insn;
-}
-
-clean_and_invalidate_dcache_va_range(func->old_addr, sizeof(*new_ptr) * 
len);
-}
+/* arch_livepatch_revert_jmp shared with ARM32. */
 
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 9c198e9..c77030e 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -69,6 +69,25 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }
 
+void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int i, len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = livepatch_insn_len(func) / sizeof(uint32_t);
+for ( i = 0; i < len; i++ )
+{
+uint32_t insn;
+
+memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
+/* PATCH! */
+*(new_ptr + i) = insn;
+}
+
+clean_and_invalidate_dcache_va_range(new_ptr, sizeof(*new_ptr) * len);
+}
+
 void arch_livepatch_post_action(void)
 {
 /* arch_livepatch_revive has nuked the instruction cache. */
-- 
2.5.5


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

[Xen-devel] [PATCH v4 10/16] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH

[Konrad Rzeszutek Wilk]

To use as a common way of testing alternative patching for
livepatches. Both architectures have this FEATURE and the
test-cases can piggyback on that.

Suggested-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: New submission
v4: Move the LIVEPATCH_FEATURE to asm-x86/livepatch.h
---
 xen/arch/arm/livepatch.c  | 3 +++
 xen/include/asm-arm/alternative.h | 2 ++
 xen/include/asm-arm/cpufeature.h  | 5 +
 xen/include/asm-x86/livepatch.h   | 1 +
 xen/test/livepatch/xen_hello_world_func.c | 8 +---
 5 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 13d6c10..b771cb7 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -175,6 +176,8 @@ void __init arch_livepatch_init(void)
 end = (void *)LIVEPATCH_VMAP_END;
 
 vm_init_type(VMAP_XEN, start, end);
+
+cpus_set_cap(LIVEPATCH_FEATURE);
 }
 
 /*
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 6851217..cca5f17 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -165,6 +165,8 @@ static inline int apply_alternatives(void *start, size_t 
lenght)
 return 0;
 }
 
+#define ALTERNATIVE(oldinstr, newinstr, ...) ""
+
 #endif
 
 #endif /* __ASM_ALTERNATIVE_H */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 66e930f..19e768b 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -40,7 +40,12 @@
 #define ARM32_WORKAROUND_766422 2
 #define ARM64_WORKAROUND_834220 3
 
+#ifdef CONFIG_LIVEPATCH
+#define LIVEPATCH_FEATURE   4
+#define ARM_NCAPS   5
+#else
 #define ARM_NCAPS   4
+#endif
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-x86/livepatch.h b/xen/include/asm-x86/livepatch.h
index 7dfc2e7..00aefd2 100644
--- a/xen/include/asm-x86/livepatch.h
+++ b/xen/include/asm-x86/livepatch.h
@@ -10,6 +10,7 @@
 
 #define ARCH_PATCH_INSN_SIZE 5
 #define ARCH_LIVEPATCH_RANGE SZ_2G
+#define LIVEPATCH_FEATUREX86_FEATURE_ALWAYS
 
 #endif /* __XEN_X86_LIVEPATCH_H__ */
 
diff --git a/xen/test/livepatch/xen_hello_world_func.c 
b/xen/test/livepatch/xen_hello_world_func.c
index 6f53ab4..765a871 100644
--- a/xen/test/livepatch/xen_hello_world_func.c
+++ b/xen/test/livepatch/xen_hello_world_func.c
@@ -20,7 +20,6 @@ const char *xen_hello_world(void)
 unsigned long tmp;
 int rc;
 
-alternative(ASM_NOP8, ASM_NOP1, X86_FEATURE_LM);
 /*
  * Any BUG, or WARN_ON will contain symbol and payload name. Furthermore
  * exceptions will be caught and processed properly.
@@ -28,8 +27,11 @@ const char *xen_hello_world(void)
 rc = __get_user(tmp, non_canonical_addr);
 BUG_ON(rc != -EFAULT);
 #endif
-#ifdef CONFIG_ARM_64
-asm(ALTERNATIVE("nop", "nop", ARM64_WORKAROUND_CLEAN_CACHE));
+#ifdef CONFIG_ARM
+asm(ALTERNATIVE("nop", "nop", LIVEPATCH_FEATURE));
+#endif
+#ifdef CONFIG_X86
+asm(ALTERNATIVE(ASM_NOP8, ASM_NOP1, LIVEPATCH_FEATURE));
 #endif
 return "Hello World";
 }
-- 
2.5.5


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

[Xen-devel] [PATCH v4] Livepatch for ARM 64 and 32.

[Konrad Rzeszutek Wilk]

Hey!

Since v3: [https://lists.xen.org/archives/html/xen-devel/2016-09/msg01127.html]
 - Addressed Jan's comment (most are renaming)
 - Addressed Julien's and Jan's idea of HAS_ALTERNATIVE
 - Addressed Julien's review comments of "arm: poison initmem when it is freed."

v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
 - Addressed the two outstanding concerns: CPU bit feature to test alternative
   test-case, and errata #843419 on some Cortex-A53 
 - Dealt with comments from Jan, Julien and Andrew.
 - Fixed (offlist) with Julien ARM32 not branching properly.
 - Committed some of the patches that had been reviewed/Acked.

v1 (and RFC): 
[https://lists.xen.org/archives/html/xen-devel/2016-08/msg01835.html]
 - Acted on most all comments.
 - Added ARM 32 support.

The patches are based on: [PATCH v6] Livepatch fixes and features for v4.8.
https://lists.xen.org/archives/html/xen-devel/2016-09/msg01719.html

And the git tree is:
 git://xenbits.xen.org/people/konradwilk/xen.git livepatch.v4.8.v6

These patches enable livepatching to work on ARM64 and ARM32. They have
been tested on multi-CPU environments (Foundation Model, 4CPU for ARM64;
and ARM CubieTruck for ARM32).

In terms of review or such, two patches have been reviewed:

 #2 livepatch: Reject payloads with .alternative or
 #6 livepatch: ARM 32|64: Ignore mapping symbols: $[d,a,x]

The rest still needs review.  Thanks!

Konrad Rzeszutek Wilk (16):
  arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]
  livepatch: Reject payloads with .alternative or .ex_table if support is 
not built-in.
  arm: poison initmem when it is freed.
  livepatch: Initial ARM64 support.
  livepatch: ARM/x86: Check displacement of old_addr and new_addr
  livepatch: ARM 32|64: Ignore mapping symbols: $[d,a,x]
  livepatch/arm/x86: Check payload for for unwelcomed symbols.
  livepatch: Move test-cases to their own sub-directory in test.
  livepatch: tests: Make them compile under ARM64
  livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH
  xen/arm32: Add an helper to invalidate all instruction caches
  bug/x86/arm: Align bug_frames sections.
  livepatch: Initial ARM32 support.
  livepatch, arm[32|64]: Share arch_livepatch_revert_jmp
  livepatch: arm[32,64],x86: NOP test-case
  livepatch: In xen_nop test-case remove the .bss and .data sections

 .gitignore  |   8 +-
 MAINTAINERS |   2 +
 docs/misc/livepatch.markdown|  14 +-
 xen/Makefile|   5 +-
 xen/arch/arm/Kconfig|   3 -
 xen/arch/arm/Makefile   |  16 +-
 xen/arch/arm/arm32/Makefile |   1 +
 xen/arch/arm/arm32/livepatch.c  | 290 +
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/livepatch.c  | 468 
 xen/arch/arm/domain.c   |   6 +
 xen/arch/arm/livepatch.c| 159 --
 xen/arch/arm/mm.c   |  17 +-
 xen/arch/arm/traps.c|   6 +
 xen/arch/x86/Kconfig|   2 +
 xen/arch/x86/Makefile   |   5 -
 xen/arch/x86/livepatch.c|  14 +
 xen/arch/x86/test/Makefile  |  85 -
 xen/arch/x86/test/xen_bye_world.c   |  34 --
 xen/arch/x86/test/xen_bye_world_func.c  |  22 --
 xen/arch/x86/test/xen_hello_world.c |  67 
 xen/arch/x86/test/xen_hello_world_func.c|  39 ---
 xen/arch/x86/test/xen_replace_world.c   |  33 --
 xen/arch/x86/test/xen_replace_world_func.c  |  22 --
 xen/arch/x86/xen.lds.S  |   1 -
 xen/common/Kconfig  |   8 +-
 xen/common/livepatch.c  |  20 +-
 xen/common/livepatch_elf.c  |   7 +
 xen/include/asm-arm/alternative.h   |   2 +
 xen/include/asm-arm/arm32/page.h|  13 +
 xen/include/asm-arm/bug.h   |   1 +
 xen/include/asm-arm/config.h|   5 +
 xen/include/asm-arm/cpufeature.h|   5 +
 xen/include/asm-arm/livepatch.h |  39 +++
 xen/include/asm-x86/bug.h   |   1 +
 xen/include/asm-x86/livepatch.h |   4 +
 xen/include/xen/elfstructs.h|  79 -
 xen/include/xen/livepatch.h |  23 +-
 xen/include/xen/types.h |   9 +
 xen/test/Makefile   |   7 +
 xen/test/livepatch/Makefile | 111 +++
 xen/test/livepatch/xen_bye_world.c  |  34 ++
 xen/test/livepatch/xen_bye_world_func.c |  22 ++
 xen/test/livepatch/xen_hello_world.c|  67 
 xen/test/livepatch/xen_hello_world_func.c   |  47 +++
 xen/test/livepatch/xen_nop.c|  49 +++
 xen/test/livepatch/xen_replace_world.c  |  33 ++
 

[Xen-devel] [PATCH v4 13/16] livepatch: Initial ARM32 support.

[Konrad Rzeszutek Wilk]

The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the neccessary livepatch infrastructure pieces in.

This patch adds three major pieces:

 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
instruction. Which required parsing BL/BLX, B/BL,
MOVT, and MOVW instructions.

The code was written from scratch using the ARM ELF manual
(and the ARM Architecture Reference Manual)

 2) Inserting an trampoline. We use the B (branch to address)
which uses an offset that is based on the PC value: PC + imm32.
Because we insert the branch at the start of the old function
we have to account for the instruction already being fetched
and subtract -8 from the delta (new_addr - old_addr). See
ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)

 3) Allows the test-cases to be built under ARM 32.
The "livepatch: tests: Make them compile under ARM64"
put in the right infrastructure for it and we piggyback on it.

Acked-by: Jan Beulich  [for non-ARM parts]
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v2: First submission.
v3: Use LIVEPATCH_ARCH_RANGE instead of NEGATIVE_32MB macro
   -Use PATCH_INSN_SIZE instead of the value 4.
   -Ditch the old_ptr local variable.
   -Use 8 for evaluating the branch instead of 4. Based on ARM docs.
   -NOP patch up to sizeof(opaque) % PATCH_INSN_SIZE (so 7 instructions).
   -Don't mask 0x00F_E_ after shifting, instead mask by 0x00F_F_.
The reason is that offset is constructed by shifting by two the insn
(except the first two bytes) by left which meant we would have cleared
offset[2]! - and jumped to a location that was -4 bytes off.
   -Update commit description to have -8 instead of -4 delta and also
include reference to spec.
v4: Added Jan's Ack.
   s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
   s/arch_livepatch_insn_len/livepatch_insn_len/
   s/LIVEPATCH_ARCH_RANGE/ARCH_LIVEPATCH_RANGE/
---
 xen/arch/arm/arm32/livepatch.c | 273 -
 xen/arch/arm/arm64/livepatch.c |   7 ++
 xen/arch/arm/livepatch.c   |   7 --
 xen/common/Kconfig |   2 +-
 xen/include/xen/elfstructs.h   |  24 +++-
 xen/test/Makefile  |   2 -
 xen/test/livepatch/Makefile|   3 +
 7 files changed, 305 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index c33b68d..6ad0ce5 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -3,28 +3,297 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 void arch_livepatch_apply_jmp(struct livepatch_func *func)
 {
+uint32_t insn;
+uint32_t *new_ptr;
+unsigned int i, len;
+
+BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != sizeof(insn));
+
+ASSERT(vmap_of_xen_text);
+
+len = livepatch_insn_len(func);
+if ( !len )
+return;
+
+/* Save old ones. */
+memcpy(func->opaque, func->old_addr, len);
+
+if ( func->new_addr )
+{
+s32 delta;
+
+/*
+ * PC is current address (old_addr) + 8 bytes. The semantics for a
+ * unconditional branch is to jump to PC + imm32 (offset).
+ *
+ * ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)
+ *
+ */
+delta = (s32)func->new_addr - (s32)(func->old_addr + 8);
+
+/* The arch_livepatch_symbol_ok should have caught it. */
+ASSERT(delta >= -(s32)ARCH_LIVEPATCH_RANGE ||
+   delta < (s32)ARCH_LIVEPATCH_RANGE);
+
+/* CPU shifts by two (left) when decoding, so we shift right by two. */
+delta = delta >> 2;
+/* Lets not modify the cond. */
+delta &= 0x00FF;
+
+insn = 0xea00 | delta;
+}
+else
+insn = 0xe1a0; /* mov r0, r0 */
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = len / sizeof(uint32_t);
+
+/* PATCH! */
+for ( i = 0; i < len; i++ )
+*(new_ptr + i) = insn;
+
+clean_and_invalidate_dcache_va_range(func->old_addr, sizeof(*new_ptr) * 
len);
 }
 
 void arch_livepatch_revert_jmp(const struct livepatch_func *func)
 {
+uint32_t *new_ptr;
+unsigned int i, len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = livepatch_insn_len(func) / sizeof(uint32_t);
+for ( i = 0; i < len; i++ )
+{
+uint32_t insn;
+
+memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
+/* PATCH! */
+*(new_ptr + i) = insn;
+}
+
+clean_and_invalidate_dcache_va_range(func->old_addr, sizeof(*new_ptr) * 
len);
 }
 
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
-

[Xen-devel] [PATCH v4 02/16] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in.

[Konrad Rzeszutek Wilk]

If the payload had the sections mentioned but the hypervisor
did not support some of them (say on ARM the .ex_table) - instead
of ignoring them - it should forbid loading of such payload.

Reviewed-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: New submission.
v4: Added Julien's Reviewed-by tag.
---
 xen/common/livepatch.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index c9ceeb0..a4ce8c7 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -638,10 +638,10 @@ static int prepare_payload(struct payload *payload,
   sizeof(*region->frame[i].bugs);
 }
 
-#ifdef CONFIG_HAS_ALTERNATIVE
 sec = livepatch_elf_sec_by_name(elf, ".altinstructions");
 if ( sec )
 {
+#ifdef CONFIG_HAS_ALTERNATIVE
 struct alt_instr *a, *start, *end;
 
 if ( sec->sec->sh_size % sizeof(*a) )
@@ -668,13 +668,17 @@ static int prepare_payload(struct payload *payload,
 }
 }
 apply_alternatives(start, end);
-}
+#else
+dprintk(XENLOG_ERR, LIVEPATCH "%s: We don't support alternative 
patching!\n",
+elf->name);
+return -EOPNOTSUPP;
 #endif
+}
 
-#ifdef CONFIG_HAS_EX_TABLE
 sec = livepatch_elf_sec_by_name(elf, ".ex_table");
 if ( sec )
 {
+#ifdef CONFIG_HAS_EX_TABLE
 struct exception_table_entry *s, *e;
 
 if ( !sec->sec->sh_size ||
@@ -693,8 +697,12 @@ static int prepare_payload(struct payload *payload,
 
 region->ex = s;
 region->ex_end = e;
-}
+#else
+dprintk(XENLOG_ERR, LIVEPATCH "%s: We don't support .ex_table!\n",
+elf->name);
+return -EOPNOTSUPP;
 #endif
+}
 
 return 0;
 }
-- 
2.5.5


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

[Xen-devel] [PATCH v4 03/16] arm: poison initmem when it is freed.

[Konrad Rzeszutek Wilk]

The current byte sequence is '0xcc' which makes sense on x86,
but on ARM it is:

stclgt  12, cr12, [ip], {204}   ; 0xcc

Picking something more ARM applicable such as:

efefefefsvc 0x00efefef

Creates a nice crash if one executes that code:
(XEN) CPU1: Unexpected Trap: Supervisor Call

But unfortunatly that may not be a good choice either as in the future
we may want to implement support for it.

Julien suggested that we use a 4-byte insn instruction instead
of trying to work with one byte.

As such on ARM 32 we use the udf instruction (see A8.8.247
in ARM DDI 0406C.c) and on ARM 64 use the AARCH64_BREAK_FAULT
instruction (aka brk instruction).

We don't have to worry about Thumb code so this instruction
is a safe to execute.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v3: New submission
v4: Instead of using 0xef, use specific insn for architectures.
---
 xen/arch/arm/mm.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 07e2037..438bed7 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -994,8 +994,23 @@ void free_init_memory(void)
 {
 paddr_t pa = virt_to_maddr(__init_begin);
 unsigned long len = __init_end - __init_begin;
+uint32_t insn;
+unsigned int i, nr = len / sizeof(insn);
+
 set_pte_flags_on_range(__init_begin, len, mg_rw);
-memset(__init_begin, 0xcc, len);
+#ifdef CONFIG_ARM_32
+/* udf instruction i.e (see A8.8.247 in ARM DDI 0406C.c) */
+insn = 0xe7f000f0;
+#else
+insn = AARCH64_BREAK_FAULT;
+#endif
+for ( i = 0; i < nr; i++ )
+*(__init_begin + i) = insn;
+
+nr = len % sizeof(insn);
+if ( nr )
+memset(__init_begin + len - nr, 0xcc, nr);
+
 set_pte_flags_on_range(__init_begin, len, mg_clear);
 init_domheap_pages(pa, pa + len);
 printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
-- 
2.5.5


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

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

On 09/16/2016 11:22 AM, Lars Kurth wrote:
>
> On 16/09/2016 13:41, "Boris Ostrovsky"  wrote:
>
>> On 09/16/2016 02:45 AM, Jan Beulich wrote:
> And then there's the question of whether excluding things from the
> build, but having them present in the sources actually helps.
 The main reason for this whole relicensing debacle is to prevent
 non-GPL
 binaries from linking against GPL objects, and this patch allows us to
 do that. Yes, there will be be two non-LGPL files (dsdt.asl amd
 mk_dsdt.c, which I will revert back to GPL) in an otherwise LGPL
 directory but that's an in-convenience and not a license violation.
>>> Well, if linking is all this is about, then it's fine of course. I'm
>>> just
>>> not a license expert, so we'd need this acked by someone who is
>>> more familiar with the differences and implications.
>> I think Ian and Lars (added both here) would be the most experienced in
>> this matter.
> It is all about linking. The terms of the GPL "spread" to derivative works
> through both “dynamic” and “static” linking of binaries only. So you can
> have one directory, which contains GPL and non-GPL licensed files, and not
> suffer GPL-contagion as long as you can guarantee that the binaries
> produced are of a specific license and you only link compatible binaries
> with each other. Of course that is brittle and error prone.
>
>> So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb
>> (which is the patch from Lenovo) and it only does 2 things (assuming I
>> parsed ASL correctly):
>> * Adds _PIC method
> As far as I can tell, only lines 30-43 of the original code remains.
> Is this correct?

_S5 object still exists but it's content has been modified by subsequent
non-Lenovo changes so I think we can not worry about lines 20-30.

But lines 30-43 are still present in current code.

>
>> * Controls and describes legacy PCI interrupt routing. This
>> functionality has actually been moved into mk_dsdt.c and so this ASL
>> code is now generated.
>
> Has it been 
> a) moved, 
> b) re-implemented in a different language using the ASL code as template,

(b) is probably the best description.


> or 
> c) implemented in C based on the ACPI spec?
>
> Given that mk_dsdt.c is C and the original contribution is entirely ASL
> (note that acpi_dsdt.c was generated from the ASL), a) does not appear to
> be the case.
>
> b) can probably not be excluded, in which case it may be safer to keep
> mk_dsdt.c as GPL. But it would be a grey area.
>
> If we knew for sure or it is plausible enough that it was c), then
> mk_dsdt.c does not need to be GPL. 

Both hand-crafted and mk_dsdt-generated ASL file are *conforming* to
ACPI spec but the values (i.e. the topology that the ASL file describes)
are specifically chosen so I don't think (c) is the right answer.

Having said that it is entirely plausible that the author of the patch
ran iasl on his machine and took the output from it to produce the
patch, possibly with minor tweaks. But we, of course, don't know for sure.

> And then the remaining Lenovo code in
> dsdt.asl may be simple enough to not be copyrightable.
>
> Whatever the answer, I would like to get Ian's opinion.
> And it is still preferable though to have the entire component in LGPL and
> to get a Lenovo ACK.
>
>> I could move these two files into tools/libacpi/gpl subdirectory to
>> emphasize their special licensing.
> That would definitely make things easier and avoid any future mistakes
> which lead to licensing issues.
>
> Another general comment is that the component should have a COPYING file
> and maybe a README.source file in the new component (that will make future
> forensics easier). 

I'll add a COPYING file (we already have a README).


-boris



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

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

[Edgar E. Iglesias]

On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote:
> Hi Edgar,
> 
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Add support for describing normal non-cacheable memory.
> >
> >Signed-off-by: Edgar E. Iglesias 
> >---
> > xen/arch/arm/p2m.c | 18 ++
> > xen/include/asm-arm/p2m.h  |  1 +
> > xen/include/asm-arm/page.h |  1 +
> > 3 files changed, 20 insertions(+)
> >
> >diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> >index b648a9d..bfef77b 100644
> >--- a/xen/arch/arm/p2m.c
> >+++ b/xen/arch/arm/p2m.c
> >@@ -282,6 +282,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
> >p2m_access_t a)
> > /* First apply type permissions */
> > switch ( t )
> > {
> >+case p2m_mem_nc:
> > case p2m_ram_rw:
> > e->p2m.xn = 0;
> > e->p2m.write = 1;
> >@@ -376,6 +377,23 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
> >p2m_access_t a)
> > e.p2m.sh = LPAE_SH_OUTER;
> > break;
> >
> >+/*
> >+ * ARM ARM: Overlaying the shareability attribute (DDI
> >+ * 0406C.b B3-1376 to 1377)
> >+ *
> >+ * A memory region with a resultant memory type attribute of Normal,
> >+ * and a resultant cacheability attribute of Inner Non-cacheable,
> >+ * Outer Non-cacheable, must have a resultant shareability attribute
> >+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
> >+ *
> >+ * On ARMv8 sharability is ignored and explicitly treated as Outer
> 
> I know you copied it from mfn_to_xen_entry, but can we fixed the copy with:
> 
> s/sharability/shareability/
> 
> >+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.
> 
> s/_/-/
> 
> Also I would like to see a spec reference for the ARMv8. I think it is the
> note in D4-1788 ARM DDI 0487A.j.
> 
> >+ */
> >+case p2m_mem_nc:
> >+e.p2m.mattr = MATTR_MEM_NC;
> >+e.p2m.sh = LPAE_SH_OUTER;
> >+break;
> >+
> > default:
> > e.p2m.mattr = MATTR_MEM;
> > e.p2m.sh = LPAE_SH_INNER;
> >diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> >index 53c4d78..b012d50 100644
> >--- a/xen/include/asm-arm/p2m.h
> >+++ b/xen/include/asm-arm/p2m.h
> >@@ -93,6 +93,7 @@ typedef enum {
> > p2m_ram_ro, /* Read-only; writes are silently dropped */
> > p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
> > non-cacheable */
> > p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area 
> > cacheable */
> >+p2m_mem_nc, /* Read/write mapping of Non-cacheable Memory */
> 
> I find the name a bit confusing. Technically p2m_mem_nc is p2m_mmio_direct_c
> version but non-cacheable.
> 
> I have got the feeling that the naming I used on a recent patch is not
> correct. Because p2m_mmio_direct_nc is not doing what is expect (i.e mapping
> non-cacheable). It maps with the device memory attribute.
> 
> Maybe we should rename p2m_mmio_direct_nc to p2m_mmio_direct_dev (because it
> will use the device memory attribute) and then use p2m_mmio_direct_nc for
> your purpose.
> 
> Any opinions?


Something that shows up after doing the rename and otherwise keeping the
patch is that we treat the XN bit differently for p2m_mmio_direct_nc
and p2m_mmio_direct_c.

Is there any reason why we can't allow execution for p2m_mmio_direct_c
mappings?
If so, perhaps that same reason also applies to p2m_mmio_direct_nc and
both should be non-executable.

I think there are use-cases for running guests that will want to
execute from on chip memories. But we can cross that bridge when
we come to it...

Cheers,
Edgar








> 
> 
> > p2m_map_foreign,/* Ram pages from foreign domain */
> > p2m_grant_map_rw,   /* Read/write grant mapping */
> > p2m_grant_map_ro,   /* Read-only grant mapping */
> >diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> >index 05d9f82..9adc973 100644
> >--- a/xen/include/asm-arm/page.h
> >+++ b/xen/include/asm-arm/page.h
> >@@ -73,6 +73,7 @@
> >  *
> >  */
> > #define MATTR_DEV 0x1
> >+#define MATTR_MEM_NC  0x5
> > #define MATTR_MEM 0xf
> >
> > /* Flags for get_page_from_gva, gvirt_to_maddr etc */
> >
> 
> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Razvan Cojocaru]

On 09/16/16 18:37, Tamas K Lengyel wrote:
> Since this breaks compilation of existing clients, I think we should
>  increment some macro to alow for compile-time switching (maybe
>  VM_EVENT_INTERFACE_VERSION?).
 >>>
 >>> I'm not sure I follow - this is a Xen internal-only enumeration. What
 >>> kind-of clients are you referring to?
>>> >>
>>> >> Nevermind, I thought these changes propagate to the toolstack headers.
>>> >> Sorry for the confusion.
>> >
>> > On second thought (and a night's rest), the problem is real. I've made
>> > it a point to test the patches today before re-reviewing them, and this
>> > happened:
>> >
>> > bdvmixeneventmanager.cpp:359:46: error: ‘union vm_event_st::’
>> > has no member named ‘emul_read_data’
>> >   uint32_t rspDataSize = sizeof( rsp.data.emul_read_data.data );
>> >   ^
>> > bdvmixeneventmanager.cpp:386:44: error: ‘union vm_event_st::’
>> > has no member named ‘emul_read_data’
>> >action, rsp.data.emul_read_data.data,
>> > rspDataSize,
>> > ^
>> > bdvmixeneventmanager.cpp:389:16: error: ‘union vm_event_st::’
>> > has no member named ‘emul_read_data’
>> >rsp.data.emul_read_data.size = rspDataSize;
>> > ^
>> > make: *** [bdvmixeneventmanager.o] Error 1
>> >
>> > So, as you can see, existing clients really don't compile without
>> > modification.
>> >
> Hi Razvan,
> yes, for Xen 4.8 we already bumped the VM_EVENT_INTERFACE_VERSION, so
> any client building on it need to adapt accordingly.

Fair enough. That's all I was asking for / about: that we should make
sure that VM_EVENT_INTERFACE_VERSION reflects these changes. If it's
already been incremented for this pending release, that's perfect.


Thanks,
Razvan

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

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

[Dario Faggioli]

On Fri, 2016-09-16 at 10:49 +0800, Wei Yang wrote:
> On Wed, Sep 14, 2016 at 06:18:48PM +0200, Dario Faggioli wrote:
> > On Wed, 2016-09-14 at 18:44 +0800, Wei Yang wrote:
> > If the system is not overbooked, it's a bit strange that the
> > scheduler
> > is the bottleneck.
> I looked at the original data again. I don't see detailed data to
> describe the
> dom0 configuration.
> 
I see. No collection of output of top and xentop in dom0 either then,
I'm guessing? :-/

> The exact user model is not accessible from our client. We guess
> their model
> looks like this.
> 
> 
>  ++ +---+ +-+
>  |Timer   | --->|Coordinator| ---+--->|Worker   |
>  ++ +---+|+-+
>  |
>  |+-+
>  +--->|Worker   |
>  |+-+
>  |
>  |+-+
>  +--->|Worker   |
>   +-+
> 
> One Coordinator would driver several workers based on a high
> resolution timer.
> Periodically, workers would be waked up by the coordinator. So at one
> moment,
> many workers would be waked up and would triggers the vcpu_wake() in
> xen.
> 
It's not clear to me whether 'Coordinator' and 'Worker's are VMs, or if
the graph describes the workload run inside the (and if yes, which
ones) VMs... but that is not terribly important, after all.

> Not sure this would be a possible reason for the burst vcpu_wake()?
> 
Well, there would be, at least potentially, a sensible number of vcpus
waking up, which indeed can make the runqueue locks of the various
pcpus contended.

But then again, if the system is not oversubscribed, I'd tend to think
it to be tolerable, and I'd expect the biggest problem to be the work-
stealing logic (considering the high number of pcpus), rather than the
duration of the critical sections within vcpu_wake().

> >  - pcpu 6 is eithe idle or it is running someone already (say d3v4)
> >    + if pcpu 6 is idle, we tickle (i.e., we raise SCHEDULE_SOFTIRQ)
> >      pcpu 6 itself, and we're done
> Ok, it looks the behavior differs from 4.1 and current upstream. The
> upstream
> just raise the softirq to pcpu6 when it is idle, while 4.1 would
> raise softirq
> to both pcpu6 and other idlers even pcpu6 is idle.
> 
> I think current upstream is more cleaver.
> 
I also think current upstream is a bit better, especially because it's
mostly me that made it look the way it does. :-D

But I was actually describing how 4.1 works. In fact, in 4.1, if pcpu 6
is idle (se the '//xxx xxx xxx' comments I'm adding to the code
excerpts:

if ( new->pri > cur->pri )  //is true, so we put pcpu 6 in mask
{
cpu_set(cpu, mask);
}
if ( cur->pri > CSCHED_PRI_IDLE )  //is false!!
{

}
if ( !cpus_empty(mask) ) //the mask contains pcpu 6 only
cpumask_raise_softirq(mask, SCHEDULE_SOFTIRQ);

On the other hand, if pcpu 6 is not idle (and, sticking to the example
started in the last email, is running d3v4):

if ( new->pri > cur->pri )  //depends from d2v2's prio and d3v4 prio's
{
cpu_set(cpu, mask);
}
if ( cur->pri > CSCHED_PRI_IDLE ) //is true, so let's see...
{
if ( cpus_empty(prv->idlers) )  //is true *only* if there are no idle 
pcpu 6. Let's assume there are (i.e., let's assume this is false)
{

}
else
{
cpumask_t idle_mask;

cpus_and(idle_mask, prv->idlers, new->vcpu->cpu_affinity);
if ( !cpus_empty(idle_mask) )  //is true if there are idlers 
suitable for new (let's assume there are)
{
if ( opt_tickle_one_idle ) //chosen on boot, default is true
{
this_cpu(last_tickle_cpu) = 
cycle_cpu(this_cpu(last_tickle_cpu), idle_mask);
cpu_set(this_cpu(last_tickle_cpu), mask);
}
else

}
cpus_and(mask, mask, new->vcpu->cpu_affinity);
}
}
if ( !cpus_empty(mask) ) //mask contains pcpu 6 if d2v2 prio's was higher, 
and also contains one idle pcpu
cpumask_raise_softirq(mask, SCHEDULE_SOFTIRQ);

So, as I was saying, if pcpu 6 is idle, only pcpu 6 is tickled. If it's
not, at least one idler (if it exists) is tickled, and pcpu 6 is
tickled or not, depending or priorities.

> > And in fact, in more recent version of Xen, I made the code do
> > something very close to what you're suggesting. Here's the comment
> > that
> > you can find where all this logic is implemented (it's way more
> > complicated than this, and than the code in 4.1, because it takes
> > soft-
> > affinity 

Re: [Xen-devel] [PATCH v3 5/6] xen/arm: domain_build: Plumb for different mapping attributes

[Edgar E. Iglesias]

On Fri, Sep 16, 2016 at 04:31:20PM +0200, Julien Grall wrote:
> Hi Edgar,
> 
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Add plumbing for passing around mapping attributes. This
> >is in preparation to allow us to differentiate the attributes
> >for specific device nodes.
> >
> >We still use the same DEVICE mappings for all nodes so this
> >patch has no functional change.
> 
> I would mention somewhere (commit message, code) that unless stated, the
> children nodes inherit of the p2m type of the parent.

Yes, agreed. I've added a comment in the commit message.
Patch nr 6, when we actually start overriding types adds
a comment about the inheritance in the code that matches
nodes and provides specific types.

Thanks,
Edgar


> 
> With that:
> 
> Acked-by: Julien Grall 
> 
> Regards,
> 
> >
> >Signed-off-by: Edgar E. Iglesias 
> >---
> > xen/arch/arm/domain_build.c | 42 +-
> > 1 file changed, 29 insertions(+), 13 deletions(-)
> >
> >diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >index f022342..bbe4895 100644
> >--- a/xen/arch/arm/domain_build.c
> >+++ b/xen/arch/arm/domain_build.c
> >@@ -42,6 +42,12 @@ static void __init parse_dom0_mem(const char *s)
> > }
> > custom_param("dom0_mem", parse_dom0_mem);
> >
> >+struct map_range_data
> >+{
> >+struct domain *d;
> >+p2m_type_t p2mt;
> >+};
> >+
> > //#define DEBUG_11_ALLOCATION
> > #ifdef DEBUG_11_ALLOCATION
> > # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
> >@@ -974,7 +980,8 @@ static int map_range_to_domain(const struct 
> >dt_device_node *dev,
> >u64 addr, u64 len,
> >void *data)
> > {
> >-struct domain *d = data;
> >+struct map_range_data *mr_data = data;
> >+struct domain *d = mr_data->d;
> > bool_t need_mapping = !dt_device_for_passthrough(dev);
> > int res;
> >
> >@@ -991,10 +998,12 @@ static int map_range_to_domain(const struct 
> >dt_device_node *dev,
> >
> > if ( need_mapping )
> > {
> >-res = map_mmio_regions(d,
> >+res = map_regions_p2mt(d,
> >_gfn(paddr_to_pfn(addr)),
> >DIV_ROUND_UP(len, PAGE_SIZE),
> >-   _mfn(paddr_to_pfn(addr)));
> >+   _mfn(paddr_to_pfn(addr)),
> >+   mr_data->p2mt);
> >+
> > if ( res < 0 )
> > {
> > printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> >@@ -1005,7 +1014,8 @@ static int map_range_to_domain(const struct 
> >dt_device_node *dev,
> > }
> > }
> >
> >-dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64"\n", addr, addr + len);
> >+dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64" P2MType=%x\n",
> >+   addr, addr + len, mr_data->p2mt);
> >
> > return 0;
> > }
> >@@ -1016,8 +1026,10 @@ static int map_range_to_domain(const struct 
> >dt_device_node *dev,
> >  * the child resources available to domain 0.
> >  */
> > static int map_device_children(struct domain *d,
> >-   const struct dt_device_node *dev)
> >+   const struct dt_device_node *dev,
> >+   p2m_type_t p2mt)
> > {
> >+struct map_range_data mr_data = { .d = d, .p2mt = p2mt };
> > int ret;
> >
> > if ( dt_device_type_is_equal(dev, "pci") )
> >@@ -1029,7 +1041,7 @@ static int map_device_children(struct domain *d,
> > if ( ret < 0 )
> > return ret;
> >
> >-ret = dt_for_each_range(dev, _range_to_domain, d);
> >+ret = dt_for_each_range(dev, _range_to_domain, _data);
> > if ( ret < 0 )
> > return ret;
> > }
> >@@ -1045,7 +1057,8 @@ static int map_device_children(struct domain *d,
> >  *  - Assign the device to the guest if it's protected by an IOMMU
> >  *  - Map the IRQs and iomem regions to DOM0
> >  */
> >-static int handle_device(struct domain *d, struct dt_device_node *dev)
> >+static int handle_device(struct domain *d, struct dt_device_node *dev,
> >+ p2m_type_t p2mt)
> > {
> > unsigned int nirq;
> > unsigned int naddr;
> >@@ -,6 +1124,7 @@ static int handle_device(struct domain *d, struct 
> >dt_device_node *dev)
> > /* Give permission and map MMIOs */
> > for ( i = 0; i < naddr; i++ )
> > {
> >+struct map_range_data mr_data = { .d = d, .p2mt = p2mt };
> > res = dt_device_get_address(dev, i, , );
> > if ( res )
> > {
> >@@ -1119,12 +1133,12 @@ static int handle_device(struct domain *d, struct 
> >dt_device_node *dev)
> > return res;
> > }
> >
> >-res = map_range_to_domain(dev, addr, size, d);
> >+res = map_range_to_domain(dev, addr, size, _data);
> > if ( res )
> >

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

[Kyle Huey]

On Fri, Sep 16, 2016 at 12:50 AM, Thomas Gleixner  wrote:
> On Thu, 15 Sep 2016, Kyle Huey wrote:
>
> First of all, please add a cover letter [PATCH 0/N] to your patch series
> and send it with something which provides proper mail threading.
> See: git-send-email, quilt

I did ... seems like using git-send-email with
--cc-cmd=scripts/get_maintainer.pl is not a good idea since people get
CCd to some parts of the thread and not others.

https://lkml.org/lkml/2016/9/15/811

>> arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
>> now. Rename the second arg to a more generic name.
>
> This changelog is useless.
>
> - it does not provide any rationale for this change, i.e. why this is
>   required. Just because its 64bit only is not a reason.
>
> - "Rename the second arg to a more generic name" does not give
>   any useful information.
>
> Misleading information is worse than no information.
>
> Further your patch does 5 things at once. It wants to be split into parts:
>
> 1) Rename do_arch_prctl() and change the argument name,
>
>> -long do_arch_prctl(struct task_struct *task, int code, unsigned long addr)
>> +long do_arch_prctl_64(struct task_struct *task, int code, unsigned long 
>> arg2)
>
> 2) Provide do_arch_prctl_common() and hook it up to the arch_prctl syscall
>
>> -long sys_arch_prctl(int code, unsigned long addr)
>> +SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
>>  {
>> - return do_arch_prctl(current, code, addr);
>> + long ret;
>> +
>> + ret = do_arch_prctl_64(current, code, arg2);
>> + if (ret == -EINVAL)
>> + ret = do_arch_prctl_common(current, code, arg2);
>> +
>> + return ret;
>>  }
>
> 3) Implement the compat version

Ok.

- Kyle

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

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

[Edgar E. Iglesias]

On Fri, Sep 16, 2016 at 04:34:36PM +0200, Julien Grall wrote:
> Hi Edgar,
> 
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Add support for describing normal non-cacheable memory.
> 
> I am a bit confused, you introduced this new p2m type but I don't see any
> usage of it in this series. Is it expected?

Hi Julien,

It's supposed to be used in patch 6
xen/arm: Map mmio-sram nodes as un-cached memory

But there's a typo using p2m_mmio_direct_c instead of p2m_mem_nc :-)
I'll fix that in v4.

Cheers,
Edgar


 
> Regards,
> 
> >
> >Signed-off-by: Edgar E. Iglesias 
> >---
> > xen/arch/arm/p2m.c | 18 ++
> > xen/include/asm-arm/p2m.h  |  1 +
> > xen/include/asm-arm/page.h |  1 +
> > 3 files changed, 20 insertions(+)
> >
> >diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> >index b648a9d..bfef77b 100644
> >--- a/xen/arch/arm/p2m.c
> >+++ b/xen/arch/arm/p2m.c
> >@@ -282,6 +282,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
> >p2m_access_t a)
> > /* First apply type permissions */
> > switch ( t )
> > {
> >+case p2m_mem_nc:
> > case p2m_ram_rw:
> > e->p2m.xn = 0;
> > e->p2m.write = 1;
> >@@ -376,6 +377,23 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
> >p2m_access_t a)
> > e.p2m.sh = LPAE_SH_OUTER;
> > break;
> >
> >+/*
> >+ * ARM ARM: Overlaying the shareability attribute (DDI
> >+ * 0406C.b B3-1376 to 1377)
> >+ *
> >+ * A memory region with a resultant memory type attribute of Normal,
> >+ * and a resultant cacheability attribute of Inner Non-cacheable,
> >+ * Outer Non-cacheable, must have a resultant shareability attribute
> >+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
> >+ *
> >+ * On ARMv8 sharability is ignored and explicitly treated as Outer
> >+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.
> >+ */
> >+case p2m_mem_nc:
> >+e.p2m.mattr = MATTR_MEM_NC;
> >+e.p2m.sh = LPAE_SH_OUTER;
> >+break;
> >+
> > default:
> > e.p2m.mattr = MATTR_MEM;
> > e.p2m.sh = LPAE_SH_INNER;
> >diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> >index 53c4d78..b012d50 100644
> >--- a/xen/include/asm-arm/p2m.h
> >+++ b/xen/include/asm-arm/p2m.h
> >@@ -93,6 +93,7 @@ typedef enum {
> > p2m_ram_ro, /* Read-only; writes are silently dropped */
> > p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
> > non-cacheable */
> > p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area 
> > cacheable */
> >+p2m_mem_nc, /* Read/write mapping of Non-cacheable Memory */
> > p2m_map_foreign,/* Ram pages from foreign domain */
> > p2m_grant_map_rw,   /* Read/write grant mapping */
> > p2m_grant_map_ro,   /* Read-only grant mapping */
> >diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> >index 05d9f82..9adc973 100644
> >--- a/xen/include/asm-arm/page.h
> >+++ b/xen/include/asm-arm/page.h
> >@@ -73,6 +73,7 @@
> >  *
> >  */
> > #define MATTR_DEV 0x1
> >+#define MATTR_MEM_NC  0x5
> > #define MATTR_MEM 0xf
> >
> > /* Flags for get_page_from_gva, gvirt_to_maddr etc */
> >
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH] x86/Intel: hide CPUID faulting capability from guests

[Kyle Huey]

On Thu, Sep 15, 2016 at 11:32 PM, Jan Beulich  wrote:
> We don't currently emulate it, so guests should not be misguided to
> believe they can (try to) use it.
>
> For now, simply return zero to guests for platform MSR reads, and only
> accept (by discarding) writes of zero. If ever there will be bits we
> can safely expose to guests, let's handle them by white listing.
>
> (As a side note - according to SDM version 059 bit 31 is reserved on
> all known families.)
>
> Reported-by: Kyle Huey 
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2699,6 +2699,13 @@ static int vmx_msr_read_intercept(unsign
>  if ( vpmu_do_rdmsr(msr, msr_content) )
>  goto gp_fault;
>  break;
> +
> +case MSR_INTEL_PLATFORM_INFO:
> +if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) )
> +goto gp_fault;
> +*msr_content = 0;
> +break;
> +
>  default:
>  if ( passive_domain_do_rdmsr(msr, msr_content) )
>  goto done;
> @@ -2918,6 +2925,13 @@ static int vmx_msr_write_intercept(unsig
>   if ( vpmu_do_wrmsr(msr, msr_content, 0) )
>  goto gp_fault;
>  break;
> +
> +case MSR_INTEL_PLATFORM_INFO:
> +if ( msr_content ||
> + rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
> +goto gp_fault;
> +break;
> +
>  default:
>  if ( passive_domain_do_wrmsr(msr, msr_content) )
>  return X86EMUL_OKAY;
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2938,6 +2938,14 @@ static int emulate_privileged_op(struct
>  if ( v->arch.debugreg[7] & DR7_ACTIVE_MASK )
>  wrmsrl(regs->_ecx, msr_content);
>  break;
> +
> +case MSR_INTEL_PLATFORM_INFO:
> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
> + msr_content ||
> + rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
> +goto fail;
> +break;
> +
>  case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
>  case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
>  case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
> @@ -3066,6 +3074,14 @@ static int emulate_privileged_op(struct
>  /* No extra capabilities are supported */
>  regs->eax = regs->edx = 0;
>  break;
> +
> +case MSR_INTEL_PLATFORM_INFO:
> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
> + rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val) )
> +goto fail;
> +regs->eax = regs->edx = 0;
> +break;
> +
>  case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
>  case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
>  case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
>
>
>

Excellent.  Thank you for writing this.

- Kyle

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

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

On Fri, Sep 16, 2016 at 7:54 AM, Julien Grall  wrote:
> Hi Tamas,
>
> On 15/09/2016 20:24, Tamas K Lengyel wrote:
>>
>> The ARM SMC instructions are already configured to trap to Xen by default.
>> In
>> this patch we allow a user-space process in a privileged domain to receive
>> notification of when such event happens through the vm_event subsystem by
>> introducing the PRIVILEGED_CALL type.
>>
>> The intended use-case for this feature is for a monitor application to be
>> able
>> insert tap-points into the domU kernel-code. For this task only
>> unconditional
>> SMC instruction should be used.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Acked-by: Wei Liu 
>> ---
>> Cc: Ian Jackson 
>> Cc: Razvan Cojocaru 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>>
>> v3: Rebase on latest master
>>
>> Note: previous discussion around this patch proposed filtering SMCs with
>> failed
>>   condition checks. As that patch is yet-to-be implemented and the 4.8
>>   code-freeze rapidly approaching I would like this patch to get
>> included.
>
>
> It is still in my todo list. But as I said last time, it is towards the
> bottom of it. I would have expected a bit of help from your side here rather
> than putting the fault on me.

Not putting a fault on anyone. I did take a look at it but there had
been enough unknowns for me that I would rather have you do it when
you get to it. I think this is just a minor issue that should not be a
roadblock for this patch. If it gets filtered at some point in the
future it will have no impact on applications that this interface is
intended for. For all else, a warning is in place not to rely on this
behavior being a "feature".

>
>>   In this patch a proper warning is placed in the public header for
>>   potential users not to rely on SMCs with failed condition checks
>> being
>>   trapped. As the intended use-case for this feature doesn't use
>>   conditional SMCs this warning should be sufficient. Hardware that
>> does
>>   issue events for SMCs with failed condition checks doesn't pose a
>> problem
>>   for a monitor application in any way. The xen-access test tool
>> illustrates
>>   how SMCs issued by the guest can be safely handled for all cases.
>
>
> This is nice, but how about passing the immediate to the event monitor? The
> SMC call is not meant to be a breakpoint instruction but a way to call the
> supervisor monitor (and potentially be emulated by the hypervisor).

I understand that was the original intention behind the instruction.
So when the emulation use-case becomes actual the immediate can be
included and passed along too, we would just bump the
VM_EVENT_INTERFACE_VERSION. As that was not my usecase it is beyond
scope for this patch. It can certainly be implemented at some later
time.

>
>
>> ---
>>  tools/libxc/include/xenctrl.h   |  2 +
>>  tools/libxc/xc_monitor.c| 14 +++
>>  tools/tests/xen-access/xen-access.c | 32 ++-
>>  xen/arch/arm/Makefile   |  1 +
>>  xen/arch/arm/monitor.c  | 79
>> +
>>  xen/arch/arm/traps.c| 15 ++-
>>  xen/include/asm-arm/domain.h|  5 +++
>>  xen/include/asm-arm/monitor.h   | 18 +++--
>>  xen/include/public/domctl.h |  1 +
>>  xen/include/public/vm_event.h   |  7 
>>  10 files changed, 158 insertions(+), 16 deletions(-)
>>  create mode 100644 xen/arch/arm/monitor.c
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index 560ce7b..eb53172 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/xenctrl.h
>> @@ -2168,6 +2168,8 @@ int xc_monitor_guest_request(xc_interface *xch,
>> domid_t domain_id,
>>  int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
>>  bool enable, bool sync);
>>  int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
>> +int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
>> +   bool enable);
>>  /**
>>   * This function enables / disables emulation for each REP for a
>>   * REP-compatible instruction.
>> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
>> index 4298813..15a7c32 100644
>> --- a/tools/libxc/xc_monitor.c
>> +++ b/tools/libxc/xc_monitor.c
>> @@ -185,6 +185,20 @@ int xc_monitor_cpuid(xc_interface *xch, domid_t
>> domain_id, bool enable)
>>  return do_domctl(xch, );
>>  }
>>
>> +int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
>> +   bool enable)
>> +{
>> +DECLARE_DOMCTL;
>> +
>> +domctl.cmd = XEN_DOMCTL_monitor_op;
>> +domctl.domain = domain_id;
>> +domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
>> +

Re: [Xen-devel] [PATCH v3 4/6] xen/device-tree: Make dt_match_node match props

[Edgar E. Iglesias]

On Fri, Sep 16, 2016 at 04:28:20PM +0200, Julien Grall wrote:
> Hi Edgar,
> 
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Make dt_match_node match for existing properties.
> >We only search for the existence of the properties, not
> >for specific values.
> >
> >Signed-off-by: Edgar E. Iglesias 
> >---
> > xen/common/device_tree.c  | 5 -
> > xen/include/xen/device_tree.h | 7 +++
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> >diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> >index b39c8ca..1be074b 100644
> >--- a/xen/common/device_tree.c
> >+++ b/xen/common/device_tree.c
> >@@ -319,7 +319,7 @@ dt_match_node(const struct dt_device_match *matches,
> > return NULL;
> >
> > while ( matches->path || matches->type ||
> >-matches->compatible || matches->not_available )
> >+matches->compatible || matches->not_available || matches->prop)
> > {
> > bool_t match = 1;
> >
> >@@ -335,6 +335,9 @@ dt_match_node(const struct dt_device_match *matches,
> > if ( matches->not_available )
> > match &= !dt_device_is_available(node);
> >
> >+if ( matches->prop )
> >+match &= dt_find_property(node, matches->prop, NULL) != NULL;
> >+
> > if ( match )
> > return matches;
> > matches++;
> >diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> >index da153a5..c71ddb9 100644
> >--- a/xen/include/xen/device_tree.h
> >+++ b/xen/include/xen/device_tree.h
> >@@ -29,6 +29,11 @@ struct dt_device_match {
> > const char *type;
> > const char *compatible;
> > const bool_t not_available;
> >+/*
> >+ * Property name to search for. We only search for the properties
> 
> NIT: s/the properties/the property/ I think same.
> I think this also apply for the commit message?

OK, I've changed the commit message to:
xen/device-tree: Make dt_match_node match props

Make dt_match_node match for a single existing property.
We only search for the existence of the property, not
for specific values.

And I've changed the comment to say "the property's existence"
which I think is correct but I'm not a native English speaker..

Cheers,
Edgar

> 
> The rest of the patch looks good to me:
> 
> Acked-by: Julien Grall 
> 
> Regards,
> 
> >+ * existence.
> >+ */
> >+const char *prop;
> > const void *data;
> > };
> >
> >@@ -36,11 +41,13 @@ struct dt_device_match {
> > #define __DT_MATCH_TYPE(typ).type = typ
> > #define __DT_MATCH_COMPATIBLE(compat)   .compatible = compat
> > #define __DT_MATCH_NOT_AVAILABLE()  .not_available = 1
> >+#define __DT_MATCH_PROP(p)  .prop = p
> >
> > #define DT_MATCH_PATH(p){ __DT_MATCH_PATH(p) }
> > #define DT_MATCH_TYPE(typ)  { __DT_MATCH_TYPE(typ) }
> > #define DT_MATCH_COMPATIBLE(compat) { __DT_MATCH_COMPATIBLE(compat) }
> > #define DT_MATCH_NOT_AVAILABLE(){ __DT_MATCH_NOT_AVAILABLE() }
> >+#define DT_MATCH_PROP(p){ __DT_MATCH_PROP(p) }
> >
> > typedef u32 dt_phandle;
> >
> >
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Tamas K Lengyel]

On Fri, Sep 16, 2016 at 1:21 AM, Razvan Cojocaru
 wrote:
> On 09/15/16 20:08, Razvan Cojocaru wrote:
>> On 09/15/16 19:36, Tamas K Lengyel wrote:
>>> On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru
>>>  wrote:
 On 09/13/2016 09:12 PM, Tamas K Lengyel wrote:
> When emulating instructions the emulator maintains a small i-cache fetched
> from the guest memory. This patch extends the vm_event interface to allow
> returning this i-cache via the vm_event response instead.
>
> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor 
> subscriber
> normally has to remove the INT3 from memory - singlestep - place back INT3
> to allow the guest to continue execution. This routine however is 
> susceptible
> to a race-condition on multi-vCPU guests. By allowing the subscriber to 
> return
> the i-cache to be used for emulation it can side-step the problem by 
> returning
> a clean buffer without the INT3 present.
>
> As part of this patch we rename hvm_mem_access_emulate_one to
> hvm_emulate_one_vm_event to better reflect that it is used in various 
> vm_event
> scenarios now, not just in response to mem_access events.
>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: George Dunlap 
> Cc: Razvan Cojocaru 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
>
> Note: This patch only has been compile-tested.
> ---
>  xen/arch/x86/hvm/emulate.c| 44 
> ++-
>  xen/arch/x86/hvm/hvm.c|  9 +---
>  xen/arch/x86/hvm/vmx/vmx.c|  1 +
>  xen/arch/x86/vm_event.c   |  9 +++-
>  xen/common/vm_event.c |  1 -
>  xen/include/asm-x86/hvm/emulate.h |  8 ---
>  xen/include/asm-x86/vm_event.h|  3 ++-
>  xen/include/public/vm_event.h | 16 +-
>  8 files changed, 67 insertions(+), 24 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index cc25676..504ed35 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int 
> size)
>  if ( curr->arch.vm_event )
>  {
>  unsigned int safe_size =
> -min(size, curr->arch.vm_event->emul_read_data.size);
> +min(size, curr->arch.vm_event->emul_read.size);
>
> -memcpy(buffer, curr->arch.vm_event->emul_read_data.data, 
> safe_size);
> +memcpy(buffer, curr->arch.vm_event->emul_read.data, safe_size);
>  memset(buffer + safe_size, 0, size - safe_size);
>  return X86EMUL_OKAY;
>  }
> @@ -827,7 +827,7 @@ static int hvmemul_read(
>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  return set_context_data(p_data, bytes);
>
>  return __hvmemul_read(
> @@ -1029,7 +1029,7 @@ static int hvmemul_cmpxchg(
>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  {
>  int rc = set_context_data(p_new, bytes);
>
> @@ -1122,7 +1122,7 @@ static int hvmemul_rep_outs(
>  p2m_type_t p2mt;
>  int rc;
>
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  return hvmemul_rep_outs_set_context(src_seg, src_offset, 
> dst_port,
>  bytes_per_rep, reps, ctxt);
>
> @@ -1264,7 +1264,7 @@ static int hvmemul_rep_movs(
>  if ( buf == NULL )
>  return X86EMUL_UNHANDLEABLE;
>
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  {
>  rc = set_context_data(buf, bytes);
>
> @@ -1470,7 +1470,7 @@ static int hvmemul_read_io(
>
>  *val = 0;
>
> -if ( unlikely(hvmemul_ctxt->set_context) )
> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>  return set_context_data(val, bytes);
>
>  return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
> @@ 

[Xen-devel] [seabios test] 100987: tolerable FAIL - PUSHED

[osstest service owner]

flight 100987 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100987/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100898
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100898

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios  dc2433e35bde0120e1765d8643cdf9e66e496661
baseline version:
 seabios  642db1905ab133007d7427b6758a2103fb09a19a

Last test of basis   100898  2016-09-12 14:45:02 Z4 days
Testing same since   100987  2016-09-16 12:44:40 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Igor Mammedov 
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=seabios
+ revision=dc2433e35bde0120e1765d8643cdf9e66e496661
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push seabios 
dc2433e35bde0120e1765d8643cdf9e66e496661
+ branch=seabios
+ revision=dc2433e35bde0120e1765d8643cdf9e66e496661
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ 

Re: [Xen-devel] [PATCH v3 2/6] xen/arm: Rename and generalize un/map_regions_rw_cache

[Edgar E. Iglesias]

On Fri, Sep 16, 2016 at 04:24:17PM +0200, Julien Grall wrote:
> Hi Edgar,
> 
> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Rename and generalize un/map_regions_rw_cache into
> >un/map_regions_p2mt. The new functions take the mapping
> >attributes as an argument.
> >
> >No functional change.
> >
> >Signed-off-by: Edgar E. Iglesias 
> >---
> > xen/arch/arm/domain_build.c | 18 ++
> > xen/arch/arm/p2m.c  | 19 ++-
> > xen/include/asm-arm/p2m.h   | 19 ++-
> > 3 files changed, 30 insertions(+), 26 deletions(-)
> >
> >diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >index 35ab08d..f022342 100644
> >--- a/xen/arch/arm/domain_build.c
> >+++ b/xen/arch/arm/domain_build.c
> >@@ -1518,10 +1518,11 @@ static void acpi_map_other_tables(struct domain *d)
> > {
> > addr = acpi_gbl_root_table_list.tables[i].address;
> > size = acpi_gbl_root_table_list.tables[i].length;
> >-res = map_regions_rw_cache(d,
> >-   _gfn(paddr_to_pfn(addr)),
> >-   DIV_ROUND_UP(size, PAGE_SIZE),
> >-   _mfn(paddr_to_pfn(addr)));
> >+res = map_regions_p2mt(d,
> >+   _gfn(paddr_to_pfn(addr)),
> >+   DIV_ROUND_UP(size, PAGE_SIZE),
> >+   _mfn(paddr_to_pfn(addr)),
> >+   p2m_mmio_direct_c);
> > if ( res )
> > {
> >  panic(XENLOG_ERR "Unable to map ACPI region 0x%"PRIx64
> >@@ -1874,10 +1875,11 @@ static int prepare_acpi(struct domain *d, struct 
> >kernel_info *kinfo)
> > acpi_create_efi_mmap_table(d, >mem, tbl_add);
> >
> > /* Map the EFI and ACPI tables to Dom0 */
> >-rc = map_regions_rw_cache(d,
> >-  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
> >-  PFN_UP(d->arch.efi_acpi_len),
> >-  
> >_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table;
> >+rc = map_regions_p2mt(d,
> >+  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
> >+  PFN_UP(d->arch.efi_acpi_len),
> >+  
> >_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table))),
> >+  p2m_mmio_direct_c);
> > if ( rc != 0 )
> > {
> > printk(XENLOG_ERR "Unable to map EFI/ACPI table 0x%"PRIx64
> >diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> >index bfef77b..58d4940 100644
> >--- a/xen/arch/arm/p2m.c
> >+++ b/xen/arch/arm/p2m.c
> >@@ -1234,18 +1234,19 @@ static inline int p2m_remove_mapping(struct domain 
> >*d,
> >  0, p2m_invalid, d->arch.p2m.default_access);
> > }
> >
> >-int map_regions_rw_cache(struct domain *d,
> >- gfn_t gfn,
> >- unsigned long nr,
> >- mfn_t mfn)
> >+int map_regions_p2mt(struct domain *d,
> >+ gfn_t gfn,
> >+ unsigned long nr,
> >+ mfn_t mfn,
> >+ p2m_type_t p2mt)
> > {
> >-return p2m_insert_mapping(d, gfn, nr, mfn, p2m_mmio_direct_c);
> >+return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);
> > }
> >
> >-int unmap_regions_rw_cache(struct domain *d,
> >-   gfn_t gfn,
> >-   unsigned long nr,
> >-   mfn_t mfn)
> >+int unmap_regions_p2mt(struct domain *d,
> >+   gfn_t gfn,
> >+   unsigned long nr,
> >+   mfn_t mfn)
> > {
> > return p2m_remove_mapping(d, gfn, nr, mfn);
> > }
> >diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> >index b012d50..f2bd16c 100644
> >--- a/xen/include/asm-arm/p2m.h
> >+++ b/xen/include/asm-arm/p2m.h
> >@@ -166,15 +166,16 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, 
> >p2m_type_t *t);
> > /* Clean & invalidate caches corresponding to a region of guest address 
> > space */
> > int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
> >
> >-int map_regions_rw_cache(struct domain *d,
> >- gfn_t gfn,
> >- unsigned long nr,
> >- mfn_t mfn);
> >-
> >-int unmap_regions_rw_cache(struct domain *d,
> >-   gfn_t gfn,
> >-   unsigned long nr,
> >-   mfn_t mfn);
> >+int map_regions_p2mt(struct domain *d,
> >+ gfn_t gfn,
> >+ unsigned long nr,
> >+ mfn_t mfn,
> >+ p2m_type_t p2mt);
> 
> Can you document the purpose of this function in the code? Something like:
> "Map the region in the guest p2m with a specific type (will affect the
> attributes 

[Xen-devel] [PATCH v6 2/6] livepatch: Add limit of 2MB to payload .bss sections.

[Konrad Rzeszutek Wilk]

The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793
"xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the
size of the binary at 2MB. We follow that in capping the size
of the .BSSes to be at maximum 2MB.

Reviewed-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Ross Lagerwall 
Cc: Jan Beulich 

v5: Initial submission. Came about from conversation about
"livepatch: Clear .bss when payload is reverted"
   - Use only one sh_flags comparison instead of two.
   - And check for the _right_ combination (WA).
v6: Remove the logging
Move the MB(2) to a #define in the header file.
Add the newline after the addition in livepatch_elf.c.
Added Reviewed-by from Ross.
---
 xen/common/livepatch_elf.c  | 4 
 xen/include/xen/livepatch.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index cda9b27..79c290e 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -86,6 +86,10 @@ static int elf_resolve_sections(struct livepatch_elf *elf, 
const void *data)
 delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past 
end");
 return -EINVAL;
 }
+else if ( (sec[i].sec->sh_flags & (SHF_WRITE | SHF_ALLOC)) &&
+  sec[i].sec->sh_type == SHT_NOBITS &&
+  sec[i].sec->sh_size > BSS_MAX_SIZE )
+return -EINVAL;
 
 sec[i].data = data + delta;
 /* Name is populated in elf_resolve_section_names. */
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 243e240..46b9fc2 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -30,6 +30,8 @@ struct xen_sysctl_livepatch_op;
 #define ELF_LIVEPATCH_FUNC".livepatch.funcs"
 #define ELF_LIVEPATCH_DEPENDS ".livepatch.depends"
 #define ELF_BUILD_ID_NOTE  ".note.gnu.build-id"
+/* Arbitrary limit. */
+#define BSS_MAX_SIZEMB(2)
 
 struct livepatch_symbol {
 const char *name;
-- 
2.5.5


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

[Xen-devel] [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero.

[Konrad Rzeszutek Wilk]

The NOP functionality will NOP any of the code at
the 'old_addr' or at 'name' if the 'new_addr' is zero.
The purpose of this is to NOP out calls, such as:

 e8 <4-bytes-offset>

(5 byte insn), or on ARM a 4 byte insn for branching.

We need the EIP of where we need to the NOP, and that can
be provided via the `old_addr` or `name`.

If the `old_addr` is provided we will NOP 'new_size'
amount of bytes at that location.

The amount is up to 31 instructions if desired (which is
the size of the opaque member). If there is a need to NOP
more then: a) more 'struct livepatch_func' structures need
to be present, b) we have to implement a variable size
buffer (in the future), or c) first byte an unconditional
branch skipping the to be disabled code (of course provided
there are no branch targets in the middle).

While at it, also unify the code on x86 patching so
it is a bit simpler (instead of two seperate writes
just make it one memcpy).

And introduce a general livepatch_insn_len inline function
that would depend on platform specific instruction size
(for a unconditional branch). As such we also rename the
PATCH_INSN_SIZE to ARCH_PATCH_INSN_SIZE.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: First submission
v4: Fix description - e9 -> e8
Remove the restriction of only doing 5 or 4 bytes.
Redo the patching code to deal with variable size of new_size.
Expand the amount of bytes we can NOP.
Move the PATCH_INSN_SIZE definition in platform specific headers
Move the get_len to livepatch_get_insn_len inline function.
v5: s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
s/arch_livepatch_insn_len/livepatch_insn_len/
s/size_t len/unsigned int len/
Add in commit description the c) mechanism (insert an unconditional
branch).
---
 docs/misc/livepatch.markdown  |  7 +--
 xen/arch/x86/alternative.c|  2 +-
 xen/arch/x86/livepatch.c  | 40 +--
 xen/common/livepatch.c|  3 ++-
 xen/include/asm-x86/alternative.h |  1 +
 xen/include/asm-x86/livepatch.h   | 21 
 xen/include/xen/livepatch.h   |  9 +
 7 files changed, 65 insertions(+), 18 deletions(-)
 create mode 100644 xen/include/asm-x86/livepatch.h

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 81f4fc9..a8e70a8 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -320,10 +320,13 @@ The size of the structure is 64 bytes on 64-bit 
hypervisors. It will be
 
 * `new_addr` is the address of the function that is replacing the old
   function. The address is filled in during relocation. The value **MUST** be
-  the address of the new function in the file.
+  either the address of the new function in the file, or zero if we are NOPing 
out
+  at `old_addr` (and `new_size` **MUST** not be zero).
 
 * `old_size` and `new_size` contain the sizes of the respective functions in 
bytes.
-   The value of `old_size` **MUST** not be zero.
+   The value of `old_size` **MUST** not be zero. If the value of `new_addr` is
+   zero then `new_size` determines how many instruction bytes to NOP (up to
+   opaque size modulo smallest platform instruction - 1 byte x86 and 4 bytes 
on ARM).
 
 * `version` is to be one.
 
diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index 05e3eb8..6eaa10f 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -101,7 +101,7 @@ static void __init arch_init_ideal_nops(void)
 }
 
 /* Use this to add nops to a buffer, then text_poke the whole buffer. */
-static void init_or_livepatch add_nops(void *insns, unsigned int len)
+void init_or_livepatch add_nops(void *insns, unsigned int len)
 {
 while ( len > 0 )
 {
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 725b3f6..0b8642b 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -12,8 +12,7 @@
 #include 
 
 #include 
-
-#define PATCH_INSN_SIZE 5
+#include 
 
 int arch_livepatch_quiesce(void)
 {
@@ -31,11 +30,11 @@ void arch_livepatch_revive(void)
 
 int arch_livepatch_verify_func(const struct livepatch_func *func)
 {
-/* No NOP patching yet. */
-if ( !func->new_size )
+/* If NOPing only do up to maximum amount we can put in the ->opaque. */
+if ( !func->new_addr && func->new_size > sizeof(func->opaque) )
 return -EOPNOTSUPP;
 
-if ( func->old_size < PATCH_INSN_SIZE )
+if ( func->old_size < ARCH_PATCH_INSN_SIZE )
 return -EINVAL;
 
 return 0;
@@ -43,23 +42,36 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 
 void arch_livepatch_apply_jmp(struct livepatch_func *func)
 {
-int32_t val;
 uint8_t *old_ptr;
-
-BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
-

[Xen-devel] [PATCH v6 4/6] livepach: Add .livepatch.hooks functions and test-case

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Add hook functions which run during patch apply and patch revert.
Hook functions are used by livepatch payloads to manipulate data
structures during patching, etc.

One use case is the XSA91. As Martin mentions it:
"If we have shadow variables, we also need an unload hook to garbage
collect all the variables introduced by a hotpatch to prevent memory
leaks.  Potentially, we also want to pre-reserve memory for static or
existing dynamic objects in the load-hook instead of on the fly.

For testing and debugging, various applications are possible.

In general, the hooks provide flexibility when having to deal with
unforeseen cases, but their application should be rarely required (<
10%)."

Furthermore include a test-case for it.

Reviewed-by: Andrew Cooper 
Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v0.4..v0.11: Defered for v4.8
v0.12: s/xsplice/livepatch/

v3: Clarify the comments about spin_debug_enable
Rename one of the hooks to lower-case (Z->z) to guarantee it being
called last.
Learned a lot of about 'const'
v4: Do the actual const of the hooks.
Remove the requirement for the tests-case hooks to be sorted
(they never were to start with).
Fix up the comment about spin_debug_enable so more.
v5: Added Reviewed-by from Andrew.
Dropped the check_fnc hook
Added the check_fnc hook back again as "livepatch: Disallow applying
after an revert" guarantees we won't hit the BUG_ON check.
---
 docs/misc/livepatch.markdown| 23 +
 xen/arch/x86/test/xen_hello_world.c | 34 +
 xen/common/livepatch.c  | 50 -
 xen/include/xen/livepatch_payload.h | 49 
 4 files changed, 155 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/xen/livepatch_payload.h

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index a8e70a8..9e72897 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -343,6 +343,13 @@ When reverting a patch, the hypervisor iterates over each 
`livepatch_func`
 and the core code copies the data from the undo buffer (private internal copy)
 to `old_addr`.
 
+It optionally may contain the address of functions to be called right before
+being applied and after being reverted:
+
+ * `.livepatch.hooks.load` - an array of function pointers.
+ * `.livepatch.hooks.unload` - an array of function pointers.
+
+
 ### Example of .livepatch.funcs
 
 A simple example of what a payload file can be:
@@ -380,6 +387,22 @@ struct livepatch_func livepatch_hello_world = {
 
 Code must be compiled with -fPIC.
 
+### .livepatch.hooks.load and .livepatch.hooks.unload
+
+This section contains an array of function pointers to be executed
+before payload is being applied (.livepatch.funcs) or after reverting
+the payload. This is useful to prepare data structures that need to
+be modified patching.
+
+Each entry in this array is eight bytes.
+
+The type definition of the function are as follow:
+
+
+typedef void (*livepatch_loadcall_t)(void);  
+typedef void (*livepatch_unloadcall_t)(void);   
+
+
 ### .livepatch.depends and .note.gnu.build-id
 
 To support dependencies checking and safe loading (to load the
diff --git a/xen/arch/x86/test/xen_hello_world.c 
b/xen/arch/x86/test/xen_hello_world.c
index 422bdf1..cb5e27a 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -4,14 +4,48 @@
  */
 
 #include "config.h"
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
 static char hello_world_patch_this_fnc[] = "xen_extra_version";
 extern const char *xen_hello_world(void);
+static unsigned int cnt;
+
+static void apply_hook(void)
+{
+printk(KERN_DEBUG "Hook executing.\n");
+}
+
+static void revert_hook(void)
+{
+printk(KERN_DEBUG "Hook unloaded.\n");
+}
+
+static void  hi_func(void)
+{
+printk(KERN_DEBUG "%s: Hi! (called %u times)\n", __func__, ++cnt);
+};
+
+static void check_fnc(void)
+{
+printk(KERN_DEBUG "%s: Hi func called %u times\n", __func__, cnt);
+BUG_ON(cnt == 0 || cnt > 2);
+}
+
+LIVEPATCH_LOAD_HOOK(apply_hook);
+LIVEPATCH_UNLOAD_HOOK(revert_hook);
+
+/* Imbalance here. Two load and three unload. */
+
+LIVEPATCH_LOAD_HOOK(hi_func);
+LIVEPATCH_UNLOAD_HOOK(hi_func);
+
+LIVEPATCH_UNLOAD_HOOK(check_fnc);
 
 struct livepatch_func __section(".livepatch.funcs") livepatch_xen_hello_world 
= {
 .version = LIVEPATCH_PAYLOAD_VERSION,
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 

[Xen-devel] [PATCH v6] Livepatch fixes and general features for Xen4.8.

[Konrad Rzeszutek Wilk]

Hey!

Since v5:[https://lists.xen.org/archives/html/xen-devel/2016-09/msg01114.html]
 - Acted on the review comments.
 - Replaced "livepatch/docs: Document .bss not being cleared, and .data 
potentially 
   having changed values" with "livepatch: Disallow applying after an revert"
 - Added two minor fixes to the test-cases (one of them was part of the ARM32/64
   livepatch support).

Since v4: 
[https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg02705.html]
 - Committed Acked/Reviewed patches.
 - Discarded couple of patches to address later.

Since v3: [https://lists.xen.org/archives/html/xen-devel/2016-08/msg01825.html]
 - Acked on reviews
v2, v1:
 - Left over fixes and features that didn't get quite done in 4.7

Included are:
 - Bug-fixes
 - NOP patching
 - Hooks

The first one deals with .bss and replaces the "livepatch/docs: Document .bss
not being cleared, and .data potentially" which was posted in v5.

The legend is:

 r - Reviewed-by

   livepatch: Disallow applying after an revert
r  livepatch: Add limit of 2MB to payload .bss sections.
   livepatch: NOP if func->new_addr is zero.
r  livepach: Add .livepatch.hooks functions and test-case
   livepatch/tests: Make .livepatch.depends be read-only
   livepatch/tests: Move the .name value to .rodata


Thanks!

The git tree is

 git://xenbits.xen.org/people/konradwilk/xen.git livepatch.v4.8.v6

contains all the following patches (and more):

Konrad Rzeszutek Wilk (5):
  livepatch: Disallow applying after an revert
  livepatch: Add limit of 2MB to payload .bss sections.
  livepatch: NOP if func->new_addr is zero.
  livepatch/tests: Make .livepatch.depends be read-only
  livepatch/tests: Move the .name value to .rodata

Ross Lagerwall (1):
  livepach: Add .livepatch.hooks functions and test-case


 docs/misc/livepatch.markdown  | 37 +++-
 xen/arch/x86/alternative.c|  2 +-
 xen/arch/x86/livepatch.c  | 40 --
 xen/arch/x86/test/Makefile|  4 +-
 xen/arch/x86/test/xen_bye_world.c |  2 +-
 xen/arch/x86/test/xen_hello_world.c   | 36 +++-
 xen/arch/x86/test/xen_replace_world.c |  2 +-
 xen/common/livepatch.c| 80 +--
 xen/common/livepatch_elf.c|  4 ++
 xen/include/asm-x86/alternative.h |  1 +
 xen/include/asm-x86/livepatch.h   | 21 +
 xen/include/xen/livepatch.h   | 11 +
 xen/include/xen/livepatch_payload.h   | 49 +
 13 files changed, 264 insertions(+), 25 deletions(-)

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

[Xen-devel] [PATCH v6 6/6] livepatch/tests: Move the .name value to .rodata

[Konrad Rzeszutek Wilk]

Right now the contents of 'name' are all located in
the .data section. We want them in the .rodata section
so change the type to have const on them.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 

v3: First submission (as part of the ARM 32 and 64 support of Livepatch)
v6: Now moved to the Common Livepatch fixes for 4.8
---
 xen/arch/x86/test/xen_bye_world.c | 2 +-
 xen/arch/x86/test/xen_hello_world.c   | 2 +-
 xen/arch/x86/test/xen_replace_world.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/test/xen_bye_world.c 
b/xen/arch/x86/test/xen_bye_world.c
index b75e0b1..2700f0e 100644
--- a/xen/arch/x86/test/xen_bye_world.c
+++ b/xen/arch/x86/test/xen_bye_world.c
@@ -11,7 +11,7 @@
 
 #include 
 
-static char bye_world_patch_this_fnc[] = "xen_extra_version";
+static const char bye_world_patch_this_fnc[] = "xen_extra_version";
 extern const char *xen_bye_world(void);
 
 struct livepatch_func __section(".livepatch.funcs") livepatch_xen_bye_world = {
diff --git a/xen/arch/x86/test/xen_hello_world.c 
b/xen/arch/x86/test/xen_hello_world.c
index cb5e27a..02f3f85 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -12,7 +12,7 @@
 
 #include 
 
-static char hello_world_patch_this_fnc[] = "xen_extra_version";
+static const char hello_world_patch_this_fnc[] = "xen_extra_version";
 extern const char *xen_hello_world(void);
 static unsigned int cnt;
 
diff --git a/xen/arch/x86/test/xen_replace_world.c 
b/xen/arch/x86/test/xen_replace_world.c
index a2a221a..78a8f52 100644
--- a/xen/arch/x86/test/xen_replace_world.c
+++ b/xen/arch/x86/test/xen_replace_world.c
@@ -10,7 +10,7 @@
 
 #include 
 
-static char xen_replace_world_name[] = "xen_extra_version";
+static const char xen_replace_world_name[] = "xen_extra_version";
 extern const char *xen_replace_world(void);
 
 struct livepatch_func __section(".livepatch.funcs") 
livepatch_xen_replace_world = {
-- 
2.5.5


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

[Xen-devel] [PATCH v6 5/6] livepatch/tests: Make .livepatch.depends be read-only

[Konrad Rzeszutek Wilk]

As currently during the injection of the build-id it ends up
being marked as AW. We want it to be read-only.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 

v6: New submission.
---
 xen/arch/x86/test/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/test/Makefile b/xen/arch/x86/test/Makefile
index 23dff1d..48ff843 100644
--- a/xen/arch/x86/test/Makefile
+++ b/xen/arch/x86/test/Makefile
@@ -55,7 +55,7 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
 note.o:
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@.bin
$(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
-  --rename-section=.data=.livepatch.depends -S $@.bin $@
+  
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
rm -f $@.bin
 
 #
@@ -66,7 +66,7 @@ note.o:
 hello_world_note.o: $(LIVEPATCH)
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH) 
$@.bin
$(OBJCOPY)  -I binary -O elf64-x86-64 -B i386:x86-64 \
-  --rename-section=.data=.livepatch.depends -S $@.bin $@
+  
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
rm -f $@.bin
 
 xen_bye_world.o: config.h
-- 
2.5.5


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

[Xen-devel] [PATCH v6 1/6] livepatch: Disallow applying after an revert

[Konrad Rzeszutek Wilk]

On general this is unhealthy - as the payload's .bss (definitly)
or .data (maybe) will be modified once the payload is running.

Doing an revert and then re-applying the payload with a non-pristine
.bss or .data can lead to unforseen consequences (.bss are assumed
to always contain zero value but now they may have a different value).

There is one exception - if the payload contains only one .data section
- the .livepatch.funcs, then it is OK to re-apply an revert.

Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: Jan Beulich 

v6: New submission
---
 docs/misc/livepatch.markdown |  7 +++
 xen/common/livepatch.c   | 27 ++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 89c1050..81f4fc9 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -1061,6 +1061,13 @@ depending on the current state of data. As such it 
should not be attempted.
 That said we should provide hook functions so that the existing data
 can be changed during payload application.
 
+To guarantee safety we disallow re-applying an payload after it has been
+reverted. This is because we cannot guarantee that the state of .bss
+and .data to be exactly as it was during loading. Hence the administrator
+MUST unload the payload and upload it again to apply it.
+
+There is an exception to this: if the payload only has .livepatch.funcs;
+and no .data or .bss sections.
 
 ### Inline patching
 
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 23e4d51..967985c 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -52,6 +52,8 @@ struct livepatch_build_id {
 struct payload {
 uint32_t state;  /* One of the LIVEPATCH_STATE_*. */
 int32_t rc;  /* 0 or -XEN_EXX. */
+bool_t reverted; /* Whether it was reverted. */
+bool_t safe_to_reapply;  /* Can apply safely after revert. */
 struct list_head list;   /* Linked to 'payload_list'. */
 const void *text_addr;   /* Virtual address of .text. */
 size_t text_size;/* .. and its size. */
@@ -308,7 +310,7 @@ static void calc_section(const struct livepatch_elf_sec 
*sec, size_t *size,
 static int move_payload(struct payload *payload, struct livepatch_elf *elf)
 {
 void *text_buf, *ro_buf, *rw_buf;
-unsigned int i;
+unsigned int i, rw_buf_sec, rw_buf_cnt = 0;
 size_t size = 0;
 unsigned int *offset;
 int rc = 0;
@@ -381,7 +383,11 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 if ( elf->sec[i].sec->sh_flags & SHF_EXECINSTR )
 buf = text_buf;
 else if ( elf->sec[i].sec->sh_flags & SHF_WRITE )
+{
 buf = rw_buf;
+rw_buf_sec = i;
+rw_buf_cnt++;
+}
 else
 buf = ro_buf;
 
@@ -402,6 +408,10 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 }
 }
 
+/* No .bss and no .data, and only on RW - .livepatch.funcs section. */
+if ( rw_buf_cnt == 1 &&
+ !strcmp(elf->sec[rw_buf_sec].name, ELF_LIVEPATCH_FUNC) )
+payload->safe_to_reapply = true;
  out:
 xfree(offset);
 
@@ -1057,6 +1067,7 @@ static int revert_payload(struct payload *data)
 list_del_rcu(>applied_list);
 unregister_virtual_region(>region);
 
+data->reverted = true;
 return 0;
 }
 
@@ -1438,6 +1449,20 @@ static int 
livepatch_action(xen_sysctl_livepatch_action_t *action)
 case LIVEPATCH_ACTION_APPLY:
 if ( data->state == LIVEPATCH_STATE_CHECKED )
 {
+/*
+ * It is unsafe to apply an reverted payload as the .data (or .bss)
+ * may not be in in pristine condition. Hence MUST unload and then
+ * apply patch again. Unless the payload has no .bss or only one
+ * RW section (.livepatch.funcs).
+ */
+if ( data->reverted && !data->safe_to_reapply )
+{
+dprintk(XENLOG_ERR, "%s%s: can't revert as payload has .data. 
Please unload!\n",
+LIVEPATCH, data->name);
+data->rc = -EINVAL;
+break;
+}
+
 rc = build_id_dep(data, !!list_empty(_list));
 if ( rc )
 break;
-- 
2.5.5


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

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Lars Kurth]

On 16/09/2016 13:41, "Boris Ostrovsky"  wrote:

>On 09/16/2016 02:45 AM, Jan Beulich wrote:
>>
 And then there's the question of whether excluding things from the
 build, but having them present in the sources actually helps.
>>> The main reason for this whole relicensing debacle is to prevent
>>>non-GPL
>>> binaries from linking against GPL objects, and this patch allows us to
>>> do that. Yes, there will be be two non-LGPL files (dsdt.asl amd
>>> mk_dsdt.c, which I will revert back to GPL) in an otherwise LGPL
>>> directory but that's an in-convenience and not a license violation.
>> Well, if linking is all this is about, then it's fine of course. I'm
>>just
>> not a license expert, so we'd need this acked by someone who is
>> more familiar with the differences and implications.
>
>I think Ian and Lars (added both here) would be the most experienced in
>this matter.

It is all about linking. The terms of the GPL "spread" to derivative works
through both “dynamic” and “static” linking of binaries only. So you can
have one directory, which contains GPL and non-GPL licensed files, and not
suffer GPL-contagion as long as you can guarantee that the binaries
produced are of a specific license and you only link compatible binaries
with each other. Of course that is brittle and error prone.

> So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb
> (which is the patch from Lenovo) and it only does 2 things (assuming I
> parsed ASL correctly):
> * Adds _PIC method
As far as I can tell, only lines 30-43 of the original code remains.
Is this correct?

> * Controls and describes legacy PCI interrupt routing. This
> functionality has actually been moved into mk_dsdt.c and so this ASL
> code is now generated.


Has it been 
a) moved, 
b) re-implemented in a different language using the ASL code as template,
or 
c) implemented in C based on the ACPI spec?

Given that mk_dsdt.c is C and the original contribution is entirely ASL
(note that acpi_dsdt.c was generated from the ASL), a) does not appear to
be the case.

b) can probably not be excluded, in which case it may be safer to keep
mk_dsdt.c as GPL. But it would be a grey area.

If we knew for sure or it is plausible enough that it was c), then
mk_dsdt.c does not need to be GPL. And then the remaining Lenovo code in
dsdt.asl may be simple enough to not be copyrightable.

Whatever the answer, I would like to get Ian's opinion.
And it is still preferable though to have the entire component in LGPL and
to get a Lenovo ACK.

>I could move these two files into tools/libacpi/gpl subdirectory to
>emphasize their special licensing.

That would definitely make things easier and avoid any future mistakes
which lead to licensing issues.

Another general comment is that the component should have a COPYING file
and maybe a README.source file in the new component (that will make future
forensics easier). 

Regards
Lars

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

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

[Edgar E. Iglesias]

On Fri, Sep 16, 2016 at 04:21:12PM +0200, Julien Grall wrote:
> Hi Edgar,

Hi Julien,

Thanks for the review!

> On 07/09/2016 08:56, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias" 
> >
> >Add support for describing normal non-cacheable memory.
> >
> >Signed-off-by: Edgar E. Iglesias 
> >---
> > xen/arch/arm/p2m.c | 18 ++
> > xen/include/asm-arm/p2m.h  |  1 +
> > xen/include/asm-arm/page.h |  1 +
> > 3 files changed, 20 insertions(+)
> >
> >diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> >index b648a9d..bfef77b 100644
> >--- a/xen/arch/arm/p2m.c
> >+++ b/xen/arch/arm/p2m.c
> >@@ -282,6 +282,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
> >p2m_access_t a)
> > /* First apply type permissions */
> > switch ( t )
> > {
> >+case p2m_mem_nc:
> > case p2m_ram_rw:
> > e->p2m.xn = 0;
> > e->p2m.write = 1;
> >@@ -376,6 +377,23 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
> >p2m_access_t a)
> > e.p2m.sh = LPAE_SH_OUTER;
> > break;
> >
> >+/*
> >+ * ARM ARM: Overlaying the shareability attribute (DDI
> >+ * 0406C.b B3-1376 to 1377)
> >+ *
> >+ * A memory region with a resultant memory type attribute of Normal,
> >+ * and a resultant cacheability attribute of Inner Non-cacheable,
> >+ * Outer Non-cacheable, must have a resultant shareability attribute
> >+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
> >+ *
> >+ * On ARMv8 sharability is ignored and explicitly treated as Outer
> 
> I know you copied it from mfn_to_xen_entry, but can we fixed the copy with:
> 
> s/sharability/shareability/

Fixed for v4.

> 
> >+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.
> 
> s/_/-/
> 
> Also I would like to see a spec reference for the ARMv8. I think it is the
> note in D4-1788 ARM DDI 0487A.j.

Fixed for v4.

> 
> >+ */
> >+case p2m_mem_nc:
> >+e.p2m.mattr = MATTR_MEM_NC;
> >+e.p2m.sh = LPAE_SH_OUTER;
> >+break;
> >+
> > default:
> > e.p2m.mattr = MATTR_MEM;
> > e.p2m.sh = LPAE_SH_INNER;
> >diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> >index 53c4d78..b012d50 100644
> >--- a/xen/include/asm-arm/p2m.h
> >+++ b/xen/include/asm-arm/p2m.h
> >@@ -93,6 +93,7 @@ typedef enum {
> > p2m_ram_ro, /* Read-only; writes are silently dropped */
> > p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
> > non-cacheable */
> > p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area 
> > cacheable */
> >+p2m_mem_nc, /* Read/write mapping of Non-cacheable Memory */
> 
> I find the name a bit confusing. Technically p2m_mem_nc is p2m_mmio_direct_c
> version but non-cacheable.
> 
> I have got the feeling that the naming I used on a recent patch is not
> correct. Because p2m_mmio_direct_nc is not doing what is expect (i.e mapping
> non-cacheable). It maps with the device memory attribute.
> 
> Maybe we should rename p2m_mmio_direct_nc to p2m_mmio_direct_dev (because it
> will use the device memory attribute) and then use p2m_mmio_direct_nc for
> your purpose.
> 
> Any opinions?

Sounds good, I'll do that.
To keep the patches more readable, I thought i'd first do the rename in
a first patch without any functional changes. Then I'll follow up with
re-adding the p2m_mmio_direct_nc for my purposes. Let me know if you prefer
something different.

Thanks,
Edgar


> 
> 
> > p2m_map_foreign,/* Ram pages from foreign domain */
> > p2m_grant_map_rw,   /* Read/write grant mapping */
> > p2m_grant_map_ro,   /* Read-only grant mapping */
> >diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> >index 05d9f82..9adc973 100644
> >--- a/xen/include/asm-arm/page.h
> >+++ b/xen/include/asm-arm/page.h
> >@@ -73,6 +73,7 @@
> >  *
> >  */
> > #define MATTR_DEV 0x1
> >+#define MATTR_MEM_NC  0x5
> > #define MATTR_MEM 0xf
> >
> > /* Flags for get_page_from_gva, gvirt_to_maddr etc */
> >
> 
> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH RFC 5/6] xen/arm: Add function to query IRQ 'ownership'.

[Konrad Rzeszutek Wilk]

On Mon, Sep 05, 2016 at 06:14:00AM -0400, Kyle Temkin wrote:
> From: "Kyle J. Temkin" 
> 
> The addition of new IRQ-related platform hooks now allow platforms to
> perform platform-specific interrupt logic; allowing e.g. virtualization
> of platform-specific interrupt controller hardware.
> 
> This commit adds the ability to for the platform to identify the domain
> a given IRQ routes to, allowing platform logic to e.g. deny access to
> registers associated with a given IRQ unless the requesting domain
> 'owns' the IRQ. This will be used on Tegra platforms, where the hardware
> domain needs access to its legacy interrupt controller, but should not
> be able to control registers that correspond to other domains' IRQs, or
> sections associated with IRQs routed to Xen.
> 
> Signed-off-by: Kyle Temkin 
> ---
>  xen/arch/arm/irq.c| 10 ++
>  xen/include/asm-arm/irq.h |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index dc42817..c6e1a24 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -144,6 +144,16 @@ static inline struct domain *irq_get_domain(struct 
> irq_desc *desc)
>  return irq_get_guest_info(desc)->d;
>  }
>  
> +domid_t irq_get_domain_id(struct irq_desc *desc)
> +{
> +// If this domain isn't routed to a guest, return DOMID_XEN.

So that is some odd style
> +if(!test_bit(_IRQ_GUEST, >status))

Ditto here?

I think your v1 should have at least these fixed..

> +return DOMID_XEN;
> +
> +// Otherise, get the guest domain's information.
> +return irq_get_domain(desc)->domain_id;
> +}
> +
>  void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask)
>  {
>  if ( desc != NULL )
> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
> index 8f7a167..55300a8 100644
> --- a/xen/include/asm-arm/irq.h
> +++ b/xen/include/asm-arm/irq.h
> @@ -45,6 +45,8 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
> unsigned int irq, const char *devname);
>  int release_guest_irq(struct domain *d, unsigned int irq);
>  
> +domid_t irq_get_domain_id(struct irq_desc *desc);
> +
>  void arch_move_irqs(struct vcpu *v);
>  
>  #define arch_evtchn_bind_pirq(d, pirq) ((void)((d) + (pirq)))
> -- 
> 2.9.2
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH RFC 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing.

[Konrad Rzeszutek Wilk]

On Mon, Sep 05, 2016 at 06:13:59AM -0400, Kyle Temkin wrote:
> From: "Kyle J. Temkin" 
> 
> Tegra devices have a legacy interrupt controller (lic, or ictlr) that
> must be programmed in parallel with their primary GIC. For all intents
> and purposes, we treat this devices attached to this controller as
> connected to the primary GIC, as it will be handling their interrupts.

Is there a link to the specification? Could that be included in the file
or in the commit description?

> 
> This commit adds support for exposing the ictlr to the hardware domain;
> but a future commit will extend this to support exposing a virtualized
> version of the ictlr to the hardware domain, and to ensure that
> interrupts are unmasked properly when routed to a Xen, or to a domain
> other than the hardware domain.
> 
> Signed-off-by: Kyle Temkin 
> ---
>  xen/arch/arm/platforms/Makefile   |   2 +
>  xen/arch/arm/platforms/tegra.c| 339 
> ++
>  xen/include/asm-arm/platforms/tegra.h |  50 +
>  3 files changed, 391 insertions(+)
>  create mode 100644 xen/arch/arm/platforms/tegra.c
>  create mode 100644 xen/include/asm-arm/platforms/tegra.h
> 
> diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
> index 49fa683..0c3a7f4 100644
> --- a/xen/arch/arm/platforms/Makefile
> +++ b/xen/arch/arm/platforms/Makefile
> @@ -4,7 +4,9 @@ obj-$(CONFIG_ARM_32) += exynos5.o
>  obj-$(CONFIG_ARM_32) += midway.o
>  obj-$(CONFIG_ARM_32) += omap5.o
>  obj-$(CONFIG_ARM_32) += rcar2.o
> +obj-$(CONFIG_ARM_32) += tegra.o
>  obj-$(CONFIG_ARM_64) += seattle.o
>  obj-$(CONFIG_ARM_32) += sunxi.o
>  obj-$(CONFIG_ARM_64) += xgene-storm.o
>  obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
> +obj-$(CONFIG_ARM_64) += tegra.o
> diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
> new file mode 100644
> index 000..e75242c
> --- /dev/null
> +++ b/xen/arch/arm/platforms/tegra.c
> @@ -0,0 +1,339 @@
> +/*
> + * NVIDIA Tegra specific settings
> + *
> + * Ian Campbell; Copyright (c) 2014 Citrix Systems
> + * Kyle Temkin; Copyright (c) 2016 Assured Information Security, Inc.
> + * Chris Patterson; Copyright (c) 2016 Assured Information Security, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 

No config.h pls.
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +/* Permanent mapping to the Tegra legacy interrupt controller. */
> +static void __iomem *tegra_ictlr_base = NULL;

No need for NULL.
> +
> +/*
> + * List of legacy interrupt controllers that can be used to route
> + * Tegra interrupts.
> + */
> +static const char * const tegra_interrupt_compat[] __initconst =
> +{
> +"nvidia,tegra120-ictlr",  /* Tegra K1 controllers */
> +"nvidia,tegra210-ictlr"   /* Tegra X1 controllers */
> +};
> +
> +
> +/**
> + * Returns true if the given IRQ belongs to a supported tegra interrupt
> + * controller.
> + *
> + * @param rirq The raw IRQ to be identified.
> + * @return True iff the given IRQ belongs to a Tegra ictlr.
> + */
> +static bool_t tegra_irq_belongs_to_ictlr(struct dt_raw_irq * rirq)  {
> +int i;
> +
> +for (i = 0; i < ARRAY_SIZE(tegra_interrupt_compat); i++)

Something is off with your style ({, and the lack of spaces around ()).

> +{
> +if ( dt_device_is_compatible(rirq->controller, 
> tegra_interrupt_compat[i]) )
> +return true;
> +}
> +
> +return false;
> +}
> +
> +
> +/**
> + * Returns true iff the given IRQ is routable -- that is, if it is descended
> + * from the platform's primary GIC.
> + *
> + * @param rirq The raw IRQ in question.
> + * @return True iff the given IRQ routes to a platform GIC.
> + */
> +static bool_t tegra_irq_is_routable(struct dt_raw_irq * rirq)

And as I found out just recently, use 'bool' instead of bool_t.

> +{
> +/* If the IRQ connects directly to our GIC, it's trivially routable. */
> +if ( rirq->controller == dt_interrupt_controller )
> +return true;
> +
> +/*
> + * If the IRQ belongs to a legacy interrupt controller, then it's
> + * effectively owned by the GIC, and is routable.
> + */
> +if ( tegra_irq_belongs_to_ictlr(rirq) )
> +return true;
> +
> +return false;
> +}
> +
> +/**
> + * Returns the IRQ number for a given device. Tegra IRQs transalate using the
> + * same algorithm as normal GIC IRQs, but aren't parented by the system 

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

[Julien Grall]

On 16/09/2016 16:35, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 16, 2016 at 03:45:12PM +0200, Julien Grall wrote:



On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:

Hi Konrad,

On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:

v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
 - Addressed the two outstanding concerns: CPU bit feature to test alternative
   test-case, and errata #843419 on some Cortex-A53


I am a bit confused. I haven't spotted any specific code for this. How did
you handle it?


livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH


AFAICT, this only handles this first part (CPU bit feature) not the errata
#843419. Did I miss anything?


My recollection is (from
Date: Wed, 31 Aug 2016 15:49:55 +0100
From: Julien Grall 
To: Konrad Rzeszutek Wilk , 
xen-de...@lists.xenproject.org, kon...@kernel.org, ross.lagerw...@citrix.com,
sstabell...@kernel.org, Andrew Cooper 
Subject: Re: [PATCH v2] Livepatch for ARM 64 and 32.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 
Thunderbird/45.2.0
"

">  -  #13 "livepatch: Initial ARM64 support."

Need to look in erratum #843419 on some Cortex-A53 and figuring
out how to avoid payloads having R_AARCH64_ADR_PREL_PG_HI21 relocations.


I will not considered this has a blocker for this series. Having livepatching
on all the other boards for Xen 4.8 would still be awesome :).
"

So I moved it off to 4.9 list.


Oh, I understood "Addressed the two outstanding concerns" as "It was 
fixed in the code". Maybe I was expecting too much to shrink down my 
todo list ^^.



--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

[Konrad Rzeszutek Wilk]

On Fri, Sep 16, 2016 at 03:45:12PM +0200, Julien Grall wrote:
> 
> 
> On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:
> > > Hi Konrad,
> > > 
> > > On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
> > > > v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
> > > >  - Addressed the two outstanding concerns: CPU bit feature to test 
> > > > alternative
> > > >test-case, and errata #843419 on some Cortex-A53
> > > 
> > > I am a bit confused. I haven't spotted any specific code for this. How did
> > > you handle it?
> > 
> > livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH
> 
> AFAICT, this only handles this first part (CPU bit feature) not the errata
> #843419. Did I miss anything?

My recollection is (from 
Date: Wed, 31 Aug 2016 15:49:55 +0100
From: Julien Grall 
To: Konrad Rzeszutek Wilk , 
xen-de...@lists.xenproject.org, kon...@kernel.org, ross.lagerw...@citrix.com,
sstabell...@kernel.org, Andrew Cooper 
Subject: Re: [PATCH v2] Livepatch for ARM 64 and 32.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 
Thunderbird/45.2.0
"

">  -  #13 "livepatch: Initial ARM64 support."
> Need to look in erratum #843419 on some Cortex-A53 and figuring
> out how to avoid payloads having R_AARCH64_ADR_PREL_PG_HI21 relocations.

I will not considered this has a blocker for this series. Having livepatching
on all the other boards for Xen 4.8 would still be awesome :).
"

So I moved it off to 4.9 list.

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

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

[Julien Grall]

Hi Edgar,

On 07/09/2016 08:56, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Add support for describing normal non-cacheable memory.


I am a bit confused, you introduced this new p2m type but I don't see 
any usage of it in this series. Is it expected?


Regards,



Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/p2m.c | 18 ++
 xen/include/asm-arm/p2m.h  |  1 +
 xen/include/asm-arm/page.h |  1 +
 3 files changed, 20 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b648a9d..bfef77b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -282,6 +282,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
 /* First apply type permissions */
 switch ( t )
 {
+case p2m_mem_nc:
 case p2m_ram_rw:
 e->p2m.xn = 0;
 e->p2m.write = 1;
@@ -376,6 +377,23 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
p2m_access_t a)
 e.p2m.sh = LPAE_SH_OUTER;
 break;

+/*
+ * ARM ARM: Overlaying the shareability attribute (DDI
+ * 0406C.b B3-1376 to 1377)
+ *
+ * A memory region with a resultant memory type attribute of Normal,
+ * and a resultant cacheability attribute of Inner Non-cacheable,
+ * Outer Non-cacheable, must have a resultant shareability attribute
+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
+ *
+ * On ARMv8 sharability is ignored and explicitly treated as Outer
+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.
+ */
+case p2m_mem_nc:
+e.p2m.mattr = MATTR_MEM_NC;
+e.p2m.sh = LPAE_SH_OUTER;
+break;
+
 default:
 e.p2m.mattr = MATTR_MEM;
 e.p2m.sh = LPAE_SH_INNER;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 53c4d78..b012d50 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -93,6 +93,7 @@ typedef enum {
 p2m_ram_ro, /* Read-only; writes are silently dropped */
 p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
non-cacheable */
 p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
+p2m_mem_nc, /* Read/write mapping of Non-cacheable Memory */
 p2m_map_foreign,/* Ram pages from foreign domain */
 p2m_grant_map_rw,   /* Read/write grant mapping */
 p2m_grant_map_ro,   /* Read-only grant mapping */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 05d9f82..9adc973 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -73,6 +73,7 @@
  *
  */
 #define MATTR_DEV 0x1
+#define MATTR_MEM_NC  0x5
 #define MATTR_MEM 0xf

 /* Flags for get_page_from_gva, gvirt_to_maddr etc */



--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 5/6] xen/arm: domain_build: Plumb for different mapping attributes

[Julien Grall]

Hi Edgar,

On 07/09/2016 08:56, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Add plumbing for passing around mapping attributes. This
is in preparation to allow us to differentiate the attributes
for specific device nodes.

We still use the same DEVICE mappings for all nodes so this
patch has no functional change.


I would mention somewhere (commit message, code) that unless stated, the 
children nodes inherit of the p2m type of the parent.


With that:

Acked-by: Julien Grall 

Regards,



Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c | 42 +-
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f022342..bbe4895 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -42,6 +42,12 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);

+struct map_range_data
+{
+struct domain *d;
+p2m_type_t p2mt;
+};
+
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -974,7 +980,8 @@ static int map_range_to_domain(const struct dt_device_node 
*dev,
u64 addr, u64 len,
void *data)
 {
-struct domain *d = data;
+struct map_range_data *mr_data = data;
+struct domain *d = mr_data->d;
 bool_t need_mapping = !dt_device_for_passthrough(dev);
 int res;

@@ -991,10 +998,12 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,

 if ( need_mapping )
 {
-res = map_mmio_regions(d,
+res = map_regions_p2mt(d,
_gfn(paddr_to_pfn(addr)),
DIV_ROUND_UP(len, PAGE_SIZE),
-   _mfn(paddr_to_pfn(addr)));
+   _mfn(paddr_to_pfn(addr)),
+   mr_data->p2mt);
+
 if ( res < 0 )
 {
 printk(XENLOG_ERR "Unable to map 0x%"PRIx64
@@ -1005,7 +1014,8 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
 }
 }

-dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64"\n", addr, addr + len);
+dt_dprintk("  - MMIO: %010"PRIx64" - %010"PRIx64" P2MType=%x\n",
+   addr, addr + len, mr_data->p2mt);

 return 0;
 }
@@ -1016,8 +1026,10 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
  * the child resources available to domain 0.
  */
 static int map_device_children(struct domain *d,
-   const struct dt_device_node *dev)
+   const struct dt_device_node *dev,
+   p2m_type_t p2mt)
 {
+struct map_range_data mr_data = { .d = d, .p2mt = p2mt };
 int ret;

 if ( dt_device_type_is_equal(dev, "pci") )
@@ -1029,7 +1041,7 @@ static int map_device_children(struct domain *d,
 if ( ret < 0 )
 return ret;

-ret = dt_for_each_range(dev, _range_to_domain, d);
+ret = dt_for_each_range(dev, _range_to_domain, _data);
 if ( ret < 0 )
 return ret;
 }
@@ -1045,7 +1057,8 @@ static int map_device_children(struct domain *d,
  *  - Assign the device to the guest if it's protected by an IOMMU
  *  - Map the IRQs and iomem regions to DOM0
  */
-static int handle_device(struct domain *d, struct dt_device_node *dev)
+static int handle_device(struct domain *d, struct dt_device_node *dev,
+ p2m_type_t p2mt)
 {
 unsigned int nirq;
 unsigned int naddr;
@@ -,6 +1124,7 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 /* Give permission and map MMIOs */
 for ( i = 0; i < naddr; i++ )
 {
+struct map_range_data mr_data = { .d = d, .p2mt = p2mt };
 res = dt_device_get_address(dev, i, , );
 if ( res )
 {
@@ -1119,12 +1133,12 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 return res;
 }

-res = map_range_to_domain(dev, addr, size, d);
+res = map_range_to_domain(dev, addr, size, _data);
 if ( res )
 return res;
 }

-res = map_device_children(d, dev);
+res = map_device_children(d, dev, p2mt);
 if ( res )
 return res;

@@ -1132,7 +1146,8 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 }

 static int handle_node(struct domain *d, struct kernel_info *kinfo,
-   struct dt_device_node *node)
+   struct dt_device_node *node,
+   p2m_type_t p2mt)
 {
 static const struct dt_device_match skip_matches[] __initconst =
 {
@@ -1219,7 +1234,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
"WARNING: Path 

Re: [Xen-devel] [PATCH v3 4/6] xen/device-tree: Make dt_match_node match props

[Julien Grall]

Hi Edgar,

On 07/09/2016 08:56, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Make dt_match_node match for existing properties.
We only search for the existence of the properties, not
for specific values.

Signed-off-by: Edgar E. Iglesias 
---
 xen/common/device_tree.c  | 5 -
 xen/include/xen/device_tree.h | 7 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index b39c8ca..1be074b 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -319,7 +319,7 @@ dt_match_node(const struct dt_device_match *matches,
 return NULL;

 while ( matches->path || matches->type ||
-matches->compatible || matches->not_available )
+matches->compatible || matches->not_available || matches->prop)
 {
 bool_t match = 1;

@@ -335,6 +335,9 @@ dt_match_node(const struct dt_device_match *matches,
 if ( matches->not_available )
 match &= !dt_device_is_available(node);

+if ( matches->prop )
+match &= dt_find_property(node, matches->prop, NULL) != NULL;
+
 if ( match )
 return matches;
 matches++;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index da153a5..c71ddb9 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -29,6 +29,11 @@ struct dt_device_match {
 const char *type;
 const char *compatible;
 const bool_t not_available;
+/*
+ * Property name to search for. We only search for the properties


NIT: s/the properties/the property/ I think same.
I think this also apply for the commit message?

The rest of the patch looks good to me:

Acked-by: Julien Grall 

Regards,


+ * existence.
+ */
+const char *prop;
 const void *data;
 };

@@ -36,11 +41,13 @@ struct dt_device_match {
 #define __DT_MATCH_TYPE(typ).type = typ
 #define __DT_MATCH_COMPATIBLE(compat)   .compatible = compat
 #define __DT_MATCH_NOT_AVAILABLE()  .not_available = 1
+#define __DT_MATCH_PROP(p)  .prop = p

 #define DT_MATCH_PATH(p){ __DT_MATCH_PATH(p) }
 #define DT_MATCH_TYPE(typ)  { __DT_MATCH_TYPE(typ) }
 #define DT_MATCH_COMPATIBLE(compat) { __DT_MATCH_COMPATIBLE(compat) }
 #define DT_MATCH_NOT_AVAILABLE(){ __DT_MATCH_NOT_AVAILABLE() }
+#define DT_MATCH_PROP(p){ __DT_MATCH_PROP(p) }

 typedef u32 dt_phandle;




--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/6] xen/arm: Rename and generalize un/map_regions_rw_cache

[Julien Grall]

Hi Edgar,

On 07/09/2016 08:56, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Rename and generalize un/map_regions_rw_cache into
un/map_regions_p2mt. The new functions take the mapping
attributes as an argument.

No functional change.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c | 18 ++
 xen/arch/arm/p2m.c  | 19 ++-
 xen/include/asm-arm/p2m.h   | 19 ++-
 3 files changed, 30 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..f022342 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1518,10 +1518,11 @@ static void acpi_map_other_tables(struct domain *d)
 {
 addr = acpi_gbl_root_table_list.tables[i].address;
 size = acpi_gbl_root_table_list.tables[i].length;
-res = map_regions_rw_cache(d,
-   _gfn(paddr_to_pfn(addr)),
-   DIV_ROUND_UP(size, PAGE_SIZE),
-   _mfn(paddr_to_pfn(addr)));
+res = map_regions_p2mt(d,
+   _gfn(paddr_to_pfn(addr)),
+   DIV_ROUND_UP(size, PAGE_SIZE),
+   _mfn(paddr_to_pfn(addr)),
+   p2m_mmio_direct_c);
 if ( res )
 {
  panic(XENLOG_ERR "Unable to map ACPI region 0x%"PRIx64
@@ -1874,10 +1875,11 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 acpi_create_efi_mmap_table(d, >mem, tbl_add);

 /* Map the EFI and ACPI tables to Dom0 */
-rc = map_regions_rw_cache(d,
-  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
-  PFN_UP(d->arch.efi_acpi_len),
-  
_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table;
+rc = map_regions_p2mt(d,
+  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
+  PFN_UP(d->arch.efi_acpi_len),
+  
_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table))),
+  p2m_mmio_direct_c);
 if ( rc != 0 )
 {
 printk(XENLOG_ERR "Unable to map EFI/ACPI table 0x%"PRIx64
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index bfef77b..58d4940 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1234,18 +1234,19 @@ static inline int p2m_remove_mapping(struct domain *d,
  0, p2m_invalid, d->arch.p2m.default_access);
 }

-int map_regions_rw_cache(struct domain *d,
- gfn_t gfn,
- unsigned long nr,
- mfn_t mfn)
+int map_regions_p2mt(struct domain *d,
+ gfn_t gfn,
+ unsigned long nr,
+ mfn_t mfn,
+ p2m_type_t p2mt)
 {
-return p2m_insert_mapping(d, gfn, nr, mfn, p2m_mmio_direct_c);
+return p2m_insert_mapping(d, gfn, nr, mfn, p2mt);
 }

-int unmap_regions_rw_cache(struct domain *d,
-   gfn_t gfn,
-   unsigned long nr,
-   mfn_t mfn)
+int unmap_regions_p2mt(struct domain *d,
+   gfn_t gfn,
+   unsigned long nr,
+   mfn_t mfn)
 {
 return p2m_remove_mapping(d, gfn, nr, mfn);
 }
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index b012d50..f2bd16c 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -166,15 +166,16 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t 
*t);
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);

-int map_regions_rw_cache(struct domain *d,
- gfn_t gfn,
- unsigned long nr,
- mfn_t mfn);
-
-int unmap_regions_rw_cache(struct domain *d,
-   gfn_t gfn,
-   unsigned long nr,
-   mfn_t mfn);
+int map_regions_p2mt(struct domain *d,
+ gfn_t gfn,
+ unsigned long nr,
+ mfn_t mfn,
+ p2m_type_t p2mt);


Can you document the purpose of this function in the code? Something 
like: "Map the region in the guest p2m with a specific type (will affect 
the attributes of the region).".



+
+int unmap_regions_p2mt(struct domain *d,
+   gfn_t gfn,
+   unsigned long nr,
+   mfn_t mfn);

 int map_dev_mmio_region(struct domain *d,
 gfn_t gfn,



Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: p2m: Add support for normal non-cacheable memory

[Julien Grall]

Hi Edgar,

On 07/09/2016 08:56, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

Add support for describing normal non-cacheable memory.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/p2m.c | 18 ++
 xen/include/asm-arm/p2m.h  |  1 +
 xen/include/asm-arm/page.h |  1 +
 3 files changed, 20 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b648a9d..bfef77b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -282,6 +282,7 @@ static void p2m_set_permission(lpae_t *e, p2m_type_t t, 
p2m_access_t a)
 /* First apply type permissions */
 switch ( t )
 {
+case p2m_mem_nc:
 case p2m_ram_rw:
 e->p2m.xn = 0;
 e->p2m.write = 1;
@@ -376,6 +377,23 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
p2m_access_t a)
 e.p2m.sh = LPAE_SH_OUTER;
 break;

+/*
+ * ARM ARM: Overlaying the shareability attribute (DDI
+ * 0406C.b B3-1376 to 1377)
+ *
+ * A memory region with a resultant memory type attribute of Normal,
+ * and a resultant cacheability attribute of Inner Non-cacheable,
+ * Outer Non-cacheable, must have a resultant shareability attribute
+ * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
+ *
+ * On ARMv8 sharability is ignored and explicitly treated as Outer


I know you copied it from mfn_to_xen_entry, but can we fixed the copy with:

s/sharability/shareability/


+ * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.


s/_/-/

Also I would like to see a spec reference for the ARMv8. I think it is 
the note in D4-1788 ARM DDI 0487A.j.



+ */
+case p2m_mem_nc:
+e.p2m.mattr = MATTR_MEM_NC;
+e.p2m.sh = LPAE_SH_OUTER;
+break;
+
 default:
 e.p2m.mattr = MATTR_MEM;
 e.p2m.sh = LPAE_SH_INNER;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 53c4d78..b012d50 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -93,6 +93,7 @@ typedef enum {
 p2m_ram_ro, /* Read-only; writes are silently dropped */
 p2m_mmio_direct_nc, /* Read/write mapping of genuine MMIO area 
non-cacheable */
 p2m_mmio_direct_c,  /* Read/write mapping of genuine MMIO area cacheable */
+p2m_mem_nc, /* Read/write mapping of Non-cacheable Memory */


I find the name a bit confusing. Technically p2m_mem_nc is 
p2m_mmio_direct_c version but non-cacheable.


I have got the feeling that the naming I used on a recent patch is not 
correct. Because p2m_mmio_direct_nc is not doing what is expect (i.e 
mapping non-cacheable). It maps with the device memory attribute.


Maybe we should rename p2m_mmio_direct_nc to p2m_mmio_direct_dev 
(because it will use the device memory attribute) and then use 
p2m_mmio_direct_nc for your purpose.


Any opinions?



 p2m_map_foreign,/* Ram pages from foreign domain */
 p2m_grant_map_rw,   /* Read/write grant mapping */
 p2m_grant_map_ro,   /* Read-only grant mapping */
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 05d9f82..9adc973 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -73,6 +73,7 @@
  *
  */
 #define MATTR_DEV 0x1
+#define MATTR_MEM_NC  0x5
 #define MATTR_MEM 0xf

 /* Flags for get_page_from_gva, gvirt_to_maddr etc */



Regards,

--
Julien Grall

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

[Xen-devel] [qemu-mainline test] 100984: regressions - FAIL

[osstest service owner]

flight 100984 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100984/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   5 xen-buildfail REGR. vs. 100966
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 100975 REGR. 
vs. 100966

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  11 guest-startfail pass in 100975
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 100975

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install  fail in 100975 like 100966
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100966
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100966

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 100975 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 100975 never 
pass
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 100975 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 100975 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 100975 never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 100975 never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuu5f473241ac595452ae0638dc63e7af2a2294f5ec
baseline version:
 qemuu8212ff86f4405b6128d89dd1d97ff2d6cfcf9842

Last test of basis   100966  2016-09-15 10:45:30 Z1 days
Failing since100971  2016-09-15 17:22:22 Z0 days3 attempts
Testing same since   100975  2016-09-16 00:25:23 Z0 days2 attempts


People who touched revisions under test:
  Andrew Dutcher 
  Ashijeet Acharya 
  Aurelien Jarno 
  Cao jin 
  

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

[Julien Grall]

Hi Tamas,

On 15/09/2016 20:24, Tamas K Lengyel wrote:

The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.

The intended use-case for this feature is for a monitor application to be able
insert tap-points into the domU kernel-code. For this task only unconditional
SMC instruction should be used.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Razvan Cojocaru 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v3: Rebase on latest master

Note: previous discussion around this patch proposed filtering SMCs with failed
  condition checks. As that patch is yet-to-be implemented and the 4.8
  code-freeze rapidly approaching I would like this patch to get included.


It is still in my todo list. But as I said last time, it is towards the 
bottom of it. I would have expected a bit of help from your side here 
rather than putting the fault on me.



  In this patch a proper warning is placed in the public header for
  potential users not to rely on SMCs with failed condition checks being
  trapped. As the intended use-case for this feature doesn't use
  conditional SMCs this warning should be sufficient. Hardware that does
  issue events for SMCs with failed condition checks doesn't pose a problem
  for a monitor application in any way. The xen-access test tool illustrates
  how SMCs issued by the guest can be safely handled for all cases.


This is nice, but how about passing the immediate to the event monitor? 
The SMC call is not meant to be a breakpoint instruction but a way to 
call the supervisor monitor (and potentially be emulated by the hypervisor).



---
 tools/libxc/include/xenctrl.h   |  2 +
 tools/libxc/xc_monitor.c| 14 +++
 tools/tests/xen-access/xen-access.c | 32 ++-
 xen/arch/arm/Makefile   |  1 +
 xen/arch/arm/monitor.c  | 79 +
 xen/arch/arm/traps.c| 15 ++-
 xen/include/asm-arm/domain.h|  5 +++
 xen/include/asm-arm/monitor.h   | 18 +++--
 xen/include/public/domctl.h |  1 +
 xen/include/public/vm_event.h   |  7 
 10 files changed, 158 insertions(+), 16 deletions(-)
 create mode 100644 xen/arch/arm/monitor.c

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 560ce7b..eb53172 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2168,6 +2168,8 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id,
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 4298813..15a7c32 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -185,6 +185,20 @@ int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, 
bool enable)
 return do_domctl(xch, );
 }

+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index ed18c71..6eefe0c 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -338,6 +338,8 @@ void usage(char* progname)
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
 fprintf(stderr, 
"|breakpoint|altp2m_write|altp2m_exec|debug|cpuid");
+#elif defined(__arm__) || defined(__aarch64__)
+fprintf(stderr, "|privcall");
 #endif
 fprintf(stderr,
 "\n"
@@ -362,6 +364,7 @@ int main(int argc, char *argv[])
 int required = 0;
 int breakpoint = 0;
 int shutting_down = 0;
+int privcall = 0;
 int altp2m = 0;
 int debug = 0;
 int cpuid = 0;
@@ -431,6 +434,11 @@ int main(int argc, char *argv[])
 {
 cpuid = 1;
 }
+#elif defined(__arm__) 

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

[Julien Grall]

On 16/09/2016 15:41, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:

Hi Konrad,

On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:

v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
 - Addressed the two outstanding concerns: CPU bit feature to test alternative
   test-case, and errata #843419 on some Cortex-A53


I am a bit confused. I haven't spotted any specific code for this. How did
you handle it?


livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH


AFAICT, this only handles this first part (CPU bit feature) not the 
errata #843419. Did I miss anything?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

[Konrad Rzeszutek Wilk]

On Fri, Sep 16, 2016 at 03:35:21PM +0200, Julien Grall wrote:
> Hi Konrad,
> 
> On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:
> > v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
> >  - Addressed the two outstanding concerns: CPU bit feature to test 
> > alternative
> >test-case, and errata #843419 on some Cortex-A53
> 
> I am a bit confused. I haven't spotted any specific code for this. How did
> you handle it?

livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH

?

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

Re: [Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

[Julien Grall]

Hi Konrad,

On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:

v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
 - Addressed the two outstanding concerns: CPU bit feature to test alternative
   test-case, and errata #843419 on some Cortex-A53


I am a bit confused. I haven't spotted any specific code for this. How 
did you handle it?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 05/18] arm: poison initmem when it is freed.

[Julien Grall]

Hi Konrad,

On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:

The current byte sequence is '0xcc' which makes sense on x86,
but on ARM it is:

stclgt  12, cr12, [ip], {204}   ; 0xcc

Picking something more ARM applicable such as:

efefefefsvc 0x00efefef


Whilst I agree it is much better to get a trap rather than executing a 
random instruction (though co-processor 12 is reserved and a trap should 
(?) occur), I see two problems with this choice.


Firstly, it might be possible that in the future we decide to use svc in 
the hypervisor (it is dumb but valid use case).


Secondly, AArch64 is using a different set (and therefore encoding). So 
far this encoding is not allocated, but it is not rule out that this 
encoding will not be used in the future.


So I would suggest to point initmem with:
- AArch32: udf instruction i.e 0xe7f000f0 (see A8.8.247 in ARM DDI 
0406C.c)
- AArch64: a break point (possibly the encoding AARCH64_BREAK_FAULT 
(see asm-arm/arm64/brk.h).


What do you think?



Creates a nice crash if one executes that code:
(XEN) CPU1: Unexpected Trap: Supervisor Call

We don't have to worry about Thumb code so this instruction
is a safe to execute.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
---
 xen/arch/arm/mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 07e2037..0fa5623 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -995,7 +995,7 @@ void free_init_memory(void)
 paddr_t pa = virt_to_maddr(__init_begin);
 unsigned long len = __init_end - __init_begin;
 set_pte_flags_on_range(__init_begin, len, mg_rw);
-memset(__init_begin, 0xcc, len);
+memset(__init_begin, 0xef, len);


Regardless the final decision, I think we should document the meaning of 
the value in the code.



 set_pte_flags_on_range(__init_begin, len, mg_clear);
 init_domheap_pages(pa, pa + len);
 printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);



Regards,

--
Julien Grall

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

[Xen-devel] [distros-debian-jessie test] 67722: tolerable FAIL

[Platform Team regression test user]

flight 67722 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67722/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-jessie-netboot-pvgrub 10 guest-startfail like 67680

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   67680

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub fail
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


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

Re: [Xen-devel] [PATCH v3 03/18] arm/x86: change [modify, destroy]_xen_mappings to return error

[Julien Grall]

Hi Konrad,

On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:

The implementation on x86 always returns zero, but
other platforms may return error values.

Reviewed-by: Andrew Cooper 
Suggested-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 


For the ARM bits:

Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

[Xen-devel] First set of Xen Project Developer Summit Videos are available

[Lars Kurth]

Hi all,

the first batch of Xen Project Developer Summit Videos are available. There are 
a few videos missing, which have some issues that still need to be fixed, but 
that shouldn't take too long. You can see what is uploaded and available t 
https://www.youtube.com/playlist?list=PLYyw7IQjL-zEcw-9M5YWzAwXj9mlOKZnU 

Further videos will be published either later today or on Monday

Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 02/18] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in.

[Julien Grall]

Hi Konrad,

On 11/09/2016 22:35, Konrad Rzeszutek Wilk wrote:

If the payload had the sections mentioned but the hypervisor
did not support some of them (say on ARM the .ex_table) - instead
of ignoring them - it should forbid loading of such payload.

Signed-off-by: Konrad Rzeszutek Wilk 



FWIW:

Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable test] 100982: tolerable FAIL

[osstest service owner]

flight 100982 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100982/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail in 100973 pass in 100982
 test-armhf-armhf-xl-vhd   9 debian-di-install  fail pass in 100973

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeatfail  like 100970
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100973
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100973
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100973
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100973
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100973

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd 11 migrate-support-check fail in 100973 never pass
 test-armhf-armhf-xl-vhd 12 saverestore-support-check fail in 100973 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8
baseline version:
 xen  115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8

Last test of basis   100982  2016-09-16 06:18:50 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17060 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

On 09/16/2016 02:45 AM, Jan Beulich wrote:
>
>>> And then there's the question of whether excluding things from the
>>> build, but having them present in the sources actually helps.
>> The main reason for this whole relicensing debacle is to prevent non-GPL
>> binaries from linking against GPL objects, and this patch allows us to
>> do that. Yes, there will be be two non-LGPL files (dsdt.asl amd
>> mk_dsdt.c, which I will revert back to GPL) in an otherwise LGPL
>> directory but that's an in-convenience and not a license violation.
> Well, if linking is all this is about, then it's fine of course. I'm just
> not a license expert, so we'd need this acked by someone who is
> more familiar with the differences and implications.


I think Ian and Lars (added both here) would be the most experienced in
this matter.

I could move these two files into tools/libacpi/gpl subdirectory to
emphasize their special licensing.

-boris


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

Re: [Xen-devel] [PATCH V3] xen/arm: arm64: Update the Image header

[Julien Grall]

Hello Peng,

On 12/09/2016 11:43, Peng Fan wrote:

According to Linux Kernel, Documentation/arm64/booting.txt
"
When image_size is zero, a bootloader should attempt to keep as much
memory as possible free for use by the kernel immediately after the
end of the kernel image. The amount of space required will vary
depending on selected features, and is effectively unbound.
"
This will consumes some memory and time, for example,
When booting xen from U-Boot, U-Boot will use the image size
info. Because this information is lacked in XEN image,U-Boot
assume the image size is 16MB to memmove, which will cost lots
time on simulation platform.

The flags field is also filled with value 0xA,
Bit3(physical placement):   1
Bit2-1(Page size):  1
Bit0(endianness):   0


Please explain in the commit message why those values and, for instance, 
not 0 for Bit3.




Signed-off-by: Peng Fan 
Cc: Julien Grall 
Cc: Stefano Stabellini 
---

V3:
 Drop the image.h macros.h from Linux, included in V2.
 Only update image size and flags entry. offset was kept 0 as before.
 Only little endian supported.

V2:
 According to Linux Kernel, a2c1d73b94ed49 "arm64: Update the Image header",
 included unneccessary stuff.

 xen/arch/arm/arm64/head.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 91e2817..2cd3699 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -115,8 +115,8 @@ efi_head:
 add x13, x18, #0x16
 b   real_start   /* branch to kernel start */
 .quad   0/* Image load offset from start of RAM */
-.quad   0/* reserved */
-.quad   0/* reserved */
+   .quad   _end - start /* Effective size of kernel image, 
little-endian */


NIT: Please use _start here.


+   .quad   0xa  /* Informative flags(Physical placement 1, 
4KB, LE), little-endian */
 .quad   0/* reserved */
 .quad   0/* reserved */
 .quad   0/* reserved */



Regards,

--
Julien Grall

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

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

[Jan Beulich]

>>> On 14.09.16 at 10:23,  wrote:
> Starting from the beginning it looks that there are "soft" limits enforced
> in BIOS early boot code looking for usable low memory region. Hight limit
> is set at 640 KiB and low at 256 KiB. This means that if a value from a given
> source which describes low memory region (i.e. EBDA base segment, base memory
> size, multiboot protocol) is out of bounds then we try to get new value from
> next one (I mean source). However, at the end there are no checks that assure
> us that we got what we expected. So, I think that at first we should add 
> "hard"
> checks here. This means that if we get value out of earlier mentioned bounds
> then we should print relevant message on serial console and halt the system.

I disagree. I think that the best effort approach (what you name "soft"
checks) are quite okay in the legacy BIOS case: Even if the BIOS has
screwed things up, we can still _try_ to come up nevertheless.

This is quite different for (imo) much more sophisticated EFI
environments: We know they are screwed too, but we can't as
easily ignore them using certain pieces of memory.

> Additionally, my investigation has shown that there are no bound checks in
> low memory allocation machinery for trampoline (by the way, in BIOS path we
> allocate 64 KiB for trampoline but in EFI code we properly calculate its size;
> so, I think we should do the same calculation in BIOS path), stack and boot 
> data
> taken from multiboot protocol. Hence, relevant fixes should be added here too.

Would be nice, yes, but we need to weigh the need to presumably do
at least some of this in assembly code (for now at least) against the
potential gain.

> Moreover I think that at least allocation machinery with additional checks
> described in last paragraph can be used on EFI platforms when Xen is booted
> via multiboot2 protocol. However, then high limit should be defined as 1 MiB.
> Though I think that low limit, 256 KiB, should stay as is.

Why 1Mb? The 640k limit derives from hardware aspects, but doesn't
depend on the software environment.

> So, I think that we should prepare following patches:
>   - allocate properly calculated amount of memory for trampoline,
>   - define high/low limit as a constants and use them,
>   - add bounds checks for chosen low memory region, and bounds
> checks in allocation machinery for trampoline and stack,
>   - add bounds checks to allocator in reloc.c.
> 
> I have a feeling that this fixes are not very critical, however, nice to have.

Indeed. I'd just like to avoid that new code (read: your mb2 series)
gets introduced with similar issues. Just like the original EFI code at
least tries to properly allocate the trampoline space.

Jan


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

Re: [Xen-devel] [PATCH v4 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dongli Zhang]

> What is the scenario that you would want toolstack to set such flag?
> 
> Shouldn't hypervisor always set the flag when the guest is never
> unpaused and always clear / ignore that flag if the guest is ever
> unpaused? If that's all is needed, why does toolstack need to get
> involved?

You are right. I will not expose the flag to toolstack.

- Original Message -
From: wei.l...@citrix.com
To: dongli.zh...@oracle.com
Cc: jbeul...@suse.com, wei.l...@citrix.com, konrad.w...@oracle.com, 
sstabell...@kernel.org, t...@xen.org, dario.faggi...@citrix.com, 
ian.jack...@eu.citrix.com, george.dun...@eu.citrix.com, 
david.vra...@citrix.com, xen-devel@lists.xen.org, andrew.coop...@citrix.com
Sent: Friday, September 16, 2016 6:55:33 PM GMT +08:00 Beijing / Chongqing / 
Hong Kong / Urumqi
Subject: Re: [PATCH v4 2/2] xen: move TLB-flush filtering out into 
populate_physmap during vm creation

On Fri, Sep 16, 2016 at 03:47:23AM -0700, Dongli Zhang wrote:
> > > +/*
> > > + * MEMF_no_tlbflush can be set only during vm creation phase when
> > > + * is_ever_unpaused is still false before this domain gets unpaused 
> > > for
> > > + * the first time.
> > > + */
> > > +if ( unlikely(!d->is_ever_unpaused) )
> > > +a->memflags |= MEMF_no_tlbflush;
> > 
> > So you no longer mean to expose this to the caller?
> 
> hmmm I would prefer to expose this to the toolstack if it is OK for
> maintainers.
> 
> I copy and paste Wei's comments below:
> 
> ==
> 
> > Rule 1. It is toolstack's responsibility to set the "MEMF_no_tlbflush" bit
> > in memflags. The toolstack developers should be careful that
> > "MEMF_no_tlbflush" should never be used after vm creation is finished.
> > 
> 
> Is it possible to have a safety catch for this in the hypervisor? In
> general IMHO we should avoid providing an interface that is possible to
> create a security problem.
> 
> ==
> 
> Hi Wei, since it is possible to have a safety catch now in the hypervisor (the
> bit is allowed only before VM creation is finished), is it OK for you to 
> expose
> MEMF_no_tlbflush bit to toolstack?
> 

What is the scenario that you would want toolstack to set such flag?

Shouldn't hypervisor always set the flag when the guest is never
unpaused and always clear / ignore that flag if the guest is ever
unpaused? If that's all is needed, why does toolstack need to get
involved?

Do I miss something here?

Wei.


> Thank you very much!
> 
> Dongli Zhang

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

Re: [Xen-devel] [PATCH v2] xen-netback: fix error handling on netback_probe()

[Wei Liu]

On Thu, Sep 15, 2016 at 05:10:46PM +0200, Filipe Manco wrote:
> In case of error during netback_probe() (e.g. an entry missing on the
> xenstore) netback_remove() is called on the new device, which will set
> the device backend state to XenbusStateClosed by calling
> set_backend_state(). However, the backend state wasn't initialized by
> netback_probe() at this point, which will cause and invalid transaction
> and set_backend_state() to BUG().
> 
> Initialize the backend state at the beginning of netback_probe() to
> XenbusStateInitialising, and create two new valid state transitions on
> set_backend_state(), from XenbusStateInitialising to XenbusStateClosed,
> and from XenbusStateInitialising to XenbusStateInitWait.
> 
> Signed-off-by: Filipe Manco 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

[Wei Liu]

On Fri, Sep 16, 2016 at 10:51:18AM +0200, Juergen Groß wrote:
> On 09/15/2016 05:38 PM, Wei Liu wrote:
> >On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
> >>Add HVM usb passthrough support to libxl by using qemu's capability
> >>to emulate standard USB controllers.
> >>
> >>A USB controller is added via qmp command to the emulated hardware
> >>when a usbctrl device of type DEVICEMODEL is requested. Depending on
> >>the requested speed the appropriate hardware type is selected. A host
> >>USB device can then be added to the emulated USB controller via qmp
> >>command.
> >>
> >>Removing of the devices is done via qmp commands, too.
> >
> >Overall the code looks plausible. But the code seems to do more than
> >what is stated in commit message. Some comments below.
> 
> Thanks. I'm just travelling, so my answers are based on my memory what I
> did in the patch. I'll double check before sending out V2.
> 
> >
> >>
> >>Signed-off-by: Juergen Gross 
> >>---
> >> tools/libxl/libxl_device.c |   3 +-
> >> tools/libxl/libxl_usb.c| 417 
> >> +++--
> >> tools/libxl/xl_cmdimpl.c   |   4 +-
> >> 3 files changed, 331 insertions(+), 93 deletions(-)
> >>
> >>diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> >>index 5211f20..c6f15db 100644
> >>--- a/tools/libxl/libxl_device.c
> >>+++ b/tools/libxl/libxl_device.c
> >>@@ -782,8 +782,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
> >>libxl__devices_remove_state *drs)
> >> aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
> >> aodev->dev = dev;
> >> aodev->force = drs->force;
> >>-if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB ||
> >>-dev->backend_kind == LIBXL__DEVICE_KIND_QUSB)
> >>+if (dev->kind == LIBXL__DEVICE_KIND_VUSB)
> >
> >This looks a bit suspicious to me. This could be rather obvious but I'm
> >not sure because I didn't follow closely on the overall design of PV /
> >HVM USB passthrough.
> >
> >AIUI:
> >
> >VUSB -> PV USB with in-kernel backend
> >QUSB -> PV USB with QEMU backend
> >
> >Why is QUSB deleted here?
> 
> It isn't. :-)
> 
> A USB passthrough device will always be of kind == VUSB. The backend
> kind may differ, though. This is to ensure a proper device numbering
> regardless of the backend type used.

I see. I missed that dev->backend_kind is changed to dev->kind in the
diff.

> >> {
> >> device->backend_devid   = usbctrl->devid;
> >> device->backend_domid   = usbctrl->backend_domid;
> >>-device->backend_kind= (usbctrl->type == LIBXL_USBCTRL_TYPE_PV)
> >>-  ? LIBXL__DEVICE_KIND_VUSB
> >>-  : LIBXL__DEVICE_KIND_QUSB;
> >>+switch (usbctrl->type) {
> >>+case LIBXL_USBCTRL_TYPE_PV:
> >>+device->backend_kind = LIBXL__DEVICE_KIND_VUSB;
> >>+break;
> >>+case LIBXL_USBCTRL_TYPE_QUSB:
> >>+device->backend_kind = LIBXL__DEVICE_KIND_QUSB;
> >>+break;
> >>+case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
> >>+device->backend_kind = LIBXL__DEVICE_KIND_NONE;
> >>+break;
> >>+default:
> >>+break;
> >
> >Shouldn't we return some sort of error here?
> 
> This case should not be possible.
> Are you okay with me adding an assert() here?

Yes (and the other place as well).

Wei.

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

[Xen-devel] [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[Vitaly Kuznetsov]

Small packet loss is reported on complex multi host network configurations
including tunnels, NAT, ... My investigation led me to the following check
in netback which drops packets:

if (unlikely(txreq.size < ETH_HLEN)) {
netdev_err(queue->vif->dev,
   "Bad packet size: %d\n", txreq.size);
xenvif_tx_err(queue, , extra_count, idx);
break;
}

But this check itself is legitimate. SKBs consist of a linear part (which
has to have the ethernet header) and (optionally) a number of frags.
Netfront transmits the head of the linear part up to the page boundary
as the first request and all the rest becomes frags so when we're
reconstructing the SKB in netback we can't distinguish between original
frags and the 'tail' of the linear part. The first SKB needs to be at
least ETH_HLEN size. So in case we have an SKB with its linear part
starting too close to the page boundary the packet is lost.

I see two ways to fix the issue:
- Change the 'wire' protocol between netfront and netback to start keeping
  the original SKB structure. We'll have to add a flag indicating the fact
  that the particular request is a part of the original linear part and not
  a frag. We'll need to know the length of the linear part to pre-allocate
  memory.
- Avoid transmitting SKBs with linear parts starting too close to the page
  boundary. That seems preferable short-term and shouldn't bring
  significant performance degradation as such packets are rare. That's what
  this patch is trying to achieve with skb_copy().

Signed-off-by: Vitaly Kuznetsov 
Acked-by: David Vrabel 
---
- This is just a RESEND with David's ACK added.
---
 drivers/net/xen-netfront.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 96ccd4e..28c4a66 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -565,6 +565,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
struct netfront_queue *queue = NULL;
unsigned int num_queues = dev->real_num_tx_queues;
u16 queue_index;
+   struct sk_buff *nskb;
 
/* Drop the packet if no queues are set up */
if (num_queues < 1)
@@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
offset = offset_in_page(skb->data);
len = skb_headlen(skb);
 
+   /* The first req should be at least ETH_HLEN size or the packet will be
+* dropped by netback.
+*/
+   if (unlikely(PAGE_SIZE - offset < ETH_HLEN)) {
+   nskb = skb_copy(skb, GFP_ATOMIC);
+   if (!nskb)
+   goto drop;
+   dev_kfree_skb_any(skb);
+   skb = nskb;
+   page = virt_to_page(skb->data);
+   offset = offset_in_page(skb->data);
+   }
+
spin_lock_irqsave(>tx_lock, flags);
 
if (unlikely(!netif_carrier_ok(dev) ||
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v4 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Wei Liu]

On Fri, Sep 16, 2016 at 03:47:23AM -0700, Dongli Zhang wrote:
> > > +/*
> > > + * MEMF_no_tlbflush can be set only during vm creation phase when
> > > + * is_ever_unpaused is still false before this domain gets unpaused 
> > > for
> > > + * the first time.
> > > + */
> > > +if ( unlikely(!d->is_ever_unpaused) )
> > > +a->memflags |= MEMF_no_tlbflush;
> > 
> > So you no longer mean to expose this to the caller?
> 
> hmmm I would prefer to expose this to the toolstack if it is OK for
> maintainers.
> 
> I copy and paste Wei's comments below:
> 
> ==
> 
> > Rule 1. It is toolstack's responsibility to set the "MEMF_no_tlbflush" bit
> > in memflags. The toolstack developers should be careful that
> > "MEMF_no_tlbflush" should never be used after vm creation is finished.
> > 
> 
> Is it possible to have a safety catch for this in the hypervisor? In
> general IMHO we should avoid providing an interface that is possible to
> create a security problem.
> 
> ==
> 
> Hi Wei, since it is possible to have a safety catch now in the hypervisor (the
> bit is allowed only before VM creation is finished), is it OK for you to 
> expose
> MEMF_no_tlbflush bit to toolstack?
> 

What is the scenario that you would want toolstack to set such flag?

Shouldn't hypervisor always set the flag when the guest is never
unpaused and always clear / ignore that flag if the guest is ever
unpaused? If that's all is needed, why does toolstack need to get
involved?

Do I miss something here?

Wei.


> Thank you very much!
> 
> Dongli Zhang

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

Re: [Xen-devel] [PATCH v4 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dongli Zhang]

> > +/*
> > + * MEMF_no_tlbflush can be set only during vm creation phase when
> > + * is_ever_unpaused is still false before this domain gets unpaused for
> > + * the first time.
> > + */
> > +if ( unlikely(!d->is_ever_unpaused) )
> > +a->memflags |= MEMF_no_tlbflush;
> 
> So you no longer mean to expose this to the caller?

hmmm I would prefer to expose this to the toolstack if it is OK for
maintainers.

I copy and paste Wei's comments below:

==

> Rule 1. It is toolstack's responsibility to set the "MEMF_no_tlbflush" bit
> in memflags. The toolstack developers should be careful that
> "MEMF_no_tlbflush" should never be used after vm creation is finished.
> 

Is it possible to have a safety catch for this in the hypervisor? In
general IMHO we should avoid providing an interface that is possible to
create a security problem.

==

Hi Wei, since it is possible to have a safety catch now in the hypervisor (the
bit is allowed only before VM creation is finished), is it OK for you to expose
MEMF_no_tlbflush bit to toolstack?

Thank you very much!

Dongli Zhang

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

Re: [Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Thomas Gleixner]

On Thu, 15 Sep 2016, Kyle Huey wrote:

Please use proper prefixes for your patch:

git-log arch/x86/kernel/cpu/scattered.c will give you the hint:

x86/cpufeature: Move some of the scattered feature bits to x86_capability
x86/cpufeature: Correct spelling of the HWP_NOTIFY flag

and make the subject line short. Long sentences belong into the body of the
changelog.

And again this changelog does not tell anything.

What is this CPUID faulting support?
Which CPUs do support this?
Why do we want this?

>  #define X86_FEATURE_CPB  ( 7*32+ 2) /* AMD Core Performance 
> Boost */
>  #define X86_FEATURE_EPB  ( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS 
> support */
> +#define X86_FEATURE_CPUID_FAULT ( 7*32+ 4) /* Intel CPUID faulting */

Boris?

>  #define X86_FEATURE_HW_PSTATE( 7*32+ 8) /* AMD HW-PState */
>  #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
> diff --git a/arch/x86/include/asm/msr-index.h 
> b/arch/x86/include/asm/msr-index.h
> index 56f4c66..83908d5 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -41,6 +41,7 @@
>  #define MSR_IA32_PERFCTR10x00c2
>  #define MSR_FSB_FREQ 0x00cd
>  #define MSR_PLATFORM_INFO0x00ce
> +#define CPUID_FAULTING_SUPPORT   (1UL << 31)

If you look at the other MSR bit defines then they have always a prefix
which links them to the MSR

What's the name of this bit in the Documentation?

> +static int supports_cpuid_faulting(void)

bool please

> +{
> + unsigned int lo, hi;
> +
> + if (rdmsr_safe(MSR_PLATFORM_INFO, , ) == 0 &&
> + (lo & CPUID_FAULTING_SUPPORT))
> + return 1;
> + else
> + return 0;

if (rdmsr_safe(MSR_PLATFORM_INFO, , ))
return false;

return lo & PLATINFO_CPUID_FAULT;

would make it readable without linebreaks.

Thanks,

tglx
 

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

Re: [Xen-devel] [PATCH] x86/Intel: hide CPUID faulting capability from guests

[Jan Beulich]

>>> On 16.09.16 at 11:46,  wrote:
> On 16/09/16 07:32, Jan Beulich wrote:
>> We don't currently emulate it, so guests should not be misguided to
>> believe they can (try to) use it.
>>
>> For now, simply return zero to guests for platform MSR reads, and only
>> accept (by discarding) writes of zero. If ever there will be bits we
>> can safely expose to guests, let's handle them by white listing.
>>
>> (As a side note - according to SDM version 059 bit 31 is reserved on
>> all known families.)
>>
>> Reported-by: Kyle Huey 
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Andrew Cooper , but I would also 
> suggest putting in a d->arch.x86_vendor check against Intel as well.

In general I agree, but then let's please do this for all instances
which currently use the host CPU vendor field at once: There's no
single example of this, and I have to admit that it's also not
immediately clear to me what the best behavior would be in some
of the cases if host and guest vendor disagree.

Jan


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

Re: [Xen-devel] [PATCH] x86/Intel: hide CPUID faulting capability from guests

[Andrew Cooper]

On 16/09/16 07:32, Jan Beulich wrote:

We don't currently emulate it, so guests should not be misguided to
believe they can (try to) use it.

For now, simply return zero to guests for platform MSR reads, and only
accept (by discarding) writes of zero. If ever there will be bits we
can safely expose to guests, let's handle them by white listing.

(As a side note - according to SDM version 059 bit 31 is reserved on
all known families.)

Reported-by: Kyle Huey 
Signed-off-by: Jan Beulich 


Acked-by: Andrew Cooper , but I would also 
suggest putting in a d->arch.x86_vendor check against Intel as well.


~Andrew

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

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

[Juergen Groß]

On 09/15/2016 05:38 PM, Wei Liu wrote:

On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:

Add HVM usb passthrough support to libxl by using qemu's capability
to emulate standard USB controllers.

A USB controller is added via qmp command to the emulated hardware
when a usbctrl device of type DEVICEMODEL is requested. Depending on
the requested speed the appropriate hardware type is selected. A host
USB device can then be added to the emulated USB controller via qmp
command.

Removing of the devices is done via qmp commands, too.


Overall the code looks plausible. But the code seems to do more than
what is stated in commit message. Some comments below.


Thanks. I'm just travelling, so my answers are based on my memory what I
did in the patch. I'll double check before sending out V2.





Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl_device.c |   3 +-
 tools/libxl/libxl_usb.c| 417 +++--
 tools/libxl/xl_cmdimpl.c   |   4 +-
 3 files changed, 331 insertions(+), 93 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5211f20..c6f15db 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -782,8 +782,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
libxl__devices_remove_state *drs)
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->dev = dev;
 aodev->force = drs->force;
-if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB ||
-dev->backend_kind == LIBXL__DEVICE_KIND_QUSB)
+if (dev->kind == LIBXL__DEVICE_KIND_VUSB)


This looks a bit suspicious to me. This could be rather obvious but I'm
not sure because I didn't follow closely on the overall design of PV /
HVM USB passthrough.

AIUI:

VUSB -> PV USB with in-kernel backend
QUSB -> PV USB with QEMU backend

Why is QUSB deleted here?


It isn't. :-)

A USB passthrough device will always be of kind == VUSB. The backend
kind may differ, though. This is to ensure a proper device numbering
regardless of the backend type used.


If there is refactoring involved, can that be separated out?


 libxl__initiate_device_usbctrl_remove(egc, aodev);
 else
 libxl__initiate_device_generic_remove(egc, aodev);
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index 6b30e0f..40c5a84 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -17,6 +17,7 @@

 #include "libxl_internal.h"
 #include 
+#include 

 #define USBBACK_INFO_PATH "/libxl/usbback"

@@ -43,12 +44,6 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
uint32_t domid,
 int rc;
 libxl_domain_type domtype = libxl__domain_type(gc, domid);

-if (!usbctrl->version)
-usbctrl->version = 2;
-
-if (!usbctrl->ports)
-usbctrl->ports = 8;
-
 if (usbctrl->type == LIBXL_USBCTRL_TYPE_AUTO) {
 if (domtype == LIBXL_DOMAIN_TYPE_PV) {
 rc = usbback_is_loaded(gc);
@@ -62,6 +57,67 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
uint32_t domid,
 }
 }

+switch (usbctrl->type) {
+case LIBXL_USBCTRL_TYPE_PV:
+case LIBXL_USBCTRL_TYPE_QUSB:
+if (!usbctrl->version)
+usbctrl->version = 2;
+if (usbctrl->version < 1 || usbctrl->version > 2) {
+LOG(ERROR, "USB version for paravirtualized devices must be 1 or 
2");
+rc = ERROR_INVAL;
+goto out;
+}
+if (!usbctrl->ports)
+usbctrl->ports = 8;
+if (usbctrl->ports < 1 || usbctrl->ports > USBIF_MAX_PORTNR) {
+LOG(ERROR, "Number of ports for USB controller is limited to %u",
+USBIF_MAX_PORTNR);
+rc = ERROR_INVAL;
+goto out;
+}
+break;
+case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
+if (!usbctrl->version)
+usbctrl->version = 2;
+switch (usbctrl->version) {
+case 1:
+/* uhci controller in qemu has fixed number of ports. */
+if (usbctrl->ports && usbctrl->ports != 2) {
+LOG(ERROR, "Number of ports for USB controller of version 1 is 
always 2");


Please wrap long line if possible.


Okay.




+rc = ERROR_INVAL;
+goto out;
+}
+usbctrl->ports = 2;
+break;
+case 2:
+/* ehci controller in qemu has fixed number of ports. */
+if (usbctrl->ports && usbctrl->ports != 6) {
+LOG(ERROR, "Number of ports for USB controller of version 2 is 
always 6");
+rc = ERROR_INVAL;
+goto out;
+}
+usbctrl->ports = 6;
+break;
+case 3:
+if (!usbctrl->ports)
+usbctrl->ports = 8;
+/* xhci controller in qemu supports up to 15 ports. */
+if 

[Xen-devel] [libvirt test] 100980: regressions - FAIL

[osstest service owner]

flight 100980 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100980/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 100962

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass

version targeted for testing:
 libvirt  d18c7d712471dabafec1a3a4c01f219dc26d38db
baseline version:
 libvirt  4a457adda649447a7873f48bf71c5139bc6404d2

Last test of basis   100962  2016-09-15 04:22:11 Z1 days
Testing same since   100980  2016-09-16 04:31:01 Z0 days1 attempts


People who touched revisions under test:
  Jason Miesionczek 
  Martin Kletzander 
  Michal Privoznik 
  Shivaprasad G Bhat 
  Tomáš Ryšavý 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt blocked 
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit d18c7d712471dabafec1a3a4c01f219dc26d38db
Author: Tomáš Ryšavý 
Date:   Thu Sep 15 10:27:09 2016 +0200

test driver: Implement testNodeGetFreePages.

Signed-off-by: Tomáš Ryšavý 

commit dc98750a06dbb0389f7bc22c3f0ed8e1c17e3a41
Author: Tomáš Ryšavý 

[Xen-devel] [qemu-mainline test] 100975: regressions - FAIL

[osstest service owner]

flight 100975 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100975/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100966

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100966
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100966
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100966

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuu5f473241ac595452ae0638dc63e7af2a2294f5ec
baseline version:
 qemuu8212ff86f4405b6128d89dd1d97ff2d6cfcf9842

Last test of basis   100966  2016-09-15 10:45:30 Z0 days
Failing since100971  2016-09-15 17:22:22 Z0 days2 attempts
Testing same since   100975  2016-09-16 00:25:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Dutcher 
  Ashijeet Acharya 
  Aurelien Jarno 
  Cao jin 
  Daniel P. Berrange 
  Eduardo Habkost 
  Fam Zheng 
  Gerd Hoffmann 
  Guan Xuetao 
  Hans Petter Selasky 
  Isaac Lozano <109loza...@gmail.com>
  John Arbuckle 
  Ladi Prosek 
  Laurent Vivier 
  Li Qiang 
  Lin Ma 
  Marc-André Lureau 
  Marc-André Lureau 
  Markus Armbruster 
  Md Haris Iqbal 
  Michael Tokarev 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Maydell 
  Prasad J Pandit 
  Programmingkid 
  Reda Sallahi 
  Richard Henderson 
  Stanislav 

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

[Thomas Gleixner]

On Thu, 15 Sep 2016, Kyle Huey wrote:

First of all, please add a cover letter [PATCH 0/N] to your patch series
and send it with something which provides proper mail threading. 
See: git-send-email, quilt 

> arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
> now. Rename the second arg to a more generic name.

This changelog is useless.

- it does not provide any rationale for this change, i.e. why this is
  required. Just because its 64bit only is not a reason.

- "Rename the second arg to a more generic name" does not give
  any useful information.

Misleading information is worse than no information.

Further your patch does 5 things at once. It wants to be split into parts:

1) Rename do_arch_prctl() and change the argument name,

> -long do_arch_prctl(struct task_struct *task, int code, unsigned long addr)
> +long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2)

2) Provide do_arch_prctl_common() and hook it up to the arch_prctl syscall

> -long sys_arch_prctl(int code, unsigned long addr)
> +SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
>  {
> - return do_arch_prctl(current, code, addr);
> + long ret;
> +
> + ret = do_arch_prctl_64(current, code, arg2);
> + if (ret == -EINVAL)
> + ret = do_arch_prctl_common(current, code, arg2);
> +
> + return ret;
>  }

3) Implement the compat version
  
Thanks,

tflx

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

Re: [Xen-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

[Olaf Hering]

On Wed, Sep 14, Stefano Stabellini wrote:

> The doc says:
> 
> "If VMDP was configured to control just NIC devices it would write the
> value 0x1 to offset 0x8. If VMDP was configured to control just storage
> devices it would write the value 0x2 to offset 0x8."
> 
> So 0x1 to 0x8 to unplug NICs, otherwise 0x2 to 0x8 to unplug storage.
> The switch above does the opposite. What am I missing? Am I misreading
> the document?

The doc is wrong, this is what qemu-trad does:

+case 8:
+   if (val ==1 ) {
+   fprintf(logfile, "Disconnect IDE hard disk...\n");
+   ide_unplug_harddisks();
+   fprintf(logfile, "Done.\n");
+   } else if (val == 2) {
+   fprintf(logfile, "Disconnect netifs...\n");
+   pci_unplug_netifs();
+   fprintf(logfile, "Shutdown taps...\n");
+   net_tap_shutdown_all();
+   fprintf(logfile, "Done.\n");
+   }
+   break;

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] xen_platform: unplug also SCSI disks

[Olaf Hering]

On Wed, Sep 14, Stefano Stabellini wrote:

> Written like this, the code will unplug any Xen SCSI disks together with
> Xen IDE disks when the guest writes "1" to ioport `0x10`. I am sorry to
> be pedantic, but the recent changes introduced to
> docs/misc/hvm-emulated-unplug.markdown do not cover any changes in
> behavior to the existing ioport address (I am looking specifically at
> point 6).  Sorry to only notice this now.

I will update the docs once the code is changed.

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

[Razvan Cojocaru]

On 09/15/16 21:24, Tamas K Lengyel wrote:
> The ARM SMC instructions are already configured to trap to Xen by default. In
> this patch we allow a user-space process in a privileged domain to receive
> notification of when such event happens through the vm_event subsystem by
> introducing the PRIVILEGED_CALL type.
> 
> The intended use-case for this feature is for a monitor application to be able
> insert tap-points into the domU kernel-code. For this task only unconditional
> SMC instruction should be used.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Razvan Cojocaru 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Razvan Cojocaru]

On 09/15/16 20:08, Razvan Cojocaru wrote:
> On 09/15/16 19:36, Tamas K Lengyel wrote:
>> On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru
>>  wrote:
>>> On 09/13/2016 09:12 PM, Tamas K Lengyel wrote:
 When emulating instructions the emulator maintains a small i-cache fetched
 from the guest memory. This patch extends the vm_event interface to allow
 returning this i-cache via the vm_event response instead.

 When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor 
 subscriber
 normally has to remove the INT3 from memory - singlestep - place back INT3
 to allow the guest to continue execution. This routine however is 
 susceptible
 to a race-condition on multi-vCPU guests. By allowing the subscriber to 
 return
 the i-cache to be used for emulation it can side-step the problem by 
 returning
 a clean buffer without the INT3 present.

 As part of this patch we rename hvm_mem_access_emulate_one to
 hvm_emulate_one_vm_event to better reflect that it is used in various 
 vm_event
 scenarios now, not just in response to mem_access events.

 Signed-off-by: Tamas K Lengyel 
 ---
 Cc: Paul Durrant 
 Cc: Jan Beulich 
 Cc: Andrew Cooper 
 Cc: Jun Nakajima 
 Cc: Kevin Tian 
 Cc: George Dunlap 
 Cc: Razvan Cojocaru 
 Cc: Stefano Stabellini 
 Cc: Julien Grall 

 Note: This patch only has been compile-tested.
 ---
  xen/arch/x86/hvm/emulate.c| 44 
 ++-
  xen/arch/x86/hvm/hvm.c|  9 +---
  xen/arch/x86/hvm/vmx/vmx.c|  1 +
  xen/arch/x86/vm_event.c   |  9 +++-
  xen/common/vm_event.c |  1 -
  xen/include/asm-x86/hvm/emulate.h |  8 ---
  xen/include/asm-x86/vm_event.h|  3 ++-
  xen/include/public/vm_event.h | 16 +-
  8 files changed, 67 insertions(+), 24 deletions(-)

 diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
 index cc25676..504ed35 100644
 --- a/xen/arch/x86/hvm/emulate.c
 +++ b/xen/arch/x86/hvm/emulate.c
 @@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int 
 size)
  if ( curr->arch.vm_event )
  {
  unsigned int safe_size =
 -min(size, curr->arch.vm_event->emul_read_data.size);
 +min(size, curr->arch.vm_event->emul_read.size);

 -memcpy(buffer, curr->arch.vm_event->emul_read_data.data, 
 safe_size);
 +memcpy(buffer, curr->arch.vm_event->emul_read.data, safe_size);
  memset(buffer + safe_size, 0, size - safe_size);
  return X86EMUL_OKAY;
  }
 @@ -827,7 +827,7 @@ static int hvmemul_read(
  struct hvm_emulate_ctxt *hvmemul_ctxt =
  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);

 -if ( unlikely(hvmemul_ctxt->set_context) )
 +if ( unlikely(hvmemul_ctxt->set_context_data) )
  return set_context_data(p_data, bytes);

  return __hvmemul_read(
 @@ -1029,7 +1029,7 @@ static int hvmemul_cmpxchg(
  struct hvm_emulate_ctxt *hvmemul_ctxt =
  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);

 -if ( unlikely(hvmemul_ctxt->set_context) )
 +if ( unlikely(hvmemul_ctxt->set_context_data) )
  {
  int rc = set_context_data(p_new, bytes);

 @@ -1122,7 +1122,7 @@ static int hvmemul_rep_outs(
  p2m_type_t p2mt;
  int rc;

 -if ( unlikely(hvmemul_ctxt->set_context) )
 +if ( unlikely(hvmemul_ctxt->set_context_data) )
  return hvmemul_rep_outs_set_context(src_seg, src_offset, dst_port,
  bytes_per_rep, reps, ctxt);

 @@ -1264,7 +1264,7 @@ static int hvmemul_rep_movs(
  if ( buf == NULL )
  return X86EMUL_UNHANDLEABLE;

 -if ( unlikely(hvmemul_ctxt->set_context) )
 +if ( unlikely(hvmemul_ctxt->set_context_data) )
  {
  rc = set_context_data(buf, bytes);

 @@ -1470,7 +1470,7 @@ static int hvmemul_read_io(

  *val = 0;

 -if ( unlikely(hvmemul_ctxt->set_context) )
 +if ( unlikely(hvmemul_ctxt->set_context_data) )
  return set_context_data(val, bytes);

  return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
 @@ -1793,7 +1793,14 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
 *hvmemul_ctxt,
  pfec |= PFEC_user_mode;

  hvmemul_ctxt->insn_buf_eip = regs->eip;
 -if ( 

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Jan Beulich]

>>> On 15.09.16 at 18:40,  wrote:
> On 09/15/2016 12:05 PM, Jan Beulich wrote
> 
>>> Maybe even without changes to mk_dsdt.c
>> But isn't that the critical part? 
> 
> Not necessarily since we'd use --gpl option only for
> dsdt_anycpu_qemu_xen, dsdt_anycpu and dsdt_15cpu and these files are not
> used by the non-GPL caller, which is libxl (it only wants dsdt_pvh).
> 
> Of course, this is what we have currently.

Right - and with the goal to guard against future changes I think
we'd better not omit those parts.

>> And - what functionality do we lose
>> without that code? There's no point in generating something that's
>> of no practical use.
> 
> We don't lose any functionality (again, currently). In fact, this
> indirectly prevents us from generating unnecessary files listed above.

Agreed - I got the sense of the check in mk_dsdt.c the wrong way
round.

>> And then there's the question of whether excluding things from the
>> build, but having them present in the sources actually helps.
> 
> The main reason for this whole relicensing debacle is to prevent non-GPL
> binaries from linking against GPL objects, and this patch allows us to
> do that. Yes, there will be be two non-LGPL files (dsdt.asl amd
> mk_dsdt.c, which I will revert back to GPL) in an otherwise LGPL
> directory but that's an in-convenience and not a license violation.

Well, if linking is all this is about, then it's fine of course. I'm just
not a license expert, so we'd need this acked by someone who is
more familiar with the differences and implications.

Jan


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