date:20161108

On Wed, 28 Sep 2016, Andre Przywara wrote:
> The INV command instructs the ITS to update the configuration data for
> a given LPI by re-reading its entry from the property table.
> We don't need to care so much about the priority value, but enabling
> or disabling an LPI has some effect: We remove or push virtual LPIs
> to their VCPUs, also propagate the enable bit to the hardware.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-its.c| 35 
>  xen/arch/arm/vgic-its.c   | 74 
> +++
>  xen/include/asm-arm/gic-its.h |  3 ++
>  3 files changed, 112 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index 766a7cb..6f4329f 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -215,6 +215,19 @@ static int its_send_cmd_mapd(struct host_its *its, 
> uint32_t deviceid,
>  return its_send_command(its, cmd);
>  }
>  
> +static int its_send_cmd_inv(struct host_its *its,
> +uint32_t deviceid, uint32_t eventid)
> +{
> +uint64_t cmd[4];
> +
> +cmd[0] = GITS_CMD_INV | ((uint64_t)deviceid << 32);
> +cmd[1] = eventid;
> +cmd[2] = 0x00;
> +cmd[3] = 0x00;
> +
> +return its_send_command(its, cmd);
> +}
> +
>  int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
>   int devid, int bits, bool valid)
>  {
> @@ -655,6 +668,28 @@ uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t 
> host_lpi, int *vcpu_id)
>  return hlpi.virt_lpi;
>  }
>  
> +void gicv3_lpi_set_enable(struct host_its *its,
> +  uint32_t deviceid, uint32_t eventid,
> +  uint32_t host_lpi, bool enabled)
> +{
> +host_lpi -= 8192;
> +
> +if ( host_lpi >= MAX_HOST_LPIS )
> +return;
> +
> +if ( !its )
> +return;
> +
> +if (enabled)
> +lpi_data.lpi_property[host_lpi] |= LPI_PROP_ENABLED;
> +else
> +lpi_data.lpi_property[host_lpi] &= ~LPI_PROP_ENABLED;
> +
> +__flush_dcache_area(_data.lpi_property[host_lpi], 1);
> +
> +its_send_cmd_inv(its, deviceid, eventid);
> +its_send_cmd_sync(its, 0);
> +}
> +
>  void gicv3_its_dt_init(const struct dt_device_node *node)
>  {
>  const struct dt_device_node *its = NULL;
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 028d234..74da8fc 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -223,6 +223,77 @@ out_unlock:
>  return ret;
>  }
>  
> +/* For a given virtual LPI read the enabled bit from the virtual property
> + * table and update the virtual IRQ's state.
> + * This enables or disables the associated hardware LPI, also takes care
> + * of removing or pushing of virtual LPIs to their VCPUs.
> + */
> +static void update_lpi_enabled_status(struct virt_its* its,
> +  struct vcpu *vcpu, uint32_t vlpi,
> +  uint32_t deviceid, uint32_t eventid,
> +  uint32_t hlpi)
> +{
> +struct pending_irq *pirq = lpi_to_pending(vcpu, vlpi, false);
> +uint8_t property = its->d->arch.vgic.proptable[vlpi - 8192];

We need to check vlpi before using to access an array. We also need a
barrier before using property.


> +if ( property & LPI_PROP_ENABLED )
> +{
> +if ( pirq )
> +{
> +unsigned long flags;
> +
> +set_bit(GIC_IRQ_GUEST_ENABLED, >status);
> +spin_lock_irqsave(>arch.vgic.lock, flags);
> +if ( !list_empty(>inflight) &&
> + !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
> +gic_raise_guest_irq(vcpu, vlpi, property & 0xfc);
> +spin_unlock_irqrestore(>arch.vgic.lock, flags);
> +
> +}
> +gicv3_lpi_set_enable(its->hw_its, deviceid, eventid, hlpi, true);
> +}
> +else
> +{
> +if ( pirq )
> +{
> +clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
> +gic_remove_from_queues(vcpu, vlpi);
> +}
> +gicv3_lpi_set_enable(its->hw_its, deviceid, eventid, hlpi, false);
> +}
> +}
> +
> +static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +uint32_t eventid = its_cmd_get_id(cmdptr);
> +struct vits_itte *itte;
> +struct vcpu *vcpu;
> +uint32_t hlpi, vlpi;
> +int ret = -1;
> +
> +spin_lock(>its_lock);
> +
> +itte = get_devid_evid(its, devid, eventid);
> +if ( !itte )
> +goto out_unlock;

We need to check itte->collection before using it to access d->vcpu.


> +vcpu = its->d->vcpu[itte->collection];
> +vlpi = itte->vlpi;
> +hlpi = itte->hlpi;
> +
> +ret = 0;
> +
> +put_devid_evid(its, itte);
> +
> +out_unlock:
> +spin_unlock(>its_lock);
> +
> +if ( !ret )
> +update_lpi_enabled_status(its, vcpu,

Re: [Xen-devel] [PATCH v3 00/15] Enable L2 Cache Allocation Technology

2016-11-08 Thread Yi Sun

Hi, all,

Any comment or suggestion to this patch set? That would be very appreciated.
Thank you!

BRs,
Sun Yi

On 16-10-25 11:40:48, Yi Sun wrote:
> Hi all,
> 
> We plan to bring a new PSR (Platform Shared Resource) feature called
> Intel L2 Cache Allocation Technology (L2 CAT) to Xen.
> 
> Besides the L2 CAT implementaion, we refactor the psr.c to make it more
> flexible to add new features and fulfill the principle, open for extension
> but closed for modification. We abstract the general operations of all
> features and encapsulate them into a structure. Then, the development
> of new feature is simple to mainly implement these callback functions.
> 
> The patch set can be found at:
> https://github.com/yisun-git/xen_l2_cat.git xen_l2_v3_3
> 
> ---
> Changes since v2:
>  * Add design document into docs/.
>  * Split "refactor psr" patch to several small patches. 
>  * Function and variables names are changed to express accurately.
>  * Revert some unnecessary changes.
>  * Fix issues according to comments provided by reviewers.
> 
> -- 
> 2.7.4

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

Re: [Xen-devel] [RFC PATCH 19/24] ARM: vITS: handle DISCARD command

On Wed, 28 Sep 2016, Andre Przywara wrote:
> The DISCARD command drops the connection between a DeviceID/EventID
> and an LPI/collection pair.
> We mark the respective structure entries as not allocated and make
> sure that any queued IRQs are removed.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-its.c| 21 +++
>  xen/arch/arm/vgic-its.c   | 48 
> +++
>  xen/include/asm-arm/gic-its.h |  5 +
>  3 files changed, 74 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index d1b1cbb..766a7cb 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -634,6 +634,27 @@ int gicv3_lpi_change_vcpu(struct domain *d, uint32_t 
> host_lpi, int new_vcpu_id)
>  return 0;
>  }
>  
> +/* Looks up a given host LPI assigned to that domain and returns the
> + * connected virtual LPI number. Also stores the target vcpu ID in
> + * the passed vcpu_id pointer.
> + * Returns 0 if no host LPI could be found for that domain, or the
> + * virtual LPI number (>= 8192) if the lookup succeeded.
> + */
> +uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t host_lpi, int 
> *vcpu_id)
> +{
> +union host_lpi *hlpip, hlpi;
> +
> +hlpip = gic_find_host_lpi(host_lpi, d);
> +if ( !hlpip )
> +return 0;
> +
> +hlpi.data = hlpip->data;
> +if ( vcpu_id )
> +*vcpu_id = hlpi.vcpu_id;
> +
> +return hlpi.virt_lpi;
> +}
> +
>  void gicv3_its_dt_init(const struct dt_device_node *node)
>  {
>  const struct dt_device_node *its = NULL;
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index c0a60ad..028d234 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -367,6 +367,51 @@ out_unlock:
>  return 0;
>  }
>  
> +static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +uint32_t eventid = its_cmd_get_id(cmdptr);
> +struct pending_irq *pirq;
> +struct vits_itte *itte;
> +struct vcpu *vcpu;
> +uint32_t vlpi;
> +int ret = -1, vcpu_id;
> +
> +spin_lock(>its_lock);
> +itte = get_devid_evid(its, devid, eventid);
> +if ( !itte )
> +goto out_unlock;
> +
> +vlpi = gicv3_lpi_lookup_lpi(its->d, itte->hlpi, _id);
> +if ( !vlpi )
> +goto out_unlock;

Using itte->hlpi like that is very dangerous because the guest could be
modifying that field while we run gicv3_lpi_lookup_lpi or
gicv3_lpi_drop_host_lpi. Actually we need a compiler barrier after
reading all guest accessible fields and before using them to access our
own data structures.


> +vcpu = its->d->vcpu[vcpu_id];
> +
> +pirq = lpi_to_pending(vcpu, vlpi, false);
> +if ( pirq )
> +{
> +clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
> +gic_remove_from_queues(vcpu, vlpi);
> +
> +/* Mark this pending IRQ struct as availabe again. */
> +if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
> +pirq->irq = 0;

We need to do something in case the vlpi is in a GICH_LR register


> +}
> +
> +gicv3_lpi_drop_host_lpi(its->hw_its, devid, eventid, itte->hlpi);

Same here regarding itte->hlpi


> +itte->hlpi = 0; /* Mark this ITTE as unused. */
> +ret = 0;
> +
> +put_devid_evid(its, itte);
> +
> +out_unlock:
> +spin_unlock(>its_lock);
> +
> +return ret;
> +}
> +
>  #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>  
>  static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -390,6 +435,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
> virt_its *its,
>  case GITS_CMD_CLEAR:
>  its_handle_clear(its, cmdptr);
>  break;
> +case GITS_CMD_DISCARD:
> +its_handle_discard(its, cmdptr);
> +break;
>  case GITS_CMD_INT:
>  its_handle_int(its, cmdptr);
>  break;
> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
> index 7e1142f..3f5698d 100644
> --- a/xen/include/asm-arm/gic-its.h
> +++ b/xen/include/asm-arm/gic-its.h
> @@ -133,6 +133,11 @@ int gicv3_its_map_device(struct host_its *hw_its, struct 
> domain *d,
>  int gicv3_lpi_allocate_host_lpi(struct host_its *its,
>  uint32_t devid, uint32_t eventid,
>  struct vcpu *v, int virt_lpi);
> +/* Given a physical LPI, looks up and returns the associated virtual LPI
> + * and the target VCPU in the given domain.
> + */
> +uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t host_lpi,
> +  int *vcpu_id);
>  int gicv3_lpi_change_vcpu(struct domain *d, uint32_t host_lpi, int 
> new_vcpu_id);
>  int gicv3_lpi_drop_host_lpi(struct host_its *its,
>  uint32_t devid, uint32_t eventid,
> -- 
> 2.9.0
>

Re: [Xen-devel] [RFC PATCH 18/24] ARM: vITS: handle MOVI command

On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MOVI command moves the interrupt affinity from one redistributor
> (read: VCPU) to another.
> For now migration of "live" LPIs is not yet implemented, but we store
> the changed affinity in the host LPI structure and in our virtual ITTE.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/gic-its.c| 16 +++
>  xen/arch/arm/vgic-its.c   | 46 
> +++
>  xen/include/asm-arm/gic-its.h |  1 +
>  3 files changed, 63 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index 6bac422..d1b1cbb 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -618,6 +618,22 @@ int gicv3_lpi_drop_host_lpi(struct host_its *its,
>  return 0;
>  }
>  
> +/* Changes the target VCPU for a given host LPI assigned to a domain. */
> +int gicv3_lpi_change_vcpu(struct domain *d, uint32_t host_lpi, int 
> new_vcpu_id)
> +{
> +union host_lpi *hlpip, hlpi;
> +
> +hlpip = gic_find_host_lpi(host_lpi, d);
> +if ( !hlpip )
> +return -1;
> +
> +hlpi.data = hlpip->data;
> +hlpi.vcpu_id = new_vcpu_id;
> +hlpip->data = hlpi.data;

Most surely we need to call vgic_migrate_irq


> +return 0;
> +}
> +
>  void gicv3_its_dt_init(const struct dt_device_node *node)
>  {
>  const struct dt_device_node *its = NULL;
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 70897dd..c0a60ad 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -327,6 +327,46 @@ out_unlock:
>  return ret;
>  }
>  
> +static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +uint32_t eventid = its_cmd_get_id(cmdptr);
> +int collid = its_cmd_get_collection(cmdptr);
> +struct vits_itte *itte;
> +struct vcpu *vcpu;
> +uint32_t host_lpi = 0;
> +
> +if ( collid >= its->max_collections )
> +return -1;
> +
> +spin_lock(>its_lock);
> +
> +vcpu = get_vcpu_from_collection(its, collid);
> +if ( !vcpu )
> +goto out_unlock;
> +
> +itte = get_devid_evid(its, devid, eventid);
> +if ( !itte )
> +goto out_unlock;
> +
> +itte->collection = collid;
> +host_lpi = itte->hlpi;
> +
> +/* TODO: lookup currently-in-guest virtual IRQs and migrate them */
> +
> +put_devid_evid(its, itte);
> +
> +out_unlock:
> +spin_unlock(>its_lock);
> +
> +if ( !host_lpi )
> +return -1;
> +
> +gicv3_lpi_change_vcpu(its->d, host_lpi, vcpu->vcpu_id);
> +
> +return 0;
> +}
> +
>  #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>  
>  static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -363,6 +403,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
> virt_its *its,
>  case GITS_CMD_MAPTI:
>  its_handle_mapti(its, cmdptr);
>  break;
> +case GITS_CMD_MOVALL:
> +gdprintk(XENLOG_G_INFO, "ITS: ignoring MOVALL command\n");
> +break;
> +case GITS_CMD_MOVI:
> +its_handle_movi(its, cmdptr);
> +break;
>  case GITS_CMD_SYNC:
>  /* We handle ITS commands synchronously, so we ignore SYNC. */
>   break;
> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
> index 3b2e5c0..7e1142f 100644
> --- a/xen/include/asm-arm/gic-its.h
> +++ b/xen/include/asm-arm/gic-its.h
> @@ -133,6 +133,7 @@ int gicv3_its_map_device(struct host_its *hw_its, struct 
> domain *d,
>  int gicv3_lpi_allocate_host_lpi(struct host_its *its,
>  uint32_t devid, uint32_t eventid,
>  struct vcpu *v, int virt_lpi);
> +int gicv3_lpi_change_vcpu(struct domain *d, uint32_t host_lpi, int 
> new_vcpu_id);
>  int gicv3_lpi_drop_host_lpi(struct host_its *its,
>  uint32_t devid, uint32_t eventid,
>  uint32_t host_lpi);
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [RFC PATCH 17/24] ARM: vITS: handle MAPTI command

On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
> pair and actually instantiates LPI interrupts.
> We allocate a new host LPI and connect that one to this virtual LPI,
> so that any triggering IRQ on the host can be quickly forwarded to
> a guest.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-its.c | 53 
> +
>  1 file changed, 53 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 83d47e1..70897dd 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -278,6 +278,55 @@ static int its_handle_mapd(struct virt_its *its, 
> uint64_t *cmdptr)
>  return 0;
>  }
>  
> +static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +uint32_t eventid = its_cmd_get_id(cmdptr);
> +uint32_t intid = its_cmd_get_physical_id(cmdptr);
> +int collid = its_cmd_get_collection(cmdptr);
> +struct vits_itte *itte;
> +uint32_t host_lpi;
> +struct vcpu *vcpu;
> +int ret = -1;
> +
> +if ( its_cmd_get_command(cmdptr) == GITS_CMD_MAPI )
> +intid = eventid;
> +
> +if ( collid >= its->max_collections )
> +return -1;
> +
> +spin_lock(>its_lock);
> +vcpu = get_vcpu_from_collection(its, collid);
> +if ( !vcpu )
> +goto out_unlock;
> +
> +itte = get_devid_evid(its, devid, eventid);
> +if ( !itte )
> +goto out_unlock;
> +
> +if ( itte->hlpi )
> +goto out_unmap;

get_vcpu_from_collection and get_devid_evid take care of checking the
validity of devid, eventid and collid. Do we need to also check that
devid, eventid and intid are valid from a host perspective, given that
we are calling gicv3_lpi_allocate_host_lpi?


> +host_lpi = gicv3_lpi_allocate_host_lpi(its->hw_its,
> +   devid, eventid,
> +   vcpu, intid);
> +if ( host_lpi >= 0 )
> +itte->hlpi = host_lpi;
> +
> +itte->vlpi = intid;
> +itte->collection = collid;
> +
> +ret = 0;
> +
> +out_unmap:
> +put_devid_evid(its, itte);
> +
> +out_unlock:
> +spin_unlock(>its_lock);
> +
> +return ret;
> +}
> +
>  #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>  
>  static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -310,6 +359,10 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
> virt_its *its,
>  case GITS_CMD_MAPD:
>  its_handle_mapd(its, cmdptr);
>   break;
> +case GITS_CMD_MAPI:
> +case GITS_CMD_MAPTI:
> +its_handle_mapti(its, cmdptr);
> +break;
>  case GITS_CMD_SYNC:
>  /* We handle ITS commands synchronously, so we ignore SYNC. */
>   break;
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [RFC PATCH 16/24] ARM: vITS: handle MAPD command

On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MAPD command maps a device by associating a memory region for
> storing ITTEs with a certain device ID.
> We just store the given guest physical address in the device table.
> We don't map the device tables permanently, as their alignment
> requirement is only 256 Bytes, thus making mapping of several tables
> complicated. We map the device tables on demand when we need them later.
> 
> Also we propagate the MAPD request to the hardware ITS, as the device ID
> is only meaningful there.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-its.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index caad320..83d47e1 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -250,6 +250,34 @@ static int its_handle_mapc(struct virt_its *its, 
> uint64_t *cmdptr)
>  return ret;
>  }
>  
> +static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +int size = its_cmd_get_size(cmdptr);
> +bool valid = its_cmd_get_validbit(cmdptr);
> +paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) & GENMASK(51, 8);
> +
> +if ( !its->dev_table )
> +return -1;

We should validate devid, size and itt_addr?


> +spin_lock(>its_lock);
> +if ( valid )
> +its->dev_table[devid] = DEV_TABLE_ENTRY(itt_addr, size + 1);
> +else
> +its->dev_table[devid] = 0;
> +
> +spin_unlock(>its_lock);
> +
> +/* DomUs (will later) have their ITTs allocated at domain creation time,
> + * when Dom0 configures the passthrough.
> + */
> +if ( its->hw_its )
> +return gicv3_its_map_device(its->hw_its,
> +its->d, devid, size + 1, valid);
> +
> +return 0;
> +}
> +
>  #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>  
>  static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -279,6 +307,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
> virt_its *its,
>  case GITS_CMD_MAPC:
>  its_handle_mapc(its, cmdptr);
>  break;
> +case GITS_CMD_MAPD:
> +its_handle_mapd(its, cmdptr);
> + break;
>  case GITS_CMD_SYNC:
>  /* We handle ITS commands synchronously, so we ignore SYNC. */
>   break;
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [RFC PATCH 15/24] ARM: vITS: handle MAPC command

On Wed, 28 Sep 2016, Andre Przywara wrote:
> The MAPC command associates a given collection ID with a given
> redistributor, thus mapping collections to VCPUs.
> We just store the vcpu_id in the collection table for that.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-its.c | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 7072753..caad320 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -223,6 +223,33 @@ out_unlock:
>  return ret;
>  }
>  
> +static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t collid = its_cmd_get_collection(cmdptr);
> +uint64_t rdbase = its_cmd_mask_field(cmdptr, 2, 16, 44);
> +int ret = -1;

I take 44 is a bit arbitrary here? It might be best to #define it.


> +if ( collid >= its->max_collections )
> +return ret;
> +
> +if ( rdbase >= its->d->max_vcpus )
> +return ret;
> +
> +spin_lock(>its_lock);
> +if ( its->coll_table )
> +{
> +if ( its_cmd_get_validbit(cmdptr) )
> +its->coll_table[collid] = rdbase;
> +else
> +its->coll_table[collid] = UNMAPPED_COLLECTION;
> +
> +ret = 0;
> +}
> +spin_unlock(>its_lock);
> +
> +return ret;
> +}
> +
>  #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>  
>  static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -249,6 +276,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
> virt_its *its,
>  case GITS_CMD_INT:
>  its_handle_int(its, cmdptr);
>  break;
> +case GITS_CMD_MAPC:
> +its_handle_mapc(its, cmdptr);
> +break;
>  case GITS_CMD_SYNC:
>  /* We handle ITS commands synchronously, so we ignore SYNC. */
>   break;
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [RFC PATCH 14/24] ARM: vITS: handle INT command

On Wed, 28 Sep 2016, Andre Przywara wrote:
> The INT command sets a given LPI identified by a DeviceID/EventID pair
> as pending and thus triggers it to be injected.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-its.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 99d9e9c..7072753 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -192,6 +192,37 @@ static int its_handle_clear(struct virt_its *its, 
> uint64_t *cmdptr)
>  return 0;
>  }
>  
> +static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +uint32_t eventid = its_cmd_get_id(cmdptr);
> +struct vits_itte *itte;
> +struct vcpu *vcpu;
> +int ret = -1;
> +uint32_t vlpi;
> +
> +spin_lock(>its_lock);
> +
> +itte = get_devid_evid(its, devid, eventid);
> +if ( !itte )
> +goto out_unlock;
> +
> +vcpu = its->d->vcpu[itte->collection];

We need to check that itte->collection is a valid vcpu before using as
array index.


> +vlpi = itte->vlpi;
> +
> +ret = 0;
> +
> +put_devid_evid(its, itte);
> +
> +out_unlock:
> +spin_unlock(>its_lock);
> +
> +if ( !ret)

code style


> +vgic_vcpu_inject_irq(vcpu, vlpi);
> +
> +return ret;
> +}
> +
>  #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>  
>  static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -215,6 +246,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
> virt_its *its,
>  case GITS_CMD_CLEAR:
>  its_handle_clear(its, cmdptr);
>  break;
> +case GITS_CMD_INT:
> +its_handle_int(its, cmdptr);
> +break;
>  case GITS_CMD_SYNC:
>  /* We handle ITS commands synchronously, so we ignore SYNC. */
>   break;
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [RFC PATCH 13/24] ARM: vITS: handle CLEAR command

On Wed, 28 Sep 2016, Andre Przywara wrote:
> This introduces the ITS command handler for the CLEAR command, which
> clears the pending state of an LPI.
> This removes a not-yet injected, but already queued IRQ from a VCPU.
> 
> In addition this patch introduces the lookup function which translates
> a given DeviceID/EventID pair into a pointer to our vITTE structure.
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/vgic-its.c | 115 
> 
>  1 file changed, 115 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 875b992..99d9e9c 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -61,6 +61,73 @@ struct vits_itte
>  uint64_t collection:16;
>  };
>  
> +#define UNMAPPED_COLLECTION  ((uint16_t)~0)
> +
> +/* Must be called with the ITS lock held. */
> +static struct vcpu *get_vcpu_from_collection(struct virt_its *its, int 
> collid)
> +{
> +uint16_t vcpu_id;
> +
> +if ( collid >= its->max_collections )
> +return NULL;
> +
> +vcpu_id = its->coll_table[collid];
> +if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
> +return NULL;
> +
> +return its->d->vcpu[vcpu_id];
> +}
> +
> +#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
> +#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(7, 0)) + 1))
> +#define DEV_TABLE_ENTRY(addr, bits) \
> +(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(7, 0)))
> +
> +static paddr_t get_itte_address(struct virt_its *its,
> +uint32_t devid, uint32_t evid)
> +{
> +paddr_t addr;
> +
> +if ( devid >= its->max_devices )
> +return ~0;

Please #define the error


> +if ( evid >= DEV_TABLE_ITT_SIZE(its->dev_table[devid]) )
> +return ~0;

same here


> +addr = DEV_TABLE_ITT_ADDR(its->dev_table[devid]);
> +
> +return addr + evid * sizeof(struct vits_itte);
> +}
> +
> +/* Looks up a given deviceID/eventID pair on an ITS and returns a pointer to
> + * the corresponding ITTE. This maps the respective guest page into Xen.
> + * Once finished with handling the ITTE, call put_devid_evid() to unmap
> + * the page again.
> + * Must be called with the ITS lock held.
> + */
> +static struct vits_itte *get_devid_evid(struct virt_its *its,
> +uint32_t devid, uint32_t evid)
> +{
> +paddr_t addr = get_itte_address(its, devid, evid);
> +struct vits_itte *itte;
> +
> +if (addr == ~0)
> +return NULL;
> +
> +/* TODO: check locking for map_guest_pages() */
> +itte = map_guest_pages(its->d, addr & PAGE_MASK, 1);
> +if ( !itte )
> +return NULL;

No need to use the vmap to map 1 page


> +return itte + (addr & ~PAGE_MASK) / sizeof(struct vits_itte);

Please use () around the div operation for clarity


> +}
> +
> +/* Must be called with the ITS lock held. */
> +static void put_devid_evid(struct virt_its *its, struct vits_itte *itte)
> +{
> +unmap_guest_pages(itte, 1);

No need for this, once you use __pa instead of the vmap


> +}
> +
>  /**
>   * Functions that handle ITS commands *
>   **/
> @@ -80,6 +147,51 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
>  #define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
>  #define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
>  
> +static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +uint32_t eventid = its_cmd_get_id(cmdptr);
> +struct pending_irq *pirq;
> +struct vits_itte *itte;
> +struct vcpu *vcpu;
> +uint32_t vlpi;
> +
> +spin_lock(>its_lock);
> +
> +itte = get_devid_evid(its, devid, eventid);
> +if ( !itte )
> +{
> +spin_unlock(>its_lock);
> +return -1;
> +}
> +
> +vcpu = get_vcpu_from_collection(its, itte->collection);
> +if ( !vcpu )
> +{
> +spin_unlock(>its_lock);
> +return -1;
> +}
> +
> +vlpi = itte->vlpi;
> +
> +put_devid_evid(its, itte);
> +spin_unlock(>its_lock);
> +
> +/* Remove a pending, but not yet injected guest IRQ. */

We need to check that the vlpi hasn't already been added to an LR
register. We can do that with GIC_IRQ_GUEST_VISIBLE.

In case GIC_IRQ_GUEST_VISIBLE is set, we need to clear the lr
(clear_lr). If we don't handle this case, we should at least print a
warning.


> +pirq = lpi_to_pending(vcpu, vlpi, false);
> +if ( pirq )
> +{
> +clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
> +gic_remove_from_queues(vcpu, vlpi);
> +
> +/* Mark this pending IRQ struct as availabe again. */
> +if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
> +pirq->irq = 0;
> +}
> +
> +return 0;
> +}
> +
>  #define

Re: [Xen-devel] [PATCH 05/12] xen: make use of xenbus_read_unsigned() in xen-kbdfront

2016-11-08 Thread Dmitry Torokhov

On Mon, Oct 31, 2016 at 05:48:23PM +0100, Juergen Gross wrote:
> Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
> This requires to change the type of the reads from int to unsigned,
> but these cases have been wrong before: negative values are not allowed
> for the modified cases.
> 
> Cc: dmitry.torok...@gmail.com
> Cc: linux-in...@vger.kernel.org
> 
> Signed-off-by: Juergen Gross 

Acked-by: Dmitry Torokhov 

> ---
>  drivers/input/misc/xen-kbdfront.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 227fbd2..3900875 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -108,7 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>  static int xenkbd_probe(struct xenbus_device *dev,
> const struct xenbus_device_id *id)
>  {
> - int ret, i, abs;
> + int ret, i;
> + unsigned int abs;
>   struct xenkbd_info *info;
>   struct input_dev *kbd, *ptr;
>  
> @@ -127,8 +128,7 @@ static int xenkbd_probe(struct xenbus_device *dev,
>   if (!info->page)
>   goto error_nomem;
>  
> - if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", 
> ) < 0)
> - abs = 0;
> + abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
>   if (abs) {
>   ret = xenbus_write(XBT_NIL, dev->nodename,
>  "request-abs-pointer", "1");
> @@ -322,11 +322,8 @@ static void xenkbd_backend_changed(struct xenbus_device 
> *dev,
>  
>   case XenbusStateInitWait:
>  InitWait:
> - ret = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> -"feature-abs-pointer", "%d", );
> - if (ret < 0)
> - val = 0;
> - if (val) {
> + if (xenbus_read_unsigned(info->xbdev->otherend,
> +  "feature-abs-pointer", 0)) {
>   ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
>  "request-abs-pointer", "1");
>   if (ret)
> -- 
> 2.6.6
> 

-- 
Dmitry

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

[Xen-devel] [ovmf baseline-only test] 68015: all pass

2016-11-08 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 68015 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68015/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d66f85cb5eed5c218d822204897a78bab53fc157
baseline version:
 ovmf 2998af862469c6a05657e169d7def6f55420caad

Last test of basis68012  2016-11-08 04:50:39 Z0 days
Testing same since68015  2016-11-08 13:17:19 Z0 days1 attempts


People who touched revisions under test:
  Hegde Nagaraj P 
  hegdenag 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.


commit d66f85cb5eed5c218d822204897a78bab53fc157
Author: hegdenag 
Date:   Mon Nov 7 00:40:48 2016 -0800

ShellPkg/Ping6: Add a note in help for TargetIp

'Ping6 TargetIp' is a valid command input but we bail out
when TargetIp is a link local address because we would want
the user to specify the NIC (via SourceIp) through which
he/she would want to ping to TargetIp. This patch updates
the help text to mention the same.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hegde Nagaraj P 
Reviewed-by: Jaben Carsey 

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

Re: [Xen-devel] [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits

On Wed, 28 Sep 2016, Andre Przywara wrote:
> Create a new file to hold the emulation code for the ITS widget.
> For now we emulate the memory mapped ITS registers and provide a stub
> to introduce the ITS command handling framework (but without actually
> emulating any commands at this time).
> 
> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/Makefile |   1 +
>  xen/arch/arm/vgic-its.c   | 378 
> ++
>  xen/arch/arm/vgic-v3.c|   9 -
>  xen/include/asm-arm/gic_v3_defs.h |  19 ++
>  4 files changed, 398 insertions(+), 9 deletions(-)
>  create mode 100644 xen/arch/arm/vgic-its.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index c2c4daa..cb0201f 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -44,6 +44,7 @@ obj-y += traps.o
>  obj-y += vgic.o
>  obj-y += vgic-v2.o
>  obj-$(CONFIG_ARM_64) += vgic-v3.o
> +obj-$(CONFIG_HAS_ITS) += vgic-its.o
>  obj-y += vm_event.o
>  obj-y += vtimer.o
>  obj-y += vpsci.o
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> new file mode 100644
> index 000..875b992
> --- /dev/null
> +++ b/xen/arch/arm/vgic-its.c
> @@ -0,0 +1,378 @@
> +/*
> + * xen/arch/arm/vgic-its.c
> + *
> + * ARM Interrupt Translation Service (ITS) emulation
> + *
> + * Andre Przywara 
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Data structure to describe a virtual ITS */
> +struct virt_its {
> +struct domain *d;
> +struct host_its *hw_its;
> +spinlock_t vcmd_lock;   /* protects the virtual command buffer */
> +uint64_t cbaser;
> +uint64_t *cmdbuf;
> +int cwriter;
> +int creadr;
> +spinlock_t its_lock;/* protects the collection and device tables 
> */
> +uint64_t baser0, baser1;
> +uint16_t *coll_table;
> +int max_collections;
> +uint64_t *dev_table;
> +int max_devices;
> +bool enabled;
> +};
> +
> +/* An Interrupt Translation Table Entry: this is indexed by a
> + * DeviceID/EventID pair and is located in guest memory.
> + */
> +struct vits_itte
> +{
> +uint64_t hlpi:24;
> +uint64_t vlpi:24;
> +uint64_t collection:16;
> +};
> +
> +/**
> + * Functions that handle ITS commands *
> + **/
> +
> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
> +   int word, int shift, int size)
> +{
> +return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
> +}
> +
> +#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
> +#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
> +#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
> +#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
> +#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
> +#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
> +#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
> +#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
> +
> +#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
> +
> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> +uint32_t writer)
> +{
> +uint64_t *cmdptr;
> +
> +if ( !its->cmdbuf )
> +return -1;
> +
> +if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
> +return -1;
> +
> +spin_lock(>vcmd_lock);
> +
> +while ( its->creadr != writer )
> +{
> +cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
> +
> +switch (its_cmd_get_command(cmdptr))
> +{
> +case GITS_CMD_SYNC:
> +/* We handle ITS commands synchronously, so we ignore SYNC. */
> + break;

indentation


> +default:
> +gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
> +   its_cmd_get_command(cmdptr));
> +break;
> +}
> +
> +its->creadr += ITS_CMD_SIZE;
> +if ( its->creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
> +its->creadr =

Re: [Xen-devel] Error migrating VM to secondary host using COLO replication

2016-11-08 Thread Sadi

Hi,

Apparently vif2.0-emu was already binded with br0 when "brctl addif br0
vif2.0-emu" failed.

root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl addif br0 vif2.0-emu
device vif2.0-emu is already a member of a bridge; can't enslave it to
bridge br0.
root@colob-HP-Compaq-6005-Pro-MT-PC:~# brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.001a3fc46255   no  eth0
vif2.0
vif2.0-emu
br1 8000.   no

About the iptables, it seems like SECCOLO target can't be recognised.

root@colob-HP-Compaq-6005-Pro-MT-PC:~# iptables -t mangle -D PREROUTING -m
physdev --physdev-in vif2.0-emu -j SECCOLO --index 1
iptables: No chain/target/match by that name.

Here is my active modules matching colo:

root@colob-HP-Compaq-6005-Pro-MT-PC:~# lsmod | grep -i colo
xt_SECCOLO 16384  1
nf_conntrack_colo  16384  2 xt_SECCOLO
x_tables   36864  8
xt_physdev,ip6table_mangle,ip_tables,xt_SECCOLO,xt_tcpudp,iptable_filter,iptable_mangle,ip6_tables
nf_conntrack  106496  4
xt_SECCOLO,nf_nat,nf_conntrack_colo,nf_conntrack_ipv4

So i was looking in the iptables and this really looks like the source of
the problem.

Sadi.

On Tue, Nov 8, 2016 at 5:57 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:

> > entered forwarding state
> > Nov  7 18:10:30 colob NetworkManager[907]:   (vif2.0-emu): enslaved
> > to br0
> > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: brctl
> addif
> > br0 vif2.0-emu failed
>
>
> How come this failed?
>
> > Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: iptables
> -t
> > mangle -D PREROUTING -m physdev --physdev-in vif2.0-emu -j SECCOLO
> --index
> > 1 failed
>
> Ah b/c of this. Are there any errors of what exactly failed?
>

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

[Xen-devel] [ovmf test] 102036: all pass - PUSHED

flight 102036 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102036/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf fef15ecd20dd8db5bf0c33b00908fc59491dba8a
baseline version:
 ovmf d66f85cb5eed5c218d822204897a78bab53fc157

Last test of basis   102029  2016-11-08 04:46:30 Z0 days
Testing same since   102036  2016-11-08 12:14:46 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 
  Hao Wu 
  Maurice Ma 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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=ovmf
+ revision=fef15ecd20dd8db5bf0c33b00908fc59491dba8a
+ . ./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 ovmf 
fef15ecd20dd8db5bf0c33b00908fc59491dba8a
+ branch=ovmf
+ revision=fef15ecd20dd8db5bf0c33b00908fc59491dba8a
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xfef15ecd20dd8db5bf0c33b00908fc59491dba8a = 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
++ :

[Xen-devel] [distros-debian-snapshot test] 68013: tolerable FAIL

2016-11-08 Thread Platform Team regression test user

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 67973
 test-amd64-amd64-i386-daily-netboot-pygrub 9 debian-di-install fail like 67973
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail like 67973
 test-amd64-i386-i386-daily-netboot-pvgrub  9 debian-di-install fail like 67973
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail like 67973
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 67973
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 67973
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 67973
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
67973

baseline version:
 flight   67973

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-xsm  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt  11 guest-start  fail REGR. vs. 101909
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 101909
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 101909
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
101909
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt 11 guest-start  fail REGR. vs. 101909
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 101909
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101909

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

Tests which did not succeed, but are not blocking:
 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-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-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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

version targeted for testing:
 qemuu207faf24c58859f5240f66bf6decc33b87a1776e
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z4 days
Failing since101943  2016-11-04 22:40:48 Z3 days6 attempts
Testing same since   102031  2016-11-08 07:59:22 Z0 days1 attempts


People who touched revisions under test:
  Christian Borntraeger 
  Cornelia Huck 
  Julian Brown 
  Marcin Krzeminski 
  Olaf Hering 
  Peter Maydell 
  Prasad J Pandit 
  Sander Eikelenboom 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Thomas Huth 
  Wei Liu 

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  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass

[Xen-devel] [PULL] xen: Fix xenpv machine initialisation

From: Anthony PERARD 

When using QEMU for Xen PV guest, QEMU abort with:
xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type 
generic-pc-machine

This is because the machine 'xenpv' also use accel=xen. Moving the code
to xen_hvm_init() fix the issue.

This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae.

Signed-off-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Stefano Stabellini 
---
 xen-common.c | 6 --
 xen-hvm.c| 4 
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen-common.c b/xen-common.c
index bacf962..9099760 100644
--- a/xen-common.c
+++ b/xen-common.c
@@ -9,7 +9,6 @@
  */
 
 #include "qemu/osdep.h"
-#include "hw/i386/pc.h"
 #include "hw/xen/xen_backend.h"
 #include "qmp-commands.h"
 #include "sysemu/char.h"
@@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int 
running,
 
 static int xen_init(MachineState *ms)
 {
-PCMachineState *pcms = PC_MACHINE(ms);
-
-/* Disable ACPI build because Xen handles it */
-pcms->acpi_build_enabled = false;
-
 xen_xc = xc_interface_open(0, 0, 0);
 if (xen_xc == NULL) {
 xen_pv_printf(NULL, 0, "can't open xen interface\n");
diff --git a/xen-hvm.c b/xen-hvm.c
index 2f348ed..150c7e7 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 }
 xen_be_register_common();
 xen_read_physmap(state);
+
+/* Disable ACPI build because Xen handles it */
+pcms->acpi_build_enabled = false;
+
 return;
 
 err:
-- 
1.9.1


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

[Xen-devel] [PULL 0/1] tags/xen-20161108-tag

The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e:

  Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into 
staging (2016-11-07 14:02:15 +)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161108-tag

for you to fetch changes up to 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5:

  xen: Fix xenpv machine initialisation (2016-11-08 11:17:30 -0800)


Xen 2016/11/08


Anthony PERARD (1):
  xen: Fix xenpv machine initialisation

 xen-common.c | 6 --
 xen-hvm.c| 4 
 2 files changed, 4 insertions(+), 6 deletions(-)

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

Re: [Xen-devel] Error migrating VM to secondary host using COLO replication

2016-11-08 Thread Konrad Rzeszutek Wilk

> entered forwarding state
> Nov  7 18:10:30 colob NetworkManager[907]:   (vif2.0-emu): enslaved
> to br0
> Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: brctl addif
> br0 vif2.0-emu failed


How come this failed?

> Nov  7 18:10:30 colob root: /etc/xen/scripts/colo-proxy-setup: iptables -t
> mangle -D PREROUTING -m physdev --physdev-in vif2.0-emu -j SECCOLO --index
> 1 failed

Ah b/c of this. Are there any errors of what exactly failed?

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

[Xen-devel] [PATCH v3 0/2] Fix Xen boot on XGene

Hi all,

the following commit:

commit 21550029f709072aacf3b90edd574e7d3021b400
Author: Julien Grall 
Date:   Thu Oct 8 19:23:53 2015 +0100

xen/arm: gic-v2: Automatically detect aliased GIC400


removed PLATFORM_QUIRK_GIC_64K_STRIDE and introduced an heuristic to
check whether the two GICC pages have a 64K stride. However the
heuristic needs device tree to report a GICC region size of 128K to work
properly. That is not the case for some versions of XGene (including the
one I am using, kindly provided by CloudLab.us).

The patch series fixes the issue by reintroducing platform quirks,
PLATFORM_QUIRK_GIC_64K_STRIDE, and forcing GICC size to 128K if
PLATFORM_QUIRK_GIC_64K_STRIDE.

We should consider this series for 4.8. 


Changes in v3:
- add a warning when enabling the quirk
- update comment to match the new behavior of the quirk

Changes in v2:
- only set csize to SZ_128K if it is initially SZ_4K
- set vsize to match
- add warning if gicc is SZ_128K and not aliased


Stefano Stabellini (2):
  Revert "xen/arm: platform: Drop the quirks callback"
  Partially revert 21550029f709072aacf3b90edd574e7d3021b400

 xen/arch/arm/gic-v2.c| 12 ++--
 xen/arch/arm/platform.c  | 10 ++
 xen/arch/arm/platforms/xgene-storm.c |  6 ++
 xen/include/asm-arm/platform.h   | 14 ++
 4 files changed, 40 insertions(+), 2 deletions(-)

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

[Xen-devel] [PATCH v3 1/2] Revert "xen/arm: platform: Drop the quirks callback"

This reverts commit 14fa16961b03a23e9b883e5f0ed06b6837a489d8.
Do not reintroduce platform_dom0_evtchn_ppi.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 
Release-acked-by: Wei Liu 
---
 xen/arch/arm/platform.c| 10 ++
 xen/include/asm-arm/platform.h |  7 +++
 2 files changed, 17 insertions(+)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index b0bfaa9..0af6d57 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,6 +127,16 @@ void platform_poweroff(void)
 platform->poweroff();
 }
 
+bool_t platform_has_quirk(uint32_t quirk)
+{
+uint32_t quirks = 0;
+
+if ( platform && platform->quirks )
+quirks = platform->quirks();
+
+return !!(quirks & quirk);
+}
+
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
 {
 const struct dt_device_match *blacklist = NULL;
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index f97315d..c6e5010 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -27,6 +27,12 @@ struct platform_desc {
 /* Platform power-off */
 void (*poweroff)(void);
 /*
+ * Platform quirks
+ * Defined has a function because a platform can support multiple
+ * board with different quirk on each
+ */
+uint32_t (*quirks)(void);
+/*
  * Platform blacklist devices
  * List of devices which must not pass-through to a guest
  */
@@ -42,6 +48,7 @@ int platform_cpu_up(int cpu);
 #endif
 void platform_reset(void);
 void platform_poweroff(void);
+bool_t platform_has_quirk(uint32_t quirk);
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node);
 
 #define PLATFORM_START(_name, _namestr) \
-- 
1.9.1


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

[Xen-devel] [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400

Commit 21550029f709072aacf3b90edd574e7d3021b400 removed the
PLATFORM_QUIRK_GIC_64K_STRIDE quirk and introduced a way to
automatically detect that the two GICC pages have a 64K stride.

However the heuristic requires that the device tree for the platform
reports a GICC size == 128K, which is not the case for some versions of
XGene.

Fix the issue by partially reverting
21550029f709072aacf3b90edd574e7d3021b400:

- reintroduce PLATFORM_QUIRK_GIC_64K_STRIDE for XGene
- force csize and vsize to SZ_128K if csize is initially 4K and if
  PLATFORM_QUIRK_GIC_64K_STRIDE

Also add a warning in case GICC is SZ_128K but not aliased.

Signed-off-by: Stefano Stabellini 
Release-acked-by: Wei Liu 

---

Changes in v3:
- add a warning when enabling the quirk
- update comment to match the new behavior of the quirk

Changes in v2:
- only set csize to SZ_128K if it is initially SZ_4K
- set vsize to match
- add warning if gicc is SZ_128K and not aliased
---
 xen/arch/arm/gic-v2.c| 12 ++--
 xen/arch/arm/platforms/xgene-storm.c |  6 ++
 xen/include/asm-arm/platform.h   |  7 +++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 9bd9d0b..bca6d27 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -965,7 +965,12 @@ static void __init gicv2_dt_init(void)
 printk(XENLOG_WARNING "GICv2: WARNING: "
"The GICC size is too small: %#"PRIx64" expected %#x\n",
csize, SZ_8K);
-csize = SZ_8K;
+if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
+{
+printk(XENLOG_WARNING "GICv2: enable platform quirk: 64K 
stride\n");
+vsize = csize = SZ_128K;
+} else
+csize = SZ_8K;
 }
 
 /*
@@ -1189,7 +1194,10 @@ static int __init gicv2_init(void)
 printk(XENLOG_WARNING
"GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
cbase + aliased_offset);
-}
+} else if ( csize == SZ_128K )
+printk(XENLOG_WARNING
+"GICv2: GICC size=%lu but not aliased\n",
+csize);
 
 gicv2.map_hbase = ioremap_nocache(hbase, PAGE_SIZE);
 if ( !gicv2.map_hbase )
diff --git a/xen/arch/arm/platforms/xgene-storm.c 
b/xen/arch/arm/platforms/xgene-storm.c
index 686b19b..c795a95 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -67,6 +67,11 @@ static void __init xgene_check_pirq_eoi(void)
   "Please upgrade your firmware to the latest version");
 }
 
+static uint32_t xgene_storm_quirks(void)
+{
+return PLATFORM_QUIRK_GIC_64K_STRIDE;
+}
+
 static void xgene_storm_reset(void)
 {
 void __iomem *addr;
@@ -116,6 +121,7 @@ PLATFORM_START(xgene_storm, "APM X-GENE STORM")
 .compatible = xgene_storm_dt_compat,
 .init = xgene_storm_init,
 .reset = xgene_storm_reset,
+.quirks = xgene_storm_quirks,
 PLATFORM_END
 
 /*
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index c6e5010..08010ba 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -39,6 +39,13 @@ struct platform_desc {
 const struct dt_device_match *blacklist_dev;
 };
 
+/*
+ * Quirk for platforms where device tree incorrectly reports 4K GICC
+ * size, but actually the two GICC register ranges are placed at 64K
+ * stride.
+ */
+#define PLATFORM_QUIRK_GIC_64K_STRIDE (1 << 0)
+
 void __init platform_init(void);
 int __init platform_init_time(void);
 int __init platform_specific_mapping(struct domain *d);
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] stubdom: remove EXTRA_CFLAGS meant for building tools

2016-11-08 Thread Samuel Thibault

Wei Liu, on Tue 08 Nov 2016 10:47:18 +, wrote:
> On Tue, Nov 08, 2016 at 10:09:41AM +0100, Juergen Gross wrote:
> > When building stubdoms EXTRA_CFLAGS_XEN_TOOLS and
> > EXTRA_CFLAGS_QEMU_TRADITIONAL should be cleared as they might contain
> > flags not suitable for all stubdom builds (e.g. "-m64" often to be
> > found in $RPM_OPT_FLAGS will break building 32 bit stubdoms).
> > 
> > Signed-off-by: Juergen Gross 
> > ---
> >  stubdom/Makefile | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/stubdom/Makefile b/stubdom/Makefile
> > index 2921f30..c89e353 100644
> > --- a/stubdom/Makefile
> > +++ b/stubdom/Makefile
> > @@ -4,6 +4,10 @@ MINI_OS = $(XEN_ROOT)/extras/mini-os
> >  export XEN_ROOT
> >  export XEN_OS=MiniOS
> >  
> > +# Remove flags which are meant for tools, e.g. "-m64"
> > +export EXTRA_CFLAGS_XEN_TOOLS=
> > +export EXTRA_CFLAGS_QEMU_TRADITIONAL=
> > +
> 
> I can't think of a better way to deal with this. This is in line with
> how it is done in firmware build, so
> 
> Acked-by: Wei Liu 

Acked-by: Samuel Thibault 

> >  export stubdom=y
> >  export debug=y
> >  # Moved from config/StdGNU.mk
> > -- 
> > 2.6.6
> > 
> 

-- 
Samuel
* D a decide de peter un cable dans son rapport de pfp
 et il a bien raison ;-)
 tu vas dire quoi ?
 j'ai mis les paroles de "le coq est mort" en en-tete
 -+- #ens-mim et la peufeupeu -+-

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

Re: [Xen-devel] [PATCH v2] xen: Fix xenpv machine initialisation

On Tue, 8 Nov 2016, Anthony PERARD wrote:
> When using QEMU for Xen PV guest, QEMU abort with:
> xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type 
> generic-pc-machine
> 
> This is because the machine 'xenpv' also use accel=xen. Moving the code
> to xen_hvm_init() fix the issue.
> 
> This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Stefano Stabellini 


> CC: Wei Liu 
> CC: Eduardo Habkost 
> ---
>  xen-common.c | 6 --
>  xen-hvm.c| 4 
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/xen-common.c b/xen-common.c
> index bacf962..9099760 100644
> --- a/xen-common.c
> +++ b/xen-common.c
> @@ -9,7 +9,6 @@
>   */
>  
>  #include "qemu/osdep.h"
> -#include "hw/i386/pc.h"
>  #include "hw/xen/xen_backend.h"
>  #include "qmp-commands.h"
>  #include "sysemu/char.h"
> @@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int 
> running,
>  
>  static int xen_init(MachineState *ms)
>  {
> -PCMachineState *pcms = PC_MACHINE(ms);
> -
> -/* Disable ACPI build because Xen handles it */
> -pcms->acpi_build_enabled = false;
> -
>  xen_xc = xc_interface_open(0, 0, 0);
>  if (xen_xc == NULL) {
>  xen_pv_printf(NULL, 0, "can't open xen interface\n");
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 2f348ed..150c7e7 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
> **ram_memory)
>  }
>  xen_be_register_common();
>  xen_read_physmap(state);
> +
> +/* Disable ACPI build because Xen handles it */
> +pcms->acpi_build_enabled = false;
> +
>  return;
>  
>  err:
> -- 
> Anthony PERARD
> 

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

Re: [Xen-devel] [PATCH 01/10] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

2016-11-08 Thread Daniel De Graaf


On 11/06/2016 04:42 PM, Boris Ostrovsky wrote:

This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set'). While this currently is only intended to be needed by
PVH guests we will call this domctl for all (x86) guests for consistency.

Signed-off-by: Boris Ostrovsky 


Acked-by: Daniel De Graaf 

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

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

2016-11-08 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 68002
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot fail REGR. vs. 68002
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 leak-check/check fail REGR. vs. 
68002

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   like 68002
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   like 68002
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   like 68002
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   like 68002
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   like 68002
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68002
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68002
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68002
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68002

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-rumprun6 xen-buildfail   never pass
 build-amd64-rumprun   6 xen-buildfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-xsm 12 migrate-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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-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-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  8a35a95615b1a64c98c30195f343bc2c58054d9d
baseline version:
 xen  3ebe9a1a826e8d569bef6045777cc01a5699933d

Last test of basis68002  2016-11-05 12:44:12 Z3 days
Testing same since68011  2016-11-08 04:50:39 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64-xsm  pass

Re: [Xen-devel] CPUID improvements (phase 2) Design Doc

2016-11-08 Thread Andrew Cooper

On 08/11/16 16:32, Jan Beulich wrote:
 On 08.11.16 at 16:35,  wrote:
>> Please find inline the design doc for further CPUID improvements, planned for
>> development during the 4.9 timeframe.
> Looks good, just a couple of minor remarks.
>
>> ## Changes in hypercall behaviour
>>
>> During domain construction, some pieces of information critical to the
>> determination of the domains maximum acceptable CPUID policy are available
>> right from the very start (Most notably, the HVM and HAP flags from the
>> `XEN_DOMCTL_createdomain`).
>>
>> However, some other parameters are not available at convenient points.
>>
>> 1.  The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
>> `d->disable_migrate`, whose only purpose is to avoid the unconditional
>> clobbering of the Invariant TSC flag.  This flag cannot even be queried 
>> by
>> the toolstack once set.
>>
>> There are other facilities which should be restricted based on whether a
>> VM might migrate or not.  (e.g. The use of LBR, whose record format is
>> hardware specific.)
> Not really - the LBR format only limits the set of hosts the VM can
> migrate to. I.e. this is just like a CPUID flag which needs to be set
> on the target host in order for the VM to be permitted to migrate
> there.

It is more complicated than that.  The LBR format also depends on
whether TSX is enabled or not, which on Haswell-WS CPUs depends on
whether hyperthreading is enabled.

ITSC itself is complicated.  If the toolstack can guarantee it only
migrates to hosts which support full TSC scaling, ITSC is still safe to
expose to the guest.

For situations like this, Xen should default safe (i.e. disable those
features), but still permit the toolstack to enable them on migrateable
VMs.  By having the toolstack explicitly opt in to enabling the unsafe
features for migratable VMs, it is taking on the added responsibility of
ensuring destination compatibility.

From an implementation point of view, this would work exactly like
choosing to use experiential features.  All we do in Xen is audit
against the maximum allowable featureset for a domain, not the default.

>
>> 2.  The use of `XEN_DOMCTL_set_address_size` switches a PV guest between
>> native (64bit) and compat (32bit) mode.  The current behaviour for 32bit
>> PV guests is to hide all 64bit-only features.
>>
>> Using this hypercall once to switch from native to compat is fairly easy
>> to cope with, feature wise, but using the hypercall a second time to
>> switch back causes the same ordering problems with respect to
>> `XEN_DOMCTL_set_address_size`.
>>
>> The preferred option here is to avoid hiding 32bit features.  This is 
>> more
>> architecturally correct, as a 32bit kernel running on 64bit-capable
>> hardware will see 64bit-only features.
> But the upside of hiding them is that the guest won't even try to play
> any long / 64-bit mode games (which wouldn't work anyway).

A PV guest already understands that it is running under Xen and can't
change its mode.  As such, not hiding the long mode features won't
affect the guest (even more so because we were never doing it
consistently before).

>
>>  Other options would be to modify
>> the API to make `XEN_DOMCTL_set_address_size` a single-shot hypercall
>> (which, given the existing restrictions, shouldn't impact any usecase),
> There must have been a reason why we had made it bi-directional,
> but I don't recall what it was. As long as no existing functionality is
> impacted, I think making this single-shot would be fine.

I am still hesitant of this route, because it is far less easy to be
confident that it is a safe change to make than to revert to
architectural feature behaviour.

~Andrew

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

Re: [Xen-devel] Xen ARM community call

On Tue, 8 Nov 2016, Julien Grall wrote:
> Hi all,
> 
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
> 
> Example of features that could be discussed:
>   - Sharing co-processor between guests
>   - PCI passthrough
> 
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd November.
> I know that people are spread across different timezones, so I would like to
> gather thought before choosing a time.

Hi Julien,

I would like to join, I am UTC-8.
Thanks for organizing this!

- Stefano

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

[Xen-devel] [xen-unstable test] 102027: regressions - FAIL

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 102008
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102008
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102008
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102008
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102008
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102008
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102008
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102008
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102008
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102008

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
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 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
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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

version targeted for testing:
 xen  bcb13635fa503113c981c6ea7423f930c1548452
baseline version:
 xen  8a35a95615b1a64c98c30195f343bc2c58054d9d

Last test of basis   102008  2016-11-07 16:52:13 Z1 days
Testing same since   102027  2016-11-08 04:30:42 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau MonnÃ© 
  Wei Liu 

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

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Edward Sandberg

I am interested, UTC -6.

On 11/08/2016 06:19 AM, Julien Grall wrote:
> Hi all,
> 
> I would like to start organizing a recurring community call to discuss
> and sync-up on upcoming features for Xen ARM.
> 
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough
> 
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
> 
> Your sincerely,
> 

-- 
Edward Sandberg
Adventium Labs
111 3rd Avenue S. Suite #100
Minneapolis, MN 55401
ed.sandb...@adventiumlabs.com



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

Re: [Xen-devel] [PATCH for-4.8] libxc: fix unmap of ACPI guest memory region

2016-11-08 Thread Boris Ostrovsky




On 11/08/2016 11:22 AM, Roger Pau Monne wrote:

Commit fac7f7 changed the value of ptr so that it points to the right memory
area, taking the page offset into account, but failed to remove this when
doing the unmap, which caused the region to not be unmapped. Fix this by not
modifying ptr and instead adding the page offset directly in the memcpy
call.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Ian Jackson 
---
 tools/libxc/xc_dom_core.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index ad819dd..36cd3c8 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1119,10 +1119,9 @@ static int xc_dom_load_acpi(struct xc_dom_image *dom)
 goto err;
 }

-ptr = (uint8_t *)ptr +
-  (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK);
-
-memcpy(ptr, dom->acpi_modules[i].data, dom->acpi_modules[i].length);
+memcpy((uint8_t *)ptr +
+   (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK),
+   dom->acpi_modules[i].data, dom->acpi_modules[i].length);
 munmap(ptr, XC_PAGE_SIZE * num_pages);

 free(extents);




Reviewed-by: Boris Ostrovsky 

(Although I don't think this would cause memory not to be unmapped: per 
Linux man page "All pages containing a part of the indicated range are 
unmapped ..." and ptr is offset from its original value by a fraction of 
a page.)


-boris

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

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Ruigrok, Richard


Please include me in the invite.   Mountain time (GMT-6)


On 11/8/2016 9:56 AM, Chris Patterson wrote:

I would suggest to start with a 1 hour meeting on the Wednesday 23rd
November. I know that people are spread across different timezones, so I
would like to gather thought before choosing a time.


Sounds good! EST (GMT-5).

Cheers,
-Chris

___
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] Xen ARM community call

2016-11-08 Thread Alistair Francis

On Tue, Nov 8, 2016 at 4:19 AM, Julien Grall  wrote:
> Hi all,
>
...
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.

I can't make it that week, but I would be interested in attending
future calls. I'm PST (UTC-8)

Thanks,

Alistair

>
> Your sincerely,
>
> --
> Julien Grall
>
> ___
> 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] Xen ARM community call

2016-11-08 Thread Chris Patterson

> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
>

Sounds good! EST (GMT-5).

Cheers,
-Chris

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

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Iurii Mykhalskyi

Hello Julien,

I and Iurii Konovalenko are interesting in attending. We are in GMT+2
timezone.

With the best regards,
Iurii Mykhalskyi


On Tue, Nov 8, 2016 at 6:17 PM, Stewart Hildebrand <
stewart.hildebr...@dornerworks.com> wrote:

> Hello Julien,
>
> Yes, myself and a couple of others from DornerWorks are interested in
> attending.  We are in EST (GMT-5).
>
> Stewart Hildebrand
> Embedded Software Engineer
> DornerWorks, Ltd
> stewart.hildebr...@dornerworks.com
>
>
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: Tuesday, November 8, 2016 7:20 AM
> To: xen-devel@lists.xen.org
> Cc: Stefano Stabellini ; Edgar Iglesias (
> edgar.igles...@xilinx.com) ;
> alistair.fran...@xilinx.com; Shanker Donthineni ;
> Goel, Sameer ; Stewart Hildebrand <
> stewart.hildebr...@dornerworks.com>; Steve Capper ;
> andrii.ani...@gmail.com; Lars Kurth 
> Subject: Xen ARM community call
>
> Hi all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough
>
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
>
> Your sincerely,
>
> --
> Julien Grall
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>



-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Stewart Hildebrand

Hello Julien,

Yes, myself and a couple of others from DornerWorks are interested in 
attending.  We are in EST (GMT-5).

Stewart Hildebrand
Embedded Software Engineer
DornerWorks, Ltd
stewart.hildebr...@dornerworks.com


-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com] 
Sent: Tuesday, November 8, 2016 7:20 AM
To: xen-devel@lists.xen.org
Cc: Stefano Stabellini ; Edgar Iglesias 
(edgar.igles...@xilinx.com) ; 
alistair.fran...@xilinx.com; Shanker Donthineni ; 
Goel, Sameer ; Stewart Hildebrand 
; Steve Capper ; 
andrii.ani...@gmail.com; Lars Kurth 
Subject: Xen ARM community call

Hi all,

I would like to start organizing a recurring community call to discuss and 
sync-up on upcoming features for Xen ARM.

Example of features that could be discussed:
- Sharing co-processor between guests
- PCI passthrough

I would suggest to start with a 1 hour meeting on the Wednesday 23rd November. 
I know that people are spread across different timezones, so I would like to 
gather thought before choosing a time.

Your sincerely,

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

Re: [Xen-devel] CPUID improvements (phase 2) Design Doc

2016-11-08 Thread Jan Beulich

>>> On 08.11.16 at 16:35,  wrote:
> Please find inline the design doc for further CPUID improvements, planned for
> development during the 4.9 timeframe.

Looks good, just a couple of minor remarks.

> ## Changes in hypercall behaviour
> 
> During domain construction, some pieces of information critical to the
> determination of the domains maximum acceptable CPUID policy are available
> right from the very start (Most notably, the HVM and HAP flags from the
> `XEN_DOMCTL_createdomain`).
> 
> However, some other parameters are not available at convenient points.
> 
> 1.  The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
> `d->disable_migrate`, whose only purpose is to avoid the unconditional
> clobbering of the Invariant TSC flag.  This flag cannot even be queried by
> the toolstack once set.
> 
> There are other facilities which should be restricted based on whether a
> VM might migrate or not.  (e.g. The use of LBR, whose record format is
> hardware specific.)

Not really - the LBR format only limits the set of hosts the VM can
migrate to. I.e. this is just like a CPUID flag which needs to be set
on the target host in order for the VM to be permitted to migrate
there.

> 2.  The use of `XEN_DOMCTL_set_address_size` switches a PV guest between
> native (64bit) and compat (32bit) mode.  The current behaviour for 32bit
> PV guests is to hide all 64bit-only features.
> 
> Using this hypercall once to switch from native to compat is fairly easy
> to cope with, feature wise, but using the hypercall a second time to
> switch back causes the same ordering problems with respect to
> `XEN_DOMCTL_set_address_size`.
> 
> The preferred option here is to avoid hiding 32bit features.  This is more
> architecturally correct, as a 32bit kernel running on 64bit-capable
> hardware will see 64bit-only features.

But the upside of hiding them is that the guest won't even try to play
any long / 64-bit mode games (which wouldn't work anyway).

>  Other options would be to modify
> the API to make `XEN_DOMCTL_set_address_size` a single-shot hypercall
> (which, given the existing restrictions, shouldn't impact any usecase),

There must have been a reason why we had made it bi-directional,
but I don't recall what it was. As long as no existing functionality is
impacted, I think making this single-shot would be fine.

Jan


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

[Xen-devel] [PATCH for-4.8] libxc: fix unmap of ACPI guest memory region

2016-11-08 Thread Roger Pau Monne

Commit fac7f7 changed the value of ptr so that it points to the right memory
area, taking the page offset into account, but failed to remove this when
doing the unmap, which caused the region to not be unmapped. Fix this by not
modifying ptr and instead adding the page offset directly in the memcpy
call.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Ian Jackson 
---
 tools/libxc/xc_dom_core.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index ad819dd..36cd3c8 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1119,10 +1119,9 @@ static int xc_dom_load_acpi(struct xc_dom_image *dom)
 goto err;
 }
 
-ptr = (uint8_t *)ptr +
-  (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK);
-
-memcpy(ptr, dom->acpi_modules[i].data, dom->acpi_modules[i].length);
+memcpy((uint8_t *)ptr +
+   (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK),
+   dom->acpi_modules[i].data, dom->acpi_modules[i].length);
 munmap(ptr, XC_PAGE_SIZE * num_pages);
 
 free(extents);
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH 08/10] pvh/acpi: Handle ACPI accesses for PVH guests

2016-11-08 Thread Boris Ostrovsky


diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 171ea82..ced7c92 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1392,6 +1392,72 @@ void hvm_ioreq_init(struct domain *d)
 static int acpi_ioaccess(
 int dir, unsigned int port, unsigned int bytes, uint32_t *val)
 {
+unsigned int i;
+unsigned int bits = bytes * 8;
+uint8_t *reg = NULL;
+unsigned idx = port & 3;
+bool is_cpu_map = 0;


Shouldn't we be using false instead of 0 now that we are using proper bool 
types?


+struct domain *currd = current->domain;
+
+BUILD_BUG_ON((ACPI_PM1A_EVT_BLK_LEN != 4) ||
+ (ACPI_GPE0_BLK_LEN_V1 != 4));
+
+switch (port)
+{
+case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
+(ACPI_PM1A_EVT_BLK_ADDRESS_V1 + ACPI_PM1A_EVT_BLK_LEN - 1):
+reg = currd->arch.hvm_domain.acpi_io.pm1a;
+break;
+case ACPI_GPE0_BLK_ADDRESS_V1 ...
+(ACPI_GPE0_BLK_ADDRESS_V1 + ACPI_GPE0_BLK_LEN_V1 - 1):
+reg = currd->arch.hvm_domain.acpi_io.gpe;
+break;
+case 0xaf00 ... (0xaf00 + HVM_MAX_VCPUS/8 - 1):
+is_cpu_map = 1;


s/1/true ?


+break;
+default:
+return X86EMUL_UNHANDLEABLE;
+}
+
+if ( bytes == 0 )
+return X86EMUL_OKAY;
+
+if ( dir == IOREQ_READ )
+{
+*val &= ~((1U << bits) - 1);
+
+if ( is_cpu_map )
+{
+unsigned first_bit, last_bit;


unsigned int


+
+first_bit = (port - 0xaf00) * 8;
+last_bit = min(currd->arch.avail_vcpus, first_bit + bits);
+for (i = first_bit; i < last_bit; i++)
+*val |= (1U << (i - first_bit));
+}
+else
+memcpy(val, [idx], bytes);
+}
+else
+{
+if ( is_cpu_map )
+/* CPU map should not be written. */
+return X86EMUL_UNHANDLEABLE;
+
+/* Write either status or enable reegister. */
+if ( (bytes > 2) || ((bytes == 2) && (port & 1)) )
+return X86EMUL_UNHANDLEABLE;
+
+if ( idx < 2 ) /* status, write 1 to clear. */
+{
+reg[idx] &= ~(*val & 0xff);
+if ( bytes == 2 )
+reg[idx + 1] &= ~((*val >> 8) & 0xff);
+}
+else   /* enable */
+memcpy([idx], val, bytes);


idx should be strictly == 2 in the else case shouldn't it (since it = port & 3) 
so would it not be more efficient to use direct assignment rather than resorting to 
a call to memcpy?



Why do you think idx can't be 3? Reading 1 byte from index 3 should be 
possible.


-boris

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

[Xen-devel] [linux-3.4 test] 102014: regressions - FAIL

flight 102014 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102014/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 92983
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 92983
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 92983
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
92983
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass 
in 102014
 test-amd64-amd64-i386-pvgrub  6 xen-boot   fail pass in 101695
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101695
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101695
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101720
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101720
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101822
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101840
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail pass in 101840
 test-amd64-amd64-amd64-pvgrub  6 xen-boot  fail pass in 101867
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101867
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101867
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101951
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101951
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 101951
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 101951

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

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-amd64-rumprun   7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux8d1988f838a95e836342b505398d38b223181f17
baseline version:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4

Last test of basis92983  2016-04-27 16:21:44 Z  194 days
Testing same since   101695  2016-10-26 18:26:23 Z   12 days   19 attempts


People who touched revisions under test:
  "Suzuki K. Poulose" 
  Aaro Koskinen 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Thorlton 
  Alexandru Cornea 
  Alexey Khoroshilov 
  Amitkumar Karwar 
  Andrew Banman 
  Andrew Morton 
  Andrey Ryabinin 
  Anson Huang 
  Arnaldo Carvalho de Melo

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Andrii Anisov

Dirk,

IuriiK did great work at the beginning of the summer to bringup XEN on
Salvator-X in a short term.
Due to different reasons it was a bit hacky and was not exposed here,
but you can find the stuff here:
https://github.com/qbeeukraine/meta-platform-xen. I'm not really sure
if the final code was pushed there, but still consists of useful
things.

I'm really happy they decided to upstream it.

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Iurii Mykhalskyi

Hello Dirk,

I have made only single change - I recompile ATF to leave CPU in EL2 mode
and reflash it.
Looks like this way are the mostly "correct" approach for this board.

All changes are made in publicly available sources, based on official
Renesas H3 yocto layer - https://github.com/renesas-rcar/meta-renesas

If you don't mind - I can create & handle documentation page about board
setup and take ownership about further board support.

With the best regards,
Iurii Mykhalskyi


On Tue, Nov 8, 2016 at 5:22 PM, Dirk Behme  wrote:

> On 08.11.2016 15:30, Julien Grall wrote:
>
>> Hello Iurii,
>>
>> Dirk (in CC) sent a similar patch few months ago to add support for
>> this board (see [1]).
>>
>> I didn't ack the patch back then because I wanted to see documentation
>> on the wiki to bring up Xen on this board (see [2] for the
>> requirements). I didn't see any follow-up since then for this board.
>>
>> Can one of you write a documentation for this board
>>
>
>
> Yes, that would be nice.
>
> As mentioned, I couldn't find an 'easy' way to load Xen without modifying
> the firmware (U-Boot or ATF) or using a JTAG debugger. Therefore I
> hesitated to write that documentation.
>
> Maybe Iurii found an easier, more user compatible way?
>
> Best regards
>
> Dirk
>
>
>
> and take
>
>> "ownership" on this board?
>>
>> Regards,
>>
>> [1]
>> https://lists.xenproject.org/archives/html/xen-devel/2016-07
>> /msg00315.html
>>
>> [2]
>> https://lists.xenproject.org/archives/html/xen-devel/2016-07
>> /msg00130.html
>>
>>
>> On 08/11/2016 14:20, Iurii Mykhalskyi wrote:
>>
>>> From: Iurii Konovalenko 
>>>
>>> Add support for the "Salvator-X" development board based on R-Car H3
>>> SoC
>>> which has SCIF compatible UART.
>>>
>>> Signed-off-by: Iurii Konovalenko 
>>> Signed-off-by: Iurii Mykhalskyi 
>>> ---
>>>  xen/arch/arm/Rules.mk |  1 +
>>>  xen/arch/arm/arm64/debug-scif.inc | 51
>>> +++
>>>  2 files changed, 52 insertions(+)
>>>  create mode 100644 xen/arch/arm/arm64/debug-scif.inc
>>>
>>> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
>>> index 569a0ba..7989634 100644
>>> --- a/xen/arch/arm/Rules.mk
>>> +++ b/xen/arch/arm/Rules.mk
>>> @@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  :=
>>> pl011,0x1c09,115200
>>>  EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
>>>  EARLY_PRINTK_juno   := pl011,0x7ff8
>>>  EARLY_PRINTK_lager  := scif,0xe6e6
>>> +EARLY_PRINTK_salvator   := scif,0xe6e88000
>>>  EARLY_PRINTK_midway := pl011,0xfff36000
>>>  EARLY_PRINTK_omap5432   := 8250,0x4802,2
>>>  EARLY_PRINTK_seattle:= pl011,0xe101
>>> diff --git a/xen/arch/arm/arm64/debug-scif.inc
>>> b/xen/arch/arm/arm64/debug-scif.inc
>>> new file mode 100644
>>> index 000..1f4d657
>>> --- /dev/null
>>> +++ b/xen/arch/arm/arm64/debug-scif.inc
>>> @@ -0,0 +1,51 @@
>>> +/*
>>> + * xen/arch/arm/arm64/debug-scif.inc
>>> + *
>>> + * SCIF specific debug code
>>> + *
>>> + * Oleksandr Tyshchenko 
>>> + * Iurii Konovalenko 
>>> + * Iurii Mykhalskyi 
>>> + * Copyright (C) 2014-2016, Globallogic.
>>> + *
>>> + * 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 
>>> +
>>> +/* SCIF UART wait UART to be ready to transmit
>>> + * rb: register which contains the UART base address
>>> + * rc: scratch register
>>> + */
>>> +.macro early_uart_ready xb c
>>> +1:
>>> +ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status
>>> register) */
>>> +tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
>>> +beq1b/* Wait for the UART to be
>>> ready */
>>> +.endm
>>> +
>>> +/* SCIF UART transmit character
>>> + * rb: register which contains the UART base address
>>> + * rt: register which contains the character to transmit
>>> + */
>>> +.macro early_uart_transmit xb wt
>>> +strb   \wt, [\xb, #SCIF_SCFTDR]  /* ->
>>> SCFTDR (data register) */
>>> +ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <-
>>> SCFSR (status register) */
>>> +and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear
>>> TEND and TDFE bits */
>>> +strh   \wt, [\xb, #SCIF_SCFSR]   /* ->
>>> SCFSR (status register) */
>>>

[Xen-devel] CPUID improvements (phase 2) Design Doc

2016-11-08 Thread Andrew Cooper

Hello.

Please find inline the design doc for further CPUID improvements, planned for
development during the 4.9 timeframe.

A PDF version can be obtained from:

  http://xenbits.xen.org/people/andrewcoop/cpuid-improvements-phase-2-v1.pdf

Comments welcome.

~Andrew

---8<---

% CPUID improvements, phase 2

\clearpage

# Executive Summary

Previous CPUID work in the Xen 4.7 time-frame provided remedial improvements
for feature levelling, by having Xen decide what it would tolerate as the
maximum featureset for each type of guest and offer this information to the
toolstack.

The purpose of that work was to allow a toolstack to be able to safely migrate
a guest between two non-identical servers; first by the toolstack having an
accurate idea of the hardware capabilities, and second by ensuring that the
guest can only see the features permitted.

There were known issues at the start which were deliberately not addressed,
and further issues became evident during the work.  In particular, Xen's
internal handling of guests CPUID information is in need of improvements.

The purpose of the phase 2 work is to improve the internals of CPUID handling
in Xen and the lower levels of the toolstack.


# Identified Issues

## Privileged domain CPUID policies

The control domain and hardware domain have no policy data in Xen.  This is a
consequence of how the guest CPUID logic was developed.  The lack of policy
data is worked around in `pv_cpuid()` with logic looking like:

if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
domain_cpuid(currd, leaf, subleaf, , , , );
else
cpuid_count(leaf, subleaf, , , , );

but this is flawed for several reasons.

There is nothing special about these domains when it comes to CPUID; they
should still see CPUID data appropriate for their VM container rather than
leaking all hardware state.

The default leaking of hardware state thus far has caused anti-features to
enter into the ABI, most notably OXSAVE and MTRR handling for PV guests.

There is also no equivalent logic for HVM control/hardware domains.

## Domain construction

Currently, only PV domains are viable for use as the control domain in
production scenarios.  As the control domain has previously had full hardware
CPUID information leaked into it, the domain construction logic has become
reliant on this leakage.

In particular the domain construction logic expects, by default, to seed xsave
state information from what it can find in native CPUID.  As PV guests are
more feature restricted than HVM guests, this fails to construct an HVM guest
with all available features if the control domain's CPUID view is properly
restricted.

A workaround for this was left over from the feature levelling work to avoid
enabling CPUID Faulting on the control domain until this issue is resolved.

## Internal CPUID representation

Xen's internal representation of CPUID policy information for a guest is an
unordered list.  This list gets searched for all leaf lookups, and contains
unaudited toolstack values.

Because the unordered list contains unaudited toolstack data, the main CPUID
handling functions attempt to retrofit some sanity to the contents of the
list.  This is recalculated for every leaf lookup.

Because the toolstack provided data isn't in a flat format, logic in Xen needs
to make calls into the CPUID handling functions to find information.  This
causes searching and recalculation even for information such as maxphysaddr or
feature flags which should be accessible in O(1) time.

Some CPUID information depends on other CPUID information.  As the data isn't
in a flat format, handling of things like xsave state or max_leaf boundary
checking requires recursion to obtain, and extra special care to not end up
with a hypervisor stack overflow.

## Topology information

Xen has very little concept of topology information in the CPUID policy.  Some
values (e.g. APIC ID) are hard-coded based on VCPU ID, while some values
(e.g. the cache detail in leaf 4) are blindly propagated from the static
toolstack-provided values, without understanding that they should vary by
vcpu.

The result is very confusing to a VM, as the values it reads across its vcpus
do not match the expectations set out by the Intel/AMD software manuals.

# Proposed Remediation

## Flat internal representation

The following structure is proposed for containing a domains CPUID policy:

struct cpuid_leaf { uint32_t a, b, c, d; };

struct cpuid_policy {
union {
struct cpuid_leaf raw[CPUID_GUEST_NR_BASIC];
struct {
struct {
uint32_t max_leaf, vendor_ebx, vendor_ecx, vendor_edx;
};
struct {
uint32_t stepping: 4, model: 4, family: 4,
type: 2, ext_model: 4, ext_family: 8;
uint8_t brand, clflush, cpu_count, apic_id;
union {
uint32_t _1c;

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Dirk Behme


On 08.11.2016 15:30, Julien Grall wrote:

Hello Iurii,

Dirk (in CC) sent a similar patch few months ago to add support for
this board (see [1]).

I didn't ack the patch back then because I wanted to see documentation
on the wiki to bring up Xen on this board (see [2] for the
requirements). I didn't see any follow-up since then for this board.

Can one of you write a documentation for this board



Yes, that would be nice.

As mentioned, I couldn't find an 'easy' way to load Xen without 
modifying the firmware (U-Boot or ATF) or using a JTAG debugger. 
Therefore I hesitated to write that documentation.


Maybe Iurii found an easier, more user compatible way?

Best regards

Dirk


and take

"ownership" on this board?

Regards,

[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00315.html

[2]
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html


On 08/11/2016 14:20, Iurii Mykhalskyi wrote:

From: Iurii Konovalenko 

Add support for the "Salvator-X" development board based on R-Car H3
SoC
which has SCIF compatible UART.

Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 xen/arch/arm/Rules.mk |  1 +
 xen/arch/arm/arm64/debug-scif.inc | 51
+++
 2 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-scif.inc

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..7989634 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  :=
pl011,0x1c09,115200
 EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
 EARLY_PRINTK_juno   := pl011,0x7ff8
 EARLY_PRINTK_lager  := scif,0xe6e6
+EARLY_PRINTK_salvator   := scif,0xe6e88000
 EARLY_PRINTK_midway := pl011,0xfff36000
 EARLY_PRINTK_omap5432   := 8250,0x4802,2
 EARLY_PRINTK_seattle:= pl011,0xe101
diff --git a/xen/arch/arm/arm64/debug-scif.inc
b/xen/arch/arm/arm64/debug-scif.inc
new file mode 100644
index 000..1f4d657
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-scif.inc
@@ -0,0 +1,51 @@
+/*
+ * xen/arch/arm/arm64/debug-scif.inc
+ *
+ * SCIF specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Iurii Konovalenko 
+ * Iurii Mykhalskyi 
+ * Copyright (C) 2014-2016, Globallogic.
+ *
+ * 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 
+
+/* SCIF UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status
register) */
+tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be
ready */
+.endm
+
+/* SCIF UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+strb   \wt, [\xb, #SCIF_SCFTDR]  /* ->
SCFTDR (data register) */
+ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <-
SCFSR (status register) */
+and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear
TEND and TDFE bits */
+strh   \wt, [\xb, #SCIF_SCFSR]   /* ->
SCFSR (status register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */






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

Re: [Xen-devel] [OSSTEST PATCH v2 4/4] ts-xen-build: Enable CONFIG_VERBOSE_DEBUG

2016-11-08 Thread Andrew Cooper

On 08/11/16 15:09, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 
> CC: Andrew Cooper 
> ---
>  ts-xen-build | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/ts-xen-build b/ts-xen-build
> index 80f6492..7cdd365 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -109,6 +109,7 @@ END
>   if test -f xen/Kconfig; then
>   echo >>xen/.config CONFIG_EXPERT=y
>   echo >>xen/.config CONFIG_HVM_FEP=y
> + echo >>xen/.config CONFIG_VERBOSE_DEBUG=y
>   fi
>  END
> );

Overall, Reviewed-by: Andrew Cooper 

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

[Xen-devel] [OSSTEST PATCH v2 2/4] BuildSupport: Honour $buildcmd_global_prefix

This will make life more convenient in a moment.

Signed-off-by: Ian Jackson 
---
 Osstest/BuildSupport.pm | 4 
 1 file changed, 4 insertions(+)

diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index 7e114cf..4c2b658 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -38,6 +38,7 @@ BEGIN {
   builddirsprops
   buildcmd_stamped_logged
   $builddir $makeflags
+ $buildcmd_global_prefix
 
   prepbuilddirs
 
@@ -57,10 +58,13 @@ our ($whhost,$ho);
 our ($builddir,$makeflags);
 our ($xendist);
 
+our $buildcmd_global_prefix //= '';
+
 sub buildcmd_stamped_logged ($$) {
 my ($timeout, $component, $stampname, $prefix, $cmd, $suffix) = @_;
 target_cmd_build($ho, $timeout, $builddir, <&1 && touch ../$stampname-ok-stamp
 ) |tee ../$stampname-log
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH v2 1/4] xtf: Always boot with loglvl=all guest_loglvl=all

CC: Andrew Cooper 
Signed-off-by: Ian Jackson 
---
 make-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index 7bb536f..a374884 100755
--- a/make-flight
+++ b/make-flight
@@ -463,7 +463,7 @@ do_xtf_tests () {
   job_create_test test-xtf-$xenarch-$dom0arch-$i \
test-xtf xl $xenarch $dom0arch\
 xtfbuildjob=${bfi}build-$xenarch-xtf   \
-xen_boot_append='hvm_fep=1'  \
+xen_boot_append='hvm_fep=1 loglvl=all guest_loglvl=all'\
 all_hostflags=$most_hostflags,diverse-xtf-x86
   done
 }
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH v2 3/4] ts-xen-build: Enable CONFIG_EXPERT

This requires an environment variable set in the build environment,
too.  (There is an argument amongst hypervisor maintainers about
whether this requirement in xen.git is a good idea; but, nevertheless,
it is currently there in several existing trees, so we need to set
it.)

Signed-off-by: Ian Jackson 
CC: Andrew Cooper 
---
 ts-xen-build | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ts-xen-build b/ts-xen-build
index 3e53d74..80f6492 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -43,6 +43,10 @@ builddirsprops();
 
 my $enable_xsm = ($r{enable_xsm}//'false') =~ m/true/ ? 1 : 0;
 
+$buildcmd_global_prefix= <xen/.config CONFIG_EXPERT=y
echo >>xen/.config CONFIG_HVM_FEP=y
fi
 END
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH v2 4/4] ts-xen-build: Enable CONFIG_VERBOSE_DEBUG

Signed-off-by: Ian Jackson 
CC: Andrew Cooper 
---
 ts-xen-build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-xen-build b/ts-xen-build
index 80f6492..7cdd365 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -109,6 +109,7 @@ END
if test -f xen/Kconfig; then
echo >>xen/.config CONFIG_EXPERT=y
echo >>xen/.config CONFIG_HVM_FEP=y
+   echo >>xen/.config CONFIG_VERBOSE_DEBUG=y
fi
 END
);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2] xen: Fix xenpv machine initialisation

2016-11-08 Thread Eduardo Habkost

On Tue, Nov 08, 2016 at 02:07:22PM +, Anthony PERARD wrote:
> When using QEMU for Xen PV guest, QEMU abort with:
> xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type 
> generic-pc-machine
> 
> This is because the machine 'xenpv' also use accel=xen. Moving the code
> to xen_hvm_init() fix the issue.
> 
> This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Eduardo Habkost 

> ---
> CC: Wei Liu 
> CC: Eduardo Habkost 
> ---
>  xen-common.c | 6 --
>  xen-hvm.c| 4 
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/xen-common.c b/xen-common.c
> index bacf962..9099760 100644
> --- a/xen-common.c
> +++ b/xen-common.c
> @@ -9,7 +9,6 @@
>   */
>  
>  #include "qemu/osdep.h"
> -#include "hw/i386/pc.h"
>  #include "hw/xen/xen_backend.h"
>  #include "qmp-commands.h"
>  #include "sysemu/char.h"
> @@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int 
> running,
>  
>  static int xen_init(MachineState *ms)
>  {
> -PCMachineState *pcms = PC_MACHINE(ms);
> -
> -/* Disable ACPI build because Xen handles it */
> -pcms->acpi_build_enabled = false;
> -
>  xen_xc = xc_interface_open(0, 0, 0);
>  if (xen_xc == NULL) {
>  xen_pv_printf(NULL, 0, "can't open xen interface\n");
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 2f348ed..150c7e7 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
> **ram_memory)
>  }
>  xen_be_register_common();
>  xen_read_physmap(state);
> +
> +/* Disable ACPI build because Xen handles it */
> +pcms->acpi_build_enabled = false;
> +
>  return;
>  
>  err:
> -- 
> Anthony PERARD
> 

-- 
Eduardo

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

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board


Hello Iurii,

Dirk (in CC) sent a similar patch few months ago to add support for this 
board (see [1]).


I didn't ack the patch back then because I wanted to see documentation 
on the wiki to bring up Xen on this board (see [2] for the 
requirements). I didn't see any follow-up since then for this board.


Can one of you write a documentation for this board and take "ownership" 
on this board?


Regards,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00315.html
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html


On 08/11/2016 14:20, Iurii Mykhalskyi wrote:

From: Iurii Konovalenko 

Add support for the "Salvator-X" development board based on R-Car H3 SoC
which has SCIF compatible UART.

Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 xen/arch/arm/Rules.mk |  1 +
 xen/arch/arm/arm64/debug-scif.inc | 51 +++
 2 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-scif.inc

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..7989634 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  := pl011,0x1c09,115200
 EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
 EARLY_PRINTK_juno   := pl011,0x7ff8
 EARLY_PRINTK_lager  := scif,0xe6e6
+EARLY_PRINTK_salvator   := scif,0xe6e88000
 EARLY_PRINTK_midway := pl011,0xfff36000
 EARLY_PRINTK_omap5432   := 8250,0x4802,2
 EARLY_PRINTK_seattle:= pl011,0xe101
diff --git a/xen/arch/arm/arm64/debug-scif.inc 
b/xen/arch/arm/arm64/debug-scif.inc
new file mode 100644
index 000..1f4d657
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-scif.inc
@@ -0,0 +1,51 @@
+/*
+ * xen/arch/arm/arm64/debug-scif.inc
+ *
+ * SCIF specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Iurii Konovalenko 
+ * Iurii Mykhalskyi 
+ * Copyright (C) 2014-2016, Globallogic.
+ *
+ * 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 
+
+/* SCIF UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status register) */
+tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be ready */
+.endm
+
+/* SCIF UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+strb   \wt, [\xb, #SCIF_SCFTDR]  /* -> SCFTDR (data 
register) */
+ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status 
register) */
+and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear TEND and 
TDFE bits */
+strh   \wt, [\xb, #SCIF_SCFSR]   /* -> SCFSR (status 
register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */



--
Julien Grall

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

[Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Iurii Mykhalskyi

From: Iurii Konovalenko 

Add support for the "Salvator-X" development board based on R-Car H3 SoC
which has SCIF compatible UART.

Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 xen/arch/arm/Rules.mk |  1 +
 xen/arch/arm/arm64/debug-scif.inc | 51 +++
 2 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-scif.inc

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..7989634 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  := pl011,0x1c09,115200
 EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
 EARLY_PRINTK_juno   := pl011,0x7ff8
 EARLY_PRINTK_lager  := scif,0xe6e6
+EARLY_PRINTK_salvator   := scif,0xe6e88000
 EARLY_PRINTK_midway := pl011,0xfff36000
 EARLY_PRINTK_omap5432   := 8250,0x4802,2
 EARLY_PRINTK_seattle:= pl011,0xe101
diff --git a/xen/arch/arm/arm64/debug-scif.inc 
b/xen/arch/arm/arm64/debug-scif.inc
new file mode 100644
index 000..1f4d657
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-scif.inc
@@ -0,0 +1,51 @@
+/*
+ * xen/arch/arm/arm64/debug-scif.inc
+ *
+ * SCIF specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Iurii Konovalenko 
+ * Iurii Mykhalskyi 
+ * Copyright (C) 2014-2016, Globallogic.
+ *
+ * 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 
+
+/* SCIF UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status register) */
+tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be ready */
+.endm
+
+/* SCIF UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+strb   \wt, [\xb, #SCIF_SCFTDR]  /* -> SCFTDR (data 
register) */
+ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status 
register) */
+and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear TEND and 
TDFE bits */
+strh   \wt, [\xb, #SCIF_SCFSR]   /* -> SCFSR (status 
register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.10.2


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

[Xen-devel] [PATCH v2] xen: Fix xenpv machine initialisation

2016-11-08 Thread Anthony PERARD

When using QEMU for Xen PV guest, QEMU abort with:
xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type 
generic-pc-machine

This is because the machine 'xenpv' also use accel=xen. Moving the code
to xen_hvm_init() fix the issue.

This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae.

Signed-off-by: Anthony PERARD 
---
CC: Wei Liu 
CC: Eduardo Habkost 
---
 xen-common.c | 6 --
 xen-hvm.c| 4 
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen-common.c b/xen-common.c
index bacf962..9099760 100644
--- a/xen-common.c
+++ b/xen-common.c
@@ -9,7 +9,6 @@
  */
 
 #include "qemu/osdep.h"
-#include "hw/i386/pc.h"
 #include "hw/xen/xen_backend.h"
 #include "qmp-commands.h"
 #include "sysemu/char.h"
@@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int 
running,
 
 static int xen_init(MachineState *ms)
 {
-PCMachineState *pcms = PC_MACHINE(ms);
-
-/* Disable ACPI build because Xen handles it */
-pcms->acpi_build_enabled = false;
-
 xen_xc = xc_interface_open(0, 0, 0);
 if (xen_xc == NULL) {
 xen_pv_printf(NULL, 0, "can't open xen interface\n");
diff --git a/xen-hvm.c b/xen-hvm.c
index 2f348ed..150c7e7 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 }
 xen_be_register_common();
 xen_read_physmap(state);
+
+/* Disable ACPI build because Xen handles it */
+pcms->acpi_build_enabled = false;
+
 return;
 
 err:
-- 
Anthony PERARD


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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH v8] sndif: add ABI for Para-virtual sound

2016-11-08 Thread Lars Kurth

> On 8 Nov 2016, at 13:27, Oleksandr Andrushchenko  wrote:
> 
> Hi, Lars!
> 
> Thank you for your inputs,
> 
> I've just added the persons you mentioned to the CC list and hope that someone
> 
> will have time to review the protocol.

...
> 
> Yes, PV audio ABI update is also from us. Oleksandr just used the same =
> thread to update the patchset, lots of stuff changed since it was =
> initially published, indeed. Oleksndr will update the thread as you have =
> suggested.

I added Kyle, Chris and Christopher to this thread who are involved in OpenXT & 
Xenbedded, and who I believe may have some experience in the field also. As far 
as I recall, one of the sticking points in the past, was that Xen maintainers 
could not verify whether the PV protocol proposal maps well onto sound 
protocols.

I don't know whether Xenbedded or OpenXT contain any PV sound drivers yet. In 
any case, it seems that maybe we are starting to get a little bit of 
fragmentation and overlap in some areas around drivers for 
embedded/client/tablets/automotive between Xen Project, OpenXT and Xenbedded. 

It may make sense at some point to try and resolve this overlap and establish 
one place, where this functionality should live. I don't have any opinions, 
just throwing the question out and trying to figure out who has done what 
already.

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

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Meng Xu

Hi Julien,

On Tue, Nov 8, 2016 at 7:19 AM, Julien Grall  wrote:
> Hi all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough
>
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.

I'm interested in joining. I'm at EST (GMT-5).

Thank you very much!

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [Xen PATCH] xen-netback: fix error handling output

2016-11-08 Thread Paul Durrant

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 08 November 2016 13:35
> To: David Vrabel 
> Cc: Arnd Bergmann ; Wei Liu ; Paul
> Durrant ; David S. Miller
> ; Juergen Gross ; Filipe Manco
> ; xen-de...@lists.xenproject.org;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [Xen PATCH] xen-netback: fix error handling output
> 
> The connect function prints an unintialized error code after an
> earlier initialization was removed:
> 
> drivers/net/xen-netback/xenbus.c: In function 'connect':
> drivers/net/xen-netback/xenbus.c:938:3: error: 'err' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This prints it as -EINVAL instead, which seems to be the most
> appropriate error code. Before the patch that caused the warning,
> this would print a positive number returned by vsscanf() instead,
> which is also wrong. We probably don't need a backport though,
> as fixing the warning here should be sufficient.
> 
> Fixes: f95842e7a9f2 ("xen: make use of xenbus_read_unsigned() in xen-
> netback")
> Fixes: 8d3d53b3e433 ("xen-netback: Add support for multiple queues")
> Signed-off-by: Arnd Bergmann 

Yes, I'd say EINVAL was most appropriate.

Reviewed-by: Paul Durrant 

> ---
>  drivers/net/xen-netback/xenbus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-
> netback/xenbus.c
> index 7356e00fac54..bfed79877b8a 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -935,7 +935,7 @@ static void connect(struct backend_info *be)
>   "multi-queue-num-queues", 1);
>   if (requested_num_queues > xenvif_max_queues) {
>   /* buggy or malicious guest */
> - xenbus_dev_fatal(dev, err,
> + xenbus_dev_fatal(dev, -EINVAL,
>"guest requested %u queues, exceeding the
> maximum of %u.",
>requested_num_queues,
> xenvif_max_queues);
>   return;
> --
> 2.9.0


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

[Xen-devel] [Xen PATCH] xen-netback: fix error handling output

2016-11-08 Thread Arnd Bergmann

The connect function prints an unintialized error code after an
earlier initialization was removed:

drivers/net/xen-netback/xenbus.c: In function 'connect':
drivers/net/xen-netback/xenbus.c:938:3: error: 'err' may be used uninitialized 
in this function [-Werror=maybe-uninitialized]

This prints it as -EINVAL instead, which seems to be the most
appropriate error code. Before the patch that caused the warning,
this would print a positive number returned by vsscanf() instead,
which is also wrong. We probably don't need a backport though,
as fixing the warning here should be sufficient.

Fixes: f95842e7a9f2 ("xen: make use of xenbus_read_unsigned() in xen-netback")
Fixes: 8d3d53b3e433 ("xen-netback: Add support for multiple queues")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/xen-netback/xenbus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 7356e00fac54..bfed79877b8a 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -935,7 +935,7 @@ static void connect(struct backend_info *be)
"multi-queue-num-queues", 1);
if (requested_num_queues > xenvif_max_queues) {
/* buggy or malicious guest */
-   xenbus_dev_fatal(dev, err,
+   xenbus_dev_fatal(dev, -EINVAL,
 "guest requested %u queues, exceeding the 
maximum of %u.",
 requested_num_queues, xenvif_max_queues);
return;
-- 
2.9.0


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

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Edgar E. Iglesias

Hi Julien,

I'm interested in joining. I'm in Sweden GMT+1.

Thanks!
Edgar


On Tue, Nov 08, 2016 at 12:19:52PM +, Julien Grall wrote:
> Hi all,
> 
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
> 
> Example of features that could be discussed:
>   - Sharing co-processor between guests
>   - PCI passthrough
> 
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
> 
> Your sincerely,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH v8] sndif: add ABI for Para-virtual sound

2016-11-08 Thread Oleksandr Andrushchenko

Hi, Lars!

Thank you for your inputs,

I've just added the persons you mentioned to the CC list and hope that
someone

will have time to review the protocol.

Thank you,
Oleksandr

On 11/08/2016 03:11 PM, Lars Kurth wrote:

Oleksandr,

you may want to update the CC list, as there have been changes to maintainership. Remove Ian
Campell and Keir Fraser, add Stefano Stabellini and Julien Grall
. Also, as this is a change in the Hypervisor, you probably want to
use xen-devel@ as the main mailing list. embedded-pv-devel
is not properly moderated, which means that it may
take time until a mail which is posted gets to everyone.

The same applies to the other mail.

Regards
Lars

On 4 Nov 2016, at 20:51, Andrushchenko, Oleksandr wrote:

Hi, there!

We would like to bring back to life this thread.
We do hope that the re-worked version of the original patch
addresses all the issues discussed before.
What is more we already have a working version of the
frontend and backend which prove that the protocol works
(those are in the process of preparing to be pushed to
the community as well).

Hope you can review the changes and provide some feedback,
so finally sound devices find their way in the world of Xen

Best regards,
Andrushchenko, Oleksandr
Grytsov, Oleksandr

Andrushchenko, Oleksandr (1):
This is ABI for the two halves of a Para-virtual sound driver to
communicate with each to other.

xen/include/public/io/sndif.h | 583
xen/include/public/io/sndif_linux.h | 114 +++
2 files changed, 697 insertions(+)
create mode 100644 xen/include/public/io/sndif.h
create mode 100644 xen/include/public/io/sndif_linux.h

--
2.7.4

___
Embedded-pv-devel mailing list
embedded-pv-de...@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel

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

Re: [Xen-devel] [PATCH RFC] x86/xen: Return error for xc_hvm_inject_trap() with pending events

On 11/08/2016 03:10 PM, Jan Beulich wrote:
 On 08.11.16 at 13:16,  wrote:
>> xc_hvm_inject_trap() sets v->arch.hvm_vcpu.inject_trap.vector,
>> which is then checked in hvm_do_resume(), and if != -1, a trap
>> is injected, regardless of whether vmx_idtv_reinject() has written
>> VM_ENTRY_INTR_INFO directly. If that's the case, the toolstack
>> injected interrupt will overwrite the reinjected one, which will
>> get lost forever. This patch returns -EBUSY not only if
>> v->arch.hvm_vcpu.inject_trap.vector != -1, but also if
>> hvm_event_pending(v).
> 
> Considering the earlier discussion I don't understand why this was
> put together and submitted: It is my understanding that it won't
> cover all possible cases of actual injection not succeeding, and I
> can't see what good a partial solution will do for you or anyone
> else.

Well, the previous discussion also moved quite a bit through proposed
solutions, and this is the smallest patch that helps.

We're always injecting traps when the VCPU is paused (i.e. when handling
a sync vm_event), and at that time I believe that xc_hvm_inject_trap()
succeeding with this patch would guarantee that the interrupt can be
delivered, and it failing immediately will notify us that injection is
not currently possible.

So for the flow which prompted the discussion, this is a solution. Also,
the patch is RFC - I thought seeing a concrete patch would help, rather
than going on with more abstract concerns.

I'll go back to the vm_event patch then.

Thanks,
Razvan

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH v8] sndif: add ABI for Para-virtual sound

2016-11-08 Thread Lars Kurth

Oleksandr,

you may want to update the CC list, as there have been changes to 
maintainership. Remove Ian Campell and Keir Fraser, add Stefano Stabellini 
 and Julien Grall . Also, as this 
is a change in the Hypervisor, you probably want to use xen-devel@ as the main 
mailing list. embedded-pv-devel  is not 
properly moderated, which means that it may take time until a mail which is 
posted gets to everyone.

The same applies to the other mail.

Regards
Lars

> On 4 Nov 2016, at 20:51, Andrushchenko, Oleksandr  wrote:
> 
> Hi, there!
> 
> We would like to bring back to life this thread.
> We do hope that the re-worked version of the original patch
> addresses all the issues discussed before.
> What is more we already have a working version of the
> frontend and backend which prove that the protocol works
> (those are in the process of preparing to be pushed to
> the community as well).
> 
> Hope you can review the changes and provide some feedback,
> so finally sound devices find their way in the world of Xen
> 
> Best regards,
> Andrushchenko, Oleksandr
> Grytsov, Oleksandr
> 
> Andrushchenko, Oleksandr (1):
>  This is ABI for the two halves of a Para-virtual sound driver to
>communicate with each to other.
> 
> xen/include/public/io/sndif.h   | 583 
> xen/include/public/io/sndif_linux.h | 114 +++
> 2 files changed, 697 insertions(+)
> create mode 100644 xen/include/public/io/sndif.h
> create mode 100644 xen/include/public/io/sndif_linux.h
> 
> -- 
> 2.7.4
> 
> 
> ___
> Embedded-pv-devel mailing list
> embedded-pv-de...@lists.xenproject.org
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel


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

Re: [Xen-devel] [PATCH RFC] x86/xen: Return error for xc_hvm_inject_trap() with pending events

2016-11-08 Thread Jan Beulich

>>> On 08.11.16 at 13:16,  wrote:
> xc_hvm_inject_trap() sets v->arch.hvm_vcpu.inject_trap.vector,
> which is then checked in hvm_do_resume(), and if != -1, a trap
> is injected, regardless of whether vmx_idtv_reinject() has written
> VM_ENTRY_INTR_INFO directly. If that's the case, the toolstack
> injected interrupt will overwrite the reinjected one, which will
> get lost forever. This patch returns -EBUSY not only if
> v->arch.hvm_vcpu.inject_trap.vector != -1, but also if
> hvm_event_pending(v).

Considering the earlier discussion I don't understand why this was
put together and submitted: It is my understanding that it won't
cover all possible cases of actual injection not succeeding, and I
can't see what good a partial solution will do for you or anyone
else.

Jan

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

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Andrii Anisov

Hello Julien,

We will be happy to work on this. We are in GMT+2 timezone (EET).
Adding Artem Mygaiev and Oleksandr Tyshchenko who work on co-processor
sharing with me in EPAM.

Sincerely,
Andrii Anisov.


On Tue, Nov 8, 2016 at 2:19 PM, Julien Grall  wrote:
> Hi all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough
>
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
>
> Your sincerely,
>
> --
> Julien Grall

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

[Xen-devel] [ovmf baseline-only test] 68012: all pass

2016-11-08 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 68012 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68012/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 2998af862469c6a05657e169d7def6f55420caad
baseline version:
 ovmf f675a1b42235b508e17220878453b4b1f04dd990

Last test of basis68009  2016-11-07 17:17:47 Z0 days
Testing same since68012  2016-11-08 04:50:39 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.


commit 2998af862469c6a05657e169d7def6f55420caad
Author: Gary Lin 
Date:   Wed Oct 19 15:01:10 2016 +0800

CryptoPkg: Fix typos in comments

- intialized -> initialized
- componenet -> component
- compoents -> components
- FAlSE -> FALSE
- responsiblity -> responsibility
- validility -> validity
- procudure -> procedure
- pamameter -> parameter
- randome -> random
- buiild -> build

Cc: Ting Ye 
Cc: Qin Long 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin 
Reviewed-by: Qin Long 

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

[Xen-devel] Xen ARM community call


Hi all,

I would like to start organizing a recurring community call to discuss 
and sync-up on upcoming features for Xen ARM.


Example of features that could be discussed:
- Sharing co-processor between guests
- PCI passthrough

I would suggest to start with a 1 hour meeting on the Wednesday 23rd 
November. I know that people are spread across different timezones, so I 
would like to gather thought before choosing a time.


Your sincerely,

--
Julien Grall

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

[Xen-devel] [PATCH RFC] x86/xen: Return error for xc_hvm_inject_trap() with pending events

xc_hvm_inject_trap() sets v->arch.hvm_vcpu.inject_trap.vector,
which is then checked in hvm_do_resume(), and if != -1, a trap
is injected, regardless of whether vmx_idtv_reinject() has written
VM_ENTRY_INTR_INFO directly. If that's the case, the toolstack
injected interrupt will overwrite the reinjected one, which will
get lost forever. This patch returns -EBUSY not only if
v->arch.hvm_vcpu.inject_trap.vector != -1, but also if
hvm_event_pending(v). hvm_event_pending() has also been modified
to be able to run on a VCPU which is not current.

Signed-off-by: Razvan Cojocaru 
---
 xen/arch/x86/hvm/hvm.c | 2 +-
 xen/arch/x86/hvm/vmx/vmx.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 704fd64..cf01ae4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5938,7 +5938,7 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid]) == NULL )
 goto injtrap_fail;
 
-if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
+if ( v->arch.hvm_vcpu.inject_trap.vector != -1 || hvm_event_pending(v) 
)
 rc = -EBUSY;
 else 
 {
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9a8f694..f50a593 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1790,8 +1790,9 @@ static int vmx_event_pending(struct vcpu *v)
 {
 unsigned long intr_info;
 
-ASSERT(v == current);
+vmx_vmcs_enter(v);
 __vmread(VM_ENTRY_INTR_INFO, _info);
+vmx_vmcs_exit(v);
 
 return intr_info & INTR_INFO_VALID_MASK;
 }
-- 
1.9.1


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

[Xen-devel] [ovmf test] 102029: all pass - PUSHED

flight 102029 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102029/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d66f85cb5eed5c218d822204897a78bab53fc157
baseline version:
 ovmf 2998af862469c6a05657e169d7def6f55420caad

Last test of basis   102010  2016-11-07 17:23:51 Z0 days
Testing same since   102029  2016-11-08 04:46:30 Z0 days1 attempts


People who touched revisions under test:
  Hegde Nagaraj P 
  hegdenag 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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=ovmf
+ revision=d66f85cb5eed5c218d822204897a78bab53fc157
+ . ./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 ovmf 
d66f85cb5eed5c218d822204897a78bab53fc157
+ branch=ovmf
+ revision=d66f85cb5eed5c218d822204897a78bab53fc157
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xd66f85cb5eed5c218d822204897a78bab53fc157 = 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] Help regarding bringing up dom0 for lager board




On 07/11/2016 16:39, George John wrote:

Hi,


Hello,


(XEN) Freed 276kB init memory.
(XEN) traps.c:2505:d0v0 HSR=0x93820007 pc=0xc001d084 gva=0xe7804060
gpa=0x00e6160060


Looking at the log, DOM0 is trying to access an region that is not 
mapped (0x00e6160060).


When booting Xen is going through the device tree and mapping to dom0 
all the regions described. So it seems that this region is not present 
in the device tree.


Which Linux kernel are you using? I would recommend you to try the 
latest as possible and use the device-tree provided in 
arch/arm/boot/dts/ to see if it solves the problem.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Moving Xen Project ACPI tables to xenbits


Hi all,

On 07/09/2016 18:56, Stefano Stabellini wrote:

On Wed, 7 Sep 2016, Julien Grall wrote:

On 30/08/2016 19:28, Ian Jackson wrote:

Julien Grall writes ("Moving Xen Project ACPI tables to xenbits"):

Some ACPI tables (STAO, XENV) are currently maintained by the Xen
Project and referenced on the ACPI webpage [1].

They used to be available on mediawiki ([2] and [3]), however with the
recent upgrade the links are now broken.

Given that the mediawiki attachment links my change across version, I am
proposing to upload the ACPI tables on xenbits under the following
URL: http://xenbits.xen.org/docs/acpi-tables/

Any opinions? I will request change on the ACPI website once we agreed
where the specifications will reside.


+1 from me.  (I suggested the path above.)


I haven't seen any other one responding regarding the URL. I will wait another
day and if there are no concerns I will ask Ian to upload the ACPI tables at
http://xenbits.xen.org/docs/acpi-tables.


+1 from me too


Sorry I forgot to follow-up on this thread. Ian could you upload the 2 
pdfs sent by birin ([1]) to the following URL: 
http://xenbits.xen.org/acpi-tables?


I will then request a change on the ACPI webpage [2] and will look at 
upstreaming the source of the PDFs in xen.git.


Cheers,

[1] 
[2] http://www.uefi.org/acpi

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen: Fix xenpv machine initialisation

2016-11-08 Thread Anthony PERARD

On Mon, Nov 07, 2016 at 12:53:29PM -0800, Stefano Stabellini wrote:
> On Mon, 7 Nov 2016, Anthony PERARD wrote:
> > When using QEMU for Xen PV guest, QEMU abort with:
> > xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type 
> > generic-pc-machine
> > 
> > This is because the machine 'xenpv' also use accel=xen.
> > 
> > This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae
> > 
> > Signed-off-by: Anthony PERARD 
> 
> What about moving the acpi_build_enabled initialization to
> xen_hvm_init?

Yes, that would be better, I'll do that.

Thanks.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] stubdom: correct dependency for ioemu linkfarm

2016-11-08 Thread Juergen Gross

On 08/11/16 11:41, Wei Liu wrote:
> On Tue, Nov 08, 2016 at 07:29:01AM +0100, Juergen Gross wrote:
>> The dependency for setting up the links for ioemu is wrong: it is
>> depending on tools/qemu-xen-traditional-dir which is being modified by
>> each "make tools" call. This leads to rebuilds of several stubdom
>> libraries for each call of "make stubdom" as those depend on the ioemu
>> linkfarm stamp file.
>>
>> Modify the dependency to the qemu Makefile instead which is a better
>> indicator whether we need to create the qemu directory before setting
>> up the links.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  stubdom/Makefile | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/stubdom/Makefile b/stubdom/Makefile
>> index 2921f30..0b33e23 100644
>> --- a/stubdom/Makefile
>> +++ b/stubdom/Makefile
>> @@ -281,10 +281,10 @@ IOEMU_LINKFARM_TARGET := ioemu/linkfarm.stamp
>>  endif
>>  
>>  ifeq ($(QEMU_ROOT),.)
>> -$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
>> +$(XEN_ROOT)/tools/qemu-xen-traditional-dir/Makefile:
>>  $(MAKE) DESTDIR= -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
>>  
> 
> What happens if you modify qemu-trad source file(s) and then rebuild
> stubdom? Will that work correctly after this patch is applied?

I think so, yes. Make is using the file modification times of the link
targets to figure out what to rebuild.

The only problem which could occur is that adding a file to qemu would
lead to a link missing. This could be caught by always creating the
links. Question is whether this rare case is to be handled properly or
not. Especially when taking the status of qemu-trad into account: I
wouldn't expect new source files to show up very often.


Juergen

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

Re: [Xen-devel] [PATCH] stubdom: remove EXTRA_CFLAGS meant for building tools

2016-11-08 Thread Wei Liu

On Tue, Nov 08, 2016 at 10:09:41AM +0100, Juergen Gross wrote:
> When building stubdoms EXTRA_CFLAGS_XEN_TOOLS and
> EXTRA_CFLAGS_QEMU_TRADITIONAL should be cleared as they might contain
> flags not suitable for all stubdom builds (e.g. "-m64" often to be
> found in $RPM_OPT_FLAGS will break building 32 bit stubdoms).
> 
> Signed-off-by: Juergen Gross 
> ---
>  stubdom/Makefile | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 2921f30..c89e353 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -4,6 +4,10 @@ MINI_OS = $(XEN_ROOT)/extras/mini-os
>  export XEN_ROOT
>  export XEN_OS=MiniOS
>  
> +# Remove flags which are meant for tools, e.g. "-m64"
> +export EXTRA_CFLAGS_XEN_TOOLS=
> +export EXTRA_CFLAGS_QEMU_TRADITIONAL=
> +

I can't think of a better way to deal with this. This is in line with
how it is done in firmware build, so

Acked-by: Wei Liu 

>  export stubdom=y
>  export debug=y
>  # Moved from config/StdGNU.mk
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] [PATCH] build system: don't let install-stubdom depend on install-tools

2016-11-08 Thread Wei Liu

On Tue, Nov 08, 2016 at 09:29:11AM +0100, Juergen Gross wrote:
> There is no reason for the install-stubdom target to depend on
> install-tools. It is absolutely reasonable to install new stubdoms
> only.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index a8e9523..084588e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -101,7 +101,7 @@ install-tools:
>   $(MAKE) -C tools install
>  
>  .PHONY: install-stubdom
> -install-stubdom: install-tools mini-os-dir
> +install-stubdom: mini-os-dir
>   $(MAKE) -C stubdom install
>  ifeq (x86_64,$(XEN_TARGET_ARCH))
>   XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] [PATCH] stubdom: correct dependency for ioemu linkfarm

2016-11-08 Thread Wei Liu

On Tue, Nov 08, 2016 at 07:29:01AM +0100, Juergen Gross wrote:
> The dependency for setting up the links for ioemu is wrong: it is
> depending on tools/qemu-xen-traditional-dir which is being modified by
> each "make tools" call. This leads to rebuilds of several stubdom
> libraries for each call of "make stubdom" as those depend on the ioemu
> linkfarm stamp file.
> 
> Modify the dependency to the qemu Makefile instead which is a better
> indicator whether we need to create the qemu directory before setting
> up the links.
> 
> Signed-off-by: Juergen Gross 
> ---
>  stubdom/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 2921f30..0b33e23 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -281,10 +281,10 @@ IOEMU_LINKFARM_TARGET := ioemu/linkfarm.stamp
>  endif
>  
>  ifeq ($(QEMU_ROOT),.)
> -$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
> +$(XEN_ROOT)/tools/qemu-xen-traditional-dir/Makefile:
>   $(MAKE) DESTDIR= -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
>  

What happens if you modify qemu-trad source file(s) and then rebuild
stubdom? Will that work correctly after this patch is applied?

> -ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir
> +ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir/Makefile
>   mkdir -p ioemu
>   set -e; 
> \
>   $(buildmakevars2shellvars); 
> \
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] xc_hvm_inject_trap() races

On 11/08/2016 11:39 AM, Razvan Cojocaru wrote:
> On 11/08/2016 11:19 AM, Razvan Cojocaru wrote:
>> On 11/08/2016 10:15 AM, Jan Beulich wrote:
>> On 07.11.16 at 18:01,  wrote:
 On 11/07/2016 06:10 PM, Jan Beulich wrote:
 On 07.11.16 at 16:24,  wrote:
>> The one-shot vm_event does sound reasonable. I could set a flag
>> per-VCPU, basically similar to v->arch.hvm_vcpu.inject_trap.vector, and
>> fire a single event from hvm_inject_trap() if it's set (then unset it) -
>> the flag would be set via an xc_monitor_next_interrupt() call in libxc.
>
> Doing this in hvm_inject_trap() would not cover all cases afict.
> I'd suggest doing this from hvm_do_resume() _after_ the
> (conditional) call to hvm_inject_trap(), if there is _any_ event
> pending.

 But that would only cover the hypercall-injected traps. The condition in
 hvm_do_resume() is "if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )",
 and inject_trap.vector seems to only ever be set by the hypercall:
 [...]
 So if the next interrupt is not caused by the hypercall, we'll never get
 another event. Am I reading the code wrong?
>>>
>>> No, maybe I expressed myself ambiguously: I meant to say that the
>>> event should be delivered from hvm_do_resume(), but _outside_ the
>>> conditional guarding the call to hvm_inject_trap(). Otherwise things
>>> would have been worse than when doing it inside hvm_inject_trap().
>>
>> While working on this patch, I've had a new idea, which would require
>> less changes and fix the problem in a more elegant manner if validated.
>> Looking at vmx_idtv_reinject(), the real problem seems to be that
>> VM_ENTRY_INTR_INFO is being written to directly:
>>
>> 3229 static void vmx_idtv_reinject(unsigned long idtv_info)
>> 3230 {
>> 3231
>> 3232 /* Event delivery caused this intercept? Queue for redelivery. */
>> 3233 if ( unlikely(idtv_info & INTR_INFO_VALID_MASK) )
>> 3234 {
>> 3235 if ( hvm_event_needs_reinjection(MASK_EXTR(idtv_info,
>> 3236
>> INTR_INFO_INTR_TYPE_MASK),
>> 3237  idtv_info &
>> INTR_INFO_VECTOR_MASK) )
>> 3238 {
>> 3239 /* See SDM 3B 25.7.1.1 and .2 for info about masking
>> resvd bits. */
>> 3240 __vmwrite(VM_ENTRY_INTR_INFO,
>> 3241   idtv_info & ~INTR_INFO_RESVD_BITS_MASK);
>> 3242 if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK )
>> 3243 {
>> 3244 unsigned long ec;
>> 3245
>> 3246 __vmread(IDT_VECTORING_ERROR_CODE, );
>> 3247 __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, ec);
>> 3248 }
>> 3249 }
>> 3250
>> 3251 /*
>> 3252  * Clear NMI-blocking interruptibility info if an NMI
>> delivery faulted.
>> 3253  * Re-delivery will re-set it (see SDM 3B 25.7.1.2).
>> 3254  */
>> 3255 if ( cpu_has_vmx_vnmi &&
>> 3256  ((idtv_info & INTR_INFO_INTR_TYPE_MASK) ==
>> 3257   MASK_INSR(X86_EVENTTYPE_NMI, INTR_INFO_INTR_TYPE_MASK)) )
>> 3258 {
>> 3259 unsigned long intr_info;
>> 3260
>> 3261 __vmread(GUEST_INTERRUPTIBILITY_INFO, _info);
>> 3262 __vmwrite(GUEST_INTERRUPTIBILITY_INFO,
>> 3263   intr_info & ~VMX_INTR_SHADOW_NMI);
>> 3264 }
>> 3265 }
>> 3266 }
>>
>> where the hypercall looks at v->arch.hvm_vcpu.inject_trap.vector only.
>> Then we notice that the hypercall _fails_immediately_ with -EBUSY if
>> v->arch.hvm_vcpu.inject_trap.vector is already set:
>>
>> 5922 case HVMOP_inject_trap:
>> 5923 {
>> 5924 xen_hvm_inject_trap_t tr;
>> 5925 struct domain *d;
>> 5926 struct vcpu *v;
>> 5927
>> 5928 if ( copy_from_guest(, arg, 1 ) )
>> 5929 return -EFAULT;
>> 5930
>> 5931 rc = rcu_lock_remote_domain_by_id(tr.domid, );
>> 5932 if ( rc != 0 )
>> 5933 return rc;
>> 5934
>> 5935 rc = -EINVAL;
>> 5936 if ( !is_hvm_domain(d) )
>> 5937 goto injtrap_fail;
>> 5938
>> 5939 rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
>> 5940 if ( rc )
>> 5941 goto injtrap_fail;
>> 5942
>> 5943 rc = -ENOENT;
>> 5944 if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid])
>> == NULL )
>> 5945 goto injtrap_fail;
>> 5946
>> 5947 if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>> 5948 rc = -EBUSY;
> 
> Actually the fix should be even simpler than that: we can add to this if
> " || hvm_event_pending(v)".
> 
> Objections?

Nevermind, vmx_event_pending() has a fair ASSERT that v == curr:

1789 static int vmx_event_pending(struct vcpu *v)
1790 {
1791 unsigned long intr_info;
1792
1793 ASSERT(v == current);
1794 __vmread(VM_ENTRY_INTR_INFO, _info);
1795
1796 return intr_info & INTR_INFO_VALID_MASK;
1797 }

The

Re: [Xen-devel] xc_hvm_inject_trap() races

On 11/08/2016 11:19 AM, Razvan Cojocaru wrote:
> On 11/08/2016 10:15 AM, Jan Beulich wrote:
> On 07.11.16 at 18:01,  wrote:
>>> On 11/07/2016 06:10 PM, Jan Beulich wrote:
>>> On 07.11.16 at 16:24,  wrote:
> The one-shot vm_event does sound reasonable. I could set a flag
> per-VCPU, basically similar to v->arch.hvm_vcpu.inject_trap.vector, and
> fire a single event from hvm_inject_trap() if it's set (then unset it) -
> the flag would be set via an xc_monitor_next_interrupt() call in libxc.

 Doing this in hvm_inject_trap() would not cover all cases afict.
 I'd suggest doing this from hvm_do_resume() _after_ the
 (conditional) call to hvm_inject_trap(), if there is _any_ event
 pending.
>>>
>>> But that would only cover the hypercall-injected traps. The condition in
>>> hvm_do_resume() is "if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )",
>>> and inject_trap.vector seems to only ever be set by the hypercall:
>>> [...]
>>> So if the next interrupt is not caused by the hypercall, we'll never get
>>> another event. Am I reading the code wrong?
>>
>> No, maybe I expressed myself ambiguously: I meant to say that the
>> event should be delivered from hvm_do_resume(), but _outside_ the
>> conditional guarding the call to hvm_inject_trap(). Otherwise things
>> would have been worse than when doing it inside hvm_inject_trap().
> 
> While working on this patch, I've had a new idea, which would require
> less changes and fix the problem in a more elegant manner if validated.
> Looking at vmx_idtv_reinject(), the real problem seems to be that
> VM_ENTRY_INTR_INFO is being written to directly:
> 
> 3229 static void vmx_idtv_reinject(unsigned long idtv_info)
> 3230 {
> 3231
> 3232 /* Event delivery caused this intercept? Queue for redelivery. */
> 3233 if ( unlikely(idtv_info & INTR_INFO_VALID_MASK) )
> 3234 {
> 3235 if ( hvm_event_needs_reinjection(MASK_EXTR(idtv_info,
> 3236
> INTR_INFO_INTR_TYPE_MASK),
> 3237  idtv_info &
> INTR_INFO_VECTOR_MASK) )
> 3238 {
> 3239 /* See SDM 3B 25.7.1.1 and .2 for info about masking
> resvd bits. */
> 3240 __vmwrite(VM_ENTRY_INTR_INFO,
> 3241   idtv_info & ~INTR_INFO_RESVD_BITS_MASK);
> 3242 if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK )
> 3243 {
> 3244 unsigned long ec;
> 3245
> 3246 __vmread(IDT_VECTORING_ERROR_CODE, );
> 3247 __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, ec);
> 3248 }
> 3249 }
> 3250
> 3251 /*
> 3252  * Clear NMI-blocking interruptibility info if an NMI
> delivery faulted.
> 3253  * Re-delivery will re-set it (see SDM 3B 25.7.1.2).
> 3254  */
> 3255 if ( cpu_has_vmx_vnmi &&
> 3256  ((idtv_info & INTR_INFO_INTR_TYPE_MASK) ==
> 3257   MASK_INSR(X86_EVENTTYPE_NMI, INTR_INFO_INTR_TYPE_MASK)) )
> 3258 {
> 3259 unsigned long intr_info;
> 3260
> 3261 __vmread(GUEST_INTERRUPTIBILITY_INFO, _info);
> 3262 __vmwrite(GUEST_INTERRUPTIBILITY_INFO,
> 3263   intr_info & ~VMX_INTR_SHADOW_NMI);
> 3264 }
> 3265 }
> 3266 }
> 
> where the hypercall looks at v->arch.hvm_vcpu.inject_trap.vector only.
> Then we notice that the hypercall _fails_immediately_ with -EBUSY if
> v->arch.hvm_vcpu.inject_trap.vector is already set:
> 
> 5922 case HVMOP_inject_trap:
> 5923 {
> 5924 xen_hvm_inject_trap_t tr;
> 5925 struct domain *d;
> 5926 struct vcpu *v;
> 5927
> 5928 if ( copy_from_guest(, arg, 1 ) )
> 5929 return -EFAULT;
> 5930
> 5931 rc = rcu_lock_remote_domain_by_id(tr.domid, );
> 5932 if ( rc != 0 )
> 5933 return rc;
> 5934
> 5935 rc = -EINVAL;
> 5936 if ( !is_hvm_domain(d) )
> 5937 goto injtrap_fail;
> 5938
> 5939 rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
> 5940 if ( rc )
> 5941 goto injtrap_fail;
> 5942
> 5943 rc = -ENOENT;
> 5944 if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid])
> == NULL )
> 5945 goto injtrap_fail;
> 5946
> 5947 if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
> 5948 rc = -EBUSY;

Actually the fix should be even simpler than that: we can add to this if
" || hvm_event_pending(v)".

Objections?


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v3] xen-netback: prefer xenbus_scanf() over xenbus_gather()

2016-11-08 Thread Paul Durrant

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 November 2016 07:46
> To: Paul Durrant ; Wei Liu 
> Cc: xen-devel ; net...@vger.kernel.org
> Subject: [PATCH v3] xen-netback: prefer xenbus_scanf() over
> xenbus_gather()
> 
> For single items being collected this should be preferred as being more
> typesafe (as the compiler can check format string and to-be-written-to
> variable match) and more efficient (requiring one less parameter to be
> passed).
> 
> Signed-off-by: Jan Beulich 

LGTM

Reviewed-by: Paul Durrant 

> ---
> v3: For consistency with other code don't consider zero an error
> (utilizing that xenbus_scanf() at present won't return zero).
> v2: Avoid commit message to continue from subject.
> ---
>  drivers/net/xen-netback/xenbus.c |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> --- 4.9-rc4/drivers/net/xen-netback/xenbus.c
> +++ 4.9-rc4-xen-netback-prefer-xenbus_scanf/drivers/net/xen-
> netback/xenbus.c
> @@ -889,16 +889,16 @@ static int connect_ctrl_ring(struct back
>   unsigned int evtchn;
>   int err;
> 
> - err = xenbus_gather(XBT_NIL, dev->otherend,
> - "ctrl-ring-ref", "%u", , NULL);
> - if (err)
> + err = xenbus_scanf(XBT_NIL, dev->otherend,
> +"ctrl-ring-ref", "%u", );
> + if (err < 0)
>   goto done; /* The frontend does not have a control ring */
> 
>   ring_ref = val;
> 
> - err = xenbus_gather(XBT_NIL, dev->otherend,
> - "event-channel-ctrl", "%u", , NULL);
> - if (err) {
> + err = xenbus_scanf(XBT_NIL, dev->otherend,
> +"event-channel-ctrl", "%u", );
> + if (err < 0) {
>   xenbus_dev_fatal(dev, err,
>"reading %s/event-channel-ctrl",
>dev->otherend);
> 
> 


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

Re: [Xen-devel] xc_hvm_inject_trap() races

On 11/08/2016 10:15 AM, Jan Beulich wrote:
 On 07.11.16 at 18:01,  wrote:
>> On 11/07/2016 06:10 PM, Jan Beulich wrote:
>> On 07.11.16 at 16:24,  wrote:
 The one-shot vm_event does sound reasonable. I could set a flag
 per-VCPU, basically similar to v->arch.hvm_vcpu.inject_trap.vector, and
 fire a single event from hvm_inject_trap() if it's set (then unset it) -
 the flag would be set via an xc_monitor_next_interrupt() call in libxc.
>>>
>>> Doing this in hvm_inject_trap() would not cover all cases afict.
>>> I'd suggest doing this from hvm_do_resume() _after_ the
>>> (conditional) call to hvm_inject_trap(), if there is _any_ event
>>> pending.
>>
>> But that would only cover the hypercall-injected traps. The condition in
>> hvm_do_resume() is "if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )",
>> and inject_trap.vector seems to only ever be set by the hypercall:
>> [...]
>> So if the next interrupt is not caused by the hypercall, we'll never get
>> another event. Am I reading the code wrong?
> 
> No, maybe I expressed myself ambiguously: I meant to say that the
> event should be delivered from hvm_do_resume(), but _outside_ the
> conditional guarding the call to hvm_inject_trap(). Otherwise things
> would have been worse than when doing it inside hvm_inject_trap().

While working on this patch, I've had a new idea, which would require
less changes and fix the problem in a more elegant manner if validated.
Looking at vmx_idtv_reinject(), the real problem seems to be that
VM_ENTRY_INTR_INFO is being written to directly:

3229 static void vmx_idtv_reinject(unsigned long idtv_info)
3230 {
3231
3232 /* Event delivery caused this intercept? Queue for redelivery. */
3233 if ( unlikely(idtv_info & INTR_INFO_VALID_MASK) )
3234 {
3235 if ( hvm_event_needs_reinjection(MASK_EXTR(idtv_info,
3236
INTR_INFO_INTR_TYPE_MASK),
3237  idtv_info &
INTR_INFO_VECTOR_MASK) )
3238 {
3239 /* See SDM 3B 25.7.1.1 and .2 for info about masking
resvd bits. */
3240 __vmwrite(VM_ENTRY_INTR_INFO,
3241   idtv_info & ~INTR_INFO_RESVD_BITS_MASK);
3242 if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK )
3243 {
3244 unsigned long ec;
3245
3246 __vmread(IDT_VECTORING_ERROR_CODE, );
3247 __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, ec);
3248 }
3249 }
3250
3251 /*
3252  * Clear NMI-blocking interruptibility info if an NMI
delivery faulted.
3253  * Re-delivery will re-set it (see SDM 3B 25.7.1.2).
3254  */
3255 if ( cpu_has_vmx_vnmi &&
3256  ((idtv_info & INTR_INFO_INTR_TYPE_MASK) ==
3257   MASK_INSR(X86_EVENTTYPE_NMI, INTR_INFO_INTR_TYPE_MASK)) )
3258 {
3259 unsigned long intr_info;
3260
3261 __vmread(GUEST_INTERRUPTIBILITY_INFO, _info);
3262 __vmwrite(GUEST_INTERRUPTIBILITY_INFO,
3263   intr_info & ~VMX_INTR_SHADOW_NMI);
3264 }
3265 }
3266 }

where the hypercall looks at v->arch.hvm_vcpu.inject_trap.vector only.
Then we notice that the hypercall _fails_immediately_ with -EBUSY if
v->arch.hvm_vcpu.inject_trap.vector is already set:

5922 case HVMOP_inject_trap:
5923 {
5924 xen_hvm_inject_trap_t tr;
5925 struct domain *d;
5926 struct vcpu *v;
5927
5928 if ( copy_from_guest(, arg, 1 ) )
5929 return -EFAULT;
5930
5931 rc = rcu_lock_remote_domain_by_id(tr.domid, );
5932 if ( rc != 0 )
5933 return rc;
5934
5935 rc = -EINVAL;
5936 if ( !is_hvm_domain(d) )
5937 goto injtrap_fail;
5938
5939 rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
5940 if ( rc )
5941 goto injtrap_fail;
5942
5943 rc = -ENOENT;
5944 if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid])
== NULL )
5945 goto injtrap_fail;
5946
5947 if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
5948 rc = -EBUSY;
5949 else
5950 {
5951 v->arch.hvm_vcpu.inject_trap.vector = tr.vector;
5952 v->arch.hvm_vcpu.inject_trap.type = tr.type;
5953 v->arch.hvm_vcpu.inject_trap.error_code = tr.error_code;
5954 v->arch.hvm_vcpu.inject_trap.insn_len = tr.insn_len;
5955 v->arch.hvm_vcpu.inject_trap.cr2 = tr.cr2;
5956 rc = 0;
5957 }
5958
5959 injtrap_fail:
5960 rcu_unlock_domain(d);
5961 break;
5962 }

The conclusion: instead of __vmwrite(VM_ENTRY_INTR_INFO, ...);
__vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, ...) in vmx_idtv_reinject(),
simply do what the hypercall would have done, i.e. write
inject_trap.vector, inject_trap.type, etc.

This way, the hypercall will fail immediately if there's a pending
interrupt set on

[Xen-devel] [PATCH] stubdom: remove EXTRA_CFLAGS meant for building tools

2016-11-08 Thread Juergen Gross

When building stubdoms EXTRA_CFLAGS_XEN_TOOLS and
EXTRA_CFLAGS_QEMU_TRADITIONAL should be cleared as they might contain
flags not suitable for all stubdom builds (e.g. "-m64" often to be
found in $RPM_OPT_FLAGS will break building 32 bit stubdoms).

Signed-off-by: Juergen Gross 
---
 stubdom/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index 2921f30..c89e353 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -4,6 +4,10 @@ MINI_OS = $(XEN_ROOT)/extras/mini-os
 export XEN_ROOT
 export XEN_OS=MiniOS
 
+# Remove flags which are meant for tools, e.g. "-m64"
+export EXTRA_CFLAGS_XEN_TOOLS=
+export EXTRA_CFLAGS_QEMU_TRADITIONAL=
+
 export stubdom=y
 export debug=y
 # Moved from config/StdGNU.mk
-- 
2.6.6


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

[Xen-devel] [libvirt test] 102026: tolerable all pass - PUSHED

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101948
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101948
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101948
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101948

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-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-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  214c226f9e1440f02ba338b485899b62d9e6bdf8
baseline version:
 libvirt  2d649f800f690bf9e5ed4625e8f63bcd0c32d639

Last test of basis   101948  2016-11-05 04:22:37 Z3 days
Testing same since   102026  2016-11-08 04:28:21 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Guido GÃ¼nther 

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  pass
 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   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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=libvirt
+ revision=214c226f9e1440f02ba338b485899b62d9e6bdf8
+ . ./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

[Xen-devel] [PATCH] build system: don't let install-stubdom depend on install-tools

2016-11-08 Thread Juergen Gross

There is no reason for the install-stubdom target to depend on
install-tools. It is absolutely reasonable to install new stubdoms
only.

Signed-off-by: Juergen Gross 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a8e9523..084588e 100644
--- a/Makefile
+++ b/Makefile
@@ -101,7 +101,7 @@ install-tools:
$(MAKE) -C tools install
 
 .PHONY: install-stubdom
-install-stubdom: install-tools mini-os-dir
+install-stubdom: mini-os-dir
$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
-- 
2.6.6


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

Re: [Xen-devel] xc_hvm_inject_trap() races