Re: [Xen-devel] [PATCH v2 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

[Wei Chen]

On 2017/3/31 6:00, Julien Grall wrote:
>
>
> On 30/03/2017 22:49, Stefano Stabellini wrote:
>> On Thu, 30 Mar 2017, Wei Chen wrote:
>>> +/*
>>> + * If the SErrors option is "FORWARD", we have to prevent forwarding
>>> + * serror to wrong vCPU. So before context switch, we have to use the
>>> + * synchronize_serror to guarantee that the pending serror would be
>>> + * caught by current vCPU.
>>> + *
>>> + * The SKIP_CTXT_SWITCH_SERROR_SYNC will be set to cpu_hwcaps when the
>>> + * SErrors option is NOT "FORWARD".
>>> + */
>>> +asm volatile(ALTERNATIVE("bl synchronize_serror",
>>> + "nop",
>>> + SKIP_CTXT_SWITCH_SERROR_SYNC));
>>
>>
>> This good, but here you need to add:
>>
>>   barrier();
>>
>> because the compiler is free to reorder even asm volatile instructions
>> (it could move the asm volatile after __context_switch theoretically).
>
> ... or it could moved before hand because there are no barrier... What
> you want to use is asm volatile(ALTERNATIVE(...) : : : "memory");
>

I would cover this consideration in the change of #16 in next version.

> Cheers,
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

[Wei Chen]

On 2017/3/31 2:38, Julien Grall wrote:
>
>
> On 30/03/17 19:32, Julien Grall wrote:
>> On 30/03/17 19:28, Julien Grall wrote:
>>> Hi Wei,
>>>
>>> On 30/03/17 10:13, Wei Chen wrote:
 +void synchronize_serror(void)
>>>
>>> Sorry for been late in the party. Looking at the way you use the
>>> function, you execute depending on the behavior chosen by the user when
>>> an SErrors happen. This behavior will not change at runtime, so always
>>> checking the option chosen in the hot path does not sound very efficient.
>>>
>>> I would recommend to look at ALTERNATIVE and streamline (dsb sy, isb).
>>> I.e
>>>
>>> ALTERNATIVE("dsb sy; isb", "nop; nop", ...) or the invert depending of
>>> the place.
>>
>> To complete what I was suggestion, you could define:
>>
>> /* Synchronize SError unless the feature is selected */
>> #define SYNCHRONIZE_SERROR(feat) ALTERNATIVE("dsb sy; isb", "nop; nop");
>
> Or even:
>
> /*
>   * Synchronize SError unless the feature is selected.
>   * This is relying on the SErrors are currently unmasked.
>   */
> #define SYNCHRONIZE_SERROR(feat)\
>   do {  \
> ASSERT(cpus_have_cap(feat) && local_abort_is_enabled());\
> ALTERNATIVE("dsb sy; isb", "nop; nop"); \
>   while (0)
>
> The ASSERT is here to check that we have abort enabled. Otherwise, doing
> the synchronization would be pointless.
>
> Note that the function local_abort_is_enabled is not implemented. But it
> is easy to write it. Looking how local_irq_is_enabled was implemented.
>

This is a better solution than function, I would do it.

> Cheers,
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [PATCH v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

[Tian, Kevin]

> From: Gao, Chao
> Sent: Wednesday, March 29, 2017 1:12 PM
> 
> msi_msg_to_remap_entry() is buggy when the live IRTE is in posted format. It
> wrongly inherits the 'im' field meaning the IRTE is in posted format but
> updates all the other fields to remapping format.
> 
> There are also two situations that lead to the above issue. One is some
> callers
> really want to change the IRTE to remapped format. The other is some callers
> only want to update msi message (e.g. set msi affinity) for they don't aware
> that this msi is binded with a guest interrupt. We should suppress update
> in the second situation. To distinguish them, straightforwardly, we can let
> caller specify which format of IRTE they want update to. It isn't feasible for
> making all callers be aware of the binding with guest interrupt will cause a
> far more complicated change (including the interfaces exposed to IOAPIC and
> MSI). Also some callings happen in interrupt context where we can't acquire
> d->event_lock to read struct hvm_pirq_dpci.
> 
> This patch introduces two new fields in msi_desc to track binding with a
> guest
> interrupt such that msi_msg_to_remap_entry() can get the binding and
> update
> IRTE accordingly. After that change, pi_update_irte() can utilize
> msi_msg_to_remap_entry() to update IRTE to posted format.
> 
> Signed-off-by: Feng Wu 
> Signed-off-by: Chao Gao 
> ---
> v11:
> - Commit message changes.
> - Add code to clear the two new fields introduced in this patch.
> 
> v10:
> - Newly added.
> 
>  xen/arch/x86/msi.c |   1 +
>  xen/drivers/passthrough/io.c   |   2 +
>  xen/drivers/passthrough/vtd/intremap.c | 150 
> +++--
>  xen/include/asm-x86/msi.h  |   2 +
>  4 files changed, 36 insertions(+), 119 deletions(-)
> 
> diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
> index a868007..3374cd4 100644
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -578,6 +578,7 @@ static struct msi_desc *alloc_msi_entry(unsigned int
> nr)
>  entry[nr].dev = NULL;
>  entry[nr].irq = -1;
>  entry[nr].remap_index = -1;
> +entry[nr].pi_desc = NULL;
>  }
> 
>  return entry;
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index d53976c..5dbfe53 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -618,6 +618,8 @@ int pt_irq_destroy_bind(
>  else
>  what = "bogus";
>  }
> +else if ( iommu_intpost && pirq && pirq_dpci->gmsi.posted )

No need to check iommu_intpost. Just keep later conditions.

btw isn't the condition be " (pirq_dpci && pirq_dpci->gmsi.posted)"?

> +pi_update_irte(NULL, pirq, 0);
> 
>  if ( pirq_dpci && (pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) &&
>   list_empty(_dpci->digl_list) )
> diff --git a/xen/drivers/passthrough/vtd/intremap.c
> b/xen/drivers/passthrough/vtd/intremap.c
> index bfd468b..9bbf0f6 100644
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -551,12 +551,12 @@ static int msi_msg_to_remap_entry(
>  struct iommu *iommu, struct pci_dev *pdev,
>  struct msi_desc *msi_desc, struct msi_msg *msg)
>  {
> -struct iremap_entry *iremap_entry = NULL, *iremap_entries;
> -struct iremap_entry new_ire;
> +struct iremap_entry *iremap_entry = NULL, *iremap_entries, new_ire = { };
>  struct msi_msg_remap_entry *remap_rte;
>  unsigned int index, i, nr = 1;
>  unsigned long flags;
>  struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
> +const struct pi_desc *pi_desc = msi_desc->pi_desc;
> 
>  if ( msi_desc->msi_attrib.type == PCI_CAP_ID_MSI )
>  nr = msi_desc->msi.nvec;
> @@ -595,33 +595,35 @@ static int msi_msg_to_remap_entry(
>  GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
>   iremap_entries, iremap_entry);
> 
> -memcpy(_ire, iremap_entry, sizeof(struct iremap_entry));
> -
> -/* Set interrupt remapping table entry */
> -new_ire.remap.fpd = 0;
> -new_ire.remap.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT)
> & 0x1;
> -new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
> -new_ire.remap.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT)
> & 0x1;
> -/* Hardware require RH = 1 for LPR delivery mode */
> -new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
> -new_ire.remap.avail = 0;
> -new_ire.remap.res_1 = 0;
> -new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
> -MSI_DATA_VECTOR_MASK;
> -new_ire.remap.res_2 = 0;
> -if ( x2apic_enabled )
> -new_ire.remap.dst = msg->dest32;
> +if ( !pi_desc )
> +{
> +new_ire.remap.dm = msg->address_lo >>
> MSI_ADDR_DESTMODE_SHIFT;
> +new_ire.remap.tm = msg->data >> MSI_DATA_TRIGGER_SHIFT;
> +new_ire.remap.dlm = msg->data >>
> MSI_DATA_DELIVERY_MODE_SHIFT;

Re: [Xen-devel] [PATCH v2 12/19] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header

[Wei Chen]

On 2017/3/31 5:36, Stefano Stabellini wrote:
> On Thu, 30 Mar 2017, Wei Chen wrote:
>> We want to move part of SErrors checking code from hyp_error assembly code
>> to a function. This new function will use this macro to distinguish the
>> guest SErrors from hypervisor SErrors. So we have to move this macro to
>> common header.
>>
>> The VABORT_GEN_BY_GUEST macro used two symbols abort_guest_exit_start and
>> abort_guest_exit_end. After we moved this macro to common header, we
>> should export these two symbols to other source files that will use
>> VABORT_GEN_BY_GUEST macro. So we change these two symbols to global.
>
> Please rewrite this to:
>
>   The VABORT_GEN_BY_GUEST macro uses the symbols abort_guest_exit_start
>   and abort_guest_exit_end. After we move this macro to a common header,
>   we need to make sure that the two symbols are visible to other source
>   files. Currently, they are declared .global in arm32/entry.S, but not
>   arm64/entry.S. Fix that.
>

Thanks for reorganization, I would rewrite in next version.

> Reviewed-by: Stefano Stabellini 
>
>
>> Signed-off-by: Wei Chen 
>> ---
>> v1->v2:
>> 1. Explain in commit message why we change abort_guest_exit_start and
>>abort_guest_exit_end to global.
>> ---
>>  xen/arch/arm/arm64/entry.S|  2 ++
>>  xen/include/asm-arm/arm32/processor.h | 10 --
>>  xen/include/asm-arm/processor.h   | 10 ++
>>  3 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
>> index 4baa3cb..113e1c3 100644
>> --- a/xen/arch/arm/arm64/entry.S
>> +++ b/xen/arch/arm/arm64/entry.S
>> @@ -380,10 +380,12 @@ check_pending_vserror:
>>   * exception handler, and the elr_el2 will be set to
>>   * abort_guest_exit_start or abort_guest_exit_end.
>>   */
>> +.global abort_guest_exit_start
>>  abort_guest_exit_start:
>>
>>  isb
>>
>> +.global abort_guest_exit_end
>>  abort_guest_exit_end:
>>  /* Mask PSTATE asynchronous abort bit, close the checking window. */
>>  msr daifset, #4
>> diff --git a/xen/include/asm-arm/arm32/processor.h 
>> b/xen/include/asm-arm/arm32/processor.h
>> index f6d5df3..68cc821 100644
>> --- a/xen/include/asm-arm/arm32/processor.h
>> +++ b/xen/include/asm-arm/arm32/processor.h
>> @@ -56,16 +56,6 @@ struct cpu_user_regs
>>  uint32_t pad1; /* Doubleword-align the user half of the frame */
>>  };
>>
>> -/* Functions for pending virtual abort checking window. */
>> -void abort_guest_exit_start(void);
>> -void abort_guest_exit_end(void);
>> -
>> -#define VABORT_GEN_BY_GUEST(r)  \
>> -( \
>> -( (unsigned long)abort_guest_exit_start == (r)->pc ) || \
>> -( (unsigned long)abort_guest_exit_end == (r)->pc ) \
>> -)
>> -
>>  #endif
>>
>>  /* Layout as used in assembly, with src/dest registers mixed in */
>> diff --git a/xen/include/asm-arm/processor.h 
>> b/xen/include/asm-arm/processor.h
>> index 47e7026..700bde9 100644
>> --- a/xen/include/asm-arm/processor.h
>> +++ b/xen/include/asm-arm/processor.h
>> @@ -709,6 +709,16 @@ int call_smc(register_t function_id, register_t arg0, 
>> register_t arg1,
>>
>>  void do_trap_guest_error(struct cpu_user_regs *regs);
>>
>> +/* Functions for pending virtual abort checking window. */
>> +void abort_guest_exit_start(void);
>> +void abort_guest_exit_end(void);
>> +
>> +#define VABORT_GEN_BY_GUEST(r)  \
>> +( \
>> +( (unsigned long)abort_guest_exit_start == (r)->pc ) || \
>> +( (unsigned long)abort_guest_exit_end == (r)->pc ) \
>> +)
>> +
>>  #endif /* __ASSEMBLY__ */
>>  #endif /* __ASM_ARM_PROCESSOR_H */
>>  /*
>> --
>> 2.7.4
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel
>>
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [PATCH v2 11/19] xen/arm32: Use alternative to skip the check of pending serrors

[Wei Chen]

On 2017/3/31 5:29, Stefano Stabellini wrote:
> On Thu, 30 Mar 2017, Julien Grall wrote:
>> Hi Wei,
>>
>> On 30/03/17 10:13, Wei Chen wrote:
>>> We have provided an option to administrator to determine how to
>>> handle the SErrors. In order to skip the check of pending SError,
>>> in conventional way, we have to read the option every time before
>>> we try to check the pending SError. This will add overhead to check
>>> the option at every trap.
>>>
>>> The ARM32 supports the alternative patching feature. We can use an
>>> ALTERNATIVE to avoid checking option at every trap. We added a new
>>> cpufeature named "SKIP_CHECK_PENDING_VSERROR". This feature will be
>>> enabled when the option is not diverse.
>>>
>>> Signed-off-by: Wei Chen 
>>
>> Reviewed-by: Julien Grall 
>>
>>> ---
>>
>> Stefano, this is requiring the alternative patch (see [1]) which is still in
>> review.
>>
>> Wei, a general rule is to mention the dependencies between series. So we 
>> don't
>> apply by mistake in the wrong order.
>
> Right. Thanks Wei for sending both the other patch and this series
> together, that helps me avoiding mistakes.
>
> But please add a note about the dependencies, just in case I forget.
>

Stefano and Julien, thank you. I would place a note about the
dependencies in next version.

>
>> Cheers,
>>
>> [1] 
>> https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg04132.html
>>
>>>  xen/arch/arm/arm32/entry.S | 10 ++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
>>> index 2187226..105cae8 100644
>>> --- a/xen/arch/arm/arm32/entry.S
>>> +++ b/xen/arch/arm/arm32/entry.S
>>> @@ -1,5 +1,6 @@
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>>  #define SAVE_ONE_BANKED(reg)mrs r11, reg; str r11, [sp, #UREGS_##reg]
>>> @@ -44,6 +45,14 @@ save_guest_regs:
>>>  SAVE_BANKED(fiq)
>>>  SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq);
>>> SAVE_ONE_BANKED(R10_fiq)
>>>  SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
>>> +
>>> +/*
>>> + * If the SKIP_CHECK_PENDING_VSERROR has been set in the cpu
>>> feature,
>>> + * the checking of pending SErrors will be skipped.
>>> + */
>>> +ALTERNATIVE("nop",
>>> +"b skip_check",
>>> +SKIP_CHECK_PENDING_VSERROR)
>>>  /*
>>>   * Start to check pending virtual abort in the gap of Guest -> HYP
>>>   * world switch.
>>> @@ -99,6 +108,7 @@ abort_guest_exit_end:
>>>   */
>>>  bne return_from_trap
>>>
>>> +skip_check:
>>>  mov pc, lr
>>>
>>>  #define DEFINE_TRAP_ENTRY(trap) \
>>>
>>
>> --
>> Julien Grall
>>
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [PATCH v2 08/19] xen/arm: Introduce a command line parameter for SErrors/Aborts

[Wei Chen]

Hi Julien,

On 2017/3/31 1:39, Julien Grall wrote:
> Hi Wei,
>
> On 30/03/17 10:13, Wei Chen wrote:
>> In order to distinguish guest-generated SErrors from hypervisor-generated
>> SErrors we have to place SError checking code in every EL1 -> EL2 paths.
>> That will cause overhead on entries due to dsb/isb.
>>
>> However, not all platforms want to categorize SErrors. For example, a host
>> that is running with trusted guests. The administrator can confirm that
>> all guests that are running on the host will not trigger such SErrors. In
>> this user-case, we should provide some options to administrators to avoid
>
> s/user-case/use-case/
>
>> +### serrors (ARM)
>> +> `= diverse | forward | panic`
>> +
>> +> Default: `diverse`
>> +
>> +This parameter is provided to administrators to determine how the
>> +hypervisors handle SErrors.
>> +
>> +In order to distinguish guest-generated SErrors from hypervisor-generated
>> +SErrors we have to place SError checking code in every EL1 -> EL2 paths.
>> +That will cause overhead on entries due to dsb/isb. However, not all 
>> platforms
>
> s/entries/entries and exits/ I think because none of the options you
> provide will effectively only do dsb/isb on entries.
>

Yes, the options will affect both entries and exits. I would update the
commit message and doc.

> Cheers,
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

[Tian, Kevin]

> From: Chao Gao
> Sent: Wednesday, March 29, 2017 1:12 PM
> 
> When a vCPU migrated to another pCPU, pt irqs binded to this vCPU also
> needed migration. When VT-d PI is enabled, interrupt vector will be recorded
> to a main memory resident data-structure and a notification whose
> destination is decided by NDST is generated. NDST is properly adjusted
> during vCPU migration so pirq directly injected to guest needn't be migrated.
> 
> This patch adds a indicator, @posted, to show whether the pt irq is delivered
> through VT-d PI.
> 
> Signed-off-by: Chao Gao 
> ---
> v11:
> - rename the indicator to 'posted'
> - move setting 'posted' field to event lock un-locked region.
> 
> v10:
> - Newly added.
> 
>  xen/arch/x86/hvm/hvm.c   |  3 +++
>  xen/drivers/passthrough/io.c | 62 
> +---
>  xen/include/xen/hvm/irq.h|  1 +
>  3 files changed, 16 insertions(+), 50 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> 0282986..2d8de16 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -438,6 +438,9 @@ static int hvm_migrate_pirq(struct domain *d, struct
> hvm_pirq_dpci *pirq_dpci,
>  struct vcpu *v = arg;
> 
>  if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) &&
> + (pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI) &&
> + /* Needn't migrate pirq if this pirq is delivered to guest 
> directly.*/
> + (!pirq_dpci->gmsi.posted) &&
>   (pirq_dpci->gmsi.dest_vcpu_id == v->vcpu_id) )

simply looking at above change it's more than what you intend to change.
Previously even w/o GUEST_MSI flag will fall into that path, but now
you limit it to only GUEST_MSI and irq remapping (i.e. changed the
behavior for both posted case and w/o GUEST_MSI case). I haven't looked
whether MACH_MASI always set with GUEST_MSI, but my gut-feeling 
looks not correct here.

>  {
>  struct irq_desc *desc =
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 080183e..d53976c 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -259,52 +259,6 @@ static struct vcpu *vector_hashing_dest(const struct
> domain *d,
>  return dest;
>  }
> 
> -/*
> - * The purpose of this routine is to find the right destination vCPU for
> - * an interrupt which will be delivered by VT-d posted-interrupt. There
> - * are several cases as below:
> - *
> - * - For lowest-priority interrupts, use vector-hashing mechanism to find
> - *   the destination.
> - * - Otherwise, for single destination interrupt, it is straightforward to
> - *   find the destination vCPU and return true.
> - * - For multicast/broadcast vCPU, we cannot handle it via interrupt posting,
> - *   so return NULL.
> - */
> -static struct vcpu *pi_find_dest_vcpu(const struct domain *d, uint32_t
> dest_id,
> -  bool_t dest_mode, uint8_t 
> delivery_mode,
> -  uint8_t gvec)
> -{
> -unsigned int dest_vcpus = 0;
> -struct vcpu *v, *dest = NULL;
> -
> -switch ( delivery_mode )
> -{
> -case dest_LowestPrio:
> -return vector_hashing_dest(d, dest_id, dest_mode, gvec);
> -case dest_Fixed:
> -for_each_vcpu ( d, v )
> -{
> -if ( !vlapic_match_dest(vcpu_vlapic(v), NULL, APIC_DEST_NOSHORT,
> -dest_id, dest_mode) )
> -continue;
> -
> -dest_vcpus++;
> -dest = v;
> -}
> -
> -/* For fixed mode, we only handle single-destination interrupts. */
> -if ( dest_vcpus == 1 )
> -return dest;
> -
> -break;
> -default:
> -break;
> -}
> -
> -return NULL;
> -}
> -
>  int pt_irq_create_bind(
>  struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)  { @@ -365,6
> +319,7 @@ int pt_irq_create_bind(
>  {
>  uint8_t dest, dest_mode, delivery_mode;
>  int dest_vcpu_id;
> +const struct vcpu *vcpu;
> 
>  if ( !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
>  {
> @@ -442,17 +397,24 @@ int pt_irq_create_bind(
>  dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
>  pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
>  spin_unlock(>event_lock);
> +
> +pirq_dpci->gmsi.posted = false;
> +vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL;
> +if ( iommu_intpost && (delivery_mode == dest_LowestPrio) )
> +{
> +vcpu = vector_hashing_dest(d, dest, dest_mode,
> +   pirq_dpci->gmsi.gvec);
> +if ( vcpu )
> +pirq_dpci->gmsi.posted = true;
> +}
>  if ( dest_vcpu_id >= 0 )
>  hvm_migrate_pirqs(d->vcpu[dest_vcpu_id]);
> 
>  /* Use interrupt posting if it is supported. */
>  if ( iommu_intpost )
>  {
> -const 

[Xen-devel] [qemu-mainline baseline-only test] 71127: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71127 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71127/

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 build-armhf-xsm   4 capture-logs   broken blocked in 71121
 build-armhf-pvops 4 capture-logs   broken blocked in 71121
 build-armhf   4 capture-logs   broken blocked in 71121
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71121
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 71121

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuub529aec1ee1cbb642f236893bf46a712d0187e4d
baseline version:
 qemuudf9046363220e57d45818312759b954c033c58ab

Last test of basis71121  2017-03-30 02:44:51 Z1 days
Testing same since71127  2017-03-30 23:18:20 Z0 days1 attempts


People who touched revisions under test:
  Eduardo Habkost 
  Jiri Denemark 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  

Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

[Wei Chen]

On 2017/3/31 1:20, Julien Grall wrote:
> Hi Wei,
>
> On 30/03/17 10:13, Wei Chen wrote:
>> When guest triggers async aborts, in most platform, such aborts
>> will be routed to hypervisor. But we don't want the hypervisor
>> to handle such aborts, so we have to route such aborts back to
>> the guest.
>>
>> This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
>> route such aborts back to the guest. If the guest PC had been
>> advanced by SVC/HVC/SMC instructions before we caught the SError
>> in hypervisor, we have to adjust the guest PC to exact address
>> while the SError generated.
>>
>> About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
>> we would like them to be handled here. This would be useful when
>> VM introspection will gain support of SVC32/64 trapping.
>>
>> This helper will be used by the later patches in this series, we
>> use #if 0 to disable it in this patch temporarily to remove the
>> warning message of unused function from compiler.
>>
>> Signed-off-by: Wei Chen 
>> Acked-by: Stefano Stabellini 
>> ---
>> v1->v2:
>> 1. After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
>>to HCR_EL2 immediately. In this case we don't need to move the
>>restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
>>regardless of whether we get preempted.
>
> This should have been explained in the commit message and ...

Ok.

>
>> 2. Add Stefano's Acked-by.
>
> I would not keep Acked-by/Reviewed-by with a change like above. Or at
> least, I would ask whether they are fine with this change.

Thanks, I understand now.

>
> Cheers,
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [PATCH v11 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list

[Tian, Kevin]

> From: Gao, Chao
> Sent: Wednesday, March 29, 2017 1:12 PM
> 
> The current VT-d PI related code may operate incorrectly in the following
> scenarios:
> 1. When VT-d PI is enabled, neen't migrate pirq which is using VT-d PI during

neen't -> needn't

> vCPU migration. Patch [1/6] solves this by introducing a new flag to indicate
> that the pt-irq is delivered through VT-d PI.
> 
> 2. msi_msg_to_remap_entry() is buggy when the live IRTE is in posted format.
> It wrongly inherits the 'im' field from the live IRTE but updates all the 
> other
> fileds to remapping format. Patch [2/6] handles this.
> 
> 3. [3/6] is a cleanup patch
> 
> 4. When a pCPU is unplugged, and there might be vCPUs on its list. Since the
> pCPU is offline, those vCPUs might not be woken up again. [4/6] addresses it.
> 
> 5. IRTE is updated through structure assigment which is unsafe in some cases.
> To resolve this, Patch [5/6] provides two variants, atomic and non-atomic, to
> update IRTE. And a bug is raised when we can't meet the caller's atomic
> requirement.
> 
> 6. We didn't change the IRTE to remapping format when pt-irq is
> configurated to have multi-destination vCPUs. Patch [6/6] resolves this
> problem.
> 
> 
> Chao Gao (4):
>   passthrough: don't migrate pirq when it is delivered through VT-d PI
>   VT-d: Introduce new fields in msi_desc to track binding with guest
> interrupt
>   VT-d: introduce update_irte to update irte safely
>   passthrough/io: Fall back to remapping interrupt when we can't use
> VT-d PI
> 
> Feng Wu (2):
>   VT-d: Some cleanups
>   VMX: Fixup PI descriptor when cpu is offline
> 
>  xen/arch/x86/hvm/hvm.c |   3 +
>  xen/arch/x86/hvm/vmx/vmcs.c|   1 +
>  xen/arch/x86/hvm/vmx/vmx.c |  70 ++
>  xen/arch/x86/msi.c |   2 +
>  xen/drivers/passthrough/io.c   |  71 ++
>  xen/drivers/passthrough/vtd/intremap.c | 236 +++--
> 
>  xen/include/asm-x86/hvm/vmx/vmx.h  |   1 +
>  xen/include/asm-x86/msi.h  |   3 +
>  xen/include/xen/hvm/irq.h  |   1 +
>  9 files changed, 204 insertions(+), 184 deletions(-)
> 
> --
> 1.8.3.1


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

Re: [Xen-devel] [PATCH v3 3/9] x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Thursday, March 30, 2017 2:20 PM
> 
> If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and
> LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those
> bits are set before SW can enable LMCE.
> 
> Signed-off-by: Haozhong Zhang 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v3 2/8] x86/hvm: introduce hvm_domain_irq macro

[Tian, Kevin]

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, March 29, 2017 10:47 PM
> 
> Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No
> functional change.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Kevin Tian  for VTd part.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 251779fca719bf9ea00505ee7629c08b452c150d
baseline version:
 ovmf 072060a6f81b3e43473b9e5dcba7049ad9de4b18

Last test of basis   107008  2017-03-30 20:45:03 Z0 days
Testing same since   107013  2017-03-31 00:45:04 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

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=251779fca719bf9ea00505ee7629c08b452c150d
+ . ./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 
251779fca719bf9ea00505ee7629c08b452c150d
+ branch=ovmf
+ revision=251779fca719bf9ea00505ee7629c08b452c150d
+ . ./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.8-testing
+ '[' x251779fca719bf9ea00505ee7629c08b452c150d = 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
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, March 27, 2017 4:00 PM
> 
> >>> On 24.03.17 at 17:54,  wrote:
> > As I understand it, for level triggered legacy PCI interrupts Xen sets
> > up a timer in order to perform the EOI if the guest takes too long in
> > deasserting the line. This is done in pt_irq_time_out. What I don't
> > understand is why this function also does a deassertion of the guest view
> of the PCI interrupt, ie:
> > why it calls hvm_pci_intx_deassert. This AFAICT will clear the pending
> > assert in the guest, and thus the guest will end up loosing one interrupt.
> 
> Especially with the comment next to the respective set_timer() it looks to me
> as if this was the intended effect: If the guest didn't care to at least start
> handling the interrupt within PT_IRQ_TIME_OUT, we want it look to be lost in
> order to not have it block other interrupts inside the guest (i.e. there's 
> more
> to it than just guarding the host here).
> 
> "Luckily" commit 0f843ba00c ("vt-d: Allow pass-through of shared
> interrupts") introducing this has no description at all. Let's see if Kevin
> remembers any further details ...
> 

Sorry I don't remember more detail other than existing comments.
Roger, did you encounter a problem now?

Thanks
Kevin

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

Re: [Xen-devel] [PATCH RFC 00/20] Add postcopy live migration support

[Joshua Otto]

On Wed, Mar 29, 2017 at 11:50:52PM +0100, Andrew Cooper wrote:
> On 27/03/2017 10:06, Joshua Otto wrote:
> > Hi,
> >
> > We're a team of three fourth-year undergraduate software engineering 
> > students at
> > the University of Waterloo in Canada.  In late 2015 we posted on the list 
> > [1] to
> > ask for a project to undertake for our program's capstone design project, 
> > and
> > Andrew Cooper pointed us in the direction of the live migration 
> > implementation
> > as an area that could use some attention.  We were particularly interested 
> > in
> > post-copy live migration (as evaluated by [2] and discussed on the list at 
> > [3]),
> > and have been working on an implementation of this on-and-off since then.
> >
> > We now have a working implementation of this scheme, and are submitting it 
> > for
> > comment.  The changes are also available as the 'postcopy' branch of the 
> > GitHub
> > repository at [4]
> >
> > As a brief overview of our approach:
> > - We introduce a mechanism by which libxl can indicate to the libxc stream
> >   helper process that the iterative migration precopy loop should be 
> > terminated
> >   and postcopy should begin.
> > - At this point, we suspend the domain, collect the final set of dirty pfns 
> > and
> >   write these pfns (and _not_ their contents) into the stream.
> > - At the destination, the xc restore logic registers itself as a pager for 
> > the
> >   migrating domain, 'evicts' all of the pfns indicated by the sender as
> >   outstanding, and then resumes the domain at the destination.
> > - As the domain executes, the migration sender continues to push the 
> > remaining
> >   oustanding pages to the receiver in the background.  The receiver
> >   monitors both the stream for incoming page data and the paging ring event
> >   channel for page faults triggered by the guest.  Page faults are 
> > forwarded on
> >   the back-channel migration stream to the migration sender, which 
> > prioritizes
> >   these pages for transmission.
> >
> > By leveraging the existing paging API, we are able to implement the postcopy
> > scheme without any hypervisor modifications - all of our changes are 
> > confined to
> > the userspace toolstack.  However, we inherit from the paging API the
> > requirement that the domains be HVM and that the host have HAP/EPT support.
> 
> Wow.  Considering that the paging API has had no in-tree consumers (and
> its out-of-tree consumer folded), I am astounded that it hasn't bitrotten.

Well, there's tools/xenpaging, which was a helpful reference when
putting this together.  The user-space pager actually has rotted a bit
(I'm fairly certain the VM event ring protocol has changed subtly under
its feet), so I also needed to consult tools/xen-access to get things
right.

> 
> >
> > We haven't yet had the opportunity to perform a quantitative evaluation of 
> > the
> > performance trade-offs between the traditional pre-copy and our post-copy
> > strategies, but intend to.  Informally, we've been testing our 
> > implementation by
> > migrating a domain running the x86 memtest program (which is obviously a
> > tremendously write-heavy workload), and have observed a substantial 
> > reduction in
> > total time required for migration completion (at the expense of a visually
> > obvious 'slowdown' in the execution of the program).
> 
> Do you have any numbers, even for this informal testing?

We have a much more ambitious test matrix planned, but sure, here's an
early encouraging set of measurements - for a domain with 2GB of memory
and a 256MB writable working set (the application driving the writes
being fio submitting writes against a ramdisk), we measured these times:

Pre-copy + Stop-and-copy |  1 precopy iteration +
 (s) |   postcopy (s)
   --+-
 Precopy Duration:   66.97   | 44.44
 Suspend Duration:6.807  |  3.23
Postcopy Duration:N/A|  4.83

However...

That 3.23s suspend for the hybrid migration seems too high, doesn't it?

There's currently a serious performance bug that we're still trying to
work out in the case of pure-postcopy migrations, with no leading
precopy.  Attempting a pure postcopy migration when running the
experiment above yields:

 Pure postcopy (s)
   --
 Precopy Duration:   0
 Suspend Duration:  21.93
Postcopy Duration:  44.22

Although the postcopy scheme clearly works, it takes 21.93s (!) to
unpause the guest at the destination.  The eviction of the unmigrated
pages completes in a second or two because of the lack of batching
support (still bad, but not this bad) - the holdup is somewhere on the
domain creation sequence between domcreate_stream_done() and
domcreate_complete().

I suspect that this is the result of a bad 

[Xen-devel] Outreachy project - Xen Code Review Dashboard

[Vaishnavi Ramesh Jayaraman]

Hi,
I am Vaishnavi, interested in contributing to the Xen Project as part of
the Outreachy Program. I am particularly interested in working on the Xen
Code Review Dashboard.

I have worked on the ElasticSearch - Logstash- Kibana (ELK) stack
previously and am comfortable with Javascript.

It would be great if you could give me pointers on how to get started!

Also, I am unable to join the mailing list for this project -
metrics-grimo...@lists.libresoft.es


Could you please add me? Thanks!

Looking forward to contributing!

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

[Xen-devel] [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

[Nicolai Stange]

In preparation for making the clockevents core NTP correction aware,
all clockevent device drivers must set ->min_delta_ticks and
->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
clockevent device's rate is going to change dynamically and thus, the
ratio of ns to ticks ceases to stay invariant.

Make the x86 arch's xen clockevent driver initialize these fields properly.

This patch alone doesn't introduce any change in functionality as the
clockevents core still looks exclusively at the (untouched) ->min_delta_ns
and ->max_delta_ns. As soon as this has changed, a followup patch will
purge the initialization of ->min_delta_ns and ->max_delta_ns from this
driver.

Signed-off-by: Nicolai Stange 
---

Notes:
This prerequisite patch is part of a larger effort to feed NTP
corrections into the clockevent devices' frequencies and thus
avoiding their notion of time to diverge from the system's
one. If you're interested, the current state of the whole series
can be found at [1].

If you haven't got any objections and these prerequisites get
merged by 4.12 everywhere, I'll proceed with the remainder of
this series in 4.13.

Applicable to next-20170324 as well as to John' Stultz tree [2].

[1]
  git://nicst.de/linux.git cev-freq-adj.v10.fortglx-4.12-time
  
https://nicst.de/git/?p=linux.git;a=shortlog;h=refs/heads/cev-freq-adj.v10.fortglx-4.12-time

[2]
  https://git.linaro.org/people/john.stultz/linux.git fortglx/4.12/time

 arch/x86/xen/time.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1e69956d7852..7a3089285c59 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -209,7 +209,9 @@ static const struct clock_event_device 
xen_timerop_clockevent = {
.features   = CLOCK_EVT_FEAT_ONESHOT,
 
.max_delta_ns   = 0x,
+   .max_delta_ticks= 0x,
.min_delta_ns   = TIMER_SLOP,
+   .min_delta_ticks= TIMER_SLOP,
 
.mult   = 1,
.shift  = 0,
@@ -268,7 +270,9 @@ static const struct clock_event_device 
xen_vcpuop_clockevent = {
.features = CLOCK_EVT_FEAT_ONESHOT,
 
.max_delta_ns = 0x,
+   .max_delta_ticks = 0x,
.min_delta_ns = TIMER_SLOP,
+   .min_delta_ticks = TIMER_SLOP,
 
.mult = 1,
.shift = 0,
-- 
2.12.0


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

Re: [Xen-devel] [RFC PATCH 4/4] msi: taking interrupt format into consideration during judging a pirq is binded with a event channel

[Chao Gao]

On Thu, Mar 30, 2017 at 06:29:29PM +0100, Anthony PERARD wrote:
>On Fri, Mar 17, 2017 at 07:29:17PM +0800, Lan Tianyu wrote:
>> From: Chao Gao 
>> Subject: msi: taking interrupt format into consideration during
>> judging a pirq is binded with a event channel
>
>This is quite a long title, I think we can make it shorter. Maybe "msi:
>Handle MSI remapping format.

OK.

>
>>  data = pci_get_word(dev->config + msi_data_off(dev, msi64bit));
>> -if (xen_is_pirq_msi(data)) {
>> +addr_lo = pci_get_word(dev->config + msi_address_lo_off(dev));
>
>This could be get_long, so addr_lo will actually have the all low bits
>of the addr.

yes.

>
>> +int xen_is_pirq_msi(uint32_t msi_data, uint32_t msi_addr_lo)
>>  {
>> +/* If msi address is configurate to remapping format, the msi will not
>> + * remapped into a pirq.
>> + */
>> +if ( msi_addr_lo & 0x10 )
>
>That's a magic number, is 0x10 MSI_ADDR_IM_MASK?

Yes.

Really thanks for your comments.

>
>Thanks,
>
>-- 
>Anthony PERARD

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

Re: [Xen-devel] [RFC PATCH 3/4] xen-pt: bind/unbind interrupt remapping format MSI

[Chao Gao]

On Thu, Mar 30, 2017 at 05:51:45PM +0100, Anthony PERARD wrote:
>On Fri, Mar 17, 2017 at 07:29:16PM +0800, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
>> format. The original code isn't suitable to the new format. A new pair
>> bind/unbind interfaces are added for this usage. This patch recognizes
>> this case and use new interfaces to bind/unbind msi.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  hw/xen/xen_pt_msi.c   | 36 
>>  include/hw/i386/apic-msidef.h |  1 +
>>  2 files changed, 29 insertions(+), 8 deletions(-)
>> 
>> diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
>> index 62add06..8b0d7fc 100644
>> --- a/hw/xen/xen_pt_msi.c
>> +++ b/hw/xen/xen_pt_msi.c
>> @@ -161,6 +161,7 @@ static int msi_msix_update(XenPCIPassthroughState *s,
>>  uint8_t gvec = msi_vector(data);
>>  uint32_t gflags = msi_gflags(data, addr);
>>  int rc = 0;
>> +bool ir = !!(addr & MSI_ADDR_IM_MASK);
>>  uint64_t table_addr = 0;
>>  
>>  XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
>> @@ -171,8 +172,14 @@ static int msi_msix_update(XenPCIPassthroughState *s,
>>  table_addr = s->msix->mmio_base_addr;
>>  }
>>  
>> -rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
>> +if (ir) {
>
>You could maybe use add_ADDR_IM_MASK instead of going through a
>variable.
>
>> +rc = xc_domain_update_msi_irq_remapping(xen_xc, xen_domid, pirq,
>> +d->devfn, data, addr, table_addr);
>
>Do you also want to update the XEN_PT_LOG above? Since it does not
>always reflect the update_msi call anymore.

Yes. I adjust the output.

>
>> +}
>> +else {
>> +rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
>>pirq, gflags, table_addr);
>> +}
>>  
>>  if (rc) {
>>  XEN_PT_ERR(d, "Updating of MSI%s failed. (err: %d)\n",
>> @@ -204,13 +211,26 @@ static int msi_msix_disable(XenPCIPassthroughState *s,
>>  }
>>  
>>  if (is_binded) {
>> -XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
>> -   is_msix ? "-X" : "", pirq, gvec);
>> -rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, 
>> gflags);
>> -if (rc) {
>> -XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: %d, 
>> gvec: %#x)\n",
>> -   is_msix ? "-X" : "", errno, pirq, gvec);
>> -return rc;
>> +if ( addr & MSI_ADDR_IM_MASK ) {
>> +XEN_PT_LOG(d, "Unbinding of MSI%s . ( pirq: %d, data: %x, addr: 
>> %lx)\n",
>
>For addr, it should be PRIx64 instead of %lx.
>
>> +   is_msix ? "-X" : "", pirq, data, addr);
>> +rc = xc_domain_unbind_msi_irq_remapping(xen_xc, xen_domid, pirq,
>> +d->devfn, data, addr);
>> +if (rc) {
>> +XEN_PT_ERR(d, "Unbinding of MSI%s . (error: %d, pirq: %d, 
>> data: %x, addr: %lx)\n",
>> +   is_msix ? "-X" : "", rc, pirq, data, addr);
>> +return rc;
>> +}
>> +
>> +} else {
>> +XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
>> +   is_msix ? "-X" : "", pirq, gvec);
>> +rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, 
>> gflags);
>> +if (rc) {
>> +XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: 
>> %d, gvec: %#x)\n",
>> +   is_msix ? "-X" : "", errno, pirq, gvec);
>> +return rc;
>> +}
>>  }
>>  }
>>  
>> diff --git a/include/hw/i386/apic-msidef.h b/include/hw/i386/apic-msidef.h
>> index 8b4d4cc..08b584f 100644
>> --- a/include/hw/i386/apic-msidef.h
>> +++ b/include/hw/i386/apic-msidef.h
>> @@ -27,5 +27,6 @@
>>  #define MSI_ADDR_DEST_ID_SHIFT  12
>>  #define MSI_ADDR_DEST_IDX_SHIFT 4
>>  #define  MSI_ADDR_DEST_ID_MASK  0x000
>
>Could you add a 0 to dest_id here? So their will be 8 digit and it those
>not look weird when compared to the next define.
>

Will do.

>> +#define  MSI_ADDR_IM_MASK   0x0010
>
>Is the definition of MSI_ADDR_IM_MASK available somewhere? In the Intel
>SDM I've only found this bit to be reserved.

Yes, it is defined in VT-d spec 5.1.5.2 MSI and MSI-X Register Programming.
I made a mistake here. I should use MSI_ADDR_IF_MASK. 

Thanks
Chao

>
>Thanks,
>
>-- 
>Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 01/19] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check

[Wei Chen]

Hi Julien
On 2017/3/30 21:31, Julien Grall wrote:
> Hi Wei,
>
> On 30/03/17 10:13, Wei Chen wrote:
>> Xen will do exception syndrome check while some types of exception
>> take place in EL2. The syndrome check code read the ESR_EL2 register
>> directly, but in some situation this register maybe overridden by
>> nested exception.
>>
>> For example, if we re-enable IRQ before reading ESR_EL2 which means
>> Xen may enter in IRQ exception mode and return the processor with
>> clobbered ESR_EL2 (See ARM ARM DDI 0487A.j D7.2.25)
>>
>> In this case the guest exception syndrome has been overridden, we will
>> check the syndrome for guest sync exception with an incorrect ESR_EL2
>> value. So we want to save ESR_EL2 to cpu_user_regs as soon as the
>> exception takes place in EL2 to avoid using an incorrect syndrome value.
>>
>> In order to save ESR_EL2, we added a 32-bit member hsr to cpu_user_regs.
>> But while saving registers in trap entry, we use stp to save ELR and
>> CPSR at the same time through 64-bit general registers. If we keep this
>> code, the hsr will be overridden by upper 32-bit of CPSR. So adjust the
>> code to use str to save ELR in a separate instruction and use stp to
>> save CPSR and HSR at the same time through 32-bit general registers.
>> This change affects the registers restore in trap exit, we can't use the
>> ldp to restore ELR and CPSR from stack at the same time. We have to use
>> ldr to restore them separately.
>>
>> Signed-off-by: Wei Chen 
>>
>> ---
>
> As mentioned in the internal review, it would have been helpful to
> mention this is a bug fix and should be backported on Xen 4.8 and Xen 4.7.
>

Sorry about that, I will add it to the note in next version.

>
>> v1->v2:
>> 1. Use more accurate words in the commit message.
>> 2. Remove pointless comment message in cpu_user_regs.
>> 3. Explain the changes of the registers save/restore order in trap
>>entry/exit.
>> ---
>>  xen/arch/arm/arm32/asm-offsets.c  |  1 +
>>  xen/arch/arm/arm32/entry.S|  3 +++
>>  xen/arch/arm/arm64/asm-offsets.c  |  1 +
>>  xen/arch/arm/arm64/entry.S| 13 +
>>  xen/arch/arm/traps.c  |  2 +-
>>  xen/include/asm-arm/arm32/processor.h |  2 +-
>>  xen/include/asm-arm/arm64/processor.h |  3 +--
>
> A quick grep gives of ESR_EL2 in the code gives me:
>
> include/asm-arm/cpregs.h
> 308:#define ESR_EL2 HSR
>
> arch/arm/arm64/traps.c
> 35:union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
>
> arch/arm/traps.c
> 846:printk("   ESR_EL2: %08"PRIx32"\n", READ_SYSREG32(ESR_EL2));
> 2424: *  (the bit ESR_EL2.S1PTW is set)
> 2644:const union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
>
> The problem you describe also apply for the other READ_SYSREG32(ESR_EL2)
> and I was expecting to see them updated in this patch.
>

Yes, that's what I hadn't considered. I would cover them in next version.


> Cheers,
>


-- 
Regards,
Wei Chen

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

Re: [Xen-devel] [RFC PATCH 2/4] Xen: add a dummy vIOMMU to create/destroy vIOMMU in Xen

[Chao Gao]

On Thu, Mar 30, 2017 at 05:24:52PM +0100, Anthony PERARD wrote:
>Hi,
>
>On Fri, Mar 17, 2017 at 07:29:15PM +0800, Lan Tianyu wrote:
>> From: Chao Gao 
>> 
>> Since adding a dynamic sysbus device is forbidden, so choose TYPE_DEVICE
>> as parent class.
>> 
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
>> ---
>>  hw/xen/Makefile.objs |   1 +
>>  hw/xen/xen_viommu.c  | 116 
>> +++
>>  2 files changed, 117 insertions(+)
>>  create mode 100644 hw/xen/xen_viommu.c
>> 
>> +static void xen_viommu_realize(DeviceState *dev, Error **errp)
>> +{
>> +int rc;
>> +uint64_t cap;
>> +char *dom;
>> +char viommu_path[1024];
>> +XenVIOMMUState *s = XEN_VIOMMU_DEVICE(dev);
>> +
>> +s->id = -1;
>> +
>> +/* Read vIOMMU attributes from Xenstore. */
>> +dom = xs_get_domain_path(xenstore, xen_domid);
>> +snprintf(viommu_path, sizeof(viommu_path), "%s/viommu", dom);
>> +rc = xenstore_read_uint64(viommu_path, "base_addr", >base_addr);  
>
>Could these informations (base_addr and cap) be read from the command
>line instead of via xenstore?
>Any reason for these informations to be on xenstore?

Actually, we passed both via command line at first. We just concerned
whether it was ok to pass a address through command line since
we find no device does the similar thing.

>
>> +if (rc) {
>> +error_report("Can't get base address of vIOMMU");
>
>I think error_setg should be used instead of error_report.
>
>> +exit(1);
>
>Also, exit should be remove, and return instead. error_setg would be
>enough to signal that the device can not work.
>
>> +}
>> +
>> +rc = xenstore_read_uint64(viommu_path, "cap", >cap);
>> +if (rc) {
>> +error_report("Can't get capabilities of vIOMMU");
>> +exit(1);
>> +}
>> +
>> +rc = xc_viommu_query_cap(xen_xc, xen_domid, );
>
>Since xc_viommu_* seems to be new, you should use
>xendevicemodel_viommu_* instead, also you will need to define a stub for
>them to be able to compile QEMU against older version of Xen.

Will follow your suggestions above.

Thanks
Chao

>
>
>The patch looks good otherwise.
>
>Thanks,
>
>-- 
>Anthony PERARD

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

Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu operations in libxc

[Chao Gao]

On Wed, Mar 29, 2017 at 09:08:06AM +, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
>> Chao Gao
>> Sent: 29 March 2017 01:40
>> To: Wei Liu 
>> Cc: Lan Tianyu ; Kevin Tian ;
>> Ian Jackson ; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu
>> operations in libxc
>> 
>> Tianyu is on vacation this two weeks, so I will try to address
>> some comments on this series.
>> 
>> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote:
>> >On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote:
>> >> From: Chao Gao 
>> >>
>> >> In previous patch, we introduce a common vIOMMU layer. In our design,
>> >> we create/destroy vIOMMU through DMOP interface instead of creating
>> it
>> >> according to a config flag of domain. It makes it is possible
>> >> to create vIOMMU in device model or in tool stack.
>> >>
>
>I've not been following this closely so apologies if this has already been 
>asked...
>
>Why would you need to create a vIOMMU instance in an external device model.
> Since the toolstack should be in control of the device model configuration 
> why would it not know in advance that one was required?

I assume your question is why we don't create a vIOMMU instance via hypercall 
in toolstack.
I think creating in toolstack is also ok and is easier to be reused by pvh.

If Tianyu has no concern about this, will move this part to toolstack.

Thanks,
Chao

>
>  Paul
>
>> >> The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls:
>> >
>> >Hypercalls, not syscalls.
>> >
>> >>  - query capabilities of vIOMMU emulated by Xen
>> >>  - create vIOMMU in Xen hypervisor with base address, capability
>> >>  - destroy vIOMMU specified by viommu_id
>> >>
>> >> Signed-off-by: Chao Gao 
>> >> Signed-off-by: Lan Tianyu 
>> >> ---
>> >>  tools/libs/devicemodel/core.c   | 69
>> +
>> >>  tools/libs/devicemodel/include/xendevicemodel.h | 35 +
>> >>  tools/libs/devicemodel/libxendevicemodel.map|  3 ++
>> >>  tools/libxc/include/xenctrl_compat.h|  5 ++
>> >>  tools/libxc/xc_devicemodel_compat.c | 18 +++
>> >>  5 files changed, 130 insertions(+)
>> >>
>> >> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
>> >> index a85cb49..aee1150 100644
>> >> --- a/tools/libs/devicemodel/core.c
>> >> +++ b/tools/libs/devicemodel/core.c
>> >
>> >Bear in mind that this library is stable, so whatever ends up here can
>> >change in the future.
>> >
>> >This is not saying the following code is problematic. It is just a
>> >general FYI.
>> >
>> >Obviously the toolstack side is going to follow the hypervisor
>> >interface, so I will do a detailed review later.
>> 
>> Sure. If the hypervisor interface settles down, we can inform you.
>> 
>> >
>> >> +int xendevicemodel_viommu_destroy(
>> >> +xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id);
>> >>  #endif /* __XEN_TOOLS__ */
>> >>
>> >>  #endif /* XENDEVICEMODEL_H */
>> >> diff --git a/tools/libs/devicemodel/libxendevicemodel.map
>> b/tools/libs/devicemodel/libxendevicemodel.map
>> >> index 45c773e..c2e0968 100644
>> >> --- a/tools/libs/devicemodel/libxendevicemodel.map
>> >> +++ b/tools/libs/devicemodel/libxendevicemodel.map
>> >> @@ -17,6 +17,9 @@ VERS_1.0 {
>> >>   xendevicemodel_modified_memory;
>> >>   xendevicemodel_set_mem_type;
>> >>   xendevicemodel_inject_event;
>> >> + xendevicemodel_viommu_query_cap;
>> >> + xendevicemodel_viommu_create;
>> >> + xendevicemodel_viommu_destroy;
>> >>   xendevicemodel_restrict;
>> >>   xendevicemodel_close;
>> >
>> >I suppose this series is going to miss 4.9.
>> >
>> >Please add these functions to VERS_1.1.
>> 
>> Yes. We will fix this.
>> 
>> >
>> >>   local: *; /* Do not expose anything by default */
>> >> diff --git a/tools/libxc/include/xenctrl_compat.h
>> b/tools/libxc/include/xenctrl_compat.h
>> >> index 040e7b2..315c45d 100644
>> >> --- a/tools/libxc/include/xenctrl_compat.h
>> >> +++ b/tools/libxc/include/xenctrl_compat.h
>> >> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type(
>> >>  int xc_hvm_inject_trap(
>> >>  xc_interface *xch, domid_t domid, int vcpu, uint8_t vector,
>> >>  uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2);
>> >> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t
>> *cap);
>> >> +int xc_viommu_create(
>> >> +xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap,
>> >> +uint32_t *viommu_id);
>> >> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t
>> viommu_id);
>> >>
>> >>  #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */
>> >>
>> >> diff --git a/tools/libxc/xc_devicemodel_compat.c
>> 

Re: [Xen-devel] [PATCH v3 1/9] x86/mce: handle LMCE locally

[Haozhong Zhang]

On 03/30/17 08:35 -0600, Jan Beulich wrote:
> >>> On 30.03.17 at 08:19,  wrote:
> > --- a/xen/arch/x86/cpu/mcheck/mce.c
> > +++ b/xen/arch/x86/cpu/mcheck/mce.c
> > @@ -42,6 +42,13 @@ DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, 
> > poll_bankmask);
> >  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
> >  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, mce_clear_banks);
> >  
> > +/*
> > + * Flag to indicate that at least one non-local MCE on this CPU has
> > + * not been completed handled. It's set by mcheck_cmn_handler() and
> 
> completely
> 
> > + * cleared by mce_softirq().
> > + */
> > +static DEFINE_PER_CPU(bool, nonlocal_mce_in_progress);
> 
> Does a boolean really suffice here? I.e. can't there be a 2nd one
> while the first one is still being dealt with?

It's to indicate the existence of a non-local MCE, and mce_softirq()
will call mctelem_process_deferred() to handle all MCE's if it's true,
so a boolean flag is suffice.

Haozhong

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

Re: [Xen-devel] [PATCH v3] xen/arm32: Introduce alternative runtime patching

[Wei Chen]

Hi Julien,

On 2017/3/30 20:55, Julien Grall wrote:
> Hi Wei,
>
> On 30/03/17 10:02, Wei Chen wrote:
>> +/* Unconditional branch instructions */
>> +/*
>> + * From ARM DDI 0406C.c Section A8.8.25. We can see blx has a H bit.
>> + * In an ARM/Thumb instructions mixed running environment, this bit
>> + * can be 1 or 0. Although Xen is only using the ARM instructions
>> + * and the H bit is always 0. We mask this bit to catch both of these
>> + * two encodings for future-proof.
>> + */
>> +__AARCH32_INSN_FUNCS(blx, 0x0E00, 0x0A00)
>> +
>> +int32_t aarch32_get_branch_offset(uint32_t insn);
>> +uint32_t aarch32_set_branch_offset(uint32_t insn, int32_t offset);
>> +
>> +/* Wrapper for common code */
>> +static inline bool insn_is_branch_imm(uint32_t insn)
>> +{
>> +/* Check conditional branch instructions */
>> +if ( __CONDITIONAL_INSN(insn) )
>
> This is not what I asked. Whilst I am happy to see a different solution
> this one is completely wrong. b and bl instruction cannot be
> unconditional and a user of the helpers aarch32_insn_is_{b,bl} would
> expect them to do the right things.
>
> By "open-coding" I meant dropping the macro __AARCH32_INS_FUNCS and
> directly implement insn_is_branch_imm with:
>
> return ( (insn & 0x0E00) == 0x0A00 );
>
> With the comment on top explain the check.
>

Thanks. This will make the code more clear. I would add comment to code
to explain this check.

> Cheers,
>


-- 
Regards,
Wei Chen

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail REGR. vs. 106959
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106959
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106959
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106959
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106959
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106959
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106959
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106959

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   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
 build-arm64-pvops 5 kernel-build fail   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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 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-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9614f0246688d1e4cee4d6bec47894b6e289c721
baseline version:
 xen  ac9ff74f39a734756af90ccbb7184551f7b1e22a

Last test of basis   106959  2017-03-28 09:14:17 Z2 days
Failing since106979  2017-03-29 16:19:31 Z1 days3 attempts
Testing same since   107005  2017-03-30 15:45:14 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jonathan Davies 
  Joshua Otto 
  Juergen Gross 
  Owen Smith 
  Paul 

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

[Wei Chen]

Hi Julien and Stefano,

On 2017/3/31 6:03, Stefano Stabellini wrote:
> On Thu, 30 Mar 2017, Julien Grall wrote:
>> Hi Wei,
>>
>> On 30/03/17 10:13, Wei Chen wrote:
>>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>> index de59e5f..8af223e 100644
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -2171,6 +2171,13 @@ int construct_dom0(struct domain *d)
>>>  return rc;
>>>
>>>  /*
>>> + * The HCR_EL2 will temporarily switch to dom0's HCR_EL2 value
>>> + * by p2m_restore_state. We have to save HCR_EL2 to idle vCPU's
>>> + * context for restoring it in later.
>>> + */
>>> +current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
>>
>> I don't understand why we care here. idle vCPU will never restore HCR_EL2 nor
>> return from the hypervisor.
>
> I don't understand this either
>

Yes, idle vCPU will never return from hypervisor. But in construct_dom0,
it has one chance to restore HCR_EL2.
In in construct_dom0 we will call p2m_restore_state twice.
 saved_current = current;
 p2m_restore_state(v); --->> This is dom0's vCPU0
 [...]
 set_current(saved_current);
 p2m_restore_state(saved_current); --->> this is idle vCPU0

In p2m_restore_state, we will write vcpu->arch.hcr_el2 to HCR_EL2. in
this case, we will write an unknown value to HCR_EL2. Even though this
would not cause any problem from my current testing. But from code
scope, I think it would be a drawback.



-- 
Regards,
Wei Chen

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

[Xen-devel] [xen-4.8-testing baseline-only test] 71125: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71125 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71125/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf   4 capture-logs  broken baseline untested
 build-armhf-xsm   4 capture-logs  broken baseline untested
 build-armhf-pvops 4 capture-logs  broken baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-saverestore.2 
fail baseline untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 17 
guest-start/debianhvm.repeat fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail baseline untested

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-armhf-pvops 3 host-install(3)  broken never pass
 build-armhf   3 host-install(3)  broken never pass
 build-armhf-xsm   3 host-install(3)  broken never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  ca41491f0507150139fc35ff6c9f076fdbe9487b
baseline version:
 xen  eca97a466dc8d8f99fbff8f51a117d6e8255ecdc

Last test of basis71102  2017-03-27 05:53:24 Z3 days
Testing same since71125  2017-03-30 16:14:44 Z0 days1 attempts


People who touched revisions under test:
  Stefano Stabellini 
  Wei Chen 

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

[Xen-devel] [ovmf baseline-only test] 71126: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 host-ping-check-xen fail REGR. vs. 71124

version targeted for testing:
 ovmf f663ed8a328a6d5007d3f03685f08cfceb506105
baseline version:
 ovmf d3017dd96bf96521cbb87a26bb9dd09f8aa5811d

Last test of basis71124  2017-03-30 08:50:06 Z0 days
Testing same since71126  2017-03-30 17:21:48 Z0 days1 attempts


People who touched revisions under test:
  Qin Long 

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 fail
 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 f663ed8a328a6d5007d3f03685f08cfceb506105
Author: Qin Long 
Date:   Thu Mar 30 15:53:21 2017 +0800

CryptoPkg/BaseCryptLib: Fix Build Warning issue in PEI Module

The memory free operation is empty function in PEI. The compiler
optimization will bring the build warning in openssl/crypto/mem.c:
  warning C4718: 'CRYPTO_free': recursive call has no side
 effects, deleting
This patch uses '/wd4718' to silence the build warning for PEI
module building.

Cc: Ting Ye 
Cc: Eric Dong 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
Reviewed-by: Eric Dong 
Reviewed-by: Ye Ting 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106977
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106977
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106977
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106977
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 106977
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106977

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   5 xen-buildfail   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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   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
 build-arm64-pvops 5 kernel-build fail   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-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuub529aec1ee1cbb642f236893bf46a712d0187e4d
baseline version:
 qemuudf9046363220e57d45818312759b954c033c58ab

Last test of basis   106977  2017-03-29 16:16:55 Z1 days
Testing same since   106999  2017-03-30 12:16:09 Z0 days1 attempts


People who touched revisions under test:
  Eduardo Habkost 
  Jiri Denemark 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt   

[Xen-devel] [PATCH] xl: Add 'pvh' config option

[Boris Ostrovsky]

In addition to 'device_model_version="none"' config option users can
also use 'pvh=1' in xl configuration file when creating a PVH guest.

We can skip parsing options related to device model once we establish
that we are building PVH guest.

Also process 'device_model_version="none"' for HVM guests only since
it is not a valid model for PV guests.

Signed-off-by: Boris Ostrovsky 
---
 docs/man/xl.cfg.pod.5.in |  7 ++-
 tools/xl/xl_parse.c  | 12 +++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 206d33e..5833987 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1201,6 +1201,11 @@ expose unexpected bugs in the guest, or find bugs in 
Xen, so it is
 possible to disable this feature.  Use of out of sync page tables,
 when Xen thinks it appropriate, is the default.
 
+=item 

[Xen-devel] [PATCH v2 2/2] ACPICA: IORT: Add in support for the SMMUv3 subtable

[Sameer Goel]

From: Al Stone 

ACPICA commit 9f7c3e148f440049615e2791d73b292f65692d7e

The most recent version of the IORT specification adds in a definition
for a subtable to describe SMMUv3 devices; there is already a subtable
for SMMUv1/v2 devices.

Add in the definition of the subtable, add in the code to compile it,
and add in a template for it.

Link: https://github.com/acpica/acpica/commit/9f7c3e14
Signed-off-by: Al Stone 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
[Linux commit 4ac78baf88d85c49883fcc87d31198ebe408e54d]
Signed-off-by: Sameer Goel 
---
 xen/include/acpi/actbl2.h | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 7d66014..d1cd148 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -560,7 +560,7 @@ struct acpi_ibft_target {
  * IORT - IO Remapping Table
  *
  * Conforms to "IO Remapping Table System Software on ARM Platforms",
- * Document number: ARM DEN 0049A, 2015
+ * Document number: ARM DEN 0049B, October 2015
  *
  
**/
 
@@ -590,7 +590,8 @@ enum acpi_iort_node_type {
ACPI_IORT_NODE_ITS_GROUP = 0x00,
ACPI_IORT_NODE_NAMED_COMPONENT = 0x01,
ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
-   ACPI_IORT_NODE_SMMU = 0x03
+   ACPI_IORT_NODE_SMMU = 0x03,
+   ACPI_IORT_NODE_SMMU_V3 = 0x04
 };
 
 struct acpi_iort_id_mapping {
@@ -680,6 +681,23 @@ struct acpi_iort_smmu {
 #define ACPI_IORT_SMMU_DVM_SUPPORTED(1)
 #define ACPI_IORT_SMMU_COHERENT_WALK(1<<1)
 
+struct acpi_iort_smmu_v3 {
+   u64 base_address;   /* SMMUv3 base address */
+   u32 flags;
+   u32 reserved;
+   u64 vatos_address;
+   u32 model;  /* O: generic SMMUv3 */
+   u32 event_gsiv;
+   u32 pri_gsiv;
+   u32 gerr_gsiv;
+   u32 sync_gsiv;
+};
+
+/* Masks for Flags field above */
+
+#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE   (1)
+#define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1)
+
 
/***
  *
  * IVRS - I/O Virtualization Reporting Structure
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. 
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [PATCH v2 0/2] Support for IORT table

[Sameer Goel]

This patch set adds definitions for IORT ACPI table. The header file
definitions are ported from Linux Kernel source.

Al Stone (1):
  ACPICA: IORT: Add in support for the SMMUv3 subtable

Lv Zheng (1):
  ACPICA: ACPI 6.0: Add support for IORT table.

 xen/include/acpi/actbl2.h | 144 ++
 1 file changed, 144 insertions(+)

-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. 
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

[Xen-devel] [PATCH v2 1/2] ACPICA: ACPI 6.0: Add support for IORT table.

[Sameer Goel]

From: Lv Zheng 

ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca

This patch adds support for IORT (IO Remapping Table) in iasl.

Note that some field names are modified to shrink their length or the
decompiled IORT ASL will contain fields with ugly ":" alignment.

The IORT contains field definitions around "Memory Access Properties". This
patch also adds support to encode/decode it using inline table.

This patch doesn't add inline table support for the SMMU interrupt fields
due to a limitation in current ACPICA data table support. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/5de82757
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki 
[Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf]
Signed-off-by: Sameer Goel 
---
 xen/include/acpi/actbl2.h | 126 ++
 1 file changed, 126 insertions(+)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index d2327d2..7d66014 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -69,6 +69,7 @@
 #define ACPI_SIG_HPET   "HPET" /* High Precision Event Timer table */
 #define ACPI_SIG_IBFT   "IBFT" /* i_sCSI Boot Firmware Table */
 #define ACPI_SIG_IVRS   "IVRS" /* I/O Virtualization Reporting 
Structure */
+#define ACPI_SIG_IORT   "IORT" /* IO Remapping Table */
 #define ACPI_SIG_MCFG   "MCFG" /* PCI Memory Mapped Configuration 
table */
 #define ACPI_SIG_MCHI   "MCHI" /* Management Controller Host Interface 
table */
 #define ACPI_SIG_SLIC   "SLIC" /* Software Licensing Description Table 
*/
@@ -556,6 +557,131 @@ struct acpi_ibft_target {
 
 
/***
  *
+ * IORT - IO Remapping Table
+ *
+ * Conforms to "IO Remapping Table System Software on ARM Platforms",
+ * Document number: ARM DEN 0049A, 2015
+ *
+ 
**/
+
+struct acpi_table_iort {
+   struct acpi_table_header header;
+   u32 node_count;
+   u32 node_offset;
+   u32 reserved;
+};
+
+/*
+ * IORT subtables
+ */
+struct acpi_iort_node {
+   u8 type;
+   u16 length;
+   u8 revision;
+   u32 reserved;
+   u32 mapping_count;
+   u32 mapping_offset;
+   char node_data[1];
+};
+
+/* Values for subtable Type above */
+
+enum acpi_iort_node_type {
+   ACPI_IORT_NODE_ITS_GROUP = 0x00,
+   ACPI_IORT_NODE_NAMED_COMPONENT = 0x01,
+   ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
+   ACPI_IORT_NODE_SMMU = 0x03
+};
+
+struct acpi_iort_id_mapping {
+   u32 input_base; /* Lowest value in input range */
+   u32 id_count;   /* Number of IDs */
+   u32 output_base;/* Lowest value in output range */
+   u32 output_reference;   /* A reference to the output node */
+   u32 flags;
+};
+
+/* Masks for Flags field above for IORT subtable */
+
+#define ACPI_IORT_ID_SINGLE_MAPPING (1)
+
+struct acpi_iort_memory_access {
+   u32 cache_coherency;
+   u8 hints;
+   u16 reserved;
+   u8 memory_flags;
+};
+
+/* Values for cache_coherency field above */
+
+#define ACPI_IORT_NODE_COHERENT 0x0001 /* The device node is 
fully coherent */
+#define ACPI_IORT_NODE_NOT_COHERENT 0x /* The device node is 
not coherent */
+
+/* Masks for Hints field above */
+
+#define ACPI_IORT_HT_TRANSIENT  (1)
+#define ACPI_IORT_HT_WRITE  (1<<1)
+#define ACPI_IORT_HT_READ   (1<<2)
+#define ACPI_IORT_HT_OVERRIDE   (1<<3)
+
+/* Masks for memory_flags field above */
+
+#define ACPI_IORT_MF_COHERENCY  (1)
+#define ACPI_IORT_MF_ATTRIBUTES (1<<1)
+
+/*
+ * IORT node specific subtables
+ */
+struct acpi_iort_its_group {
+   u32 its_count;
+   u32 identifiers[1]; /* GIC ITS identifier arrary */
+};
+
+struct acpi_iort_named_component {
+   u32 node_flags;
+   u64 memory_properties;  /* Memory access properties */
+   u8 memory_address_limit;/* Memory address size limit */
+   char device_name[1];/* Path of namespace object */
+};
+
+struct acpi_iort_root_complex {
+   u64 memory_properties;  /* Memory access properties */
+   u32 ats_attribute;
+   u32 pci_segment_number;
+};
+
+/* Values for ats_attribute field above */
+
+#define ACPI_IORT_ATS_SUPPORTED 0x0001 /* The root complex 
supports ATS */
+#define ACPI_IORT_ATS_UNSUPPORTED   0x /* The root complex 
doesn't support ATS */
+
+struct acpi_iort_smmu {
+   u64 base_address;   /* SMMU base address */
+   u64 span;   /* Length of memory range */
+   u32 model;
+   u32 flags;
+   u32 global_interrupt_offset;
+   u32 context_interrupt_count;
+   u32 

Re: [Xen-devel] [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

[Boris Ostrovsky]

On 03/30/2017 04:06 PM, Nicolai Stange wrote:
> In preparation for making the clockevents core NTP correction aware,
> all clockevent device drivers must set ->min_delta_ticks and
> ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
> clockevent device's rate is going to change dynamically and thus, the
> ratio of ns to ticks ceases to stay invariant.
>
> Make the x86 arch's xen clockevent driver initialize these fields properly.
>
> This patch alone doesn't introduce any change in functionality as the
> clockevents core still looks exclusively at the (untouched) ->min_delta_ns
> and ->max_delta_ns. As soon as this has changed, a followup patch will
> purge the initialization of ->min_delta_ns and ->max_delta_ns from this
> driver.
>
> Signed-off-by: Nicolai Stange 

Reviewed-by: Boris Ostrovsky 



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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 072060a6f81b3e43473b9e5dcba7049ad9de4b18
baseline version:
 ovmf f663ed8a328a6d5007d3f03685f08cfceb506105

Last test of basis   106996  2017-03-30 09:09:57 Z0 days
Testing same since   107008  2017-03-30 20:45:03 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Phil Dennis-Jordan 

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=072060a6f81b3e43473b9e5dcba7049ad9de4b18
+ . ./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 
072060a6f81b3e43473b9e5dcba7049ad9de4b18
+ branch=ovmf
+ revision=072060a6f81b3e43473b9e5dcba7049ad9de4b18
+ . ./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.8-testing
+ '[' x072060a6f81b3e43473b9e5dcba7049ad9de4b18 = 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] [linux-linus test] 106998: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linux89970a04d70c6c9e5e4492fd4096c0b5630a478c
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  630 days
Failing since 59348  2015-07-10 04:24:05 Z  629 days  365 attempts
Testing same since   106998  2017-03-30 11:52:36 Z0 days1 attempts


8116 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl 

[Xen-devel] [PATCH] setup vwfi correctly on cpu0

[Stefano Stabellini]

parse_vwfi runs after init_traps on cpu0, potentially resulting in the
wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their
case init_traps will write the correct set of flags to HCR_EL2.

For cpu0, fix the issue by changing HCR_EL2 setting directly in
parse_vwfi.

Signed-off-by: Stefano Stabellini 

---
This patch should be apply to 4.8, 4.7, 4.6, not to unstable (it will be
fixed differently there).
---
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 614501f..94d2e8a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -112,6 +112,16 @@ static void __init parse_vwfi(const char *s)
vwfi = NATIVE;
else
vwfi = TRAP;
+/*
+ * HCR_EL2 has already been set on cpu0, change the setting here, if
+ * needed. Other cpus haven't booted yet, init_traps will setup
+ * HCR_EL2 correctly.
+ */
+if (vwfi == NATIVE) {
+register_t hcr;
+hcr = READ_SYSREG(HCR_EL2);
+WRITE_SYSREG(hcr & ~(HCR_TWI|HCR_TWE), HCR_EL2);
+}
 }
 custom_param("vwfi", parse_vwfi);
 

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

Re: [Xen-devel] [PATCH v2 02/19] xen/arm: Remove vwfi while setting HCR_EL2 in init_traps

[Stefano Stabellini]

On Thu, 30 Mar 2017, Julien Grall wrote:
> Hi Wei,
> 
> On 30/03/17 10:13, Wei Chen wrote:
> > We will set HCR_EL2 for each domain individually at the place where each
> > domain is created. vwfi will affect the behavior of VM trap. Initialize
> > the HCR_EL2 in init_traps is a generic setting for AT translations while
> > creating dom0.
> 
> This statement looks wrong. Any AT s1s2 translations (i.e on behalf of the
> guest) should be done after a call to p2m_restore_state that restore HCR_EL2,
> SCTLR_EL1, VTTBR_EL1. If it is not the case, then there is an error.
> 
> > After dom0 has been created, the HCR_EL2 will use the saved
> > value in dom0's context. So checking vwfi in init_trap is pointless.
> > 
> > Signed-off-by: Wei Chen 
> 
> This is a nack from me. We don't remove feature even temporarily without any
> strong reasons. This is making more difficult to track the history of a
> feature and a call to forget to restore it correctly later on or removing the
> feature if we ever decide to revert the patch which adds back the feature (see
> patch #4).
> 
> I would prefer to see patch #2, #3 squashed into #4, the patch will not be
> that big (50 lines) and avoid to drop a feature temporarily.

Yes, please.


> But I am not convinced about your reasons.
> > ---
> > I have tried to remove HCR_EL2 setting from init_traps, but the Xen will
> > hang at the place of creating domain0. The console hot key can work, so
> > the Xen is alive, not panic.
> 
> With the limited description you provided it is hard to know what's going on.
> In the future please try to provide meaningful details (platform used,
> debugging you have done...). Anyway, I have done some debug and I don't end up
> to the same conclusion as you.
> 
> I tried on different boards, and it gets stuck when initializing stage-2 page
> table configuration on each CPU (see setup_virt_paging). The secondary CPUs
> don't receive the SGI.
> 
> Reading a bit more the ARM ARM (D7.2.33 in ARM DDI 0487A.k_iss10775), HCR_EL2
> is unknown at reset. Whilst I already knew that, I would have expected to have
> no impact on EL2 (at least in the non-VHE case). However, the value of the
> {A,I,F}MO bits will affect the routing of physical IRQs to Xen.
> 
> I have only gone quickly through the spec, so it might be possible to have
> other necessary bits. It might be good to keep initialization here until
> someone sit in front of the spec for few hours and check everything.
> 
> So in this case I would prefer to keep the helper avoiding to have declared
> twice the same flags. Stefano any opinions?

I don't particularly care whether we keep the helper or not. From what
you say we need to set HCR_EL2 in init_traps, but given that's only
temporary, we don't necessarily need to write the same set of flags: for
example HCR_TWI|HCR_TWE are useless at this stage. A minimal set would
suffice. Either way, it's fine by me.


> Also, whilst I was debugging the problem I noticed the vwfi option does not
> work properly on CPU0. Indeed, the command line has not been parsed when
> init_traps is called on CPU0. This is should be fixed by patch #4 in this
> series, but I don't think we want to backport it.

No, we don't want to backport patch #4.


> Stefano, would you be up to write a patch for this?

I am thinking that the patch should only to fix the backports, given
that unstable and 4.9 will be fixed by this series (and given that it's
pretty ugly). I'll send it separately shortly.

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

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

[Stefano Stabellini]

On Thu, 30 Mar 2017, Julien Grall wrote:
> Hi Wei,
> 
> On 30/03/17 10:13, Wei Chen wrote:
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index de59e5f..8af223e 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2171,6 +2171,13 @@ int construct_dom0(struct domain *d)
> >  return rc;
> > 
> >  /*
> > + * The HCR_EL2 will temporarily switch to dom0's HCR_EL2 value
> > + * by p2m_restore_state. We have to save HCR_EL2 to idle vCPU's
> > + * context for restoring it in later.
> > + */
> > +current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
> 
> I don't understand why we care here. idle vCPU will never restore HCR_EL2 nor
> return from the hypervisor.

I don't understand this either

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

Re: [Xen-devel] [PATCH v2 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

[Julien Grall]

On 30/03/2017 22:49, Stefano Stabellini wrote:

On Thu, 30 Mar 2017, Wei Chen wrote:

+/*
+ * If the SErrors option is "FORWARD", we have to prevent forwarding
+ * serror to wrong vCPU. So before context switch, we have to use the
+ * synchronize_serror to guarantee that the pending serror would be
+ * caught by current vCPU.
+ *
+ * The SKIP_CTXT_SWITCH_SERROR_SYNC will be set to cpu_hwcaps when the
+ * SErrors option is NOT "FORWARD".
+ */
+asm volatile(ALTERNATIVE("bl synchronize_serror",
+ "nop",
+ SKIP_CTXT_SWITCH_SERROR_SYNC));



This good, but here you need to add:

  barrier();

because the compiler is free to reorder even asm volatile instructions
(it could move the asm volatile after __context_switch theoretically).


... or it could moved before hand because there are no barrier... What 
you want to use is asm volatile(ALTERNATIVE(...) : : : "memory");


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

[Stefano Stabellini]

On Thu, 30 Mar 2017, Wei Chen wrote:
> If there is a pending SError while we are doing context switch, if the
> SError handle option is "FORWARD", We have to guranatee this serror to
> be caught by current vCPU, otherwise it will be caught by next vCPU and
> be forwarded to this wrong vCPU.
> 
> So we have to synchronize SError before switch to next vCPU. But this is
> only required by "FORWARD" option. In this case we added a new flag
> SKIP_CTXT_SWITCH_SERROR_SYNC in cpu_hwcaps to skip synchronizing SError
> in context switch for other options. In the meantime, we don't need to
> export serror_op accessing to other source files.
> 
> Signed-off-by: Wei Chen 
> ---
> v1->v2:
> 1. Added a new flag in cpu_hwcaps to avoid using serror_op to skip
>synchronizing SError in context switch.
> 2. Update commit message to explain why we added this cpu_hwcaps.
> ---
>  xen/arch/arm/domain.c| 14 ++
>  xen/arch/arm/traps.c |  3 +++
>  xen/include/asm-arm/cpufeature.h |  3 ++-
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 18b34e7..e866ed3 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -326,6 +327,19 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>  
>  local_irq_disable();
>  
> +/*
> + * If the SErrors option is "FORWARD", we have to prevent forwarding
> + * serror to wrong vCPU. So before context switch, we have to use the
> + * synchronize_serror to guarantee that the pending serror would be
> + * caught by current vCPU.
> + *
> + * The SKIP_CTXT_SWITCH_SERROR_SYNC will be set to cpu_hwcaps when the
> + * SErrors option is NOT "FORWARD".
> + */
> +asm volatile(ALTERNATIVE("bl synchronize_serror",
> + "nop",
> + SKIP_CTXT_SWITCH_SERROR_SYNC));


This good, but here you need to add:

  barrier();

because the compiler is free to reorder even asm volatile instructions
(it could move the asm volatile after __context_switch theoretically).


>  set_current(next);
>  
>  prev = __context_switch(prev, next);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 55d85ed..9b4546e 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -125,6 +125,9 @@ static int __init update_serrors_cpu_caps(void)
>  if ( serrors_op != SERRORS_DIVERSE )
>  cpus_set_cap(SKIP_CHECK_PENDING_VSERROR);
>  
> +if ( serrors_op != SERRORS_FORWARD )
> +cpus_set_cap(SKIP_CTXT_SWITCH_SERROR_SYNC);
> +
>  return 0;
>  }
>  __initcall(update_serrors_cpu_caps);
> diff --git a/xen/include/asm-arm/cpufeature.h 
> b/xen/include/asm-arm/cpufeature.h
> index ec3f9e5..99ecb2b 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -41,8 +41,9 @@
>  #define ARM64_WORKAROUND_834220 3
>  #define LIVEPATCH_FEATURE   4
>  #define SKIP_CHECK_PENDING_VSERROR 5
> +#define SKIP_CTXT_SWITCH_SERROR_SYNC 6
>  
> -#define ARM_NCAPS   6
> +#define ARM_NCAPS   7
>  
>  #ifndef __ASSEMBLY__
>  
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH v2 12/19] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header

[Stefano Stabellini]

On Thu, 30 Mar 2017, Wei Chen wrote:
> We want to move part of SErrors checking code from hyp_error assembly code
> to a function. This new function will use this macro to distinguish the
> guest SErrors from hypervisor SErrors. So we have to move this macro to
> common header.
> 
> The VABORT_GEN_BY_GUEST macro used two symbols abort_guest_exit_start and
> abort_guest_exit_end. After we moved this macro to common header, we
> should export these two symbols to other source files that will use
> VABORT_GEN_BY_GUEST macro. So we change these two symbols to global.

Please rewrite this to:

  The VABORT_GEN_BY_GUEST macro uses the symbols abort_guest_exit_start
  and abort_guest_exit_end. After we move this macro to a common header,
  we need to make sure that the two symbols are visible to other source
  files. Currently, they are declared .global in arm32/entry.S, but not
  arm64/entry.S. Fix that.

Reviewed-by: Stefano Stabellini 


> Signed-off-by: Wei Chen 
> ---
> v1->v2:
> 1. Explain in commit message why we change abort_guest_exit_start and
>abort_guest_exit_end to global.
> ---
>  xen/arch/arm/arm64/entry.S|  2 ++
>  xen/include/asm-arm/arm32/processor.h | 10 --
>  xen/include/asm-arm/processor.h   | 10 ++
>  3 files changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 4baa3cb..113e1c3 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -380,10 +380,12 @@ check_pending_vserror:
>   * exception handler, and the elr_el2 will be set to
>   * abort_guest_exit_start or abort_guest_exit_end.
>   */
> +.global abort_guest_exit_start
>  abort_guest_exit_start:
>  
>  isb
>  
> +.global abort_guest_exit_end
>  abort_guest_exit_end:
>  /* Mask PSTATE asynchronous abort bit, close the checking window. */
>  msr daifset, #4
> diff --git a/xen/include/asm-arm/arm32/processor.h 
> b/xen/include/asm-arm/arm32/processor.h
> index f6d5df3..68cc821 100644
> --- a/xen/include/asm-arm/arm32/processor.h
> +++ b/xen/include/asm-arm/arm32/processor.h
> @@ -56,16 +56,6 @@ struct cpu_user_regs
>  uint32_t pad1; /* Doubleword-align the user half of the frame */
>  };
>  
> -/* Functions for pending virtual abort checking window. */
> -void abort_guest_exit_start(void);
> -void abort_guest_exit_end(void);
> -
> -#define VABORT_GEN_BY_GUEST(r)  \
> -( \
> -( (unsigned long)abort_guest_exit_start == (r)->pc ) || \
> -( (unsigned long)abort_guest_exit_end == (r)->pc ) \
> -)
> -
>  #endif
>  
>  /* Layout as used in assembly, with src/dest registers mixed in */
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 47e7026..700bde9 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -709,6 +709,16 @@ int call_smc(register_t function_id, register_t arg0, 
> register_t arg1,
>  
>  void do_trap_guest_error(struct cpu_user_regs *regs);
>  
> +/* Functions for pending virtual abort checking window. */
> +void abort_guest_exit_start(void);
> +void abort_guest_exit_end(void);
> +
> +#define VABORT_GEN_BY_GUEST(r)  \
> +( \
> +( (unsigned long)abort_guest_exit_start == (r)->pc ) || \
> +( (unsigned long)abort_guest_exit_end == (r)->pc ) \
> +)
> +
>  #endif /* __ASSEMBLY__ */
>  #endif /* __ASM_ARM_PROCESSOR_H */
>  /*
> -- 
> 2.7.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH v2 11/19] xen/arm32: Use alternative to skip the check of pending serrors

[Stefano Stabellini]

On Thu, 30 Mar 2017, Julien Grall wrote:
> Hi Wei,
> 
> On 30/03/17 10:13, Wei Chen wrote:
> > We have provided an option to administrator to determine how to
> > handle the SErrors. In order to skip the check of pending SError,
> > in conventional way, we have to read the option every time before
> > we try to check the pending SError. This will add overhead to check
> > the option at every trap.
> > 
> > The ARM32 supports the alternative patching feature. We can use an
> > ALTERNATIVE to avoid checking option at every trap. We added a new
> > cpufeature named "SKIP_CHECK_PENDING_VSERROR". This feature will be
> > enabled when the option is not diverse.
> > 
> > Signed-off-by: Wei Chen 
> 
> Reviewed-by: Julien Grall 
> 
> > ---
> 
> Stefano, this is requiring the alternative patch (see [1]) which is still in
> review.
> 
> Wei, a general rule is to mention the dependencies between series. So we don't
> apply by mistake in the wrong order.

Right. Thanks Wei for sending both the other patch and this series
together, that helps me avoiding mistakes.

But please add a note about the dependencies, just in case I forget.


> Cheers,
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg04132.html
> 
> >  xen/arch/arm/arm32/entry.S | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> > index 2187226..105cae8 100644
> > --- a/xen/arch/arm/arm32/entry.S
> > +++ b/xen/arch/arm/arm32/entry.S
> > @@ -1,5 +1,6 @@
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > 
> >  #define SAVE_ONE_BANKED(reg)mrs r11, reg; str r11, [sp, #UREGS_##reg]
> > @@ -44,6 +45,14 @@ save_guest_regs:
> >  SAVE_BANKED(fiq)
> >  SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq);
> > SAVE_ONE_BANKED(R10_fiq)
> >  SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
> > +
> > +/*
> > + * If the SKIP_CHECK_PENDING_VSERROR has been set in the cpu
> > feature,
> > + * the checking of pending SErrors will be skipped.
> > + */
> > +ALTERNATIVE("nop",
> > +"b skip_check",
> > +SKIP_CHECK_PENDING_VSERROR)
> >  /*
> >   * Start to check pending virtual abort in the gap of Guest -> HYP
> >   * world switch.
> > @@ -99,6 +108,7 @@ abort_guest_exit_end:
> >   */
> >  bne return_from_trap
> > 
> > +skip_check:
> >  mov pc, lr
> > 
> >  #define DEFINE_TRAP_ENTRY(trap) \
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH v2 09/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

[Stefano Stabellini]

On Thu, 30 Mar 2017, Julien Grall wrote:
> On 30/03/17 10:13, Wei Chen wrote:
> > In the later patches of this series, we want to use the alternative
> > patching framework to avoid checking serror_op in every entries.
> > So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
> > serror_op. When serror_op is not equal to SERROR_DIVERSE, this
> > feature will be set to cpu_hwcaps.
> > 
> > Currently, the default serror_op is SERROR_DIVERSE, if we want to
> > change the serror_op value we have to place the serror parameter
> > in command line. It seems no problem to update cpu_hwcaps directly
> > in the serror parameter parsing function.
> > 
> > But one day, if we change the default serror_op to SERROR_PANIC or
> > SERROR_FORWARD by some security policy. We may not place the serror
> > parameter in command line. In this case, if we rely on the serror
> > parameter parsing function to update cpu_hwcaps, this function would
> > not be invoked and the "SKIP_CHECK_PENDING_VSERROR" could not be
> > set in cpu_hwcaps.
> > 
> > So, we introduce this initcall to guarantee the cpu_hwcaps can be
> > updated no matter the serror parameter is placed in the command line
> > or not.
> > 
> > Signed-off-by: Wei Chen 
> > ---
> > v1->v2:
> > 1. Explain this initcall is to future-proof the code in commit
> >message.
> > 2. Fix a coding style of this initcall.
> > ---
> >  xen/arch/arm/traps.c | 9 +
> >  xen/include/asm-arm/cpufeature.h | 3 ++-
> >  2 files changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 955d97c..dafb730 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -120,6 +120,15 @@ static void __init parse_serrors_behavior(const char
> > *str)
> >  }
> >  custom_param("serrors", parse_serrors_behavior);
> > 
> > +static int __init update_serrors_cpu_caps(void)
> > +{
> > +if ( serrors_op != SERRORS_DIVERSE )
> > +cpus_set_cap(SKIP_CHECK_PENDING_VSERROR);
> 
> Thinking a bit more of this. I am wondering if we should add a warning (see
> warning_add) if the user is selecting an option other than diverse. Two
> reasons for that:
>   1) The user is fully aware that he is not classifying the SError at
> his own risks
>   2) If someone send an e-mail saying: "My guest crashed the hypervisor
> with an SError". We can directly know from the log.
> 
> Any opinions?

I would not do that: warnings are good to warn the user about something
unexpected or potentially unknown. In this case the user has to look up
the docs to find about the other options, where it's clearly written
what they are for. We have to expect taht they know what their are
doing.

For this patch:

Reviewed-by: Stefano Stabellini 

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

Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

[Stefano Stabellini]

On Thu, 30 Mar 2017, Julien Grall wrote:
> Hi Wei,
> 
> On 30/03/17 10:13, Wei Chen wrote:
> > When guest triggers async aborts, in most platform, such aborts
> > will be routed to hypervisor. But we don't want the hypervisor
> > to handle such aborts, so we have to route such aborts back to
> > the guest.
> > 
> > This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
> > route such aborts back to the guest. If the guest PC had been
> > advanced by SVC/HVC/SMC instructions before we caught the SError
> > in hypervisor, we have to adjust the guest PC to exact address
> > while the SError generated.
> > 
> > About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
> > we would like them to be handled here. This would be useful when
> > VM introspection will gain support of SVC32/64 trapping.
> > 
> > This helper will be used by the later patches in this series, we
> > use #if 0 to disable it in this patch temporarily to remove the
> > warning message of unused function from compiler.
> > 
> > Signed-off-by: Wei Chen 
> > Acked-by: Stefano Stabellini 
> > ---
> > v1->v2:
> > 1. After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
> >to HCR_EL2 immediately. In this case we don't need to move the
> >restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
> >regardless of whether we get preempted.
> 
> This should have been explained in the commit message and ...
> 
> > 2. Add Stefano's Acked-by.
> 
> I would not keep Acked-by/Reviewed-by with a change like above. Or at least, I
> would ask whether they are fine with this change.

That's true. Regardless, for this patch:

Reviewed-by: Stefano Stabellini 

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

Re: [Xen-devel] [PATCH v2 05/19] xen/arm: Avoid setting/clearing HCR_RW at every context switch

[Stefano Stabellini]

On Thu, 30 Mar 2017, Wei Chen wrote:
> The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
> when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
> DomU in vcpu_initialise, we didn't know the domain's address size
> information. We had to use compatible flags to initialize HCR_EL2,
> and set HCR_RW for 64-bit domain or clear HCR_RW for 32-bit domain
> at every context switch.
> 
> But, after we added the HCR_EL2 to vcpu's context, this behaviour
> seems a little fussy. We can update the HCR_RW bit in vcpu's context
> as soon as we get the domain's address size to avoid setting/clearing
> HCR_RW at every context switch.
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/arm64/domctl.c  | 6 ++
>  xen/arch/arm/domain.c| 5 +
>  xen/arch/arm/domain_build.c  | 7 +++
>  xen/arch/arm/p2m.c   | 5 -
>  xen/include/asm-arm/domain.h | 1 +
>  5 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> index 44e1e7b..ab8781f 100644
> --- a/xen/arch/arm/arm64/domctl.c
> +++ b/xen/arch/arm/arm64/domctl.c
> @@ -14,6 +14,8 @@
>  
>  static long switch_mode(struct domain *d, enum domain_type type)
>  {
> +struct vcpu *v;
> +
>  if ( d == NULL )
>  return -EINVAL;
>  if ( d->tot_pages != 0 )
> @@ -23,6 +25,10 @@ static long switch_mode(struct domain *d, enum domain_type 
> type)
>  
>  d->arch.type = type;
>  
> +if ( is_64bit_domain(d) )
> +for_each_vcpu(d, v)
> +vcpu_switch_to_aarch64_mode(v);
> +
>  return 0;
>  }
>  
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index c69e204..18b34e7 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -553,6 +553,11 @@ void vcpu_destroy(struct vcpu *v)
>  free_xenheap_pages(v->arch.stack, STACK_ORDER);
>  }
>  
> +void vcpu_switch_to_aarch64_mode(struct vcpu *v)
> +{
> +v->arch.hcr_el2 |= HCR_RW;
> +}
> +
>  int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> struct xen_arch_domainconfig *config)
>  {
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8af223e..14475a5 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2148,6 +2148,10 @@ int construct_dom0(struct domain *d)
>  return -EINVAL;
>  }
>  d->arch.type = kinfo.type;
> +
> +if ( is_64bit_domain(d) )
> +vcpu_switch_to_aarch64_mode(v);
> +
>  #endif
>  
>  allocate_memory(d, );
> @@ -2247,6 +2251,9 @@ int construct_dom0(struct domain *d)
>  printk("Failed to allocate dom0 vcpu %d on pcpu %d\n", i, cpu);
>  break;
>  }
> +
> +if ( is_64bit_domain(d) )
> +vcpu_switch_to_aarch64_mode(d->vcpu[i]);
>  }
>  
>  return 0;
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 83c4b7d..34d5776 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -137,11 +137,6 @@ void p2m_restore_state(struct vcpu *n)
>  WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
>  isb();
>  
> -if ( is_32bit_domain(n->domain) )
> -n->arch.hcr_el2 &= ~HCR_RW;
> -else
> -n->arch.hcr_el2 |= HCR_RW;
> -
>  WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
>  isb();
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 7b1dacc..68185e2 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -268,6 +268,7 @@ struct arch_vcpu
>  
>  void vcpu_show_execution_state(struct vcpu *);
>  void vcpu_show_registers(const struct vcpu *);
> +void vcpu_switch_to_aarch64_mode(struct vcpu *);
>  
>  unsigned int domain_max_vcpus(const struct domain *);
>  
> -- 
> 2.7.4
> 
> 
> ___
> 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

[Xen-devel] [PATCH v7 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini]

This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.

   Indexes page
   +--+
   |@0 $NAME_data_intf:   |
   |@76: ring_order = 1   |
   |@80: ref[0]+  |
   |@84: ref[1]+  |
   |   |  |
   |   |  |
   +--+
   |
   v (data ring)
   +---+---+
   |  @0->4095: in |
   |  ref[0]   |
   |---|
   |  @4096->8191: out |
   |  ref[1]   |
   +---+

$NAME_read_packet and $NAME_write_packet are provided to read or write
any data struct from/to the ring. In pvcalls, they are unused. In xen
9pfs, they are used to read or write the 9pfs header. In other protocols
they could be used to read/write the whole request structure. See
docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
is on the ring, and how to handle notifications.

There is a ring_size parameter to most functions so that protocols using
these macros don't have to have a statically defined ring order at build
time. In pvcalls for example, each new ring could have a different
order.

These macros don't help you share the indexes page or the event channels
needed for notifications. You can do that with other out of band
mechanisms, such as xenstore or another ring.

It is not possible to use a macro to define another macro with a
variable name. For this reason, this patch introduces static inline
functions instead, that are not C89 compliant. Additionally, the macro
defines a struct with a variable sized array, which is also not C89
compliant.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: jbeul...@suse.com
---
 xen/include/public/io/ring.h | 151 +++
 1 file changed, 151 insertions(+)

diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 801c0da..7b7794c 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -27,6 +27,21 @@
 #ifndef __XEN_PUBLIC_IO_RING_H__
 #define __XEN_PUBLIC_IO_RING_H__
 
+/*
+ * When #include'ing this header, you need to provide the following
+ * declaration upfront:
+ * - standard integers types (uint8_t, uint16_t, etc)
+ * They are provided by stdint.h of the standard headers.
+ *
+ * In addition, if you intend to use the FLEX macros, you also need to
+ * provide the following, before invoking the FLEX macros:
+ * - size_t
+ * - memcpy
+ * - grant_ref_t
+ * These declarations are provided by string.h of the standard headers,
+ * and grant_table.h from the Xen public headers.
+ */
+
 #include "../xen-compat.h"
 
 #if __XEN_INTERFACE_VERSION__ < 0x00030208
@@ -313,6 +328,142 @@ typedef struct __name##_back_ring __name##_back_ring_t
 (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);  \
 } while (0)
 
+
+/*
+ * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
+ * functions to check if there is data on the ring, and to read and
+ * write to them.
+ *
+ * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
+ * does not define the indexes page. As different protocols can have
+ * extensions to the basic format, this macro allow them to define their
+ * own struct.
+ *
+ * XEN_FLEX_RING_SIZE
+ *   Convenience macro to calculate the size of one of the two rings
+ *   from the overall order.
+ *
+ * $NAME_mask
+ *   Function to apply the size mask to an index, to reduce the index
+ *   within the range [0-size].
+ *
+ * $NAME_read_packet
+ *   Function to read data from the ring. The amount of data to read is
+ *   specified by the "size" argument.
+ *
+ * $NAME_write_packet
+ *   Function to write data to the ring. The amount of data to write is
+ *   specified by the "size" argument.
+ *
+ * $NAME_get_ring_ptr
+ *   Convenience function that returns a pointer to read/write to the
+ *   ring at the right location.
+ *
+ * $NAME_data_intf
+ *   Indexes page, shared between frontend and backend. It also
+ *   contains the array of grant refs.
+ *
+ * $NAME_queued
+ *   Function to calculate how many bytes are currently on the ring,
+ *   ready to be read. It can also be used to calculate how much free
+ *   space is currently on the ring (ring_size - $NAME_queued()).
+ */
+
+#define XEN_PAGE_SHIFT 12
+#define XEN_FLEX_RING_SIZE(order) \
+(1UL << ((order) + XEN_PAGE_SHIFT - 1))
+
+#define DEFINE_XEN_FLEX_RING(name)\
+static inline RING_IDX 

[Xen-devel] [PATCH v7 2/4] xen: introduce a C99 headers check

[Stefano Stabellini]

Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h
and pvcalls.h.

In addition to the usual -include stdint.h, also add -include string.h
to the C99 check to get the declaration of memcpy and size_t.

For the same reason, also add -include cstring to the C++ check when
necessary.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
 .gitignore   |  1 +
 xen/include/Makefile | 30 ++
 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/.gitignore b/.gitignore
index 443b12a..a8905b1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -274,6 +274,7 @@ xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
 xen/arch/*/efi/runtime.c
 xen/include/headers.chk
+xen/include/headers99.chk
 xen/include/headers++.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
diff --git a/xen/include/Makefile b/xen/include/Makefile
index aca7f20..64fecbd 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -90,11 +90,12 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) Makefile
 
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
-all: headers.chk headers++.chk
+all: headers.chk headers99.chk headers++.chk
 
 PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
public/*.h public/*/*.h) $(public-y))
 
-PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h, $(PUBLIC_HEADERS))
+PUBLIC_C99_HEADERS :=
+PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
 
 headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
for i in $(filter %.h,$^); do \
@@ -104,16 +105,21 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
done >$@.new
mv $@.new $@
 
+headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
+   rm -f $@.new
+   $(foreach i, $(filter %.h,$^), $(CC) -x c -std=c99 -Wall -Werror\
+   -include stdint.h $(foreach j, $($(i)-prereq), -include $(j).h) \
+   -S -o /dev/null $(i) || exit 1; echo $(i) >> $@.new;)
+   mv $@.new $@
+
 headers++.chk: $(PUBLIC_HEADERS) Makefile
-   if $(CXX) -v >/dev/null 2>&1; then \
-   for i in $(filter %.h,$^); do \
-   echo '#include "'$$i'"' \
-   | $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__ \
- -include stdint.h -include public/xen.h -S -o /dev/null - \
-   || exit 1; \
-   echo $$i; \
-   done ; \
-   fi >$@.new
+   rm -f $@.new
+   $(CXX) -v >/dev/null 2>&1 || exit 0
+   $(foreach i, $(filter %.h,$^), echo "#include "\"$(i)\"|   \
+   $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__   \
+   -include stdint.h -include public/xen.h\
+   $(foreach j, $($(i)-prereq), -include c$(j))   \
+   -S -o /dev/null - || exit 1; echo $(i) >> $@.new;)
mv $@.new $@
 
 endif
@@ -128,5 +134,5 @@ all: $(BASEDIR)/include/asm-x86/cpuid-autogen.h
 endif
 
 clean::
-   rm -rf compat headers.chk headers++.chk
+   rm -rf compat headers*.chk
rm -f $(BASEDIR)/include/asm-x86/cpuid-autogen.h
-- 
1.9.1


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

[Xen-devel] [PATCH v7 4/4] Introduce the pvcalls header

[Stefano Stabellini]

Define the ring and request and response structs according to the
specification. Use the new DEFINE_XEN_FLEX_RING macro.

Add the header to the C99 check.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
 xen/include/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 2e82b73..f011c1d 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -94,10 +94,11 @@ all: headers.chk headers99.chk headers++.chk
 
 PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
public/*.h public/*/*.h) $(public-y))
 
-PUBLIC_C99_HEADERS := public/io/9pfs.h
+PUBLIC_C99_HEADERS := public/io/9pfs.h public/io/pvcalls.h
 PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
 
 public/io/9pfs.h-prereq := string
+public/io/pvcalls.h-prereq := string
 
 headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
for i in $(filter %.h,$^); do \
-- 
1.9.1


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

[Xen-devel] [PATCH v7 3/4] Introduce the Xen 9pfs transport header

[Stefano Stabellini]

Define the ring according to the protocol specification, using the new
DEFINE_XEN_FLEX_RING_AND_INTF macro.

Add the header to the C99 check.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
---
 xen/include/Makefile |  4 +++-
 xen/include/public/io/9pfs.h | 49 
 2 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/public/io/9pfs.h

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 64fecbd..2e82b73 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -94,9 +94,11 @@ all: headers.chk headers99.chk headers++.chk
 
 PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
public/*.h public/*/*.h) $(public-y))
 
-PUBLIC_C99_HEADERS :=
+PUBLIC_C99_HEADERS := public/io/9pfs.h
 PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
 
+public/io/9pfs.h-prereq := string
+
 headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
for i in $(filter %.h,$^); do \
$(CC) -x c -ansi -Wall -Werror -include stdint.h \
diff --git a/xen/include/public/io/9pfs.h b/xen/include/public/io/9pfs.h
new file mode 100644
index 000..4bfd5d4
--- /dev/null
+++ b/xen/include/public/io/9pfs.h
@@ -0,0 +1,49 @@
+/*
+ * 9pfs.h -- Xen 9PFS transport
+ *
+ * Refer to docs/misc/9pfs.markdown for the specification
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_9PFS_H__
+#define __XEN_PUBLIC_IO_9PFS_H__
+
+#include "../grant_table.h"
+#include "ring.h"
+
+/*
+ * See docs/misc/9pfs.markdown in xen.git for the full specification:
+ * https://xenbits.xen.org/docs/unstable/misc/9pfs.html
+ */
+DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


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

[Xen-devel] [PATCH v7 0/4] new ring macros, 9pfs and pvcalls headers

[Stefano Stabellini]

Hi all,

this patch series introduces a set of new ring macros to support rings
in the formats specified by the Xen 9pfs transport and PV Calls
protocol. It also introduces the Xen 9pfs and PV Calls protocols
headers.

Changes in v7:
- code style
- remove -include from prereq variable
- use only one prereq variable for both cxx and c99

Changes in v6:
- remove stray semicolons
- code style fix for return statements
- make the last element of DEFINE_XEN_FLEX_RING non a static inline
  function
- improve ring.h prereq comment
- remove mask_order
- use ring_size as parameter instead of ring_order
- fix indentation of parameters in ring.h
- improve order of parameters in ring.h
- introduce per header prereqs in xen/include/Makefile

Changes in v5:
- parenthesize uses of macro parameters in XEN_FLEX_RING_SIZE
- add grant_table.h to the list of prereqs in ring.h and remove the
  #include from ring.h
- #include grant_table.h in 9pfs.h and pvcalls.h
- remove PAGE_SHIFT definition, define XEN_PAGE_SHIFT instead
- code style fixes
- remove struct xen_9pfs_header definition
- don't add extra -include cstring to all c++ tests, only when needed
- add headers99.chk to .gitignore 

Changes in v4:
- include ../grant_table.h in ring.h
- add a comment about required declarations on top of ring.h
- add a patch to introduce a C99 headers check
- add -include string.h to the existing C++ headers check
- add 9pfs and pvcalls to the C99 headers check

Changes in v3:
- fix commit message
- add newlines after read/write_packet functions
- reorder DEFINE_XEN_FLEX_RING_AND_INTF and DEFINE_XEN_FLEX_RING

Changes in v2:
- replace __attribute__((packed)) with #pragma pack
- remove XEN_9PFS_RING_ORDER, the 9pfs ring order should be dynamic
- add editor configuration blocks
- add links to the specs


Stefano Stabellini (4):
  ring.h: introduce macros to handle monodirectional rings with multiple 
req sizes
  xen: introduce a C99 headers check
  Introduce the Xen 9pfs transport header
  Introduce the pvcalls header

 .gitignore   |   1 +
 xen/include/Makefile |  33 ++
 xen/include/public/io/9pfs.h |  49 ++
 xen/include/public/io/ring.h | 151 +++
 4 files changed, 222 insertions(+), 12 deletions(-)
 create mode 100644 xen/include/public/io/9pfs.h

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v6 3/4] Introduce the Xen 9pfs transport header

[Stefano Stabellini]

On Thu, 30 Mar 2017, Jan Beulich wrote:
> >>> On 30.03.17 at 00:18,  wrote:
> > --- a/xen/include/Makefile
> > +++ b/xen/include/Makefile
> > @@ -94,9 +94,12 @@ all: headers.chk headers99.chk headers++.chk
> >  
> >  PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
> > public/*.h public/*/*.h) $(public-y))
> >  
> > -PUBLIC_C99_HEADERS :=
> > +PUBLIC_C99_HEADERS := public/io/9pfs.h
> >  PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
> > public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
> >  
> > +public/io/9pfs.h-c99-prereq := -include string.h
> > +public/io/9pfs.h-cxx-prereq := -include cstring
> 
> For the moment (where we only have consistent prereqs) I wonder
> whether we couldn't simplify this to
> 
> public/io/9pfs.h-prereqs := string
> 
> with the C++ use site then becoming
> $(addprefix -include c,$($(i)-prereqs)) (C99 similar). In any event
> I'd like to see the -include go away from the macros here - they
> should at most list header names.

All right, but given that in the c99 case we need to add both a prefix
(-include) and a suffix (.h), I'll use foreach instead of addprefix.

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

Re: [Xen-devel] [PATCH v6 2/4] xen: introduce a C99 headers check

[Stefano Stabellini]

On Thu, 30 Mar 2017, Jan Beulich wrote:
> >>> On 30.03.17 at 00:18,  wrote:
> > @@ -104,16 +105,22 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> > done >$@.new
> > mv $@.new $@
> >  
> > +headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
> > +   rm -f $@.new $@
> 
> Why also $@?
> 
> > +   $(foreach i, $(filter %.h,$^), $(CC) -x c -std=c99 -Wall -Werror \
> > +   -include stdint.h $($(i)-c99-prereq) -S -o /dev/null $(i) || \
> > +   exit 1; echo $(i) >> $@.new;)
> > +   mv $@.new $@
> > +
> >  headers++.chk: $(PUBLIC_HEADERS) Makefile
> > -   if $(CXX) -v >/dev/null 2>&1; then \
> > -   for i in $(filter %.h,$^); do \
> > -   echo '#include "'$$i'"' \
> > -   | $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__ \
> > - -include stdint.h -include public/xen.h -S -o /dev/null - \
> > -   || exit 1; \
> > -   echo $$i; \
> > -   done ; \
> > -   fi >$@.new
> > +   if ! $(CXX) -v >/dev/null 2>&1; then \
> > +   exit 0;  \
> > +   fi
> 
> How about
> 
>   $(CXX) -v >/dev/null 2>&1 || exit 0
> 
> avoiding the line continuations?
> 
> You can't, however, separate this from the rest (or else the
> following commands will be executed anyway).
> 
> > +   rm -f $@.new $@
> 
> This will then want moving ahead (without the $@).
> 
> > +   $(foreach i, $(filter %.h,$^), echo "#include "\"$(i)\"|   \
> > +   $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__   \
> > +   -include stdint.h $($(i)-cxx-prereq) -include public/xen.h \
> 
> I think the prereq(s) should come after public/xen.h (the presence
> of which I question anyway, as all headers should include it if there
> is a dependency).

I'll address all comments

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

Re: [Xen-devel] [PATCH v6 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini]

On Thu, 30 Mar 2017, Jan Beulich wrote:
> >>> On 30.03.17 at 00:18,  wrote:
> > +static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size)   
> >\
> > +{  
> >\
> > +return (idx & (ring_size - 1));
> >\
> > +}  
> >\
> > +   
> >\
> > +static inline unsigned char *name##_get_ring_ptr(unsigned char *buf,   
> >\
> > + RING_IDX idx, 
> >\
> > + RING_IDX ring_size)   
> >\
> > +{  
> >\
> > +return buf + name##_mask(idx, ring_size);  
> >\
> > +}  
> >\
> 
> Inconsistent parenthesization of the operands of return has
> not been taken care of.
> 
> > +struct name##_data {   
> >\
> > +unsigned char *in; /* half of the allocation */
> >\
> > +unsigned char *out; /* half of the allocation */   
> >\
> > +}; 
> >\
> > +
> 
> There's now not only a trailing semicolon here, but also a stray
> backslash.

I'll fix all issues

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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Artem Mygaiev]

Lets make it clear - there must be one translation table for EL0 apps...

On Mar 30, 2017 23:18, Volodymyr Babchuk  wrote:
Hi Julien,



On 30 March 2017 at 22:57, Julien Grall  wrote:
> Hi Volodymyr
>
> On 30/03/2017 20:19, Volodymyr Babchuk wrote:
>>
>> On 30 March 2017 at 21:52, Stefano Stabellini 
>> wrote:
>>>
>>> On Thu, 30 Mar 2017, Volodymyr Babchuk wrote:
>>
>> And yes, my profiler shows that there are ways to further decrease
>> latency. Most obvious way is to get rid of 2nd stage translation and
>> thus eliminate p2m code from the call chain. Currently hypervisor
>> spends 20% of time in spinlocks code and about ~10-15% in p2m. So
>> there definitely are areas to improve :)
>
>
> Correct me if I am wrong. You are suggesting to remove stage-2 MMU
> translation, right? If so, what are the benefits to have some Xen code
> running at EL0?
Because that will be loadable code :) Also, this will provide some
degree of isolation as this code will communicate with Xen only via
SVCs.

Look, we need two stages in the first place because conventional guest
wants to control own MMU. But Xen native app (lets call it in this
way) should not control MMU. In my hack I had to create stage-1 table
with 1:1 mapping to make things work. Actually it just came to me
that I can try to disable stage 1 MMU and leave only stage 2. Not sure
if it is possible, need to check TRM...
But, anyways, my initial idea was to disable second stage MMU (drop VM
bit in HCR_EL2) and program only TTBR0_EL1 with friends. With this
approach there will be no need to save/restore p2m context when I
switch from guest context to app context and back.

--
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Volodymyr Babchuk]

Hi Julien,



On 30 March 2017 at 22:57, Julien Grall  wrote:
> Hi Volodymyr
>
> On 30/03/2017 20:19, Volodymyr Babchuk wrote:
>>
>> On 30 March 2017 at 21:52, Stefano Stabellini 
>> wrote:
>>>
>>> On Thu, 30 Mar 2017, Volodymyr Babchuk wrote:
>>
>> And yes, my profiler shows that there are ways to further decrease
>> latency. Most obvious way is to get rid of 2nd stage translation and
>> thus eliminate p2m code from the call chain. Currently hypervisor
>> spends 20% of time in spinlocks code and about ~10-15% in p2m. So
>> there definitely are areas to improve :)
>
>
> Correct me if I am wrong. You are suggesting to remove stage-2 MMU
> translation, right? If so, what are the benefits to have some Xen code
> running at EL0?
Because that will be loadable code :) Also, this will provide some
degree of isolation as this code will communicate with Xen only via
SVCs.

Look, we need two stages in the first place because conventional guest
wants to control own MMU. But Xen native app (lets call it in this
way) should not control MMU. In my hack I had to create stage-1 table
with 1:1 mapping to make things work. Actually it just came to me
that I can try to disable stage 1 MMU and leave only stage 2. Not sure
if it is possible, need to check TRM...
But, anyways, my initial idea was to disable second stage MMU (drop VM
bit in HCR_EL2) and program only TTBR0_EL1 with friends. With this
approach there will be no need to save/restore p2m context when I
switch from guest context to app context and back.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Julien Grall]

Hi Volodymyr

On 30/03/2017 20:19, Volodymyr Babchuk wrote:

On 30 March 2017 at 21:52, Stefano Stabellini  wrote:

On Thu, 30 Mar 2017, Volodymyr Babchuk wrote:

And yes, my profiler shows that there are ways to further decrease
latency. Most obvious way is to get rid of 2nd stage translation and
thus eliminate p2m code from the call chain. Currently hypervisor
spends 20% of time in spinlocks code and about ~10-15% in p2m. So
there definitely are areas to improve :)


Correct me if I am wrong. You are suggesting to remove stage-2 MMU 
translation, right? If so, what are the benefits to have some Xen code 
running at EL0?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Julien Grall]

Hi Volodymyr

On 30/03/2017 20:19, Volodymyr Babchuk wrote:

On 30 March 2017 at 21:52, Stefano Stabellini  wrote:

On Thu, 30 Mar 2017, Volodymyr Babchuk wrote:

And yes, my profiler shows that there are ways to further decrease
latency. Most obvious way is to get rid of 2nd stage translation and
thus eliminate p2m code from the call chain. Currently hypervisor
spends 20% of time in spinlocks code and about ~10-15% in p2m. So
there definitely are areas to improve :)


Correct me if I am wrong. You are suggesting to remove stage-2 MMU 
translation, right? If so, what are the benefits to have some Xen code 
running at EL0?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

[Julien Grall]

Hi Stefano,

On 30/03/2017 19:55, Stefano Stabellini wrote:

On Thu, 30 Mar 2017, Julien Grall wrote:

Hi Stefano,

On 30/03/17 19:37, Stefano Stabellini wrote:

On Thu, 30 Mar 2017, Julien Grall wrote:

+/*
+ * When using ACPI, most of the MMIO regions will be mapped on-demand
+ * in stage-2 page tables for the hardware domain because Xen is not
+ * able to know from the EFI memory map the MMIO regions.
+ */
+static bool try_map_mmio(gfn_t gfn)
+{
+struct domain *d = current->domain;
+
+/* For the hardware domain, all MMIOs are mapped with GFN == MFN */
+mfn_t mfn = _mfn(gfn_x(gfn));
+
+/*
+ * Device-Tree should already have everything mapped when building
+ * the hardware domain.
+ */
+if ( acpi_disabled )
+return false;
+
+if ( d != hardware_domain )


is_hardware_domain(d)


Will fix it.




+return false;
+
+/* The hardware domain can only map permitted MMIO regions */
+if ( !iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + 1) )
+return false;


Because of the potential of causing problems with DMA to device MMIO,
I would add a warning here, something like:

   dprintk(XENLOG_WARNING, "Mapping gfn=mfn=%"PRI_gfn" to Dom%d\n",
d->domain_id);

I hope that it will help us debug issues when/if we'll actually
encounter such a case.


I don't think this will help us and it will flood the console in debug-build
(there are a lot of MMIO to map).

When SMMUs are not used, DMA to device MMIO will work regardless the mapping
in stage-2.

When SMMUs are in use, you will get a SMMU fault that tells you the address
used. With that you could know the region was not mapped.


Fair enough. Do you think there is any value in adding only one debug
warning, to say that we are mapping MMIOs on trap on this platform? But
today, it would basically be the same as saying "ACPI is enabled".


I think we clearly need some documentation in tree to explain the design 
of Xen with ACPI and Device Tree. But this is lacking so far :/.


I can have a go when I find some times.

Cheers,

--
Julien Grall

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

[Xen-devel] [RFC PATCH v3 1/2] xen: credit2: enable per cpu runqueue creation

[Praveen Kumar]

The patch introduces a new command line option 'cpu' that when used will
create runqueue per logical pCPU.

Signed-off-by: Praveen Kumar 
---
 docs/misc/xen-command-line.markdown |  3 ++-
 xen/common/sched_credit2.c  | 15 +++
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 9eb85d68b5..c245cfa471 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -525,7 +525,7 @@ also slow in responding to load changes.
 The default value of `1 sec` is rather long.
 
 ### credit2\_runqueue
-> `= core | socket | node | all`
+> `= cpu | core | socket | node | all`
 
 > Default: `socket`
 
@@ -536,6 +536,7 @@ balancing (for instance, it will deal better with 
hyperthreading),
 but also more overhead.
 
 Available alternatives, with their meaning, are:
+* `cpu`: one runqueue per each logical pCPUs of the host;
 * `core`: one runqueue per each physical core of the host;
 * `socket`: one runqueue per each physical socket (which often,
 but not always, matches a NUMA node) of the host;
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index bb1c657e76..ee7b443f9e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -301,6 +301,9 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  * want that to happen basing on topology. At the moment, it is possible
  * to choose to arrange runqueues to be:
  *
+ * - per-cpu: meaning that there will be one runqueue per logical cpu. This
+ *will happen when if the opt_runqueue parameter is set to 'cpu'.
+ *
  * - per-core: meaning that there will be one runqueue per each physical
  * core of the host. This will happen if the opt_runqueue
  * parameter is set to 'core';
@@ -322,11 +325,13 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  * either the same physical core, the same physical socket, the same NUMA
  * node, or just all of them, will be put together to form runqueues.
  */
-#define OPT_RUNQUEUE_CORE   0
-#define OPT_RUNQUEUE_SOCKET 1
-#define OPT_RUNQUEUE_NODE   2
-#define OPT_RUNQUEUE_ALL3
+#define OPT_RUNQUEUE_CPU0
+#define OPT_RUNQUEUE_CORE   1
+#define OPT_RUNQUEUE_SOCKET 2
+#define OPT_RUNQUEUE_NODE   3
+#define OPT_RUNQUEUE_ALL4
 static const char *const opt_runqueue_str[] = {
+[OPT_RUNQUEUE_CPU] = "cpu",
 [OPT_RUNQUEUE_CORE] = "core",
 [OPT_RUNQUEUE_SOCKET] = "socket",
 [OPT_RUNQUEUE_NODE] = "node",
@@ -682,6 +687,8 @@ cpu_to_runqueue(struct csched2_private *prv, unsigned int 
cpu)
 BUG_ON(cpu_to_socket(cpu) == XEN_INVALID_SOCKET_ID ||
cpu_to_socket(peer_cpu) == XEN_INVALID_SOCKET_ID);
 
+if (opt_runqueue == OPT_RUNQUEUE_CPU)
+continue;
 if ( opt_runqueue == OPT_RUNQUEUE_ALL ||
  (opt_runqueue == OPT_RUNQUEUE_CORE && same_core(peer_cpu, cpu)) ||
  (opt_runqueue == OPT_RUNQUEUE_SOCKET && same_socket(peer_cpu, 
cpu)) ||
-- 
2.12.0


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

[Xen-devel] [RFC PATCH v3 2/2] xen: credit2: provide custom option to create

[Praveen Kumar]

The patch introduces a new command line option 'custom' that when used will
create runqueue based upon the pCPU subset provide during bootup.

Signed-off-by: Praveen Kumar 
---
 docs/misc/xen-command-line.markdown |   8 +-
 xen/common/sched_credit2.c  | 170 +++-
 2 files changed, 176 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index c245cfa471..e65056b3d0 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -525,7 +525,7 @@ also slow in responding to load changes.
 The default value of `1 sec` is rather long.
 
 ### credit2\_runqueue
-> `= cpu | core | socket | node | all`
+> `= cpu | core | socket | node | all | custom`
 
 > Default: `socket`
 
@@ -543,6 +543,12 @@ Available alternatives, with their meaning, are:
 * `node`: one runqueue per each NUMA node of the host;
 * `all`: just one runqueue shared by all the logical pCPUs of
  the host
+* `custom`: one runqueue per subset. Example:
+credit2_runqueue=[[0,1,4,5][2,3,6,7][8,9,12,13][10,11,14,15]]
+- pCPUs 0, 1, 4 and 5 belong to runqueue 0
+- pCPUs 2, 3, 6 and 7 belong to runqueue 1
+- pCPUs 8, 9, 12 and 13 belong to runqueue 2
+- pCPUs 10, 11, 14 and 15 belong to runqueue 3
 
 ### dbgp
 > `= ehci[  | @pci:. ]`
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index ee7b443f9e..9234b023cb 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -321,6 +321,15 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  *   (logical) processors of the host belong. This will happen if
  *   the opt_runqueue parameter is set to 'all'.
  *
+ * - custom: meaning that there will be one runqueue per subset being passed as
+ *   parameter to credit2_runqueue as shown in below example.
+ *   Example:
+ *   credit2_runqueue=[[cpu0,cpu1][cpu3][cpu4,cpu5]]
+ *   The example mentioned states :
+ *   cpu0 and cpu1 belongs to runqueue 0
+ *   cpu3 belongs to runqueue 1
+ *   cpu4 and cpu5 belongs to runqueue 2
+ *
  * Depending on the value of opt_runqueue, therefore, cpus that are part of
  * either the same physical core, the same physical socket, the same NUMA
  * node, or just all of them, will be put together to form runqueues.
@@ -330,18 +339,60 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
 #define OPT_RUNQUEUE_SOCKET 2
 #define OPT_RUNQUEUE_NODE   3
 #define OPT_RUNQUEUE_ALL4
+#define OPT_RUNQUEUE_CUSTOM 5
 static const char *const opt_runqueue_str[] = {
 [OPT_RUNQUEUE_CPU] = "cpu",
 [OPT_RUNQUEUE_CORE] = "core",
 [OPT_RUNQUEUE_SOCKET] = "socket",
 [OPT_RUNQUEUE_NODE] = "node",
-[OPT_RUNQUEUE_ALL] = "all"
+[OPT_RUNQUEUE_ALL] = "all",
+[OPT_RUNQUEUE_CUSTOM] = "custom"
 };
 static int __read_mostly opt_runqueue = OPT_RUNQUEUE_SOCKET;
 
+static int __read_mostly custom_cpu_runqueue[NR_CPUS];
+
+#define GETTOKEN( token, len, start, end )   \
+{\
+char _tmp[len+1];\
+int _i;  \
+safe_strcpy(_tmp, start);\
+_tmp[len] = '\0';\
+for ( _i = 0; _tmp[_i] != '\0'; _i++ )   \
+token = ( ( token * 10 ) + ( _tmp[_i] - '0' ) ); \
+}
+
+static inline int trim(const char *c, char *t, char elem)
+{
+int l = strlen(c);
+const char *x = c ;
+int i = 0;
+if ( !c || !t )
+return -1;
+while ( *x != '\0' && i < l )
+{
+if ( *x != elem )
+t[i++] = *x;
+x++;
+}
+t[i] = '\0';
+return 0;
+}
+
+static inline int getlen(char *start, char *end)
+{
+if ( ( start ) && ( end ) && ( end > start ) )
+return end-start;
+else
+return -1;
+}
+
 static void parse_credit2_runqueue(const char *s)
 {
 unsigned int i;
+const char *s_end = NULL;
+char m[strlen(s)];
+char *_s = NULL;
 
 for ( i = 0; i < ARRAY_SIZE(opt_runqueue_str); i++ )
 {
@@ -351,7 +402,115 @@ static void parse_credit2_runqueue(const char *s)
 return;
 }
 }
+/*
+ * At this stage we are either unknown value of credit2_runqueue or we can
+ * consider it to be custom cpu. Lets try parsing the same.
+ * Resetting the custom_cpu_runqueue for future use. Only the non-negative
+ * entries will be valid. The index 'i' in custom_cpu_runqueue will store
+ * the specific runqueue it belongs to.
+ * Example:
+ * If custom_cpu_runqueue[3] == 2
+ * Then, it means that cpu 3 belong to runqueue 2.
+ * If custom_cpu_runqueue[4] == -1
+ * Then, it means 

[Xen-devel] [RFC PATCH v3 0/2] xen: credit2: flexible configuration for runqueues

[Praveen Kumar]

Hello,

The idea is to give user more flexibility to configure runqueue further.
For most workloads and in most systems, using per-core means have too many
small runqueues. Using per-socket is almost always better, but it may result
in too few big runqueues.

OPTION 1 :

The user can create runqueue per-cpu using Xen boot parameter like below:

 credit2_runqueue=cpu

which would mean the following:
 - pCPU 0 belong to runqueue 0
 - pCPU 1 belong to runqueue 1
 - pCPU 2 belong to runqueue 2
 and so on.

OPTION 2 :

Further user can be allowed to say something shown below :

 credit2_runqueue=0,1,4,5;2,3,6,7;8,9,12,13;10,11,14,15

or (with exactly the same meaning, but a perhaps more clear syntax):

 credit2_runqueue=[[0,1,4,5][2,3,6,7][8,9,12,13][10,11,14,15]]

which would mean the following:
 - pCPUs 0, 1, 4 and 5 belong to runqueue 0
 - pCPUs 2, 3, 6 and 7 belong to runqueue 1
 - pCPUs 8, 9, 12 and 13 belong to runqueue 2
 - pCPUs 10, 11, 14 and 15 belong to runqueue 3

Thanks and Regards,
Praveen Kumar.
---
v3 has proper subject for RFC
---
Praveen Kumar (2):
  xen: credit2: enable per cpu runqueue creation
  xen: credit2: provide flexible option to create runqueue

 docs/misc/xen-command-line.markdown |   9 +-
 xen/common/sched_credit2.c  | 185 +++-
 2 files changed, 188 insertions(+), 6 deletions(-)

-- 
2.12.0


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

[Xen-devel] [PATCH v2 2/2] xen: credit2: provide custom option to create

[Praveen Kumar]

The patch introduces a new command line option 'custom' that when used will
create runqueue based upon the pCPU subset provide during bootup.

Signed-off-by: Praveen Kumar 
---
 docs/misc/xen-command-line.markdown |   8 +-
 xen/common/sched_credit2.c  | 170 +++-
 2 files changed, 176 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index c245cfa471..e65056b3d0 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -525,7 +525,7 @@ also slow in responding to load changes.
 The default value of `1 sec` is rather long.
 
 ### credit2\_runqueue
-> `= cpu | core | socket | node | all`
+> `= cpu | core | socket | node | all | custom`
 
 > Default: `socket`
 
@@ -543,6 +543,12 @@ Available alternatives, with their meaning, are:
 * `node`: one runqueue per each NUMA node of the host;
 * `all`: just one runqueue shared by all the logical pCPUs of
  the host
+* `custom`: one runqueue per subset. Example:
+credit2_runqueue=[[0,1,4,5][2,3,6,7][8,9,12,13][10,11,14,15]]
+- pCPUs 0, 1, 4 and 5 belong to runqueue 0
+- pCPUs 2, 3, 6 and 7 belong to runqueue 1
+- pCPUs 8, 9, 12 and 13 belong to runqueue 2
+- pCPUs 10, 11, 14 and 15 belong to runqueue 3
 
 ### dbgp
 > `= ehci[  | @pci:. ]`
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index ee7b443f9e..9234b023cb 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -321,6 +321,15 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  *   (logical) processors of the host belong. This will happen if
  *   the opt_runqueue parameter is set to 'all'.
  *
+ * - custom: meaning that there will be one runqueue per subset being passed as
+ *   parameter to credit2_runqueue as shown in below example.
+ *   Example:
+ *   credit2_runqueue=[[cpu0,cpu1][cpu3][cpu4,cpu5]]
+ *   The example mentioned states :
+ *   cpu0 and cpu1 belongs to runqueue 0
+ *   cpu3 belongs to runqueue 1
+ *   cpu4 and cpu5 belongs to runqueue 2
+ *
  * Depending on the value of opt_runqueue, therefore, cpus that are part of
  * either the same physical core, the same physical socket, the same NUMA
  * node, or just all of them, will be put together to form runqueues.
@@ -330,18 +339,60 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
 #define OPT_RUNQUEUE_SOCKET 2
 #define OPT_RUNQUEUE_NODE   3
 #define OPT_RUNQUEUE_ALL4
+#define OPT_RUNQUEUE_CUSTOM 5
 static const char *const opt_runqueue_str[] = {
 [OPT_RUNQUEUE_CPU] = "cpu",
 [OPT_RUNQUEUE_CORE] = "core",
 [OPT_RUNQUEUE_SOCKET] = "socket",
 [OPT_RUNQUEUE_NODE] = "node",
-[OPT_RUNQUEUE_ALL] = "all"
+[OPT_RUNQUEUE_ALL] = "all",
+[OPT_RUNQUEUE_CUSTOM] = "custom"
 };
 static int __read_mostly opt_runqueue = OPT_RUNQUEUE_SOCKET;
 
+static int __read_mostly custom_cpu_runqueue[NR_CPUS];
+
+#define GETTOKEN( token, len, start, end )   \
+{\
+char _tmp[len+1];\
+int _i;  \
+safe_strcpy(_tmp, start);\
+_tmp[len] = '\0';\
+for ( _i = 0; _tmp[_i] != '\0'; _i++ )   \
+token = ( ( token * 10 ) + ( _tmp[_i] - '0' ) ); \
+}
+
+static inline int trim(const char *c, char *t, char elem)
+{
+int l = strlen(c);
+const char *x = c ;
+int i = 0;
+if ( !c || !t )
+return -1;
+while ( *x != '\0' && i < l )
+{
+if ( *x != elem )
+t[i++] = *x;
+x++;
+}
+t[i] = '\0';
+return 0;
+}
+
+static inline int getlen(char *start, char *end)
+{
+if ( ( start ) && ( end ) && ( end > start ) )
+return end-start;
+else
+return -1;
+}
+
 static void parse_credit2_runqueue(const char *s)
 {
 unsigned int i;
+const char *s_end = NULL;
+char m[strlen(s)];
+char *_s = NULL;
 
 for ( i = 0; i < ARRAY_SIZE(opt_runqueue_str); i++ )
 {
@@ -351,7 +402,115 @@ static void parse_credit2_runqueue(const char *s)
 return;
 }
 }
+/*
+ * At this stage we are either unknown value of credit2_runqueue or we can
+ * consider it to be custom cpu. Lets try parsing the same.
+ * Resetting the custom_cpu_runqueue for future use. Only the non-negative
+ * entries will be valid. The index 'i' in custom_cpu_runqueue will store
+ * the specific runqueue it belongs to.
+ * Example:
+ * If custom_cpu_runqueue[3] == 2
+ * Then, it means that cpu 3 belong to runqueue 2.
+ * If custom_cpu_runqueue[4] == -1
+ * Then, it means 

[Xen-devel] [PATCH v2 1/2] xen: credit2: enable per cpu runqueue creation

[Praveen Kumar]

The patch introduces a new command line option 'cpu' that when used will
create runqueue per logical pCPU.

Signed-off-by: Praveen Kumar 
---
 docs/misc/xen-command-line.markdown |  3 ++-
 xen/common/sched_credit2.c  | 15 +++
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 9eb85d68b5..c245cfa471 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -525,7 +525,7 @@ also slow in responding to load changes.
 The default value of `1 sec` is rather long.
 
 ### credit2\_runqueue
-> `= core | socket | node | all`
+> `= cpu | core | socket | node | all`
 
 > Default: `socket`
 
@@ -536,6 +536,7 @@ balancing (for instance, it will deal better with 
hyperthreading),
 but also more overhead.
 
 Available alternatives, with their meaning, are:
+* `cpu`: one runqueue per each logical pCPUs of the host;
 * `core`: one runqueue per each physical core of the host;
 * `socket`: one runqueue per each physical socket (which often,
 but not always, matches a NUMA node) of the host;
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index bb1c657e76..ee7b443f9e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -301,6 +301,9 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  * want that to happen basing on topology. At the moment, it is possible
  * to choose to arrange runqueues to be:
  *
+ * - per-cpu: meaning that there will be one runqueue per logical cpu. This
+ *will happen when if the opt_runqueue parameter is set to 'cpu'.
+ *
  * - per-core: meaning that there will be one runqueue per each physical
  * core of the host. This will happen if the opt_runqueue
  * parameter is set to 'core';
@@ -322,11 +325,13 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  * either the same physical core, the same physical socket, the same NUMA
  * node, or just all of them, will be put together to form runqueues.
  */
-#define OPT_RUNQUEUE_CORE   0
-#define OPT_RUNQUEUE_SOCKET 1
-#define OPT_RUNQUEUE_NODE   2
-#define OPT_RUNQUEUE_ALL3
+#define OPT_RUNQUEUE_CPU0
+#define OPT_RUNQUEUE_CORE   1
+#define OPT_RUNQUEUE_SOCKET 2
+#define OPT_RUNQUEUE_NODE   3
+#define OPT_RUNQUEUE_ALL4
 static const char *const opt_runqueue_str[] = {
+[OPT_RUNQUEUE_CPU] = "cpu",
 [OPT_RUNQUEUE_CORE] = "core",
 [OPT_RUNQUEUE_SOCKET] = "socket",
 [OPT_RUNQUEUE_NODE] = "node",
@@ -682,6 +687,8 @@ cpu_to_runqueue(struct csched2_private *prv, unsigned int 
cpu)
 BUG_ON(cpu_to_socket(cpu) == XEN_INVALID_SOCKET_ID ||
cpu_to_socket(peer_cpu) == XEN_INVALID_SOCKET_ID);
 
+if (opt_runqueue == OPT_RUNQUEUE_CPU)
+continue;
 if ( opt_runqueue == OPT_RUNQUEUE_ALL ||
  (opt_runqueue == OPT_RUNQUEUE_CORE && same_core(peer_cpu, cpu)) ||
  (opt_runqueue == OPT_RUNQUEUE_SOCKET && same_socket(peer_cpu, 
cpu)) ||
-- 
2.12.0


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

[Xen-devel] [PATCH v2 0/2] xen: credit2: flexible configuration for runqueues

[Praveen Kumar]

Hello,

The idea is to give user more flexibility to configure runqueue further.
For most workloads and in most systems, using per-core means have too many
small runqueues. Using per-socket is almost always better, but it may result
in too few big runqueues.

OPTION 1 :

The user can create runqueue per-cpu using Xen boot parameter like below:

 credit2_runqueue=cpu

which would mean the following:
 - pCPU 0 belong to runqueue 0
 - pCPU 1 belong to runqueue 1
 - pCPU 2 belong to runqueue 2
 and so on.

OPTION 2 :

Further user can be allowed to say something shown below :

 credit2_runqueue=0,1,4,5;2,3,6,7;8,9,12,13;10,11,14,15

or (with exactly the same meaning, but a perhaps more clear syntax):

 credit2_runqueue=[[0,1,4,5][2,3,6,7][8,9,12,13][10,11,14,15]]

which would mean the following:
 - pCPUs 0, 1, 4 and 5 belong to runqueue 0
 - pCPUs 2, 3, 6 and 7 belong to runqueue 1
 - pCPUs 8, 9, 12 and 13 belong to runqueue 2
 - pCPUs 10, 11, 14 and 15 belong to runqueue 3

Thanks and Regards,
Praveen Kumar.
---
Praveen Kumar (2):
  xen: credit2: enable per cpu runqueue creation
  xen: credit2: provide flexible option to create runqueue

 docs/misc/xen-command-line.markdown |   9 +-
 xen/common/sched_credit2.c  | 185 +++-
 2 files changed, 188 insertions(+), 6 deletions(-)

-- 
2.12.0


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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Volodymyr Babchuk]

Hi Stefano,

On 30 March 2017 at 21:52, Stefano Stabellini  wrote:
> On Thu, 30 Mar 2017, Volodymyr Babchuk wrote:
>> Hi Julien,
>>
>> 5pm UTC+1 will be fine for me.
>>
>> I just finished my EL0 PoC and want to share benchmark results.
>>
>> My benchmark setup is primitive, but results are reproducible. I have
>> wrote small driver that calls SMC 10.000.000  times in a loop. So,
>> benchmark looks like this:
>>
>> root@xenaarch64:~# time cat /proc/smc_test
>>  Will call SMC 1000 time(s)
>> Done!
>>
>> real 1m51.428s
>> user 0m0.020s
>> sys 1m51.240s
>>
>> I compared three types of SMC "handlers":
>>
>> 1. Right in hypervisor. I lust put `advance_pc` into the
>> `do_trap_smc()`. This is the base.
>> 2. Handling in MiniOS, using `monitor.c` framework.
>> 3. Handling in EL0 XEN application.
>>
>> In all three cases there was no actual handling. Just variants of `return 
>> 0;`.
>> Results:
>>
>> 1. Hypervisor:
>> real 0m10.757s
>> user 0m0.000s
>> sys 0m10.752s
>>
>> 10.757s = 1x (base value)
>> 1.07us per call
>
> 1u is incredibly good actually

Yep. But handler was right in the traps.c. There is very short path:
guest_sync (in entry.S) -> do_trap_hypervisor() -> do_trap_smc().
I assume that most of simple traps are handled within 1-2us.

>
>> 2. MiniOs:
>> real 1m51.428s
>> user 0m0.020s
>> sys 1m51.240s
>>
>> 111.428s = 10.35x slower than hypervisor handler
>> 11.1us per call
>>
>> 3. EL0:
>> real 1m3.525s
>> user 0m0.000s
>> sys 1m3.516s
>>
>> 63.525s = 5.9x slower than hypervisor handler
>> 6.35us par call
>>
>> As you can see, handling in hypervisor mode is obviously the fastest
>> way. In my first implementation EL0 approach was as slow as MiniOs.
>> Then I simplified context switching (for example we don't need to
>> save/restore GIC context). That gave me 1.7x boost. Now profiler shows
>> that hypervisor spends time in spinlocks and p2m code. But, anyways,
>> 10 000 000 traps in 60 seconds is a good result :)
>>
>> Testing was done on Renesas H3 board with 4xA57 cores.
>
> This is a very good result! I am also quite happy with your scientific
> approach.
Thanks!

> I wish more people started their projects doing experiments
> like this one, before putting their head down to write thousands of
> lines of code. I encourage you to submit a talk to Xen Summit about this
> and/or write a blog post for https://blog.xenproject.org/.
Yep. Actually Artem is pushing me to talk at Xen Summit :)

> I think that 6u per call is very good. Seeing that in the hypervisor
> case the time is only 1u per call, it makes me think we might be able to
> go down a bit more. I also assume that it is quite reliable (having
> vcpus pinned to pcpus), while in the MiniOs case, unless you have enough
> free pcpus to guarantee that MiniOs is already running, we should see
> spikes of latency, right? Because if MiniOs is not running, or it cannot
> run immediately, it should take much longer?  In fact, where was MiniOs
> running in your setup?

Yes, there was MiniOS for aarch64 running. I published links to
corresponding patches in the ML some time ago.

I didn't pinned vcpus to cpus because I had only 3 domais running on 4 CPUs:
dom0, domU which I used for benchmarking and MiniOS. I'm sure that at
leas two cores were idle. But you are right, under heavy load there
will be latency spikes, because we can't guarantee that MiniOs will be
scheduled immediately to serve handling request.
My design of EL0 app is better in this case, because for hypervisor it
looks like another function call. It still can be preempted, thought.
But at least entry to EL0 handler is done immediately.

And yes, my profiler shows that there are ways to further decrease
latency. Most obvious way is to get rid of 2nd stage translation and
thus eliminate p2m code from the call chain. Currently hypervisor
spends 20% of time in spinlocks code and about ~10-15% in p2m. So
there definitely are areas to improve :)
>
>> On 28 March 2017 at 18:23, Julien Grall  wrote:
>> > Hi all,
>> >
>> > Apologies for the late sending, you will find at the end of the e-mail a
>> > summary of the discussion from the previous call. Feel free to reply if I
>> > missed some parts.
>> >
>> > I suggest to have the next call on the 5th April at 5PM UTC. Any opinions?
>> >
>> > Also do you have any specific topic you would like to talk during this 
>> > call?
>> >
>> > Cheers,
>> >
>> > == Attendees ==
>> >
>> > Apologies if I misspelled any name.
>> >
>> > Stefano, Aporeto
>> > Julien, ARM
>> > Oleksandr, EPAM
>> > Artem, EPAM
>> > Thanasis, OnApp
>> > Volodymir, EPAM
>> >
>> > == Xen on ARM status ==
>> >
>> > Over 100 patches in-flight for Xen on ARM:
>> > - PV protocols: Some are already accepted
>> > - NUMA support
>> > - GICv3 ITS support
>> > - Exposing and emulating a PL011 for guest
>> > - guest SMC forwarding for Xilinx platform
>> > - Interrupt 

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

[Stefano Stabellini]

On Thu, 30 Mar 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/03/17 19:37, Stefano Stabellini wrote:
> > On Thu, 30 Mar 2017, Julien Grall wrote:
> > > +/*
> > > + * When using ACPI, most of the MMIO regions will be mapped on-demand
> > > + * in stage-2 page tables for the hardware domain because Xen is not
> > > + * able to know from the EFI memory map the MMIO regions.
> > > + */
> > > +static bool try_map_mmio(gfn_t gfn)
> > > +{
> > > +struct domain *d = current->domain;
> > > +
> > > +/* For the hardware domain, all MMIOs are mapped with GFN == MFN */
> > > +mfn_t mfn = _mfn(gfn_x(gfn));
> > > +
> > > +/*
> > > + * Device-Tree should already have everything mapped when building
> > > + * the hardware domain.
> > > + */
> > > +if ( acpi_disabled )
> > > +return false;
> > > +
> > > +if ( d != hardware_domain )
> > 
> > is_hardware_domain(d)
> 
> Will fix it.
> 
> > 
> > > +return false;
> > > +
> > > +/* The hardware domain can only map permitted MMIO regions */
> > > +if ( !iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + 1) )
> > > +return false;
> > 
> > Because of the potential of causing problems with DMA to device MMIO,
> > I would add a warning here, something like:
> > 
> >dprintk(XENLOG_WARNING, "Mapping gfn=mfn=%"PRI_gfn" to Dom%d\n",
> > d->domain_id);
> > 
> > I hope that it will help us debug issues when/if we'll actually
> > encounter such a case.
> 
> I don't think this will help us and it will flood the console in debug-build
> (there are a lot of MMIO to map).
> 
> When SMMUs are not used, DMA to device MMIO will work regardless the mapping
> in stage-2.
> 
> When SMMUs are in use, you will get a SMMU fault that tells you the address
> used. With that you could know the region was not mapped.
 
Fair enough. Do you think there is any value in adding only one debug
warning, to say that we are mapping MMIOs on trap on this platform? But
today, it would basically be the same as saying "ACPI is enabled".

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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Stefano Stabellini]

On Thu, 30 Mar 2017, Volodymyr Babchuk wrote:
> Hi Julien,
> 
> 5pm UTC+1 will be fine for me.
> 
> I just finished my EL0 PoC and want to share benchmark results.
> 
> My benchmark setup is primitive, but results are reproducible. I have
> wrote small driver that calls SMC 10.000.000  times in a loop. So,
> benchmark looks like this:
> 
> root@xenaarch64:~# time cat /proc/smc_test
>  Will call SMC 1000 time(s)
> Done!
> 
> real 1m51.428s
> user 0m0.020s
> sys 1m51.240s
> 
> I compared three types of SMC "handlers":
> 
> 1. Right in hypervisor. I lust put `advance_pc` into the
> `do_trap_smc()`. This is the base.
> 2. Handling in MiniOS, using `monitor.c` framework.
> 3. Handling in EL0 XEN application.
> 
> In all three cases there was no actual handling. Just variants of `return 0;`.
> Results:
> 
> 1. Hypervisor:
> real 0m10.757s
> user 0m0.000s
> sys 0m10.752s
> 
> 10.757s = 1x (base value)
> 1.07us per call

1u is incredibly good actually


> 2. MiniOs:
> real 1m51.428s
> user 0m0.020s
> sys 1m51.240s
> 
> 111.428s = 10.35x slower than hypervisor handler
> 11.1us per call
> 
> 3. EL0:
> real 1m3.525s
> user 0m0.000s
> sys 1m3.516s
> 
> 63.525s = 5.9x slower than hypervisor handler
> 6.35us par call
> 
> As you can see, handling in hypervisor mode is obviously the fastest
> way. In my first implementation EL0 approach was as slow as MiniOs.
> Then I simplified context switching (for example we don't need to
> save/restore GIC context). That gave me 1.7x boost. Now profiler shows
> that hypervisor spends time in spinlocks and p2m code. But, anyways,
> 10 000 000 traps in 60 seconds is a good result :)
> 
> Testing was done on Renesas H3 board with 4xA57 cores.

This is a very good result! I am also quite happy with your scientific
approach. I wish more people started their projects doing experiments
like this one, before putting their head down to write thousands of
lines of code. I encourage you to submit a talk to Xen Summit about this
and/or write a blog post for https://blog.xenproject.org/.

I think that 6u per call is very good. Seeing that in the hypervisor
case the time is only 1u per call, it makes me think we might be able to
go down a bit more. I also assume that it is quite reliable (having
vcpus pinned to pcpus), while in the MiniOs case, unless you have enough
free pcpus to guarantee that MiniOs is already running, we should see
spikes of latency, right? Because if MiniOs is not running, or it cannot
run immediately, it should take much longer?  In fact, where was MiniOs
running in your setup?


> On 28 March 2017 at 18:23, Julien Grall  wrote:
> > Hi all,
> >
> > Apologies for the late sending, you will find at the end of the e-mail a
> > summary of the discussion from the previous call. Feel free to reply if I
> > missed some parts.
> >
> > I suggest to have the next call on the 5th April at 5PM UTC. Any opinions?
> >
> > Also do you have any specific topic you would like to talk during this call?
> >
> > Cheers,
> >
> > == Attendees ==
> >
> > Apologies if I misspelled any name.
> >
> > Stefano, Aporeto
> > Julien, ARM
> > Oleksandr, EPAM
> > Artem, EPAM
> > Thanasis, OnApp
> > Volodymir, EPAM
> >
> > == Xen on ARM status ==
> >
> > Over 100 patches in-flight for Xen on ARM:
> > - PV protocols: Some are already accepted
> > - NUMA support
> > - GICv3 ITS support
> > - Exposing and emulating a PL011 for guest
> > - guest SMC forwarding for Xilinx platform
> > - Interrupt latency improvement
> >
> > == PV protocols ==
> >
> > * PV protocols written by Stefano was merged after 10 months
> >
> > Stefano: PV protocols review are moving faster
> > Attendees agreed
> >
> > * Audio protocol: close to be accepted
> > * Display protocol: minor issue, a bit more design is required
> >
> > Hopefully both will be ready for Xen 4.9
> >
> > Oleksandr: What to do when the backend die?
> >
> > (I cannot find any notes on it some I am not sure if we answered the 
> > question
> > during the call. I suspect it has been asked to bring up the subject on the 
> > ML).
> >
> > == Interrupt latency ==
> >
> > Stefano: Some improvement has been done but it is not possible to know 
> > whether
> > it is good. Do you have any specific IRQ latency requirements?
> >
> > Artem: There is no hard latency requirements in automotive, although many
> > requirements depends on latency. For example:
> > * Scheduling
> > * GPU (implementation is sentive to interrupt latency)
> >
> > Automotive is using a set of benchmark to find the virtualization overhead. 
> > This
> > should be low.
> >
> > ACTION: Artem to send a list of benchmark
> >
> > == SMC/HVC handling in Xen ==
> >
> > Artem: Please review the proposal on the mailing list. See:
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg00430.html
> >
> > == Deprivilege mode ==
> >
> > EPAM are working on adding support for OP-TEE in 

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

[Julien Grall]

Hi Stefano,

On 30/03/17 19:37, Stefano Stabellini wrote:

On Thu, 30 Mar 2017, Julien Grall wrote:

+/*
+ * When using ACPI, most of the MMIO regions will be mapped on-demand
+ * in stage-2 page tables for the hardware domain because Xen is not
+ * able to know from the EFI memory map the MMIO regions.
+ */
+static bool try_map_mmio(gfn_t gfn)
+{
+struct domain *d = current->domain;
+
+/* For the hardware domain, all MMIOs are mapped with GFN == MFN */
+mfn_t mfn = _mfn(gfn_x(gfn));
+
+/*
+ * Device-Tree should already have everything mapped when building
+ * the hardware domain.
+ */
+if ( acpi_disabled )
+return false;
+
+if ( d != hardware_domain )


is_hardware_domain(d)


Will fix it.




+return false;
+
+/* The hardware domain can only map permitted MMIO regions */
+if ( !iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + 1) )
+return false;


Because of the potential of causing problems with DMA to device MMIO,
I would add a warning here, something like:

   dprintk(XENLOG_WARNING, "Mapping gfn=mfn=%"PRI_gfn" to Dom%d\n", 
d->domain_id);

I hope that it will help us debug issues when/if we'll actually
encounter such a case.


I don't think this will help us and it will flood the console in 
debug-build (there are a lot of MMIO to map).


When SMMUs are not used, DMA to device MMIO will work regardless the 
mapping in stage-2.


When SMMUs are in use, you will get a SMMU fault that tells you the 
address used. With that you could know the region was not mapped.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

[Julien Grall]

On 30/03/17 19:32, Julien Grall wrote:

On 30/03/17 19:28, Julien Grall wrote:

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

+void synchronize_serror(void)


Sorry for been late in the party. Looking at the way you use the
function, you execute depending on the behavior chosen by the user when
an SErrors happen. This behavior will not change at runtime, so always
checking the option chosen in the hot path does not sound very efficient.

I would recommend to look at ALTERNATIVE and streamline (dsb sy, isb).
I.e

ALTERNATIVE("dsb sy; isb", "nop; nop", ...) or the invert depending of
the place.


To complete what I was suggestion, you could define:

/* Synchronize SError unless the feature is selected */
#define SYNCHRONIZE_SERROR(feat) ALTERNATIVE("dsb sy; isb", "nop; nop");


Or even:

/*
 * Synchronize SError unless the feature is selected.
 * This is relying on the SErrors are currently unmasked.
 */
#define SYNCHRONIZE_SERROR(feat)  \
do {  \
  ASSERT(cpus_have_cap(feat) && local_abort_is_enabled());\
  ALTERNATIVE("dsb sy; isb", "nop; nop"); \
while (0)

The ASSERT is here to check that we have abort enabled. Otherwise, doing 
the synchronization would be pointless.


Note that the function local_abort_is_enabled is not implemented. But it 
is easy to write it. Looking how local_irq_is_enabled was implemented.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

[Stefano Stabellini]

On Thu, 30 Mar 2017, Julien Grall wrote:
> When booting using ACPI, not all MMIOs can be discovered by parsing the
> static tables or the UEFI memory map. A lot of them will be described in
> the DSDT. However, Xen does not have an AML parser which requires us to
> find a different approach.
> 
> During the first discussions on supporting ACPI (see design doc [1]), it
> was decided to rely on the hardware domain to make a request to the
> hypervisor to map the MMIO region in stage-2 page table before accessing
> it. This approach works fine if the OS has limited hooks to modify the
> page tables.
> 
> In the case of Linux kernel, notifiers have been added to map
> the MMIO regions when adding a new AMBA/platform device. Whilst this is
> covering most of the MMIOs, some of them (e.g OpRegion, ECAM...) are not
> related to a specific device or the driver is not using the
> AMBA/platform API. So more hooks would need to be added in the code.
> 
> Various approaches have been discussed (see [2]), one of them was to
> create stage-2 mappings seamlessly in Xen upon hardware memory faults.
> This approach was first ruled out because it relies on the hardware
> domain to probe the region before any use. So this would not work when
> DMA'ing to another device's MMIO region when the device is protected by
> an SMMU. It has been pointed out that this is a limited use case compare
> to DMA'ing between MMIO and RAM.
> 
> This patch implements this approach. All MMIOs region will be mapped in
> stage-2 using p2m_mmio_direct_c (i.e normal memory outer and inner
> write-back cacheable). The stage-1 page table will be in control of the
> memory attribute. This is fine because the hardware domain is a trusted
> domain.
> 
> Note that MMIO will only be mapped on a data abort fault. It is assumed
> that it will not be possible to execute code from MMIO
> (p2m_mmio_direct_c will forbid that).
> 
> As mentioned above, this solution will cover most of the cases. If a
> platform requires to do DMA'ing to another device's MMIO region without
> any access performed by the OS. Then it will be expected to have
> specific platform code in the hypervisor to map the MMIO at boot time or
> the OS to use the existing hypercalls (i.e XENMEM_add_to_add_physmap{,_batch})
> before any access.
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
> [2] https://marc.info/?l=linux-arm-kernel=148469169210500=2
> 
> Signed-off-by: Julien Grall 
> 
> ---
> This patch is a candidate for Xen 4.9. Whilst the last posting date
> was few days ago, I think it would be good to have this patch in the
> next release. Although ACPI support for ARM64 is still a technical
> preview, it would help servers to test Xen upstream on their platform
> with ACPI and provide feedback on missing features.
> 
> All the code is gated by !acpi_disabled and therefore will not be
> executed on when using Device Tree.
> 
> RM hat on: I will leave the decision to Stefano.
> 
> Shanker: You mentioned offline that you tested the patch. May I add
> your tested-by?
> 
> ---
>  xen/arch/arm/traps.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 614501f761..ebf915bb3b 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -49,6 +50,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* The base of the stack must always be double-word aligned, which means
>   * that both the kernel half of struct cpu_user_regs (which is pushed in
> @@ -2534,6 +2536,35 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
>  return !!handle_mmio(info);
>  }
>  
> +/*
> + * When using ACPI, most of the MMIO regions will be mapped on-demand
> + * in stage-2 page tables for the hardware domain because Xen is not
> + * able to know from the EFI memory map the MMIO regions.
> + */
> +static bool try_map_mmio(gfn_t gfn)
> +{
> +struct domain *d = current->domain;
> +
> +/* For the hardware domain, all MMIOs are mapped with GFN == MFN */
> +mfn_t mfn = _mfn(gfn_x(gfn));
> +
> +/*
> + * Device-Tree should already have everything mapped when building
> + * the hardware domain.
> + */
> +if ( acpi_disabled )
> +return false;
> +
> +if ( d != hardware_domain )

is_hardware_domain(d)


> +return false;
> +
> +/* The hardware domain can only map permitted MMIO regions */
> +if ( !iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + 1) )
> +return false;

Because of the potential of causing problems with DMA to device MMIO,
I would add a warning here, something like:

   dprintk(XENLOG_WARNING, "Mapping gfn=mfn=%"PRI_gfn" to Dom%d\n", 
d->domain_id);

I hope that it will help us debug issues when/if we'll actually
encounter 

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

[Julien Grall]

On 30/03/17 19:28, Julien Grall wrote:

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

+void synchronize_serror(void)


Sorry for been late in the party. Looking at the way you use the
function, you execute depending on the behavior chosen by the user when
an SErrors happen. This behavior will not change at runtime, so always
checking the option chosen in the hot path does not sound very efficient.

I would recommend to look at ALTERNATIVE and streamline (dsb sy, isb). I.e

ALTERNATIVE("dsb sy; isb", "nop; nop", ...) or the invert depending of
the place.


To complete what I was suggestion, you could define:

/* Synchronize SError unless the feature is selected */
#define SYNCHRONIZE_SERROR(feat) ALTERNATIVE("dsb sy; isb", "nop; nop");

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

+void synchronize_serror(void)


Sorry for been late in the party. Looking at the way you use the 
function, you execute depending on the behavior chosen by the user when 
an SErrors happen. This behavior will not change at runtime, so always 
checking the option chosen in the hot path does not sound very efficient.


I would recommend to look at ALTERNATIVE and streamline (dsb sy, isb). I.e

ALTERNATIVE("dsb sy; isb", "nop; nop", ...) or the invert depending of 
the place.



+{
+/* Synchronize against in-flight ld/st. */
+dsb(sy);
+
+/* A single instruction exception window */
+isb();
+}
+


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen 4.9 Development Update

[Oleksandr Tyshchenko]

Hi, all

On Tue, Mar 28, 2017 at 5:20 PM, Julien Grall  wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.9 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> working on.
>
> = Timeline =
>
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.9 timeline are as followed:
>
> * Last posting date: March 24th, 2017
> * Hard code freeze: April 7th, 2017
> * RC1: TBD
> * Release: June 2, 2017
>
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.9 must be posted no later than the last posting
> date. All patches posted after that date will be automatically queued
> into next release.
>
> RCs will be arranged immediately after freeze.
>
> We recently introduced a jira instance to track all the tasks (not only big)
> for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.
>
> Most of the tasks tracked by this e-mail also have a corresponding jira task
> referred by XEN-N.
>
> = Projects =
>
> == Hypervisor ==
>
> *  Per-cpu tasklet
>   -  XEN-28
>   -  Konrad Rzeszutek Wilk
>
> *  Add support of rcu_idle_{enter,exit}
>   -  XEN-27
>   -  Dario Faggioli
>
> === x86 ===
>
> *  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol) (v16)
>   -  XEN-42
>   -  Daniel Kiper
>
> *  Allow ioreq server interface to support XenGT (v7)
>   -  XEN-43
>   -  Yu Zhang
>   -  Paul Durrant
>
> *  PVHv2 support
>   -  XEN-44
>   -  Roger Pau Monne
>
> *  vNVDIMM support for HVM (RFC)
>   -  XEN-45
>   -  Haozhong Zhang
>
> *  Completion of the x86 insn emulator (as far as possible)
>   -  XEN-46
>   -  Jan Beulich
>
> *  Getting guest CPUID handling into a better shape
>   -  XEN-47
>   -  Andrew Cooper
>
> *  Enable L2 Cache Allocation Technology (v8)
>   -  XEN-37
>   -  Yi Sun
>
> *  Enable Memory Bandwidth Allocation (RFC)
>   -  XEN-48
>   -  Yi Sun
>
> *  Intel LMCE support: (v2)
>   -  XEN-68
>   -  Haozhon Zhang
>
> === ARM ===
>
> *  ITS emulation (Dom0 only) (v1)
>   -  XEN-2
>   -  Andre Przywara
>
> *  Support Tegra SoCs (RFC)
>   -  XEN-49
>   -  Kyle Temkin
>
> == Toolstack ==
>
> *  Libxl PVSCSI support (v13)
>   -  XEN-50
>   -  Olaf Hering
>
> *  Libxl depriv QEMU
>   -  Ian Jackson
>
> *  Remove blktap2
>   -  XEN-8
>   -  Wei Liu
>
> == Mini-OS ==
>
> == PV Drivers ==
>
> *  Xen transport for 9pfs
>   -  XEN-51
>   -  Stefano Stabellini
>
> *  PV calls
>   -  XEN-63
>   -  Stefano Stabellini
>
> *  Multi-touch
>   -  Oleksandr Andrushchenko
>   -  Oleksanr Grytsov
>
> *  Sound
>   -  Oleksandr Andrushchenko
>   -  Oleksanr Grytsov
>
> *  Display
>   -  Oleksandr Andrushchenko
>   -  Oleksanr Grytsov
>
> == GRUB ==
>
> *  Support booting Xen ARM
>   -  XEN-67
>   -  Fu Wei
>
> == Testing ==
>
> *  Continuous fuzzing of Xen code using Google oss-fuzz
>   -  Wei Liu
>
> == Blocker ==
>
> *  Fix issues with zero-length records in migration v2
>   -  XEN-5
>   -  Andrew Cooper
>
> == Completed ==
>
> *  Rework gcov support in hypervisor
>   -  Wei Liu
>
> *  XenStore XS_DIRECTORY_PART extension
>   -  Juergen Gross
>
> == Deferred ==
>
> *  Altp2m for ARM
>   -  Sergej Proskurin
>
>
> = Notes =
>
> * Revert commit 997382b771 or surround the code with NDEBUG before the
>   release (see e-mail <58a2ef4e027800139...@prv-mh.provo.novell.com>)
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

Hi, all.

I am working on both non-shared IOMMU support on ARM and IPMMU-VMSA driver.
Now they are RFC patches [1]. Want to see them in Xen 4.10).

[1] https://lists.xen.org/archives/html/xen-devel/2017-03/msg01905.html

-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH] docs/misc: document PV control/feature keys for laptop/slate mode

[Stefano Stabellini]

On Thu, 30 Mar 2017, Paul Durrant wrote:
> On 30 March 2017, at 18:49, Stefano Stabellini  wrote:
> >On Thu, 30 Mar 2017, Paul Durrant wrote:
> >> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
> >> added code to provide an 'laptop/slate mode' ACPI device to guests.
> >>
> >> When present this device is used by Microsoft Windows to bind a HID
> >> driver which controls whether the Windows desktop appearance is optimized
> >> for laptop/desktop or slate/tablet PCs. The mechanism for switching
> >> between modes is to open a handle to this driver and write a byte of
> >> arbitrary data.
> >>
> >> This patch documents xenstore keys such that a PV agent running in a
> >> Windows guest can advertise the capability to, and receive instruction
> >> from, a toolstack to cause such a mode switch.
> >>
> >> Signed-off-by: Paul Durrant 
> >> ---
> >> Cc: Andrew Cooper 
> >> Cc: George Dunlap 
> >> Cc: Ian Jackson 
> >> Cc: Jan Beulich 
> >> Cc: Konrad Rzeszutek Wilk 
> >> Cc: Stefano Stabellini 
> >> Cc: Tim Deegan 
> >> Cc: Wei Liu 
> >> ---
> >>  docs/misc/xenstore-paths.markdown | 15 +++
> >>  1 file changed, 15 insertions(+)
> >>
> >> diff --git a/docs/misc/xenstore-paths.markdown 
> >> b/docs/misc/xenstore-paths.markdown
> >> index 5d89ed8..6c80a9e 100644
> >> --- a/docs/misc/xenstore-paths.markdown
> >> +++ b/docs/misc/xenstore-paths.markdown
> >> @@ -435,6 +435,21 @@ XS_RESET_WATCHES xenstore message. See
> >>  [xen/include/public/io/xs\_wire.h][XSWIRE] for the XenStore wire
> >>  protocol definition.
> >> 
> >> + ~/control/laptop-slate-mode = (""|"laptop"|"slate") [w]
> >> +
> >> +This is the PV laptop/slate mode control node. If the toolstack has
> >> +provisioned a guest with the ACPI laptop/slate mode device then it
> >> +can write the desired mode here to cause the guest to switch modes if
> >> +necessary. The guest acknowledges a request by writing the empty
> >> +string back to the control node.
> >> +
> >> + ~/control/feature-laptop-slate-mode = (""|"0"|"1") [w]
> >> +
> >> +This may be initialized to "" by the toolstack and may then be set
> >> +to 0 or 1 by a guest to indicate whether it is capable or incapable,
> >> +respectively, of responding to a mode value written to
> >> +~/control/laptop-slate-mode.
> >Usually, this is done by having the guest drivers write something like:
> >feature-laptop-slate-mode
> >to xenstore. The lack of the feature-* means no support is available.
> >In fact, how is this supposed to work with old guest PV drivers that
> >don't know about ~/control/feature-laptop-slate-mode? There won't be
> >anybody to write "0" there, right?
> 
> The toolstack has to write this first because the parent control key is read 
> only to the guest.
> Old guests will not write 0 so the toolstack does not know whether the guest 
> can handle a command written to control/laptop-slate-mode. It has to apply 
> some form of timeout in
> that case. This is exactly the same as with any of the shutdown features.

All right, I had not read the shutdown protocol before, so this struck
me as odd (compared to PV frontends/backends). If I were to write this,
I would avoid the possibility to end up in uncertain state like "".
However, it is up to you :)


> >>  ### Domain Controlled Paths
> >> 
> >>   ~/data/* [w]
> >> --
> >> 2.1.4
> >>
> >
> 
> 
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [GSoC] Xen on ARM: create multiple guests from device tree

[Luca Miccio]

Hi Stefano,
sorry if i am so late but my schedule was full this week. I am currently 
preparing a presentation for an event here
in Italy and i had no time to check even my emails.

> Il giorno 29 mar 2017, alle ore 02:13, Stefano Stabellini 
>  ha scritto:
> 
> On Tue, 28 Mar 2017, Stefano Stabellini wrote:
>> Hello Luca,
>> 
>> did you manage to make any progress on the number of cores exposed by the 
>> model?
>> 
I am still not using the psci and the XEN console says that he is bringing up 
all the 4 CPUs.
>> Thank you for the Makefile patch! If you have time, I encourage you to
>> fix one of the other small outstanding bugs, for example XEN-20 or
>> XEN-11 (just the ability to load a Dom0 kernel bigger than 128MB or just
>> the ability to parse the new image_size field introduced in Linux 3.17).
>> 
I will try to give it a look this weekend but i am not sure to have the time to
make e fix soon. 
>> Finally, I would like to remind you of the upcoming deadline for
>> applications submissions, which is the 3rd of April for GSoC, see:
>> 
>> http://marc.info/?l=xen-devel=149071502330534
>> 
>> The GSoC application system is
>> https://summerofcode.withgoogle.com/get-started/.
>> 
>> Please give a look at the Xen Project application template here:
>> 
>> https://wiki.xenproject.org/wiki/GSoC_Student_Application_Template
>> 
>> It also includes an "Implementation Plan", where you have the chance to
>> explain the implementation plan for the project you would like to apply
>> for.
> 
> FYI I added some more information on this project here:
> http://marc.info/?l=xen-devel=149074542307880 
> 
> 

Thank you for all the information. Unfortunately I have not considered all of 
my personal deadlines
before attempting to approach this project. It was my mistake. Anyway I will 
try with all my strength
to fill up the application this weekend and try to submit it anyway. I like the 
Xen project, and even if
I will not be chosen for this task, surely I will continue to support and 
follow it diligently.

> 
>> 
>> On Thu, 23 Mar 2017, Luca Miccio wrote:
>>> Hello Julien
 Il giorno 23 mar 2017, alle ore 15:49, Julien Grall  
 ha scritto:
 
 Hello Luca,
 
 On 23/03/17 02:23, Luca Miccio wrote:
> I tried also this method but i had the same error. So i came up with the
> idea of removing the
> psci method from the configure and also from the dtsi file that i have
> changed.
 
 I guess you are using only 1 core in this case. Am I right?
 
>>> No, i am using 4 cores, with —cores option and i think that i am using 
>>> actually 4 cores
>>> because on the model “control panel” i have 4 green triangles which ones of 
>>> them should
>>> represent the number of cores and their status. 
>>> It is only my opinion so, please, tell me if i am wrong.
> 
> With this configuration the model booted up correctly, even if the
> process took about 10 minutes.
> Just for my personal knowledge: it is normal that the boot is very slow?
> Is the rootfs that i’m using?
 
 Booting a full distro on the model can be slow. Usually I write my own 
 initscript to start the necessary daemon and skip systemd.
 
 42sh> cat /root/init.sh
 
 set -x
 mount -t proc proc  /proc
 mount -t devtmpfs dev /dev
 
 export HOME=/root
 
 rm -rf /var/run/xenstore
 rm -rf /var/run/xen
 
 /etc/init.d/xencommons start
 
 exec /bin/bash
 
 ---
 
 And I pass init=/root/init.sh on the Linux kernel command line.
 
>>> That helped a lot, thank you.
 Cheers,
 
 -- 
 Julien Grall
>>> 
>>> Luca.
Thank you,
Luca

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

Re: [Xen-devel] [PATCH v2 11/19] xen/arm32: Use alternative to skip the check of pending serrors

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.

The ARM32 supports the alternative patching feature. We can use an
ALTERNATIVE to avoid checking option at every trap. We added a new
cpufeature named "SKIP_CHECK_PENDING_VSERROR". This feature will be
enabled when the option is not diverse.

Signed-off-by: Wei Chen 


Reviewed-by: Julien Grall 


---


Stefano, this is requiring the alternative patch (see [1]) which is 
still in review.


Wei, a general rule is to mention the dependencies between series. So we 
don't apply by mistake in the wrong order.


Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg04132.html



 xen/arch/arm/arm32/entry.S | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 2187226..105cae8 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 

 #define SAVE_ONE_BANKED(reg)mrs r11, reg; str r11, [sp, #UREGS_##reg]
@@ -44,6 +45,14 @@ save_guest_regs:
 SAVE_BANKED(fiq)
 SAVE_ONE_BANKED(R8_fiq); SAVE_ONE_BANKED(R9_fiq); 
SAVE_ONE_BANKED(R10_fiq)
 SAVE_ONE_BANKED(R11_fiq); SAVE_ONE_BANKED(R12_fiq);
+
+/*
+ * If the SKIP_CHECK_PENDING_VSERROR has been set in the cpu feature,
+ * the checking of pending SErrors will be skipped.
+ */
+ALTERNATIVE("nop",
+"b skip_check",
+SKIP_CHECK_PENDING_VSERROR)
 /*
  * Start to check pending virtual abort in the gap of Guest -> HYP
  * world switch.
@@ -99,6 +108,7 @@ abort_guest_exit_end:
  */
 bne return_from_trap

+skip_check:
 mov pc, lr

 #define DEFINE_TRAP_ENTRY(trap) \



--
Julien Grall

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

Re: [Xen-devel] [PATCH] docs/misc: document PV control/feature keys for laptop/slate mode

[Paul Durrant]

On 30 March 2017, at 18:49, Stefano Stabellini  wrote:

>
>
>On Thu, 30 Mar 2017, Paul Durrant wrote:
>> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
>> added code to provide an 'laptop/slate mode' ACPI device to guests.
>>
>> When present this device is used by Microsoft Windows to bind a HID
>> driver which controls whether the Windows desktop appearance is optimized
>> for laptop/desktop or slate/tablet PCs. The mechanism for switching
>> between modes is to open a handle to this driver and write a byte of
>> arbitrary data.
>>
>> This patch documents xenstore keys such that a PV agent running in a
>> Windows guest can advertise the capability to, and receive instruction
>> from, a toolstack to cause such a mode switch.
>>
>> Signed-off-by: Paul Durrant 
>> ---
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> ---
>>  docs/misc/xenstore-paths.markdown | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/docs/misc/xenstore-paths.markdown 
>> b/docs/misc/xenstore-paths.markdown
>> index 5d89ed8..6c80a9e 100644
>> --- a/docs/misc/xenstore-paths.markdown
>> +++ b/docs/misc/xenstore-paths.markdown
>> @@ -435,6 +435,21 @@ XS_RESET_WATCHES xenstore message. See
>>  [xen/include/public/io/xs\_wire.h][XSWIRE] for the XenStore wire
>>  protocol definition.
>>
>> + ~/control/laptop-slate-mode = (""|"laptop"|"slate") [w]
>> +
>> +This is the PV laptop/slate mode control node. If the toolstack has
>> +provisioned a guest with the ACPI laptop/slate mode device then it
>> +can write the desired mode here to cause the guest to switch modes if
>> +necessary. The guest acknowledges a request by writing the empty
>> +string back to the control node.
>> +
>> + ~/control/feature-laptop-slate-mode = (""|"0"|"1") [w]
>> +
>> +This may be initialized to "" by the toolstack and may then be set
>> +to 0 or 1 by a guest to indicate whether it is capable or incapable,
>> +respectively, of responding to a mode value written to
>> +~/control/laptop-slate-mode.
>Usually, this is done by having the guest drivers write something like:
>feature-laptop-slate-mode
>to xenstore. The lack of the feature-* means no support is available.
>In fact, how is this supposed to work with old guest PV drivers that
>don't know about ~/control/feature-laptop-slate-mode? There won't be
>anybody to write "0" there, right?

The toolstack has to write this first because the parent control key is read 
only to the guest.
Old guests will not write 0 so the toolstack does not know whether the guest 
can handle a command written to control/laptop-slate-mode. It has to apply some 
form of timeout in that case. This is exactly the same as with any of the 
shutdown features.

  Paul

>>  ### Domain Controlled Paths
>>
>>   ~/data/* [w]
>> --
>> 2.1.4
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 09/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

[Julien Grall]

On 30/03/17 10:13, Wei Chen wrote:

In the later patches of this series, we want to use the alternative
patching framework to avoid checking serror_op in every entries.
So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
serror_op. When serror_op is not equal to SERROR_DIVERSE, this
feature will be set to cpu_hwcaps.

Currently, the default serror_op is SERROR_DIVERSE, if we want to
change the serror_op value we have to place the serror parameter
in command line. It seems no problem to update cpu_hwcaps directly
in the serror parameter parsing function.

But one day, if we change the default serror_op to SERROR_PANIC or
SERROR_FORWARD by some security policy. We may not place the serror
parameter in command line. In this case, if we rely on the serror
parameter parsing function to update cpu_hwcaps, this function would
not be invoked and the "SKIP_CHECK_PENDING_VSERROR" could not be
set in cpu_hwcaps.

So, we introduce this initcall to guarantee the cpu_hwcaps can be
updated no matter the serror parameter is placed in the command line
or not.

Signed-off-by: Wei Chen 
---
v1->v2:
1. Explain this initcall is to future-proof the code in commit
   message.
2. Fix a coding style of this initcall.
---
 xen/arch/arm/traps.c | 9 +
 xen/include/asm-arm/cpufeature.h | 3 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 955d97c..dafb730 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -120,6 +120,15 @@ static void __init parse_serrors_behavior(const char *str)
 }
 custom_param("serrors", parse_serrors_behavior);

+static int __init update_serrors_cpu_caps(void)
+{
+if ( serrors_op != SERRORS_DIVERSE )
+cpus_set_cap(SKIP_CHECK_PENDING_VSERROR);


Thinking a bit more of this. I am wondering if we should add a warning 
(see warning_add) if the user is selecting an option other than diverse. 
Two reasons for that:
	1) The user is fully aware that he is not classifying the SError at his 
own risks
	2) If someone send an e-mail saying: "My guest crashed the hypervisor 
with an SError". We can directly know from the log.


Any opinions?

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 107006: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  3bdb14004b9fe8c35e4961f8a7c73c19f0fb4365
baseline version:
 xen  9614f0246688d1e4cee4d6bec47894b6e289c721

Last test of basis   107000  2017-03-30 14:01:50 Z0 days
Testing same since   107006  2017-03-30 16:01:43 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Paul Durrant 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=3bdb14004b9fe8c35e4961f8a7c73c19f0fb4365
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
3bdb14004b9fe8c35e4961f8a7c73c19f0fb4365
+ branch=xen-unstable-smoke
+ revision=3bdb14004b9fe8c35e4961f8a7c73c19f0fb4365
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x3bdb14004b9fe8c35e4961f8a7c73c19f0fb4365 = 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
++ : 

Re: [Xen-devel] [GSoC]about the task "Share a page in memory from the VM config file"

[Stefano Stabellini]

I think that makes perfect sense.

On Thu, 30 Mar 2017, Zhongze Liu wrote:
> Hi Stefano,
> 
> What do you say if we extend this project into "sharing multiple
> ranges of memory area among VMs from the config file".
> 
> Cheers.
> 
> Zhongze Liu
> 
> 2017-03-30 9:07 GMT+08:00 Zhongze Liu :
> > Hi Stefano,
> >
> > Thanks for reminding me of the deadline and providing me with more 
> > information
> > on this project.
> >
> > I did setup the arm model and doing well with it. But after that, I
> > encountered some
> > private issues that I have to handle first, so I failed to get back to
> > you immediately.
> > Sorry for that.
> >
> > I would finish the proposal ASAP and start discussing the
> > implementation details with
> > you and Julien.
> >
> > Thanks again.
> >
> > Cheers.
> >
> > Zhongze Liu
> >
> > 2017-03-29 8:15 GMT+08:00 Stefano Stabellini :
> >> On Tue, 28 Mar 2017, Stefano Stabellini wrote:
> >>> Hello Zhongze,
> >>>
> >>> did you manage to make any progress with the ARM model?
> >>>
> >>> Finally, I would like to remind you of the upcoming deadline for
> >>> applications submissions, which is the 3rd of April for GSoC and the
> >>> 30th of March for Outreachy, see:
> >>>
> >>> http://marc.info/?l=xen-devel=149071502330534
> >>>
> >>> Please give a look at the Xen Project application template here:
> >>>
> >>> https://wiki.xenproject.org/wiki/GSoC_Student_Application_Template
> >>>
> >>> It also includes an "Implementation Plan", where you have the chance to
> >>> explain the implementation plan for the projects you would like to apply
> >>> for.
> >>
> >> FYI I added more info on this project here:
> >>
> >> http://marc.info/?l=xen-devel=149074641908123
> >>
> >>
> >>> Thanks,
> >>>
> >>> Stefano
> >>>
> >>>
> >>> On Wed, 22 Mar 2017, Stefano Stabellini wrote:
> >>> > On Thu, 23 Mar 2017, Zhongze Liu wrote:
> >>> > > Back to the GSoC task.
> >>> > > Do I need to meet any special hardware requirements to complete the 
> >>> > > task?
> >>> >
> >>> > No special hardware requirements, what you have below is more than
> >>> > enough. However, if you have some spare time, it would be helpful for
> >>> > you to setup an ARM build and test environment too, because it would be
> >>> > nice if you could make this project work on ARM as well. In fact, this
> >>> > work is mostly meant to help users in embedded scenarios, which are
> >>> > mostly ARM based. You could go very far in this project with only the
> >>> > x86 hardware you have, but you'll need ARM for the last bit.
> >>> >
> >>> > First you need a cross-compiler, you can download the latest from
> >>> > linaro:
> >>> >
> >>> > https://releases.linaro.org/components/toolchain/binaries/latest/armv8l-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-x86_64_armv8l-linux-gnueabihf.tar.xz
> >>> >
> >>> > You can download a free ARMv8 emulator from here:
> >>> >
> >>> > https://developer.arm.com/products/system-design/fixed-virtual-platforms
> >>> >
> >>> > choose "ARMv8-A Foundation Platform for Linux". Then follow these
> >>> > instructions:
> >>> >
> >>> > http://marc.info/?l=xen-devel=149021352631609
> >>> >
> >>> > Please read the following emails in the thread too which tells you how
> >>> > to build Xen and Linux for ARM. We are still solving some issues but the
> >>> > steps so far are also on the wiki, see "Firmware & boot-wrapper" ->
> >>> > arm64 and "Foundation Model":
> >>> >
> >>> > https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels
> >>> >
> >>> >
> >>> > > Currently I have 12G RAM and 128G SSD + 1T HDD.
> >>> > > The output of "lscpu" on my test machine is as follows:
> >>> > >
> >>> > >Architecture:  x86_64
> >>> > >CPU op-mode(s):32-bit, 64-bit
> >>> > >Byte Order:Little Endian
> >>> > >CPU(s):4
> >>> > >On-line CPU(s) list:   0-3
> >>> > >Thread(s) per core:1
> >>> > >Core(s) per socket:4
> >>> > >Socket(s): 1
> >>> > >NUMA node(s):  1
> >>> > >Vendor ID: GenuineIntel
> >>> > >CPU family:6
> >>> > >Model: 94
> >>> > >Model name:Intel(R) Core(TM) i5-6300HQ CPU @ 2.30GHz
> >>> > >Stepping:  3
> >>> > >CPU MHz:   800.030
> >>> > >CPU max MHz:   3200.
> >>> > >CPU min MHz:   800.
> >>> > >BogoMIPS:  4609.00
> >>> > >Virtualization:VT-x
> >>> > >L1d cache: 32K
> >>> > >L1i cache: 32K
> >>> > >L2 cache:  256K
> >>> > >L3 cache:  6144K
> >>> > >NUMA node0 CPU(s): 0-3
> >>> > >Flags: fpu vme de pse tsc msr pae mce cx8 apic sep
> >>> > > mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
> >>> > > tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs
> >>> > > bts rep_good nopl xtopology 

Re: [Xen-devel] [PATCH v2 09/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

In the later patches of this series, we want to use the alternative
patching framework to avoid checking serror_op in every entries.
So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
serror_op. When serror_op is not equal to SERROR_DIVERSE, this
feature will be set to cpu_hwcaps.

Currently, the default serror_op is SERROR_DIVERSE, if we want to
change the serror_op value we have to place the serror parameter
in command line. It seems no problem to update cpu_hwcaps directly
in the serror parameter parsing function.

But one day, if we change the default serror_op to SERROR_PANIC or
SERROR_FORWARD by some security policy. We may not place the serror
parameter in command line. In this case, if we rely on the serror
parameter parsing function to update cpu_hwcaps, this function would
not be invoked and the "SKIP_CHECK_PENDING_VSERROR" could not be
set in cpu_hwcaps.


This paragraph is a bit difficult to understand. I would reword to: 
"While the default option will be diverse today, this may change in the 
future. So we introduce " and then paste the paragraph below.




So, we introduce this initcall to guarantee the cpu_hwcaps can be
updated no matter the serror parameter is placed in the command line
or not.

Signed-off-by: Wei Chen 


With the change suggested above:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] docs/misc: document PV control/feature keys for laptop/slate mode

[Stefano Stabellini]

On Thu, 30 Mar 2017, Paul Durrant wrote:
> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
> added code to provide an 'laptop/slate mode' ACPI device to guests.
> 
> When present this device is used by Microsoft Windows to bind a HID
> driver which controls whether the Windows desktop appearance is optimized
> for laptop/desktop or slate/tablet PCs. The mechanism for switching
> between modes is to open a handle to this driver and write a byte of
> arbitrary data.
> 
> This patch documents xenstore keys such that a PV agent running in a
> Windows guest can advertise the capability to, and receive instruction
> from, a toolstack to cause such a mode switch.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
>  docs/misc/xenstore-paths.markdown | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/docs/misc/xenstore-paths.markdown 
> b/docs/misc/xenstore-paths.markdown
> index 5d89ed8..6c80a9e 100644
> --- a/docs/misc/xenstore-paths.markdown
> +++ b/docs/misc/xenstore-paths.markdown
> @@ -435,6 +435,21 @@ XS_RESET_WATCHES xenstore message. See
>  [xen/include/public/io/xs\_wire.h][XSWIRE] for the XenStore wire
>  protocol definition.
>  
> + ~/control/laptop-slate-mode = (""|"laptop"|"slate") [w]
> +
> +This is the PV laptop/slate mode control node. If the toolstack has
> +provisioned a guest with the ACPI laptop/slate mode device then it
> +can write the desired mode here to cause the guest to switch modes if
> +necessary. The guest acknowledges a request by writing the empty
> +string back to the control node.
> +
> + ~/control/feature-laptop-slate-mode = (""|"0"|"1") [w]
> +
> +This may be initialized to "" by the toolstack and may then be set
> +to 0 or 1 by a guest to indicate whether it is capable or incapable,
> +respectively, of responding to a mode value written to
> +~/control/laptop-slate-mode.

Usually, this is done by having the guest drivers write something like:

feature-laptop-slate-mode

to xenstore. The lack of the feature-* means no support is available.
In fact, how is this supposed to work with old guest PV drivers that
don't know about ~/control/feature-laptop-slate-mode? There won't be
anybody to write "0" there, right?


>  ### Domain Controlled Paths
>  
>   ~/data/* [w]
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] raisin and minios stubdom

[Gémes Géza]

On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:

Hi,

Currently the xen build system has optional support for building a minios
(+needed libraries and tools) based stubdom.

What is your opinion about moving support for building this into raisin and
once that is stable drop support in the xen build system?

Why? I do like doing 'make' and 'make install' and it doing everything
for me.


Cheers,

Geza


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


Because it means that xen build needs to download and build a lot of 3PP 
components. Raisin is already designed to do so (it already builds 
qemu-xen, qemu-traditional, libvirt and a few others). I think building 
anything besides xen proper would fit its scope better.


Cheers,

Geza


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

Re: [Xen-devel] [PATCH v2 08/19] xen/arm: Introduce a command line parameter for SErrors/Aborts

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

In order to distinguish guest-generated SErrors from hypervisor-generated
SErrors we have to place SError checking code in every EL1 -> EL2 paths.
That will cause overhead on entries due to dsb/isb.

However, not all platforms want to categorize SErrors. For example, a host
that is running with trusted guests. The administrator can confirm that
all guests that are running on the host will not trigger such SErrors. In
this user-case, we should provide some options to administrators to avoid


s/user-case/use-case/


+### serrors (ARM)
+> `= diverse | forward | panic`
+
+> Default: `diverse`
+
+This parameter is provided to administrators to determine how the
+hypervisors handle SErrors.
+
+In order to distinguish guest-generated SErrors from hypervisor-generated
+SErrors we have to place SError checking code in every EL1 -> EL2 paths.
+That will cause overhead on entries due to dsb/isb. However, not all platforms


s/entries/entries and exits/ I think because none of the options you 
provide will effectively only do dsb/isb on entries.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 4/4] msi: taking interrupt format into consideration during judging a pirq is binded with a event channel

[Anthony PERARD]

On Fri, Mar 17, 2017 at 07:29:17PM +0800, Lan Tianyu wrote:
> From: Chao Gao 
> Subject: msi: taking interrupt format into consideration during
> judging a pirq is binded with a event channel

This is quite a long title, I think we can make it shorter. Maybe "msi:
Handle MSI remapping format.

> 
> As remapping format interrupt has been introduced, the vector in msi remapping
> format can also be 0, same as a interrupt is binded with a event channel.
> So we can't just use whether vector is 0 or not to judge a msi is binded
> to a event channel or not.
> 
> This patch takes the msi interrupt format into consideration.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  hw/pci/msi.c | 5 +++--
>  hw/pci/msix.c| 4 +++-
>  hw/xen/xen_pt_msi.c  | 2 +-
>  include/hw/xen/xen.h | 2 +-
>  xen-hvm-stub.c   | 2 +-
>  xen-hvm.c| 7 ++-
>  6 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/pci/msi.c b/hw/pci/msi.c
> index a87b227..8d1ac9e 100644
> --- a/hw/pci/msi.c
> +++ b/hw/pci/msi.c
> @@ -289,7 +289,7 @@ void msi_reset(PCIDevice *dev)
>  static bool msi_is_masked(const PCIDevice *dev, unsigned int vector)
>  {
>  uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
> -uint32_t mask, data;
> +uint32_t mask, data, addr_lo;
>  bool msi64bit = flags & PCI_MSI_FLAGS_64BIT;
>  assert(vector < PCI_MSI_VECTORS_MAX);
>  
> @@ -298,7 +298,8 @@ static bool msi_is_masked(const PCIDevice *dev, unsigned 
> int vector)
>  }
>  
>  data = pci_get_word(dev->config + msi_data_off(dev, msi64bit));
> -if (xen_is_pirq_msi(data)) {
> +addr_lo = pci_get_word(dev->config + msi_address_lo_off(dev));

This could be get_long, so addr_lo will actually have the all low bits
of the addr.

> +if (xen_is_pirq_msi(data, addr_lo)) {
>  return false;
>  }
>  
> diff --git a/hw/pci/msix.c b/hw/pci/msix.c
> index 0ec1cb1..6b8045a 100644
> --- a/hw/pci/msix.c
> +++ b/hw/pci/msix.c
> @@ -81,9 +81,11 @@ static bool msix_vector_masked(PCIDevice *dev, unsigned 
> int vector, bool fmask)
>  {
>  unsigned offset = vector * PCI_MSIX_ENTRY_SIZE;
>  uint8_t *data = >msix_table[offset + PCI_MSIX_ENTRY_DATA];
> +uint8_t *addr_lo = >msix_table[offset + PCI_MSIX_ENTRY_LOWER_ADDR];
>  /* MSIs on Xen can be remapped into pirqs. In those cases, masking
>   * and unmasking go through the PV evtchn path. */
> -if (xen_enabled() && xen_is_pirq_msi(pci_get_long(data))) {
> +if (xen_enabled() && xen_is_pirq_msi(pci_get_long(data),
> + pci_get_long(addr_lo))) {
>  return false;
>  }
>  return fmask || dev->msix_table[offset + PCI_MSIX_ENTRY_VECTOR_CTRL] &
> diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
> index 8b0d7fc..f799fed 100644
> --- a/hw/xen/xen_pt_msi.c
> +++ b/hw/xen/xen_pt_msi.c
> @@ -114,7 +114,7 @@ static int msi_msix_setup(XenPCIPassthroughState *s,
>  
>  assert((!is_msix && msix_entry == 0) || is_msix);
>  
> -if (xen_is_pirq_msi(data)) {
> +if (xen_is_pirq_msi(data, (uint32_t)(addr & 0x))) {

I don't think the cast is necessary. Also the & 0x is probably
not needed as well.

>  *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
>  if (!*ppirq) {
>  /* this probably identifies an misconfiguration of the guest,
> diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
> index a8f3afb..c15beb5 100644
> --- a/include/hw/xen/xen.h
> +++ b/include/hw/xen/xen.h
> @@ -33,7 +33,7 @@ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
>  void xen_piix3_set_irq(void *opaque, int irq_num, int level);
>  void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int 
> len);
>  void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
> -int xen_is_pirq_msi(uint32_t msi_data);
> +int xen_is_pirq_msi(uint32_t msi_data, uint32_t msi_addr_lo);
>  
>  qemu_irq *xen_interrupt_controller_init(void);
>  
> diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
> index c500325..dae421c 100644
> --- a/xen-hvm-stub.c
> +++ b/xen-hvm-stub.c
> @@ -31,7 +31,7 @@ void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
>  {
>  }
>  
> -int xen_is_pirq_msi(uint32_t msi_data)
> +int xen_is_pirq_msi(uint32_t msi_data, uint32_t msi_addr_lo)
>  {
>  return 0;
>  }
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 2f348ed..9e78b23 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -146,8 +146,13 @@ void xen_piix_pci_write_config_client(uint32_t address, 
> uint32_t val, int len)
>  }
>  }
>  
> -int xen_is_pirq_msi(uint32_t msi_data)
> +int xen_is_pirq_msi(uint32_t msi_data, uint32_t msi_addr_lo)
>  {
> +/* If msi address is configurate to remapping format, the msi will not
> + * remapped into a pirq.
> + */
> +if ( msi_addr_lo & 0x10 )

That's a magic number, is 0x10 MSI_ADDR_IM_MASK?

Thanks,

-- 
Anthony PERARD

Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.

This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
route such aborts back to the guest. If the guest PC had been
advanced by SVC/HVC/SMC instructions before we caught the SError
in hypervisor, we have to adjust the guest PC to exact address
while the SError generated.

About HSR_EC_SVC32/64, even thought we don't trap SVC32/64 today,
we would like them to be handled here. This would be useful when
VM introspection will gain support of SVC32/64 trapping.

This helper will be used by the later patches in this series, we
use #if 0 to disable it in this patch temporarily to remove the
warning message of unused function from compiler.

Signed-off-by: Wei Chen 
Acked-by: Stefano Stabellini 
---
v1->v2:
1. After updating HCR_EL2.VSE bit of vCPU HCR_EL2, write the value
   to HCR_EL2 immediately. In this case we don't need to move the
   restoration of HCR_EL2 to leave_hypervisor_tail, and it worked
   regardless of whether we get preempted.


This should have been explained in the commit message and ...


2. Add Stefano's Acked-by.


I would not keep Acked-by/Reviewed-by with a change like above. Or at 
least, I would ask whether they are fine with this change.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 05/19] xen/arm: Avoid setting/clearing HCR_RW at every context switch

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
DomU in vcpu_initialise, we didn't know the domain's address size
information. We had to use compatible flags to initialize HCR_EL2,
and set HCR_RW for 64-bit domain or clear HCR_RW for 32-bit domain
at every context switch.

But, after we added the HCR_EL2 to vcpu's context, this behaviour
seems a little fussy. We can update the HCR_RW bit in vcpu's context
as soon as we get the domain's address size to avoid setting/clearing
HCR_RW at every context switch.

Signed-off-by: Wei Chen 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/emul: Poision the stubs with debug traps

[Andrew Cooper]

On 30/03/17 13:08, Jan Beulich wrote:
 On 30.03.17 at 13:56,  wrote:
>> On 20/03/17 11:50, Jan Beulich wrote:
>> On 20.03.17 at 11:58,  wrote:
 ...rather than leaving fragments of old instructions in place.  This 
 reduces
 the chances of something going further-wrong (as the debug trap will be 
 caught
 and terminate the guest) in a cascade-failure where we end up executing the
 instruction fragments.

 Before:
 (XEN) d2v0 exception 6 (ec=) in emulation stub (line 6239)
 (XEN) d2v0 stub: c4 e1 44 77 c3 80 d0 82 ff ff ff d1 90 ec 90

 After:
 (XEN) d3v0 exception 6 (ec=) in emulation stub (line 6239)
 (XEN) d3v0 stub: c4 e1 44 77 c3 cc cc cc cc cc cc cc cc cc cc

 To make this work, the int3 handler needs to be extended to attempt 
 recovery
 rather than simply returning back to Xen context.  This is a good general
 precaution anyway, as nothing good will happen from letting Xen blindly
 execute over 0xcc's.
>>> I partly disagree: It can be a very useful thing to not have to rebuild
>>> Xen with hard coded INT3 invocations removed/re-added between
>>> runs with or without a debugger attached.
>> What possible usecase is this for?  If you don't already modify
>> do_int3(), use of embedded int3's are of no use.
> How are they not, with an external debugger attached? (I admit
> that I have no idea in what good or bad a state the external
> debugger support code is that we have.)

I have never succeeded at using the external debugger facilities, but I
have only tried once or twice.

If you do have an external debugger attached, you don't need embedded
int3's to start with, and you'd still hit the debugger_trap_*() calls
before dying.

If you don't have an external debugger attached, ignoring int3's is very
poor behaviour.  The fact that it ever worked is a bug IMO.

~Andrew

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

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de59e5f..8af223e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2171,6 +2171,13 @@ int construct_dom0(struct domain *d)
 return rc;

 /*
+ * The HCR_EL2 will temporarily switch to dom0's HCR_EL2 value
+ * by p2m_restore_state. We have to save HCR_EL2 to idle vCPU's
+ * context for restoring it in later.
+ */
+current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);


I don't understand why we care here. idle vCPU will never restore 
HCR_EL2 nor return from the hypervisor.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] 4.9.19 (and others) hang when running as a nested dom0

[George Dunlap]

On 30/03/17 17:53, Juergen Gross wrote:
> On 30/03/17 18:32, George Dunlap wrote:
>> I normally test CentOS using nested virtualization (mainly because
>> it's easy to restore the disk to a known state).  At some point in the
>> last six months this basically stopped working, as newer kernels (and
>> even backports) stopped booting properly under Xen.
>>
>> I've finally gotten around to building my own kernel outside of the
>> normal RPM / CentOS build system to reproduce the issue.
>>
>> I downloaded the 4.9.19 tarball and compiled under CentOS 6 with the
>> attached config.
>>
>> The console output for the VM when running as a simple domU is
>> attached as native-vm.console.
>>
>> Then console output when running with Xen inside the VM and the Linux
>> kernel as a dom0 inside that guest is attached as L1-dom0.console.
>> (That is, the dom0 for L1, as opposed to the dom0 for L0.  Not clear
>> how the terminology should apply here.)
>>
>> As you can see, native-vm boots to completion, whereas L1 hangs just
>> after deciding to use clocksource as the TSC.
>>
>> The guest appears to be mostly but not completely idle -- as one would
>> expect if dom0 just decided it didn't have anything to do.
>>
>> Any ideas on how to proceed?
> 
> Try upstream commit da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.

That seems to have done the trick, thanks!

 -George


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

Re: [Xen-devel] [PATCH v2 02/19] xen/arm: Remove vwfi while setting HCR_EL2 in init_traps

[Julien Grall]

Hi Wei,

On 30/03/17 10:13, Wei Chen wrote:

We will set HCR_EL2 for each domain individually at the place where each
domain is created. vwfi will affect the behavior of VM trap. Initialize
the HCR_EL2 in init_traps is a generic setting for AT translations while
creating dom0.


This statement looks wrong. Any AT s1s2 translations (i.e on behalf of 
the guest) should be done after a call to p2m_restore_state that restore 
HCR_EL2, SCTLR_EL1, VTTBR_EL1. If it is not the case, then there is an 
error.



After dom0 has been created, the HCR_EL2 will use the saved
value in dom0's context. So checking vwfi in init_trap is pointless.

Signed-off-by: Wei Chen 


This is a nack from me. We don't remove feature even temporarily without 
any strong reasons. This is making more difficult to track the history 
of a feature and a call to forget to restore it correctly later on or 
removing the feature if we ever decide to revert the patch which adds 
back the feature (see patch #4).


I would prefer to see patch #2, #3 squashed into #4, the patch will not 
be that big (50 lines) and avoid to drop a feature temporarily. But I am 
not convinced about your reasons.



---
I have tried to remove HCR_EL2 setting from init_traps, but the Xen will
hang at the place of creating domain0. The console hot key can work, so
the Xen is alive, not panic.


With the limited description you provided it is hard to know what's 
going on. In the future please try to provide meaningful details 
(platform used, debugging you have done...). Anyway, I have done some 
debug and I don't end up to the same conclusion as you.


I tried on different boards, and it gets stuck when initializing stage-2 
page table configuration on each CPU (see setup_virt_paging). The 
secondary CPUs don't receive the SGI.


Reading a bit more the ARM ARM (D7.2.33 in ARM DDI 0487A.k_iss10775), 
HCR_EL2 is unknown at reset. Whilst I already knew that, I would have 
expected to have no impact on EL2 (at least in the non-VHE case). 
However, the value of the {A,I,F}MO bits will affect the routing of 
physical IRQs to Xen.


I have only gone quickly through the spec, so it might be possible to 
have other necessary bits. It might be good to keep initialization here 
until someone sit in front of the spec for few hours and check everything.


So in this case I would prefer to keep the helper avoiding to have 
declared twice the same flags. Stefano any opinions?


Also, whilst I was debugging the problem I noticed the vwfi option does 
not work properly on CPU0. Indeed, the command line has not been parsed 
when init_traps is called on CPU0. This is should be fixed by patch #4 
in this series, but I don't think we want to backport it. Stefano, would 
you be up to write a patch for this?


Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

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

Last test of basis   106988  2017-03-30 03:47:11 Z0 days
Testing same since   106996  2017-03-30 09:09:57 Z0 days1 attempts


People who touched revisions under test:
  Qin Long 

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=f663ed8a328a6d5007d3f03685f08cfceb506105
+ . ./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 
f663ed8a328a6d5007d3f03685f08cfceb506105
+ branch=ovmf
+ revision=f663ed8a328a6d5007d3f03685f08cfceb506105
+ . ./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.8-testing
+ '[' xf663ed8a328a6d5007d3f03685f08cfceb506105 = 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
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] 4.9.19 (and others) hang when running as a nested dom0

[Juergen Gross]

On 30/03/17 18:32, George Dunlap wrote:
> I normally test CentOS using nested virtualization (mainly because
> it's easy to restore the disk to a known state).  At some point in the
> last six months this basically stopped working, as newer kernels (and
> even backports) stopped booting properly under Xen.
> 
> I've finally gotten around to building my own kernel outside of the
> normal RPM / CentOS build system to reproduce the issue.
> 
> I downloaded the 4.9.19 tarball and compiled under CentOS 6 with the
> attached config.
> 
> The console output for the VM when running as a simple domU is
> attached as native-vm.console.
> 
> Then console output when running with Xen inside the VM and the Linux
> kernel as a dom0 inside that guest is attached as L1-dom0.console.
> (That is, the dom0 for L1, as opposed to the dom0 for L0.  Not clear
> how the terminology should apply here.)
> 
> As you can see, native-vm boots to completion, whereas L1 hangs just
> after deciding to use clocksource as the TSC.
> 
> The guest appears to be mostly but not completely idle -- as one would
> expect if dom0 just decided it didn't have anything to do.
> 
> Any ideas on how to proceed?

Try upstream commit da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.


Juergen


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

Re: [Xen-devel] [RFC PATCH 3/4] xen-pt: bind/unbind interrupt remapping format MSI

[Anthony PERARD]

On Fri, Mar 17, 2017 at 07:29:16PM +0800, Lan Tianyu wrote:
> From: Chao Gao 
> 
> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
> format. The original code isn't suitable to the new format. A new pair
> bind/unbind interfaces are added for this usage. This patch recognizes
> this case and use new interfaces to bind/unbind msi.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  hw/xen/xen_pt_msi.c   | 36 
>  include/hw/i386/apic-msidef.h |  1 +
>  2 files changed, 29 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
> index 62add06..8b0d7fc 100644
> --- a/hw/xen/xen_pt_msi.c
> +++ b/hw/xen/xen_pt_msi.c
> @@ -161,6 +161,7 @@ static int msi_msix_update(XenPCIPassthroughState *s,
>  uint8_t gvec = msi_vector(data);
>  uint32_t gflags = msi_gflags(data, addr);
>  int rc = 0;
> +bool ir = !!(addr & MSI_ADDR_IM_MASK);
>  uint64_t table_addr = 0;
>  
>  XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
> @@ -171,8 +172,14 @@ static int msi_msix_update(XenPCIPassthroughState *s,
>  table_addr = s->msix->mmio_base_addr;
>  }
>  
> -rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
> +if (ir) {

You could maybe use add_ADDR_IM_MASK instead of going through a
variable.

> +rc = xc_domain_update_msi_irq_remapping(xen_xc, xen_domid, pirq,
> +d->devfn, data, addr, table_addr);

Do you also want to update the XEN_PT_LOG above? Since it does not
always reflect the update_msi call anymore.

> +}
> +else {
> +rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
>pirq, gflags, table_addr);
> +}
>  
>  if (rc) {
>  XEN_PT_ERR(d, "Updating of MSI%s failed. (err: %d)\n",
> @@ -204,13 +211,26 @@ static int msi_msix_disable(XenPCIPassthroughState *s,
>  }
>  
>  if (is_binded) {
> -XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
> -   is_msix ? "-X" : "", pirq, gvec);
> -rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
> -if (rc) {
> -XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: %d, 
> gvec: %#x)\n",
> -   is_msix ? "-X" : "", errno, pirq, gvec);
> -return rc;
> +if ( addr & MSI_ADDR_IM_MASK ) {
> +XEN_PT_LOG(d, "Unbinding of MSI%s . ( pirq: %d, data: %x, addr: 
> %lx)\n",

For addr, it should be PRIx64 instead of %lx.

> +   is_msix ? "-X" : "", pirq, data, addr);
> +rc = xc_domain_unbind_msi_irq_remapping(xen_xc, xen_domid, pirq,
> +d->devfn, data, addr);
> +if (rc) {
> +XEN_PT_ERR(d, "Unbinding of MSI%s . (error: %d, pirq: %d, 
> data: %x, addr: %lx)\n",
> +   is_msix ? "-X" : "", rc, pirq, data, addr);
> +return rc;
> +}
> +
> +} else {
> +XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
> +   is_msix ? "-X" : "", pirq, gvec);
> +rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, 
> gflags);
> +if (rc) {
> +XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: 
> %d, gvec: %#x)\n",
> +   is_msix ? "-X" : "", errno, pirq, gvec);
> +return rc;
> +}
>  }
>  }
>  
> diff --git a/include/hw/i386/apic-msidef.h b/include/hw/i386/apic-msidef.h
> index 8b4d4cc..08b584f 100644
> --- a/include/hw/i386/apic-msidef.h
> +++ b/include/hw/i386/apic-msidef.h
> @@ -27,5 +27,6 @@
>  #define MSI_ADDR_DEST_ID_SHIFT  12
>  #define MSI_ADDR_DEST_IDX_SHIFT 4
>  #define  MSI_ADDR_DEST_ID_MASK  0x000

Could you add a 0 to dest_id here? So their will be 8 digit and it those
not look weird when compared to the next define.

> +#define  MSI_ADDR_IM_MASK   0x0010

Is the definition of MSI_ADDR_IM_MASK available somewhere? In the Intel
SDM I've only found this bit to be reserved.

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v4 3/4] xenstore: rework of transaction handling

[Juergen Gross]

On 30/03/17 17:41, Wei Liu wrote:
> On Thu, Mar 30, 2017 at 03:11:48PM +0200, Juergen Gross wrote:
> [...]
>> +
>> +/*
>> + * A node has been accessed.
>> + *
>> + * Modifying accesses (write, delete) always update the generation (global 
>> and
>> + * node->generation).
>> + *
>> + * Accesses in a transaction will be added to the list of accessed nodes
>> + * if not already done. Read type accesses will copy the node to the
>> + * transaction specific data base part, write type accesses go there
>> + * anyway.
>> + *
>> + * If not NULL, key will be supplied with name and length of name of the 
>> node
>> + * to be accessed in the data base.
>> + */
>> +int access_node(struct connection *conn, struct node *node,
>> +enum node_access_type type, TDB_DATA *key)
>> +{
>> +struct accessed_node *i = NULL;
>>  struct transaction *trans;
>> +TDB_DATA local_key;
>> +const char *trans_name = NULL;
>> +int ret;
>> +bool introduce = false;
>>  
>> -if (!conn || !conn->transaction) {
>> +if (type != NODE_ACCESS_READ) {
>>  /* They're changing the global database. */
> 
> This comment should be moved below.

Right.

> 
>>  node->generation = generation++;
>> -return;
>> +if (conn && !conn->transaction)
>> +wrl_apply_debit_direct(conn);
>> +}
>> +
>> +if (!conn || !conn->transaction) {
>> +if (key)
>> +set_tdb_key(node->name, key);
>> +return 0;
>>  }
>>  
>>  trans = conn->transaction;
>>  
>> -node->generation = generation + trans->trans_gen++;
>> +trans_name = transaction_get_node_name(node, trans, node->name);
>> +if (!trans_name)
>> +goto nomem;
>>  
>> -list_for_each_entry(i, >changes, list) {
>> -if (streq(i->node, node->name)) {
>> -if (recurse)
>> -i->recurse = recurse;
>> -return;
>> -}
>> -}
>> -
>> -i = talloc(trans, struct changed_node);
>> +i = find_accessed_node(trans, node->name);
>>  if (!i) {
>> -/* All we can do is let the transaction fail. */
>> -generation++;
>> -return;
>> +i = talloc_zero(trans, struct accessed_node);
>> +if (!i)
>> +goto nomem;
>> +i->node = talloc_strdup(i, node->name);
>> +if (!i->node)
>> +goto nomem;
>> +
>> +introduce = true;
>> +i->ta_node = false;
>> +
>> +/* We have to verify read nodes only if we didn't write them. */
>> +if (type == NODE_ACCESS_READ) {
>> +i->generation = node->generation;
>> +i->check_gen = true;
>> +if (node->generation != NO_GENERATION) {
>> +set_tdb_key(trans_name, _key);
>> +ret = write_node_raw(conn, _key, node);
>> +if (ret)
>> +goto err;
>> +i->ta_node = true;
>> +}
>> +}
> 
> I think the current code structure is a bit confusing.
> 
> For write types, the call to write_node_raw is outside of this function
> but for read type it is inside this function.

This is due to the different purpose of write_node_raw() in both
cases:

In the read case we write an _additional_ node into the transaction,
while in the write case it is just the user's operation.

> 
>> +list_add_tail(>list, >accessed);
>>  }
>> -i->node = talloc_strdup(i, node->name);
>> -if (!i->node) {
>> -/* All we can do is let the transaction fail. */
>> -generation++;
>> +
>> +if (type != NODE_ACCESS_READ)
>> +i->modified = true;
>> +
>> +if (introduce && type == NODE_ACCESS_DELETE)
>> +/* Nothing to delete. */
>> +return -1;
>> +
>> +if (key) {
>> +set_tdb_key(trans_name, key);
>> +if (type == NODE_ACCESS_WRITE)
>> +i->ta_node = true;
>> +if (type == NODE_ACCESS_DELETE)
>> +i->ta_node = false;
> 
> The same caveat made me wonder if ta_node was really what it meant to
> be because I couldn't find where write_node_raw was.
> 
> Can I suggest you make them consistent? Either lift the write_node_raw
> for read to read_node or push down the write_node_raw in delete_node and
> write_node here?
> 
> If I misunderstand how this works, please tell me...

As I already said: in the read case writing the node is depending
on the context and lifting it up would seem rather strange: why
should reading a node contain a write_node_raw() call?

In the write case I believe we should keep write_node_raw() where
it belongs: in the appropriate function modifying the node.

All actions in access_node() are transaction specific and 

Re: [Xen-devel] [PATCH v3 6/9] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

[Wei Liu]

On Thu, Mar 30, 2017 at 08:57:05AM -0600, Jan Beulich wrote:
> >>> On 30.03.17 at 08:20,  wrote:
> > If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present
> > in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP.
> > By default, LMCE is not exposed to guest so as to keep the backwards 
> > migration
> > compatibility.
> > 
> > Signed-off-by: Haozhong Zhang 
> 
> Hypervisor side
> Reviewed-by: Jan Beulich 
> 
> For the tools side, doesn't the new HVM param need saving /
> restoring? If so an addition to the array in
> tools/libxc/xc_sr_save_x86_hvm.c:write_hvm_params() is going
> to be needed.
> 

Actually quite a few of HVM params are missing.  It works because libxl
actually sets them, I think.

Haozhong, the best way to check is to `xl migrate guest localhost`.

Wei.

> Jan
> 

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

[Xen-devel] [PATCH for-4.9 1/4] tools/libxc: Tolerate specific zero-content records in migration v2 streams

[Andrew Cooper]

The migration v2 save code was written to avoid sending data records with no
content, as such records serve no purpose but come with a performance hit.
The restore code sanity checks this expectation.

Under some circumstances (most notably, on AMD hardware with Debug Extensions,
and a PV guest kernel which is not using the feature), the save code would
generate a record with no content, which trips the sanity check in the restore
code.

As the stream is otherwise fine, tolerate these records and avoid failing the
migration.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
---
CC: Ian Jackson 
CC: Julien Grall 

This needs backporting to Xen 4.6, and fixes XEN-5
---
 tools/libxc/xc_sr_restore_x86_hvm.c | 25 ++---
 tools/libxc/xc_sr_restore_x86_pv.c  | 17 ++---
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c 
b/tools/libxc/xc_sr_restore_x86_hvm.c
index 49d22c7..1dca853 100644
--- a/tools/libxc/xc_sr_restore_x86_hvm.c
+++ b/tools/libxc/xc_sr_restore_x86_hvm.c
@@ -39,13 +39,32 @@ static int handle_hvm_params(struct xc_sr_context *ctx,
 unsigned int i;
 int rc;
 
-if ( rec->length < sizeof(*hdr)
- || rec->length < sizeof(*hdr) + hdr->count * sizeof(*entry) )
+if ( rec->length < sizeof(*hdr) )
 {
-ERROR("hvm_params record is too short");
+ERROR("HVM_PARAMS record truncated: length %u, header size %zu",
+  rec->length, sizeof(*hdr));
 return -1;
 }
 
+if ( rec->length != (sizeof(*hdr) + hdr->count * sizeof(*entry)) )
+{
+ERROR("HVM_PARAMS record truncated: header %zu, count %u, "
+  "expected len %zu, got %u",
+  sizeof(*hdr), hdr->count, hdr->count * sizeof(*entry),
+  rec->length);
+return -1;
+}
+
+/*
+ * Tolerate empty records.  Older sending sides used to accidentally
+ * generate them.
+ */
+if ( hdr->count == 0 )
+{
+DBGPRINTF("Skipping empty HVM_PARAMS record\n");
+return 0;
+}
+
 for ( i = 0; i < hdr->count; i++, entry++ )
 {
 switch ( entry->index )
diff --git a/tools/libxc/xc_sr_restore_x86_pv.c 
b/tools/libxc/xc_sr_restore_x86_pv.c
index bc604b3..50e25c1 100644
--- a/tools/libxc/xc_sr_restore_x86_pv.c
+++ b/tools/libxc/xc_sr_restore_x86_pv.c
@@ -753,15 +753,26 @@ static int handle_x86_pv_vcpu_blob(struct xc_sr_context 
*ctx,
 }
 
 /* Confirm that there is a complete header. */
-if ( rec->length <= sizeof(*vhdr) )
+if ( rec->length < sizeof(*vhdr) )
 {
-ERROR("%s record truncated: length %u, min %zu",
-  rec_name, rec->length, sizeof(*vhdr) + 1);
+ERROR("%s record truncated: length %u, header size %zu",
+  rec_name, rec->length, sizeof(*vhdr));
 goto out;
 }
 
 blobsz = rec->length - sizeof(*vhdr);
 
+/*
+ * Tolerate empty records.  Older sending sides used to accidentally
+ * generate them.
+ */
+if ( blobsz == 0 )
+{
+DBGPRINTF("Skipping empty %s record for vcpu %u\n",
+  rec_type_to_str(rec->type), vhdr->vcpu_id);
+goto out;
+}
+
 /* Check that the vcpu id is within range. */
 if ( vhdr->vcpu_id >= ctx->x86_pv.restore.nr_vcpus )
 {
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.9 3/4] tools/python: Adjust migration v2 library to warn about zero-content records

[Andrew Cooper]

These records shouldn't be in a stream, but accidentally are.  Warn about
them, but don't abort the verification.

While here, add a missing length check to the X86_PV_P2M_FRAMES record
checker.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
---
CC: Ian Jackson 
CC: Julien Grall 
---
 tools/python/xen/migration/libxc.py | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/tools/python/xen/migration/libxc.py 
b/tools/python/xen/migration/libxc.py
index 6fd3f6d..f24448a 100644
--- a/tools/python/xen/migration/libxc.py
+++ b/tools/python/xen/migration/libxc.py
@@ -312,6 +312,10 @@ class VerifyLibxc(VerifyBase):
 def verify_record_x86_pv_p2m_frames(self, content):
 """ x86 PV p2m frames record """
 
+if len(content) < 8:
+raise RecordError("x86_pv_p2m_frames: record length must be at"
+  " least 8 bytes long")
+
 if len(content) % 8 != 0:
 raise RecordError("Length expected to be a multiple of 8, not %d"
   % (len(content), ))
@@ -324,10 +328,14 @@ class VerifyLibxc(VerifyBase):
 """ Generic for all REC_TYPE_x86_pv_vcpu_{basic,extended,xsave,msrs} 
"""
 minsz = calcsize(X86_PV_VCPU_HDR_FORMAT)
 
-if len(content) <= minsz:
+if len(content) < minsz:
 raise RecordError("X86_PV_VCPU_%s record length must be at least 
%d"
   " bytes long" % (name, minsz))
 
+if len(content) == minsz:
+self.info("Warning: X86_PV_VCPU_%s record with zero content"
+  % (name, ))
+
 vcpuid, res1 = unpack(X86_PV_VCPU_HDR_FORMAT, content[:minsz])
 
 if res1 != 0:
@@ -385,6 +393,9 @@ class VerifyLibxc(VerifyBase):
 if rsvd != 0:
 raise RecordError("Reserved field not zero (0x%04x)" % (rsvd, ))
 
+if count == 0:
+self.info("Warning: HVM_PARAMS record with zero content")
+
 sz += count * calcsize(HVM_PARAMS_ENTRY_FORMAT)
 
 if len(content) != sz:
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.9 4/4] docs: Clarify the expected behaviour of zero-content records

[Andrew Cooper]

The sending side shouldn't send any data records which end up having zero
content, but the receiving side will need to tolerate such records for
compatibility purposes.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 docs/specs/libxc-migration-stream.pandoc | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/docs/specs/libxc-migration-stream.pandoc 
b/docs/specs/libxc-migration-stream.pandoc
index 31eba10..546baab 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -3,7 +3,7 @@
   Andrew Cooper <>
   Wen Congyang <>
   Yang Hongyang <>
-% Revision 1
+% Revision 2
 
 Introduction
 
@@ -631,6 +631,11 @@ The set of valid records depends on the guest architecture 
and type.  No
 assumptions should be made about the ordering or interleaving of
 independent records.  Record dependencies are noted below.
 
+Some records are used for signalling, and explicitly have zero length.  All
+other records contain data relevent to the migration.  Data records with no
+content should be elided on the source side, as they their presence serves no
+purpose, but result in extra work for the restore side.
+
 x86 PV Guest
 
 
@@ -719,3 +724,12 @@ restored.
 The image header may only be extended by _appending_ additional
 fields.  In particular, the `marker`, `id` and `version` fields must
 never change size or location.
+
+
+Errata
+==
+
+1. For compatibility with older code, the receving side of a stream should
+   tolerate and ignore variable sized records with zero content.  Xen releases
+   between 4.6 and 4.8 could end up generating valid HVM\_PARAMS or
+   X86\_PV\_VCPU\_{EXTENDED,XSAVE,MSRS} records with 0 content.
-- 
2.1.4


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