Re: [Xen-devel] Xen's Linux kernel config options V2

[Jan Beulich]

>>> On 04.02.15 at 01:48,  wrote:
> So as I see it XEN_BALLOON should depend on XEN_PV || XEN_PVH -- not
> sure how ballooning would be used on HVM only domains although right
> now ballooning would indeed be initialized in such situations, should
> it not? If it should not then the above check should be for
> xen_pvh_domain() not just xen_domain(). If it should work for hvm
> domains too we could perhaps use XEN_BACKEND || XEN_FRONTEND.

Why do you think HVM can't use ballooning?

> As for XENFS we have the same check on init for xen_domain(), we only
> have a small difference for two types of cases. If your kernel
> supports XEN_DOM0 you also get exposed on the xenfs the xsd_kva and
> xsd_port which correspond to the xen_store_evtchn and
> xen_store_interface respectively. Does it make sense to expose xenfs
> for hvms? If so under this new arrangement perhaps it should depend on
> XEN_BACKEND || XEN_FRONTEND ?

In general I think options should be hidden only if they can't work
in certain cases.

> XEN_SYS_HYPERVISOR just populates the generic /sys/hypervisor/ and
> also extends it with Xen specific information, its initialization also
> depends on xen_domain() but I cannot think of a reason to have this
> for HVM. Perhaps this should depend on XEN_BACKEND only ?

Again - don't hide options that may end up being useful, unless there
is a reason they can't possibly work.

>>>   XEN_DEV_EVTCHN
>>
>> Frontends and backends select this?
> 
> This registers /dev/xen/evtchn only if we're in xen_domain(). Do we
> want this to user visible selectable option and have it depend on
> XEN_BACKEND || XEN_FRONTEND ?

I think this can be useful even without any (kernel based) backends
or frontends (e.g. for user mode ones). It's also needed for certain
daemons.

>>>   XEN_GNTDEV
>>
>> Backend should select this?
> 
> Based on my review I would think that this should depend on
> XEN_BACKEND but be user selectable. I'm hoping Stefano can best decide
> this though.

Just like for the evtchn device, this is useful to user mode even without
any kernel based backends.

>>>   XEN_TMEM
>>>   XEN_PRIVCMD
>>
>> Backend select this?

Why? There's no connection between these and backend functionality.

Jan


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

Re: [Xen-devel] [PATCH 1/2] hvmloader: remove timestamp from smbios

[Jan Beulich]

>>> On 03.02.15 at 19:41,  wrote:
> On Tue, Feb 03, Andrew Cooper wrote:
> 
>> A release date is part of the SMBIOS spec, and the change below results
>> in a malformed smbios table (stale p->release_date_str = 3; pointer)
> 
> Good point. Thanks for review. Do you have a pointer to that spec?

http://dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
(in particular section 7.1 and table 5)

Jan


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

Re: [Xen-devel] [PATCH v9 0/3] enable Memory Bandwidth Monitoring (MBM) for VMs

[Chao Peng]

On Mon, Feb 02, 2015 at 04:06:06PM +0800, Chao Peng wrote:
> Changes from v8:
> * Merge event mask patch to MBM enabling patch;
> * Address comments from Ian Campbell(Detail in patch itself).

Any comments on this revision?
Thanks,
Chao

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

Re: [Xen-devel] [PATCH 1/2] hvmloader: remove timestamp from smbios

[Olaf Hering]

On Wed, Feb 04, Jan Beulich wrote:

> http://dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf
> (in particular section 7.1 and table 5)

"The date string, if supplied, is in either mm/dd/yy or mm/dd/ format."

To me it sounds like an optional thing. An empty string is as
informative as any other random date. 

But before the bikeshedding starts I think its best to turn the
assignment in the Makefiles from "VAR = VAL" into "VAR ?= VAL". This
preserves existing practice and gives us the opportunity to pass
01/01/1970 as fixed VAL.

Olaf

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

Re: [Xen-devel] [PATCH] Avoid needless flush cache when guest change MTRR

[Jan Beulich]

>>> On 04.02.15 at 04:28,  wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -791,7 +791,7 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, 
> hvm_load_mtrr_msr,
>  
>  void memory_type_changed(struct domain *d)
>  {
> -if ( iommu_enabled && d->vcpu && d->vcpu[0] )
> +if ( need_iommu(d) && d->vcpu && d->vcpu[0] )
>  {
>  p2m_memory_type_changed(d);
>  flush_all(FLUSH_CACHE);

This doesn't do what title and description say: You not only suppress
the flush, but also the EPT table adjustments. Either adjust at least
the description accordingly, or make the code do what the description
says.

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1365,6 +1365,11 @@ static int assign_device(struct domain *d, u16 seg, u8 
> bus, u8 devfn)
>  }
>  }
>  d->need_iommu = 1;
> +/* There may be dirty cache lines when a device is assigned
> + * and before need_iommu(d) becoming true, this will cause
> + * memory_type_changed lose effect if memory type changes.
> + * Call memory_type_changed here to amend this. */
> +memory_type_changed(d);

The comment formatting does not adhere to ./CODING_STYLE.

Jan


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

Re: [Xen-devel] [PATCH v9 0/3] enable Memory Bandwidth Monitoring (MBM) for VMs

[Jan Beulich]

>>> On 04.02.15 at 09:39,  wrote:
> On Mon, Feb 02, 2015 at 04:06:06PM +0800, Chao Peng wrote:
>> Changes from v8:
>> * Merge event mask patch to MBM enabling patch;
>> * Address comments from Ian Campbell(Detail in patch itself).
> 
> Any comments on this revision?

Please be a little more patient before pinging - you only sent this
2 days ago. Please allow for at least a week.

Jan


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

Re: [Xen-devel] [PATCH 00/18] x86: multiboot2 protocol support

[Andrew Cooper]

On 03/02/2015 17:14, Daniel Kiper wrote:
> On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wrote:
> On 30.01.15 at 18:54,  wrote:
>>>   - xen.efi build will not so strongly depend
>>> on a given GCC and binutils version.
>> While I can see the possibility of making the binutils version
>> dependency go away (by manually creating the PE header), I can't
>> see how you'd overcome the gcc one: The MS calling convention
>> support is still going to be needed (not having looked at the patches
> Right, I forgot about that one.
>
>> themselves yet, I can't see myself accepting the introduction of
>> stubs to convert between calling conventions).

How about __attribute__((ms_abi)) ?  It would appear to exist for this
purpose.

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] hvmloader: remove timestamp from smbios

[Jan Beulich]

>>> On 04.02.15 at 09:42,  wrote:
> On Wed, Feb 04, Jan Beulich wrote:
> 
>> http://dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf 
>> (in particular section 7.1 and table 5)
> 
> "The date string, if supplied, is in either mm/dd/yy or mm/dd/ format."
> 
> To me it sounds like an optional thing. An empty string is as
> informative as any other random date. 

Please, again, be considerate of utilities looking for such information
even if the specification calls it optional. As pointed out before, there
are ways to achieve your goal of reproducible builds without dropping
bits of information.

> But before the bikeshedding starts I think its best to turn the
> assignment in the Makefiles from "VAR = VAL" into "VAR ?= VAL". This
> preserves existing practice and gives us the opportunity to pass
> 01/01/1970 as fixed VAL.

I don't think a BIOS date of 1970 will be taken well by various
components. ISTR some Linux versions blacklisting certain
functionality on too old BIOSes. Just grep for DMI_BIOS_DATE in
Linux'es arch/x86/pci/ for examples (there are further uses
elsewhere).

Jan


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

Re: [Xen-devel] [RFC PATCH V3 09/12] x86/hvm: factor out and rename vm_event related functions into separate file

[Jan Beulich]

>>> On 29.01.15 at 22:46,  wrote:
> +static int hvm_event_traps(long parameters, vm_event_request_t *req)
> +{
> +int rc;
> +struct vcpu *curr = current;
> +struct domain *currd = curr->domain;
> +
> +if ( !(parameters & HVMPME_MODE_MASK) )
> +return 0;
> +
> +rc = vm_event_claim_slot(currd, &currd->vm_event->monitor);
> +if ( rc == -ENOSYS )
> +{
> +/* If there was no ring to handle the event, then
> + * simple continue executing normally. */

Coding style.

> +return 1;
> +}
> +else if ( rc < 0 )
> +return rc;

Pointless "else".

> +void hvm_event_cr0(unsigned long value, unsigned long old)
> +{
> +struct vcpu *curr = current;
> +struct domain *currd = curr->domain;
> +vm_event_request_t req = {
> +.reason = VM_EVENT_REASON_MOV_TO_CR0,
> +.vcpu_id = curr->vcpu_id,
> +.data.mov_to_cr.new_value = value,
> +.data.mov_to_cr.old_value = old
> +};
> +
> +long params = currd->arch.hvm_domain.params[HVM_PARAM_MEMORY_EVENT_CR0];

No blank lines between declarations please (they're used to separate
declarations from statements). Also while I can see the need for
"curr", I don't think you need "currd" - it's being used just once.

> --- /dev/null
> +++ b/xen/include/asm-x86/hvm/event.h
> @@ -0,0 +1,40 @@
> +/*
> + * event.h: Hardware virtual machine assist events.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 59 
> Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + */
> +
> +#ifndef __ASM_X86_HVM_EVENT_H__
> +#define __ASM_X86_HVM_EVENT_H__
> +
> +/* Called for current VCPU on crX changes by guest */
> +void hvm_event_cr0(unsigned long value, unsigned long old);
> +void hvm_event_cr3(unsigned long value, unsigned long old);
> +void hvm_event_cr4(unsigned long value, unsigned long old);
> +void hvm_event_msr(unsigned long msr, unsigned long value);
> +/* Called for current VCPU on int3: returns -1 if no listener */
> +int hvm_event_int3(unsigned long gla);
> +int hvm_event_single_step(unsigned long gla);

Either have correct comments for all individual functions or groups
thereof, or none at all. IOW, please be consistent.

> -/* Called for current VCPU on single step: returns -1 if no listener */
> -int hvm_memory_event_single_step(unsigned long gla);

Oddly enough you can't even say you just copied what was there, as
you lost this comment in any case.

Jan


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

Re: [Xen-devel] [RFC PATCH V3 10/12] xen: Introduce monitor_op domctl

[Jan Beulich]

>>> On 29.01.15 at 22:46,  wrote:
> --- /dev/null
> +++ b/xen/arch/x86/monitor.c
> @@ -0,0 +1,197 @@
> +/*
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
> + * License v2 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.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; if not, write to the
> + * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
> + * Boston, MA 021110-1307, USA.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DISABLE_OPTION(option)  \
> +if ( !option->enabled ) \
> +return -EFAULT; \
> +memset(option, 0, sizeof(*option))

This needs to be wrapped in either ({ }) or do { } while (0), allowing
you to drop currently necessary (but suggested to be omitted by
./CODING_STYLE) braces around (some of) its uses below.

> +int monitor_domctl(struct xen_domctl_monitor_op *domctl, struct domain *d)
> +{
> +/*
> + * At the moment only HVM domains are supported. However, event delivery
> + * could be extended to PV domains. See comments below.
> + */
> +if ( !is_hvm_domain(d) )
> +return -ENOSYS;
> +
> +if ( domctl->op != XEN_DOMCTL_MONITOR_OP_ENABLE &&
> + domctl->op != XEN_DOMCTL_MONITOR_OP_DISABLE )
> +return -EFAULT;
> +
> +switch ( domctl->subop )
> +{
> +case XEN_DOMCTL_MONITOR_SUBOP_MOV_TO_CR0:
> +{
> +/* Note: could be supported on PV domains. */
> +struct mov_to_cr0 *options = &d->arch.monitor_options.mov_to_cr0;
> +
> +if ( domctl->op == XEN_DOMCTL_MONITOR_OP_ENABLE )
> +{
> +if ( options->enabled )
> +return -EBUSY;
> +
> +options->enabled = 1;
> +options->sync = domctl->options.mov_to_cr0.sync;
> +options->onchangeonly = domctl->options.mov_to_cr0.onchangeonly;

Shouldn't you set "->enabled" last, after a suitable barrier (and with
the consuming sides using suitable barriers too)? Or are you missing
a domain_pause() here?

> +}
> +else
> +{
> +DISABLE_OPTION(options);
> +}
> +break;
> +}
> +case XEN_DOMCTL_MONITOR_SUBOP_MOV_TO_CR3:

Please consistently have blank lines between individual, not falling
through cases.

> +default:
> +return -EFAULT;

Certainly not.

> @@ -1179,6 +1180,16 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  }
>  break;
>  
> +case XEN_DOMCTL_monitor_op:
> +{
> +ret = -EPERM;
> +if ( current->domain == d )
> +break;
> +
> +ret = monitor_domctl(&op->u.monitor_op, d);
> +}
> +break;

Pointless braces.

> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -617,16 +617,10 @@ int vm_event_domctl(struct domain *d, 
> xen_domctl_vm_event_op_t *vec,
>  switch( vec->op )
>  {
>  case XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE:
> -case XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION:
>  {
>  rc = vm_event_enable(d, vec, ved, _VPF_mem_access,
>  HVM_PARAM_MONITOR_RING_PFN,
>  mem_access_notification);
> -
> -if ( vec->op == 
> XEN_DOMCTL_VM_EVENT_OP_MONITOR_ENABLE_INTROSPECTION
> - && !rc )
> -p2m_setup_introspection(d);
> -
>  }
>  break;

The braces should now be removed too.

> @@ -635,7 +629,6 @@ int vm_event_domctl(struct domain *d, 
> xen_domctl_vm_event_op_t *vec,
>  if ( ved->ring_page )
>  {
>  rc = vm_event_disable(d, ved);
> -d->arch.hvm_domain.introspection_enabled = 0;
>  }

And again. Please go through all of the modification the series makes
and adjust for coding style.

> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -236,6 +236,41 @@ struct time_scale {
>  u32 mul_frac;
>  };
>  
> +//
> +/*monitor event options */
> +//
> +struct mov_to_cr0 {
> +uint8_t enabled;
> +uint8_t sync;
> +uint8_t onchangeonly;
> +};
> +
> +struct mov_to_cr3 {
> +uint8_t enabled;
> +uint8_t sync;
> +uint8_t onchangeonly;
> +};
> +
> +struct mov_to_cr4 {
> +uint8_t enabled;
> +uint8_t sync;
> +uint8_t onchangeonly;
> +};

As long as they're identical, these should just be a single
struct mov_to_cr, allowing (afaict) further abstraction elsewhere.

> 

[Xen-devel] [v2] Avoid needless EPT table ajustment and cache flush

[Liang Li]

When a guest change it's MTRR MSRs, ajusting EPT table and flushing
cache are needed only when guest has IOMMU device, using need_iommu(d)
can minimize the impact to guest with device assigned, since a guest
may be hot plugged with a device thus there may be dirty cache lines
before need_iommu(d) becoming true, force the p2m_memory_type_changed
and flush_all when the first device is assigned to guest to amend this
issue.

Signed-off-by: Liang Li 
Signed-off-by: Yang Zhang 
Acked-by: Kevin Tian 
---
 xen/arch/x86/hvm/mtrr.c   | 2 +-
 xen/drivers/passthrough/pci.c | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index ee18553..858fb7e 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -791,7 +791,7 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, 
hvm_load_mtrr_msr,
 
 void memory_type_changed(struct domain *d)
 {
-if ( iommu_enabled && d->vcpu && d->vcpu[0] )
+if ( need_iommu(d) && d->vcpu && d->vcpu[0] )
 {
 p2m_memory_type_changed(d);
 flush_all(FLUSH_CACHE);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..b93e7d8 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1365,6 +1365,13 @@ static int assign_device(struct domain *d, u16 seg, u8 
bus, u8 devfn)
 }
 }
 d->need_iommu = 1;
+/*
+ * There may be dirty cache lines when a device is assigned
+ * and before need_iommu(d) becoming true, this will cause
+ * memory_type_changed lose effect if memory type changes.
+ * Call memory_type_changed here to amend this.
+ */
+memory_type_changed(d);
 }
 
 pdev = pci_get_pdev_by_domain(hardware_domain, seg, bus, devfn);
-- 
1.9.1


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

Re: [Xen-devel] [PATCH RFC] xen: arm: Log a warning message when a deprecated hypercall is used

[Ard Biesheuvel]

On 20 January 2015 at 10:52, Ian Campbell  wrote:
> A few folks have been caught out by OSes which call e.g.
> HYPERVISOR_event_channel_op_compat which has been deprecated since
> 3.2.2 (i.e. long before Xen on ARM). Existing x86 code can still
> safely and quietly using those calls, waiting for an unsuspecting ARM
> porter to turn up and trip over it. This turns out to be rather
> perplexing when it happens, since it can be obscured e.g. by various
> conditionals like __XEN_INTERFACE_VERSION__ what is actually being
> called.
>
> Note that I'm making a distinction here between hypercalls which are
> simply not used/implemented on arm (yet) and those which were
> deprecated and replaced by a newer variant prior to Xen on ARM even
> being invented.  The latter will never be implemented on ARM and have
> non-deprecated aliases leading to confusion so those are the ones for
> which a warning is useful.
>
> Signed-off-by: Ian Campbell 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Ard Biesheuvel 
> Cc: Anthony PERARD 
> ---
> RFC since I'm not sure how extreme our reaction ought to be here, e.g.
> I considered domain_crash() or even panic() when in a debug build. A
> XENLOG_DEBUG message is about the most benign of the options.
>
> Jan/Keir, although this is ARM specific I'd welcome your views as
> x86/REST maintainers.
>
> Ard, I've not actually run this -- any chance you could re-b0rk your
> Tianocore image and give it a go?

I get a bunch of lines in my log looking like

(XEN) traps.c:1162:d4v0 d4v0: deprecated hypercall 16

so

Tested-by: Ard Biesheuvel 

-- 
Ard.

> ---
>  xen/arch/arm/traps.c |   30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index ad046e8..89cbde6 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1148,6 +1148,22 @@ die:
>  }
>  #endif
>
> +static register_t do_deprecated_hypercall(void)
> +{
> +struct cpu_user_regs *regs = guest_cpu_user_regs();
> +const register_t op =
> +#ifdef CONFIG_ARM_64
> +!is_32bit_domain(current->domain) ?
> +regs->x16
> +:
> +#endif
> +regs->r12;
> +
> +gdprintk(XENLOG_DEBUG, "%pv: deprecated hypercall %ld\n",
> + current, (unsigned long)op);
> +return -ENOSYS;
> +}
> +
>  typedef register_t (*arm_hypercall_fn_t)(
>  register_t, register_t, register_t, register_t, register_t);
>
> @@ -1167,15 +1183,29 @@ typedef struct {
>  .fn = (arm_hypercall_fn_t) &do_arm_ ## _name,\
>  .nr_args = _nr_args, \
>  }
> +/*
> + * Only use this for hypercalls which were deprecated (i.e. replaced
> + * by something else) before Xen on ARM was created, i.e. *not* for
> + * hypercalls which are simply not yet used on ARM.
> + */
> +#define HYPERCALL_DEPRECATED(_name, _nr_args)   \
> +[ __HYPERVISOR_##_name ] = {\
> +.fn = (arm_hypercall_fn_t) &do_deprecated_hypercall,\
> +.nr_args = _nr_args,\
> +}
> +
>  static arm_hypercall_t arm_hypercall_table[] = {
>  HYPERCALL(memory_op, 2),
>  HYPERCALL(domctl, 1),
>  HYPERCALL(sched_op, 2),
> +HYPERCALL_DEPRECATED(sched_op_compat, 2),
>  HYPERCALL(console_io, 3),
>  HYPERCALL(xen_version, 2),
>  HYPERCALL(xsm_op, 1),
>  HYPERCALL(event_channel_op, 2),
> +HYPERCALL_DEPRECATED(event_channel_op_compat, 1),
>  HYPERCALL(physdev_op, 2),
> +HYPERCALL_DEPRECATED(physdev_op_compat, 1),
>  HYPERCALL(sysctl, 2),
>  HYPERCALL(hvm_op, 2),
>  HYPERCALL(grant_table_op, 3),
> --
> 1.7.10.4
>

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

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

[xen . org]

flight 34128 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34128/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass

version targeted for testing:
 libvirt  b38da58423f44035e259e18a35853c16267ec83a
baseline version:
 libvirt  a2bdfa5261a664c8833caa57352ce3730b0b7aa5


People who touched revisions under test:
  Daniel P. Berrange 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Michal Privoznik 
  Pavel Hrdina 
  Peter Krempa 
  Tony Krowiak 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt fail
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  fail



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Pushing revision :

+ branch=libvirt
+ revision=b38da58423f44035e259e18a35853c16267ec83a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt 
b38da58423f44035e259e18a35853c16267ec83a
+ branch=libvirt
+ revision=b38da58423f44035e259e18a35853c16267ec83a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock 
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/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.xensource.com:/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://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/

Re: [Xen-devel] [RFC PATCH V3 11/12] xen/vm_event: Decouple vm_event and mem_access.

[Jan Beulich]

>>> On 29.01.15 at 22:46,  wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -52,9 +52,10 @@ obj-y += tmem_xen.o
>  obj-y += radix-tree.o
>  obj-y += rbtree.o
>  obj-y += lzo.o
> +obj-y += vm_event.o
> +obj-y += monitor.o

Please make the (not) sorting situation worse than it already is - the
original intention was for entries to be alphabetically sorted here.

> --- /dev/null
> +++ b/xen/common/monitor.c
> @@ -0,0 +1,64 @@
> +/**
> + * monitor.c
> + *
> + * VM event monitor support.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +void monitor_resume(struct domain *d)
> +{
> +vm_event_response_t rsp;
> +
> +/* Pull all responses off the ring. */
> +while ( vm_event_get_response(d, &d->vm_event->monitor, &rsp) )
> +{
> +struct vcpu *v;
> +
> +if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
> +continue;
> +
> +#ifndef NDEBUG
> +if ( rsp.flags & VM_EVENT_FLAG_DUMMY )
> +continue;
> +#endif

This code was unconditional in the original function. Such a change
needs mentioning in the description.

> @@ -49,7 +53,7 @@ int mem_access_send_req(struct domain *d, 
> vm_event_request_t *req)
>  return -ENOSYS;
>  }
>  
> -static inline void mem_access_resume(struct domain *d) {}
> +static inline void mem_access_resume(struct vcpu *vcpu, vm_event_response_t 
> *rsp) {}

Long line.

> --- /dev/null
> +++ b/xen/include/xen/monitor.h
> @@ -0,0 +1,38 @@
> +/**
> + * monitor.h
> + *
> + * Monitor event support.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#ifndef _XEN_ASM_MONITOR_H
> +#define _XEN_ASM_MONITOR_H
> +
> +#include 

This can't be enough (nor can I see why it's needed here), or else ...

> +/* Resumes the running of the VCPU, restarting the last instruction */
> +void monitor_resume(struct domain *d);

... struct domain may end up being a forward reference (with scope
restricted to monitor_resume()).

Jan


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

Re: [Xen-devel] [RFC PATCH V3 12/12] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds

[Jan Beulich]

>>> On 29.01.15 at 22:46,  wrote:
> The flag is only used for debugging purposes, thus it should be only checked
> for in debug builds of Xen.

So this should be where the respective conditional I just complained
about should get added.


> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -30,6 +30,37 @@
>  #include 
>  #include 
>  
> +void mem_access_resume(struct domain *d)
> +{

Why is this being re-added, and how do things build with the other
(inline) mem_access_resume() added in an earlier patch?

Jan


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

Re: [Xen-devel] [PATCH 00/18] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 04.02.15 at 10:04,  wrote:
> On 03/02/2015 17:14, Daniel Kiper wrote:
>> On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wrote:
>> On 30.01.15 at 18:54,  wrote:
   - xen.efi build will not so strongly depend
 on a given GCC and binutils version.
>>> While I can see the possibility of making the binutils version
>>> dependency go away (by manually creating the PE header), I can't
>>> see how you'd overcome the gcc one: The MS calling convention
>>> support is still going to be needed (not having looked at the patches
>> Right, I forgot about that one.
>>
>>> themselves yet, I can't see myself accepting the introduction of
>>> stubs to convert between calling conventions).
> 
> How about __attribute__((ms_abi)) ?  It would appear to exist for this
> purpose.

But that's the point: Older compilers don't support it. And with
compilers supporting it we need no stubs.

Jan


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

[Xen-devel] [PATCH OSSTEST] ts-logs-capture: ensure captured log files are readable.

[Ian Campbell]

At least /var/log/libvirt/libvirtd.log is 0600 on the target machine
and this gets preserved in the captured logfile, eventually meaning
that apache on the log server cannot read the file to serve it ("You
don't have permission to access...").

There seems to be no harm in setting all log files to 0664, so do so.

Signed-off-by: Ian Campbell 
---
Currently visible at
http://www.chiark.greenend.org.uk/~xensrcts/logs/34114/test-armhf-armhf-libvirt/marilith-n4---var-log-libvirt-libvirtd.log
but not mentioning in the commit log since it'll go away before long.
---
 ts-logs-capture | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-logs-capture b/ts-logs-capture
index dbca13a..5a994c7 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -59,6 +59,7 @@ END
 logm("fetching $logfile to $llogfile");
 if (!eval {
 target_getfile_root($lho,60, $logfile,"$stash/$llogfile");
+   chmod(0664, "$stash/$llogfile") or die "chmod $stash/$llogfile 
$!";
if ($logfile !~ m/\.gz$/) {
stat("$stash/$llogfile") or die "$stash/$llogfile $!";
compress_stashed($llogfile) if(stat _)[7] > 10;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH RFC] xen: arm: Log a warning message when a deprecated hypercall is used

[Ian Campbell]

On Wed, 2015-02-04 at 09:41 +, Ard Biesheuvel wrote:
> On 20 January 2015 at 10:52, Ian Campbell  wrote:
> > A few folks have been caught out by OSes which call e.g.
> > HYPERVISOR_event_channel_op_compat which has been deprecated since
> > 3.2.2 (i.e. long before Xen on ARM). Existing x86 code can still
> > safely and quietly using those calls, waiting for an unsuspecting ARM
> > porter to turn up and trip over it. This turns out to be rather
> > perplexing when it happens, since it can be obscured e.g. by various
> > conditionals like __XEN_INTERFACE_VERSION__ what is actually being
> > called.
> >
> > Note that I'm making a distinction here between hypercalls which are
> > simply not used/implemented on arm (yet) and those which were
> > deprecated and replaced by a newer variant prior to Xen on ARM even
> > being invented.  The latter will never be implemented on ARM and have
> > non-deprecated aliases leading to confusion so those are the ones for
> > which a warning is useful.
> >
> > Signed-off-by: Ian Campbell 
> > Cc: Jan Beulich 
> > Cc: Keir Fraser 
> > Cc: Ard Biesheuvel 
> > Cc: Anthony PERARD 
> > ---
> > RFC since I'm not sure how extreme our reaction ought to be here, e.g.
> > I considered domain_crash() or even panic() when in a debug build. A
> > XENLOG_DEBUG message is about the most benign of the options.
> >
> > Jan/Keir, although this is ARM specific I'd welcome your views as
> > x86/REST maintainers.
> >
> > Ard, I've not actually run this -- any chance you could re-b0rk your
> > Tianocore image and give it a go?
> 
> I get a bunch of lines in my log looking like
> 
> (XEN) traps.c:1162:d4v0 d4v0: deprecated hypercall 16
> 
> so
> 
> Tested-by: Ard Biesheuvel 

Thanks!



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

Re: [Xen-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough

[Ian Campbell]

On Wed, 2015-02-04 at 09:34 +0800, Chen, Tiejun wrote:
> >
> >>   "-machine xxx,igd-passthru=on", to enable/disable that feature.
> >>   And we also remove that old option, "-gfx_passthru", just from
> >>   the case of LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN since actually
> >>   no any qemu stream version really need or use that.
> > ^up ?
> >
> > What happens if you pass this new option to an older version of qemu
> > upstream? I suppose it doesn't fail any worse than passing -gfx_passthru
> > would have done.
> 
> Neither '-gfx_passthru' nor 'igd-passthrou' exists in any version of 
> qemu upstream. As I mentioned previously, just now we're starting to 
> support this in qemu upstream :)
> 
> But you known, on Xen side we have two qemu versions, 
> qemu-xen-traditional and qemu-xen. Although '-gfx_passthru' is adopted 
> in both two versions, just qemu-xen-traditional supports IGD passthrough 
> completely. For qemu-xen, we just have this term definition but without 
> that IGD passthrough feature support actually.

I'm afraid I don't follow, you seem to be simultaneously saying that
qemu-xen both does and does not support -gfx_passthru, which cannot be
right. I think from the following paragraph that what you mean is that
upstream qemu-xen has no support for any kind of -gfx_passthru command
line option in any form in any existing version, including the git tree.
Is that correct?

(for the purposes of this conversation qemu-traditional is not of
interest)

> And now we're trying to support IGD passthrough in qemu stream. This 
> mean we should set 'device_model_version="qemu-xen", right? Then libxl 
> still pass '-gfx_passthru' to qemu upstream. But when I post other 
> stuffs to qemu upstream community to support IGD passthrough. Gerd 
> thought "-machine xxx,igd-passthru=on" is better than '-gfx_passthru'. 
> So finally you see this change in Xen/tools/libxl.
> 
> >
> > I have one more general concern, which is that hardcoding igd-passthru
> > here may make it harder to support gfx_passthru of other cards in the
> > future.
> 
> Actually gfx_passthrou is introduced to just work for IGD passthrough 
> since something specific to IGD is tricky, so we have to need such a 
> flag to handle this precisely, like its fixed at 00:02.0, and expose 
> some ISA bridge PCI config info and even host bridge PCI config info.
> 
> So I don't thing other cards need this.

If one type VGA device needs these sorts of workaround it is not
inconceivable that some other one will also need workarounds in the
future.

Even if you don't consider non-IGD, what about the possibility of a
future IGD device which needs different (or additional, or fewer)
workarounds?

> > Somehow something in the stack needs to either detect or be told which
> > kind of card to passthrough. Automatic detection would be preferable,
> > but maybe being told by the user is the only possibility.
> 
> Based on the above explanation, something should be done before we 
> detect to construct that real card , so its difficulty to achieve this 
> goal currently.
> 
> >
> > Is there any way, given gfx_passthru as a boolean that libxl can
> > automatically figure out that IGD passthru is what is actually desired
> > -- e.g. by scanning the set of PCI devices given to the guest perhaps?
> 
> Sorry I don't understand what you mean here.

"gfx_passthru" is a generically named option, but it is being
implemented in an IGD specific way. We need to consider the possibility
of other graphics devices needing special handling in the future and
plan accordingly such that we can try and maintain our API guarantees
when this happens.

I think there are three ways to achieve that:

  * Make the libxl/xl option something which is not generic e.g.
igd_passthru=1
  * Add a second option to allow the user to configure the kind of
graphics device being passed thru (e.g. gfx_passthru=1,
passthru_device="igd"), or combine the two by making the
gfx_passthru option a string instead of a boolean.
  * Make libxl detect the type of graphics device somehow and
therefore automatically determine when gfx_passthru=1 =>
igd-passthru

>  Currently, we have to set 
> something as follows,
> 
> gfx_passthru=1
> pci=["00:02.0"]
> 
> This always works for qemu-xen-traditional.
> 
> But you should know '00:02.0' doesn't mean we are passing IGD through.

But by looking at the device 00:02.0 (e.g. its PCI vendor and device ID
and other properties) we can unambiguously determine if it is an IGD
device or not, can't we?

> > If not then that _might_ suggest we should deprecate the gdx_passthru
> > option at the libxl interface and switch to something more expressive,
> > such as an Enumeration of card types (with a singleton of IGD right
> > now), but I'm not really very familiar with passthru nor the qemu side
> > of this.
> >
> > What happens if you try to pass two different GFX cards to a guest?
> >
> 

Re: [Xen-devel] Xen's Linux kernel config options V2

[David Vrabel]

On 16/12/14 16:21, Juergen Gross wrote:
> Hi,
> 
> This is a design proposal for a rework of the config options on the
> Linux kernel which are related to Xen.
> 
> The need to do so arose from the fact that it is currently not
> possible to build the Xen frontend drivers for a non-pvops kernel,
> e.g. to run them in a HVM-domain. There are more drawbacks in the
> current config options to which I'll come later.
> 
> Option  Selects Depends
> --
> XEN
>   XEN_PV(x86)   XEN_HAVE_PVMMU
> PARAVIRT
> PARAVIRT_CLOCK
>   XEN_PVH(x86)  XEN_PVHVM
> PARAVIRT
> PARAVIRT_CLOCK
>   XEN_PVHVM PARAVIRT
> PARAVIRT_CLOCK
>   XEN_BACKEND   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
> XEN_PVH(x86) ||
> XEN_PVHVM
> XEN_BLKDEV_BACKEND
> XEN_PCIDEV_BACKEND(x86)
> XEN_SCSI_BACKEND
> XEN_NETDEV_BACKEND
>   PCI_XEN(x86)  SWIOTLB_XEN
>   XEN_DOM0  XEN_BACKEND XEN_PV(x86) ||
> PCI_XEN(x86)XEN_PVH(x86)
> XEN_ACPI_HOTPLUG_MEMORY XEN_STUB
> XEN_ACPI_HOTPLUG_CPUXEN_STUB
> XEN_MCE_LOG(x86)
>   XEN_MAX_DOMAIN_MEMORY(x86)
>   XEN_SAVE_RESTORE(x86)
>   XEN_DEBUG_FS
>   XEN_WDT
>   XEN_BALLOON
> XEN_SELFBALLOONING  XEN_TMEM
> XEN_BALLOON_MEMORY_HOTPLUG
> XEN_SCRUB_PAGES
>   XENFS XEN_PRIVCMD
> XEN_COMPAT_XENFS
>   XEN_SYS_HYPERVISOR
>   XEN_DEV_EVTCHN
>   XEN_GNTDEV
>   XEN_GRANT_DEV_ALLOC
>   SWIOTLB_XEN
>   XEN_TMEM
>   XEN_PRIVCMD
>   XEN_STUB(x86_64)  BROKEN
>   XEN_ACPI_PROCESSOR(x86)
>   XEN_HAVE_PVMMU
>   XEN_EFI(x64)
>   XEN_XENBUS_FRONTEND
> XEN_FRONTENDXEN
> XEN_XENBUS_FRONTEND
>   XEN_FBDEV_FRONTENDINPUT_XEN_KBDDEV_FRONTEND
>   XEN_BLKDEV_FRONTEND
>   HVC_XEN_FRONTEND  HVC_XEN
>   TCG_XEN
>   XEN_PCIDEV_FRONTEND   PCI_XEN
>   XEN_SCSI_FRONTEND
>   INPUT_XEN_KBDDEV_FRONTEND
>   XEN_NETDEV_FRONTEND
>   XEN_PLATFORM_PCI

This looks fine to me.

David

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

Re: [Xen-devel] Request for help, implementing a new network scheduler

[Wei Liu]

Add xen-devel back on Cc list.

And please don't top-post.

On Tue, Feb 03, 2015 at 09:26:20PM +0100, ronald pina wrote:
> Thanks Wei, it was useful, my primary goal is to contribute on improving
> the latency and jitter on xen, that is  my purpose not to implement a
> general QoS linux scheduler, the basic idea is  prioritize real-time
> traffic which have critical requirements to QoS especially on heavy network
> i/o hosts, and if the vifs of different guest are scheduled on round robin
> manner in dom0 backend than we can improve this scheduling algorithm like
> using weighted round robin which can give more scheduling time to a vif
> that was used by a  voip-server guest.
> 

As Ian and Zoli suggested, there might be already tools that can achieve
your goal. Your idea to improve latency and jitter  is certainly
valuable, but I would suggest you do through research on existing tools.
That would help you understand the strength and weakness of existing
tools, as well as the strength and weakness of your own idea.

If you have any problem with regard to netback driver, feel free to post
on xen-devel. However I don't have much knowledge on Linux scheduler so
I cannot comment on the round robin and QoS part.  :-)

Wei.

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

Re: [Xen-devel] [PATCH] x86: re-order struct arch_domain fields

[Andrew Cooper]

On 03/02/15 09:45, Jan Beulich wrote:
 On 19.01.15 at 18:52,  wrote:
>> On 19/01/15 15:41, Jan Beulich wrote:
>>> ... to reduce padding holes. While doing this I noticed vtsc_usercount
>>> is a PV-only thing, so it gets moved straight to struct pv_domain.
>> The vtsc_{user,kernel}count split is curious.  They are both for stats
>> purposes alone, but there is nothing pv specific about the usercount. 
>> It frankly looks as if it has been mis-implemented for HVM, despite the
>> split appearing to be deliberate when it was introduced in c/s
>> bf2c44f8b469.  I am really not sure what to make of it.
> Since I didn't hear back on my earlier response, I looked at this again:
> Considering especially the explicit callers of hvm_get_guest_tsc_fixed(),
> I also wonder whether the accounting for HVM makes sense in the
> first place - to me, these two numbers are meant to be _only_ counting
> actual emulations. Hence I first of all would think this ought to be
> moved into hvm_rdtsc_intercept() (and maybe mirrored in
> hvm_msr_read_intercept(), perhaps by refactoring the former to be
> usable by the latter).
>
> In that case it would indeed make sense to keep the user count for
> non-PV, as then it really makes sense to check for user/kernel mode
> there.
>
> Jan
>

I agree with your analysis.  Now that you point it out, the current code
does look wrong.

~Andrew


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

Re: [Xen-devel] Hackathon date options in Shanghai : please vote for a preference by Wed the 3rd of Feb (confirmed Option 2: April 28-29)

[Lars Kurth]

Hi all,
seems the overwhelming majority has chosen - Option 2: April 28-29 - I will 
work with Intel on the details and send these out as soon as I have final 
confirmation
Best Regards
Lars

On 28 Jan 2015, at 10:09, Lars Kurth  wrote:

> Dear community members,
> 
> Intel has volunteered to host the next Xen Project Hackathon in Shanghai in 
> China. We were originally looking at an April/May time-frame, but due to 
> Easter holidays and the OpenStack summit in May, the following two date 
> options look most sensible.
> 
> Remember, this is a two day event.
> 
> The options are:
> * Option 1: 2 days from Tue April 21 to Fri 24th ... In this case I would 
> suggest maybe the 22 - 23rd, giving people a chance to meet customers on 
> Friday and/or do a bit of sightseeing. It also means that attendees from 
> other Chinese cities will be able to get to their home cities more easily 
> (Friday is always extremely busy)
> * Option 2: April 28-29
> 
> Please let me know if you have any preferences and vote for option 1 or 2 (if 
> you vote for option 1 let me know if you care about any specific dates)
> 
> Regards
> Lars


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

Re: [Xen-devel] [rumpuserxen test] 34129: regressions - FAIL

[Martin Lucina]

Caused by:

> commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c
> Author: Martin Lucina 
> Date:   Mon Feb 2 18:00:36 2015 +0100
> 
> Remove even older rumpxen-app-* variants of app-tools
> 
> Signed-off-by: Martin Lucina 

bash: line 14: 
/home/osstest/build.34129.build-amd64-rumpuserxen/rumpuserxen/app-tools/rumpxen-app-configure:
 No such file or directory

Ian, can you update osstest to use rumprun-xen-configure as discussed on
rumpkernel-users? 

Thanks,

Martin

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

Re: [Xen-devel] [rumpuserxen test] 34129: regressions - FAIL

[Ian Campbell]

On Wed, 2015-02-04 at 12:21 +0100, Martin Lucina wrote:
> Caused by:
> 
> > commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c
> > Author: Martin Lucina 
> > Date:   Mon Feb 2 18:00:36 2015 +0100
> > 
> > Remove even older rumpxen-app-* variants of app-tools
> > 
> > Signed-off-by: Martin Lucina 
> 
> bash: line 14: 
> /home/osstest/build.34129.build-amd64-rumpuserxen/rumpuserxen/app-tools/rumpxen-app-configure:
>  No such file or directory
> 
> Ian, can you update osstest to use rumprun-xen-configure as discussed on
> rumpkernel-users? 

I think we also need Wei's patch from
<1422971228-4320-1-git-send-email-wei.l...@citrix.com> / 
http://article.gmane.org/gmane.comp.emulators.xen.devel/230968

to deal with:

commit 91d56232d987f5df594723ed46b9000b4d43e21a
Author: Martin Lucina 
Date:   Mon Feb 2 17:52:41 2015 +0100

Renaming platform macros, app-tools and autoconf target string

As discussed at: 
http://thread.gmane.org/gmane.comp.rumpkernel.user/739

This commit renames the platform macros, app-tools and autoconf 
target
string to be consistent with current naming of the entire stack:

app-tools/rumpapp-xen-* -> app-tools/rumprun-xen-*
$ARCH-rumpxen-netbsd -> $ARCH-rumprun-netbsd
-D__RUMPUSER_XEN__ -D__RUMPAPP__ -> -D__RUMPRUN__

Signed-off-by: Martin Lucina 

Ian.


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

[Xen-devel] [PATCH] ts-rumpuserxen-build: Use new app-tools

[Martin Lucina]

ian.campb...@citrix.com said:
> On Wed, 2015-02-04 at 12:21 +0100, Martin Lucina wrote:
> > Caused by:
> > 
> > > commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c
> > > Author: Martin Lucina 
> > > Date:   Mon Feb 2 18:00:36 2015 +0100
> > > 
> > > Remove even older rumpxen-app-* variants of app-tools
> > > 
> > > Signed-off-by: Martin Lucina 
> > 
> > bash: line 14: 
> > /home/osstest/build.34129.build-amd64-rumpuserxen/rumpuserxen/app-tools/rumpxen-app-configure:
> >  No such file or directory
> > 
> > Ian, can you update osstest to use rumprun-xen-configure as discussed on
> > rumpkernel-users? 
> 
> I think we also need Wei's patch from
> <1422971228-4320-1-git-send-email-wei.l...@citrix.com> / 
> http://article.gmane.org/gmane.comp.emulators.xen.devel/230968

Ack. Patch to update Osstest follows.

>From ff80800099956e429df65bdf7669083cf5c5a8df Mon Sep 17 00:00:00 2001
From: Martin Lucina 
Date: Wed, 4 Feb 2015 12:31:33 +0100
Subject: [PATCH] ts-rumpuserxen-build: Use new app-tools

Osstest was using old names for rumprun-xen app-tools. These have been
removed in rumprun-xen commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c.

Update to use the new app-tools names.

Signed-off-by: Martin Lucina 
---
 ts-rumpuserxen-build |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-rumpuserxen-build b/ts-rumpuserxen-build
index 47bcf76..916100b 100755
--- a/ts-rumpuserxen-build
+++ b/ts-rumpuserxen-build
@@ -98,7 +98,7 @@ END
 }
 
 sub recordtools() {
-my $apptool = "$rux/app-tools/rumpxen-app";
+my $apptool = "$rux/app-tools/rumprun-xen";
 store_runvar('cmdprefix_configure', "$apptool-configure");
 store_runvar('cmdprefix_make',  "$apptool-make");
 }
-- 
1.7.10.4


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

Re: [Xen-devel] Request for help, implementing a new network scheduler

[Zoltan Kiss]

Hi,

On 03/02/15 19:55, ronald pina wrote:

Thanks Zoli for your clear and very helpfull answer, my idea is to
prioritize traffic that comes from different guest, for example if
guest_1 is used for a voip server than it would be reasonable to
schedule first the vif guest_1 before other guests. The diagram atached
below explains better my idea. The goal is to improve the latency and
jitter for real-time traffic which have critical requirements to QoS
especially on heavy network i/o hosts, and if the vifs of different
guest are scheduled on round robin manner in dom0 backend than we can
improve this scheduling algorithm like using weighted round robin which
can give more scheduling time to a vif that was used by a  voip-server
guest. I would like to know that which module or function is responsible
for scheduling vif on dom0 ?


As I said, it is a NAPI polling function:

http://www.linuxfoundation.org/collaborate/workgroups/networking/napi

So it is scheduled by NAPI, which doesn't have a clue about what kind of 
packets the device dealing with, therefore can't make a decision based 
on that. You can try manually configure the weight of a device through 
netif_napi_add(), but I strongly recommend to look for other ways I 
mentioned in my previous letter.




Thanks
Ronald

On Tue, Feb 3, 2015 at 12:54 PM, Zoltan Kiss mailto:zoltan.k...@linaro.org>> wrote:



On 03/02/15 00:42, Ronald PIna wrote:

Hi

I am working for the msc thesis to improve the performance on
network
for guest domains that uses real-time services like voip or video
streaming servers , i have an idea to implement a network
scheduler on
network backend, the schedulers may be weighted fair queuing or
weighted
round robin,  the idea is to schedule first the packet coming from
real-time guest services, one of those schedulers could make the
job and
can prioritize the network traffic.

As far as i have studied from previous works explain that the
outgoing
network traffic in xen is scheduled in round robin manner inside the
function net_tx_action(). Later on the last version of xen this
function
has changed xenvif_tx_action() and have changed his primarily
structure.
My primarily goal is to modify the round robin to more advanced
scheduler  which introduce priorities. The clear question is
that where
is located the function which schedule in round robin and if
possible
are there any concern about using another network scheduling
method in
netback ?

xenvif_tx_action is called from NAPI polling context, per queue. It
copies & maps the packets from the guest to Dom0 (at which point it
doesn't have the slightest idea about the packet content), formats
them in xenvif_tx_submit to be a well formed skb, and calls
netif_receive_skb to hand it over to the stack.
You could try doing some reordering in xenvif_tx_submit or
introducing priorities in the ring buffer, but I would strongly
discourage you to do that, for similar reasons mentioned by Ian. You
would be better off using standard Linux tools for doing that, see
'man tc', and I would try on the sending side, in the guest, before
netfront gets the packet.
Or, if your idea is to prioritize between traffic coming from
separate guests, then xenvif_tx_action is definitely the wrong place
to do that: as said above, it deals only with the traffic of one
particular queue of a netback device. You might want to look into
the entity switching/routing between the guests and NICs: Linux
bridge module, openvswitch, the IP routing engine of the backend
etc. I think the first two could be the reasonable choices, bridge
might lacks such functionality though.

Zoli




Thanks in advance

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




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

[Xen-devel] [PATCH OSSTEST] ts-logs-capture: ensure captured log files are readable.

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST] ts-logs-capture: ensure captured log 
files are readable."):
> At least /var/log/libvirt/libvirtd.log is 0600 on the target machine
> and this gets preserved in the captured logfile, eventually meaning
> that apache on the log server cannot read the file to serve it ("You
> don't have permission to access...").
> 
> There seems to be no harm in setting all log files to 0664, so do so.
...
> + chmod(0664, "$stash/$llogfile") or die "chmod $stash/$llogfile 
> $!";

I think this is an unwarranted assumption about the umask, sadly.

Maybe you want  0666&~umask  ?

Ian.

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

Re: [Xen-devel] [PATCH v9 0/3] enable Memory Bandwidth Monitoring (MBM) for VMs

[Chao Peng]

On Wed, Feb 04, 2015 at 08:53:28AM +, Jan Beulich wrote:
> >>> On 04.02.15 at 09:39,  wrote:
> > On Mon, Feb 02, 2015 at 04:06:06PM +0800, Chao Peng wrote:
> >> Changes from v8:
> >> * Merge event mask patch to MBM enabling patch;
> >> * Address comments from Ian Campbell(Detail in patch itself).
> > 
> > Any comments on this revision?
> 
> Please be a little more patient before pinging - you only sent this
> 2 days ago. Please allow for at least a week.

Not urgent :) . Please ignore the noise.

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

[Xen-devel] [PATCH OSSTEST v2] ts-logs-capture: ensure captured log files are readable.

[Ian Campbell]

At least /var/log/libvirt/libvirtd.log is 0600 on the target machine
and this gets preserved in the captured logfile, eventually meaning
that apache on the log server cannot read the file to serve it ("You
don't have permission to access...").

Set all logfiles to 0666, modified by umask.

Signed-off-by: Ian Campbell 
---
v2: Honour umask

Currently visible at
http://www.chiark.greenend.org.uk/~xensrcts/logs/34114/test-armhf-armhf-libvirt/marilith-n4---var-log-libvirt-libvirtd.log
but not mentioning in the commit log since it'll go away before long.
---
 ts-logs-capture | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-logs-capture b/ts-logs-capture
index dbca13a..453b03d 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -59,6 +59,7 @@ END
 logm("fetching $logfile to $llogfile");
 if (!eval {
 target_getfile_root($lho,60, $logfile,"$stash/$llogfile");
+   chmod(0666&~umask, "$stash/$llogfile") or die "chmod 
$stash/$llogfile $!";
if ($logfile !~ m/\.gz$/) {
stat("$stash/$llogfile") or die "$stash/$llogfile $!";
compress_stashed($llogfile) if(stat _)[7] > 10;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] ts-rumpuserxen-build: Use new app-tools

[Ian Campbell]

On Wed, 2015-02-04 at 12:36 +0100, Martin Lucina wrote:
> ian.campb...@citrix.com said:
> > On Wed, 2015-02-04 at 12:21 +0100, Martin Lucina wrote:
> > > Caused by:
> > > 
> > > > commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c
> > > > Author: Martin Lucina 
> > > > Date:   Mon Feb 2 18:00:36 2015 +0100
> > > > 
> > > > Remove even older rumpxen-app-* variants of app-tools
> > > > 
> > > > Signed-off-by: Martin Lucina 
> > > 
> > > bash: line 14: 
> > > /home/osstest/build.34129.build-amd64-rumpuserxen/rumpuserxen/app-tools/rumpxen-app-configure:
> > >  No such file or directory
> > > 
> > > Ian, can you update osstest to use rumprun-xen-configure as discussed on
> > > rumpkernel-users? 
> > 
> > I think we also need Wei's patch from
> > <1422971228-4320-1-git-send-email-wei.l...@citrix.com> / 
> > http://article.gmane.org/gmane.comp.emulators.xen.devel/230968
> 
> Ack. Patch to update Osstest follows.
> 
> From ff80800099956e429df65bdf7669083cf5c5a8df Mon Sep 17 00:00:00 2001
> From: Martin Lucina 
> Date: Wed, 4 Feb 2015 12:31:33 +0100
> Subject: [PATCH] ts-rumpuserxen-build: Use new app-tools
> 
> Osstest was using old names for rumprun-xen app-tools. These have been
> removed in rumprun-xen commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c.
> 
> Update to use the new app-tools names.

I'm not sure if we need to support bisection over this change -- but I
think we probably do (Ian?) in which case we would need to probe for
which one actually exists, preferring the newer name.

Ian?

> 
> Signed-off-by: Martin Lucina 
> ---
>  ts-rumpuserxen-build |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ts-rumpuserxen-build b/ts-rumpuserxen-build
> index 47bcf76..916100b 100755
> --- a/ts-rumpuserxen-build
> +++ b/ts-rumpuserxen-build
> @@ -98,7 +98,7 @@ END
>  }
>  
>  sub recordtools() {
> -my $apptool = "$rux/app-tools/rumpxen-app";
> +my $apptool = "$rux/app-tools/rumprun-xen";
>  store_runvar('cmdprefix_configure', "$apptool-configure");
>  store_runvar('cmdprefix_make',  "$apptool-make");
>  }



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

Re: [Xen-devel] Stubdom breakage in 4.5

[Ian Campbell]

On Tue, 2015-02-03 at 14:11 +, Paul Durrant wrote:
> How about this as a slightly hacky solution that I think may work in both 
> cases?
> 
> If Xen finds no emulator at all for an HVM guest then it waits around
> for at least one to show up before processing an emulation request.
> Until one does it stalls the vcpu in question indefinitely, but on the
> first emulator attach (i.e. ioreq server creations) then the IO will
> always be processed, even if it doesn't match the ioreq server.

It sounds plausible to me and seems like it would probably be
backportable.

Longer term I think we still need to fix the domain creation interlock
for launching multiple qemu's, ioreq servers and any other type of
service thing we might launch (whether in a stub dom or not), at which
point we may be able to remove the above workaround too.

Ian.




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

[Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Andrew Cooper]

The xen event channel for the ioreq server must be targeted at the appropriate
vcpu, so the correct one can be unpaused when IO is completed.

Signed-off-by: Andrew Cooper 
CC: Jan Beulich 

---

The cosmetic tweaks were not completely cosmetic.
---
 xen/arch/x86/hvm/hvm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b03ee4e..4b7792d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -638,7 +638,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 {
 struct domain *d = s->domain;
 
-rc = alloc_unbound_xen_event_channel(v->domain, 0, s->domid, NULL);
+rc = alloc_unbound_xen_event_channel(v->domain, v->vcpu_id, s->domid, 
NULL);
 if ( rc < 0 )
 goto fail3;
 
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Jan Beulich]

>>> On 04.02.15 at 13:35,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -638,7 +638,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
> hvm_ioreq_server *s,
>  {
>  struct domain *d = s->domain;
>  
> -rc = alloc_unbound_xen_event_channel(v->domain, 0, s->domid, NULL);
> +rc = alloc_unbound_xen_event_channel(v->domain, v->vcpu_id, 
> s->domid, NULL);

But this sits in a conditional checking v->vcpu_id == 0. I.e. I don't
see what difference this makes.

Jan


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

Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Paul Durrant]

> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Andrew Cooper
> Sent: 04 February 2015 12:35
> To: Xen-devel
> Cc: Andrew Cooper; Jan Beulich
> Subject: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced
> by c58ba78c84
> 
> The xen event channel for the ioreq server must be targeted at the
> appropriate
> vcpu, so the correct one can be unpaused when IO is completed.
> 
> Signed-off-by: Andrew Cooper 
> CC: Jan Beulich 
> 
> ---
> 
> The cosmetic tweaks were not completely cosmetic.

No, they weren't were they.

Reviewed-by: Paul Durrant 

> ---
>  xen/arch/x86/hvm/hvm.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index b03ee4e..4b7792d 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -638,7 +638,7 @@ static int hvm_ioreq_server_add_vcpu(struct
> hvm_ioreq_server *s,
>  {
>  struct domain *d = s->domain;
> 
> -rc = alloc_unbound_xen_event_channel(v->domain, 0, s->domid,
> NULL);
> +rc = alloc_unbound_xen_event_channel(v->domain, v->vcpu_id, s-
> >domid, NULL);
>  if ( rc < 0 )
>  goto fail3;
> 
> --
> 1.7.10.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Paul Durrant]

> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: 04 February 2015 12:46
> To: Andrew Cooper
> Cc: Xen-devel
> Subject: Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression
> introduced by c58ba78c84
> 
> >>> On 04.02.15 at 13:35,  wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -638,7 +638,7 @@ static int hvm_ioreq_server_add_vcpu(struct
> hvm_ioreq_server *s,
> >  {
> >  struct domain *d = s->domain;
> >
> > -rc = alloc_unbound_xen_event_channel(v->domain, 0, s->domid,
> NULL);
> > +rc = alloc_unbound_xen_event_channel(v->domain, v->vcpu_id, s-
> >domid, NULL);
> 
> But this sits in a conditional checking v->vcpu_id == 0. I.e. I don't
> see what difference this makes.

True, but without the context it did appear to be wrong. Perhaps best to go 
with vcpu_id for clarity?

  Paul

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

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

Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Andrew Cooper]

On 04/02/15 12:45, Jan Beulich wrote:
 On 04.02.15 at 13:35,  wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -638,7 +638,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
>> hvm_ioreq_server *s,
>>  {
>>  struct domain *d = s->domain;
>>  
>> -rc = alloc_unbound_xen_event_channel(v->domain, 0, s->domid, NULL);
>> +rc = alloc_unbound_xen_event_channel(v->domain, v->vcpu_id, 
>> s->domid, NULL);
> But this sits in a conditional checking v->vcpu_id == 0. I.e. I don't
> see what difference this makes.
>
> Jan
>

Hmm so it does.

Something between d0b2caa..c58ba78 has broken HVM guests to point at
which HVMloader doesn't reliably function.

Back to debugging...

~Andrew

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

Re: [Xen-devel] Stubdom breakage in 4.5

[Paul Durrant]

> -Original Message-
> From: Ian Campbell
> Sent: 04 February 2015 12:30
> To: Paul Durrant
> Cc: Wei Liu; xen-devel@lists.xen.org; Ian Jackson; Jan Beulich; Andrew
> Cooper; Stefano Stabellini
> Subject: Re: Stubdom breakage in 4.5
> 
> On Tue, 2015-02-03 at 14:11 +, Paul Durrant wrote:
> > How about this as a slightly hacky solution that I think may work in both
> cases?
> >
> > If Xen finds no emulator at all for an HVM guest then it waits around
> > for at least one to show up before processing an emulation request.
> > Until one does it stalls the vcpu in question indefinitely, but on the
> > first emulator attach (i.e. ioreq server creations) then the IO will
> > always be processed, even if it doesn't match the ioreq server.
> 
> It sounds plausible to me and seems like it would probably be
> backportable.
> 

Actually I think it may be even simpler, although I've not tried it. If 
hvm_domain_initialise() pauses the domain and the first 
hvm_ioreq_server_enable() unpauses it, I'm hoping that may be enough.

> Longer term I think we still need to fix the domain creation interlock
> for launching multiple qemu's, ioreq servers and any other type of
> service thing we might launch (whether in a stub dom or not), at which
> point we may be able to remove the above workaround too.
> 

Yes. Once the toolstack is aware it can keep the domain paused until all 
emulators report readiness.

  Paul

> Ian.
> 
> 

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

Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Jan Beulich]

>>> On 04.02.15 at 13:56,  wrote:
> Something between d0b2caa..c58ba78 has broken HVM guests to point at
> which HVMloader doesn't reliably function.

And no crash (with register state dumped) or any other hint as to
what's going wrong?

Jan


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

Re: [Xen-devel] [PATCH] x86/hvm: Fix HVM guest regression introduced by c58ba78c84

[Andrew Cooper]

On 04/02/15 13:00, Jan Beulich wrote:
 On 04.02.15 at 13:56,  wrote:
>> Something between d0b2caa..c58ba78 has broken HVM guests to point at
>> which HVMloader doesn't reliably function.
> And no crash (with register state dumped) or any other hint as to
> what's going wrong?

PV guests are all fine, and mixed PV/HVM tests have the PV side complete
successfully.

~Andrew

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

[Xen-devel] [PATCH v5 3/3] xen/arm: Introduce support for Renesas R-Car Gen2 platform

[Oleksandr Tyshchenko]

From: Iurii Konovalenko 

Signed-off-by: Iurii Konovalenko 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/platforms/Makefile |  1 +
 xen/arch/arm/platforms/rcar2.c  | 71 +
 2 files changed, 72 insertions(+)
 create mode 100644 xen/arch/arm/platforms/rcar2.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..e173fec 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_ARM_32) += exynos5.o
 obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += sunxi.o
+obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
new file mode 100644
index 000..aef544c
--- /dev/null
+++ b/xen/arch/arm/platforms/rcar2.c
@@ -0,0 +1,71 @@
+/*
+ * xen/arch/arm/platforms/rcar2.c
+ *
+ * Renesas R-Car Gen2 specific settings
+ *
+ * Iurii Konovalenko 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define RCAR2_RAM_ADDR 0xE63C
+#define RCAR2_RAM_SIZE 0x1000
+#define RCAR2_SMP_START_OFFSET 0xFFC
+
+static int __init rcar2_smp_init(void)
+{
+void __iomem *pram;
+
+/* map ICRAM */
+pram = ioremap_nocache(RCAR2_RAM_ADDR, RCAR2_RAM_SIZE);
+if( !pram )
+{
+dprintk( XENLOG_ERR, "Unable to map RCAR2 ICRAM\n");
+return -ENOMEM;
+}
+
+/* setup reset vectors */
+writel(__pa(init_secondary), pram + RCAR2_SMP_START_OFFSET);
+iounmap(pram);
+
+sev();
+
+return 0;
+}
+
+static const char const *rcar2_dt_compat[] __initdata =
+{
+"renesas,lager",
+NULL
+};
+
+PLATFORM_START(rcar2, "Renesas R-Car Gen2")
+.compatible = rcar2_dt_compat,
+.cpu_up = cpu_up_send_sgi,
+.smp_init = rcar2_smp_init,
+
+.dom0_gnttab_start = 0xc000,
+.dom0_gnttab_size = 0x2,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


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

[Xen-devel] [PATCH v5 0/3] arm: introduce basic Renesas R-Car Gen2 platform support

[Oleksandr Tyshchenko]

Changes in v5:
1. Rename UART stuff (RCAR2 -> SCIF)
2. Rename board stuff (SHMOBILE -> RCAR2)

Changes in v4:
No changes.

Changes in v3:
1. Rewrite uart driver code to use start_tx/stop_tx callbacks.
2. Uncomment udelay after setup desired baudrate.
3. Call platform_get_irq() before ioremap_nocache().

Changes in v2:
1. Remove timer initialization from board file (timer shold be initialized in 
u-boot)
2. Coding style fixes.
3. Change ioremap_attr() to ioremap_nocache().
4. Other misc fixes.

The following patch series adds basic support needed for R-Car Gen2 boards.
Verified on Xen 4.5.0 stable on Lager board with and without early_printk.
Procedure needed to run Xen on Lager board is described on Xen wiki:
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager

Iurii Konovalenko (1):
  xen/arm: Introduce support for Renesas R-Car Gen2 platform

Oleksandr Tyshchenko (2):
  xen/arm: Add SCIF UART support for early printk
  xen/arm: Add new driver for SCIF UART

 config/arm32.mk   |   1 +
 docs/misc/arm/early-printk.txt|   1 +
 xen/arch/arm/Rules.mk |   4 +
 xen/arch/arm/arm32/debug-scif.inc |  49 +
 xen/arch/arm/platforms/Makefile   |   1 +
 xen/arch/arm/platforms/rcar2.c|  71 
 xen/drivers/char/Makefile |   1 +
 xen/drivers/char/scif-uart.c  | 367 ++
 xen/include/asm-arm/scif-uart.h   | 107 +++
 9 files changed, 602 insertions(+)
 create mode 100644 xen/arch/arm/arm32/debug-scif.inc
 create mode 100644 xen/arch/arm/platforms/rcar2.c
 create mode 100644 xen/drivers/char/scif-uart.c
 create mode 100644 xen/include/asm-arm/scif-uart.h

-- 
1.9.1


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

[Xen-devel] [PATCH v5 2/3] xen/arm: Add new driver for SCIF UART

[Oleksandr Tyshchenko]

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Iurii Konovalenko 
Reviewed-by: Julien Grall 
---
 config/arm32.mk  |   1 +
 xen/drivers/char/Makefile|   1 +
 xen/drivers/char/scif-uart.c | 367 +++
 3 files changed, 369 insertions(+)
 create mode 100644 xen/drivers/char/scif-uart.c

diff --git a/config/arm32.mk b/config/arm32.mk
index 4f83a63..268ca9c 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -12,6 +12,7 @@ CFLAGS += -marm
 HAS_PL011 := y
 HAS_EXYNOS4210 := y
 HAS_OMAP := y
+HAS_SCIF := y
 HAS_NS16550 := y
 
 # Use only if calling $(LD) directly.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 911b788..9e94195 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,6 +3,7 @@ obj-$(HAS_NS16550) += ns16550.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
+obj-$(HAS_SCIF) += scif-uart.o
 obj-$(HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += dt-uart.o
 obj-y += serial.o
diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
new file mode 100644
index 000..1a1c496
--- /dev/null
+++ b/xen/drivers/char/scif-uart.c
@@ -0,0 +1,367 @@
+/*
+ * xen/drivers/char/scif-uart.c
+ *
+ * Driver for SCIF (Serial communication interface with FIFO)
+ * compatible UART.
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2014, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PARITY_NONE0
+#define PARITY_EVEN1
+#define PARITY_ODD 2
+
+#define scif_readb(uart, off)  readb((uart)->regs + (off))
+#define scif_writeb(uart, off, val)writeb((val), (uart)->regs + (off))
+
+#define scif_readw(uart, off)  readw((uart)->regs + (off))
+#define scif_writew(uart, off, val)writew((val), (uart)->regs + (off))
+
+static struct scif_uart {
+unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int irq;
+char __iomem *regs;
+struct irqaction irqaction;
+struct vuart_info vuart;
+} scif_com = {0};
+
+static void scif_uart_interrupt(int irq, void *data, struct cpu_user_regs 
*regs)
+{
+struct serial_port *port = data;
+struct scif_uart *uart = port->uart;
+uint16_t status, ctrl;
+
+ctrl = scif_readw(uart, SCIF_SCSCR);
+status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+/* Ignore next flag if TX Interrupt is disabled */
+if ( !(ctrl & SCSCR_TIE) )
+status &= ~SCFSR_TDFE;
+
+while ( status != 0 )
+{
+/* TX Interrupt */
+if ( status & SCFSR_TDFE )
+serial_tx_interrupt(port, regs);
+
+/* RX Interrupt */
+if ( status & (SCFSR_RDF | SCFSR_DR) )
+serial_rx_interrupt(port, regs);
+
+/* Error Interrupt */
+if ( status & SCIF_ERRORS )
+scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
+if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
+scif_writew(uart, SCIF_SCLSR, 0);
+
+ctrl = scif_readw(uart, SCIF_SCSCR);
+status = scif_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+/* Ignore next flag if TX Interrupt is disabled */
+if ( !(ctrl & SCSCR_TIE) )
+status &= ~SCFSR_TDFE;
+}
+}
+
+static void __init scif_uart_init_preirq(struct serial_port *port)
+{
+struct scif_uart *uart = port->uart;
+unsigned int divisor;
+uint16_t val;
+
+/*
+ * Wait until last bit has been transmitted. This is needed for a smooth
+ * transition when we come from early printk
+ */
+while ( !(scif_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
+
+/* Disable TX/RX parts and all interrupts */
+scif_writew(uart, SCIF_SCSCR, 0);
+
+/* Reset TX/RX FIFOs */
+scif_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
+
+/* Clear all errors and flags */
+scif_readw(uart, SCIF_SCFSR);
+scif_writew(uart, SCIF_SCFSR, 0);
+scif_readw(uart, SCIF_SCLSR);
+scif_writew(uart, SCIF_SCLSR, 0);
+
+/* Select Baud rate generator output as a clock source */
+scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10);
+
+/* Setup protocol format and Baud rate, select Asynchronous mode */
+val = 0;
+ASSERT( uart->data_bits >= 7 && uart->data_bits <= 8 );
+if ( uart->data_bits == 7 )
+val |= SCSMR_CHR;
+else
+val &= ~SCSMR_CHR;
+
+ASSERT( uart->stop_bits >= 1 && uart->stop_bits 

[Xen-devel] [PATCH v5 1/3] xen/arm: Add SCIF UART support for early printk

[Oleksandr Tyshchenko]

Add support for the "Lager" development board based on R-Car H2 SoC
which has SCIF compatible UART.

Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Julien Grall 
---
 docs/misc/arm/early-printk.txt|   1 +
 xen/arch/arm/Rules.mk |   4 ++
 xen/arch/arm/arm32/debug-scif.inc |  49 +
 xen/include/asm-arm/scif-uart.h   | 107 ++
 4 files changed, 161 insertions(+)
 create mode 100644 xen/arch/arm/arm32/debug-scif.inc
 create mode 100644 xen/include/asm-arm/scif-uart.h

diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 71a0247..1ca2a55 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -19,6 +19,7 @@ where mach is the name of the machine:
   - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors.
   - hip04-d01: printk with 8250 on HiSilicon Hip-04 D01
   - seattle: printk with pl011 for AMD Seattle processor
+  - lager: printk with SCIF0 on Renesas R-Car H2 processors
 
 The base address and baud rate is hardcoded in xen/arch/arm/Rules.mk,
 see there when adding support for new machines.
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 4ee51a9..c7bd227 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -109,6 +109,10 @@ ifeq ($(CONFIG_EARLY_PRINTK), seattle)
 EARLY_PRINTK_INC := pl011
 EARLY_UART_BASE_ADDRESS := 0xe101
 endif
+ifeq ($(CONFIG_EARLY_PRINTK), lager)
+EARLY_PRINTK_INC := scif
+EARLY_UART_BASE_ADDRESS := 0xe6e6
+endif
 
 ifneq ($(EARLY_PRINTK_INC),)
 EARLY_PRINTK := y
diff --git a/xen/arch/arm/arm32/debug-scif.inc 
b/xen/arch/arm/arm32/debug-scif.inc
new file mode 100644
index 000..ce85752
--- /dev/null
+++ b/xen/arch/arm/arm32/debug-scif.inc
@@ -0,0 +1,49 @@
+/*
+ * xen/arch/arm/arm32/debug-scif.inc
+ *
+ * SCIF specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2014, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/* SCIF UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready rb rc
+1:
+ldrh   \rc, [\rb, #SCIF_SCFSR]   /* <- SCFSR (status register) */
+tst\rc, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be ready */
+.endm
+
+/* SCIF UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit rb rt
+strb   \rt, [\rb, #SCIF_SCFTDR]  /* -> SCFTDR (data 
register) */
+ldrh   \rt, [\rb, #SCIF_SCFSR]   /* <- SCFSR (status 
register) */
+and\rt, \rt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear TEND and 
TDFE bits */
+strh   \rt, [\rb, #SCIF_SCFSR]   /* -> SCFSR (status 
register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h
new file mode 100644
index 000..7a9f639
--- /dev/null
+++ b/xen/include/asm-arm/scif-uart.h
@@ -0,0 +1,107 @@
+/*
+ * xen/include/asm-arm/scif-uart.h
+ *
+ * Common constant definition between early printk and the UART driver
+ * for the SCIF compatible UART.
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2014, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARM_SCIF_UART_H
+#define __ASM_ARM_SCIF_UART_H
+
+#define SCIF_FIFO_MAX_SIZE16
+#define SCIF_CLK_FREQ 14745600
+
+/* Register offsets */
+#define SCIF_SCSMR (0x00)/* Serial mode register   */
+#define SCIF_SCBRR (0x04)/* Bit rate register  */
+#define SCIF_SCSCR (0x08)/* Serial control register*/
+#define SCIF_SCFTDR(0x0C)/* Transmit FIFO data register*/
+#define SCIF_SCFSR (0x10)/* Serial status register */
+#define SCIF_SCFRDR(0x14)/* Receive FIFO data re

[Xen-devel] [PATCH] xen-netfront: Use static attribute groups for sysfs entries

[Takashi Iwai]

Instead of manual calls of device_create_file() and
device_remove_files(), assign the static attribute groups to netdev
groups array.  This simplifies the code and avoids the possible
races.

Signed-off-by: Takashi Iwai 
---
 drivers/net/xen-netfront.c | 62 --
 1 file changed, 16 insertions(+), 46 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d8c10764f130..1524d2ee1c21 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -223,11 +223,7 @@ static grant_ref_t xennet_get_rx_ref(struct netfront_queue 
*queue,
 }
 
 #ifdef CONFIG_SYSFS
-static int xennet_sysfs_addif(struct net_device *netdev);
-static void xennet_sysfs_delif(struct net_device *netdev);
-#else /* !CONFIG_SYSFS */
-#define xennet_sysfs_addif(dev) (0)
-#define xennet_sysfs_delif(dev) do { } while (0)
+static const struct attribute_group xennet_dev_group;
 #endif
 
 static bool xennet_can_sg(struct net_device *dev)
@@ -1367,20 +1363,15 @@ static int netfront_probe(struct xenbus_device *dev,
 
info = netdev_priv(netdev);
dev_set_drvdata(&dev->dev, info);
-
+#ifdef CONFIG_SYSFS
+   info->netdev->sysfs_groups[0] = &xennet_dev_group;
+#endif
err = register_netdev(info->netdev);
if (err) {
pr_warn("%s: register_netdev err=%d\n", __func__, err);
goto fail;
}
 
-   err = xennet_sysfs_addif(info->netdev);
-   if (err) {
-   unregister_netdev(info->netdev);
-   pr_warn("%s: add sysfs failed err=%d\n", __func__, err);
-   goto fail;
-   }
-
return 0;
 
  fail:
@@ -2144,39 +2135,20 @@ static ssize_t store_rxbuf(struct device *dev,
return len;
 }
 
-static struct device_attribute xennet_attrs[] = {
-   __ATTR(rxbuf_min, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf),
-   __ATTR(rxbuf_max, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf),
-   __ATTR(rxbuf_cur, S_IRUGO, show_rxbuf, NULL),
-};
+static DEVICE_ATTR(rxbuf_min, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf);
+static DEVICE_ATTR(rxbuf_max, S_IRUGO|S_IWUSR, show_rxbuf, store_rxbuf);
+static DEVICE_ATTR(rxbuf_cur, S_IRUGO, show_rxbuf, NULL);
 
-static int xennet_sysfs_addif(struct net_device *netdev)
-{
-   int i;
-   int err;
-
-   for (i = 0; i < ARRAY_SIZE(xennet_attrs); i++) {
-   err = device_create_file(&netdev->dev,
-  &xennet_attrs[i]);
-   if (err)
-   goto fail;
-   }
-   return 0;
-
- fail:
-   while (--i >= 0)
-   device_remove_file(&netdev->dev, &xennet_attrs[i]);
-   return err;
-}
-
-static void xennet_sysfs_delif(struct net_device *netdev)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(xennet_attrs); i++)
-   device_remove_file(&netdev->dev, &xennet_attrs[i]);
-}
+static struct attribute *xennet_dev_attrs[] = {
+   &dev_attr_rxbuf_min.attr,
+   &dev_attr_rxbuf_max.attr,
+   &dev_attr_rxbuf_cur.attr,
+   NULL
+};
 
+static const struct attribute_group xennet_dev_group = {
+   .attrs = xennet_dev_attrs
+};
 #endif /* CONFIG_SYSFS */
 
 static int xennet_remove(struct xenbus_device *dev)
@@ -2190,8 +2162,6 @@ static int xennet_remove(struct xenbus_device *dev)
 
xennet_disconnect_backend(info);
 
-   xennet_sysfs_delif(info->netdev);
-
unregister_netdev(info->netdev);
 
for (i = 0; i < num_queues; ++i) {
-- 
2.2.2


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

[Xen-devel] [linux-linus test] 34127: regressions - FAIL

[xen . org]

flight 34127 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34127/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels 
fail REGR. vs. 33815

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 33815
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 33815
 test-amd64-amd64-xl-sedf  5 xen-boot  fail REGR. vs. 33815
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33815
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 33815

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-sedf 10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-xl-midway   10 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass

version targeted for testing:
 linuxe36f014edff70fc02b3d3d79cead1d58f289332e
baseline version:
 linux26bc420b59a38e4e6685a73345a0def461136dce


People who touched revisions under test:
  Ahmed S. Darwish 
  Alex Deucher 
  Alexei Starovoitov 
  Andrew Jackson 
  Andrew Lunn 
  Andrew Morton 
  Andrey Ryabinin 
  Andy Shevchenko 
  Anna Schumaker 
  Arnaldo Carvalho de Melo 
  Ashay Jaiswal 
  Aurelien BOUIN 
  Axel Lin 
  Bard Liao 
  Ben Goz 
  Ben Hutchings 
  Bo Shen 
  Bob Paauwe 
  Borislav Petkov 
  Chanwoo Choi 
  Charles Keepax 
  Chen-Yu Tsai 
  Cheng-Yi Chiang 
  Chris Mason 
  Christoffer Dall 
  Christoph Hellwig 
  Clemens Ladisch 
  Daniel Borkmann 
  Dave Airlie 
  David S. Miller 
  David Spinadel 
  David Woodhouse 
  David Woodhouse 
  Dmitry Nezhevenko 
  Dmitry Osipenko 
  Dmitry Torokhov 
  Emmanuel Grumbach 
  Eric Dumazet 
  Eugene Crosser 
  Eyal Shapira 
  Eyal Shapira 
  Ezequiel Garcia 
  Fabio Estevam 
  Felipe Balbi 
  Felix Fietkau 
  Florian Fainelli 
  Florian Westphal 
  Fred Chou 
  Fugang Duan 
  Geert Uytterhoeven 
  Govindarajulu Varadarajan <_gov...@gmx.com>
  Greg KH 
  Greg Kroah-Hartman 
  Greg Kroah-Hartman 
  Greg Thelen 
  Gregory CLEMENT 
  Guenter Roeck 
  Gui Hecheng 
  Hannes Frederic Sowa 
  Hans de Goede 
  Heikki Krogerus 
  Heiko Carstens  # "s390 still compiles and boots"
  Heiko Stuebner 
  Herbert Xu 
  Ilya Dryomov 
  Ingo Molnar 
  James Bottomley 
  Jan Engelhardt 
  Jan Kara 
  Jani Nikula 
  Jarkko Nikula 
  Jean Delvare 
  Jean-Christophe PLAGNIOL-VILLARD 
  Jean-Francois Moine 
  Jeremiah Mahler 
  Jianqun Xu 
  Jie Yang 
  Jiri Olsa 
  Jiri Pirko 
  Jochen Hein 
  Joe Thornber 
  Joerg Roedel 
  Johannes Berg 
  Johannes Weiner 
  Jonghwa Lee 
  Julian Anastasov 
  Kalle Valo 
  Kan Liang 
  Kees Cook 
  Lars Poeschel 
  Lars-Peter Clausen 
  Laurent Dufour 
  Laurent Pinchart 
  Laurent Pinchart 
  Lee Jones 
  Lendacky, Thomas 
  Linus Torvalds 
  Linus Walleij 
  Liviu Dudau 
  Lubomir Rintel 
  Luciano Coelho 
  Lud

Re: [Xen-devel] [PATCH] xen-netfront: Use static attribute groups for sysfs entries

[David Vrabel]

On 04/02/15 13:38, Takashi Iwai wrote:
> Instead of manual calls of device_create_file() and
> device_remove_files(), assign the static attribute groups to netdev
> groups array.  This simplifies the code and avoids the possible
> races.

Acked-by: David Vrabel 

David

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

Re: [Xen-devel] [PATCH v6] sndif: add ABI for Para-virtual sound

[Oleksandr Dmytryshyn]

On Thu, Jan 29, 2015 at 1:01 PM, Oleksandr Dmytryshyn
 wrote:
>
> This is ABI for the two halves of a Para-virtual
> sound driver to communicate with each to other.
>
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Iurii Konovalenko 
> ---
> Changes since v1:
>  * removed __attribute__((__packed__)) from all structures definitions
>
> Changes since v2:
>  * removed all C structures
>  * added protocol description between frontend and backend drivers
>
> Changes since v3:
>  * fixed some typos
>  * renamed XENSND_PCM_FORMAT_FLOAT_** to XENSND_PCM_FORMAT_F32_**
>  * renamed XENSND_PCM_FORMAT_FLOAT64_** to XENSND_PCM_FORMAT_F64_**
>  * added 'id' field to the request and response packets
>  * renamed 'stream_id' to 'stream' in the packets description
>  * renamed 'pcm_data_rate' to 'pcm_rate' in the packets description
>  * renamed 'pcm_stream_type' to 'pcm_type' in the packets description
>  * removed 'stream_id' field from the response packets
>
> Changes since v4:
>  * renamed 'stream_id' back to the to 'stream' in the packets description
>  * moved 'id' field to the upper position in the response packets
>
> Changes since v5:
>  * Slightly reworked request/response packets
>  * Size of the request/response packet is changed to the 64 bytes
>  * Now parameters for the XENSND_OP_SET_VOLUME/XENSND_OP_GET_VOLUME are
>passed via shared page
>  * Added parameters for the XenBus nodes (now each stream can be mapped
>to the defined sound device in the backend using those parameters)
>  * Added XenBus state diagrams description
>
>  xen/include/public/io/sndif.h | 421 
> ++
>  1 file changed, 421 insertions(+)
>  create mode 100644 xen/include/public/io/sndif.h
>
> diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
> new file mode 100644
> index 000..f2e080b
> --- /dev/null
> +++ b/xen/include/public/io/sndif.h
> @@ -0,0 +1,421 @@
> +/**
> + * sndif.h
> + *
> + * Unified sound-device I/O interface for Xen guest OSes.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Copyright (C) 2013-2015 GlobalLogic Inc.
> + */
> +
> +#ifndef __XEN_PUBLIC_IO_XENSND_H__
> +#define __XEN_PUBLIC_IO_XENSND_H__
> +
> +/*
> + * Front->back notifications: When enqueuing a new request, sending a
> + * notification can be made conditional on req_event (i.e., the generic
> + * hold-off mechanism provided by the ring macros). Backends must set
> + * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
> + *
> + * Back->front notifications: When enqueuing a new response, sending a
> + * notification can be made conditional on rsp_event (i.e., the generic
> + * hold-off mechanism provided by the ring macros). Frontends must set
> + * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()).
> + */
> +
> +/*
> + * Feature and Parameter Negotiation
> + * =
> + * The two halves of a Para-virtual sound card driver utilize nodes within 
> the
> + * XenStore to communicate capabilities and to negotiate operating 
> parameters.
> + * This section enumerates these nodes which reside in the respective front 
> and
> + * backend portions of the XenStore, following the XenBus convention.
> + *
> + * All data in the XenStore is stored as strings.  Nodes specifying numeric
> + * values are encoded in decimal.  Integer value ranges listed below are
> + * expressed as fixed sized integer types capable of storing the conversion
> + * of a properly formated node string, without loss of information.
> + *
> + 
> *
> + *Backend XenBus Nodes
> + 
> *
> + *
> + *-

[Xen-devel] [PATCH RFC 01/35] xen: acpi: Build numa and pmstate x86 only

[parth . dixit]

From: Naresh Bhat 

Configure and build numa, pmstate for x86 architecture only.

Signed-off-by: Naresh Bhat 
---
 xen/drivers/acpi/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index bbb06a7..009fe5a 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -3,9 +3,9 @@ subdir-y += utilities
 subdir-$(x86) += apei
 
 obj-bin-y += tables.init.o
-obj-y += numa.o
+obj-$(x86) += numa.o
 obj-y += osl.o
-obj-y += pmstat.o
+obj-$(x86) += pmstat.o
 
 obj-$(x86) += hwregs.o
 obj-$(x86) += reboot.o
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 00/35] Add ACPI support for arm64 on Xen

[parth . dixit]

From: Parth Dixit 

This patch series adds ACPI support for arm64.
Xen reads static tables described by ACPI standard (5.1) from uefi
and configures timer, gic and uart. ACPI tables are modified to 
enable PSCI, HVC and xen specific information (grant table and 
event channel interrupts) and mapped into dom0 address space.
A skeleton device tree is created to pass memory
(which cannot be passed using ACPI) and rsdp pointer to DOM0.
DOM0 parses dynamic ACPI tables and configure other peripherals.

- patches 1-19 add ACPI support for xen/uefi interface
- patches 20-35 add ACPI support for xen/dom0 interface
Last patch "xen: arm64: Add ACPI support" enables the support for ACPI
so that individual patches do not affect working xen code base.

Instructions for reproducing the setup and working code base can be found 
in the following repositories
wiki : https://wiki.linaro.org/LEG/Engineering/Xen_boot_on_FVP_ACPI_UEFI
linux : 
https://git.linaro.org/people/parth.dixit/xen-acpi-support/leg-kernel.git
xen : https://git.linaro.org/people/parth.dixit/xen-acpi-support/xen.git
uefi : 
https://git.linaro.org/people/parth.dixit/xen-acpi-support/linaro-edk2.git

Few workarounds have been made to get it working, these are as follows
1. Xen assumes that mmio regions are defined in firmware. It reads 
this information from uefi tables and map's it to dom0 address space.
Right now FVP firmware on which this series has been tested 
does not contains all the mmio regions defined in ACPI supplied by
firmware, to overcome this hard coding of mmio regions is done.

2. Linux is checking if mapped pages belong to ram and when this check 
fails(incorrectly)
it maps RAM using ioremap, to overcome this at present this check is 
disabled in linux. 

3. Device specific interrupt information is defined in DSDT tables in ACPI.
Parsing this table is out of scope for xen so it uses dom0 to parse DSDT table
and enables the interrupt dynamically when they are enabled by dom0.

4. Grant table region and event channel interrupts are hard coded right now.

5. RSDP ponter is exposed to dom0 by using "rsdp" node, this node is not yet 
defined
in linux and its name may get changed to "linux,acpi-rsdp" or something else.


Naresh Bhat (22):
  xen: acpi: Build numa and pmstate x86 only
  xen: arm64: ACPI: Support common ACPI drivers
  xen: arm64: ACPI: Add basic ACPI initialization
  ACPI / ACPICA: Introduce ARM Boot Architecture Flags in  FADT
  ARM64 / ACPI: Parse FADT table to get PSCI flags
  ACPI: Add Generic Interrupt and Distributor struct
  ACPI / ACPICA: Add new features for MADT which  introduced by ACPI
5.1
  ACPI / table: Print GIC information when MADT is parsed
  Add cpumask_next_zero set_cpu_present and possible
  asm / arm: Introduce cputype.h
  ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR  and get
cpu_possible/present_map
  ARM64: Initialization of cpu_logical_map(0)
  ACPI: Introduce acpi_parse_entries
  ACPI / ACPICA: Add GTDT support updated by ACPI 5.1
  ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm
  ARM64 / ACPI: Parse GTDT to initialize timer
  pl011: Initialize serial from ACPI SPCR table
  ACPI / GICv2: Add GIC specific ACPI boot support
  xen/arm: Prepare a min DT for DOM0
  xen/arm: Create memory node for DOM0
  xen/arm: Create chosen node for DOM0
  xen: arm64: Add ACPI support

Parth Dixit (13):
  arm : add helper function for setting interrupt type
  arm: acpi add status override table
  arm : acpi add xen environment table
  arm: acpi add helper functions to map memory regions
  arm : acpi read mmio tables from uefi
  arm: acpi map mmio regions to dom0
  arm: acpi map acpi tables in dom0
  arm : acpi enable PSCI and hvc in acpi FADT table
  arm : acpi map XSDT table to dom0
  arm : acpi map status override table to dom0
  arm : acpi map xen environment table to dom0
  arm : acpi enable efi for acpi
  arm : acpi workarounds for firmware/linux dependencies

 config/arm64.mk   |   1 +
 xen/arch/arm/arm64/Makefile   |   1 +
 xen/arch/arm/arm64/acpi/Makefile  |   1 +
 xen/arch/arm/arm64/acpi/arm-core.c| 508 ++
 xen/arch/arm/domain_build.c   | 294 +++-
 xen/arch/arm/efi/efi-boot.h   |  16 ++
 xen/arch/arm/gic-v2.c | 271 ++
 xen/arch/arm/irq.c|  19 ++
 xen/arch/arm/p2m.c|  24 ++
 xen/arch/arm/setup.c  |  36 ++-
 xen/arch/arm/time.c   |  66 +
 xen/arch/arm/vgic.c   |  16 ++
 xen/common/cpu.c  |  18 ++
 xen/common/efi/runtime.c  |   6 +
 xen/common/sysctl.c   |   2 +
 xen/drivers/acpi/Makefile |   4 +-
 xen/drivers/acpi/osl.c|  13 +-
 xen/drivers/acpi/tables.c | 110 +++-
 xen/drivers/acpi/utilities/utglobal.c |   1 +
 xen/drivers/char/pl011.c  |  69 +
 xen/include/

[Xen-devel] [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers

[parth . dixit]

From: Naresh Bhat 

xen hypervisor will use ACPI for initialisation in the same manner that
current x86/x86_64 ones do. Add the calls to initialise the ACPI tables
and load devices using the xen/drivers/acpi subsytem.

Signed-off-by: Naresh Bhat 
---
 xen/common/sysctl.c   |   2 +
 xen/drivers/acpi/osl.c|   6 ++
 xen/drivers/acpi/utilities/utglobal.c |   1 +
 xen/include/asm-arm/acpi.h| 106 ++
 xen/include/asm-arm/arm64/page.h  |   2 +
 5 files changed, 117 insertions(+)
 create mode 100644 xen/include/asm-arm/acpi.h

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..a700a16 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 op->u.availheap.avail_bytes <<= PAGE_SHIFT;
 break;
 
+#ifdef CONFIG_X86
 #ifdef HAS_ACPI
 case XEN_SYSCTL_get_pmstat:
 ret = do_get_pm_info(&op->u.get_pmstat);
@@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 copyback = 1;
 break;
 #endif
+#endif
 
 case XEN_SYSCTL_page_offline_op:
 {
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 93c983c..73da9d9 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size 
size)
return __va(phys);
return __vmap(&pfn, PFN_UP(offs + size), 1, 1, 
PAGE_HYPERVISOR_NOCACHE) + offs;
}
+#ifdef CONFIG_X86
return __acpi_map_table(phys, size);
+#else
+   return __va(phys);
+#endif
 }
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
@@ -105,6 +109,7 @@ void acpi_os_unmap_memory(void __iomem * virt, acpi_size 
size)
vunmap((void *)((unsigned long)virt & PAGE_MASK));
 }
 
+#ifdef CONFIG_X86
 acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
 {
u32 dummy;
@@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 
value, u32 width)
 
return AE_OK;
 }
+#endif
 
 acpi_status
 acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
diff --git a/xen/drivers/acpi/utilities/utglobal.c 
b/xen/drivers/acpi/utilities/utglobal.c
index 7dbc964..65c918e 100644
--- a/xen/drivers/acpi/utilities/utglobal.c
+++ b/xen/drivers/acpi/utilities/utglobal.c
@@ -43,6 +43,7 @@
 
 #define DEFINE_ACPI_GLOBALS
 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
new file mode 100644
index 000..f6284b5
--- /dev/null
+++ b/xen/include/asm-arm/acpi.h
@@ -0,0 +1,106 @@
+/*
+ *  Copyright (C) 2014, Naresh Bhat 
+ *
+ * ~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~
+ */
+
+#ifndef _ASM_ARM64_ACPI_H
+#define _ASM_ARM64_ACPI_H
+
+#include 
+
+#define COMPILER_DEPENDENT_INT64   long long
+#define COMPILER_DEPENDENT_UINT64  unsigned long long
+
+#define MAX_LOCAL_APIC 256
+#define MAX_IO_APICS 64
+
+/*
+ * Calling conventions:
+ *
+ * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
+ * ACPI_EXTERNAL_XFACE  - External ACPI interfaces
+ * ACPI_INTERNAL_XFACE  - Internal ACPI interfaces
+ * ACPI_INTERNAL_VAR_XFACE  - Internal variable-parameter list interfaces
+ */
+#define ACPI_SYSTEM_XFACE
+#define ACPI_EXTERNAL_XFACE
+#define ACPI_INTERNAL_XFACE
+#define ACPI_INTERNAL_VAR_XFACE
+
+/* Asm macros */
+#define ACPI_ASM_MACROS
+#define BREAKPOINT3
+#define ACPI_DISABLE_IRQS() local_irq_disable()
+#define ACPI_ENABLE_IRQS()  local_irq_enable()
+#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
+
+/* Blob handling macros */
+#define ACPI_BLOB_HEADER_SIZE   8
+
+/* Basic configuration for ACPI */
+#ifdef  CONFIG_ACPI
+extern int acpi_disabled;
+extern int acpi_noirq;
+extern int acpi_pci_disabled;
+extern int acpi_strict;
+
+/* map logic cpu id to physical APIC id
+ * APIC = GIC cpu interface on ARM
+ */
+extern volatile int arm_cpu_to_apicid[NR_CPUS];
+extern int boot_cpu_apic_id;
+#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]

[Xen-devel] [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization

[parth . dixit]

From: Naresh Bhat 

This patch introduce arm-core.c and its related header file

- asm/acpi.h for arch specific variables and functions needed by
  ACPI driver core;
- arm-core.c for ARM64 related ACPI implementation for ACPI driver
  core;

acpi_boot_table_init() will be called in setup_arch()
to get the RSDP and all the table pointers. with this patch,
we can get ACPI boot-time tables from firmware on ARM64.

Signed-off-by: Naresh Bhat 
---
 xen/arch/arm/arm64/Makefile|  1 +
 xen/arch/arm/arm64/acpi/Makefile   |  1 +
 xen/arch/arm/arm64/acpi/arm-core.c | 97 ++
 xen/arch/arm/setup.c   | 14 +-
 xen/include/xen/acpi.h | 11 +
 5 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/arm64/acpi/Makefile
 create mode 100644 xen/arch/arm/arm64/acpi/arm-core.c

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c7243f5..49d135f 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,4 +1,5 @@
 subdir-y += lib
+subdir-y += acpi
 
 obj-y += entry.o
 
diff --git a/xen/arch/arm/arm64/acpi/Makefile b/xen/arch/arm/arm64/acpi/Makefile
new file mode 100644
index 000..07e3c44
--- /dev/null
+++ b/xen/arch/arm/arm64/acpi/Makefile
@@ -0,0 +1 @@
+obj-y  += arm-core.o
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
new file mode 100644
index 000..50a83d6
--- /dev/null
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -0,0 +1,97 @@
+/*
+ *  ARM64 Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2014, Naresh Bhat 
+ *
+ * ~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~
+ */
+
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+#include 
+#include 
+
+#include 
+
+/*
+ * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
+ * variable is still required by the ACPI core
+ */
+u32 acpi_rsdt_forced;
+
+int acpi_noirq;/* skip ACPI IRQ initialization */
+int acpi_strict;
+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);
+
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+
+struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
+
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+*irq = -1;
+return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+
+/*
+ * success: return IRQ number (>0)
+ * failure: return =< 0
+ */
+//int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
+{
+return -1;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
+/*
+ * acpi_boot_table_init() called from setup_arch(), always.
+ *  1. find RSDP and get its address, and then find XSDT
+ *  2. extract all tables and checksums them all
+ *
+ * We can parse ACPI boot-time tables such as FADT, MADT after
+ * this function is called.
+ */
+int __init acpi_boot_table_init(void)
+{
+int error;
+/* If acpi_disabled, bail out */
+if (acpi_disabled)
+return 1;
+
+/* Initialize the ACPI boot-time table parser. */
+error = acpi_table_init();
+if (error)
+{
+disable_acpi();
+return error;
+}
+
+return 0;
+}
+#endif
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3991d64..7ae126b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -45,6 +45,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct bootinfo __initdata bootinfo;
 
@@ -737,7 +739,18 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 setup_mm(fdt_paddr, fdt_size);
 
+system_state = SYS_STATE_boot;
+
 vm_init();
+
+/*
+ * Parse the ACPI tables for possible boot-time configuration
+ */
+
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+acpi_boot_table_init();
+#endif
+
 dt_unflatten_host_device_tree();
 dt_irq_xlate = gic_irq_xlate;
 
@@ -802,7 +8

[Xen-devel] [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT

[parth . dixit]

From: Naresh Bhat 

The Power State Coordination Interface (PSCI) defines an API that
can be used to coordinate power control amongst the various supervisory
systems concurrently running on a device. ACPI support for this
technology would require the addition of two flags: PSCI_COMPLIANT and
PSCI_USE_HVC. When set, the former signals to the OS that the hardware
is PSCI compliant. The latter selects the appropriate conduit for PSCI
calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
Calls (SMC).

An ARM Boot Architecture Flags structure to support new ARM hardware
was introduced in FADT in ACPI 5.1, add the code accordingly to
implement that in ACPICA core.

Since ACPI 5.1 doesn't support self defined PSCI function IDs,
which means that only PSCI 0.2+ is supported in ACPI.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
 xen/include/acpi/actbl.h | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
index 856945d..34e8673 100644
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -244,7 +244,8 @@ struct acpi_table_fadt {
u32 flags;  /* Miscellaneous flag bits (see below for 
individual flags) */
struct acpi_generic_address reset_register; /* 64-bit address of 
the Reset register */
u8 reset_value; /* Value to write to the reset_register port to 
reset the system */
-   u8 reserved4[3];/* Reserved, must be zero */
+u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below for 
individual flags) */
+u8 minor_version;   /* Minor version of this FADT structure */
u64 Xfacs;  /* 64-bit physical address of FACS */
u64 Xdsdt;  /* 64-bit physical address of DSDT */
struct acpi_generic_address xpm1a_event_block;  /* 64-bit Extended 
Power Mgt 1a Event Reg Blk address */
@@ -259,7 +260,7 @@ struct acpi_table_fadt {
struct acpi_generic_address sleep_status;   /* 64-bit Sleep Status 
register */
 };
 
-/* Masks for FADT Boot Architecture Flags (boot_flags) */
+/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced 
in this FADT revision */
 
 #define ACPI_FADT_LEGACY_DEVICES(1)/* 00: [V2] System has LPC or 
ISA bus devices */
 #define ACPI_FADT_8042  (1<<1) /* 01: [V3] System has an 8042 
controller on port 60/64 */
@@ -270,6 +271,11 @@ struct acpi_table_fadt {
 
 #define FADT2_REVISION_ID   3
 
+/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
+
+#define ACPI_FADT_PSCI_COMPLIANT(1)/* 00: PSCI 0.2+ is implemented 
*/
+#define ACPI_FADT_PSCI_USE_HVC  (1<<1) /* 01: HVC must be used instead 
of SMC as the PSCI conduit */
+
 /* Masks for FADT flags */
 
 #define ACPI_FADT_WBINVD(1)/* 00: [V1] The wbinvd 
instruction works properly */
@@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
  * FADT V5  size: 0x10C
  */
 #define ACPI_FADT_V1_SIZE   (u32) (ACPI_FADT_OFFSET (flags) + 4)
-#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
+#define ACPI_FADT_V2_SIZE   (u32) (ACPI_FADT_OFFSET (arm_boot_flags) + 3)
 #define ACPI_FADT_V3_SIZE   (u32) (ACPI_FADT_OFFSET (sleep_control))
 #define ACPI_FADT_V5_SIZE   (u32) (sizeof (struct acpi_table_fadt))
 
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags

[parth . dixit]

From: Naresh Bhat 

There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the hardware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).

FADT table contains such information, parse FADT to get the flags
for furture usage. At the same time, only ACPI 5.1 or higher verison
supports PSCI, and FADT Major.Minor version was introduced in ACPI
5.1, so we will check the version and only parse FADT table with
version >= 5.1.

If firmware provides ACPI tables with ACPI version less than 5.1,
OS will be messed up with those information, so disable ACPI if we
get an FADT table with version less that 5.1.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
 xen/arch/arm/arm64/acpi/arm-core.c | 54 +++---
 xen/arch/arm/setup.c   |  1 +
 xen/include/asm-arm/acpi.h |  2 ++
 3 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 50a83d6..2b7e2ef 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -25,6 +25,7 @@
 #if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
 #include 
 #include 
+#include 
 
 #include 
 
@@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
 int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
 EXPORT_SYMBOL(acpi_pci_disabled);
 
+/* 1 to indicate PSCI is implemented */
+int acpi_psci_present;
+
+/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
+int acpi_psci_use_hvc;
+
 enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
 
 struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
@@ -58,7 +65,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
  * failure: return =< 0
  */
 //int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
-unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
+unsigned int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)
 {
 return -1;
 }
@@ -69,6 +76,33 @@ void acpi_unregister_gsi(u32 gsi)
 }
 EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
 
+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+   struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
+
+   /*
+* Revision in table header is the FADT Major version,
+* and there is a minor version of FADT which was introduced
+* by ACPI 5.1, we only deal with ACPI 5.1 or higher version
+* to get arm boot flags, or we will disable ACPI.
+*/
+   if ( table->revision < 5 || fadt->minor_version < 1 ) {
+   printk("FADT version is %d.%d, no PSCI support, should be 5.1 
or higher\n",
+   table->revision, fadt->minor_version);
+   acpi_psci_present = 0;
+   disable_acpi();
+   return -EINVAL;
+   }
+
+   if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT )
+   acpi_psci_present = 1;
+
+   if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC )
+   acpi_psci_use_hvc = 1;
+
+   return 0;
+}
+
 /*
  * acpi_boot_table_init() called from setup_arch(), always.
  *  1. find RSDP and get its address, and then find XSDT
@@ -81,12 +115,12 @@ int __init acpi_boot_table_init(void)
 {
 int error;
 /* If acpi_disabled, bail out */
-if (acpi_disabled)
+if ( acpi_disabled )
 return 1;
 
 /* Initialize the ACPI boot-time table parser. */
 error = acpi_table_init();
-if (error)
+if ( error )
 {
 disable_acpi();
 return error;
@@ -94,4 +128,18 @@ int __init acpi_boot_table_init(void)
 
 return 0;
 }
+
+int __init acpi_boot_init(void)
+{
+int err = 0;
+/* If acpi_disabled, bail out */
+if (acpi_disabled)
+return -ENODEV;
+
+err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
+if ( err )
+printk("Can't find FADT\n");
+
+return err;
+}
 #endif
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7ae126b..3531d47 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -749,6 +749,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
 acpi_boot_table_init();
+acpi_boot_init();
 #endif
 
 dt_unflatten_host_device_tree();
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index f6284b5..03051ef 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -60,6 +60,8 @@ extern int acpi_disabled;
 extern int acpi_noirq;
 extern int acpi_pci_disabled;
 extern int acpi_strict;
+extern int acpi_psci_present;
+extern int acpi_psci_use_hvc;
 
 /* map logic cpu id to physical APIC id
  * APIC = GIC cpu interface on ARM
-- 
1.9.1


___
Xen-devel ma

[Xen-devel] [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1

[parth . dixit]

From: Naresh Bhat 

Add new features for MADT which introduced by ACPI 5.1:
-comment on the GIC ID field of the GIC structure which is replaced
 by CPU Interface Number.
-add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
-add new structures for GIC MSI frame and GICR.
-add flag definition for GICC flags.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
 xen/include/acpi/actbl1.h | 38 ++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
index dd6dc27..d16670d 100644
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -641,7 +641,9 @@ enum acpi_madt_type {
ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
-   ACPI_MADT_TYPE_RESERVED = 13/* 13 and greater are reserved */
+   ACPI_MADT_TYPE_GIC_MSI_FRAME = 13,
+   ACPI_MADT_TYPE_GIC_REDISTRIBUTOR = 14,
+   ACPI_MADT_TYPE_RESERVED = 15/* 15 and greater are reserved */
 };
 
 /*
@@ -762,18 +764,23 @@ struct acpi_madt_local_x2apic_nmi {
u8 reserved[3];
 };
 
-/* 11: Generic Interrupt (ACPI 5.0) */
+/* 11: Generic Interrupt (ACPI 5.1) */
 
 struct acpi_madt_generic_interrupt {
 struct acpi_subtable_header header;
 u16 reserved;   /* reserved - must be zero */
-u32 gic_id;
+u32 gic_id;/* it was renamed to cpu interface number in 
ACPI 5.1 */
 u32 uid;
 u32 flags;
 u32 parking_version;
 u32 performance_interrupt;
 u64 parked_address;
 u64 base_address;
+u64 gicv_base_address;
+u64 gich_base_address;
+u32 vgic_maintenance_interrupt;
+u64 redist_base_address;
+u64 mpidr;
 };
 
 /* 12: Generic Distributor (ACPI 5.0) */
@@ -787,14 +794,37 @@ struct acpi_madt_generic_distributor {
 u32 reserved2;  /* reserved - must be zero */
 };
 
+/* 13: GIC MSI Frame (ACPI 5.1) */
+
+struct acpi_madt_gic_msi_frame {
+   struct acpi_subtable_header header;
+   u16 reserved;   /* reserved - must be zero */
+   u32 gic_msi_frame_id;
+   u64 base_address;
+};
+
+/* 14: GIC Redistributor (ACPI 5.1) */
+
+struct acpi_madt_gic_redistributor {
+   struct acpi_subtable_header header;
+   u16 reserved;   /* reserved - must be zero */
+   u64 base_address;
+   u32 region_size;
+};
+
 /*
  * Common flags fields for MADT subtables
  */
 
-/* MADT Local APIC flags (lapic_flags) */
+/* MADT Local APIC flags (lapic_flags) and GICC flags */
 
 #define ACPI_MADT_ENABLED   (1)/* 00: Processor is usable if 
set */
 
+/* MADT GICC flags only */
+
+#define ACPI_MADT_PERF_INT_MODE (1<<1) /* 01: Performance Interrupt 
Mode */
+#define ACPI_MADT_VGIC  (1<<2) /* 02: VGIC Maintenance 
interrupt mode */
+
 /* MADT MPS INTI flags (inti_flags) */
 
 #define ACPI_MADT_POLARITY_MASK (3)/* 00-01: Polarity of APIC I/O 
input signals */
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct

[parth . dixit]

From: Naresh Bhat 

Add Generic Interrupt and Distributor (ACPI 5.0) structure.

Signed-off-by: Naresh Bhat 
---
 xen/include/acpi/actbl1.h | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
index 9311e3a..dd6dc27 100644
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -639,7 +639,9 @@ enum acpi_madt_type {
ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
-   ACPI_MADT_TYPE_RESERVED = 11/* 11 and greater are reserved */
+   ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
+   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
+   ACPI_MADT_TYPE_RESERVED = 13/* 13 and greater are reserved */
 };
 
 /*
@@ -760,6 +762,31 @@ struct acpi_madt_local_x2apic_nmi {
u8 reserved[3];
 };
 
+/* 11: Generic Interrupt (ACPI 5.0) */
+
+struct acpi_madt_generic_interrupt {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u32 gic_id;
+u32 uid;
+u32 flags;
+u32 parking_version;
+u32 performance_interrupt;
+u64 parked_address;
+u64 base_address;
+};
+
+/* 12: Generic Distributor (ACPI 5.0) */
+
+struct acpi_madt_generic_distributor {
+struct acpi_subtable_header header;
+u16 reserved;   /* reserved - must be zero */
+u32 gic_id;
+u64 base_address;
+u32 global_irq_base;
+u32 reserved2;  /* reserved - must be zero */
+};
+
 /*
  * Common flags fields for MADT subtables
  */
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 10/35] asm / arm: Introduce cputype.h

[parth . dixit]

From: Naresh Bhat 

Introduce cputype.h file for arm

Signed-off-by: Naresh Bhat 
---
 xen/include/asm-arm/cputype.h | 83 +++
 1 file changed, 83 insertions(+)
 create mode 100644 xen/include/asm-arm/cputype.h

diff --git a/xen/include/asm-arm/cputype.h b/xen/include/asm-arm/cputype.h
new file mode 100644
index 000..0b454cc
--- /dev/null
+++ b/xen/include/asm-arm/cputype.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_CPUTYPE_H
+#define __ASM_CPUTYPE_H
+
+#include 
+
+#define INVALID_HWIDULONG_MAX
+
+#define MPIDR_HWID_BITMASK  0xff00ff
+
+#define MPIDR_LEVEL_BITS_SHIFT  3
+#define MPIDR_LEVEL_MASK((1 << MPIDR_LEVEL_BITS) - 1)
+
+#define MPIDR_LEVEL_SHIFT(level) \
+(((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
+
+#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
+((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
+
+#define read_cpuid(reg) ({  \
+u64 __val;  \
+asm("mrs%0, " #reg : "=r" (__val)); \
+__val;  \
+})
+
+#define ARM_CPU_IMP_ARM 0x41
+#define ARM_CPU_IMP_APM 0x50
+
+#define ARM_CPU_PART_AEM_V8 0xD0F0
+#define ARM_CPU_PART_FOUNDATION 0xD000
+#define ARM_CPU_PART_CORTEX_A57 0xD070
+
+#define APM_CPU_PART_POTENZA0x
+
+#ifndef __ASSEMBLY__
+
+/*
+ * The CPU ID never changes at run time, so we might as well tell the
+ * compiler that it's constant.  Use this function to read the CPU ID
+ * rather than directly reading processor_id or read_cpuid() directly.
+ */
+static inline u32 __attribute_const__ read_cpuid_id(void)
+{
+return read_cpuid(MIDR_EL1);
+}
+
+static inline u64 __attribute_const__ read_cpuid_mpidr(void)
+{
+return read_cpuid(MPIDR_EL1);
+}
+
+static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
+{
+return (read_cpuid_id() & 0xFF00) >> 24;
+}
+
+static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
+{
+return (read_cpuid_id() & 0xFFF0);
+}
+
+static inline u32 __attribute_const__ read_cpuid_cachetype(void)
+{
+return read_cpuid(CTR_EL0);
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible

[parth . dixit]

From: Naresh Bhat 

Introduce and use cpumask_next_zero, set_cpu_present and set_cpu_possible.

Signed-off-by: Naresh Bhat 
---
 xen/common/cpu.c  | 18 ++
 xen/include/xen/cpumask.h | 40 
 2 files changed, 58 insertions(+)

diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 630881e..da399c9 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -216,3 +216,21 @@ void enable_nonboot_cpus(void)
 
 cpumask_clear(&frozen_cpus);
 }
+
+static DECLARE_BITMAP(cpu_present_bits, NR_CPUS) __read_mostly;
+static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
+void set_cpu_possible(unsigned int cpu, bool possible)
+{
+if ( possible )
+ cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
+else
+cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
+}
+
+void set_cpu_present(unsigned int cpu, bool present)
+{
+if ( present )
+cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
+else
+cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
+}
diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
index 850b4a2..209483e 100644
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -78,6 +78,7 @@
 #include 
 #include 
 #include 
+#include 
 
 typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
 
@@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
 }
 
 /*
+ * cpumask_next_zero - get the next unset cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus unset.
+ */
+static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
+{
+/* -1 is a legal arg here. */
+if (n != -1)
+cpumask_check(n);
+
+return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);
+}
+
+/*
  * cpumask_var_t: struct cpumask for stack usage.
  *
  * Oh, the wicked games we play!  In order to make kernel coding a
@@ -440,6 +457,29 @@ extern cpumask_t cpu_present_map;
 #define for_each_online_cpu(cpu)   for_each_cpu(cpu, &cpu_online_map)
 #define for_each_present_cpu(cpu)  for_each_cpu(cpu, &cpu_present_map)
 
+/* Wrappers for arch boot code to manipulate normally-constant masks */
+void set_cpu_possible(unsigned int cpu, bool possible);
+void set_cpu_present(unsigned int cpu, bool present);
+
+/*
+ * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
+ * @bitmap: the bitmap
+ *
+ * There are a few places where cpumask_var_t isn't appropriate and
+ * static cpumasks must be used (eg. very early boot), yet we don't
+ * expose the definition of 'struct cpumask'.
+ *
+ * This does the conversion, and can be used as a constant initializer.
+ */
+#define to_cpumask(bitmap)  \
+((struct cpumask *)(1 ? (bitmap)\
+: (void *)sizeof(__check_is_bitmap(bitmap
+
+static inline int __check_is_bitmap(const unsigned long *bitmap)
+{
+return 1;
+}
+
 /* Copy to/from cpumap provided by control tools. */
 struct xenctl_bitmap;
 int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0)

[parth . dixit]

From: Naresh Bhat 

Initialization of cpu_logical_map(0) before acpi_boot_init()

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
 xen/arch/arm/setup.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3531d47..569b2da 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bootinfo __initdata bootinfo;
 
@@ -749,6 +750,10 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
 acpi_boot_table_init();
+
+/* Get the boot CPU's MPIDR before cpu logical map is built */
+cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
+
 acpi_boot_init();
 #endif
 
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 15/35] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm

[parth . dixit]

From: Naresh Bhat 

Needed because ARM64 uses GIC which is defined in ACPI 5.0 spec.

Signed-off-by: Al Stone 
Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
 xen/arch/arm/arm64/acpi/arm-core.c |  6 ++-
 xen/drivers/acpi/tables.c  | 95 --
 2 files changed, 55 insertions(+), 46 deletions(-)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 84b0032..cc11fce 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -55,7 +55,11 @@ int acpi_psci_use_hvc;
 /* available_cpus means enabled cpu in MADT */
 static int available_cpus;
 
-enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+/*
+ * Since we're on ARM, the default interrupt routing model
+ * clearly has to be GIC.
+ */
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
 
 struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
 
diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 5314f0b..ad680f8 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -244,60 +244,65 @@ acpi_parse_entries(unsigned long table_size,
 struct acpi_table_header *table_header,
 int entry_id, unsigned int max_entries)
 {
-struct acpi_subtable_header *entry;
-int count = 0;
-unsigned long table_end;
+struct acpi_subtable_header *entry;
+int count = 0;
+unsigned long table_end;
 
-if (acpi_disabled)
-return -ENODEV;
+if ( acpi_disabled )
+return -ENODEV;
 
-if (!handler)
-return -EINVAL;
+if ( !handler )
+return -EINVAL;
 
-if (!table_size)
-return -EINVAL;
+if ( !table_size )
+return -EINVAL;
 
-if (!table_header) {
-printk("Table header not present\n");
-return -ENODEV;
-}
+if ( !table_header )
+{
+printk("Table header not present\n");
+return -ENODEV;
+}
 
-table_end = (unsigned long)table_header + table_header->length;
+table_end = (unsigned long)table_header + table_header->length;
 
-/* Parse all entries looking for a match. */
+/* Parse all entries looking for a match. */
 
-entry = (struct acpi_subtable_header *)
-((unsigned long)table_header + table_size);
-
-while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
-   table_end) {
-if (entry->type == entry_id
-&& (!max_entries || count++ < max_entries))
-if (handler(entry, table_end)) {
-count = -EINVAL;
-goto err;
-}
-
-/*
- * If entry->length is 0, break from this loop to avoid
- * infinite loop.
- */
-if (entry->length == 0) {
-printk("[0x%02x] Invalid zero length\n", entry_id);
-count = -EINVAL;
-goto err;
-}
-
-entry = (struct acpi_subtable_header *)
-((unsigned long)entry + entry->length);
-}
+entry = (struct acpi_subtable_header *)
+((unsigned long)table_header + table_size);
+
+while ( ( (unsigned long)entry ) + sizeof(struct acpi_subtable_header) <
+table_end)
+{
+if ( entry->type == entry_id
+&& ( !max_entries || count++ < max_entries ) )
+if ( handler(entry, table_end) )
+{
+count = -EINVAL;
+goto err;
+}
 
-if (max_entries && count > max_entries) {
-printk("[0x%02x] ignored %i entries of %i found\n",
-entry_id, count - max_entries, count);
+/*
+ * If entry->length is 0, break from this loop to avoid
+ * infinite loop.
+ */
+if ( entry->length == 0 )
+{
+printk("[0x%02x] Invalid zero length\n", entry_id);
+count = -EINVAL;
+goto err;
 }
 
-err:
+entry = (struct acpi_subtable_header *)
+((unsigned long)entry + entry->length);
+}
+
+if ( max_entries && count > max_entries )
+{
+printk("[0x%02x] ignored %i entries of %i found\n",
+entry_id, count - max_entries, count);
+}
+
+err:
 return count;
 }
 
@@ -394,7 +399,7 @@ int __init acpi_table_parse(char *id, acpi_table_handler 
handler)
return 1;
 }
 
-/* 
+/*
  * The BIOS is supposed to supply a single APIC/MADT,
  * but some report two.  Provide a knob to use either.
  * (don't you wish instance 0 and 1 were not the same?)
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 08/35] ACPI / table: Print GIC information when MADT is parsed

[parth . dixit]

From: Naresh Bhat 

When MADT is parsed, print GIC information to make the boot
log look pretty.

Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Naresh Bhat 
---
 xen/drivers/acpi/tables.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 1beca79..6754933 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -190,6 +190,45 @@ void __init acpi_table_print_madt_entry(struct 
acpi_subtable_header *header)
}
break;
 
+case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
+{
+struct acpi_madt_generic_interrupt *p =
+(struct acpi_madt_generic_interrupt *)header;
+printk(KERN_INFO PREFIX
+"GIC (acpi_id[0x%04x] gic_id[0x%04x] %s)\n",
+p->uid, p->gic_id,
+(p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
+}
+break;
+
+   case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
+{
+struct acpi_madt_generic_distributor *p =
+(struct acpi_madt_generic_distributor *)header;
+printk(KERN_INFO PREFIX
+"GIC Distributor (id[0x%04x] address[0x%08llx] 
gsi_base[%d])\n",
+p->gic_id, (long long unsigned int)p->base_address, 
p->global_irq_base);
+}
+break;
+
+   case ACPI_MADT_TYPE_GIC_MSI_FRAME:
+{
+struct acpi_madt_gic_msi_frame *p =
+(struct acpi_madt_gic_msi_frame *)header;
+printk("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
+(long long unsigned int)p->base_address, 
p->gic_msi_frame_id);
+}
+break;
+
+   case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
+   {
+struct acpi_madt_gic_redistributor *p =
+(struct acpi_madt_gic_redistributor *)header;
+printk("GIC Redistributor (address[0x%08llx] 
region_size[0x%x])\n",
+(long long unsigned int)p->base_address, 
p->region_size);
+   }
+   break;
+
default:
printk(KERN_WARNING PREFIX
   "Found unsupported MADT entry (type = %#x)\n",
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer

[parth . dixit]

From: Naresh Bhat 

Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
Using the information presented by GTDT to initialize the arch
timer (not momery-mapped).

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/setup.c   |  6 +
 xen/arch/arm/time.c| 66 ++
 xen/include/xen/time.h |  1 +
 3 files changed, 73 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 569b2da..af9f429 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -775,7 +775,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 smp_init_cpus();
 cpus = smp_get_max_cpus();
 
+/* Comment for now take it after GIC initialization */
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+   init_xen_acpi_time();
+#else
 init_xen_time();
+#endif
 
 gic_init();
 
@@ -789,6 +794,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 xsm_dt_init();
 
 init_maintenance_interrupt();
+
 init_timer_interrupt();
 
 timer_init();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 0add494..0d4c26d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -239,6 +240,71 @@ struct tm wallclock_time(uint64_t *ns)
 return (struct tm) { 0 };
 }
 
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+
+#define ACPI_GTDT_INTR_MASK 0x3
+
+static int GTDT_INTRL_TAB[] ={ DT_IRQ_TYPE_LEVEL_HIGH, DT_IRQ_TYPE_EDGE_RISING,
+  DT_IRQ_TYPE_LEVEL_LOW ,DT_IRQ_TYPE_EDGE_FALLING};
+
+/* Initialize per-processor generic timer */
+static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+{
+int res;
+int type;
+struct acpi_table_gtdt *gtdt;
+
+gtdt = (struct acpi_table_gtdt *)table;
+
+/* Initialize all the generic timer IRQ variable from GTDT table */
+
+type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->non_secure_el1_interrupt, type);
+timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->secure_el1_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->secure_el1_interrupt, type);
+timer_irq[TIMER_PHYS_SECURE_PPI] = gtdt->secure_el1_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->non_secure_el2_interrupt, type);
+timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
+
+type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags & ACPI_GTDT_INTR_MASK];
+acpi_set_irq(gtdt->virtual_timer_interrupt, type);
+timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
+
+printk("Generic Timer IRQ from ACPI GTDT: phys=%u hyp=%u virt=%u\n",
+   timer_irq[TIMER_PHYS_NONSECURE_PPI],
+   timer_irq[TIMER_HYP_PPI],
+   timer_irq[TIMER_VIRT_PPI]);
+
+res = platform_init_time();
+if ( res )
+printk("Timer: Cannot initialize platform timer");
+
+/* Check that this CPU supports the Generic Timer interface */
+if ( !cpu_has_gentimer )
+printk("CPU does not support the Generic Timer v1 interface");
+
+cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+
+boot_count = READ_SYSREG64(CNTPCT_EL0);
+
+printk("Using generic timer at %lu KHz\n", cpu_khz);
+
+return 0;
+}
+
+int __init init_xen_acpi_time(void)
+{
+   /* Initialize all the generic timers presented in GTDT */
+   acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+   return 0;
+}
+
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index 709501f..4598a0c 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+extern int init_xen_acpi_time(void);
 extern int init_xen_time(void);
 extern void cstate_restore_tsc(void);
 
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table

[parth . dixit]

From: Naresh Bhat 

Parse ACPI SPCR (Serial Port Console Redirection table) table and
initialize the serial port pl011.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/setup.c  |  6 +
 xen/drivers/char/pl011.c  | 69 +++
 xen/include/acpi/actbl2.h |  6 +
 xen/include/xen/serial.h  |  1 +
 4 files changed, 82 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index af9f429..317b985 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -762,7 +762,13 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 init_IRQ();
 
+/* If ACPI enabled and ARM64 arch then UART initialization from SPCR table 
*/
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+acpi_uart_init();
+#else
 dt_uart_init();
+#endif
+
 console_init_preirq();
 console_init_ring();
 
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..3499ee3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -280,6 +280,75 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
 .init = pl011_uart_init,
 DT_DEVICE_END
 
+/* Parse the SPCR table and initialize the Serial UART */
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+
+#include 
+
+static int __init acpi_pl011_uart_init(struct acpi_table_spcr *spcr)
+{
+struct pl011 *uart;
+u64 addr, size;
+
+uart = &pl011_com;
+uart->clock_hz  = 0x16e3600;
+uart->baud  = spcr->baud_rate;
+uart->data_bits = 8;
+uart->parity= spcr->parity;
+uart->stop_bits = spcr->stop_bits;
+
+if ( spcr->interrupt < 0 )
+{
+printk("pl011: Unable to retrieve the IRQ\n");
+return -EINVAL;
+}
+
+uart->irq = spcr->interrupt;
+addr = spcr->serial_port.address;
+size = 0x1000;
+uart->regs = ioremap_nocache(addr, size);
+
+acpi_set_irq(uart->irq, DT_IRQ_TYPE_EDGE_BOTH);
+
+if ( !uart->regs )
+{
+printk("pl011: Unable to map the UART memory\n");
+return -ENOMEM;
+}
+
+uart->vuart.base_addr = addr;
+uart->vuart.size = size;
+uart->vuart.data_off = DR;
+uart->vuart.status_off = FR;
+uart->vuart.status = 0;
+
+/* Register with generic serial driver. */
+serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
+
+return 0;
+}
+
+void __init acpi_uart_init(void)
+{
+struct acpi_table_spcr *spcr=NULL;
+
+printk("ACPI UART Init\n");
+acpi_get_table(ACPI_SIG_SPCR, 0,(struct acpi_table_header **)&spcr);
+
+switch(spcr->interface_type) {
+case ACPI_SPCR_TYPPE_PL011:
+acpi_pl011_uart_init(spcr);
+break;
+/* Not implemented yet */
+case ACPI_SPCR_TYPE_16550:
+case ACPI_SPCR_TYPE_16550_SUB:
+default:
+printk("iinvalid uart type\n");
+}
+}
+
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 87bc6b3..6aad200 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -815,6 +815,12 @@ struct acpi_table_spcr {
 
 #define ACPI_SPCR_DO_NOT_DISABLE(1)
 
+/* UART Interface type */
+#define ACPI_SPCR_TYPE_16550 0
+#define ACPI_SPCR_TYPE_16550_SUB 1
+#define ACPI_SPCR_TYPPE_PL011 3
+
+
 
/***
  *
  * SPMI - Server Platform Management Interface table
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..99e53d4 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -167,6 +167,7 @@ void ns16550_init(int index, struct ns16550_defaults 
*defaults);
 void ehci_dbgp_init(void);
 
 void __init dt_uart_init(void);
+void __init acpi_uart_init(void);
 
 struct physdev_dbgp_op;
 int dbgp_op(const struct physdev_dbgp_op *);
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 18/35] arm : add helper function for setting interrupt type

[parth . dixit]

From: Parth Dixit 

set edge/level type information for an interrupt

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/irq.c| 19 +++
 xen/include/asm-arm/irq.h |  4 
 2 files changed, 23 insertions(+)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 25ecf1d..ae4e99a 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -545,6 +545,25 @@ int platform_get_irq(const struct dt_device_node *device, 
int index)
 return irq;
 }
 
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+int acpi_set_irq(int irq,int type)
+{
+int res;
+
+/* Setup the IRQ type */
+if ( irq < NR_LOCAL_IRQS )
+res = irq_local_set_type(irq, type);
+else
+res = irq_set_spi_type(irq, type);
+
+if ( res )
+return -1;
+
+return 0;
+
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 435dfcd..7b09557 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -47,6 +47,10 @@ void arch_move_irqs(struct vcpu *v);
 /* Set IRQ type for an SPI */
 int irq_set_spi_type(unsigned int spi, unsigned int type);
 
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+int acpi_set_irq(int irq,int type);
+#endif
+
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0

[parth . dixit]

From: Naresh Bhat 

This patch prepare a DT from scratch for DOM0 for
ACPI-case only. Basically the DT contains minmal
required informations such as DOM0 bootargs, memory
and ACPI RSDP informations only.

Signed-off-by: Naresh Bhat 
---
 xen/arch/arm/domain_build.c | 67 -
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..bb7f043 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -61,6 +62,9 @@ custom_param("dom0_mem", parse_dom0_mem);
  */
 #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
 
+/* Reserve DOM0 FDT size in ACPI case only */
+#define DOM0_FDT_MIN_SIZE 4096
+
 struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 {
 if ( opt_dom0_max_vcpus == 0 )
@@ -1151,6 +1155,63 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 
+/*
+ * Prepare a minimal DTB for DOM0 which contains
+ * bootargs, memory information,
+ * ACPI RSDP pointer.
+ */
+static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+int new_size;
+int ret;
+
+DPRINT("Prepare a min DTB for DOM0\n");
+
+/* Allocate min size for DT */
+new_size = DOM0_FDT_MIN_SIZE;
+kinfo->fdt = xmalloc_bytes(DOM0_FDT_MIN_SIZE);
+
+if ( kinfo->fdt == NULL )
+return -ENOMEM;
+
+/* Create a new empty DT for DOM0 */
+ret = fdt_create(kinfo->fdt, new_size);
+if ( ret < 0 )
+goto err;
+
+/* Reserve the memory space for new DT */
+ret = fdt_finish_reservemap(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+ret = fdt_begin_node(kinfo->fdt, "/");
+if ( ret < 0 )
+goto err;
+
+ret = fdt_property_cell(kinfo->fdt, "#address-cells", 2);
+if ( ret )
+return ret;
+
+ret = fdt_property_cell(kinfo->fdt, "#size-cells", 1);
+if ( ret )
+return ret;
+
+ret = fdt_end_node(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+ret = fdt_finish(kinfo->fdt);
+if ( ret < 0 )
+goto err;
+
+return 0;
+
+  err:
+printk("Device tree generation failed (%d).\n", ret);
+xfree(kinfo->fdt);
+return -EINVAL;
+}
+
 static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
 {
 const void *fdt;
@@ -1305,7 +1366,11 @@ int construct_dom0(struct domain *d)
 
 allocate_memory(d, &kinfo);
 
-rc = prepare_dtb(d, &kinfo);
+if (acpi_disabled)
+rc = prepare_dtb(d, &kinfo);
+else
+rc = prepare_dtb_acpi(d, &kinfo);
+
 if ( rc < 0 )
 return rc;
 
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support

[parth . dixit]

From: Naresh Bhat 

ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
It needs to parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.

NOTE: This commit allow to initialize GICv1/2 only.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Graeme Gregory 
Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 

Conflicts:

xen/arch/arm/irq.c
---
 xen/arch/arm/gic-v2.c  | 271 +
 xen/arch/arm/setup.c   |   3 +-
 xen/include/asm-arm/acpi.h |   2 +
 3 files changed, 275 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..cb1d205 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
 .init = gicv2_init,
 DT_DEVICE_END
 
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Hard code here, we can not get memory size from MADT (but FDT does),
+ * this size can be inferred from GICv2 spec
+ */
+
+#define ACPI_GIC_DIST_MEM_SIZE   0x0001 // (SZ_64K)
+#define ACPI_GIC_CPU_IF_MEM_SIZE 0x2000 // (SZ_8K)
+
+static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
+static cpumask_t gic_acpi_cpu_mask;
+static u64 dist_phy_base;
+
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+unsigned int cpu;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+
+if (BAD_MADT_ENTRY(processor, end))
+return -EINVAL;
+for_each_possible_cpu(cpu) {
+/*
+ * FIXME: This condition is failing.
+ * In Xen we first want to bring/initialize the GIC in hypervisor with 
single CPU
+ * if (processor->mpidr == cpu_logical_map(cpu))
+ */
+goto find;
+}
+
+printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir 
%lx]\n",
+(long)processor->mpidr);
+
+return 0;
+
+find:
+/* Read from APIC table and fill up the GIC variables */
+gicv2.dbase = processor->redist_base_address;
+gicv2.cbase = processor->base_address;
+gicv2.hbase = processor->gich_base_address;
+gicv2.vbase = processor->gicv_base_address;
+gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
+if( processor->flags & ACPI_MADT_ENABLED )
+{
+if( processor->flags & ACPI_MADT_VGIC )
+acpi_set_irq(gicv2_info.maintenance_irq, 
DT_IRQ_TYPE_EDGE_BOTH);
+else
+acpi_set_irq(gicv2_info.maintenance_irq, 
DT_IRQ_TYPE_LEVEL_MASK);
+}
+
+/*
+ * Do not validate CPU i/f base, we can still use "Local Interrupt
+ * Controller Address" from MADT header instead.
+ */
+per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
+cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
+
+return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_distributor *dist;
+
+dist = (struct acpi_madt_generic_distributor *)header;
+
+if (BAD_MADT_ENTRY(dist, end))
+return -EINVAL;
+
+dist_phy_base = dist->base_address;
+
+return 0;
+}
+
+static int gic_acpi_validate_init(u64 madt_cpu_addr)
+{
+void __iomem *cpu_base, *dist_base;
+u64 gic_cpu_base = 0;
+unsigned int cpu;
+
+/* Process all GICC entries delivered by MADT */
+if (!cpumask_empty(&gic_acpi_cpu_mask)) {
+/*
+ * If MADT contains at least one GICC entry, it must be BSP
+ * dedicated.
+ */
+if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
+printk("GICC entries exist but unable to find BSP GICC 
"
+"address\n");
+goto madt_cpu_base;
+}
+
+/*
+ * There is no support for non-banked GICv1/2 register in ACPI
+ * spec. All CPU interface addresses have to be the same.
+ */
+gic_cpu_base = per_cpu(gic_percpu_cpu_base, 0);
+for_each_cpu (cpu, &gic_acpi_cpu_mask) {
+if (gic_cpu_base != per_cpu(gic_percpu_cpu_base, cpu)) 
{
+printk("GICC addresses are different, no 
support"
+"for non-banked GICC registers !!!\n");
+gic_cpu_base = 0;
+

[Xen-devel] [PATCH RFC 22/35] xen/arm: Create chosen node for DOM0

[parth . dixit]

From: Naresh Bhat 

Create a chosen node for DOM0 with
 - bootargs
 - rsdp

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 30bebe5..d781c63 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1199,6 +1200,41 @@ static int make_memory_node_acpi(const struct domain *d,
 return res;
 }
 
+static int make_chosen_node(const struct domain *d, const struct kernel_info 
*kinfo)
+{
+   int res = 0;
+   const char *bootargs = NULL;
+   const struct bootmodule *mod = kinfo->kernel_bootmodule;
+   u64 a = acpi_os_get_root_pointer();
+   void *fdt = kinfo->fdt;
+   __be32 val[2];
+   __be32 *cellp;
+
+   DPRINT("Create bootargs chosen node\n");
+
+   if ( mod && mod->cmdline[0] )
+bootargs = &mod->cmdline[0];
+
+   res = fdt_begin_node(fdt, "chosen");
+   if ( res )
+   return res;
+
+   res = fdt_property(fdt, "bootargs", bootargs, (strlen(bootargs)+1));
+   if ( res )
+  return res;
+
+   cellp = (__be32 *)val;
+   dt_set_cell(&cellp, ARRAY_SIZE(val), a);
+
+   res = fdt_property(fdt, "rsdp", &val, sizeof(val));
+   if ( res )
+   return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
 /*
  * Prepare a minimal DTB for DOM0 which contains
  * bootargs, memory information,
@@ -1244,6 +1280,11 @@ static int prepare_dtb_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( ret )
 goto err;
 
+/* Create a chosen node for DOM0 */
+ret = make_chosen_node(d, kinfo);
+if ( ret )
+goto err;
+
 ret = fdt_end_node(kinfo->fdt);
 if ( ret < 0 )
 goto err;
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 24/35] arm : acpi add xen environment table

[parth . dixit]

From: Parth Dixit 

Xen environment table is ACPI table that is used to pass grant table
and event channel interrupt information to dom0.

Signed-off-by: Parth Dixit 
---
 xen/include/acpi/actbl2.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 38e35d6..129ce70 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -80,6 +80,7 @@
 #define ACPI_SIG_WDDT   "WDDT" /* Watchdog Timer Description Table */
 #define ACPI_SIG_WDRT   "WDRT" /* Watchdog Resource Table */
 #define ACPI_SIG_STAO   "STAO"  /* Status Override Table */
+#define ACPI_SIG_XENV   "XENV"  /* Xen Environment Table */
 
 #ifdef ACPI_UNDEFINED_TABLES
 /*
@@ -910,6 +911,21 @@ struct acpi_table_stao {
 
 
/***
  *
+ * XENV - Xen Environment Table
+ *Version 1
+ *
+ 
**/
+
+struct acpi_table_xenv {
+struct acpi_table_header header;/* Common ACPI table header */
+u64 gnt_start;/* Starting address of Xen grant table region */
+u64 gnt_size; /* Size of Xen grant table region */
+u32 evt_intr;/* Xen event channel interrupt */
+u8  evt_intr_flag;/* Flags for event channel interrupt */
+};
+
+/***
+ *
  * WAET - Windows ACPI Emulated devices Table
  *Version 1
  *
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 23/35] arm: acpi add status override table

[parth . dixit]

From: Parth Dixit 

Status override table is used to hide devices from DOM0
that are used by xen

Signed-off-by: Parth Dixit 
---
 xen/include/acpi/actbl2.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 6aad200..38e35d6 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -79,6 +79,7 @@
 #define ACPI_SIG_WDAT   "WDAT" /* Watchdog Action Table */
 #define ACPI_SIG_WDDT   "WDDT" /* Watchdog Timer Description Table */
 #define ACPI_SIG_WDRT   "WDRT" /* Watchdog Resource Table */
+#define ACPI_SIG_STAO   "STAO"  /* Status Override Table */
 
 #ifdef ACPI_UNDEFINED_TABLES
 /*
@@ -895,6 +896,19 @@ struct acpi_table_uefi {
 };
 
 
/***
+  *
+  * STAO - Status Override Table
+  *Version 1
+  *
+ 
**/
+
+struct acpi_table_stao {
+struct acpi_table_header header;   /* Common ACPI table header */
+u8 uart;/* Indicates presence of SPCR table */
+u8 devpath[1];/* Full namepath of uart device in ACPI namespace */
+};
+
+/***
  *
  * WAET - Windows ACPI Emulated devices Table
  *Version 1
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 21/35] xen/arm: Create memory node for DOM0

[parth . dixit]

From: Naresh Bhat 

Create a memory node for DOM0.

Signed-off-by: Naresh Bhat 
---
 xen/arch/arm/domain_build.c | 48 +
 1 file changed, 48 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index bb7f043..30bebe5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1155,6 +1155,50 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 
+static int make_memory_node_acpi(const struct domain *d,
+void *fdt,
+int addr_cells,
+int size_cells,
+const struct kernel_info *kinfo)
+{
+int res, i;
+int reg_size = addr_cells + size_cells;
+int nr_cells = reg_size*kinfo->mem.nr_banks;
+__be32 reg[nr_cells];
+__be32 *cells;
+
+DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, 
nr_cells);
+
+/* ePAPR 3.4 */
+res = fdt_begin_node(fdt, "memory");
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "device_type", "memory");
+if ( res )
+return res;
+
+cells = ®[0];
+for ( i = 0 ; i < kinfo->mem.nr_banks; i++ )
+{
+u64 start = kinfo->mem.bank[i].start;
+u64 size = kinfo->mem.bank[i].size;
+
+DPRINT("  Bank %d: %#"PRIx64"->%#"PRIx64"\n",
+i, start, start + size);
+
+dt_set_range(&cells, fdt, start, size);
+}
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if ( res )
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
 /*
  * Prepare a minimal DTB for DOM0 which contains
  * bootargs, memory information,
@@ -1196,6 +1240,10 @@ static int prepare_dtb_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( ret )
 return ret;
 
+ret = make_memory_node_acpi(d, kinfo->fdt, 2, 1, kinfo);
+if ( ret )
+goto err;
+
 ret = fdt_end_node(kinfo->fdt);
 if ( ret < 0 )
 goto err;
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions

[parth . dixit]

From: Parth Dixit 

For passing ACPI tables to dom0, UEFI memory needs to be mapped
by xen in dom0 address space. This patch adds helper functions for mapping.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/p2m.c| 24 
 xen/include/asm-arm/p2m.h | 10 ++
 2 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 8809f5a..5593a91 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
  0, MATTR_MEM, p2m_ram_rw);
 }
 
+int map_ram_regions(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)
+{
+return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, p2m_mmio_direct);
+}
+
+int unmap_ram_regions(struct domain *d,
+   unsigned long start_gfn,
+   unsigned long nr,
+   unsigned long mfn)
+{
+return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, p2m_invalid);
+}
+
 int map_mmio_regions(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index da36504..be76ecd 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -132,6 +132,16 @@ int guest_physmap_add_entry(struct domain *d,
 unsigned long page_order,
 p2m_type_t t);
 
+int map_ram_regions(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr_mfns,
+unsigned long mfn);
+
+int unmap_ram_regions(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr_mfns,
+unsigned long mfn);
+
 /* Untyped version for RAM only, for compatibility */
 static inline int guest_physmap_add_page(struct domain *d,
  unsigned long gfn,
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 28/35] arm: acpi map acpi tables in dom0

[parth . dixit]

From: Parth Dixit 

map acpi tables described in uefi table to dom0 address space

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/arm64/acpi/arm-core.c | 43 ++
 xen/arch/arm/domain_build.c|  4 
 xen/include/asm-arm/acpi.h |  1 +
 3 files changed, 48 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index cc11fce..6707e4c 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -31,6 +31,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
@@ -241,6 +242,48 @@ static int __init acpi_parse_fadt(struct acpi_table_header 
*table)
return 0;
 }
 
+int acpi_map_tables(struct domain *d)
+{
+int i,res;
+u64 addr, size;
+
+/* map rsdp table */
+addr = acpi_os_get_root_pointer();
+size = sizeof(struct acpi_table_rsdp);
+
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
+{
+addr = acpi_gbl_root_table_list.tables[i].address;
+size = acpi_gbl_root_table_list.tables[i].length;
+
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+}
+
+return 0;
+}
+
 /*
  * acpi_boot_table_init() called from setup_arch(), always.
  *  1. find RSDP and get its address, and then find XSDT
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 49eb52a..a504064 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1278,6 +1278,10 @@ static int map_acpi_regions(struct domain *d)
 {
 int res;
 
+res = acpi_map_tables(d);
+if ( res )
+return res;
+
 res = acpi_map_mmio(d);
 if ( res )
 return res;
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 01ce28d..4f52cd6 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -108,5 +108,6 @@ static inline void acpi_disable_pci(void)
 #define MAX_GIC_CPU_INTERFACE 65535
 #define MAX_GIC_DISTRIBUTOR   1/* should be the same as 
MAX_GIC_NR */
 extern int __init acpi_gic_init(void);
+int acpi_map_tables(struct domain *d);
 
 #endif /*_ASM_ARM_ACPI_H*/
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table

[parth . dixit]

From: Parth Dixit 

Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
boot vcpu's

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/arm64/acpi/arm-core.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 6707e4c..9a26202 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -242,6 +243,19 @@ static int __init acpi_parse_fadt(struct acpi_table_header 
*table)
return 0;
 }
 
+static void set_psci_fadt(void)
+{
+struct acpi_table_fadt *fadt=NULL;
+struct acpi_table_header *table=NULL;
+u8 checksum;
+
+acpi_get_table(ACPI_SIG_FADT, 0, &table);
+fadt = (struct acpi_table_fadt *)table;
+fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT | 
ACPI_FADT_PSCI_USE_HVC );
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), fadt->header.length);
+fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
+}
+
 int acpi_map_tables(struct domain *d)
 {
 int i,res;
@@ -263,6 +277,8 @@ int acpi_map_tables(struct domain *d)
  return res;
 }
 
+set_psci_fadt();
+
 for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
 {
 addr = acpi_gbl_root_table_list.tables[i].address;
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 31/35] arm : acpi map status override table to dom0

[parth . dixit]

From: Parth Dixit 

hide UART used by xen by indicating it in STAO table
and map it to dom0

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/arm64/acpi/arm-core.c | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index a210596..9fd02f9 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -256,6 +256,48 @@ static void set_psci_fadt(void)
 fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
 }
 
+static int map_stao_table(struct domain *d, u64 *mstao)
+{
+u64 addr;
+u64 size;
+int res;
+u8 checksum;
+struct acpi_table_stao *stao=NULL;
+
+stao = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_table_stao) );
+if( stao == NULL )
+return -ENOMEM;
+
+ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);
+stao->header.length = sizeof(struct acpi_table_header) + 1;
+stao->header.checksum = 0;
+ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
+ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
+stao->header.revision = 1;
+ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
+stao->header.asl_compiler_revision = 0x20140828;
+stao->uart = 1;
+size = sizeof(struct acpi_table_stao);
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
+stao->header.checksum = (u8)( stao->header.checksum - checksum );
+*mstao = addr = virt_to_maddr(stao);
+
+res = map_ram_regions(d,
+  paddr_to_pfn(addr & PAGE_MASK),
+  DIV_ROUND_UP(size, PAGE_SIZE),
+  paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+   " - 0x%"PRIx64" in domain \n",
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+return res;
+}
+
+return 0;
+}
+
+
 #define NR_NEW_XEN_TABLES 2
 
 static int map_xsdt_table(struct domain *d, u64 *xsdt)
@@ -304,6 +346,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
 ( ( (size - sizeof(struct acpi_table_header) ) /
 sizeof(acpi_native_uint) ) );
 
+/* map stao table */
+map_stao_table(d, &addr);
+if(res)
+return res;
+
+table_entry--;
+*table_entry = addr ;
+
 checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
 table->checksum = (u8)( table->checksum - checksum );
 return 0;
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 27/35] arm: acpi map mmio regions to dom0

[parth . dixit]

From: Parth Dixit 

map mmio regions described in uefi tables to dom0 address space

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 54 +
 1 file changed, 54 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d781c63..49eb52a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1235,6 +1235,56 @@ static int make_chosen_node(const struct domain *d, 
const struct kernel_info *ki
 return res;
 }
 
+static int acpi_map_mmio(struct domain *d)
+{
+int i,res;
+u64 addr,size;
+
+for( i = 0; i < acpi_mmio.nr_banks; i++ )
+{
+addr = acpi_mmio.bank[i].start;
+size = acpi_mmio.bank[i].size;
+
+res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
+paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to permit to dom%d access to"
+   " 0x%"PRIx64" - 0x%"PRIx64"\n",
+   d->domain_id,
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+return res;
+}
+
+res = map_mmio_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+   " - 0x%"PRIx64" in domain %d\n",
+   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1,
+   d->domain_id);
+return res;
+}
+
+}
+
+ return 0;
+}
+
+static int map_acpi_regions(struct domain *d)
+{
+int res;
+
+res = acpi_map_mmio(d);
+if ( res )
+return res;
+
+return 0;
+}
+
 /*
  * Prepare a minimal DTB for DOM0 which contains
  * bootargs, memory information,
@@ -1264,6 +1314,10 @@ static int prepare_dtb_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( ret < 0 )
 goto err;
 
+ret = map_acpi_regions(d);
+if ( ret < 0 )
+goto err;
+
 ret = fdt_begin_node(kinfo->fdt, "/");
 if ( ret < 0 )
 goto err;
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 30/35] arm : acpi map XSDT table to dom0

[parth . dixit]

From: Parth Dixit 

XSDT table cannot be passed as is to dom0 because new tables specific to xen
need to be added to its table entries

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/arm64/acpi/arm-core.c | 65 --
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 9a26202..a210596 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -256,13 +256,74 @@ static void set_psci_fadt(void)
 fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
 }
 
+#define NR_NEW_XEN_TABLES 2
+
+static int map_xsdt_table(struct domain *d, u64 *xsdt)
+{
+int res;
+u64 size;
+u64 addr = *xsdt;
+u64 *new_xsdt;
+struct acpi_table_header *table;
+u64 *table_entry;
+u8 checksum;
+
+/* map xsdt table */
+table = acpi_os_map_memory(addr, sizeof(struct acpi_table_header) );
+size = table->length ;
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header) );
+
+table = acpi_os_map_memory(addr, size);
+size += ( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
+new_xsdt = ACPI_ALLOCATE_ZEROED(size);
+if( new_xsdt == NULL)
+return -ENOMEM;
+ACPI_MEMCPY(new_xsdt, table,table->length);
+acpi_os_unmap_memory(table, table->length);
+
+table = (struct acpi_table_header *) new_xsdt;
+table->length = size;
+*xsdt = addr = virt_to_maddr(new_xsdt);
+
+/* map xsdt region */
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+table_entry = ACPI_CAST_PTR(u64,
+( ACPI_CAST_PTR(u8, new_xsdt) + sizeof(struct acpi_table_header) ) );
+table_entry +=
+( ( (size - sizeof(struct acpi_table_header) ) /
+sizeof(acpi_native_uint) ) );
+
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
+table->checksum = (u8)( table->checksum - checksum );
+return 0;
+}
+
 int acpi_map_tables(struct domain *d)
 {
 int i,res;
-u64 addr, size;
+u64 addr, size, rsdp;
+struct acpi_table_rsdp *rsdt;
+
+addr = rsdp = acpi_os_get_root_pointer();
+rsdt = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp) );
+addr = rsdt->xsdt_physical_address;
+map_xsdt_table(d, &addr);
+rsdt->xsdt_physical_address = addr;
+acpi_os_unmap_memory(rsdt, sizeof(struct acpi_table_rsdp) );
 
 /* map rsdp table */
-addr = acpi_os_get_root_pointer();
+addr = rsdp;
 size = sizeof(struct acpi_table_rsdp);
 
 res = map_ram_regions(d,
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 33/35] arm : acpi enable efi for acpi

[parth . dixit]

From: Parth Dixit 

efi should be enabled to fetch the root pointer from uefi

Signed-off-by: Parth Dixit 
---
 xen/common/efi/runtime.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index c840e08..c8b8642 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
 #ifndef COMPAT
 
 #ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
+
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+const bool_t efi_enabled = 1;
+#else
 const bool_t efi_enabled = 0;
+#endif
+
 #else
 # include 
 # include 
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 26/35] arm : acpi read mmio tables from uefi

[parth . dixit]

From: Parth Dixit 

For ACPI on arm device initialization is done by dom0 after parsing DSDT.
xen requires mmio region information described in uefi tables
for mapping it to dom0.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/efi/efi-boot.h | 16 
 xen/arch/arm/setup.c|  1 +
 xen/include/asm-arm/setup.h |  1 +
 3 files changed, 18 insertions(+)

diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 639942d..535f484 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -127,6 +127,8 @@ static EFI_STATUS __init 
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
 {
 int Index;
 int i = 0;
+int j = 0;
+
 EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
 
 for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
@@ -145,10 +147,24 @@ static EFI_STATUS __init 
efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
 break;
 }
 }
+else if ( desc_ptr->Type == EfiMemoryMappedIO
+  || desc_ptr->Type == EfiMemoryMappedIOPortSpace )
+{
+acpi_mmio.bank[j].start = desc_ptr->PhysicalStart;
+acpi_mmio.bank[j].size  = desc_ptr->NumberOfPages * EFI_PAGE_SIZE;
+if ( ++j >= NR_MEM_BANKS )
+{
+PrintStr(L"Warning: All ");
+DisplayUint(NR_MEM_BANKS, -1);
+PrintStr(L" acpi meminfo mem banks exhausted.\r\n");
+break;
+}
+}
 desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
 }
 
 bootinfo.mem.nr_banks = i;
+acpi_mmio.nr_banks = j;
 return EFI_SUCCESS;
 }
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 93c8a8a..930746b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -50,6 +50,7 @@
 #include 
 
 struct bootinfo __initdata bootinfo;
+struct meminfo __initdata acpi_mmio;
 
 struct cpuinfo_arm __read_mostly boot_cpu_data;
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index ba5a67d..5ea9ed6 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -46,6 +46,7 @@ struct bootinfo {
 };
 
 extern struct bootinfo bootinfo;
+extern struct meminfo acpi_mmio;
 
 void arch_init_memory(void);
 
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies

[parth . dixit]

From: Parth Dixit 

Some bugs are identified in edk2 and some of the functionality is not
yet merged. This patch contains workarounds for them

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/domain_build.c | 82 -
 xen/arch/arm/vgic.c | 16 +
 xen/drivers/acpi/osl.c  |  7 ++--
 3 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a504064..a425ef4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1234,7 +1234,87 @@ static int make_chosen_node(const struct domain *d, 
const struct kernel_info *ki
 
 return res;
 }
+#define ACPI_UEFI_MEM_STUB
+
+#ifdef ACPI_UEFI_MEM_STUB
+enum{
+IO_NET0,
+IO_SREG,
+IO_VIRT,
+IO_SCT0,
+IO_AAC0,
+IO_MMC0,
+IO_KMI0,
+IO_KMI1,
+IO_SER1,
+IO_SER2,
+IO_SER3,
+IO_WDT0,
+IO_TIM0,
+IO_TIM2,
+IO_RTC0,
+IO_TIM3,
+IO_TIM4,
+IO_MAX
+};
+#define INIT_IO( dev,addr,size ) [dev] = {addr,size}
+
+static const u64 acpi_mmio_region[][IO_MAX]=
+{
+INIT_IO(IO_NET0,0x1a00,(PAGE_SIZE*16) ),
+INIT_IO(IO_SREG,0x1c01,PAGE_SIZE),
+INIT_IO(IO_VIRT,0x1c13,PAGE_SIZE),
+INIT_IO(IO_SCT0,0x1c02,PAGE_SIZE),
+INIT_IO(IO_AAC0,0x1c04,PAGE_SIZE),
+INIT_IO(IO_MMC0,0x1c05,PAGE_SIZE),
+INIT_IO(IO_KMI0,0x1c06,PAGE_SIZE),
+INIT_IO(IO_KMI1,0x1c07,PAGE_SIZE),
+INIT_IO(IO_SER1,0x1c0a,PAGE_SIZE),
+INIT_IO(IO_SER2,0x1c0b,PAGE_SIZE),
+INIT_IO(IO_SER3,0x1c0c,PAGE_SIZE),
+INIT_IO(IO_WDT0,0x1c0f,PAGE_SIZE),
+INIT_IO(IO_TIM0,0x1c11,PAGE_SIZE),
+INIT_IO(IO_TIM2,0x1c12,PAGE_SIZE),
+INIT_IO(IO_RTC0,0x1c17,PAGE_SIZE),
+INIT_IO(IO_TIM3,0x2a81,(PAGE_SIZE*16) ),
+INIT_IO(IO_TIM4,0x2a83,(PAGE_SIZE*16) ),
+};
+
+int acpi_map_mmio(struct domain *d)
+{
+int i,res;
+u64 addr,size;
+
+for (i = 0; i < IO_MAX; i++)
+{
+addr = acpi_mmio_region[i][0];
+size = acpi_mmio_region[i][1];
 
+res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
+  paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
+res = map_mmio_regions(d,
+   paddr_to_pfn(addr & PAGE_MASK),
+   DIV_ROUND_UP(size, PAGE_SIZE),
+   paddr_to_pfn(addr & PAGE_MASK));
+
+
+}
+#if 0
+ for( i=32 ; i < 255 ; i++ )
+ {
+res = vgic_reserve_virq(d, i);
+res = route_irq_to_guest(d, i, NULL);
+ if ( res )
+{
+printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
+   i, d->domain_id);
+}
+
+ }
+#endif
+ return 0;
+}
+#else
 static int acpi_map_mmio(struct domain *d)
 {
 int i,res;
@@ -1273,7 +1353,7 @@ static int acpi_map_mmio(struct domain *d)
 
  return 0;
 }
-
+#endif
 static int map_acpi_regions(struct domain *d)
 {
 int res;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..e74555d 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
 }
 }
 
+#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
+
 void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 {
 struct domain *d = v->domain;
@@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
 
 while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
 irq = i + (32 * n);
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+if( ( n!=0 ) && is_hardware_domain(d) ){
+struct vgic_irq_rank *vr = vgic_get_rank(v, n);
+uint32_t tr;
+tr = vr->icfg[i >> 4] ;
+
+if( ( tr & VGIC_ICFG_MASK(i) ) )
+acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
+else
+acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
+
+route_irq_to_guest(d,irq,NULL);
+}
+#endif
 v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
 p = irq_to_pending(v_target, irq);
 set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 73da9d9..2d78ba0 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
 
 acpi_physical_address __init acpi_os_get_root_pointer(void)
 {
-   if (efi_enabled) {
+if (efi_enabled) {
if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
return efi.acpi20;
else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
@@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 
value, u32 width)
 
return AE_OK;
 }
-
+#ifdef CONFIG_X86
 #define is_xmalloc_memory(ptr) ((unsigned lo

[Xen-devel] [PATCH RFC 35/35] xen: arm64: Add ACPI support

[parth . dixit]

From: Naresh Bhat 

Add ACPI support on arm64 xen hypervisor.

Signed-off-by: Naresh Bhat 
---
 config/arm64.mk  | 1 +
 xen/include/asm-arm/config.h | 5 +
 2 files changed, 6 insertions(+)

diff --git a/config/arm64.mk b/config/arm64.mk
index 6eafda2..91c1de4 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -8,6 +8,7 @@ CFLAGS += #-marm -march= -mcpu= etc
 
 HAS_PL011 := y
 HAS_NS16550 := y
+HAS_ACPI := y
 
 # Use only if calling $(LD) directly.
 LDFLAGS_DIRECT += -EL
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 264e2c1..184f5db 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -33,6 +33,11 @@
 
 #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
 
+#if defined(CONFIG_ARM_64)
+#define CONFIG_ACPI 1
+#define CONFIG_ACPI_BOOT 1
+#endif
+
 #define CONFIG_SMP 1
 
 #define CONFIG_VIDEO 1
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 32/35] arm : acpi map xen environment table to dom0

[parth . dixit]

From: Parth Dixit 

xen environment table contains the grant table address,size and event
channel interrupt information required by dom0.

Signed-off-by: Parth Dixit 
---
 xen/arch/arm/arm64/acpi/arm-core.c | 52 +-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 9fd02f9..9e9285c 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-
 /*
  * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
  * variable is still required by the ACPI core
@@ -297,6 +296,49 @@ static int map_stao_table(struct domain *d, u64 *mstao)
 return 0;
 }
 
+static int map_xenv_table(struct domain *d, u64 *mxenv)
+{
+u64 addr;
+u64 size;
+int res;
+u8 checksum;
+struct acpi_table_xenv *xenv=NULL;
+
+xenv = ACPI_ALLOCATE_ZEROED( sizeof(struct acpi_table_xenv) );
+if( xenv == NULL )
+return -ENOMEM;
+
+ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
+xenv->header.length = sizeof(struct acpi_table_header)+12;
+xenv->header.checksum = 0;
+ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
+ACPI_MEMCPY(xenv->header.oem_table_id, "RTSMVEV8", 8);
+xenv->header.revision = 1;
+ACPI_MEMCPY(xenv->header.asl_compiler_id, "INTL", 4);
+xenv->header.asl_compiler_revision = 0x20140828;
+xenv->gnt_start = 0x001000;
+xenv->gnt_size = 0x2;
+xenv->evt_intr = 31;
+xenv->evt_intr_flag =3;
+size = sizeof(struct acpi_table_xenv);
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), size);
+xenv->header.checksum = (u8)( xenv->header.checksum - checksum );
+*mxenv = addr = virt_to_maddr(xenv);
+
+res = map_ram_regions(d,
+paddr_to_pfn(addr & PAGE_MASK),
+DIV_ROUND_UP(size, PAGE_SIZE),
+paddr_to_pfn(addr & PAGE_MASK));
+if ( res )
+{
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+" - 0x%"PRIx64" in domain \n",
+addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+}
+
+return 0;
+}
 
 #define NR_NEW_XEN_TABLES 2
 
@@ -346,6 +388,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
 ( ( (size - sizeof(struct acpi_table_header) ) /
 sizeof(acpi_native_uint) ) );
 
+/* map xen env table */
+res = map_xenv_table(d, &addr);
+if(res)
+return res;
+
+table_entry--;
+*table_entry = addr ;
+
 /* map stao table */
 map_stao_table(d, &addr);
 if(res)
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 11/35] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[parth . dixit]

From: Naresh Bhat 

MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map and
cpu_present_map.

Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Naresh Bhat 
---
 xen/arch/arm/arm64/acpi/arm-core.c | 139 +
 xen/include/asm-arm/acpi.h |   2 +
 xen/include/xen/acpi.h |   5 ++
 3 files changed, 146 insertions(+)

diff --git a/xen/arch/arm/arm64/acpi/arm-core.c 
b/xen/arch/arm/arm64/acpi/arm-core.c
index 2b7e2ef..84b0032 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -26,7 +26,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
+#include 
 #include 
 
 /*
@@ -49,10 +52,141 @@ int acpi_psci_present;
 /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
 int acpi_psci_use_hvc;
 
+/* available_cpus means enabled cpu in MADT */
+static int available_cpus;
+
 enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
 
 struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
 
+/* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
+unsigned int total_cpus = 0;
+
+/*
+ * acpi_register_gic_cpu_interface - register a gic cpu interface and
+ * generates a logic cpu number
+ * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
+ * @enabled: this cpu is enabled or not
+ *
+ * Returns the logic cpu number which maps to the gic cpu interface
+ */
+static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
+{
+int cpu;
+
+if ( mpidr == INVALID_HWID )
+{
+printk("Skip invalid cpu hardware ID\n");
+return -EINVAL;
+}
+
+total_cpus++;
+if ( !enabled )
+return -EINVAL;
+
+if ( available_cpus >=  NR_CPUS )
+{
+printk("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+NR_CPUS, total_cpus, (long long unsigned 
int)mpidr);
+return -EINVAL;
+}
+
+/* If it is the first CPU, no need to check duplicate MPIDRs */
+if ( !available_cpus )
+goto skip_mpidr_check;
+
+/*
+* Duplicate MPIDRs are a recipe for disaster. Scan
+* all initialized entries and check for
+* duplicates. If any is found just ignore the CPU.
+*/
+for_each_present_cpu(cpu)
+{
+if ( cpu_logical_map(cpu) == mpidr )
+{
+printk("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
+(long long unsigned int)mpidr);
+return -EINVAL;
+}
+}
+
+skip_mpidr_check:
+available_cpus++;
+
+/* allocate a logic cpu id for the new comer */
+if ( cpu_logical_map(0) == mpidr )
+{
+/*
+ * boot_cpu_init() already hold bit 0 in cpu_present_mask
+ * for BSP, no need to allocte again.
+ */
+cpu = 0;
+}
+else
+cpu = cpumask_next_zero(-1, &cpu_present_map);
+
+/* map the logic cpu id to cpu MPIDR */
+cpu_logical_map(cpu) = mpidr;
+
+set_cpu_possible(cpu, true);
+set_cpu_present(cpu, true);
+
+return cpu;
+}
+
+static int __init
+acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+   const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+
+if ( BAD_MADT_ENTRY(processor, end) )
+return -EINVAL;
+
+acpi_table_print_madt_entry(header);
+
+acpi_register_gic_cpu_interface(processor->mpidr,
+processor->flags & ACPI_MADT_ENABLED);
+
+return 0;
+}
+
+/*
+ * Parse GIC cpu interface related entries in MADT
+ * returns 0 on success, < 0 on error
+ */
+static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
+{
+int count;
+
+/*
+ * do a partial walk of MADT to determine how many CPUs
+ * we have including disabled CPUs, and get information
+ * we need for SMP init
+ */
+count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
+
+if ( !count )
+{
+printk("No GIC CPU interface entries present\n");
+return -ENODEV;
+}
+else if ( count < 0 )
+{
+printk("Error parsing GIC CPU interface entry\n");
+return count;
+}
+
+/* Make boot-up look pretty */
+printk("%d CPUs available, %d CPUs total\n", available_cpus,
+total_cpus);
+
+return 0;
+}
+
 int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
 {
 *irq = -1;
@@ -140,6 +274,11 @@ int __init acpi_boot_init(void)
 if ( err )
 printk("Can't find FADT\n");
 
+/* Get the boot CPU's MPIDR before MADT parsing */
+cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
+
+err = acpi_parse_

[Xen-devel] [PATCH RFC 13/35] ACPI: Introduce acpi_parse_entries

[parth . dixit]

From: Naresh Bhat 

Introduce acpi_parse_entries

Signed-off-by: Naresh Bhat 
---
 xen/drivers/acpi/tables.c | 64 +++
 xen/include/xen/acpi.h|  4 +++
 2 files changed, 68 insertions(+)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 6754933..5314f0b 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -239,6 +239,70 @@ void __init acpi_table_print_madt_entry(struct 
acpi_subtable_header *header)
 
 
 int __init
+acpi_parse_entries(unsigned long table_size,
+acpi_table_entry_handler handler,
+struct acpi_table_header *table_header,
+int entry_id, unsigned int max_entries)
+{
+struct acpi_subtable_header *entry;
+int count = 0;
+unsigned long table_end;
+
+if (acpi_disabled)
+return -ENODEV;
+
+if (!handler)
+return -EINVAL;
+
+if (!table_size)
+return -EINVAL;
+
+if (!table_header) {
+printk("Table header not present\n");
+return -ENODEV;
+}
+
+table_end = (unsigned long)table_header + table_header->length;
+
+/* Parse all entries looking for a match. */
+
+entry = (struct acpi_subtable_header *)
+((unsigned long)table_header + table_size);
+
+while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
+   table_end) {
+if (entry->type == entry_id
+&& (!max_entries || count++ < max_entries))
+if (handler(entry, table_end)) {
+count = -EINVAL;
+goto err;
+}
+
+/*
+ * If entry->length is 0, break from this loop to avoid
+ * infinite loop.
+ */
+if (entry->length == 0) {
+printk("[0x%02x] Invalid zero length\n", entry_id);
+count = -EINVAL;
+goto err;
+}
+
+entry = (struct acpi_subtable_header *)
+((unsigned long)entry + entry->length);
+}
+
+if (max_entries && count > max_entries) {
+printk("[0x%02x] ignored %i entries of %i found\n",
+entry_id, count - max_entries, count);
+}
+
+err:
+return count;
+}
+
+
+int __init
 acpi_table_parse_entries(char *id,
 unsigned long table_size,
 int entry_id,
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 9387b36..bf60334 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -81,6 +81,10 @@ void acpi_hest_init(void);
 
 int acpi_table_init (void);
 int acpi_table_parse(char *id, acpi_table_handler handler);
+int __init acpi_parse_entries(unsigned long table_size,
+acpi_table_entry_handler handler,
+struct acpi_table_header *table_header,
+int entry_id, unsigned int max_entries);
 int acpi_table_parse_entries(char *id, unsigned long table_size,
int entry_id, acpi_table_entry_handler handler, unsigned int 
max_entries);
 int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler 
handler, unsigned int max_entries);
-- 
1.9.1


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

[Xen-devel] [PATCH RFC 14/35] ACPI / ACPICA: Add GTDT support updated by ACPI 5.1

[parth . dixit]

From: Naresh Bhat 

With ACPI 5.0, we got per-processor timer support in GTDT,
and ACPI 5.1 introduced the support for platform (memory-mapped)
timers: GT Block and SBSA watchdog timer, add the code needed
in this patch.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
---
 xen/include/acpi/actbl3.h | 90 ---
 1 file changed, 77 insertions(+), 13 deletions(-)

diff --git a/xen/include/acpi/actbl3.h b/xen/include/acpi/actbl3.h
index 8c61b5f..0d1ff52 100644
--- a/xen/include/acpi/actbl3.h
+++ b/xen/include/acpi/actbl3.h
@@ -241,34 +241,98 @@ struct acpi_s3pt_suspend {
 
 
/***
  *
- * GTDT - Generic Timer Description Table (ACPI 5.0)
+ * GTDT - Generic Timer Description Table (ACPI 5.1)
  *Version 1
  *
  
**/
 
 struct acpi_table_gtdt {
struct acpi_table_header header;/* Common ACPI table header */
-   u64 address;
-   u32 flags;
-   u32 secure_pl1_interrupt;
-   u32 secure_pl1_flags;
-   u32 non_secure_pl1_interrupt;
-   u32 non_secure_pl1_flags;
+   u64 cnt_control_base_address;
+   u32 reserved;
+   u32 secure_el1_interrupt;
+   u32 secure_el1_flags;
+   u32 non_secure_el1_interrupt;
+   u32 non_secure_el1_flags;
u32 virtual_timer_interrupt;
u32 virtual_timer_flags;
-   u32 non_secure_pl2_interrupt;
-   u32 non_secure_pl2_flags;
+   u32 non_secure_el2_interrupt;
+   u32 non_secure_el2_flags;
+   u64 cnt_read_base_address;
+   u32 platform_timer_count;
+   u32 platform_timer_offset;
 };
 
-/* Values for Flags field above */
-
-#define ACPI_GTDT_MAPPED_BLOCK_PRESENT  1
-
 /* Values for all "TimerFlags" fields above */
 
 #define ACPI_GTDT_INTERRUPT_MODE1
 #define ACPI_GTDT_INTERRUPT_POLARITY2
 
+#define ACPI_GTDT_ALWAYS_ON4
+
+/* Values for GTDT subtable type in struct acpi_subtable_header */
+
+enum acpi_gtdt_type {
+   ACPI_GTDT_TYPE_GT_BLOCK = 0,/* memory-mapped generic timer */
+   ACPI_GTDT_TYPE_SBSA_GENERIC_WATCHDOG = 1,
+   ACPI_GTDT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
+};
+
+/*
+ * GTDT Subtables, correspond to Type in struct acpi_subtable_header
+ */
+
+/* 0: Generic Timer Block */
+
+struct acpi_gtdt_gt_block {
+   struct acpi_subtable_header header;
+   u16 reserved;
+   u64 gt_block_address;
+   u32 gt_block_timer_count;   /* must be less than or equal to 8 */
+   u32 gt_block_timer_offset;
+};
+
+/* GT Block Timer Structure */
+
+struct acpi_gt_block_timer {
+   u8 gt_frame_number;
+   u8 reseved[3];
+   u64 cnt_base_address;
+   u64 cnt_el0_base_adress;
+   u32 physical_timer_interrupt;
+   u32 physical_timer_flags;
+   u32 vitual_timer_interrupt;
+   u32 vitual_timer_flags;
+   u32 timer_common_flags;
+};
+
+/* Flag Definitions: GT Block Physical Timers and Virtual timers */
+
+#define ACPI_GT_BLOCK_INTERRUPT_MODE   1
+#define ACPI_GT_BLOCK_INTERRUPT_POLARITY   2
+
+/* Flag Definitions: Common Flags */
+
+#define ACPI_GT_BLOCK_IS_SECURE_TIMER  1
+#define ACPI_GT_BLOCK_ALWAYS_ON2
+
+/* 1: SBSA Generic Watchdog Structure */
+
+struct acpi_sbsa_generic_watchdog {
+   struct acpi_subtable_header header;
+   u16 reserved;
+   u64 refresh_frame_address;
+   u64 control_frame_address;
+   u32 interrupt;
+   u32 flags;
+};
+
+/* Flag Definitions: SBSA Generic Watchdog */
+
+#define ACPI_SBSA_WATCHDOG_INTERRUPT_MODE  1
+#define ACPI_SBSA_WATCHDOG_INTERRUPT_POLARITY  2
+#define ACPI_SBSA_WATCHDOG_IS_SECURE_TIMER 4
+
 
/***
  *
  * MPST - Memory Power State Table (ACPI 5.0)
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] ts-rumpuserxen-build: Use new app-tools

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH] ts-rumpuserxen-build: Use new app-tools"):
> On Wed, 2015-02-04 at 12:36 +0100, Martin Lucina wrote:
> > Update to use the new app-tools names.
> 
> I'm not sure if we need to support bisection over this change -- but I
> think we probably do (Ian?) in which case we would need to probe for
> which one actually exists, preferring the newer name.

It's not just bisection; our push gate will fail because of the lack
of compatibility.

So we need to probe.  I will prepare a patch.

Ian.

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

Re: [Xen-devel] [PATCH v3 07/19] TestSupport: always use xl for generic operations.

[Ian Campbell]

On Tue, 2015-01-27 at 17:09 +, Ian Campbell wrote:
> On Tue, 2015-01-27 at 16:40 +, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH v3 07/19] TestSupport: always use xl for 
> > generic operations."):
> > > Unless the toolstack is xend (for compatibility with pre-xl Xen
> > > versions), when we use xm.
> > 
> > Acked-by: Ian Jackson 
> 
> Thanks.
> 
> > > For several operations in TestSupport.pm the actual toolstack isn't
> > > really relevant, since we want info straight from Xen. For simplicity
> > > just use xl (or xm) in these cases, to avoid needing to implement the
> > > following specially for each toolstack:
> > >   - host_get_free_memory
> > >   - guest_get_state
> > >   - guest_find_domid
> > >   - listing assignable pci devices
> > 
> > I think at the very least "guest_get_state" should be implemented
> > per-toolstack to exercise the toolstack's query functionality.  But
> > that's not a blocker for this series.
> 
> True. I'll see if I can make that happen for v4.

... I didn't.

I've just looked now and I don't see a way to extract the necessary
granularity info via virsh needed to replicate the interface which the
callers expect. I can just get running or not.

Possibly with some refactoring the callers could be made to ask
questions which virsh can answer, but I don't propose to work on that
right now.

Ian.


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

Re: [Xen-devel] [PATCH] ts-rumpuserxen-build: Use new app-tools

[Antti Kantee]

On 04/02/15 14:33, Ian Jackson wrote:

Ian Campbell writes ("Re: [PATCH] ts-rumpuserxen-build: Use new app-tools"):

On Wed, 2015-02-04 at 12:36 +0100, Martin Lucina wrote:

Update to use the new app-tools names.


I'm not sure if we need to support bisection over this change -- but I
think we probably do (Ian?) in which case we would need to probe for
which one actually exists, preferring the newer name.


It's not just bisection; our push gate will fail because of the lack
of compatibility.

So we need to probe.  I will prepare a patch.


Can the grievous-bodge grievances now be removed, or are prehistoric 
revisions still required to build?


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

[Xen-devel] [OSSTEST PATCH] ts-rumpuserxen-build: Cope with rumprun-xen rename

[Ian Jackson]

rumpxen-app-* has been renamed to rumprun-xen-*.  We need to cope with
either, at least for the transition.

Signed-off-by: Ian Jackson 
CC: Martin Lucina 
---
 ts-rumpuserxen-build |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/ts-rumpuserxen-build b/ts-rumpuserxen-build
index 47bcf76..9e6580a 100755
--- a/ts-rumpuserxen-build
+++ b/ts-rumpuserxen-build
@@ -98,9 +98,14 @@ END
 }
 
 sub recordtools() {
-my $apptool = "$rux/app-tools/rumpxen-app";
-store_runvar('cmdprefix_configure', "$apptool-configure");
-store_runvar('cmdprefix_make',  "$apptool-make");
+foreach my $stem (qw(rumprun-xen rumpxen-app)) {
+   my $apptool = "$rux/app-tools/$stem";
+   next unless target_file_exists($ho, "$apptool-configure");
+   store_runvar('cmdprefix_configure', "$apptool-configure");
+   store_runvar('cmdprefix_make',  "$apptool-make");
+   return;
+}
+die "app-tools not found ($rux)";
 }
 
 sub install() {
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH] ts-rumpuserxen-build: Use new app-tools

[Ian Jackson]

Antti Kantee writes ("Re: [PATCH] ts-rumpuserxen-build: Use new app-tools"):
> On 04/02/15 14:33, Ian Jackson wrote:
> > So we need to probe.  I will prepare a patch.
> 
> Can the grievous-bodge grievances now be removed, or are prehistoric 
> revisions still required to build?

I think we can probably delete those now but we should do that as a
separate step to reduce the risk of messing up.  We want the fix to
cope with rumprun-xen to pass the osstest self-push-gate.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH] ts-rumpuserxen-build: Cope with rumprun-xen rename

[Ian Campbell]

On Wed, 2015-02-04 at 14:41 +, Ian Jackson wrote:
> rumpxen-app-* has been renamed to rumprun-xen-*.  We need to cope with
> either, at least for the transition.
> 
> Signed-off-by: Ian Jackson 
> CC: Martin Lucina 

Acked-by: Ian Campbell 

> ---
>  ts-rumpuserxen-build |   11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/ts-rumpuserxen-build b/ts-rumpuserxen-build
> index 47bcf76..9e6580a 100755
> --- a/ts-rumpuserxen-build
> +++ b/ts-rumpuserxen-build
> @@ -98,9 +98,14 @@ END
>  }
>  
>  sub recordtools() {
> -my $apptool = "$rux/app-tools/rumpxen-app";
> -store_runvar('cmdprefix_configure', "$apptool-configure");
> -store_runvar('cmdprefix_make',  "$apptool-make");
> +foreach my $stem (qw(rumprun-xen rumpxen-app)) {
> + my $apptool = "$rux/app-tools/$stem";
> + next unless target_file_exists($ho, "$apptool-configure");
> + store_runvar('cmdprefix_configure', "$apptool-configure");
> + store_runvar('cmdprefix_make',  "$apptool-make");
> + return;
> +}
> +die "app-tools not found ($rux)";
>  }
>  
>  sub install() {



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

Re: [Xen-devel] [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support

[G Gregory]

On 4 February 2015 at 14:02,   wrote:
> From: Naresh Bhat 
>
> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
> It needs to parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>
> NOTE: This commit allow to initialize GICv1/2 only.
>
> Signed-off-by: Tomasz Nowicki 
> Signed-off-by: Graeme Gregory 

I do not recognise any of the code here and I'm pretty sure I have not
worked on any of it. I am unsure what the rules on Signed-off-by: is
but I think this one is wrong.

Graeme

> Signed-off-by: Hanjun Guo 
> Signed-off-by: Naresh Bhat 
> Signed-off-by: Parth Dixit 
>
> Conflicts:
>
> xen/arch/arm/irq.c
> ---
>  xen/arch/arm/gic-v2.c  | 271 
> +
>  xen/arch/arm/setup.c   |   3 +-
>  xen/include/asm-arm/acpi.h |   2 +
>  3 files changed, 275 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index faad1ff..cb1d205 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
>  .init = gicv2_init,
>  DT_DEVICE_END
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Hard code here, we can not get memory size from MADT (but FDT does),
> + * this size can be inferred from GICv2 spec
> + */
> +
> +#define ACPI_GIC_DIST_MEM_SIZE   0x0001 // (SZ_64K)
> +#define ACPI_GIC_CPU_IF_MEM_SIZE 0x2000 // (SZ_8K)
> +
> +static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
> +static cpumask_t gic_acpi_cpu_mask;
> +static u64 dist_phy_base;
> +
> +static int __init
> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> +const unsigned long end)
> +{
> +struct acpi_madt_generic_interrupt *processor;
> +unsigned int cpu;
> +
> +processor = (struct acpi_madt_generic_interrupt *)header;
> +
> +if (BAD_MADT_ENTRY(processor, end))
> +return -EINVAL;
> +for_each_possible_cpu(cpu) {
> +/*
> + * FIXME: This condition is failing.
> + * In Xen we first want to bring/initialize the GIC in hypervisor 
> with single CPU
> + * if (processor->mpidr == cpu_logical_map(cpu))
> + */
> +goto find;
> +}
> +
> +printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir 
> %lx]\n",
> +(long)processor->mpidr);
> +
> +return 0;
> +
> +find:
> +/* Read from APIC table and fill up the GIC variables */
> +gicv2.dbase = processor->redist_base_address;
> +gicv2.cbase = processor->base_address;
> +gicv2.hbase = processor->gich_base_address;
> +gicv2.vbase = processor->gicv_base_address;
> +gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
> +if( processor->flags & ACPI_MADT_ENABLED )
> +{
> +if( processor->flags & ACPI_MADT_VGIC )
> +acpi_set_irq(gicv2_info.maintenance_irq, 
> DT_IRQ_TYPE_EDGE_BOTH);
> +else
> +acpi_set_irq(gicv2_info.maintenance_irq, 
> DT_IRQ_TYPE_LEVEL_MASK);
> +}
> +
> +/*
> + * Do not validate CPU i/f base, we can still use "Local Interrupt
> + * Controller Address" from MADT header instead.
> + */
> +per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
> +cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
> +
> +return 0;
> +}
> +
> +static int __init
> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
> +const unsigned long end)
> +{
> +struct acpi_madt_generic_distributor *dist;
> +
> +dist = (struct acpi_madt_generic_distributor *)header;
> +
> +if (BAD_MADT_ENTRY(dist, end))
> +return -EINVAL;
> +
> +dist_phy_base = dist->base_address;
> +
> +return 0;
> +}
> +
> +static int gic_acpi_validate_init(u64 madt_cpu_addr)
> +{
> +void __iomem *cpu_base, *dist_base;
> +u64 gic_cpu_base = 0;
> +unsigned int cpu;
> +
> +/* Process all GICC entries delivered by MADT */
> +if (!cpumask_empty(&gic_acpi_cpu_mask)) {
> +/*
> + * If MADT contains at least one GICC entry, it must be BSP
> + * dedicated.
> + */
> +if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
> +printk("GICC entries exist but unable to find BSP 
> GICC "
> +"address\n");
> +goto madt_cpu_base;
> +}
> +
> +/*
> + * There is no support for non-banked GICv1/2 register in 
> ACPI
> + * spec

Re: [Xen-devel] [PATCH v2] rump kernels: use new platform macro

[Ian Jackson]

Wei Liu writes ("[PATCH v2] rump kernels: use new platform macro"):
> Starting from rump kernel changeset 91d5623 ("Renaming platform macros,
> app-tools and autoconf target string"), __RUMPUSER_XEN__ and __RUMPAPP__
> are deleted. We are supposed to use __RUMPRUN__ instead.
> 
> We still keep __RUMPUSER_XEN__ for now in order to make xen-unstable
> pass osstest push gate. I will remove __RUMPUSER_XEN__ later.

Acked-by: Ian Jackson 

I will push shortly.

Ian.

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

Re: [Xen-devel] Xen's Linux kernel config options V2

[Stefano Stabellini]

On Wed, 4 Feb 2015, David Vrabel wrote:
> On 16/12/14 16:21, Juergen Gross wrote:
> > Hi,
> > 
> > This is a design proposal for a rework of the config options on the
> > Linux kernel which are related to Xen.
> > 
> > The need to do so arose from the fact that it is currently not
> > possible to build the Xen frontend drivers for a non-pvops kernel,
> > e.g. to run them in a HVM-domain. There are more drawbacks in the
> > current config options to which I'll come later.
> > 
> > Option  Selects Depends
> > --
> > XEN
> >   XEN_PV(x86)   XEN_HAVE_PVMMU
> > PARAVIRT
> > PARAVIRT_CLOCK
> >   XEN_PVH(x86)  XEN_PVHVM
> > PARAVIRT  
> > PARAVIRT_CLOCK
> >   XEN_PVHVM PARAVIRT
> > PARAVIRT_CLOCK

PARAVIRT_CLOCK and PARAVIRT are x86 specific.
Given that there is no CONFIG_PV or CONFIG_PVH or even CONFIG_PVHVM on
arm and arm64 as there is just one type of guest, I would rather just
have CONFIG_XEN there.


> >   XEN_BACKEND   SWIOTLB_XEN(arm,arm64)  XEN_PV(x86) ||
> > XEN_PVH(x86) ||
> > XEN_PVHVM
> > XEN_BLKDEV_BACKEND
> > XEN_PCIDEV_BACKEND(x86)
> > XEN_SCSI_BACKEND
> > XEN_NETDEV_BACKEND
> >   PCI_XEN(x86)  SWIOTLB_XEN
> >   XEN_DOM0  XEN_BACKEND XEN_PV(x86) ||
> > PCI_XEN(x86)XEN_PVH(x86)
> > XEN_ACPI_HOTPLUG_MEMORY XEN_STUB
> > XEN_ACPI_HOTPLUG_CPUXEN_STUB
> > XEN_MCE_LOG(x86)
> >   XEN_MAX_DOMAIN_MEMORY(x86)
> >   XEN_SAVE_RESTORE(x86)
> >   XEN_DEBUG_FS
> >   XEN_WDT
> >   XEN_BALLOON
> > XEN_SELFBALLOONING  XEN_TMEM
> > XEN_BALLOON_MEMORY_HOTPLUG
> > XEN_SCRUB_PAGES
> >   XENFS XEN_PRIVCMD
> > XEN_COMPAT_XENFS
> >   XEN_SYS_HYPERVISOR
> >   XEN_DEV_EVTCHN
> >   XEN_GNTDEV
> >   XEN_GRANT_DEV_ALLOC
> >   SWIOTLB_XEN
> >   XEN_TMEM

not available on arm and arm64


> >   XEN_PRIVCMD
> >   XEN_STUB(x86_64)  BROKEN
> >   XEN_ACPI_PROCESSOR(x86)
> >   XEN_HAVE_PVMMU

x86 specific


> >   XEN_EFI(x64)

FYI soon to be available on arm


> >   XEN_XENBUS_FRONTEND
> > XEN_FRONTENDXEN
> > XEN_XENBUS_FRONTEND
> >   XEN_FBDEV_FRONTENDINPUT_XEN_KBDDEV_FRONTEND
> >   XEN_BLKDEV_FRONTEND
> >   HVC_XEN_FRONTEND  HVC_XEN
> >   TCG_XEN
> >   XEN_PCIDEV_FRONTEND   PCI_XEN

x86 specific for the moment


> >   XEN_SCSI_FRONTEND
> >   INPUT_XEN_KBDDEV_FRONTEND
> >   XEN_NETDEV_FRONTEND
> >   XEN_PLATFORM_PCI

definitely x86 only


> This looks fine to me.
> 
> David
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH v2] rump kernels: use new platform macro

[Ian Jackson]

Wei Liu writes ("[PATCH v2] rump kernels: use new platform macro"):
> Starting from rump kernel changeset 91d5623 ("Renaming platform macros,
> app-tools and autoconf target string"), __RUMPUSER_XEN__ and __RUMPAPP__
> are deleted. We are supposed to use __RUMPRUN__ instead.
> 
> We still keep __RUMPUSER_XEN__ for now in order to make xen-unstable
> pass osstest push gate. I will remove __RUMPUSER_XEN__ later.

Actually, I think there is a problem here.  Are we supposed to
backport this patch to previous (stable, released) versions of Xen ?
Obviously we can do that but I don't think we should be breaking the
rumpkernel build for old versions of Xen, at least until there has
been quite a while for the stable backports to make it into Xen.

If we apply Wei's patch to xen.git#staging, and it ends up in
xen.git#master, the osstest rumpuser-xen push gate will pass and push
the rumpkernel changes to the osstest push gate output.  That version
will then be used for tests of Xen 4.5, causing the Xen 4.5 push gate
to fail.

I think this shows that:
  - Wei's patch should not be applied to xen.git#staging yet
  - The rump kernel tree ought to continue to -D the old names for now
  - After that, Wei's patch should go into xen.git#staging and be
a backport candidate
  - The rump kernel tree may remove the old -D's only (at least)
after Wei's patch has made it to xen.git#stable-4.*; but preferably
only after stable Xen releases have been made containing Wei's
patch.

I'm sorry that I didn't spot in the rumpkernel-users messages about
this that it was intended to remove the old -D options.

Thanks,
Ian.

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

Re: [Xen-devel] Xen's Linux kernel config options V2

[Ian Campbell]

On Wed, 2015-02-04 at 14:57 +, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, David Vrabel wrote:
> > On 16/12/14 16:21, Juergen Gross wrote:
> > > Hi,
> > > 
> > > This is a design proposal for a rework of the config options on the
> > > Linux kernel which are related to Xen.
> > > 
> > > The need to do so arose from the fact that it is currently not
> > > possible to build the Xen frontend drivers for a non-pvops kernel,
> > > e.g. to run them in a HVM-domain. There are more drawbacks in the
> > > current config options to which I'll come later.
> > > 
> > > Option  Selects Depends
> > > --
> > > XEN
> > >   XEN_PV(x86)   XEN_HAVE_PVMMU
> > > PARAVIRT
> > > PARAVIRT_CLOCK
> > >   XEN_PVH(x86)  XEN_PVHVM
> > > PARAVIRT  
> > > PARAVIRT_CLOCK
> > >   XEN_PVHVM PARAVIRT
> > > PARAVIRT_CLOCK
> 
> PARAVIRT_CLOCK and PARAVIRT are x86 specific.

Does PARAVIRT_CLOCK include the pvclock_read_wallclock stuff? Eventually
we are going to want that functionality on ARM too, although it's not
clear to me that bundling pv-wallclock and pv-cyclecounter in
arch/x86/kernel/pvclock.c under the same config option is most correct.

Ian.


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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Stefano Stabellini]

On Mon, 2 Feb 2015, Julien Grall wrote:
> On 02/02/15 12:16, Ian Campbell wrote:
> > On Mon, 2015-02-02 at 11:40 +, Jan Beulich wrote:
> > On 02.02.15 at 12:14,  wrote:
> >>> On Mon, 2015-02-02 at 12:49 +0200, Denys Drozdov wrote:
>  The issue observed on credit2 scheduler is similar to the rt scheduler
>  on arm platform. The root cause is that interrupts are disabled in the
>  beginning of arm context_switch, thus spin_lock_irq is failing in
>  ASSERT(local_irq_is_enabled()). I propose to change both credit2 and
>  rt scheduler to run on arm platform as well and re-run the regression
>  with scheduler patches.
> >>>
> >>> I'd like to hear from the scheduler and other $arch folks regarding
> >>> whether we think the rtds and credit2 schedulers are wrong or whether it
> >>> is actually the ARM arch code which needs fixing before considering any
> >>> change.
> >>
> >> The aspect to be understood first is why ARM needs IRQs disabled
> >> past __context_switch() into schedule_tail() (and there until after
> >> ctxt_switch_from() and ctxt_switch_to()). If that's indeed necessary,
> >> there's no question that the schedulers need to be adjusted to
> >> accommodate for this.
> > 
> > I don't think it's *necessary*, but we do seem to have ended up with the
> > context switch having that requirement today (and relying on it in
> > several places in switch from/to (mostly to).
> 
> > I'm pretty sure we could rework things more along the lines of how x86
> > does it if needed, but it would be a non-trivial refactoring I think.
> 
> We have some part of the code which may inject an interrupt during
> context switch.
> For instance the timer may inject an IRQ as long as it has not been
> disabled. Same when the timer is restored.
> 
> The former may result to inject an interrupt to the wrong vCPU.

Also the gic save and restore functions need to be run with interrupt
disabled.

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

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Ian Campbell]

On Wed, 2015-02-04 at 15:04 +, Stefano Stabellini wrote:
> On Mon, 2 Feb 2015, Julien Grall wrote:
> > On 02/02/15 12:16, Ian Campbell wrote:
> > > On Mon, 2015-02-02 at 11:40 +, Jan Beulich wrote:
> > > On 02.02.15 at 12:14,  wrote:
> > >>> On Mon, 2015-02-02 at 12:49 +0200, Denys Drozdov wrote:
> >  The issue observed on credit2 scheduler is similar to the rt scheduler
> >  on arm platform. The root cause is that interrupts are disabled in the
> >  beginning of arm context_switch, thus spin_lock_irq is failing in
> >  ASSERT(local_irq_is_enabled()). I propose to change both credit2 and
> >  rt scheduler to run on arm platform as well and re-run the regression
> >  with scheduler patches.
> > >>>
> > >>> I'd like to hear from the scheduler and other $arch folks regarding
> > >>> whether we think the rtds and credit2 schedulers are wrong or whether it
> > >>> is actually the ARM arch code which needs fixing before considering any
> > >>> change.
> > >>
> > >> The aspect to be understood first is why ARM needs IRQs disabled
> > >> past __context_switch() into schedule_tail() (and there until after
> > >> ctxt_switch_from() and ctxt_switch_to()). If that's indeed necessary,
> > >> there's no question that the schedulers need to be adjusted to
> > >> accommodate for this.
> > > 
> > > I don't think it's *necessary*, but we do seem to have ended up with the
> > > context switch having that requirement today (and relying on it in
> > > several places in switch from/to (mostly to).
> > 
> > > I'm pretty sure we could rework things more along the lines of how x86
> > > does it if needed, but it would be a non-trivial refactoring I think.
> > 
> > We have some part of the code which may inject an interrupt during
> > context switch.
> > For instance the timer may inject an IRQ as long as it has not been
> > disabled. Same when the timer is restored.
> > 
> > The former may result to inject an interrupt to the wrong vCPU.
> 
> Also the gic save and restore functions need to be run with interrupt
> disabled.

I am aware that today all sorts of things rely on interrupts being
disabled during context switch on ARM.

My point was that we *could*, if required, rework things to not rely on
this.

Ian.


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

Re: [Xen-devel] Xen's Linux kernel config options V2

[Stefano Stabellini]

On Wed, 4 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-04 at 14:57 +, Stefano Stabellini wrote:
> > On Wed, 4 Feb 2015, David Vrabel wrote:
> > > On 16/12/14 16:21, Juergen Gross wrote:
> > > > Hi,
> > > > 
> > > > This is a design proposal for a rework of the config options on the
> > > > Linux kernel which are related to Xen.
> > > > 
> > > > The need to do so arose from the fact that it is currently not
> > > > possible to build the Xen frontend drivers for a non-pvops kernel,
> > > > e.g. to run them in a HVM-domain. There are more drawbacks in the
> > > > current config options to which I'll come later.
> > > > 
> > > > Option  Selects Depends
> > > > --
> > > > XEN
> > > >   XEN_PV(x86)   XEN_HAVE_PVMMU
> > > > PARAVIRT
> > > > PARAVIRT_CLOCK
> > > >   XEN_PVH(x86)  XEN_PVHVM
> > > > PARAVIRT  
> > > > PARAVIRT_CLOCK
> > > >   XEN_PVHVM PARAVIRT
> > > > PARAVIRT_CLOCK
> > 
> > PARAVIRT_CLOCK and PARAVIRT are x86 specific.
> 
> Does PARAVIRT_CLOCK include the pvclock_read_wallclock stuff? Eventually
> we are going to want that functionality on ARM too, although it's not
> clear to me that bundling pv-wallclock and pv-cyclecounter in
> arch/x86/kernel/pvclock.c under the same config option is most correct.
 
Agreed.  Also that patch series never went upstream unfortunately.

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

Re: [Xen-devel] [qemu-upstream-unstable bisection] complete test-amd64-i386-freebsd10-i386

[Stefano Stabellini]

Paul,

do you have an estimate on when it is going to be fixed?

If it is not soon, I would prefer to revert the patch for now to unbreak
tests.

Cheers,

Stefano

On Mon, 2 Feb 2015, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-freebsd10-i386
> test guest-localmigrate
> 
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  qemuu 
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git
>   Bug introduced:  7665d6ba98e20fb05c420de947c1750fd47e5c07
>   Bug not present: 9026dca821a61b72983778e3dcd92cfc34b02e8b
> 
> 
>   commit 7665d6ba98e20fb05c420de947c1750fd47e5c07
>   Author: Paul Durrant 
>   Date:   Tue Jan 20 11:06:19 2015 +
>   
>   Xen: Use the ioreq-server API when available
>   
>   The ioreq-server API added to Xen 4.5 offers better security than
>   the existing Xen/QEMU interface because the shared pages that are
>   used to pass emulation request/results back and forth are removed
>   from the guest's memory space before any requests are serviced.
>   This prevents the guest from mapping these pages (they are in a
>   well known location) and attempting to attack QEMU by synthesizing
>   its own request structures. Hence, this patch modifies configure
>   to detect whether the API is available, and adds the necessary
>   code to use the API if it is.
>   
>   upstream-commit-id: 3996e85c1822e05c50250f8d2d1e57b6bea1229d
>   
>   Signed-off-by: Paul Durrant 
>   Signed-off-by: Stefano Stabellini 
>   Acked-by: Stefano Stabellini 
> 
> 
> For bisection revision-tuple graph see:
>
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-upstream-unstable.test-amd64-i386-freebsd10-i386.guest-localmigrate.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> 
> Searching for failure / basis pass:
>  34011 fail [host=grain-weevil] / 33488 [host=scape-moth] 32024 
> [host=scape-moth] 31848 ok.
> Failure / basis pass flights: 34011 / 31848
> (tree in latest but not in basispass: ovmf)
> (tree with no url: seabios)
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest c3b70f0bbb6a883f4afa639286043d3f71fbbddf 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
> be11dc1e9172f91e798a8f831b30c14b479e08e8 
> 7106c691a6332cffab4037186d1caa3012ae051e
> Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 
> c530a75c1e6a472b0eb9558310b518f0dfcd8860 
> b0d42741f8e9a00854c3b3faca1da84bfc69bf22 
> a230ec3101ddda868252c036ea960af2b2d6cd5a 
> 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4
> Generating revisions with ./adhoc-revtuple-generator  
> git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-c3b70f0bbb6a883f4afa639286043d3f71fbbddf
>  
> git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
>  
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22
>  
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#a230ec3101ddda868252c036ea960af2b2d6cd5a-be11dc1e9172f91e798a8f831b30c14b479e08e8
>  
> git://xenbits.xen.org/xen.git#6913fa31fa898f45ecc3b00e2397b8ebc75c8df4-7106c691a6332cffab4037186d1caa3012ae051e
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/linux-pvops
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/xen
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/linux-pvops
> + git remote set-url origin 
> git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
> + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
> + exec
> + sh -xe
> + cd /export/home/osstest/repos/qemu-upstream-unstable
> + git remote set-url origin 
> gi

Re: [Xen-devel] [PATCH] xen/arm: Fix rtds scheduler for arm

[Ian Campbell]

On Mon, 2015-02-02 at 20:03 +0200, Denis Drozdov wrote:
> From: denys drozdov 
> 
> Make Credit2 and RT schedulers to run on arm platform
> context_saved should be deferred on ARM after IRQs enabled

A better subject+message would be:

xen/arm: Call context_saved() with interrupts enabled during context 
switch

This is a requirement of the scheduler interface, violating this
causes for example with the RT scheduler:


> Signed-off-by: denys drozdov 

Acked-by: Ian Campbell 

However I would like an ack from a scheduler person (e.g. George) before
it gets applied.

> ---
>  xen/arch/arm/domain.c |7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..1626376 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -64,7 +64,7 @@ static void ctxt_switch_from(struct vcpu *p)
>   * mode. Therefore we don't need to save the context of an idle VCPU.
>   */
>  if ( is_idle_vcpu(p) )
> -goto end_context;
> +return;
>  
>  p2m_save_state(p);
>  
> @@ -138,9 +138,6 @@ static void ctxt_switch_from(struct vcpu *p)
>  gic_save_state(p);
>  
>  isb();
> -
> -end_context:
> -context_saved(p);
>  }
>  
>  static void ctxt_switch_to(struct vcpu *n)
> @@ -246,6 +243,8 @@ static void schedule_tail(struct vcpu *prev)
>  
>  local_irq_enable();
>  
> +context_saved(prev);
> +
>  if ( prev != current )
>  update_runstate_area(current);
>  



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