Re: [Xen-devel] [PATCH v2 1/2] xen: move wallclock functions from x86 to common

[Shannon Zhao]

Hi Stefano,

When I apply this patch, there are some warnings.

Applying: xen: move wallclock functions from x86 to common
/home/open-source/xen/.git/rebase-apply/patch:268: trailing whitespace.
return wc_sec + (wc_nsec + NOW()) / 10ULL
/home/open-source/xen/.git/rebase-apply/patch:299: new blank line at EOF.
+
warning: 2 lines add whitespace errors.

On 2015/11/10 1:32, sstabell...@kernel.org wrote:
> From: Stefano Stabellini 
> 
> Remove dummy arm implementation of wallclock_time.
> Use shared_info() in common code rather than x86-ism to access it, when
> possible.
> 
> Define the static variable wc_sec, and the local variale sec in
> update_domain_wallclock_time, as uint64_t instead of unsigned long, to
> avoid size issue on arm.
> Take a uint64_t sec paramter in do_settime for the same reason.
> 
> Signed-off-by: Stefano Stabellini 
> CC: jbeul...@suse.com
> CC: andrew.coop...@citrix.com
> 
> ---
> Changes in v2:
> - remove stray blank lines
> - remove include 
> - move version_update_* to include/xen/time.h
> - introduce ifdef to fix build issue in common/time.c
> - define wc_sec and sec as uint64_t
> - pass u64 to do_settime
> ---
>  xen/arch/arm/time.c|5 ---
>  xen/arch/x86/time.c|   96 
> +---
>  xen/common/time.c  |   96 
> +++-
>  xen/include/xen/time.h |5 ++-
>  4 files changed, 100 insertions(+), 102 deletions(-)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 5ded30c..6207615 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -280,11 +280,6 @@ void domain_set_time_offset(struct domain *d, int64_t 
> time_offset_seconds)
>  /* XXX update guest visible wallclock time */
>  }
>  
> -struct tm wallclock_time(uint64_t *ns)
> -{
> -return (struct tm) { 0 };
> -}
> -
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index bbb7e6c..0f16db5 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -47,9 +47,6 @@ string_param("clocksource", opt_clocksource);
>  unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
>  DEFINE_SPINLOCK(rtc_lock);
>  unsigned long pit0_ticks;
> -static unsigned long wc_sec; /* UTC time at last 'time update'. */
> -static unsigned int wc_nsec;
> -static DEFINE_SPINLOCK(wc_lock);
>  
>  struct cpu_time {
>  u64 local_tsc_stamp;
> @@ -783,10 +780,6 @@ uint64_t tsc_ticks2ns(uint64_t ticks)
>  return scale_delta(ticks, &t->tsc_scale);
>  }
>  
> -/* Explicitly OR with 1 just in case version number gets out of sync. */
> -#define version_update_begin(v) (((v)+1)|1)
> -#define version_update_end(v)   ((v)+1)
> -
>  static void __update_vcpu_system_time(struct vcpu *v, int force)
>  {
>  struct cpu_time   *t;
> @@ -900,37 +893,6 @@ void force_update_vcpu_system_time(struct vcpu *v)
>  __update_vcpu_system_time(v, 1);
>  }
>  
> -void update_domain_wallclock_time(struct domain *d)
> -{
> -uint32_t *wc_version;
> -unsigned long sec;
> -
> -spin_lock(&wc_lock);
> -
> -wc_version = &shared_info(d, wc_version);
> -*wc_version = version_update_begin(*wc_version);
> -wmb();
> -
> -sec = wc_sec + d->time_offset_seconds;
> -if ( likely(!has_32bit_shinfo(d)) )
> -{
> -d->shared_info->native.wc_sec= sec;
> -d->shared_info->native.wc_nsec   = wc_nsec;
> -d->shared_info->native.wc_sec_hi = sec >> 32;
> -}
> -else
> -{
> -d->shared_info->compat.wc_sec = sec;
> -d->shared_info->compat.wc_nsec= wc_nsec;
> -d->shared_info->compat.arch.wc_sec_hi = sec >> 32;
> -}
> -
> -wmb();
> -*wc_version = version_update_end(*wc_version);
> -
> -spin_unlock(&wc_lock);
> -}
> -
>  static void update_domain_rtc(void)
>  {
>  struct domain *d;
> @@ -988,27 +950,6 @@ int cpu_frequency_change(u64 freq)
>  return 0;
>  }
>  
> -/* Set clock to  after 00:00:00 UTC, 1 January, 1970. */
> -void do_settime(unsigned long secs, unsigned int nsecs, u64 system_time_base)
> -{
> -u64 x;
> -u32 y;
> -struct domain *d;
> -
> -x = SECONDS(secs) + nsecs - system_time_base;
> -y = do_div(x, 10);
> -
> -spin_lock(&wc_lock);
> -wc_sec  = x;
> -wc_nsec = y;
> -spin_unlock(&wc_lock);
> -
> -rcu_read_lock(&domlist_read_lock);
> -for_each_domain ( d )
> -update_domain_wallclock_time(d);
> -rcu_read_unlock(&domlist_read_lock);
> -}
> -
>  /* Per-CPU communication between rendezvous IRQ and softirq handler. */
>  struct cpu_calibration {
>  u64 local_tsc_stamp;
> @@ -1608,25 +1549,6 @@ void send_timer_event(struct vcpu *v)
>  send_guest_vcpu_virq(v, VIRQ_TIMER);
>  }
>  
> -/* Return secs after 00:00:00 localtime, 1 January, 1970. */
> -unsigned long get_localtime(struct domain *d)
> -{
> -return wc_sec + (wc_nsec + NOW()) / 10ULL 
> -+ d->time_offset_

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

[Shannon Zhao]

Hi Stefano,

When I apply this patch, there are some warnings too.

Applying: arm: export platform_op XENPF_settime64
/home/open-source/xen/.git/rebase-apply/patch:67: trailing whitespace.
 *
/home/open-source/xen/.git/rebase-apply/patch:69: trailing whitespace.
 *
/home/open-source/xen/.git/rebase-apply/patch:172: trailing whitespace.

warning: 3 lines add whitespace errors.

On 2015/11/10 1:32, sstabell...@kernel.org wrote:
> From: Stefano Stabellini 
> 
> Call update_domain_wallclock_time at domain initialization, specifically
> in arch_set_info_guest for vcpu0, like we do on x86.
> Set time_offset_seconds to the number of seconds between phisical boot
> and domain initialization: it is going to be used to get/set the
> wallclock time.
> Add time_offset_seconds to system_time when before calling do_settime,
> so that system_time actually accounts for all the time in nsec between
> machine boot and when the wallclock was set.
> 
> 
> 
> Signed-off-by: Stefano Stabellini 
> CC: dgde...@tycho.nsa.gov
> 
> ---
> 
> Changes in v2:
> - drop XENPF_settime32
> - set time_offset_seconds
> - modify xen/xsm/flask/hooks.c
> ---
>  xen/arch/arm/Makefile |1 +
>  xen/arch/arm/domain.c |9 ++
>  xen/arch/arm/platform_hypercall.c |   62 
> +
>  xen/arch/arm/traps.c  |1 +
>  xen/arch/arm/vtimer.c |1 -
>  xen/include/asm-arm/time.h|2 ++
>  xen/include/xsm/dummy.h   |   12 +++
>  xen/include/xsm/xsm.h |   13 
>  xen/xsm/flask/hooks.c |2 +-
>  9 files changed, 89 insertions(+), 14 deletions(-)
>  create mode 100644 xen/arch/arm/platform_hypercall.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 1ef39f7..240aa29 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -23,6 +23,7 @@ obj-y += percpu.o
>  obj-y += guestcopy.o
>  obj-y += physdev.o
>  obj-y += platform.o
> +obj-y += platform_hypercall.o
>  obj-y += setup.o
>  obj-y += bootfdt.o
>  obj-y += time.o
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index b2bfc7d..1f07a41 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -21,6 +21,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -742,6 +743,14 @@ int arch_set_info_guest(
>  v->arch.ttbr1 = ctxt->ttbr1;
>  v->arch.ttbcr = ctxt->ttbcr;
>  
> +if ( v->vcpu_id == 0 )
> +{
> +struct domain *d = v->domain;
> +d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset 
> - boot_count);
> +do_div(d->time_offset_seconds, 10);
> +update_domain_wallclock_time(d);
> +}
> +
>  v->is_initialised = 1;
>  
>  if ( ctxt->flags & VGCF_online )
> diff --git a/xen/arch/arm/platform_hypercall.c 
> b/xen/arch/arm/platform_hypercall.c
> new file mode 100644
> index 000..cb8e575
> --- /dev/null
> +++ b/xen/arch/arm/platform_hypercall.c
> @@ -0,0 +1,62 @@
> +/**
> + * platform_hypercall.c
> + * 
> + * Hardware platform operations. Intended for use by domain-0 kernel.
> + * 
> + * Copyright (c) 2015, Citrix
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DEFINE_SPINLOCK(xenpf_lock);
> +
> +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
> +{
> +long ret;
> +struct xen_platform_op curop, *op = &curop;
> +struct domain *d;
> +
> +if ( copy_from_guest(op, u_xenpf_op, 1) )
> +return -EFAULT;
> +
> +if ( op->interface_version != XENPF_INTERFACE_VERSION )
> +return -EACCES;
> +
> +d = rcu_lock_current_domain();
> +if ( d == NULL )
> +return -ESRCH;
> +
> +ret = xsm_platform_op(XSM_PRIV, op->cmd);
> +if ( ret )
> +return ret;
> +
> +spin_lock(&xenpf_lock);
> +
> +switch ( op->cmd )
> +{
> +case XENPF_settime64:
> +if ( likely(!op->u.settime64.mbz) )
> +do_settime(op->u.settime64.secs,
> +   op->u.settime64.nsecs,
> +   op->u.settime64.system_time + 
> SECONDS(d->time_offset_seconds));
> +else
> +ret = -EINVAL;
> +break;
> +
> +default:
> +ret = -ENOSYS;
> +break;
> +}
> +
> +spin_unlock(&xenpf_lock);
> +rcu_unlock_domain(d);
> +return ret;
> +}
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 9d2bd6a..c49bd3f 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1233,6 +1233,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
>  HYPERCALL(hvm_op, 2),
>  HYPERCALL(grant_table_op, 3),
>  HYPERCALL(multicall, 2),
> +HYPERCALL(platform_op, 1),
>  HYPERCALL_ARM(vcpu_op, 3),
>  };
>  
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 11/10/2015 at 02:11 AM, in message
<22080.57829.461049.37...@mariner.uk.xensource.com>, Ian Jackson
 wrote: 
> Chunyan Liu writes ("[PATCH V8 3/7] libxl: add pvusb API"): 
> > Add pvusb APIs, including: 
> >  - attach/detach (create/destroy) virtual usb controller. 
> >  - attach/detach usb device 
> >  - list usb controller and usb devices 
> >  - some other helper functions 
>  
> Thanks for this. 
>  
>  
> I have reviewed it in detail (not just the ao handling aspects) and 
> (I'm afraid) produced a large number of comments, relating to style, 
> error handling, etc., as well as ao handling. 
>  
> Please let me know if anything I've said is unclear.  I've been rather 
> brief in my comments, rather than writing a paragraph for each one. 
> Thanks. 
>  
>  
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> > index dacfaae..a050e8b 100644 
> > --- a/tools/libxl/libxl.c 
> > +++ b/tools/libxl/libxl.c 
> > @@ -4218,11 +4218,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
> ... 
> > +/* Macro for defining device remove/destroy functions for usbctrl */ 
> > +/* Following functions are defined: 
> > + * libxl_device_usbctrl_remove 
> > + * libxl_device_usbctrl_destroy 
> > + */ 
> > + 
> > +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
>  
> As George has said, I would prefer to avoid committing this 
> duplication in-tree, even with a promise to de-duplicated it later. 
>  
>  
> > +void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t domid, 
> > +   libxl_device_usbctrl *usbctrl, 
> > +   libxl__ao_device *aodev) 
> > +{ 
>  
> Thanks for adjusting the error-handling patterns in these functions. 
> The new way is good, except that: 
>  
> > +out: 
> > +aodev->rc = rc; 
> > +if (rc) aodev->callback(egc, aodev); 
>  
> Here, rc is always set, and indeed the code would be wrong if it were 
> not.  So can you remove the conditional please ?  Ie: 

Reading the codes, libxl__wait_device_connection will call aodev->callback
properly. So here, only if (rc != 0), that means error happens, then we need to
call aodev->callback to end the process. (Refer to current 
libxl__device_disk_add,
all current code does similar work.) So I think the code is not wrong (?)

>  
>   +   aodev->callback(egc, aodev); 
>  
> The same goes for: 
>  
> > +static int 
> > +libxl__device_usb_remove(libxl__gc *gc, uint32_t domid, libxl_device_usb  
> *usb); 
> ... 
>  
> > +/* Remove usb devices first */ 
> > +rc  = libxl__device_usb_list_for_usbctrl(gc, domid, usbctrl_devid, 
> > + &usbs, &numusb); 
>  ^^ 
> While you're fixing other things, you could remove one of these space.s 
>  
> > +libxl_device_usbctrl * 
> > +libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num) 
> > +{ 
> ... 
> > +for (usbctrl = usbctrls; usbctrl < end; 
> > + usbctrl++, entry++, (*num)++) { 
>  
> I think this would be clearer if there were a line break at the first 
> semicolon too.  Ie, I like 
> for (A; B; C) { 
> or 
> for (A; 
>  B; 
>  C) { 
>  
> But I don't like very much 
> for (A; B; 
>  C) { 
> or 
> for (A; 
>  B; C) { 
>  
> > +#define READ_SUBPATH(path, subpath) ({  \ 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL,   \ 
> > +GCSPRINTF("%s/" subpath, path), \ 
> > +&tmp);  \ 
> > +if (rc) goto outerr;\ 
> > +(char *)tmp;\ 
> > +}) 
>  
> Thanks, I'm pleased with how you have done this. 
>  
> > +be_path = READ_SUBPATH(fe_path, "backend"); 
> > +usbctrl->backend_domid = atoi(READ_SUBPATH(fe_path,  
> "backend-id")); 
> > +usbctrl->version = atoi(READ_SUBPATH(be_path, "usb-ver")); 
> > +usbctrl->ports = atoi(READ_SUBPATH(be_path, "num-ports")); 
>  
> However, I have a question: 
>  
> Why do you use atoi here, but strtoul in libxl_device_usbctrl_getinfo ? 

Didn't care much about that. atoi and strtoul both work. Previously use aoti,
in libxl_device_usbctrl_getinfo, to keep consistent with other functions (like
libxl_device_disk_getinfo), use strtoul.

Will update and use the same.

>  
> > +int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t domid, 
> > +libxl_device_usbctrl *usbctrl, 
> > +libxl_usbctrlinfo *usbctrlinfo) 
> > +{ 
> ... 
> > +tmp = READ_SUBPATH(fe_path, "backend-id"); 
> > +usbctrlinfo->backend_id = tmp ? strtoul(tmp, NULL, 10) : -1; 
>  
> There are ten copies of this pattern with tmp and strtoul.  I really 
> think this needs to be refactored somehow.  Can you please make a 
>

Re: [Xen-devel] [PATCH v1 01/11] xsplice: Design document (v2).

[Ross Lagerwall]

On 11/03/2015 06:15 PM, Ross Lagerwall wrote:

From: Konrad Rzeszutek Wilk 

snip

+## Patching code
+
+The first mechanism to patch that comes in mind is in-place replacement.
+That is replace the affected code with new code. Unfortunately the x86
+ISA is variable size which places limits on how much space we have available
+to replace the instructions. That is not a problem if the change is smaller
+than the original opcode and we can fill it with nops. Problems will
+appear if the replacement code is longer.
+
+The second mechanism is by replacing the call or jump to the
+old function with the address of the new function.
+
+A third mechanism is to add a jump to the new function at the
+start of the old function.


Perhaps this document should be clarified to say what is actually 
implemented in this patch series? I.e. the third mechanism is the one 
that is actually implemented.



+
+### Example of trampoline and in-place splicing
+

snip

+## Addendum
+
+Implementation quirks should not be discussed in a design document.
+
+However these observations can provide aid when developing against this
+document.
+
+
+### Alternative assembler
+
+Alternative assembler is a mechanism to use different instructions depending
+on what the CPU supports. This is done by providing multiple streams of code
+that can be patched in - or if the CPU does not support it - padded with
+`nop` operations. The alternative assembler macros cause the compiler to
+expand the code to place a most generic code in place - emit a special
+ELF .section header to tag this location. During run-time the hypervisor
+can leave the areas alone or patch them with an better suited opcodes.


Note that if you patch any function that does a copy to or from guest 
memory, alternatives support is _required_ on Broadwell hardware because 
of SMAP (it patches in stac and clac).


This is actually implemented in this patch series.


+
+
+### When to patch
+
+During the discussion on the design two candidates bubbled where
+the call stack for each CPU would be deterministic. This would
+minimize the chance of the patch not being applied due to safety
+checks failing.
+
+ Rendezvous code instead of stop_machine for patching
+
+The hypervisor's time rendezvous code runs synchronously across all CPUs
+every second. Using the stop_machine to patch can stall the time rendezvous
+code and result in NMI. As such having the patching be done at the tail
+of rendezvous code should avoid this problem.
+
+However the entrance point for that code is
+do_softirq->timer_softirq_action->time_calibration
+which ends up calling on_selected_cpus on remote CPUs.
+
+The remote CPUs receive CALL_FUNCTION_VECTOR IPI and execute the
+desired function.
+
+ Before entering the guest code.
+
+Before we call VMXResume we check whether any soft IRQs need to be executed.
+This is a good spot because all Xen stacks are effectively empty at
+that point.
+
+To randezvous all the CPUs an barrier with an maximum timeout (which
+could be adjusted), combined with forcing all other CPUs through the
+hypervisor with IPIs, can be utilized to have all the CPUs be lockstep.
+
+The approach is similar in concept to stop_machine and the time rendezvous
+but is time-bound. However the local CPU stack is much shorter and
+a lot more deterministic.


This is implemented in this patch series.


+
+### Compiling the hypervisor code
+
+Hotpatch generation often requires support for compiling the target
+with -ffunction-sections / -fdata-sections.  Changes would have to
+be done to the linker scripts to support this.


As implemented, the current tool for payload generation requires no 
changes to Xen.
It is also possible to create a payload by compiling a C file containing 
the replacement functions that it completely separate from Xen itself.



+
+
+### Generation of xSplice ELF payloads
+
+The design of that is not discussed in this design.
+
+The author of this design envisions objdump and objcopy along
+with special GCC parameters (see above) to create .o.xsplice files
+which can be used to splice an ELF with the new payload.
+
+The ksplice or kpatching code can provide inspiration.


This is already implemented and the tool lives in a separate repo.


+
+### Exception tables and symbol tables growth
+
+We may need support for adapting or augmenting exception tables if
+patching such code.  Hotpatches may need to bring their own small
+exception tables (similar to how Linux modules support this).
+
+If supporting hotpatches that introduce additional exception-locations
+is not important, one could also change the exception table in-place
+and reorder it afterwards.


Almost every patch to a non-trivial function requires additional entries 
in the exception table and/or the bug frames.


This patch series allows each payload to introduce their own exception 
tables and bug frames to support this.



+
+### Security
+
+Only the privileged domain should be allowed to do this operation.

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 3ab1434a6ede4e006ef0b001108c354f4fa6d91e
baseline version:
 ovmf 3ec97ca490009ed5604ccd7f2653e5a9ecbf3474

Last test of basis63795  2015-11-08 01:58:30 Z2 days
Testing same since63933  2015-11-09 08:15:26 Z1 days1 attempts


People who touched revisions under test:
  Qiu Shumin 
  Yonghong Zhu 
  Zhang Lubo 

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=3ab1434a6ede4e006ef0b001108c354f4fa6d91e
+ . ./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 
3ab1434a6ede4e006ef0b001108c354f4fa6d91e
+ branch=ovmf
+ revision=3ab1434a6ede4e006ef0b001108c354f4fa6d91e
+ . ./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
+ '[' x3ab1434a6ede4e006ef0b001108c354f4fa6d91e = 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 v2 1/2] xen: move wallclock functions from x86 to common

[Jan Beulich]

>>> On 09.11.15 at 18:32,  wrote:
> From: Stefano Stabellini 
> 
> Remove dummy arm implementation of wallclock_time.
> Use shared_info() in common code rather than x86-ism to access it, when
> possible.
> 
> Define the static variable wc_sec, and the local variale sec in
> update_domain_wallclock_time, as uint64_t instead of unsigned long, to
> avoid size issue on arm.
> Take a uint64_t sec paramter in do_settime for the same reason.
> 
> Signed-off-by: Stefano Stabellini 
> CC: jbeul...@suse.com 
> CC: andrew.coop...@citrix.com 
> 
> ---
> Changes in v2:
> - remove stray blank lines

There's still one left at the end of xen/common/time.c, but anyway
Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v9 00/17] Add VT-d Posted-Interrupts support

[Jan Beulich]

>>> On 10.11.15 at 08:33,  wrote:
> Thanks for your effort on this series and kindly ping..

Don't worry, it hasn't been forgotten. But getting to it will take time.

Jan


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

Re: [Xen-devel] [PATCH] efi: Fix booting failure with UEFI on ARM

[Jan Beulich]

>>> On 10.11.15 at 08:55,  wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -636,8 +636,8 @@ static void __init efi_console_set_mode(void)
>  static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
>  {
>  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
> -EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
> -EFI_HANDLE *handles;
> +EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
> +EFI_HANDLE *handles = NULL;

I can see the issue with handles being left uninitialized, but if you
think gop also needs initializing, then I would have expected an
explanation. The change is simple enough to take as is, but in the
future please explain changes that aren't obviously needed.

Also please Cc maintainers for the touched code on your patches.

Jan


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

[Xen-devel] [PATCH v2] tools/ocaml/xb: Correct calculations of data/space the ring

[Andrew Cooper]

ml_interface_{read,write}() would miscalculate the quantity of
data/space in the ring if it crossed the ring boundary, and incorrectly
return a short read/write.

This causes a protocol stall, as either side of the ring ends up waiting
for what they believe to be the other side needing to take the next
action.

Correct the calculations to cope with crossing the ring boundary.

In addition, correct the error detection.  It is a hard error if the
producer index gets more than a ring size ahead of the consumer, or if
the consumer ever overtakes the producer.

Signed-off-by: Andrew Cooper 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: David Scott 
CC: Samuel Thibault 

v2:
 * Correct error handling adjustments
 * More fixes to space calculations
 * Fix whitespace errors
 * No longer RFC - passed XenServer sanity testing
---
 tools/ocaml/libs/xb/xs_ring_stubs.c | 64 +
 1 file changed, 44 insertions(+), 20 deletions(-)

diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c 
b/tools/ocaml/libs/xb/xs_ring_stubs.c
index fd561a2..4737870 100644
--- a/tools/ocaml/libs/xb/xs_ring_stubs.c
+++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
@@ -50,7 +50,7 @@ CAMLprim value ml_interface_read(value ml_interface,
 
struct xenstore_domain_interface *intf = interface->addr;
XENSTORE_RING_IDX cons, prod; /* offsets only */
-   int to_read;
+   int total_data, data;
uint32_t connection;
 
cons = *(volatile uint32_t*)&intf->req_cons;
@@ -65,19 +65,28 @@ CAMLprim value ml_interface_read(value ml_interface,
if ((prod - cons) > XENSTORE_RING_SIZE)
caml_failwith("bad connection");
 
-   if (prod == cons) {
+   /* Check for any pending data at all. */
+   total_data = prod - cons;
+   if (total_data == 0) {
+   /* No pending data at all. */
result = 0;
goto exit;
}
-   cons = MASK_XENSTORE_IDX(cons);
-   prod = MASK_XENSTORE_IDX(prod);
-   if (prod > cons)
-   to_read = prod - cons;
-   else
-   to_read = XENSTORE_RING_SIZE - cons;
-   if (to_read < len)
-   len = to_read;
-   memcpy(buffer, intf->req + cons, len);
+   else if (total_data < len)
+   /* Some data - make a partial read. */
+   len = total_data;
+
+   /* Check whether data crosses the end of the ring. */
+   data = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
+   if (len < data)
+   /* Data within the remaining part of the ring. */
+   memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), len);
+   else {
+   /* Data crosses the ring boundary. Read both halves. */
+   memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), data);
+   memcpy(buffer + data, intf->req, len - data);
+   }
+
xen_mb();
intf->req_cons += len;
result = len;
@@ -100,7 +109,7 @@ CAMLprim value ml_interface_write(value ml_interface,
 
struct xenstore_domain_interface *intf = interface->addr;
XENSTORE_RING_IDX cons, prod;
-   int can_write;
+   int total_space, space;
uint32_t connection;
 
cons = *(volatile uint32_t*)&intf->rsp_cons;
@@ -111,17 +120,32 @@ CAMLprim value ml_interface_write(value ml_interface,
caml_raise_constant(*caml_named_value("Xb.Reconnect"));
 
xen_mb();
-   if ( (prod - cons) >= XENSTORE_RING_SIZE ) {
+
+   if ((prod - cons) > XENSTORE_RING_SIZE)
+   caml_failwith("bad connection");
+
+   /* Check for space to write the full message. */
+   total_space = XENSTORE_RING_SIZE - (prod - cons);
+   if (total_space == 0) {
+   /* No space at all - exit having done nothing. */
result = 0;
goto exit;
}
-   if (MASK_XENSTORE_IDX(prod) >= MASK_XENSTORE_IDX(cons))
-   can_write = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
-   else 
-   can_write = MASK_XENSTORE_IDX(cons) - MASK_XENSTORE_IDX(prod);
-   if (can_write < len)
-   len = can_write;
-   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
+   else if (total_space < len)
+   /* Some space - make a partial write. */
+   len = total_space;
+
+   /* Check for space until the ring wraps. */
+   space = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
+   if (len < space)
+   /* Message fits inside the remaining part of the ring. */
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
+   else {
+   /* Message wraps around the end of the ring. Write both halves. 
*/
+   memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, space);
+   memcpy(intf->rsp, buffer + space, len - space);
+   }
+
xen_mb();
intf->rsp_prod += len;
result = len;
-- 
2.1.4


___

[Xen-devel] Using IRQ_GUEST|IRQ_PER_CPU to signal "delivery to current vcpu"?

[Ian Campbell]

Hi arch maintainers,

The ARM hardware has a concept called a "Peripheral Private Interrupt"
(PPI), an IRQ which is per-core as opposed to a "Shared Peripheral
Interrupt" (SPI) which is per-SOC (routable to all cores).

(For completeness the other classes of IRQ are "Software Generated
Interrupt" (SGI) AKA "IPI" and "Locality-specific Peripheral Interrupt"
(LPI) which is, approximately, an MSI).

PPIs are typically generated by per-core resources, such as the timer
block, or PMU blocks etc.

I would like to arrange for a new (I think) class of interrupt within Xen,
which is an interrupt (necessarily a PPI) which is always delivered to
whichever VCPU is currently resident on a given PCPU and use this to
arrange to deliver vtimer interrupts direct to the current VCPU, taking
care of context switching the status (is it pending? active? etc) of the
PPI while context switching the vtimer (something which the h/w supports
quite easily and which then avoids races wrt guests unmasking the timer
while it is still active in the interrupt virtual controller but not the
real one).

My first cut ([0], from January this year) keyed this behaviour on an ARM
specific struct irq_guest field ->d (domain) being NULL, which I wasn't
terribly comfortable with. In my WIP v2 I have current added a new boolean
field to struct irq_guest, which seems rather wasteful due to rounding up
of the size etc and so I'm not really happy with that either (I also
considered and rejected other tricks like stealing a bit from an existing
field, e.g. the unsigned virq).

So, I was considering using a new bit in the common desc->status bit. Upon
checking xen/irq.h I found there was already IRQ_PER_CPU which appears to
be completely unused in the current code base (it looks to have been used
by IA64 and PPC, but never by x86 and not currently used AFAICT by ARM, x86
or common code.)

It seems like IRQ_GUEST|IRQ_PER_CPU is a pretty good fit for the semantics
I want, but I think it would be confusing to define it as meaning such only
on ARM and having either common code or other architectures ascribe a
different meaning (other than "meaningless on this arch") to it.

I think the other possible use case of this scenario (routing a PPI to a
specific guest) seems rather unlikely (since it would imply pinning in
various odd ways). I think that use case can also be dealt with by the
context switching code which can reroute the interrupt as needed (i.e.
unmask only when the relevant vcpu is running).

Any thoughts?

Arguably all PPIs on ARM (even "normal" ones) ought to have IRQ_PER_CPU set
too but that is something of an aside.

Cheers,
Ian.

[0] http://lists.xen.org/archives/html/xen-devel/2015-01/msg03161.html

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

Re: [Xen-devel] [PATCH v2] tools/ocaml/xb: Correct calculations of data/space the ring

[Wei Liu]

On Tue, Nov 10, 2015 at 10:46:44AM +, Andrew Cooper wrote:
> ml_interface_{read,write}() would miscalculate the quantity of
> data/space in the ring if it crossed the ring boundary, and incorrectly
> return a short read/write.
> 
> This causes a protocol stall, as either side of the ring ends up waiting
> for what they believe to be the other side needing to take the next
> action.
> 
> Correct the calculations to cope with crossing the ring boundary.
> 
> In addition, correct the error detection.  It is a hard error if the
> producer index gets more than a ring size ahead of the consumer, or if
> the consumer ever overtakes the producer.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] efi: Fix booting failure with UEFI on ARM

[Daniel Kiper]

On Tue, Nov 10, 2015 at 03:55:50PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
>
> Commit 9fd08b4 (efi: split out efi_get_gop()) splits out the
> codes getting the pointer to GOP as efi_get_gop(), but it doesn't
> initialize the variable handles and gop to NULL like what the original

As I can see original code did not initialized gop to NULL but it does
not hurt. So, ...

> codes do. This will cause booting failure on ARM while printing below
> logs:
>   Xen 4.7-unstable (c/s Tue Oct 13 14:40:28 2015 +0100 git:7a92036) EFI 
> loader
>   Synchronous Exception at 0xFECB021C
>
> Signed-off-by: Shannon Zhao 

Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

[Lars Kurth]

Hi everyone, 

firstly I wanted to thank everyone for raising this issue. I wanted to point 
out that we are not talking about a security process here, but the development 
process. Or more accurately the cost of writing more secure code and the 
relative importance of security compared to features. And of course the recent 
increase of relative importance of "built-in security as a feature" since 
Snowden. 

> On 9 Nov 2015, at 16:31, Franz <169...@gmail.com> wrote:
> 
> (Please note that all of the above are my personal views, i.e. I'm
> explicitly not speaking on behalf of the project.)
> 
> 
> It seems positions are antithetic with no possible compromise in view. Sadly 
> this is a general problem of FOSS software: developers  tend to do what they 
> like and not what users request. And who can blame developers for that? After 
> all they are working as volunteers so they deserve to do what they like. No 
> possible compromise.

I don't think this is a fair statement: more than 95% of developers working on 
Xen are employees of large organisations. And they follow the priorities that 
their employers set. The same is true in Linux and for comparable projects and 
of course for proprietary software developers. Blaming open source developers, 
is simply wrong and not constructive. 

In fact, throughout 2014 and 2015, the project has received complaints from 
several large vendors that the Xen Project today is too rigorous with code 
reviews compared to Linux, KVM and QEMU and that it is now harder to get code 
into Xen compared to similar projects. To understand the root causes, the Xen 
Project Advisory Board has commissioned a study to look at the root causes  
(see http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01635.html 
). 
The result of the first phase of the study showed, that a primary factor for 
longer review times are significantly higher quality expectations on new code 
compared to the past. Of course this does not help with code that has been 
added in the past.

In many ways, the problem which was stated comes down to different 
expectations, by different classes of contributors. And a solution, will 
necessarily have to involve compromise. 

> Perhaps a way out of this impasse is to put bounties on Xen security tasks 
> identified by Joanna and properly advertise these bounties to Xen users. I 
> would give particular attention to the companies that use Xen.

I can certainly raise this suggestion with the Advisory Board and see whether 
we can make some funds available. However, the board has already invested 
nearly 50% of its entire budget in Test Infrastructure and is planning to 
continue to spend in this area at roughly this proportion of the projects 
budget. However, we do not have huge amounts of funds: thus, what we could do 
with bounties would necessarily be limited. 

I personally also looked at other ways to change the cost-benefit equation. One 
example is the Feature Maturity Lifecycle (see 
http://lists.xen.org/archives/html/xen-devel/2015-11/msg00609.html 
 & 
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html 
) 
which aims to use better classification to change behaviour of contributors. 

I do hope, that this discussion can remain constructive. De-motivating the good 
work many of our developers (and in particular code reviewers) are doing, is 
really not helpful in this context. 

Best Regards
Lars


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

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

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-weekly-netinst-pygrub 3 host-install(3) broken REGR. 
vs. 38244
 test-amd64-amd64-amd64-daily-netboot-pvgrub  6 xen-boot   fail REGR. vs. 38244
 test-amd64-i386-i386-current-netinst-pygrub 9 debian-di-install fail REGR. vs. 
38244
 test-amd64-amd64-amd64-current-netinst-pygrub 9 debian-di-install fail REGR. 
vs. 38244

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-weekly-netinst-pygrub 13 guest-saverestore fail blocked 
in 38244
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 38244
 test-amd64-i386-amd64-daily-netboot-pygrub 13 guest-saverestore fail like 38244

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-daily-netboot-pygrub 11 migrate-support-check fail 
never pass
 test-armhf-armhf-armhf-daily-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   38244

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubpass
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  pass
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub broken  
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  pass
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] efi: Fix booting failure with UEFI on ARM

[Shannon Zhao]

On 2015/11/10 18:45, Jan Beulich wrote:
 On 10.11.15 at 08:55,  wrote:
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -636,8 +636,8 @@ static void __init efi_console_set_mode(void)
>>  static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
>>  {
>>  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
>> -EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
>> -EFI_HANDLE *handles;
>> +EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
>> +EFI_HANDLE *handles = NULL;
> 
> I can see the issue with handles being left uninitialized, but if you
> think gop also needs initializing, then I would have expected an
> explanation. The change is simple enough to take as is, but in the
> future please explain changes that aren't obviously needed.
> 
Yes, the root cause is the uninitialized handles not the uninitialized
gop. It just does what the original codes do before applying commit
9fd08b4.

@@ -738,14 +773,12 @@ void EFIAPI __init noreturn
 efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
 {
 static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL;
-static EFI_GUID __initdata gop_guid =
EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
 static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
 EFI_LOADED_IMAGE *loaded_image;
 EFI_STATUS status;
 unsigned int i, argc;
 CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
 UINTN map_key, info_size, gop_mode = ~0;
-EFI_HANDLE *handles = NULL;
 EFI_SHIM_LOCK_PROTOCOL *shim_lock;
 EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;

If you think it's not proper, I'll fix this.

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH v2 1/2] xen: move wallclock functions from x86 to common

[Stefano Stabellini]

On Tue, 10 Nov 2015, Jan Beulich wrote:
> >>> On 09.11.15 at 18:32,  wrote:
> > From: Stefano Stabellini 
> > 
> > Remove dummy arm implementation of wallclock_time.
> > Use shared_info() in common code rather than x86-ism to access it, when
> > possible.
> > 
> > Define the static variable wc_sec, and the local variale sec in
> > update_domain_wallclock_time, as uint64_t instead of unsigned long, to
> > avoid size issue on arm.
> > Take a uint64_t sec paramter in do_settime for the same reason.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: jbeul...@suse.com 
> > CC: andrew.coop...@citrix.com 
> > 
> > ---
> > Changes in v2:
> > - remove stray blank lines
> 
> There's still one left at the end of xen/common/time.c, but anyway
> Acked-by: Jan Beulich 

Thanks!

I'll remove the line at the end of xen/common/time.c if I have to
resend, otherwise feel free to remove it yourself when committing.

Thanks again,

Stefano

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

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

[Stefano Stabellini]

On Tue, 10 Nov 2015, Shannon Zhao wrote:
> Hi Stefano,
> 
> When I apply this patch, there are some warnings too.
> 
> Applying: arm: export platform_op XENPF_settime64
> /home/open-source/xen/.git/rebase-apply/patch:67: trailing whitespace.
>  *
> /home/open-source/xen/.git/rebase-apply/patch:69: trailing whitespace.
>  *
> /home/open-source/xen/.git/rebase-apply/patch:172: trailing whitespace.
> 
> warning: 3 lines add whitespace errors.

Thanks, I'll fix.


> On 2015/11/10 1:32, sstabell...@kernel.org wrote:
> > From: Stefano Stabellini 
> > 
> > Call update_domain_wallclock_time at domain initialization, specifically
> > in arch_set_info_guest for vcpu0, like we do on x86.
> > Set time_offset_seconds to the number of seconds between phisical boot
> > and domain initialization: it is going to be used to get/set the
> > wallclock time.
> > Add time_offset_seconds to system_time when before calling do_settime,
> > so that system_time actually accounts for all the time in nsec between
> > machine boot and when the wallclock was set.
> > 
> > 
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: dgde...@tycho.nsa.gov
> > 
> > ---
> > 
> > Changes in v2:
> > - drop XENPF_settime32
> > - set time_offset_seconds
> > - modify xen/xsm/flask/hooks.c
> > ---
> >  xen/arch/arm/Makefile |1 +
> >  xen/arch/arm/domain.c |9 ++
> >  xen/arch/arm/platform_hypercall.c |   62 
> > +
> >  xen/arch/arm/traps.c  |1 +
> >  xen/arch/arm/vtimer.c |1 -
> >  xen/include/asm-arm/time.h|2 ++
> >  xen/include/xsm/dummy.h   |   12 +++
> >  xen/include/xsm/xsm.h |   13 
> >  xen/xsm/flask/hooks.c |2 +-
> >  9 files changed, 89 insertions(+), 14 deletions(-)
> >  create mode 100644 xen/arch/arm/platform_hypercall.c
> > 
> > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> > index 1ef39f7..240aa29 100644
> > --- a/xen/arch/arm/Makefile
> > +++ b/xen/arch/arm/Makefile
> > @@ -23,6 +23,7 @@ obj-y += percpu.o
> >  obj-y += guestcopy.o
> >  obj-y += physdev.o
> >  obj-y += platform.o
> > +obj-y += platform_hypercall.o
> >  obj-y += setup.o
> >  obj-y += bootfdt.o
> >  obj-y += time.o
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index b2bfc7d..1f07a41 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -742,6 +743,14 @@ int arch_set_info_guest(
> >  v->arch.ttbr1 = ctxt->ttbr1;
> >  v->arch.ttbcr = ctxt->ttbcr;
> >  
> > +if ( v->vcpu_id == 0 )
> > +{
> > +struct domain *d = v->domain;
> > +d->time_offset_seconds = 
> > ticks_to_ns(d->arch.virt_timer_base.offset - boot_count);
> > +do_div(d->time_offset_seconds, 10);
> > +update_domain_wallclock_time(d);
> > +}
> > +
> >  v->is_initialised = 1;
> >  
> >  if ( ctxt->flags & VGCF_online )
> > diff --git a/xen/arch/arm/platform_hypercall.c 
> > b/xen/arch/arm/platform_hypercall.c
> > new file mode 100644
> > index 000..cb8e575
> > --- /dev/null
> > +++ b/xen/arch/arm/platform_hypercall.c
> > @@ -0,0 +1,62 @@
> > +/**
> > + * platform_hypercall.c
> > + * 
> > + * Hardware platform operations. Intended for use by domain-0 kernel.
> > + * 
> > + * Copyright (c) 2015, Citrix
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DEFINE_SPINLOCK(xenpf_lock);
> > +
> > +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
> > +{
> > +long ret;
> > +struct xen_platform_op curop, *op = &curop;
> > +struct domain *d;
> > +
> > +if ( copy_from_guest(op, u_xenpf_op, 1) )
> > +return -EFAULT;
> > +
> > +if ( op->interface_version != XENPF_INTERFACE_VERSION )
> > +return -EACCES;
> > +
> > +d = rcu_lock_current_domain();
> > +if ( d == NULL )
> > +return -ESRCH;
> > +
> > +ret = xsm_platform_op(XSM_PRIV, op->cmd);
> > +if ( ret )
> > +return ret;
> > +
> > +spin_lock(&xenpf_lock);
> > +
> > +switch ( op->cmd )
> > +{
> > +case XENPF_settime64:
> > +if ( likely(!op->u.settime64.mbz) )
> > +do_settime(op->u.settime64.secs,
> > +   op->u.settime64.nsecs,
> > +   op->u.settime64.system_time + 
> > SECONDS(d->time_offset_seconds));
> > +else
> > +ret = -EINVAL;
> > +break;
> > +
> > +default:
> > +ret = -ENOSYS;
> > +break;
> > +}
> > +
> > +spin_unlock(&xenpf_lock);
> > +rcu_unlock_domain(d);
> > +return ret;
> > +}
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 9d2bd6a..c49bd3f 

Re: [Xen-devel] [PATCH v11 2/5] missing include asm/paravirt.h in cputime.c

[Stefano Stabellini]

On Mon, 9 Nov 2015, Peter Zijlstra wrote:
> On Thu, Nov 05, 2015 at 05:30:01PM +, Stefano Stabellini wrote:
> > On Thu, 5 Nov 2015, Peter Zijlstra wrote:
> > > How can this be missing? Things compile fine now, right?
> >
> > Fair enough.
> >
> >
> > > So please better explain why we do this change.
> >
> > asm/paravirt.h is included by one of the other headers included in
> > kernel/sched/cputime.c on x86, but not on other architecures. On arm and
> > arm64, where I am about to introduce asm/paravirt.h and stolen time
> > support, without #include  in cputime.c I would get:
> >
> > kernel/sched/cputime.c: In function ‘steal_account_process_tick’:
> > kernel/sched/cputime.c:260:24: error: ‘paravirt_steal_enabled’ undeclared 
> > (first use in this function)
> >   if (static_key_false(¶virt_steal_enabled)) {
> >
> > A bit of digging on x86 (using gcc -E on cputime.c) tells me that
> > asm/paravirt.h is coming from the following include chain:
> >
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
>
>
> Fair enough; a slightly shorter version of that for a changelog will do
> nicely.

Sure. Can I add your Acked-by to it?___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Using IRQ_GUEST|IRQ_PER_CPU to signal "delivery to current vcpu"?

[Jan Beulich]

>>> On 10.11.15 at 11:48,  wrote:
> So, I was considering using a new bit in the common desc->status bit. Upon
> checking xen/irq.h I found there was already IRQ_PER_CPU which appears to
> be completely unused in the current code base (it looks to have been used
> by IA64 and PPC, but never by x86 and not currently used AFAICT by ARM, x86
> or common code.)
> 
> It seems like IRQ_GUEST|IRQ_PER_CPU is a pretty good fit for the semantics
> I want, but I think it would be confusing to define it as meaning such only
> on ARM and having either common code or other architectures ascribe a
> different meaning (other than "meaningless on this arch") to it.
> 
> I think the other possible use case of this scenario (routing a PPI to a
> specific guest) seems rather unlikely (since it would imply pinning in
> various odd ways). I think that use case can also be dealt with by the
> context switching code which can reroute the interrupt as needed (i.e.
> unmask only when the relevant vcpu is running).
> 
> Any thoughts?

Sounds reasonable.

Jan


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

[Xen-devel] [PATCH v8.1 09/21] xen/x86: set the vPMU interface based on the presence of a lapic

[Roger Pau Monne]

Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or not.

Signed-off-by: Roger Pau Monné 
Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v8:
 - Don't add the xenpmu hypercalls to the HVM hypercall table (yet).
 - Add Jan Beulich Acked-by.

Changes since v7:
 - Merge vpmu work from Boris.

Changes since v6:
 - Major rework of the approach.
 - Drop Andrew Cooper Acked-by.

Changes since v4:
 - Add Andrew Cooper Acked-by.
---
 xen/arch/x86/cpu/vpmu.c   | 11 ++-
 xen/arch/x86/cpu/vpmu_amd.c   |  6 +++---
 xen/arch/x86/cpu/vpmu_intel.c |  6 +++---
 xen/arch/x86/hvm/svm/svm.c|  2 +-
 xen/arch/x86/hvm/vmx/vmx.c|  2 +-
 5 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 2f5156a..4346c66 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -94,7 +94,7 @@ void vpmu_lvtpc_update(uint32_t val)
 vpmu->hw_lapic_lvtpc = PMU_APIC_VECTOR | (val & APIC_LVT_MASKED);
 
 /* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
-if ( is_hvm_vcpu(curr) || !vpmu->xenpmu_data ||
+if ( has_vlapic(curr->domain) || !vpmu->xenpmu_data ||
  !vpmu_is_set(vpmu, VPMU_CACHED) )
 apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
@@ -129,7 +129,7 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
  * and since do_wr/rdmsr may load VPMU context we should save
  * (and unload) it again.
  */
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+if ( !has_vlapic(curr->domain) && vpmu->xenpmu_data &&
 vpmu_is_set(vpmu, VPMU_CACHED) )
 {
 vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
@@ -184,7 +184,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 return;
 
 /* PV(H) guest */
-if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
+if ( !has_vlapic(sampling->domain) || (vpmu_mode & XENPMU_MODE_ALL) )
 {
 const struct cpu_user_regs *cur_regs;
 uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
@@ -411,7 +411,8 @@ int vpmu_load(struct vcpu *v, bool_t from_guest)
 
 /* Only when PMU is counting, we load PMU context immediately. */
 if ( !vpmu_is_set(vpmu, VPMU_RUNNING) ||
- (!is_hvm_vcpu(vpmu_vcpu(vpmu)) && vpmu_is_set(vpmu, VPMU_CACHED)) )
+ (!has_vlapic(vpmu_vcpu(vpmu)->domain) &&
+ vpmu_is_set(vpmu, VPMU_CACHED)) )
 return 0;
 
 if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
@@ -635,7 +636,7 @@ long do_xenpmu_op(unsigned int op, 
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 struct xen_pmu_data *xenpmu_data;
 struct vpmu_struct *vpmu;
 
-if ( !opt_vpmu_enabled )
+if ( !opt_vpmu_enabled || has_vlapic(current->domain) )
 return -EOPNOTSUPP;
 
 ret = xsm_pmu_op(XSM_OTHER, current->domain, op);
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 04da81a..990e6f3 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -238,7 +238,7 @@ static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
 bool_t is_running = 0;
 struct xen_pmu_amd_ctxt *guest_ctxt = &vpmu->xenpmu_data->pmu.c.amd;
 
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
 
 ctxt = vpmu->context;
 ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
@@ -314,7 +314,7 @@ static int amd_vpmu_save(struct vcpu *v,  bool_t to_guest)
 {
 struct xen_pmu_amd_ctxt *guest_ctxt, *ctxt;
 
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
 ctxt = vpmu->context;
 guest_ctxt = &vpmu->xenpmu_data->pmu.c.amd;
 memcpy(&guest_ctxt->regs[0], &ctxt->regs[0], regs_sz);
@@ -525,7 +525,7 @@ int svm_vpmu_initialise(struct vcpu *v)
 vpmu->context = ctxt;
 vpmu->priv_context = NULL;
 
-if ( !is_hvm_vcpu(v) )
+if ( !has_vlapic(v->domain) )
 {
 /* Copy register offsets to shared area */
 ASSERT(vpmu->xenpmu_data);
diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 12f80ae..a9e0e68 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -337,7 +337,7 @@ static int core2_vpmu_save(struct vcpu *v, bool_t to_guest)
 
 if ( to_guest )
 {
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
 memcpy((void *)(&vpmu->xenpmu_data->pmu.c.intel) + regs_off,
vpmu->context + regs_off, regs_sz);
 }
@@ -442,7 +442,7 @@ static int core2_vpmu_load(struct vcpu *v, bool_t 
from_guest)
 {
 int ret;
 
-ASSERT(!is_hvm_vcpu(v));
+ASSERT(!has_vlapic(v->domain));
 
 memcpy(vpmu->context + regs_off,
(void *)&v->arch.vpmu.xenpmu_data->pmu.c.intel + regs_off,
@@ -502,7 +502,7 @@ static int core2_vpmu_alloc_resource

Re: [Xen-devel] [PATCH v2] tools/ocaml/xb: Correct calculations of data/space the ring

[Samuel Thibault]

Andrew Cooper, on Tue 10 Nov 2015 10:46:44 +, wrote:
> ml_interface_{read,write}() would miscalculate the quantity of
> data/space in the ring if it crossed the ring boundary, and incorrectly
> return a short read/write.
> 
> This causes a protocol stall, as either side of the ring ends up waiting
> for what they believe to be the other side needing to take the next
> action.
> 
> Correct the calculations to cope with crossing the ring boundary.
> 
> In addition, correct the error detection.  It is a hard error if the
> producer index gets more than a ring size ahead of the consumer, or if
> the consumer ever overtakes the producer.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Samuel Thibault 

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: David Scott 
> CC: Samuel Thibault 
> 
> v2:
>  * Correct error handling adjustments
>  * More fixes to space calculations
>  * Fix whitespace errors
>  * No longer RFC - passed XenServer sanity testing
> ---
>  tools/ocaml/libs/xb/xs_ring_stubs.c | 64 
> +
>  1 file changed, 44 insertions(+), 20 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c 
> b/tools/ocaml/libs/xb/xs_ring_stubs.c
> index fd561a2..4737870 100644
> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
> @@ -50,7 +50,7 @@ CAMLprim value ml_interface_read(value ml_interface,
>  
>   struct xenstore_domain_interface *intf = interface->addr;
>   XENSTORE_RING_IDX cons, prod; /* offsets only */
> - int to_read;
> + int total_data, data;
>   uint32_t connection;
>  
>   cons = *(volatile uint32_t*)&intf->req_cons;
> @@ -65,19 +65,28 @@ CAMLprim value ml_interface_read(value ml_interface,
>   if ((prod - cons) > XENSTORE_RING_SIZE)
>   caml_failwith("bad connection");
>  
> - if (prod == cons) {
> + /* Check for any pending data at all. */
> + total_data = prod - cons;
> + if (total_data == 0) {
> + /* No pending data at all. */
>   result = 0;
>   goto exit;
>   }
> - cons = MASK_XENSTORE_IDX(cons);
> - prod = MASK_XENSTORE_IDX(prod);
> - if (prod > cons)
> - to_read = prod - cons;
> - else
> - to_read = XENSTORE_RING_SIZE - cons;
> - if (to_read < len)
> - len = to_read;
> - memcpy(buffer, intf->req + cons, len);
> + else if (total_data < len)
> + /* Some data - make a partial read. */
> + len = total_data;
> +
> + /* Check whether data crosses the end of the ring. */
> + data = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
> + if (len < data)
> + /* Data within the remaining part of the ring. */
> + memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), len);
> + else {
> + /* Data crosses the ring boundary. Read both halves. */
> + memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), data);
> + memcpy(buffer + data, intf->req, len - data);
> + }
> +
>   xen_mb();
>   intf->req_cons += len;
>   result = len;
> @@ -100,7 +109,7 @@ CAMLprim value ml_interface_write(value ml_interface,
>  
>   struct xenstore_domain_interface *intf = interface->addr;
>   XENSTORE_RING_IDX cons, prod;
> - int can_write;
> + int total_space, space;
>   uint32_t connection;
>  
>   cons = *(volatile uint32_t*)&intf->rsp_cons;
> @@ -111,17 +120,32 @@ CAMLprim value ml_interface_write(value ml_interface,
>   caml_raise_constant(*caml_named_value("Xb.Reconnect"));
>  
>   xen_mb();
> - if ( (prod - cons) >= XENSTORE_RING_SIZE ) {
> +
> + if ((prod - cons) > XENSTORE_RING_SIZE)
> + caml_failwith("bad connection");
> +
> + /* Check for space to write the full message. */
> + total_space = XENSTORE_RING_SIZE - (prod - cons);
> + if (total_space == 0) {
> + /* No space at all - exit having done nothing. */
>   result = 0;
>   goto exit;
>   }
> - if (MASK_XENSTORE_IDX(prod) >= MASK_XENSTORE_IDX(cons))
> - can_write = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
> - else 
> - can_write = MASK_XENSTORE_IDX(cons) - MASK_XENSTORE_IDX(prod);
> - if (can_write < len)
> - len = can_write;
> - memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
> + else if (total_space < len)
> + /* Some space - make a partial write. */
> + len = total_space;
> +
> + /* Check for space until the ring wraps. */
> + space = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
> + if (len < space)
> + /* Message fits inside the remaining part of the ring. */
> + memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
> + else {
> + /* Message wraps around the end of the ring. Write both halves. 
> */
> + memcpy(intf->rsp + MASK_XE

Re: [Xen-devel] [PATCH v2] tools/ocaml/xb: Correct calculations of data/space the ring

[David Scott]

> On 10 Nov 2015, at 11:41, Samuel Thibault  
> wrote:
> 
> Andrew Cooper, on Tue 10 Nov 2015 10:46:44 +, wrote:
>> ml_interface_{read,write}() would miscalculate the quantity of
>> data/space in the ring if it crossed the ring boundary, and incorrectly
>> return a short read/write.
>> 
>> This causes a protocol stall, as either side of the ring ends up waiting
>> for what they believe to be the other side needing to take the next
>> action.
>> 
>> Correct the calculations to cope with crossing the ring boundary.
>> 
>> In addition, correct the error detection.  It is a hard error if the
>> producer index gets more than a ring size ahead of the consumer, or if
>> the consumer ever overtakes the producer.
>> 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Samuel Thibault 

Looks good to me too

Reviewed-by: David Scott 

> 
>> ---
>> CC: Ian Campbell 
>> CC: Ian Jackson 
>> CC: Wei Liu 
>> CC: David Scott 
>> CC: Samuel Thibault 
>> 
>> v2:
>> * Correct error handling adjustments
>> * More fixes to space calculations
>> * Fix whitespace errors
>> * No longer RFC - passed XenServer sanity testing
>> ---
>> tools/ocaml/libs/xb/xs_ring_stubs.c | 64 
>> +
>> 1 file changed, 44 insertions(+), 20 deletions(-)
>> 
>> diff --git a/tools/ocaml/libs/xb/xs_ring_stubs.c 
>> b/tools/ocaml/libs/xb/xs_ring_stubs.c
>> index fd561a2..4737870 100644
>> --- a/tools/ocaml/libs/xb/xs_ring_stubs.c
>> +++ b/tools/ocaml/libs/xb/xs_ring_stubs.c
>> @@ -50,7 +50,7 @@ CAMLprim value ml_interface_read(value ml_interface,
>> 
>>  struct xenstore_domain_interface *intf = interface->addr;
>>  XENSTORE_RING_IDX cons, prod; /* offsets only */
>> -int to_read;
>> +int total_data, data;
>>  uint32_t connection;
>> 
>>  cons = *(volatile uint32_t*)&intf->req_cons;
>> @@ -65,19 +65,28 @@ CAMLprim value ml_interface_read(value ml_interface,
>>  if ((prod - cons) > XENSTORE_RING_SIZE)
>>  caml_failwith("bad connection");
>> 
>> -if (prod == cons) {
>> +/* Check for any pending data at all. */
>> +total_data = prod - cons;
>> +if (total_data == 0) {
>> +/* No pending data at all. */
>>  result = 0;
>>  goto exit;
>>  }
>> -cons = MASK_XENSTORE_IDX(cons);
>> -prod = MASK_XENSTORE_IDX(prod);
>> -if (prod > cons)
>> -to_read = prod - cons;
>> -else
>> -to_read = XENSTORE_RING_SIZE - cons;
>> -if (to_read < len)
>> -len = to_read;
>> -memcpy(buffer, intf->req + cons, len);
>> +else if (total_data < len)
>> +/* Some data - make a partial read. */
>> +len = total_data;
>> +
>> +/* Check whether data crosses the end of the ring. */
>> +data = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(cons);
>> +if (len < data)
>> +/* Data within the remaining part of the ring. */
>> +memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), len);
>> +else {
>> +/* Data crosses the ring boundary. Read both halves. */
>> +memcpy(buffer, intf->req + MASK_XENSTORE_IDX(cons), data);
>> +memcpy(buffer + data, intf->req, len - data);
>> +}
>> +
>>  xen_mb();
>>  intf->req_cons += len;
>>  result = len;
>> @@ -100,7 +109,7 @@ CAMLprim value ml_interface_write(value ml_interface,
>> 
>>  struct xenstore_domain_interface *intf = interface->addr;
>>  XENSTORE_RING_IDX cons, prod;
>> -int can_write;
>> +int total_space, space;
>>  uint32_t connection;
>> 
>>  cons = *(volatile uint32_t*)&intf->rsp_cons;
>> @@ -111,17 +120,32 @@ CAMLprim value ml_interface_write(value ml_interface,
>>  caml_raise_constant(*caml_named_value("Xb.Reconnect"));
>> 
>>  xen_mb();
>> -if ( (prod - cons) >= XENSTORE_RING_SIZE ) {
>> +
>> +if ((prod - cons) > XENSTORE_RING_SIZE)
>> +caml_failwith("bad connection");
>> +
>> +/* Check for space to write the full message. */
>> +total_space = XENSTORE_RING_SIZE - (prod - cons);
>> +if (total_space == 0) {
>> +/* No space at all - exit having done nothing. */
>>  result = 0;
>>  goto exit;
>>  }
>> -if (MASK_XENSTORE_IDX(prod) >= MASK_XENSTORE_IDX(cons))
>> -can_write = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
>> -else 
>> -can_write = MASK_XENSTORE_IDX(cons) - MASK_XENSTORE_IDX(prod);
>> -if (can_write < len)
>> -len = can_write;
>> -memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), buffer, len);
>> +else if (total_space < len)
>> +/* Some space - make a partial write. */
>> +len = total_space;
>> +
>> +/* Check for space until the ring wraps. */
>> +space = XENSTORE_RING_SIZE - MASK_XENSTORE_IDX(prod);
>> +if (len < space)
>> +/* Message fits inside the remaining part of the ring. */
>> +memcpy(intf->rsp + MASK_XENSTORE_IDX(prod), 

[Xen-devel] [PATCH v2 0/7] Xen wallclock on arm and arm64

[Stefano Stabellini]

Hi all,

this series introduces PV wallclock time support on arm and arm64.


Changes in v2:
- introduce __current_kernel_time64
- rename dom0_op to platform_op
- introduce XENPF_settime64
- extend pvclock_wall_clock with sec_hi
- properly convert arch_timer ticker to nsec
- use timespec64 interfaces
- use sec_hi to get a 64-bit seconds value
- use XENPF_settime64
- rename dom0_op to platform_op


Stefano Stabellini (7):
  timekeeping: introduce __current_kernel_time64
  xen: rename dom0_op to platform_op
  xen/arm: introduce HYPERVISOR_platform_op on arm and arm64
  xen: introduce XENPF_settime64
  arm: extend pvclock_wall_clock with sec_hi
  xen/arm: introduce xen_read_wallclock
  xen/arm: set the system time in Xen via the XENPF_settime64 hypercall

 arch/arm/Kconfig |1 +
 arch/arm/include/asm/xen/hypercall.h |2 +
 arch/arm/include/asm/xen/interface.h |1 +
 arch/arm/xen/enlighten.c |   86 ++
 arch/arm/xen/hypercall.S |1 +
 arch/arm64/xen/hypercall.S   |1 +
 arch/x86/include/asm/xen/hypercall.h |6 +--
 arch/x86/xen/apic.c  |2 +-
 arch/x86/xen/enlighten.c |8 ++--
 arch/x86/xen/time.c  |   10 ++--
 drivers/xen/acpi.c   |2 +-
 drivers/xen/efi.c|   30 ++--
 drivers/xen/pcpu.c   |8 ++--
 drivers/xen/xen-acpi-cpuhotplug.c|2 +-
 drivers/xen/xen-acpi-pad.c   |4 +-
 drivers/xen/xen-acpi-processor.c |8 ++--
 drivers/xen/xenfs/xensyms.c  |4 +-
 include/linux/timekeeping.h  |3 +-
 include/xen/interface/platform.h |   18 +--
 include/xen/interface/xen.h  |2 +-
 kernel/time/timekeeping.c|7 +++
 21 files changed, 158 insertions(+), 48 deletions(-)

Cheers,

Stefano

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

[Xen-devel] [PATCH v2 3/7] xen/arm: introduce HYPERVISOR_platform_op on arm and arm64

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 

---

Changes in v2:
- rename dom0_op to platform_op
---
 arch/arm/include/asm/xen/hypercall.h |2 ++
 arch/arm/xen/enlighten.c |1 +
 arch/arm/xen/hypercall.S |1 +
 arch/arm64/xen/hypercall.S   |1 +
 4 files changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index 712b50e..c3e00d0 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 
 long privcmd_call(unsigned call, unsigned long a1,
unsigned long a2, unsigned long a3,
@@ -49,6 +50,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_platform_op(void *arg);
 int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
 
 static inline int
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 15621b1..2f57ba3 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -328,5 +328,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
+EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 10fd99c..d4539f4 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -89,6 +89,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(platform_op);
 HYPERCALL2(multicall);
 
 ENTRY(privcmd_call)
diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
index 8bbe940..f7d5724 100644
--- a/arch/arm64/xen/hypercall.S
+++ b/arch/arm64/xen/hypercall.S
@@ -80,6 +80,7 @@ HYPERCALL2(memory_op);
 HYPERCALL2(physdev_op);
 HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
+HYPERCALL1(platform_op);
 HYPERCALL2(multicall);
 
 ENTRY(privcmd_call)
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 5/7] arm: extend pvclock_wall_clock with sec_hi

[Stefano Stabellini]

The hypervisor actually exposes an additional field to struct
pvclock_wall_clock, with the high 32 bit seconds.

Signed-off-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/interface.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 5006600..5b150d7 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -76,6 +76,7 @@ struct pvclock_wall_clock {
u32   version;
u32   sec;
u32   nsec;
+   u32   sec_hi;
 } __attribute__((__packed__));
 #endif
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 7/7] xen/arm: set the system time in Xen via the XENPF_settime64 hypercall

[Stefano Stabellini]

If Linux is running as dom0, call XENPF_settime64 to update the system
time in Xen on pvclock_gtod notifications.

Signed-off-by: Stefano Stabellini 

---

Changes in v2:
- properly convert arch_timer ticker to nsec
- rename dom0_op to platform_op
- use timespec64 interfaces
- use XENPF_settime64
---
 arch/arm/xen/enlighten.c |   54 +-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 32675b5..a991b25 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -125,6 +126,52 @@ static void xen_read_wallclock(struct timespec64 *ts)
 
 }
 
+static int xen_pvclock_gtod_notify(struct notifier_block *nb,
+  unsigned long was_set, void *priv)
+{
+   /* Protected by the calling core code serialization */
+   static struct timespec64 next_sync;
+
+   struct xen_platform_op op;
+   struct timespec64 now;
+
+   now = __current_kernel_time64();
+
+   /*
+* We only take the expensive HV call when the clock was set
+* or when the 11 minutes RTC synchronization time elapsed.
+*/
+   if (!was_set && timespec64_compare(&now, &next_sync) < 0)
+   return NOTIFY_OK;
+
+   op.interface_version = XENPF_INTERFACE_VERSION;
+   op.cmd = XENPF_settime64;
+   op.u.settime64.mbz = 0;
+   op.u.settime64.secs = now.tv_sec;
+   op.u.settime64.nsecs = now.tv_nsec;
+   op.u.settime64.system_time = arch_timer_read_counter() * 
(u64)NSEC_PER_SEC;
+   do_div(op.u.settime64.system_time, arch_timer_get_rate());
+   printk("GTOD: Setting to %llu.%u at %llu\n",
+  op.u.settime64.secs,
+  op.u.settime64.nsecs,
+  op.u.settime64.system_time);
+   (void)HYPERVISOR_platform_op(&op);
+
+   /*
+* Move the next drift compensation time 11 minutes
+* ahead. That's emulating the sync_cmos_clock() update for
+* the hardware RTC.
+*/
+   next_sync = now;
+   next_sync.tv_sec += 11 * 60;
+
+   return NOTIFY_OK;
+}
+
+static struct notifier_block xen_pvclock_gtod_notifier = {
+   .notifier_call = xen_pvclock_gtod_notify,
+};
+
 static void xen_percpu_init(void)
 {
struct vcpu_register_vcpu_info info;
@@ -323,7 +370,12 @@ static int __init xen_guest_init(void)
pv_time_ops.steal_clock = xen_stolen_accounting;
static_key_slow_inc(¶virt_steal_enabled);
xen_read_wallclock(&ts);
-   do_settimeofday64(&ts);
+   if (xen_initial_domain())
+   pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
+   else {
+   xen_read_wallclock(&ts);
+   do_settimeofday64(&ts);
+   }
 
return 0;
 }
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 6/7] xen/arm: introduce xen_read_wallclock

[Stefano Stabellini]

Read the wallclock from the shared info page at boot time.

Signed-off-by: Stefano Stabellini 

---

Changes in v2:
- properly convert arch_timer ticker to nsec
- use timespec64 interfaces
- use sec_hi to get a 64-bit seconds value
---
 arch/arm/Kconfig |1 +
 arch/arm/xen/enlighten.c |   33 +
 2 files changed, 34 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 60be104..a9de420 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1852,6 +1852,7 @@ config XEN
depends on CPU_V7 && !CPU_V6
depends on !GENERIC_ATOMIC64
depends on MMU
+   depends on HAVE_ARM_ARCH_TIMER
select ARCH_DMA_ADDR_T_64BIT
select ARM_PSCI
select SWIOTLB_XEN
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 2f57ba3..32675b5 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -95,6 +97,34 @@ static unsigned long long xen_stolen_accounting(int cpu)
return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
 }
 
+static void xen_read_wallclock(struct timespec64 *ts)
+{
+   u32 version;
+   u64 delta;
+   struct timespec64 now;
+   struct shared_info *s = HYPERVISOR_shared_info;
+   struct pvclock_wall_clock *wall_clock = &(s->wc);
+
+   /* get wallclock at system boot */
+   do {
+   version = wall_clock->version;
+   rmb();  /* fetch version before time */
+   now.tv_sec  = ((uint64_t)wall_clock->sec_hi << 32) | 
wall_clock->sec;
+   now.tv_nsec = wall_clock->nsec;
+   rmb();  /* fetch time before checking version */
+   } while ((wall_clock->version & 1) || (version != wall_clock->version));
+
+   delta = arch_timer_read_counter() * (u64)NSEC_PER_SEC;
+   do_div(delta, arch_timer_get_rate()); /* time since system boot */
+   delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
+
+   now.tv_nsec = do_div(delta, NSEC_PER_SEC);
+   now.tv_sec = delta;
+
+   set_normalized_timespec64(ts, now.tv_sec, now.tv_nsec);
+
+}
+
 static void xen_percpu_init(void)
 {
struct vcpu_register_vcpu_info info;
@@ -218,6 +248,7 @@ static int __init xen_guest_init(void)
struct shared_info *shared_info_page = NULL;
struct resource res;
phys_addr_t grant_frames;
+   struct timespec64 ts;
 
if (!xen_domain())
return 0;
@@ -291,6 +322,8 @@ static int __init xen_guest_init(void)
 
pv_time_ops.steal_clock = xen_stolen_accounting;
static_key_slow_inc(¶virt_steal_enabled);
+   xen_read_wallclock(&ts);
+   do_settimeofday64(&ts);
 
return 0;
 }
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 4/7] xen: introduce XENPF_settime64

[Stefano Stabellini]

Rename the current XENPF_settime hypercall and related struct to
XENPF_settime32.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: david.vra...@citrix.com
CC: boris.ostrov...@oracle.com
---
 arch/x86/xen/time.c  |8 
 include/xen/interface/platform.h |   18 ++
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 663c2ea..3bbd377 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -134,10 +134,10 @@ static int xen_pvclock_gtod_notify(struct notifier_block 
*nb,
if (!was_set && timespec_compare(&now, &next_sync) < 0)
return NOTIFY_OK;
 
-   op.cmd = XENPF_settime;
-   op.u.settime.secs = now.tv_sec;
-   op.u.settime.nsecs = now.tv_nsec;
-   op.u.settime.system_time = xen_clocksource_read();
+   op.cmd = XENPF_settime32;
+   op.u.settime32.secs = now.tv_sec;
+   op.u.settime32.nsecs = now.tv_nsec;
+   op.u.settime32.system_time = xen_clocksource_read();
 
(void)HYPERVISOR_platform_op(&op);
 
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index 8e03587..732efb0 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -35,14 +35,23 @@
  * Set clock such that it would read  after 00:00:00 UTC,
  * 1 January, 1970 if the current system time was .
  */
-#define XENPF_settime 17
-struct xenpf_settime {
+#define XENPF_settime32 17
+struct xenpf_settime32 {
/* IN variables. */
uint32_t secs;
uint32_t nsecs;
uint64_t system_time;
 };
-DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t);
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime32_t);
+#define XENPF_settime64   62
+struct xenpf_settime64 {
+/* IN variables. */
+uint64_t secs;
+uint32_t nsecs;
+uint32_t mbz;
+uint64_t system_time;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime64_t);
 
 /*
  * Request memory range (@mfn, @mfn+@nr_mfns-1) to have type @type.
@@ -495,7 +504,8 @@ struct xen_platform_op {
uint32_t cmd;
uint32_t interface_version; /* XENPF_INTERFACE_VERSION */
union {
-   struct xenpf_settime   settime;
+   struct xenpf_settime32 settime32;
+   struct xenpf_settime64 settime64;
struct xenpf_add_memtype   add_memtype;
struct xenpf_del_memtype   del_memtype;
struct xenpf_read_memtype  read_memtype;
-- 
1.7.10.4


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

[Xen-devel] [PATCH v2 2/7] xen: rename dom0_op to platform_op

[Stefano Stabellini]

The dom0_op hypercall has been renamed to platform_op since Xen 3.2,
which is ancient, and modern upstream Linux kernels cannot run as dom0
and it anymore anyway.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: david.vra...@citrix.com
CC: boris.ostrov...@oracle.com
---
 arch/x86/include/asm/xen/hypercall.h |6 +++---
 arch/x86/xen/apic.c  |2 +-
 arch/x86/xen/enlighten.c |8 
 arch/x86/xen/time.c  |2 +-
 drivers/xen/acpi.c   |2 +-
 drivers/xen/efi.c|   30 +++---
 drivers/xen/pcpu.c   |8 
 drivers/xen/xen-acpi-cpuhotplug.c|2 +-
 drivers/xen/xen-acpi-pad.c   |4 ++--
 drivers/xen/xen-acpi-processor.c |8 
 drivers/xen/xenfs/xensyms.c  |4 ++--
 include/xen/interface/xen.h  |2 +-
 12 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index 4c20dd3..3bcdcc8 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -310,10 +310,10 @@ HYPERVISOR_mca(struct xen_mc *mc_op)
 }
 
 static inline int
-HYPERVISOR_dom0_op(struct xen_platform_op *platform_op)
+HYPERVISOR_platform_op(struct xen_platform_op *op)
 {
-   platform_op->interface_version = XENPF_INTERFACE_VERSION;
-   return _hypercall1(int, dom0_op, platform_op);
+   op->interface_version = XENPF_INTERFACE_VERSION;
+   return _hypercall1(int, platform_op, op);
 }
 
 static inline int
diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index acda713..abf4901 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -64,7 +64,7 @@ static u32 xen_apic_read(u32 reg)
if (reg != APIC_ID)
return 0;
 
-   ret = HYPERVISOR_dom0_op(&op);
+   ret = HYPERVISOR_platform_op(&op);
if (ret)
return 0;
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 5774800..f963c40 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -415,7 +415,7 @@ static bool __init xen_check_mwait(void)
 
set_xen_guest_handle(op.u.set_pminfo.pdc, buf);
 
-   if ((HYPERVISOR_dom0_op(&op) == 0) &&
+   if ((HYPERVISOR_platform_op(&op) == 0) &&
(buf[2] & (ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH))) {
cpuid_leaf5_ecx_val = cx;
cpuid_leaf5_edx_val = dx;
@@ -1374,7 +1374,7 @@ static void __init xen_boot_params_init_edd(void)
info->params.length = sizeof(info->params);
set_xen_guest_handle(op.u.firmware_info.u.disk_info.edd_params,
 &info->params);
-   ret = HYPERVISOR_dom0_op(&op);
+   ret = HYPERVISOR_platform_op(&op);
if (ret)
break;
 
@@ -1392,7 +1392,7 @@ static void __init xen_boot_params_init_edd(void)
op.u.firmware_info.type = XEN_FW_DISK_MBR_SIGNATURE;
for (nr = 0; nr < EDD_MBR_SIG_MAX; nr++) {
op.u.firmware_info.index = nr;
-   ret = HYPERVISOR_dom0_op(&op);
+   ret = HYPERVISOR_platform_op(&op);
if (ret)
break;
mbr_signature[nr] = 
op.u.firmware_info.u.disk_mbr_signature.mbr_signature;
@@ -1698,7 +1698,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
xen_start_info->console.domU.mfn = 0;
xen_start_info->console.domU.evtchn = 0;
 
-   if (HYPERVISOR_dom0_op(&op) == 0)
+   if (HYPERVISOR_platform_op(&op) == 0)
boot_params.kbd_status = 
op.u.firmware_info.u.kbd_shift_flags;
 
/* Make sure ACS will be enabled */
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 041d4cd..663c2ea 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -139,7 +139,7 @@ static int xen_pvclock_gtod_notify(struct notifier_block 
*nb,
op.u.settime.nsecs = now.tv_nsec;
op.u.settime.system_time = xen_clocksource_read();
 
-   (void)HYPERVISOR_dom0_op(&op);
+   (void)HYPERVISOR_platform_op(&op);
 
/*
 * Move the next drift compensation time 11 minutes
diff --git a/drivers/xen/acpi.c b/drivers/xen/acpi.c
index 90307c0..6893c79 100644
--- a/drivers/xen/acpi.c
+++ b/drivers/xen/acpi.c
@@ -58,7 +58,7 @@ static int xen_acpi_notify_hypervisor_state(u8 sleep_state,
 bits, val_a, val_b))
return -1;
 
-   HYPERVISOR_dom0_op(&op);
+   HYPERVISOR_platform_op(&op);
return 1;
 }
 
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index f745db2..be7e56a 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -42,7 +42,7 @@ static efi_status_t xen_efi_get_time(efi_time_t *tm, 
efi_time_cap_t *tc)
 {
struct xen_platform_op op = INIT_EFI_OP(get_time);
 
- 

[Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[Stefano Stabellini]

__current_kernel_time64 returns a struct timespec64, without taking the
xtime lock. Mirrors __current_kernel_time/current_kernel_time.

Signed-off-by: Stefano Stabellini 
CC: a...@arndb.de
CC: john.stu...@linaro.org
CC: t...@linutronix.de
CC: mi...@kernel.org
CC: pet...@infradead.org
---
 include/linux/timekeeping.h |3 ++-
 kernel/time/timekeeping.c   |7 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index ec89d84..b5802bf 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -19,7 +19,8 @@ extern int do_sys_settimeofday(const struct timespec *tv,
  */
 unsigned long get_seconds(void);
 struct timespec64 current_kernel_time64(void);
-/* does not take xtime_lock */
+/* do not take xtime_lock */
+struct timespec64 __current_kernel_time64(void);
 struct timespec __current_kernel_time(void);
 
 static inline struct timespec current_kernel_time(void)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index b1356b7..c1221c2 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1881,6 +1881,13 @@ struct timespec __current_kernel_time(void)
return timespec64_to_timespec(tk_xtime(tk));
 }
 
+struct timespec64 __current_kernel_time64(void)
+{
+   struct timekeeper *tk = &tk_core.timekeeper;
+
+   return tk_xtime(tk);
+}
+
 struct timespec64 current_kernel_time64(void)
 {
struct timekeeper *tk = &tk_core.timekeeper;
-- 
1.7.10.4


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 3ab1434a6ede4e006ef0b001108c354f4fa6d91e
baseline version:
 ovmf 3ec97ca490009ed5604ccd7f2653e5a9ecbf3474

Last test of basis38261  2015-11-09 06:21:06 Z1 days
Testing same since38264  2015-11-10 10:21:29 Z0 days1 attempts


People who touched revisions under test:
  Qiu Shumin 
  Yonghong Zhu 
  Zhang Lubo 

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 3ab1434a6ede4e006ef0b001108c354f4fa6d91e
Author: Yonghong Zhu 
Date:   Mon Nov 9 07:43:07 2015 +

BaseTools: Allow decimal values in the EDK II meta-data file

Because the EDK II meta-data specifications already allow using decimal
values in the EDK II Meta-data file [Defines] section, this patch update
code to allow this usage.

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

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

commit ac4588532d17a2f3cac3e7dde7c85ed59dab319b
Author: Zhang Lubo 
Date:   Mon Nov 9 07:00:20 2015 +

NetworkPkg:Fix the issue that cannot parse ipv6 address correctly.

If there is a ipv6 expressed url, the NetLibAsciiStrToIp6 cannot get the 
Ipv6
address from the host name, because the host name contains left and right
bracket which cannot be used to configure the Tcp6 connection.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Reviewed-by: Ye Ting 
Reviewed-by: Fu Siyuan 
Reviewed-by: Wu Jiaxin 

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

commit e91cc29dd71c9597dbf835b068e4d4d9b1ccb97d
Author: Zhang Lubo 
Date:   Mon Nov 9 03:45:23 2015 +

MdeModulePkg:Fix a bug that HttpLib can not parse Ipv6 address correctly.

When parsing the authority component of the input URL, it can not 
distinguish
the ":" is the flag that indicates the port or the separator between
the ipv6 address.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Reviewed-by: Fu Siyuan 
Reviewed-by: Wu Jiaxin 
Reviewed-by: Gary Ching-Pang Lin 

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

commit b659408b933f40765960e877de3e1f8ceaab52cb
Author: Zhang Lubo 
Date:   Mon Nov 9 03:30:42 2015 +

NetworkPkg:Enable Http Boot over Ipv6 stack

Add new features to support Http boot over ipv6 stack.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Reviewed-by: Fu Siyuan 
Reviewed-by: Ye Ting 
Reviewed-by: Wu Jiaxin 

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

commit d1c275c651099c7f187885412b7751327b86ca38
Author: Qiu Shumin 
Date:   Mon Nov 9 02:29:31 2015 +

ShellPkg: Don't strip positional parameters of quotation marks.

Per Shell SPEC 2.1 'Double-quotation marks that surround arguments are not 
stripped in positional parameters'. This patch makes Shell implementation to 
follow SPEC.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
Reviewed-by: Jaben Carsey 

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

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

Re: [Xen-devel] [PATCH v11 2/5] missing include asm/paravirt.h in cputime.c

[Peter Zijlstra]

On Tue, Nov 10, 2015 at 11:27:33AM +, Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Peter Zijlstra wrote:
> > On Thu, Nov 05, 2015 at 05:30:01PM +, Stefano Stabellini wrote:
> > > On Thu, 5 Nov 2015, Peter Zijlstra wrote:
> > > > How can this be missing? Things compile fine now, right?
> > > 
> > > Fair enough.
> > > 
> > > 
> > > > So please better explain why we do this change.
> > > 
> > > asm/paravirt.h is included by one of the other headers included in
> > > kernel/sched/cputime.c on x86, but not on other architecures. On arm and
> > > arm64, where I am about to introduce asm/paravirt.h and stolen time
> > > support, without #include  in cputime.c I would get:
> > > 
> > > kernel/sched/cputime.c: In function ‘steal_account_process_tick’:
> > > kernel/sched/cputime.c:260:24: error: ‘paravirt_steal_enabled’ undeclared 
> > > (first use in this function)
> > >   if (static_key_false(¶virt_steal_enabled)) {
> > > 
> > > A bit of digging on x86 (using gcc -E on cputime.c) tells me that
> > > asm/paravirt.h is coming from the following include chain:
> > > 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > 
> > 
> > Fair enough; a slightly shorter version of that for a changelog will do
> > nicely.
> 
> Sure. Can I add your Acked-by to it?

Yep, no objection if the changelog is updated as per the above.

Acked-by: Peter Zijlstra (Intel) 

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

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[Peter Zijlstra]

On Tue, Nov 10, 2015 at 11:57:49AM +, Stefano Stabellini wrote:
> __current_kernel_time64 returns a struct timespec64, without taking the
> xtime lock. Mirrors __current_kernel_time/current_kernel_time.

It always helps if you include a reason why you want a patch.

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

Re: [Xen-devel] [PATCHv1 1/3] x86/ept: remove unnecessary sync after resolving misconfigured entries

[Jan Beulich]

>>> On 06.11.15 at 18:37,  wrote:
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -644,7 +644,6 @@ bool_t ept_handle_misconfig(uint64_t gpa)
>  spurious = curr->arch.hvm_vmx.ept_spurious_misconfig;
>  rc = resolve_misconfig(p2m, PFN_DOWN(gpa));
>  curr->arch.hvm_vmx.ept_spurious_misconfig = 0;
> -ept_sync_domain(p2m);
>  
>  p2m_unlock(p2m);
>  
> @@ -692,12 +691,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
> mfn_t mfn,
>  /* Carry out any eventually pending earlier changes first. */
>  ret = resolve_misconfig(p2m, gfn);
>  if ( ret < 0 )
> -{
> -ept_sync_domain(p2m);

Is avoiding this sync really a win? It shouldn't be needed according
to your analysis, I agree, but if it doesn't do any harm I'd prefer it
to be kept (and the deletion above to be converted to a similar,
conditional sync too). After all there also shouldn't be any error
here, yet if there was one, wanting to be on the safe side calls for
doing a sync imo.

>  return ret;
> -}
> -if ( ret > 0 )
> -needs_sync = sync_on;

This deletes the only use of sync_on, i.e. the patch should change
needs_sync back to bool_t at once.

Jan


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

Re: [Xen-devel] Runtime services support for Xen on ARM

[Stefano Stabellini]

CC'ing xen-devel and Jan

On Tue, 10 Nov 2015, Shannon Zhao wrote:
> Hi Stefano,
> 
> I'm working on adding Runtime services support at Xen side. Most of work
> is adding the ARM part in xen/common/efi/runtime.c.
> 
> There is one problem which block me. That is how to implement
> efi_rs_enter() and efi_rs_leave() for ARM, since I think current
> implementation is x86 specific and won't work on ARM. Also the rtc_lock.
> 
> Could you give some suggestion? Thanks!

efi_rs_enter() and efi_rs_leave() look very PV x86 specific. It is
possible that we don't actually need to do anything at all on ARM, aside
from refactoring the code. Jan?

Similarly we don't have an rtc_lock spinlock today and it is not
actually needed, but for the sake of keeping the common code common, I
would just introduce rtc_lock on ARM too.

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

[Xen-devel] [linux-mingo-tip-master test] 63927: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

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

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[Arnd Bergmann]

On Tuesday 10 November 2015 11:57:49 Stefano Stabellini wrote:
> __current_kernel_time64 returns a struct timespec64, without taking the
> xtime lock. Mirrors __current_kernel_time/current_kernel_time.
> 

Actually it doesn't mirror __current_kernel_time/current_kernel_time

> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> index ec89d84..b5802bf 100644
> --- a/include/linux/timekeeping.h
> +++ b/include/linux/timekeeping.h
> @@ -19,7 +19,8 @@ extern int do_sys_settimeofday(const struct timespec *tv,
>   */
>  unsigned long get_seconds(void);
>  struct timespec64 current_kernel_time64(void);
> -/* does not take xtime_lock */
> +/* do not take xtime_lock */
> +struct timespec64 __current_kernel_time64(void);
>  struct timespec __current_kernel_time(void);

Please change __current_kernel_time into a static inline function
while you are introducing the new one, to match the patch description ;-)

Arnd

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

Re: [Xen-devel] [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.

[Jan Beulich]

>>> On 06.11.15 at 20:36,  wrote:
> All of XENVER_* have now an XSM check.
> 
> The subops for XENVER_[compile_info|changeset|commandline|
> extraversion] are now priviliged operations. To not break
> guests we still return an string - but it is just ''.

And I continue to question at least the extraversion part.

> The rest: XENVER_[version|capabilities|
> parameters|get_features|page_size|guest_handle] behave
> as before - allowed by default for all guests.
> 
> This is with the XSM default policy and with the dummy ones.

And with a non-default policy you now ignore one of the latter
ops to also get denied.

> @@ -354,10 +356,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
> arg)
>  return 0;
>  
>  case XENVER_commandline:
> -if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
> +{
> +size_t len = ARRAY_SIZE(saved_cmdline);
> +
> +if ( deny )
> +len = strlen(xen_deny());

+1 (or else you fail to nul-terminate the output).

Jan


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

Re: [Xen-devel] [PATCH v2 4/7] xen: introduce XENPF_settime64

[Arnd Bergmann]

On Tuesday 10 November 2015 11:57:52 Stefano Stabellini wrote:
> Rename the current XENPF_settime hypercall and related struct to
> XENPF_settime32.
> 
> Signed-off-by: Stefano Stabellini 
> CC: konrad.w...@oracle.com
> CC: david.vra...@citrix.com
> CC: boris.ostrov...@oracle.com

Looks good.

> ---
>  arch/x86/xen/time.c  |8 
>  include/xen/interface/platform.h |   18 ++
>  2 files changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index 663c2ea..3bbd377 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -134,10 +134,10 @@ static int xen_pvclock_gtod_notify(struct 
> notifier_block *nb,
> if (!was_set && timespec_compare(&now, &next_sync) < 0)
> return NOTIFY_OK;
>  
> -   op.cmd = XENPF_settime;
> -   op.u.settime.secs = now.tv_sec;
> -   op.u.settime.nsecs = now.tv_nsec;
> -   op.u.settime.system_time = xen_clocksource_read();
> +   op.cmd = XENPF_settime32;
> +   op.u.settime32.secs = now.tv_sec;
> +   op.u.settime32.nsecs = now.tv_nsec;
> +   op.u.settime32.system_time = xen_clocksource_read();
>  
> (void)HYPERVISOR_platform_op(&op);

I suppose someone will have to get back to this eventually and
change the code to try XENPF_settime64 first.

Arnd

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

Re: [Xen-devel] [PATCH v2 6/7] xen/arm: introduce xen_read_wallclock

[Arnd Bergmann]

On Tuesday 10 November 2015 11:57:54 Stefano Stabellini wrote:
> +static void xen_read_wallclock(struct timespec64 *ts)
> +{
> +   u32 version;
> +   u64 delta;
> +   struct timespec64 now;
> +   struct shared_info *s = HYPERVISOR_shared_info;
> +   struct pvclock_wall_clock *wall_clock = &(s->wc);
> +
> +   /* get wallclock at system boot */
> +   do {
> +   version = wall_clock->version;
> +   rmb();  /* fetch version before time */
> +   now.tv_sec  = ((uint64_t)wall_clock->sec_hi << 32) | 
> wall_clock->sec;
> +   now.tv_nsec = wall_clock->nsec;
> +   rmb();  /* fetch time before checking version */
> +   } while ((wall_clock->version & 1) || (version != 
> wall_clock->version));
> +
> +   delta = arch_timer_read_counter() * (u64)NSEC_PER_SEC;
> +   do_div(delta, arch_timer_get_rate()); /* time since system boot */
> +   delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
> +
> +   now.tv_nsec = do_div(delta, NSEC_PER_SEC);
> +   now.tv_sec = delta;
> +
> +   set_normalized_timespec64(ts, now.tv_sec, now.tv_nsec);
> +
> +}

Instead of the two do_div(), I would do the entire calculation in
terms of nanoseconds and then call ns_to_timespec64() in the end
instead of set_normalized_timespec64(). That is just an optimization
though, your version looks correct as well.

Arnd

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

Re: [Xen-devel] Runtime services support for Xen on ARM

[Ian Campbell]

On Tue, 2015-11-10 at 12:26 +, Stefano Stabellini wrote:
> CC'ing xen-devel and Jan
> 
> On Tue, 10 Nov 2015, Shannon Zhao wrote:
> > Hi Stefano,
> > 
> > I'm working on adding Runtime services support at Xen side. Most of
> > work
> > is adding the ARM part in xen/common/efi/runtime.c.
> > 
> > There is one problem which block me. That is how to implement
> > efi_rs_enter() and efi_rs_leave() for ARM, since I think current
> > implementation is x86 specific and won't work on ARM. Also the
> > rtc_lock.
> > 
> > Could you give some suggestion? Thanks!
> 
> efi_rs_enter() and efi_rs_leave() look very PV x86 specific. It is
> possible that we don't actually need to do anything at all on ARM, aside
> from refactoring the code. Jan?

I think these functions derive from the USE_SET_VIRTUAL_ADDRESS_MAP option.
If that is set we call efi_rs->SetVirtualAddressMap to tell the f/w about
our virtual address layout and can then call rs directly with no faff.

Unfortunately SetVirtualAddressMap is incompatible with kexec (I think you
can only call it once), so we have this USE_SET_VIRTUAL_ADDRESS_MAP option.

Without USE_SET_VIRTUAL_ADDRESS_MAP we need to switch to a set of page
tables which are "OK" for calling the runtime services. I'm not sure what
"OK" means here -- but I suspect it means "1:1" in some part.

So sadly I think we do _eventually_ need to support this mode (for kexec),
which would mean quite a bit of refactoring (since the relevant code
in xen/common/efi/boot.c has some x86-isms).

But right now, since we do not yet support kexec,  I think we could get the
ball rolling wrt RS support by setting USE_SET_VIRTUAL_ADDRESS_MAP on ARM
and dodging the need to make efi_rs_enter() work right now. (IOW make it
the problem of whomever wants kexec support...)

Unless there are issues other than kexec with SetVirtualAddressMap which
I'm not thinking of now?

> Similarly we don't have an rtc_lock spinlock today and it is not
> actually needed, but for the sake of keeping the common code common, I
> would just introduce rtc_lock on ARM too.

Agreed.

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

Re: [Xen-devel] Using IRQ_GUEST|IRQ_PER_CPU to signal "delivery to current vcpu"?

[Stefano Stabellini]

On Tue, 10 Nov 2015, Ian Campbell wrote:
> Hi arch maintainers,
> 
> The ARM hardware has a concept called a "Peripheral Private Interrupt"
> (PPI), an IRQ which is per-core as opposed to a "Shared Peripheral
> Interrupt" (SPI) which is per-SOC (routable to all cores).
> 
> (For completeness the other classes of IRQ are "Software Generated
> Interrupt" (SGI) AKA "IPI" and "Locality-specific Peripheral Interrupt"
> (LPI) which is, approximately, an MSI).
> 
> PPIs are typically generated by per-core resources, such as the timer
> block, or PMU blocks etc.
> 
> I would like to arrange for a new (I think) class of interrupt within Xen,
> which is an interrupt (necessarily a PPI) which is always delivered to
> whichever VCPU is currently resident on a given PCPU and use this to
> arrange to deliver vtimer interrupts direct to the current VCPU, taking
> care of context switching the status (is it pending? active? etc) of the
> PPI while context switching the vtimer (something which the h/w supports
> quite easily and which then avoids races wrt guests unmasking the timer
> while it is still active in the interrupt virtual controller but not the
> real one).
> 
> My first cut ([0], from January this year) keyed this behaviour on an ARM
> specific struct irq_guest field ->d (domain) being NULL, which I wasn't
> terribly comfortable with. In my WIP v2 I have current added a new boolean
> field to struct irq_guest, which seems rather wasteful due to rounding up
> of the size etc and so I'm not really happy with that either (I also
> considered and rejected other tricks like stealing a bit from an existing
> field, e.g. the unsigned virq).
> 
> So, I was considering using a new bit in the common desc->status bit. Upon
> checking xen/irq.h I found there was already IRQ_PER_CPU which appears to
> be completely unused in the current code base (it looks to have been used
> by IA64 and PPC, but never by x86 and not currently used AFAICT by ARM, x86
> or common code.)
> 
> It seems like IRQ_GUEST|IRQ_PER_CPU is a pretty good fit for the semantics
> I want, but I think it would be confusing to define it as meaning such only
> on ARM and having either common code or other architectures ascribe a
> different meaning (other than "meaningless on this arch") to it.
> 
> I think the other possible use case of this scenario (routing a PPI to a
> specific guest) seems rather unlikely (since it would imply pinning in
> various odd ways). I think that use case can also be dealt with by the
> context switching code which can reroute the interrupt as needed (i.e.
> unmask only when the relevant vcpu is running).
> 
> Any thoughts?
> 
> Arguably all PPIs on ARM (even "normal" ones) ought to have IRQ_PER_CPU set
> too but that is something of an aside.

It seems reasonable.

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

Re: [Xen-devel] [PATCH v2 7/7] xen/arm: set the system time in Xen via the XENPF_settime64 hypercall

[Arnd Bergmann]

On Tuesday 10 November 2015 11:57:55 Stefano Stabellini wrote:
> +   op.u.settime64.nsecs = now.tv_nsec;
> +   op.u.settime64.system_time = arch_timer_read_counter() * 
> (u64)NSEC_PER_SEC;
> +   do_div(op.u.settime64.system_time, arch_timer_get_rate());

NSEC_PER_SEC is a large number, doesn't that multiplication overflow the
64-bit system_time variable?

> +   printk("GTOD: Setting to %llu.%u at %llu\n",

   %llu.%09u

so you get the leading zeroes.

> +  op.u.settime64.secs,
> +  op.u.settime64.nsecs,
> +  op.u.settime64.system_time);
> +   (void)HYPERVISOR_platform_op(&op);

Arnd

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

Re: [Xen-devel] [PATCH QEMU-XEN v5 9/9] xen: make it possible to build without the Xen PV domain builder

[Stefano Stabellini]

On Mon, 9 Nov 2015, Ian Campbell wrote:
> Until the previous patch this relied on xc_fd(), which was only
> implemented for Xen 4.0 and earlier.
> 
> Given this wasn't working since Xen 4.0 I have marked this as disabled
> by default.
> 
> Removing this support drops the use of a bunch of symbols from
> libxenctrl, specifically:
> 
>   - xc_domain_create
>   - xc_domain_destroy
>   - xc_domain_getinfo
>   - xc_domain_max_vcpus
>   - xc_domain_setmaxmem
>   - xc_domain_unpause
>   - xc_evtchn_alloc_unbound
>   - xc_linux_build
> 
> This is another step towards only using Xen libraries which provide a
> stable inteface.
> 
> Signed-off-by: Ian Campbell 

Reviewed-by: Stefano Stabellini 


> v5: XEN_CREATE entirely wihtin CONFIG_XEN_PV_DOMAIN_BUILD ifdef.
> Simplify configure'ry.
> 
> v4: Fixed all checkpatch errors.
> Disabled by default.
> ---
>  configure | 15 +++
>  hw/xenpv/Makefile.objs|  4 +++-
>  hw/xenpv/xen_machine_pv.c | 15 +++
>  3 files changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index 0253cc9..4ab6d9c 100755
> --- a/configure
> +++ b/configure
> @@ -247,6 +247,7 @@ vnc_jpeg=""
>  vnc_png=""
>  xen=""
>  xen_ctrl_version=""
> +xen_pv_domain_build="no"
>  xen_pci_passthrough=""
>  linux_aio=""
>  cap_ng=""
> @@ -917,6 +918,10 @@ for opt do
>;;
>--enable-xen-pci-passthrough) xen_pci_passthrough="yes"
>;;
> +  --disable-xen-pv-domain-build) xen_pv_domain_build="no"
> +  ;;
> +  --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
> +  ;;
>--disable-brlapi) brlapi="no"
>;;
>--enable-brlapi) brlapi="yes"
> @@ -2172,6 +2177,12 @@ if test "$xen_pci_passthrough" != "no"; then
>fi
>  fi
>  
> +if test "$xen_pv_domain_build" = "yes" &&
> +   test "$xen" != "yes"; then
> +error_exit "User requested Xen PV domain builder support" \
> +"which requires Xen support."
> +fi
> +
>  ##
>  # libtool probe
>  
> @@ -4762,6 +4773,7 @@ fi
>  echo "xen support   $xen"
>  if test "$xen" = "yes" ; then
>echo "xen ctrl version  $xen_ctrl_version"
> +  echo "pv dom build  $xen_pv_domain_build"
>  fi
>  echo "brlapi support$brlapi"
>  echo "bluez  support$bluez"
> @@ -5130,6 +5142,9 @@ fi
>  if test "$xen" = "yes" ; then
>echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
>echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
> $config_host_mak
> +  if test "$xen_pv_domain_build" = "yes" ; then
> +echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> +  fi
>  fi
>  if test "$linux_aio" = "yes" ; then
>echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
> diff --git a/hw/xenpv/Makefile.objs b/hw/xenpv/Makefile.objs
> index 49f6e9e..bbf5873 100644
> --- a/hw/xenpv/Makefile.objs
> +++ b/hw/xenpv/Makefile.objs
> @@ -1,2 +1,4 @@
>  # Xen PV machine support
> -obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
> +obj-$(CONFIG_XEN) += xen_machine_pv.o
> +# Xen PV machine builder support
> +obj-$(CONFIG_XEN_PV_DOMAIN_BUILD) += xen_domainbuild.o
> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
> index 23d6ef0..3250b94 100644
> --- a/hw/xenpv/xen_machine_pv.c
> +++ b/hw/xenpv/xen_machine_pv.c
> @@ -30,9 +30,6 @@
>  
>  static void xen_init_pv(MachineState *machine)
>  {
> -const char *kernel_filename = machine->kernel_filename;
> -const char *kernel_cmdline = machine->kernel_cmdline;
> -const char *initrd_filename = machine->initrd_filename;
>  DriveInfo *dinfo;
>  int i;
>  
> @@ -46,17 +43,27 @@ static void xen_init_pv(MachineState *machine)
>  case XEN_ATTACH:
>  /* nothing to do, xend handles everything */
>  break;
> -case XEN_CREATE:
> +#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
> +case XEN_CREATE: {
> +const char *kernel_filename = machine->kernel_filename;
> +const char *kernel_cmdline = machine->kernel_cmdline;
> +const char *initrd_filename = machine->initrd_filename;
>  if (xen_domain_build_pv(kernel_filename, initrd_filename,
>  kernel_cmdline) < 0) {
>  fprintf(stderr, "xen pv domain creation failed\n");
>  exit(1);
>  }
>  break;
> +}
> +#endif
>  case XEN_EMULATE:
>  fprintf(stderr, "xen emulation not implemented (yet)\n");
>  exit(1);
>  break;
> +default:
> +fprintf(stderr, "unhandled xen_mode %d\n", xen_mode);
> +exit(1);
> +break;
>  }
>  
>  xen_be_register("console", &xen_console_ops);
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

[Lars Kurth]

> On 9 Nov 2015, at 18:15, Wojtek Porczyk  wrote:
> 
> On Mon, Nov 09, 2015 at 04:31:58PM +, Franz wrote:
>> Perhaps a way out of this impasse is to put bounties on Xen security tasks
>> identified by Joanna and properly advertise these bounties to Xen users.
>> [snip]
> 
> This is fundamentaly wrong idea. Security isn't something you can
> "apply" or put bounty on. It's a state of the mind, especcialy
> developer's.

I don't think this was what was proposed. What was proposed, if I understood 
correctly, was to use funds to sponsor solutions to specific problems in 
specific areas of code that have been developed in the past and where we may 
have issues due to past mistakes. 

> Joanna wrote in her mail:
> 
 I can't help but have a feeling that some of the Xen developers seem to be
 overconfident in their belief they can fully understand all the possible
 execution paths in their code. Well, the XSAs quoted above are an 
 indisputable
 prove that this is not quite always the case. Realizing that, each 
 developer by
 themselves, might be a great step towards a more secure hypervisor...
> 
> And that's why we can't just "submit a patch" to "contribute security".

Although I agree that you can't submit a patch to fix security, it is possible 
to focus on some areas you care about and lead by example. In particular, if 
you believe that there is a mindset problem today. I think, you do also need to 
distinguish between what was happening in the past and what the project does 
today. There is little point to complain about what developers, who now don't 
work on Xen any more, did in the past. In particular, as the vast majority of 
active developers in the project were not around 6-7 years ago.

> There is something wrong with Xen as a whole project, but that something
> isn't the code. There is a mindset to be fixed.

I think this is a rather generalising statement, and maybe it would be more 
fruitful to focus on some concrete areas that can be improved. I also believe, 
that there has been a significant shift in mindset in many areas in the project 
in the last few years. 

Lars 


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

Re: [Xen-devel] Runtime services support for Xen on ARM

[Jan Beulich]

>>> On 10.11.15 at 13:26,  wrote:
> CC'ing xen-devel and Jan
> 
> On Tue, 10 Nov 2015, Shannon Zhao wrote:
>> Hi Stefano,
>> 
>> I'm working on adding Runtime services support at Xen side. Most of work
>> is adding the ARM part in xen/common/efi/runtime.c.
>> 
>> There is one problem which block me. That is how to implement
>> efi_rs_enter() and efi_rs_leave() for ARM, since I think current
>> implementation is x86 specific and won't work on ARM. Also the rtc_lock.
>> 
>> Could you give some suggestion? Thanks!
> 
> efi_rs_enter() and efi_rs_leave() look very PV x86 specific. It is
> possible that we don't actually need to do anything at all on ARM, aside
> from refactoring the code. Jan?

Whether you need to do much on ARM I don't know; doing
nothing doesn't seem to be among the options though, as at the
very least you need to acquire/release efi_rs_lock. The fact that
the code will need refactoring has been well known since the time
it got made common.

> Similarly we don't have an rtc_lock spinlock today and it is not
> actually needed, but for the sake of keeping the common code common, I
> would just introduce rtc_lock on ARM too.

I think this would better be hidden behind an arch abstraction,
doing nothing on ARM.

Jan


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

Re: [Xen-devel] [PATCHv1 3/3] x86/ept: defer the invalidation until the p2m lock is released

[Tim Deegan]

At 17:37 + on 06 Nov (1446831437), David Vrabel wrote:
> Holding the p2m lock while calling ept_sync_domain() is very expensive
> since it does a on_selected_cpus() call.  IPIs on many socket machines
> can be very slows and on_selected_cpus() is serialized.
> 
> Defer the invalidate until the p2m lock is released.  Since the processor
> may cache partial translations, we also need to make sure any page table
> pages to be freed are not freed until the invalidate is complete.  Such
> pages are temporarily stored an per-PCPU list.

That seems like it could get messy if a PCPU might have multiple p2ms
locked at once (e.g. nested HAP, altp2m).  I think a per-p2m list
would be more obviously correct, and not too expensive.

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH QEMU-XEN v5 7/9] xen: Use stable library interfaces when they are available.

[Stefano Stabellini]

On Mon, 9 Nov 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
> 
> Previous patches have already laid the groundwork for using these by
> switching the existing compatibility shims to reflect the intefaces to
> these libraries.
> 
> So all which remains is to update configure to detect the libraries
> and enable their use. Although they are notionally independent we take
> an all or nothing approach to the three libraries since they were
> added at the same time.
> 
> The only non-obvious bit is that we now open a proper xenforeignmemory
> handle for xen_fmem instead of reusing the xen_xc handle.
> 
> Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
> 4.7 which adds these libraries.
> 
> Signed-off-by: Ian Campbell 

Reviewed-by: Stefano Stabellini 

Two formatting issues below:


> v5: Remove ifdef check when undeffing the compat stuff.
> s/now way/no way/
> 
> v4: xenforeignmemory_open is now a compat wrapper, so no ifdef.
> 
> Simplify configury by asserting that interface version 470 will
> always have the libraries (lack of them makes it 460).
> 
> Ran checkpatch and fixed everything except:
> 
> ERROR: need consistent spacing around '*' (ctx:WxV)
> +typedef xc_interface *XenXC;
> 
> Which I think is a false +ve.
> 
> Simpler configure stuff
> ---
>  configure   | 55 
> +
>  include/hw/xen/xen_common.h | 36 +++--
>  2 files changed, 89 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index b4a3488..0253cc9 100755
> --- a/configure
> +++ b/configure
> @@ -1898,6 +1898,7 @@ fi
>  
>  if test "$xen" != "no" ; then
>xen_libs="-lxenstore -lxenctrl -lxenguest"
> +  xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
>  
># First we test whether Xen headers and libraries are available.
># If no, we are done and there is no Xen support.
> @@ -1920,6 +1921,57 @@ EOF
># Xen unstable
>elif
>cat > $TMPC < +/*
> + * If we have stable libs the we don't want the libxc compat
> + * layers, regardless of what CFLAGS we may have been given.
> + */
> +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#if !defined(HVM_MAX_VCPUS)
> +# error HVM_MAX_VCPUS not defined
> +#endif
> +int main(void) {
> +  xc_interface *xc;
> +  xenforeignmemory_handle *xfmem;
> +  xenevtchn_handle *xe;
> +  xengnttab_handle *xg;
> +
> +  xs_daemon_open();
> +
> +  xc = xc_interface_open(0, 0, 0);
> +  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
> +  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
> +  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
> +  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
> +
> +  xfmem = xenforeignmemory_open(0, 0);
> +  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
> +
> +  xe = xenevtchn_open(0, 0);
> +  xenevtchn_fd(xe);
> +
> +  xg = xengnttab_open(0, 0);
> +  xengnttab_map_grant_ref(xg, 0, 0, 0);
> +
> +  return 0;
> +}
> +EOF
> +  compile_prog "" "$xen_libs $xen_stable_libs"
> +  then
> +xen_ctrl_version=470
> +xen=yes
> +
> +  # Xen 4.6
> +  elif
> +  cat > $TMPC <  #include 
>  #include 
>  #include 
> @@ -2096,6 +2148,9 @@ EOF
>fi
>  
>if test "$xen" = yes; then
> +if test $xen_ctrl_version -ge 470  ; then
> + libs_softmmu="$xen_stable_libs $libs_softmmu"

tab


> +fi
>  libs_softmmu="$xen_libs $libs_softmmu"
>fi
>  fi
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 323c76c..a758ac4 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -6,6 +6,15 @@
>  #include 
>  #include 
>  
> +/*
> + * If we have new enough libxenctrl then we do not want/need these compat
> + * interfaces, despite what the user supplied cflags might say. They
> + * must be undefined before including xenctrl.h
> + */
> +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +
>  #include 
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
>  #  include 
> @@ -151,8 +160,8 @@ static inline void xs_close(struct xs_handle *xsh)
>  }
>  
>  
> -/* Xen 4.1 */
> -#else
> +/* Xen 4.1 thru 4.6 */
> +#elif CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
>  
>  typedef xc_interface *XenXC;
>  typedef xc_interface *xenforeignmemory_handle;
> @@ -190,11 +199,34 @@ static inline XenXC xen_xc_interface_open(void *logger, 
> void *dombuild_logger,
>  xc_map_foreign_bulk(*h, d, p, a, e, n)
>  #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
>  
> +/* FIXME There is no way to have the xen fd */
> +static inline int xc_f

Re: [Xen-devel] [PATCH QEMU-XEN v5 3/9] xen: Switch to libxengnttab interface for compat shims.

[Stefano Stabellini]

On Mon, 9 Nov 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> One such library will be libxengnttab which provides access to grant
> tables.
> 
> In preparation for this switch the compatibility layer in xen_common.h
> (which support building with older versions of Xen) to use what will
> be the new library API. This means that the gnttab shim will disappear
> for versions of Xen which include libxengnttab.
> 
> To simplify things for the <= 4.0.0 support we wrap the int fd in a
> malloc(sizeof int) such that the handle is always a pointer. This
> leads to less typedef headaches and the need for
> XC_HANDLER_INITIAL_VALUE etc for these interfaces.
> 
> Note that this patch does not add any support for actually using
> libxengnttab, it just adjusts the existing shims.
> 
> Signed-off-by: Ian Campbell 

Reviewed-by: Stefano Stabellini 


> v4: Ran checkpatch, fixed all errors
> Allocate correct size for handle (i.e. not size of the ptr)
> Rebase onto "xen_console: correctly cleanup primary console on
> teardown."
> 
> v5: Rebase over b4f72e31b924 "hw/net/xen_nic.c: Free 'netdev->txs'
> when map 'netdev->rxs' fails" which added a new gnttab_munmap.
> ---
>  hw/block/xen_disk.c  | 38 --
>  hw/char/xen_console.c|  4 ++--
>  hw/net/xen_nic.c | 18 +-
>  hw/xen/xen_backend.c | 10 +-
>  include/hw/xen/xen_backend.h |  2 +-
>  include/hw/xen/xen_common.h  | 42 --
>  6 files changed, 69 insertions(+), 45 deletions(-)
> 
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 1bbc111..0e80da1 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -173,11 +173,11 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
> gpointer user_data)
>  static void destroy_grant(gpointer pgnt)
>  {
>  PersistentGrant *grant = pgnt;
> -XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
>  
> -if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
> +if (xengnttab_munmap(gnt, grant->page, 1) != 0) {
>  xen_be_printf(&grant->blkdev->xendev, 0,
> -  "xc_gnttab_munmap failed: %s\n",
> +  "xengnttab_munmap failed: %s\n",
>strerror(errno));
>  }
>  grant->blkdev->persistent_gnt_count--;
> @@ -190,11 +190,11 @@ static void remove_persistent_region(gpointer data, 
> gpointer dev)
>  {
>  PersistentRegion *region = data;
>  struct XenBlkDev *blkdev = dev;
> -XenGnttab gnt = blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
>  
> -if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
> +if (xengnttab_munmap(gnt, region->addr, region->num) != 0) {
>  xen_be_printf(&blkdev->xendev, 0,
> -  "xc_gnttab_munmap region %p failed: %s\n",
> +  "xengnttab_munmap region %p failed: %s\n",
>region->addr, strerror(errno));
>  }
>  xen_be_printf(&blkdev->xendev, 3,
> @@ -329,7 +329,7 @@ err:
>  
>  static void ioreq_unmap(struct ioreq *ioreq)
>  {
> -XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
>  int i;
>  
>  if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
> @@ -339,8 +339,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
>  if (!ioreq->pages) {
>  return;
>  }
> -if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
> -xen_be_printf(&ioreq->blkdev->xendev, 0, "xc_gnttab_munmap 
> failed: %s\n",
> +if (xengnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
> +xen_be_printf(&ioreq->blkdev->xendev, 0,
> +  "xengnttab_munmap failed: %s\n",
>strerror(errno));
>  }
>  ioreq->blkdev->cnt_map -= ioreq->num_unmap;
> @@ -350,8 +351,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
>  if (!ioreq->page[i]) {
>  continue;
>  }
> -if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
> -xen_be_printf(&ioreq->blkdev->xendev, 0, "xc_gnttab_munmap 
> failed: %s\n",
> +if (xengnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
> +xen_be_printf(&ioreq->blkdev->xendev, 0,
> +  "xengnttab_munmap failed: %s\n",
>strerror(errno));
>  }
>  ioreq->blkdev->cnt_map--;
> @@ -363,7 +365,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
>  
>  static int ioreq_map(struct ioreq *ioreq)
>  {
> -XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = ioreq->blkde

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  4fa72bd15564c59cbd54d4db31a3060293e782ca
baseline version:
 xen  22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c

Last test of basis63720  2015-11-06 15:01:02 Z3 days
Testing same since64060  2015-11-10 12:01:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Jan Beulich 
  Riku Voipio 
  Roger Pau Monné 
  Shannon Zhao 
  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=4fa72bd15564c59cbd54d4db31a3060293e782ca
+ . ./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 
4fa72bd15564c59cbd54d4db31a3060293e782ca
+ branch=xen-unstable-smoke
+ revision=4fa72bd15564c59cbd54d4db31a3060293e782ca
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x4fa72bd15564c59cbd54d4db31a3060293e782ca = 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/
+++

Re: [Xen-devel] [PATCH v11 4/5] arm64: introduce CONFIG_PARAVIRT, PARAVIRT_TIME_ACCOUNTING and pv_time_ops

[Stefano Stabellini]

On Thu, 5 Nov 2015, Stefano Stabellini wrote:
> Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM64.
> Necessary duplication of paravirt.h and paravirt.c with ARM.
> 
> The only paravirt interface supported is pv_time_ops.steal_clock, so no
> runtime pvops patching needed.
> 
> This allows us to make use of steal_account_process_tick for stolen
> ticks accounting.
> 
> Signed-off-by: Stefano Stabellini 
> Acked-by: Marc Zyngier 

Ping?

Catalin, Will,
are you happy with this change?


> CC: will.dea...@arm.com
> CC: n...@linaro.org
> CC: marc.zyng...@arm.com
> CC: c...@codeaurora.org
> CC: a...@arndb.de
> CC: o...@lixom.net
> CC: catalin.mari...@arm.com
> 
> ---
> 
> Changes in v10:
> - replace "---help---" with "help"
> 
> Changes in v7:
> - ifdef CONFIG_PARAVIRT the content of paravirt.h.
> ---
>  arch/arm64/Kconfig|   20 
>  arch/arm64/include/asm/paravirt.h |   20 
>  arch/arm64/kernel/Makefile|1 +
>  arch/arm64/kernel/paravirt.c  |   25 +
>  4 files changed, 66 insertions(+)
>  create mode 100644 arch/arm64/include/asm/paravirt.h
>  create mode 100644 arch/arm64/kernel/paravirt.c
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7b10647..659e286 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -533,6 +533,25 @@ config SECCOMP
> and the task is only allowed to execute a few safe syscalls
> defined by each seccomp mode.
>  
> +config PARAVIRT
> + bool "Enable paravirtualization code"
> + help
> +   This changes the kernel so it can modify itself when it is run
> +   under a hypervisor, potentially improving performance significantly
> +   over full virtualization.
> +
> +config PARAVIRT_TIME_ACCOUNTING
> + bool "Paravirtual steal time accounting"
> + select PARAVIRT
> + default n
> + help
> +   Select this option to enable fine granularity task steal time
> +   accounting. Time spent executing other tasks in parallel with
> +   the current vCPU is discounted from the vCPU power. To account for
> +   that, there can be a small performance impact.
> +
> +   If in doubt, say N here.
> +
>  config XEN_DOM0
>   def_bool y
>   depends on XEN
> @@ -541,6 +560,7 @@ config XEN
>   bool "Xen guest support on ARM64"
>   depends on ARM64 && OF
>   select SWIOTLB_XEN
> + select PARAVIRT
>   help
> Say Y if you want to run Linux in a Virtual Machine on Xen on ARM64.
>  
> diff --git a/arch/arm64/include/asm/paravirt.h 
> b/arch/arm64/include/asm/paravirt.h
> new file mode 100644
> index 000..fd5f428
> --- /dev/null
> +++ b/arch/arm64/include/asm/paravirt.h
> @@ -0,0 +1,20 @@
> +#ifndef _ASM_ARM64_PARAVIRT_H
> +#define _ASM_ARM64_PARAVIRT_H
> +
> +#ifdef CONFIG_PARAVIRT
> +struct static_key;
> +extern struct static_key paravirt_steal_enabled;
> +extern struct static_key paravirt_steal_rq_enabled;
> +
> +struct pv_time_ops {
> + unsigned long long (*steal_clock)(int cpu);
> +};
> +extern struct pv_time_ops pv_time_ops;
> +
> +static inline u64 paravirt_steal_clock(int cpu)
> +{
> + return pv_time_ops.steal_clock(cpu);
> +}
> +#endif
> +
> +#endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 474691f..ca9fbe1 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -41,6 +41,7 @@ arm64-obj-$(CONFIG_EFI) += efi.o 
> efi-entry.stub.o
>  arm64-obj-$(CONFIG_PCI)  += pci.o
>  arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
>  arm64-obj-$(CONFIG_ACPI) += acpi.o
> +arm64-obj-$(CONFIG_PARAVIRT) += paravirt.o
>  
>  obj-y+= $(arm64-obj-y) vdso/
>  obj-m+= $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
> new file mode 100644
> index 000..53f371e
> --- /dev/null
> +++ b/arch/arm64/kernel/paravirt.c
> @@ -0,0 +1,25 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2013 Citrix Systems
> + *
> + * Author: Stefano Stabellini 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct static_key paravirt_steal_enabled;
> +struct static_key paravirt_steal_rq_enabled;
> +
> +struct pv_time_ops pv_time_ops;
> +EXPORT_SYMBOL_GPL(pv_time_ops);
> -- 
> 1.7.10.4
> 

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

Re: [Xen-devel] [PATCH v11 3/5] arm: introduce CONFIG_PARAVIRT, PARAVIRT_TIME_ACCOUNTING and pv_time_ops

[Stefano Stabellini]

On Thu, 5 Nov 2015, Stefano Stabellini wrote:
> Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM.
> 
> The only paravirt interface supported is pv_time_ops.steal_clock, so no
> runtime pvops patching needed.
> 
> This allows us to make use of steal_account_process_tick for stolen
> ticks accounting.
> 
> Signed-off-by: Stefano Stabellini 
> Acked-by: Christopher Covington 
> Acked-by: Ian Campbell 
> CC: li...@arm.linux.org.uk
> CC: will.dea...@arm.com
> CC: n...@linaro.org
> CC: marc.zyng...@arm.com
> CC: c...@codeaurora.org
> CC: a...@arndb.de
> CC: o...@lixom.net


Russell,
are you OK with this patch?




> 
> Changes in v10:
> - replace "---help---" with "help"
> 
> Changes in v7:
> - ifdef CONFIG_PARAVIRT the content of paravirt.h.
> 
> Changes in v3:
> - improve commit description and Kconfig help text;
> - no need to initialize pv_time_ops;
> - add PARAVIRT_TIME_ACCOUNTING.
> ---
>  arch/arm/Kconfig|   20 
>  arch/arm/include/asm/paravirt.h |   20 
>  arch/arm/kernel/Makefile|1 +
>  arch/arm/kernel/paravirt.c  |   25 +
>  4 files changed, 66 insertions(+)
>  create mode 100644 arch/arm/include/asm/paravirt.h
>  create mode 100644 arch/arm/kernel/paravirt.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f1ed110..60be104 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1823,6 +1823,25 @@ config SWIOTLB
>  config IOMMU_HELPER
>   def_bool SWIOTLB
>  
> +config PARAVIRT
> + bool "Enable paravirtualization code"
> + help
> +   This changes the kernel so it can modify itself when it is run
> +   under a hypervisor, potentially improving performance significantly
> +   over full virtualization.
> +
> +config PARAVIRT_TIME_ACCOUNTING
> + bool "Paravirtual steal time accounting"
> + select PARAVIRT
> + default n
> + help
> +   Select this option to enable fine granularity task steal time
> +   accounting. Time spent executing other tasks in parallel with
> +   the current vCPU is discounted from the vCPU power. To account for
> +   that, there can be a small performance impact.
> +
> +   If in doubt, say N here.
> +
>  config XEN_DOM0
>   def_bool y
>   depends on XEN
> @@ -1836,6 +1855,7 @@ config XEN
>   select ARCH_DMA_ADDR_T_64BIT
>   select ARM_PSCI
>   select SWIOTLB_XEN
> + select PARAVIRT
>   help
> Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>  
> diff --git a/arch/arm/include/asm/paravirt.h b/arch/arm/include/asm/paravirt.h
> new file mode 100644
> index 000..8435ff59
> --- /dev/null
> +++ b/arch/arm/include/asm/paravirt.h
> @@ -0,0 +1,20 @@
> +#ifndef _ASM_ARM_PARAVIRT_H
> +#define _ASM_ARM_PARAVIRT_H
> +
> +#ifdef CONFIG_PARAVIRT
> +struct static_key;
> +extern struct static_key paravirt_steal_enabled;
> +extern struct static_key paravirt_steal_rq_enabled;
> +
> +struct pv_time_ops {
> + unsigned long long (*steal_clock)(int cpu);
> +};
> +extern struct pv_time_ops pv_time_ops;
> +
> +static inline u64 paravirt_steal_clock(int cpu)
> +{
> + return pv_time_ops.steal_clock(cpu);
> +}
> +#endif
> +
> +#endif
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index af9e59b..3e6e937 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_VDSO)  += vdso.o
>  ifneq ($(CONFIG_ARCH_EBSA110),y)
>obj-y  += io.o
>  endif
> +obj-$(CONFIG_PARAVIRT)   += paravirt.o
>  
>  head-y   := head$(MMUEXT).o
>  obj-$(CONFIG_DEBUG_LL)   += debug.o
> diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel/paravirt.c
> new file mode 100644
> index 000..53f371e
> --- /dev/null
> +++ b/arch/arm/kernel/paravirt.c
> @@ -0,0 +1,25 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2013 Citrix Systems
> + *
> + * Author: Stefano Stabellini 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct static_key paravirt_steal_enabled;
> +struct static_key paravirt_steal_rq_enabled;
> +
> +struct pv_time_ops pv_time_ops;
> +EXPORT_SYMBOL_GPL(pv_time_ops);
> -- 
> 1.7.10.4
> 

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

Re: [Xen-devel] [PATCH 2/2] arm: export platform_op XENPF_settime

[Julien Grall]

Hi Stefano,

On 09/11/15 17:09, Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Julien Grall wrote:
>> For instance we may want to call update_domain_wallclock_time in
>> construct_dom0 before clearing the pause flags. This is because the
>> wallclock may be out of sync as construction DOM0 takes some time.
> 
> That's not necessary: the wallclock in Xen is the number
> of seconds since 1970 at the time the physical machine booted, plus the
> domain specific offset, so it is not subject to quick incremental
> changes, like a monotonic clock.

Well, building dom0 takes more than one sec, even on big platform.

And if it's not subject to quick incremental, what's the point to call
update_domain_wallclock_time in an odd way in arch_set_info_guest rather
than in arch_domain_create?

>>> Signed-off-by: Stefano Stabellini 
>>> Signed-off-by: Ian Campbell 
>>> ---
>>>  xen/arch/arm/Makefile |1 +
>>>  xen/arch/arm/domain.c |3 ++
>>>  xen/arch/arm/platform_hypercall.c |   62 
>>> +
>>>  xen/arch/arm/traps.c  |1 +
>>>  xen/include/xsm/dummy.h   |   12 +++
>>>  xen/include/xsm/xsm.h |   13 
>>
>> You also have to fix xsm/flask/hooks.c.
> 
> Uhm.. OK
> 
> 
>>>  6 files changed, 80 insertions(+), 12 deletions(-)
>>>  create mode 100644 xen/arch/arm/platform_hypercall.c
>>
>> [..]
>>
>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>>> index b2bfc7d..ac9b1b3 100644
>>> --- a/xen/arch/arm/domain.c
>>> +++ b/xen/arch/arm/domain.c
>>> @@ -742,6 +742,9 @@ int arch_set_info_guest(
>>>  v->arch.ttbr1 = ctxt->ttbr1;
>>>  v->arch.ttbcr = ctxt->ttbcr;
>>>  
>>> +if ( v->vcpu_id == 0 )
>>> +update_domain_wallclock_time(v->domain);
>>> +
>>>  v->is_initialised = 1;
>>>  
>>>  if ( ctxt->flags & VGCF_online )
>>> diff --git a/xen/arch/arm/platform_hypercall.c 
>>> b/xen/arch/arm/platform_hypercall.c
>>> new file mode 100644
>>> index 000..f60d7b3
>>> --- /dev/null
>>> +++ b/xen/arch/arm/platform_hypercall.c
>>> @@ -0,0 +1,62 @@
>>> +/**
>>> + * platform_hypercall.c
>>> + * 
>>> + * Hardware platform operations. Intended for use by domain-0 kernel.
>>> + * 
>>> + * Copyright (c) 2015, Citrix
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +DEFINE_SPINLOCK(xenpf_lock);
>>> +
>>> +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
>>> +{
>>
>> Would it make sense to introduce a common platform code which take care
>> of common hypercall? See for instance do_domctl and arch_do_domctl.
> 
> In this case I don't think so. I don't see the other existing
> platform_ops being used on arm.

Are you sure? I can see some of the sub-hypercall implemented for ARM
too such as XENPF_efi_runtime_call, XENPF_change_freq,
XENPF_getidletime, XENPF_cpu_{online,offline}...

I'm not asking for implementing all of them now, but just preparing an
infrastructure for later similar to the domctl version.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [qubes-devel] Re: Critique of the Xen Security Process

[Franz]

On Tue, Nov 10, 2015 at 1:09 PM, Lars Kurth 
wrote:

>
> > On 9 Nov 2015, at 18:15, Wojtek Porczyk 
> wrote:
> >
> > On Mon, Nov 09, 2015 at 04:31:58PM +, Franz wrote:
> >> Perhaps a way out of this impasse is to put bounties on Xen security
> tasks
> >> identified by Joanna and properly advertise these bounties to Xen users.
> >> [snip]
> >
> > This is fundamentaly wrong idea. Security isn't something you can
> > "apply" or put bounty on. It's a state of the mind, especcialy
> > developer's.
>
> I don't think this was what was proposed. What was proposed, if I
> understood correctly, was to use funds to sponsor solutions to specific
> problems in specific areas of code that have been developed in the past and
> where we may have issues due to past mistakes.
>
>
Yes Lars of course, and also changing mindset has real costs, because a
more security oriented mindset involves some additional work, some hard
thinking, some additional study, something already done that needs recoding
etc.  I mean it is not simply an act of will, rather a targeted effort. A
security mindset is slowing developing in the whole society and I see Qubes
developers as the more advanced front. The reality is changing fast. A
serious  bug in Xen practically means that all my passwords can be stolen
from my no-network VM or even more seriously that the life of an activist
can be compromised. These facts are dramatic or tragic and the situation is
constantly and fast worsening. So nobody is guilty for 7 years old code
developed in a different situation, but the same Joanna words are totally
justified and welcome. We have to face reality and take action. From my
point of view It is a matter of educating those who pay, for that I offered
to write some copywriting.
Best
Fran


> > Joanna wrote in her mail:
> >
>  I can't help but have a feeling that some of the Xen developers seem
> to be
>  overconfident in their belief they can fully understand all the
> possible
>  execution paths in their code. Well, the XSAs quoted above are an
> indisputable
>  prove that this is not quite always the case. Realizing that, each
> developer by
>  themselves, might be a great step towards a more secure hypervisor...
> >
> > And that's why we can't just "submit a patch" to "contribute security".
>
> Although I agree that you can't submit a patch to fix security, it is
> possible to focus on some areas you care about and lead by example. In
> particular, if you believe that there is a mindset problem today. I think,
> you do also need to distinguish between what was happening in the past and
> what the project does today. There is little point to complain about what
> developers, who now don't work on Xen any more, did in the past. In
> particular, as the vast majority of active developers in the project were
> not around 6-7 years ago.
>
> > There is something wrong with Xen as a whole project, but that something
> > isn't the code. There is a mindset to be fixed.
>
> I think this is a rather generalising statement, and maybe it would be
> more fruitful to focus on some concrete areas that can be improved. I also
> believe, that there has been a significant shift in mindset in many areas
> in the project in the last few years.
>
> Lars
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8.1 09/21] xen/x86: set the vPMU interface based on the presence of a lapic

[Boris Ostrovsky]

On 11/10/2015 06:30 AM, Roger Pau Monne wrote:

Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or not.

Signed-off-by: Roger Pau Monné 
Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v8:
  - Don't add the xenpmu hypercalls to the HVM hypercall table (yet).


This, of course, breaks VPMU. I thought that what Jan suggested 
yesterday (folding the two hypercall tables) was meant to be made part 
of the series.


-boris


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

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

[Julien Grall]

Hi Stefano,

I've made some comment on the v1 after you resend this version. I think
there are still valid with the new version.

Can you give a look there?

Regards,

On 09/11/15 17:32, sstabell...@kernel.org wrote:
> From: Stefano Stabellini 
> 
> Call update_domain_wallclock_time at domain initialization, specifically
> in arch_set_info_guest for vcpu0, like we do on x86.
> Set time_offset_seconds to the number of seconds between phisical boot
> and domain initialization: it is going to be used to get/set the
> wallclock time.
> Add time_offset_seconds to system_time when before calling do_settime,
> so that system_time actually accounts for all the time in nsec between
> machine boot and when the wallclock was set.
> 
> 
> 
> Signed-off-by: Stefano Stabellini 
> CC: dgde...@tycho.nsa.gov
> 
> ---
> 
> Changes in v2:
> - drop XENPF_settime32
> - set time_offset_seconds
> - modify xen/xsm/flask/hooks.c
> ---
>  xen/arch/arm/Makefile |1 +
>  xen/arch/arm/domain.c |9 ++
>  xen/arch/arm/platform_hypercall.c |   62 
> +
>  xen/arch/arm/traps.c  |1 +
>  xen/arch/arm/vtimer.c |1 -
>  xen/include/asm-arm/time.h|2 ++
>  xen/include/xsm/dummy.h   |   12 +++
>  xen/include/xsm/xsm.h |   13 
>  xen/xsm/flask/hooks.c |2 +-
>  9 files changed, 89 insertions(+), 14 deletions(-)
>  create mode 100644 xen/arch/arm/platform_hypercall.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 1ef39f7..240aa29 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -23,6 +23,7 @@ obj-y += percpu.o
>  obj-y += guestcopy.o
>  obj-y += physdev.o
>  obj-y += platform.o
> +obj-y += platform_hypercall.o
>  obj-y += setup.o
>  obj-y += bootfdt.o
>  obj-y += time.o
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index b2bfc7d..1f07a41 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -21,6 +21,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -742,6 +743,14 @@ int arch_set_info_guest(
>  v->arch.ttbr1 = ctxt->ttbr1;
>  v->arch.ttbcr = ctxt->ttbcr;
>  
> +if ( v->vcpu_id == 0 )
> +{
> +struct domain *d = v->domain;
> +d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset 
> - boot_count);
> +do_div(d->time_offset_seconds, 10);
> +update_domain_wallclock_time(d);
> +}
> +
>  v->is_initialised = 1;
>  
>  if ( ctxt->flags & VGCF_online )
> diff --git a/xen/arch/arm/platform_hypercall.c 
> b/xen/arch/arm/platform_hypercall.c
> new file mode 100644
> index 000..cb8e575
> --- /dev/null
> +++ b/xen/arch/arm/platform_hypercall.c
> @@ -0,0 +1,62 @@
> +/**
> + * platform_hypercall.c
> + * 
> + * Hardware platform operations. Intended for use by domain-0 kernel.
> + * 
> + * Copyright (c) 2015, Citrix
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DEFINE_SPINLOCK(xenpf_lock);
> +
> +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
> +{
> +long ret;
> +struct xen_platform_op curop, *op = &curop;
> +struct domain *d;
> +
> +if ( copy_from_guest(op, u_xenpf_op, 1) )
> +return -EFAULT;
> +
> +if ( op->interface_version != XENPF_INTERFACE_VERSION )
> +return -EACCES;
> +
> +d = rcu_lock_current_domain();
> +if ( d == NULL )
> +return -ESRCH;
> +
> +ret = xsm_platform_op(XSM_PRIV, op->cmd);
> +if ( ret )
> +return ret;
> +
> +spin_lock(&xenpf_lock);
> +
> +switch ( op->cmd )
> +{
> +case XENPF_settime64:
> +if ( likely(!op->u.settime64.mbz) )
> +do_settime(op->u.settime64.secs,
> +   op->u.settime64.nsecs,
> +   op->u.settime64.system_time + 
> SECONDS(d->time_offset_seconds));
> +else
> +ret = -EINVAL;
> +break;
> +
> +default:
> +ret = -ENOSYS;
> +break;
> +}
> +
> +spin_unlock(&xenpf_lock);
> +rcu_unlock_domain(d);
> +return ret;
> +}
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 9d2bd6a..c49bd3f 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1233,6 +1233,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
>  HYPERCALL(hvm_op, 2),
>  HYPERCALL(grant_table_op, 3),
>  HYPERCALL(multicall, 2),
> +HYPERCALL(platform_op, 1),
>  HYPERCALL_ARM(vcpu_op, 3),
>  };
>  
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 1418092..95c2d6c 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  
> -extern s_time_t ticks_to_ns(uint64_t ticks);
>  extern uint64_t ns_to_ticks(

Re: [Xen-devel] Runtime services support for Xen on ARM

[Shannon Zhao]

On 2015/11/10 20:36, Ian Campbell wrote:

On Tue, 2015-11-10 at 12:26 +, Stefano Stabellini wrote:

CC'ing xen-devel and Jan

On Tue, 10 Nov 2015, Shannon Zhao wrote:

Hi Stefano,

I'm working on adding Runtime services support at Xen side. Most of
work
is adding the ARM part in xen/common/efi/runtime.c.

There is one problem which block me. That is how to implement
efi_rs_enter() and efi_rs_leave() for ARM, since I think current
implementation is x86 specific and won't work on ARM. Also the
rtc_lock.

Could you give some suggestion? Thanks!


efi_rs_enter() and efi_rs_leave() look very PV x86 specific. It is
possible that we don't actually need to do anything at all on ARM, aside
from refactoring the code. Jan?


I think these functions derive from the USE_SET_VIRTUAL_ADDRESS_MAP option.
If that is set we call efi_rs->SetVirtualAddressMap to tell the f/w about
our virtual address layout and can then call rs directly with no faff.

Unfortunately SetVirtualAddressMap is incompatible with kexec (I think you
can only call it once), so we have this USE_SET_VIRTUAL_ADDRESS_MAP option.

Without USE_SET_VIRTUAL_ADDRESS_MAP we need to switch to a set of page
tables which are "OK" for calling the runtime services. I'm not sure what
"OK" means here -- but I suspect it means "1:1" in some part.

So sadly I think we do _eventually_ need to support this mode (for kexec),
which would mean quite a bit of refactoring (since the relevant code
in xen/common/efi/boot.c has some x86-isms).

But right now, since we do not yet support kexec,  I think we could get the
ball rolling wrt RS support by setting USE_SET_VIRTUAL_ADDRESS_MAP on ARM
and dodging the need to make efi_rs_enter() work right now. (IOW make it
the problem of whomever wants kexec support...)

Yeah, we could set USE_SET_VIRTUAL_ADDRESS_MAP at this moment, but as 
you said, it needs to support kexec and make efi_rs_enter() work 
eventually. So if anyone know this well, please share me your ideas. 
Thanks very much.



Unless there are issues other than kexec with SetVirtualAddressMap which
I'm not thinking of now?


Similarly we don't have an rtc_lock spinlock today and it is not
actually needed, but for the sake of keeping the common code common, I
would just introduce rtc_lock on ARM too.


Agreed.



--
Shannon

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

Re: [Xen-devel] [PATCH 2/2] arm: export platform_op XENPF_settime

[Stefano Stabellini]

On Tue, 10 Nov 2015, Julien Grall wrote:
> Hi Stefano,
> 
> On 09/11/15 17:09, Stefano Stabellini wrote:
> > On Thu, 5 Nov 2015, Julien Grall wrote:
> >> For instance we may want to call update_domain_wallclock_time in
> >> construct_dom0 before clearing the pause flags. This is because the
> >> wallclock may be out of sync as construction DOM0 takes some time.
> > 
> > That's not necessary: the wallclock in Xen is the number
> > of seconds since 1970 at the time the physical machine booted, plus the
> > domain specific offset, so it is not subject to quick incremental
> > changes, like a monotonic clock.
> 
> Well, building dom0 takes more than one sec, even on big platform.
> 
> And if it's not subject to quick incremental, what's the point to call
> update_domain_wallclock_time in an odd way in arch_set_info_guest rather
> than in arch_domain_create?

Only to make sure that is called after domain_vtimer_init.
In fact I could move it to arch_domain_create right after it. That might
be better?


> >>> Signed-off-by: Stefano Stabellini 
> >>> Signed-off-by: Ian Campbell 
> >>> ---
> >>>  xen/arch/arm/Makefile |1 +
> >>>  xen/arch/arm/domain.c |3 ++
> >>>  xen/arch/arm/platform_hypercall.c |   62 
> >>> +
> >>>  xen/arch/arm/traps.c  |1 +
> >>>  xen/include/xsm/dummy.h   |   12 +++
> >>>  xen/include/xsm/xsm.h |   13 
> >>
> >> You also have to fix xsm/flask/hooks.c.
> > 
> > Uhm.. OK
> > 
> > 
> >>>  6 files changed, 80 insertions(+), 12 deletions(-)
> >>>  create mode 100644 xen/arch/arm/platform_hypercall.c
> >>
> >> [..]
> >>
> >>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> >>> index b2bfc7d..ac9b1b3 100644
> >>> --- a/xen/arch/arm/domain.c
> >>> +++ b/xen/arch/arm/domain.c
> >>> @@ -742,6 +742,9 @@ int arch_set_info_guest(
> >>>  v->arch.ttbr1 = ctxt->ttbr1;
> >>>  v->arch.ttbcr = ctxt->ttbcr;
> >>>  
> >>> +if ( v->vcpu_id == 0 )
> >>> +update_domain_wallclock_time(v->domain);
> >>> +
> >>>  v->is_initialised = 1;
> >>>  
> >>>  if ( ctxt->flags & VGCF_online )
> >>> diff --git a/xen/arch/arm/platform_hypercall.c 
> >>> b/xen/arch/arm/platform_hypercall.c
> >>> new file mode 100644
> >>> index 000..f60d7b3
> >>> --- /dev/null
> >>> +++ b/xen/arch/arm/platform_hypercall.c
> >>> @@ -0,0 +1,62 @@
> >>> +/**
> >>> + * platform_hypercall.c
> >>> + * 
> >>> + * Hardware platform operations. Intended for use by domain-0 kernel.
> >>> + * 
> >>> + * Copyright (c) 2015, Citrix
> >>> + */
> >>> +
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +DEFINE_SPINLOCK(xenpf_lock);
> >>> +
> >>> +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
> >>> +{
> >>
> >> Would it make sense to introduce a common platform code which take care
> >> of common hypercall? See for instance do_domctl and arch_do_domctl.
> > 
> > In this case I don't think so. I don't see the other existing
> > platform_ops being used on arm.
> 
> Are you sure? I can see some of the sub-hypercall implemented for ARM
> too such as XENPF_efi_runtime_call, XENPF_change_freq,
> XENPF_getidletime, XENPF_cpu_{online,offline}...
> 
> I'm not asking for implementing all of them now, but just preparing an
> infrastructure for later similar to the domctl version.

The spin_trylock call is not useful on ARM and many of the other ops are
not either. In addition the implementation of XENPF_settime64 is
slightly different too.

I don't think there is any value in trying to share the do_platform_op
function now. But maybe in the future.

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

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

[Stefano Stabellini]

Actually I addressed all the ones I thought needed to be addressed and
replied to the others. Is there anything that I missed?

On Tue, 10 Nov 2015, Julien Grall wrote:
> Hi Stefano,
> 
> I've made some comment on the v1 after you resend this version. I think
> there are still valid with the new version.
> 
> Can you give a look there?
> 
> Regards,
> 
> On 09/11/15 17:32, sstabell...@kernel.org wrote:
> > From: Stefano Stabellini 
> > 
> > Call update_domain_wallclock_time at domain initialization, specifically
> > in arch_set_info_guest for vcpu0, like we do on x86.
> > Set time_offset_seconds to the number of seconds between phisical boot
> > and domain initialization: it is going to be used to get/set the
> > wallclock time.
> > Add time_offset_seconds to system_time when before calling do_settime,
> > so that system_time actually accounts for all the time in nsec between
> > machine boot and when the wallclock was set.
> > 
> > 
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: dgde...@tycho.nsa.gov
> > 
> > ---
> > 
> > Changes in v2:
> > - drop XENPF_settime32
> > - set time_offset_seconds
> > - modify xen/xsm/flask/hooks.c
> > ---
> >  xen/arch/arm/Makefile |1 +
> >  xen/arch/arm/domain.c |9 ++
> >  xen/arch/arm/platform_hypercall.c |   62 
> > +
> >  xen/arch/arm/traps.c  |1 +
> >  xen/arch/arm/vtimer.c |1 -
> >  xen/include/asm-arm/time.h|2 ++
> >  xen/include/xsm/dummy.h   |   12 +++
> >  xen/include/xsm/xsm.h |   13 
> >  xen/xsm/flask/hooks.c |2 +-
> >  9 files changed, 89 insertions(+), 14 deletions(-)
> >  create mode 100644 xen/arch/arm/platform_hypercall.c
> > 
> > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> > index 1ef39f7..240aa29 100644
> > --- a/xen/arch/arm/Makefile
> > +++ b/xen/arch/arm/Makefile
> > @@ -23,6 +23,7 @@ obj-y += percpu.o
> >  obj-y += guestcopy.o
> >  obj-y += physdev.o
> >  obj-y += platform.o
> > +obj-y += platform_hypercall.o
> >  obj-y += setup.o
> >  obj-y += bootfdt.o
> >  obj-y += time.o
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index b2bfc7d..1f07a41 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -742,6 +743,14 @@ int arch_set_info_guest(
> >  v->arch.ttbr1 = ctxt->ttbr1;
> >  v->arch.ttbcr = ctxt->ttbcr;
> >  
> > +if ( v->vcpu_id == 0 )
> > +{
> > +struct domain *d = v->domain;
> > +d->time_offset_seconds = 
> > ticks_to_ns(d->arch.virt_timer_base.offset - boot_count);
> > +do_div(d->time_offset_seconds, 10);
> > +update_domain_wallclock_time(d);
> > +}
> > +
> >  v->is_initialised = 1;
> >  
> >  if ( ctxt->flags & VGCF_online )
> > diff --git a/xen/arch/arm/platform_hypercall.c 
> > b/xen/arch/arm/platform_hypercall.c
> > new file mode 100644
> > index 000..cb8e575
> > --- /dev/null
> > +++ b/xen/arch/arm/platform_hypercall.c
> > @@ -0,0 +1,62 @@
> > +/**
> > + * platform_hypercall.c
> > + * 
> > + * Hardware platform operations. Intended for use by domain-0 kernel.
> > + * 
> > + * Copyright (c) 2015, Citrix
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DEFINE_SPINLOCK(xenpf_lock);
> > +
> > +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
> > +{
> > +long ret;
> > +struct xen_platform_op curop, *op = &curop;
> > +struct domain *d;
> > +
> > +if ( copy_from_guest(op, u_xenpf_op, 1) )
> > +return -EFAULT;
> > +
> > +if ( op->interface_version != XENPF_INTERFACE_VERSION )
> > +return -EACCES;
> > +
> > +d = rcu_lock_current_domain();
> > +if ( d == NULL )
> > +return -ESRCH;
> > +
> > +ret = xsm_platform_op(XSM_PRIV, op->cmd);
> > +if ( ret )
> > +return ret;
> > +
> > +spin_lock(&xenpf_lock);
> > +
> > +switch ( op->cmd )
> > +{
> > +case XENPF_settime64:
> > +if ( likely(!op->u.settime64.mbz) )
> > +do_settime(op->u.settime64.secs,
> > +   op->u.settime64.nsecs,
> > +   op->u.settime64.system_time + 
> > SECONDS(d->time_offset_seconds));
> > +else
> > +ret = -EINVAL;
> > +break;
> > +
> > +default:
> > +ret = -ENOSYS;
> > +break;
> > +}
> > +
> > +spin_unlock(&xenpf_lock);
> > +rcu_unlock_domain(d);
> > +return ret;
> > +}
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 9d2bd6a..c49bd3f 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -1233,6 +1233,7 @@ static arm_hyper

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

[Julien Grall]

On 10/11/15 14:28, Stefano Stabellini wrote:
> Actually I addressed all the ones I thought needed to be addressed and
> replied to the others. Is there anything that I missed?

I was speaking about: <5641fb01.4050...@citrix.com>

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[Stefano Stabellini]

On Tue, 10 Nov 2015, Peter Zijlstra wrote:
> On Tue, Nov 10, 2015 at 11:57:49AM +, Stefano Stabellini wrote:
> > __current_kernel_time64 returns a struct timespec64, without taking the
> > xtime lock. Mirrors __current_kernel_time/current_kernel_time.
> 
> It always helps if you include a reason why you want a patch.

You are right, sorry.

I need to get the current_kernel_time from a pvclock_gtod callback
function, which cannot take the lock again.

On x86 we are just calling __current_kernel_time() (see
arch/x86/xen/time.c:xen_pvclock_gtod_notify). I was introducing the same
functionality on ARM, when the maintainers pointed out that it might be
better to use struct timespec64 and related functions for
future-proofness. To do that I need a version of __current_kernel_time
which returns a struct timespec64.

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

Re: [Xen-devel] [PATCH v2 3/6] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

On Mon, Nov 09, 2015 at 09:05:15PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 20.07.2015 16:35, Daniel Kiper wrote:
> > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. 
> > Relocator
> > will set lower parts of %rax and %rbx accordingly to multiboot2 
> > specification.
> > On the other hand processor mode, just before jumping into loaded image, 
> > will
> > be set accordingly to Unified Extensible Firmware Interface Specification,
> > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> > loaded image will be able to use EFI boot services without any issues.
> >
> > If idea is accepted I will prepare grub_relocator32_efi relocator too.
> >
> > Signed-off-by: Daniel Kiper 
> > ---
> >  grub-core/Makefile.core.def  |1 +
> >  grub-core/lib/i386/relocator.c   |   53 +++
> >  grub-core/lib/i386/relocator64_efi.S |   77 
> > ++
> >  grub-core/loader/multiboot.c |   29 +++--
> >  grub-core/loader/multiboot_mbi2.c|   19 +++--
> >  include/grub/i386/multiboot.h|   11 +
> >  include/grub/i386/relocator.h|   21 ++
> >  include/multiboot2.h |9 
> >  8 files changed, 213 insertions(+), 7 deletions(-)
> >  create mode 100644 grub-core/lib/i386/relocator64_efi.S
> >
> > diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> > index a6101de..d583549 100644
> > --- a/grub-core/Makefile.core.def
> > +++ b/grub-core/Makefile.core.def
> > @@ -1519,6 +1519,7 @@ module = {
> >x86 = lib/i386/relocator_common_c.c;
> >ieee1275 = lib/ieee1275/relocator.c;
> >efi = lib/efi/relocator.c;
> > +  x86_64_efi = lib/i386/relocator64_efi.S;
> >mips = lib/mips/relocator_asm.S;
> >mips = lib/mips/relocator.c;
> >powerpc = lib/powerpc/relocator_asm.S;
> > diff --git a/grub-core/lib/i386/relocator.c b/grub-core/lib/i386/relocator.c
> > index 71dd4f0..459027e 100644
> > --- a/grub-core/lib/i386/relocator.c
> > +++ b/grub-core/lib/i386/relocator.c
> > @@ -69,6 +69,19 @@ extern grub_uint64_t grub_relocator64_rsi;
> >  extern grub_addr_t grub_relocator64_cr3;
> >  extern struct grub_i386_idt grub_relocator16_idt;
> >
> > +#ifdef GRUB_MACHINE_EFI
> > +#ifdef __x86_64__
> > +extern grub_uint8_t grub_relocator64_efi_start;
> > +extern grub_uint8_t grub_relocator64_efi_end;
> > +extern grub_uint64_t grub_relocator64_efi_rax;
> > +extern grub_uint64_t grub_relocator64_efi_rbx;
> > +extern grub_uint64_t grub_relocator64_efi_rcx;
> > +extern grub_uint64_t grub_relocator64_efi_rdx;
> > +extern grub_uint64_t grub_relocator64_efi_rip;
> > +extern grub_uint64_t grub_relocator64_efi_rsi;
> > +#endif
> > +#endif
> > +
> >  #define RELOCATOR_SIZEOF(x)(&grub_relocator##x##_end - 
> > &grub_relocator##x##_start)
> >
> >  grub_err_t
> > @@ -214,3 +227,43 @@ grub_relocator64_boot (struct grub_relocator *rel,
> >/* Not reached.  */
> >return GRUB_ERR_NONE;
> >  }
> > +
> > +#ifdef GRUB_MACHINE_EFI
> > +#ifdef __x86_64__
> > +grub_err_t
> > +grub_relocator64_efi_boot (struct grub_relocator *rel,
> > +  struct grub_relocator64_efi_state state)
> > +{
> > +  grub_err_t err;
> > +  void *relst;
> > +  grub_relocator_chunk_t ch;
> > +
> > +  err = grub_relocator_alloc_chunk_align (rel, &ch, 0,
> > + 0x4000 - RELOCATOR_SIZEOF 
> > (64_efi),
> > + RELOCATOR_SIZEOF (64_efi), 16,
> > + GRUB_RELOCATOR_PREFERENCE_NONE, 1);
> > +  if (err)
> > +return err;
> > +
> > +  grub_relocator64_efi_rax = state.rax;
> > +  grub_relocator64_efi_rbx = state.rbx;
> > +  grub_relocator64_efi_rcx = state.rcx;
> > +  grub_relocator64_efi_rdx = state.rdx;
> > +  grub_relocator64_efi_rip = state.rip;
> > +  grub_relocator64_efi_rsi = state.rsi;
> > +
> > +  grub_memmove (get_virtual_current_address (ch), 
> > &grub_relocator64_efi_start,
> > +   RELOCATOR_SIZEOF (64_efi));
> > +
> > +  err = grub_relocator_prepare_relocs (rel, get_physical_target_address 
> > (ch),
> > +  &relst, NULL);
> > +  if (err)
> > +return err;
> > +
> > +  ((void (*) (void)) relst) ();
> > +
> > +  /* Not reached.  */
> > +  return GRUB_ERR_NONE;
> > +}
> > +#endif
> > +#endif
> > diff --git a/grub-core/lib/i386/relocator64_efi.S 
> > b/grub-core/lib/i386/relocator64_efi.S
> > new file mode 100644
> > index 000..fcd1964
> > --- /dev/null
> > +++ b/grub-core/lib/i386/relocator64_efi.S
> > @@ -0,0 +1,77 @@
> > +/*
> > + *  GRUB  --  GRand Unified Bootloader
> > + *  Copyright (C) 2009,2010  Free Software Foundation, Inc.
> > + *  Copyright (C) 2014,2015  Oracle Co.
> > + *  Author: Daniel Kiper
> > + *
> > + *  GRUB is free software: you can redistribute it and/or modify
> > + *  it under the terms o

Re: [Xen-devel] [PATCH v2 4/7] xen: introduce XENPF_settime64

[Stefano Stabellini]

On Tue, 10 Nov 2015, Arnd Bergmann wrote:
> On Tuesday 10 November 2015 11:57:52 Stefano Stabellini wrote:
> > Rename the current XENPF_settime hypercall and related struct to
> > XENPF_settime32.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: konrad.w...@oracle.com
> > CC: david.vra...@citrix.com
> > CC: boris.ostrov...@oracle.com
> 
> Looks good.

Can I add your acked-by?


> > ---
> >  arch/x86/xen/time.c  |8 
> >  include/xen/interface/platform.h |   18 ++
> >  2 files changed, 18 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> > index 663c2ea..3bbd377 100644
> > --- a/arch/x86/xen/time.c
> > +++ b/arch/x86/xen/time.c
> > @@ -134,10 +134,10 @@ static int xen_pvclock_gtod_notify(struct 
> > notifier_block *nb,
> > if (!was_set && timespec_compare(&now, &next_sync) < 0)
> > return NOTIFY_OK;
> >  
> > -   op.cmd = XENPF_settime;
> > -   op.u.settime.secs = now.tv_sec;
> > -   op.u.settime.nsecs = now.tv_nsec;
> > -   op.u.settime.system_time = xen_clocksource_read();
> > +   op.cmd = XENPF_settime32;
> > +   op.u.settime32.secs = now.tv_sec;
> > +   op.u.settime32.nsecs = now.tv_nsec;
> > +   op.u.settime32.system_time = xen_clocksource_read();
> >  
> > (void)HYPERVISOR_platform_op(&op);
> 
> I suppose someone will have to get back to this eventually and
> change the code to try XENPF_settime64 first.

I'll leave that to the x86 maintainers

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

Re: [Xen-devel] [PATCH 2/2] arm: export platform_op XENPF_settime

[Julien Grall]

On 10/11/15 14:27, Stefano Stabellini wrote:
> On Tue, 10 Nov 2015, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 09/11/15 17:09, Stefano Stabellini wrote:
>>> On Thu, 5 Nov 2015, Julien Grall wrote:
 For instance we may want to call update_domain_wallclock_time in
 construct_dom0 before clearing the pause flags. This is because the
 wallclock may be out of sync as construction DOM0 takes some time.
>>>
>>> That's not necessary: the wallclock in Xen is the number
>>> of seconds since 1970 at the time the physical machine booted, plus the
>>> domain specific offset, so it is not subject to quick incremental
>>> changes, like a monotonic clock.
>>
>> Well, building dom0 takes more than one sec, even on big platform.
>>
>> And if it's not subject to quick incremental, what's the point to call
>> update_domain_wallclock_time in an odd way in arch_set_info_guest rather
>> than in arch_domain_create?
> 
> Only to make sure that is called after domain_vtimer_init.
> In fact I could move it to arch_domain_create right after it. That might
> be better?

Yes, it would make more sense.

I'm also wondering if we can directly do the call in domain_vtimer_init?


> Signed-off-by: Stefano Stabellini 
> Signed-off-by: Ian Campbell 
> ---
>  xen/arch/arm/Makefile |1 +
>  xen/arch/arm/domain.c |3 ++
>  xen/arch/arm/platform_hypercall.c |   62 
> +
>  xen/arch/arm/traps.c  |1 +
>  xen/include/xsm/dummy.h   |   12 +++
>  xen/include/xsm/xsm.h |   13 

 You also have to fix xsm/flask/hooks.c.
>>>
>>> Uhm.. OK
>>>
>>>
>  6 files changed, 80 insertions(+), 12 deletions(-)
>  create mode 100644 xen/arch/arm/platform_hypercall.c

 [..]

> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index b2bfc7d..ac9b1b3 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -742,6 +742,9 @@ int arch_set_info_guest(
>  v->arch.ttbr1 = ctxt->ttbr1;
>  v->arch.ttbcr = ctxt->ttbcr;
>  
> +if ( v->vcpu_id == 0 )
> +update_domain_wallclock_time(v->domain);
> +
>  v->is_initialised = 1;
>  
>  if ( ctxt->flags & VGCF_online )
> diff --git a/xen/arch/arm/platform_hypercall.c 
> b/xen/arch/arm/platform_hypercall.c
> new file mode 100644
> index 000..f60d7b3
> --- /dev/null
> +++ b/xen/arch/arm/platform_hypercall.c
> @@ -0,0 +1,62 @@
> +/**
> + * platform_hypercall.c
> + * 
> + * Hardware platform operations. Intended for use by domain-0 kernel.
> + * 
> + * Copyright (c) 2015, Citrix
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DEFINE_SPINLOCK(xenpf_lock);
> +
> +long do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
> +{

 Would it make sense to introduce a common platform code which take care
 of common hypercall? See for instance do_domctl and arch_do_domctl.
>>>
>>> In this case I don't think so. I don't see the other existing
>>> platform_ops being used on arm.
>>
>> Are you sure? I can see some of the sub-hypercall implemented for ARM
>> too such as XENPF_efi_runtime_call, XENPF_change_freq,
>> XENPF_getidletime, XENPF_cpu_{online,offline}...
>>
>> I'm not asking for implementing all of them now, but just preparing an
>> infrastructure for later similar to the domctl version.
> 
> The spin_trylock call is not useful on ARM and many of the other ops are
> not either. In addition the implementation of XENPF_settime64 is
> slightly different too.

That's a call to forget changing the locking when it will be required
and may lead to security issue.

It really doesn't hurt us to do the spin_trylock solution today.

> 
> I don't think there is any value in trying to share the do_platform_op
> function now. But maybe in the future.

Ok.

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 4/7] xen: introduce XENPF_settime64

[Arnd Bergmann]

On Tuesday 10 November 2015 14:43:26 Stefano Stabellini wrote:
> On Tue, 10 Nov 2015, Arnd Bergmann wrote:
> > On Tuesday 10 November 2015 11:57:52 Stefano Stabellini wrote:
> > > Rename the current XENPF_settime hypercall and related struct to
> > > XENPF_settime32.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > CC: konrad.w...@oracle.com
> > > CC: david.vra...@citrix.com
> > > CC: boris.ostrov...@oracle.com
> > 
> > Looks good.
> 
> Can I add your acked-by?
> 
> 

Yes, please do.

Arnd

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

Re: [Xen-devel] [PATCH v2 5/6] multiboot2: Add support for relocatable images

[Daniel Kiper]

On Mon, Nov 09, 2015 at 09:08:35PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 20.07.2015 16:35, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper 
> What is handling the actual relocation?

In Xen we get image offset from GRUB2 and using this value we calculate
relative addresses. We are using %fs for it.

> Why doesn't this patch include support for ELF relocations?

This is another option. We considered it too. However, in our case
relative addressing looks simpler then ELF relocations. However, if
you wish I can add this functionality when this patch series is
included in upstream GRUB2. Is it OK for you?

Daniel

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

Re: [Xen-devel] [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design

[Dario Faggioli]

On Tue, 2015-11-03 at 16:43 +0800, Feng Wu wrote:

> diff --git a/docs/misc/vtd-pi.txt b/docs/misc/vtd-pi.txt
> new file mode 100644
> index 000..f9b4637
> --- /dev/null
> +++ b/docs/misc/vtd-pi.txt

> +With VT-d Posted-interrupt we can get the following advantages:
> +- Direct delivery of external interrupts to running vCPUs without
> VMM
> +intervention
> +- Decrease the interrupt migration complexity. On vCPU migration,
> software
> +can atomically co-migrate all interrupts targeting the migrating
> vCPU. For
> +virtual machines with assigned devices, migrating a vCPU across
> pCPUs
> +either incurs the overhead of forwarding interrupts in software
> (e.g. via VMM
> +generated IPIs), or complexity to independently migrate each
> interrupt targeting
> +the vCPU to the new pCPU. However, after enabling VT-d PI, the
> destination vCPU
> +of an external interrupt from assigned devices is stored in the IRTE
> (i.e.
> +Posted-interrupt Descriptor Address), when vCPU is migrated to
> another pCPU,
> +we will set this new pCPU in the 'NDST' filed of Posted-interrupt

   ^field

> +More information about APICv and CPU-side Posted-interrupt, please
> refer
> +to Chapter 29, and Section 29.6 in the Intel SDM:
> +http://www.intel.com/content/dam/www/public/us/en/documents/manuals/
> 64-ia-32-architectures-software-developer-manual-325462.pdf
> +
ISTR Andrew said something about chapter names and numbers, and about
what to link in these cases, during v8 review.

> +- Update posted-interrupt descriptor during vCPU scheduling
> +
> +The basic idea here is:
> +1. When vCPU is running
> +- Set 'NV' to 'posted_intr_vector'.
> +- Clear 'SN' to accept posted-interrupts.
> +- Set 'NDST' to the pCPU on which the vCPU will be running.
> +2. When vCPU is blocked
> +- Set 'NV' to ' pi_wakeup_vector ', so we can wake up the
> +  related vCPU when posted-interrupt happens for it.
> +  Please refer to the above section about the new global
> vector.
> +- Clear 'SN' to accept posted-interrupts
> +3. When vCPU is preempted or sleeping
> +- Set 'SN' to suppress non-urgent interrupts
> +  (Currently, we only support non-urgent interrupts)
> + When vCPU is preempted or sleep, it doesn't need to accept
> + posted-interrupt notification event since we don't change
> the behavior
> + of scheduler when the interrupt occurs, we still need wait
> for the next
> + scheduling of the vCPU. When external interrupts from
> assigned devices occur,
> + the interrupts are recorded in PIR, and will be synced to
> IRR before VM-Entry.
> +- Set 'NV' to 'posted_intr_vector'.
> +
> +- How to wakeup blocked vCPU when an interrupt is posted for it
> (wakeup notification handler).
> +
>
> [...]
>
> +Here are what we do for the blocked vCPU:
> +1. Define a per-cpu list 'pi_blocked_vcpu', which stored the blocked
> +vCPU on the pCPU.
> +2. When the vCPU is going to block, insert the vCPU
> +to the per-cpu list belonging to the pCPU it was running.
> +3. When the vCPU is unblocked, remove the vCPU from the related pCPU
> list.
> +
> +In the handler of 'pi_wakeup_vector', we do:
> +1. Get the physical CPU.
> +2. Iterate the list 'pi_blocked_vcpu' of the current pCPU, if 'ON'
> is set,
> +we unblock the associated vCPU.
> +
This is indeed more general, and the fact that it does no longer
mentions RUNSTATEs, makes it more adherent to the actual implementation
(and hence more useful), so thanks for doing this.

Personally, I'd add a quick comment about how this, despite being
related to blocking and unblocking, happens actually inside VMX
handlers, i.e., (quickly) what is the relationship within these sets of
events (blocking/unblocking VMENTER/EXIT) and why it is ok to do things
like they are done.

I'm not too fussed about this, though. So, if others don't think
something like this is necessary, I'm fine with what you have here.

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 v2] tools/ocaml/xb: Correct calculations of data/space the ring

[Wei Liu]

On Tue, Nov 10, 2015 at 10:46:44AM +, Andrew Cooper wrote:
> ml_interface_{read,write}() would miscalculate the quantity of
> data/space in the ring if it crossed the ring boundary, and incorrectly
> return a short read/write.
> 
> This causes a protocol stall, as either side of the ring ends up waiting
> for what they believe to be the other side needing to take the next
> action.
> 
> Correct the calculations to cope with crossing the ring boundary.
> 
> In addition, correct the error detection.  It is a hard error if the
> producer index gets more than a ring size ahead of the consumer, or if
> the consumer ever overtakes the producer.
> 
> Signed-off-by: Andrew Cooper 

I think I will port this patch to cxenstored at some point. As far as I
can tell cxenstored's data / space calculation is bogus in the same way.

Wei.

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

Re: [Xen-devel] [PATCH v2] tools/ocaml/xb: Correct calculations of data/space the ring

[Samuel Thibault]

Wei Liu, on Tue 10 Nov 2015 14:59:17 +, wrote:
> I think I will port this patch to cxenstored at some point. As far as I
> can tell cxenstored's data / space calculation is bogus in the same way.

The low-level function return short reads and writes, yes, but that is
handled at a higher level: initialize_fds sets timeout to 0 when there
is still room (domain_can_read() or domain_can_write()). So it will
improve performance a little bit, but not fix actual bugs.

Samuel

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

Re: [Xen-devel] [PATCH v2] tools/ocaml/xb: Correct calculations of data/space the ring

[Wei Liu]

On Tue, Nov 10, 2015 at 04:06:13PM +0100, Samuel Thibault wrote:
> Wei Liu, on Tue 10 Nov 2015 14:59:17 +, wrote:
> > I think I will port this patch to cxenstored at some point. As far as I
> > can tell cxenstored's data / space calculation is bogus in the same way.
> 
> The low-level function return short reads and writes, yes, but that is
> handled at a higher level: initialize_fds sets timeout to 0 when there
> is still room (domain_can_read() or domain_can_write()). So it will
> improve performance a little bit, but not fix actual bugs.
> 

Yeah, that's true. Just IMHO it would be better if we can actually make
low level routine correct. That's orthogonal to what the upper layer is
doing and should prevent latent bug if upper layer logic changes.

Wei.

> Samuel

-- 
Wei.

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

Re: [Xen-devel] [PATCH v2] tools/ocaml/xb: Correct calculations of data/space the ring

[Samuel Thibault]

Wei Liu, on Tue 10 Nov 2015 15:09:33 +, wrote:
> On Tue, Nov 10, 2015 at 04:06:13PM +0100, Samuel Thibault wrote:
> > Wei Liu, on Tue 10 Nov 2015 14:59:17 +, wrote:
> > > I think I will port this patch to cxenstored at some point. As far as I
> > > can tell cxenstored's data / space calculation is bogus in the same way.
> > 
> > The low-level function return short reads and writes, yes, but that is
> > handled at a higher level: initialize_fds sets timeout to 0 when there
> > is still room (domain_can_read() or domain_can_write()). So it will
> > improve performance a little bit, but not fix actual bugs.
> > 
> 
> Yeah, that's true. Just IMHO it would be better if we can actually make
> low level routine correct. That's orthogonal to what the upper layer is
> doing and should prevent latent bug if upper layer logic changes.

Agreed.

Samuel

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

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[Stefano Stabellini]

On Tue, 10 Nov 2015, Arnd Bergmann wrote:
> On Tuesday 10 November 2015 11:57:49 Stefano Stabellini wrote:
> > __current_kernel_time64 returns a struct timespec64, without taking the
> > xtime lock. Mirrors __current_kernel_time/current_kernel_time.
> > 
> 
> Actually it doesn't mirror __current_kernel_time/current_kernel_time
> 
> > diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> > index ec89d84..b5802bf 100644
> > --- a/include/linux/timekeeping.h
> > +++ b/include/linux/timekeeping.h
> > @@ -19,7 +19,8 @@ extern int do_sys_settimeofday(const struct timespec *tv,
> >   */
> >  unsigned long get_seconds(void);
> >  struct timespec64 current_kernel_time64(void);
> > -/* does not take xtime_lock */
> > +/* do not take xtime_lock */
> > +struct timespec64 __current_kernel_time64(void);
> >  struct timespec __current_kernel_time(void);
> 
> Please change __current_kernel_time into a static inline function
> while you are introducing the new one, to match the patch description ;-)

The implementation is:

struct timekeeper *tk = &tk_core.timekeeper;

return timespec64_to_timespec(tk_xtime(tk));

which cannot be easily made into a static inline, unless we start
exporting tk_core.

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

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[John Stultz]

On Tue, Nov 10, 2015 at 7:10 AM, Stefano Stabellini
 wrote:
> On Tue, 10 Nov 2015, Arnd Bergmann wrote:
>> On Tuesday 10 November 2015 11:57:49 Stefano Stabellini wrote:
>> > __current_kernel_time64 returns a struct timespec64, without taking the
>> > xtime lock. Mirrors __current_kernel_time/current_kernel_time.
>> >
>>
>> Actually it doesn't mirror __current_kernel_time/current_kernel_time
>>
>> > diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
>> > index ec89d84..b5802bf 100644
>> > --- a/include/linux/timekeeping.h
>> > +++ b/include/linux/timekeeping.h
>> > @@ -19,7 +19,8 @@ extern int do_sys_settimeofday(const struct timespec *tv,
>> >   */
>> >  unsigned long get_seconds(void);
>> >  struct timespec64 current_kernel_time64(void);
>> > -/* does not take xtime_lock */
>> > +/* do not take xtime_lock */
>> > +struct timespec64 __current_kernel_time64(void);
>> >  struct timespec __current_kernel_time(void);
>>
>> Please change __current_kernel_time into a static inline function
>> while you are introducing the new one, to match the patch description ;-)
>
> The implementation is:
>
> struct timekeeper *tk = &tk_core.timekeeper;
>
> return timespec64_to_timespec(tk_xtime(tk));
>
> which cannot be easily made into a static inline, unless we start
> exporting tk_core.

So the timekeeper is passed to the notifier. So you probably want something like

struct timespec64 __current_kernel_time64(struct timekeeper *tk)
{
 return timespec64_to_timespec(tk_xtime(tk));
}

Then you can cast the priv pointer in the notifier to a timekeeper and
use it that way?

thanks
-john

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

[Xen-devel] [linux-next test] 63942: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot fail blocked in 63747
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot  fail blocked in 63747
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail blocked in 63747
 test-amd64-i386-libvirt   6 xen-boot fail blocked in 63747
 test-amd64-i386-rumpuserxen-i386  6 xen-boot fail blocked in 63747
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 63747
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail blocked in 63747
 test-amd64-i386-libvirt-pair  9 xen-boot/src_hostfail blocked in 63747
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail blocked in 
63747
 test-armhf-armhf-xl-rtds 15 guest-start.2fail blocked in 63747
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail like 63747
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot   fail like 63747
 test-amd64-i386-xl6 xen-boot fail   like 63747
 test-amd64-i386-xl-raw6 xen-boot fail   like 63747
 test-amd64-i386-freebsd10-i386  6 xen-boot fail like 63747
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot   fail like 63747
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot   fail like 63747
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail like 63747
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail like 63747
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot   fail like 63747
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail like 63747
 test-amd64-i386-xl-xsm6 xen-boot fail   like 63747
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail like 63747
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 63747
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-boot fail like 63747
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-boot fail like 63747
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail like 63747
 test-amd64-i386-pair 10 xen-boot/dst_hostfail   like 63747
 test-amd64-i386-pair  9 xen-boot/src_hostfail   like 63747
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail like 63747
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail like 63747
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail like 63747

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

[Xen-devel] [PATCH v2 3/8] libxl: implement virDomainInterfaceStats

[Joao Martins]

Introduce support for domainInterfaceStats API call for querying
network interface statistics. Consequently it also enables the
use of `virsh domifstat  ` command.

After succesful guest creation we fill the network
interfaces names based on domain, device id and append suffix
if it's emulated in the following form: vif.[-emu]. Because
we need the devid from domain config (which is filled by libxl on domain
create)  we cannot do generate the names in console callback. We also
skip this part in case the name of the interface is manually inserted
by adminstrator.

For getting the interface statistics we resort to virNetInterfaceStats
and let libvirt handle the platform specific nits. Note that the latter
is not yet supported in FreeBSD.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Fill .ifname after domain start with generated
 name from libxl  based on domain id and devid returned by libxl.
 After that path validation don interfaceStats is enterily based
 on ifname pretty much like the other drivers.
 - Modify commit message reflecting the changes mentioned in
 the previous item.
 - Bump version to 1.2.22
---
 src/libxl/libxl_domain.c | 15 +++
 src/libxl/libxl_driver.c | 48 
 2 files changed, 63 insertions(+)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 40dcea1..4fbb3fc 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -901,6 +901,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
 virDomainDefPtr def = NULL;
 virObjectEventPtr event = NULL;
 libxlSavefileHeader hdr;
+ssize_t i;
 int ret = -1;
 uint32_t domid = 0;
 char *dom_xml = NULL;
@@ -1023,6 +1024,20 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
  */
 vm->def->id = domid;
 
+for (i = 0; i < vm->def->nnets; i++) {
+virDomainNetDefPtr net = vm->def->nets[i];
+libxl_device_nic *x_nic = &d_config.nics[i];
+const char *suffix =
+x_nic->nictype != LIBXL_NIC_TYPE_VIF ? "-emu" : "";
+
+if (net->ifname)
+continue;
+
+if (virAsprintf(&net->ifname, "vif%d.%d%s",
+domid, x_nic->devid, suffix) < 0)
+continue;
+}
+
 /* Always enable domain death events */
 if (libxl_evenable_domain_death(cfg->ctx, vm->def->id, 0, &priv->deathW))
 goto cleanup_dom;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index f4fc7bc..9a5a74c 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -58,6 +58,7 @@
 #include "virhostdev.h"
 #include "network/bridge_driver.h"
 #include "locking/domain_lock.h"
+#include "virstats.h"
 
 #define VIR_FROM_THIS VIR_FROM_LIBXL
 
@@ -4643,6 +4644,52 @@ libxlDomainIsUpdated(virDomainPtr dom)
 }
 
 static int
+libxlDomainInterfaceStats(virDomainPtr dom,
+  const char *path,
+  virDomainInterfaceStatsPtr stats)
+{
+libxlDriverPrivatePtr driver = dom->conn->privateData;
+virDomainObjPtr vm;
+ssize_t i;
+int ret = -1;
+
+if (!(vm = libxlDomObjFromDomain(dom)))
+goto cleanup;
+
+if (virDomainInterfaceStatsEnsureACL(dom->conn, vm->def) < 0)
+goto cleanup;
+
+if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_QUERY) < 0)
+goto cleanup;
+
+if (!virDomainObjIsActive(vm)) {
+virReportError(VIR_ERR_OPERATION_INVALID,
+   "%s", _("domain is not running"));
+goto endjob;
+}
+
+/* Check the path is one of the domain's network interfaces. */
+for (i = 0; i < vm->def->nnets; i++) {
+if (vm->def->nets[i]->ifname &&
+STREQ(vm->def->nets[i]->ifname, path)) {
+ret = virNetInterfaceStats(path, stats);
+break;
+}
+}
+
+ endjob:
+if (!libxlDomainObjEndJob(driver, vm)) {
+virObjectUnlock(vm);
+vm = NULL;
+}
+
+ cleanup:
+if (vm)
+virObjectUnlock(vm);
+return ret;
+}
+
+static int
 libxlDomainGetTotalCPUStats(libxlDriverPrivatePtr driver,
 virDomainObjPtr vm,
 virTypedParameterPtr params,
@@ -5411,6 +5458,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
 #endif
 .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
 .nodeGetCellsFreeMemory = libxlNodeGetCellsFreeMemory, /* 1.1.1 */
+.domainInterfaceStats = libxlDomainInterfaceStats, /* 1.2.22 */
 .domainMemoryStats = libxlDomainMemoryStats, /* 1.2.22 */
 .domainGetCPUStats = libxlDomainGetCPUStats, /* 1.2.22 */
 .connectDomainEventRegister = libxlConnectDomainEventRegister, /* 0.9.0 */
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/8] libxl: implement virDomainMemorystats

[Joao Martins]

Introduce support for domainMemoryStats API call, which
consequently enables the use of `virsh dommemstat` command to
query for memory statistics of a domain. We support
the following statistics: balloon info, available and currently
in use. swap-in, swap-out, major-faults, minor-faults require
cooperation of the guest and thus currently not supported.

We build on the data returned from libxl_domain_info and deliver
it in the virDomainMemoryStat format.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Cleanup properly after error fetching domain stats
 - Dispose libxl_dominfo after succesfull call to
 libxl_domain_info()
 - Bump version to 1.2.22
---
 src/libxl/libxl_driver.c | 70 
 1 file changed, 70 insertions(+)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 50f6e34..f4fc7bc 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -4749,6 +4749,75 @@ libxlDomainGetCPUStats(virDomainPtr dom,
 return ret;
 }
 
+#define LIBXL_SET_MEMSTAT(TAG, VAL) \
+if (i < nr_stats) { \
+stats[i].tag = TAG; \
+stats[i].val = VAL; \
+i++; \
+}
+
+static int
+libxlDomainMemoryStats(virDomainPtr dom,
+   virDomainMemoryStatPtr stats,
+   unsigned int nr_stats,
+   unsigned int flags)
+{
+libxlDriverPrivatePtr driver = dom->conn->privateData;
+libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
+virDomainObjPtr vm;
+libxl_dominfo d_info;
+unsigned mem, maxmem;
+size_t i = 0;
+int ret = -1;
+
+virCheckFlags(0, -1);
+
+if (!(vm = libxlDomObjFromDomain(dom)))
+goto cleanup;
+
+if (virDomainMemoryStatsEnsureACL(dom->conn, vm->def) < 0)
+goto cleanup;
+
+if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_QUERY) < 0)
+goto cleanup;
+
+if (!virDomainObjIsActive(vm)) {
+virReportError(VIR_ERR_OPERATION_INVALID,
+   "%s", _("domain is not running"));
+goto endjob;
+}
+
+if (libxl_domain_info(cfg->ctx, &d_info, vm->def->id) != 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("libxl_domain_info failed for domain '%d'"),
+   vm->def->id);
+goto endjob;
+}
+mem = d_info.current_memkb;
+maxmem = d_info.max_memkb;
+
+LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON, maxmem - mem);
+LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_AVAILABLE, maxmem);
+LIBXL_SET_MEMSTAT(VIR_DOMAIN_MEMORY_STAT_RSS, mem);
+
+ret = i;
+
+libxl_dominfo_dispose(&d_info);
+
+ endjob:
+if (!libxlDomainObjEndJob(driver, vm)) {
+virObjectUnlock(vm);
+vm = NULL;
+}
+
+ cleanup:
+if (vm)
+virObjectUnlock(vm);
+return ret;
+}
+
+#undef LIBXL_SET_MEMSTAT
+
 static int
 libxlConnectDomainEventRegisterAny(virConnectPtr conn, virDomainPtr dom, int 
eventID,
virConnectDomainEventGenericCallback 
callback,
@@ -5342,6 +5411,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
 #endif
 .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
 .nodeGetCellsFreeMemory = libxlNodeGetCellsFreeMemory, /* 1.1.1 */
+.domainMemoryStats = libxlDomainMemoryStats, /* 1.2.22 */
 .domainGetCPUStats = libxlDomainGetCPUStats, /* 1.2.22 */
 .connectDomainEventRegister = libxlConnectDomainEventRegister, /* 0.9.0 */
 .connectDomainEventDeregister = libxlConnectDomainEventDeregister, /* 
0.9.0 */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[Thomas Gleixner]

On Tue, 10 Nov 2015, John Stultz wrote:
> On Tue, Nov 10, 2015 at 7:10 AM, Stefano Stabellini
>  wrote:
> > On Tue, 10 Nov 2015, Arnd Bergmann wrote:
> >> On Tuesday 10 November 2015 11:57:49 Stefano Stabellini wrote:
> >> > __current_kernel_time64 returns a struct timespec64, without taking the
> >> > xtime lock. Mirrors __current_kernel_time/current_kernel_time.
> >> >
> >>
> >> Actually it doesn't mirror __current_kernel_time/current_kernel_time
> >>
> >> > diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> >> > index ec89d84..b5802bf 100644
> >> > --- a/include/linux/timekeeping.h
> >> > +++ b/include/linux/timekeeping.h
> >> > @@ -19,7 +19,8 @@ extern int do_sys_settimeofday(const struct timespec 
> >> > *tv,
> >> >   */
> >> >  unsigned long get_seconds(void);
> >> >  struct timespec64 current_kernel_time64(void);
> >> > -/* does not take xtime_lock */
> >> > +/* do not take xtime_lock */
> >> > +struct timespec64 __current_kernel_time64(void);
> >> >  struct timespec __current_kernel_time(void);
> >>
> >> Please change __current_kernel_time into a static inline function
> >> while you are introducing the new one, to match the patch description ;-)
> >
> > The implementation is:
> >
> > struct timekeeper *tk = &tk_core.timekeeper;
> >
> > return timespec64_to_timespec(tk_xtime(tk));
> >
> > which cannot be easily made into a static inline, unless we start
> > exporting tk_core.
> 
> So the timekeeper is passed to the notifier. So you probably want something 
> like
> 
> struct timespec64 __current_kernel_time64(struct timekeeper *tk)
> {
>  return timespec64_to_timespec(tk_xtime(tk));
> }
> 
> Then you can cast the priv pointer in the notifier to a timekeeper and
> use it that way?

Err no. Look at commit 8758a240e2d74c5932ab51a73377e6507b7fd441

i.e. Add the new 64bit function and make the existing one a static
inline which does the timespec64 to timespec conversion.

Thanks,

tglx

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

[Xen-devel] [PATCH v2] libxl: add p2p migration

[Joao Martins]

Introduce support for VIR_MIGRATE_PEER2PEER in libxl driver
for supporting migration in Openstack. Most of the changes
occur at the source and no modifications at the receiver.

In P2P mode there is only the Perform phase so we must handle
the connection with the destination and actually perform the
migration. libxlDomainPerformP2P implements the connection to
the destination and let libxlDoMigrateP2P implements the actual
migration logic with virConnectPtr. In this function we do
the migration steps in the destination similar to
virDomainMigrateVersion3Full. We appropriately save the last
error reported in each of the phases to provide proper
reporting. We don't yet support VIR_MIGRATE_TUNNELED and
we always use V3 with extensible params, making the
implementation simpler.

It is worth noting that the receiver didn't have any changes,
and because it's still the v3 sequence thus it is possible to
migrate from a P2P to non-P2P host.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Move Begin step to libxlDoMigrateP2P to have all 4 steps
 together.
 - Remove if before VIR_FREE(dom_xml)
---
 src/libxl/libxl_driver.c|  13 ++-
 src/libxl/libxl_migration.c | 220 
 src/libxl/libxl_migration.h |  11 +++
 3 files changed, 241 insertions(+), 3 deletions(-)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index fcdcbdb..da98265 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -4713,6 +4713,7 @@ libxlConnectSupportsFeature(virConnectPtr conn, int 
feature)
 switch (feature) {
 case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
 case VIR_DRV_FEATURE_MIGRATION_PARAMS:
+case VIR_DRV_FEATURE_MIGRATION_P2P:
 return 1;
 default:
 return 0;
@@ -5039,9 +5040,15 @@ libxlDomainMigratePerform3Params(virDomainPtr dom,
 if (virDomainMigratePerform3ParamsEnsureACL(dom->conn, vm->def) < 0)
 goto cleanup;
 
-if (libxlDomainMigrationPerform(driver, vm, dom_xml, dconnuri,
-uri, dname, flags) < 0)
-goto cleanup;
+if (flags & VIR_MIGRATE_PEER2PEER) {
+if (libxlDomainMigrationPerformP2P(driver, vm, dom->conn, dom_xml,
+   dconnuri, uri, dname, flags) < 0)
+goto cleanup;
+} else {
+if (libxlDomainMigrationPerform(driver, vm, dom_xml, dconnuri,
+uri, dname, flags) < 0)
+goto cleanup;
+}
 
 ret = 0;
 
diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 0d23e5f..a1c7b55 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -42,6 +42,7 @@
 #include "libxl_conf.h"
 #include "libxl_migration.h"
 #include "locking/domain_lock.h"
+#include "virtypedparam.h"
 
 #define VIR_FROM_THIS VIR_FROM_LIBXL
 
@@ -456,6 +457,225 @@ libxlDomainMigrationPrepare(virConnectPtr dconn,
 return ret;
 }
 
+/* This function is a simplification of virDomainMigrateVersion3Full
+ * excluding tunnel support and restricting it to migration v3
+ * with params since it was the first to be introduced in libxl.
+ */
+static int
+libxlDoMigrateP2P(libxlDriverPrivatePtr driver,
+  virDomainObjPtr vm,
+  virConnectPtr sconn,
+  const char *xmlin,
+  virConnectPtr dconn,
+  const char *dconnuri ATTRIBUTE_UNUSED,
+  const char *dname,
+  const char *uri,
+  unsigned int flags)
+{
+virDomainPtr ddomain = NULL;
+virTypedParameterPtr params = NULL;
+int nparams = 0;
+int maxparams = 0;
+char *uri_out = NULL;
+char *dom_xml = NULL;
+unsigned long destflags;
+bool cancelled = true;
+virErrorPtr orig_err = NULL;
+int ret = -1;
+
+dom_xml = libxlDomainMigrationBegin(sconn, vm, xmlin);
+if (!dom_xml)
+goto cleanup;
+
+if (virTypedParamsAddString(¶ms, &nparams, &maxparams,
+VIR_MIGRATE_PARAM_DEST_XML, dom_xml) < 0)
+goto cleanup;
+
+if (dname &&
+virTypedParamsAddString(¶ms, &nparams, &maxparams,
+VIR_MIGRATE_PARAM_DEST_NAME, dname) < 0)
+goto cleanup;
+
+if (uri &&
+virTypedParamsAddString(¶ms, &nparams, &maxparams,
+VIR_MIGRATE_PARAM_URI, uri) < 0)
+goto cleanup;
+
+/* We don't require the destination to have P2P support
+ * as it looks to be normal migration from the receiver perpective.
+ */
+destflags = flags & ~(VIR_MIGRATE_PEER2PEER);
+
+VIR_DEBUG("Prepare3");
+virObjectUnlock(vm);
+ret = dconn->driver->domainMigratePrepare3Params
+(dconn, params, nparams, NULL, 0, NULL, NULL, &uri_out, destflags);
+virObjectLock(vm);
+
+if (ret == -1)
+goto cleanup;
+
+if (uri_out) {
+if (virTypedParamsReplaceString(¶ms, &nparams,
+ 

[Xen-devel] [PATCH v2 8/8] libxl: implement virDomainGetJobStats

[Joao Martins]

Introduces support for domainGetJobStats which has the same
info as domainGetJobInfo but in a slightly different format.
Another difference is that virDomainGetJobStats can also
retrieve info on the most recently completed job. Though so
far this is only used in the source node to know if the
migration has been completed. But because we don't support
completed jobs we will deliver an error.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Fixed indentation on libxlDomainGetJobStats()
 - s/estimed/estimated/g
 - Bump version to 1.2.22
---
 src/libxl/libxl_driver.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index b0b6ea7..dda14c2 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5273,6 +5273,58 @@ libxlDomainGetJobInfo(virDomainPtr dom,
 return ret;
 }
 
+static int
+libxlDomainGetJobStats(virDomainPtr dom,
+   int *type,
+   virTypedParameterPtr *params,
+   int *nparams,
+   unsigned int flags)
+{
+libxlDomainObjPrivatePtr priv;
+virDomainObjPtr vm;
+virDomainJobInfoPtr jobInfo;
+int ret = -1;
+int maxparams = 0;
+
+/* VIR_DOMAIN_JOB_STATS_COMPLETED not supported yet */
+virCheckFlags(0, -1);
+
+if (!(vm = libxlDomObjFromDomain(dom)))
+goto cleanup;
+
+if (virDomainGetJobStatsEnsureACL(dom->conn, vm->def) < 0)
+goto cleanup;
+
+priv = vm->privateData;
+jobInfo = priv->job.current;
+if (!priv->job.active) {
+*type = VIR_DOMAIN_JOB_NONE;
+*params = NULL;
+*nparams = 0;
+ret = 0;
+goto cleanup;
+}
+
+/* In libxl we don't have an estimated completion time
+ * thus we always set to unbounded and update time
+ * for the active job. */
+if (libxlDomainJobUpdateTime(&priv->job) < 0)
+goto cleanup;
+
+if (virTypedParamsAddULLong(params, nparams, &maxparams,
+VIR_DOMAIN_JOB_TIME_ELAPSED,
+jobInfo->timeElapsed) < 0)
+goto cleanup;
+
+*type = jobInfo->type;
+ret = 0;
+
+ cleanup:
+if (vm)
+virObjectUnlock(vm);
+return ret;
+}
+
 #undef LIBXL_SET_MEMSTAT
 
 #define LIBXL_RECORD_UINT(error, key, value, ...) \
@@ -6134,6 +6186,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
 .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
 .nodeGetCellsFreeMemory = libxlNodeGetCellsFreeMemory, /* 1.1.1 */
 .domainGetJobInfo = libxlDomainGetJobInfo, /* 1.2.22 */
+.domainGetJobStats = libxlDomainGetJobStats, /* 1.2.22 */
 .domainBlockStats = libxlDomainBlockStats, /* 1.2.22 */
 .domainBlockStatsFlags = libxlDomainBlockStatsFlags, /* 1.2.22 */
 .domainInterfaceStats = libxlDomainInterfaceStats, /* 1.2.22 */
-- 
2.1.4


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

[Xen-devel] [PATCH v2 1/8] libxl: implement virDomainGetCPUStats

[Joao Martins]

Introduce support for domainGetCPUStats API call and consequently
allow us to use `virsh cpu-stats`. The latter returns a more brief
output than the one provided by`virsh vcpuinfo`.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Remove libxl_vcpuinfo_dispose() in favor or using
 libxl_vcpuinfo_list_free(), and also removing VIR_FREE call
 - Dispose libxl_dominfo after succesfull call to
 libxl_domain_info()
 - Fixed identation of parameters
 - Bump version to 1.2.22
---
 src/libxl/libxl_driver.c | 110 +++
 1 file changed, 110 insertions(+)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index fcdcbdb..50f6e34 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -73,6 +73,8 @@ VIR_LOG_INIT("libxl.libxl_driver");
 #define LIBXL_CONFIG_FORMAT_XM "xen-xm"
 #define LIBXL_CONFIG_FORMAT_SEXPR "xen-sxpr"
 
+#define LIBXL_NB_TOTAL_CPU_STAT_PARAM 1
+
 #define HYPERVISOR_CAPABILITIES "/proc/xen/capabilities"
 #define HYPERVISOR_XENSTORED "/dev/xen/xenstored"
 
@@ -4641,6 +4643,113 @@ libxlDomainIsUpdated(virDomainPtr dom)
 }
 
 static int
+libxlDomainGetTotalCPUStats(libxlDriverPrivatePtr driver,
+virDomainObjPtr vm,
+virTypedParameterPtr params,
+unsigned int nparams)
+{
+libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
+libxl_dominfo d_info;
+int ret = -1;
+
+if (nparams == 0)
+return LIBXL_NB_TOTAL_CPU_STAT_PARAM;
+
+if (libxl_domain_info(cfg->ctx, &d_info, vm->def->id) != 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("libxl_domain_info failed for domain '%d'"),
+   vm->def->id);
+return ret;
+}
+
+if (virTypedParameterAssign(¶ms[0], VIR_DOMAIN_CPU_STATS_CPUTIME,
+VIR_TYPED_PARAM_ULLONG, d_info.cpu_time) < 0)
+nparams = ret;
+
+libxl_dominfo_dispose(&d_info);
+return nparams;
+}
+
+static int
+libxlDomainGetPerCPUStats(libxlDriverPrivatePtr driver,
+  virDomainObjPtr vm,
+  virTypedParameterPtr params,
+  unsigned int nparams,
+  int start_cpu,
+  unsigned int ncpus)
+{
+libxl_vcpuinfo *vcpuinfo;
+int maxcpu, hostcpus;
+size_t i;
+libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
+int ret = -1;
+
+if (nparams == 0 && ncpus != 0)
+return LIBXL_NB_TOTAL_CPU_STAT_PARAM;
+else if (nparams == 0)
+return vm->def->maxvcpus;
+
+if ((vcpuinfo = libxl_list_vcpu(cfg->ctx, vm->def->id, &maxcpu,
+&hostcpus)) == NULL) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   _("Failed to list vcpus for domain '%d' with 
libxenlight"),
+   vm->def->id);
+return ret;
+}
+
+for (i = start_cpu; i < maxcpu && i < ncpus; ++i) {
+if (virTypedParameterAssign(¶ms[(i-start_cpu)],
+VIR_DOMAIN_CPU_STATS_CPUTIME,
+VIR_TYPED_PARAM_ULLONG,
+vcpuinfo[i].vcpu_time) < 0)
+goto cleanup;
+}
+ret = nparams;
+
+ cleanup:
+libxl_vcpuinfo_list_free(vcpuinfo, maxcpu);
+return ret;
+}
+
+static int
+libxlDomainGetCPUStats(virDomainPtr dom,
+   virTypedParameterPtr params,
+   unsigned int nparams,
+   int start_cpu,
+   unsigned int ncpus,
+   unsigned int flags)
+{
+libxlDriverPrivatePtr driver = dom->conn->privateData;
+virDomainObjPtr vm = NULL;
+int ret = -1;
+
+virCheckFlags(VIR_TYPED_PARAM_STRING_OKAY, -1);
+
+if (!(vm = libxlDomObjFromDomain(dom)))
+goto cleanup;
+
+if (virDomainGetCPUStatsEnsureACL(dom->conn, vm->def) < 0)
+goto cleanup;
+
+if (!virDomainObjIsActive(vm)) {
+virReportError(VIR_ERR_OPERATION_INVALID,
+   "%s", _("domain is not running"));
+goto cleanup;
+}
+
+if (start_cpu == -1)
+ret = libxlDomainGetTotalCPUStats(driver, vm, params, nparams);
+else
+ret = libxlDomainGetPerCPUStats(driver, vm, params, nparams,
+  start_cpu, ncpus);
+
+ cleanup:
+if (vm)
+virObjectUnlock(vm);
+return ret;
+}
+
+static int
 libxlConnectDomainEventRegisterAny(virConnectPtr conn, virDomainPtr dom, int 
eventID,
virConnectDomainEventGenericCallback 
callback,
void *opaque, virFreeCallback freecb)
@@ -5233,6 +5342,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
 #endif
 .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
 .nodeGetCellsFreeMemory = libxlNodeGetCellsFreeMemory, /* 1.1

[Xen-devel] [PATCH v2 7/8] libxl: implement virDomainGetJobInfo

[Joao Martins]

Introduce support for domainGetJobInfo to get info about the
ongoing job. If the job is active it will update the
timeElapsed which is computed with the "started" field added to
struct libxlDomainJobObj.  For now we support just the very basic
info and all jobs have VIR_DOMAIN_JOB_UNBOUNDED (i.e. no completion
time estimation) plus timeElapsed computed.

Openstack Kilo uses the Job API to monitor live-migration
progress which is currently nonexistent in libxl driver and
therefore leads to a crash in the nova compute node. Right
now, migration doesn't use jobs in the source node and will
return VIR_DOMAIN_JOB_NONE. Though nova handles this case and
will migrate it properly instead of crashing.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - s/inexistent/nonexistent/g in commit message
 - s/estimed/estimated/g
 - Bump version to 1.2.22
---
 src/libxl/libxl_domain.c | 28 
 src/libxl/libxl_domain.h |  6 ++
 src/libxl/libxl_driver.c | 38 ++
 3 files changed, 72 insertions(+)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 4fbb3fc..0411e9b 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -74,6 +74,10 @@ libxlDomainObjInitJob(libxlDomainObjPrivatePtr priv)
 if (virCondInit(&priv->job.cond) < 0)
 return -1;
 
+if (VIR_ALLOC(priv->job.current) < 0)
+return -1;
+
+memset(priv->job.current, 0, sizeof(*(priv->job.current)));
 return 0;
 }
 
@@ -90,6 +94,7 @@ static void
 libxlDomainObjFreeJob(libxlDomainObjPrivatePtr priv)
 {
 ignore_value(virCondDestroy(&priv->job.cond));
+VIR_FREE(priv->job.current);
 }
 
 /* Give up waiting for mutex after 30 seconds */
@@ -131,6 +136,8 @@ libxlDomainObjBeginJob(libxlDriverPrivatePtr driver 
ATTRIBUTE_UNUSED,
 VIR_DEBUG("Starting job: %s", libxlDomainJobTypeToString(job));
 priv->job.active = job;
 priv->job.owner = virThreadSelfID();
+priv->job.started = now;
+priv->job.current->type = VIR_DOMAIN_JOB_UNBOUNDED;
 
 return 0;
 
@@ -179,6 +186,27 @@ libxlDomainObjEndJob(libxlDriverPrivatePtr driver 
ATTRIBUTE_UNUSED,
 return virObjectUnref(obj);
 }
 
+int
+libxlDomainJobUpdateTime(struct libxlDomainJobObj *job)
+{
+virDomainJobInfoPtr jobInfo = job->current;
+unsigned long long now;
+
+if (!job->started)
+return 0;
+
+if (virTimeMillisNow(&now) < 0)
+return -1;
+
+if (now < job->started) {
+job->started = 0;
+return 0;
+}
+
+jobInfo->timeElapsed = now - job->started;
+return 0;
+}
+
 static void *
 libxlDomainObjPrivateAlloc(void)
 {
diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
index 44b3e0b..1c1eba3 100644
--- a/src/libxl/libxl_domain.h
+++ b/src/libxl/libxl_domain.h
@@ -53,6 +53,8 @@ struct libxlDomainJobObj {
 virCond cond;   /* Use to coordinate jobs */
 enum libxlDomainJob active; /* Currently running job */
 int owner;  /* Thread which set current job */
+unsigned long long started; /* When the job started */
+virDomainJobInfoPtr current;/* Statistics for the current job */
 };
 
 typedef struct _libxlDomainObjPrivate libxlDomainObjPrivate;
@@ -88,6 +90,10 @@ libxlDomainObjEndJob(libxlDriverPrivatePtr driver,
  virDomainObjPtr obj)
 ATTRIBUTE_RETURN_CHECK;
 
+int
+libxlDomainJobUpdateTime(struct libxlDomainJobObj *job)
+ATTRIBUTE_RETURN_CHECK;
+
 void
 libxlDomainEventQueue(libxlDriverPrivatePtr driver,
   virObjectEventPtr event);
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 8db6536..b0b6ea7 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5236,6 +5236,43 @@ libxlDomainMemoryStats(virDomainPtr dom,
 return ret;
 }
 
+static int
+libxlDomainGetJobInfo(virDomainPtr dom,
+  virDomainJobInfoPtr info)
+{
+libxlDomainObjPrivatePtr priv;
+virDomainObjPtr vm;
+int ret = -1;
+
+if (!(vm = libxlDomObjFromDomain(dom)))
+goto cleanup;
+
+if (virDomainGetJobInfoEnsureACL(dom->conn, vm->def) < 0)
+goto cleanup;
+
+priv = vm->privateData;
+if (!priv->job.active) {
+memset(info, 0, sizeof(*info));
+info->type = VIR_DOMAIN_JOB_NONE;
+ret = 0;
+goto cleanup;
+}
+
+/* In libxl we don't have an estimated completion time
+ * thus we always set to unbounded and update time
+ * for the active job. */
+if (libxlDomainJobUpdateTime(&priv->job) < 0)
+goto cleanup;
+
+memcpy(info, priv->job.current, sizeof(virDomainJobInfo));
+ret = 0;
+
+ cleanup:
+if (vm)
+virObjectUnlock(vm);
+return ret;
+}
+
 #undef LIBXL_SET_MEMSTAT
 
 #define LIBXL_RECORD_UINT(error, key, value, ...) \
@@ -6096,6 +6133,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
 #endif
 .nodeGetFreeMemory = libxlNodeGetFreeMemo

[Xen-devel] [PATCH v2 5/8] libxl: implement virDomainBlockStats

[Joao Martins]

Introduce initial support for domainBlockStats API call that
allow us to query block device statistics. openstack nova
uses this API call to query block statistics, alongside
virDomainMemoryStats and virDomainInterfaceStats.  Note that
this patch only introduces it for VBD for starters. QDisk
will come in a separate patch series.

A new statistics data structure is introduced to fit common
statistics among others specific to the underlying block
backends. For the VBD statistics on linux these are exported
via sysfs on the path:

"/sys/bus/xen-backend/devices/vbd--/statistics"

To calculate the block devno libxlDiskPathToID is introduced.
Each backend implements its own function to extract statistics
and let there be handled the different platforms. An alternative
would be to reuse libvirt xen driver function.

VBD stats are exposed in reqs and number of sectors from
blkback, and it's up to us to convert it to sector sizes.
The sector size is gathered through xenstore in the device
backend entry "physical-sector-size". This adds up an extra
dependency namely of xenstore for doing the xs_read.

BlockStatsFlags variant is also implemented which has the
added benefit of getting the number of flush requests.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Fix identation issues
 - Set ret to LIBXL_VBD_SECTOR_SIZE
 - Reuse VIR_STRDUP error instead of doing virReportError
 when we fail to set stats->backend
 - Change virAsprintf(...) error checking
 - Change error to VIR_ERR_OPERATION_FAILED when xenstore path
 does not exist and when failing to read stat.
 - Resolve issues with 'make syntax-check' with cppi installed.
 - Remove libxlDiskPathMatches in favor of using virutil
 virDiskNameParse to fetch disk and partition index.
 - Rename libxlDiskPathParse to libxlDiskPathToID and rework
 function to just convert disk and partition index to devno.
 - Bump version to 1.2.22
---
 configure.ac |   2 +-
 src/libxl/libxl_driver.c | 375 +++
 2 files changed, 376 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index f481c50..10c56e5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -896,7 +896,7 @@ if test "$with_libxl" != "no" ; then
 LIBS="$LIBS $LIBXL_LIBS"
 AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [
 with_libxl=yes
-LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl"
+LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl -lxenstore"
 ],[
 if test "$with_libxl" = "yes"; then
 fail=1
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 9a5a74c..ba1d67b 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -59,6 +59,7 @@
 #include "network/bridge_driver.h"
 #include "locking/domain_lock.h"
 #include "virstats.h"
+#include 
 
 #define VIR_FROM_THIS VIR_FROM_LIBXL
 
@@ -75,6 +76,7 @@ VIR_LOG_INIT("libxl.libxl_driver");
 #define LIBXL_CONFIG_FORMAT_SEXPR "xen-sxpr"
 
 #define LIBXL_NB_TOTAL_CPU_STAT_PARAM 1
+#define LIBXL_NB_TOTAL_BLK_STAT_PARAM 6
 
 #define HYPERVISOR_CAPABILITIES "/proc/xen/capabilities"
 #define HYPERVISOR_XENSTORED "/dev/xen/xenstored"
@@ -103,6 +105,25 @@ struct _libxlOSEventHookInfo {
 int id;
 };
 
+/* Object used to store disk statistics across multiple xen backends */
+typedef struct _libxlBlockStats libxlBlockStats;
+typedef libxlBlockStats *libxlBlockStatsPtr;
+struct _libxlBlockStats {
+long long rd_req;
+long long rd_bytes;
+long long wr_req;
+long long wr_bytes;
+long long f_req;
+
+char *backend;
+union {
+struct {
+long long ds_req;
+long long oo_req;
+} vbd;
+} u;
+};
+
 /* Function declarations */
 static int
 libxlDomainManagedSaveLoad(virDomainObjPtr vm,
@@ -4644,6 +4665,358 @@ libxlDomainIsUpdated(virDomainPtr dom)
 }
 
 static int
+libxlDiskPathToID(const char *virtpath)
+{
+static char const* drive_prefix[] = {"xvd", "hd", "sd"};
+int disk, partition, chrused;
+int fmt, id;
+char *r;
+size_t i;
+
+fmt = id = -1;
+
+/* Find any disk prefixes we know about */
+for (i = 0; i < ARRAY_CARDINALITY(drive_prefix); i++) {
+if (STRPREFIX(virtpath, drive_prefix[i]) &&
+!virDiskNameParse(virtpath, &disk, &partition)) {
+fmt = i;
+break;
+}
+}
+
+/* Handle it same way as xvd */
+if (fmt < 0 &&
+(sscanf(virtpath, "d%ip%i%n", &disk, &partition, &chrused) >= 2
+ && chrused == strlen(virtpath)))
+fmt = 0;
+
+/* Test indexes ranges and calculate the device id */
+switch (fmt) {
+case 0: /* xvd */
+if (disk <= 15 && partition <= 15)
+id = (202 << 8) | (disk << 4) | partition;
+else if ((disk <= ((1<<20)-1)) || partition <= 255)
+id = (1 << 28) | (disk << 8) | partition;
+break;
+case 1: /* hd */
+if (disk <= 3 && partition <= 63)
+id = 

[Xen-devel] [PATCH v2 6/8] libxl: implement virConnectGetAllDomainStats

[Joao Martins]

Introduce support for connectGetAllDomainStats call that
allow us to _all_ domain(s) statistics including network, block,
cpus and memory. Changes are rather mechanical and mostly
take care of the format to export the data.

Signed-off-by: Joao Martins 
---
Changes since v1:
 - Rework flags checking on libxlDomainGetStats
 for VIR_DOMAIN_STATS_{VCPU,INTERFACE,BLOCK}
 - Removed path since we are reusing .ifname
 - Init dominfo and dispose it on cleanup.
 - Fixed VIR_FREE issue that was reported with make syntax-check"
 - Bump version to 1.2.22
---
 src/libxl/libxl_driver.c | 266 +++
 1 file changed, 266 insertions(+)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index ba1d67b..8db6536 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5238,6 +5238,271 @@ libxlDomainMemoryStats(virDomainPtr dom,
 
 #undef LIBXL_SET_MEMSTAT
 
+#define LIBXL_RECORD_UINT(error, key, value, ...) \
+do { \
+char param_name[VIR_TYPED_PARAM_FIELD_LENGTH]; \
+snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, \
+ key, ##__VA_ARGS__); \
+if (virTypedParamsAddUInt(&tmp->params, \
+  &tmp->nparams, \
+  &maxparams, \
+  param_name, \
+  value) < 0) \
+goto error;   \
+} while (0)
+
+#define LIBXL_RECORD_LL(error, key, value, ...) \
+do { \
+char param_name[VIR_TYPED_PARAM_FIELD_LENGTH]; \
+snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, \
+ key, ##__VA_ARGS__); \
+if (virTypedParamsAddLLong(&tmp->params, \
+   &tmp->nparams, \
+   &maxparams, \
+   param_name, \
+   value) < 0) \
+goto error; \
+} while (0)
+
+#define LIBXL_RECORD_ULL(error, key, value, ...) \
+do { \
+char param_name[VIR_TYPED_PARAM_FIELD_LENGTH]; \
+snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, \
+ key, ##__VA_ARGS__); \
+if (virTypedParamsAddULLong(&tmp->params, \
+&tmp->nparams, \
+&maxparams, \
+param_name, \
+value) < 0) \
+goto error; \
+} while (0)
+
+#define LIBXL_RECORD_STR(error, key, value, ...) \
+do { \
+char param_name[VIR_TYPED_PARAM_FIELD_LENGTH]; \
+snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, \
+ key, ##__VA_ARGS__); \
+if (virTypedParamsAddString(&tmp->params, \
+&tmp->nparams, \
+&maxparams, \
+param_name, \
+value) < 0) \
+goto error; \
+} while (0)
+
+static int
+libxlDomainGetStats(virConnectPtr conn,
+virDomainObjPtr dom,
+unsigned int stats,
+virDomainStatsRecordPtr *record)
+{
+libxlDriverPrivatePtr driver = conn->privateData;
+libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
+virDomainStatsRecordPtr tmp;
+libxl_dominfo d_info;
+libxl_vcpuinfo *vcpuinfo = NULL;
+int maxcpu, hostcpus;
+unsigned long long mem, maxmem;
+int maxparams = 0;
+int ret = -1;
+size_t i, state;
+unsigned int domflags = stats & (VIR_DOMAIN_STATS_BALLOON |
+ VIR_DOMAIN_STATS_CPU_TOTAL);
+
+if (VIR_ALLOC(tmp) < 0)
+return ret;
+
+libxl_dominfo_init(&d_info);
+
+mem = virDomainDefGetMemoryInitial(dom->def);
+maxmem = virDomainDefGetMemoryActual(dom->def);
+d_info.cpu_time = 0;
+
+if (domflags && virDomainObjIsActive(dom) &&
+!libxl_domain_info(cfg->ctx, &d_info, dom->def->id)) {
+mem = d_info.current_memkb;
+maxmem = d_info.max_memkb;
+}
+
+if (stats & VIR_DOMAIN_STATS_STATE) {
+LIBXL_RECORD_UINT(cleanup, "state.reason", dom->state.reason);
+LIBXL_RECORD_UINT(cleanup, "state.state", dom->state.state);
+}
+
+if (stats & VIR_DOMAIN_STATS_BALLOON) {
+LIBXL_RECORD_ULL(cleanup, "balloon.current", mem);
+LIBXL_RECORD_ULL(cleanup, "balloon.maximum", maxmem);
+}
+
+if (stats & VIR_DOMAIN_STATS_CPU_TOTAL)
+LIBXL_RECORD_ULL(cleanup, "cpu.time", d_info.cpu_time);
+
+if (stats & VIR_DOMAIN_STATS_VCPU) {
+vcpuinfo = libxl_list_vcpu(cfg->ctx, dom->def->id, &maxcpu, &hostcpus);
+
+for (i = 0; i < dom->def->vcpus; i++) {
+if (!vcpuinfo)
+state = VIR_VCPU_OFFLINE;
+else if (vcpuinfo[i].running)
+state = VIR_VCPU_RUNNING;
+else if (vcpuinfo[i].blocked)
+state = VIR_VCPU_BLOCKED;
+else
+state = VIR_VCPU_OFFLINE;
+

[Xen-devel] [PATCH v2 0/8] libxl: domain statistics support

[Joao Martins]

Hey,

This series bring support for various statistics about domains
regarding CPU, Memory, Network Interfaces, Block and Jobs. Not all of
the statistics are implemented: qdisk support is missing in this series
and some of the memory statistics aren't available.

With this series we further implement 7 more functions of libvirt APIs.
It is organized as follows:

 * Patch 1, 2: implements cpu/memory statistics.
 * Patch 3: implements network statistics
 * Patch 4: adds helper method virDiskNameParse as an extension
to virDiskNameToIndex (New)
 * Patch 5: VBD block statistics. QDisk will follow up in a separate
series regarding QEMU monitor integration.
 * Patch 6: implement fetching all domain statistics
 * Patch 7, 8: implements Job information statistics.

Overall it looks big but 70% of the patch is due to #5 and #6 but doesn't
add necessarily more complexity to the driver I believe. Patch #7 and #8
are of special importance because GetJobInfo and GetJobStats are now used
in Openstack Kilo to monitor live-migration progress. These two patches
together with the p2p migration I sent earlier let us sucessfully
live-migrate with Openstack Kilo. Furthermore with this series we get to
support nova diagnostics.

Tested this series on 4.4.3 and 4.5 setups plus Openstack Kilo.

Individual patches contain the changelog and comments addressed since v1.

Thanks!

Joao Martins (8):
  libxl: implement virDomainGetCPUStats
  libxl: implement virDomainMemorystats
  libxl: implement virDomainInterfaceStats
  util: add virDiskNameParse to handle disk and partition idx
  libxl: implement virDomainBlockStats
  libxl: implement virConnectGetAllDomainStats
  libxl: implement virDomainGetJobInfo
  libxl: implement virDomainGetJobStats

 configure.ac |   2 +-
 src/libvirt_private.syms |   1 +
 src/libxl/libxl_domain.c |  43 +++
 src/libxl/libxl_domain.h |   6 +
 src/libxl/libxl_driver.c | 960 +++
 src/util/virutil.c   |  41 +-
 src/util/virutil.h   |   1 +
 tests/utiltest.c |  56 +++
 8 files changed, 1105 insertions(+), 5 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/8] util: add virDiskNameParse to handle disk and partition idx

[Joao Martins]

Introduce a new helper function "virDiskNameParse" which extends
virDiskNameToIndex but handling both disk index and partition index.
Also rework virDiskNameToIndex to be based on virDiskNameParse.
A test is also added for this function testing both valid and
invalid disk names.

Signed-off-by: Joao Martins 
---
 src/libvirt_private.syms |  1 +
 src/util/virutil.c   | 41 +++
 src/util/virutil.h   |  1 +
 tests/utiltest.c | 56 
 4 files changed, 95 insertions(+), 4 deletions(-)

diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index a835f18..6913d7c 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -149,6 +149,7 @@ virDomainCapsNew;
 # conf/domain_conf.h
 virBlkioDeviceArrayClear;
 virDiskNameToBusDeviceIndex;
+virDiskNameParse;
 virDiskNameToIndex;
 virDomainActualNetDefFree;
 virDomainBlockedReasonTypeFromString;
diff --git a/src/util/virutil.c b/src/util/virutil.c
index cddc78a..76591be 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -537,14 +537,17 @@ const char *virEnumToString(const char *const*types,
 }
 
 /* Translates a device name of the form (regex) /^[fhv]d[a-z]+[0-9]*$/
- * into the corresponding index (e.g. sda => 0, hdz => 25, vdaa => 26)
- * Note that any trailing string of digits is simply ignored.
+ * into the corresponding index and partition number
+ * (e.g. sda0 => (0,0), hdz2 => (25,2), vdaa12 => (26,12))
  * @param name The name of the device
- * @return name's index, or -1 on failure
+ * @param disk The disk index to be returned
+ * @param partition The partition index to be returned
+ * @return 0 on success, or -1 on failure
  */
-int virDiskNameToIndex(const char *name)
+int virDiskNameParse(const char *name, int *disk, int *partition)
 {
 const char *ptr = NULL;
+char *rem;
 int idx = 0;
 static char const* const drive_prefix[] = {"fd", "hd", "vd", "sd", "xvd", 
"ubd"};
 size_t i;
@@ -573,6 +576,36 @@ int virDiskNameToIndex(const char *name)
 if (ptr[n_digits] != '\0')
 return -1;
 
+*disk = idx;
+
+/* Convert trailing digits into our partition index */
+if (partition) {
+*partition = 0;
+
+/* Shouldn't start by zero */
+if (n_digits > 1 && *ptr == '0')
+return -1;
+
+if (n_digits && virStrToLong_i(ptr, &rem, 10, partition) < 0)
+return -1;
+}
+
+return 0;
+}
+
+/* Translates a device name of the form (regex) /^[fhv]d[a-z]+[0-9]*$/
+ * into the corresponding index (e.g. sda => 0, hdz => 25, vdaa => 26)
+ * Note that any trailing string of digits is simply ignored.
+ * @param name The name of the device
+ * @return name's index, or -1 on failure
+ */
+int virDiskNameToIndex(const char *name)
+{
+int idx;
+
+if (virDiskNameParse(name, &idx, NULL))
+idx = -1;
+
 return idx;
 }
 
diff --git a/src/util/virutil.h b/src/util/virutil.h
index 53025f7..02387e0 100644
--- a/src/util/virutil.h
+++ b/src/util/virutil.h
@@ -67,6 +67,7 @@ int virDoubleToStr(char **strp, double number)
 char *virFormatIntDecimal(char *buf, size_t buflen, int val)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_RETURN_CHECK;
 
+int virDiskNameParse(const char *name, int *disk, int *partition);
 int virDiskNameToIndex(const char* str);
 char *virIndexToDiskName(int idx, const char *prefix);
 
diff --git a/tests/utiltest.c b/tests/utiltest.c
index 98c689d..a8f9060 100644
--- a/tests/utiltest.c
+++ b/tests/utiltest.c
@@ -23,6 +23,23 @@ static const char* diskNames[] = {
 "sdia", "sdib", "sdic", "sdid", "sdie", "sdif", "sdig", "sdih", "sdii", 
"sdij", "sdik", "sdil", "sdim", "sdin", "sdio", "sdip", "sdiq", "sdir", "sdis", 
"sdit", "sdiu", "sdiv", "sdiw", "sdix", "sdiy", "sdiz"
 };
 
+struct testDiskName
+{
+const char *name;
+int idx;
+int partition;
+};
+
+static struct testDiskName diskNamesPart[] = {
+{"sda0",  0,   0},
+{"sdb10", 1,  10},
+{"sdc2147483647", 2,  2147483647},
+};
+
+static const char* diskNamesInvalid[] = {
+"sda00", "sda01", "sdb-1"
+};
+
 static int
 testIndexToDiskName(const void *data ATTRIBUTE_UNUSED)
 {
@@ -79,6 +96,44 @@ testDiskNameToIndex(const void *data ATTRIBUTE_UNUSED)
 
 
 
+static int
+testDiskNameParse(const void *data ATTRIBUTE_UNUSED)
+{
+size_t i;
+int idx;
+int partition;
+struct testDiskName *disk = NULL;
+
+for (i = 0; i < ARRAY_CARDINALITY(diskNamesPart); ++i) {
+disk = &diskNamesPart[i];
+if (virDiskNameParse(disk->name, &idx, &partition))
+return -1;
+
+if (disk->idx != idx) {
+VIR_TEST_DEBUG("\nExpect [%d]\n", disk->idx);
+VIR_TEST_DEBUG("Actual [%d]\n", idx);
+return -1;
+}
+
+if (disk->partition != partition) {
+VIR_TEST_DEBUG("\nExpect [%d]\n", disk->partition);
+VIR_TEST_DEBUG("Actual [%d]\n", partition);
+re

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[John Stultz]

On Tue, Nov 10, 2015 at 7:31 AM, Thomas Gleixner  wrote:
> On Tue, 10 Nov 2015, John Stultz wrote:
>> On Tue, Nov 10, 2015 at 7:10 AM, Stefano Stabellini
>>  wrote:
>> > On Tue, 10 Nov 2015, Arnd Bergmann wrote:
>> >> On Tuesday 10 November 2015 11:57:49 Stefano Stabellini wrote:
>> >> > __current_kernel_time64 returns a struct timespec64, without taking the
>> >> > xtime lock. Mirrors __current_kernel_time/current_kernel_time.
>> >> >
>> >>
>> >> Actually it doesn't mirror __current_kernel_time/current_kernel_time
>> >>
>> >> > diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
>> >> > index ec89d84..b5802bf 100644
>> >> > --- a/include/linux/timekeeping.h
>> >> > +++ b/include/linux/timekeeping.h
>> >> > @@ -19,7 +19,8 @@ extern int do_sys_settimeofday(const struct timespec 
>> >> > *tv,
>> >> >   */
>> >> >  unsigned long get_seconds(void);
>> >> >  struct timespec64 current_kernel_time64(void);
>> >> > -/* does not take xtime_lock */
>> >> > +/* do not take xtime_lock */
>> >> > +struct timespec64 __current_kernel_time64(void);
>> >> >  struct timespec __current_kernel_time(void);
>> >>
>> >> Please change __current_kernel_time into a static inline function
>> >> while you are introducing the new one, to match the patch description ;-)
>> >
>> > The implementation is:
>> >
>> > struct timekeeper *tk = &tk_core.timekeeper;
>> >
>> > return timespec64_to_timespec(tk_xtime(tk));
>> >
>> > which cannot be easily made into a static inline, unless we start
>> > exporting tk_core.
>>
>> So the timekeeper is passed to the notifier. So you probably want something 
>> like
>>
>> struct timespec64 __current_kernel_time64(struct timekeeper *tk)
>> {
>>  return timespec64_to_timespec(tk_xtime(tk));
>> }
>>
>> Then you can cast the priv pointer in the notifier to a timekeeper and
>> use it that way?
>
> Err no. Look at commit 8758a240e2d74c5932ab51a73377e6507b7fd441
>
> i.e. Add the new 64bit function and make the existing one a static
> inline which does the timespec64 to timespec conversion.

So yea. The style there is what should be done.

I'm sort of objecting to a different issue, where the
__current_kernel_time() implementation probably shouldn't be grabbing
the tk_core.timekeeper directly, and instead should take a passed
pointer to a timekeeper. The vdso/pv_clock usage should have a
timekeeper passed to them that they could use.

There's one useage in kdb thats maybe problematic, so maybe this will
need a deeper cleanup.

thanks
-john

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

Re: [Xen-devel] [PATCH v2 1/7] timekeeping: introduce __current_kernel_time64

[Thomas Gleixner]

On Tue, 10 Nov 2015, John Stultz wrote:
> I'm sort of objecting to a different issue, where the
> __current_kernel_time() implementation probably shouldn't be grabbing
> the tk_core.timekeeper directly, and instead should take a passed
> pointer to a timekeeper. The vdso/pv_clock usage should have a
> timekeeper passed to them that they could use.

That usage of __current_kernel_time() in that xen notifier is silly to
begin with. The notifier gets already called with a pointer to the
time keeper. That xen implementation just does not use it.

We extract exactly that information in the vdso updates without
calling back into the core code. So for solving that xen thing we do
not need a 64 bit variant of __current_kernel_time() at all. The
notifier has the pointer to the timekeeper and can just grab data from
there.

> There's one useage in kdb thats maybe problematic, so maybe this will
> need a deeper cleanup.

That one is silly as well. It only wants to know the seconds portion.

Thanks,

tglx

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

Re: [Xen-devel] [PATCH v2 7/7] xen/arm: set the system time in Xen via the XENPF_settime64 hypercall

[Stefano Stabellini]

On Tue, 10 Nov 2015, Arnd Bergmann wrote:
> On Tuesday 10 November 2015 11:57:55 Stefano Stabellini wrote:
> > +   op.u.settime64.nsecs = now.tv_nsec;
> > +   op.u.settime64.system_time = arch_timer_read_counter() * 
> > (u64)NSEC_PER_SEC;
> > +   do_div(op.u.settime64.system_time, arch_timer_get_rate());
> 
> NSEC_PER_SEC is a large number, doesn't that multiplication overflow the
> 64-bit system_time variable?

It could be a concern, you are right. I think I can solve this issue and
remove multiple do_divs by calculating nsec_per_tick at initialization
time and use it here and in xen_read_wallclock.


> > +   printk("GTOD: Setting to %llu.%u at %llu\n",
> 
>  %llu.%09u
> 
> so you get the leading zeroes.
> 
> > +  op.u.settime64.secs,
> > +  op.u.settime64.nsecs,
> > +  op.u.settime64.system_time);
> > +   (void)HYPERVISOR_platform_op(&op);
> 
>   Arnd
> 

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

[Xen-devel] [PATCH v2 2/8] xen: arm: fix typo in the description of struct pending_irq->desc

[Ian Campbell]

s/it/if/ makes more sense.

Signed-off-by: Ian Campbell 
---
 xen/include/asm-arm/vgic.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index cb51a9e..7d580cc 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -66,7 +66,7 @@ struct pending_irq
 #define GIC_IRQ_GUEST_ENABLED  3
 #define GIC_IRQ_GUEST_MIGRATING   4
 unsigned long status;
-struct irq_desc *desc; /* only set it the irq corresponds to a physical 
irq */
+struct irq_desc *desc; /* only set if the irq corresponds to a physical 
irq */
 unsigned int irq;
 #define GIC_INVALID_LR ~(uint8_t)0
 uint8_t lr;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 7/8] xen: arm: context switch vtimer PPI state.

[Ian Campbell]

... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does).

By using the newly added hwppi save/restore functionality we make use
of the GICD I[SC]ACTIVER registers to save and restore the active
state of the interrupt, which prevents the nested invocations which
the current masking works around.

Signed-off-by: Ian Campbell 
---
v2: Rebased, in particular over Julien's passthrough stuff which
reworked a bunch of IRQ related stuff.
Also largely rewritten since precursor patches now lay very
different groundwork.
---
 xen/arch/arm/time.c  | 26 ++
 xen/arch/arm/vtimer.c| 41 +
 xen/include/asm-arm/domain.h |  1 +
 3 files changed, 40 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 5ded30c..2a1cdba 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -181,28 +181,6 @@ static void timer_interrupt(int irq, void *dev_id, struct 
cpu_user_regs *regs)
 }
 }
 
-static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
-{
-/*
- * Edge-triggered interrupts can be used for the virtual timer. Even
- * if the timer output signal is masked in the context switch, the
- * GIC will keep track that of any interrupts raised while IRQS are
- * disabled. As soon as IRQs are re-enabled, the virtual interrupt
- * will be injected to Xen.
- *
- * If an IDLE vCPU was scheduled next then we should ignore the
- * interrupt.
- */
-if ( unlikely(is_idle_vcpu(current)) )
-return;
-
-perfc_incr(virt_timer_irqs);
-
-current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
-WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
-vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
-}
-
 /*
  * Arch timer interrupt really ought to be level triggered, since the
  * design of the timer/comparator mechanism is based around that
@@ -242,8 +220,8 @@ void __cpuinit init_timer_interrupt(void)
 
 request_irq(timer_irq[TIMER_HYP_PPI], 0, timer_interrupt,
 "hyptimer", NULL);
-request_irq(timer_irq[TIMER_VIRT_PPI], 0, vtimer_interrupt,
-   "virtimer", NULL);
+route_hwppi_to_current_vcpu(timer_irq[TIMER_VIRT_PPI], "virtimer");
+
 request_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], 0, timer_interrupt,
 "phytimer", NULL);
 
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 1418092..82e2b88 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -55,9 +55,19 @@ static void phys_timer_expired(void *data)
 static void virt_timer_expired(void *data)
 {
 struct vtimer *t = data;
-t->ctl |= CNTx_CTL_MASK;
-vgic_vcpu_inject_irq(t->v, t->irq);
-perfc_incr(vtimer_virt_inject);
+t->ctl |= CNTx_CTL_PENDING;
+if ( !(t->ctl & CNTx_CTL_MASK) )
+{
+/*
+ * An edge triggered interrupt should now be pending. Since
+ * this timer can never expire while the domain is scheduled
+ * we know that the gic_restore_hwppi in virt_timer_restore
+ * will cause the real hwppi to occur and be routed.
+ */
+gic_hwppi_set_pending(&t->ppi_state);
+vcpu_unblock(t->v);
+perfc_incr(vtimer_virt_inject);
+}
 }
 
 int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
@@ -96,9 +106,12 @@ int domain_vtimer_init(struct domain *d, struct 
xen_arch_domainconfig *config)
 
 int vcpu_vtimer_init(struct vcpu *v)
 {
+struct pending_irq *p;
 struct vtimer *t = &v->arch.phys_timer;
 bool_t d0 = is_hardware_domain(v->domain);
 
+const unsigned host_vtimer_irq_ppi = timer_get_irq(TIMER_VIRT_PPI);
+
 /*
  * Hardware domain uses the hardware interrupts, guests get the virtual
  * platform.
@@ -116,10 +129,16 @@ int vcpu_vtimer_init(struct vcpu *v)
 init_timer(&t->timer, virt_timer_expired, t, v->processor);
 t->ctl = 0;
 t->irq = d0
-? timer_get_irq(TIMER_VIRT_PPI)
+? host_vtimer_irq_ppi
 : GUEST_TIMER_VIRT_PPI;
 t->v = v;
 
+p = irq_to_pending(v, t->irq);
+p->irq = t->irq;
+
+gic_hwppi_state_init(&v->arch.virt_timer.ppi_state,
+ host_vtimer_irq_ppi);
+
 v->arch.vtimer_initialized = 1;
 
 return 0;
@@ -147,6 +166,15 @@ int virt_timer_save(struct vcpu *v)
 set_timer(&v->arch.virt_timer.timer, 
ticks_to_ns(v->arch.virt_timer.cval +
   v->domain->arch.virt_timer_base.offset - boot_count));
 }
+
+/*
+ * Since the vtimer irq is a PPI we don't need to worry about
+ * racing against it becoming active while we are saving the
+ * state, since that requires the guest to be reading the IAR.
+ */
+gic_save_and_mask_hwppi(v, v->arch.virt_timer.irq,
+ 

[Xen-devel] [PATCH v2] xen: arm: context switch vtimer PPI state.

[Ian Campbell]

... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask which it isn't required to
do per the h/w spec, although Linux does, other OSes (FreeRTOS?) needed
changes. Making the vtimer follow the h/w spec is the main driving force
here although it may also enable us to do direct injection in the future
(GIC >=v4). It's also something I wanted to sort out before starting to
think about how to migrate a vtimer.

This series introduces the concept of routing a PPI to the currently
running VCPU and of context switching its state using the GICD I[SC]ACTIVER
registers to save and restore the active state of the interrupt. In the
case of the vtimer this prevents the nested invocations which the current
masking works around.

For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered interrupts
SPENDR sets a latch which is only cleared by ICPENDR (and not by h/w
state changes), therefore we do not want to context switch the pending
state for level PPIs -- instead we rely on the context switch of the
peripheral to restore the correct level.

This is an update of a much older RFC[0]. Lots has changed, the hooks are
now at a different level with more common code (although maybe not as much
as I would like) and lots of refactoring, It also now handles non-1:1
configurations (tested with a patch to force GUEST_TIMER_VIRT_PPI to
something whic didn't match the h/w platform).

I also switched from using struct irq_guest->d (domain) == NULL to signal
this type of interrupt to using desc->state containing both IRQ_GUEST and
IRQ_PER_CPU as the trigger instead as discussed in[1].

I think I've addressed all the comments which remained relevant after the
reworking, although so much has changed I'm not completely sure, sorry if
I've missed anything.

Ian.

[0] http://lists.xen.org/archives/html/xen-devel/2015-01/msg03161.html
[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00842.html

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

[Xen-devel] [PATCH v2 6/8] xen: arm: supporting routing a PPI to the current vcpu.

[Ian Campbell]

That is whichever vcpu is resident when the interrupt fires. An
interrupt is in this state when both IRQ_GUEST and IRQ_PER_CPU are set
in the descriptor status. Only PPIs can be in this mode.

This requires some peripheral specific code to make use of the
previously introduced functionality to save and restore the PPI state.
The vtimer driver will do so shortly.

Signed-off-by: Ian Campbell 
---
 xen/arch/arm/gic.c| 24 ++
 xen/arch/arm/irq.c| 84 +--
 xen/include/asm-arm/gic.h |  2 ++
 xen/include/asm-arm/irq.h |  2 +-
 4 files changed, 101 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e294e89..aea913b 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -177,6 +177,30 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const 
cpumask_t *cpu_mask,
 gic_set_irq_properties(desc, cpu_mask, priority);
 }
 
+/* Program the GIC to route an interrupt to the current guest
+ *
+ * That is the IRQ is delivered to whichever VCPU happens to be
+ * resident on the PCPU when the interrupt arrives.
+ *
+ * Currently the interrupt *must* be a PPI and the code responsible
+ * for the related hardware must save and restore the PPI with
+ * gic_save_and_mask_hwppi/gic_restore_hwppi.
+ */
+int gic_route_irq_to_current_guest(struct irq_desc *desc,
+   unsigned int priority)
+{
+ASSERT(spin_is_locked(&desc->lock));
+ASSERT(desc->irq >= 16 && desc->irq < 32);
+
+desc->handler = gic_hw_ops->gic_guest_irq_type;
+set_bit(_IRQ_GUEST, &desc->status);
+set_bit(_IRQ_PER_CPU, &desc->status);
+
+gic_set_irq_properties(desc, cpumask_of(smp_processor_id()), GIC_PRI_IRQ);
+
+return 0;
+}
+
 /* Program the GIC to route an interrupt to a guest
  *   - desc.lock must be held
  */
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 95be10e..ca18403 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -229,12 +229,15 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
 set_bit(_IRQ_INPROGRESS, &desc->status);
 
 /*
- * The irq cannot be a PPI, we only support delivery of SPIs to
- * guests.
+ * A PPI exposed to a guest must always be in IRQ_GUEST|IRQ_PER_CPU
+ * mode ("route to active VCPU"), so we use current.
+ *
+ * For SPI we look up the required target as normal.
  */
-v = vgic_get_target_vcpu(info->d->vcpu[0], info->virq);
-vgic_vcpu_inject_irq(v, info->virq);
+v = test_bit(_IRQ_PER_CPU, &desc->status) ? current :
+vgic_get_target_vcpu(info->d->vcpu[0], info->virq);
 
+vgic_vcpu_inject_irq(v, info->virq);
 goto out_no_end;
 }
 
@@ -363,11 +366,15 @@ int setup_irq(unsigned int irq, unsigned int irqflags, 
struct irqaction *new)
 
 if ( test_bit(_IRQ_GUEST, &desc->status) )
 {
-struct domain *d = irq_get_domain(desc);
+struct irq_guest *info = irq_get_guest_info(desc);
 
 spin_unlock_irqrestore(&desc->lock, flags);
-printk(XENLOG_ERR "ERROR: IRQ %u is already in use by the domain %u\n",
-   irq, d->domain_id);
+if ( !test_bit(_IRQ_PER_CPU, &desc->status) )
+printk(XENLOG_ERR "ERROR: IRQ %u is already in use by domain %u\n",
+   irq, info->d->domain_id);
+else
+printk(XENLOG_ERR
+   "ERROR: IRQ %u is already in use by \n", irq);
 return -EBUSY;
 }
 
@@ -410,7 +417,7 @@ static int setup_guest_irq(struct irq_desc *desc, unsigned 
int virq,
 {
 const unsigned irq = desc->irq;
 struct irqaction *action;
-int retval = 0;
+int retval;
 
 ASSERT(spin_is_locked(&desc->lock));
 
@@ -451,12 +458,21 @@ static int setup_guest_irq(struct irq_desc *desc, 
unsigned int virq,
d->domain_id, irq, irq_get_guest_info(desc)->virq);
 retval = -EBUSY;
 }
+else
+retval = 0;
 goto out;
 }
 
 if ( test_bit(_IRQ_GUEST, &desc->status) )
-printk(XENLOG_G_ERR "IRQ %u is already used by domain %u\n",
-   irq, ad->domain_id);
+{
+if ( !test_bit(_IRQ_PER_CPU, &desc->status) )
+printk(XENLOG_ERR
+   "ERROR: IRQ %u is already used by domain %u\n",
+   irq, ad->domain_id);
+else
+printk(XENLOG_ERR
+   "ERROR: IRQ %u is already used by \n", 
irq);
+}
 else
 printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
 retval = -EBUSY;
@@ -542,6 +558,54 @@ free_info:
 return retval;
 }
 
+/*
+ * Route a PPI such that it is always delivered to the current vcpu on
+ * the pcpu. The driver for the peripheral must use
+ * gic_{save_and_mask,restore}_hwppi as part of the context switch.
+ */
+

[Xen-devel] [PATCH v2 3/8] xen: arm: Refactor route_irq_to_guest

[Ian Campbell]

Split out the bit which allocates the struct irqaction and calls
__setup_irq into a new function (setup_guest_irq). I'm going to want
to call this a second time in a subsequent patch.

Note that the action is now allocated and initialised with the desc
lock held (since it is taken by the caller). I don't think this is an
issue (and avoiding this would make things more complex)

Signed-off-by: Ian Campbell 
---
v2: New patch (maybe, it's been a while...)
---
 xen/arch/arm/irq.c | 104 +++--
 1 file changed, 61 insertions(+), 43 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 5031777..6918438 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -394,61 +394,24 @@ bool_t is_assignable_irq(unsigned int irq)
 return ((irq >= NR_LOCAL_IRQS) && (irq < gic_number_lines()));
 }
 
-/*
- * Route an IRQ to a specific guest.
- * For now only SPIs are assignable to the guest.
- */
-int route_irq_to_guest(struct domain *d, unsigned int virq,
-   unsigned int irq, const char * devname)
+static int setup_guest_irq(struct irq_desc *desc, unsigned int virq,
+   unsigned int irqflags,
+   struct irq_guest *info, const char *devname)
 {
+const unsigned irq = desc->irq;
 struct irqaction *action;
-struct irq_guest *info;
-struct irq_desc *desc;
-unsigned long flags;
 int retval = 0;
 
-if ( virq >= vgic_num_irqs(d) )
-{
-printk(XENLOG_G_ERR
-   "the vIRQ number %u is too high for domain %u (max = %u)\n",
-   irq, d->domain_id, vgic_num_irqs(d));
-return -EINVAL;
-}
-
-/* Only routing to virtual SPIs is supported */
-if ( virq < NR_LOCAL_IRQS )
-{
-printk(XENLOG_G_ERR "IRQ can only be routed to an SPI\n");
-return -EINVAL;
-}
-
-if ( !is_assignable_irq(irq) )
-{
-printk(XENLOG_G_ERR "the IRQ%u is not routable\n", irq);
-return -EINVAL;
-}
-desc = irq_to_desc(irq);
+ASSERT(spin_is_locked(&desc->lock));
 
 action = xmalloc(struct irqaction);
 if ( !action )
 return -ENOMEM;
 
-info = xmalloc(struct irq_guest);
-if ( !info )
-{
-xfree(action);
-return -ENOMEM;
-}
-
-info->d = d;
-info->virq = virq;
-
 action->dev_id = info;
 action->name = devname;
 action->free_on_release = 1;
 
-spin_lock_irqsave(&desc->lock, flags);
-
 if ( desc->arch.type == DT_IRQ_TYPE_INVALID )
 {
 printk(XENLOG_G_ERR "IRQ %u has not been configured\n", irq);
@@ -466,6 +429,7 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
  */
 if ( desc->action != NULL )
 {
+struct domain *d = info->d;
 struct domain *ad = irq_get_domain(desc);
 
 if ( test_bit(_IRQ_GUEST, &desc->status) && d == ad )
@@ -493,6 +457,61 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
 if ( retval )
 goto out;
 
+return 0;
+
+out:
+xfree(action);
+return retval;
+}
+
+/*
+ * Route an IRQ to a specific guest.
+ * For now only SPIs are assignable to the guest.
+ */
+int route_irq_to_guest(struct domain *d, unsigned int virq,
+   unsigned int irq, const char * devname)
+{
+struct irq_guest *info;
+struct irq_desc *desc;
+unsigned long flags;
+int retval;
+
+if ( virq >= vgic_num_irqs(d) )
+{
+printk(XENLOG_G_ERR
+   "the vIRQ number %u is too high for domain %u (max = %u)\n",
+   irq, d->domain_id, vgic_num_irqs(d));
+return -EINVAL;
+}
+
+/* Only routing to virtual SPIs is supported */
+if ( virq < NR_LOCAL_IRQS )
+{
+printk(XENLOG_G_ERR "IRQ can only be routed to an SPI\n");
+return -EINVAL;
+}
+
+if ( !is_assignable_irq(irq) )
+{
+printk(XENLOG_G_ERR "the IRQ%u is not routable\n", irq);
+return -EINVAL;
+}
+
+desc = irq_to_desc(irq);
+
+info = xmalloc(struct irq_guest);
+if ( !info )
+return -ENOMEM;
+
+info->d = d;
+info->virq = virq;
+
+spin_lock_irqsave(&desc->lock, flags);
+
+retval = setup_guest_irq(desc, virq, flags, info, devname);
+if ( retval )
+goto out;
+
 retval = gic_route_irq_to_guest(d, virq, desc, GIC_PRI_IRQ);
 
 spin_unlock_irqrestore(&desc->lock, flags);
@@ -507,7 +526,6 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
 
 out:
 spin_unlock_irqrestore(&desc->lock, flags);
-xfree(action);
 free_info:
 xfree(info);
 
-- 
2.1.4


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

[Xen-devel] [PATCH v2 5/8] xen: arm: add interfaces to save/restore the state of a PPI.

[Ian Campbell]

Make use of the GICD I[SC]ACTIVER registers to save and
restore the active state of the interrupt.

For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered interrupts
SPENDR sets a latch which is only cleared by ICPENDR (and not by h/w
state changes), therefore we do not want to context switch the pending
state for level PPIs -- instead we rely on the context switch of the
peripheral to restore the correct level.

Tested on GIC v2 only.

Unused as yet, will be used by the vtimer code shortly.

Signed-off-by: Ian Campbell 
---
 xen/arch/arm/gic-v2.c| 67 
 xen/arch/arm/gic-v3.c| 67 
 xen/arch/arm/gic.c   | 54 +++
 xen/arch/arm/irq.c   |  7 +
 xen/include/asm-arm/domain.h | 11 
 xen/include/asm-arm/gic.h| 16 +++
 xen/include/asm-arm/irq.h|  3 ++
 7 files changed, 225 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 01e36b5..5308c35 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -81,6 +81,9 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
 /* Maximum cpu interface per GIC */
 #define NR_GIC_CPU_IF 8
 
+static void gicv2_irq_enable(struct irq_desc *desc);
+static void gicv2_irq_disable(struct irq_desc *desc);
+
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
 writeb_relaxed(val, gicv2.map_dbase + offset);
@@ -149,6 +152,37 @@ static void gicv2_save_state(struct vcpu *v)
 writel_gich(0, GICH_HCR);
 }
 
+static void gicv2_save_and_mask_hwppi(struct irq_desc *desc,
+  struct hwppi_state *s)
+{
+const unsigned int mask = (1u << desc->irq);
+const unsigned int pendingr = readl_gicd(GICD_ISPENDR);
+const unsigned int activer = readl_gicd(GICD_ISACTIVER);
+const unsigned int enabler = readl_gicd(GICD_ISENABLER);
+const bool is_edge = !!(desc->arch.type & DT_IRQ_TYPE_EDGE_BOTH);
+
+s->active = !!(activer & mask);
+s->enabled = !!(enabler & mask);
+s->pending = !!(pendingr & mask);
+
+/* Write a 1 to IC...R to clear the corresponding bit of state */
+if ( s->active )
+writel_gicd(mask, GICD_ICACTIVER);
+/*
+ * For an edge interrupt clear the pending state, for a level interrupt
+ * this clears the latch there is no need since saving the peripheral state
+ * (and/or restoring the next VCPU) will cause the correct action.
+ */
+if ( is_edge && s->pending )
+writel_gicd(mask, GICD_ICPENDR);
+
+if ( s->enabled )
+gicv2_irq_disable(desc);
+
+ASSERT(!(readl_gicd(GICD_ISACTIVER) & mask));
+ASSERT(!(readl_gicd(GICD_ISENABLER) & mask));
+}
+
 static void gicv2_restore_state(const struct vcpu *v)
 {
 int i;
@@ -161,6 +195,37 @@ static void gicv2_restore_state(const struct vcpu *v)
 writel_gich(GICH_HCR_EN, GICH_HCR);
 }
 
+static void gicv2_restore_hwppi(struct irq_desc *desc,
+const struct hwppi_state *s)
+{
+const unsigned int mask = (1u << desc->irq);
+const bool is_edge = !!(desc->arch.type & DT_IRQ_TYPE_EDGE_BOTH);
+
+/*
+ * The IRQ must always have been set inactive and masked etc by
+ * the saving of the previous state via save_and_mask_hwppi.
+ */
+ASSERT(!(readl_gicd(GICD_ISACTIVER) & mask));
+ASSERT(!(readl_gicd(GICD_ISENABLER) & mask));
+
+if ( s->active )
+writel_gicd(mask, GICD_ICACTIVER);
+
+/*
+ * Restore pending state for edge triggered interrupts only. For
+ * level triggered interrupts the level will be restored as
+ * necessary by restoring the state of the relevant peripheral.
+ *
+ * For a level triggered interrupt ISPENDR acts as a *latch* which
+ * is only cleared by ICPENDR (i.e. the input level is no longer
+ * relevant). We certainly do not want that here.
+ */
+if ( is_edge && s->pending )
+writel_gicd(mask, GICD_ISPENDR);
+if ( s->enabled )
+gicv2_irq_enable(desc);
+}
+
 static void gicv2_dump_state(const struct vcpu *v)
 {
 int i;
@@ -744,7 +809,9 @@ const static struct gic_hw_operations gicv2_ops = {
 .init= gicv2_init,
 .secondary_init  = gicv2_secondary_cpu_init,
 .save_state  = gicv2_save_state,
+.save_and_mask_hwppi = gicv2_save_and_mask_hwppi,
 .restore_state   = gicv2_restore_state,
+.restore_hwppi   = gicv2_restore_hwppi,
 .dump_state  = gicv2_dump_state,
 .gic_host_irq_type   = &gicv2_host_irq_type,
 .gic_guest_irq_type  = &gicv2_guest_irq_type,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 4fe0c37..cfe705a 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -61,6 +61,9 @@ static DEFINE_PER_CPU(void __iomem*, rbase);
 #define GICD_RDIST_BASE(this_cpu(rbase))
 #define GICD_RDIST_SGI_

[Xen-devel] [PATCH v2 8/8] HACK: Force virt timer to PPI0 (IRQ16)

[Ian Campbell]

Just for testing so the guest vtimer ppi it isn't the same as the
physical virt timer PPI on my platform, and therefore allows to
exercise the non-1:1 bits of the code.
---
 xen/include/public/arch-arm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 6322548..01dbb41 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -432,7 +432,7 @@ typedef uint64_t xen_callback_t;
 #define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
 
 /* Interrupts */
-#define GUEST_TIMER_VIRT_PPI27
+#define GUEST_TIMER_VIRT_PPI16
 #define GUEST_TIMER_PHYS_S_PPI  29
 #define GUEST_TIMER_PHYS_NS_PPI 30
 #define GUEST_EVTCHN_PPI31
-- 
2.1.4


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

[Xen-devel] [PATCH v2 1/8] xen: arm: fix indendation of struct vtimer

[Ian Campbell]

Signed-off-by: Ian Campbell 
---
 xen/include/asm-arm/domain.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index e7e40da..c56f06e 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -35,11 +35,11 @@ extern int dom0_11_mapping;
 #define is_domain_direct_mapped(d) ((d) == hardware_domain && dom0_11_mapping)
 
 struct vtimer {
-struct vcpu *v;
-int irq;
-struct timer timer;
-uint32_t ctl;
-uint64_t cval;
+struct vcpu *v;
+int irq;
+struct timer timer;
+uint32_t ctl;
+uint64_t cval;
 };
 
 struct arch_domain
-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/8] xen: arm: remove vgic_vcpu_inject_spi()

[Ian Campbell]

Currently this has only a single caller, which I intend to teach about
injecting PPIs shortly. This helper doesn't add much so remove it.

Drop a stray tab from the comment immediately preceding this change.

Signed-off-by: Ian Campbell 
---
 xen/arch/arm/irq.c |  7 +--
 xen/arch/arm/vgic.c| 11 ---
 xen/include/asm-arm/vgic.h |  1 -
 3 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 6918438..5b073d1 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -214,6 +214,7 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
 if ( test_bit(_IRQ_GUEST, &desc->status) )
 {
 struct irq_guest *info = irq_get_guest_info(desc);
+struct vcpu *v;
 
 perfc_incr(guest_irqs);
 desc->handler->end(desc);
@@ -223,8 +224,10 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
 /*
  * The irq cannot be a PPI, we only support delivery of SPIs to
  * guests.
-*/
-vgic_vcpu_inject_spi(info->d, info->virq);
+ */
+v = vgic_get_target_vcpu(info->d->vcpu[0], info->virq);
+vgic_vcpu_inject_irq(v, info->virq);
+
 goto out_no_end;
 }
 
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 7bb4570..7a76f00 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -477,17 +477,6 @@ out:
 }
 }
 
-void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq)
-{
-struct vcpu *v;
-
-/* the IRQ needs to be an SPI */
-ASSERT(virq >= 32 && virq <= vgic_num_irqs(d));
-
-v = vgic_get_target_vcpu(d->vcpu[0], virq);
-vgic_vcpu_inject_irq(v, virq);
-}
-
 void arch_evtchn_inject(struct vcpu *v)
 {
 vgic_vcpu_inject_irq(v, v->domain->arch.evtchn_irq);
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 7d580cc..aa675cb 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -207,7 +207,6 @@ extern void domain_vgic_free(struct domain *d);
 extern int vcpu_vgic_init(struct vcpu *v);
 extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int irq);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
-extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
 extern void vgic_clear_pending_irqs(struct vcpu *v);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq);
-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH v2 01/16] hvmloader: Fix scratch_alloc to avoid overlaps

[Jan Beulich]

>>> On 26.10.15 at 17:03,  wrote:
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -479,7 +479,7 @@ void *scratch_alloc(uint32_t size, uint32_t align)
>  align = 16;
>  
>  s = (scratch_start + align - 1) & ~(align - 1);
> -e = s + size - 1;
> +e = s + size;

This further increases the delta to the actually quite similar
mem_alloc(). I'd prefer the two to remain in sync as much as
possible, and hence either the other one to also be adjusted
or this one to be fixed the other way around (dropping the
first "- 1" in the assignment to s, but requiring changes
elsewhere too).

Jan


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

Re: [Xen-devel] [PATCH v8 13/21] xen/x86: make sure the HVM callback vector is correctly set

[Jan Beulich]

>>> On 06.11.15 at 17:05,  wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t via)
>   (via_type > HVMIRQ_callback_vector) )
>  via_type = HVMIRQ_callback_none;
>  
> +if ( via_type != HVMIRQ_callback_vector &&
> + (!has_vlapic(d) || !has_vioapic(d)) )
> +return;

What about PIC? With vpic_irq_positive_edge() now asserting
has_vpic(), and hvm_set_callback_irq_level() calling the former,
I don't think the above is sufficient.

Jan


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

Re: [Xen-devel] [PATCH v2 2/3] XENVER_build_id: Provide ld-embedded build-ids

[Jan Beulich]

>>> On 06.11.15 at 20:36,  wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -109,15 +109,19 @@ $(TARGET)-syms: prelink.o xen.lds 
> $(BASEDIR)/common/symbols-dummy.o
>   $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
>   | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
>   $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> - $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> + $(LD) $(LDFLAGS) -T xen.lds -N prelink.o --build-id=sha1 \

You continue to use option this unconditionally.

Jan


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