[Xen-devel] [xen-4.6-testing test] 65088: regressions - FAIL

[osstest service owner]

flight 65088 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65088/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail REGR. vs. 63449
 build-i3865 xen-buildfail in 65062 REGR. vs. 63449

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-startfail in 65062 pass in 65088
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 65062 pass in 65088
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 65062

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested 3 host-install(3) broken in 65062 baseline 
untested
 test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail in 65062 blocked in 63449

Tests which did not succeed, but are not blocking:
 build-i386-rumpuserxen1 build-check(1)blocked in 65062 n/a
 build-i386-libvirt1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-migrupgrade   1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-xl1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-libvirt   1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)  blocked in 65062 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)  blocked in 65062 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
65062 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-pair  1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)  blocked in 65062 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-xl-raw1 build-check(1)blocked in 65062 n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked in 65062 n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked in 65062 n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked in 65062 n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Jan Beulich]

>>> On 25.11.15 at 16:13,  wrote:
> On 25/11/15 10:49, Jan Beulich wrote:
> On 25.11.15 at 11:28,  wrote:
>>> On 24/11/15 17:41, Jan Beulich wrote:
>>> On 24.11.15 at 18:17,  wrote:
> --- a/xen/drivers/passthrough/vtd/quirks.c
> +++ b/xen/drivers/passthrough/vtd/quirks.c
> @@ -320,6 +320,20 @@ void __init platform_quirks_init(void)
>  /* Tylersburg interrupt remap quirk */
>  if ( iommu_intremap )
>  tylersburg_intremap_quirk();
> +
> +/*
> + * Disable shared EPT ("sharept") on Sandybridge and older processors
> + * by default.
> + * SandyBridge has no huge page support for IOTLB which leads to 
> fallback
> + * on 4k pages and leads to performance degradation.
> + *
> + * Shared EPT ("sharept") will be disabled only if user has not
> + * provided explicit choice on the command line thus 
> iommu_hap_pt_share 
> is
> + * at its initialized value of -1.
> + */
> +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F 
> ||
> +  boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == 
> -1) )
> +iommu_hap_pt_share = 0;
 If we really want to do this, then I think we should key this on
 EPT but not VT-d having 2M support, instead of on CPU models.
>>> This check is already performed by vtd_ept_page_compatible()
>> Yeah, I realized there would be such a check on the way home.
>>
>>> The problem is that SandyBridge IOMMUs advertise 2M support and do
>>> function with it, but cannot cache 2MB translations in the IOTLBs.
>>>
>>> As a result, attempting to use 2M translations causes substantially
>>> worse performance than 4K translations.
>> So commit message and comment should make this more explicit,
>> to avoid the impression "IOTLB" isn't just the relatively common
>> mis-naming of "IOMMU".
>>
>> Plus I guess the sharing won't need suppressing if !opt_hap_2mb?
>>
>> Further the model based check is relatively broad, and includes
>> Atoms (0x36 actually is one), which can't be considered "Sandybridge
>> or older" imo.
>>
>> And finally I'm not fully convinced using CPU model info to deduce
>> chipset behavior is entirely correct (albeit perhaps in practice it'll
>> be fine except maybe when running Xen itself virtualized).
> 
> What else would you suggest? I can't think of any better identifying
> information.

Chipset IDs / revisions?

Jan


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

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Malcolm Crossley]

On 25/11/15 15:38, Jan Beulich wrote:
 On 25.11.15 at 16:13,  wrote:
>> On 25/11/15 10:49, Jan Beulich wrote:
>> On 25.11.15 at 11:28,  wrote:
 On 24/11/15 17:41, Jan Beulich wrote:
 On 24.11.15 at 18:17,  wrote:
>> --- a/xen/drivers/passthrough/vtd/quirks.c
>> +++ b/xen/drivers/passthrough/vtd/quirks.c
>> @@ -320,6 +320,20 @@ void __init platform_quirks_init(void)
>>  /* Tylersburg interrupt remap quirk */
>>  if ( iommu_intremap )
>>  tylersburg_intremap_quirk();
>> +
>> +/*
>> + * Disable shared EPT ("sharept") on Sandybridge and older 
>> processors
>> + * by default.
>> + * SandyBridge has no huge page support for IOTLB which leads to 
>> fallback
>> + * on 4k pages and leads to performance degradation.
>> + *
>> + * Shared EPT ("sharept") will be disabled only if user has not
>> + * provided explicit choice on the command line thus 
>> iommu_hap_pt_share 
>> is
>> + * at its initialized value of -1.
>> + */
>> +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F 
>> ||
>> +  boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == 
>> -1) )
>> +iommu_hap_pt_share = 0;
> If we really want to do this, then I think we should key this on
> EPT but not VT-d having 2M support, instead of on CPU models.
 This check is already performed by vtd_ept_page_compatible()
>>> Yeah, I realized there would be such a check on the way home.
>>>
 The problem is that SandyBridge IOMMUs advertise 2M support and do
 function with it, but cannot cache 2MB translations in the IOTLBs.

 As a result, attempting to use 2M translations causes substantially
 worse performance than 4K translations.
>>> So commit message and comment should make this more explicit,
>>> to avoid the impression "IOTLB" isn't just the relatively common
>>> mis-naming of "IOMMU".
>>>
>>> Plus I guess the sharing won't need suppressing if !opt_hap_2mb?
>>>
>>> Further the model based check is relatively broad, and includes
>>> Atoms (0x36 actually is one), which can't be considered "Sandybridge
>>> or older" imo.
>>>
>>> And finally I'm not fully convinced using CPU model info to deduce
>>> chipset behavior is entirely correct (albeit perhaps in practice it'll
>>> be fine except maybe when running Xen itself virtualized).
>>
>> What else would you suggest? I can't think of any better identifying
>> information.
> 
> Chipset IDs / revisions?

In this case the IOMMU is integrated into the Sandybridge-EP processor itself.
Unfortunately there's no register to query the IOTLB configuration of the IOMMU
and so we're stuck identifying the via the processor model number itself.

Malcolm

> 
> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


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

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Boris Ostrovsky]

On 11/12/2015 08:43 AM, Juergen Gross wrote:

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.


This patch breaks 32-bit pygrub.

I am not 100% sure yet but it may be that only 64-bit guests are affected.

With RHEL5 I get
initrd extends beyond end of memory (0x780080eda000 > 0x4000)


-boris

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

[Xen-devel] [PATCH v4 4/4] Revert "libxc: create an initial FPU state for HVM guests"

[Roger Pau Monne]

This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad:

Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.

This was a stop-gap measure in order to unblock OSSTest Windows 7 failures
while a proper fix for the HVM CPU save/restore is being worked on.

This can now be reverted because a proper fix is in place and we can signal
in the save record whether the FPU is initialized or not.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Acked-by: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxc/xc_dom_x86.c | 38 --
 1 file changed, 38 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 5ff33ca..50cceee 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -910,27 +910,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
-/*
- * The layout of the fpu context structure is the same for
- * both 32 and 64 bits.
- */
-struct {
-uint16_t fcw;
-uint16_t fsw;
-uint8_t ftw;
-uint8_t rsvd1;
-uint16_t fop;
-union {
-uint64_t addr;
-struct {
-uint32_t offs;
-uint16_t sel;
-uint16_t rsvd;
-};
-} fip, fdp;
-uint32_t mxcsr;
-uint32_t mxcsr_mask;
-} *fpu_ctxt;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -998,23 +977,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 /* Set the control registers. */
 bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
 
-/*
- * XXX: Set initial FPU state.
- *
- * This should be removed once Xen is able to know if the
- * FPU state saved is valid or not, now Xen always sets
- * fpu_initialised to true regardless of the FPU state.
- *
- * The code below mimics the FPU sate after executing
- * fninit
- * ldmxcsr 0x1f80
- */
-fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
-
-fpu_ctxt->fcw = 0x37f;
-fpu_ctxt->ftw = 0xff;
-fpu_ctxt->mxcsr = 0x1f80;
-
 /* Set the IP. */
 bsp_ctx.cpu.rip = dom->parms.phys_entry;
 
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v4 3/4] xen/hvm: introduce a flags field in the CPU save record

[Roger Pau Monne]

Introduce a new flags field and use bit 0 to signal if the FPU has been
initialised or not. Previously Xen always wrongly assumed the FPU was
initialised on restore.

Signed-off-by: Roger Pau Monné 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v3:
 - Don't add a comment in the compat structure regaring the fpu_initialised
   field.
 - Rename fpu_initialised to flags and use it as a bit field. Bit 0 will be
   used to signal whether the fpu is initialised.
 - Only save the fpu context if it's initialised.
 - Only restore the fpu context from the save record if the fpu is
   initialised.
 - Check that unused bits in the flags field are 0.

Changes since v1:
 - Don't add yet another compat structure, new fields should always be added
   to the end of the existing structure and offsetof should be used to
   compare sizes.
 - Leave the previous compat structure as-is, since the field was not added
   to the end we cannot remove it and use offsetof in this case.
 - Set xstate_bv based on fpu_initialised value instead of unconditionally
   setting it to XSTATE_FP_SSE.
---
 xen/arch/x86/hvm/hvm.c | 20 +---
 xen/include/public/arch-x86/hvm/save.h | 27 ---
 2 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 141a130..d966074 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1798,8 +1798,7 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 
 if ( v->fpu_initialised )
 memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs));
-else 
-memset(ctxt.fpu_regs, 0, sizeof(ctxt.fpu_regs));
+ctxt.flags = v->fpu_initialised ? XEN_X86_FPU_INITIALISED : 0;
 
 ctxt.rax = v->arch.user_regs.eax;
 ctxt.rbx = v->arch.user_regs.ebx;
@@ -1979,7 +1978,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( hvm_load_entry(CPU, h, ) != 0 ) 
+if ( hvm_load_entry_zeroextend(CPU, h, ) != 0 )
 return -EINVAL;
 
 /* Sanity check some control registers. */
@@ -2007,6 +2006,13 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
+if ( (ctxt.flags & ~XEN_X86_FPU_INITIALISED) != 0 )
+{
+gprintk(XENLOG_ERR, "bad flags value in CPU context: %#x\n",
+ctxt.flags);
+return -EINVAL;
+}
+
 /* Older Xen versions used to save the segment arbytes directly 
  * from the VMCS on Intel hosts.  Detect this and rearrange them
  * into the struct segment_register format. */
@@ -2085,16 +2091,17 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 seg.attr.bytes = ctxt.ldtr_arbytes;
 hvm_set_segment_register(v, x86_seg_ldtr, );
 
+v->fpu_initialised = !!(ctxt.flags & XEN_X86_FPU_INITIALISED);
 /* In case xsave-absent save file is restored on a xsave-capable host */
-if ( cpu_has_xsave && !xsave_enabled(v) )
+if ( cpu_has_xsave && !xsave_enabled(v) && v->fpu_initialised )
 {
 struct xsave_struct *xsave_area = v->arch.xsave_area;
 
 memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
 xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
 }
-else
-memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
+else if ( v->fpu_initialised )
+memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
 
 v->arch.user_regs.eax = ctxt.rax;
 v->arch.user_regs.ebx = ctxt.rbx;
@@ -2122,7 +2129,6 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 v->arch.debugreg[7] = ctxt.dr7;
 
 v->arch.vgc_flags = VGCF_online;
-v->fpu_initialised = 1;
 
 /* Auxiliary processors should be woken immediately. */
 v->is_initialised = 1;
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index 29d513c..b6b1bf8 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -47,7 +47,9 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
 /*
  * Processor
  *
- * Compat: Pre-3.4 didn't have msr_tsc_aux
+ * Compat:
+ * - Pre-3.4 didn't have msr_tsc_aux
+ * - Pre-4.7 didn't have fpu_initialised
  */
 
 struct hvm_hw_cpu {
@@ -157,6 +159,10 @@ struct hvm_hw_cpu {
 };
 /* error code for pending event */
 uint32_t error_code;
+
+#define _XEN_X86_FPU_INITIALISED0
+#define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
+uint32_t flags;
 };
 
 struct hvm_hw_cpu_compat {
@@ -275,12 +281,19 @@ static inline int _hvm_hw_fix_cpu(void *h, uint32_t size) 
{
 struct hvm_hw_cpu_compat cmp;
 } *ucpu = (union hvm_hw_cpu_union *)h;
 
-/* If we copy from the end backwards, we should
- * 

[Xen-devel] [PATCH v4 0/4] Introduce a flags field to HVM CPU context

[Roger Pau Monne]

Hello,

This patch series tries to properly solve the problem seen with the HVMlite 
series, that Xen always assumes the FPU is initialised on CPU context 
restore.

Roger.

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

Re: [Xen-devel] [RFC 1/1] xen: block: correct setting for xen_blkif_max_ring_order

[Konrad Rzeszutek Wilk]

On Wed, Nov 25, 2015 at 06:26:01PM +0800, Peng Fan wrote:
> According to this piece code:
> "
>  pr_info("Invalid max_ring_order (%d), will use default max: %d.\n",
>   xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);
> "
> if xen_blkif_max_ring_order is bigger that XENBUS_MAX_RING_GRANT_ORDER,
> need to set xen_blkif_max_ring_order using XENBUS_MAX_RING_GRANT_ORDER,
> but not 0.
> 
> Signed-off-by: Peng Fan 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: "Roger Pau Monné" 
> ---
> 
> Hi,
> 
> I am new to xen and reading related soure code, not sure whether
> this is correct. Please comments.

Applied to 'devel/for-jens-4.5'.

Thanks!
> 
> Thanks
> 
>  drivers/block/xen-blkfront.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 0823a96..883b9fa 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2126,7 +2126,7 @@ static int __init xlblk_init(void)
>   if (xen_blkif_max_ring_order > XENBUS_MAX_RING_PAGE_ORDER) {
>   pr_info("Invalid max_ring_order (%d), will use default max: 
> %d.\n",
>   xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
> - xen_blkif_max_ring_order = 0;
> + xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
>   }
>  
>   if (!xen_has_pv_disk_devices())
> -- 
> 2.6.2
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  2a91f05083c33f69d19ec3ee037b4536f9dd4516
baseline version:
 xen  7d596f5ad70969d8171e1eb5b7a39d0dc6c11dc2

Last test of basis65104  2015-11-25 11:01:34 Z0 days
Testing same since65108  2015-11-25 13:58:43 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Jan Beulich 
  Julien Grall 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2a91f05083c33f69d19ec3ee037b4536f9dd4516
+ . ./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 
2a91f05083c33f69d19ec3ee037b4536f9dd4516
+ branch=xen-unstable-smoke
+ revision=2a91f05083c33f69d19ec3ee037b4536f9dd4516
+ . ./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-unstable
+ '[' x2a91f05083c33f69d19ec3ee037b4536f9dd4516 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;

[Xen-devel] [PATCH v1 1/2] libxl: re-name libxl__xs_write() to libxl__xs_printf()...

[Paul Durrant]

...to denote what it actually does.

The name libxl__xs_write() suggests something taking a buffer and length,
akin to write(2), whereas the semantics of the function are actually more
akin to printf(3).

This patch is a textual substitution of libxl__xs_write with
libxl__xs_printf with some associated formatting fixes.

Signed-off-by: Paul Durrant 
Acked-by: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl.c| 47 +-
 tools/libxl/libxl_bootloader.c |  4 ++--
 tools/libxl/libxl_create.c |  4 ++--
 tools/libxl/libxl_dm.c | 36 
 tools/libxl/libxl_dom.c| 23 +++--
 tools/libxl/libxl_exec.c   |  2 +-
 tools/libxl/libxl_genid.c  |  6 +++---
 tools/libxl/libxl_internal.h   |  4 ++--
 tools/libxl/libxl_pci.c| 22 ++--
 tools/libxl/libxl_qmp.c|  4 ++--
 tools/libxl/libxl_xshelp.c |  4 ++--
 11 files changed, 79 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bd3aac8..bd604ac 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1136,7 +1136,7 @@ int libxl__domain_pvcontrol_write(libxl__gc *gc, 
xs_transaction_t t,
 if (!shutdown_path)
 return ERROR_FAIL;
 
-return libxl__xs_write(gc, t, shutdown_path, "%s", cmd);
+return libxl__xs_printf(gc, t, shutdown_path, "%s", cmd);
 }
 
 static int libxl__domain_pvcontrol(libxl__gc *gc, uint32_t domid,
@@ -1364,7 +1364,7 @@ static void disk_eject_xswatch_callback(libxl__egc *egc, 
libxl__ev_xswatch *w,
 if (!value || strcmp(value,  "eject"))
 return;
 
-if (libxl__xs_write(gc, XBT_NULL, wpath, "")) {
+if (libxl__xs_printf(gc, XBT_NULL, wpath, "")) {
 LIBXL__EVENT_DISASTER(egc, "xs_write failed acknowledging eject",
   errno, LIBXL_EVENT_TYPE_DISK_EJECT);
 return;
@@ -4696,13 +4696,13 @@ retry_transaction:
 goto out;
 
 if (target == NULL) {
-libxl__xs_write(gc, t, target_path, "%"PRIu32,
-(uint32_t) info.current_memkb);
+libxl__xs_printf(gc, t, target_path, "%"PRIu32,
+ (uint32_t) info.current_memkb);
 *target_memkb = (uint32_t) info.current_memkb;
 }
 if (staticmax == NULL) {
-libxl__xs_write(gc, t, max_path, "%"PRIu32,
-(uint32_t) info.max_memkb);
+libxl__xs_printf(gc, t, max_path, "%"PRIu32,
+ (uint32_t) info.max_memkb);
 *max_memkb = (uint32_t) info.max_memkb;
 }
 
@@ -4839,8 +4839,8 @@ retry_transaction:
 goto out;
 }
 
-libxl__xs_write(gc, t, GCSPRINTF("%s/memory/target",
-dompath), "%"PRIu32, new_target_memkb);
+libxl__xs_printf(gc, t, GCSPRINTF("%s/memory/target", dompath),
+ "%"PRIu32, new_target_memkb);
 rc = xc_domain_getinfolist(ctx->xch, domid, 1, );
 if (rc != 1 || info.domain != domid) {
 abort_transaction = 1;
@@ -4850,8 +4850,8 @@ retry_transaction:
 libxl_dominfo_init();
 xcinfo2xlinfo(ctx, , );
 uuid = libxl__uuid2string(gc, ptr.uuid);
-libxl__xs_write(gc, t, GCSPRINTF("/vm/%s/memory", uuid),
-"%"PRIu32, new_target_memkb / 1024);
+libxl__xs_printf(gc, t, GCSPRINTF("/vm/%s/memory", uuid),
+ "%"PRIu32, new_target_memkb / 1024);
 libxl_dominfo_dispose();
 
 out:
@@ -5486,9 +5486,9 @@ static int libxl__set_vcpuonline_xenstore(libxl__gc *gc, 
uint32_t domid,
 retry_transaction:
 t = xs_transaction_start(CTX->xsh);
 for (i = 0; i <= info->vcpu_max_id; i++)
-libxl__xs_write(gc, t,
-   GCSPRINTF("%s/cpu/%u/availability", dompath, i),
-   "%s", libxl_bitmap_test(cpumap, i) ? "online" : 
"offline");
+libxl__xs_printf(gc, t,
+ GCSPRINTF("%s/cpu/%u/availability", dompath, i),
+ "%s", libxl_bitmap_test(cpumap, i) ? "online" : 
"offline");
 if (!xs_transaction_end(CTX->xsh, t, 0)) {
 if (errno == EAGAIN)
 goto retry_transaction;
@@ -5984,7 +5984,8 @@ int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char 
sysrq)
 GC_INIT(ctx);
 char *dompath = libxl__xs_get_dompath(gc, domid);
 
-libxl__xs_write(gc, XBT_NULL, GCSPRINTF("%s/control/sysrq", dompath), 
"%c", sysrq);
+libxl__xs_printf(gc, XBT_NULL, GCSPRINTF("%s/control/sysrq", dompath),
+ "%c", sysrq);
 
 GC_FREE;
 return 0;
@@ -6262,12 +6263,12 @@ int libxl_cpupool_create(libxl_ctx *ctx, const char 
*name,
 t = xs_transaction_start(ctx->xsh);
 
 xs_mkdir(ctx->xsh, t, GCSPRINTF("/local/pool/%d", *poolid));
-libxl__xs_write(gc, t,
-

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Wei Liu]

On Wed, Nov 25, 2015 at 04:29:13PM +, Ian Campbell wrote:
> On Wed, 2015-11-25 at 16:18 +, Wei Liu wrote:
> > On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
> > > On 11/12/2015 08:43 AM, Juergen Gross wrote:
> > > > In case the kernel of a new pv-domU indicates it is supporting an
> > > > unmapped initrd, don't waste precious virtual space for the initrd,
> > > > but allocate only guest physical memory for it.
> > > 
> > > This patch breaks 32-bit pygrub.
> > > 
> > 
> > This particular patch?
> > 
> > We discovered a bug in mini-os that caused 32-bit pygrub to break withi
> > this series. It's now fixed in mini-os upstream.  Check Config.mk for
> > mini-os commit that fixes the bug.
> 
> Are we really talking about pygrub here, or pvgrub? (the former is
> unaffected by mini-os).
> 

Duh! I misread again.

Boris, can you clarify this?

> If we are really talking about pygrub then we are _actually_ talking about
> the domain builder when operating on the RHEL5 kernel+initrd -- the fact
> ithat they were extracted from the guest filesystem by pygrub is
> irrelevant.
> 
> > > With RHEL5 I get
> > > initrd extends beyond end of memory (0x780080eda000 > 0x4000)
> 
> This is reported within the guest, right?
> 
> Ian.

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

[Xen-devel] [PATCH] xen/arm: implement GICD_ICACTIVER read/write

[Stefano Stabellini]

Implement GICD_ICACTIVER and GICD_ISACTIVER reads by looking for the
GIC_IRQ_GUEST_ACTIVE bit in the relevant struct pending_irq. However
given that the pending to active transaction for irqs in LRs in done in
hardware, the GIC_IRQ_GUEST_ACTIVE bit might be out of date. We'll have
to live with that.

Implement GICD_ICACTIVER writes by checking the state of the irq in our
queues: if the irq is present in an LR, remove the hardware ACTIVE bit.
If the irq is present in an LR of another vcpu, send an IPI. Set the
GIC_IRQ_GUEST_DEACTIVATE bit to tell the receiving vcpu that the active
bit needs to be deactivated.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/gic.c |   40 +++
 xen/arch/arm/vgic-v2.c |   45 ++--
 xen/arch/arm/vgic-v3.c |   44 ++-
 xen/include/asm-arm/gic.h  |1 +
 xen/include/asm-arm/vgic.h |4 
 5 files changed, 123 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1e1e5ba..75c1f52 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -414,6 +414,15 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 gic_hw_ops->read_lr(i, _val);
 irq = lr_val.virq;
 p = irq_to_pending(v, irq);
+
+if ( test_and_clear_bit(GIC_IRQ_GUEST_DEACTIVATE, >status) &&
+ (lr_val.state & GICH_LR_ACTIVE) )
+{
+clear_bit(GIC_IRQ_GUEST_ACTIVE, >status);
+lr_val.state &= ~GICH_LR_ACTIVE;
+gic_hw_ops->write_lr(i, _val);
+}
+
 if ( lr_val.state & GICH_LR_ACTIVE )
 {
 set_bit(GIC_IRQ_GUEST_ACTIVE, >status);
@@ -489,6 +498,37 @@ void gic_clear_lrs(struct vcpu *v)
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
 }
 
+/* called with rank lock held */
+void gic_deactivate_irq(struct vcpu *v, unsigned int irq)
+{
+unsigned long flags;
+struct pending_irq *p;
+struct vcpu *v_target = v->domain->arch.vgic.handler->get_target_vcpu(v, 
irq);
+
+spin_lock_irqsave(_target->arch.vgic.lock, flags);
+
+p = irq_to_pending(v_target, irq);
+/* the interrupt is not even in an LR */
+if ( list_empty(>inflight) || !list_empty(>lr_queue) )
+{
+spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
+return;
+}
+
+/* it is in an LR, let's check */
+set_bit(GIC_IRQ_GUEST_DEACTIVATE, >status);
+if ( v_target == current )
+{
+gic_update_one_lr(v_target, p->lr);
+spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
+} else {
+spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
+vcpu_unblock(v_target);
+if (v_target->is_running )
+smp_send_event_check_mask(cpumask_of(v_target->processor));
+}
+}
+
 static void gic_restore_pending_irqs(struct vcpu *v)
 {
 int lr = 0;
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index f7d784b..9042062 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -126,8 +126,31 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 /* Read the active status of an IRQ via GICD is not supported */
 case GICD_ISACTIVER ... GICD_ISACTIVERN:
 case GICD_ICACTIVER ... GICD_ICACTIVERN:
-goto read_as_zero;
-
+{
+unsigned int i = 0, irq = 0;
+struct pending_irq *p;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+rank = vgic_rank_offset(v, 1, gicd_reg - GICD_ICACTIVER, DABT_WORD);
+if ( rank == NULL) goto read_as_zero;
+vgic_lock_rank(v, rank, flags);
+*r = 0;
+irq = (gicd_reg - GICD_ICACTIVER) << 3;
+for (i = 0; i < 32; i++)
+{
+p = irq_to_pending(v, i + irq);
+/*
+ * This information is likely out of date because we don't
+ * actually know which interrupts have become ACTIVE from
+ * PENDING in the LRs of other processors at it happens
+ * transparently in hardware.  We would have to interrupt
+ * all other running vcpus to get an accurate snapshot.
+ * Let's not do that.
+ */
+*r |= test_bit(GIC_IRQ_GUEST_ACTIVE, >status) ? (1 << i) : 0;
+}
+vgic_unlock_rank(v, rank, flags);
+return 1;
+}
 case GICD_ITARGETSR ... GICD_ITARGETSRN:
 if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto bad_width;
 rank = vgic_rank_offset(v, 8, gicd_reg - GICD_ITARGETSR, DABT_WORD);
@@ -332,11 +355,21 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 return 0;
 
 case GICD_ICACTIVER ... GICD_ICACTIVERN:
+{
+unsigned int i = 0, irq;
 if ( dabt.size != DABT_WORD ) goto bad_width;
-printk(XENLOG_G_ERR
-   "%pv: vGICD: unhandled word write %#"PRIregister" to 
ICACTIVER%d\n",
-   v, r, gicd_reg - 

[Xen-devel] [PATCH] build: fix dependencies for files compiled from their parent directory

[Jan Beulich]

The use of $(basename ...) here was wrong (yet I'm sure I tested it).

Signed-off-by: Jan Beulich 

--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -105,7 +105,7 @@ include Makefile
 DEPS = .*.d
 define gendep
 ifneq ($(1),$(subst /,:,$(1)))
-DEPS += $(dir $(1)).$(basename $(notdir $(1))).d
+DEPS += $(dir $(1)).$(notdir $(1)).d
 endif
 endef
 $(foreach o,$(filter-out %/,$(obj-y)),$(eval $(call gendep,$(o




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

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Boris Ostrovsky]

On 11/25/2015 11:29 AM, Ian Campbell wrote:

On Wed, 2015-11-25 at 16:18 +, Wei Liu wrote:

On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:

On 11/12/2015 08:43 AM, Juergen Gross wrote:

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.

This patch breaks 32-bit pygrub.


This particular patch?

We discovered a bug in mini-os that caused 32-bit pygrub to break withi
this series. It's now fixed in mini-os upstream.  Check Config.mk for
mini-os commit that fixes the bug.

Are we really talking about pygrub here, or pvgrub? (the former is
unaffected by mini-os).


That's exactly what confused me into thinking earlier that the fix that 
Wei is talking about would resolve my problem.


It's pYgrub.



If we are really talking about pygrub then we are _actually_ talking about
the domain builder when operating on the RHEL5 kernel+initrd -- the fact
ithat they were extracted from the guest filesystem by pygrub is
irrelevant.


With RHEL5 I get
  initrd extends beyond end of memory (0x780080eda000 > 0x4000)

This is reported within the guest, right?



Right. I don't have RHEL5 sources to see what exactly the code is doing 
but if it prints what it says it does ;-) then the address looks pretty 
bogus.


-boris

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

Re: [Xen-devel] [PATCH] libxl: Introduce a template for devices with a controller

[George Dunlap]

On Wed, Nov 25, 2015 at 3:11 AM, Chun Yan Liu  wrote:
>
>
 On 11/24/2015 at 10:40 PM, in message
> <1448376011-20217-1-git-send-email-george.dun...@eu.citrix.com>, George Dunlap
>  wrote:
>> We have several outstanding patch series which add devices that have
>> two levels: a controller and individual devices attached to that
>> controller.
>>
>> In the interest of consistency, this patch introduces a section that
>> sketches out a template for interfaces for such devices.
>
> Some typos. Otherwise, agreed.

Thanks.  If I fix the typos you've pointed out, can I add your Acked-by? :-)

 -George


>
> - Chunyan
>
>>
>> Signed-off-by: George Dunlap 
>> ---
>> CC: Ian Campbell 
>> CC: Ian Jackson 
>> CC: Wei Liu 
>> CC: Juergen Gross 
>> CC: Chun Yan Liu 
>> CC: Olaf Hering 
>>
>> Changes in v1 (since the RFC):
>>
>> - Use  rather than , and  rather than specifying
>>   controller and device.  The idea being to allow SCSI to use
>>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun)
>>   rather than naming things after USB (controller & device).
>>
>> - Do not require each  to have a deviceid, but just a unique
>>   naming schema.
>>
>> - Allow multiple levels.
>>
>> - Include the paragraph about domain configuration lists.
>> ---
>>  tools/libxl/libxl.h | 65
>> +
>>  1 file changed, 65 insertions(+)
>>
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index 6b73848..46bcfe8 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int
>> nr_vtpms);
>>   *
>>   *   This function does not interact with the guest and therefore
>>   *   cannot block on the guest.
>> + *
>> + * Controllers
>> + * ---
>> + *
>> + * Most devices are treated individually.  Some classes of device,
>> + * however, like USB or SCSI, inherently have the need to have a
>> + * heiarchy of different levels, with lower-level devices "attached"
>> + * to higher-level ones.  USB for instance has "controllers" at the
>> + * top, which have busses, on which are devices, which consist of
>> + * multiple interfaces.  SCSI has "hosts" at the top, then busses,
>> + * targets, and LUNs.
>> + *
>> + * In that case, for each , there will be a set of funcitons
>   
>   ^^^ functions
>> + * and types for each .  For example, for =usb, there
>> + * may be  ctrl (controller) and dev (device), with ctrl being
>> + * level 0.
>> + *
>> + * libxl_device__ will act more or
>> + * less like top-level non-bus devices: they will either create or
>> + * accept a libxl_devid which will be unique within the
>> + *  libxl_devid namespace.
>   ?
>> + *
>> + * Lower-level devices must have a unique way to be identified.  One
>> + * way to do this would be to name it via the name of the next level
>> + * up plus an index; for instance, .  Another
>> + * way would be to have another devid namespace for that level.  This
>> + * identifier will be used for queries and removals.
>> + *
>> + * Lower-level devices will will include in their
>   ^ s/will will/will/
>> + * libxl_device_ struct a field referring to the unique
>> + * index of the level above.  For instance, libxl_device_usbdev might
>> + * contain the controller devid.
>> + *
>> + * In the case where there are multiple different ways to implement a
>> + * given device -- for instance, one which is fully PV and one which
>> + * uses an emulator -- the controller will contain a field which
>> + * specifies what type of implementation is used.  The implementations
>> + * of individual devices will be known by the controller to which they
>> + * are attached.
>> + *
>> + * If libxl_device__add receives an empty reference to
>> + * the level above, it may return an error.  Or it may (but is not
>> + * required to) automatically choose a suitable device in the level
>> + * above to which to attach the new device at this level.  It may also
>> + * (but is not required to) automatically create a new device at the
>> + * level above if no suitable devices exist.  Each class should
>> + * document its behavior.
>> + *
>> + * libxl_device__list will list all devices of 
>> + * at  in the domain.  For example, libxl_class_usbctrl_list
>   
> libxl_device_usbctrl_list
>> + * will list all usb controllers; libxl_class_usbdev_list will list
>libxl_device_usbdev_list
>> + * all usb devices across all controllers.
>> + *
>> + * For each class, the domain config file will contain a single list
>> + * for each level.  libxl will first 

Re: [Xen-devel] [osstest test] 64958: regressions - trouble: broken/fail/pass

[Ian Campbell]

On Wed, 2015-11-25 at 14:37 +, Ian Campbell wrote:
> 2015-11-21 23:06:44 Z executing ssh ... root@172.16.144.44 virsh 
> domxml-from-native xen-xl /etc/xen/debian.jessie.guest.osstest.cfg > 
> /etc/xen/debian.jessie.guest.osstest.cfg.xml 
> error: An error occurred, but the cause is unknown

This turned out to be the check of vcpus vs MAX_VIRT_CPUS in
xenParseCPUFeatures. 

MAX_VIRT_CPUS is defined (by libvirt) as XEN_LEGACY_MAX_VCPUS, which is
mostly wrong on x86 (which supports more than that for guests using vcpu
placement) but is very wrong on ARM where we insist on vcpu placement and
XEN_LEGACY_MAX_VCPUS is therefore 1.

This test was trying to create a 2 cpu guest.

Since this check is in xen_common.c I think it might take a little
unravelling to fix this, since it seems to have lead to various other
assumptions to do with CPU masks fitting into an unsigned long in the
libvirt code base.

/me rolls up sleeves.

Ian.

> 
> This was always masked before now because when running with Wheezy
> osstest
> failed to find a suitable kernel+initramfs before this point.
> 
> http://logs.test-lab.xenproject.org/osstest/logs/64958/test-armhf-armhf-l
> ibvirt-qcow2/arndale-metrocentre---var-log-libvirt-libvirtd.log.gz
> just has:
> 
> 2015-11-21 23:06:44.686+: 1648: debug :
> virConnectDomainXMLFromNative:2626 : conn=0xb4000598, format=xen-xl,
> config=name= 'debian.jessie.guest.osstest'
> memory = 512
> vif = [ 'mac=5a:36:0e:be:00:09' ]
> #
> on_poweroff = 'preserve'
> on_reboot   = 'restart'
> on_crash= 'preserve'
> #
> vcpus = 2
> #
> kernel  = "/root/64958-test-armhf-armhf-libvirt-qcow2-
> di/kernel_jessie_armhf"
> ramdisk = "/root/64958-test-armhf-armhf-libvirt-qcow2-
> di/ramdisk_jessie_armhf"
> 
> extra   = "debian-installer/exit/poweroff=true domain=test-
> lab.xenproject.org console=hvc0 auto=true preseed hw-
> detect/load_firmware=false DEBCONF_DEBUG=5 DEBIAN_FRONTEND=text
> hostname=debian.jessie.guest.osstest url=osstest.test-
> lab.xenproject.org/~osstest/osstest/arndale-
> metrocentre_debian.jessie.guest.osstest_preseed netcfg/dhcp_timeout=150
> netcfg/choose_interface=auto -- console=hvc0"
> #
> disk= [
>  'format=qcow2,vdev=xvda,target=/var/lib/xen/images/debia
> n/disk.qcow2'
> ]
> 
> #
> 
> , flags=0
> 
> and seemingly no information on the mysterious failure. The config looks
> perfectly find to me (and FWIW xl create likes it just fine)
> 
> I'll dig in but I wondered if you had any pointers, to either what might
> be
> failing or why the error reporting seems to not filter through.
> 
> Cheers,
> Ian.
> 
> >  test-armhf-armhf-xl-credit2  13 saverestore-support-
> > checkfail   never pass
> >  test-armhf-armhf-xl-credit2  12 migrate-support-
> > checkfail   never pass
> >  test-armhf-armhf-xl-vhd  11 migrate-support-
> > checkfail   never pass
> >  test-armhf-armhf-xl-vhd  12 saverestore-support-
> > checkfail   never pass
> >  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-
> > check fail never pass
> >  test-amd64-i386-libvirt  12 migrate-support-
> > checkfail   never pass
> > 
> > version targeted for testing:
> >  osstest  2b83c10eb530fbd6a501717deb5aac1beff0cf80
> > baseline version:
> >  osstest  b0c5663a03e7ad679841dea72785db4ca981efe8
> > 
> > Last test of basis64659  2015-11-18 01:58:35 Z4 days
> > Testing same since64958  2015-11-20 15:06:13 Z1 days1
> > attempts
> > 
> > jobs:
> >  build-amd64-xsm  pass
> >  build-armhf-xsm  pass
> >  build-i386-xsm   pass
> >  build-amd64  pass
> >  build-armhf  pass
> >  build-i386   pass
> >  build-amd64-libvirt  pass
> >  build-armhf-libvirt  pass
> >  build-i386-libvirt   pass
> >  build-amd64-pvopspass
> >  build-armhf-pvopspass
> >  build-i386-pvops pass
> >  build-amd64-rumpuserxen  pass
> >  build-i386-rumpuserxen   pass
> >  test-amd64-amd64-xl  pass
> >  test-armhf-armhf-xl  pass
> >  test-amd64-i386-xl   pass
> >  test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
> >  

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Boris Ostrovsky]

On 11/25/2015 11:18 AM, Wei Liu wrote:

On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:

On 11/12/2015 08:43 AM, Juergen Gross wrote:

In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.

This patch breaks 32-bit pygrub.


This particular patch?

We discovered a bug in mini-os that caused 32-bit pygrub to break withi
this series. It's now fixed in mini-os upstream.  Check Config.mk for
mini-os commit that fixes the bug.


Yes, I was waiting for that patch because somehow I thought it was going 
to fix this. And it was unrelated.





I am not 100% sure yet but it may be that only 64-bit guests are affected.

With RHEL5 I get
 initrd extends beyond end of memory (0x780080eda000 > 0x4000)


But this is different from what we found. We need more information.

My wild guess is RHEL5 advertise it supports unmapped initrd but it was
buggy in some way.


Maybe. Unfortunately RHEL5 is the only guest I have available to me 
right now that I can test with pygrub on 32 bit. I have others and they 
also fail but I am not convinced they fail because of this issue.


I was going to look some more at this but I am not sure how much I will 
be able to do before next Monday (it's Thanksgiving 4-day weekend in US) 
so I figured I'd post this now.


-boris

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

Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Jan Beulich]

>>> On 25.11.15 at 14:07,  wrote:

>> On Nov 25, 2015, at 2:58 AM, Jan Beulich  wrote:
>> 
> On 24.11.15 at 19:19,  wrote:
>> 
 On Nov 24, 2015, at 11:30 AM, Jan Beulich  wrote:
 
>>> On 24.11.15 at 18:22,  wrote:
 
>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>  wrote:
>> 
>> So, the files in xen/ were the dependencies files for xen.efi and 
>> xen-syms that were getting left behind. $(DEPS) appears to always
>> have ‘.*.d’ in it, based on me putting an echo into the clean rule to 
>> print it out. However, looking at this, I am also seeing ‘.d’ files left
>> behind in xen/common/compat that I did not notice before.
> 
> Actually, looking closer at it, xen/common/compat does not appear to be
> cleaning at all, so I think that is a separate, unrelated issue.
 
 That would be quite related, as it would be a result of the same
 commit.
>>> 
>>> Yeah, I now see where that change got introduced. I don’t see a clear way 
>>> of 
> 
>>> cleaning
>>> those objects files since the build system no longer goes into the 
>>> common/compat directory at
>>> all. The existing clean rules walk all of the subdirectories, cleaning 
>>> object files and dependency
>>> files as it goes. 
>> 
>> But wouldn't the way DEPS gets populated in xen/Rules.mk cover for
>> this? If so, the alternative to your original patch might be to simply
>> rm those ..xen*.o.d files right in the $(TARGET)-syms and
>> $(TARGET).efi rules (along with their corresponding
>> $(@D)/.$(@F).[0-9]* getting removed, due to which those .o.d
>> ones are of no use anyway). Or maybe it should really do both,
>> considering that *.o get removed by _clean too.
>> 
> 
> So, I think we are talking a bit at cross purposes here. There are two
> problems as I see it:
> 
> 1. Dependency files get left in the xen/ directory for xen and xen-syms.
> Those dependency files just started appearing in the xen/ directory when
> the dependency generation was redone and the clean rule for the 
> top-level directory did not handle cleaning dependency files in the 
> top-level, because it has no source files. That is what my patch was
> specifically aiming at fixing. The way DEPS gets populated in xen/Rules.mk
> does cover it, but since DEPS was never in that top-level directory, it 
> wasn’t clearing the dep files that were left in that directory.
> 
> However, you could make the argument that the real problem is that the 
> dependency files are being dropped in that directory in the first place. 

Even if the rule deleted them, a failed or interrupted build could
leave them there. I'll therefore apply your patch as is.

> 2. The xen/common/compat directory is not being cleaned at all, although
> there are .o and .o.d files left in that directory. My patch does not handle 
> that
> and was never meant to handle that. Given the way the clean rule works, I
> don’t see how to clean out the files in that directory now that it is no 
> longer
> in the subdir-y list without just special casing it, which is kind of gross.

This actually points out a worse problem: Dependencies are currently
broken for all the files built from their parent directory. I wrongly used
$(basename ...) in the DEPS generation, which I'll send a patch for
shortly. Once fixed, the "clean" aspect will be fixed at once.

Jan

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

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Wei Liu]

On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
> On 11/12/2015 08:43 AM, Juergen Gross wrote:
> >In case the kernel of a new pv-domU indicates it is supporting an
> >unmapped initrd, don't waste precious virtual space for the initrd,
> >but allocate only guest physical memory for it.
> 
> This patch breaks 32-bit pygrub.
> 

This particular patch?

We discovered a bug in mini-os that caused 32-bit pygrub to break withi
this series. It's now fixed in mini-os upstream.  Check Config.mk for
mini-os commit that fixes the bug.

> I am not 100% sure yet but it may be that only 64-bit guests are affected.
> 
> With RHEL5 I get
> initrd extends beyond end of memory (0x780080eda000 > 0x4000)
> 

But this is different from what we found. We need more information.

My wild guess is RHEL5 advertise it supports unmapped initrd but it was
buggy in some way.

Wei.

> 
> -boris

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

Re: [Xen-devel] [PATCH v2 2/2] libxl: implement libxl__xs_mknod using XS_WRITE rather than XS_MKDIR

[Ian Jackson]

Paul Durrant writes ("[PATCH v2 2/2] libxl: implement libxl__xs_mknod using 
XS_WRITE rather than XS_MKDIR"):
> This patch modifies the implentation of libxl__xs_mknod() to use XS_WRITE
> rather than XS_MKDIR since passing an empty value to the former will
> ensure that the path is both existent and empty upon return, rather than
> merely existent. The function return type is also changed to a libxl
> error value rather than a boolean, it's declaration is accordingly moved
> into the 'checked' section in libxl_internal.h, and a comment is added to
> clarify its semantics.
...

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Ian Campbell]

On Wed, 2015-11-25 at 16:18 +, Wei Liu wrote:
> On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
> > On 11/12/2015 08:43 AM, Juergen Gross wrote:
> > > In case the kernel of a new pv-domU indicates it is supporting an
> > > unmapped initrd, don't waste precious virtual space for the initrd,
> > > but allocate only guest physical memory for it.
> > 
> > This patch breaks 32-bit pygrub.
> > 
> 
> This particular patch?
> 
> We discovered a bug in mini-os that caused 32-bit pygrub to break withi
> this series. It's now fixed in mini-os upstream.  Check Config.mk for
> mini-os commit that fixes the bug.

Are we really talking about pygrub here, or pvgrub? (the former is
unaffected by mini-os).

If we are really talking about pygrub then we are _actually_ talking about
the domain builder when operating on the RHEL5 kernel+initrd -- the fact
ithat they were extracted from the guest filesystem by pygrub is
irrelevant.

> > With RHEL5 I get
> > initrd extends beyond end of memory (0x780080eda000 > 0x4000)

This is reported within the guest, right?

Ian.

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

[Xen-devel] [PATCH v1 2/2] libxl: re-implement libxl__xs_printf()

[Paul Durrant]

This patch adds a new libxl__xs_vprintf() which actually checks the
success of the underlying call to xs_write() (logging if it fails) and
then re-implements libxl__xs_printf() using this (and replacing the
call to vasprintf() with a call to libxl__vsprintf()).

libxl__xs_vprintf() is added to the 'checked' section of libxl_internal.h
and, since it now underpins libxl__xs_printf(), that declaration is
moved into the same section.

Looking at call sites of libxl__xs_printf() it seems as though most of
them expected a failure if the underlying xs_write() failed, so this
patch should actually fulfil the semantic that was intended all along.

Signed-off-by: Paul Durrant 
---
 tools/libxl/libxl_internal.h |  8 +---
 tools/libxl/libxl_xshelp.c   | 32 ++--
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 12b2b30..e5000cf 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -666,9 +666,6 @@ _hidden int libxl__xs_writev_perms(libxl__gc *gc, 
xs_transaction_t t,
 /* _atonce creates a transaction and writes all keys at once */
 _hidden int libxl__xs_writev_atonce(libxl__gc *gc,
  const char *dir, char **kvs);
-
-_hidden int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
-   const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
/* Each fn returns 0 on success.
 * On error: returns -1, sets errno (no logging) */
 
@@ -688,6 +685,11 @@ _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t 
domid);
  * fails it logs and returns ERROR_FAIL.
  */
 
+int libxl__xs_vprintf(libxl__gc *gc, xs_transaction_t t,
+  const char *path, const char *fmt, va_list ap);
+int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
+ const char *path, const char *fmt, ...) 
PRINTF_ATTRIBUTE(4, 5);
+
 /* On success, path will exist and will be empty */
 int libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
 const char *path, struct xs_permissions *perms,
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 912a1f2..930b458 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -96,23 +96,35 @@ out:
 
 }
 
-int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
- const char *path, const char *fmt, ...)
+int libxl__xs_vprintf(libxl__gc *gc, xs_transaction_t t,
+  const char *path, const char *fmt, va_list ap)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
 char *s;
+bool ok;
+
+s = libxl__vsprintf(gc, fmt, ap);
+
+ok = xs_write(ctx->xsh, t, path, s, strlen(s));
+if (!ok) {
+LOGE(ERROR, "xenstore write failed: `%s' = `%s'", path, s);
+return ERROR_FAIL;
+}
+
+return 0;
+}
+
+int libxl__xs_printf(libxl__gc *gc, xs_transaction_t t,
+ const char *path, const char *fmt, ...)
+{
 va_list ap;
-int ret;
+int rc;
+
 va_start(ap, fmt);
-ret = vasprintf(, fmt, ap);
+rc = libxl__xs_vprintf(gc, t, path, fmt, ap);
 va_end(ap);
 
-if (ret == -1) {
-return -1;
-}
-xs_write(ctx->xsh, t, path, s, ret);
-free(s);
-return 0;
+return rc;
 }
 
 char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
-- 
2.1.4


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

[Xen-devel] Xen Security Advisory 161 - WITHDRAWN: missing XSETBV intercept privilege check on AMD SVM

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory XSA-161
  version 2

WITHDRAWN: missing XSETBV intercept privilege check on AMD SVM

UPDATES IN VERSION 2


Upon further inspection the necessary privilege level check is present
in the generic code which handles XSETBV and therefore there is no
vulnerability in any version of Xen.

This advisory is therefore withdrawn. The previous text is retained
below for reference.

Thanks to Andrew Cooper for pointing out this oversight.

ISSUE DESCRIPTION
=

*** NOTE: This advisory has been withdrawn ***

XSETBV is a privileged instruction, i.e. should result in #GP when
issued by code running at other than the most privileged level (CPL 0).
Unlike other privileged and intercepted instructions in AMD SVM, XSETBV
has the privilege level check done after the intercept check, resulting
in the need for software to do the checking instead. This software
check was missing.

IMPACT
==

*** NOTE: This advisory has been withdrawn ***

User mode code of HVM guests running on AVX-capable AMD hardware may
effect changes to the set of enabled AVX sub-features in the guest,
potentially confusing the guest kernel, likely resulting in crash and
hence a Denial of Service to the guest. Other attacks, namely privilege
escalation (again inside the guest only), cannot be ruled out.

VULNERABLE SYSTEMS
==

*** NOTE: This advisory has been withdrawn, no versions are vulnerable ***

Xen versions from 4.1 onwards are affected.

Only x86 AMD systems supporting AVX are affected. Intel systems as
well as ARM ones are unaffected.

Only HVM guest user mode code can leverage this vulnerability.

MITIGATION
==

Running only PV guests will avoid this vulnerability.

Running HVM guests on only Intel hardware will also avoid this
vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa161.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x

$ sha256sum xsa161*
aa205960410c2feaa2a45127a1837a64212dd322d8edf884aa3231dd10c8a884  xsa161.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWVdPmAAoJEIP+FMlX6CvZ6IgH/RNKOBcIYc2BTxacwhIh/9Uj
lxXT1XfR3xksFzsW1T7rp6OAYQ1Lpsh+yAQLF8qAEEE+jUi7TWTb1U87K6tS9yYp
ppqwWfp6YS63uhtTu0SiMdvM0hOHTHC2ZfNehpX/iAtzpsdzqcYeWkIjjMBq6z95
isxXnuJq1EmfaI+Sx56c8yRntJwAqDx4twD7gJWC1feRltJn+kSR+pyGpcw4IeM3
ThfgW5Q1s2N4IX/yHlvPGhWDjBwfCP13de23UvUQwiSzLF6m42OnDtSLozvA/h56
yA7JDi/RYDsyL30qYllHKpW8lfrlsq6Xkyakrkw49sm1cJvaYu4vjLDZ9byVvmU=
=wPwa
-END PGP SIGNATURE-


xsa161.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-mingo-tip-master test] 65095: regressions - FAIL

[osstest service owner]

flight 65095 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65095/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-raw6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 60684
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail 

[Xen-devel] [PATCH v3] x86/VPMU: implement ipc and arch filter flags

[Brendan Gregg]

This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.

Signed-off-by: Brendan Gregg 
---
Changes in v3:
* addressing review comments from Boris:
* ensure final flag is validated
* code tidy

Changes in v2:
* feature flags can now be combined (eg, "vpmu=ipc,bts")
* addressing review comments from Boris:
* restrict DS_AREA and PEBS_ENABLE access when filters are in use
* better variable types
* include MSR_IA32_CMT_EVTSEL_UE_MASK flag
---
 docs/misc/xen-command-line.markdown | 14 +-
 xen/arch/x86/cpu/vpmu.c | 51 +
 xen/arch/x86/cpu/vpmu_intel.c   | 49 +++
 xen/include/asm-x86/msr-index.h |  1 +
 xen/include/public/pmu.h| 14 --
 5 files changed, 115 insertions(+), 14 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 70daa84..6055a68 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1452,7 +1452,7 @@ Use Virtual Processor ID support if available.  This 
prevents the need for TLB
 flushes on VM entry and exit, increasing performance.
 
 ### vpmu
-> `= ( bts )`
+> `= (  | { bts | ipc | arch [, ...] } )`
 
 > Default: `off`
 
@@ -1468,6 +1468,18 @@ wrong behaviour (see handle\_pmc\_quirk()).
 If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
 feature is switched on on Intel processors supporting this feature.
 
+vpmu=ipc enables performance monitoring, but restricts the counters to the
+most minimum set possible: instructions, cycles, and reference cycles. These
+can be used to calculate instructions per cycle (IPC).
+
+vpmu=arch enables performance monitoring, but restricts the counters to the
+pre-defined architectural events only. These are exposed by cpuid, and listed
+in Table 18-1 from the Intel 64 and IA-32 Architectures Software Developer's
+Manual, Volume 3B, System Programming Guide, Part 2.
+
+If a boolean is not used, combinations of flags are allowed, comma separated.
+For example, vpmu=arch,bts.
+
 Note that if **watchdog** option is also specified vpmu will be turned off.
 
 *Warning:*
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 2f5156a..46b5324 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -43,34 +43,59 @@ CHECK_pmu_data;
 CHECK_pmu_params;
 
 /*
- * "vpmu" : vpmu generally enabled
- * "vpmu=off" : vpmu generally disabled
- * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu" : vpmu generally enabled (all counters)
+ * "vpmu=off"  : vpmu generally disabled
+ * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
+ * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
+ * flag combinations are allowed, eg, "vpmu=ipc,bts".
  */
 static unsigned int __read_mostly opt_vpmu_enabled;
 unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
 unsigned int __read_mostly vpmu_features = 0;
-static void parse_vpmu_param(char *s);
-custom_param("vpmu", parse_vpmu_param);
+static void parse_vpmu_params(char *s);
+custom_param("vpmu", parse_vpmu_params);
 
 static DEFINE_SPINLOCK(vpmu_lock);
 static unsigned vpmu_count;
 
 static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
 
-static void __init parse_vpmu_param(char *s)
+static int parse_vpmu_param(char *s, int len)
 {
+if ( ! *s || ! len )
+return 0;
+if ( !strncmp(s, "bts", len) )
+vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+else if ( !strncmp(s, "ipc", len) )
+vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
+else if ( !strncmp(s, "arch", len) )
+vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
+else
+return 1;
+return 0;
+}
+
+static void __init parse_vpmu_params(char *s)
+{
+char *sep, *p = s;
+
 switch ( parse_bool(s) )
 {
 case 0:
 break;
 default:
-if ( !strcmp(s, "bts") )
-vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-else if ( *s )
+while (1)
 {
-printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
-break;
+sep = strchr(p, ',');
+if ( sep == NULL )
+sep = strchr(p, 0);
+if ( parse_vpmu_param(p, sep - p) )
+goto error;
+if ( *sep == 0 )
+/* reached end of flags */
+break;
+p = sep + 1;
 }
 /* fall through */
 case 1:
@@ -79,6 +104,10 @@ static void __init parse_vpmu_param(char *s)
 opt_vpmu_enabled = 1;
 break;
 }
+return;
+
+ error:
+printk("VPMU: unknown flags: %s - vpmu disabled!\n", s);
 }
 
 void vpmu_lvtpc_update(uint32_t val)
diff --git 

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Ed Swierk]

A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and
it yields similar results. Not surprising, since Fusion uses basically
the same virtualization engine.

However, ESXi offers many more choices of number of processors, number
of cores, hyperthreading, etc. The weird processor ID assignment (0,
2, 4, 6, ...) occurs only with 4 or 8 processors, 1 core per socket,
and no hyperthreading. If I change any of these parameters, the
processor IDs become sequential.

It appears in the 4- and 8-processor cases, VMware is emulating
something like a Xeon E7340:
https://github.com/deater/test_proc/blob/master/x86_64/x86_64.intel.6.15.11.xeon_e7340

In fact someone asked a question about running Xen on this platform
way back when: 
http://lists.xenproject.org/archives/html/xen-users/2008-05/msg00691.html

Others of similar vintage assign processor IDs 0 and 3 on a
2-processor system:
https://www.centos.org/forums/viewtopic.php?t=30255

or even 0 and 6: http://serverfault.com/questions/302429/interpreting-cpuinfo

So there are real hardware platforms with non-sequential processor
IDs. They are quite ancient and don't support CAT, but that doesn't
rule out the possibility of a newer or future platform behaving
similarly.

At least there is no evidence of a platform assigning extremely large
processor IDs; until then we are safe using arrays and bitmaps. The
issue is sizing these data structures appropriately.

--Ed


On Wed, Nov 25, 2015 at 1:04 AM, Jan Beulich  wrote:
 On 25.11.15 at 08:48,  wrote:
>> On Tue, Nov 24, 2015 at 03:34:45AM -0700, Jan Beulich wrote:
>>> Chao, could you - inside Intel - please check whether there are
>>> any assumptions on the respective CPUID leaf output that aren't
>>> explicitly stated in the SDM right now (like resulting in contiguous
>>> socket numbers), and ask for them getting made explicit (if there
>>> are any), or it being made explicit that no assumptions at all are
>>> to be made at all on the presented values
>>
>> Actually there is already such statement in SDM (ch8.9.1, vol3):
>>
>> "The value of valid APIC_IDs need not be contiguous across package
>> boundary or core boundaries".
>
> That's a statement on APIC ID space (which necessarily can't be
> contiguous on systems with a non-power-of-2 core count), but I
> was asking about the socket ID space.
>
>>> (in which case we'd
>>> have to consume MADT parsing data in set_nr_sockets(), e.g.
>>> by replacing num_processors there with one more than the
>>> maximum APIC ID of any non-disabled CPU)?
>>
>> Even with this, we still have problem for hotplug case, the inserted
>> CPU may have a APIC_ID bigger than the maximum APIC_ID here.
>>
>> But let's back to the real world. Most machines that support CAT should
>> have continuous SOCKET_ID so it's not a problem. Giving that CAT is the
>> only feature uses this, I guess this suggestion might be better than
>> other solutions in practice.
>
> And we could actually cater for that by extrapolating the value
> added to cover disabled_cpus.
>
> Jan
>

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

Re: [Xen-devel] [PATCH v2 2/2] x86/VPMU: implement ipc and arch filter flags

[Brendan Gregg]

On Wed, Nov 25, 2015 at 7:13 AM, Boris Ostrovsky  wrote:

> On 11/24/2015 06:53 PM, Brendan Gregg wrote:
>
>> This introduces a way to have a restricted VPMU, by specifying one of two
>> predefined groups of PMCs to make available. For secure environments, this
>> allows the VPMU to be used without needing to enable all PMCs.
>>
>> Signed-off-by: Brendan Gregg 
>> ---
>>   docs/misc/xen-command-line.markdown | 14 +-
>>   xen/arch/x86/cpu/vpmu.c | 51
>> +
>>   xen/arch/x86/cpu/vpmu_intel.c   | 48
>> ++
>>   xen/include/asm-x86/msr-index.h |  1 +
>>   xen/include/public/pmu.h| 14 --
>>   5 files changed, 115 insertions(+), 13 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.markdown
>> b/docs/misc/xen-command-line.markdown
>> index 70daa84..6055a68 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1452,7 +1452,7 @@ Use Virtual Processor ID support if available.
>> This prevents the need for TLB
>>   flushes on VM entry and exit, increasing performance.
>> ### vpmu
>> -> `= ( bts )`
>> +> `= (  | { bts | ipc | arch [, ...] } )`
>> > Default: `off`
>>   @@ -1468,6 +1468,18 @@ wrong behaviour (see handle\_pmc\_quirk()).
>>   If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store
>> (BTS)
>>   feature is switched on on Intel processors supporting this feature.
>>   +vpmu=ipc enables performance monitoring, but restricts the counters to
>> the
>> +most minimum set possible: instructions, cycles, and reference cycles.
>> These
>> +can be used to calculate instructions per cycle (IPC).
>> +
>> +vpmu=arch enables performance monitoring, but restricts the counters to
>> the
>> +pre-defined architectural events only. These are exposed by cpuid, and
>> listed
>> +in Table 18-1 from the Intel 64 and IA-32 Architectures Software
>> Developer's
>> +Manual, Volume 3B, System Programming Guide, Part 2.
>> +
>> +If a boolean is not used, combinations of flags are allowed, comma
>> separated.
>> +For example, vpmu=arch,bts.
>> +
>>   Note that if **watchdog** option is also specified vpmu will be turned
>> off.
>> *Warning:*
>> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
>> index 2f5156a..bb0ca37 100644
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -43,33 +43,64 @@ CHECK_pmu_data;
>>   CHECK_pmu_params;
>> /*
>> - * "vpmu" : vpmu generally enabled
>> - * "vpmu=off" : vpmu generally disabled
>> - * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
>> + * "vpmu" : vpmu generally enabled (all counters)
>> + * "vpmu=off"  : vpmu generally disabled
>> + * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
>> + * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
>> + * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
>> + * flag combinations are allowed, eg, "vpmu=ipc,bts".
>>*/
>>   static unsigned int __read_mostly opt_vpmu_enabled;
>>   unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
>>   unsigned int __read_mostly vpmu_features = 0;
>> -static void parse_vpmu_param(char *s);
>> -custom_param("vpmu", parse_vpmu_param);
>> +static void parse_vpmu_params(char *s);
>> +custom_param("vpmu", parse_vpmu_params);
>> static DEFINE_SPINLOCK(vpmu_lock);
>>   static unsigned vpmu_count;
>> static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>>   -static void __init parse_vpmu_param(char *s)
>> +static int parse_vpmu_param(char *s, int len)
>>   {
>> +if ( ! *s || ! len )
>> +return 0;
>> +if ( !strncmp(s, "bts", len) )
>> +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> +else if ( !strncmp(s, "ipc", len) )
>> +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>> +else if ( !strncmp(s, "arch", len) )
>> +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>> +else if ( *s )
>>
>
> Why not just "else return 1;" ? We've already tested above that *s is not
> '\0'. (And you don't need curly braces for single-line clauses)
>
>
Ok, thanks.


> +{
>> +return 1;
>> +}
>> +return 0;
>> +}
>> +
>> +static void __init parse_vpmu_params(char *s)
>> +{
>> +bool_t badflag = 0;
>> +char *sep, *p = s;
>> +
>>   switch ( parse_bool(s) )
>>   {
>>   case 0:
>>   break;
>>   default:
>> -if ( !strcmp(s, "bts") )
>> -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> -else if ( *s )
>> +sep = strchr(p, ',');
>> +while (sep != NULL)
>> +{
>> +if ( parse_vpmu_param(p, sep - p) )
>> +badflag = 1;
>> +p = sep + 1;
>> +sep = strchr(p, ',');
>> +}
>> +sep = strchr(p, 0);
>> +parse_vpmu_param(p, sep - p);
>>
>
> This can find unsupported flag too but we are not setting 

[Xen-devel] [ovmf baseline-only test] 38345: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 capture-logs !broken [st=!broken!]
 build-i386-xsm3 capture-logs !broken [st=!broken!]
 build-i3863 capture-logs !broken [st=!broken!]
 build-i386-pvops  2 hosts-allocate  broken REGR. vs. 38340
 build-i386-xsm2 hosts-allocate  broken REGR. vs. 38340
 build-i3862 hosts-allocate  broken REGR. vs. 38340
 build-amd64   5 xen-build fail REGR. vs. 38340

Regressions which are regarded as allowable (not blocking):
 build-amd64-xsm   5 xen-buildfail   like 38340

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 ovmf 9f419739d1ae849e0c4d75a131502f9367ca4a7d
baseline version:
 ovmf 3164361121526318f278a7c1b84bdcc475d4ad95

Last test of basis38340  2015-11-25 07:51:00 Z0 days
Testing same since38345  2015-11-25 22:20:46 Z0 days1 attempts


People who touched revisions under test:
  "Yao, Jiewen" 
  "Zeng, Star" 
  Jeff Fan 
  Yao, Jiewen 
  Zeng, Star 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   broken  
 build-amd64  fail
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

broken build-i386-pvops capture-logs !broken
broken-step build-i386-pvops hosts-allocate
broken-step build-i386-xsm hosts-allocate
broken build-i386-xsm capture-logs !broken
broken build-i386 capture-logs !broken
broken-step build-i386 hosts-allocate

Push not applicable.


commit 9f419739d1ae849e0c4d75a131502f9367ca4a7d
Author: Yao, Jiewen 
Date:   Wed Nov 25 04:28:46 2015 +

Move RestoreSmmConfigurationInS3 function to PerformPreTasks().

In this way, we can centralize the silicon configuration in
PerformRemainingTasks()/PerformPreTasks() function.
If there are more features need to be configured, they can put in
PerformRemainingTasks()/PerformPreTasks() only.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Reviewed-by: "Kinney, Michael D" 
Reviewed-by: "Laszlo Ersek" 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18938 
6f19259b-4bc3-4df7-8a09-765794883524

commit fe5f19494353421d3382f32f31a627e09724bbb2
Author: Yao, Jiewen 
Date:   Wed Nov 25 04:23:01 2015 +

Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED.

Move Gdt initialization from InitializeMpServiceData() to CPU Arch specific 
function.
We create SmmFuncsArch.c for hold CPU specific function, so that
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64) can be removed.

For IA32 version, we always allocate new page for GDT entry, for easy 
maintenance.
For X64 version, we fixed TssBase in GDT entry to make sure TSS data is 
correct.
Remove TSS fixup for GDT in ASM file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Reviewed-by: "Fan, Jeff" 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18937 

Re: [Xen-devel] [PATCH] xen/arm: implement GICD_ICACTIVER read/write

[Shannon Zhao]

On 2015/11/26 0:40, Stefano Stabellini wrote:
> Implement GICD_ICACTIVER and GICD_ISACTIVER reads by looking for the
> GIC_IRQ_GUEST_ACTIVE bit in the relevant struct pending_irq. However
> given that the pending to active transaction for irqs in LRs in done in
> hardware, the GIC_IRQ_GUEST_ACTIVE bit might be out of date. We'll have
> to live with that.
> 
> Implement GICD_ICACTIVER writes by checking the state of the irq in our
> queues: if the irq is present in an LR, remove the hardware ACTIVE bit.
> If the irq is present in an LR of another vcpu, send an IPI. Set the
> GIC_IRQ_GUEST_DEACTIVATE bit to tell the receiving vcpu that the active
> bit needs to be deactivated.
> 
> Signed-off-by: Stefano Stabellini 

Tested-by: Shannon Zhao 

> ---
>  xen/arch/arm/gic.c |   40 +++
>  xen/arch/arm/vgic-v2.c |   45 
> ++--
>  xen/arch/arm/vgic-v3.c |   44 ++-
>  xen/include/asm-arm/gic.h  |1 +
>  xen/include/asm-arm/vgic.h |4 
>  5 files changed, 123 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 1e1e5ba..75c1f52 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -414,6 +414,15 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>  gic_hw_ops->read_lr(i, _val);
>  irq = lr_val.virq;
>  p = irq_to_pending(v, irq);
> +
> +if ( test_and_clear_bit(GIC_IRQ_GUEST_DEACTIVATE, >status) &&
> + (lr_val.state & GICH_LR_ACTIVE) )
> +{
> +clear_bit(GIC_IRQ_GUEST_ACTIVE, >status);
> +lr_val.state &= ~GICH_LR_ACTIVE;
> +gic_hw_ops->write_lr(i, _val);
> +}
> +
>  if ( lr_val.state & GICH_LR_ACTIVE )
>  {
>  set_bit(GIC_IRQ_GUEST_ACTIVE, >status);
> @@ -489,6 +498,37 @@ void gic_clear_lrs(struct vcpu *v)
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
>  }
>  
> +/* called with rank lock held */
> +void gic_deactivate_irq(struct vcpu *v, unsigned int irq)
> +{
> +unsigned long flags;
> +struct pending_irq *p;
> +struct vcpu *v_target = v->domain->arch.vgic.handler->get_target_vcpu(v, 
> irq);
> +
> +spin_lock_irqsave(_target->arch.vgic.lock, flags);
> +
> +p = irq_to_pending(v_target, irq);
> +/* the interrupt is not even in an LR */
> +if ( list_empty(>inflight) || !list_empty(>lr_queue) )
> +{
> +spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
> +return;
> +}
> +
> +/* it is in an LR, let's check */
> +set_bit(GIC_IRQ_GUEST_DEACTIVATE, >status);
> +if ( v_target == current )
> +{
> +gic_update_one_lr(v_target, p->lr);
> +spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
> +} else {
> +spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
> +vcpu_unblock(v_target);
> +if (v_target->is_running )
> +smp_send_event_check_mask(cpumask_of(v_target->processor));
> +}
> +}
> +
>  static void gic_restore_pending_irqs(struct vcpu *v)
>  {
>  int lr = 0;
> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> index f7d784b..9042062 100644
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -126,8 +126,31 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  /* Read the active status of an IRQ via GICD is not supported */
>  case GICD_ISACTIVER ... GICD_ISACTIVERN:
>  case GICD_ICACTIVER ... GICD_ICACTIVERN:
> -goto read_as_zero;
> -
> +{
> +unsigned int i = 0, irq = 0;
> +struct pending_irq *p;
> +if ( dabt.size != DABT_WORD ) goto bad_width;
> +rank = vgic_rank_offset(v, 1, gicd_reg - GICD_ICACTIVER, DABT_WORD);
> +if ( rank == NULL) goto read_as_zero;
> +vgic_lock_rank(v, rank, flags);
> +*r = 0;
> +irq = (gicd_reg - GICD_ICACTIVER) << 3;
> +for (i = 0; i < 32; i++)
> +{
> +p = irq_to_pending(v, i + irq);
> +/*
> + * This information is likely out of date because we don't
> + * actually know which interrupts have become ACTIVE from
> + * PENDING in the LRs of other processors at it happens
> + * transparently in hardware.  We would have to interrupt
> + * all other running vcpus to get an accurate snapshot.
> + * Let's not do that.
> + */
> +*r |= test_bit(GIC_IRQ_GUEST_ACTIVE, >status) ? (1 << i) : 0;
> +}
> +vgic_unlock_rank(v, rank, flags);
> +return 1;
> +}
>  case GICD_ITARGETSR ... GICD_ITARGETSRN:
>  if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto 
> bad_width;
>  rank = vgic_rank_offset(v, 8, gicd_reg - GICD_ITARGETSR, DABT_WORD);
> @@ -332,11 +355,21 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 

[Xen-devel] can I read or write the physical memory of a nested xen?

[Big Strong]

I installed a nested xen (L1) on xen (L0). Is it possible to read or write
the physical memory of L1 from dom0 of L0? Is the L1 directly access the
physical memory or need to translate through L0?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/10] xen-block: multi hardware-queues/rings support

[Konrad Rzeszutek Wilk]

On Thu, Nov 26, 2015 at 10:28:10AM +0800, Bob Liu wrote:
> 
> On 11/26/2015 06:12 AM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
>    xen/blkback: separate ring information out of struct xen_blkif
>    xen/blkback: pseudo support for multi hardware queues/rings
>    xen/blkback: get the number of hardware queues/rings from blkfront
>    xen/blkback: make pool of persistent grants and free pages per-queue
> >>>
> >>> OK, got to those as well. I have put them in 'devel/for-jens-4.5' and
> >>> are going to test them overnight before pushing them out.
> >>>
> >>> I see two bugs in the code that we MUST deal with:
> >>>
> >>>  - print_stats () is going to show zero values.
> >>>  - the sysfs code (VBD_SHOW) aren't converted over to fetch data
> >>>from all the rings.
> >>
> >> - kthread_run can't handle the two "name, i" arguments. I see:
> >>
> >> root  5101 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
> >> root  5102 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
> > 
> > And doing save/restore:
> > 
> > xl save  /tmp/A;
> > xl restore /tmp/A;
> > 
> > ends up us loosing the proper state and not getting the ring setup back.
> > I see this is backend:
> > 
> > [ 2719.448600] vbd vbd-22-51712: -1 guest requested 0 queues, exceeding the 
> > maximum of 3.
> > 
> > And XenStore agrees:
> > tool = ""
> >  xenstored = ""
> > local = ""
> >  domain = ""
> >   0 = ""
> >domid = "0"
> >name = "Domain-0"
> >device-model = ""
> > 0 = ""
> >  state = "running"
> >error = ""
> > backend = ""
> >  vbd = ""
> >   2 = ""
> >51712 = ""
> > error = "-1 guest requested 0 queues, exceeding the maximum of 3."
> > 
> > .. which also leads to a memory leak as xen_blkbk_remove never gets
> > called.
> 
> I think which was already fix by your patch:
> [PATCH RFC 2/2] xen/blkback: Free resources if connect_ring failed.

Nope. I get that with or without the patch.

I pushed the patches in
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
#devel/for-jens-4.5 tree. It also has some extra patches that should be
soon going via the x86 tree.

With the xen-blkback compiled with #define DEBUG 1 I see:

[   63.887741] xen-blkback: xen_blkbk_probe 880026a8cc00 1
[   63.894302] xen-blkback: backend_changed 880026a8cc00 1
[   63.895748] xen-blkback: frontend_changed 880026a8cc00 Initialising
[   63.922700] xen-blkback: xen_blkbk_probe 8800269da800 1
[   63.927849] xen-blkback: backend_changed 8800269da800 1
[   63.929117] xen-blkback: Successful creation of handle=ca00 (dom=1)
[   63.930605] xen-blkback: frontend_changed 8800269da800 Initialising
[   64.097161] xen-blkback: backend_changed 880026a8cc00 1
[   64.098992] xen-blkback: Successful creation of handle=1600 (dom=1)
[   64.345913] device vif1.0 entered promiscuous mode
[   64.351469] IPv6: ADDRCONF(NETDEV_UP): vif1.0: link is not ready
[   64.538682] device vif1.0-emu entered promiscuous mode
[   64.546592] switch: port 3(vif1.0-emu) entered forwarding state
[   64.548357] switch: port 3(vif1.0-emu) entered forwarding state
[   79.544475] switch: port 3(vif1.0-emu) entered forwarding state
[   84.090637] switch: port 3(vif1.0-emu) entered disabled state
[   84.091545] device vif1.0-emu left promiscuous mode
[   84.092416] switch: port 3(vif1.0-emu) entered disabled state
[   89.286901] vif vif-1-0 vif1.0: Guest Rx ready
[   89.287921] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes ready
[   89.288943] switch: port 2(vif1.0) entered forwarding state
[   89.289747] switch: port 2(vif1.0) entered forwarding state
[   89.456176] xen-blkback: frontend_changed 880026a8cc00 Closed
[   89.481945] xen-blkback: frontend_changed 8800269da800 Initialised
[   89.482802] xen-blkback: connect_ring /local/domain/1/device/vbd/51712
[   89.484068] xen-blkback: backend/vbd/1/51712: using 2 queues, protocol 2 
(x86_32-abi) persistent grants
[   89.532755] xen-blkback: connect /local/domain/1/device/vbd/51712
[   89.541694] xen_update_blkif_status: name=[blkback.1.xvda-0]
[   89.542667] xen_update_blkif_status: name=[blkback.1.xvda-1]
[   89.561913] xen-blkback: frontend_changed 8800269da800 Connected

.. so here the guest booted and now we are suspending it.

[  104.300579] switch: port 2(vif1.0) entered forwarding state
[  208.057752] xen-blkback: frontend_changed 880026a8cc00 Unknown
[  208.061282] xen-blkback: xen_blkbk_remove 880026a8cc00 1
[  208.081888] xen-blkback: frontend_changed 8800269da800 Unknown
[  208.082759] xen-blkback: xen_blkbk_remove 8800269da800 1
[  208.102745] switch: port 2(vif1.0) entered disabled state
[  208.109089] switch: port 2(vif1.0) entered disabled state
[  208.109934] device vif1.0 left promiscuous mode
[  208.110734] switch: port 2(vif1.0) entered disabled state

We are done 

Re: [Xen-devel] [PATCH v5 00/10] xen-block: multi hardware-queues/rings support

[Bob Liu]

On 11/26/2015 06:12 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
   xen/blkback: separate ring information out of struct xen_blkif
   xen/blkback: pseudo support for multi hardware queues/rings
   xen/blkback: get the number of hardware queues/rings from blkfront
   xen/blkback: make pool of persistent grants and free pages per-queue
>>>
>>> OK, got to those as well. I have put them in 'devel/for-jens-4.5' and
>>> are going to test them overnight before pushing them out.
>>>
>>> I see two bugs in the code that we MUST deal with:
>>>
>>>  - print_stats () is going to show zero values.
>>>  - the sysfs code (VBD_SHOW) aren't converted over to fetch data
>>>from all the rings.
>>
>> - kthread_run can't handle the two "name, i" arguments. I see:
>>
>> root  5101 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
>> root  5102 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
> 
> And doing save/restore:
> 
> xl save  /tmp/A;
> xl restore /tmp/A;
> 
> ends up us loosing the proper state and not getting the ring setup back.
> I see this is backend:
> 
> [ 2719.448600] vbd vbd-22-51712: -1 guest requested 0 queues, exceeding the 
> maximum of 3.
> 
> And XenStore agrees:
> tool = ""
>  xenstored = ""
> local = ""
>  domain = ""
>   0 = ""
>domid = "0"
>name = "Domain-0"
>device-model = ""
> 0 = ""
>  state = "running"
>error = ""
> backend = ""
>  vbd = ""
>   2 = ""
>51712 = ""
> error = "-1 guest requested 0 queues, exceeding the maximum of 3."
> 
> .. which also leads to a memory leak as xen_blkbk_remove never gets
> called.

I think which was already fix by your patch:
[PATCH RFC 2/2] xen/blkback: Free resources if connect_ring failed.

P.S. I didn't see your git tree updated with these patches.

-- 
Regards,
-Bob

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 64579
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 64579
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 64579
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 64579

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 14 leak-check/check fail in 65078 pass in 
65100
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail pass in 65078

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 64579
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 64579

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail in 65078 never 
pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass

version targeted for testing:
 qemuu4b6eda626fdb8bf90472c6868d502a2ac09abeeb
baseline version:
 qemuu9be060f5278dc0d732ebfcf2bf0a293f88b833eb

Last test of basis64579  2015-11-17 15:37:49 Z8 days
Failing since 64797  2015-11-19 03:03:30 Z6 days6 attempts
Testing same since65078  2015-11-24 17:44:35 Z1 days2 attempts


People who touched revisions under test:
  "Dr. David Alan Gilbert" 
  Alberto Garcia 
  Alistair Francis 
  Andreas Färber 
  Bandan Das 
  Daniel P. Berrange 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Fam Zheng 
  François Baldassari 
  Gerd Hoffmann 
  Greg Kurz 
  Ildar Isaev 
  James Hogan 
  John Clarke 
  John Snow 
  Juan Quintela 
  Kevin Wolf 
  Leon Alrae 
  Marc-André Lureau 
  Max Reitz 
  Michael Roth 
  Michael S. Tsirkin 
  Pavel Fedin 
  Peter Lieven 

[Xen-devel] [PATCH] target: xen-scsiback: Return proper -Exx instead of -1.

[Konrad Rzeszutek Wilk]

We could return EINVAL but EBUSY (or EALREADY?)is more appropiate.

CC: jgr...@suse.com
Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/xen/xen-scsiback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 43bcae8..286e3da 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -800,7 +800,7 @@ static int scsiback_init_sring(struct vscsibk_info *info, 
grant_ref_t ring_ref,
int err;
 
if (info->irq)
-   return -1;
+   return -EBUSY;
 
err = xenbus_map_ring_valloc(info->dev, _ref, 1, );
if (err)
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v5 00/10] xen-block: multi hardware-queues/rings support

[Konrad Rzeszutek Wilk]

>   xen/blkback: separate ring information out of struct xen_blkif
>   xen/blkback: pseudo support for multi hardware queues/rings
>   xen/blkback: get the number of hardware queues/rings from blkfront
>   xen/blkback: make pool of persistent grants and free pages per-queue

OK, got to those as well. I have put them in 'devel/for-jens-4.5' and
are going to test them overnight before pushing them out.

I see two bugs in the code that we MUST deal with:

 - print_stats () is going to show zero values.
 - the sysfs code (VBD_SHOW) aren't converted over to fetch data
   from all the rings.

> 
>  drivers/block/xen-blkback/blkback.c | 386 ++-
>  drivers/block/xen-blkback/common.h  |  78 ++--
>  drivers/block/xen-blkback/xenbus.c  | 359 --
>  drivers/block/xen-blkfront.c| 718 
> ++--
>  include/xen/interface/io/blkif.h|  48 +++
>  5 files changed, 971 insertions(+), 618 deletions(-)
> 
> -- 
> 1.8.3.1
> 

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

Re: [Xen-devel] [PATCH v5 08/10] xen/blkback: get the number of hardware queues/rings from blkfront

[Konrad Rzeszutek Wilk]

On Sat, Nov 14, 2015 at 11:12:17AM +0800, Bob Liu wrote:
> Backend advertises "multi-queue-max-queues" to front, also get the negotiated
> number from "multi-queue-num-queues" written by blkfront.
> 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkback/blkback.c |   12 
>  drivers/block/xen-blkback/common.h  |1 +
>  drivers/block/xen-blkback/xenbus.c  |   34 --
>  3 files changed, 41 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index fb5bfd4..acedc46 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -84,6 +84,15 @@ MODULE_PARM_DESC(max_persistent_grants,
>   "Maximum number of grants to map persistently");
>  
>  /*
> + * Maximum number of rings/queues blkback supports, allow as many queues as 
> there
> + * are CPUs if user has not specified a value.
> + */
> +unsigned int xenblk_max_queues;
> +module_param_named(max_queues, xenblk_max_queues, uint, 0644);
> +MODULE_PARM_DESC(max_queues,
> +  "Maximum number of hardware queues per virtual disk");

Added:
 unsigned int xenblk_max_queues;
 module_param_named(max_queues, xenblk_max_queues, uint, 0644);
 MODULE_PARM_DESC(max_queues,
-"Maximum number of hardware queues per virtual disk");
+"Maximum number of hardware queues per virtual disk." \
+"By default it is the number of online CPUs.");
 
 /*

> +
> +/*
>   * Maximum order of pages to be used for the shared ring between front and
>   * backend, 4KB page granularity is used.
>   */
> @@ -1483,6 +1492,9 @@ static int __init xen_blkif_init(void)
>   xen_blkif_max_ring_order = XENBUS_MAX_RING_GRANT_ORDER;
>   }
>  
> + if (xenblk_max_queues == 0)
> + xenblk_max_queues = num_online_cpus();
> +
>   rc = xen_blkif_interface_init();
>   if (rc)
>   goto failed_init;
> diff --git a/drivers/block/xen-blkback/common.h 
> b/drivers/block/xen-blkback/common.h
> index f2386e3..0833dc6 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -46,6 +46,7 @@
>  #include 
>  
>  extern unsigned int xen_blkif_max_ring_order;
> +extern unsigned int xenblk_max_queues;
>  /*
>   * This is the maximum number of segments that would be allowed in indirect
>   * requests. This value will also be passed to the frontend.
> diff --git a/drivers/block/xen-blkback/xenbus.c 
> b/drivers/block/xen-blkback/xenbus.c
> index 6c6e048..d83b790 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -181,12 +181,6 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
>   blkif->st_print = jiffies;
>   INIT_WORK(>persistent_purge_work, xen_blkbk_unmap_purged_grants);
>  
> - blkif->nr_rings = 1;
> - if (xen_blkif_alloc_rings(blkif)) {
> - kmem_cache_free(xen_blkif_cachep, blkif);
> - return ERR_PTR(-ENOMEM);
> - }
> -
>   return blkif;
>  }
>  
> @@ -595,6 +589,12 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
>   goto fail;
>   }
>  
> + /* Multi-queue: write how many queues are supported by the backend. */
> + err = xenbus_printf(XBT_NIL, dev->nodename,
> + "multi-queue-max-queues", "%u", xenblk_max_queues);
> + if (err)
> + pr_warn("Error writing multi-queue-num-queues\n");

s/num/max/

> +
>   /* setup back pointer */
>   be->blkif->be = be;
>  
> @@ -980,6 +980,7 @@ static int connect_ring(struct backend_info *be)
>   char *xspath;
>   size_t xspathsize;
>   const size_t xenstore_path_ext_size = 11; /* sufficient for 
> "/queue-NNN" */
> + unsigned int requested_num_queues = 0;
>  
>   pr_debug("%s %s\n", __func__, dev->otherend);
>  
> @@ -1007,6 +1008,27 @@ static int connect_ring(struct backend_info *be)
>   be->blkif->vbd.feature_gnt_persistent = pers_grants;
>   be->blkif->vbd.overflow_max_grants = 0;
>  
> + /*
> +  * Read the number of hardware queues from frontend.
> +  */
> + err = xenbus_scanf(XBT_NIL, dev->otherend, "multi-queue-num-queues",
> +"%u", _num_queues);
> + if (err < 0) {
> + requested_num_queues = 1;
> + } else {
> + if (requested_num_queues > xenblk_max_queues
> + || requested_num_queues == 0) {
> + /* buggy or malicious guest */
> + xenbus_dev_fatal(dev, err,
> + "guest requested %u queues, exceeding 
> the maximum of %u.",
> + requested_num_queues, 
> xenblk_max_queues);
> + return -1;

And made this return -ENOSYS.


> + }
> + }
> + be->blkif->nr_rings = requested_num_queues;
> + if 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 64035

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 64035
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 64035
 test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail blocked in 64035
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 64035
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 64035
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 64035

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 xen  0c3f24645b07b875bc1294fb4627f01e030690fe
baseline version:
 xen  22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c

Last test of basis64035  2015-11-10 08:01:11 Z   15 days
Failing since 64149  2015-11-11 19:15:29 Z   14 days   10 attempts
Testing same since65094  2015-11-25 02:33:44 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Bob Liu 
  Bob Moore 
  Boris Ostrovsky 
  Dario Faggioli 
  David Scott 
  Feng Wu 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Joe Perches 
  Jonathan Davies 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Naresh Bhat 
  Olaf Hering 
  Oleksandr Tyshchenko 
  Parth Dixit 
  Paul Durrant 
  Razvan Cojocaru 
  Riku Voipio 
  Roger Pau Monné 
  Samuel Thibault 
  Shannon Zhao 
  Simon Rowe 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
baseline version:
 xen  2a91f05083c33f69d19ec3ee037b4536f9dd4516

Last test of basis65108  2015-11-25 13:58:43 Z0 days
Testing same since65113  2015-11-25 17:01:26 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Daniel Kiper 
  Ian Campbell 
  Jan Beulich 
  Jonathan Creekmore 
  Peng Fan 
  Shuai Ruan 
  Shuai Ruan 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
+ . ./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 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
+ branch=xen-unstable-smoke
+ revision=713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
+ . ./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-unstable
+ '[' x713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ 

Re: [Xen-devel] [PATCH v2 1/2] x86/VPMU: return correct fixed PMC count

[Boris Ostrovsky]

On 11/25/2015 10:31 AM, Jan Beulich wrote:


However, I just noticed that various control and status registers are
not available for v1. I wonder whether we should even support version 1
since we'd need to add whole lot of 'if (supported)' throughout the code
plus there are some assumptions about existence of IA32_PERF_GLOBAL_CTRL
so we'll need to add additional logic to handle that too. And it's not
clear to me if it's all worth it.

Indeed, let's not support v1 then for now and leave the exercise
to add all the if()s to whoever cares for such support.


And, in fact, I think we should drop model check in core2_vpmu_init() 
and only test for PMU version. Especially in light of XSA-163.


We could limit support to versions 2 and 3 only if we want to be on the 
safe side.


If people agree I'll send a patch (on Monday).


-boris

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

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" 
> > 
> > Using deprecate gnutls_*_set() triggers a failure to compile
> > with gnutls30-3.4.4, used on OpenSUSE factory:
> > 
> > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference 
> > to `gnutls_kx_set_priority'
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference 
> > to `gnutls_certificate_type_set_priority'
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference 
> > to `gnutls_protocol_set_priority'
> > 
> > This compilation issue can be fixed by using the new routine
> > gnutls_priority_set_direct() which replaces the deprecated calls
> > which also simplifies the code considerably.
> 
> 
> Thanks for posting that! It certainly fixes that issue.

Acked-by?

> I was wondering if you had seen these as well:
> 
> /home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
> ‘gnutls_anon_server_credentials’ is deprecated
> [-Wdeprecated-declarations]
>  {
>  ^
> /home/konrad/qemu-trad.git/vnc.c: In function
> ‘vnc_tls_initialize_anon_cred’:
> /home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
> ‘gnutls_anon_server_credentials’ is deprecated
> [-Wdeprecated-declarations]
>  gnutls_anon_server_credentials anon_cred;
>  ^
> /home/konrad/qemu-trad.git/vnc.c: In function ‘vnc_start_tls’:
> /home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
> ‘gnutls_anon_server_credentials’ is deprecated
> [-Wdeprecated-declarations]
>   gnutls_anon_server_credentials anon_cred =
> vnc_tls_initialize_anon_cred();
>   ^
> ?
> 
> (This is Fedora 23)

Nope.

 Luis

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

[Xen-devel] [PATCH RFC 1/2] xen/blocks: Return -EXX instead of -1

[Konrad Rzeszutek Wilk]

Lets return sensible values instead of -1.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/block/xen-blkback/xenbus.c | 2 +-
 drivers/block/xen-blkfront.c   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 2b8650a9..ca3a414 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -996,7 +996,7 @@ static int connect_ring(struct backend_info *be)
be->blkif->blk_protocol = BLKIF_PROTOCOL_X86_64;
else {
xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
-   return -1;
+   return -ENOSYS;
}
err = xenbus_gather(XBT_NIL, dev->otherend,
"feature-persistent", "%u",
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index b48e488..0360c44 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -828,11 +828,11 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 
sector_size,
info->tag_set.driver_data = info;
 
if (blk_mq_alloc_tag_set(>tag_set))
-   return -1;
+   return -EINVAL;
rq = blk_mq_init_queue(>tag_set);
if (IS_ERR(rq)) {
blk_mq_free_tag_set(>tag_set);
-   return -1;
+   return PTR_ERR(rq);
}
 
queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq);
-- 
2.5.0


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

[Xen-devel] [PATCH RFC] Various fixes to xen block drivers on top of Bob's multi-queue patches.

[Konrad Rzeszutek Wilk]

Hey,

As I was reviewing Bob's backend patches I spotted a couple of
oddities that I thought should be fixed.

Please review at your leisure.

 drivers/block/xen-blkback/xenbus.c | 10 --
 drivers/block/xen-blkfront.c   |  4 ++--
 2 files changed, 10 insertions(+), 4 deletions(-)


Konrad Rzeszutek Wilk (2):
  xen/blocks: Return -EXX instead of -1
  xen/blkback: Free resources if connect_ring failed.


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

Re: [Xen-devel] [PATCH v5 00/10] xen-block: multi hardware-queues/rings support

[Konrad Rzeszutek Wilk]

On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
> > >   xen/blkback: separate ring information out of struct xen_blkif
> > >   xen/blkback: pseudo support for multi hardware queues/rings
> > >   xen/blkback: get the number of hardware queues/rings from blkfront
> > >   xen/blkback: make pool of persistent grants and free pages per-queue
> > 
> > OK, got to those as well. I have put them in 'devel/for-jens-4.5' and
> > are going to test them overnight before pushing them out.
> > 
> > I see two bugs in the code that we MUST deal with:
> > 
> >  - print_stats () is going to show zero values.
> >  - the sysfs code (VBD_SHOW) aren't converted over to fetch data
> >from all the rings.
> 
> - kthread_run can't handle the two "name, i" arguments. I see:
> 
> root  5101 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
> root  5102 2  0 20:47 ?00:00:00 [blkback.3.xvda-]

And doing save/restore:

xl save  /tmp/A;
xl restore /tmp/A;

ends up us loosing the proper state and not getting the ring setup back.
I see this is backend:

[ 2719.448600] vbd vbd-22-51712: -1 guest requested 0 queues, exceeding the 
maximum of 3.

And XenStore agrees:
tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   domid = "0"
   name = "Domain-0"
   device-model = ""
0 = ""
 state = "running"
   error = ""
backend = ""
 vbd = ""
  2 = ""
   51712 = ""
error = "-1 guest requested 0 queues, exceeding the maximum of 3."

.. which also leads to a memory leak as xen_blkbk_remove never gets
called.
> 
> 
> > 
> > > 
> > >  drivers/block/xen-blkback/blkback.c | 386 ++-
> > >  drivers/block/xen-blkback/common.h  |  78 ++--
> > >  drivers/block/xen-blkback/xenbus.c  | 359 --
> > >  drivers/block/xen-blkfront.c| 718 
> > > ++--
> > >  include/xen/interface/io/blkif.h|  48 +++
> > >  5 files changed, 971 insertions(+), 618 deletions(-)
> > > 
> > > -- 
> > > 1.8.3.1
> > > 

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

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" 
> > > 
> > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > 
> > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined 
> > > reference to `gnutls_kx_set_priority'
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined 
> > > reference to `gnutls_certificate_type_set_priority'
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined 
> > > reference to `gnutls_protocol_set_priority'
> > > 
> > > This compilation issue can be fixed by using the new routine
> > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > which also simplifies the code considerably.
> > 
> > 
> > Thanks for posting that! It certainly fixes that issue.
> 
> Acked-by?

Tested-by: Konrad Rzeszutek Wilk 
> 
> > I was wondering if you had seen these as well:
> > 
> > /home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
> > ‘gnutls_anon_server_credentials’ is deprecated
> > [-Wdeprecated-declarations]
> >  {
> >  ^
> > /home/konrad/qemu-trad.git/vnc.c: In function
> > ‘vnc_tls_initialize_anon_cred’:
> > /home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
> > ‘gnutls_anon_server_credentials’ is deprecated
> > [-Wdeprecated-declarations]
> >  gnutls_anon_server_credentials anon_cred;
> >  ^
> > /home/konrad/qemu-trad.git/vnc.c: In function ‘vnc_start_tls’:
> > /home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
> > ‘gnutls_anon_server_credentials’ is deprecated
> > [-Wdeprecated-declarations]
> >   gnutls_anon_server_credentials anon_cred =
> > vnc_tls_initialize_anon_cred();
> >   ^
> > ?
> > 
> > (This is Fedora 23)
> 
> Nope.
> 
>  Luis

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

Re: [Xen-devel] [PATCH v5 00/10] xen-block: multi hardware-queues/rings support

[Konrad Rzeszutek Wilk]

On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
> >   xen/blkback: separate ring information out of struct xen_blkif
> >   xen/blkback: pseudo support for multi hardware queues/rings
> >   xen/blkback: get the number of hardware queues/rings from blkfront
> >   xen/blkback: make pool of persistent grants and free pages per-queue
> 
> OK, got to those as well. I have put them in 'devel/for-jens-4.5' and
> are going to test them overnight before pushing them out.
> 
> I see two bugs in the code that we MUST deal with:
> 
>  - print_stats () is going to show zero values.
>  - the sysfs code (VBD_SHOW) aren't converted over to fetch data
>from all the rings.

- kthread_run can't handle the two "name, i" arguments. I see:

root  5101 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
root  5102 2  0 20:47 ?00:00:00 [blkback.3.xvda-]


> 
> > 
> >  drivers/block/xen-blkback/blkback.c | 386 ++-
> >  drivers/block/xen-blkback/common.h  |  78 ++--
> >  drivers/block/xen-blkback/xenbus.c  | 359 --
> >  drivers/block/xen-blkfront.c| 718 
> > ++--
> >  include/xen/interface/io/blkif.h|  48 +++
> >  5 files changed, 971 insertions(+), 618 deletions(-)
> > 
> > -- 
> > 1.8.3.1
> > 

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

[Xen-devel] [PATCH] libxl: Be more careful with error handling in libxl__dm_runas_helper()

[Boris Ostrovsky]

getpwnam_r() has fairly complicated return rules. From man pages:

  RETURN VALUE
  ...
  On success, getpwnam_r() and getpwuid_r() return zero, and set
  *result to pwd.  If no matching  password record was found, these
  functions return 0 and store NULL in *result. In case of error,
  an error number is returned, and NULL is stored in *result.
  ERRORS
  0 or ENOENT or ESRCH or EBADF or EPERM or ...
The given name or uid was not found.

While it's not clear what ellipses are meant to be, the way we currently
treat return values from getpwnam_r() is no sufficient. In fact, two of
my systems behave differently when username is not found: one returns
ENOENT and the other returns 0. Both set *result to NULL.

This patch adjusts return value management to be more in line with man
pages.

While at it, also make sure we don't get stuck on ERANGE.

Signed-off-by: Boris Ostrovsky 
---
 tools/libxl/libxl_dm.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a4934df..bd3daeb 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -726,7 +726,7 @@ static int libxl__dm_runas_helper(libxl__gc *gc, const char 
*username)
 struct passwd pwd, *user = NULL;
 char *buf = NULL;
 long buf_size;
-int ret;
+int ret, retry_cnt = 0;
 
 buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
 if (buf_size < 0) {
@@ -740,12 +740,17 @@ static int libxl__dm_runas_helper(libxl__gc *gc, const 
char *username)
 ret = getpwnam_r(username, , buf, buf_size, );
 if (ret == ERANGE) {
 buf_size += 128;
+if (retry_cnt++ > 10)
+return ERROR_FAIL;
 continue;
 }
-if (ret != 0)
-return ERROR_FAIL;
-if (user != NULL)
-return 1;
+if (user == NULL) {
+if (!ret || (ret == ENOENT) || (ret == ESRCH) ||
+(ret == EBADF) || (ret == EPERM))
+return ERROR_NOTFOUND;
+else
+return ERROR_FAIL;
+}
 return 0;
 }
 }
@@ -1261,16 +1266,16 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 
 user = GCSPRINTF("%s%d", LIBXL_QEMU_USER_BASE, guest_domid);
 ret = libxl__dm_runas_helper(gc, user);
-if (ret < 0)
+if (ret && (ret != ERROR_NOTFOUND))
 return ret;
-if (ret > 0)
+if (!ret)
 goto end_search;
 
 user = LIBXL_QEMU_USER_SHARED;
 ret = libxl__dm_runas_helper(gc, user);
-if (ret < 0)
+if (ret && (ret != ERROR_NOTFOUND))
 return ret;
-if (ret > 0) {
+if (!ret) {
 LOG(WARN, "Could not find user %s%d, falling back to %s",
 LIBXL_QEMU_USER_BASE, guest_domid, LIBXL_QEMU_USER_SHARED);
 goto end_search;
-- 
1.8.1.4


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

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

On 25/11/15 17:12, Boris Ostrovsky wrote:
> On 11/12/2015 08:43 AM, Juergen Gross wrote:
>> In case the kernel of a new pv-domU indicates it is supporting an
>> unmapped initrd, don't waste precious virtual space for the initrd,
>> but allocate only guest physical memory for it.
> 
> This patch breaks 32-bit pygrub.
> 
> I am not 100% sure yet but it may be that only 64-bit guests are affected.
> 
> With RHEL5 I get
> initrd extends beyond end of memory (0x780080eda000 > 0x4000)

Let me summarize your findings:

You are using a 32 bit dom0 to start a 64 bit RHEL5 guest via pygrub
(not pvgrub). The guest then barfs about the initrd position in
memory.

Can you get the debug output of the domain builder? This would help
to see what is really happening.


Juergen


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

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

On 26/11/15 06:06, Juergen Gross wrote:
> On 25/11/15 17:12, Boris Ostrovsky wrote:
>> On 11/12/2015 08:43 AM, Juergen Gross wrote:
>>> In case the kernel of a new pv-domU indicates it is supporting an
>>> unmapped initrd, don't waste precious virtual space for the initrd,
>>> but allocate only guest physical memory for it.
>>
>> This patch breaks 32-bit pygrub.
>>
>> I am not 100% sure yet but it may be that only 64-bit guests are affected.
>>
>> With RHEL5 I get
>> initrd extends beyond end of memory (0x780080eda000 > 0x4000)
> 
> Let me summarize your findings:
> 
> You are using a 32 bit dom0 to start a 64 bit RHEL5 guest via pygrub
> (not pvgrub). The guest then barfs about the initrd position in
> memory.
> 
> Can you get the debug output of the domain builder? This would help
> to see what is really happening.

I think I have found a potential problem not (directly) related to my
patch:

The domain builder is using xen_pfn_t for pfns. With a 32 bit toolstack
this will lead to problems with 64 bit guests, as xen_pfn_t on x86 is:

typedef unsigned long xen_pfn_t;

I guess we have to modify the domain builder to use a 64 bit type
instead.


Juergen


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

Re: [Xen-devel] [PATCH v8 03/21] xen/x86: allow disabling the emulated local apic

[Tian, Kevin]

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Saturday, November 07, 2015 12:06 AM
> 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Andrew Cooper 
> Acked-by: Jan Beulich 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Eddie Dong 
> Cc: Kevin Tian 

Acked-by: Kevin Tian 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] target: xen-scsiback: Return proper -Exx instead of -1.

[Juergen Gross]

On 25/11/15 20:24, Konrad Rzeszutek Wilk wrote:
> We could return EINVAL but EBUSY (or EALREADY?)is more appropiate.
> 
> CC: jgr...@suse.com
> Signed-off-by: Konrad Rzeszutek Wilk 

While it doesn't really matter it's cleaner.

Reviewed-by: Juergen Gross 

> ---
>  drivers/xen/xen-scsiback.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
> index 43bcae8..286e3da 100644
> --- a/drivers/xen/xen-scsiback.c
> +++ b/drivers/xen/xen-scsiback.c
> @@ -800,7 +800,7 @@ static int scsiback_init_sring(struct vscsibk_info *info, 
> grant_ref_t ring_ref,
>   int err;
>  
>   if (info->irq)
> - return -1;
> + return -EBUSY;
>  
>   err = xenbus_map_ring_valloc(info->dev, _ref, 1, );
>   if (err)
> 


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

Re: [Xen-devel] [PATCH] build: fix dependencies for files compiled from their parent directory

[Jan Beulich]

>>> On 25.11.15 at 17:26,  wrote:
> On Wed, 2015-11-25 at 09:16 -0700, Jan Beulich wrote:
>> The use of $(basename ...) here was wrong (yet I'm sure I tested it).
> 
> Is the issue here that xen/arch/x86/x86_64/.compat.o.d ought really to be
> xen/arch/x86/.x86_64.compat.o.d?

No, xen/arch/x86/x86_64/.compat.o.d is the correct name. Just
that $(dir $(1)).$(basename $(notdir $(1))).d produces
xen/arch/x86/x86_64/.compat.d (i.e. strips the .o, which is not in
line with $(@D)/.$(@F).d used to generate those files), and hence
neither dependency tracking nor cleaning work.

Jan


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

Re: [Xen-devel] [PATCH v2 1/2] x86/VPMU: return correct fixed PMC count

[Jan Beulich]

>>> On 25.11.15 at 20:32,  wrote:
> On 11/25/2015 10:31 AM, Jan Beulich wrote:
>>> However, I just noticed that various control and status registers are
>>> not available for v1. I wonder whether we should even support version 1
>>> since we'd need to add whole lot of 'if (supported)' throughout the code
>>> plus there are some assumptions about existence of IA32_PERF_GLOBAL_CTRL
>>> so we'll need to add additional logic to handle that too. And it's not
>>> clear to me if it's all worth it.
>> Indeed, let's not support v1 then for now and leave the exercise
>> to add all the if()s to whoever cares for such support.
> 
> And, in fact, I think we should drop model check in core2_vpmu_init() 
> and only test for PMU version. Especially in light of XSA-163.
> 
> We could limit support to versions 2 and 3 only if we want to be on the 
> safe side.
> 
> If people agree I'll send a patch (on Monday).

Yes please.

Jan


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

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Jan Beulich]

>>> On 26.11.15 at 00:27,  wrote:
> A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and
> it yields similar results. Not surprising, since Fusion uses basically
> the same virtualization engine.
> 
> However, ESXi offers many more choices of number of processors, number
> of cores, hyperthreading, etc. The weird processor ID assignment (0,
> 2, 4, 6, ...) occurs only with 4 or 8 processors, 1 core per socket,
> and no hyperthreading. If I change any of these parameters, the
> processor IDs become sequential.
> 
> It appears in the 4- and 8-processor cases, VMware is emulating
> something like a Xeon E7340:
> https://github.com/deater/test_proc/blob/master/x86_64/x86_64.intel.6.15.11.
> xeon_e7340
> 
> In fact someone asked a question about running Xen on this platform
> way back when: 
> http://lists.xenproject.org/archives/html/xen-users/2008-05/msg00691.html 
> 
> Others of similar vintage assign processor IDs 0 and 3 on a
> 2-processor system:
> https://www.centos.org/forums/viewtopic.php?t=30255 
> 
> or even 0 and 6: 
> http://serverfault.com/questions/302429/interpreting-cpuinfo 
> 
> So there are real hardware platforms with non-sequential processor
> IDs. They are quite ancient and don't support CAT, but that doesn't
> rule out the possibility of a newer or future platform behaving
> similarly.

Not supporting CAT is not a criteria, since the socket data setup
happens unconditionally. However (and as said before), non-
sequential processor IDs are fine. Non-sequential socket IDs are
what is problematic.

Jan


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

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> Using deprecate gnutls_*_set() triggers a failure to compile
> with gnutls30-3.4.4, used on OpenSUSE factory:
> 
> ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to 
> `gnutls_kx_set_priority'
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to 
> `gnutls_certificate_type_set_priority'
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to 
> `gnutls_protocol_set_priority'
> 
> This compilation issue can be fixed by using the new routine
> gnutls_priority_set_direct() which replaces the deprecated calls
> which also simplifies the code considerably.


Thanks for posting that! It certainly fixes that issue.

I was wondering if you had seen these as well:

/home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
‘gnutls_anon_server_credentials’ is deprecated
[-Wdeprecated-declarations]
 {
 ^
/home/konrad/qemu-trad.git/vnc.c: In function
‘vnc_tls_initialize_anon_cred’:
/home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
‘gnutls_anon_server_credentials’ is deprecated
[-Wdeprecated-declarations]
 gnutls_anon_server_credentials anon_cred;
 ^
/home/konrad/qemu-trad.git/vnc.c: In function ‘vnc_start_tls’:
/home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
‘gnutls_anon_server_credentials’ is deprecated
[-Wdeprecated-declarations]
  gnutls_anon_server_credentials anon_cred =
vnc_tls_initialize_anon_cred();
  ^
?

(This is Fedora 23)
> 
> The following Coccinelle rule expresses the change in a general
> grammar form, this could be used should the code be rebased, or
> to do the transformation in other projects using the same gnutls
> library.
> 
> @ vars @
> identifier kx_x509, kx_anon, cert_type_priority, protocol_priority;
> declarer name NEED_X509_AUTH;
> @@
> 
> -int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> -int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
> -int kx_anon[] = { GNUTLS_KX_ANON_DH, 0};
> -int kx_x509[] = { GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, 
> GNUTLS_KX_SRP, 0};
> 
> @ calls_kx_set_priority @
> identifier vars.kx_x509, vars.kx_anon;
> expression need_x509;
> struct VncState *vs;
> @@
> 
> -if (gnutls_kx_set_priority(vs->tls_session, need_x509 ? kx_x509 : kx_anon) < 
> 0) {
> - gnutls_deinit(vs->tls_session);
> - vs->tls_session = NULL;
> - vnc_client_error(vs);
> - return -1;
> -}
> 
> @ calls_certificate_type_set_priority depends on calls_kx_set_priority @
> identifier vars.cert_type_priority;
> struct VncState *calls_kx_set_priority.vs;
> @@
> -if (gnutls_certificate_type_set_priority(vs->tls_session, 
> cert_type_priority) < 0) {
> - gnutls_deinit(vs->tls_session);
> - vs->tls_session = NULL;
> - vnc_client_error(vs);
> - return -1;
> -}
> 
> @ calls_protocol_set_priority depends on calls_certificate_type_set_priority @
> identifier vars.protocol_priority;
> struct VncState *calls_kx_set_priority.vs;
> expression calls_kx_set_priority.need_x509;
> @@
> 
> -if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
> - gnutls_deinit(vs->tls_session);
> - vs->tls_session = NULL;
> - vnc_client_error(vs);
> - return -1;
> -}
> +if (gnutls_priority_set_direct(vs->tls_session, need_x509 ? "NORMAL" : 
> "NORMAL:+ANON-DH", NULL) < 0) {
> + gnutls_deinit(vs->tls_session);
> + vs->tls_session = NULL;
> + vnc_client_error(vs);
> + return -1;
> +}
> 
> Generated-by: Coccinelle SmPL
> Cc: co...@systeme.lip6.fr
> Signed-off-by: Luis R. Rodriguez 
> ---
>  vnc.c | 21 +
>  1 file changed, 1 insertion(+), 20 deletions(-)
> 
> diff --git a/vnc.c b/vnc.c
> index 7629dfa18645..32c604084a5b 100644
> --- a/vnc.c
> +++ b/vnc.c
> @@ -2137,11 +2137,6 @@ static void vnc_handshake_io(void *opaque) {
>  
>  
>  static int vnc_start_tls(struct VncState *vs) {
> -static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> -static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, 
> GNUTLS_SSL3, 0 };
> -static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
> -static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, 
> GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
> -
>  VNC_DEBUG("Do TLS setup\n");
>  if (vnc_tls_initialize() < 0) {
>   VNC_DEBUG("Failed to init TLS\n");
> @@ -2161,21 +2156,7 @@ static int vnc_start_tls(struct VncState *vs) {
>   return -1;
>   }
>  
> - if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? 
> kx_x509 : kx_anon) < 0) {
> - gnutls_deinit(vs->tls_session);
> - vs->tls_session = NULL;
> - vnc_client_error(vs);
> - return -1;
> - }
> -
> - if (gnutls_certificate_type_set_priority(vs->tls_session, 
> cert_type_priority) < 0) {
> - 

[Xen-devel] [PATCH v2 0/2] libxl: change libxl__xs_mkdir() to libxl__xs_mknod()

[Paul Durrant]

Patch #1 is purely a search and replace
Patch #2 changes the underlying implementation

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

Re: [Xen-devel] [PATCH XEN v5 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.

[Ian Campbell]

On Tue, 2015-11-24 at 09:34 +, Ian Campbell wrote:
> Thinking about this some more overnight, it occurred to me that the
> real issue is that gnttab and gntshr are actually two quite difference
> APIs. gnttab is all about consuming grant references which are given to
> you from elsewhere while gntshr is all about creating grant references
> to give to others. They have relatively little in common wrt the
> underlying infrastructure, e.g. gnttab is mostly about making GNTTABOP
> hypercalls while gntshr mostly interacts with the kernel's grant ref
> allocator with no interaction with the hypervisor.
> 
> Maybe that and the API issues above constitute an argument for not
> combining, I'm really not sure.

Ian and I discussed this (briefly) in real life and based on the above
argumentation we decided that keeping the two APIs separate (but in the
same library) was justified, since there is a reasonable enough air gap
between their functionality (i.e. consuming vs producing grants).

We did wonder a bit about changing the names to make that divide clearer,
but couldn't think of anything especially compelling and decided to stick
with the current shade of yellow.

Ian.


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

[Xen-devel] [PATCH v2 1/2] libxl: replace libxl__xs_mkdir() with libxl__xs_mknod()

[Paul Durrant]

This patch is purely cosmetic, it contains no functional change. A
change in the implementation of libxl__xs_mknod() will be made in a
subsequent patch.

Signed-off-by: Paul Durrant 
Acked-by: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_create.c   | 26 +-
 tools/libxl/libxl_internal.h |  2 +-
 tools/libxl/libxl_xshelp.c   |  2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8770486..673e537 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -583,43 +583,43 @@ retry_transaction:
 t = xs_transaction_start(ctx->xsh);
 
 xs_rm(ctx->xsh, t, dom_path);
-libxl__xs_mkdir(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
+libxl__xs_mknod(gc, t, dom_path, roperm, ARRAY_SIZE(roperm));
 
 xs_rm(ctx->xsh, t, vm_path);
-libxl__xs_mkdir(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
+libxl__xs_mknod(gc, t, vm_path, roperm, ARRAY_SIZE(roperm));
 
 xs_rm(ctx->xsh, t, libxl_path);
-libxl__xs_mkdir(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
+libxl__xs_mknod(gc, t, libxl_path, noperm, ARRAY_SIZE(noperm));
 
 xs_write(ctx->xsh, t, GCSPRINTF("%s/vm", dom_path), vm_path, 
strlen(vm_path));
 rc = libxl__domain_rename(gc, *domid, 0, info->name, t);
 if (rc)
 goto out;
 
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/cpu", dom_path),
 roperm, ARRAY_SIZE(roperm));
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/memory", dom_path),
 roperm, ARRAY_SIZE(roperm));
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/device", dom_path),
 roperm, ARRAY_SIZE(roperm));
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/control", dom_path),
 roperm, ARRAY_SIZE(roperm));
 if (info->type == LIBXL_DOMAIN_TYPE_HVM)
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/hvmloader", dom_path),
 roperm, ARRAY_SIZE(roperm));
 
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/control/shutdown", dom_path),
 rwperm, ARRAY_SIZE(rwperm));
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/device/suspend/event-channel", dom_path),
 rwperm, ARRAY_SIZE(rwperm));
-libxl__xs_mkdir(gc, t,
+libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/data", dom_path),
 rwperm, ARRAY_SIZE(rwperm));
 
@@ -628,13 +628,13 @@ retry_transaction:
  * Create a local "libxl" directory for each guest, since we might want
  * to use libxl from inside the guest
  */
-libxl__xs_mkdir(gc, t, GCSPRINTF("%s/libxl", dom_path), rwperm,
+libxl__xs_mknod(gc, t, GCSPRINTF("%s/libxl", dom_path), rwperm,
 ARRAY_SIZE(rwperm));
 /*
  * Create a local "device-model" directory for each guest, since we
  * might want to use Qemu from inside the guest
  */
-libxl__xs_mkdir(gc, t, GCSPRINTF("%s/device-model", dom_path), rwperm,
+libxl__xs_mknod(gc, t, GCSPRINTF("%s/device-model", dom_path), rwperm,
 ARRAY_SIZE(rwperm));
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 58d07cd..a671a61 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -680,7 +680,7 @@ _hidden char *libxl__xs_read(libxl__gc *gc, 
xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
const char *path, unsigned int *nb);
/* On error: returns NULL, sets errno (no logging) */
-_hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+_hidden bool libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
  const char *path, struct xs_permissions *perms,
 unsigned int num_perms);
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index bc60b9a..cb6a559 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -147,7 +147,7 @@ char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t 
t,
 return ret;
 }
 
-bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
+bool libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
  const char *path, struct xs_permissions *perms,
 unsigned int num_perms)
 {
-- 
2.1.4


___
Xen-devel mailing list

Re: [Xen-devel] [PATCH for-2.5] vnc: fix segfault

[Anthony PERARD]

On Wed, Nov 25, 2015 at 08:09:58AM +0100, Gerd Hoffmann wrote:
> Commit "c7628bf vnc: only alloc server surface with clients connected"
> missed one rarely used codepath (cirrus with guest drivers using 2d
> accel) where we have to check for the server surface being present,
> to avoid qemu crashing with a NULL pointer dereference.  Add the check.
> 
> Reported-by: Anthony PERARD 
> Signed-off-by: Gerd Hoffmann 

This works for me.

Thanks.

> ---
>  ui/vnc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/ui/vnc.c b/ui/vnc.c
> index c9f2fed..7538405 100644
> --- a/ui/vnc.c
> +++ b/ui/vnc.c
> @@ -931,6 +931,11 @@ static void vnc_dpy_copy(DisplayChangeListener *dcl,
>  int i, x, y, pitch, inc, w_lim, s;
>  int cmp_bytes;
>  
> +if (!vd->server) {
> +/* no client connected */
> +return;
> +}
> +
>  vnc_refresh_server_surface(vd);
>  QTAILQ_FOREACH_SAFE(vs, >clients, next, vn) {
>  if (vnc_has_feature(vs, VNC_FEATURE_COPYRECT)) {
> -- 
> 1.8.3.1
> 

-- 
Anthony PERARD

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

[Xen-devel] [PATCH v2 2/2] libxl: implement libxl__xs_mknod using XS_WRITE rather than XS_MKDIR

[Paul Durrant]

This patch modifies the implentation of libxl__xs_mknod() to use XS_WRITE
rather than XS_MKDIR since passing an empty value to the former will
ensure that the path is both existent and empty upon return, rather than
merely existent. The function return type is also changed to a libxl
error value rather than a boolean, it's declaration is accordingly moved
into the 'checked' section in libxl_internal.h, and a comment is added to
clarify its semantics.

This patch also contains as small whitespace fix in the definition of
libxl__xs_mknod() and the addition of 'ok' to CODING_STYLE as the
canonical variable name for holding return values from boolean functions.

Signed-off-by: Paul Durrant 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---

v2:
 - Add logging should libxl__xs_mknod() fail
 - Clarify semantics of libxl__xs_mknod() in libxl_internal.h
 - Re-word use ok 'ok' in libxl/CODING_STYLE
---
 tools/libxl/CODING_STYLE |  1 +
 tools/libxl/libxl_internal.h |  9 +
 tools/libxl/libxl_xshelp.c   | 24 ++--
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
index 919bcc6..522d1c9 100644
--- a/tools/libxl/CODING_STYLE
+++ b/tools/libxl/CODING_STYLE
@@ -35,6 +35,7 @@ The following local variable names should be used where 
applicable:
 
   int rc;/* a libxl error code - and not anything else */
   int r; /* the return value from a system call (or libxc call) */
+  bool ok;   /* the success return value from a boolean function */
 
   uint32_t domid;
   libxl__gc *gc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a671a61..d2bda0a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -680,10 +680,6 @@ _hidden char *libxl__xs_read(libxl__gc *gc, 
xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
const char *path, unsigned int *nb);
/* On error: returns NULL, sets errno (no logging) */
-_hidden bool libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
- const char *path, struct xs_permissions *perms,
-unsigned int num_perms);
-
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
 
@@ -692,6 +688,11 @@ _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t 
domid);
  * fails it logs and returns ERROR_FAIL.
  */
 
+/* On success, path will exist and will have an empty value */
+int libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
+const char *path, struct xs_permissions *perms,
+unsigned int num_perms);
+
 /* On success, *result_out came from the gc.
  * On error, *result_out is undefined.
  * ENOENT counts as success but sets *result_out=0
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index cb6a559..8554ee5 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -147,14 +147,26 @@ char **libxl__xs_directory(libxl__gc *gc, 
xs_transaction_t t,
 return ret;
 }
 
-bool libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
- const char *path, struct xs_permissions *perms,
-unsigned int num_perms)
+int libxl__xs_mknod(libxl__gc *gc, xs_transaction_t t,
+const char *path, struct xs_permissions *perms,
+unsigned int num_perms)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
-if (!xs_mkdir(ctx->xsh, t, path))
-return false;
-return xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+bool ok;
+
+ok = xs_write(ctx->xsh, t, path, "", 0);
+if (!ok) {
+LOGE(ERROR, "xenstore write failed: `%s' = ''", path);
+return ERROR_FAIL;
+}
+
+ok = xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
+if (!ok) {
+LOGE(ERROR, "xenstore set permissions failed on `%s'", path);
+return ERROR_FAIL;
+}
+
+return 0;
 }
 
 char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 2/2] x86/VPMU: implement ipc and arch filter flags

[Boris Ostrovsky]

On 11/24/2015 06:53 PM, Brendan Gregg wrote:

This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.

Signed-off-by: Brendan Gregg 
---
  docs/misc/xen-command-line.markdown | 14 +-
  xen/arch/x86/cpu/vpmu.c | 51 +
  xen/arch/x86/cpu/vpmu_intel.c   | 48 ++
  xen/include/asm-x86/msr-index.h |  1 +
  xen/include/public/pmu.h| 14 --
  5 files changed, 115 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 70daa84..6055a68 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1452,7 +1452,7 @@ Use Virtual Processor ID support if available.  This 
prevents the need for TLB
  flushes on VM entry and exit, increasing performance.
  
  ### vpmu

-> `= ( bts )`
+> `= (  | { bts | ipc | arch [, ...] } )`
  
  > Default: `off`
  
@@ -1468,6 +1468,18 @@ wrong behaviour (see handle\_pmc\_quirk()).

  If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
  feature is switched on on Intel processors supporting this feature.
  
+vpmu=ipc enables performance monitoring, but restricts the counters to the

+most minimum set possible: instructions, cycles, and reference cycles. These
+can be used to calculate instructions per cycle (IPC).
+
+vpmu=arch enables performance monitoring, but restricts the counters to the
+pre-defined architectural events only. These are exposed by cpuid, and listed
+in Table 18-1 from the Intel 64 and IA-32 Architectures Software Developer's
+Manual, Volume 3B, System Programming Guide, Part 2.
+
+If a boolean is not used, combinations of flags are allowed, comma separated.
+For example, vpmu=arch,bts.
+
  Note that if **watchdog** option is also specified vpmu will be turned off.
  
  *Warning:*

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 2f5156a..bb0ca37 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -43,33 +43,64 @@ CHECK_pmu_data;
  CHECK_pmu_params;
  
  /*

- * "vpmu" : vpmu generally enabled
- * "vpmu=off" : vpmu generally disabled
- * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu" : vpmu generally enabled (all counters)
+ * "vpmu=off"  : vpmu generally disabled
+ * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
+ * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
+ * flag combinations are allowed, eg, "vpmu=ipc,bts".
   */
  static unsigned int __read_mostly opt_vpmu_enabled;
  unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
  unsigned int __read_mostly vpmu_features = 0;
-static void parse_vpmu_param(char *s);
-custom_param("vpmu", parse_vpmu_param);
+static void parse_vpmu_params(char *s);
+custom_param("vpmu", parse_vpmu_params);
  
  static DEFINE_SPINLOCK(vpmu_lock);

  static unsigned vpmu_count;
  
  static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
  
-static void __init parse_vpmu_param(char *s)

+static int parse_vpmu_param(char *s, int len)
  {
+if ( ! *s || ! len )
+return 0;
+if ( !strncmp(s, "bts", len) )
+vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+else if ( !strncmp(s, "ipc", len) )
+vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
+else if ( !strncmp(s, "arch", len) )
+vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
+else if ( *s )


Why not just "else return 1;" ? We've already tested above that *s is 
not '\0'. (And you don't need curly braces for single-line clauses)




+{
+return 1;
+}
+return 0;
+}
+
+static void __init parse_vpmu_params(char *s)
+{
+bool_t badflag = 0;
+char *sep, *p = s;
+
  switch ( parse_bool(s) )
  {
  case 0:
  break;
  default:
-if ( !strcmp(s, "bts") )
-vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-else if ( *s )
+sep = strchr(p, ',');
+while (sep != NULL)
+{
+if ( parse_vpmu_param(p, sep - p) )
+badflag = 1;
+p = sep + 1;
+sep = strchr(p, ',');
+}
+sep = strchr(p, 0);
+parse_vpmu_param(p, sep - p);


This can find unsupported flag too but we are not setting badflag so we 
will miss it (i.e. "vpmu=foo").


Can you just say something like
sep = strchr(p, ',')
if ( sep == NULL )
sep = strchr(p, 0);

and keep both parse_vpmu_param() invocations in a single loop? And then, 
instead of having badflags simply print the warning and break.



+if ( badflag )
  {
-printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
+printk("VPMU: unknown flags: %s - vpmu 

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Andrew Cooper]

On 25/11/15 10:49, Jan Beulich wrote:
 On 25.11.15 at 11:28,  wrote:
>> On 24/11/15 17:41, Jan Beulich wrote:
>> On 24.11.15 at 18:17,  wrote:
 --- a/xen/drivers/passthrough/vtd/quirks.c
 +++ b/xen/drivers/passthrough/vtd/quirks.c
 @@ -320,6 +320,20 @@ void __init platform_quirks_init(void)
  /* Tylersburg interrupt remap quirk */
  if ( iommu_intremap )
  tylersburg_intremap_quirk();
 +
 +/*
 + * Disable shared EPT ("sharept") on Sandybridge and older processors
 + * by default.
 + * SandyBridge has no huge page support for IOTLB which leads to 
 fallback
 + * on 4k pages and leads to performance degradation.
 + *
 + * Shared EPT ("sharept") will be disabled only if user has not
 + * provided explicit choice on the command line thus 
 iommu_hap_pt_share is
 + * at its initialized value of -1.
 + */
 +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F ||
 +  boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == -1) 
 )
 +iommu_hap_pt_share = 0;
>>> If we really want to do this, then I think we should key this on
>>> EPT but not VT-d having 2M support, instead of on CPU models.
>> This check is already performed by vtd_ept_page_compatible()
> Yeah, I realized there would be such a check on the way home.
>
>> The problem is that SandyBridge IOMMUs advertise 2M support and do
>> function with it, but cannot cache 2MB translations in the IOTLBs.
>>
>> As a result, attempting to use 2M translations causes substantially
>> worse performance than 4K translations.
> So commit message and comment should make this more explicit,
> to avoid the impression "IOTLB" isn't just the relatively common
> mis-naming of "IOMMU".
>
> Plus I guess the sharing won't need suppressing if !opt_hap_2mb?
>
> Further the model based check is relatively broad, and includes
> Atoms (0x36 actually is one), which can't be considered "Sandybridge
> or older" imo.
>
> And finally I'm not fully convinced using CPU model info to deduce
> chipset behavior is entirely correct (albeit perhaps in practice it'll
> be fine except maybe when running Xen itself virtualized).

What else would you suggest? I can't think of any better identifying
information.

~Andrew

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

[Xen-devel] [PATCH v4 1/4] xen/save: pass a size parameter to the HVM compat functions

[Roger Pau Monne]

In order to cope with types having multiple compat versions pass a size
parameter to the fixup function so we can identify which compat version
Xen is dealing with.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Tim Deegan 
---
Changes since v3:
 - Add Andrew Cooper Reviewed-by.
 - s/d/desc/ in the _hvm_load_entry macro.

Changes since v2:
 - Size is uint32_t not int.
 - Pass the actual size of the record and not the size of the whole stream.
---
 xen/include/public/arch-x86/hvm/save.h |  2 +-
 xen/include/public/hvm/save.h  | 10 ++
 xen/include/xen/hvm/save.h |  4 +++-
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index efb0b62..29d513c 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -268,7 +268,7 @@ struct hvm_hw_cpu_compat {
 uint32_t error_code;
 };
 
-static inline int _hvm_hw_fix_cpu(void *h) {
+static inline int _hvm_hw_fix_cpu(void *h, uint32_t size) {
 
 union hvm_hw_cpu_union {
 struct hvm_hw_cpu nat;
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index cc8b5fd..0bd240d 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -63,13 +63,15 @@ struct hvm_save_descriptor {
 
 #ifdef __XEN__
 # define DECLARE_HVM_SAVE_TYPE_COMPAT(_x, _code, _type, _ctype, _fix) \
-static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h) { return _fix(h); } \
-struct __HVM_SAVE_TYPE_##_x { _type t; char c[_code]; char cpt[2];}; \
+static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h, uint32_t size)  \
+{ return _fix(h, size); } \
+struct __HVM_SAVE_TYPE_##_x { _type t; char c[_code]; char cpt[2];};  \
 struct __HVM_SAVE_TYPE_COMPAT_##_x { _ctype t; }   
 
 # include  /* BUG() */
 # define DECLARE_HVM_SAVE_TYPE(_x, _code, _type) \
-static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h) { BUG(); return -1; 
} \
+static inline int __HVM_SAVE_FIX_COMPAT_##_x(void *h, uint32_t size) \
+{ BUG(); return -1; }\
 struct __HVM_SAVE_TYPE_##_x { _type t; char c[_code]; char cpt[1];}; \
 struct __HVM_SAVE_TYPE_COMPAT_##_x { _type t; }   
 #else
@@ -89,7 +91,7 @@ struct hvm_save_descriptor {
 # define HVM_SAVE_LENGTH_COMPAT(_x) (sizeof (HVM_SAVE_TYPE_COMPAT(_x)))
 
 # define HVM_SAVE_HAS_COMPAT(_x) (sizeof (((struct __HVM_SAVE_TYPE_##_x 
*)(0))->cpt)-1)
-# define HVM_SAVE_FIX_COMPAT(_x, _dst) __HVM_SAVE_FIX_COMPAT_##_x(_dst)
+# define HVM_SAVE_FIX_COMPAT(_x, _dst, _size) __HVM_SAVE_FIX_COMPAT_##_x(_dst, 
_size)
 #endif
 
 /* 
diff --git a/xen/include/xen/hvm/save.h b/xen/include/xen/hvm/save.h
index aa27a50..51bc7d5 100644
--- a/xen/include/xen/hvm/save.h
+++ b/xen/include/xen/hvm/save.h
@@ -60,6 +60,8 @@ void _hvm_read_entry(struct hvm_domain_context *h,
  */
 #define _hvm_load_entry(_x, _h, _dst, _strict) ({   \
 int r;  \
+struct hvm_save_descriptor *desc\
+= (struct hvm_save_descriptor *)&(_h)->data[(_h)->cur]; \
 if ( (r = _hvm_check_entry((_h), HVM_SAVE_CODE(_x), \
HVM_SAVE_LENGTH(_x), (_strict))) == 0 )  \
 _hvm_read_entry((_h), (_dst), HVM_SAVE_LENGTH(_x)); \
@@ -67,7 +69,7 @@ void _hvm_read_entry(struct hvm_domain_context *h,
  && (r = _hvm_check_entry((_h), HVM_SAVE_CODE(_x),  \
HVM_SAVE_LENGTH_COMPAT(_x), (_strict))) == 0 ) { \
 _hvm_read_entry((_h), (_dst), HVM_SAVE_LENGTH_COMPAT(_x));  \
-r=HVM_SAVE_FIX_COMPAT(_x, (_dst));  \
+r = HVM_SAVE_FIX_COMPAT(_x, (_dst), desc->length);  \
 }   \
 r; })
 
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v4 2/4] xen/save: allow the usage of zeroextend and a fixup function

[Roger Pau Monne]

With the current compat implementation in the save/restore context handling,
only one compat structure is allowed, and using _zeroextend prevents the
fixup function from being called.

In order to allow for the compat handling layer to be able to handle
different compat versions allow calling the fixup function with
hvm_load_entry_zeroextend.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Tim Deegan 
---
Changes since v3:
 - Split the if condition in order to avoid changing the '\' delimiters.
 - Add Andrew Cooper Reviewed by.
---
 xen/include/xen/hvm/save.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/include/xen/hvm/save.h b/xen/include/xen/hvm/save.h
index 51bc7d5..a9a78f9 100644
--- a/xen/include/xen/hvm/save.h
+++ b/xen/include/xen/hvm/save.h
@@ -64,7 +64,12 @@ void _hvm_read_entry(struct hvm_domain_context *h,
 = (struct hvm_save_descriptor *)&(_h)->data[(_h)->cur]; \
 if ( (r = _hvm_check_entry((_h), HVM_SAVE_CODE(_x), \
HVM_SAVE_LENGTH(_x), (_strict))) == 0 )  \
+{   \
 _hvm_read_entry((_h), (_dst), HVM_SAVE_LENGTH(_x)); \
+if ( HVM_SAVE_HAS_COMPAT(_x) && \
+ desc->length != HVM_SAVE_LENGTH(_x) )  \
+r = HVM_SAVE_FIX_COMPAT(_x, (_dst), desc->length);  \
+}   \
 else if (HVM_SAVE_HAS_COMPAT(_x)\
  && (r = _hvm_check_entry((_h), HVM_SAVE_CODE(_x),  \
HVM_SAVE_LENGTH_COMPAT(_x), (_strict))) == 0 ) { \
-- 
1.9.5 (Apple Git-50.3)


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

Re: [Xen-devel] [PATCH v5 6/9] libxc: create unmapped initrd in domain builder if supported

[Juergen Gross]

On 25/11/15 17:12, Boris Ostrovsky wrote:
> On 11/12/2015 08:43 AM, Juergen Gross wrote:
>> In case the kernel of a new pv-domU indicates it is supporting an
>> unmapped initrd, don't waste precious virtual space for the initrd,
>> but allocate only guest physical memory for it.
> 
> This patch breaks 32-bit pygrub.
> 
> I am not 100% sure yet but it may be that only 64-bit guests are affected.
> 
> With RHEL5 I get
> initrd extends beyond end of memory (0x780080eda000 > 0x4000)

I think I have found the problem. Can you verify the attached patch is
working?


Juergen

>From 11eaee2aa2291a1d56556d538ac23b8156cf3388 Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Thu, 26 Nov 2015 08:32:26 +0100
Subject: [PATCH] libxc: correct domain builder for 64 bit guest with 32 bit
 tools

Commit 8c45adec18e0512c3d34dcafb13414ecba21be6a ("create unmapped
initrd in domain builder if supported") introduced an error for
building a 64 bit guest with a 32 bit toolset.

The initrd start address and size where stored in an unsigned long
instead of using a 64 bit type.

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 2176216..370 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -99,8 +99,8 @@ struct xc_dom_image {
 xen_vaddr_t bsd_symtab_start;
 
 /* initrd parameters as specified in start_info page */
-unsigned long initrd_start;
-unsigned long initrd_len;
+uint64_t initrd_start;
+uint64_t initrd_len;
 
 unsigned int alloc_bootstack;
 xen_vaddr_t virt_pgtab_end;
-- 
2.6.2

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

[Xen-devel] [linux-next test] 65101: tolerable trouble: broken/fail/pass

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  3 host-install(3) broken REGR. vs. 65059
 test-amd64-i386-xl6 xen-boot fail   like 65059
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail like 65059
 test-amd64-amd64-xl   6 xen-boot fail   like 65059
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot   fail like 65059
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail  like 65059
 test-amd64-i386-rumpuserxen-i386  6 xen-boot   fail like 65059
 test-amd64-i386-xl-raw6 xen-boot fail   like 65059
 test-amd64-amd64-rumpuserxen-amd64  6 xen-boot fail like 65059
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail like 65059
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-boot fail like 65059
 test-amd64-amd64-pygrub   6 xen-boot fail   like 65059
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail like 65059
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail like 65059
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 65059
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail like 65059
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  6 xen-boot fail like 65059
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail like 65059
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail like 65059
 test-amd64-i386-libvirt   6 xen-boot fail   like 65059
 test-amd64-amd64-xl-xsm   6 xen-boot fail   like 65059
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail like 65059
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail like 65059
 test-amd64-amd64-libvirt-vhd  6 xen-boot fail   like 65059
 test-amd64-i386-libvirt-xsm   6 xen-boot fail   like 65059
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-bootfail like 65059
 test-amd64-amd64-xl-pvh-amd   6 xen-boot fail   like 65059
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot fail like 65059
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail like 65059
 test-amd64-i386-xl-xsm6 xen-boot fail   like 65059
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-bootfail like 65059
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail like 65059
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot   fail like 65059
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot   fail like 65059
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot  fail like 65059
 test-amd64-amd64-xl-qcow2 6 xen-boot fail   like 65059
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot   fail like 65059
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail like 65059
 test-amd64-i386-freebsd10-i386  6 xen-boot fail like 65059
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-boot fail like 65059
 test-amd64-amd64-libvirt-xsm  6 xen-boot fail   like 65059
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot   fail like 65059
 test-amd64-amd64-i386-pvgrub  6 xen-boot fail   like 65059
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail  like 65059
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail like 65059
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail like 65059
 test-armhf-armhf-xl-arndale   6 xen-boot fail   like 65059
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail like 65059
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 65059
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail like 
65059
 test-armhf-armhf-xl   6 xen-boot fail   like 65059
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 65059
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 65059
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   like 65059
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail like 65059
 test-armhf-armhf-xl-vhd   6 xen-boot fail   like 65059
 test-amd64-amd64-pair10 xen-boot/dst_hostfail   like 65059
 test-amd64-amd64-pair 9 xen-boot/src_hostfail   like 65059
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail like 65059
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot   fail like 65059
 

Re: [Xen-devel] [PATCH v5 00/10] xen-block: multi hardware-queues/rings support

[Bob Liu]

On 11/26/2015 10:57 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 26, 2015 at 10:28:10AM +0800, Bob Liu wrote:
>>
>> On 11/26/2015 06:12 AM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
 On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
>>   xen/blkback: separate ring information out of struct xen_blkif
>>   xen/blkback: pseudo support for multi hardware queues/rings
>>   xen/blkback: get the number of hardware queues/rings from blkfront
>>   xen/blkback: make pool of persistent grants and free pages per-queue
>
> OK, got to those as well. I have put them in 'devel/for-jens-4.5' and
> are going to test them overnight before pushing them out.
>
> I see two bugs in the code that we MUST deal with:
>
>  - print_stats () is going to show zero values.
>  - the sysfs code (VBD_SHOW) aren't converted over to fetch data
>from all the rings.

 - kthread_run can't handle the two "name, i" arguments. I see:

 root  5101 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
 root  5102 2  0 20:47 ?00:00:00 [blkback.3.xvda-]
>>>
>>> And doing save/restore:
>>>
>>> xl save  /tmp/A;
>>> xl restore /tmp/A;
>>>
>>> ends up us loosing the proper state and not getting the ring setup back.
>>> I see this is backend:
>>>
>>> [ 2719.448600] vbd vbd-22-51712: -1 guest requested 0 queues, exceeding the 
>>> maximum of 3.
>>>
>>> And XenStore agrees:
>>> tool = ""
>>>  xenstored = ""
>>> local = ""
>>>  domain = ""
>>>   0 = ""
>>>domid = "0"
>>>name = "Domain-0"
>>>device-model = ""
>>> 0 = ""
>>>  state = "running"
>>>error = ""
>>> backend = ""
>>>  vbd = ""
>>>   2 = ""
>>>51712 = ""
>>> error = "-1 guest requested 0 queues, exceeding the maximum of 3."
>>>
>>> .. which also leads to a memory leak as xen_blkbk_remove never gets
>>> called.
>>
>> I think which was already fix by your patch:
>> [PATCH RFC 2/2] xen/blkback: Free resources if connect_ring failed.
> 
> Nope. I get that with or without the patch.
> 

Attached patch should fix this issue. 

-- 
Regards,
-Bob
>From f297a05fc27fb0bc9a3ed15407f8cc6ffd5e2a00 Mon Sep 17 00:00:00 2001
From: Bob Liu 
Date: Wed, 25 Nov 2015 14:56:32 -0500
Subject: [PATCH 1/2] xen:blkfront: fix compile error
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fix this build error:
drivers/block/xen-blkfront.c: In function ‘blkif_free’:
drivers/block/xen-blkfront.c:1234:6: error: ‘struct blkfront_info’ has no
member named ‘ring’ info->ring = NULL;

Signed-off-by: Bob Liu 
---
 drivers/block/xen-blkfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 625604d..ef5ce43 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1231,7 +1231,7 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 		blkif_free_ring(>rinfo[i]);

 	kfree(info->rinfo);
-	info->ring = NULL;
+	info->rinfo = NULL;
 	info->nr_rings = 0;
 }

--
1.8.3.1

>From aab0bb1690213e665966ea22b021e0eeaacfc717 Mon Sep 17 00:00:00 2001
From: Bob Liu 
Date: Wed, 25 Nov 2015 17:52:55 -0500
Subject: [PATCH 2/2] xen/blkfront: realloc ring info in blkif_resume

Need to reallocate ring info in the resume path, because info->rinfo was freed
in blkif_free(). And 'multi-queue-max-queues' backend reports may have been
changed.

Signed-off-by: Bob Liu 
---
 drivers/block/xen-blkfront.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index ef5ce43..9634a65 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1926,12 +1926,38 @@ static int blkif_recover(struct blkfront_info *info)
 static int blkfront_resume(struct xenbus_device *dev)
 {
 	struct blkfront_info *info = dev_get_drvdata(>dev);
-	int err;
+	int err = 0;
+	unsigned int max_queues = 0, r_index;
 
 	dev_dbg(>dev, "blkfront_resume: %s\n", dev->nodename);
 
 	blkif_free(info, info->connected == BLKIF_STATE_CONNECTED);
 
+	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			"multi-queue-max-queues", "%u", _queues, NULL);
+	if (err)
+		max_queues = 1;
+
+	info->nr_rings = min(max_queues, xen_blkif_max_queues);
+	/* We need at least one ring. */
+	if (!info->nr_rings)
+		info->nr_rings = 1;
+
+	info->rinfo = kzalloc(sizeof(struct blkfront_ring_info) * info->nr_rings, GFP_KERNEL);
+	if (!info->rinfo)
+		return -ENOMEM;
+
+	for (r_index = 0; r_index < info->nr_rings; r_index++) {
+		struct blkfront_ring_info *rinfo;
+
+		rinfo = >rinfo[r_index];
+		INIT_LIST_HEAD(>indirect_pages);
+		INIT_LIST_HEAD(>grants);
+		rinfo->dev_info = info;
+		INIT_WORK(>work, blkif_restart_queue);
+		

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Tian, Kevin]

> From: Malcolm Crossley [mailto:malcolm.cross...@citrix.com]
> Sent: Wednesday, November 25, 2015 11:59 PM
> 
> On 25/11/15 15:38, Jan Beulich wrote:
>  On 25.11.15 at 16:13,  wrote:
> >> On 25/11/15 10:49, Jan Beulich wrote:
> >> On 25.11.15 at 11:28,  wrote:
>  On 24/11/15 17:41, Jan Beulich wrote:
>  On 24.11.15 at 18:17,  wrote:
> >> --- a/xen/drivers/passthrough/vtd/quirks.c
> >> +++ b/xen/drivers/passthrough/vtd/quirks.c
> >> @@ -320,6 +320,20 @@ void __init platform_quirks_init(void)
> >>  /* Tylersburg interrupt remap quirk */
> >>  if ( iommu_intremap )
> >>  tylersburg_intremap_quirk();
> >> +
> >> +/*
> >> + * Disable shared EPT ("sharept") on Sandybridge and older 
> >> processors
> >> + * by default.
> >> + * SandyBridge has no huge page support for IOTLB which leads to
> >> fallback
> >> + * on 4k pages and leads to performance degradation.
> >> + *
> >> + * Shared EPT ("sharept") will be disabled only if user has not
> >> + * provided explicit choice on the command line thus 
> >> iommu_hap_pt_share
> >> is
> >> + * at its initialized value of -1.
> >> + */
> >> +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 
> >> 0x2F
> ||
> >> +  boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share ==
> -1) )
> >> +iommu_hap_pt_share = 0;
> > If we really want to do this, then I think we should key this on
> > EPT but not VT-d having 2M support, instead of on CPU models.
>  This check is already performed by vtd_ept_page_compatible()
> >>> Yeah, I realized there would be such a check on the way home.
> >>>
>  The problem is that SandyBridge IOMMUs advertise 2M support and do
>  function with it, but cannot cache 2MB translations in the IOTLBs.
> 
>  As a result, attempting to use 2M translations causes substantially
>  worse performance than 4K translations.
> >>> So commit message and comment should make this more explicit,
> >>> to avoid the impression "IOTLB" isn't just the relatively common
> >>> mis-naming of "IOMMU".
> >>>
> >>> Plus I guess the sharing won't need suppressing if !opt_hap_2mb?
> >>>
> >>> Further the model based check is relatively broad, and includes
> >>> Atoms (0x36 actually is one), which can't be considered "Sandybridge
> >>> or older" imo.
> >>>
> >>> And finally I'm not fully convinced using CPU model info to deduce
> >>> chipset behavior is entirely correct (albeit perhaps in practice it'll
> >>> be fine except maybe when running Xen itself virtualized).
> >>
> >> What else would you suggest? I can't think of any better identifying
> >> information.
> >
> > Chipset IDs / revisions?
> 
> In this case the IOMMU is integrated into the Sandybridge-EP processor itself.
> Unfortunately there's no register to query the IOTLB configuration of the 
> IOMMU
> and so we're stuck identifying the via the processor model number itself.
> 
> Malcolm
> 

I'm OK to use processor model here, though ideally Jan is right. :-)

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v2 1/2] x86/VPMU: return correct fixed PMC count

[Dietmar Hahn]

Am Dienstag 24 November 2015, 15:53:11 schrieb Brendan Gregg:
> Fixes a register typo.
> 
> Signed-off-by: Brendan Gregg 
> ---
>  xen/arch/x86/cpu/vpmu_intel.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Dietmar Hahn 

> 
> diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
> index 12f80ae..8d83a1a 100644
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -166,10 +166,10 @@ static int core2_get_arch_pmc_count(void)
>   */
>  static int core2_get_fixed_pmc_count(void)
>  {
> -u32 eax;
> +u32 edx;
>  
> -eax = cpuid_eax(0xa);
> -return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
> +edx = cpuid_edx(0xa);
> +return MASK_EXTR(edx, PMU_FIXED_NR_MASK);
>  }
>  
>  /* edx bits 5-12: Bit width of fixed-function performance counters  */
> 

-- 
Company details: http://ts.fujitsu.com/imprint.html

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

Re: [Xen-devel] [PATCH V9 0/7] xen pvusb toolstack work

[Chun Yan Liu]

According to current active discussion:
libxl: Introduce a template for devices with a controller
https://www.mail-archive.com/xen-devel@lists.xen.org/msg46720.html

Will update naming and RESEND.

- Chunyan

>>> On 11/24/2015 at 04:35 PM, in message
<1448354134-21644-1-git-send-email-cy...@suse.com>, Chunyan Liu
 wrote: 
> This patch series is to add pvusb toolstack work, supporting hot add|remove 
> USB device to|from guest and specify USB device in domain configuration  
> file. 
>  
> Changes to V8: 
> * lots of changes in libxl pvusb API (patch 3/7) 
> * update 2/7 to write separate read_sysfs_file function 
> * address all other comments 
>  
> V8: 
> http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html 
>  
> V7: 
> http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html 
>  
> V6: 
> http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html 
>  
> V5: 
> http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html 
>  
> V4: 
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html 
>  
> Related Discussion Threads: 
> http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html 
> http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html 
>  
>   <<< pvusb work introduction >>> 
>  
> 1. Overview 
>  
> There are two general methods for passing through individual host 
> devices to a guest. The first is via an emulated USB device 
> controller; the second is PVUSB. 
>  
> Additionally, there are two ways to add USB devices to a guest: via 
> the config file at domain creation time, and via hot-plug while the VM 
> is running. 
>  
> * Emulated USB 
>  
> In emulated USB, the device model (qemu) presents an emulated USB 
> controller to the guest. The device model process then grabs control 
> of the device from domain 0 and and passes the USB commands between 
> the guest OS and the host USB device. 
>  
> This method is only available to HVM domains, and is not available for 
> domains running with device model stubdomains. 
>  
> * PVUSB 
>  
> PVUSB uses a paravirtialized front-end/back-end interface, similar to 
> the traditional Xen PV network and disk protocols. In order to use 
> PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
> your USB driver domain). 
>  
> 2. Specifying a host USB device 
>  
> QEMU qmp commands allows USB devices to be specified either by their 
> bus address (in the form bus.device) or their device tag (in the form 
> vendorid:deviceid). 
>  
> Each way of specifying has its advantages: 
>  
> Specifying by device tag will always get the same device, 
> regardless of where the device ends up in the USB bus topology. 
> However, if there are two identical devices, it will not allow you to 
> specify which one. 
>  
> Specifying by bus address will always allow you to choose a 
> specific device, even if you have duplicates. However, the bus address 
> may change depending on which port you plugged the device into, and 
> possibly also after a reboot. 
>  
> To avoid duplication of vendorid:deviceid, we'll use bus address to 
> specify host USB device in xl toolstack. 
>  
> You can use lsusb to list the USB devices on the system: 
>  
> Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 003 Device 002: ID f617:0905 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
> Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra 
> Fast Media Reader 
> Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse 
>  
> To pass through the Logitec mouse, for instance, you could specify 
> 1.6 (remove leading zeroes). 
>  
> Note: USB hubs can not be assigned to guest. 
>  
> 3. PVUSB toolstack 
>  
> * Specify USB device in xl config file 
>  
> You can just specify usb devices, like: 
> usbdev=['1.6'] 
>  
> Then it will create a USB controller automatically and attach the USB 
> device to the first available USB controller:port. 
>  
> or, you can explicitly specify usb controllers and usb devices, like: 
> usbctrl=['verison=1, ports=4', 'version=2, ports=8', ] 
> usbdev=['1.6, controller=0, port=1'] 
>  
> Then it will create two USB controllers as you specified. 
> And if controller and port are specified in usb config, then it will 
> attach the USB device to that controller:port. About the controller 
> and port value: 
> Each USB controller has a index (or called devid) based on 0. The 1st 
> controller has index 0, the 2nd controller has index 1, ... 
> Under controller, each port has a port number based on 1. In above 
> configuration, the 1st controller will have port 1,2,3,4. 
>  
> * Hot-Plug USB device 
>  
> To attach a USB device, you should first create a USB controller. 
> e.g. 
> xl usb-ctrl-attach domain [version=1|2] [ports=value] 
> By default, it will create a USB2.0 controller with 8 

Re: [Xen-devel] [xen-unstable test] 65066: regressions - FAIL

[Andrew Cooper]

On 25/11/15 09:33, Ian Campbell wrote:
> On Wed, 2015-11-25 at 02:30 +, osstest service owner wrote:
>> flight 65066 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/65066/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 
>> 64035
> We discussed this possibility IRL when the "minios: don't rely on specific
> page table allocation scheme" fix was being made for the issue exposed by
> the changes to the domain builder to support larger guests.
>
> The rumpkernel flights have been disabled for a while now pending a
> reworking of osstest to cope with an upstream change to the build system,
> so there is no possibility, at the moment, of getting the mini-os fix into
> upstream rump and then through our rumpkernel push gate and into the xen-
> unstable tests.
>
> Therefore I believe we concluded we would force push this failure.
>
> But before I did so I just wanted to confirm I'd understood the plan.

+1 force push.  Master is a long way behind staging currently, and this
doesn't look like it is going to be fixed any time soon.

~Andrew

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

[Xen-devel] [RFC 1/1] xen: block: correct setting for xen_blkif_max_ring_order

[Peng Fan]

According to this piece code:
"
 pr_info("Invalid max_ring_order (%d), will use default max: %d.\n",
  xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);
"
if xen_blkif_max_ring_order is bigger that XENBUS_MAX_RING_GRANT_ORDER,
need to set xen_blkif_max_ring_order using XENBUS_MAX_RING_GRANT_ORDER,
but not 0.

Signed-off-by: Peng Fan 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: "Roger Pau Monné" 
---

Hi,

I am new to xen and reading related soure code, not sure whether
this is correct. Please comments.

Thanks

 drivers/block/xen-blkfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 0823a96..883b9fa 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2126,7 +2126,7 @@ static int __init xlblk_init(void)
if (xen_blkif_max_ring_order > XENBUS_MAX_RING_PAGE_ORDER) {
pr_info("Invalid max_ring_order (%d), will use default max: 
%d.\n",
xen_blkif_max_ring_order, XENBUS_MAX_RING_PAGE_ORDER);
-   xen_blkif_max_ring_order = 0;
+   xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
}
 
if (!xen_has_pv_disk_devices())
-- 
2.6.2


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

Re: [Xen-devel] [PATCH v4 2/3] arm: export platform_op XENPF_settime64

[Ian Campbell]

On Tue, 2015-11-24 at 12:00 -0500, Daniel De Graaf wrote:
> On 16/11/15 08:08, Ian Campbell wrote:
> > On Thu, 2015-11-12 at 17:46 +, Stefano Stabellini wrote:
> > > Call update_domain_wallclock_time at domain initialization.
> > > Set time_offset_seconds to the number of seconds between physical
> > > boot
> > > and domain initialization: it is going to be used to get/set the
> > > wallclock time.
> > > Add time_offset_seconds to system_time when before calling
> > > do_settime,
> > > so that system_time actually accounts for all the time in nsec
> > > between
> > > machine boot and when the wallclock was set.
> > > 
> > > Expose xsm_platform_op to ARM.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > 
> > Acked-by: Ian Campbell 
> > 
> > An aside:[...]
> > @@ -1332,6 +1332,75 @@ static int flask_deassign_dtdevice(struct domain
> > > *d, const char *dtpath)
> > >   }
> > >   #endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */
> > > 
> > > +static int flask_platform_op(uint32_t op)
> > > +{
> > > +switch ( op )
> > > +{
> > > +#ifdef CONFIG_X86
> > > +/* These operations have their own XSM hooks */
> > > +case XENPF_cpu_online:
> > > +case XENPF_cpu_offline:
> > > +case XENPF_cpu_hotadd:
> > > +case XENPF_mem_hotadd:
> > > +return 0;
> > 
> > Should this not then be an error (e.g. fail closed)?
> 
> During the invocation of these operations, two XSM hooks are called: this
> one (from above the switch) and the individual hook (inside the switch).
> This hook needs to allow access so that the more detailed hook is called.

I see, thanks for the explanation.

> > Also, although only implemented today for x86 they don't seem
> > inherently
> > any more x86 specific than many of the other things below, so maybe the
> > ifdef could be ditched?
> 
> The #ifdef is there mostly as a failsafe reminder to ensure that the
> implementation for other architectures actually calls the same XSM hooks
> that the x86 version does.

OK.

Ian.


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

Re: [Xen-devel] [PATCH] console: make printk() line continuation tracking per-CPU

[Ian Campbell]

On Tue, 2015-11-24 at 10:36 -0700, Jan Beulich wrote:
> This avoids cases where split messages (with other than the initial
> part not carrying a log level; single line messages only of course)
> issued on multiple CPUs interfere with each other, causing messages to
> be issued which are supposed to be suppressed due to the log level
> setting. E.g.
> 
>   CPU A   CPU B
> XENLOG_G_DEBUG "abc"
>   XENLOG_G_DEBUG "def\n"
> "xyz\n"
> 
> would cause the last message to be logged despite this obviously not
> being intended (at default log levels).
> 
> Suggested-by: Boris Ostrovsky 
> Signed-off-by: Jan Beulich 
> Tested-by: Boris Ostrovsky 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 25 November 2015 10:43
> To: Paul Durrant; Ian Jackson
> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Wei Liu
> Subject: Re: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> On Tue, 2015-11-24 at 17:20 +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: 24 November 2015 16:35
> > > To: Paul Durrant
> > > Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell;
> > > Wei Liu
> > > Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> > > ~/control/shutdown
> > >
> > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using
> > > libxl__xs_mkdir()
> > > for ~/control/shutdown"):
> > > > [Ian Jackson]
> > > > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using
> > > libxl__xs_mkdir()
> > > > > for ~/control/shutdown"):
> > > > > > [Ian Jackson:]
> > > > > > > Maybe it would be easier to rename libxl__xs_mkdir to
> > > > > > > libxl__xs_mknode ?  (It's probably too late to rename
> > > > > > > XS_MKDIR.)
> > > > > >
> > > > > > There is still the need to set the path to an empty value though,
> > > > > > which
> > > is
> > > > > not implicitly done by the XS_MKDIR.
> > > > >
> > > > > Under what circumstances would this path not contain an empty
> value
> > > > > after XS_MKDIR ?
> > > >
> > > > In this case I believe you are correct, but my feeling was that
> > > > people reading the code would be lulled into a false sense of
> > > > security that XS_MKDIR always did the right thing to initialize a
> > > > new path.
> > >
> > > I'm not sure I follow this argument.  What did you think of my idea
> > > of renaming libxl__xs_mkdir to libxl__xs_mknode ?
> > >
> >
> > The issue, as I said, is the initial state of the node. If you use
> > XS_MKDIR then it is not guaranteed to be empty.
> 
> Just to satisfy my curiosity, how can it be non-empty? What else could it
> possibly contain, just garbage?
> 
> Or maybe this is the behaviour of XS_MKDIR on a path/node which already
> exists?
> 

Yes, that's exactly it. I believe XS_MKDIR does guarantee to create a path 
empty, but will not clear an existing one.

  Paul

> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Jan Beulich]

>>> On 24.11.15 at 19:19,  wrote:

>> On Nov 24, 2015, at 11:30 AM, Jan Beulich  wrote:
>> 
> On 24.11.15 at 18:22,  wrote:
>> 
 On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>>>  wrote:
> On Nov 24, 2015, at 11:07 AM, Jan Beulich  wrote:
 On 24.11.15 at 17:56,  wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
>> -rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
>> $(TARGET)-syms 
>>> *~ core
>> +rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
>> $(TARGET)-syms 
>>> *~ core $(DEPS)
> 
> Is this really a problem only in xen/ ? The referenced commit clearly
> introduces "stray" *.d files elsewhere. Also there aren't any source
> files in xen/, so I'd expect $(DEPS) to be empty. Please clarify.
 
 So, the files in xen/ were the dependencies files for xen.efi and 
 xen-syms that were getting left behind. $(DEPS) appears to always
 have ‘.*.d’ in it, based on me putting an echo into the clean rule to 
 print it out. However, looking at this, I am also seeing ‘.d’ files left
 behind in xen/common/compat that I did not notice before.
>>> 
>>> Actually, looking closer at it, xen/common/compat does not appear to be
>>> cleaning at all, so I think that is a separate, unrelated issue.
>> 
>> That would be quite related, as it would be a result of the same
>> commit.
> 
> Yeah, I now see where that change got introduced. I don’t see a clear way of 
> cleaning
> those objects files since the build system no longer goes into the 
> common/compat directory at
> all. The existing clean rules walk all of the subdirectories, cleaning 
> object files and dependency
> files as it goes. 

But wouldn't the way DEPS gets populated in xen/Rules.mk cover for
this? If so, the alternative to your original patch might be to simply
rm those ..xen*.o.d files right in the $(TARGET)-syms and
$(TARGET).efi rules (along with their corresponding
$(@D)/.$(@F).[0-9]* getting removed, due to which those .o.d
ones are of no use anyway). Or maybe it should really do both,
considering that *.o get removed by _clean too.

Jan

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

Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks

[Malcolm Crossley]

On 24/11/15 18:30, George Dunlap wrote:
> On 24/11/15 18:16, George Dunlap wrote:
>> On 20/11/15 16:03, Malcolm Crossley wrote:
>>> This patch series adds per-cpu reader-writer locks as a generic lock
>>> implementation and then converts the grant table and p2m rwlocks to
>>> use the percpu rwlocks, in order to improve multi-socket host performance.
>>>
>>> CPU profiling has revealed the rwlocks themselves suffer from severe cache
>>> line bouncing due to the cmpxchg operation used even when taking a read 
>>> lock.
>>> Multiqueue paravirtualised I/O results in heavy contention of the grant 
>>> table
>>> and p2m read locks of a specific domain and so I/O throughput is 
>>> bottlenecked
>>> by the overhead of the cache line bouncing itself.
>>>
>>> Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data
>>> area to record a CPU has taken the read lock. Correctness is enforced for 
>>> the 
>>> write lock by using a per lock barrier which forces the per-cpu read lock 
>>> to revert to using a standard read lock. The write lock then polls all 
>>> the percpu data area until active readers for the lock have exited.
>>>
>>> Removing the cache line bouncing on a multi-socket Haswell-EP system 
>>> dramatically improves performance, with 16 vCPU network IO performance 
>>> going 
>>> from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 
>>> logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even 
>>> better
>>> IO improvement.
>>
>> Impressive -- thanks for doing this work.

Thanks, I think the key to isolating the problem was using profiling tools. The 
scale
of the overhead would not have been clear without them.

>>
>> One question: Your description here sounds like you've tested with a
>> single large domain, but what happens with multiple domains?
>>
>> It looks like the "per-cpu-rwlock" is shared by *all* locks of a
>> particular type (e.g., all domains share the per-cpu p2m rwlock).
>> (Correct me if I'm wrong here.)
> 
> Sorry, looking in more detail at the code, it seems I am wrong.  The
> fast-path stores which "slow" lock has been grabbed in the per-cpu
> variable; so the writer only needs to wait for readers that have grabbed
> the particular lock it's interested in.  So the scenarios I outline
> below shouldn't really be issues.
> 
> The description of the algorithm  in the changelog could do with a bit
> more detail. :-)

I'll enhance the description to say "per lock local variable" to make it clearer
that not all readers will be affected.

BTW, I added to the "To" list because I need your ACK for the patch to the p2m 
code.

Do you have any review comments for that patch?

Thanks

Malcolm

> 
>  -George
> 


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

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Jan Beulich]

>>> On 25.11.15 at 08:48,  wrote:
> On Tue, Nov 24, 2015 at 03:34:45AM -0700, Jan Beulich wrote:
>> Chao, could you - inside Intel - please check whether there are
>> any assumptions on the respective CPUID leaf output that aren't
>> explicitly stated in the SDM right now (like resulting in contiguous
>> socket numbers), and ask for them getting made explicit (if there
>> are any), or it being made explicit that no assumptions at all are
>> to be made at all on the presented values
> 
> Actually there is already such statement in SDM (ch8.9.1, vol3):
> 
> "The value of valid APIC_IDs need not be contiguous across package
> boundary or core boundaries".

That's a statement on APIC ID space (which necessarily can't be
contiguous on systems with a non-power-of-2 core count), but I
was asking about the socket ID space.

>> (in which case we'd
>> have to consume MADT parsing data in set_nr_sockets(), e.g.
>> by replacing num_processors there with one more than the
>> maximum APIC ID of any non-disabled CPU)?
> 
> Even with this, we still have problem for hotplug case, the inserted
> CPU may have a APIC_ID bigger than the maximum APIC_ID here.
> 
> But let's back to the real world. Most machines that support CAT should
> have continuous SOCKET_ID so it's not a problem. Giving that CAT is the
> only feature uses this, I guess this suggestion might be better than
> other solutions in practice. 

And we could actually cater for that by extrapolating the value
added to cover disabled_cpus.

Jan


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

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Jan Beulich]

>>> On 24.11.15 at 21:28,  wrote:
> RFC. Boot tested on VMware Fusion, and on a 2-socket Xeon server.

Well, thanks, but as said I view this is overkill (and I'm also not sure
what you have is completely race free). Hence I'd prefer a more light
weight solution if at all possible.

Jan


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

[Xen-devel] [RESEND][PATCH V9 0/7] xen pvusb toolstack work

[Chunyan Liu]

RESEND to update usb controller and device naming according to current
discussion:
* libxl: Introduce a template for devices with a controller
https://www.mail-archive.com/xen-devel@lists.xen.org/msg46720.html

This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

Changes to V8:
* lots of changes in libxl pvusb API (patch 3/7)
* update 2/7 to write separate read_sysfs_file function
* address all other comments

V8:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html

V7:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html

V6:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html

V5:
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html

V4:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html

Related Discussion Threads:
http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html
http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['1.6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['1.6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl usb-ctrl-attach domain [version=1|2] [ports=value]
By default, it will create a USB2.0 controller with 8 ports.

Then you could attach a USB device.
e.g.
xl usb-attach domain 1.6 [controller=index port=number]
By default, it will find the 1st available controller:port to attach
the USB device.

You could view USB device status of the domain by usb-list.
e.g.
xl usb-list domain
It will list USB controllers and USB devices under each controller.

You could detach a USB device with usb-detach command.
e.g.
xl usb-detach domain 1.6

You can also remove the whole USB controller by usb-ctrl-detach

[Xen-devel] [RESEND][PATCH V9 3/7] libxl: add pvusb API

[Chunyan Liu]

Add pvusb APIs, including:
 - attach/detach (create/destroy) virtual usb controller.
 - attach/detach usb device
 - list usb controller and usb devices
 - some other helper functions

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 

---
changes:
  - update naming, all places indicating usb controller named
as usbctrl, all places indicating usb device named as usbdev
  - update DEFINE_DEVICE_REMOVE instead of creating a new
DEFINE_DEVICE_REMOVE_EXT
  - use libxl__xs_read_checked instead of libxl__xs_read
  - update local READ_SUBPATH(_INT) macros to include more common codes
  - save drvpath before unbind
  - get_assigned_devices: call libxl__device_usbdev_list_for_ctrl
instead of doing all things from scratch
  - usb_interface_xenstore_encode: use special char to avoid confusion
  - usb readdir_r instead of readdir
  - check syscall errno
  - remove usbinfo definition
  - address other comments except:
libxl__device_usbdev_add/remove and do_usbdev_add/remove, in previous
discussion, we'd like to get usbctrlinfo once and pass usbctrlinfo to
do_usbdev_add/remove. However, during update, adding usbdev process
still needs to try twice to get usbctrlinfo. (Before set_default,
if usbctrl doesn't exist it doesn't doing getting usbctrlinfo actually;
after set_default, needs to get usbctrlinfo then). So, finally, just
change codes to make adding/removing process symmetrical.

 tools/libxl/Makefile |2 +-
 tools/libxl/libxl.c  |   50 +-
 tools/libxl/libxl.h  |   77 ++
 tools/libxl/libxl_device.c   |5 +-
 tools/libxl/libxl_internal.h |   18 +
 tools/libxl/libxl_osdeps.h   |   13 +
 tools/libxl/libxl_pvusb.c| 1534 ++
 tools/libxl/libxl_types.idl  |   46 +
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_utils.c|   18 +
 tools/libxl/libxl_utils.h|5 +
 11 files changed, 1766 insertions(+), 3 deletions(-)
 create mode 100644 tools/libxl/libxl_pvusb.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 6ff5bee..a36145a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
-   libxl_dom_suspend.o $(LIBXL_OBJS-y)
+   libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index eaa7d75..a479465 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4144,6 +4144,36 @@ out:
 return rc;
 }
 
+static void libxl__initiate_device_disk_remove(libxl__egc *egc,
+   libxl__ao_device *aodev)
+{
+return libxl__initiate_device_remove(egc, aodev);
+}
+
+static void libxl__initiate_device_nic_remove(libxl__egc *egc,
+  libxl__ao_device *aodev)
+{
+return libxl__initiate_device_remove(egc, aodev);
+}
+
+static void libxl__initiate_device_vtpm_remove(libxl__egc *egc,
+   libxl__ao_device *aodev)
+{
+return libxl__initiate_device_remove(egc, aodev);
+}
+
+static void libxl__initiate_device_vkb_remove(libxl__egc *egc,
+  libxl__ao_device *aodev)
+{
+return libxl__initiate_device_remove(egc, aodev);
+}
+
+static void libxl__initiate_device_vfb_remove(libxl__egc *egc,
+  libxl__ao_device *aodev)
+{
+return libxl__initiate_device_remove(egc, aodev);
+}
+
 
/**/
 
 /* Macro for defining device remove/destroy functions in a compact way */
@@ -4158,6 +4188,8 @@ out:
  * libxl_device_vkb_destroy
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
+ * libxl_device_usbctrl_remove
+ * libxl_device_usbctrl_destroy
  */
 #define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
@@ -4179,7 +4211,7 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##type##_remove(egc, aodev); \
 \
 out:

[Xen-devel] [RESEND][PATCH V9 4/7] libxl: add libxl_device_usbdev_assignable_list API

[Chunyan Liu]

Add API for listing assignable USB devices info.
Assignable USB device means the USB device type is assignable and
it's not assigned to any guest yet.

Signed-off-by: Chunyan Liu 

---
This could be squashed with previous patch. Split because there is
some dispute on this. If this is acceptable, could be squashed,
otherwise could be removed.

Changes:
  - update usb device naming

 tools/libxl/libxl.h   |  2 ++
 tools/libxl/libxl_pvusb.c | 62 +++
 2 files changed, 64 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 609d068..d659ec3 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1479,6 +1479,8 @@ int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t 
domid,
  libxl_usbctrlinfo *usbctrlinfo);
 
 /* USB Devices */
+libxl_device_usbdev *
+libxl_device_usbdev_assignable_list(libxl_ctx *ctx, int *num);
 
 int libxl_device_usbdev_add(libxl_ctx *ctx, uint32_t domid,
 libxl_device_usbdev *usbdev,
diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index e35c6b5..b0f0808 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -592,6 +592,68 @@ static bool is_usbdev_assignable(libxl__gc *gc, 
libxl_device_usbdev *usbdev)
 return classcode != USBHUB_CLASS_CODE;
 }
 
+libxl_device_usbdev *
+libxl_device_usbdev_assignable_list(libxl_ctx *ctx, int *num)
+{
+GC_INIT(ctx);
+libxl_device_usbdev *usbdevs = NULL;
+libxl_device_usbdev *assigned;
+int num_assigned;
+DIR *dir;
+int r;
+
+*num = 0;
+
+r = get_assigned_devices(gc, , _assigned);
+if (r) {
+LOG(ERROR, "cannot determine if device is assigned");
+goto out;
+}
+
+dir = opendir(SYSFS_USB_DEV);
+if (!dir) goto out;
+
+size_t need = offsetof(struct dirent, d_name) +
+pathconf(SYSFS_USB_DEV, _PC_NAME_MAX) + 1;
+struct dirent *de_buf = libxl__zalloc(gc, need);
+struct dirent *de;
+
+while (readdir_r(dir, de_buf, ) == 0 && de != NULL) {
+libxl_device_usbdev *usbdev;
+uint8_t bus, addr;
+
+if (!strcmp(de->d_name, ".") ||
+!strcmp(de->d_name, ".."))
+continue;
+
+if (usbdev_busaddr_from_busid(gc, de->d_name, , ))
+continue;
+
+GCNEW(usbdev);
+usbdev->u.hostdev.hostbus = bus;
+usbdev->u.hostdev.hostaddr = addr;
+
+if (!is_usbdev_assignable(gc, usbdev))
+continue;
+
+if (is_usbdev_in_array(assigned, num_assigned, usbdev))
+continue;
+
+usbdevs = libxl__realloc(NOGC, usbdevs,
+ sizeof(*usbdevs) * (*num + 1));
+libxl_device_usbdev_init(usbdevs + *num);
+usbdevs[*num].u.hostdev.hostbus = bus;
+usbdevs[*num].u.hostdev.hostaddr = addr;
+(*num)++;
+}
+
+closedir(dir);
+
+out:
+GC_FREE;
+return usbdevs;
+}
+
 /* get usb devices under certain usb controller */
 static int
 libxl__device_usbdev_list_for_usbctrl(libxl__gc *gc,
-- 
2.1.4


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

[Xen-devel] [RESEND][PATCH V9 5/7] xl: add pvusb commands

[Chunyan Liu]

Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.

To attach a usb device to guest through pvusb, one could follow
following example:

 #xl usbctrl-attach test_vm version=1 ports=8

 #xl usb-list test_vm
 will show the usb controllers and port usage under the domain.

 #xl usbdev-attach test_vm hostbus=1 hostaddr=2
 will find the first usable controller:port, and attach usb
 device whose busnum is 1 and devnum is 6.
 One could also specify which  and which .

 #xl usbdev-detach test_vm 0 1
 will detach USB device under controller 0 port 1.

 #xl usbctrl-detach test_vm dev_id
 will destroy the controller with specified dev_id. Dev_id
 can be traced in usb-list info.

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 

---
Changes:
  - use libxl_usbdev/usbctrl_type_from_string instead of
comparing oparg string mannually.
  - update docs as George suggested

 docs/man/xl.pod.1 |  41 
 tools/libxl/xl.h  |   5 +
 tools/libxl/xl_cmdimpl.c  | 243 ++
 tools/libxl/xl_cmdtable.c |  25 +
 4 files changed, 314 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..746f49f 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1345,6 +1345,47 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head1 USB PASS-THROUGH
+
+=over 4
+
+=item B I 

[Xen-devel] [RESEND][PATCH V9 6/7] xl: add usbdev-assignable-list command

[Chunyan Liu]

Add xl usbdev-assignable-list command to list assignable USB devices.
Assignable USB device means the USB device type is assignable and
it's not assigned to any guest yet.

Signed-off-by: Chunyan Liu 

---
  Same as "libxl: add libxl_device_usbdev_assignable_list API" patch,
  this patch could be sqaushed to previous one. Split because of
  some dispute. Could be squashed if acceptable, otherwise could
  be removed.

 tools/libxl/xl.h  |  1 +
 tools/libxl/xl_cmdimpl.c  | 28 
 tools/libxl/xl_cmdtable.c |  4 
 3 files changed, 33 insertions(+)

diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 309627a..8418fff 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -92,6 +92,7 @@ int main_blockdetach(int argc, char **argv);
 int main_vtpmattach(int argc, char **argv);
 int main_vtpmlist(int argc, char **argv);
 int main_vtpmdetach(int argc, char **argv);
+int main_usbdev_assignable_list(int argc, char **argv);
 int main_usbctrl_attach(int argc, char **argv);
 int main_usbctrl_detach(int argc, char **argv);
 int main_usbdev_attach(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f98e367..dfc3ad5 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3449,6 +3449,34 @@ int main_cd_insert(int argc, char **argv)
 return 0;
 }
 
+static void usbdev_assignable_list(void)
+{
+libxl_device_usbdev *usbdevs;
+int num, i;
+
+usbdevs = libxl_device_usbdev_assignable_list(ctx, );
+
+for (i = 0; i < num; i++) {
+printf("%d.%d\n",
+   usbdevs[i].u.hostdev.hostbus,
+   usbdevs[i].u.hostdev.hostaddr);
+}
+
+libxl_device_usbdev_list_free(usbdevs, num);
+}
+
+int main_usbdev_assignable_list(int argc, char **argv)
+{
+int opt;
+
+SWITCH_FOREACH_OPT(opt, "", NULL, "usbdev-assignable-list", 0) {
+/* No options */
+}
+
+usbdev_assignable_list();
+return 0;
+}
+
 int main_usbctrl_attach(int argc, char **argv)
 {
 uint32_t domid;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index b14b881..df4f6d9 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -578,6 +578,10 @@ struct cmd_spec cmd_table[] = {
   "List information about all USB controllers and devices for a domain",
   "",
 },
+{ "usbdev-assignable-list",
+  _usbdev_assignable_list, 0, 0,
+  "List all assignable USB devices",
+},
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);
-- 
2.1.4


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

[Xen-devel] [RESEND][PATCH V9 2/7] libxl_utils: add internal function to read sysfs file contents

[Chunyan Liu]

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
---
Changes:
  - write a separate function libxl__read_sysfs_file_contents, no
longer mix with libxl_read_file_contents

 tools/libxl/libxl_internal.h |  5 +++
 tools/libxl/libxl_utils.c| 77 
 2 files changed, 82 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ab981d2..7aff237 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4021,6 +4021,11 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 const libxl_bitmap *sptr);
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
+
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 #endif
 
 /*
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index e42422a..7f612a6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,83 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), )) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+if (!data) goto xe;
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+if (!data)
+goto xe;
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

[Xen-devel] osstest serial logs

[Ian Campbell]

On Tue, 2015-11-24 at 20:12 +, Ian Campbell wrote:
> The serial logs begin at the start of the flight, which might be long
> before the job actually started. (confusing, I agree)

We could switch this to collect logs only from the start of the job, rather
than the start of the flight, but this would still include a potentially
long time in the hosts-allocate phase, where several other jobs could run.

I investigated other options a while back:

I found that sympathy has no way to ask it to rotate the logs (either
globally or for a specific host, which would allow us to cause the relevant
job's logs at least start on a file break boundary) nor any mechanism to
inject a string into the log (to fingerprint the start of a phase to make
searching easier etc).

I also investigated making Osstest::Serial::* filter based on time stamps,
but it was getting pretty fiddly. Perhaps not impossible to achieve, but
still suffers from not being able to know when to cut off (maybe hosts-
allocate could set a runvar?)

Perhaps one simple aid would be to have osstest-confirm-booted log the
flight + job along with an easily searchable pattern (like how I can
usually search for *** in a build log to see what went wrong)?

Ian.

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

[Xen-devel] [RESEND][PATCH V9 7/7] domcreate: support pvusb in configuration file

[Chunyan Liu]

Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.

One could specify usb controllers and usb devices in config file
like this:
usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
---
changes:
  - update docs
  - update usb device naming

 docs/man/xl.cfg.pod.5| 84 
 tools/libxl/libxl_create.c   | 73 --
 tools/libxl/libxl_device.c   |  4 +++
 tools/libxl/libxl_internal.h |  8 +
 tools/libxl/xl_cmdimpl.c | 55 -
 5 files changed, 220 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index b63846a..db00371 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -722,6 +722,90 @@ Note this may be overridden by rdm_policy option in PCI 
device configuration.
 
 =back
 
+=item 

Re: [Xen-devel] [xen-unstable test] 65066: regressions - FAIL

[Wei Liu]

On Wed, Nov 25, 2015 at 09:33:56AM +, Ian Campbell wrote:
> On Wed, 2015-11-25 at 02:30 +, osstest service owner wrote:
> > flight 65066 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/65066/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 
> > 64035
> 
> We discussed this possibility IRL when the "minios: don't rely on specific
> page table allocation scheme" fix was being made for the issue exposed by
> the changes to the domain builder to support larger guests.
> 
> The rumpkernel flights have been disabled for a while now pending a
> reworking of osstest to cope with an upstream change to the build system,
> so there is no possibility, at the moment, of getting the mini-os fix into
> upstream rump and then through our rumpkernel push gate and into the xen-
> unstable tests.
> 
> Therefore I believe we concluded we would force push this failure.
> 
> But before I did so I just wanted to confirm I'd understood the plan.
> 

Yes. Force push please. This failure is expected.

Wei.

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

Re: [Xen-devel] [V12 1/4] x86/xsaves: using named operand instead numbered operand in xrstor

[Jan Beulich]

>>> On 25.11.15 at 08:51,  wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -158,6 +158,16 @@ void xsave(struct vcpu *v, uint64_t mask)
>  ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = word_size;
>  }
>  
> +#define XRSTOR_FIXUP   ".section .fixup,\"ax\"   \n"\
> +   "2: mov %[size],%%ecx \n"\
> +   "   xor %[lmask_out],%[lmask_out] \n"\
> +   "   rep stosb \n"\
> +   "   lea %[mem],%[ptr] \n"\
> +   "   mov %[lmask_in],%[lmask_out]  \n"\
> +   "   jmp 1b\n"\
> +   ".previous\n"\
> +   _ASM_EXTABLE(1b, 2b)

So this is exactly the disconnect I told you to avoid: The definition
here and the use site can't independently change any of the
operand names, since you don't pass them as macro arguments.
But I guess I'll give up on this an will try to remember to adjust this
later myself.

Jan


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

Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks

[George Dunlap]

On 25/11/15 08:58, Malcolm Crossley wrote:
> On 24/11/15 18:30, George Dunlap wrote:
>> On 24/11/15 18:16, George Dunlap wrote:
>>> On 20/11/15 16:03, Malcolm Crossley wrote:
 This patch series adds per-cpu reader-writer locks as a generic lock
 implementation and then converts the grant table and p2m rwlocks to
 use the percpu rwlocks, in order to improve multi-socket host performance.

 CPU profiling has revealed the rwlocks themselves suffer from severe cache
 line bouncing due to the cmpxchg operation used even when taking a read 
 lock.
 Multiqueue paravirtualised I/O results in heavy contention of the grant 
 table
 and p2m read locks of a specific domain and so I/O throughput is 
 bottlenecked
 by the overhead of the cache line bouncing itself.

 Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data
 area to record a CPU has taken the read lock. Correctness is enforced for 
 the 
 write lock by using a per lock barrier which forces the per-cpu read lock 
 to revert to using a standard read lock. The write lock then polls all 
 the percpu data area until active readers for the lock have exited.

 Removing the cache line bouncing on a multi-socket Haswell-EP system 
 dramatically improves performance, with 16 vCPU network IO performance 
 going 
 from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 
 logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even 
 better
 IO improvement.
>>>
>>> Impressive -- thanks for doing this work.
> 
> Thanks, I think the key to isolating the problem was using profiling tools. 
> The scale
> of the overhead would not have been clear without them.
> 
>>>
>>> One question: Your description here sounds like you've tested with a
>>> single large domain, but what happens with multiple domains?
>>>
>>> It looks like the "per-cpu-rwlock" is shared by *all* locks of a
>>> particular type (e.g., all domains share the per-cpu p2m rwlock).
>>> (Correct me if I'm wrong here.)
>>
>> Sorry, looking in more detail at the code, it seems I am wrong.  The
>> fast-path stores which "slow" lock has been grabbed in the per-cpu
>> variable; so the writer only needs to wait for readers that have grabbed
>> the particular lock it's interested in.  So the scenarios I outline
>> below shouldn't really be issues.
>>
>> The description of the algorithm  in the changelog could do with a bit
>> more detail. :-)
> 
> I'll enhance the description to say "per lock local variable" to make it 
> clearer
> that not all readers will be affected.
> 
> BTW, I added to the "To" list because I need your ACK for the patch to the 
> p2m code.
> 
> Do you have any review comments for that patch?

Yes, I realize that, and I'll get to it. :-)

 -George

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

[Xen-devel] [distros-debian-squeeze test] 38339: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38305

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v2 1/2] x86/VPMU: return correct fixed PMC count

[Jan Beulich]

>>> On 25.11.15 at 00:53,  wrote:
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -166,10 +166,10 @@ static int core2_get_arch_pmc_count(void)
>   */
>  static int core2_get_fixed_pmc_count(void)
>  {
> -u32 eax;
> +u32 edx;
>  
> -eax = cpuid_eax(0xa);
> -return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
> +edx = cpuid_edx(0xa);
> +return MASK_EXTR(edx, PMU_FIXED_NR_MASK);
>  }
>  
>  /* edx bits 5-12: Bit width of fixed-function performance counters  */

I'll commit as is since it's an immediate improvement, but I don't think
this is sufficient: The SDM clearly says "if Version ID > 1", which isn't
being tested here or in the immediately following function.

Looking at this I'd also like to note that the triplets
PMU_*_{SHIFT,BITS,MASK} seem to be rather less readable than if
there were just PMU_*_MASK with a simple hex number on the right
side (the SHIFT and BITS ones aren't being used for other than
defining MASK afaics).

Jan


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

[Xen-devel] [RFC 1/1] xen: interface: correct comments

[Peng Fan]

According to definition of structure evtchn_alloc_unbound,
there is an entry "domid_t remote_dom", no "rdom". So
using "remote_dom" in comments instead of "rdom".

Signed-off-by: Peng Fan 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
---
 include/xen/interface/event_channel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/xen/interface/event_channel.h 
b/include/xen/interface/event_channel.h
index 7e6acef..1903a23 100644
--- a/include/xen/interface/event_channel.h
+++ b/include/xen/interface/event_channel.h
@@ -20,7 +20,7 @@ DEFINE_GUEST_HANDLE(evtchn_port_t);
  * is allocated in  and returned as .
  * NOTES:
  *  1. If the caller is unprivileged then  must be DOMID_SELF.
- *  2.  may be DOMID_SELF, allowing loopback connections.
+ *  2.  may be DOMID_SELF, allowing loopback connections.
  */
 #define EVTCHNOP_alloc_unbound   6
 struct evtchn_alloc_unbound {
-- 
2.6.2


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

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Andrew Cooper]

On 24/11/15 17:41, Jan Beulich wrote:
 On 24.11.15 at 18:17,  wrote:
>> --- a/xen/drivers/passthrough/vtd/quirks.c
>> +++ b/xen/drivers/passthrough/vtd/quirks.c
>> @@ -320,6 +320,20 @@ void __init platform_quirks_init(void)
>>  /* Tylersburg interrupt remap quirk */
>>  if ( iommu_intremap )
>>  tylersburg_intremap_quirk();
>> +
>> +/*
>> + * Disable shared EPT ("sharept") on Sandybridge and older processors
>> + * by default.
>> + * SandyBridge has no huge page support for IOTLB which leads to 
>> fallback
>> + * on 4k pages and leads to performance degradation.
>> + *
>> + * Shared EPT ("sharept") will be disabled only if user has not
>> + * provided explicit choice on the command line thus iommu_hap_pt_share 
>> is
>> + * at its initialized value of -1.
>> + */
>> +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F ||
>> +  boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == -1) )
>> +iommu_hap_pt_share = 0;
> If we really want to do this, then I think we should key this on
> EPT but not VT-d having 2M support, instead of on CPU models.

This check is already performed by vtd_ept_page_compatible()

The problem is that SandyBridge IOMMUs advertise 2M support and do
function with it, but cannot cache 2MB translations in the IOTLBs.

As a result, attempting to use 2M translations causes substantially
worse performance than 4K translations.

~Andrew

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

Re: [Xen-devel] [xen-unstable test] 65066: regressions - FAIL

[Ian Campbell]

On Wed, 2015-11-25 at 10:13 +, Wei Liu wrote:
> On Wed, Nov 25, 2015 at 09:33:56AM +, Ian Campbell wrote:
> > On Wed, 2015-11-25 at 02:30 +, osstest service owner wrote:
> > > flight 65066 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/65066/
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR.
> > > vs. 64035
> > 
> > We discussed this possibility IRL when the "minios: don't rely on
> > specific
> > page table allocation scheme" fix was being made for the issue exposed
> > by
> > the changes to the domain builder to support larger guests.
> > 
> > The rumpkernel flights have been disabled for a while now pending a
> > reworking of osstest to cope with an upstream change to the build
> > system,
> > so there is no possibility, at the moment, of getting the mini-os fix
> > into
> > upstream rump and then through our rumpkernel push gate and into the
> > xen-
> > unstable tests.
> > 
> > Therefore I believe we concluded we would force push this failure.
> > 
> > But before I did so I just wanted to confirm I'd understood the plan.
> > 
> 
> Yes. Force push please. This failure is expected.

Done, from original report:

> version targeted for testing:
>  xen  827db7b26384ce083df7154d77f13379b2cf4121
> baseline version:
>  xen  22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c

Therefore:

(test-lab)osstest@osstest:~/branches/for-xen-unstable.git$ 
OSSTEST_CONFIG=production-config ./ap-push xen-unstable 
827db7b26384ce083df7154d77f13379b2cf4121
+ branch=xen-unstable
+ revision=827db7b26384ce083df7154d77f13379b2cf4121
+ . ./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 
827db7b26384ce083df7154d77f13379b2cf4121
+ branch=xen-unstable
+ revision=827db7b26384ce083df7154d77f13379b2cf4121
+ . ./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
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x827db7b26384ce083df7154d77f13379b2cf4121 = 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://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : 

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Ian Campbell]

On Tue, 2015-11-24 at 17:20 +, Paul Durrant wrote:
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: 24 November 2015 16:35
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell;
> > Wei Liu
> > Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> > ~/control/shutdown
> > 
> > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using
> > libxl__xs_mkdir()
> > for ~/control/shutdown"):
> > > [Ian Jackson]
> > > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using
> > libxl__xs_mkdir()
> > > > for ~/control/shutdown"):
> > > > > [Ian Jackson:]
> > > > > > Maybe it would be easier to rename libxl__xs_mkdir to
> > > > > > libxl__xs_mknode ?  (It's probably too late to rename
> > > > > > XS_MKDIR.)
> > > > > 
> > > > > There is still the need to set the path to an empty value though,
> > > > > which
> > is
> > > > not implicitly done by the XS_MKDIR.
> > > > 
> > > > Under what circumstances would this path not contain an empty value
> > > > after XS_MKDIR ?
> > > 
> > > In this case I believe you are correct, but my feeling was that
> > > people reading the code would be lulled into a false sense of
> > > security that XS_MKDIR always did the right thing to initialize a
> > > new path.
> > 
> > I'm not sure I follow this argument.  What did you think of my idea
> > of renaming libxl__xs_mkdir to libxl__xs_mknode ?
> > 
> 
> The issue, as I said, is the initial state of the node. If you use
> XS_MKDIR then it is not guaranteed to be empty.

Just to satisfy my curiosity, how can it be non-empty? What else could it
possibly contain, just garbage?

Or maybe this is the behaviour of XS_MKDIR on a path/node which already
exists?

Ian.

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

Re: [Xen-devel] How to recognize which guest issues the hypercall?

[George Dunlap]

On Wed, Nov 25, 2015 at 7:18 AM, Big Strong  wrote:
> I write a program to intercept all hypercalls happend on a xen hypervisor.
> How can I know which domain called the hypercall? Is it possible to obtain
> it from the registers?

Why are you cross-posting this to both xen-users and xen-devel?  This
is obviously a development question.

At any given time, "current" will point to the vcpu struct of the
currently-running vcpu; current->domain will point to the domain
struct.  That should get you started.

 -George

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

Re: [Xen-devel] [xen-unstable test] 65066: regressions - FAIL

[Ian Campbell]

On Wed, 2015-11-25 at 02:30 +, osstest service owner wrote:
> flight 65066 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65066/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 
> 64035

We discussed this possibility IRL when the "minios: don't rely on specific
page table allocation scheme" fix was being made for the issue exposed by
the changes to the domain builder to support larger guests.

The rumpkernel flights have been disabled for a while now pending a
reworking of osstest to cope with an upstream change to the build system,
so there is no possibility, at the moment, of getting the mini-os fix into
upstream rump and then through our rumpkernel push gate and into the xen-
unstable tests.

Therefore I believe we concluded we would force push this failure.

But before I did so I just wanted to confirm I'd understood the plan.

Ian.

> Regressions which are regarded as allowable (not blocking):
>  test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs.
> 64035
>  test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail baseline
> untested
>  test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like
> 64035
>  test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like
> 64035
>  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-
> install fail like 64035
>  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-
> localmigrate fail like 64035
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pvh-intel 11 guest-
> start  fail  never pass
>  test-armhf-armhf-libvirt-raw  9 debian-di-
> installfail   never pass
>  test-armhf-armhf-libvirt 14 guest-
> saverestorefail   never pass
>  test-armhf-armhf-libvirt 12 migrate-support-
> checkfail   never pass
>  test-armhf-armhf-libvirt-xsm 12 migrate-support-
> checkfail   never pass
>  test-armhf-armhf-libvirt-xsm 14 guest-
> saverestorefail   never pass
>  test-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-armhf-armhf-xl-multivcpu 13 saverestore-support-
> checkfail  never pass
>  test-armhf-armhf-xl-multivcpu 12 migrate-support-
> checkfail  never pass
>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-
> check fail never pass
>  test-amd64-i386-libvirt-xsm  12 migrate-support-
> checkfail   never pass
>  test-armhf-armhf-xl-arndale  12 migrate-support-
> checkfail   never pass
>  test-armhf-armhf-xl-arndale  13 saverestore-support-
> checkfail   never pass
>  test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail
> never pass
>  test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail
> never pass
>  test-amd64-amd64-libvirt-vhd 11 migrate-support-
> checkfail   never pass
>  test-amd64-amd64-xl-pvh-amd  11 guest-
> start  fail   never pass
>  test-armhf-armhf-xl-vhd   9 debian-di-
> installfail   never pass
>  test-armhf-armhf-xl-xsm  13 saverestore-support-
> checkfail   never pass
>  test-armhf-armhf-xl-xsm  12 migrate-support-
> checkfail   never pass
>  test-armhf-armhf-xl  12 migrate-support-
> checkfail   never pass
>  test-armhf-armhf-xl  13 saverestore-support-
> checkfail   never pass
>  test-amd64-amd64-libvirt 12 migrate-support-
> checkfail   never pass
>  test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail
> never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail
> never pass
>  test-armhf-armhf-xl-credit2  13 saverestore-support-
> checkfail   never pass
>  test-armhf-armhf-xl-credit2  12 migrate-support-
> checkfail   never pass
>  test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail
> never pass
>  test-amd64-i386-libvirt  12 migrate-support-
> checkfail   never pass
> 
> version targeted for testing:
>  xen  827db7b26384ce083df7154d77f13379b2cf4121
> baseline version:
>  xen  22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
> 
> Last test of basis64035  2015-11-10 08:01:11 Z   14 days
> Failing since 64149  2015-11-11 19:15:29 Z   13 days9
> attempts
> Testing same since65066  2015-11-24 02:32:19 Z0 days1
> attempts
> 
> 
> People who touched revisions under test:
>   Andrew Cooper 
>   Aravind Gopalakrishnan 
>   Bob Liu 
>   Boris Ostrovsky 
>   David Scott 
>   Feng Wu 

Re: [Xen-devel] [PATCH v2 05/11] xen/arm: vgic: Properly emulate the full register

[Shannon Zhao]

Hi Julien,

On 2015/11/19 1:28, Julien Grall wrote:
> -case GICD_ICACTIVER ... GICD_ICACTIVERN:
> +case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
>  if ( dabt.size != DABT_WORD ) goto bad_width;
>  printk(XENLOG_G_ERR
> "%pv: vGICD: unhandled word write %#"PRIregister" to 
> ICACTIVER%d\n",
> v, r, gicd_reg - GICD_ICACTIVER);
>  return 0;

Maybe this question is not related to what this patch does. But I have a
problem when I rebase my ACPI patches on upstream Linux kernel.

Upstream Linux kernel applies below patch which will write
GICD_ICACTIVER. But since Xen doesn't support it, so it will cause Dom0
initializes GIC failed.

0eece2b22849c90b730815c893425a36b9d10fd5 (irqchip/gic: Make sure all
interrupts are deactivated at boot)

(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) traps.c:2447:d0v0 HSR=0x93860046 pc=0xffc0008d63f0
gva=0xff804384 gpa=0x002f000384
(XEN) DOM0: Unhandled fault: ttbr address size fault (0x9600) at
0xff804384
(XEN) DOM0: Internal error: : 9600 [#1] PREEMPT SMP
(XEN) DOM0: Modules linked in:
(XEN) DOM0: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc2+ #364
(XEN) DOM0: Hardware name: (null) (DT)
(XEN) DOM0: task: ffc000969970 ti: ffc00095c000 task.ti:
ffc00095c000
(XEN) DOM0: PC is at gic_dist_config+0x78/0xa0
(XEN) DOM0: LR is at __gic_init_bases+0x240/0x2bc

Do we have a plan to fix this?

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [V12 2/4] x86/xsaves: enable xsaves/xrstors/xsavec in xen

[Jan Beulich]

>>> On 25.11.15 at 08:51,  wrote:
> @@ -197,20 +373,26 @@ void xrstor(struct vcpu *v, uint64_t mask)
>  switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
>  {
>  default:
> -asm volatile ( "1: .byte 0x48,0x0f,0xae,0x2f\n"
> -   XRSTOR_FIXUP
> -   : [ptr] "+" (ptr), [lmask_out] "+" (lmask)
> -   : [mem] "m" (*ptr), [lmask_in] "g" (lmask),
> - [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size)
> -   : "ecx" );
> +alternative_io( "1: .byte 0x48,0x0f,0xae,0x2f\n"
> +XRSTOR_FIXUP,
> +".byte 0x48,0x0f,0xc7,0x1f\n"
> +XRSTOR_FIXUP,
> +X86_FEATURE_XSAVES,
> +ASM_OUTPUT2([ptr] "+" (ptr), [lmask_out] "+" 
> (lmask)),
> +[mem] "m" (*ptr), [lmask_in] "g" (lmask),
> +[hmask] "d" (hmask), [size] "m" (xsave_cntxt_size)
> +: "ecx" );

Mind explaining the point of the second XRSTOR_FIXUP?
Alternative patching doesn't deal with multiple sections at a time,
and I told you on the previous iteration that no second instance
should be necessary. If there is something I overlooked, please
tell me (you could and perhaps should have added such as remark
after the first --- separator at the top of the patch).

Jan


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

[Xen-devel] [PATCH OSSTEST] Debian: Move FANCYTTY=0 setting from preseed_create to preseed_base

[Ian Campbell]

This makes the console logs of any HVM or debian-installer created
easier to parse by omitting the escape characters.

Signed-off-by: Ian Campbell 
---
 Osstest/Debian.pm | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 464f190..76171c0 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -807,6 +807,14 @@ in-target apt-get install -y sysvinit-core
 END
 }
 
+preseed_hook_command($ho, 'late_command', $sfx, <> /target/etc/lsb-base-logging.sh
+END
+
+
 preseed_ssh($ho, $sfx);
 
 preseed_hook_command($ho, 'late_command', '', <<'END');
@@ -1058,13 +1066,6 @@ ls -l /dev/sd*
 true
 END
 
-preseed_hook_command($ho, 'late_command', $sfx, <> /target/etc/lsb-base-logging.sh
-END
-
 my $dtbs = "$d_i/dtbs.tar.gz";
 if (!stat $dtbs) {
 $!== or die "dtbs $!";
-- 
2.6.1


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