date:20170214

On 14/02/2017 08:04, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew 
>> Cooper
>> Sent: Tuesday, February 14, 2017 3:59 PM
>>
>> On 14/02/2017 02:52, Tian, Kevin wrote:
 From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
 Sent: Monday, February 13, 2017 10:32 PM

 hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
 restored when switching into guest context.  It should never have been 
 part of
 the migration state to start with, and Xen must not make any decisions 
 based
 on the value seen during restore.

 Identify it as obsolete in the header files, consistently save it as zero 
 and
 ignore it on restore.

 The MSRs must be considered dirty during VMCS creation to cause the proper
 defaults of 0 to be visible to the guest.

 Signed-off-by: Andrew Cooper 
>>> Reviewed-by: Kevin Tian , with one small comment.
>>>
>>> the effect of this patch should be more than not leaking syscall MSR.
>>> what about making the subject clearer when check-in?
>> What other effects do you think are going on here?  Yes, we now context
>> switch the MSRs right from the start of the domain, but that is
>> necessary to avoid leaking them.
>>
> If just looking at this patch, it's for general MSR save/restore policy,
> nothing specific to syscall MSR.

The only three MSRs which use this infrastructure are LSTAR, STAR and
FMASK.  What if I were to clarify that in the first paragraph?

~Andrew

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

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

2017-02-14 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5b97eb4c35316cbe8235ae526209263da818e1a4
baseline version:
 ovmf 296153c5bf9976a3b5f00566819f109d1c23c135

Last test of basis68554  2017-02-13 10:16:42 Z0 days
Testing same since68555  2017-02-14 06:16:27 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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


Push not applicable.


commit 5b97eb4c35316cbe8235ae526209263da818e1a4
Author: Yonghong Zhu 
Date:   Mon Feb 13 13:10:43 2017 +0800

BaseTools: Enhance BaseTools supports FixedAtBuild usage in VFR file

This patch is to update BaseTools generate Fixed PCD APIs and Value into
$(MODULE_NAME)StrDefs.h for VFR only. If the module has VFR files, and it
directly consumes FixedAtBuild PCD, BaseTool will generate those
FixedAtBuild PCD value into its $(MODULE_NAME)StrDefs.h. FixedPcdGetXX
macro are always generated. Every FixedPcd _PCD_VALUE_PcdName will be
generated without the postfix U or UL or ULL.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=348
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit 8b2a15fd5c7235f2998e26906e034204147d07a9
Author: Star Zeng 
Date:   Fri Feb 10 15:31:40 2017 +0800

MdePkg ACPI: Incorrect definition name for ACPI IORT Table signature

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=363

The definition name for ACPI IO Remapping Table signature is incorrect
in Acpi60.h and Acpi61.h as below:
EFI_ACPI_6_0_INTERRUPT_SOURCE_OVERRIDE_SIGNATURE
EFI_ACPI_6_1_INTERRUPT_SOURCE_OVERRIDE_SIGNATURE

The name should be changed to
EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE
EFI_ACPI_6_1_IO_REMAPPING_TABLE_SIGNATURE

The comments
///
/// "IORT" Interrupt Source Override
///
will be also changed to
///
/// "IORT" I/O Remapping Table
///

Cc: Alexei Fedorov 
Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

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

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

2017-02-14 Thread Tian, Kevin

> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper
> Sent: Tuesday, February 14, 2017 4:19 PM
> 
> On 14/02/2017 08:04, Tian, Kevin wrote:
> >> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
> Cooper
> >> Sent: Tuesday, February 14, 2017 3:59 PM
> >>
> >> On 14/02/2017 02:52, Tian, Kevin wrote:
>  From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>  Sent: Monday, February 13, 2017 10:32 PM
> 
>  hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to 
>  be
>  restored when switching into guest context.  It should never have been 
>  part of
>  the migration state to start with, and Xen must not make any decisions 
>  based
>  on the value seen during restore.
> 
>  Identify it as obsolete in the header files, consistently save it as 
>  zero and
>  ignore it on restore.
> 
>  The MSRs must be considered dirty during VMCS creation to cause the 
>  proper
>  defaults of 0 to be visible to the guest.
> 
>  Signed-off-by: Andrew Cooper 
> >>> Reviewed-by: Kevin Tian , with one small comment.
> >>>
> >>> the effect of this patch should be more than not leaking syscall MSR.
> >>> what about making the subject clearer when check-in?
> >> What other effects do you think are going on here?  Yes, we now context
> >> switch the MSRs right from the start of the domain, but that is
> >> necessary to avoid leaking them.
> >>
> > If just looking at this patch, it's for general MSR save/restore policy,
> > nothing specific to syscall MSR.
> 
> The only three MSRs which use this infrastructure are LSTAR, STAR and
> FMASK.  What if I were to clarify that in the first paragraph?
> 
> ~Andrew

I meant the subject line (talk about syscall MSR leakage) mismatches the 
commit message (for general MSR load)

Thanks
Kevin

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

[Xen-devel] [PATCH v3 1/2] xen/grants: print grant number and handle in hex format

Due to the large number of grants in use it seems more useful to print the
grant references and handlers in hex format rather than decimal.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v2:
 - Remove the () and the final dot of messages.
 - Fix printing the ref in the 'g' debug key, so that 3 chars are used for the
   ref itself.
---
 xen/common/grant_table.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index d3ea805..f780975 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -814,7 +814,7 @@ __gnttab_map_grant_ref(
 
 /* Bounds check on the grant ref */
 if ( unlikely(op->ref >= nr_grant_entries(rgt)))
-PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
+PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x\n", op->ref);
 
 act = active_entry_acquire(rgt, op->ref);
 shah = shared_entry_header(rgt, op->ref);
@@ -1087,7 +1087,7 @@ __gnttab_unmap_common(
 
 if ( unlikely(op->handle >= lgt->maptrack_limit) )
 {
-gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
+gdprintk(XENLOG_INFO, "Bad handle %#x\n", op->handle);
 op->status = GNTST_bad_handle;
 return;
 }
@@ -1099,7 +1099,7 @@ __gnttab_unmap_common(
 if ( unlikely(!read_atomic(&op->map->flags)) )
 {
 grant_read_unlock(lgt);
-gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
+gdprintk(XENLOG_INFO, "Zero flags for handle %#x\n", op->handle);
 op->status = GNTST_bad_handle;
 return;
 }
@@ -1132,7 +1132,7 @@ __gnttab_unmap_common(
 op->flags = read_atomic(&op->map->flags);
 if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
 {
-gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
+gdprintk(XENLOG_WARNING, "Unstable handle %#x\n", op->handle);
 rc = GNTST_bad_handle;
 goto unmap_out;
 }
@@ -1706,7 +1706,7 @@ gnttab_prepare_for_transfer(
 if ( unlikely(ref >= nr_grant_entries(rgt)) )
 {
 gdprintk(XENLOG_INFO,
-"Bad grant reference (%d) for transfer to domain(%d).\n",
+"Bad grant reference %#x for transfer to d%d\n",
 ref, rd->domain_id);
 goto fail;
 }
@@ -2672,7 +2672,7 @@ 
gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
 break;
 default:
 gdprintk(XENLOG_INFO,
- "bad flags %#x in grant %u when switching version\n",
+ "bad flags %#x in grant %#x when switching version\n",
  flags, i);
 /* fall through */
 case GTF_invalid:
@@ -2836,9 +2836,9 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t 
ref_b)
 
 /* Bounds check on the grant refs */
 if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
-PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-a (%d).\n", ref_a);
+PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-a %#x\n", ref_a);
 if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
-PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
+PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b %#x\n", ref_b);
 
 /* Swapping the same ref is a no-op. */
 if ( ref_a == ref_b )
@@ -2846,11 +2846,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t 
ref_b)
 
 act_a = active_entry_acquire(gt, ref_a);
 if ( act_a->pin )
-PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
+PIN_FAIL(out, GNTST_eagain, "ref a %#x busy\n", ref_a);
 
 act_b = active_entry_acquire(gt, ref_b);
 if ( act_b->pin )
-PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
+PIN_FAIL(out, GNTST_eagain, "ref b %#x busy\n", ref_b);
 
 if ( gt->gt_version == 1 )
 {
@@ -3284,9 +3284,8 @@ gnttab_release_mappings(
 
 ref = map->ref;
 
-gdprintk(XENLOG_INFO, "Grant release (%hu) ref:(%hu) "
-"flags:(%x) dom:(%hu)\n",
-handle, ref, map->flags, map->domid);
+gdprintk(XENLOG_INFO, "Grant release %#x ref %#x flags %#x dom %u\n",
+ handle, ref, map->flags, map->domid);
 
 rd = rcu_lock_domain_by_id(map->domid);
 if ( rd == NULL )
@@ -3530,8 +3529,8 @@ static void gnttab_usage_print(struct domain *rd)
 first = 0;
 }
 
-/*  [ddd]d 0xXX 0x  d 0xXX 0xXX */
-printk("[%3d]%5d 0x%06lx 0x%08x  %5d 0x%06"PRIx64" 0x%02x\n",
+/*  [0xXXX]  d 0xXX 0x  d 0xXX 0xXX */
+printk("[0x%03x]  %5d 0x%06lx 0x%08x

[Xen-devel] [PATCH v3 2/2] build/printf: fix incorrect format specifiers

The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:

mce.c:601:18: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
 smp_processor_id());
 ^

xenpm.c:102:23: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
what, argv[argc > 1]);
  ^

libxl_internal.c:25:69: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^
libxl_internal.c:26:21: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
fprintf(stderr, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^

This patch contains the fixes for them and enables -Wformat for clang.

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
---
NB: FWIW, there's a way to disable extra arguments checks
(-Wno-format-extra-args), that would prevent us from having to apply some of
the changes here. However, given that there are not that many occurrences, I
would rather leave the full checks of Wformat enabled.

NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only
against the components that build on FreeBSD (ie: no qemu-trad, and certainly
no blktap).
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Christoph Egger 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Change the format string for MCE to avoid duplicating CPU%i.
 - Remove the grant-ref format specifier change, it's already taken care in
   patch #1.
---
 Config.mk |  2 +-
 tools/libxl/libxl_internal.c  | 21 -
 tools/misc/xenpm.c| 13 -
 xen/arch/x86/cpu/mcheck/mce.c |  5 ++---
 4 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/Config.mk b/Config.mk
index 3a1d960..4739f36 100644
--- a/Config.mk
+++ b/Config.mk
@@ -215,7 +215,7 @@ CFLAGS += -Wall -Wstrict-prototypes
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 # and is over-zealous with the printf format lint
 # and is a bit too fierce about unused return values
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
+CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d288215..f492dae 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -20,14 +20,25 @@
 void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
  size_t nmemb, size_t size) {
 #define M "libxl: FATAL ERROR: memory allocation failure"
-#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
-  func, (unsigned long)nmemb, (unsigned long)size
-libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
-fprintf(stderr, L);
+#define M_SIZE M " (%s, %lu x %lu)\n"
+#define M_NSIZE M " (%s)\n"
+if (size) {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_SIZE, func, (unsigned long)nmemb, (unsigned long)size);
+   fprintf(stderr, M_SIZE, func, (unsigned long)nmemb,
+   (unsigned long)size);
+} else {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_NSIZE, func);
+   fprintf(stderr, M_NSIZE, func);
+
+}
+
 fflush(stderr);
 _exit(-1);
+#undef M_NSIZE
+#undef M_SIZE
 #undef M
-#undef L
 }
 
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index a2edee5..ded40b9 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -93,13 +93,16 @@ static void parse_cpuid(const char *arg, int *cpuid)
 static void parse_cpuid_and_int(int argc, char *argv[],
 int *cpuid, int *val, const char *what)
 {
-if ( argc > 1 )
-parse_cpuid(argv[0], cpuid);
+if ( argc == 0 )
+{
+ fprintf(stderr, "Missing %s\n", what);
+ exit(EINVAL);
+}
 
-if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
+parse_cpuid(argv[0], cpuid);
+if ( sscanf(argv[1], "%d", val) != 1 )
 {
-fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
-what, argv[argc > 1]);
+fprintf(stderr, "Invalid %s '%s'\n", what, argv[1]);
 exit(EINVAL);
 }
 }
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 2695b0c..6616026 100644
--- a/xen/arch/x86/cpu/mche

[Xen-devel] [PATCH v3 0/2] Enable Wformat for clang

Hello,

These patches fix the remaining issues so that Wformat can be enabled for
clang.

This patches have been tested on FreeBSD with clang 3.8, and travis:

https://travis-ci.org/royger/xen/builds/201165863

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

>>> On 13.02.17 at 19:26,  wrote:
> On 13/02/17 13:19, Jan Beulich wrote:
>> ---
>> TBD: Do we really want to re-init the TSS every time we are about to
>>  use it? This can happen quite often during boot, especially while
>>  grub is running.
> 
> The only case we need worry about is if the guest manually writes to the
> area covered by the vm86 tss.  I think, looking at the logic, that we
> properly restore the old %tr when re-entering protected mode, so we
> aren't at risk of having the vm86 tss on the leaving-side of a hardware
> task switch.

Yes. But that's the whole point of the question: The guest could
equally well write to the TSS manually right after we've initialized
it. And it only harms itself by doing so, hence we could as well
init the TSS on a less frequently executed path.

> We have lasted thus far without, but given the issues recently
> identified, the only safe conclusion to be drawn is that this
> functionality hasn't been used in anger.
> 
> For sensible performance, we need to keep the IO bitmap clear to avoid
> taking the #GP emulation path.
> 
> For correct behaviour, we need the entire software bitmap to be 0.

This one is just for reasonable performance too, afaict. If faulting,
just like with port accesses, we'd emulate the INT $nn.

>> +void hvm_prepare_vm86_tss(struct vcpu *v, uint32_t base, uint32_t limit)
>> +{
>> +/*
>> + * If the provided area is large enough to cover at least the ISA port
>> + * range, keep the bitmaps outside the base structure. For rather small
>> + * areas (namely relevant for guests having been migrated from older
>> + * Xen versions), maximize interrupt vector and port coverage by 
>> pointing
>> + * the I/O bitmap at 0x20 (which puts the interrupt redirection bitmap
>> + * right at zero), accepting accesses to port 0x235 (represented by bit 
>> 5
>> + * of byte 0x46) to trigger #GP (which will simply result in the access
>> + * being handled by the emulator via a slightly different path than it
>> + * would be anyway). Be sure to include one extra byte at the end of the
>> + * I/O bitmap (hence the missing "- 1" in the comparison is not an
>> + * off-by-one mistake), which we deliberately don't fill with all ones.
>> + */
>> +uint16_t iomap = (limit >= sizeof(struct tss32) + (0x100 / 8) + (0x400 
>> / 8)
>> +  ? sizeof(struct tss32) : 0) + (0x100 / 8);
>> +
>> +ASSERT(limit >= sizeof(struct tss32) - 1);
>> +hvm_copy_to_guest_phys(base, NULL, limit + 1, v);
>> +hvm_copy_to_guest_phys(base + offsetof(struct tss32, iomap),
>> +   &iomap, sizeof(iomap), v);
> 
> This should be linear rather than phys.

Strictly speaking yes, but since we're running with an ident map,
it doesn't matter. And I'd prefer not to have to introduce a vcpu
parameter to the linear copy function, as that would mean quite
a few changes elsewhere. Would you be okay with me just
attaching a respective comment here?

> In practice it will only make a difference if the guest manages to
> corrupt its IDENT_PT (which is why I suggested that we move the IDENT_PT
> entirely outside of the guest control), but in such a case, we will
> re-enter the guest with the vm86 tss pointing to something other than
> what we have just initialised.

Right, but again the guest would only harm itself.

>> @@ -4484,6 +4511,31 @@ static int hvmop_set_param(
>>  }
>>  d->arch.x87_fip_width = a.value;
>>  break;
>> +
>> +case HVM_PARAM_VM86_TSS:
>> +/* Hardware would silently truncate high bits. */
> 
> Does it?  I'd have thought it would be a vmentry failure.

I'm pretty sure I've tried it out, as I didn't have it that way initially.
I think a VM entry failure would result only if the address was
non-canonical.

Jan


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

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

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu305e6c8a2ff7a6e3f4942b50e853230f18eeb5a9
baseline version:
 qemuu6fe791b5e3aca8a6de8a322e85e76d2f13338a7e

Last test of basis   105279  2017-02-02 10:18:27 Z   11 days
Failing since105294  2017-02-02 16:42:47 Z   11 days   79 attempts
Testing same since   105775  2017-02-13 19:18:39 Z0 days2 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex BennÃ©e 
  Alex Williamson 
  Alexander Graf 
  Alexander Indenbaum 
  Andrea Bolognani 
  Anthony PERARD 
  Avinesh Kumar 
  Bharata B Rao 
  Cao jin 
  Christian Borntraeger 
  CÃ©dric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Dou Liyang 
  Dr. David Alan Gilbert 
  Edgar E. Iglesias 
  Eric Blake 
  Fam Zheng 
  Gerd Hoffmann 
  Greg Kurz 
  Haozhong Zhang 
  Hariharan T.S. 
  HervÃ© Poussineau 
  Jason Wang 
  Jeff Cody 
  Jing Liu 
  Joel Stanley 
  John P

Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

My previous reply got bounced because my tablet insisted on using HTML...

> -Original Message-
> 
> These need to be static. (I can fix it when committing.)

Ok, thanks.

> 
> And I am still not sure about using XEN_PAGE_SIZE. There is no
> dependency in the hypervisor on buffers being page-sized, is there? If
> not, XEN_PAGE_SIZE is here just because it happens to be 4K, which is a
> reasonable value.
> 
> How about just setting it to 4096?
> 

I chose XEN_PAGE_SIZE because the hypercall will eventually copy in the buffer 
so it seemed like a reasonable value to use. If you want to just use 4096 then 
I am ok with that.

  Paul

PS: If you want to change from XEN_PAGE_SIZE to 4096 then I assume you are 
happy to do this at commit and don't need me to send a v4?

> 
> -boris

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

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

>>> On 14.02.17 at 03:19,  wrote:
> vpmu_enable() can not use for check if vpmu is enabled in guest during
> booting up. Because linux kernel get the status of if supported pmu
> is earler than xen vpmu initialise. vpmu_enable() will return false
> even if vpmu has been enabled in guest.
> 
> Signed-off-by: Luwei Kang 

You've probably seen Boris' patch with the same overall goal. While
his looks to leave things a little too strict, yours looks to be widening
things a little too much. Do both of you think we could find a middle
ground, or do we need to accept the effect of possibly misleading
the guest by surfacing the CPUID data independent of vPMU mode,
as is done here?

Jan

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

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

2017-02-14 Thread Peter Zijlstra

On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
> It is the address of &steal_time that will exceed the 32-bit limit.

That seems extremely unlikely. That would mean we have more than 4G
worth of per-cpu variables declared in the kernel.

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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
> >>> On 10.02.17 at 13:33,  wrote:
> > ---
> > Changes since v5:
> >  - Adjust the logic to set need_paging.
> >  - Remove the usage of the _AC macro.
> >  - Subtract memory from the end of regions instead of the start.
> >  - Create the VM86_TSS before the identity page table, so that the page 
> > table
> >is aligned to a page boundary.
> >  - Use MB1_PAGES in modify_identity_mmio.
> >  - Move and simply the ASSERT in pvh_setup_p2m.
> >  - Move the creation of the PSE page tables to a separate function, and use 
> > it
> >in shadow_enable also.
> >  - Make the map modify_identiy_mmio parameter a constant.
> >  - Add a comment to HVM_VM86_TSS_SIZE, although it seems this might need
> >further fixing.
> 
> Indeed, I think this wants to be re-based on top of the patch I've
> just sent (with you Cc-ed).

Sure. Just done that.

> > +static int __init pvh_steal_ram(struct domain *d, unsigned long size,
> > +unsigned long align, paddr_t limit,
> > +paddr_t *addr)
> > +{
> > +unsigned int i = d->arch.nr_e820;
> > +
> > +/*
> > + * Alignment 0 should be set to 1, so it doesn't wrap around in the
> > + * calculations below.
> > + */
> > +align = align ? : 1;
> > +while ( i-- )
> > +{
> > +struct e820entry *entry = &d->arch.e820[i];
> > +
> > +if ( entry->type != E820_RAM || entry->addr + entry->size > limit 
> > ||
> > + entry->addr < MB(1) )
> > +continue;
> > +
> > +*addr = (entry->addr + entry->size - size) & ~(align - 1);
> 
> Without taking the present callers into account (who don't request
> huge alignment) this (theoretically) risks running into the low 1Mb.
> I see two options - either add a comment clarifying that an entry
> will never cross the 1Mb boundary (and hence the issue can't
> occur), or limit the alignment (by way of ASSERT()) to PAGE_SIZE
> (in which case no significant harm would result from crossing the
> boundary).

I don't mind adding the ASSERT, but I don't see how this can risk running into
the low 1MB. If entry->addr < MB(1) the entry is skipped. If an entry crosses
the 1Mb boundary it will certainly have entry->addr < 1Mb.

> > +static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
> > +{
> > +p2m_type_t p2mt;
> > +uint32_t rc, *ident_pt;
> > +uint8_t *tss;
> > +mfn_t mfn;
> > +paddr_t gaddr;
> > +
> > +/*
> > + * Steal some space from the last RAM region below 4GB and use it to
> > + * store the real-mode TSS.
> > + */
> > +if ( !pvh_steal_ram(d, HVM_VM86_TSS_SIZE, 0, GB(4), &gaddr) &&
> 
> Please request at least 128-byte alignment here, to avoid the
> base TSS structure crossing a page boundary.

Right, this TSS is loaded while using the identity PT, so with paging enabled.

> > + (tss = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)),
> > +   &mfn, &p2mt, 0, &rc)) )
> > +{
> > +memset(tss, 0, HVM_VM86_TSS_SIZE);
> 
> What makes you assume that you've mapped all the space you've
> allocated?

Hm, right, I've just realized we don't really need to map anything here, a
hvm_copy_to_guest_phys with NULL should be enough, and then I don't need to
worry about boundaries.

> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, uint32_t 
> > new_flags)
> >  return ((of | (of ^ nf)) == nf);
> >  }
> >  
> > +/* Build a 32bit PSE page table using 4MB pages. */
> > +static inline void
> > +write_32bit_pse_identmap(uint32_t *l2)
> 
> Why does this need to be an inline function?

Given it's size and the low number of callers I though it would be better to
make it inline, but since this is not in any performance critical path I'm
going to remove the inlining, although I think the compiler is probably going
to do it anyway.

Roger.

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

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

>>> On 14.02.17 at 09:40,  wrote:
>>  From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew 
>> Cooper
>> Sent: Tuesday, February 14, 2017 4:19 PM
>> 
>> On 14/02/2017 08:04, Tian, Kevin wrote:
>> >> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
>> Cooper
>> >> Sent: Tuesday, February 14, 2017 3:59 PM
>> >>
>> >> On 14/02/2017 02:52, Tian, Kevin wrote:
>>  From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>>  Sent: Monday, February 13, 2017 10:32 PM
>> 
>>  hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing 
>>  to be
>>  restored when switching into guest context.  It should never have been 
>>  part of
>>  the migration state to start with, and Xen must not make any decisions 
>>  based
>>  on the value seen during restore.
>> 
>>  Identify it as obsolete in the header files, consistently save it as 
>>  zero and
>>  ignore it on restore.
>> 
>>  The MSRs must be considered dirty during VMCS creation to cause the 
>>  proper
>>  defaults of 0 to be visible to the guest.
>> 
>>  Signed-off-by: Andrew Cooper 
>> >>> Reviewed-by: Kevin Tian , with one small comment.
>> >>>
>> >>> the effect of this patch should be more than not leaking syscall MSR.
>> >>> what about making the subject clearer when check-in?
>> >> What other effects do you think are going on here?  Yes, we now context
>> >> switch the MSRs right from the start of the domain, but that is
>> >> necessary to avoid leaking them.
>> >>
>> > If just looking at this patch, it's for general MSR save/restore policy,
>> > nothing specific to syscall MSR.
>> 
>> The only three MSRs which use this infrastructure are LSTAR, STAR and
>> FMASK.  What if I were to clarify that in the first paragraph?
> 
> I meant the subject line (talk about syscall MSR leakage) mismatches the 
> commit message (for general MSR load)

I'm with Andrew here: The title seems perfectly fine to me, considering
that the generic mechanism is only used for the syscall MSRs. Hence I
would think his offer to clarify the change in the first paragraph of the
commit message ought to suffice. Otherwise, may I ask that you make
a concrete suggestion as to what you'd like to see?

Jan


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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

On Tue, Feb 14, 2017 at 10:10:16AM +, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
> > >>> On 10.02.17 at 13:33,  wrote:
> > > --- a/xen/include/asm-x86/page.h
> > > +++ b/xen/include/asm-x86/page.h
> > > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, 
> > > uint32_t new_flags)
> > >  return ((of | (of ^ nf)) == nf);
> > >  }
> > >  
> > > +/* Build a 32bit PSE page table using 4MB pages. */
> > > +static inline void
> > > +write_32bit_pse_identmap(uint32_t *l2)
> > 
> > Why does this need to be an inline function?
> 
> Given it's size and the low number of callers I though it would be better to
> make it inline, but since this is not in any performance critical path I'm
> going to remove the inlining, although I think the compiler is probably going
> to do it anyway.

Right, now I remember why it needs to be inline:

xen/include/asm/page.h:379:1: error: unused function 'write_32bit_pse_identmap'
  [-Werror,-Wunused-function]
write_32bit_pse_identmap(uint32_t *l2)

Roger.

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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

>>> On 14.02.17 at 11:10,  wrote:
> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
>> >>> On 10.02.17 at 13:33,  wrote:
>> > +static int __init pvh_steal_ram(struct domain *d, unsigned long size,
>> > +unsigned long align, paddr_t limit,
>> > +paddr_t *addr)
>> > +{
>> > +unsigned int i = d->arch.nr_e820;
>> > +
>> > +/*
>> > + * Alignment 0 should be set to 1, so it doesn't wrap around in the
>> > + * calculations below.
>> > + */
>> > +align = align ? : 1;
>> > +while ( i-- )
>> > +{
>> > +struct e820entry *entry = &d->arch.e820[i];
>> > +
>> > +if ( entry->type != E820_RAM || entry->addr + entry->size > limit 
>> > ||
>> > + entry->addr < MB(1) )
>> > +continue;
>> > +
>> > +*addr = (entry->addr + entry->size - size) & ~(align - 1);
>> 
>> Without taking the present callers into account (who don't request
>> huge alignment) this (theoretically) risks running into the low 1Mb.
>> I see two options - either add a comment clarifying that an entry
>> will never cross the 1Mb boundary (and hence the issue can't
>> occur), or limit the alignment (by way of ASSERT()) to PAGE_SIZE
>> (in which case no significant harm would result from crossing the
>> boundary).
> 
> I don't mind adding the ASSERT, but I don't see how this can risk running into
> the low 1MB. If entry->addr < MB(1) the entry is skipped. If an entry crosses
> the 1Mb boundary it will certainly have entry->addr < 1Mb.

Oh, of course. I'm sorry for the noise (and the code here is fine
then as is).

>> > --- a/xen/include/asm-x86/page.h
>> > +++ b/xen/include/asm-x86/page.h
>> > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, uint32_t 
>> > new_flags)
>> >  return ((of | (of ^ nf)) == nf);
>> >  }
>> >  
>> > +/* Build a 32bit PSE page table using 4MB pages. */
>> > +static inline void
>> > +write_32bit_pse_identmap(uint32_t *l2)
>> 
>> Why does this need to be an inline function?
> 
> Given it's size and the low number of callers I though it would be better to
> make it inline, but since this is not in any performance critical path I'm
> going to remove the inlining, although I think the compiler is probably going
> to do it anyway.

I don't think so, unless you use LTO, as the function body can be
visible in at most one of the two CUs containing a call to it.

Jan


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

Re: [Xen-devel] [PATCH] configure: disable bash check for FreeBSD

On Mon, Feb 13, 2017 at 04:05:19PM +, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 03:59:15PM +, Wei Liu wrote:
> > On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> > > Sorry, I've forgot to re-generate the patch after adding the 
> > > maintainers...
> > > 
> > > On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> > > > Bash it's not used on FreeBSD.
> > > > 
> > > > Signed-off-by: Roger Pau Monné 
> > > > ---
> > > > Please re-run autoconf after applying
> > > > ---
> > > >  tools/configure.ac | 6 +-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/tools/configure.ac b/tools/configure.ac
> > > > index 873e18d..28a539c 100644
> > > > --- a/tools/configure.ac
> > > > +++ b/tools/configure.ac
> > > > @@ -320,7 +320,11 @@ AS_IF([test "x$xsmpolicy" = "xy"], [
> > > >  xsmpolicy="n"
> > > >  ])
> > > >  ])
> > > > -AX_PATH_PROG_OR_FAIL([BASH], [bash])
> > > > +dnl FreeBSD doesn't require bash (hotplug scripts are in plain sh)
> > 
> > I am not sure I follow this comment.  It implies hotplug scripts are the
> > only shell scripts that we ship or care and this check here is
> > specifically for that purpose.
> > 
> > If this comment is correct, isn't it better to just  remove this check?
> > AFAICT sh is standard.  If this comment is not correct, should we check
> > for the desired shell in FreeBSD?
> 
> Hotplug scripts are specific to each OS, and the FreeBSD ones use /bin/sh as
> the parser, which is present in base (ie: there's no reason to explicitly 
> check
> for it, also because it's the same that's used in configure). Linux OTOH uses
> bash as the hotplug script parser, hence this check is needed there.
> 
> Hope this makes sense, Roger.

Yes, it does.

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

>>> On 14.02.17 at 11:19,  wrote:
> On Tue, Feb 14, 2017 at 10:10:16AM +, Roger Pau Monne wrote:
>> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
>> > >>> On 10.02.17 at 13:33,  wrote:
>> > > --- a/xen/include/asm-x86/page.h
>> > > +++ b/xen/include/asm-x86/page.h
>> > > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, 
>> > > uint32_t new_flags)
>> > >  return ((of | (of ^ nf)) == nf);
>> > >  }
>> > >  
>> > > +/* Build a 32bit PSE page table using 4MB pages. */
>> > > +static inline void
>> > > +write_32bit_pse_identmap(uint32_t *l2)
>> > 
>> > Why does this need to be an inline function?
>> 
>> Given it's size and the low number of callers I though it would be better to
>> make it inline, but since this is not in any performance critical path I'm
>> going to remove the inlining, although I think the compiler is probably going
>> to do it anyway.
> 
> Right, now I remember why it needs to be inline:
> 
> xen/include/asm/page.h:379:1: error: unused function 
> 'write_32bit_pse_identmap'
>   [-Werror,-Wunused-function]
> write_32bit_pse_identmap(uint32_t *l2)

Funny - when sending the other reply a second ago I did think about
whether this needs clarification, and I decide it's obvious enough.
But it looks like I was wrong: Not inlining the function of course means
moving its definition to a C file, keeping just the declaration here.

Jan


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

[Xen-devel] [PATCH 0/2] x86: context switch handling adjustments

1: VMX: fix VMCS race on context-switch paths
2: x86: package up context switch hook pointers

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

On 14/02/17 02:19, Luwei Kang wrote:
> vpmu_enable() can not use for check if vpmu is enabled in guest during
> booting up. Because linux kernel get the status of if supported pmu
> is earler than xen vpmu initialise. vpmu_enable() will return false
> even if vpmu has been enabled in guest.

Sorry for breaking this.  However ...

> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..b63c5d8 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -713,8 +713,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
> struct cpuid_leaf *res)
>  }
>  }
>  
> -if ( vpmu_enabled(curr) &&
> - vpmu_is_set(vcpu_vpmu(curr), VPMU_CPU_HAS_DS) )
> +if ( opt_vpmu_enabled && boot_cpu_has(X86_FEATURE_DS) )

... this is overly general.  The visibility of these flags must be per
domain, and not globally like this.

In particular, XENPMU_MODE_ALL needs to expose PMU to dom0, but hide it
from all other domains, while even in the XENPMU_MODE_SELF case, only
domains explicitly configured with PMU should see it (as it generally
unsafe to migrate with).

Longterm (with the inclusion of the CPUID improvements), my plan was to
have PMU available in the max policy but hidden in the default policy,
which requires the toolstack to explicitly opt in for domains.  It would
opt in/out by setting the version field in guests CPUID policy and the
other feature bits.

~Andrew

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

[Xen-devel] [PATCH 1/2] VMX: fix VMCS race on context-switch paths

When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().

Similarly, when __context_switch() is being bypassed also on the second
(switch-in) path, VMCS ownership may have been lost and hence needs
re-establishing. Since there's no existing hook to put this in, add a
new one.

Reported-by: Kevin Mayer 
Reported-by: Anshul Makkar 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2098,11 +2098,14 @@ void context_switch(struct vcpu *prev, s
 
 set_current(next);
 
-if ( (per_cpu(curr_vcpu, cpu) == next) ||
- (is_idle_domain(nextd) && cpu_online(cpu)) )
+if ( (per_cpu(curr_vcpu, cpu) == next) )
 {
+if ( next->arch.ctxt_switch_same )
+next->arch.ctxt_switch_same(next);
 local_irq_enable();
 }
+else if ( is_idle_domain(nextd) && cpu_online(cpu) )
+local_irq_enable();
 else
 {
 __context_switch();
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -552,6 +552,27 @@ static void vmx_load_vmcs(struct vcpu *v
 local_irq_restore(flags);
 }
 
+void vmx_vmcs_reload(struct vcpu *v)
+{
+/*
+ * As we're running with interrupts disabled, we can't acquire
+ * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
+ * the VMCS can't be taken away from us anymore if we still own it.
+ */
+ASSERT(!local_irq_is_enabled());
+if ( v->arch.hvm_vmx.vmcs_pa == this_cpu(current_vmcs) )
+return;
+ASSERT(!this_cpu(current_vmcs));
+
+/*
+ * Wait for the remote side to be done with the VMCS before loading
+ * it here.
+ */
+while ( v->arch.hvm_vmx.active_cpu != -1 )
+cpu_relax();
+vmx_load_vmcs(v);
+}
+
 int vmx_cpu_up_prepare(unsigned int cpu)
 {
 /*
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -298,6 +298,7 @@ static int vmx_vcpu_initialise(struct vc
 v->arch.schedule_tail= vmx_do_resume;
 v->arch.ctxt_switch_from = vmx_ctxt_switch_from;
 v->arch.ctxt_switch_to   = vmx_ctxt_switch_to;
+v->arch.ctxt_switch_same = vmx_vmcs_reload;
 
 if ( (rc = vmx_create_vmcs(v)) != 0 )
 {
@@ -936,6 +937,18 @@ static void vmx_ctxt_switch_from(struct
 if ( unlikely(!this_cpu(vmxon)) )
 return;
 
+if ( !v->is_running )
+{
+/*
+ * When this vCPU isn't marked as running anymore, a remote pCPU's
+ * attempt to pause us (from vmx_vmcs_enter()) won't have a reason
+ * to spin in vcpu_sleep_sync(), and hence that pCPU might have taken
+ * away the VMCS from us. As we're running with interrupts disabled,
+ * we also can't call vmx_vmcs_enter().
+ */
+vmx_vmcs_reload(v);
+}
+
 vmx_fpu_leave(v);
 vmx_save_guest_msrs(v);
 vmx_restore_host_msrs();
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -514,6 +514,7 @@ struct arch_vcpu
 
 void (*ctxt_switch_from) (struct vcpu *);
 void (*ctxt_switch_to) (struct vcpu *);
+void (*ctxt_switch_same) (struct vcpu *);
 
 struct vpmu_struct vpmu;
 
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -174,6 +174,7 @@ void vmx_destroy_vmcs(struct vcpu *v);
 void vmx_vmcs_enter(struct vcpu *v);
 bool_t __must_check vmx_vmcs_try_enter(struct vcpu *v);
 void vmx_vmcs_exit(struct vcpu *v);
+void vmx_vmcs_reload(struct vcpu *v);
 
 #define CPU_BASED_VIRTUAL_INTR_PENDING0x0004
 #define CPU_BASED_USE_TSC_OFFSETING   0x0008


VMX: fix VMCS race on context-switch paths

When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().

Similarly, when __context_switch() is being bypassed also on the second
(switch-in) path, VM

[Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers

They're all solely dependent on guest type, so we don't need to repeat
all the same four pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.

Since touching it anyway, take the opportunity and move schedule_tail()
into the only C file needing it.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -426,16 +426,8 @@ int vcpu_initialise(struct vcpu *v)
 /* PV guests by default have a 100Hz ticker. */
 v->periodic_period = MILLISECS(10);
 }
-
-v->arch.schedule_tail = continue_nonidle_domain;
-v->arch.ctxt_switch_from = paravirt_ctxt_switch_from;
-v->arch.ctxt_switch_to   = paravirt_ctxt_switch_to;
-
-if ( is_idle_domain(d) )
-{
-v->arch.schedule_tail = continue_idle_domain;
-v->arch.cr3   = __pa(idle_pg_table);
-}
+else
+v->arch.cr3 = __pa(idle_pg_table);
 
 v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
 
@@ -642,8 +634,23 @@ int arch_domain_create(struct domain *d,
 goto fail;
 }
 else
+{
+static const struct arch_csw pv_csw = {
+.from = paravirt_ctxt_switch_from,
+.to   = paravirt_ctxt_switch_to,
+.tail = continue_nonidle_domain,
+};
+static const struct arch_csw idle_csw = {
+.from = paravirt_ctxt_switch_from,
+.to   = paravirt_ctxt_switch_to,
+.tail = continue_idle_domain,
+};
+
+d->arch.ctxt_switch = is_idle_domain(d) ? &idle_csw : &pv_csw;
+
 /* 64-bit PV guest by default. */
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+}
 
 /* initialize default tsc behavior in case tools don't */
 tsc_set_info(d, TSC_MODE_DEFAULT, 0UL, 0, 0);
@@ -1997,7 +2004,7 @@ static void __context_switch(void)
 {
 memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
 vcpu_save_fpu(p);
-p->arch.ctxt_switch_from(p);
+pd->arch.ctxt_switch->from(p);
 }
 
 /*
@@ -2023,7 +2030,7 @@ static void __context_switch(void)
 set_msr_xss(n->arch.hvm_vcpu.msr_xss);
 }
 vcpu_restore_fpu_eager(n);
-n->arch.ctxt_switch_to(n);
+nd->arch.ctxt_switch->to(n);
 }
 
 psr_ctxt_switch_to(nd);
@@ -2066,6 +2073,15 @@ static void __context_switch(void)
 per_cpu(curr_vcpu, cpu) = n;
 }
 
+/*
+ * Schedule tail *should* be a terminal function pointer, but leave a bugframe
+ * around just incase it returns, to save going back into the context
+ * switching code and leaving a far more subtle crash to diagnose.
+ */
+#define schedule_tail(vcpu) do {  \
+(((vcpu)->domain->arch.ctxt_switch->tail)(vcpu)); \
+BUG();\
+} while (0)
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
 {
@@ -2100,8 +2116,8 @@ void context_switch(struct vcpu *prev, s
 
 if ( (per_cpu(curr_vcpu, cpu) == next) )
 {
-if ( next->arch.ctxt_switch_same )
-next->arch.ctxt_switch_same(next);
+if ( nextd->arch.ctxt_switch->same )
+nextd->arch.ctxt_switch->same(next);
 local_irq_enable();
 }
 else if ( is_idle_domain(nextd) && cpu_online(cpu) )
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1144,6 +1144,14 @@ void svm_host_osvw_init()
 
 static int svm_domain_initialise(struct domain *d)
 {
+static const struct arch_csw csw = {
+.from = svm_ctxt_switch_from,
+.to   = svm_ctxt_switch_to,
+.tail = svm_do_resume,
+};
+
+d->arch.ctxt_switch = &csw;
+
 return 0;
 }
 
@@ -1155,10 +1163,6 @@ static int svm_vcpu_initialise(struct vc
 {
 int rc;
 
-v->arch.schedule_tail= svm_do_resume;
-v->arch.ctxt_switch_from = svm_ctxt_switch_from;
-v->arch.ctxt_switch_to   = svm_ctxt_switch_to;
-
 v->arch.hvm_svm.launch_core = -1;
 
 if ( (rc = svm_create_vmcb(v)) != 0 )
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -268,8 +268,16 @@ void vmx_pi_hooks_deassign(struct domain
 
 static int vmx_domain_initialise(struct domain *d)
 {
+static const struct arch_csw csw = {
+.from = vmx_ctxt_switch_from,
+.to   = vmx_ctxt_switch_to,
+.same = vmx_vmcs_reload,
+.tail = vmx_do_resume,
+};
 int rc;
 
+d->arch.ctxt_switch = &csw;
+
 if ( !has_vlapic(d) )
 return 0;
 
@@ -295,11 +303,6 @@ static int vmx_vcpu_initialise(struct vc
 
 INIT_LIST_HEAD(&v->arch.hvm_vmx.pi_blocking.list);
 
-v->arch.schedule_tail= vmx_do_resume;
-v->arch.ctxt_switch_from = vmx_ctxt_switch_from;
-v->arch.ctxt_switch_to   = vmx_ctxt_switch_to;
-v->arch.ctxt_switch_same = vmx_vmcs_reload;
-
 if ( (rc = vmx_create_vmcs(v)) != 0 )
 {
 dprintk(XENLOG_WARNING,
--- a/xen/include/asm-x

Re: [Xen-devel] [PATCH v4 0/3] x86/vvmx: correctly emulate VMREAD and VMWRITE

On 13/02/17 14:21, Sergey Dyasli wrote:
> Sergey Dyasli (3):
>   x86/vmx: introduce VMX_INSN_SUCCEED
>   x86/vvmx: correctly emulate VMWRITE
>   x86/vvmx: correctly emulate VMREAD

Committed, thanks.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

On Thu, Feb 09, 2017 at 11:35:16AM +, George Dunlap wrote:
> On 09/02/17 11:24, Wei Liu wrote:
> > On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote:
> >> On 09/02/17 10:35, Wei Liu wrote:
> >>> On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
>  On 08/02/17 16:11, Dario Faggioli wrote:
> > On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
> >> Callers to libxl_cpupool_create() can either request a specific pool
> >> id, or request that Xen do it for them.  But at the moment, the
> >> "automatic" selection is indicated by using a magic value, 0.  This
> >> is
> >> undesirable both because it doesn't obviously have meaning, but also
> >> because '0' is a valid cpupool (albeit one which at the moment can't
> >> be changed).
> >>
> >> Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
> >> instead.  Still accept '0' as meaning "ANY" for backwards
> >> compatibility.
> >>
> >> Signed-off-by: George Dunlap 
> >>
> > Reviewed-by: Dario Faggioli 
> >
> > With one remark.
> >
> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> >> --- a/tools/libxl/libxl.h
> >> +++ b/tools/libxl/libxl.h
> >> @@ -2086,6 +2086,12 @@ int libxl_tmem_shared_auth(libxl_ctx *ctx,
> >> uint32_t domid, char* uuid,
> >>  int libxl_tmem_freeable(libxl_ctx *ctx);
> >>  
> >>  int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
> >> +
> >> +/* 
> >> + * Set poolid to LIBXL_CPUOOL_POOLID_ANY to have Xen choose a
> >> + * free poolid for you.
> >> + */
> >> +#define LIBXL_CPUPOOL_POOLID_ANY 0x
> >>
> > Do we want this to be here, or in libxl_types.idl.
> >
> > Asking because, AFAICT, it's the only one LIBXL_FOO_BAR defined like
> > this. I appreciate that there's few point in making this an enum, as it
> > is only one value, and will most likely remain so, but still, I thought
> > I'd at least bring this up.
> >
> > FWIW, my Reviewed-by stands both if it is kept as is, and if it is
> > moved to IDL.
> 
>  Well there's things like:
> 
>  #define LIBXL_PCI_FUNC_ALL (~0U)
> 
>  #define LIBXL_TIMER_MODE_DEFAULT -1
>  #define LIBXL_MEMKB_DEFAULT ~0ULL
> 
>  #define LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT (2048 * 1024)
> 
>  #define LIBXL_MS_VM_GENID_LEN 16
> 
>  #define LIBXL_SUSPEND_DEBUG 1
>  #define LIBXL_SUSPEND_LIVE 2
> 
>  Many of which seem similar in some ways.  Enums I think are meant to be
>  exhaustive (as in, contain all possible options), not be special cases.
> 
>  But I'm happy to defer to the tools maintainers.
> 
> >>>
> >>> I don't really care if it is an enum or a macro.
> >>>
> >>> There is an issue that is  more subtle than where it lives or what form
> >>> it is in.
> >>>
> >>> You need to modify all the poolid fields in various structure to make it
> >>> as default.  Otherwise the whole json infrastructure would still use 0
> >>> as the default value.
> >>
> >> Hmm, at the moment there are only two structs that include poolid:
> >> cpupoolinfo, which is OUT-only (so the field should always be
> >> initialized) and domain_create_info, for which 0 is a much better
> >> default logically than "ANY".
> >>
> > 
> > I don't follow here. Isn't 0 already "ANY"?
> 
> No.  This is why I'm bothering to paint this bikeshed: In every context
> *except* "cpupool create", 0 means cpupool0 -- the one that was created
> at boot, which always contains dom0, and which cannot be destroyed.
> (You can only remove all but one of the cpus.)  If you remove a cpupool
> from poolid 0, you remove it from cpupool0, not "any" pool.  If you
> create a domain and ask to put it in poolid 0, it will be put in
> cpupool0, not "any" pool.  The only context in which "0" currently means
> "any" is when you're creating a cpupool.
> 

OK. This makes sense.

> >>> And maybe a LIBXL_HAVE macro is needed, too.
> >>
> >> I thought about that, but figured people could just do #ifdef
> >> LIBXL_CPUPOOL_POOLID_ANY.  It seemed a bit strange to define a whole new
> >> macro just to see if another macro existed.
> >>
> > 
> > I want to reserve the possibility to change that into an enum in the
> > future.
> 
> Yes, I had thought of that -- but like I said, I thought enums were
> meant mostly for things for which there was an exhaustive list.  In this
> case it's a "magic" value for a parameter which normally has a plain
> numerical meaning.
> 
> But I can add the #define if you wish.
> 

You don't need to do that.

Wei.

>  -George

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

Re: [Xen-devel] [PATCH 2/5] x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c

>>> On 13.02.17 at 14:03,  wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -0,0 +1,332 @@
> +/**
> + * arch/hvm/hypercall.c
> + *
> + * HVM hypercall dispatching routines
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Copyright (c) 2017 Citrix Systems Ltd.
> + */
> +#include 
> +#include 
> +
> +#include 
> +
> +static int grant_table_op_is_allowed(unsigned int cmd)
> +{
> +switch (cmd) {

Pure code motion or not, I think it would be nice to fix coding style
(here and elsewhere, albeit the only other issue I can spot are a
few missing blanks lines between non-fall-through case statements).

With that
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 2/5] x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c

On 14/02/17 10:33, Jan Beulich wrote:
 On 13.02.17 at 14:03,  wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -0,0 +1,332 @@
>> +/**
>> + * arch/hvm/hypercall.c
>> + *
>> + * HVM hypercall dispatching routines
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; If not, see .
>> + *
>> + * Copyright (c) 2017 Citrix Systems Ltd.
>> + */
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +static int grant_table_op_is_allowed(unsigned int cmd)
>> +{
>> +switch (cmd) {
> Pure code motion or not, I think it would be nice to fix coding style
> (here and elsewhere, albeit the only other issue I can spot are a
> few missing blanks lines between non-fall-through case statements).
>
> With that
> Acked-by: Jan Beulich 

I believe all of those issues are addressed in the following patches. 
If not, I can certainly fix them up here.

~Andrew

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

Re: [Xen-devel] [PATCH 3/5] x86/hvm: Improve memory_op hypercall dispatching

>>> On 13.02.17 at 14:03,  wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -23,6 +23,29 @@
>  
>  #include 
>  
> +static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> +{
> +struct vcpu *curr = current;

const? (yes, you modify *curr->domain below, but *curr isn't being
altered)

Other than that
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 4/5] x86/hvm: Improve grant_table_op hypercall dispatching

>>> On 13.02.17 at 14:03,  wrote:
> hvm_grant_table_op() and hvm_grant_table_op_compat32() are almost identical,
> but there is no need to have two functions instantiated at the end of
> different function pointers.
> 
> Combine the two into a single hvm_grant_table_op() (folding
> grant_table_op_is_allowed() into is now-single caller) and dispatch to
> {do,compat}_grant_table_op() based on the hcall_64bit setting.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

[Xen-devel] [PATCH] x86/vmx: fix compilation after 997382

997382 introduced the following errors:

intr.c:342:46: error: address of array 'vlapic->regs->data' will always 
evaluate to 'true'
  [-Werror,-Wpointer-bool-conversion]
if ( vlapic && vlapic->regs->data )
~~ ~~^~~~
intr.c:352:42: error: address of array 'pi_desc->pir' will always evaluate to 
'true'
  [-Werror,-Wpointer-bool-conversion]
if ( pi_desc && pi_desc->pir )
 ~~ ~^~~
Both of those checks are done against static arrays, which doesn't seem to make
much sense, so just remove them.

Signed-off-by: Roger Pau Monné 
---
NB: maybe the first check should be against vlapic->regs?
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Chao Gao 
---
 xen/arch/x86/hvm/vmx/intr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 1e17c4e..b9a02d1 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -339,7 +339,7 @@ void vmx_intr_assist(void)
current, intack.source, intack.vector, pt_vector);
 
 vlapic = vcpu_vlapic(v);
-if ( vlapic && vlapic->regs->data )
+if ( vlapic )
 {
 word = (const void *)&vlapic->regs->data[APIC_IRR];
 printk(XENLOG_ERR "vIRR:");
@@ -349,7 +349,7 @@ void vmx_intr_assist(void)
 }
 
 pi_desc = &v->arch.hvm_vmx.pi_desc;
-if ( pi_desc && pi_desc->pir )
+if ( pi_desc )
 {
 word = (const void *)&pi_desc->pir;
 printk(XENLOG_ERR " PIR:");
-- 
2.10.1 (Apple Git-78)


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

Re: [Xen-devel] [PATCH 5/5] x86/hvm: Improve physdev_op hypercall dispatching

>>> On 13.02.17 at 14:03,  wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -73,10 +73,12 @@ static long hvm_grant_table_op(
>  
>  static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
> +struct vcpu *curr = current;

With this constified
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 2/5] x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c

>>> On 14.02.17 at 11:33,  wrote:
> On 14/02/17 10:33, Jan Beulich wrote:
> On 13.02.17 at 14:03,  wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -0,0 +1,332 @@
>>> 
> +/***
> ***
>>> + * arch/hvm/hypercall.c
>>> + *
>>> + * HVM hypercall dispatching routines
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program; If not, see .
>>> + *
>>> + * Copyright (c) 2017 Citrix Systems Ltd.
>>> + */
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +static int grant_table_op_is_allowed(unsigned int cmd)
>>> +{
>>> +switch (cmd) {
>> Pure code motion or not, I think it would be nice to fix coding style
>> (here and elsewhere, albeit the only other issue I can spot are a
>> few missing blanks lines between non-fall-through case statements).
>>
>> With that
>> Acked-by: Jan Beulich 
> 
> I believe all of those issues are addressed in the following patches. 
> If not, I can certainly fix them up here.

Right, I've just seen that while going through the later ones.
Either way is fine with me.

Jan


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

[Xen-devel] [distros-debian-snapshot test] 68556: regressions - trouble: blocked/broken/fail/pass

2017-02-14 Thread Platform Team regression test user

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-daily-netboot-pygrub 10 guest-start fail REGR. vs. 68530
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
68530
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 
68530

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   68530

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



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] x86/vmx: fix compilation after 997382

>>> On 14.02.17 at 11:37,  wrote:
> 997382 introduced the following errors:
> 
> intr.c:342:46: error: address of array 'vlapic->regs->data' will always 
> evaluate to 'true'
>   [-Werror,-Wpointer-bool-conversion]
> if ( vlapic && vlapic->regs->data )
> ~~ ~~^~~~
> intr.c:352:42: error: address of array 'pi_desc->pir' will always evaluate to 
> 'true'
>   [-Werror,-Wpointer-bool-conversion]
> if ( pi_desc && pi_desc->pir )
>  ~~ ~^~~
> Both of those checks are done against static arrays, which doesn't seem to 
> make
> much sense, so just remove them.

Darn, I had meant to check while massaging the patch, but then
forgot.

> Signed-off-by: Roger Pau Monné 
> ---
> NB: maybe the first check should be against vlapic->regs?

Yes, please. Or I can do this while committing. The subject, btw,
should probably include "clang", as neither I nor osstest have an
issue with gcc?

Jan

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

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

>>> On 07.02.17 at 00:32,  wrote:
> Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
> added a assertion that intack.vector is the highest priority vector. But
> according to the osstest, the assertion failed sometimes. More discussion can
> be found in the thread
> (https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.html).
> 
> The assertion failure is hard to reproduce. In order to root cause issue, this
> patch is to add logs to dump PIR and vIRR when failure takes place. It should
> be reverted once the root cause is found.

Julien, could you add a note on the 4.9 tracking list for us to not
forget to revert this (or at least add NDEBUG conditionals) the
latest in the RC phase?

Thanks, Jan


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

Re: [Xen-devel] [PATCH] x86/vmx: fix compilation after 997382

On Tue, Feb 14, 2017 at 03:46:37AM -0700, Jan Beulich wrote:
> >>> On 14.02.17 at 11:37,  wrote:
> > 997382 introduced the following errors:
> > 
> > intr.c:342:46: error: address of array 'vlapic->regs->data' will always 
> > evaluate to 'true'
> >   [-Werror,-Wpointer-bool-conversion]
> > if ( vlapic && vlapic->regs->data )
> > ~~ ~~^~~~
> > intr.c:352:42: error: address of array 'pi_desc->pir' will always evaluate 
> > to 
> > 'true'
> >   [-Werror,-Wpointer-bool-conversion]
> > if ( pi_desc && pi_desc->pir )
> >  ~~ ~^~~
> > Both of those checks are done against static arrays, which doesn't seem to 
> > make
> > much sense, so just remove them.
> 
> Darn, I had meant to check while massaging the patch, but then
> forgot.
> 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > NB: maybe the first check should be against vlapic->regs?
> 
> Yes, please. Or I can do this while committing. The subject, btw,
> should probably include "clang", as neither I nor osstest have an
> issue with gcc?

If you don't mind please change the check while committing, so that it's
against vlapic->regs. Regarding the subject, what about:

x86/vmx: fix compilation with clang after 997382

FWIW, neither the versions of clang in travis seem to pick this up:

https://travis-ci.org/xen-project/xen/builds/201180775

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2 01/11] x86emul: catch exceptions occurring in stubs

On 13/02/17 16:20, Jan Beulich wrote:
 On 13.02.17 at 14:58,  wrote:
>> On 13/02/17 11:40, Jan Beulich wrote:
>> On 10.02.17 at 17:38,  wrote:
 On 01/02/17 11:12, Jan Beulich wrote:
> Before adding more use of stubs cloned from decoded guest insns, guard
> ourselves against mistakes there: Should an exception (with the
> noteworthy exception of #PF) occur inside the stub, forward it to the
> guest.
 Why exclude #PF ? Nothing in a stub should be hitting a pagefault in the
 first place.
>>> To be honest, I've been considering to limit this to just #UD. We
>>> clearly shouldn't hide memory addressing issues, as them going
>>> by silently means information leaks. Nevertheless including #PF
>>> here would be a trivial change to the patch.
>> When I considered this first, my plan was to catch the fault and crash
>> the domain, rather than allow it to continue (FPU exceptions being the
>> exception).
>>
>> One way or another, by the time we encounter a fault in the stubs,
>> something has gone wrong, and crashing the domain is better than
>> crashing the host.  (In fact, I am looking to extend this principle
>> further, e.g. with vmread/vmwrite failures.)
>>
>> I don't see #PF being meaningfully different to #GP or #SS here.  If we
>> get a fault, an action was stopped, but we can never catch the issues
>> which don't fault in the first place.
>>
>> #UD is a little more tricky.  It either means that we created a
>> malformed stub, or we didn't have sufficient feature checking, both of
>> which are emulation bugs.  This could be passed back to the domain, but
>> I'd err on the side of making it more obvious by crashing the domain. 
> Generally yes, but I think here we really should forward at least
> #UD. I can agree with other faults being terminal to the domain,
> which will the also allow #PF to be handled uniformly (as there
> won't be a need to propagate some CR2 value).
>
>> (Perhaps changing behaviour based on debug?)
> Not here, I would say - this logic should be tested the way it is
> meant to be run in production.

Ok.  Could we at least get a printk() in the case of handing a fault
like this back to the guest, so we stand a chance of noticing the
emulation bug and fixing it?

>
> ---
> There's one possible caveat here: A stub invocation immediately
> followed by another instruction having fault revovery attached to it
> would not work properly, as the table lookup can only ever find one of
> the two entries. Such CALL instructions would then need to be followed
> by a NOP for disambiguation (even if only a slim chance exists for the
> compiler to emit things that way).
 Why key on return address at all?  %rip being in the stubs should be
 good enough.
>>> Well, we need unique (key-address, recovery-address) tuples,
>>> and key-address can't possibly be an address inside the stub
>>> (for both the address varying between CPUs and said uniqueness
>>> requirement).
>> We don't necessarily need to use the extable infrastructure, and you
>> don't appear to be using a unique key at all.
> How am I not? How would both the self test and the emulator
> uses work without unique addresses to key off of?

I'd not followed how you were hooking the information up.  Sorry for the
noise.

> @@ -85,15 +86,88 @@ search_one_extable(const struct exceptio
>  }
>  
>  unsigned long
> -search_exception_table(unsigned long addr)
> +search_exception_table(const struct cpu_user_regs *regs, bool check_stub)
>  {
> -const struct virtual_region *region = find_text_region(addr);
> +const struct virtual_region *region = find_text_region(regs->rip);
> +unsigned long stub = this_cpu(stubs.addr);
>  
>  if ( region && region->ex )
> -return search_one_extable(region->ex, region->ex_end - 1, addr);
> +return search_one_extable(region->ex, region->ex_end - 1, 
> regs->rip);
> +
> +if ( check_stub &&
> + regs->rip >= stub + STUB_BUF_SIZE / 2 &&
> + regs->rip < stub + STUB_BUF_SIZE &&
> + regs->rsp > (unsigned long)&check_stub &&
> + regs->rsp < (unsigned long)get_cpu_info() )
 How much do we care about accidentally clobbering %rsp in a stub?
>>> I think we can't guard against everything, but we should do the
>>> best we reasonably can. I.e. in the case here, rather than
>>> reading the return (key) address from somewhere outside the
>>> stack (easing a possible attacker's job), don't handle the fault
>>> at all, and instead accept the crash.
>> As before, it would be better overall to result in a domain_crash() than
>> a host crash.
> Yes (see above), but in no case should we do the crashing here
> (or else, even if it may seem marginal, the self test won't work
> anymore). To provide best functionality to current and possible
> future uses, we should leave the decision for which exceptions
> to crash the guest to t

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

2017-02-14 Thread Kang, Luwei

> >>> On 14.02.17 at 03:19,  wrote:
> > vpmu_enable() can not use for check if vpmu is enabled in guest during
> > booting up. Because linux kernel get the status of if supported pmu is
> > earler than xen vpmu initialise. vpmu_enable() will return false even
> > if vpmu has been enabled in guest.
> >
> > Signed-off-by: Luwei Kang 
> 
> You've probably seen Boris' patch with the same overall goal. While his looks 
> to leave things a little too strict, yours looks to be widening
> things a little too much. Do both of you think we could find a middle ground, 
> or do we need to accept the effect of possibly misleading
> the guest by surfacing the CPUID data independent of vPMU mode, as is done 
> here?
> 
Sorry, I didn't check the mail list on time and don't know somebody is working 
on this.  I think Boris' patch is better than me.

Thanks,
Luwei Kang

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

[Xen-devel] [libvirt test] 105785: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  723fef99c0e29d1a327aaea4cef477609f6ccbc2
baseline version:
 libvirt  5620c609596cdfb3b809afab1b37b7f00fe831a1

Last test of basis   105720  2017-02-11 04:21:00 Z3 days
Failing since105759  2017-02-13 04:20:10 Z1 days2 attempts
Testing same since   105785  2017-02-14 04:20:10 Z0 days1 attempts


People who touched revisions under test:
  JÃ¡n Tomko 
  Marc Hartmayer 
  Roman Bogorodskiy 

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



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

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

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

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

2017-02-14 Thread Kang, Luwei

> On 14/02/17 02:19, Luwei Kang wrote:
> > vpmu_enable() can not use for check if vpmu is enabled in guest during
> > booting up. Because linux kernel get the status of if supported pmu is
> > earler than xen vpmu initialise. vpmu_enable() will return false even
> > if vpmu has been enabled in guest.
> 
> Sorry for breaking this.  However ...
> 
> > diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index
> > e0a387e..b63c5d8 100644
> > --- a/xen/arch/x86/cpuid.c
> > +++ b/xen/arch/x86/cpuid.c
> > @@ -713,8 +713,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
> > struct cpuid_leaf *res)
> >  }
> >  }
> >
> > -if ( vpmu_enabled(curr) &&
> > - vpmu_is_set(vcpu_vpmu(curr), VPMU_CPU_HAS_DS) )
> > +if ( opt_vpmu_enabled && boot_cpu_has(X86_FEATURE_DS) )
> 
> ... this is overly general.  The visibility of these flags must be per 
> domain, and not globally like this.
> 
> In particular, XENPMU_MODE_ALL needs to expose PMU to dom0, but hide it from 
> all other domains, while even in the
> XENPMU_MODE_SELF case, only domains explicitly configured with PMU should see 
> it (as it generally unsafe to migrate with).
> 
> Longterm (with the inclusion of the CPUID improvements), my plan was to have 
> PMU available in the max policy but hidden in the
> default policy, which requires the toolstack to explicitly opt in for 
> domains.  It would opt in/out by setting the version field in guests
> CPUID policy and the other feature bits.
> 
Get it. Thanks for your explanation.

Thanks,
Luwei Kang

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

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

2017-02-14 Thread George Dunlap

On Tue, Feb 14, 2017 at 10:29 AM, Wei Liu  wrote:
> On Thu, Feb 09, 2017 at 11:35:16AM +, George Dunlap wrote:
>> No.  This is why I'm bothering to paint this bikeshed: In every context
>> *except* "cpupool create", 0 means cpupool0 -- the one that was created
>> at boot, which always contains dom0, and which cannot be destroyed.
>> (You can only remove all but one of the cpus.)  If you remove a cpupool
>> from poolid 0, you remove it from cpupool0, not "any" pool.  If you
>> create a domain and ask to put it in poolid 0, it will be put in
>> cpupool0, not "any" pool.  The only context in which "0" currently means
>> "any" is when you're creating a cpupool.
>>
>
> OK. This makes sense.
>
[snip]
>> > I want to reserve the possibility to change that into an enum in the
>> > future.
>>
>> Yes, I had thought of that -- but like I said, I thought enums were
>> meant mostly for things for which there was an exhaustive list.  In this
>> case it's a "magic" value for a parameter which normally has a plain
>> numerical meaning.
>>
>> But I can add the #define if you wish.
>>
>
> You don't need to do that.

Is that an Ack? :-)

 -George

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

[Xen-devel] [PATCH v4 1/4] xen/grants: print grant number and handle in hex format

Due to the large number of grants in use it seems more useful to print the
grant references and handlers in hex format rather than decimal.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v2:
 - Remove the () and the final dot of messages.
 - Fix printing the ref in the 'g' debug key, so that 3 chars are used for the
   ref itself.
---
 xen/common/grant_table.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index d3ea805..f780975 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -814,7 +814,7 @@ __gnttab_map_grant_ref(
 
 /* Bounds check on the grant ref */
 if ( unlikely(op->ref >= nr_grant_entries(rgt)))
-PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
+PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x\n", op->ref);
 
 act = active_entry_acquire(rgt, op->ref);
 shah = shared_entry_header(rgt, op->ref);
@@ -1087,7 +1087,7 @@ __gnttab_unmap_common(
 
 if ( unlikely(op->handle >= lgt->maptrack_limit) )
 {
-gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
+gdprintk(XENLOG_INFO, "Bad handle %#x\n", op->handle);
 op->status = GNTST_bad_handle;
 return;
 }
@@ -1099,7 +1099,7 @@ __gnttab_unmap_common(
 if ( unlikely(!read_atomic(&op->map->flags)) )
 {
 grant_read_unlock(lgt);
-gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
+gdprintk(XENLOG_INFO, "Zero flags for handle %#x\n", op->handle);
 op->status = GNTST_bad_handle;
 return;
 }
@@ -1132,7 +1132,7 @@ __gnttab_unmap_common(
 op->flags = read_atomic(&op->map->flags);
 if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
 {
-gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
+gdprintk(XENLOG_WARNING, "Unstable handle %#x\n", op->handle);
 rc = GNTST_bad_handle;
 goto unmap_out;
 }
@@ -1706,7 +1706,7 @@ gnttab_prepare_for_transfer(
 if ( unlikely(ref >= nr_grant_entries(rgt)) )
 {
 gdprintk(XENLOG_INFO,
-"Bad grant reference (%d) for transfer to domain(%d).\n",
+"Bad grant reference %#x for transfer to d%d\n",
 ref, rd->domain_id);
 goto fail;
 }
@@ -2672,7 +2672,7 @@ 
gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
 break;
 default:
 gdprintk(XENLOG_INFO,
- "bad flags %#x in grant %u when switching version\n",
+ "bad flags %#x in grant %#x when switching version\n",
  flags, i);
 /* fall through */
 case GTF_invalid:
@@ -2836,9 +2836,9 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t 
ref_b)
 
 /* Bounds check on the grant refs */
 if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
-PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-a (%d).\n", ref_a);
+PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-a %#x\n", ref_a);
 if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
-PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
+PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b %#x\n", ref_b);
 
 /* Swapping the same ref is a no-op. */
 if ( ref_a == ref_b )
@@ -2846,11 +2846,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t 
ref_b)
 
 act_a = active_entry_acquire(gt, ref_a);
 if ( act_a->pin )
-PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
+PIN_FAIL(out, GNTST_eagain, "ref a %#x busy\n", ref_a);
 
 act_b = active_entry_acquire(gt, ref_b);
 if ( act_b->pin )
-PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
+PIN_FAIL(out, GNTST_eagain, "ref b %#x busy\n", ref_b);
 
 if ( gt->gt_version == 1 )
 {
@@ -3284,9 +3284,8 @@ gnttab_release_mappings(
 
 ref = map->ref;
 
-gdprintk(XENLOG_INFO, "Grant release (%hu) ref:(%hu) "
-"flags:(%x) dom:(%hu)\n",
-handle, ref, map->flags, map->domid);
+gdprintk(XENLOG_INFO, "Grant release %#x ref %#x flags %#x dom %u\n",
+ handle, ref, map->flags, map->domid);
 
 rd = rcu_lock_domain_by_id(map->domid);
 if ( rd == NULL )
@@ -3530,8 +3529,8 @@ static void gnttab_usage_print(struct domain *rd)
 first = 0;
 }
 
-/*  [ddd]d 0xXX 0x  d 0xXX 0xXX */
-printk("[%3d]%5d 0x%06lx 0x%08x  %5d 0x%06"PRIx64" 0x%02x\n",
+/*  [0xXXX]  d 0xXX 0x  d 0xXX 0xXX */
+printk("[0x%03x]  %5d 0x%06lx 0x%08x

[Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

And fix the following errors reported:

traps.c:2014:25: error: equality comparison with extraneous parentheses
  [-Werror,-Wparentheses-equality]
else if ( (port == RTC_PORT(0)) )
   ~^~
traps.c:2014:25: note: remove extraneous parentheses around the comparison to 
silence this warning
else if ( (port == RTC_PORT(0)) )
  ~ ^ ~
traps.c:2014:25: note: use '=' to turn this equality comparison into an 
assignment
else if ( (port == RTC_PORT(0)) )
^~
=
traps.c:2083:25: error: equality comparison with extraneous parentheses
  [-Werror,-Wparentheses-equality]
else if ( (port == RTC_PORT(0)) )
   ~^~

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk| 3 ---
 xen/arch/x86/traps.c | 4 ++--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Config.mk b/Config.mk
index bff4dc5..9a28d15 100644
--- a/Config.mk
+++ b/Config.mk
@@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
 
 CFLAGS += -Wall -Wstrict-prototypes
 
-# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
-CFLAGS-$(clang) += -Wno-parentheses
-
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 691c9a2..eb634d9 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2011,7 +2011,7 @@ uint32_t guest_io_read(unsigned int port, unsigned int 
bytes,
 {
 sub_data = pv_pit_handler(port, 0, 0);
 }
-else if ( (port == RTC_PORT(0)) )
+else if ( port == RTC_PORT(0) )
 {
 sub_data = currd->arch.cmos_idx;
 }
@@ -2080,7 +2080,7 @@ void guest_io_write(unsigned int port, unsigned int 
bytes, uint32_t data,
 {
 pv_pit_handler(port, (uint8_t)data, 1);
 }
-else if ( (port == RTC_PORT(0)) )
+else if ( port == RTC_PORT(0) )
 {
 currd->arch.cmos_idx = data;
 }
-- 
2.10.1 (Apple Git-78)


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

[Xen-devel] [PATCH v4 0/4] clang: don't disable any warnings

Hello,

The following series removes the disable of certain clang warnings, after this
all clang warnings are enabled. This supersedes "[PATCH v3 0/2] Enable Wformat
for clang".

It has been tested in FreeBSD with clang 3.8, and by travis, all OK:

https://travis-ci.org/royger/xen/builds/201482055

Thanks, Roger.


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

[Xen-devel] [PATCH v4 2/4] build/printf: fix incorrect format specifiers

The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:

mce.c:601:18: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
 smp_processor_id());
 ^

xenpm.c:102:23: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
what, argv[argc > 1]);
  ^

libxl_internal.c:25:69: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^
libxl_internal.c:26:21: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
fprintf(stderr, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^

This patch contains the fixes for them and enables -Wformat for clang.

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
---
NB: FWIW, there's a way to disable extra arguments checks
(-Wno-format-extra-args), that would prevent us from having to apply some of
the changes here. However, given that there are not that many occurrences, I
would rather leave the full checks of Wformat enabled.

NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only
against the components that build on FreeBSD (ie: no qemu-trad, and certainly
no blktap).
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Christoph Egger 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v2:
 - Remove the printf related comment near the -Wno-format.

Changes since v1:
 - Change the format string for MCE to avoid duplicating CPU%i.
 - Remove the grant-ref format specifier change, it's already taken care in
   patch #1.
---
 Config.mk |  3 +--
 tools/libxl/libxl_internal.c  | 21 -
 tools/misc/xenpm.c| 13 -
 xen/arch/x86/cpu/mcheck/mce.c |  5 ++---
 4 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/Config.mk b/Config.mk
index 3a1d960..7d08d16 100644
--- a/Config.mk
+++ b/Config.mk
@@ -213,9 +213,8 @@ CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
-# and is over-zealous with the printf format lint
 # and is a bit too fierce about unused return values
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
+CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d288215..f492dae 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -20,14 +20,25 @@
 void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
  size_t nmemb, size_t size) {
 #define M "libxl: FATAL ERROR: memory allocation failure"
-#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
-  func, (unsigned long)nmemb, (unsigned long)size
-libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
-fprintf(stderr, L);
+#define M_SIZE M " (%s, %lu x %lu)\n"
+#define M_NSIZE M " (%s)\n"
+if (size) {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_SIZE, func, (unsigned long)nmemb, (unsigned long)size);
+   fprintf(stderr, M_SIZE, func, (unsigned long)nmemb,
+   (unsigned long)size);
+} else {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_NSIZE, func);
+   fprintf(stderr, M_NSIZE, func);
+
+}
+
 fflush(stderr);
 _exit(-1);
+#undef M_NSIZE
+#undef M_SIZE
 #undef M
-#undef L
 }
 
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index a2edee5..ded40b9 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -93,13 +93,16 @@ static void parse_cpuid(const char *arg, int *cpuid)
 static void parse_cpuid_and_int(int argc, char *argv[],
 int *cpuid, int *val, const char *what)
 {
-if ( argc > 1 )
-parse_cpuid(argv[0], cpuid);
+if ( argc == 0 )
+{
+ fprintf(stderr, "Missing %s\n", what);
+ exit(EINVAL);
+}
 
-if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
+parse_cpuid(argv[0], cpuid);
+if ( sscanf(argv[1], "%d", val) != 1 )
 {
-fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
-what, argv[argc > 1]);
+fprintf(stderr, "Invalid %s '%s'\n", what, argv[1]);
 exit(EINVAL);
 }
 }
diff --git a/xen/arch/x86/cpu

[Xen-devel] [PATCH v4 3/4] build: enable unused value checks for clang

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Config.mk b/Config.mk
index 7d08d16..bff4dc5 100644
--- a/Config.mk
+++ b/Config.mk
@@ -213,8 +213,7 @@ CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
-# and is a bit too fierce about unused return values
-CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
+CFLAGS-$(clang) += -Wno-parentheses
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
-- 
2.10.1 (Apple Git-78)


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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 105756
 build-amd64-xsm   5 xen-build  fail in 105777 REGR. vs. 105756
 build-armhf-libvirt  4 host-build-prep fail in 105777 REGR. vs. 105756

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qcow23 host-install(3) broken in 105777 pass in 105784
 test-armhf-armhf-xl-arndale   4 host-ping-check-native fail pass in 105777

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 105728
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105756
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105756
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105756
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105756
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105756
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105756
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105756
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 105756

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 105777 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 105777 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 105777 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 105777 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 105777 n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 105777 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 105777 never 
pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   ne

Re: [Xen-devel] [PATCH v3 0/2] Enable Wformat for clang

On Tue, Feb 14, 2017 at 08:46:56AM +, Roger Pau Monne wrote:
> Hello,
> 
> These patches fix the remaining issues so that Wformat can be enabled for
> clang.

This has now been superseded by "[PATCH v4 0/4] clang: don't disable any
warnings". Please ignore this series.

Roger.

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

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

2017-02-14 Thread Roger Pau Monné

On Tue, Feb 14, 2017 at 12:31:00PM +, osstest service owner wrote:
> flight 105784 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105784/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
> REGR. vs. 105756

Seems like an issue with the debian mirror:

http://logs.test-lab.xenproject.org/osstest/logs/105784/test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm/elbling1---var-log-xen-osstest-serial-debianhvm.guest.osstest.log

>  build-amd64-xsm   5 xen-build  fail in 105777 REGR. vs. 
> 105756
>  build-armhf-libvirt  4 host-build-prep fail in 105777 REGR. vs. 
> 105756

And I cannot see those last two as failing in the html report...

Roger.

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

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

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  62c7b99a10793738db1007f6750cf79057625f2c
baseline version:
 xen  28722e98f7ff1ef0da1bef885f98e232f89a8ca7

Last test of basis   105771  2017-02-13 15:01:46 Z0 days
Testing same since   105788  2017-02-14 11:01:40 Z0 days1 attempts


People who touched revisions under test:
  Kevin Tian 
  Sergey Dyasli 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=62c7b99a10793738db1007f6750cf79057625f2c
+ . ./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 
62c7b99a10793738db1007f6750cf79057625f2c
+ branch=xen-unstable-smoke
+ revision=62c7b99a10793738db1007f6750cf79057625f2c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x62c7b99a10793738db1007f6750cf79057625f2c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://g

Re: [Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

On 14/02/17 12:30, Roger Pau Monne wrote:
> And fix the following errors reported:
>
> traps.c:2014:25: error: equality comparison with extraneous parentheses
>   [-Werror,-Wparentheses-equality]
> else if ( (port == RTC_PORT(0)) )
>~^~
> traps.c:2014:25: note: remove extraneous parentheses around the comparison to 
> silence this warning
> else if ( (port == RTC_PORT(0)) )
>   ~ ^ ~
> traps.c:2014:25: note: use '=' to turn this equality comparison into an 
> assignment
> else if ( (port == RTC_PORT(0)) )
> ^~
> =
> traps.c:2083:25: error: equality comparison with extraneous parentheses
>   [-Werror,-Wparentheses-equality]
> else if ( (port == RTC_PORT(0)) )
>~^~
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

>>> On 14.02.17 at 13:30,  wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
>  
>  CFLAGS += -Wall -Wstrict-prototypes
>  
> -# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> -CFLAGS-$(clang) += -Wno-parentheses

Taking the comment being removed here together with 

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2011,7 +2011,7 @@ uint32_t guest_io_read(unsigned int port, unsigned int 
> bytes,
>  {
>  sub_data = pv_pit_handler(port, 0, 0);
>  }
> -else if ( (port == RTC_PORT(0)) )
> +else if ( port == RTC_PORT(0) )
>  {
>  sub_data = currd->arch.cmos_idx;
>  }
> @@ -2080,7 +2080,7 @@ void guest_io_write(unsigned int port, unsigned int 
> bytes, uint32_t data,
>  {
>  pv_pit_handler(port, (uint8_t)data, 1);
>  }
> -else if ( (port == RTC_PORT(0)) )
> +else if ( port == RTC_PORT(0) )
>  {
>  currd->arch.cmos_idx = data;
>  }

... the code adjustments all being to other than macros I wonder
whether in the version you use the issue is no longer being
reported in macro expansions, but older clang still chokes on such.
Or did you go check that we have no such uses left (which seems
unlikely to me)?

Jan


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

Re: [Xen-devel] [PATCH v4 3/4] build: enable unused value checks for clang

>>> On 14.02.17 at 13:30,  wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -213,8 +213,7 @@ CFLAGS += -std=gnu99
>  CFLAGS += -Wall -Wstrict-prototypes
>  
>  # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> -# and is a bit too fierce about unused return values
> -CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
> +CFLAGS-$(clang) += -Wno-parentheses

Same question here - does removing the warning suppression work
with all clang versions, or just new enough ones?

Jan


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

Re: [Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

On Tue, Feb 14, 2017 at 06:56:12AM -0700, Jan Beulich wrote:
> >>> On 14.02.17 at 13:30,  wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
> >  
> >  CFLAGS += -Wall -Wstrict-prototypes
> >  
> > -# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> > -CFLAGS-$(clang) += -Wno-parentheses
> 
> Taking the comment being removed here together with 
> 
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -2011,7 +2011,7 @@ uint32_t guest_io_read(unsigned int port, unsigned 
> > int bytes,
> >  {
> >  sub_data = pv_pit_handler(port, 0, 0);
> >  }
> > -else if ( (port == RTC_PORT(0)) )
> > +else if ( port == RTC_PORT(0) )
> >  {
> >  sub_data = currd->arch.cmos_idx;
> >  }
> > @@ -2080,7 +2080,7 @@ void guest_io_write(unsigned int port, unsigned int 
> > bytes, uint32_t data,
> >  {
> >  pv_pit_handler(port, (uint8_t)data, 1);
> >  }
> > -else if ( (port == RTC_PORT(0)) )
> > +else if ( port == RTC_PORT(0) )
> >  {
> >  currd->arch.cmos_idx = data;
> >  }
> 
> ... the code adjustments all being to other than macros I wonder
> whether in the version you use the issue is no longer being
> reported in macro expansions, but older clang still chokes on such.
> Or did you go check that we have no such uses left (which seems
> unlikely to me)?

I assume that in recent versions of clang this is no longer an issue. Travis
tests with clang 3.5 and I test with 3.8, and none of them find any issues.
IMHO we should turn it on because I barely doubt anyone is building Xen with
older versions of clang, when I started working on this the clang support was
completely bitrotted.

Roger.

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

Re: [Xen-devel] [PATCH v4 3/4] build: enable unused value checks for clang

On Tue, Feb 14, 2017 at 07:00:18AM -0700, Jan Beulich wrote:
> >>> On 14.02.17 at 13:30,  wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -213,8 +213,7 @@ CFLAGS += -std=gnu99
> >  CFLAGS += -Wall -Wstrict-prototypes
> >  
> >  # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> > -# and is a bit too fierce about unused return values
> > -CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
> > +CFLAGS-$(clang) += -Wno-parentheses
> 
> Same question here - does removing the warning suppression work
> with all clang versions, or just new enough ones?

Works with 3.5 and 3.8 at least. As I said in the other reply, given the
previous state of Xen with clang I barely doubt anyone was actually compiling
Xen with clang until I setup the FreeBSD ports and Doug the Travis stuff.

Roger.

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

Re: [Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

On 14/02/17 14:06, Roger Pau Monne wrote:
> On Tue, Feb 14, 2017 at 06:56:12AM -0700, Jan Beulich wrote:
> On 14.02.17 at 13:30,  wrote:
>>> --- a/Config.mk
>>> +++ b/Config.mk
>>> @@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
>>>  
>>>  CFLAGS += -Wall -Wstrict-prototypes
>>>  
>>> -# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
>>> -CFLAGS-$(clang) += -Wno-parentheses
>> Taking the comment being removed here together with 
>>
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -2011,7 +2011,7 @@ uint32_t guest_io_read(unsigned int port, unsigned 
>>> int bytes,
>>>  {
>>>  sub_data = pv_pit_handler(port, 0, 0);
>>>  }
>>> -else if ( (port == RTC_PORT(0)) )
>>> +else if ( port == RTC_PORT(0) )
>>>  {
>>>  sub_data = currd->arch.cmos_idx;
>>>  }
>>> @@ -2080,7 +2080,7 @@ void guest_io_write(unsigned int port, unsigned int 
>>> bytes, uint32_t data,
>>>  {
>>>  pv_pit_handler(port, (uint8_t)data, 1);
>>>  }
>>> -else if ( (port == RTC_PORT(0)) )
>>> +else if ( port == RTC_PORT(0) )
>>>  {
>>>  currd->arch.cmos_idx = data;
>>>  }
>> ... the code adjustments all being to other than macros I wonder
>> whether in the version you use the issue is no longer being
>> reported in macro expansions, but older clang still chokes on such.
>> Or did you go check that we have no such uses left (which seems
>> unlikely to me)?
> I assume that in recent versions of clang this is no longer an issue. Travis
> tests with clang 3.5 and I test with 3.8, and none of them find any issues.
> IMHO we should turn it on because I barely doubt anyone is building Xen with
> older versions of clang, when I started working on this the clang support was
> completely bitrotted.

There was some Clang 3.2 support in the past, but it had completely
bitrotten.

Clang 3.5 is our documented minimum, so I think it is reasonable to take
these clobbers out, seeing as they are not needed.

~Andrew

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

Re: [Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

>>> On 14.02.17 at 15:13,  wrote:
> On 14/02/17 14:06, Roger Pau Monne wrote:
>> On Tue, Feb 14, 2017 at 06:56:12AM -0700, Jan Beulich wrote:
>> On 14.02.17 at 13:30,  wrote:
 --- a/Config.mk
 +++ b/Config.mk
 @@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
  
  CFLAGS += -Wall -Wstrict-prototypes
  
 -# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 -CFLAGS-$(clang) += -Wno-parentheses
>>> Taking the comment being removed here together with 
>>>
 --- a/xen/arch/x86/traps.c
 +++ b/xen/arch/x86/traps.c
 @@ -2011,7 +2011,7 @@ uint32_t guest_io_read(unsigned int port, unsigned 
 int bytes,
  {
  sub_data = pv_pit_handler(port, 0, 0);
  }
 -else if ( (port == RTC_PORT(0)) )
 +else if ( port == RTC_PORT(0) )
  {
  sub_data = currd->arch.cmos_idx;
  }
 @@ -2080,7 +2080,7 @@ void guest_io_write(unsigned int port, unsigned int 
 bytes, uint32_t data,
  {
  pv_pit_handler(port, (uint8_t)data, 1);
  }
 -else if ( (port == RTC_PORT(0)) )
 +else if ( port == RTC_PORT(0) )
  {
  currd->arch.cmos_idx = data;
  }
>>> ... the code adjustments all being to other than macros I wonder
>>> whether in the version you use the issue is no longer being
>>> reported in macro expansions, but older clang still chokes on such.
>>> Or did you go check that we have no such uses left (which seems
>>> unlikely to me)?
>> I assume that in recent versions of clang this is no longer an issue. Travis
>> tests with clang 3.5 and I test with 3.8, and none of them find any issues.
>> IMHO we should turn it on because I barely doubt anyone is building Xen with
>> older versions of clang, when I started working on this the clang support was
>> completely bitrotted.
> 
> There was some Clang 3.2 support in the past, but it had completely
> bitrotten.
> 
> Clang 3.5 is our documented minimum, so I think it is reasonable to take
> these clobbers out, seeing as they are not needed.

Okay, if the minimum version was tested, then I'm fine with the
adjustment.

Jan


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

Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

2017-02-14 Thread Boris Ostrovsky




On 02/14/2017 04:20 AM, Paul Durrant wrote:

My previous reply got bounced because my tablet insisted on using HTML...


-Original Message-

These need to be static. (I can fix it when committing.)


Ok, thanks.



And I am still not sure about using XEN_PAGE_SIZE. There is no
dependency in the hypervisor on buffers being page-sized, is there? If
not, XEN_PAGE_SIZE is here just because it happens to be 4K, which is a
reasonable value.

How about just setting it to 4096?



I chose XEN_PAGE_SIZE because the hypercall will eventually copy in the buffer 
so it seemed like a reasonable value to use. If you want to just use 4096 then 
I am ok with that.

  Paul

PS: If you want to change from XEN_PAGE_SIZE to 4096 then I assume you are 
happy to do this at commit and don't need me to send a v4?


Right.

But I also had a question about patch 3 (commit message). I can make the 
change when committing as well but I need to make sure you are OK with it.


-boris

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

Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt


(Resending the e-mail due to SMTP issue)

On 02/14/2017 02:18 PM, Julien Grall wrote:

Hi,

Ping? As Ian mentioned earlier, without this series it is not possible
to build Xen tools for ARM64 in osstest.

Cheers,

On 02/08/2017 07:50 PM, Julien Grall wrote:

Hi,

On 24/01/17 22:19, David Scott wrote:



On 24 Jan 2017, at 11:35, Ian Jackson 
wrote:

Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness
when no ocamlopt"):

Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
package lacks ocamlopt.

...

This does not actually fix the real problem.  I'm unsure how to fix it
properly, for the following reasons:


Can I have some input from ocaml folks ?

The first ARM64 boxes in the Xen Project test lab are in principle now
online, but this bug is stopping osstest actually getting as far as
trying to boot Xen.


ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
`ocamlc'.  However our ocaml Makefiles seem to explicitly call
$(OCAMLOPT) in some places and and $(OCAMLC) in others.


I’m terrible at reading m4 and am really bad with autoconf so I may have
got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`?
Where

`ocamlc`: outputs bytecode, and is a bytecode executable itself
`ocamlc.opt`: outputs bytecode, and is a native code executable itself
`ocamlopt`: outputs native code, and is a bytecode executable itself
`ocamlopt.opt`: outputs native code, and is a native code executable
itself

Both `ocamlc` and `ocamlc.opt` should be interchangeable: same
command-line
arguments, exactly the same output. Same for `ocamlopt` and
`ocamlopt.opt`.

I _think_ the m4 is looking for `ocamlc.opt` because it’s an
optimised native
(therefore faster) version of `ocamlc`. It should be fine to set
`OCAMLC`
to either.

The tools/ocaml/Makefile.rules does contain rules for both bytecode
outputs
(e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe
*.cmi
can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).

I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it
refers
directly to *.cmxa files which are native-code only— I don’t see how
that
could work for bytecode outputs.

Do you have a link to the build failure?


Here a link for the build failure:

http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log


Cheers,





--
Julien Grall

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

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()


(Resending the e-mail due to SMTP issue)

On 02/14/2017 12:12 PM, Julien Grall wrote:

Hi Jan,

On 02/14/2017 10:51 AM, Jan Beulich wrote:

On 07.02.17 at 00:32,  wrote:

Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv
issue") has
added a assertion that intack.vector is the highest priority vector. But
according to the osstest, the assertion failed sometimes. More
discussion can
be found in the thread
(https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.html).


The assertion failure is hard to reproduce. In order to root cause
issue, this
patch is to add logs to dump PIR and vIRR when failure takes place.
It should
be reverted once the root cause is found.


Julien, could you add a note on the 4.9 tracking list for us to not
forget to revert this (or at least add NDEBUG conditionals) the
latest in the RC phase?


I have added a note in the 4.9 tracking list.

Cheers,



--
Julien Grall

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

Re: [Xen-devel] HostedXen: Build Instructions

On Tue, Feb 14, 2017 at 11:08:11AM +0530, rohan kumbhar wrote:
> Hi,
> 
> I am interested to restart Hosted Xen Project.
> 
> I have gone through the presentation of Hosted Xen and Ian Pratt's video in
> Xen Summit 9.
> I have secured the source code for HostedXen from
> https://downloads.xen.org/HostedXen/release/
> 
> Tried to build it on windows but its failing.
> It would be of utmost help if detailed build instructions be available.

Sorry :-(

I think you are on your own. You could see labs.bromium.com ?

> 
> I have searched the archives with no success.
> 
> Please help.

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


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

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

2017-02-14 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 68506

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68506
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68506
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 68506
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68506
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68506

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

version targeted for testing:
 qemuu305e6c8a2ff7a6e3f4942b50e853230f18eeb5a9
baseline version:
 qemuu6fe791b5e3aca8a6de8a322e85e76d2f13338a7e

Last test of basis68506  2017-02-02 16:46:49 Z   11 days
Testing same since68557  2017-02-14 09:14:19 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex BennÃ©e 
  Alex Williamson 
  Alexander Graf 
  Alexander Indenbaum 
  Andrea Bolognani 
  Anthony PERARD 
  Avinesh Kumar 
  Bharata B Rao 
  Cao jin 
  Christian Borntraeger 
  CÃ©dric Le Goater 
  Daniel P

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

2017-02-14 Thread Waiman Long

On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
>> It is the address of &steal_time that will exceed the 32-bit limit.
> That seems extremely unlikely. That would mean we have more than 4G
> worth of per-cpu variables declared in the kernel.

I have some doubt about if the compiler is able to properly use
RIP-relative addressing for this. Anyway, it seems like constraints
aren't allowed for asm() when not in the function context, at least for
the the compiler that I am using (4.8.5). So it is a moot point.

Cheers,
Longman

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

Re: [Xen-devel] qemu-upstream triggering OOM killer

2017-02-14 Thread Anthony PERARD

On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote:
> >>> On 09.02.17 at 23:24,  wrote:
> > On Thu, 9 Feb 2017, Jan Beulich wrote:
> >> the recent qemuu update results in the produced binary triggering the
> >> OOM killer on the first system I tried the updated code on. Is there
> >> anything known in this area? Are there any hints as to finding out
> >> what is going wrong?
> > 
> > Do you mean QEMU upstream (from qemu.org) or qemu-xen/staging (that
> > hasn't changed much in the last couple of months)?
> 
> The latter. The diff to my last snapshot (from early January) is 6.6Mb
> though - I wouldn't call this "hasn't changed much". Looks like Anthony
> did update to 2.8.0 in early January (a day or two after I had last
> snapshotted it).

Yes, I did the update.

> > Do you know if it's something Xen specific?
> 
> Not so far. It appears to happen when grub clears the screen
> before displaying its graphical menu, so I'd rather suspect an issue
> with a graphics related change (the one you pointed out isn't).

I tried to reproduce this, by limiting the amount of memory available to
qemu using cgroups, but about 44MB of memory is enough to boot a guest
(tried Ubuntu and Debian).

How much memory did qemu try to use?
What guest did you try to boot?
What the xl configuration?

-- 
Anthony PERARD

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

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

Hi,

On 01/26/2017 09:11 PM, Julien Grall wrote:

Hi,

On 26/01/2017 19:01, Boris Ostrovsky wrote:

On 01/26/2017 12:18 PM, Ian Jackson wrote:

Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684:
regressions - FAIL"):

On 01/26/2017 08:23 AM, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs.
59254

...

I don't see why ARM tests fail. But then I also don't see (in the
serial
log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
but there it nothing coming to the console from it.

Yes.

Unfortunately the osstest bisector is having some trouble with this
because the basis revision combination includes Xen f3a7ca02400d which
is ancient and doesn't build now on armhf, although it built before.
(I think the difference is that the compiler has been updated by
Debian.)

Since there is no output from Xen, I think this must be a problem with
the Xen image, not anything to do with Linux.

The history for this test is here:

http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus

In xen-unstable, there is what looks like a different failure:

http://logs.test-lab.xenproject.org/osstest/logs/104681/test-armhf-armhf-xl/serial-arndale-westfield.log

The machine in 104684 is cubietruck-metzinger which seems fine:

http://logs.test-lab.xenproject.org/osstest/results/host/cubietruck-metzinger.html

I am probably not interpreting results correctly but 104684 looks like
failed to me:

http://logs.test-lab.xenproject.org/osstest/logs/104684/test-armhf-armhf-xl/info.html

And 104681's failure looks exactly like 104684.

I agree here. I think Ian got confused because the cubietruck is used to
build Xen.

Here are the histories on the linux-linus and xen-unstable branches:

http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus

http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable

I think there may be a host-specific bug in ARM in xen-unstable ?

So the problem with linux-linus is the path in the DeviceTree for the
serial has been changed by commit 5d99cc5 "ARM: dts: exynos: Move
Exynos5250 and Exynos5420 nodes under soc". Before the path was
/serial@12C2, now it is /soc/serial@12C2.

From my understanding, osstest is testing 3.18 and onwards. Correct?

If so, all the device tree we care have the same alias name to the
serial node. I would use it to get avoid specific command line option
depending on the kernel.

Replacing on xen command line "dtuart=/serial@12C2" by
"dtuart=serial0" will allow Xen to be able to use again the console.

I have looked at osstest git [1] and was not able to find where the
configuration for the Arndale.

Can someone knowing Osstest look at it? This would unblock linux-linus
test on ARM.

Regarding xen-unstable, I spot in the log a lot of "asix 2-3.2.4:1.0
eth0: link down". So this looks like an ethernet issue. IIRC the network
dongle on the Arndale has always been unreliable. So I would not worry
too much here and wait the next flight.

Cheers,

[1] http://xenbits.xen.org/gitweb/?p=osstest.git;a=summary

--
Julien Grall

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

Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.

On Mon, Feb 13, 2017 at 08:46:29AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 10 February 2017 21:52
> > To: Paul Durrant ; xen-de...@lists.xenproject.org
> > Cc: Konrad Rzeszutek Wilk 
> > Subject: [PATCH] Make it compiler under Xen 4.7.
> > 
> > With b7f76a699dcfadc0a52ab45b33cc72dbf3a69e7b
> > Author: Ian Campbell 
> > Date:   Mon Jun 1 16:20:09 2015 +0100
> > 
> > tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
> > 
> > commit 32486916793fd78a41fc25e53d2b53a5aa0b1bd5
> > Author: Ian Campbell 
> > Date:   Thu Jun 18 16:30:19 2015 +0100
> > 
> > tools: Refactor foreign memory mapping into libxenforeignmemory
> > 
> > We need to use the compat layer.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> 
> Thanks for taking the time to send this. I'll incorporate this a.s.a.p.

Thank you. Keep in mind that it will likely break against
older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h

[Oh wait, Xen 4.4 didn't have ioreq either, so perhaps Xen 4.5?]

But I wasn't sure how you wanted to deal with this being compiled
against say Xen 4.6?

Or maybe the README file should just say what version of Xen
is required? (I can send an patch for that too if you would like).

> 
> Acked-by: Paul Durrant 
> 
> > 
> > ---
> > CC: paul.durr...@citrix.com
> > 
> > v1: First version
> > ---
> >  demu.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/demu.c b/demu.c
> > index 2933efb..7d73a69 100644
> > --- a/demu.c
> > +++ b/demu.c
> > @@ -56,7 +56,12 @@
> > 
> >  #include 
> > 
> > +#define XC_WANT_COMPAT_MAP_FOREIGN_API 1
> > +#define XC_WANT_COMPAT_EVTCHN_API 1
> > +
> >  #include 
> > +#include 
> > +
> >  #include 
> > 
> >  #include "debug.h"
> > @@ -126,7 +131,7 @@ typedef enum {
> >  typedef struct demu_state {
> >  demu_seq_t  seq;
> >  xc_interface*xch;
> > -xc_interface*xceh;
> > +xc_evtchn  *xceh;
> >  domid_t domid;
> >  unsigned intvcpus;
> >  ioservid_t  ioservid;
> > --
> > 2.9.3
> 

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 10 February 2017 21:52
> > To: Paul Durrant ; xen-de...@lists.xenproject.org
> > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > 
> > Hey!
> > 
> > This patch lets me compile this emulator under Xen 4.7.
> > 
> > It probably can be done better (#ifdef magic?) but for right
> > now this gets me past the compile errors.
> > 
> > BTW, are there any other outstanding patches against this tree?
> > 
> 
> This is still my private project, although if it's generally useful then 
> maybe it can be adopted as part of the Xen project?

It is a nice project!

By 'adopted' you mean being built as part of xen.git (like minios.git?) - and
all of those requirements?

> 
> For the benefit of the list, there are two branches in 
> http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> 
> - The 'master' branch is a very basic standalone device emulator. It serves 
> as boilerplate for emulation of a single PCI device.
> 
> - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using 
> libVNCServer which can potentially be used with an HVM guest with PV network 
> and storage drivers, thus removing the need to use QEMU. demu is a small and 
> constrained piece of code and thus presents a much smaller attack surface. 
> The original intention was also to run it in a 'console service domain' to 
> further contain damage it was successfully attacked.
> 
> It's likely that I will patch the code further once my current work on 
> libxendevicemodel is done (following acceptance of my recent privcmd patches).


> 
>   Cheers,
> 
> Paul
> 
> > 
> >  demu.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > Konrad Rzeszutek Wilk (1):
> >   Make it compiler under Xen 4.7.
> 

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

Re: [Xen-devel] [PATCH 1/2] VMX: fix VMCS race on context-switch paths

On 14/02/17 10:28, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -552,6 +552,27 @@ static void vmx_load_vmcs(struct vcpu *v
>  local_irq_restore(flags);
>  }
>  
> +void vmx_vmcs_reload(struct vcpu *v)
> +{
> +/*
> + * As we're running with interrupts disabled, we can't acquire
> + * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
> + * the VMCS can't be taken away from us anymore if we still own it.
> + */
> +ASSERT(!local_irq_is_enabled());
> +if ( v->arch.hvm_vmx.vmcs_pa == this_cpu(current_vmcs) )
> +return;
> +ASSERT(!this_cpu(current_vmcs));
> +
> +/*
> + * Wait for the remote side to be done with the VMCS before loading
> + * it here.
> + */
> +while ( v->arch.hvm_vmx.active_cpu != -1 )
> +cpu_relax();

Doesn't this need a ACCESS_ONCE() read?

While the compiled code (using GCC 4.9) isn't an infinite loop, I am not
aware of anything which prevents a compiler hoisting the comparison out
as being constant.

Otherwise, everything else LGTM.

~Andrew

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

Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Konrad Rzeszutek Wilk
> Sent: 14 February 2017 15:15
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.
> 
> On Mon, Feb 13, 2017 at 08:46:29AM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: 10 February 2017 21:52
> > > To: Paul Durrant ; xen-
> de...@lists.xenproject.org
> > > Cc: Konrad Rzeszutek Wilk 
> > > Subject: [PATCH] Make it compiler under Xen 4.7.
> > >
> > > With b7f76a699dcfadc0a52ab45b33cc72dbf3a69e7b
> > > Author: Ian Campbell 
> > > Date:   Mon Jun 1 16:20:09 2015 +0100
> > >
> > > tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
> > >
> > > commit 32486916793fd78a41fc25e53d2b53a5aa0b1bd5
> > > Author: Ian Campbell 
> > > Date:   Thu Jun 18 16:30:19 2015 +0100
> > >
> > > tools: Refactor foreign memory mapping into libxenforeignmemory
> > >
> > > We need to use the compat layer.
> > >
> > > Signed-off-by: Konrad Rzeszutek Wilk 
> >
> > Thanks for taking the time to send this. I'll incorporate this a.s.a.p.
> 
> Thank you. Keep in mind that it will likely break against
> older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h

I'm not sure you actually need to include that directly. I was going to try 
just adding the 'want compat' defines and seeing if I could make it work. I 
think it *should* work since all we do for upstream QEMU is add those defines 
into the configure cmd line IIRC.

> 
> [Oh wait, Xen 4.4 didn't have ioreq either, so perhaps Xen 4.5?]
> 
> But I wasn't sure how you wanted to deal with this being compiled
> against say Xen 4.6?
> 
> Or maybe the README file should just say what version of Xen
> is required? (I can send an patch for that too if you would like).
> 

That's ok. I can do a little experimentation and add a README.

  Paul

> >
> > Acked-by: Paul Durrant 
> >
> > >
> > > ---
> > > CC: paul.durr...@citrix.com
> > >
> > > v1: First version
> > > ---
> > >  demu.c | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/demu.c b/demu.c
> > > index 2933efb..7d73a69 100644
> > > --- a/demu.c
> > > +++ b/demu.c
> > > @@ -56,7 +56,12 @@
> > >
> > >  #include 
> > >
> > > +#define XC_WANT_COMPAT_MAP_FOREIGN_API 1
> > > +#define XC_WANT_COMPAT_EVTCHN_API 1
> > > +
> > >  #include 
> > > +#include 
> > > +
> > >  #include 
> > >
> > >  #include "debug.h"
> > > @@ -126,7 +131,7 @@ typedef enum {
> > >  typedef struct demu_state {
> > >  demu_seq_t  seq;
> > >  xc_interface*xch;
> > > -xc_interface*xceh;
> > > +xc_evtchn  *xceh;
> > >  domid_t domid;
> > >  unsigned intvcpus;
> > >  ioservid_t  ioservid;
> > > --
> > > 2.9.3
> >
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers

On 14/02/17 10:29, Jan Beulich wrote:
> They're all solely dependent on guest type, so we don't need to repeat
> all the same four pointers in every vCPU control structure. Instead use
> static const structures, and store pointers to them in the domain
> control structure.
>
> Since touching it anyway, take the opportunity and move schedule_tail()
> into the only C file needing it.
>
> Signed-off-by: Jan Beulich 

+1.  This has been a niggle on my todo list for ages.

> @@ -2066,6 +2073,15 @@ static void __context_switch(void)
>  per_cpu(curr_vcpu, cpu) = n;
>  }
>  
> +/*
> + * Schedule tail *should* be a terminal function pointer, but leave a 
> bugframe
> + * around just incase it returns, to save going back into the context
> + * switching code and leaving a far more subtle crash to diagnose.
> + */
> +#define schedule_tail(vcpu) do {  \
> +(((vcpu)->domain->arch.ctxt_switch->tail)(vcpu)); \
> +BUG();\
> +} while (0)

schedule_tail() is used only twice.  I'd suggest dropping it entirely
and calling the ->tail() function pointer normally, rather than hiding
it this.

Upon reviewing, this patch, don't we also need a ->same() call in the
continue_same() path in the previous patch?

~Andrew

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 14 February 2017 15:16
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> 
> On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: 10 February 2017 21:52
> > > To: Paul Durrant ; xen-
> de...@lists.xenproject.org
> > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > >
> > > Hey!
> > >
> > > This patch lets me compile this emulator under Xen 4.7.
> > >
> > > It probably can be done better (#ifdef magic?) but for right
> > > now this gets me past the compile errors.
> > >
> > > BTW, are there any other outstanding patches against this tree?
> > >
> >
> > This is still my private project, although if it's generally useful then 
> > maybe it
> can be adopted as part of the Xen project?
> 
> It is a nice project!
> 

Glad you find it useful :-)

> By 'adopted' you mean being built as part of xen.git (like minios.git?) - and
> all of those requirements?
> 

Something like that, then it can be incorporated as an option into the xen 
build and we can make sure any dependency issues like this are caught in future.

I guess I'd probably make the 'console' branch master in a more official 
repo... I could even look at adding the necessary tooling into libxl to kick it 
off too :-)

  Paul

> >
> > For the benefit of the list, there are two branches in
> http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> >
> > - The 'master' branch is a very basic standalone device emulator. It serves
> as boilerplate for emulation of a single PCI device.
> >
> > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using
> libVNCServer which can potentially be used with an HVM guest with PV
> network and storage drivers, thus removing the need to use QEMU. demu is
> a small and constrained piece of code and thus presents a much smaller
> attack surface. The original intention was also to run it in a 'console 
> service
> domain' to further contain damage it was successfully attacked.
> >
> > It's likely that I will patch the code further once my current work on
> libxendevicemodel is done (following acceptance of my recent privcmd
> patches).
> 
> 
> >
> >   Cheers,
> >
> > Paul
> >
> > >
> > >  demu.c | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > Konrad Rzeszutek Wilk (1):
> > >   Make it compiler under Xen 4.7.
> >

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:16
> > To: Paul Durrant 
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > 
> > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > Sent: 10 February 2017 21:52
> > > > To: Paul Durrant ; xen-
> > de...@lists.xenproject.org
> > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > > >
> > > > Hey!
> > > >
> > > > This patch lets me compile this emulator under Xen 4.7.
> > > >
> > > > It probably can be done better (#ifdef magic?) but for right
> > > > now this gets me past the compile errors.
> > > >
> > > > BTW, are there any other outstanding patches against this tree?
> > > >
> > >
> > > This is still my private project, although if it's generally useful then 
> > > maybe it
> > can be adopted as part of the Xen project?
> > 
> > It is a nice project!
> > 
> 
> Glad you find it useful :-)
> 
> > By 'adopted' you mean being built as part of xen.git (like minios.git?) - 
> > and
> > all of those requirements?
> > 
> 
> Something like that, then it can be incorporated as an option into the xen 
> build and we can make sure any dependency issues like this are caught in 
> future.
> 
> I guess I'd probably make the 'console' branch master in a more official 
> repo... I could even look at adding the necessary tooling into libxl to kick 
> it off too :-)

Oooh, and what kind of bribe^H^H^H^H incentive should I send your way?

> 
>   Paul
> 
> > >
> > > For the benefit of the list, there are two branches in
> > http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> > >
> > > - The 'master' branch is a very basic standalone device emulator. It 
> > > serves
> > as boilerplate for emulation of a single PCI device.
> > >
> > > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using
> > libVNCServer which can potentially be used with an HVM guest with PV
> > network and storage drivers, thus removing the need to use QEMU. demu is
> > a small and constrained piece of code and thus presents a much smaller
> > attack surface. The original intention was also to run it in a 'console 
> > service
> > domain' to further contain damage it was successfully attacked.
> > >
> > > It's likely that I will patch the code further once my current work on
> > libxendevicemodel is done (following acceptance of my recent privcmd
> > patches).
> > 
> > 
> > >
> > >   Cheers,
> > >
> > > Paul
> > >
> > > >
> > > >  demu.c | 7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > Konrad Rzeszutek Wilk (1):
> > > >   Make it compiler under Xen 4.7.
> > >

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

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

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuuec7a9bd5bb2c46c60cc0ec9b9d9f2ce404226ec0
baseline version:
 qemuu305e6c8a2ff7a6e3f4942b50e853230f18eeb5a9

Last test of basis   105781  2017-02-14 01:16:33 Z0 days
Testing same since   105787  2017-02-14 10:14:42 Z0 days1 attempts


People who touched revisions under test:
  Amit Shah 
  Ashijeet Acharya 
  Dr. David Alan Gilbert 
  Halil Pasic 
  Li Zhijian 
  Pavel Butsykin 
  Peter Maydell 
  zhanghailiang 

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 14 February 2017 15:32
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> 
> On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: 14 February 2017 15:16
> > > To: Paul Durrant 
> > > Cc: xen-de...@lists.xenproject.org
> > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> later)
> > >
> > > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > > Sent: 10 February 2017 21:52
> > > > > To: Paul Durrant ; xen-
> > > de...@lists.xenproject.org
> > > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> later)
> > > > >
> > > > > Hey!
> > > > >
> > > > > This patch lets me compile this emulator under Xen 4.7.
> > > > >
> > > > > It probably can be done better (#ifdef magic?) but for right
> > > > > now this gets me past the compile errors.
> > > > >
> > > > > BTW, are there any other outstanding patches against this tree?
> > > > >
> > > >
> > > > This is still my private project, although if it's generally useful then
> maybe it
> > > can be adopted as part of the Xen project?
> > >
> > > It is a nice project!
> > >
> >
> > Glad you find it useful :-)
> >
> > > By 'adopted' you mean being built as part of xen.git (like minios.git?) -
> and
> > > all of those requirements?
> > >
> >
> > Something like that, then it can be incorporated as an option into the xen
> build and we can make sure any dependency issues like this are caught in
> future.
> >
> > I guess I'd probably make the 'console' branch master in a more official
> repo... I could even look at adding the necessary tooling into libxl to kick 
> it off
> too :-)
> 
> Oooh, and what kind of bribe^H^H^H^H incentive should I send your way?
> 

A time machine? :-)

  Paul

> >
> >   Paul
> >
> > > >
> > > > For the benefit of the list, there are two branches in
> > > http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> > > >
> > > > - The 'master' branch is a very basic standalone device emulator. It
> serves
> > > as boilerplate for emulation of a single PCI device.
> > > >
> > > > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using
> > > libVNCServer which can potentially be used with an HVM guest with PV
> > > network and storage drivers, thus removing the need to use QEMU.
> demu is
> > > a small and constrained piece of code and thus presents a much smaller
> > > attack surface. The original intention was also to run it in a 'console
> service
> > > domain' to further contain damage it was successfully attacked.
> > > >
> > > > It's likely that I will patch the code further once my current work on
> > > libxendevicemodel is done (following acceptance of my recent privcmd
> > > patches).
> > >
> > > 
> > > >
> > > >   Cheers,
> > > >
> > > > Paul
> > > >
> > > > >
> > > > >  demu.c | 7 ++-
> > > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > >
> > > > > Konrad Rzeszutek Wilk (1):
> > > > >   Make it compiler under Xen 4.7.
> > > >

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

On Tue, Feb 14, 2017 at 03:39:00PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:32
> > To: Paul Durrant 
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > 
> > On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > Sent: 14 February 2017 15:16
> > > > To: Paul Durrant 
> > > > Cc: xen-de...@lists.xenproject.org
> > > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> > later)
> > > >
> > > > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > > > > -Original Message-
> > > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > > > Sent: 10 February 2017 21:52
> > > > > > To: Paul Durrant ; xen-
> > > > de...@lists.xenproject.org
> > > > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> > later)
> > > > > >
> > > > > > Hey!
> > > > > >
> > > > > > This patch lets me compile this emulator under Xen 4.7.
> > > > > >
> > > > > > It probably can be done better (#ifdef magic?) but for right
> > > > > > now this gets me past the compile errors.
> > > > > >
> > > > > > BTW, are there any other outstanding patches against this tree?
> > > > > >
> > > > >
> > > > > This is still my private project, although if it's generally useful 
> > > > > then
> > maybe it
> > > > can be adopted as part of the Xen project?
> > > >
> > > > It is a nice project!
> > > >
> > >
> > > Glad you find it useful :-)
> > >
> > > > By 'adopted' you mean being built as part of xen.git (like minios.git?) 
> > > > -
> > and
> > > > all of those requirements?
> > > >
> > >
> > > Something like that, then it can be incorporated as an option into the xen
> > build and we can make sure any dependency issues like this are caught in
> > future.
> > >
> > > I guess I'd probably make the 'console' branch master in a more official
> > repo... I could even look at adding the necessary tooling into libxl to 
> > kick it off
> > too :-)
> > 
> > Oooh, and what kind of bribe^H^H^H^H incentive should I send your way?
> > 
> 
> A time machine? :-)

Analog or digital? Amazon.co.uk does have a nice list of 'Timex' ones :-)

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

[Xen-devel] [linux-linus test] 105786: regressions - trouble: blocked/broken/fail/pass

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

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 15 
guest-localmigrate/x10 fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
105778
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail in 105778 
pass in 105786

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

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

version targeted for testing:
 linux7089db84e356562f8ba737c29e472cc42d530dbc
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  586 days
Failing since 59348  2015-07-10 04:24:05 Z  585 days  273 attempts
Testing same since   105757  2017-02-13 03:57:45 Z1 days4 attempts


7580 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()


Hi Jan,

On 02/14/2017 10:51 AM, Jan Beulich wrote:

On 07.02.17 at 00:32,  wrote:

Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
added a assertion that intack.vector is the highest priority vector. But
according to the osstest, the assertion failed sometimes. More discussion can
be found in the thread
(https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.html).

The assertion failure is hard to reproduce. In order to root cause issue, this
patch is to add logs to dump PIR and vIRR when failure takes place. It should
be reverted once the root cause is found.


Julien, could you add a note on the 4.9 tracking list for us to not
forget to revert this (or at least add NDEBUG conditionals) the
latest in the RC phase?


I have added a note in the 4.9 tracking list.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

On 14/02/17 08:55, Jan Beulich wrote:
 On 13.02.17 at 19:26,  wrote:
>> On 13/02/17 13:19, Jan Beulich wrote:
>>> ---
>>> TBD: Do we really want to re-init the TSS every time we are about to
>>>  use it? This can happen quite often during boot, especially while
>>>  grub is running.
>> The only case we need worry about is if the guest manually writes to the
>> area covered by the vm86 tss.  I think, looking at the logic, that we
>> properly restore the old %tr when re-entering protected mode, so we
>> aren't at risk of having the vm86 tss on the leaving-side of a hardware
>> task switch.
> Yes. But that's the whole point of the question: The guest could
> equally well write to the TSS manually right after we've initialized
> it. And it only harms itself by doing so, hence we could as well
> init the TSS on a less frequently executed path.

Per this patch (I think) we initialise it each time the guest tries to
clear CR0.PE

Unless the VM86_TSS location is below the 1MB boundary, the guest can't
actually clobber it.


As an alternative, if you don't reinitialise each time, when would you
do so?

>
>> We have lasted thus far without, but given the issues recently
>> identified, the only safe conclusion to be drawn is that this
>> functionality hasn't been used in anger.
>>
>> For sensible performance, we need to keep the IO bitmap clear to avoid
>> taking the #GP emulation path.
>>
>> For correct behaviour, we need the entire software bitmap to be 0.
> This one is just for reasonable performance too, afaict. If faulting,
> just like with port accesses, we'd emulate the INT $nn.

Does that actually work?  Upon re-injection of the event, won't hardware
follow the same bad path which caused the #GP fault to start with?

>
>>> +void hvm_prepare_vm86_tss(struct vcpu *v, uint32_t base, uint32_t limit)
>>> +{
>>> +/*
>>> + * If the provided area is large enough to cover at least the ISA port
>>> + * range, keep the bitmaps outside the base structure. For rather small
>>> + * areas (namely relevant for guests having been migrated from older
>>> + * Xen versions), maximize interrupt vector and port coverage by 
>>> pointing
>>> + * the I/O bitmap at 0x20 (which puts the interrupt redirection bitmap
>>> + * right at zero), accepting accesses to port 0x235 (represented by 
>>> bit 5
>>> + * of byte 0x46) to trigger #GP (which will simply result in the access
>>> + * being handled by the emulator via a slightly different path than it
>>> + * would be anyway). Be sure to include one extra byte at the end of 
>>> the
>>> + * I/O bitmap (hence the missing "- 1" in the comparison is not an
>>> + * off-by-one mistake), which we deliberately don't fill with all ones.
>>> + */
>>> +uint16_t iomap = (limit >= sizeof(struct tss32) + (0x100 / 8) + (0x400 
>>> / 8)
>>> +  ? sizeof(struct tss32) : 0) + (0x100 / 8);
>>> +
>>> +ASSERT(limit >= sizeof(struct tss32) - 1);
>>> +hvm_copy_to_guest_phys(base, NULL, limit + 1, v);
>>> +hvm_copy_to_guest_phys(base + offsetof(struct tss32, iomap),
>>> +   &iomap, sizeof(iomap), v);
>> This should be linear rather than phys.
> Strictly speaking yes, but since we're running with an ident map,
> it doesn't matter. And I'd prefer not to have to introduce a vcpu
> parameter to the linear copy function, as that would mean quite
> a few changes elsewhere. Would you be okay with me just
> attaching a respective comment here?

Ok.

~Andrew

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

Re: [Xen-devel] [PATCH v7 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

On Mon, Feb 13, 2017 at 02:32:13PM +0800, Yi Sun wrote:
> This patch creates CAT and CDP feature document in doc/features/. It describes
> key points to implement L3 CAT/CDP and L2 CAT which is described in details in
> Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION 
> FEATURES".
> 
> Signed-off-by: Yi Sun 
> ---
> v7:
> - correct typo.
> - replace application/VM to domain.
> - amend description of `feat_mask` to make it clearer.
> - update revision.
> - other minor fixes.

You forgot to include in the 'Areas of improvement' the issues I described.


> ---
>  docs/features/intel_psr_cat_cdp.pandoc | 454 
> +
>  1 file changed, 454 insertions(+)
>  create mode 100644 docs/features/intel_psr_cat_cdp.pandoc
> 
> diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
> b/docs/features/intel_psr_cat_cdp.pandoc
> new file mode 100644
> index 000..65736cc
> --- /dev/null
> +++ b/docs/features/intel_psr_cat_cdp.pandoc
> @@ -0,0 +1,454 @@
> +% Intel Cache Allocation Technology and Code and Data Prioritization Features
> +% Revision 1.0

?? 1.6 surely

.. snip..

> +# Areas for improvement
> +
> +N/A

Here.
> +
> +# Known issues
> +
> +N/A
> +
> +# References
> +
> +"INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION FEATURES" 
> [Intel® 64 and IA-32 Architectures Software Developer Manuals, 
> vol3](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html)
> +
> +# History
> +
> +
> +Date   Revision Version  Notes
> +--   ---
> +2016-08-12 1.0  Xen 4.9  Design document written
> +2017-02-13 1.6  Xen 4.9  Design document written

It was not written at 1.6. It was changed. And you enumerate
what was changed.

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

Re: [Xen-devel] [PATCH] x86/mm: Alter is_xen_fixed_mfn() to use mfn_t


Hi Andrew,

On 02/07/2017 06:57 PM, Andrew Cooper wrote:

The predicate is common between x86 and ARM, and is unlikley to be different/


NIT: s/unlikley/unlikely/


on other architectures.  Drop the arch declarations and introduce a common
static inline in xen/mm.h instead.

Signed-off-by: Andrew Cooper 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 04/24] x86: refactor psr: implement CPU init and free flow.

On Mon, Feb 13, 2017 at 02:32:16PM +0800, Yi Sun wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
> 
> Signed-off-by: Yi Sun 
> ---
> v7:
> - initialize 'l3_cat'.
> - fix typo.
> - correct criteria to call 'free_feature' in cpu_fini_work. Only when
>   CPU_STARTING has been done and all CPUs are offline, 'free_feature'
>   can be called.
> - remove 'free_feature in 'psr_free' because 'psr_free' should only free
>   resources allocated in 'psr_cpu_prepare'. But resources allocated in
>   'psr_cpu_prepare' will not be freed to simplify things.
> ---
>  xen/arch/x86/cpuid.c|   6 --
>  xen/arch/x86/psr.c  | 170 
> +++-
>  xen/include/asm-x86/processor.h |   7 ++
>  3 files changed, 175 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..e3e92dd 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -34,12 +34,6 @@ static void cpuid_leaf(uint32_t leaf, struct cpuid_leaf 
> *data)
>  cpuid(leaf, &data->a, &data->b, &data->c, &data->d);
>  }
>  
> -static void cpuid_count_leaf(uint32_t leaf, uint32_t subleaf,
> - struct cpuid_leaf *data)
> -{
> -cpuid_count(leaf, subleaf, &data->a, &data->b, &data->c, &data->d);
> -}
> -
>  static void sanitise_featureset(uint32_t *fs)
>  {
>  /* for_each_set_bit() uses unsigned longs.  Extend with zeroes. */
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index 5acd9ca..9a2b717 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Terminology:
> @@ -35,6 +36,9 @@
>  #define PSR_CAT(1<<1)
>  #define PSR_CDP(1<<2)
>  
> +#define CAT_CBM_LEN_MASK 0x1f
> +#define CAT_COS_MAX_MASK 0x
> +
>  /*
>   * Per SDM chapter 'Cache Allocation Technology: Cache Mask Configuration',
>   * the MSRs ranging from 0C90H through 0D0FH (inclusive), enables support for
> @@ -136,11 +140,84 @@ struct psr_assoc {
>  
>  struct psr_cmt *__read_mostly psr_cmt;
>  
> +static struct psr_socket_info *__read_mostly socket_info;
> +
>  static unsigned int opt_psr;
>  static unsigned int __initdata opt_rmid_max = 255;
> +static unsigned int __read_mostly opt_cos_max = MAX_COS_REG_CNT;
>  static uint64_t rmid_mask;
>  static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
>  
> +/*
> + * Declare global feature list entry for every feature to facilitate the
> + * feature list creation. It will be allocated in psr_cpu_prepare() and
> + * inserted into feature list in cpu_init_work(). It is protected by
> + * cpu_add_remove_lock spinlock.
> + */
> +static struct feat_node *feat_l3_cat;
> +
> +/* Common functions. */
> +static void free_feature(struct psr_socket_info *info)
> +{
> +struct feat_node *feat, *next;
> +
> +if ( !info )
> +return;
> +
> +/*
> + * Free resources of features. But we do not free global feature list
> + * entry, like feat_l3_cat. Although it may cause a few memory leak,
> + * it is OK simplify things.
> + */
> +list_for_each_entry_safe(feat, next, &info->feat_list, list)
> +{
> +__clear_bit(feat->feature, &info->feat_mask);
> +list_del(&feat->list);
> +xfree(feat);
> +}
> +}
> +
> +/* L3 CAT functions implementation. */
> +static void l3_cat_init_feature(struct cpuid_leaf regs,
> +struct feat_node *feat,
> +struct psr_socket_info *info)
> +{
> +struct psr_cat_hw_info l3_cat = { };
> +unsigned int socket;
> +
> +/* No valid value so do not enable feature. */
> +if ( !regs.a || !regs.d )
> +return;
> +
> +l3_cat.cbm_len = (regs.a & CAT_CBM_LEN_MASK) + 1;
> +l3_cat.cos_max = min(opt_cos_max, regs.d & CAT_COS_MAX_MASK);
> +
> +/* cos=0 is reserved as default cbm(all bits within cbm_len are 1). */
> +feat->cos_reg_val[0] = (1ull << l3_cat.cbm_len) - 1;
> +
> +feat->feature = PSR_SOCKET_L3_CAT;
> +ASSERT(!test_bit(PSR_SOCKET_L3_CAT, &info->feat_mask));
> +__set_bit(PSR_SOCKET_L3_CAT, &info->feat_mask);
> +
> +feat->info.l3_cat_info = l3_cat;
> +
> +info->nr_feat++;
> +
> +/* Add this feature into list. */
> +list_add_tail(&feat->list, &info->feat_list);
> +
> +socket = cpu_to_socket(smp_processor_id());
> +if ( !opt_cpu_info )
> +return;
> +
> +printk(XENLOG_INFO "L3 CAT: enabled on socket %u, cos_max:%u, 
> cbm_len:%u\n",
> +   socket, feat->info.l3_cat_info.cos_max,
> +   feat->info.l3_cat_info.cbm_len);
> +}
> +
> +static const struct feat_ops l3_cat_ops = {
> +};
> +
>  static void __init parse_psr_bool(char *s, char *value, char *feature,
>unsigned int mask)
>  {
> @@ -180,6 +257,9 @@ static void __init parse_psr_param(char *s)
>

Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.

> -Original Message-
[snip]
> > Thank you. Keep in mind that it will likely break against
> > older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h
> 
> I'm not sure you actually need to include that directly. I was going to try 
> just
> adding the 'want compat' defines and seeing if I could make it work. I think 
> it
> *should* work since all we do for upstream QEMU is add those defines into
> the configure cmd line IIRC.

I pushed modified patches into the master and console branches. Hopefully it 
should now build ok for you.

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

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

2017-02-14 Thread Peter Zijlstra

On Tue, Feb 14, 2017 at 09:46:17AM -0500, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
> > On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
> >> It is the address of &steal_time that will exceed the 32-bit limit.
> > That seems extremely unlikely. That would mean we have more than 4G
> > worth of per-cpu variables declared in the kernel.
> 
> I have some doubt about if the compiler is able to properly use
> RIP-relative addressing for this.

Its not RIP relative, &steal_time lives in the .data..percpu section and
is absolute in that.

> Anyway, it seems like constraints
> aren't allowed for asm() when not in the function context, at least for
> the the compiler that I am using (4.8.5). So it is a moot point.

Well kvm_steal_time is (host/guest) ABI anyway, so the offset is fixed
and hard-coding it isn't a problem.

$ readelf -s defconfig-build/vmlinux | grep steal_time
100843: 00017ac064 OBJECT  WEAK   DEFAULT   35 steal_time

$ objdump -dr defconfig-build/vmlinux | awk '/[<][^>]*[>]:/ { o=0 } 
/[<]__raw_callee_save___kvm_vcpu_is_preempted[>]:/ {o=1} { if (o) print $0 }'
810b4480 <__raw_callee_save___kvm_vcpu_is_preempted>:
810b4480:   55  push   %rbp
810b4481:   48 89 e5mov%rsp,%rbp
810b4484:   48 8b 04 fd 00 94 46mov-0x7db96c00(,%rdi,8),%rax
810b448b:   82 
810b4488: R_X86_64_32S  __per_cpu_offset
810b448c:   80 b8 d0 7a 01 00 00cmpb   $0x0,0x17ad0(%rax)
810b448e: R_X86_64_32S  steal_time+0x10
810b4493:   0f 95 c0setne  %al
810b4496:   5d  pop%rbp
810b4497:   c3  retq   


And as you'll note, the displacement is correct and 'small'.

The below relies on the 'extra' cast in PVOP_CALL_ARG1() to extend the
argument to 64bit on the call side of things.

---
 arch/x86/kernel/kvm.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 099fcba..2c854b8 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -589,6 +589,7 @@ static void kvm_wait(u8 *ptr, u8 val)
local_irq_restore(flags);
 }
 
+#ifdef CONFIG_X86_32
 __visible bool __kvm_vcpu_is_preempted(int cpu)
 {
struct kvm_steal_time *src = &per_cpu(steal_time, cpu);
@@ -597,6 +598,26 @@ __visible bool __kvm_vcpu_is_preempted(int cpu)
 }
 PV_CALLEE_SAVE_REGS_THUNK(__kvm_vcpu_is_preempted);
 
+#else
+
+extern bool __raw_callee_save___kvm_vcpu_is_preempted(int cpu);
+
+asm(
+".pushsection .text;"
+".global __raw_callee_save___kvm_vcpu_is_preempted;"
+".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
+"__raw_callee_save___kvm_vcpu_is_preempted:"
+FRAME_BEGIN
+"movq __per_cpu_offset(,%rdi,8), %rax;"
+"cmpb $0, 16+steal_time(%rax);"
+"setne %al;"
+FRAME_END
+"ret;"
+".popsection"
+);
+
+#endif
+
 /*
  * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
  */

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

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor


Hi Tamas,

On 13/02/17 16:20, Tamas K Lengyel wrote:

On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
 wrote:

Hello,

This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to discuss more broad topic there.

Obviously, there are growing number of SMC users and current state of
SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
secure way, Xilinx wants to forward some calls directly to Secure
Monitor, while allowing to handle other in userspace, etc.

My proposition is to gather all requirements to SMC (and HVC) handling
in one place (e.g. in this mail thread). After we' will have clear
picture of what we want, we will be able to develop some solution,
that will satisfy us all. At least, I hope so :)

Also I want to remind, that there are ARM document called "SMC Calling
Convention" [3]. According to it, any aarch64 hypervisor "must
implement the Standard Secure and Hypervisor Service calls". At this
moment XEN does not conform to this.

So, lets get started with the requirements:
0. There are no much difference between SMC and HVC handling (at least
according to SMCCC).
1. Hypervisor should at least provide own UUID and version while
called by SMC/HVC
2. Hypervisor should forward some calls from dom0 directly to Secure
Monitor (Xilinx use case)
3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
architecture service calls, etc.
4. Hypervisor should handle TEE calls in a secure way (e.g. no
untrusted handlers in Dom0 userspace).
5. Hypervisor should support multiple TEEs (at least at compilation time).
6. Hypervisor should do this as fast as possible (DRM playback use case).
7. All domains (including dom0) should be handled in the same way.
8. Not all domains will have right to issue certain SMCs.
9. Hypervisor will issue own SMCs in some cases.


10. Domains on which the monitor privileged call feature is enabled
(which is by default disabled for all domains) should not be able to
issue SMCs such that it reaches the firmware directly. Xen should not
bounce such calls to the firmware on behalf of the domain. Xen should
not alter the state of the domain automatically (ie. incrementing PC).
These calls should be exclusively transfered to the monitor subscriber
for further processing. HVC calls need not be included in the monitor
forwarding as long as the HVC call can be governed by XSM.


This should not be a strong requirement. Whilst in your use case you 
want to forward all the SMCs to the monitor app, there are use case 
where Xen would need to emulate SMCs on the behalf of the guest. For 
instance see PSCI (arch/arm/vpsci.c).


Another valid use case is Xen handling power management for device 
assigned to the guest and having the monitor app acting as a "Trusted App".


Regarding the HVC call governed by XSM. I think this is the wrong way to 
g. As it was mentioned a couple of time HVC is a valid conduit for 
Secure monitor call. You should not deny them on the basis that your 
monitor app is not able to handle it properly. A better way would be to 
have a list of Secure Monitor Call (HVC/SMC) that should be forwarded to 
the monitor app.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

On 13/02/17 12:36, Jan Beulich wrote:
 On 13.02.17 at 12:00,  wrote:
>> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>>  
>>  cpuid_featureset_to_policy(fs, p);
>>  
>> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>>  p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
>> -d->arch.paging.gfn_bits + PAGE_SHIFT);
>> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
>> -(p->basic.pae || p->basic.pse36) ? 36 : 32);
>> +paging_max_paddr_bits(d));
>> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
> The re-write of the commit message doesn't appear to have
> resulted in the PAE/PSE36 part being explained any better. I'm
> also unconvinced that exposing namely PSE36 to a guest
> with less than 36 physical address bits would be compatible with
> old OSes not knowing of CPUID leaf 0x8008 yet - they
> would legitimately assume 36 bits. The same presumably also
> goes for PAE.

Hmm ok.  With the other bugfix of not dropping the first line, this hunk
is now simply:

@@ -504,7 +505,7 @@ void recalculate_cpuid_policy(struct domain *d)
 
 p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
 p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
-d->arch.paging.gfn_bits + PAGE_SHIFT);
+paging_max_paddr_bits(d));
 p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
 (p->basic.pae || p->basic.pse36) ? 36 :
32);
 

>
>> @@ -360,6 +361,21 @@ void paging_dump_vcpu_info(struct vcpu *v);
>>  int paging_set_allocation(struct domain *d, unsigned int pages,
>>bool *preempted);
>>  
>> +/* Maxphysaddr supportable by the paging infrastructure. */
>> +static inline unsigned int paging_max_paddr_bits(const struct domain *d)
>> +{
>> +unsigned int bits = paging_mode_hap(d) ? hap_paddr_bits : paddr_bits;
>> +
>> +if ( !IS_ENABLED(BIGMEM) && paging_mode_shadow(d) &&
>> + (!is_pv_domain(d) || opt_allow_superpage) )
>> +{
>> +/* Shadowed superpages store GFNs in 32-bit page_info fields. */
>> +bits = min(bits, 32U + PAGE_SHIFT);
>> +}
>> +
>> +return bits;
>> +}
> Does this really need to be an inline function? With the overall goal
> of not including every header everywhere, I particularly dislike the
> need to include xen/kconfig.h here for things to build.

It is not on a critically path, but it seems wasteful to force something
this small to be out of line.

As for kconfig.h, it is tiny.  What is the problem with adding it here? 
We already pull generated/autoconf.h into everything via xen/config.h

~Andrew

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

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 14/02/17 14:46, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
>> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
>>> It is the address of &steal_time that will exceed the 32-bit limit.
>> That seems extremely unlikely. That would mean we have more than 4G
>> worth of per-cpu variables declared in the kernel.
> I have some doubt about if the compiler is able to properly use
> RIP-relative addressing for this. Anyway, it seems like constraints
> aren't allowed for asm() when not in the function context, at least for
> the the compiler that I am using (4.8.5). So it is a moot point.

You can work the issue of not having parameters in a plain asm()
statement by using an asm-offset, stringizing it, and have C put the
string fragments back together.

"cmpb $0, " STR(STEAL_TIME_preempted) "(%rax);"

~Andrew

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

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor




On 13/02/17 16:59, Tamas K Lengyel wrote:

On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall  wrote:

Hi Tamas,


On 13/02/17 16:20, Tamas K Lengyel wrote:


On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
 wrote:


Hello,

This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to discuss more broad topic there.

Obviously, there are growing number of SMC users and current state of
SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
secure way, Xilinx wants to forward some calls directly to Secure
Monitor, while allowing to handle other in userspace, etc.

My proposition is to gather all requirements to SMC (and HVC) handling
in one place (e.g. in this mail thread). After we' will have clear
picture of what we want, we will be able to develop some solution,
that will satisfy us all. At least, I hope so :)

Also I want to remind, that there are ARM document called "SMC Calling
Convention" [3]. According to it, any aarch64 hypervisor "must
implement the Standard Secure and Hypervisor Service calls". At this
moment XEN does not conform to this.

So, lets get started with the requirements:
0. There are no much difference between SMC and HVC handling (at least
according to SMCCC).
1. Hypervisor should at least provide own UUID and version while
called by SMC/HVC
2. Hypervisor should forward some calls from dom0 directly to Secure
Monitor (Xilinx use case)
3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
architecture service calls, etc.
4. Hypervisor should handle TEE calls in a secure way (e.g. no
untrusted handlers in Dom0 userspace).
5. Hypervisor should support multiple TEEs (at least at compilation
time).
6. Hypervisor should do this as fast as possible (DRM playback use case).
7. All domains (including dom0) should be handled in the same way.
8. Not all domains will have right to issue certain SMCs.
9. Hypervisor will issue own SMCs in some cases.



10. Domains on which the monitor privileged call feature is enabled
(which is by default disabled for all domains) should not be able to
issue SMCs such that it reaches the firmware directly. Xen should not
bounce such calls to the firmware on behalf of the domain. Xen should
not alter the state of the domain automatically (ie. incrementing PC).
These calls should be exclusively transfered to the monitor subscriber
for further processing. HVC calls need not be included in the monitor
forwarding as long as the HVC call can be governed by XSM.



This should not be a strong requirement. Whilst in your use case you want to
forward all the SMCs to the monitor app, there are use case where Xen would
need to emulate SMCs on the behalf of the guest. For instance see PSCI
(arch/arm/vpsci.c).


In my usecases it is a strong requirement. What happens when the
monitor system is disabled is beyond my concerns - Xen can emulate or
forward the call as it wishes. But when the monitor application is in
use - in my usecase - it needs to be in exclusive control. If that
breaks an in-guest application, that is acceptable in my usecase. As
soon as there is another usecase that would need to support such an
application while the monitor system is enabled, the monitor system
can be fine-tuned for those needs to allow Xen to emulate. I've said
it many times, I have nothing against doing that, but as I don't need
it I won't be able to spend time implementing it.


Let me remind you that this discussion is not about what you implemented 
but what is a sensible design to fit everyone. I also never ask you to 
implement anything.






Another valid use case is Xen handling power management for device assigned
to the guest and having the monitor app acting as a "Trusted App".

Regarding the HVC call governed by XSM. I think this is the wrong way to g.
As it was mentioned a couple of time HVC is a valid conduit for Secure
monitor call. You should not deny them on the basis that your monitor app is
not able to handle it properly. A better way would be to have a list of
Secure Monitor Call (HVC/SMC) that should be forwarded to the monitor app.


I disagree. XSM needs to be in complete control of all hypercalls.
Whether denying some of them will break an application or not is not
Xen's concern. That is up to me as a user of Xen and XSM. If Xen
overrides a XSM policy because we hard-coded HVCs that pass-through,
that is a huge security policy violation. So even if we make a list of
HVCs that should also fall under the monitor privileged call umbrella,
it should still not override XSM. So since I would not be looking to
emulate anything that gets forwarded as a result of an HVC call, XSM
works for me just fine as the only thing I would do anyway is deny
them. So why would that list help when I might as well just make my
list more efficiently using XSM?


Again, why do you want to handle SMC and HVC differently given they are 
both a conduit fo

[Xen-devel] [PATCH 3/4] docs: remove odt variant of STAO

Signed-off-by: Olaf Hering 
---
 docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/docs/misc/status-override-table-spec.odt 
b/docs/misc/status-override-table-spec.odt
deleted file mode 100644
index 
4ea576b2c248a70445a6a5be751055bc03205092..
GIT binary patch
literal 0
HcmV?d1

literal 20206
zcmeFYQ;;uA3@|t+eXm4+AVQlDZVQ0(e
zYHPw^XXs?%#9(J{YHMO=>|$eT>&)P6>h7%Ye=>#;MD6%a1O)USWBoIxV(wyNWNT<)
z?ZoK(zeEOmTeAoSIdOOx9GHJ9@RAZDO8@3jARu5MDA0e>UeLQE5D+Mkf{cnNGcz*}
z508k5h_tk{ii(Q1wzjdcv6YpTlarH|mlv=J0MZ-)V*x<11)$plaGe2U9sn92fRyh#
zgFk>Z5Wp1*;EMpLhHPp@YzapLB;o)vi2$WkfLc00CktR0yKS1VW0kUNm%eA8v1gbI
zaLU?u&pj|L09cm*dH$=@j5c*o_4V}^c3-CT12P8y
zeS>4A{Z~~(e+xzdCF6jqDM0<`b@Rkc$MkLe9H4XNu6Y5_JAc=?4Cq@23=Iv9P0UP9
zO)V`gZEbB0F5M4p0;V<|Cw2kzJ5MwFfR%&irDMRx@yq%dVE6oW`vP!ubaZ`veQ^GK
z`1kw#=Kb^zaP{!>`1ttn^7Hcc{qytl&(DDWfBb*m1L!5r^FToO&5|O5D(;)tKJQ*=
z9IH3}Rn44W>LG!uE1td%KSKGpBivpWsZ%@48~BPp(E^((NS{f&0@Ab2Ke)Thfi6e_Kl??R0VE
zeDd)*ALtC$&Wt98l{$%9q?#S#w?`;
z4dB(eg5Bw4!7UBKzUcRRc@hQ12WIDW#IE>`JO(C@_R)8Syz-}1XEX2GyR+GcrKN0f
z3v5ut#lXn(N*rRHT*)%7-`#hJ?^)B61LfY=a~z`!BBQfc+Gn2p>sZ@jjr`Kd?C?rW
z8}N}@6?^YmFXuSZpM4Aj!>13{BQMk%XG5FArjZeGOf}_A?7?;y(>vtxMMtkgDNCP>
zRYo}e9LcmZHAVy?*U$!Ui+XozpRb+zRs64$!y?!nHrB@r6+dsvf$xvv$NkHZ=cX{`
zbcu_l3;g!=*A6AYk#VNp?JHd%tk0v*oH@wPize4gL5uB4rp2A;;s@b3T*Xc1sRM~mS1+t+Bmi+zVz$x`S1kG03w>PSyqsu$)O@My|O9|Ai@
z`t`_^HsQ5hOr5XqmA&`XUD9*awHxHh8UkYfC4O;SS{ftp
z>pEfHkE0RP(W7&HJ8Lh(pZag?o>gDjU6YMZ=OW#&@`iI*pry>I~N6pL5)7G=|8_2+#zD~}$G|f&%7ID+b&9zr2
zCpY(IrYDQ(r7K6y&d1NErK`2Ot*NuUx2YEa(6@D4Tj$o+dg{4H@7lGa=h^I8-`m#G
z!uwhq>0ZaNs6vWm1}hwze5v)D3qz2sCi6`tdFT3X!|#`E^&1;T8^XCl0O1>q6d(R+
z%G~dUA0GpeX)3|m;$#w49NhSU2xYMjk>LK?PCqBZ6M$}3AJ^yHRTA!6-QLgEbCzG9
z&*$!SNFV(S>i)%kHN{cwZ8WEwmJ&CIsLrs?VLVeFW-aHm#;ok
zU9Zq72=wAWlVK5JCXPj9YAMBpHhmoGQGI^<_*h@UzA$zxx5wS@&#bMitS#Kvo4u`e
zkJq1`v8`X({`p%?Ssf3<`j3;)VT817VC$Y_hhP&#EoltS0G4KxR){b21Uq@n&Uu`F=L^K!Vh|qiD#W-p}0E01#~{P+k~W?XNE
z-T>v_Ih}6Geaaeim$NV+1zVDVB_{h_gDZ1Ot4Z2#ZuW9lXoyr36`6`BQ_Vx5CPA6N5s(q_R@jrE(lz
zBzR_Mby>An&grG(oGt?#vL=)`cj0Q{b9q7E{$a(C*R9Iiyz=g0Ml}Vt)>YiW
z2C4*kg)er4xTv1>(?yyK!0(?WLl9qC-oH3csiPrR)h#?Lp&UhS1lJ8
zGD>97=nBjlfph|DJVyw!yuTu(bL1itM1d4$c!Cpzmkf=3N#S-w!^g1*6fp^!5qJf3
zS}-Yzg%d;xvfpFts7hhP9MAJpm*J*mcy-I+EN%(SjHN0y?r}tfa83Ssc7oL8CT&fP
zirPjQU^GLuQrY(2`b{{dJh(j~vP6JzMuI9nf$(bCM!I&%8q|egWjs#uiE?PEh=~!VQ=cIV^Mr6#ttN7JY@=t0P@PD
z)^zaVNYtBnaumq`^ZCYO0edbA5htNtF$?qOnqo%UnDMMoS~E*>K1?MidfHTwR;?Ab
z$xE`l2}P@r%9<4g93f~4GjKoJ#`|7&>UB5A&m*iG&0b$K+Mm@{)<9zS{brB%6P0TV
zr{X0s@LVx_;Z8JAR!k`O$kD8U$XDA{4<_TIb=R@7Fx0`N{3~QtZ&|c0Dm@t?*5Ta$?58P?OgvC_|HG(JRryLuoRk#n!KhM)Cxpca3Mo$*WFIO`nt(-(lG~`vSFQ?58wSs7v3Dx*N|sbEQ%$&}
zRM$oap=pKw78t&|Oeuu)^3G4jwW$2h`FogReLU*`AOqe^E)88BeZ4&GoGoqL+upVk
z<|cN&CeJdjtI_4dC%N128Wn9s0=&OZuC1;gUXY)p$bHd=Mx8Eo;zJ~W}Bsn?GZK@t!WITRYS(h^)$Xk{23Z5SD-p^|)o
zBlZRHew;qpo%j#lu>p_N=cX*50y=jqOoXg8X5saHz^GYFk_(M
z7?H0af8g9F@d#DNl2;M5<4BhgxlH6Jv=s`ACvU?Wco}r_0OD?bZI#-q_gd
z+@!GD5crU&gp2^x|644UVme|yUn5gVQBP4
zOe;f2bDeKH+;2CgiNnu5J$vPsWnDn@I*WXVND73Nro}Z#IW!U3qPsD@+cuW6M}4>b
zEGK;PF!s^3RsY-R)kYR#UoP+ZkH=@&#?Hn>Nz9i1KM-Q8r`^%fz{JJH1z7p|;<)4S
zc=gQG`FI?vOLO(h?CxoNTIsW$t<~vjW&3>1YqOix*Os8gUHgS_N_l&laA0bVWRHd9
zo$QVsusIJwsyaID$Sc<@7Kz?W5zg{G(%jJX
ze)NJ!`>Lka`uXa&zO%cotF@uAzP{ew*U{Vve}A*f_xAa<)9n2E8yB~W*6p_L@9y62
zI_Gw8SI76!P;*aLS4U4qB0G!N$-#@|I%}ii>^n@aiJqfS(4j&M=!;R$uNaHM`^_mC
zXQJMaJxsa-dz9#~EwdgzZzsW@Tl}3-+A5sP?(ytm>`OStorIfl8i>DcjUAw55+!IV
zDEq^24pVg5u^GYjk$h^u;M0Gkwu+w5VmaZ9t2m33R)I2rZHYknoUqVAJn0n*2auJN
zAjCGiK(Z2(u@IDL$Qc?2$nC(|@rd#z_noq(qoty0A~hnCPM1@S_dNwx?5M^qBsC_m
z4I>lKM4)Fw7d5ooNz*eLX)2pS6-j5MeHbKbA{+PjF`4bSSWI*0Pt)Tf^Be8cSN2~N
zCo?1)MWShSF!t}z&Kwj+75t+V(9_E0u$JUE~j?9m{t!t)sU~{|j%3*kZS%%R#%lv(C4p2fIH(-_5%hwb!qyh%Ya%
zFNj{Bh@Lw=KVCpZdz&51ZL6K^d_Gl=rd>@dpN>8aPDMT28SP6MRxYKb++M$XAej(O
z7iH``o@YN~+O{%2Z$5Kca!zm3#4CyAA--?8C5BE
z6wm$){7reEj`D3zG8#l>|*QhBNrp99~-7GL+nn0cVQj5bPkQs|*z+
zrRu27w(exlP%f^7$#O7A6l^a*B`9(^mP`>^QK&@TGESjoP>j}&f;HYTLIqQ;sT#{A
zcE^+wAO6eUi^`oDnpjRz5m^j7GHkiPeD>3ZDKo>qi`G|Kp?%44=fNyVE
zv>N8*!1@SYtB_N5@WIc3gfuXSEfH{>tN)f&}J!C)(I&&{E96Sgdh=06D2XG!vWCNJw%(o}eL2qym
z)S&hziby65o>VYbxK~7Yeqk{(u9i_|Je9))2tBx5Fj_!IHkt|u^%z=9J5_^3wMb$L
zn#J^mhi;;Z!Ky@nz2sg!TRh#tEYk42Mt?8}4upb0orGy(Gt>eNFf}#mfr`H;jK@NN
z(q%M+hC04Q2+X`(Ak#b&Ji%0VU@EW%LLoo$a7_XnRag?(6IuoFFO={`A>rBdMgweW
z&F2@BB40m~BT(dfV}{YB#1;sX59*fl{vr3tv2r=O4*gKxcGSrg0LfImwofP%n(?X>
zleo~JxTej6JuDIOHr5GE(Ib*qgk>pR%Ov>fWDwo|o)=1$;R6?mCmPP-G^Xg~
z!+{|0z@@?wAbsH5cz@;~Lc=~)iY8U}OT>(OYN8SMeL7{x{qH*r9s>Ph?qe*hK|glS
z!Bjxf3u1!Zut0gd#3F*4@$_Fb;hqB!X{N}al#$}lU7c4E(~S7VZXLC@
zG)hv?#WUW^RIH9FDbr?=g?%Sya0j4HJZhDR1J1D1CJ2rKBQ*ROrj3~cuE1dUi5Ulu
zSVin*9-*1Y$>y4)Ujj=3A{JRVTZEh}Rb$7GH
zX^|)4Rg8mk&Jqi8$V15O(v7F<2ZadO35VFLNTf6ho$w^eAoDP%(WE@KVL3AslVxe7
z!}eW~wF=21KiCcZNfAYHGbz~mzl2$J;^=O{Imd0}T)4HC=-|#|5!?oDN)&{XpE#Aw
z8yh$$fe%Bnxfxlr_WHSm+`9`mj->Ix1-#3`q|HtX7Cd-eU>I`}-v_+>=AcfKc1}f{
z

[Xen-devel] [PATCH 0/4] docs: convert from binary to ASCII

The odt files should have been saved as Flat XML via 'Save as ...'.

git send-email warns about lines longer than 998 chars. Hopefully all
involved mail services have no silly limits.

Olaf

Olaf Hering (4):
  docs: convert STAO from odt to fodt
  docs: convert XENV from odt to fodt
  docs: remove odt variant of STAO
  docs: remove odt variant of XENV

 docs/misc/status-override-table-spec.fodt | 707 +
 docs/misc/status-override-table-spec.odt  | Bin 20206 -> 0 bytes
 docs/misc/xen-env-table-spec.fodt | 852 ++
 docs/misc/xen-env-table-spec.odt  | Bin 19204 -> 0 bytes
 4 files changed, 1559 insertions(+)
 create mode 100644 docs/misc/status-override-table-spec.fodt
 delete mode 100644 docs/misc/status-override-table-spec.odt
 create mode 100644 docs/misc/xen-env-table-spec.fodt
 delete mode 100644 docs/misc/xen-env-table-spec.odt


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

[Xen-devel] [PATCH 4/4] docs: remove odt variant of XENV

Signed-off-by: Olaf Hering 
---
 docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/docs/misc/xen-env-table-spec.odt b/docs/misc/xen-env-table-spec.odt
deleted file mode 100644
index 
c8de7ca7d8e7d00dabe9d7bebef1e8117e47f95e..
GIT binary patch
literal 0
HcmV?d1

literal 19204
zcmeFZbBu36(=Ix;ZQHhI_Sm*QTZ)u>b_
z-C5POo~L>#%7B8Q0Rce)0bys-OY4uaz)=DL0sTk*bphE~*_pX|I+__dI@(&97`a+G
z*fajNH)U`za+&8Ox*pir~Np0{V|&{WGR&>1Jna
zZ)9cb!sz6fPjIZK>yYDg5RBifIxv1WmSJs
zP*8Aka`N)>ii(QL%F3#$s_N+In3$N@*x0zZxOjVegO~vzECDdq0AxD=x+4JB6+q+;
zAol{$_yQOL04zZO?l1s5|SMpYdLHvuAA0Wlqbgu0W&`jfP#v#i$h+>Z0)9za3&MS4FVdk|38e_1_r
zRX7SL83$BN0qRGunL?>b;`aA<03YIc*y^53Q;y2bJZe@(qu&AmOSx_!WZ>FF
zDMEFoI;%IcabFt?)3ep;mwoSj!!K`uEu5pV3@Q?%*)OWrcaZ9=2U>h_7fygxWR%v>05Cn>Suegibks
zt09B!uLG37^tzk3@HR42uzuamy4g=QE?Zk`;cJX`tLZ*<9BY+~Gj8D;47Y5j6v3O$
zzKiX>PCci-F2Aj|H7lRJU7l^`VZI-y+RES%E?nGe;Q^{xpH;E6e$-#T{VRTdURXXZ
zg5i8jp27=qatiEK%)txZ>RNH&?rhv&)AstU0DN7F?teMFch>FP)jUGFOeM?IT*E@H
zrFRp~-T*xOw%-;FEZGK2v;aPT0|#u&oHh*Xzbcs2ZCW;dE<&XOoN%?Pv60}%s+zt#
zvIP71U(K4h1^TXi5e;>pt28K^5DyBg07qGMGr%zunDGAZvo9miijY|IF#QLIh!R1y
zo`&_@L1`a{FZs|WET`WqCA;r&0A^iP;8Eb5K0!W2CWxlsQFg&QgVk@O;s!5p!?&tG
zC{0@}RlUD`;TAQ^V;O!6<47>Q%*9{0{0yRvT32yyWw8KR>AtHNT`hl*zLD>EnbaFp
zDSVl>tcI34EbGk2)n~J*b5a(06?Lh2YZ{!@tcnkL6}2fjFvNJt?96EUZ8-Cp-KR?c=!DF^kgU|m=$>ru5z)Ug+Ck9{`}T2>31DYR=OF6oLLhoJ|J1b>egC1rs|D%hOlG*KxffbwFxldTkuBO;cw?5FwfmoRy
zSl;iAiXt#3uTyVKouZ8`SQmm_7kJAg*5uLDQJUuCzlY|J%I>TlSeV&GCnXcPw1!Rt
zxE(GVqJ$8URc(OX@ZDQy6SghhAgB6;u4NCNt*ve@t+z4D-xa^F=@=__e+IV)My?m$
zZH|DBl$UOGv)FopuppaMuy}!vMn%rjfk#IzTm8XI03xT(0SjMU1|MTfk3Foa_m}CM
zwRXB)i@beTb@Xo&=^BuZY`v`?$FpzIjNXp?dS^4Ws|*O<8d+7zxal95eFO&8p$KN@
zKK_8Oi@iPqUwuF$cgJrt-FzGSyiB&RqJyP-OEv=jXOla`p@rpuI8o%k@~q;djw<5e
z+@yke)(@6kFGs=mmNH(AGNZsp|_eDdC!QLkGG+S}tkYt}~W+KD|toRKeMeNt$XsPQY?I`^rj5x`SV
zs|>pLGb$haq+^w!rjS{;;CZcJlR8gk@pgLNfz;`4YlG}c^sjGw_5I|m_6t*}?7@^`
zmfNCcogoHKz4`w7n{ZWD|GBmkT*F~{1z#3g7OI3YOBIJ~0>^uuxSxVGY?(tf$z5ty
zd<@X(>gr|L`?0pWo(N9;ynMX8j0WiE04`P!zgzt4>gI0!UUvrEZ60mfT2mgdDKnxn
zm}L1I(pUza=(Z;X0q;AjH;0p7g$7z$U66Pfx3%=Mb=x`sb0-@+_n(RHE}P3o+P!Z`
z&2CsY+BxKDx=1WxftSQFWEyHS9`l%Js4^;OCVM}(r9EA(uD;ga4nMmyBhR0leIM5M
z+5R;(Gke|K`a0V>U2ZO}mzc*%vW6iUCDbB$%Jds>kto*~4m-MEKR<^GoDQvPFX~~B
zdp?gdA72`mwDArzbAZnEpNpTJp465)jJ_@9o1Nl=sfP{7q>;zJM$lJ6XP4gBzj=KS
z+>La$eSd>_#uKy!)L!88~RBlQYh3zOHm)Ff|zKxpzXQ%fohyZK{C
zeyG~6=#9F2VAAh(G@Sf9*?vfv^zXBaF`Tk6BI%OpsCUa@z+^Hkq-qVWfxa-rXNha2
z7w>2WtR&qq(r@)}xWyD%M@fohhc|GgNl%fCxucG=bHKbPe=(m#xP*d}EEjzB$P7KI
zMzdj%sf$E$rihQW95y6uWcO2<(ZL@FNm`jsW;F8wz+6dxpwzbgQ_?1Tug!;bG!7i}
zNIiA1MsyrrK$qX1?Tk|DOp|5QupTc8F~?PuEi2+1ql1o@ZvR}U7jt{z!{woM#M&j6
z6^>(@nob{6N=?3!#)|EeU>p-R*9e7jU`d2XutJ&0n!3gvQzNHEX%>F5GZ8f!xk7*<
z&q$$J;TYw7osc=$I2yo{nrvHtcv<0ru$?+jaJ$_tV*LuS6t*KKnL=ZJ(e;8Gy~h~H
zA&IFEGssWQ%%uB>QB2NL$2qRrWyJcS=$i&e=1v}hg+Fw#O{Pyq9ZjH?c?x#kL%`_#
zoM?0-Ebvx%Xkl;1kMCpLLWlh}4EY(~7ZE{Y;Z?d)Ek(&?e&)f-oPU`Yf%R3jRPa?A
zspD+N=-b^FpiNYg>StgUt}s?b&eb82ZD%ypr;Wv)DF+*?kEl1)bRlj>$(j%p#-T2|
zCq8;`FCiA3svu4=j1gl?mIB^yLEEN&V7U`j=blB9Cqcp_84s|+K&FU7^`Sv$G_cc3
z=8HXgP%FJN-5Ld-5xvV9)w*&9Uq}e<=8{^{kSU^j;Btq)S|pKACYwsGkAFPh*xlL3
z7?IH%A*8;N$(8ZUpvouYPd-G>^sS+0Ft`!emBNYqeA#lSY1-R#FxVv8^2HSx<6xSn
zQB)8VdZ^*A#%p7Rj2K-pczFMH>x3ETR=Tc2qaV_@%W)9A{7`PI_h*Xh;OvW@Gr$s~SM23ZvBzTz>wv_iry)=Vnjx8zV7{SR+-VpWVA&E`BU%DOJ>X%0f
zC~qY+MV?X>42=>O=!ty3HqIi2x^>Zh7n?GLdY3E?wJpUjtL7AG8xv(>Ih@iMsT!5!
zDl}`4Ar$In^-Y=q*PC{!lu2dqSX&g6KaCU0hUCgMdWGn0iNE^|#ussN(H#*`bwEc>
z=+yZ5IeaJayS%gh{>N?jd@zmfOzblP9i3kJ(=H0l{C<=6#}lE-oY
z-I8D&6WBM4#Z>|)s%>Ud3WwhINvC?^jJdJ1I}Nd%&p@@vGRco-!e%4P;6Nz!USbr4Df
z&84R0lsQfkggEVwt}~(4pfL*SU;-0Dv5b`!_$thJxA1-)>STwZ{*#KJugwv#*aAk4iZg-QzE(C(D5{P*aZQG$M<^v?hAy~dpg@&TfWV&md)PcOuae=@9$kBl-_+;
z{6A}lHP3+FKEKz`_xG2N!^6Yfe}~^rmp8!I;oHFPva6;>N5`fsI{GpCvg;9%0MF-f
zZpUF&JbF(s&!KJY`|#sya&vQXvd3T+WOO%pr$!?F6wuUmO!x-r9jz1p`kV0T$J^m@
zVzuWp8L|k{vA(O#4^Sr2b=|X*Px$2n_^j!H?6bZ8vG4&56uqc_V(!^{@A>)oU+RAf
zKsny}N3jOnn=;y7*Ly!*?H|{CpDpZW+b1_Ah##w{{rjM+gEn>_+-WT1_kZ#yRNy@b
zoB68}eD7-2(a_PMwWW2#p~2~g)tbiJmYprLW8TxTv9oK*hRge{06bc0aB;Pa^IWpB
zx_BY(-q+z&cK_`B7=C<`8>{W^*|9+A4}+<;_v(X%b{_lLH;)vzh>fwuFyP^GU#7O_`>D`z=0cK(8enc`)(Ea{!Ae02@
zbmLxPY%<-awoP;XZwnLAuKcIN*5d6WaH4Jh4
z=d|?z^j|7t>;ZkENz$Q$Qp$!5qg7N?Y+1flRYhxJE_WfhdLd~^Xx089Pm=PX99roR
z4{xh-uC@vn8rFK&c|~C?ZLe%{hSA6cY47ASl7-P>^$IR#BD|_*c~qN}pce%b%YLR!
zP&?f6RPYY8QA@;FSi3xO7P@N{iiVbhwCY*8%G5=o%laDyWDl}DYsi?CapB1_<@<+{
zp(jv=q2v?^QuWjU-(I=n%wA2yVY7}qay5y=#MQvCM$L?bp}p=3gS)0#OjUebX4T{9
z6>I7HxZr%S&~Pedh*Vh8kPs_jB)1rnLuBL#a^!p6`v}GQB09?A;Zv|PmnihXAf!kt
zb%ao1Q4uH_WD>r@6z9?U5R}PafhMRa5Mr*>KP=N=L{Q$KVSy}Z&^gG)31T6K?jgke
zS4=#jNXA%nN@6N#p#=(2Bz4%Lg9YVitZb#S=6N{eEg^(d9>h{1^Ki446qZ5#qoJFT
z@kpf{bb8RKGD+kCtj2M?q5Q;#4FiLi53EVz(Q92ltvIi
zNU5w3=1fVadm|IGtn~4oBooZ+-*Vr7$<0;j$fy`xvCXm|n|z(u1^K!4v(3vw6IsD}
zvf5S)WKnX3)+}nm1?Gpzg5@X2bx$LitI42v*b#ShfqiphMbpdhREOD^4~U({29AZu
zVF{#g#K$5V|3E$TWKKP+~!s
zKxrtG$d^e?t6;7wr_zvXTh1%Qw2X;S$&(j}&Hf#JuP;PyNQ}gW1czW1Cx2tGV&c-I
zomhcujQab-Dr-C!p`spKgS3wb&4hP~w=&YDuR7oCbXC*J1L|H_?{o)F
z$Hv2^4r8A@Y

[Xen-devel] [PATCH 1/4] docs: convert STAO from odt to fodt

Fixes 140b31a8de ("Add STAO spec to docs/misc")

Signed-off-by: Olaf Hering 
---
 docs/misc/status-override-table-spec.fodt | 707 ++
 1 file changed, 707 insertions(+)

diff --git a/docs/misc/status-override-table-spec.fodt 
b/docs/misc/status-override-table-spec.fodt
new file mode 100644
index 00..a831b7323b
--- /dev/null
+++ b/docs/misc/status-override-table-spec.fodt
@@ -0,0 +1,707 @@
+
+
+http://www.w3.org/1999/xlink"; 
xmlns:dc="http://purl.org/dc/elements/1.1/"; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML"; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:config="urn:oas
 is:names:tc:opendocument:xmlns:config:1.0" 
xmlns:ooo="http://openoffice.org/2004/office"; 
xmlns:ooow="http://openoffice.org/2004/writer"; 
xmlns:oooc="http://openoffice.org/2004/calc"; 
xmlns:dom="http://www.w3.org/2001/xml-events"; 
xmlns:xforms="http://www.w3.org/2002/xforms"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xmlns:rpt="http://openoffice.org/2005/report"; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xhtml="http://www.w3.org/1999/xhtml"; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#"; 
xmlns:officeooo="http://openoffice.org/2009/office"; 
xmlns:tableooo="http://openoffice.org/2009/table"; 
xmlns:drawooo="http://openoffice.org/2010/draw"; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:formx="urn:openoffice:names:
 experimental:ooxml-odf-interop:xmlns:form:1.0" 
xmlns:css3t="http://www.w3.org/TR/css3-text/"; office:version="1.2" 
office:mimetype="application/vnd.oasis.opendocument.text">
+ LibreOffice/5.2.3.3$Linux_X86_64 
LibreOffice_project/20m0$Build-3
+ 
+  
+   0
+   2342
+   17861
+   7788
+   true
+   false
+   
+
+ view2
+ 3041
+ 3464
+ 2342
+ 0
+ 20202
+ 7786
+ 1
+ 1
+ false
+ 228
+ false
+
+   
+  
+  
+   false
+   true
+   true
+   true
+   0
+   true
+   true
+   
+   false
+   false
+   true
+   false
+   true
+   false
+   true
+   true
+   true
+   true
+   true
+   false
+   true
+   true
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   
+   false
+   false
+   true
+   false
+   true
+   
+   true
+   false
+   true
+   false
+   false
+   803236
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   false
+   0
+   false
+   true
+   high-resolution
+   false
+   false
+   false
+   false
+   true
+   true
+   
+   true
+   false
+   false
+   false
+   true
+   false
+   false
+   false
+   
+   true
+   true
+   720138
+   true
+   1
+   true
+   false
+   false
+   0
+   false
+   false
+   
+   
+   false
+  
+ 
+ 
+  
+   http://openoffice.org/2004/office"; 
xmlns:xlink="http://www.w3.org/1999/xlink"/>
+  
+ 
+ 
+  
+  
+  
+  
+  
+  
+  
+  
+ 
+ 
+  
+   
+   
+
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+  
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+  
+  
+  
+  
+  
+   
+  
+ 
+ 
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+   
+
+   
+   
+
+   
+  
+ 
+ 
+  
+   
+
+   
+   
+
+   
+  
+ 
+ 
+  
+   
+
+
+
+
+   
+   ACPI Specification for Status Override 
Table
+   
+   Specification: LINARO-0002
+   Authors: Al 
Stone

[Xen-devel] [PATCH 2/4] docs: convert XENV from odt to fodt

Fixes c33b5f013d ("Add XENV to docs/misc")

Signed-off-by: Olaf Hering 
---
 docs/misc/xen-env-table-spec.fodt | 852 ++
 1 file changed, 852 insertions(+)

diff --git a/docs/misc/xen-env-table-spec.fodt 
b/docs/misc/xen-env-table-spec.fodt
new file mode 100644
index 00..ccde7a6981
--- /dev/null
+++ b/docs/misc/xen-env-table-spec.fodt
@@ -0,0 +1,852 @@
+
+
+http://www.w3.org/1999/xlink"; 
xmlns:dc="http://purl.org/dc/elements/1.1/"; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML"; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:config="urn:oas
 is:names:tc:opendocument:xmlns:config:1.0" 
xmlns:ooo="http://openoffice.org/2004/office"; 
xmlns:ooow="http://openoffice.org/2004/writer"; 
xmlns:oooc="http://openoffice.org/2004/calc"; 
xmlns:dom="http://www.w3.org/2001/xml-events"; 
xmlns:xforms="http://www.w3.org/2002/xforms"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xmlns:rpt="http://openoffice.org/2005/report"; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xhtml="http://www.w3.org/1999/xhtml"; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#"; 
xmlns:officeooo="http://openoffice.org/2009/office"; 
xmlns:tableooo="http://openoffice.org/2009/table"; 
xmlns:drawooo="http://openoffice.org/2010/draw"; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:formx="urn:openoffice:names:
 experimental:ooxml-odf-interop:xmlns:form:1.0" 
xmlns:css3t="http://www.w3.org/TR/css3-text/"; office:version="1.2" 
office:mimetype="application/vnd.oasis.opendocument.text">
+ LibreOffice/5.2.3.3$Linux_X86_64 
LibreOffice_project/20m0$Build-3
+ 
+  
+   0
+   2342
+   17861
+   7788
+   true
+   false
+   
+
+ view2
+ 3041
+ 3464
+ 2342
+ 0
+ 20202
+ 7786
+ 1
+ 1
+ false
+ 228
+ false
+
+   
+  
+  
+   false
+   true
+   true
+   true
+   0
+   true
+   true
+   
+   false
+   false
+   true
+   false
+   true
+   false
+   true
+   true
+   true
+   true
+   true
+   false
+   true
+   true
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   
+   false
+   false
+   true
+   false
+   true
+   
+   true
+   false
+   true
+   false
+   false
+   1430233
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   false
+   0
+   false
+   true
+   high-resolution
+   false
+   false
+   false
+   false
+   true
+   true
+   
+   true
+   false
+   false
+   false
+   true
+   false
+   false
+   false
+   
+   true
+   true
+   1362860
+   true
+   1
+   true
+   false
+   false
+   0
+   false
+   false
+   
+   
+   false
+  
+ 
+ 
+  
+   http://openoffice.org/2004/office"; 
xmlns:xlink="http://www.w3.org/1999/xlink"/>
+  
+ 
+ 
+  
+  
+  
+  
+  
+  
+  
+  
+ 
+ 
+  
+   
+   
+
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+  
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+  
+  
+  
+  
+  
+   
+  
+ 
+ 
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+   
+
+   
+   
+
+   
+  
+ 
+ 
+  
+   
+

Re: [Xen-devel] STAO spec in xen.git

On Tue, Jan 17, Stefano Stabellini wrote:

> On Tue, 17 Jan 2017, Olaf Hering wrote:
> > On Fri, Jan 13, Julien Grall wrote:
> > 
> > > Regarding the format. Does ODT will allow git to do proper diff?
> > 
> > There is flat ODT, "Safe as ..." and pick the better format from the 
> > pulldown menu.
> 
> Sounds like a good idea. Can you submit a patch?

Done, see 'docs: convert from binary to ASCII'.

For some reason results of 'git rm' are not noticed by
get-maintainer.pl, see xen-devel for a copy of the removal.

Olaf

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

Re: [Xen-devel] [PATCH biosdevname]: handle dom0 on AMD systems

Hello,

and ping.

Olaf


On Wed, Aug 17, Olaf Hering wrote:

> Starting with xen-4.7 cpuid() will return with the hypervisor bit set
> in a dom0 when running on an AMD system. As a result biosdevname
> thinks it runs in a guest and does nothing. Detect a dom0 by looking
> into xenfs. This works with classic xenlinux based kernels and with
> pvops based kernels.
> 
> Signed-off-by: Olaf Hering 
> 
> ---
>  src/bios_dev_name.c |   31 +++
>  1 file changed, 31 insertions(+)
> 
> --- a/src/bios_dev_name.c
> +++ b/src/bios_dev_name.c
> @@ -133,6 +133,31 @@ cpuid (u_int32_t eax, u_int32_t ecx)
>  }
>  
>  /*
> +  Starting with xen-4.7 cpuid will return with the hypervisor bit set
> +  on AMD systems. This breaks biosdevname and network interface names.
> +  Instead of relying on cpuid check for dom0 in xenfs.
> +*/
> +static int
> +running_in_dom0(void)
> +{
> +size_t len = 0;
> +char buf[16];
> +FILE *f = fopen("/proc/xen/capabilities", "r");
> +
> +if (!f)
> +return 0;
> +memset(buf, 0, sizeof(buf));
> +len = fread(&buf, 1, sizeof(buf) - 1, f);
> +fclose(f);
> +while(len && --len && len < sizeof(buf)) {
> +if (buf[len] == '\n')
> +buf[len] = '\0';
> +}
> +len = !strcmp("control_d", buf);
> +return len;
> +}
> +
> +/*
>Algorithm suggested by:
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
>  */
> @@ -144,7 +171,11 @@ running_in_virtual_machine (void)
>  
>  ecx = cpuid (eax, ecx);
>  if (ecx & 0x8000U)
> +{
> +   if (running_in_dom0())
> +   return 0;
> return 1;
> +}
>  return 0;
>  }
>  




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

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

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  909c219944e944f086ec0a89938a7397e2aa4cb0
baseline version:
 xen  62c7b99a10793738db1007f6750cf79057625f2c

Last test of basis   105788  2017-02-14 11:01:40 Z0 days
Testing same since   105792  2017-02-14 15:01:05 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=909c219944e944f086ec0a89938a7397e2aa4cb0
+ . ./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 
909c219944e944f086ec0a89938a7397e2aa4cb0
+ branch=xen-unstable-smoke
+ revision=909c219944e944f086ec0a89938a7397e2aa4cb0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x909c219944e944f086ec0a89938a7397e2aa4cb0 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

2017-02-14 Thread Tim Deegan

At 16:04 + on 14 Feb (1487088291), Andrew Cooper wrote:
> Hmm ok.  With the other bugfix of not dropping the first line, this hunk
> is now simply:
> 
> @@ -504,7 +505,7 @@ void recalculate_cpuid_policy(struct domain *d)
>  
>  p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>  p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
> -d->arch.paging.gfn_bits + PAGE_SHIFT);
> +paging_max_paddr_bits(d));
>  p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
>  (p->basic.pae || p->basic.pse36) ? 36 :
> 32);

That looks good to me.  Reviewed-by: Tim Deegan 

> >> @@ -360,6 +361,21 @@ void paging_dump_vcpu_info(struct vcpu *v);
> >>  int paging_set_allocation(struct domain *d, unsigned int pages,
> >>bool *preempted);
> >>  
> >> +/* Maxphysaddr supportable by the paging infrastructure. */
> >> +static inline unsigned int paging_max_paddr_bits(const struct domain *d)
> >> +{
> >> +unsigned int bits = paging_mode_hap(d) ? hap_paddr_bits : paddr_bits;
> >> +
> >> +if ( !IS_ENABLED(BIGMEM) && paging_mode_shadow(d) &&
> >> + (!is_pv_domain(d) || opt_allow_superpage) )
> >> +{
> >> +/* Shadowed superpages store GFNs in 32-bit page_info fields. */
> >> +bits = min(bits, 32U + PAGE_SHIFT);
> >> +}
> >> +
> >> +return bits;
> >> +}
> > Does this really need to be an inline function? With the overall goal
> > of not including every header everywhere, I particularly dislike the
> > need to include xen/kconfig.h here for things to build.
> 
> It is not on a critically path, but it seems wasteful to force something
> this small to be out of line.

It could be a macro, too.  FWIW I agree with you that a static inline
is best.

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt


Hi,

Ping? As Ian mentioned earlier, without this series it is not possible 
to build Xen tools for ARM64 in osstest.


Cheers,

On 02/08/2017 07:50 PM, Julien Grall wrote:

Hi,

On 24/01/17 22:19, David Scott wrote:



On 24 Jan 2017, at 11:35, Ian Jackson  wrote:

Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no 
ocamlopt"):

Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
package lacks ocamlopt.

...

This does not actually fix the real problem.  I'm unsure how to fix it
properly, for the following reasons:


Can I have some input from ocaml folks ?

The first ARM64 boxes in the Xen Project test lab are in principle now
online, but this bug is stopping osstest actually getting as far as
trying to boot Xen.


ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
`ocamlc'.  However our ocaml Makefiles seem to explicitly call
$(OCAMLOPT) in some places and and $(OCAMLC) in others.


I’m terrible at reading m4 and am really bad with autoconf so I may have
got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`? Where

`ocamlc`: outputs bytecode, and is a bytecode executable itself
`ocamlc.opt`: outputs bytecode, and is a native code executable itself
`ocamlopt`: outputs native code, and is a bytecode executable itself
`ocamlopt.opt`: outputs native code, and is a native code executable itself

Both `ocamlc` and `ocamlc.opt` should be interchangeable: same command-line
arguments, exactly the same output. Same for `ocamlopt` and `ocamlopt.opt`.

I _think_ the m4 is looking for `ocamlc.opt` because it’s an optimised native
(therefore faster) version of `ocamlc`. It should be fine to set `OCAMLC`
to either.

The tools/ocaml/Makefile.rules does contain rules for both bytecode outputs
(e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe *.cmi
can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).

I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it refers
directly to *.cmxa files which are native-code only— I don’t see how that
could work for bytecode outputs.

Do you have a link to the build failure?


Here a link for the build failure:

http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log

Cheers,



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 2/4] build/printf: fix incorrect format specifiers

On Tue, Feb 14, 2017 at 12:30:55PM +, Roger Pau Monne wrote:
> The following incorrect format specifiers and incorrect number of parameters
> passed to printf like functions are reported by clang:
> 
> mce.c:601:18: error: data argument not used by format string 
> [-Werror,-Wformat-extra-args]
>  smp_processor_id());
>  ^
> 
> xenpm.c:102:23: error: data argument not used by format string 
> [-Werror,-Wformat-extra-args]
> what, argv[argc > 1]);
>   ^
> 
> libxl_internal.c:25:69: error: data argument not used by format string
>   [-Werror,-Wformat-extra-args]
> libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
> ^
> libxl_internal.c:24:17: note: expanded from macro 'L'
>   func, (unsigned long)nmemb, (unsigned long)size
> ^
> libxl_internal.c:26:21: error: data argument not used by format string
>   [-Werror,-Wformat-extra-args]
> fprintf(stderr, L);
> ^
> libxl_internal.c:24:17: note: expanded from macro 'L'
>   func, (unsigned long)nmemb, (unsigned long)size
> ^
> 
> This patch contains the fixes for them and enables -Wformat for clang.
> 
> Signed-off-by: Roger Pau Monné 
> Acked-by: Andrew Cooper 
> ---
> NB: FWIW, there's a way to disable extra arguments checks
> (-Wno-format-extra-args), that would prevent us from having to apply some of
> the changes here. However, given that there are not that many occurrences, I
> would rather leave the full checks of Wformat enabled.
> 
> NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only
> against the components that build on FreeBSD (ie: no qemu-trad, and certainly
> no blktap).
> ---

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

These two patches don't apply anymore. Please rebase.

Wei.

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

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document