date:20160518

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

2016-05-18 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 81c1460695f783a3f91431b2babea623556a7f5d
baseline version:
 ovmf 720eea6aa80b48acb05c1adc0f835e849d71da97

Last test of basis94541  2016-05-18 05:59:47 Z1 days
Testing same since94559  2016-05-18 20:43:21 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Ma, Maurice 
  Maurice Ma 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=81c1460695f783a3f91431b2babea623556a7f5d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
81c1460695f783a3f91431b2babea623556a7f5d
+ branch=ovmf
+ revision=81c1460695f783a3f91431b2babea623556a7f5d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x81c1460695f783a3f91431b2babea623556a7f5d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'

Re: [Xen-devel] [PATCH] AMD IOMMU: Introduce support for IVHD block type 11h

2016-05-18 Thread Suravee Suthikulpanit


Hi Jan,

On 05/17/2016 09:25 AM, Jan Beulich wrote:

On 13.05.16 at 21:54,  wrote:

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
[...]
@@ -901,7 +911,7 @@ static int __init parse_ivhd_block(const struct 
acpi_ivrs_hardware *ivhd_block)
  ivhd_block->header.length, block_length, iommu);
  break;
  default:
-AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
+AMD_IOMMU_DEBUG("IVHD Error: %s: Invalid Device Type!\n", 
__func__);


Why?


There are some duplicated error message (in get_last_bdf_ivhd() and 
parse_ivhd_block(). So, I just want to differentiate them a bit. But 
this is not a big deal. I can just get rid of this change.



[...]
+{
+AMD_IOMMU_DEBUG("IVRS Block: Found type %#x flags %#x len %#x id 
%#x\n",
+ivrs_block->type, ivrs_block->flags,
+ivrs_block->length, ivrs_block->device_id);
+if ( ivrs_block->type > IVHD_HIGHEST_SUPPORT_TYPE )
+break;


Is there a requirement for the table elements to appear in numerical
order?


That is not in the spec. Although it seems to the convention.


And anyway - this if() appears to be redundant with the
enclosing one.


I am not sure what you mean by this comment. Could you please elaborate?




+int __init amd_iommu_get_supported_ivhd_type(void)
+{
+if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
+return -EPERM;


This check appears out of the blue, and isn't being mentioned in
the description. Best would probably be to split it out, but at the
very least it needs to be (briefly) explained.


This logic was actually duplicated from the 
amd_iommu_update_ivrs_mapping_acpi(). I believe this was added by the


commit 992fdf6f46252a459c6b1b8d971b2c71f01460f8
honor ACPI v4 FADT flags

It might make more sense to pull this out to just check once in the 
amd_iommu_init() along with adding some explanation.



@@ -1233,8 +1234,11 @@ int __init amd_iommu_init(void)
   amd_sp5100_erratum28() )
  goto error_out;

-ivrs_bdf_entries = amd_iommu_get_ivrs_dev_entries();
+ivhd_type = amd_iommu_get_supported_ivhd_type();
+if ( !ivhd_type )
+goto error_out;


Is the ! here meant to catch errors? The function returns -E...
values to indicate errors ...


Sorry, my bad. I'll fix this.

Thanks,
Suravee

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

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

2016-05-18 Thread Jan Beulich

>>> "Xu, Quan"  05/19/16 3:35 AM >>>
>On May 19, 2016 8:33 AM, Tian, Kevin  wrote:
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: Wednesday, May 18, 2016 11:05 PM
>> > >>> On 18.05.16 at 14:53,  wrote:
>> > The patch can imo remain as is only if the new default timeout is
>> > large enough for all possible cases (including those users who are
>> > adventurous enough to turn on ATS).
>
>I only have an ATS device (MYRICOM Inc. Myri-10G Dual-Protocol NIC). 1 ms is 
>large enough for invalidation so far.
>Any suggestion for this new default timeout?

Unless you have theoretical proof that a lower than the current value would
suffice (as you do for the IOMMU side flushes), I think the default needs to
remain the same as it is right now (which iirc is already _much_ lower than
the real theoretical one).

>> A single default value for both IOMMU-side and device-side is anyway not
>> optimal. What about introducing a new knob e.g. vtd_qi_device_timeout
>> specifically for device-side flush while using vtd_qi_timeout for other 
>> places? If
>> device-side timeout is not specified, it is then default to vtd_qi_timeout.

There should imo be a single command line option, allowing for two values to be
passed (e.g. comma-separated).

Jan


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

Re: [Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

2016-05-18 Thread Jan Beulich

>>> Suravee Suthikulpanit  05/19/16 7:22 AM >>>
>On 05/16/2016 03:19 AM, Paul Durrant wrote:
>> >From:suravee.suthikulpa...@amd.com
>> >Sent: 13 May 2016 20:37
>>> >The guest_iommu_init() is currently called by the following code path:
>>> >
>>> > arch/x86/domain.c: arch_domain_create()
>>> >   ]- drivers/passthrough/iommu.c: iommu_domain_init()
>>> > |- drivers/passthrough/amd/pci_amd_iommu.c:
>>> >amd_iommu_domain_init();
>>> >   |- drivers/passthrough/amd/iommu_guest.c: guest_iommu_init()
>>> >
>>> >At this point, the hvm_domain_initialised() has not been
>>> >called. So register_mmio_handler(), in guest_iommu_init(), silently fails.
>>> >This patch moves the call to guest_iommu_init/destroy() into
>>> >the svm_domain_intialise/_destroy() instead.
>>> >
>> That seems wrong. You're taking a call that currently comes via a jump 
>> table, i.e. an abstraction layer, and calling it directly. Is it possible, 
>> instead, to move the call to iommu_domain_init() later in 
>> arch_domain_create()? It seems odd, to me at least, that it's done before 
>> hvm_domain_initialise() anyway.
>
>Good point. I think I should be able to move iommu_domain_init() call to 
>go after hvm_domain_initialise() as the following.
>
>--- a/xen/arch/x86/domain.c
>+++ b/xen/arch/x86/domain.c
>@@ -625,24 +625,21 @@ int arch_domain_create(struct domain *d, unsigned 
>int domcr_flags,
>
>if ( (rc = init_domain_irq_mapping(d)) != 0 )
>goto fail;
>-
>-if ( (rc = iommu_domain_init(d)) != 0 )
>-goto fail;
>}
>spin_lock_init(&d->arch.e820_lock);
>
>if ( has_hvm_container_domain(d) )
>{
>if ( (rc = hvm_domain_initialise(d)) != 0 )
>-{
>-iommu_domain_destroy(d);
>goto fail;
>-}
>}
  >else
>/* 64-bit PV guest by default. */
>d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>
>+if ( !is_idle_domain(d) && (rc = iommu_domain_init(d)) != 0 )
>+goto fail;

This would in the error case fail to undo what hvm_domain_initialise() did.
There was a fix very recently dealing with a similar issue. There really
shouldn't be anything that can fail after hvm_domain_initialise(). And I also
can't see why both of you think iommu_domain_init() has to come later -
that's a function affecting not just HVM guests.

Jan


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

[Xen-devel] [PATCH v2] xen: add steal_clock support on x86

2016-05-18 Thread Juergen Gross

The pv_time_ops structure contains a function pointer for the
"steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
uses its own mechanism to account for the "stolen" time a thread wasn't
able to run due to hypervisor scheduling.

Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen and remove the x86 Xen
hack.

Signed-off-by: Juergen Gross 
---
V2: remove the x86 do_stolen_accounting() hack
---
 arch/arm/xen/enlighten.c| 17 ++---
 arch/x86/xen/time.c | 44 ++--
 drivers/xen/time.c  | 19 +++
 include/linux/kernel_stat.h |  1 -
 include/xen/xen-ops.h   |  1 +
 kernel/sched/cputime.c  | 10 --
 6 files changed, 24 insertions(+), 68 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..9163b94 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
 
-static unsigned long long xen_stolen_accounting(int cpu)
-{
-   struct vcpu_runstate_info state;
-
-   BUG_ON(cpu != smp_processor_id());
-
-   xen_get_runstate_snapshot(&state);
-
-   WARN_ON(state.state != RUNSTATE_running);
-
-   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
 static void xen_read_wallclock(struct timespec64 *ts)
 {
u32 version;
@@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
 
register_cpu_notifier(&xen_cpu_notifier);
 
-   pv_time_ops.steal_clock = xen_stolen_accounting;
-   static_key_slow_inc(¶virt_steal_enabled);
+   xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
 
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6be31df 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -11,8 +11,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -31,44 +29,6 @@
 
 /* Xen may fire a timer up to this many ns early */
 #define TIMER_SLOP 10
-#define NS_PER_TICK(10LL / HZ)
-
-/* snapshots of runstate info */
-static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
-
-/* unused ns of stolen time */
-static DEFINE_PER_CPU(u64, xen_residual_stolen);
-
-static void do_stolen_accounting(void)
-{
-   struct vcpu_runstate_info state;
-   struct vcpu_runstate_info *snap;
-   s64 runnable, offline, stolen;
-   cputime_t ticks;
-
-   xen_get_runstate_snapshot(&state);
-
-   WARN_ON(state.state != RUNSTATE_running);
-
-   snap = this_cpu_ptr(&xen_runstate_snapshot);
-
-   /* work out how much time the VCPU has not been runn*ing*  */
-   runnable = state.time[RUNSTATE_runnable] - 
snap->time[RUNSTATE_runnable];
-   offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
-
-   *snap = state;
-
-   /* Add the appropriate number of ticks of stolen time,
-  including any left-overs from last time. */
-   stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
-
-   if (stolen < 0)
-   stolen = 0;
-
-   ticks = iter_div_u64_rem(stolen, NS_PER_TICK, &stolen);
-   __this_cpu_write(xen_residual_stolen, stolen);
-   account_steal_ticks(ticks);
-}
 
 /* Get the TSC speed from Xen */
 static unsigned long xen_tsc_khz(void)
@@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void 
*dev_id)
ret = IRQ_HANDLED;
}
 
-   do_stolen_accounting();
-
return ret;
 }
 
@@ -431,6 +389,8 @@ static void __init xen_time_init(void)
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
 
+   xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
 }
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 7107842..6648a78 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -75,6 +75,15 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
 }
 
+static u64 xen_steal_clock(int cpu)
+{
+   struct vcpu_runstate_info state;
+
+   BUG_ON(cpu != smp_processor_id());
+   xen_get_runstate_snapshot(&state);
+   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
+}
+
 void xen_setup_runstate_info(int cpu)
 {
struct vcpu_register_runstate_memory_area area;
@@ -86,3 +95,13 @@ void xen_setup_runstate_info(int cpu)
BUG();
 }
 
+void __init xen_time_setup_guest(void)
+{
+   pv_time_ops.steal_clock = xen_steal_clock;
+
+   static_key_slow_inc(¶virt_steal_enabled);
+   /*
+* We can't set paravirt_steal_rq_enabled as this would require the
+* capability to read another

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Juergen Gross

On 18/05/16 18:13, Boris Ostrovsky wrote:
> On 05/18/2016 12:00 PM, Juergen Gross wrote:
>> On 18/05/16 17:53, Boris Ostrovsky wrote:
>>> On 05/18/2016 11:45 AM, David Vrabel wrote:
 On 18/05/16 16:42, Juergen Gross wrote:
> On 18/05/16 17:25, Boris Ostrovsky wrote:
>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>>> On 18/05/16 16:46, Boris Ostrovsky wrote:
 On 05/18/2016 08:15 AM, Juergen Gross wrote:
>  }
>  
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> +  * We can't set paravirt_steal_rq_enabled as this would require 
> the
> +  * capability to read another cpu's runstate info.
> +  */
> +}
 Won't we be accounting for stolen cycles twice now --- once from
 steal_account_process_tick()->steal_clock() and second time from
 do_stolen_accounting()?
>>> Uuh, yes.
>>>
>>> I guess I should rip do_stolen_accounting() out, too? 
>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
> This is easy to accomplish. :-)
>>>
>>> I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
>>> neither) and in their case that's presumably because stealing accounting
>>> is a CPUID bit, i.e. it might not be supported. In Xen case we always
>>> have this interface.
>> So they added it later and the default is to keep the old behavior.
>>
>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>> maybe check for paravirt_steal_enabled.
> Is this really a sensible thing to do? There is a mechanism used by KVM
> to do the stolen accounting. I think we should use it instead of having
> a second implementation doing the same thing in case the generic one
> isn't enabled.
 I agree.

 Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
 don't think it's essential (or is it?).
>>> Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
>>> support yet.
>> I think the patch is still useful. It is reducing code size and
>> it is removing arch-specific Xen-hack(s). With the patch Xen's
>> solution for arm and x86 is common and the same as for KVM. Adding
>> paravirt_steal_rq_enabled later will be much easier as only one
>> function needs substantial modification.
> 
> I am not arguing against having a patch that will remove
> do_stolen_accounting(). I was responding to David's statement about
> whether we need to select CONFIG_PARAVIRT_TIME_ACCOUNTING, and I am not
> sure this is necessary since steal_account_process_tick() (that will
> take case of things that do_stolen_accounting() currently does) doesn't
> need it.

Aah, okay. That's a good reason to not add the Kconfig stuff.

> (And if it is indeed needed --- can we have Xen's Kconfig select it
> instead of "default y if XEN" ?)

I've verified that CONFIG_PARAVIRT_TIME_ACCOUNTING is _not_ needed.
I've removed it from .config and used my patch with
do_stolen_accounting() removed. In an overcommitted guest (4 vcpus on 2
physical cpus) running a parallel make top showed near 50% stolen time.


Juergen

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

Re: [Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

2016-05-18 Thread Suravee Suthikulpanit


+ Keir (since he added this code originally).

On 05/16/2016 03:19 AM, Paul Durrant wrote:

-Original Message-
>From:suravee.suthikulpa...@amd.com
>[mailto:suravee.suthikulpa...@amd.com]
>Sent: 13 May 2016 20:37
>To:xen-devel@lists.xen.org; George Dunlap;jbeul...@suse.com
>Cc: Paul Durrant; Suravee Suthikulpanit; Suravee Suthikulpanit
>Subject: [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after
>initialized HVM domain
>
>From: Suravee Suthikulpanit
>
>The guest_iommu_init() is currently called by the following code path:
>
> arch/x86/domain.c: arch_domain_create()
>   ]- drivers/passthrough/iommu.c: iommu_domain_init()
> |- drivers/passthrough/amd/pci_amd_iommu.c:
>amd_iommu_domain_init();
>   |- drivers/passthrough/amd/iommu_guest.c: guest_iommu_init()
>
>At this point, the hvm_domain_initialised() has not been
>called. So register_mmio_handler(), in guest_iommu_init(), silently fails.
>This patch moves the call to guest_iommu_init/destroy() into
>the svm_domain_intialise/_destroy() instead.
>

That seems wrong. You're taking a call that currently comes via a jump table, 
i.e. an abstraction layer, and calling it directly. Is it possible, instead, to 
move the call to iommu_domain_init() later in arch_domain_create()? It seems 
odd, to me at least, that it's done before hvm_domain_initialise() anyway.

   Paul



Good point. I think I should be able to move iommu_domain_init() call to 
go after hvm_domain_initialise() as the following.


diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 9d43f7b..ac289b6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -625,24 +625,21 @@ int arch_domain_create(struct domain *d, unsigned 
int domcr_flags,


 if ( (rc = init_domain_irq_mapping(d)) != 0 )
 goto fail;
-
-if ( (rc = iommu_domain_init(d)) != 0 )
-goto fail;
 }
 spin_lock_init(&d->arch.e820_lock);

 if ( has_hvm_container_domain(d) )
 {
 if ( (rc = hvm_domain_initialise(d)) != 0 )
-{
-iommu_domain_destroy(d);
 goto fail;
-}
 }
 else
 /* 64-bit PV guest by default. */
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;

+if ( !is_idle_domain(d) && (rc = iommu_domain_init(d)) != 0 )
+goto fail;
+
 if ( (rc = psr_domain_init(d)) != 0 )
 goto fail;

-

This was added in the commit 66a882392272346ce1d0bc5a26568894f450a7c0,
and only says initialization cleanup and bugfix. I am not sure what bug 
was reported at the time. Anyone has an idea?


Suravee

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

[Xen-devel] [xen-4.6-testing test] 94548: tolerable FAIL - PUSHED

2016-05-18 Thread osstest service owner

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 93932
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932

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

version targeted for testing:
 xen  aa3cdb6cb666400768950503863b7c3cf508f581
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z9 days
Failing since 94000  2016-05-10 18:10:33 Z8 days   13 attempts
Testing same since94548  2016-05-18 11:48:19 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kyle J. Temkin 
  Kyle Temkin 
  Shanker Donthineni 
  Stefano Stabellini 
  Stefano Stabellini 
  Vikram Sethi 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvops

[Xen-devel] [qemu-upstream-4.3-testing test] 94555: trouble: blocked/broken

2016-05-18 Thread osstest service owner

flight 94555 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94555/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  102 days
Testing same since93977  2016-05-10 11:09:16 Z8 days   22 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 test-amd64-amd64-pairblo

[Xen-devel] [PATCH] xenalyze: fix a spurious newline

2016-05-18 Thread Dario Faggioli

in dump mode, when tracing context switches.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/xentrace/xenalyze.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index b949986..01ead8b 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7655,7 +7655,7 @@ void sched_process(struct pcpu_info *p)
 printf(", was runnable for %u.%uus, ", r->rsince / 1000,
r->rsince % 1000);
 if ( r->slice > 0 )
-printf("next slice %u.%uus\n", r->slice / 1000,
+printf("next slice %u.%uus", r->slice / 1000,
r->slice % 1000);
 printf("\n");
 }


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

[Xen-devel] [PATCH for 4-7] xenalyze: fix a spurious newline

2016-05-18 Thread Dario Faggioli

Hey Wei,

I know where we stand in the release process, but the patch is so trivial and
free of risks, and the trace output, with the spurious newline, so disturbing,
that I think this should go in.

Regards,
Dario
---

Dario Faggioli (1):
  xenalyze: fix a spurious newline

 tools/xentrace/xenalyze.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Dario Faggioli

On Wed, 2016-05-18 at 12:03 -0600, Tony S wrote:
> On Wed, May 18, 2016 at 11:59 AM, Tony S 
> wrote:
> > On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky
> >  wrote:
> > > Tony narrowed the problem down to update_curr() where vruntime is
> > > calculated, based on runqueue's clock_task value. That value is
> > > computed
> > > in update_rq_clock_task(), which needs paravirt_steal_rq_enabled.
> > > 
> > Hi Boris,
> > 
> > You are right.
> > 
> > The real problem is steal_clock in pv_time_ops is implemented in
> > KVM
> > but not in Xen.
> > 
> > [...]
> >
> > Therefore, even though update_rq_clock_task() calculates the value
> > and
> > paravirt_steal_rq_enabled option is enabled, the steal value just
> > returns 0. This will cause the problem which I mentioned.
> > 
> > update_rq_clock_task
> > --> paravirt_steal_clock
> > --> pv_time_ops.steal_clock
> > --> native_steal_clock (if in Xen)
> > --> 0
> > 
Ok, thanks again for confirming this.

> Also, I tried the latest long term version of Linux 4.4, this issue
> still exists there. Hoping the next version can add this patch.
> 
Yes, as Juergen said here:

 http://lists.xen.org/archives/html/xen-devel/2016-05/msg01712.html

he has in his plans to implement the full mechanism. It will just take
a bit longer, due to the amount of work necessary for this second part.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Hackathon 16] Notes from Security Session

2016-05-18 Thread Doug Goldstein

On 5/17/16 4:08 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 26, 2016 at 09:57:12AM +0100, Lars Kurth wrote:
>> Also adding Steve Maresca to the thread, who has been using XSM extensively 
>> and also documenting XSM and can provide some user perspective 
>> Lars
>>
>>> On 25 Apr 2016, at 20:51, Daniel De Graaf  wrote:
>>>
>>> On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
 On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
> On 19/04/16 10:02, Doug Goldstein wrote:
>> On 4/18/16 12:20 PM, Lars Kurth wrote:
>>> Hi all,

 CC-ing XSM maintainer :-)
>>>
>>> Thanks. I'm going to comment on this and the wiki.
>>>
>>> [...]
>>> === Enabling XSM By default ===
>>> Andrew: There are some issues which we need to work through; a lot of 
>>> little paper cuts
>>> Rich: Could we create a list of issues on the wiki?
>>> Lars: Definitely
>>> Doug: Could we not have a policy which is equivalent to XSM being 
>>> compiled out
>>> Andrew: Could make policy more modular instead of one big global policy
>>>
>>> Re-apply policy of guest after running
>>>
>>> ACTION: Need a wiki page, Konrad can start one and we can 
>>> collaboratively flesh it out
>>> Lars: See http://wiki.xenproject.org/wiki/XSMAsDefault_TODO_List
>>>
>>> ACTION: Konrad and others to add detail to it
>>>
>>>
>> It was pointed out to me that I did not get my comments about XSM across
>> clearly. I believe we need to improve the default policy to be
>> equivalent to disabling XSM and/or create a policy called "dummy" that
>> is the same as XSM disabled. To make XSM usage more smooth I propose we
>> bake the default policy into .initdata so that when you boot Xen
>> compiled with XSM you are no worse off than compiling XSM out.
>>
>> The rationale here is that prior to a recent commit when you compiled
>> Xen with XSM enabled but did not provide a default policy then any domUs
>> that you ran had as much access as dom0. The recent commit changed it so
>> that Xen by default does not boot without a policy.
>>
>> With my proposed change we would have "dummy" that would compile in and
>> if you provided another policy it would be used instead or you could
>> late load a replacement policy. Basically filling the gap of turning on
>> XSM and having a system less secure than XSM off until you developed
>> your policy.
>
> +1.  It also avoids needing to play around loading an extra file as a grub
> module, which makes distro-integration easer.
>
> ~Andrew
>>>
>>> This should be doable, though it will require moving the rest of
>>> tools/flask/policy under xen/ for proper dependencies. Beyond that, it
>>> would need either a script or a careful invocation of objcopy to convert
>>> the policy output to an array in initdata, and then that policy would be
>>> used if the bootloader one is not present.
> 
> OK, let me take a stab at that. Unless somebody else is already looking
> at this?

I know I pitched this out and said I had planned on working on it but
the realities of life have set in and I likely won't really be able to
put an honest amount of effort into this for a few more weeks. I think a
bulk of the work will really be testing and documenting instead of
coding because as we said it should just be a few commands and a few if
checks.

> 
>>>
>>> From the wiki:
 XSM with default policy will have:

  - Same functionality exposed to guests without regressions
  - Have at minimum the same security as we have without XSM enabled.
  - Have set of policies for device driver domains vs control domains.
>>>
>>> The first two bullets should be true with the current policy. The third
>>> needs to be more precisely defined: any operation on a group it
>>> controls, or limited operations (such as adjusting memory size) on all
>>> guests?  The latter will probably need a custom policy (module) for
>>> exactly what the control domain does.
> 
> Hm. I would have thought that device driver domains would have
> limited operations. As in they can do grant maps, PCIe access, etc.
> But they cannot do the operations that dom0 has done.
> 
> Doug, didn't you do some of this already?

So I've made a domD_t but I'm not sure how encompassing it is. I've
thought about making the "driver_domain=BOOL" parameter apply that label
over domU_t but right now its just done through "seclabel". I can post
what I've got as a RFC.

-- 
Doug Goldstein



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

[Xen-devel] [xen-4.5-testing test] 94543: regressions - FAIL

2016-05-18 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 93989
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 93989

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93989
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 93989

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

version targeted for testing:
 xen  facf1562437fb79c05c5e9f1ba9d33e26535930a
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z8 days
Failing since 94030  2016-05-11 13:08:55 Z7 days   12 attempts
Testing same since94543  2016-05-18 07:57:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kyle J. Temkin 
  Kyle Temkin 
  Shanker Donthineni 
  Stefano Stabellini 
  Vikram Sethi 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

2016-05-18 Thread Xu, Quan

On May 19, 2016 8:33 AM, Tian, Kevin  wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, May 18, 2016 11:05 PM
> >
> > >>> On 18.05.16 at 14:53,  wrote:
> > > On May 17, 2016 3:48 PM, Jan Beulich  wrote:
> > >> >>> On 17.05.16 at 05:19,  wrote:
> > >> >>  From: Xu, Quan
> > >> >> Sent: Monday, May 16, 2016 11:26 PM
> > >> >>
> > >> >> On May 13, 2016 11:28 PM, Jan Beulich  wrote:
> > >> >> > >>> On 22.04.16 at 12:54,  wrote:
> > >> >> > > --- a/docs/misc/xen-command-line.markdown
> > >> >> > > +++ b/docs/misc/xen-command-line.markdown
> > >> >> > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is
> > >> >> > > also
> > >> >> > specified vpmu will be turned off.
> > >> >> > >  As the virtualisation is not 100% safe, don't use the vpmu
> > >> >> > > flag on production systems (see
> > >> >> > > http://xenbits.xen.org/xsa/advisory-
> > >> 163.html)!
> > >> >> > >
> > >> >> > > +### vtd\_qi\_timeout (VT-d)
> > >> >> > > +> `= `
> > >> >> > > +
> > >> >> > > +> Default: `1`
> > >> >> > > +
> > >> >> > > +Specify the timeout of the VT-d Queued Invalidation in
> milliseconds.
> > >> >> > > +
> > >> >> > > +By default, the timeout is 1ms. When you see error 'Queue
> > >> >> > > +invalidate wait descriptor timed out', try increasing this value.
> > >> >> >
> > >> >> > So when someone enables ATS, will the 1ms timeout apply to the
> > >> >> > dev iotlb invalidations too?
> > >> >>
> > >> >> Yes,
> > >> >> The timeout is the same for IOTLB, Context, IEC and Device-TLB
> invalidation.
> > >> >>
> > >> >> > If so, that's surely too short, and would ideally be adjusted
> > >> >> > automatically, but the need for a higher timeout in that case
> > >> >> > should in any event be mentioned here.
> > >> >>
> > >> >> I can try to use 1ms for IOTLB, Context and  IEC invalidation.
> > >> >> As mentioned, 1 ms is enough for IOTLB, Context and  IEC invalidation.
> > >> >> What about 10 ms for Device-TLB (10 ms is just a higher timeout,
> > >> >> no
> > >> specific meaning)?
> > >> >
> > >> > I remember in earlier discussion we agreed to use 1ms as the
> > >> > default for both IOMMU-side and device-side flushes. For
> > >> > device-side flushes, we checked internal HW team that 1ms is a
> > >> > reasonable threshold for integrated devices. It's likely
> > >> > insufficient for discrete devices. We may check any automatic
> > >> > adjustment method later when it becomes a real problem. For now,
> please elaborate above information in the text.
> > >>
> > >> Well, taking care of automation later is fine with me, but tying
> > >> everything to a single timeout, when device iotlb invalidation may
> > >> require a much larger value, isn't.
> > >>
> > >
> > > A little bit confused. Check it -- could I leave patch 1/3 as is?
> >
> > The patch can imo remain as is only if the new default timeout is
> > large enough for all possible cases (including those users who are
> > adventurous enough to turn on ATS).
> >

Jan,

I only have an ATS device (MYRICOM Inc. Myri-10G Dual-Protocol NIC). 1 ms is 
large enough for invalidation so far.
Any suggestion for this new default timeout?


> A single default value for both IOMMU-side and device-side is anyway not
> optimal. What about introducing a new knob e.g. vtd_qi_device_timeout
> specifically for device-side flush while using vtd_qi_timeout for other 
> places? If
> device-side timeout is not specified, it is then default to vtd_qi_timeout.
>

IMO, we are better to introduce only one  variable  for VT-d invalidation.
The users may be not interested in such a detailed VT-d knowledge. Also this is 
taking into consideration of  consistency.  :)

Quan

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

[Xen-devel] Resend: [PATCH] v3 - Add exclusive locking option to block-iscsi

2016-05-18 Thread Steven Haigh


On 2016-05-09 14:22, Steven Haigh wrote:

On 2016-05-05 15:52, Steven Haigh wrote:

On 2016-05-05 12:32, Steven Haigh wrote:

Overview

If you're using iSCSI, you can mount a target by multiple Dom0
machines on the same target. For non-cluster aware filesystems, this
can lead to disk corruption and general bad times by all. The iSCSI
protocol allows the use of persistent reservations as per the SCSI
disk spec. Low level SCSI commands for locking are handled by the
sg_persist program (bundled with sg3_utils package in EL).

The aim of this patch is to create a 'locktarget=y' option specified
within the disk 'target' command for iSCSI to lock the target in
exclusive mode on VM start with a key generated from the local 
systems

IP, and release this lock on the shutdown of the DomU.

Example Config:
disk=
['script=block-iscsi,vdev=xvda,target=iqn=iqn.1986-03.com.sun:02:mytarget,portal=iscsi.example.com,locktarget=y']

In writing this, I have also re-factored parts of the script to put
some things in what I believe to be a better place to make expansion
easier. This is mainly in removing functions that purely call other
functions with no actual code execution.

Signed-off-by: Steven Haigh 

(on a side note, first time I've submitted a patch to the list and 
I'm

currently stuck on a webmail client, so apologies in advance if this
all goes wrong ;)


Changes in v2:
Bugfix: Call find_device to locate the /dev/sdX component of the iSCSI
target before trying to run unlock_device().

Apologies for this oversight.



Changes in v3:
* Split the block-iscsi cleanup into a seperate patch
(block-iscsi-locking-v3_01_simplify_block-iscsi.patch).
* Add locking in second patch file 
(block-iscsi-locking-v3_02_add_locking.patch)


Resend of patches.

There was a mention of having to add further documentation to 
xl-disk-configuration.txt - however there are no mentions of block-iscsi 
script within the documentation to add. As such, it probably would be 
out of place to add things here.


The locktarget option is presented directly to the block-iscsi script 
and not evaluated anywhere outside this script.


--
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
--- block-iscsi.orig2016-05-09 15:12:02.489495212 +1000
+++ block-iscsi 2016-05-09 15:16:35.447480532 +1000
@@ -31,16 +31,6 @@
 echo $1 | sed "s/^\("$2"\)//"
 }
 
-check_tools()
-{
-if ! command -v iscsiadm > /dev/null 2>&1; then
-fatal "Unable to find iscsiadm tool"
-fi
-if [ "$multipath" = "y" ] && ! command -v multipath > /dev/null 2>&1; then
-fatal "Unable to find multipath"
-fi
-}
-
 # Sets the following global variables based on the params field passed in as
 # a parameter: iqn, portal, auth_method, user, multipath, password
 parse_target()
@@ -52,12 +42,18 @@
 case $param in
 iqn=*)
 iqn=$(remove_label $param "iqn=")
+if ! command -v iscsiadm > /dev/null 2>&1; then
+fatal "Could not find iscsiadm tool."
+fi
 ;;
 portal=*)
 portal=$(remove_label $param "portal=")
 ;;
 multipath=*)
 multipath=$(remove_label $param "multipath=")
+if ! command -v multipath > /dev/null 2>&1; then
+fatal "Multipath selected, but no multipath tools found"
+fi
 ;;
 esac
 done
@@ -96,40 +92,6 @@
 fi
 }

-# Attaches the target $iqn in $portal and sets $dev to point to the
-# multipath device
-attach()
-{
-do_or_die iscsiadm -m node --targetname "$iqn" -p "$portal" --login > /dev/null
-find_device
-}
-
-# Discovers targets in $portal and checks that $iqn is one of those targets
-# Also sets the auth parameters to attach the device
-prepare()
-{
-# Check if target is already opened
-iscsiadm -m session 2>&1 | grep -q "$iqn" && fatal "Device already opened"
-# Discover portal targets
-iscsiadm -m discovery -t st -p $portal 2>&1 | grep -q "$iqn" || \
-fatal "No matching target iqn found"
-}
-
-# Attaches the device and writes xenstore backend entries to connect
-# the device
-add()
-{
-attach
-write_dev $dev
-}
-
-# Disconnects the device
-remove()
-{
-find_device
-do_or_die iscsiadm -m node --targetname "$iqn" -p "$portal" --logout > /dev/null
-}
-
 command=$1
 target=$(xenstore-read $XENBUS_PATH/params || true)
 if [ -z "$target" ]; then
@@ -138,15 +100,21 @@

 parse_target "$target"

-check_tools || exit 1
-
 case $command in
 add)
-prepare
-add
+# Check if target is already opened
+iscsiadm -m session 2>&1 | grep -q "$iqn" && fatal "Device already opened"
+# Discover portal targets
+iscsiadm -m discovery -t st -p $portal 2>&1 | grep -q "$iqn" || \
+fatal "No matching target iqn found"
+
+## Login to the iSCSI target.
+do_or_die iscsiadm -m node --targetname "$iqn" -p "$portal" --login > /dev/null
+
+

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

2016-05-18 Thread Tian, Kevin

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, May 18, 2016 11:05 PM
> 
> >>> On 18.05.16 at 14:53,  wrote:
> > On May 17, 2016 3:48 PM, Jan Beulich  wrote:
> >> >>> On 17.05.16 at 05:19,  wrote:
> >> >>  From: Xu, Quan
> >> >> Sent: Monday, May 16, 2016 11:26 PM
> >> >>
> >> >> On May 13, 2016 11:28 PM, Jan Beulich  wrote:
> >> >> > >>> On 22.04.16 at 12:54,  wrote:
> >> >> > > --- a/docs/misc/xen-command-line.markdown
> >> >> > > +++ b/docs/misc/xen-command-line.markdown
> >> >> > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also
> >> >> > specified vpmu will be turned off.
> >> >> > >  As the virtualisation is not 100% safe, don't use the vpmu flag
> >> >> > > on production systems (see http://xenbits.xen.org/xsa/advisory-
> >> 163.html)!
> >> >> > >
> >> >> > > +### vtd\_qi\_timeout (VT-d)
> >> >> > > +> `= `
> >> >> > > +
> >> >> > > +> Default: `1`
> >> >> > > +
> >> >> > > +Specify the timeout of the VT-d Queued Invalidation in 
> >> >> > > milliseconds.
> >> >> > > +
> >> >> > > +By default, the timeout is 1ms. When you see error 'Queue
> >> >> > > +invalidate wait descriptor timed out', try increasing this value.
> >> >> >
> >> >> > So when someone enables ATS, will the 1ms timeout apply to the dev
> >> >> > iotlb invalidations too?
> >> >>
> >> >> Yes,
> >> >> The timeout is the same for IOTLB, Context, IEC and Device-TLB 
> >> >> invalidation.
> >> >>
> >> >> > If so, that's surely too short, and would ideally be adjusted
> >> >> > automatically, but the need for a higher timeout in that case
> >> >> > should in any event be mentioned here.
> >> >>
> >> >> I can try to use 1ms for IOTLB, Context and  IEC invalidation. As
> >> >> mentioned, 1 ms is enough for IOTLB, Context and  IEC invalidation.
> >> >> What about 10 ms for Device-TLB (10 ms is just a higher timeout,  no
> >> specific meaning)?
> >> >
> >> > I remember in earlier discussion we agreed to use 1ms as the default
> >> > for both IOMMU-side and device-side flushes. For device-side flushes,
> >> > we checked internal HW team that 1ms is a reasonable threshold for
> >> > integrated devices. It's likely insufficient for discrete devices. We
> >> > may check any automatic adjustment method later when it becomes a real
> >> > problem. For now, please elaborate above information in the text.
> >>
> >> Well, taking care of automation later is fine with me,
> >> but tying everything to a
> >> single timeout, when device iotlb invalidation may require a much larger 
> >> value,
> >> isn't.
> >>
> >
> > A little bit confused. Check it -- could I leave patch 1/3 as is?
> 
> The patch can imo remain as is only if the new default timeout
> is large enough for all possible cases (including those users
> who are adventurous enough to turn on ATS).
> 
> > btw, I have tested it against the last commit, no conflict.
> 
> No idea what you mean to say with this.
> 

A single default value for both IOMMU-side and device-side is
anyway not optimal. What about introducing a new knob
e.g. vtd_qi_device_timeout specifically for device-side flush
while using vtd_qi_timeout for other places? If device-side
timeout is not specified, it is then default to vtd_qi_timeout.

Thanks
Kevin

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

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

2016-05-18 Thread osstest service owner

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install   fail blocked in 94487
 build-i386-rumpuserxen6 xen-buildfail   like 94487
 build-amd64-rumpuserxen   6 xen-buildfail   like 94487
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94487
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94487
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94487
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94487

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

version targeted for testing:
 xen  c32381352cce9744e640bf239d2704dae4af4fc7
baseline version:
 xen  ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83

Last test of basis94487  2016-05-16 15:18:47 Z2 days
Failing since 94495  2016-05-17 00:15:00 Z1 days3 attempts
Testing same since94536  2016-05-18 03:52:54 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Edgar E. Iglesias 
  Jan Beulich 
  Peng Fan 
  Stefano Stabellini 

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

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

2016-05-18 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 720eea6aa80b48acb05c1adc0f835e849d71da97
baseline version:
 ovmf b41ef32518095f783d0c2343b496cc857c6f3dff

Last test of basis44427  2016-05-18 06:20:27 Z0 days
Testing same since44430  2016-05-18 20:20:23 Z0 days1 attempts


People who touched revisions under test:
  Dong, Eric 
  Eric Dong 
  Gabriel Somlo 
  Laszlo Ersek 
  Pedroa Liu 
  Yonghong Zhu 
  Zenith432 

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 720eea6aa80b48acb05c1adc0f835e849d71da97
Author: Eric Dong 
Date:   Tue May 17 14:00:06 2016 +0800

BootMaintenanceManagerUiLib: Rollback changes for BootNext.

Commit a85be3ae48a8aaa40b755cd0ff7270c67cfed585 imports errors for
BootNext question, this patch rollback the related changes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed-by: Liming Gao 

commit d3bb711834acd3eda35a07d0be7911bc3dbb9e6f
Author: Zenith432 
Date:   Mon May 16 23:52:21 2016 +0800

BaseTools: Eliminate two shift-negative-value in FvLib.c

clang 3.8 flags -Wshift-negative-value warning, which turns fatal due to
use of -Werror.

Fixes: https://github.com/tianocore/edk2/issues/49

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zenith432 
Reviewed-by: Liming Gao 

commit b98993580e3c07cfa139ed19b6fb4f1bb4db9edc
Author: Zenith432 
Date:   Mon May 16 23:50:06 2016 +0800

MdePkg: Reinitialize twice-iterated VA_LIST in variadic function 
UefiDevicePathLibCatPrint()

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zenith432 
Reviewed-by: Liming Gao 

commit 415700ec3eb5f6414e6278bbf338d142052b3138
Author: Zenith432 
Date:   Mon May 16 23:49:12 2016 +0800

MdeModulePkg: Terminate two unterminated VA_COPYs in 
CheckRemainingSpaceForConsistencyInternal()

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zenith432 
Reviewed-by: Liming Gao 

commit 7266e2f69b8bfa47c1c7203ad51dabf6c4cb78c9
Author: Dong, Eric 
Date:   Tue May 17 10:12:12 2016 +0800

MdeModulePkg UiApp: Add "Enter Setup" status code.

The original BdsDxe driver has "Enter Setup" status code
while current code not. This patch restores it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed-by: Liming Gao 

commit b8f3601daae5c8b50ca6f7da74bb150f2eef9453
Author: Pedroa Liu 
Date:   Mon May 16 20:48:41 2016 +0800

ShellPkg: Fix the incorrect behavior when pressing 'shift' key.

If 'ReadKeyStroke' function return EFI_NOT_READY then skip it.
If the return value is EFI_DEVICE_ERROR clean the currentString buffer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Pedroa Liu 
Reviewed-by: Qiu Shumin 

commit c28d2e1047816164ffec552e4a3375122cbcc6b6
Author: Yonghong Zhu 
Date:   Tue May 10 17:58:26 2016 +0800

BaseTools: support private package definition

EDKII build spec and DEC spec updated to support private package
definition.
If GUID, Protocol or PPI is listed in a DEC file, where the  Private
modifier is used in the section tag ([Guids.common.Private] for example),
only modules within the package are permitted to use the GUID, Protocol
or PPI. If a module or library instance outside of the package attempts
to use the item, the build must fail with an appropriate error message.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-o

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

2016-05-18 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  bab2bd8e222de9e596699ac080ea985af828c4c4
baseline version:
 xen  8b1834afdde1c0e19d92bd040ed08d3943e5f2eb

Last test of basis94556  2016-05-18 16:03:00 Z0 days
Testing same since94557  2016-05-18 19:02:02 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=bab2bd8e222de9e596699ac080ea985af828c4c4
+ . ./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 
bab2bd8e222de9e596699ac080ea985af828c4c4
+ branch=xen-unstable-smoke
+ revision=bab2bd8e222de9e596699ac080ea985af828c4c4
+ . ./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.6-testing
+ '[' xbab2bd8e222de9e596699ac080ea985af828c4c4 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9

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

2016-05-18 Thread osstest service owner

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 720eea6aa80b48acb05c1adc0f835e849d71da97
baseline version:
 ovmf b41ef32518095f783d0c2343b496cc857c6f3dff

Last test of basis94519  2016-05-17 14:41:41 Z1 days
Testing same since94541  2016-05-18 05:59:47 Z0 days1 attempts


People who touched revisions under test:
  Dong, Eric 
  Eric Dong 
  Gabriel Somlo 
  Laszlo Ersek 
  Pedroa Liu 
  Yonghong Zhu 
  Zenith432 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=720eea6aa80b48acb05c1adc0f835e849d71da97
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
720eea6aa80b48acb05c1adc0f835e849d71da97
+ branch=ovmf
+ revision=720eea6aa80b48acb05c1adc0f835e849d71da97
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x720eea6aa80b48acb05c1adc0f835e849d71da97 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://githu

Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation

2016-05-18 Thread Peter Zijlstra

On Wed, May 18, 2016 at 03:13:44PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, May 18, 2016 at 08:43:02PM +0200, Peter Zijlstra wrote:
> > 
> > We've unconditionally used the queued spinlock for many releases now.
> 
> Like since 4.2?

Yeah, that seems to be the right number.

> I don't know of any enterprise distro that is shipping anything
> more modern than 4.1?

RHEL 7  -- v3.10
SLES 12 -- v3.12
Debian Jessie   -- v3.16
Ubuntu 16.04 LTS-- v4.4

But waiting for the major enterprise distros (RHEL/SLES) would mean
another decade or so before people start using it. We don't usually wait
this long for anything.

> Perhaps it would be good to wait until they
> at least ship and then give them some time to see if they have found
> any issues?

My motivation was that people keep trying to send patches against the
ticket lock code... David did just today, and he's not the first.

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-18 Thread Meng Xu

Hi Andrii,

On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov
 wrote:
> This series RFC patches from the currently ongoing production project.
> This patch series presents changes needed to fit the system into
> customer requirements as well as workaround limitations of the
> Jacinto6 SoC.

IMHO, it will be better, if possible, to describe the exact customer
requirements this patch series tries to satisfy. I'm curious at what
the requirements are and if the requirements are general enough for
many other customers. :-)

Similarly, what are the limitations for the Jacinto6 SoC that need to
be workaround? If the board is not supported by Xen, can we say Xen
will support the board with the warkaround?

Thanks and Best Regards,

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

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

Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation

2016-05-18 Thread Konrad Rzeszutek Wilk

On Wed, May 18, 2016 at 08:43:02PM +0200, Peter Zijlstra wrote:
> 
> We've unconditionally used the queued spinlock for many releases now.

Like since 4.2? I don't know of any enterprise distro that is shipping anything
more modern than 4.1? Perhaps it would be good to wait until they
at least ship and then give them some time to see if they have found
any issues?

> 
> Its time to remove the old ticket lock code.
> 
> Cc: Waiman Long 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  arch/x86/Kconfig  |   3 +-
>  arch/x86/include/asm/paravirt.h   |  18 ---
>  arch/x86/include/asm/paravirt_types.h |   7 -
>  arch/x86/include/asm/spinlock.h   | 174 ---
>  arch/x86/include/asm/spinlock_types.h |  13 --
>  arch/x86/kernel/kvm.c | 245 -
>  arch/x86/kernel/paravirt-spinlocks.c  |   7 -
>  arch/x86/kernel/paravirt_patch_32.c   |   4 +-
>  arch/x86/kernel/paravirt_patch_64.c   |   4 +-
>  arch/x86/xen/spinlock.c   | 250 
> +-
>  10 files changed, 6 insertions(+), 719 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 7bb15747fea2..a5543914f6dd 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -705,7 +705,6 @@ config PARAVIRT_DEBUG
>  config PARAVIRT_SPINLOCKS
>   bool "Paravirtualization layer for spinlocks"
>   depends on PARAVIRT && SMP
> - select UNINLINE_SPIN_UNLOCK if !QUEUED_SPINLOCKS
>   ---help---
> Paravirtualized spinlocks allow a pvops backend to replace the
> spinlock implementation with something virtualization-friendly
> @@ -718,7 +717,7 @@ config PARAVIRT_SPINLOCKS
>  
>  config QUEUED_LOCK_STAT
>   bool "Paravirt queued spinlock statistics"
> - depends on PARAVIRT_SPINLOCKS && DEBUG_FS && QUEUED_SPINLOCKS
> + depends on PARAVIRT_SPINLOCKS && DEBUG_FS
>   ---help---
> Enable the collection of statistical data on the slowpath
> behavior of paravirtualized queued spinlocks and report
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 2970d22d7766..4cd8db05301f 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -661,8 +661,6 @@ static inline void __set_fixmap(unsigned /* enum 
> fixed_addresses */ idx,
>  
>  #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
>  
> -#ifdef CONFIG_QUEUED_SPINLOCKS
> -
>  static __always_inline void pv_queued_spin_lock_slowpath(struct qspinlock 
> *lock,
>   u32 val)
>  {
> @@ -684,22 +682,6 @@ static __always_inline void pv_kick(int cpu)
>   PVOP_VCALL1(pv_lock_ops.kick, cpu);
>  }
>  
> -#else /* !CONFIG_QUEUED_SPINLOCKS */
> -
> -static __always_inline void __ticket_lock_spinning(struct arch_spinlock 
> *lock,
> - __ticket_t ticket)
> -{
> - PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
> -}
> -
> -static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
> - __ticket_t ticket)
> -{
> - PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
> -}
> -
> -#endif /* CONFIG_QUEUED_SPINLOCKS */
> -
>  #endif /* SMP && PARAVIRT_SPINLOCKS */
>  
>  #ifdef CONFIG_X86_32
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index 7fa9e7740ba3..60aac60ba25f 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -301,23 +301,16 @@ struct pv_mmu_ops {
>  struct arch_spinlock;
>  #ifdef CONFIG_SMP
>  #include 
> -#else
> -typedef u16 __ticket_t;
>  #endif
>  
>  struct qspinlock;
>  
>  struct pv_lock_ops {
> -#ifdef CONFIG_QUEUED_SPINLOCKS
>   void (*queued_spin_lock_slowpath)(struct qspinlock *lock, u32 val);
>   struct paravirt_callee_save queued_spin_unlock;
>  
>   void (*wait)(u8 *ptr, u8 val);
>   void (*kick)(int cpu);
> -#else /* !CONFIG_QUEUED_SPINLOCKS */
> - struct paravirt_callee_save lock_spinning;
> - void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
> -#endif /* !CONFIG_QUEUED_SPINLOCKS */
>  };
>  
>  /* This contains all the paravirt structures: we get a convenient
> diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
> index be0a05913b91..921bea7a2708 100644
> --- a/arch/x86/include/asm/spinlock.h
> +++ b/arch/x86/include/asm/spinlock.h
> @@ -20,187 +20,13 @@
>   * (the type definitions are in asm/spinlock_types.h)
>   */
>  
> -#ifdef CONFIG_X86_32
> -# define LOCK_PTR_REG "a"
> -#else
> -# define LOCK_PTR_REG "D"
> -#endif
> -
> -#if defined(CONFIG_X86_32) && (defined(CONFIG_X86_PPRO_FENCE))
> -/*
> - * On PPro SMP, we use a locked operation to unlock
> - * (PPro errata 66, 92)
> - */
> -# define UNLOCK_LOCK_PREFIX LOCK_PREFIX
> -#else
> -# define UNLOCK_LOCK_PREFIX
> -#endif
> -
>  /* H

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

2016-05-18 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  c4111209b8b40fe8673f5dd13518231c4ed7967a
baseline version:
 libvirt  0e8a72a5ef16c093181af2c22e632ae639808a1b

Last test of basis94502  2016-05-17 04:21:18 Z1 days
Testing same since94539  2016-05-18 04:21:06 Z0 days1 attempts


People who touched revisions under test:
  Chunyan Liu 
  Cole Robinson 
  Erik Skultety 
  Fabian Freyer 
  Maxim Nestratov 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=c4111209b8b40fe8673f5dd13518231c4ed7967a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /

[Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation

2016-05-18 Thread Peter Zijlstra


We've unconditionally used the queued spinlock for many releases now.

Its time to remove the old ticket lock code.

Cc: Waiman Long 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/Kconfig  |   3 +-
 arch/x86/include/asm/paravirt.h   |  18 ---
 arch/x86/include/asm/paravirt_types.h |   7 -
 arch/x86/include/asm/spinlock.h   | 174 ---
 arch/x86/include/asm/spinlock_types.h |  13 --
 arch/x86/kernel/kvm.c | 245 -
 arch/x86/kernel/paravirt-spinlocks.c  |   7 -
 arch/x86/kernel/paravirt_patch_32.c   |   4 +-
 arch/x86/kernel/paravirt_patch_64.c   |   4 +-
 arch/x86/xen/spinlock.c   | 250 +-
 10 files changed, 6 insertions(+), 719 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7bb15747fea2..a5543914f6dd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -705,7 +705,6 @@ config PARAVIRT_DEBUG
 config PARAVIRT_SPINLOCKS
bool "Paravirtualization layer for spinlocks"
depends on PARAVIRT && SMP
-   select UNINLINE_SPIN_UNLOCK if !QUEUED_SPINLOCKS
---help---
  Paravirtualized spinlocks allow a pvops backend to replace the
  spinlock implementation with something virtualization-friendly
@@ -718,7 +717,7 @@ config PARAVIRT_SPINLOCKS
 
 config QUEUED_LOCK_STAT
bool "Paravirt queued spinlock statistics"
-   depends on PARAVIRT_SPINLOCKS && DEBUG_FS && QUEUED_SPINLOCKS
+   depends on PARAVIRT_SPINLOCKS && DEBUG_FS
---help---
  Enable the collection of statistical data on the slowpath
  behavior of paravirtualized queued spinlocks and report
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 2970d22d7766..4cd8db05301f 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -661,8 +661,6 @@ static inline void __set_fixmap(unsigned /* enum 
fixed_addresses */ idx,
 
 #if defined(CONFIG_SMP) && defined(CONFIG_PARAVIRT_SPINLOCKS)
 
-#ifdef CONFIG_QUEUED_SPINLOCKS
-
 static __always_inline void pv_queued_spin_lock_slowpath(struct qspinlock 
*lock,
u32 val)
 {
@@ -684,22 +682,6 @@ static __always_inline void pv_kick(int cpu)
PVOP_VCALL1(pv_lock_ops.kick, cpu);
 }
 
-#else /* !CONFIG_QUEUED_SPINLOCKS */
-
-static __always_inline void __ticket_lock_spinning(struct arch_spinlock *lock,
-   __ticket_t ticket)
-{
-   PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
-}
-
-static __always_inline void __ticket_unlock_kick(struct arch_spinlock *lock,
-   __ticket_t ticket)
-{
-   PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);
-}
-
-#endif /* CONFIG_QUEUED_SPINLOCKS */
-
 #endif /* SMP && PARAVIRT_SPINLOCKS */
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 7fa9e7740ba3..60aac60ba25f 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -301,23 +301,16 @@ struct pv_mmu_ops {
 struct arch_spinlock;
 #ifdef CONFIG_SMP
 #include 
-#else
-typedef u16 __ticket_t;
 #endif
 
 struct qspinlock;
 
 struct pv_lock_ops {
-#ifdef CONFIG_QUEUED_SPINLOCKS
void (*queued_spin_lock_slowpath)(struct qspinlock *lock, u32 val);
struct paravirt_callee_save queued_spin_unlock;
 
void (*wait)(u8 *ptr, u8 val);
void (*kick)(int cpu);
-#else /* !CONFIG_QUEUED_SPINLOCKS */
-   struct paravirt_callee_save lock_spinning;
-   void (*unlock_kick)(struct arch_spinlock *lock, __ticket_t ticket);
-#endif /* !CONFIG_QUEUED_SPINLOCKS */
 };
 
 /* This contains all the paravirt structures: we get a convenient
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index be0a05913b91..921bea7a2708 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -20,187 +20,13 @@
  * (the type definitions are in asm/spinlock_types.h)
  */
 
-#ifdef CONFIG_X86_32
-# define LOCK_PTR_REG "a"
-#else
-# define LOCK_PTR_REG "D"
-#endif
-
-#if defined(CONFIG_X86_32) && (defined(CONFIG_X86_PPRO_FENCE))
-/*
- * On PPro SMP, we use a locked operation to unlock
- * (PPro errata 66, 92)
- */
-# define UNLOCK_LOCK_PREFIX LOCK_PREFIX
-#else
-# define UNLOCK_LOCK_PREFIX
-#endif
-
 /* How long a lock should spin before we consider blocking */
 #define SPIN_THRESHOLD (1 << 15)
 
 extern struct static_key paravirt_ticketlocks_enabled;
 static __always_inline bool static_key_false(struct static_key *key);
 
-#ifdef CONFIG_QUEUED_SPINLOCKS
 #include 
-#else
-
-#ifdef CONFIG_PARAVIRT_SPINLOCKS
-
-static inline void __ticket_enter_slowpath(arch_spinlock_t *lock)
-{
-   set_bit(0, (volatile unsigned long *)&lock->tickets.head);
-}
-
-#else  /* !CONFIG_PARAVIRT_SPINLOCKS */
-static __always_inline

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

2016-05-18 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8b1834afdde1c0e19d92bd040ed08d3943e5f2eb
baseline version:
 xen  667a7120d006007389435976071f0b89f94ec7cc

Last test of basis94551  2016-05-18 13:02:38 Z0 days
Testing same since94556  2016-05-18 16:03:00 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=8b1834afdde1c0e19d92bd040ed08d3943e5f2eb
+ . ./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 
8b1834afdde1c0e19d92bd040ed08d3943e5f2eb
+ branch=xen-unstable-smoke
+ revision=8b1834afdde1c0e19d92bd040ed08d3943e5f2eb
+ . ./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.6-testing
+ '[' x8b1834afdde1c0e19d92bd040ed08d3943e5f2eb = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Tony S

On Wed, May 18, 2016 at 11:59 AM, Tony S  wrote:
> On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky
>  wrote:
>> On 05/18/2016 12:10 PM, Dario Faggioli wrote:
>>> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote:
 On 18/05/16 16:46, Boris Ostrovsky wrote:
>
> Won't we be accounting for stolen cycles twice now --- once from
> steal_account_process_tick()->steal_clock() and second time from
> do_stolen_accounting()?
 Uuh, yes.

 I guess I should rip do_stolen_accounting() out, too? It is a
 Xen-specific hack, so I guess nobody will cry. Maybe it would be a
 good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?

>>> So, config options aside, if I understand this correctly, it looks like
>>> we were actually already doing steal time accounting, although in a
>>> non-standard way.
>>>
>>> And yet, people seem to have issues relating to lack of (proper?) steal
>>> time accounting (Cc-ing Tony).
>>>
>>> I guess this means that, either:
>>>  - the issue being reported is actually not caused by the lack of
>>>steal time accounting,
>>>  - our current (Xen specific) steal time accounting solution is flawed,
>>>  - the issue is caused by the lack of the bit of steal time accounting
>>>that we do not support yet,
>>
>> I believe it's this one.
>>
>> Tony narrowed the problem down to update_curr() where vruntime is
>> calculated, based on runqueue's clock_task value. That value is computed
>> in update_rq_clock_task(), which needs paravirt_steal_rq_enabled.
>>
>
> Hi Boris,
>
> You are right.
>
> The real problem is steal_clock in pv_time_ops is implemented in KVM
> but not in Xen.
>
> arch/x86/include/asm/paravirt_types.h
> struct pv_time_ops {
> unsigned long long (*sched_clock)(void);
> unsigned long long (*steal_clock)(int cpu);
> unsigned long (*get_tsc_khz)(void);
> };
>
>
> (1) KVM implemented both sched_clock and steal_clock.
>
> arch/x86/kernel/kvmclock.c
> pv_time_ops.sched_clock = kvm_clock_read;
>
> arch/x86/kernel/kvm.c
> pv_time_ops.steal_clock = kvm_steal_clock;
>
>
> (2) However, Xen just implemented sched_clock while the steal_clock is
> still native_steal_clock(). The function native_steal_clock() just
> simply return 0.
>
> arch/x86/xen/time.c
> .sched_clock = xen_clocksource_read;
>
> arch/x86/kernel/paravirt.c
> static u64 native_steal_clock(int cpu)
> {
>  return 0;
> }
>
>
> Therefore, even though update_rq_clock_task() calculates the value and
> paravirt_steal_rq_enabled option is enabled, the steal value just
> returns 0. This will cause the problem which I mentioned.
>
> update_rq_clock_task
> --> paravirt_steal_clock
> --> pv_time_ops.steal_clock
> --> native_steal_clock (if in Xen)
> --> 0
>
> The fundamental solution is to implement a steal_clock in Xen(learn
> from KVM implementation) instead of using the native one.
>
> Tony
>

Also, I tried the latest long term version of Linux 4.4, this issue
still exists there. Hoping the next version can add this patch.

Tony


>> -boris
>>
>>>  - other ideas? Tony?
>>>
>>> Dario
>>
>>

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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Tony S

On Wed, May 18, 2016 at 11:20 AM, Boris Ostrovsky
 wrote:
> On 05/18/2016 12:10 PM, Dario Faggioli wrote:
>> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote:
>>> On 18/05/16 16:46, Boris Ostrovsky wrote:

 Won't we be accounting for stolen cycles twice now --- once from
 steal_account_process_tick()->steal_clock() and second time from
 do_stolen_accounting()?
>>> Uuh, yes.
>>>
>>> I guess I should rip do_stolen_accounting() out, too? It is a
>>> Xen-specific hack, so I guess nobody will cry. Maybe it would be a
>>> good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?
>>>
>> So, config options aside, if I understand this correctly, it looks like
>> we were actually already doing steal time accounting, although in a
>> non-standard way.
>>
>> And yet, people seem to have issues relating to lack of (proper?) steal
>> time accounting (Cc-ing Tony).
>>
>> I guess this means that, either:
>>  - the issue being reported is actually not caused by the lack of
>>steal time accounting,
>>  - our current (Xen specific) steal time accounting solution is flawed,
>>  - the issue is caused by the lack of the bit of steal time accounting
>>that we do not support yet,
>
> I believe it's this one.
>
> Tony narrowed the problem down to update_curr() where vruntime is
> calculated, based on runqueue's clock_task value. That value is computed
> in update_rq_clock_task(), which needs paravirt_steal_rq_enabled.
>

Hi Boris,

You are right.

The real problem is steal_clock in pv_time_ops is implemented in KVM
but not in Xen.

arch/x86/include/asm/paravirt_types.h
struct pv_time_ops {
unsigned long long (*sched_clock)(void);
unsigned long long (*steal_clock)(int cpu);
unsigned long (*get_tsc_khz)(void);
};


(1) KVM implemented both sched_clock and steal_clock.

arch/x86/kernel/kvmclock.c
pv_time_ops.sched_clock = kvm_clock_read;

arch/x86/kernel/kvm.c
pv_time_ops.steal_clock = kvm_steal_clock;


(2) However, Xen just implemented sched_clock while the steal_clock is
still native_steal_clock(). The function native_steal_clock() just
simply return 0.

arch/x86/xen/time.c
.sched_clock = xen_clocksource_read;

arch/x86/kernel/paravirt.c
static u64 native_steal_clock(int cpu)
{
 return 0;
}


Therefore, even though update_rq_clock_task() calculates the value and
paravirt_steal_rq_enabled option is enabled, the steal value just
returns 0. This will cause the problem which I mentioned.

update_rq_clock_task
--> paravirt_steal_clock
--> pv_time_ops.steal_clock
--> native_steal_clock (if in Xen)
--> 0

The fundamental solution is to implement a steal_clock in Xen(learn
from KVM implementation) instead of using the native one.

Tony

> -boris
>
>>  - other ideas? Tony?
>>
>> Dario
>
>

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

Re: [Xen-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-18 Thread Julien Grall


Hello Andrii,

Thank you for your series. For the next version, can you CC the relevant 
maintainers using scripts/get_maintainer.pl for each patch?


Regards,

On 18/05/2016 17:32, Andrii Anisov wrote:

This series RFC patches from the currently ongoing production project.
This patch series presents changes needed to fit the system into
customer requirements as well as workaround limitations of the
Jacinto6 SoC.
This patch series is not a full production branch upstream. Lacks of
the board specific patches as well as new PV drivers interfaces.
Patches for new PV drivers interfaces will be submitted soon.

Andrii Anisov (1):
  xen/tools: Fix virtual disks helper scripts.

Andrii Tseglytskyi (2):
  xen/arm: allow to allocate 1/128/256/512 Mb memory chunks
  xen/arm: allow reassigning of hw interrupts to guest domain

Iurii Konovalenko (3):
  arm: Fix 1-to-1 Dom0 memory allocation of any size
  arm: Add ability to relocate Xen in over 4GB space
  arm: Add ability to allocate Xen heap in lowmem

Iurii Mykhalskyi (3):
  xen: flask: Add possiblity to forward irqs into domU domains
  xen: Add dom0_mem_high option & over 4GB memory allocation for Dom0
  tools: Introduce ARM32_SEPAR_MEM_SPLIT option

Oleksandr Dmytryshyn (3):
  tools: Allow to cross-compile xentop
  xen: arm: add batch support to the XENMEM_p2m_lookup operation
  xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

Oleksandr Tyshchenko (1):
  libxl: add ability to set rambase_pfn via cfg file

Sergiy Kibrik (1):
  kbdif: add raw events passing

Viktor Kleinik (4):
  libxl: parse config data during domain reboot
  tools/misc: Modify Xen watchdog daemon
  tools/misc: Set timeout value from watchdog daemon
  libxl: Fix unneeded domain reboot during destroy routine

 tools/flask/policy/policy/modules/xen/xen.te |   1 +
 tools/hotplug/Linux/block|   2 +-
 tools/hotplug/Linux/locking.sh   |   9 +-
 tools/hotplug/Linux/xen-hotplug-common.sh.in |   2 +-
 tools/libxc/Makefile |   2 +
 tools/libxc/include/xc_dom.h |  24 ++-
 tools/libxc/xc_dom_arm.c | 103 +++-
 tools/libxc/xc_dom_compat_linux.c|   5 +
 tools/libxc/xc_dom_core.c|  51 +-
 tools/libxl/Makefile |   2 +
 tools/libxl/libxl.c  |   4 +
 tools/libxl/libxl_arm.c  |  21 ++-
 tools/libxl/libxl_create.c   |   5 +
 tools/libxl/libxl_dom.c  |  29 +++-
 tools/libxl/libxl_internal.h |   1 +
 tools/libxl/libxl_types.idl  |   2 +
 tools/libxl/xl_cmdimpl.c |  33 
 tools/misc/xenwatchdogd.c|  54 ++-
 tools/xenstat/Makefile   |   4 +-
 tools/xenstore/init-xenstore-domain.c|   5 +
 xen/Rules.mk |   3 +
 xen/arch/arm/arm32/head.S|  21 ++-
 xen/arch/arm/domain_build.c  | 224 ++-
 xen/arch/arm/irq.c   |  19 ++-
 xen/arch/arm/kernel.h|   9 ++
 xen/arch/arm/mm.c|  33 
 xen/arch/arm/platforms/omap5.c   |  17 +-
 xen/arch/arm/platforms/rcar2.c   |   9 +-
 xen/arch/arm/setup.c |  35 -
 xen/arch/arm/smpboot.c   |  33 +++-
 xen/common/memory.c  |  16 +-
 xen/common/page_alloc.c  |  91 +--
 xen/include/public/io/kbdif.h|  10 ++
 xen/include/public/memory.h  |  18 ++-
 xen/include/xen/mm.h |   8 +
 35 files changed, 801 insertions(+), 104 deletions(-)



--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Boris Ostrovsky

On 05/18/2016 12:10 PM, Dario Faggioli wrote:
> On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>>  
>>> Won't we be accounting for stolen cycles twice now --- once from
>>> steal_account_process_tick()->steal_clock() and second time from
>>> do_stolen_accounting()?
>> Uuh, yes.
>>
>> I guess I should rip do_stolen_accounting() out, too? It is a
>> Xen-specific hack, so I guess nobody will cry. Maybe it would be a
>> good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?
>>
> So, config options aside, if I understand this correctly, it looks like
> we were actually already doing steal time accounting, although in a
> non-standard way.
>
> And yet, people seem to have issues relating to lack of (proper?) steal
> time accounting (Cc-ing Tony).
>
> I guess this means that, either:
>  - the issue being reported is actually not caused by the lack of 
>steal time accounting,
>  - our current (Xen specific) steal time accounting solution is flawed,
>  - the issue is caused by the lack of the bit of steal time accounting
>that we do not support yet,

I believe it's this one.

Tony narrowed the problem down to update_curr() where vruntime is
calculated, based on runqueue's clock_task value. That value is computed
in update_rq_clock_task(), which needs paravirt_steal_rq_enabled.

-boris

>  - other ideas? Tony?
>
> Dario



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

[Xen-devel] [PATCH RFC 00/18] System adjustment to customer needs.

2016-05-18 Thread Andrii Anisov

This series RFC patches from the currently ongoing production project.
This patch series presents changes needed to fit the system into
customer requirements as well as workaround limitations of the
Jacinto6 SoC.
This patch series is not a full production branch upstream. Lacks of
the board specific patches as well as new PV drivers interfaces.
Patches for new PV drivers interfaces will be submitted soon.

Andrii Anisov (1):
  xen/tools: Fix virtual disks helper scripts.

Andrii Tseglytskyi (2):
  xen/arm: allow to allocate 1/128/256/512 Mb memory chunks
  xen/arm: allow reassigning of hw interrupts to guest domain

Iurii Konovalenko (3):
  arm: Fix 1-to-1 Dom0 memory allocation of any size
  arm: Add ability to relocate Xen in over 4GB space
  arm: Add ability to allocate Xen heap in lowmem

Iurii Mykhalskyi (3):
  xen: flask: Add possiblity to forward irqs into domU domains
  xen: Add dom0_mem_high option & over 4GB memory allocation for Dom0
  tools: Introduce ARM32_SEPAR_MEM_SPLIT option

Oleksandr Dmytryshyn (3):
  tools: Allow to cross-compile xentop
  xen: arm: add batch support to the XENMEM_p2m_lookup operation
  xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

Oleksandr Tyshchenko (1):
  libxl: add ability to set rambase_pfn via cfg file

Sergiy Kibrik (1):
  kbdif: add raw events passing

Viktor Kleinik (4):
  libxl: parse config data during domain reboot
  tools/misc: Modify Xen watchdog daemon
  tools/misc: Set timeout value from watchdog daemon
  libxl: Fix unneeded domain reboot during destroy routine

 tools/flask/policy/policy/modules/xen/xen.te |   1 +
 tools/hotplug/Linux/block|   2 +-
 tools/hotplug/Linux/locking.sh   |   9 +-
 tools/hotplug/Linux/xen-hotplug-common.sh.in |   2 +-
 tools/libxc/Makefile |   2 +
 tools/libxc/include/xc_dom.h |  24 ++-
 tools/libxc/xc_dom_arm.c | 103 +++-
 tools/libxc/xc_dom_compat_linux.c|   5 +
 tools/libxc/xc_dom_core.c|  51 +-
 tools/libxl/Makefile |   2 +
 tools/libxl/libxl.c  |   4 +
 tools/libxl/libxl_arm.c  |  21 ++-
 tools/libxl/libxl_create.c   |   5 +
 tools/libxl/libxl_dom.c  |  29 +++-
 tools/libxl/libxl_internal.h |   1 +
 tools/libxl/libxl_types.idl  |   2 +
 tools/libxl/xl_cmdimpl.c |  33 
 tools/misc/xenwatchdogd.c|  54 ++-
 tools/xenstat/Makefile   |   4 +-
 tools/xenstore/init-xenstore-domain.c|   5 +
 xen/Rules.mk |   3 +
 xen/arch/arm/arm32/head.S|  21 ++-
 xen/arch/arm/domain_build.c  | 224 ++-
 xen/arch/arm/irq.c   |  19 ++-
 xen/arch/arm/kernel.h|   9 ++
 xen/arch/arm/mm.c|  33 
 xen/arch/arm/platforms/omap5.c   |  17 +-
 xen/arch/arm/platforms/rcar2.c   |   9 +-
 xen/arch/arm/setup.c |  35 -
 xen/arch/arm/smpboot.c   |  33 +++-
 xen/common/memory.c  |  16 +-
 xen/common/page_alloc.c  |  91 +--
 xen/include/public/io/kbdif.h|  10 ++
 xen/include/public/memory.h  |  18 ++-
 xen/include/xen/mm.h |   8 +
 35 files changed, 801 insertions(+), 104 deletions(-)

-- 
2.8.2


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

[Xen-devel] [PATCH RFC 14/18] xen: flask: Add possiblity to forward irqs into domU domains

2016-05-18 Thread Andrii Anisov

From: Iurii Mykhalskyi 

Looks like that from 4.6 version, Xen didn't allow irq forwarding
into DomU domains - in our setup we forward list of them, so we need
to changed the policy.

Signed-off-by: Iurii Mykhalskyi 
---
 tools/flask/policy/policy/modules/xen/xen.te | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index 5e94ee3..b3eaa15 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -116,6 +116,7 @@ admin_device(dom0_t, device_t)
 admin_device(dom0_t, irq_t)
 admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
+admin_device(domU_t, irq_t);
 
 domain_comms(dom0_t, dom0_t)
 
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 17/18] tools: Introduce ARM32_SEPAR_MEM_SPLIT option

2016-05-18 Thread Andrii Anisov

From: Iurii Mykhalskyi 

This option enables separate memory allocation in
low & over 4GB address space.
With this option enabled in domain config files
"memory" parameter are used to specify domain low memory
"memory_high" - to specify over 4GB allocated memory

If you didn't specify high memory with this option enabled,
domain memory will be limited to 4GB (zone 20)

Signed-off-by: Iurii Mykhalskyi 
Signed-off-by: Iurii Konovalenko 
---
 tools/libxc/Makefile  |  2 ++
 tools/libxc/include/xc_dom.h  | 24 +++--
 tools/libxc/xc_dom_arm.c  | 66 +++
 tools/libxc/xc_dom_compat_linux.c |  5 +++
 tools/libxc/xc_dom_core.c | 51 ++-
 tools/libxl/Makefile  |  2 ++
 tools/libxl/libxl_arm.c   | 11 ++
 tools/libxl/libxl_dom.c   | 23 
 tools/libxl/libxl_types.idl   |  1 +
 tools/libxl/xl_cmdimpl.c  |  5 +++
 tools/xenstore/init-xenstore-domain.c |  5 +++
 xen/arch/arm/domain_build.c   | 11 +-
 xen/common/memory.c   | 16 -
 xen/common/page_alloc.c   | 23 
 xen/include/public/memory.h   |  6 
 xen/include/xen/mm.h  |  6 
 16 files changed, 245 insertions(+), 12 deletions(-)

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index a0f899b..84d21b6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -112,6 +112,8 @@ CFLAGS   += -I. -I./include $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS-$(ARM32_SEPAR_MEM_SPLIT) += -DARM32_SEPAR_MEM_SPLIT
+
 CFLAGS += $(PTHREAD_CFLAGS)
 
 CTRL_LIB_OBJS := $(patsubst %.c,%.o,$(CTRL_SRCS-y))
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 600aef6..10bb6ab 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -129,12 +129,22 @@ struct xc_dom_image {
  * in rambase_pfn.
  */
 xen_pfn_t rambase_pfn;
+#ifndef ARM32_SEPAR_MEM_SPLIT
 xen_pfn_t total_pages;
+#else
+xen_pfn_t low_mem_pages;
+xen_pfn_t high_mem_pages;
+#endif
 xen_pfn_t p2m_size; /* number of pfns covered by p2m */
 struct xc_dom_phys *phys_pages;
 int realmodearea_log;
 #if defined (__arm__) || defined(__aarch64__)
+#ifndef ARM32_SEPAR_MEM_SPLIT
 xen_pfn_t rambank_size[GUEST_RAM_BANKS];
+#else
+xen_pfn_t rambank_size_low[GUEST_RAM_BANKS];
+xen_pfn_t rambank_size_high[GUEST_RAM_BANKS];
+#endif
 #endif
 
 /* malloc memory pool */
@@ -181,6 +191,12 @@ struct xc_dom_image {
 int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
 };
 
+#ifndef ARM32_SEPAR_MEM_SPLIT
+#define XC_DOM_TOTAL_PAGES(dom) ((dom)->total_pages)
+#else
+#define XC_DOM_TOTAL_PAGES(dom) ((dom)->low_mem_pages + (dom)->high_mem_pages)
+#endif
+
 /* --- pluggable kernel loader - */
 
 struct xc_dom_loader {
@@ -228,7 +244,11 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
 void xc_dom_release_phys(struct xc_dom_image *dom);
 void xc_dom_release(struct xc_dom_image *dom);
 int xc_dom_rambase_init(struct xc_dom_image *dom, uint64_t rambase);
+#ifndef ARM32_SEPAR_MEM_SPLIT
 int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb);
+#else
+int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb_low, 
unsigned int mem_mb_high);
+#endif
 
 /* Set this larger if you have enormous ramdisks/kernels. Note that
  * you should trust all kernels not to be maliciously large (e.g. to
@@ -379,7 +399,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image 
*dom, xen_pfn_t pfn)
 {
 if (dom->shadow_enabled)
 return pfn;
-if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
+if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + 
XC_DOM_TOTAL_PAGES(dom))
 return INVALID_MFN;
 return dom->p2m_host[pfn - dom->rambase_pfn];
 }
@@ -389,7 +409,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct 
xc_dom_image *dom,
 {
 if (xc_dom_feature_translated(dom))
 return pfn;
-if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
+if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + 
XC_DOM_TOTAL_PAGES(dom))
 return INVALID_MFN;
 return dom->p2m_host[pfn - dom->rambase_pfn];
 }
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 96df669..d995241 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -306,8 +306,19 @@ static int populate_one_size(struct xc_dom_image *dom, int 
pfn_shift,
 for ( i = 0 ; i < count ; i ++ )
 extents[i] = base_pfn + (iguest_domid, count,
+pfn_shift, XENMEMF_only_low_mem, extents);
+} else {
+nr = xc_domain_populate_physmap(dom->xch, dom->guest_domid, count,
+

[Xen-devel] [PATCH RFC 11/18] arm: Fix 1-to-1 Dom0 memory allocation of any size

2016-05-18 Thread Andrii Anisov

From: Iurii Konovalenko 

For Dom0 with non-power-two memory size less then 128M allocation
of first memory bank fails. This patch fix it.

Signed-off-by: Iurii Konovalenko 
---
 xen/arch/arm/domain_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a059de6..2937ff7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -244,7 +244,7 @@ fail:
 static void allocate_memory_11(struct domain *d, struct kernel_info *kinfo)
 {
 const unsigned int min_low_order =
-get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
+get_11_allocation_size(min_t(paddr_t, dom0_mem, MB(128)));
 const unsigned int min_order = get_order_from_bytes(MB(4));
 struct page_info *pg;
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 18/18] arm: Add ability to allocate Xen heap in lowmem

2016-05-18 Thread Andrii Anisov

From: Iurii Konovalenko 

Add abiliyty to allocate Xen heap in 32-bit address range for ARM32.
Due to architecture features some ARM32 platforms require Xen heap
to be allocated in lowmem.

Signed-off-by: Iurii Konovalenko 
---
 xen/Rules.mk |  1 +
 xen/arch/arm/setup.c | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 51f7124..30f5227 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -66,6 +66,7 @@ CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB
 CFLAGS-$(ARM32_SEPAR_MEM_SPLIT) += -DARM32_SEPAR_MEM_SPLIT
+CFLAGS-$(ARM32_XENHEAP_IN_LOWMEM) += -DARM32_XENHEAP_IN_LOWMEM
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7e507bc..5510a34 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -475,7 +475,11 @@ static void init_pdx(void)
 #ifdef CONFIG_ARM_32
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 {
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+paddr_t ram_start, ram_end, ram_size, dma32_end;
+#else
 paddr_t ram_start, ram_end, ram_size;
+#endif
 paddr_t s, e;
 unsigned long ram_pages;
 unsigned long heap_pages, xenheap_pages, domheap_pages;
@@ -492,6 +496,9 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 ram_start = bootinfo.mem.bank[0].start;
 ram_size  = bootinfo.mem.bank[0].size;
 ram_end   = ram_start + ram_size;
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+dma32_end = ram_end > 0x1ULL ? 0 : ram_end;
+#endif
 
 for ( i = 1; i < bootinfo.mem.nr_banks; i++ )
 {
@@ -502,6 +509,9 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 ram_size  = ram_size + bank_size;
 ram_start = min(ram_start,bank_start);
 ram_end   = max(ram_end,bank_end);
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+dma32_end = bank_end > 0x1ULL ? dma32_end : bank_end;
+#endif
 }
 
 total_pages = ram_pages = ram_size >> PAGE_SHIFT;
@@ -530,7 +540,11 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
 
 do
 {
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+e = consider_modules(ram_start, dma32_end,
+#else
 e = consider_modules(ram_start, ram_end,
+#endif
  pfn_to_paddr(xenheap_pages),
  32<<20, 0);
 if ( e )
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 16/18] xen: Add dom0_mem_high option & over 4GB memory allocation for Dom0

2016-05-18 Thread Andrii Anisov

From: Iurii Mykhalskyi 

Add support of custom allocation of over 4GB memory for Dom0. Requested
memory size might be specified by passing dom0_mem_high option in Xen
cmdline

Signed-off-by: Iurii Mykhalskyi 
---
 xen/Rules.mk|   1 +
 xen/arch/arm/domain_build.c | 189 +++-
 xen/arch/arm/kernel.h   |   9 +++
 3 files changed, 198 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index fbd34a5..51f7124 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -65,6 +65,7 @@ CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB
+CFLAGS-$(ARM32_SEPAR_MEM_SPLIT) += -DARM32_SEPAR_MEM_SPLIT
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f06792e..a63958b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -35,6 +35,11 @@ int dom0_11_mapping = 1;
 #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
 static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
 
+#ifdef ARM32_SEPAR_MEM_SPLIT
+#define DOM0_MEM_HIGH_DEFAULT 0x0 /* 0 MiB */
+static u64 __initdata dom0_mem_high = DOM0_MEM_HIGH_DEFAULT;
+#endif
+
 static void __init parse_dom0_mem(const char *s)
 {
 dom0_mem = parse_size_and_unit(s, &s);
@@ -43,6 +48,14 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
+#ifdef ARM32_SEPAR_MEM_SPLIT
+static void __init parse_dom0_mem_high(const char *s)
+{
+dom0_mem_high = parse_size_and_unit(s, &s);
+}
+custom_param("dom0_mem_high", parse_dom0_mem_high);
+#endif
+
 //#define DEBUG_DT
 
 #ifdef DEBUG_DT
@@ -130,7 +143,11 @@ static bool_t insert_11_bank(struct domain *d,
 if ( res )
 panic("Failed map pages to DOM0: %d", res);
 
+#ifndef ARM32_SEPAR_MEM_SPLIT
 kinfo->unassigned_mem -= size;
+#else
+kinfo->unassigned_mem.low -= size;
+#endif
 
 if ( kinfo->mem.nr_banks == 0 )
 {
@@ -192,6 +209,82 @@ fail:
 return false;
 }
 
+#ifdef ARM32_SEPAR_MEM_SPLIT
+static void allocate_dom0_high_memory(struct domain *d, struct kernel_info 
*kinfo)
+{
+int i, res, st_banks = kinfo->mem.nr_banks;
+struct page_info *pg = NULL;
+int bits;
+unsigned int order = get_11_allocation_size(dom0_mem_high);
+const unsigned int min_order = get_order_from_bytes(MB(4));
+paddr_t spfn;
+paddr_t start, size;
+struct membank *bank = NULL;
+
+if (dom0_mem_high == 0)
+return;
+
+printk("Allocating %ldMB of high memory region for dom0\n",
+(unsigned long)(dom0_mem_high >> 20));
+
+while ( kinfo->unassigned_mem.high && kinfo->mem.nr_banks < NR_MEM_BANKS )
+{
+for (bits = PADDR_BITS ; bits >= min_order; bits-- )
+{
+pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
+if ( pg != NULL )
+break;
+}
+
+if ( !pg )
+{
+order --;
+if ( order >= min_order )
+continue;
+
+/* No more we can do */
+break;
+}
+
+spfn = page_to_mfn(pg);
+start = pfn_to_paddr(spfn);
+size = pfn_to_paddr((1 << order));
+
+res = guest_physmap_add_page(d, spfn, spfn, order);
+if ( res )
+panic("Failed map pages to DOM0: %d", res);
+
+kinfo->unassigned_mem.high -= size;
+
+bank = &kinfo->mem.bank[kinfo->mem.nr_banks];
+
+bank->start = start;
+bank->size = size;
+kinfo->mem.nr_banks++;
+
+/*
+ * Success, next time around try again to get the largest order
+ * allocation possible.
+ */
+
+order = get_11_allocation_size(kinfo->unassigned_mem.high);
+ }
+
+if(kinfo->unassigned_mem.high)
+panic("Unable to allocate high memory bank");
+
+for( i = st_banks; i < kinfo->mem.nr_banks; i++ )
+{
+printk("BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+   i,
+   kinfo->mem.bank[i].start,
+   kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+   /* Don't want format this as PRIpaddr (16 digit hex) */
+   (unsigned long)(kinfo->mem.bank[i].size >> 20));
+}
+}
+#endif
+
 /*
  * This is all pretty horrible.
  *
@@ -250,9 +343,13 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 get_11_allocation_size(min_t(paddr_t, dom0_mem, MB(128)));
 const unsigned int min_order = get_order_from_bytes(MB(4));
 struct page_info *pg;
-unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 u64 rambase_pfn = opt_dom0_rambase_pfn;
+#ifndef ARM32_SEPAR_MEM_SPLIT
+unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 paddr_t mem_size = kinfo->una

[Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

2016-05-18 Thread Andrii Anisov

From: Oleksandr Dmytryshyn 

This setting is used to adjust starting memory address allocated
for kernel Dom0. To use 'rambase_pfn' setting just add for example
'dom0_rambase_pfn=0x8' to the hypervisor command line. Note that
'dom0_rambase_pfn' should be aligned with the smallest memory chunk
which use xen memory allocator.

Signed-off-by: Oleksandr Dmytryshyn 
---
 xen/arch/arm/domain_build.c | 24 +---
 xen/common/page_alloc.c | 68 +++--
 xen/include/xen/mm.h|  2 ++
 3 files changed, 75 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2937ff7..b48718d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -27,6 +27,9 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+static u64 __initdata opt_dom0_rambase_pfn = 0;
+integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
+
 int dom0_11_mapping = 1;
 
 #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
@@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 const unsigned int min_order = get_order_from_bytes(MB(4));
 struct page_info *pg;
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+u64 rambase_pfn = opt_dom0_rambase_pfn;
+paddr_t mem_size = kinfo->unassigned_mem;
 int i;
 
 bool_t lowmem = is_32bit_domain(d);
@@ -267,7 +272,7 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 {
 for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
 {
-pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
+pg = alloc_domheap_pages_pfn(d, order, MEMF_bits(bits), 
rambase_pfn);
 if ( pg != NULL )
 goto got_bank0;
 }
@@ -284,16 +289,21 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 /* Now allocate more memory and fill in additional banks */
 
 order = get_11_allocation_size(kinfo->unassigned_mem);
+if ( opt_dom0_rambase_pfn )
+rambase_pfn += (mem_size - kinfo->unassigned_mem) >> PAGE_SHIFT;
+
 while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
 {
-pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
+pg = alloc_domheap_pages_pfn(d, order, lowmem ? MEMF_bits(32) : 0,
+ rambase_pfn);
 if ( !pg )
 {
 order --;
 
 if ( lowmem && order < min_low_order)
 {
-D11PRINT("Failed at min_low_order, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Failed at min_low_order, allow high 
allocations\n");
 order = get_11_allocation_size(kinfo->unassigned_mem);
 lowmem = false;
 continue;
@@ -313,7 +323,8 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 
 if ( lowmem )
 {
-D11PRINT("Allocation below bank 0, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Allocation below bank 0, allow high 
allocations\n");
 order = get_11_allocation_size(kinfo->unassigned_mem);
 lowmem = false;
 continue;
@@ -330,6 +341,11 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
  * allocation possible.
  */
 order = get_11_allocation_size(kinfo->unassigned_mem);
+if ( opt_dom0_rambase_pfn )
+{
+rambase_pfn += (mem_size - kinfo->unassigned_mem) >> PAGE_SHIFT;
+mem_size = kinfo->unassigned_mem;
+}
 }
 
 if ( kinfo->unassigned_mem )
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 74fc1de..d0c0fbb 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -583,16 +583,17 @@ static void check_low_mem_virq(void)
 }
 }
 
-/* Allocate 2^@order contiguous pages. */
-static struct page_info *alloc_heap_pages(
+/* Allocate 2^@order contiguous pages at given pfn. */
+static struct page_info *alloc_heap_pages_pfn(
 unsigned int zone_lo, unsigned int zone_hi,
 unsigned int order, unsigned int memflags,
-struct domain *d)
+struct domain *d, xen_pfn_t pfn)
 {
 unsigned int i, j, zone = 0, nodemask_retry = 0;
 nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
 unsigned long request = 1UL << order;
-struct page_info *pg;
+struct page_info *pg, *tmp_pg;
+struct page_list_head *pg_list;
 nodemask_t nodemask = (d != NULL ) ? d->node_affinity : node_online_map;
 bool_t need_tlbflush = 0;
 uint32_t tlbflush_timestamp = 0;
@@ -657,9 +658,25 @@ static struct page_info *alloc_heap_pages(
 continue;

[Xen-devel] [PATCH RFC 10/18] xen: arm: add batch support to the XENMEM_p2m_lookup operation

2016-05-18 Thread Andrii Anisov

From: Oleksandr Dmytryshyn 

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Iurii Konovalenko 
---
 xen/arch/arm/mm.c   | 33 +
 xen/include/public/memory.h | 12 +++-
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b5d8c85..04fb813 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1150,10 +1150,43 @@ int xenmem_add_to_physmap_one(
 return rc;
 }
 
+#define MAX_P2M_ENTRIES_CNT 1
+
+static long arch_paddr_to_maddr_batch(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_p2m_lookup p2mr;
+xen_pfn_t paddr, maddr;
+unsigned int i;
+
+if ( copy_from_guest(&p2mr, arg, 1) )
+return -EFAULT;
+
+if (p2mr.count < 1 || p2mr.count > MAX_P2M_ENTRIES_CNT)
+return -EINVAL;
+
+if ( guest_handle_is_null(p2mr.paddrs) ||
+ guest_handle_is_null(p2mr.maddrs))
+return -EINVAL;
+
+for ( i = 0; i < p2mr.count; i++ )
+{
+if ( unlikely(__copy_from_guest_offset(&paddr, p2mr.paddrs, i, 1)) )
+return -EFAULT;
+
+maddr = p2m_lookup(current->domain, paddr, NULL);
+
+if ( unlikely(__copy_to_guest_offset(p2mr.maddrs, i, &maddr, 1)) )
+return -EFAULT;
+}
+return 0;
+}
+
 long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 switch ( op )
 {
+case XENMEM_p2m_lookup:
+return arch_paddr_to_maddr_batch(arg);
 /* XXX: memsharing not working yet */
 case XENMEM_get_sharing_shared_pages:
 case XENMEM_get_sharing_freed_pages:
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 320de91..dfc5171 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -608,7 +608,17 @@ struct xen_vnuma_topology_info {
 typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
 DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
 
-/* Next available subop number is 28 */
+struct xen_p2m_lookup {
+uint32_t count;
+XEN_GUEST_HANDLE(xen_pfn_t) paddrs; /* IN:  physical addresses */
+XEN_GUEST_HANDLE(xen_pfn_t) maddrs; /* OUT: machine addresses */
+};
+typedef struct xen_p2m_lookup xen_p2m_lookup_t;
+DEFINE_XEN_GUEST_HANDLE(xen_p2m_lookup_t);
+
+#define XENMEM_p2m_lookup 28
+
+/* Next available subop number is 29 */
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 12/18] libxl: Fix unneeded domain reboot during destroy routine

2016-05-18 Thread Andrii Anisov

From: Viktor Kleinik 

During domain destroy we should change its state from "alive"
to "dying" to prevent reboot because of watchdog timeout.

Signed-off-by: Viktor Kleinik 
---
 tools/libxl/libxl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1366177..ac50bda 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1634,6 +1634,10 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 dis->drs.callback = devices_destroy_cb;
 dis->drs.force = 1;
 libxl__devices_destroy(egc, &dis->drs);
+rc = xc_domain_destroy(ctx->xch, domid);
+if (rc < 0) {
+LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy 
failed for %d", domid);
+}
 return;
 
 out:
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 03/18] xen/arm: allow to allocate 1/128/256/512 Mb memory chunks

2016-05-18 Thread Andrii Anisov

From: Andrii Tseglytskyi 

This is done to allow possibility of having 1 to 1 memory mapping chunks
with size 1/128/256/512 Mb what can sagnificantly decrease time of memory
allocation and fragmentation for 1-to-1 mapped domains.

Signed-off-by: Andrii Tseglytskyi 
Signed-off-by: Iurii Konovalenko 
---
 tools/libxc/xc_dom_arm.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index aeaba54..5ee8eef 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -33,7 +33,11 @@
 #define LPAE_SHIFT 9
 
 #define PFN_4K_SHIFT  (0)
+#define PFN_1M_SHIFT  (PFN_4K_SHIFT + 8)
 #define PFN_2M_SHIFT  (PFN_4K_SHIFT+LPAE_SHIFT)
+#define PFN_128M_SHIFT  (PFN_2M_SHIFT + 6)
+#define PFN_256M_SHIFT  (PFN_128M_SHIFT + 1)
+#define PFN_512M_SHIFT  (PFN_256M_SHIFT + 1)
 #define PFN_1G_SHIFT  (PFN_2M_SHIFT+LPAE_SHIFT)
 #define PFN_512G_SHIFT (PFN_1G_SHIFT+LPAE_SHIFT)
 
@@ -359,11 +363,31 @@ static int populate_guest_memory(struct xc_dom_image *dom,
 if ( rc < 0 ) break;
 if ( rc > 0 ) continue;
 
+rc = populate_one_size(dom, PFN_512M_SHIFT,
+   base_pfn + pfn, &allocsz, extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
+rc = populate_one_size(dom, PFN_256M_SHIFT,
+   base_pfn + pfn, &allocsz, extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
+rc = populate_one_size(dom, PFN_128M_SHIFT,
+   base_pfn + pfn, &allocsz, extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
 rc = populate_one_size(dom, PFN_2M_SHIFT,
base_pfn + pfn, &allocsz, extents);
 if ( rc < 0 ) break;
 if ( rc > 0 ) continue;
 
+rc = populate_one_size(dom, PFN_1M_SHIFT,
+   base_pfn + pfn, &allocsz, extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
 rc = populate_one_size(dom, PFN_4K_SHIFT,
base_pfn + pfn, &allocsz, extents);
 if ( rc < 0 ) break;
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 06/18] libxl: parse config data during domain reboot

2016-05-18 Thread Andrii Anisov

From: Viktor Kleinik 

We need to parse config data during domain reboot
to get correct I/O memory regions for mapping.

Signed-off-by: Viktor Kleinik 
---
 tools/libxl/xl_cmdimpl.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 28d57c3..98a46bc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2988,6 +2988,21 @@ start:
 d_config.c_info.name = strdup(common_domname);
 }
 
+   if (config_file) {
+   libxl_domain_config_init(&d_config);
+
+   ret = libxl_read_file_contents(ctx, config_file,
+  &config_data, &config_len);
+   if (ret) {
+   LOG("Failed to read config file: %s: %s\n",
+   config_file, strerror(errno));
+   goto out;
+   }
+
+   parse_config_data(config_file, config_data, config_len,
+ &d_config);
+   }
+
 /*
  * XXX FIXME: If this sleep is not there then domain
  * re-creation fails sometimes.
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 01/18] xen/tools: Fix virtual disks helper scripts.

2016-05-18 Thread Andrii Anisov

This patch makes virtual disks helper scripts be functional
in busybox environment. Actually we call sh insteand of bash and
rewrite loop with counter to be properly parsed by ash.

Signed-off-by: Andrii Anisov 
Signed-off-by: Andrii Tseglytskyi 
---
 tools/hotplug/Linux/block| 2 +-
 tools/hotplug/Linux/locking.sh   | 9 +++--
 tools/hotplug/Linux/xen-hotplug-common.sh.in | 2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/hotplug/Linux/block b/tools/hotplug/Linux/block
index 8d2ee9d..6a725db 100644
--- a/tools/hotplug/Linux/block
+++ b/tools/hotplug/Linux/block
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 dir=$(dirname "$0")
 . "$dir/block-common.sh"
diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
index c6a7e96..b8e9515 100644
--- a/tools/hotplug/Linux/locking.sh
+++ b/tools/hotplug/Linux/locking.sh
@@ -23,9 +23,14 @@ LOCK_BASEDIR=/var/run/xen-hotplug
 
 _setlockfd()
 {
+local lock_
 local i
-for ((i = 0; i < ${#_lockdict}; i++))
-do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
+let i=0
+
+for lock_ in _lockdict ;
+do
+[ -z "$lock_" -o "$lock_" = "$1" ] && break
+(( i++ ))
 done
 _lockdict[$i]="$1"
 let _lockfd=200+i
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh.in 
b/tools/hotplug/Linux/xen-hotplug-common.sh.in
index d5d0b69..42e46e3 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh.in
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh.in
@@ -51,7 +51,7 @@ sigerr() {
   fatal "$0 failed; error detected."
 }
 
-trap sigerr ERR
+#trap sigerr ERR
 
 
 ##
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 15/18] arm: Add ability to relocate Xen in over 4GB space

2016-05-18 Thread Andrii Anisov

From: Iurii Konovalenko 

Move Xen to the end of physical memory

Signed-off-by: Iurii Konovalenko 
---
 xen/Rules.mk   |  1 +
 xen/arch/arm/arm32/head.S  | 21 -
 xen/arch/arm/domain_build.c|  2 +-
 xen/arch/arm/platforms/omap5.c | 17 ++---
 xen/arch/arm/platforms/rcar2.c |  9 -
 xen/arch/arm/setup.c   | 21 -
 xen/arch/arm/smpboot.c | 33 +
 7 files changed, 93 insertions(+), 11 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index feb08d6..fbd34a5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -64,6 +64,7 @@ CFLAGS-$(HAS_PCI)   += -DHAS_PCI
 CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e1f29bd..a644d6d 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -262,8 +262,21 @@ cpu_init_done:
 add   r4, r4, r10/* r4 := paddr (boot_pagetable) */
 mov   r5, #0 /* r4:r5 is paddr (boot_pagetable) */
 mcrr  CP64(r4, r5, HTTBR)
+#ifdef ARM32_RELOCATE_OVER_4GB
+teq   r7, #0
+beq   1f /* construct pagetable if CPU0 */
 
-/* Setup boot_pgtable: */
+/*Skip constructing TLBs for secondary CPUs, use constracted by CPU0*/
+PRINT("- Skip construction pagetable, using CPU0 table @")
+mov   r0, r5
+blputn
+mov   r0, r4
+blputn
+PRINT("  -\r\n")
+bne   skip_constructing
+#endif
+
+1:  /* Setup boot_pgtable: */
 ldr   r1, =boot_second
 add   r1, r1, r10/* r1 := paddr (boot_second) */
 
@@ -346,6 +359,7 @@ virtphys_clash:
 PRINT("- Unable to build boot page tables - virt and phys addresses 
clash. -\r\n")
 b fail
 
+skip_constructing:
 1:
 PRINT("- Turning on paging -\r\n")
 
@@ -427,6 +441,11 @@ paging:
  * setup in init_secondary_pagetables. */
 
 ldr   r4, =init_ttbr /* VA of HTTBR value stashed by CPU 0 */
+#ifdef ARM32_RELOCATE_OVER_4GB
+ldr   r1, =_start
+sub r4, r1
+add r4, #BOOT_RELOC_VIRT_START
+#endif
 ldrd  r4, r5, [r4]   /* Actual value */
 dsb
 mcrr  CP64(r4, r5, HTTBR)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b48718d..f06792e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1487,7 +1487,7 @@ static void __init find_gnttab_region(struct domain *d,
 if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames )
 panic("Cannot find a space for the grant table region\n");
 
-#ifdef CONFIG_ARM_32
+#if defined(CONFIG_ARM_32) && !defined(ARM32_RELOCATE_OVER_4GB)
 /*
  * The gnttab region must be under 4GB in order to work with DOM0
  * using short page table.
diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index a49ba62..fe77397 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -25,6 +25,10 @@
 #include 
 #include 
 
+#ifdef ARM32_RELOCATE_OVER_4GB
+extern paddr_t xen_relocation_offset;
+#endif
+
 static uint16_t num_den[8][2] = {
 { 0,  0 },  /* not used */
 {  26 *  64,  26 *  125 },  /* 12.0 Mhz */
@@ -132,9 +136,16 @@ static int __init omap5_smp_init(void)
 }
 
 printk("Set AuxCoreBoot1 to %"PRIpaddr" (%p)\n",
-   __pa(init_secondary), init_secondary);
-writel(__pa(init_secondary), wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
-
+   __pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+   , init_secondary);
+writel(__pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+   , wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
 printk("Set AuxCoreBoot0 to 0x20\n");
 writel(0x20, wugen_base + OMAP_AUX_CORE_BOOT_0_OFFSET);
 
diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
index bb25751..26973f6 100644
--- a/xen/arch/arm/platforms/rcar2.c
+++ b/xen/arch/arm/platforms/rcar2.c
@@ -25,6 +25,9 @@
 #define RCAR2_RAM_SIZE 0x1000
 #define RCAR2_SMP_START_OFFSET 0xFFC
 
+#ifdef ARM32_RELOCATE_OVER_4GB
+extern paddr_t xen_relocation_offset;
+#endif
 static int __init rcar2_smp_init(void)
 {
 void __iomem *pram;
@@ -38,7 +41,11 @@ static int __init rcar2_smp_init(void)
 }
 
 /* setup reset vectors */
-writel(__pa(init_secondary), pram + RCAR2_SMP_START_OFFSET);
+writel(__pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+

[Xen-devel] [PATCH RFC 08/18] tools/misc: Set timeout value from watchdog daemon

2016-05-18 Thread Andrii Anisov

From: Viktor Kleinik 

Signed-off-by: Viktor Kleinik 
---
 tools/misc/xenwatchdogd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 4b27628..fcf7d16 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -61,6 +61,10 @@ int main(int argc, char **argv)
err(1, "strtoul");
 }
 
+ret = ioctl(fd, WDIOC_SETTIMEOUT, &t);
+if (ret < 0)
+   err(1, "xenwatchdogd: Failed to set timeout\n");
+
 for (;;) {
ret = ioctl(fd, WDIOC_KEEPALIVE);
if (ret)
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 05/18] xen/arm: allow reassigning of hw interrupts to guest domain

2016-05-18 Thread Andrii Anisov

From: Andrii Tseglytskyi 

Patch allows reassigning of hardware interrupts from dom0 to
other guest domain.

Signed-off-by: Andrii Tseglytskyi 
Signed-off-by: Iurii Konovalenko 
---
 xen/arch/arm/irq.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 1f38605..c470613 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -481,12 +481,23 @@ int route_irq_to_guest(struct domain *d, unsigned int 
virq,
 }
 
 if ( test_bit(_IRQ_GUEST, &desc->status) )
-printk(XENLOG_G_ERR "IRQ %u is already used by domain %u\n",
-   irq, ad->domain_id);
+{
+printk(XENLOG_G_DEBUG "IRQ %u is reassigned from domain %u to 
domain %u\n",
+irq, ad->domain_id, d->domain_id);
+
+retval = gic_remove_irq_from_guest(ad, irq, desc);
+if ( retval )
+printk(XENLOG_G_ERR "failed to remove IRQ %u from domain %u 
(%d)\n",
+irq, ad->domain_id, retval);
+xfree(desc->action);
+desc->action = NULL;
+}
 else
+{
 printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
-retval = -EBUSY;
-goto out;
+   retval = -EBUSY;
+   goto out;
+}
 }
 
 retval = __setup_irq(desc, 0, action);
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 07/18] tools/misc: Modify Xen watchdog daemon

2016-05-18 Thread Andrii Anisov

From: Viktor Kleinik 

This change allows watchdog daemon to work thru watchdog device
on the file system.

Signed-off-by: Viktor Kleinik 
---
 tools/misc/xenwatchdogd.c | 52 +++
 1 file changed, 12 insertions(+), 40 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 254117b..4b27628 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -1,17 +1,17 @@
-
 #include 
 #include 
-#include "xenctrl.h"
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
+
+#define DEV_NAME "/dev/watchdog"
 
-xc_interface *h;
-int id = 0;
+int fd = -1;
 
 void daemonize(void)
 {
@@ -36,20 +36,6 @@ void daemonize(void)
 err(1, "reopen stderr");
 }
 
-void catch_exit(int sig)
-{
-if (id)
-xc_watchdog(h, id, 300);
-exit(0);
-}
-
-void catch_usr1(int sig)
-{
-if (id)
-xc_watchdog(h, id, 0);
-exit(0);
-}
-
 int main(int argc, char **argv)
 {
 int t, s;
@@ -60,9 +46,9 @@ int main(int argc, char **argv)
 
 daemonize();
 
-h = xc_interface_open(NULL, NULL, 0);
-if (h == NULL)
-   err(1, "xc_interface_open");
+fd = open(DEV_NAME, O_RDWR);
+if (fd < 0)
+err(1, "xenwatchdogd: Failed to open %s\n", DEV_NAME);
 
 t = strtoul(argv[1], NULL, 0);
 if (t == ULONG_MAX)
@@ -75,25 +61,11 @@ int main(int argc, char **argv)
err(1, "strtoul");
 }
 
-if (signal(SIGHUP, &catch_exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGINT, &catch_exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGQUIT, &catch_exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGTERM, &catch_exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGUSR1, &catch_usr1) == SIG_ERR)
-   err(1, "signal");
-
-id = xc_watchdog(h, 0, t);
-if (id <= 0)
-err(1, "xc_watchdog setup");
-
 for (;;) {
+   ret = ioctl(fd, WDIOC_KEEPALIVE);
+   if (ret)
+   err(1, "xenwatchdogd: Failed to kick watchdog\n");
+
 sleep(s);
-ret = xc_watchdog(h, id, t);
-if (ret != 0)
-err(1, "xc_watchdog");
 }
 }
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file

2016-05-18 Thread Andrii Anisov

From: Oleksandr Tyshchenko 

In case of missing required property in cfg file
the default value (0x4) should be used.

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 tools/libxc/xc_dom_arm.c | 13 +++--
 tools/libxl/libxl_arm.c  | 10 --
 tools/libxl/libxl_create.c   |  5 +
 tools/libxl/libxl_dom.c  |  6 +++---
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_types.idl  |  1 +
 tools/libxl/xl_cmdimpl.c | 13 +
 7 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 5ee8eef..96df669 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -415,9 +415,12 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 uint64_t modbase;
 
 uint64_t ramsize = (uint64_t)dom->total_pages << XC_PAGE_SHIFT;
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+uint64_t guest_ramsize = (GUEST_RAM0_BASE + GUEST_RAM0_SIZE) -
+  guest_rambase;
 
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
-const uint64_t bankmax[] = GUEST_RAM_BANK_SIZES;
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
+const uint64_t bankmax[] = {guest_ramsize, GUEST_RAM1_SIZE};
 
 /* Convenient */
 const uint64_t kernbase = dom->kernel_seg.vstart;
@@ -433,8 +436,6 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 xen_pfn_t p2m_size;
 uint64_t bank0end;
 
-assert(dom->rambase_pfn << XC_PAGE_SHIFT == bankbase[0]);
-
 if ( modsize + kernsize > bankmax[0] )
 {
 DOMPRINTF("%s: Not enough memory for the kernel+dtb+initrd",
@@ -448,11 +449,11 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 return -1;
 }
 
-if ( ramsize > GUEST_RAM_MAX )
+if ( ramsize > (bankmax[0] + bankmax[1]) )
 {
 DOMPRINTF("%s: ram size is too large for guest address space: "
   "%"PRIx64" > %llx",
-  __FUNCTION__, ramsize, GUEST_RAM_MAX);
+  __FUNCTION__, ramsize, bankmax[0] + bankmax[1]);
 return -1;
 }
 
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0af8010..7f9547b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -372,7 +372,10 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
 {
 int res, i;
 const char *name;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
 
 for (i = 0; i < GUEST_RAM_BANKS; i++) {
 name = GCSPRINTF("memory@%"PRIx64, bankbase[i]);
@@ -914,7 +917,10 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 {
 void *fdt = dom->devicetree_blob;
 int i;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
 
 const struct xc_dom_seg *ramdisk = dom->ramdisk_blob ?
 &dom->ramdisk_seg : NULL;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 350e274..1c0579c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -182,6 +182,11 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
 b_info->target_memkb = b_info->max_memkb;
 
+#ifdef GUEST_RAM_BASE
+if (b_info->rambase == LIBXL_INVALID_RAM_BASE)
+b_info->rambase = GUEST_RAM0_BASE;
+#endif
+
 libxl_defbool_setdefault(&b_info->claim_mode, false);
 
 libxl_defbool_setdefault(&b_info->localtime, false);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2da3ac4..be6598f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -703,12 +703,12 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 LOGE(ERROR, "xc_dom_boot_xen_init failed");
 goto out;
 }
-#ifdef GUEST_RAM_BASE
-if ( (ret = xc_dom_rambase_init(dom, GUEST_RAM_BASE)) != 0 ) {
+
+if ( (ret = xc_dom_rambase_init(dom, info->rambase)) != 0 ) {
 LOGE(ERROR, "xc_dom_rambase failed");
 goto out;
 }
-#endif
+
 if ( (ret = xc_dom_parse_image(dom)) != 0 ) {
 LOGE(ERROR, "xc_dom_parse_image failed");
 goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1699f32..5b0b50a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -100,6 +100,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define LIBXL_INVALID_GFN (~(uint64_t)0)
+#define LIBXL_INVALID_RAM_BASE (~(uint64_t)0)
 /* use 0 as the domid of the toolstack domain for now */
 #define LIBXL_TOOLSTACK_DOMID 0
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
diff --git a/tools/libxl/libxl_types.idl

[Xen-devel] [PATCH RFC 02/18] kbdif: add raw events passing

2016-05-18 Thread Andrii Anisov

From: Sergiy Kibrik 

xenkbd_raw carries raw linux event structure -- type, code & value,
which allows support of more devices (e.g. touchscreens).

Signed-off-by: Sergiy Kibrik 
---
 xen/include/public/io/kbdif.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 2d2aebd..ad07ed5 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -45,6 +45,8 @@
  */
 #define XENKBD_TYPE_POS 4
 
+#define XENKBD_TYPE_RAW 5
+
 struct xenkbd_motion
 {
 uint8_t type;/* XENKBD_TYPE_MOTION */
@@ -68,6 +70,13 @@ struct xenkbd_position
 int32_t rel_z;   /* relative Z motion (wheel) */
 };
 
+struct xenkbd_raw {
+uint8_t type;/* XENKBD_TYPE_RAW */
+uint16_t input_type;
+uint16_t code;
+int32_t value;
+};
+
 #define XENKBD_IN_EVENT_SIZE 40
 
 union xenkbd_in_event
@@ -76,6 +85,7 @@ union xenkbd_in_event
 struct xenkbd_motion motion;
 struct xenkbd_key key;
 struct xenkbd_position pos;
+struct xenkbd_raw raw;
 char pad[XENKBD_IN_EVENT_SIZE];
 };
 
-- 
2.8.2


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

[Xen-devel] [PATCH RFC 09/18] tools: Allow to cross-compile xentop

2016-05-18 Thread Andrii Anisov

From: Oleksandr Dmytryshyn 

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Iurii Konovalenko 
---
 tools/xenstat/Makefile | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/xenstat/Makefile b/tools/xenstat/Makefile
index 901be4a..440b1b7 100644
--- a/tools/xenstat/Makefile
+++ b/tools/xenstat/Makefile
@@ -4,12 +4,10 @@ include $(XEN_ROOT)/tools/Rules.mk
 SUBDIRS :=
 SUBDIRS += libxenstat
 
-# This doesn't cross-compile (cross-compile environments rarely have curses)
-ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
+# This compiles if compiler environment has curses
 ifeq ($(wildcard /usr/include/curses.h),/usr/include/curses.h)
 SUBDIRS += xentop
 endif
-endif
 
 .PHONY: all install clean distclean
 
-- 
2.8.2


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

Re: [Xen-devel] [PATCH RFC 1/4] tmem: Move global stats in a tmem_statistics structure

2016-05-18 Thread Doug Goldstein

On 5/18/16 9:34 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, May 17, 2016 at 09:01:00PM -0500, Doug Goldstein wrote:
>> On 5/17/16 8:57 PM, Doug Goldstein wrote:
>>> On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
 And adjust the macro: atomic_inc_and_max to update the structure.

 Sadly one entry: pool->pgp_count cannot use this macro anymore
 so unroll the macro for this instance.

 No functional change. The name has the 'tmem_stats' as it will
 be eventually non-local.

 Signed-off-by: Konrad Rzeszutek Wilk 
 ---
  xen/common/tmem.c | 135 
 +-
  1 file changed, 73 insertions(+), 62 deletions(-)

 diff --git a/xen/common/tmem.c b/xen/common/tmem.c
 index 16e249a..d362eae 100644
 --- a/xen/common/tmem.c
 +++ b/xen/common/tmem.c
 @@ -28,25 +28,32 @@
  #define TMEM_SPEC_VERSION 1
  
  /* Global statistics (none need to be locked). */
 -static unsigned long total_tmem_ops = 0;
 -static unsigned long errored_tmem_ops = 0;
 -static unsigned long total_flush_pool = 0;
 -static unsigned long alloc_failed = 0, alloc_page_failed = 0;
 -static unsigned long evicted_pgs = 0, evict_attempts = 0;
 -static unsigned long relinq_pgs = 0, relinq_attempts = 0;
 -static unsigned long max_evicts_per_relinq = 0;
 -static unsigned long low_on_memory = 0;
 -static unsigned long deduped_puts = 0;
 -static unsigned long tot_good_eph_puts = 0;
 -static int global_obj_count_max = 0;
 -static int global_pgp_count_max = 0;
 -static int global_pcd_count_max = 0;
 -static int global_page_count_max = 0;
 -static int global_rtree_node_count_max = 0;
 -static long global_eph_count_max = 0;
 -static unsigned long failed_copies;
 -static unsigned long pcd_tot_tze_size = 0;
 -static unsigned long pcd_tot_csize = 0;
 +struct tmem_statistics {
 +unsigned long total_tmem_ops;
 +unsigned long errored_tmem_ops;
 +unsigned long total_flush_pool;
 +unsigned long alloc_failed;
 +unsigned long alloc_page_failed;
 +unsigned long evicted_pgs;
 +unsigned long evict_attempts;
 +unsigned long relinq_pgs;
 +unsigned long relinq_attempts;
 +unsigned long max_evicts_per_relinq;
 +unsigned long low_on_memory;
 +unsigned long deduped_puts;
 +unsigned long tot_good_eph_puts;
 +int global_obj_count_max;
 +int global_pgp_count_max;
 +int global_pcd_count_max;
 +int global_page_count_max;
 +int global_rtree_node_count_max;
 +long global_eph_count_max;
 +unsigned long failed_copies;
 +unsigned long pcd_tot_tze_size;
 +unsigned long pcd_tot_csize;
 +};
 +
 +static struct tmem_statistics tmem_stats;
  
  / CORE DATA STRUCTURES /
  
 @@ -225,8 +232,8 @@ static atomic_t global_rtree_node_count = 
 ATOMIC_INIT(0);
  
  #define atomic_inc_and_max(_c) do { \
  atomic_inc(&_c); \
 -if ( _atomic_read(_c) > _c##_max ) \
 -_c##_max = _atomic_read(_c); \
 +if ( _atomic_read(_c) > tmem_stats._c##_max ) \
 +tmem_stats._c##_max = _atomic_read(_c); \
  } while (0)
  
  #define atomic_dec_and_assert(_c) do { \
 @@ -273,7 +280,7 @@ static void *tmem_malloc(size_t size, struct tmem_pool 
 *pool)
  v = xmem_pool_alloc(size, tmem_mempool);
  }
  if ( v == NULL )
 -alloc_failed++;
 +tmem_stats.alloc_failed++;
  return v;
  }
  
 @@ -300,7 +307,7 @@ static struct page_info *tmem_alloc_page(struct 
 tmem_pool *pool)
  else
  pfp = __tmem_alloc_page();
  if ( pfp == NULL )
 -alloc_page_failed++;
 +tmem_stats.alloc_page_failed++;
  else
  atomic_inc_and_max(global_page_count);
>>>
>>> So the code was previously like this but this change made me notice
>>> this. How come tmem_stats.global_page_count needs to be atomically
>>> incremented but not tmem_stats.alloc_page_failed? Its also a little
>>> weird that global_page_count is in the struct now but not really visible
>>> here while alloc_page_count is in the struct but has to be explicitly
>>> called out.
>>>
>>>
>>
>> Actually I just realized "global_page_count" but this patch actually
>> deals with "global_page_count_max". So ignore the original email.
>>
>> But does this patch compile (for bisect-ability) due to the change to
>> atomic_inc_and_max() but not moving "global_page_count" into the structure?
> 
> Yup:
> 
>  #define atomic_inc_and_max(_c) do { \
>  atomic_inc(&_c); \
> -if ( _atomic_read(_c) > _c##_max ) \
> -_c##_max = _atomic_read(_c); \
> +if ( _atomic_read(_c) > tmem_stats._c##_max ) \
> +tmem_stats._c##_max

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

2016-05-18 Thread Juergen Gross

On 18/05/16 18:09, Tony S wrote:
> On Wed, May 18, 2016 at 8:57 AM, Dario Faggioli
>  wrote:
>> On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote:
>>> On 17/05/16 11:33, George Dunlap wrote:
> Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting
> process
> times. KVM uses it but Xen doesn't.
 Is someone on the Linux side going to put this on their to-do list
 then? :-)
>>>
>>> Patch sent.
>>>
>> Yep, seen it, thanks.
>>
>>> Support was already existing for arm.
>>>
>> Yes!! I remember Stefano talking about introducing it, and that was
>> also why I thought we had it already since long time on x86.
>>
>> Well, anyway... :-)
>>
>>> What is missing is support for
>>> paravirt_steal_rq_enabled which requires to be able to read the
>>> stolen
>>> time of another cpu. This can't work today as accessing another cpu's
>>> vcpu_runstate_info isn't possible without risking inconsistent data.
>>> I plan to add support for this, too, but this will require adding
>>> another hypercall to map a modified vcpu_runstate_info containing an
>>> indicator for an ongoing update of the data.
>>>
>> Understood.
>>
>> So, Tony, up for trying again your workload with this patch applied to
>> Linux?
>>
>> Most likely, it _won't_ fix all the problems you're seeing, but I'm
>> curious to see if it helps.
> 
> Hi Dario,
> 
> I did not see the patch. Can you please send me the patch and I will
> try to test it later.

Here is an updated version.


Juergen

>From d4a6e2217adfa8715237738b67a8989528d59cae Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Tue, 17 May 2016 14:03:02 +0200
Subject: [PATCH v2] xen: add steal_clock support on x86

With CONFIG_PARAVIRT_TIME_ACCOUNTING the kernel is capable to account
for time a thread wasn't able to run due to hypervisor scheduling.
Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen.

Signed-off-by: Juergen Gross 
---
 arch/arm/xen/enlighten.c| 17 ++---
 arch/x86/Kconfig|  2 +-
 arch/x86/xen/time.c | 44 ++--
 drivers/xen/time.c  | 19 +++
 include/linux/kernel_stat.h |  1 -
 include/xen/xen-ops.h   |  1 +
 kernel/sched/cputime.c  | 10 --
 7 files changed, 25 insertions(+), 69 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..9163b94 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
 
-static unsigned long long xen_stolen_accounting(int cpu)
-{
-	struct vcpu_runstate_info state;
-
-	BUG_ON(cpu != smp_processor_id());
-
-	xen_get_runstate_snapshot(&state);
-
-	WARN_ON(state.state != RUNSTATE_running);
-
-	return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
 static void xen_read_wallclock(struct timespec64 *ts)
 {
 	u32 version;
@@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
 
 	register_cpu_notifier(&xen_cpu_notifier);
 
-	pv_time_ops.steal_clock = xen_stolen_accounting;
-	static_key_slow_inc(¶virt_steal_enabled);
+	xen_time_setup_guest();
+
 	if (xen_initial_domain())
 		pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7bb1574..3be1fee 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -752,7 +752,7 @@ source "arch/x86/lguest/Kconfig"
 config PARAVIRT_TIME_ACCOUNTING
 	bool "Paravirtual steal time accounting"
 	depends on PARAVIRT
-	default n
+	default y if XEN
 	---help---
 	  Select this option to enable fine granularity task steal time
 	  accounting. Time spent executing other tasks in parallel with
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6be31df 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -11,8 +11,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -31,44 +29,6 @@
 
 /* Xen may fire a timer up to this many ns early */
 #define TIMER_SLOP	10
-#define NS_PER_TICK	(10LL / HZ)
-
-/* snapshots of runstate info */
-static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
-
-/* unused ns of stolen time */
-static DEFINE_PER_CPU(u64, xen_residual_stolen);
-
-static void do_stolen_accounting(void)
-{
-	struct vcpu_runstate_info state;
-	struct vcpu_runstate_info *snap;
-	s64 runnable, offline, stolen;
-	cputime_t ticks;
-
-	xen_get_runstate_snapshot(&state);
-
-	WARN_ON(state.state != RUNSTATE_running);
-
-	snap = this_cpu_ptr(&xen_runstate_snapshot);
-
-	/* work out how much time the VCPU has not been runn*ing*  */
-	runnable = state.time[RUNSTATE_runnable] - snap->time[RUNSTATE_runnable];
-	offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
-
-	*snap = state;
-
-	/* Add the appropriate number of ticks of stolen time,
-	   including any left-overs fro

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Boris Ostrovsky

On 05/18/2016 12:00 PM, Juergen Gross wrote:
> On 18/05/16 17:53, Boris Ostrovsky wrote:
>> On 05/18/2016 11:45 AM, David Vrabel wrote:
>>> On 18/05/16 16:42, Juergen Gross wrote:
 On 18/05/16 17:25, Boris Ostrovsky wrote:
> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
  }
  
 +void __init xen_time_setup_guest(void)
 +{
 +  pv_time_ops.steal_clock = xen_steal_clock;
 +
 +  static_key_slow_inc(¶virt_steal_enabled);
 +  /*
 +   * We can't set paravirt_steal_rq_enabled as this would require 
 the
 +   * capability to read another cpu's runstate info.
 +   */
 +}
>>> Won't we be accounting for stolen cycles twice now --- once from
>>> steal_account_process_tick()->steal_clock() and second time from
>>> do_stolen_accounting()?
>> Uuh, yes.
>>
>> I guess I should rip do_stolen_accounting() out, too? 
> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
 This is easy to accomplish. :-)
>>
>> I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
>> neither) and in their case that's presumably because stealing accounting
>> is a CPUID bit, i.e. it might not be supported. In Xen case we always
>> have this interface.
> So they added it later and the default is to keep the old behavior.
>
> that's indeed the case then we should ifndef do_stolen_accounting(). Or
> maybe check for paravirt_steal_enabled.
 Is this really a sensible thing to do? There is a mechanism used by KVM
 to do the stolen accounting. I think we should use it instead of having
 a second implementation doing the same thing in case the generic one
 isn't enabled.
>>> I agree.
>>>
>>> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
>>> don't think it's essential (or is it?).
>> Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
>> support yet.
> I think the patch is still useful. It is reducing code size and
> it is removing arch-specific Xen-hack(s). With the patch Xen's
> solution for arm and x86 is common and the same as for KVM. Adding
> paravirt_steal_rq_enabled later will be much easier as only one
> function needs substantial modification.

I am not arguing against having a patch that will remove
do_stolen_accounting(). I was responding to David's statement about
whether we need to select CONFIG_PARAVIRT_TIME_ACCOUNTING, and I am not
sure this is necessary since steal_account_process_tick() (that will
take case of things that do_stolen_accounting() currently does) doesn't
need it.

(And if it is indeed needed --- can we have Xen's Kconfig select it
instead of "default y if XEN" ?)

-boris


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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Dario Faggioli

On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
> > 
> > Won't we be accounting for stolen cycles twice now --- once from
> > steal_account_process_tick()->steal_clock() and second time from
> > do_stolen_accounting()?
> Uuh, yes.
> 
> I guess I should rip do_stolen_accounting() out, too? It is a
> Xen-specific hack, so I guess nobody will cry. Maybe it would be a
> good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?
> 
So, config options aside, if I understand this correctly, it looks like
we were actually already doing steal time accounting, although in a
non-standard way.

And yet, people seem to have issues relating to lack of (proper?) steal
time accounting (Cc-ing Tony).

I guess this means that, either:
 - the issue being reported is actually not caused by the lack of 
   steal time accounting,
 - our current (Xen specific) steal time accounting solution is flawed,
 - the issue is caused by the lack of the bit of steal time accounting
   that we do not support yet,
 - other ideas? Tony?

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

2016-05-18 Thread Tony S

On Wed, May 18, 2016 at 8:57 AM, Dario Faggioli
 wrote:
> On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote:
>> On 17/05/16 11:33, George Dunlap wrote:
>> > > Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting
>> > > process
>> > > times. KVM uses it but Xen doesn't.
>> > Is someone on the Linux side going to put this on their to-do list
>> > then? :-)
>>
>> Patch sent.
>>
> Yep, seen it, thanks.
>
>> Support was already existing for arm.
>>
> Yes!! I remember Stefano talking about introducing it, and that was
> also why I thought we had it already since long time on x86.
>
> Well, anyway... :-)
>
>> What is missing is support for
>> paravirt_steal_rq_enabled which requires to be able to read the
>> stolen
>> time of another cpu. This can't work today as accessing another cpu's
>> vcpu_runstate_info isn't possible without risking inconsistent data.
>> I plan to add support for this, too, but this will require adding
>> another hypercall to map a modified vcpu_runstate_info containing an
>> indicator for an ongoing update of the data.
>>
> Understood.
>
> So, Tony, up for trying again your workload with this patch applied to
> Linux?
>
> Most likely, it _won't_ fix all the problems you're seeing, but I'm
> curious to see if it helps.

Hi Dario,

I did not see the patch. Can you please send me the patch and I will
try to test it later.

Best
Tony

>
> Thanks again and Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>

-- 
Tony. S
Ph. D student of University of Colorado, Colorado Springs

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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Juergen Gross

On 18/05/16 17:53, Boris Ostrovsky wrote:
> On 05/18/2016 11:45 AM, David Vrabel wrote:
>> On 18/05/16 16:42, Juergen Gross wrote:
>>> On 18/05/16 17:25, Boris Ostrovsky wrote:
 On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>>  }
>>>  
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> +   pv_time_ops.steal_clock = xen_steal_clock;
>>> +
>>> +   static_key_slow_inc(¶virt_steal_enabled);
>>> +   /*
>>> +* We can't set paravirt_steal_rq_enabled as this would require 
>>> the
>>> +* capability to read another cpu's runstate info.
>>> +*/
>>> +}
>> Won't we be accounting for stolen cycles twice now --- once from
>> steal_account_process_tick()->steal_clock() and second time from
>> do_stolen_accounting()?
> Uuh, yes.
>
> I guess I should rip do_stolen_accounting() out, too? 
 I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>>> This is easy to accomplish. :-)
> 
> 
> I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
> neither) and in their case that's presumably because stealing accounting
> is a CPUID bit, i.e. it might not be supported. In Xen case we always
> have this interface.

So they added it later and the default is to keep the old behavior.

 that's indeed the case then we should ifndef do_stolen_accounting(). Or
 maybe check for paravirt_steal_enabled.
>>> Is this really a sensible thing to do? There is a mechanism used by KVM
>>> to do the stolen accounting. I think we should use it instead of having
>>> a second implementation doing the same thing in case the generic one
>>> isn't enabled.
>> I agree.
>>
>> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
>> don't think it's essential (or is it?).
> 
> Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
> support yet.

I think the patch is still useful. It is reducing code size and
it is removing arch-specific Xen-hack(s). With the patch Xen's
solution for arm and x86 is common and the same as for KVM. Adding
paravirt_steal_rq_enabled later will be much easier as only one
function needs substantial modification.


Juergen


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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread David Vrabel

On 18/05/16 16:51, Juergen Gross wrote:
> On 18/05/16 17:45, David Vrabel wrote:
>> On 18/05/16 16:42, Juergen Gross wrote:
>>> On 18/05/16 17:25, Boris Ostrovsky wrote:
 On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>>  }
>>>  
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> +   pv_time_ops.steal_clock = xen_steal_clock;
>>> +
>>> +   static_key_slow_inc(¶virt_steal_enabled);
>>> +   /*
>>> +* We can't set paravirt_steal_rq_enabled as this would require 
>>> the
>>> +* capability to read another cpu's runstate info.
>>> +*/
>>> +}
>> Won't we be accounting for stolen cycles twice now --- once from
>> steal_account_process_tick()->steal_clock() and second time from
>> do_stolen_accounting()?
> Uuh, yes.
>
> I guess I should rip do_stolen_accounting() out, too? 

 I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>>>
>>> This is easy to accomplish. :-)
>>>
 that's indeed the case then we should ifndef do_stolen_accounting(). Or
 maybe check for paravirt_steal_enabled.
>>>
>>> Is this really a sensible thing to do? There is a mechanism used by KVM
>>> to do the stolen accounting. I think we should use it instead of having
>>> a second implementation doing the same thing in case the generic one
>>> isn't enabled.
>>
>> I agree.
>>
>> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
>> don't think it's essential (or is it?).
> 
> Not doing so will change behavior in case I rip out
> do_stolen_accounting(). What about "default y if XEN" ?

Ok.

David

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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Boris Ostrovsky

On 05/18/2016 11:45 AM, David Vrabel wrote:
> On 18/05/16 16:42, Juergen Gross wrote:
>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
 On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>  }
>>  
>> +void __init xen_time_setup_guest(void)
>> +{
>> +pv_time_ops.steal_clock = xen_steal_clock;
>> +
>> +static_key_slow_inc(¶virt_steal_enabled);
>> +/*
>> + * We can't set paravirt_steal_rq_enabled as this would require 
>> the
>> + * capability to read another cpu's runstate info.
>> + */
>> +}
> Won't we be accounting for stolen cycles twice now --- once from
> steal_account_process_tick()->steal_clock() and second time from
> do_stolen_accounting()?
 Uuh, yes.

 I guess I should rip do_stolen_accounting() out, too? 
>>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>> This is easy to accomplish. :-)


I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
neither) and in their case that's presumably because stealing accounting
is a CPUID bit, i.e. it might not be supported. In Xen case we always
have this interface.


>>
>>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>>> maybe check for paravirt_steal_enabled.
>> Is this really a sensible thing to do? There is a mechanism used by KVM
>> to do the stolen accounting. I think we should use it instead of having
>> a second implementation doing the same thing in case the generic one
>> isn't enabled.
> I agree.
>
> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
> don't think it's essential (or is it?).

Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
support yet.

-boris



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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Juergen Gross

On 18/05/16 17:45, David Vrabel wrote:
> On 18/05/16 16:42, Juergen Gross wrote:
>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
 On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>  }
>>  
>> +void __init xen_time_setup_guest(void)
>> +{
>> +pv_time_ops.steal_clock = xen_steal_clock;
>> +
>> +static_key_slow_inc(¶virt_steal_enabled);
>> +/*
>> + * We can't set paravirt_steal_rq_enabled as this would require 
>> the
>> + * capability to read another cpu's runstate info.
>> + */
>> +}
> Won't we be accounting for stolen cycles twice now --- once from
> steal_account_process_tick()->steal_clock() and second time from
> do_stolen_accounting()?
 Uuh, yes.

 I guess I should rip do_stolen_accounting() out, too? 
>>>
>>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>>
>> This is easy to accomplish. :-)
>>
>>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>>> maybe check for paravirt_steal_enabled.
>>
>> Is this really a sensible thing to do? There is a mechanism used by KVM
>> to do the stolen accounting. I think we should use it instead of having
>> a second implementation doing the same thing in case the generic one
>> isn't enabled.
> 
> I agree.
> 
> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
> don't think it's essential (or is it?).

Not doing so will change behavior in case I rip out
do_stolen_accounting(). What about "default y if XEN" ?


Juergen


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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread David Vrabel

On 18/05/16 16:42, Juergen Gross wrote:
> On 18/05/16 17:25, Boris Ostrovsky wrote:
>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>>> On 18/05/16 16:46, Boris Ostrovsky wrote:
 On 05/18/2016 08:15 AM, Juergen Gross wrote:
>  }
>  
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> +  * We can't set paravirt_steal_rq_enabled as this would require the
> +  * capability to read another cpu's runstate info.
> +  */
> +}
 Won't we be accounting for stolen cycles twice now --- once from
 steal_account_process_tick()->steal_clock() and second time from
 do_stolen_accounting()?
>>> Uuh, yes.
>>>
>>> I guess I should rip do_stolen_accounting() out, too? 
>>
>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
> 
> This is easy to accomplish. :-)
> 
>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>> maybe check for paravirt_steal_enabled.
> 
> Is this really a sensible thing to do? There is a mechanism used by KVM
> to do the stolen accounting. I think we should use it instead of having
> a second implementation doing the same thing in case the generic one
> isn't enabled.

I agree.

Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
don't think it's essential (or is it?).

David

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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Juergen Gross

On 18/05/16 17:25, Boris Ostrovsky wrote:
> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
  }
  
 +void __init xen_time_setup_guest(void)
 +{
 +  pv_time_ops.steal_clock = xen_steal_clock;
 +
 +  static_key_slow_inc(¶virt_steal_enabled);
 +  /*
 +   * We can't set paravirt_steal_rq_enabled as this would require the
 +   * capability to read another cpu's runstate info.
 +   */
 +}
>>> Won't we be accounting for stolen cycles twice now --- once from
>>> steal_account_process_tick()->steal_clock() and second time from
>>> do_stolen_accounting()?
>> Uuh, yes.
>>
>> I guess I should rip do_stolen_accounting() out, too? 
> 
> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If

This is easy to accomplish. :-)

> that's indeed the case then we should ifndef do_stolen_accounting(). Or
> maybe check for paravirt_steal_enabled.

Is this really a sensible thing to do? There is a mechanism used by KVM
to do the stolen accounting. I think we should use it instead of having
a second implementation doing the same thing in case the generic one
isn't enabled.

Juergen

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

Re: [Xen-devel] [PATCH net-next] xen-netback: only deinitialized hash if it was initialized

2016-05-18 Thread Wei Liu

On Wed, May 18, 2016 at 03:55:42PM +0100, Paul Durrant wrote:
> A domain with a frontend that does not implement a control ring has been
> seen to cause a crash during domain save. This was apparently because
> the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
> regardless of whether a control ring was connected, and hence
> xenvif_hash_init() was called.
> 
> This patch brings the call to xenvif_deinit_hash() in
> xenvif_disconnect_ctrl() inside the if clause that checks whether the
> control ring event channel was connected. This is sufficient to ensure
> it is only called if xenvif_init_hash() was called previously.
> 
> Signed-off-by: Paul Durrant 
> Reported-by: Boris Ostrovsky 
> Tested-by: Boris Ostrovsky 
> Cc: Wei Liu 

Acked-by: Wei Liu 

> ---
>  drivers/net/xen-netback/interface.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index 1c7f49b..83deeeb 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
>   vif->ctrl_task = NULL;
>   }
>  
> - xenvif_deinit_hash(vif);
> -
>   if (vif->ctrl_irq) {
> + xenvif_deinit_hash(vif);
>   unbind_from_irqhandler(vif->ctrl_irq, vif);
>   vif->ctrl_irq = 0;
>   }
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH for-4.7] libxl: consolidate casting to xc psr type to a function

2016-05-18 Thread Wei Liu

In commit 31268fea (libxl: fix passing the type argument to xc_psr_*),
casting to xc psr type was done at each call site.

This patch consolidates casting into a function to avoid casting at each
conversion point. Each call site remains more type safe.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
Cc: Ian Jackson 
Cc: Roger Pau Monne 

I will commit this patch later this week if I receive no further
feedback.
---
 tools/libxl/libxl_psr.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 40f2d5f..99733f6 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -293,12 +293,18 @@ out:
 return rc;
 }
 
+static inline xc_psr_cat_type libxl__psr_cbm_type_to_libxc_psr_cat_type(
+libxl_psr_cbm_type type)
+{
+BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
+return (xc_psr_cat_type)type;
+}
+
 int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
   libxl_psr_cbm_type type, libxl_bitmap *target_map,
   uint64_t cbm)
 {
 GC_INIT(ctx);
-BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
 int rc;
 int socketid, nr_sockets;
 
@@ -309,9 +315,13 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
 }
 
 libxl_for_each_set_bit(socketid, *target_map) {
+xc_psr_cat_type xc_type;
+
 if (socketid >= nr_sockets)
 break;
-if (xc_psr_cat_set_domain_data(ctx->xch, domid, (xc_psr_cat_type)type,
+
+xc_type = libxl__psr_cbm_type_to_libxc_psr_cat_type(type);
+if (xc_psr_cat_set_domain_data(ctx->xch, domid, xc_type,
socketid, cbm)) {
 libxl__psr_cat_log_err_msg(gc, errno);
 rc = ERROR_FAIL;
@@ -329,8 +339,9 @@ int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid,
 {
 GC_INIT(ctx);
 int rc = 0;
+xc_psr_cat_type xc_type = libxl__psr_cbm_type_to_libxc_psr_cat_type(type);
 
-if (xc_psr_cat_get_domain_data(ctx->xch, domid, (xc_psr_cat_type)type,
+if (xc_psr_cat_get_domain_data(ctx->xch, domid, xc_type,
target, cbm_r)) {
 libxl__psr_cat_log_err_msg(gc, errno);
 rc = ERROR_FAIL;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Boris Ostrovsky

On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>>  }
>>>  
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> +   pv_time_ops.steal_clock = xen_steal_clock;
>>> +
>>> +   static_key_slow_inc(¶virt_steal_enabled);
>>> +   /*
>>> +* We can't set paravirt_steal_rq_enabled as this would require the
>>> +* capability to read another cpu's runstate info.
>>> +*/
>>> +}
>> Won't we be accounting for stolen cycles twice now --- once from
>> steal_account_process_tick()->steal_clock() and second time from
>> do_stolen_accounting()?
> Uuh, yes.
>
> I guess I should rip do_stolen_accounting() out, too? 

I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
that's indeed the case then we should ifndef do_stolen_accounting(). Or
maybe check for paravirt_steal_enabled.

-boris

> It is a
> Xen-specific hack, so I guess nobody will cry. Maybe it would be a
> good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?
>
>
> Juergen
>



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

Re: [Xen-devel] 2nd opinion on backportability of c35eefded2

2016-05-18 Thread Jan Beulich

>>> On 18.05.16 at 16:41,  wrote:
> On 13/05/16 10:32, Jan Beulich wrote:
>> Hi George,
>> 
>> after quite a bit of debugging on 4.6.1 I learned that said commit
>> ("x86/P2M: consolidate handling of types not requiring a valid MFN")
>> is more than just cleanup: Since p2m_set_entry() happily performs
>> arithmetic on the passed in MFN, shadow mode guests (verified) as
>> well as HAP ones when 1Gb / 2Mb mappings are unavailable (not
>> verified), if any of the MFNs below 1Gb are invalid (reported with
>> e.g. "crashkernel=512M@16M"), p2m_pt_set_entry() would (in
>> the context of guest_physmap_mark_populate_on_demand())
>> produce invalid instead of PoD entries, resulting in subsequent
>> attempts by the guest to use (e.g. balloon out) these pages to
>> fail (the balloon failure results in a crash during boot).
> 
> I'm sorry, I'm having some trouble parsing this paragraph. :-)
> 
> But this is what I gather:
> 
> Before c35eefded2, the 4k-entry path didn't check whether the p2m entry
> was PoD, it only checked that the mfn was valid.  The pod code would
> always set this mfn to 0, which is (usually) valid; but p2m_set_entry()
> might iterate over this, ending up in p2m_pt_set_entry() with non-zero
> low values for mfn.  In certain circumstances these low-value mfns might
> actually be invalid (for example, if they overlap a crash kernel).
> 
> In such a case, the resulting p2m entries would be (erroneously) marked
> as invalid rather than PoD, resulting in a crash when the guest tried to
> access it or populate it.
> 
> You observed this happening in the shadow case, and believe it would
> happen if p2m 2MiB or 1GiB pages were disabled but haven't checked those
> cases.
> 
> c35eefded2 fixes this by implicitly checking for the PoD type on the 4k
> entry path.

Yes, that's a neater re-write of what I had tried to state.

>> Now, while the backport to 4.6 is straightforward, I'm having the
>> vague feeling that this change might depend on some earlier one,
>> but I can't pinpoint anything. Hence I would appreciate if you
>> could take a look and provide your judgment.
> 
> We talked about the PoD type thing in the context of a discussion about
> 660fd65 ("x86/p2m-pt: tighten conditions of IOMMU mapping updates") --
> discussion here [1].  But it doesn't look like that's a prerequisite,
> and nothing else really comes to mind.

Right, the PoD thing was just an observation while putting together
that other patch, not something that would create a dependency.

Plus - that commit went in during 4.6-rc, and got backported to 4.5.x,
so even if it was a prereq this would not be a problem.

Thanks for double checking!

Jan


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

Re: [Xen-devel] state of xenified SUSE kernel

2016-05-18 Thread Jan Beulich

>>> On 18.05.16 at 16:39,  wrote:
> On 17.05.2016 17:34, Jan Beulich wrote:
>>> We use xenified kernels based on kernel 3.4 for years and benchmarks
>>> showed that they are faster than the pvops (vanilla) kernels.
>>> But what is the current state in terms of performance and features?
>> I'm not sure what you expect here. Up to openSUSE 42.1 and
>> SLE 12 SP1 they are fully maintained, i.e. you can get quite a
>> bit newer than 3.4 based kernels. There's not a lot of
>> performance analysis that I would be aware of, so I can't
>> answer that part anyway. And them being release branches
>> rather than development ones, there's not going to be any
>> new feature work.
> 
> As far as I know the patches are based on the original work for kernel 
> 2.6.18 and have not been adjusted to major changes in Xen architecture. 
> So what I am thinking about is performance improvements that result from 
> using newer Xen features.

We've added support for newer features where suitable, over the
years. When reasonable I've also tried to put these into the 2.6.18
tree. But from all I can tell right now this isn't going to happen any
further.

> So the question was: from an architectural 
> point of view should pvops in recent vanilla kernels be "better" then 
> xenified kernels?

Hence it's hard to answer this question, the more that I can't even
prove (or disprove) what you've said regarding its performance
having been better in the past.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation

2016-05-18 Thread Wei Liu

On Wed, May 18, 2016 at 08:49:01AM -0600, Jan Beulich wrote:
> This in particular prevents updating guest IP when handling the retry
> needed to forward the memory access to qemu.
> 
> Signed-off-by: Jan Beulich 

Release-acked-by: Wei Liu 

> 
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4178,6 +4178,8 @@ x86_emulate(
>  if ( !rc && (b & 1) && (ea.type == OP_MEM) )
>  rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
>  ea.bytes, ctxt);
> +if ( rc )
> +goto done;
>  dst.type = OP_NONE;
>  break;
>  }
> @@ -4430,6 +4432,8 @@ x86_emulate(
>  if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
>  rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
>  ea.bytes, ctxt);
> +if ( rc )
> +goto done;
>  dst.type = OP_NONE;
>  break;
>  }
> 
> 
> 

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

[Xen-devel] [PATCH net-next] xen-netback: only deinitialized hash if it was initialized

2016-05-18 Thread Paul Durrant

A domain with a frontend that does not implement a control ring has been
seen to cause a crash during domain save. This was apparently because
the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
regardless of whether a control ring was connected, and hence
xenvif_hash_init() was called.

This patch brings the call to xenvif_deinit_hash() in
xenvif_disconnect_ctrl() inside the if clause that checks whether the
control ring event channel was connected. This is sufficient to ensure
it is only called if xenvif_init_hash() was called previously.

Signed-off-by: Paul Durrant 
Reported-by: Boris Ostrovsky 
Tested-by: Boris Ostrovsky 
Cc: Wei Liu 
---
 drivers/net/xen-netback/interface.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 1c7f49b..83deeeb 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
vif->ctrl_task = NULL;
}
 
-   xenvif_deinit_hash(vif);
-
if (vif->ctrl_irq) {
+   xenvif_deinit_hash(vif);
unbind_from_irqhandler(vif->ctrl_irq, vif);
vif->ctrl_irq = 0;
}
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 for-4.7 12/14] libxl: fix passing the type argument to xc_psr_* [and 1 more messages]

2016-05-18 Thread Wei Liu

On Wed, May 18, 2016 at 03:45:22PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type 
> argument to xc_psr_*"):
> > On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> > > I'm very much against introducing casts which are not absolutely
> > > necessary.  Casts are a big hammer which can suppress important
> > > warnings (such as conversions between integers and pointers).
> > > 
> > > This anomaly with the same enum defined in two places with two names
> > > is pretty poor.  But if we are to perpetuate it, as perhaps we must,
> > > then rather than casting at each conversion point, we should introduce
> > > an inline function which contains the cast.  That way each call site
> > > remains more typesafe.
> > 
> > The two enums aren't going away any time soon.
> 
> Sadly, I think you're right.
> 
> > Does the following diff meet your requirement?
> 
> Yes, that is exactly the kind of thing I was thinking of.  It makes
> the cast non-routine by putting it in a dedicated function whose
> authors/readers know to check it's right.
> 
> Acked-by: Ian Jackson 
> 
> (with a suitable commit message)

Thanks. I will submit a proper patch with your ack.

Wei.

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

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

2016-05-18 Thread Jan Beulich

>>> On 18.05.16 at 14:53,  wrote:
> On May 17, 2016 3:48 PM, Jan Beulich  wrote:
>> >>> On 17.05.16 at 05:19,  wrote:
>> >>  From: Xu, Quan
>> >> Sent: Monday, May 16, 2016 11:26 PM
>> >>
>> >> On May 13, 2016 11:28 PM, Jan Beulich  wrote:
>> >> > >>> On 22.04.16 at 12:54,  wrote:
>> >> > > --- a/docs/misc/xen-command-line.markdown
>> >> > > +++ b/docs/misc/xen-command-line.markdown
>> >> > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also
>> >> > specified vpmu will be turned off.
>> >> > >  As the virtualisation is not 100% safe, don't use the vpmu flag
>> >> > > on production systems (see http://xenbits.xen.org/xsa/advisory- 
>> 163.html)!
>> >> > >
>> >> > > +### vtd\_qi\_timeout (VT-d)
>> >> > > +> `= `
>> >> > > +
>> >> > > +> Default: `1`
>> >> > > +
>> >> > > +Specify the timeout of the VT-d Queued Invalidation in milliseconds.
>> >> > > +
>> >> > > +By default, the timeout is 1ms. When you see error 'Queue
>> >> > > +invalidate wait descriptor timed out', try increasing this value.
>> >> >
>> >> > So when someone enables ATS, will the 1ms timeout apply to the dev
>> >> > iotlb invalidations too?
>> >>
>> >> Yes,
>> >> The timeout is the same for IOTLB, Context, IEC and Device-TLB 
>> >> invalidation.
>> >>
>> >> > If so, that's surely too short, and would ideally be adjusted
>> >> > automatically, but the need for a higher timeout in that case
>> >> > should in any event be mentioned here.
>> >>
>> >> I can try to use 1ms for IOTLB, Context and  IEC invalidation. As
>> >> mentioned, 1 ms is enough for IOTLB, Context and  IEC invalidation.
>> >> What about 10 ms for Device-TLB (10 ms is just a higher timeout,  no
>> specific meaning)?
>> >
>> > I remember in earlier discussion we agreed to use 1ms as the default
>> > for both IOMMU-side and device-side flushes. For device-side flushes,
>> > we checked internal HW team that 1ms is a reasonable threshold for
>> > integrated devices. It's likely insufficient for discrete devices. We
>> > may check any automatic adjustment method later when it becomes a real
>> > problem. For now, please elaborate above information in the text.
>> 
>> Well, taking care of automation later is fine with me, 
>> but tying everything to a
>> single timeout, when device iotlb invalidation may require a much larger 
>> value,
>> isn't.
>>
> 
> A little bit confused. Check it -- could I leave patch 1/3 as is? 

The patch can imo remain as is only if the new default timeout
is large enough for all possible cases (including those users
who are adventurous enough to turn on ATS).

> btw, I have tested it against the last commit, no conflict.

No idea what you mean to say with this.

Jan


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

Re: [Xen-devel] Saving a guest crashes dom0

2016-05-18 Thread Paul Durrant

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 18 May 2016 15:57
> To: Paul Durrant; xen-devel
> Subject: Re: Saving a guest crashes dom0
> 
> On 05/18/2016 10:27 AM, Paul Durrant wrote:
> > This should fix the problem for you:
> 
> 
> Yes, that does it. Thanks.

Brilliant :-) I'll post now.

  Paul

> 
> -boris
> 
> 
> >
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-
> netback/interface.c
> > index 1c7f49b..83deeeb 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
> > vif->ctrl_task = NULL;
> > }
> >
> > -   xenvif_deinit_hash(vif);
> > -
> > if (vif->ctrl_irq) {
> > +   xenvif_deinit_hash(vif);
> > unbind_from_irqhandler(vif->ctrl_irq, vif);
> > vif->ctrl_irq = 0;
> > }

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

Re: [Xen-devel] [PATCH] x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation

2016-05-18 Thread Andrew Cooper

On 18/05/16 15:49, Jan Beulich wrote:
> This in particular prevents updating guest IP when handling the retry
> needed to forward the memory access to qemu.
>
> Signed-off-by: Jan Beulich 

Oops.

Reviewed-by: Andrew Cooper 

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

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

2016-05-18 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  667a7120d006007389435976071f0b89f94ec7cc
baseline version:
 xen  1542efcea893df874b13b1ea78101e1ff6a55c41

Last test of basis94547  2016-05-18 11:02:48 Z0 days
Testing same since94551  2016-05-18 13:02:38 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=667a7120d006007389435976071f0b89f94ec7cc
+ . ./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 
667a7120d006007389435976071f0b89f94ec7cc
+ branch=xen-unstable-smoke
+ revision=667a7120d006007389435976071f0b89f94ec7cc
+ . ./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.6-testing
+ '[' x667a7120d006007389435976071f0b89f94ec7cc = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/h

Re: [Xen-devel] Saving a guest crashes dom0

2016-05-18 Thread Boris Ostrovsky

On 05/18/2016 10:27 AM, Paul Durrant wrote:
> This should fix the problem for you:


Yes, that does it. Thanks.

-boris


>
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index 1c7f49b..83deeeb 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
> vif->ctrl_task = NULL;
> }
>
> -   xenvif_deinit_hash(vif);
> -
> if (vif->ctrl_irq) {
> +   xenvif_deinit_hash(vif);
> unbind_from_irqhandler(vif->ctrl_irq, vif);
> vif->ctrl_irq = 0;
> }


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

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

2016-05-18 Thread Dario Faggioli

On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote:
> On 17/05/16 11:33, George Dunlap wrote:
> > > Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting
> > > process
> > > times. KVM uses it but Xen doesn't.
> > Is someone on the Linux side going to put this on their to-do list
> > then? :-)
>
> Patch sent.
> 
Yep, seen it, thanks.

> Support was already existing for arm. 
>
Yes!! I remember Stefano talking about introducing it, and that was
also why I thought we had it already since long time on x86.

Well, anyway... :-)

> What is missing is support for
> paravirt_steal_rq_enabled which requires to be able to read the
> stolen
> time of another cpu. This can't work today as accessing another cpu's
> vcpu_runstate_info isn't possible without risking inconsistent data.
> I plan to add support for this, too, but this will require adding
> another hypercall to map a modified vcpu_runstate_info containing an
> indicator for an ongoing update of the data.
> 
Understood.

So, Tony, up for trying again your workload with this patch applied to
Linux?

Most likely, it _won't_ fix all the problems you're seeing, but I'm
curious to see if it helps.

Thanks again and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Juergen Gross

On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>  }
>>  
>> +void __init xen_time_setup_guest(void)
>> +{
>> +pv_time_ops.steal_clock = xen_steal_clock;
>> +
>> +static_key_slow_inc(¶virt_steal_enabled);
>> +/*
>> + * We can't set paravirt_steal_rq_enabled as this would require the
>> + * capability to read another cpu's runstate info.
>> + */
>> +}
> 
> Won't we be accounting for stolen cycles twice now --- once from
> steal_account_process_tick()->steal_clock() and second time from
> do_stolen_accounting()?

Uuh, yes.

I guess I should rip do_stolen_accounting() out, too? It is a
Xen-specific hack, so I guess nobody will cry. Maybe it would be a
good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?


Juergen


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

Re: [Xen-devel] [PATCH RFC 1/4] tmem: Move global stats in a tmem_statistics structure

2016-05-18 Thread Konrad Rzeszutek Wilk

On Tue, May 17, 2016 at 09:01:00PM -0500, Doug Goldstein wrote:
> On 5/17/16 8:57 PM, Doug Goldstein wrote:
> > On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> >> And adjust the macro: atomic_inc_and_max to update the structure.
> >>
> >> Sadly one entry: pool->pgp_count cannot use this macro anymore
> >> so unroll the macro for this instance.
> >>
> >> No functional change. The name has the 'tmem_stats' as it will
> >> be eventually non-local.
> >>
> >> Signed-off-by: Konrad Rzeszutek Wilk 
> >> ---
> >>  xen/common/tmem.c | 135 
> >> +-
> >>  1 file changed, 73 insertions(+), 62 deletions(-)
> >>
> >> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
> >> index 16e249a..d362eae 100644
> >> --- a/xen/common/tmem.c
> >> +++ b/xen/common/tmem.c
> >> @@ -28,25 +28,32 @@
> >>  #define TMEM_SPEC_VERSION 1
> >>  
> >>  /* Global statistics (none need to be locked). */
> >> -static unsigned long total_tmem_ops = 0;
> >> -static unsigned long errored_tmem_ops = 0;
> >> -static unsigned long total_flush_pool = 0;
> >> -static unsigned long alloc_failed = 0, alloc_page_failed = 0;
> >> -static unsigned long evicted_pgs = 0, evict_attempts = 0;
> >> -static unsigned long relinq_pgs = 0, relinq_attempts = 0;
> >> -static unsigned long max_evicts_per_relinq = 0;
> >> -static unsigned long low_on_memory = 0;
> >> -static unsigned long deduped_puts = 0;
> >> -static unsigned long tot_good_eph_puts = 0;
> >> -static int global_obj_count_max = 0;
> >> -static int global_pgp_count_max = 0;
> >> -static int global_pcd_count_max = 0;
> >> -static int global_page_count_max = 0;
> >> -static int global_rtree_node_count_max = 0;
> >> -static long global_eph_count_max = 0;
> >> -static unsigned long failed_copies;
> >> -static unsigned long pcd_tot_tze_size = 0;
> >> -static unsigned long pcd_tot_csize = 0;
> >> +struct tmem_statistics {
> >> +unsigned long total_tmem_ops;
> >> +unsigned long errored_tmem_ops;
> >> +unsigned long total_flush_pool;
> >> +unsigned long alloc_failed;
> >> +unsigned long alloc_page_failed;
> >> +unsigned long evicted_pgs;
> >> +unsigned long evict_attempts;
> >> +unsigned long relinq_pgs;
> >> +unsigned long relinq_attempts;
> >> +unsigned long max_evicts_per_relinq;
> >> +unsigned long low_on_memory;
> >> +unsigned long deduped_puts;
> >> +unsigned long tot_good_eph_puts;
> >> +int global_obj_count_max;
> >> +int global_pgp_count_max;
> >> +int global_pcd_count_max;
> >> +int global_page_count_max;
> >> +int global_rtree_node_count_max;
> >> +long global_eph_count_max;
> >> +unsigned long failed_copies;
> >> +unsigned long pcd_tot_tze_size;
> >> +unsigned long pcd_tot_csize;
> >> +};
> >> +
> >> +static struct tmem_statistics tmem_stats;
> >>  
> >>  / CORE DATA STRUCTURES /
> >>  
> >> @@ -225,8 +232,8 @@ static atomic_t global_rtree_node_count = 
> >> ATOMIC_INIT(0);
> >>  
> >>  #define atomic_inc_and_max(_c) do { \
> >>  atomic_inc(&_c); \
> >> -if ( _atomic_read(_c) > _c##_max ) \
> >> -_c##_max = _atomic_read(_c); \
> >> +if ( _atomic_read(_c) > tmem_stats._c##_max ) \
> >> +tmem_stats._c##_max = _atomic_read(_c); \
> >>  } while (0)
> >>  
> >>  #define atomic_dec_and_assert(_c) do { \
> >> @@ -273,7 +280,7 @@ static void *tmem_malloc(size_t size, struct tmem_pool 
> >> *pool)
> >>  v = xmem_pool_alloc(size, tmem_mempool);
> >>  }
> >>  if ( v == NULL )
> >> -alloc_failed++;
> >> +tmem_stats.alloc_failed++;
> >>  return v;
> >>  }
> >>  
> >> @@ -300,7 +307,7 @@ static struct page_info *tmem_alloc_page(struct 
> >> tmem_pool *pool)
> >>  else
> >>  pfp = __tmem_alloc_page();
> >>  if ( pfp == NULL )
> >> -alloc_page_failed++;
> >> +tmem_stats.alloc_page_failed++;
> >>  else
> >>  atomic_inc_and_max(global_page_count);
> > 
> > So the code was previously like this but this change made me notice
> > this. How come tmem_stats.global_page_count needs to be atomically
> > incremented but not tmem_stats.alloc_page_failed? Its also a little
> > weird that global_page_count is in the struct now but not really visible
> > here while alloc_page_count is in the struct but has to be explicitly
> > called out.
> > 
> > 
> 
> Actually I just realized "global_page_count" but this patch actually
> deals with "global_page_count_max". So ignore the original email.
> 
> But does this patch compile (for bisect-ability) due to the change to
> atomic_inc_and_max() but not moving "global_page_count" into the structure?

Yup:

 #define atomic_inc_and_max(_c) do { \
 atomic_inc(&_c); \
-if ( _atomic_read(_c) > _c##_max ) \
-_c##_max = _atomic_read(_c); \
+if ( _atomic_read(_c) > tmem_stats._c##_max ) \
+tmem_stats._c##_max = _atomic_read(_c); \
 } while (0)
 
As the global_page_count is still

[Xen-devel] [PATCH] x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation

2016-05-18 Thread Jan Beulich

This in particular prevents updating guest IP when handling the retry
needed to forward the memory access to qemu.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4178,6 +4178,8 @@ x86_emulate(
 if ( !rc && (b & 1) && (ea.type == OP_MEM) )
 rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
 ea.bytes, ctxt);
+if ( rc )
+goto done;
 dst.type = OP_NONE;
 break;
 }
@@ -4430,6 +4432,8 @@ x86_emulate(
 if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
 rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
 ea.bytes, ctxt);
+if ( rc )
+goto done;
 dst.type = OP_NONE;
 break;
 }



x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation

This in particular prevents updating guest IP when handling the retry
needed to forward the memory access to qemu.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4178,6 +4178,8 @@ x86_emulate(
 if ( !rc && (b & 1) && (ea.type == OP_MEM) )
 rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
 ea.bytes, ctxt);
+if ( rc )
+goto done;
 dst.type = OP_NONE;
 break;
 }
@@ -4430,6 +4432,8 @@ x86_emulate(
 if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
 rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
 ea.bytes, ctxt);
+if ( rc )
+goto done;
 dst.type = OP_NONE;
 break;
 }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: put docs/man/ under tool stack

2016-05-18 Thread Ian Jackson

George Dunlap writes ("Re: [Xen-devel] [PATCH] MAINTAINERS: put docs/man/ under 
tool stack"):
> On Mon, May 9, 2016 at 10:57 AM, Jan Beulich  wrote:
> > Right now there's only tool stack related documentation there.
> >
> > Signed-off-by: Jan Beulich 
> 
> Acked-by: George Dunlap 
> 
> But I guess it really wants a tools maintainer's Ack.

Acked-by: Ian Jackson 

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94533: trouble: blocked/broken

2016-05-18 Thread osstest service owner

flight 94533 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94533/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  102 days
Testing same since93977  2016-05-10 11:09:16 Z8 days   21 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 test-amd64-amd64-pairblo

Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86

2016-05-18 Thread Boris Ostrovsky

On 05/18/2016 08:15 AM, Juergen Gross wrote:
>  }
>  
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> +  * We can't set paravirt_steal_rq_enabled as this would require the
> +  * capability to read another cpu's runstate info.
> +  */
> +}

Won't we be accounting for stolen cycles twice now --- once from
steal_account_process_tick()->steal_clock() and second time from
do_stolen_accounting()?

-boris


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

Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max

2016-05-18 Thread Juergen Gross

On 18/05/16 16:39, Ed Swierk wrote:
> Nice implementation. I tested it and it fixes the problem on the
> affected system.
> 
> Just a minor typo in a comment: "it's duty" should be "its duty".

Thanks. Corrected and sent to lkml.


Juergen

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

Re: [Xen-devel] [PATCH v2 for-4.7 12/14] libxl: fix passing the type argument to xc_psr_* [and 1 more messages]

2016-05-18 Thread Ian Jackson

Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type 
argument to xc_psr_*"):
> On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> > I'm very much against introducing casts which are not absolutely
> > necessary.  Casts are a big hammer which can suppress important
> > warnings (such as conversions between integers and pointers).
> > 
> > This anomaly with the same enum defined in two places with two names
> > is pretty poor.  But if we are to perpetuate it, as perhaps we must,
> > then rather than casting at each conversion point, we should introduce
> > an inline function which contains the cast.  That way each call site
> > remains more typesafe.
> 
> The two enums aren't going away any time soon.

Sadly, I think you're right.

> Does the following diff meet your requirement?

Yes, that is exactly the kind of thing I was thinking of.  It makes
the cast non-routine by putting it in a dedicated function whose
authors/readers know to check it's right.

Acked-by: Ian Jackson 

(with a suitable commit message)

Roger Pau Monne writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the 
type argument to xc_psr_*"):
> On Thu, Apr 28, 2016 at 09:49:11PM +0100, Wei Liu wrote:
> > +BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
> > +return (xc_psr_cat_type)type;
> 
> In order to prevent using a cast, we could use a union:
> 
> union {
> libxl_psr_cbm_type libxl_psr;
> xc_psr_cat_type xc_psr;
> } u;
> 
> u.libxl_psr = type;
> return u.xc_psr;

No, not really.

Firstly, although we compile with -fno-strict-aliasing, this is a bad
example in these days of hostile optimisers: without
-fno-strict-aliasing, the compiler is allowed to assume that the loads
and stores are to different variables, even though the contrary is
evident.

Secondly, it's clumsy.

Thirdly, this kind of union aliasing is normally used for
representation (structure) punning.


Thanks,
Ian.

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

[Xen-devel] [PATCH] xen: use same main loop for counting and remapping pages

2016-05-18 Thread Juergen Gross

Instead of having two functions for cycling through the E820 map in
order to count to be remapped pages and remap them later, just use one
function with a caller supplied sub-function called for each region to
be processed. This eliminates the possibility of a mismatch between
both loops which showed up in certain configurations.

Suggested-by: Ed Swierk 
Signed-off-by: Juergen Gross 
---
 arch/x86/xen/setup.c | 65 +---
 1 file changed, 26 insertions(+), 39 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7ab2951..e345891 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -393,6 +393,9 @@ static unsigned long __init 
xen_set_identity_and_remap_chunk(
unsigned long i = 0;
unsigned long n = end_pfn - start_pfn;
 
+   if (remap_pfn == 0)
+   remap_pfn = nr_pages;
+
while (i < n) {
unsigned long cur_pfn = start_pfn + i;
unsigned long left = n - i;
@@ -438,17 +441,29 @@ static unsigned long __init 
xen_set_identity_and_remap_chunk(
return remap_pfn;
 }
 
-static void __init xen_set_identity_and_remap(unsigned long nr_pages)
+static unsigned long __init xen_count_remap_pages(
+   unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages,
+   unsigned long remap_pages)
+{
+   if (start_pfn >= nr_pages)
+   return remap_pages;
+
+   return remap_pages + min(end_pfn, nr_pages) - start_pfn;
+}
+
+static unsigned long __init xen_foreach_remap_area(unsigned long nr_pages,
+   unsigned long (*func)(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned long nr_pages, unsigned long last_val))
 {
phys_addr_t start = 0;
-   unsigned long last_pfn = nr_pages;
+   unsigned long ret_val = 0;
const struct e820entry *entry = xen_e820_map;
int i;
 
/*
 * Combine non-RAM regions and gaps until a RAM region (or the
-* end of the map) is reached, then set the 1:1 map and
-* remap the memory in those non-RAM regions.
+* end of the map) is reached, then call the provided function
+* to perform its duty on the non-RAM region.
 *
 * The combined non-RAM regions are rounded to a whole number
 * of pages so any partial pages are accessible via the 1:1
@@ -466,14 +481,13 @@ static void __init xen_set_identity_and_remap(unsigned 
long nr_pages)
end_pfn = PFN_UP(entry->addr);
 
if (start_pfn < end_pfn)
-   last_pfn = xen_set_identity_and_remap_chunk(
-   start_pfn, end_pfn, nr_pages,
-   last_pfn);
+   ret_val = func(start_pfn, end_pfn, nr_pages,
+  ret_val);
start = end;
}
}
 
-   pr_info("Released %ld page(s)\n", xen_released_pages);
+   return ret_val;
 }
 
 /*
@@ -596,35 +610,6 @@ static void __init xen_ignore_unusable(void)
}
 }
 
-static unsigned long __init xen_count_remap_pages(unsigned long max_pfn)
-{
-   unsigned long extra = 0;
-   unsigned long start_pfn, end_pfn;
-   const struct e820entry *entry = xen_e820_map;
-   int i;
-
-   end_pfn = 0;
-   for (i = 0; i < xen_e820_map_entries; i++, entry++) {
-   start_pfn = PFN_DOWN(entry->addr);
-   /* Adjacent regions on non-page boundaries handling! */
-   end_pfn = min(end_pfn, start_pfn);
-
-   if (start_pfn >= max_pfn)
-   return extra + max_pfn - end_pfn;
-
-   /* Add any holes in map to result. */
-   extra += start_pfn - end_pfn;
-
-   end_pfn = PFN_UP(entry->addr + entry->size);
-   end_pfn = min(end_pfn, max_pfn);
-
-   if (entry->type != E820_RAM)
-   extra += end_pfn - start_pfn;
-   }
-
-   return extra;
-}
-
 bool __init xen_is_e820_reserved(phys_addr_t start, phys_addr_t size)
 {
struct e820entry *entry;
@@ -804,7 +789,7 @@ char * __init xen_memory_setup(void)
max_pages = xen_get_max_pages();
 
/* How many extra pages do we need due to remapping? */
-   max_pages += xen_count_remap_pages(max_pfn);
+   max_pages += xen_foreach_remap_area(max_pfn, xen_count_remap_pages);
 
if (max_pages > max_pfn)
extra_pages += max_pages - max_pfn;
@@ -922,7 +907,9 @@ char * __init xen_memory_setup(void)
 * Set identity map on non-RAM pages and prepare remapping the
 * underlying RAM.
 */
-   xen_set_identity_and_remap(max_pfn);
+   xen_foreach_remap_area(max_pfn, xen_set_identity_and_remap_chunk);
+
+   pr_info("Released %ld page(s)\n", xen_released_pages);
 
return

Re: [Xen-devel] 2nd opinion on backportability of c35eefded2

2016-05-18 Thread George Dunlap

On 13/05/16 10:32, Jan Beulich wrote:
> Hi George,
> 
> after quite a bit of debugging on 4.6.1 I learned that said commit
> ("x86/P2M: consolidate handling of types not requiring a valid MFN")
> is more than just cleanup: Since p2m_set_entry() happily performs
> arithmetic on the passed in MFN, shadow mode guests (verified) as
> well as HAP ones when 1Gb / 2Mb mappings are unavailable (not
> verified), if any of the MFNs below 1Gb are invalid (reported with
> e.g. "crashkernel=512M@16M"), p2m_pt_set_entry() would (in
> the context of guest_physmap_mark_populate_on_demand())
> produce invalid instead of PoD entries, resulting in subsequent
> attempts by the guest to use (e.g. balloon out) these pages to
> fail (the balloon failure results in a crash during boot).

I'm sorry, I'm having some trouble parsing this paragraph. :-)

But this is what I gather:

Before c35eefded2, the 4k-entry path didn't check whether the p2m entry
was PoD, it only checked that the mfn was valid.  The pod code would
always set this mfn to 0, which is (usually) valid; but p2m_set_entry()
might iterate over this, ending up in p2m_pt_set_entry() with non-zero
low values for mfn.  In certain circumstances these low-value mfns might
actually be invalid (for example, if they overlap a crash kernel).

In such a case, the resulting p2m entries would be (erroneously) marked
as invalid rather than PoD, resulting in a crash when the guest tried to
access it or populate it.

You observed this happening in the shadow case, and believe it would
happen if p2m 2MiB or 1GiB pages were disabled but haven't checked those
cases.

c35eefded2 fixes this by implicitly checking for the PoD type on the 4k
entry path.

> Now, while the backport to 4.6 is straightforward, I'm having the
> vague feeling that this change might depend on some earlier one,
> but I can't pinpoint anything. Hence I would appreciate if you
> could take a look and provide your judgment.

We talked about the PoD type thing in the context of a discussion about
660fd65 ("x86/p2m-pt: tighten conditions of IOMMU mapping updates") --
discussion here [1].  But it doesn't look like that's a prerequisite,
and nothing else really comes to mind.

 -George

[1] marc.info/?i=<560d261d0278000a7...@prv-mh.provo.novell.com>

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

Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max

2016-05-18 Thread Ed Swierk

Nice implementation. I tested it and it fixes the problem on the affected
system.

Just a minor typo in a comment: "it's duty" should be "its duty".

--Ed


On Wed, May 18, 2016 at 4:44 AM, Juergen Gross  wrote:

> On 17/05/16 22:50, Ed Swierk wrote:
> > I added some more instrumentation and discovered that the result of
> > xen_count_remap_pages() (0x85dea) is one less than the actual number
> > of pages remapped by xen_set_identity_and_remap() (0x85deb).
> >
> > The two functions differ in their handling of a xen_e820_map entry
> > whose size is not a multiple of the page size.  The entry starting at
> > 0x68000 has size 0x33400.  xen_count_remap_pages() rounds up when
> > computing the end_pfn (to 0x9c), while xen_set_identity_and_remap()
> > rounds down (to 0x9b).  Thus xen_count_remap_pages() counts the
> > remapped space following the entry as one page smaller than the other
> > function does.
>
> Could you please test the attached patch? It follows your idea of the
> combined function, but is using a function pointer instead of a flag.
> The patch is based on 4.6, but I believe it should just work on 4.4.
>
>
> Juergen
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] state of xenified SUSE kernel

2016-05-18 Thread Andreas Kinzler


On 17.05.2016 17:34, Jan Beulich wrote:

We use xenified kernels based on kernel 3.4 for years and benchmarks
showed that they are faster than the pvops (vanilla) kernels.
But what is the current state in terms of performance and features?

I'm not sure what you expect here. Up to openSUSE 42.1 and
SLE 12 SP1 they are fully maintained, i.e. you can get quite a
bit newer than 3.4 based kernels. There's not a lot of
performance analysis that I would be aware of, so I can't
answer that part anyway. And them being release branches
rather than development ones, there's not going to be any
new feature work.


As far as I know the patches are based on the original work for kernel 
2.6.18 and have not been adjusted to major changes in Xen architecture. 
So what I am thinking about is performance improvements that result from 
using newer Xen features. So the question was: from an architectural 
point of view should pvops in recent vanilla kernels be "better" then 
xenified kernels?


Regards Andreas

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

Re: [Xen-devel] [PATCH for-qemu-trad] Fix build with newer version of GNUTLS

2016-05-18 Thread Ian Jackson

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH for-qemu-trad] Fix build 
with newer version of GNUTLS"):
> On Thu, May 05, 2016 at 11:14:44AM +0100, Wei Liu wrote:
> > Provide compatibility layer for QEMU traditional. This commit is in fact
> > backport of two upstream QEMU commits:
> > 1. f40d55081667a716312b9a8b6e13835c4074f56b
> > 2. 7d2a929feba319c18603e324b1750830d6c8b7a1
...
> > Signed-off-by: Sjoer van der Ploeg 
> > Signed-off-by: Wei Liu 
> 
> Tested-by: Konrad Rzeszutek Wilk 
> 
> on
> gnutls-3.4.9-1.fc23.x86_64
> 
> And it fixes the build problems.

Thanks to everyone.  I have applied this to my local tree and queued
it for push.  I have also queued it for backport.

Ian.

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

Re: [Xen-devel] [PATCH RFC] Tmem cleanups for 4.7 (hopefully?).

2016-05-18 Thread Konrad Rzeszutek Wilk

On Tue, May 17, 2016 at 09:11:16PM -0500, Doug Goldstein wrote:
> On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> > Hey,
> > 
> > These four little cleanups move the bulk of tmem control ops
> > from tmem.c to tmem_control.c.
> > 
> > Last release I moved the control tmem ops from being part of tmem
> > hypercall to be part of the syscall subops - and this is the next
> > step in this cleanup. (See
> > http://lists.xen.org/archives/html/xen-devel/2015-10/msg03313.html)
> > which will allow me to follow up on the other steps:
> >  b) Fix the toolstack (cleanup)
> >  c) tmem tze, dedup, and zlib code drop
> > 
> > Anyhow sorry for this being so tardy - xSplice had more attention :-)
> > 
> > Regression tests show no problems.
> > 
> > The patches themselves have no functionality changes thought I was itching
> > to remove most of the counters. I will do that going forward, but need
> > to figure out which ones make sense or if some of them can be coalesced.
> > 
> >  xen/common/Makefile|   2 +-
> >  xen/common/tmem.c  | 618 
> > +
> >  xen/common/tmem_control.c  | 443 +
> >  xen/include/xen/tmem_control.h |  33 +++
> >  xen/include/xen/tmem_xen.h | 128 +
> >  5 files changed, 672 insertions(+), 552 deletions(-)
> > 
> > Konrad Rzeszutek Wilk (4):
> >   tmem: Move global stats in a tmem_statistics structure
> >   tmem: Wrap atomic_t in struct tmem_statistics as well.
> >   tmem: Move global_ individual variables in a global structure.
> >   tmem: Move bulk of tmem control functions in its own file.
> > 
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> > 
> 
> So overall applying all 4 patches results in something that I think is
> better. I think some improvement on the bisect-ability of the patches
> and I'll toss my Reviewed-by: Doug Goldstein  on the
> series.

The bisection-ability is there. Each individual patch compiles just fine
(double-checking that right now).

Thanks!

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

Re: [Xen-devel] Saving a guest crashes dom0

2016-05-18 Thread Paul Durrant

> > -Original Message-
> > From: Paul Durrant
> > Sent: 18 May 2016 15:18
> > To: 'Boris Ostrovsky'; xen-devel
> > Subject: RE: Saving a guest crashes dom0
> >
> > > -Original Message-
> > > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> > > Sent: 18 May 2016 14:54
> > > To: xen-devel; Paul Durrant
> > > Subject: Saving a guest crashes dom0
> > >
> > > Saving a guest (xl save) crashes dom0, log below.
> > >
> > > Paul, this seems to be happening in the code that you modified
> > > recently.  If you don't have time I can look at this but it will
> > > probably have to wait until tomorrow.
> > >
> >
> > No, this looks problematic, I'll look now... What was the guest?
> >
> 
> Never mind. I see the problem. Disconnection of the control ring is done
> regardless of whether a control ring was connected and the hash deinit is not
> adequately protected. I'll come up with a patch.
> 

This should fix the problem for you:

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 1c7f49b..83deeeb 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
vif->ctrl_task = NULL;
}

-   xenvif_deinit_hash(vif);
-
if (vif->ctrl_irq) {
+   xenvif_deinit_hash(vif);
unbind_from_irqhandler(vif->ctrl_irq, vif);
vif->ctrl_irq = 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  7 host-ping-check-xen   fail REGR. vs. 94506
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat fail REGR. vs. 94506
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 94506

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   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-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuua257c741491ff1c3c192d13a89c136dd6401c54d
baseline version:
 qemuuc98e7937119503d06dbb494b7e4806ec66a27df0

Last test of basis94506  2016-05-17 09:48:40 Z1 days
Testing same since94530  2016-05-17 23:10:46 Z0 days1 attempts


People who touched revisions under test:
  Alexander Yarygin 
  Changlong Xie 
  Christian Borntraeger 
  Cornelia Huck 
  Fan Zhang 
  Hollis Blanchard 
  Peter Maydell 
  Stefan Hajnoczi 
  xiaoqiang zhao 
  Yi Min Zhao 

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

Re: [Xen-devel] Saving a guest crashes dom0

2016-05-18 Thread Paul Durrant

> -Original Message-
> From: Paul Durrant
> Sent: 18 May 2016 15:18
> To: 'Boris Ostrovsky'; xen-devel
> Subject: RE: Saving a guest crashes dom0
> 
> > -Original Message-
> > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> > Sent: 18 May 2016 14:54
> > To: xen-devel; Paul Durrant
> > Subject: Saving a guest crashes dom0
> >
> > Saving a guest (xl save) crashes dom0, log below.
> >
> > Paul, this seems to be happening in the code that you modified
> > recently.  If you don't have time I can look at this but it will
> > probably have to wait until tomorrow.
> >
> 
> No, this looks problematic, I'll look now... What was the guest?
> 

Never mind. I see the problem. Disconnection of the control ring is done 
regardless of whether a control ring was connected and the hash deinit is not 
adequately protected. I'll come up with a patch.

  Paul

>   Paul
> 
> >
> > -boris
> >
> >
> > [  176.347760] BUG: unable to handle kernel NULL pointer dereference at
> > 0008
> > [  176.347780] IP: [] xenvif_flush_hash+0x6f/0xd0
> > [  176.347791] PGD 563f067 PUD 54b1067 PMD 0
> > [  176.347798] Oops:  [#1] SMP
> > [  176.347803] Modules linked in: dm_multipath dm_mod xen_evtchn
> > iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> > libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod ahci
> > libahci libata scsi_mod i915 e1000e video backlight wmi tpm_tis
> > xen_blkfront xen_netfront xenfs xen_privcmd
> > [  176.347840] CPU: 1 PID: 26 Comm: xenwatch Not tainted
> > 4.6.0upstream-03623-g0b7962a-dirty #1
> > [  176.347845] Hardware name: LENOVO ThinkServer TS130/, BIOS
> > 9HKT47AUS 01/10/2012
> > [  176.347850] task: 880037e22140 ti: 880037e4 task.ti:
> > 880037e4
> > [  176.347855] RIP: e030:[]  []
> > xenvif_flush_hash+0x6f/0xd0
> > [  176.347862] RSP: e02b:880037e43cb8  EFLAGS: 00010017
> > [  176.347866] RAX: 880006190250 RBX: 88000619f840 RCX:
> > 
> > [  176.347870] RDX: 0001 RSI: 81215ce0 RDI:
> > 88000619fad0
> > [  176.347875] RBP: 880037e43d28 R08: 0040 R09:
> > 0040
> > [  176.347879] R10: 0040 R11: 0001 R12:
> > 88000619fad0
> > [  176.347883] R13:  R14: 88000619fad8 R15:
> > 880037e43cd8
> > [  176.347892] FS:  7f3fa46cb710() GS:88003de8()
> > knlGS:
> > [  176.347927] CS:  e033 DS:  ES:  CR0: 80050033
> > [  176.347930] CR2: 0008 CR3: 06cad000 CR4:
> > 00042660
> > [  176.347935] Stack:
> > [  176.347939]  003e 880006190250 0002
> > 0006c560
> > [  176.347946]  88000619f850 0002 
> > 81476f4e
> > [  176.347952]  880037e43d18 88000619f840 0006
> > 0040
> > [  176.347959] Call Trace:
> > [  176.347963]  [] ? xenbus_unmap_ring_vfree+0xe/0x10
> > [  176.347968]  [] xenvif_deinit_hash+0x9/0x10
> > [  176.347973]  [] xenvif_disconnect_ctrl+0x3d/0xb0
> > [  176.347977]  [] set_backend_state+0x13c/0x200
> > [  176.347982]  [] frontend_changed+0x77/0xe0
> > [  176.347987]  [] xenbus_otherend_changed+0x9d/0xa0
> > [  176.347993]  [] frontend_changed+0xb/0x10
> > [  176.347997]  [] xenwatch_thread+0xc8/0x190
> > [  176.348002]  [] ? woken_wake_function+0x10/0x10
> > [  176.348008]  [] ? schedule+0x42/0xb0
> > [  176.348013]  [] ?
> > _raw_spin_unlock_irqrestore+0x15/0x20
> > [  176.348017]  [] ? join+0x60/0x60
> > [  176.348022]  [] kthread+0xd2/0xf0
> > [  176.348027]  [] ? finish_task_switch+0x91/0x220
> > [  176.348032]  [] ? schedule_tail+0x19/0xd0
> > [  176.348036]  [] ret_from_fork+0x1f/0x40
> > [  176.348041]  [] ?
> > kthread_freezable_should_stop+0x80/0x80
> > [  176.348045] Code: 90 02 00 00 4c 8d b3 98 02 00 00 4c 89 e7 e8 59 03
> > 22 00 4c 8b ab 98 02 00 00 48 89 45 98 4d 39 f5 4c 89 6d c0 74 48 4c 8d
> > 7d b0 <49> 8b 55 08 49 8b 45 00 48 bf 00 02 00 00 00 00 ad de 48 c7 c6
> > [  176.348095] RIP  [] xenvif_flush_hash+0x6f/0xd0
> > [  176.348101]  RSP 
> > [  176.348103] CR2: 0008
> > [  176.348108] ---[ end trace b58563dcb1aec61c ]---
> > [  176.348111] Kernel panic - not syncing: Fatal exception
> > [  176.348117] Kernel Offset: disabled
> > (XEN) [2016-05-18 13:06:05] Hardware Dom0 crashed: rebooting machine in
> > 5 seconds.
> > (XEN) [2016-05-18 13:06:10] Resetting with ACPI MEMORY or I/O
> RESET_REG.
> >

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

Re: [Xen-devel] Saving a guest crashes dom0

2016-05-18 Thread Paul Durrant

> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 18 May 2016 14:54
> To: xen-devel; Paul Durrant
> Subject: Saving a guest crashes dom0
> 
> Saving a guest (xl save) crashes dom0, log below.
> 
> Paul, this seems to be happening in the code that you modified
> recently.  If you don't have time I can look at this but it will
> probably have to wait until tomorrow.
> 

No, this looks problematic, I'll look now... What was the guest?

  Paul

> 
> -boris
> 
> 
> [  176.347760] BUG: unable to handle kernel NULL pointer dereference at
> 0008
> [  176.347780] IP: [] xenvif_flush_hash+0x6f/0xd0
> [  176.347791] PGD 563f067 PUD 54b1067 PMD 0
> [  176.347798] Oops:  [#1] SMP
> [  176.347803] Modules linked in: dm_multipath dm_mod xen_evtchn
> iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
> libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod ahci
> libahci libata scsi_mod i915 e1000e video backlight wmi tpm_tis
> xen_blkfront xen_netfront xenfs xen_privcmd
> [  176.347840] CPU: 1 PID: 26 Comm: xenwatch Not tainted
> 4.6.0upstream-03623-g0b7962a-dirty #1
> [  176.347845] Hardware name: LENOVO ThinkServer TS130/, BIOS
> 9HKT47AUS 01/10/2012
> [  176.347850] task: 880037e22140 ti: 880037e4 task.ti:
> 880037e4
> [  176.347855] RIP: e030:[]  []
> xenvif_flush_hash+0x6f/0xd0
> [  176.347862] RSP: e02b:880037e43cb8  EFLAGS: 00010017
> [  176.347866] RAX: 880006190250 RBX: 88000619f840 RCX:
> 
> [  176.347870] RDX: 0001 RSI: 81215ce0 RDI:
> 88000619fad0
> [  176.347875] RBP: 880037e43d28 R08: 0040 R09:
> 0040
> [  176.347879] R10: 0040 R11: 0001 R12:
> 88000619fad0
> [  176.347883] R13:  R14: 88000619fad8 R15:
> 880037e43cd8
> [  176.347892] FS:  7f3fa46cb710() GS:88003de8()
> knlGS:
> [  176.347927] CS:  e033 DS:  ES:  CR0: 80050033
> [  176.347930] CR2: 0008 CR3: 06cad000 CR4:
> 00042660
> [  176.347935] Stack:
> [  176.347939]  003e 880006190250 0002
> 0006c560
> [  176.347946]  88000619f850 0002 
> 81476f4e
> [  176.347952]  880037e43d18 88000619f840 0006
> 0040
> [  176.347959] Call Trace:
> [  176.347963]  [] ? xenbus_unmap_ring_vfree+0xe/0x10
> [  176.347968]  [] xenvif_deinit_hash+0x9/0x10
> [  176.347973]  [] xenvif_disconnect_ctrl+0x3d/0xb0
> [  176.347977]  [] set_backend_state+0x13c/0x200
> [  176.347982]  [] frontend_changed+0x77/0xe0
> [  176.347987]  [] xenbus_otherend_changed+0x9d/0xa0
> [  176.347993]  [] frontend_changed+0xb/0x10
> [  176.347997]  [] xenwatch_thread+0xc8/0x190
> [  176.348002]  [] ? woken_wake_function+0x10/0x10
> [  176.348008]  [] ? schedule+0x42/0xb0
> [  176.348013]  [] ?
> _raw_spin_unlock_irqrestore+0x15/0x20
> [  176.348017]  [] ? join+0x60/0x60
> [  176.348022]  [] kthread+0xd2/0xf0
> [  176.348027]  [] ? finish_task_switch+0x91/0x220
> [  176.348032]  [] ? schedule_tail+0x19/0xd0
> [  176.348036]  [] ret_from_fork+0x1f/0x40
> [  176.348041]  [] ?
> kthread_freezable_should_stop+0x80/0x80
> [  176.348045] Code: 90 02 00 00 4c 8d b3 98 02 00 00 4c 89 e7 e8 59 03
> 22 00 4c 8b ab 98 02 00 00 48 89 45 98 4d 39 f5 4c 89 6d c0 74 48 4c 8d
> 7d b0 <49> 8b 55 08 49 8b 45 00 48 bf 00 02 00 00 00 00 ad de 48 c7 c6
> [  176.348095] RIP  [] xenvif_flush_hash+0x6f/0xd0
> [  176.348101]  RSP 
> [  176.348103] CR2: 0008
> [  176.348108] ---[ end trace b58563dcb1aec61c ]---
> [  176.348111] Kernel panic - not syncing: Fatal exception
> [  176.348117] Kernel Offset: disabled
> (XEN) [2016-05-18 13:06:05] Hardware Dom0 crashed: rebooting machine in
> 5 seconds.
> (XEN) [2016-05-18 13:06:10] Resetting with ACPI MEMORY or I/O RESET_REG.
> 

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

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

2016-05-18 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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

version targeted for testing:
 seabios  1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
baseline version:
 seabios  c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a

Last test of basis44361  2016-04-24 01:21:29 Z   24 days
Testing same since44429  2016-05-18 09:54:18 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 

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



sg-report-flight on osstest.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 1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
Author: Kevin O'Connor 
Date:   Mon May 16 20:51:17 2016 -0400

tcgbios: Remove unused const variable

Remove the unused array `PhysicalPresence_CMD_DISABLE` to fix GCC 6
warnings.

Signed-off-by: Paul Menzel 
Signed-off-by: Kevin O'Connor 

commit 0024cd77f88a38036a228fb885217ff06e97464c
Author: Kevin O'Connor 
Date:   Mon May 16 20:50:28 2016 -0400

usb-xhci: Remove unused const variables

Remove the unused arrays `eptype_to_xhci_in` and `eptype_to_xhci_out` to
fix GCC 6 warnings.

Signed-off-by: Paul Menzel 
Signed-off-by: Kevin O'Connor 

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

[Xen-devel] Saving a guest crashes dom0

2016-05-18 Thread Boris Ostrovsky

Saving a guest (xl save) crashes dom0, log below.

Paul, this seems to be happening in the code that you modified
recently.  If you don't have time I can look at this but it will
probably have to wait until tomorrow.


-boris


[  176.347760] BUG: unable to handle kernel NULL pointer dereference at
0008
[  176.347780] IP: [] xenvif_flush_hash+0x6f/0xd0
[  176.347791] PGD 563f067 PUD 54b1067 PMD 0
[  176.347798] Oops:  [#1] SMP
[  176.347803] Modules linked in: dm_multipath dm_mod xen_evtchn
iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod ahci
libahci libata scsi_mod i915 e1000e video backlight wmi tpm_tis
xen_blkfront xen_netfront xenfs xen_privcmd
[  176.347840] CPU: 1 PID: 26 Comm: xenwatch Not tainted
4.6.0upstream-03623-g0b7962a-dirty #1
[  176.347845] Hardware name: LENOVO ThinkServer TS130/, BIOS
9HKT47AUS 01/10/2012
[  176.347850] task: 880037e22140 ti: 880037e4 task.ti:
880037e4
[  176.347855] RIP: e030:[]  []
xenvif_flush_hash+0x6f/0xd0
[  176.347862] RSP: e02b:880037e43cb8  EFLAGS: 00010017
[  176.347866] RAX: 880006190250 RBX: 88000619f840 RCX:

[  176.347870] RDX: 0001 RSI: 81215ce0 RDI:
88000619fad0
[  176.347875] RBP: 880037e43d28 R08: 0040 R09:
0040
[  176.347879] R10: 0040 R11: 0001 R12:
88000619fad0
[  176.347883] R13:  R14: 88000619fad8 R15:
880037e43cd8
[  176.347892] FS:  7f3fa46cb710() GS:88003de8()
knlGS:
[  176.347927] CS:  e033 DS:  ES:  CR0: 80050033
[  176.347930] CR2: 0008 CR3: 06cad000 CR4:
00042660
[  176.347935] Stack:
[  176.347939]  003e 880006190250 0002
0006c560
[  176.347946]  88000619f850 0002 
81476f4e
[  176.347952]  880037e43d18 88000619f840 0006
0040
[  176.347959] Call Trace:
[  176.347963]  [] ? xenbus_unmap_ring_vfree+0xe/0x10
[  176.347968]  [] xenvif_deinit_hash+0x9/0x10
[  176.347973]  [] xenvif_disconnect_ctrl+0x3d/0xb0
[  176.347977]  [] set_backend_state+0x13c/0x200
[  176.347982]  [] frontend_changed+0x77/0xe0
[  176.347987]  [] xenbus_otherend_changed+0x9d/0xa0
[  176.347993]  [] frontend_changed+0xb/0x10
[  176.347997]  [] xenwatch_thread+0xc8/0x190
[  176.348002]  [] ? woken_wake_function+0x10/0x10
[  176.348008]  [] ? schedule+0x42/0xb0
[  176.348013]  [] ? _raw_spin_unlock_irqrestore+0x15/0x20
[  176.348017]  [] ? join+0x60/0x60
[  176.348022]  [] kthread+0xd2/0xf0
[  176.348027]  [] ? finish_task_switch+0x91/0x220
[  176.348032]  [] ? schedule_tail+0x19/0xd0
[  176.348036]  [] ret_from_fork+0x1f/0x40
[  176.348041]  [] ?
kthread_freezable_should_stop+0x80/0x80
[  176.348045] Code: 90 02 00 00 4c 8d b3 98 02 00 00 4c 89 e7 e8 59 03
22 00 4c 8b ab 98 02 00 00 48 89 45 98 4d 39 f5 4c 89 6d c0 74 48 4c 8d
7d b0 <49> 8b 55 08 49 8b 45 00 48 bf 00 02 00 00 00 00 ad de 48 c7 c6
[  176.348095] RIP  [] xenvif_flush_hash+0x6f/0xd0
[  176.348101]  RSP 
[  176.348103] CR2: 0008
[  176.348108] ---[ end trace b58563dcb1aec61c ]---
[  176.348111] Kernel panic - not syncing: Fatal exception
[  176.348117] Kernel Offset: disabled
(XEN) [2016-05-18 13:06:05] Hardware Dom0 crashed: rebooting machine in
5 seconds.
(XEN) [2016-05-18 13:06:10] Resetting with ACPI MEMORY or I/O RESET_REG.



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

Re: [Xen-devel] [PATCH v2 for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

2016-05-18 Thread Wei Liu

On Fri, May 13, 2016 at 06:25:41PM +0100, Andrew Cooper wrote:
> hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
> general L1 p2m walk.  It is fine for AMD as NPT share the same format as
> normal pagetables.  For Intel EPT however, it is wrong.
> 
> The translation ends up correct (as the formats are sufficiently similar), but
> the control bits in lower 12 bits differ in meaning.  A plain PT walker sets
> A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and
> top bit of EMT (caching type).  This in turn causes problem when the EPT
> tables are subsequently used.
> 
> Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in
> paging_gva_to_gfn(), which is the correct function for the task.  This
> involves making nestedhap_walk_L1_p2m() non-static, and adding
> vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable
> from contexts other than v == current.
> 
> Signed-off-by: Andrew Cooper 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

2016-05-18 Thread George Dunlap

On Fri, May 13, 2016 at 6:25 PM, Andrew Cooper
 wrote:
> hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
> general L1 p2m walk.  It is fine for AMD as NPT share the same format as
> normal pagetables.  For Intel EPT however, it is wrong.
>
> The translation ends up correct (as the formats are sufficiently similar), but
> the control bits in lower 12 bits differ in meaning.  A plain PT walker sets
> A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and
> top bit of EMT (caching type).  This in turn causes problem when the EPT
> tables are subsequently used.
>
> Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in
> paging_gva_to_gfn(), which is the correct function for the task.  This
> involves making nestedhap_walk_L1_p2m() non-static, and adding
> vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable
> from contexts other than v == current.
>
> Signed-off-by: Andrew Cooper 

Acked-by: George Dunlap 

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

[Xen-devel] [PATCH v2] tools: bump library version numbers

2016-05-18 Thread Wei Liu

The following libraries are checked:
1. libxc, version number bumped
2. libxl, version number bumped
3. libxlu, no development in 4.7 cycle, but depends on libxl, version
   number bumped
4. libs/*, new in 4.7 cycle, version numbers not bumped
5. libxenstore, no development in 4.7 cycle, version number not bumped
6. libxenstat, no development in 4.7 cycle, version number not bumped
7. libvchan, depends on  xengnttab library, API changed, version number
   bumped

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libvchan/Makefile | 2 +-
 tools/libxc/Makefile| 2 +-
 tools/libxl/Makefile| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index 0573d2f..6d1a724 100644
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -14,7 +14,7 @@ LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab) 
$(LDLIBS_libxengnts
 $(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) 
$(CFLAGS_libxengnttab) $(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn)
 $(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab) 
$(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn)
 
-MAJOR = 1.0
+MAJOR = 4.7
 MINOR = 0
 
 CFLAGS += -I../include -I.
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ef02c9d..05264c7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -1,7 +1,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR= 4.6
+MAJOR= 4.7
 MINOR= 0
 
 ifeq ($(CONFIG_LIBXC_MINIOS),y)
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4fc264d..defeb40 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -5,10 +5,10 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR = 4.6
+MAJOR = 4.7
 MINOR = 0
 
-XLUMAJOR = 4.6
+XLUMAJOR = 4.7
 XLUMINOR = 0
 
 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
-- 
2.1.4


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

Re: [Xen-devel] [PATCH for-4.7] tools: bump library version numbers

2016-05-18 Thread Wei Liu

On Wed, May 18, 2016 at 02:32:15PM +0100, Wei Liu wrote:
> The following libraries are checked:
> 1. libxc, version number bumped
> 2. libxl, version number bumped
> 3. libxlu, no development in 4.7 cycle, version number not bumped
> 4. libs/*, new in 4.7 cycle, version number not bumped
> 5. libxenstore, no development in 4.7 cycle, version number not bumped
> 6. libxenstat, no development in 4.7 cycle, version number not bumped
> 7. libvchan, depends on  xengnttab library, API changed, version number
>bumped
> 
> Signed-off-by: Wei Liu 

Please ignore this version. The commit message is wrong.

Hit "send" too fast, sorry.

Wei.

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

[Xen-devel] [PATCH for-4.7] tools: bump library version numbers

2016-05-18 Thread Wei Liu

The following libraries are checked:
1. libxc, version number bumped
2. libxl, version number bumped
3. libxlu, no development in 4.7 cycle, version number not bumped
4. libs/*, new in 4.7 cycle, version number not bumped
5. libxenstore, no development in 4.7 cycle, version number not bumped
6. libxenstat, no development in 4.7 cycle, version number not bumped
7. libvchan, depends on  xengnttab library, API changed, version number
   bumped

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libvchan/Makefile | 2 +-
 tools/libxc/Makefile| 2 +-
 tools/libxl/Makefile| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index 0573d2f..6d1a724 100644
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -14,7 +14,7 @@ LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab) 
$(LDLIBS_libxengnts
 $(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) 
$(CFLAGS_libxengnttab) $(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn)
 $(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab) 
$(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn)
 
-MAJOR = 1.0
+MAJOR = 4.7
 MINOR = 0
 
 CFLAGS += -I../include -I.
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ef02c9d..05264c7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -1,7 +1,7 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR= 4.6
+MAJOR= 4.7
 MINOR= 0
 
 ifeq ($(CONFIG_LIBXC_MINIOS),y)
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4fc264d..defeb40 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -5,10 +5,10 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-MAJOR = 4.6
+MAJOR = 4.7
 MINOR = 0
 
-XLUMAJOR = 4.6
+XLUMAJOR = 4.7
 XLUMINOR = 0
 
 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
-- 
2.1.4


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

1 2 >

1 - 100 of 152 matches

Mail list logo