Re: [Xen-devel] [PATCH for-4.5 v7 1/7] xen: Add support for VMware cpuid leaves

[Jan Beulich]

>>> On 15.01.15 at 22:00,  wrote:
> On 01/15/15 11:42, Jan Beulich wrote:
> On 02.10.14 at 23:30,  wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/hvm/vmware/cpuid.c
>> 
>> Whether adding another subdirectory here is really the way to go
>> heavily depends on how much of this new code we really want to
>> take into the tree. There sheer size of the series makes me
>> hesitant to consider taking it all.
>> 
> 
> Not sure what I can say here to help.

Much will depend on the discussion of the subsequent much bigger
patch, so nothing specific to say here for the moment.

>>> +/*
>>> + * VMware hardware version 7 defines some of these cpuid levels,
>>> + * below is a brief description about those.
>>> + *
>>> + * Leaf 0x4000, Hypervisor CPUID information
>>> + * # EAX: The maximum input value for hypervisor CPUID info (0x4010).
>>> + * # EBX, ECX, EDX: Hypervisor vendor ID signature. E.g. "VMwareVMware"
>>> + *
>>> + * Leaf 0x4010, Timing information.
>>> + * # EAX: (Virtual) TSC frequency in kHz.
>>> + * # EBX: (Virtual) Bus (local apic timer) frequency in kHz.
>>> + * # ECX, EDX: RESERVED
>>> + */
>>> +
>>> +int cpuid_vmware_leaves(uint32_t idx, uint32_t *eax, uint32_t *ebx,
>>> +uint32_t *ecx, uint32_t *edx)
>>> +{
>>> +struct domain *d = current->domain;
>>> +
>>> +if ( !is_vmware_domain(d) )
>>> +return 0;
>>> +
>>> +switch ( idx - 0x4000 )
>>> +{
>>> +case 0x0:
>>> +if ( d->arch.hvm_domain.params[HVM_PARAM_VMWARE_HW] >= 7 )
>>> +{
>>> +*eax = 0x4010;  /* Largest leaf */
>>> +*ebx = 0x61774d56;  /* "VMwa" */
>>> +*ecx = 0x4d566572;  /* "reVM" */
>>> +*edx = 0x65726177;  /* "ware" */
>>> +break;
>>> +}
>>> +/* fallthrough */
>>> +case 0x10:
>>> +if ( d->arch.hvm_domain.params[HVM_PARAM_VMWARE_HW] >= 7 )
>>> +{
>>> +/* (Virtual) TSC frequency in kHz. */
>>> +*eax =  d->arch.tsc_khz;
>>> +/* (Virtual) Bus (local apic timer) frequency in kHz. */
>>> +*ebx = 100ull / APIC_BUS_CYCLE_NS;
>>> +*ecx = 0;  /* Reserved */
>>> +*edx = 0;  /* Reserved */
>>> +break;
>>> +}
>>> +/* fallthrough */
>> 
>> So for versions < 7 there's effectively no CPUID support at all?
>> Wouldn't it then make more sense to check for the version together
>> with the is_vmware_domain() check at the top?
>> 
> 
> Nope, when version is > 0 & < 7, all zeros are returned for these.
> This is why there is a fallthrough comment.
> 
> Doing the zero returns is part of making the environment look as much
> like VMware as possible.  I feel this is better, but I can be pushed
> into including this check at the top (since the VMware KB article
> referenced just has an equal statement).

But afaict zeros get returned even when you bail from the function
right at the top, thanks to the subsequent domain_cpuid() invocation
in the caller (unless overridden in the guest config, which surely
would be dubious).

>>> --- a/xen/include/public/hvm/params.h
>>> +++ b/xen/include/public/hvm/params.h
>>> @@ -189,6 +189,9 @@
>>>  /* Location of the VM Generation ID in guest physical address space. */
>>>  #define HVM_PARAM_VM_GENERATION_ID_ADDR 34
>>>  
>>> -#define HVM_NR_PARAMS  35
>>> +/* Params for VMware */
>>> +#define HVM_PARAM_VMWARE_HW 35
>> 
>> The comment seems wrong - after all it's the version, not some
>> arbitrary parameters/flags.
>> 
> 
> It use to be a set of Params.  Will fix, thinking of:
> 
> /* VMware Hardware Version */

... emulated ...

> Did you what me to rename HVM_PARAM_VMWARE_HW also to new name (maybe
> HVM_PARAM_VMWARE_HARDWARE_VERSION)?

Perhaps a good idea; if it turns out too long,
HVM_PARAM_VMWARE_HWVER would also seem fine.

Jan


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

Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

[Jan Beulich]

>>> On 15.01.15 at 19:23,  wrote:
> On 01/15/2015 08:15 AM, Tim Deegan wrote:
>> - Feature compatibilty/completeness.  You pointed out yourself that
>>   it doesn't work with nested HVM or migration.  I think I'd have to
>>   add mem_event/access/paging and PCI passthrough to the list of
>>   features that ought to still work.  I'm resigned to the idea that
>>   many new features don't work with shadow pagetables. :)
>> 
> 
> The intention is that mem_event/access should still work. I haven't
> specifically looked at paging, but I don't see any fundamental reason
> why it shouldn't. PCI passthrough I suspect won't. Does nested HVM
> work with migration? Is it simply not acceptable to submit a feature
> as experimental, with known compatibility issues? I had assumed that
> it was, based on the nested HVM status as documented in the release
> notes.

It is generally acceptable, sure. But the sad thing here is that
particularly with such code coming from Intel (with the nested
VMX code being a good example, and certain IOMMU/pass-
through things being another) my experience is that once that
initial code drop happened, interest from the original authors is
lost (possibly not maliciously, but because of being assigned other
tasks) and the code therefore has to remain experimental for
extended periods of time (often until someone else gets
frustrated enough about its half baked state to spend non-
negligible amounts of time to deal with the loose ends).

Jan


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

Re: [Xen-devel] [PATCH 07/11] x86/altp2m: introduce p2m_ram_rw_ve type.

[Jan Beulich]

>>> On 15.01.15 at 21:38,  wrote:
> On 01/15/2015 09:03 AM, Tim Deegan wrote:
>> At 13:26 -0800 on 09 Jan (1420806397), Ed White wrote:
>>> This is treated exactly like p2m_ram_rw, except that suppress_ve is not
>>> set in the EPTE.
>> 
>> I don't think this is going to work -- you probably want to support
>> p2m_ram_ro at least, and maybe other types, but duplicating each of
>> them as a 'type foo with #VE' doesn't seem right.
>> 
>> Since the default is to set the ignore-#ve flag everywhere, how about
>> having an operation to enable #ve for a frame that just clears that
>> bit, and then having all other updates to altp2m entries preserve it?
> 
> I hear you, but #VE is only even relevant for the in-domain agent
> model, and as the only current user of that model we not only don't
> want #VE to work on other page types, we specifically want it to be
> prohibited.
> 
> Can we do it this way, and then change it later if required?

Without you explaining to us the full details of the in-domain
agent model, I'm afraid this is going to remain dubious and the
question hard to answer. In particular, if you indeed want to
prohibit that behavior on _all_ other p2m types, how would
subsequently changing the implementation then be compatible
(if it can't be done this way right from the beginning)?

Jan


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

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

[xen . org]

flight 33424 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33424/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33402

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-armhf-armhf-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail 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-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-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-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-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-xl-winxpsp3  14 guest-stop   fail   never pass

version targeted for testing:
 qemuu3a7f560fa612610822727f7647ed6bc10bccd6ec
baseline version:
 qemuu7d5ad15d17f26dd4f9ff5f3491828bc34e74f28c


People who touched revisions under test:
  Alex Friedman 
  Anubhav Rakshit 
  Chrysostomos Nanakos 
  Don Slutz 
  Fam Zheng 
  John Snow 
  Keith Busch 
  Kevin Wolf 
  Liang Li 
  Marc Marí 
  Max Reitz 
  Paolo Bonzini 
  Peter Lieven 
  Peter Maydell 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Vladimir Sementsov-Ogievskiy 


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-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-xl-pcipt-intel  fail
 test-amd64-amd64-xl-pvh-intelfail
 test-amd64-i386-rhel6hvm-intel   pass
 te

Re: [Xen-devel] [PATCH 08/11] x86/altp2m: add remaining support routines.

[Jan Beulich]

>>> On 15.01.15 at 22:00,  wrote:
> On 01/15/2015 09:33 AM, Tim Deegan wrote:
>> Hi,
>> 
>> Sorry for the fractured replies - my notes are confused about which
>> functions were defined where.
>> 
>> At 13:26 -0800 on 09 Jan (1420806398), Ed White wrote:
>>> +bool_t p2m_change_altp2m_pfn(struct domain *d, uint16_t idx,
>>> + unsigned long old_pfn, unsigned long new_pfn)
>>> +{
>> [...]
>>> +mfn = ap2m->get_entry(ap2m, new_pfn, &t, &a, 0, NULL);
>>> +
>>> +if ( !mfn_valid(mfn) )
>>> +mfn = hp2m->get_entry(hp2m, new_pfn, &t, &a, 0, NULL);
>>> +
>>> +if ( !mfn_valid(mfn) || !(t == p2m_ram_rw || t == p2m_ram_rw) )
>>> +goto out;
>>> +
>>> +/* Use special ram type to enable #VE if setting for current domain */
>>> +if ( current->domain == d )
>>> +t = p2m_ram_rw_ve;
>>> +
>>> +if ( !ap2m->set_entry(ap2m, old_pfn, mfn, PAGE_ORDER_4K, t, a) )
>>> +rc = 1;
>> 
>> I'm afraid this is Terribly Unsafe[tm].  Following on from my point on
>> the log-dirty patch, if the original gfn gets removed from the guest,
>> for any reason, we need a way to find and remove this mapping too.
>> 
>> That will be non-trivial, since you can't do it by exhaustive search.
>> Maybe some sort of reverse mapping?
> 
> How often is it likely that a page will be removed? If it's
> infrequent, maybe an exhaustive search will suffice. I don't
> expect there to be anywhere near 10 alternates in use in most
> cases, and they are sparsely populated.

A fundamental thing you need to keep in mind when considering
exhaustive searches is that these need to be preemptible, no
matter how infrequent they are. Which may be difficult to
arrange for, based on experience with code where we needed
to add such preemption later on (as security fixes).

Jan


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

Re: [Xen-devel] how to generate a smaller core with xm dump-core

[Zhenzhong Duan]

在 2015/1/16 0:16, Don Slutz 写道:

On 01/15/15 05:20, Ian Campbell wrote:

On Thu, 2015-01-15 at 11:31 +0800, Zhenzhong Duan wrote:

Hi Maintainers,


We are facing issue collecting  coredump using the xm dump mechanism
in Dom0.

We face couple of such issues daily, where the VMs panic s and the SA
team is supposed to collect the core.

The actual problem is that where the VMs are having huge RAM like 32+
GB RAMs dumping the core using xm dump generated core of almost the
same size.

And also when the RAM size is huge the time taken to dump is also
huge.

Transferring this core dump of this huge size to another system for
analysis is really a pain. I am looking for some solution where we can
generate smaller core using xm dump or any other tool.

Something similar to makedumpfile which eliminates the zero and
unnecessary pages, which results in core of smaller size.


This has become a hot issue and we terribly need this feature.

Can you come across with anything or are you aware of any feature
which could cater our need….?

I'm not aware of any existing features or efforts in this area.

If things like zero pages can be omitted from a core file without making
it non-standard then I think we'd be happy to see such patches to the
core libxc functions which produce the core files.

That wouldn't help much with a heavily loaded VM which is making good
use of all its ram though.

I've not looked but it's not unlikely that the dumping code itself is
not very optimal, so it might be worth having a look to see if more
batching etc might help speed things up at the root. Ages ago there were
patches floating around which improved the performance of the privcmd
mmap ioctl (from Mats Peterson), which might help here too (assuming
core dumping uses those interfaces as I expect). AFAIK those patches
were abandoned when Mats moved onto other things, resurrecting them
would probably help here as well as with migration and other
foreign-memory-man heavy workloads.

Other random thoughts:
   * Automatically compress the core file, doesn't help with time to
 produce the dump (quite the opposite) but helps with copying it
 off box (but could also compress manually before moving or 
do it

 as a post processing step)
   * Have an option to produce some kind of "minicore", e.g. just
 register state and a few pages of the referenced stacks, 
perhaps

 a few pages of RAM either side of any register which happens to
 be a valid looking pointer.
   * Care would be needed to retain an acceptable 
probability

 that the resulting core will actually be useful.
   * Consider including kernel RAM only (which might still be huge
 though if it has a 1:1 mapping of all RAM).

I don't think any of those would be suitable for enabling by default but
they might be useful to have in the arsenal.

HTH,

Ian.



If these are Linux guests then the patch:

http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg02351.html

Can be used to enable crash to access the crashed guest and collect
some basic info. I would also include the output of xen-hvmctx and/or 
xenctx.

-- This is the quick way I would do Ian's minicore .

Note: dump-core currently does not include xen-hvmctx output (nor does 
it include

xenctx -a output).

Using the results from this may allow you to not need a copy of every 
dump (
not to imply that 2 similar minicore's would insure that a copy of 
each core

was not needed).

I also think that makedumpfile can process a xen dump-core file and 
make it

smaller.

Looks similar as gdbsx.
This patch will help if I could reproduce the issue locally.
But I can't access customer's env in most situation and they will not 
wait me to do online debug remotely.


Yes, makedumpfile may help in size rather than time here.
I am thinking if port some code from makedumpfile is possible and 
acceptable.


zduan

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

Re: [Xen-devel] [PATCH 1/8] ppc/kvm: Replace ACCESS_ONCE with READ_ONCE

[Christian Borntraeger]

Am 16.01.2015 um 00:09 schrieb Michael Ellerman:
> On Thu, 2015-01-15 at 09:58 +0100, Christian Borntraeger wrote:
>> ACCESS_ONCE does not work reliably on non-scalar types. For
>> example gcc 4.6 and 4.7 might remove the volatile tag for such
>> accesses during the SRA (scalar replacement of aggregates) step
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
>>
>> Change the ppc/kvm code to replace ACCESS_ONCE with READ_ONCE.
>>
>> Signed-off-by: Christian Borntraeger 
>> ---
>>  arch/powerpc/kvm/book3s_hv_rm_xics.c |  8 
>>  arch/powerpc/kvm/book3s_xics.c   | 16 
>>  2 files changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv_rm_xics.c 
>> b/arch/powerpc/kvm/book3s_hv_rm_xics.c
>> index 7b066f6..7c22997 100644
>> --- a/arch/powerpc/kvm/book3s_hv_rm_xics.c
>> +++ b/arch/powerpc/kvm/book3s_hv_rm_xics.c
>> @@ -152,7 +152,7 @@ static void icp_rm_down_cppr(struct kvmppc_xics *xics, 
>> struct kvmppc_icp *icp,
>>   * in virtual mode.
>>   */
>>  do {
>> -old_state = new_state = ACCESS_ONCE(icp->state);
>> +old_state = new_state = READ_ONCE(icp->state);
> 
> These are all icp->state.
> 
> Which is a union, but it's only the size of unsigned long. So in practice 
> there
> shouldn't be a bug here right?

This bug was that gcc lost the volatile tag when propagating aggregates to 
scalar types.
So in theory a union could be affected. See the original problem
 ( http://marc.info/?i=54611D86.4040306%40de.ibm.com ) 
which happened on 

union ipte_control {
unsigned long val;
struct {
unsigned long k  : 1;
unsigned long kh : 31;
unsigned long kg : 32;
};
};

Christian



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

Re: [Xen-devel] [PATCH v2 2/2] tools/configure: Check if pixman is present on the system when building QEMU

[Ian Campbell]

On Thu, 2015-01-15 at 21:06 +, Julien Grall wrote:
> QEMU upstream requires the use of pixman. When pixman is not present the
> system, the configure of QEMU will fail with:
> 
> ERROR: pixman not present. Your options:
>  (1) Preferred: Install the pixman devel package (any recent
>  distro should have packages as Xorg needs pixman too).
>  (2) Fetch the pixman submodule, using:
>  git submodule update --init pixman
> 
> I think we can use by default the version on the system. So check it
> a Xen configuration time to avoid a build issue later.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> This patch requires to regenerate tools/configure.
> 
> Changes in v2:
> - Only check if pixman is present when building QEMU
> ---
>  tools/configure.ac | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 2aff18d..64dc75c 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -323,9 +323,10 @@ esac
>   AX_CHECK_UUID
>   AX_CHECK_CURSES
>  
> -dnl Glib 2.0 is only required when QEMU is built
> +dnl Glib 2.0 and pixman are only required when QEMU is built

Rather than an ever increasing list here I propose to say "The following
are only...", and perhaps insert an "upstream" before QEMU, unless these
are needed for trad too (in which case the condition isn't quite right).
I think glib and pixman are only for upstream though.

I can do that on commit though if you like.

>  AS_IF([test "x$qemu_xen" = "xy"], [
>  PKG_CHECK_MODULES(glib, [glib-2.0 >= 2.12])
> +PKG_CHECK_MODULES(pixman, pixman-1)
>  ])
>  AX_CHECK_FETCHER
>  



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

[Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls

[Paul Durrant]

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
This is usually an IOAPIC vector and is only used if the event
channel is bound to vcpu 0.

PVHVM Linux uses a pre-defined interrupt vector for the event
channel upcall, set using HVM_PARAM_CALLBACK_IRQ by ORing in a
special bit (bit 57) into the value (see params.h). However, it
does not assert the interrupt via the emulated local APIC.

This mechanism is not suitable in the general case since Windows
(and potentially other OSes) because they:

- cannot guarantee the same vector for all VCPUs
- do require the upcall to be asserted via the local APIC

This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu
therefore coping with the case of differing vector numbers.

Signed-off-by: Paul Durrant 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: David Vrabel 
---
v2:
 - Addressed comments from Andrew Cooper
   - Check vector >=16
   - Put hypercall in x86-specific section

v3:
 - Addressed comments from Jan Beulich
   - More verbose check-in comment

v4:
 - Amended check-in comment as suggested by David Vrabel

v5:
 - Addressed comments from Jan Beulich

 xen/arch/x86/hvm/hvm.c  |   30 ++
 xen/arch/x86/hvm/irq.c  |8 +++-
 xen/include/asm-x86/hvm/vcpu.h  |1 +
 xen/include/public/hvm/hvm_op.h |   19 +++
 4 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8b06bfd..85e43b8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5514,6 +5514,31 @@ static int hvmop_destroy_ioreq_server(
 return rc;
 }
 
+static int hvmop_set_evtchn_upcall_vector(
+XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
+{
+xen_hvm_set_evtchn_upcall_vector_t op;
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( copy_from_guest(&op, uop, 1) )
+return -EFAULT;
+
+if ( !is_hvm_domain(d) )
+return -EINVAL;
+
+if ( op.vector < 0x10 )
+return -EINVAL;
+
+if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
+return -ENOENT;
+
+printk(XENLOG_G_INFO "%pv: upcall vector %u\n", v, op.vector);
+
+v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
+return 0;
+}
+
 /*
  * Note that this value is effectively part of the ABI, even if we don't need
  * to make it a formal part of it: A guest suspended for migration in the
@@ -5573,6 +5598,11 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
 break;
 
+case HVMOP_set_evtchn_upcall_vector:
+rc = hvmop_set_evtchn_upcall_vector(
+guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
+break;
+
 case HVMOP_set_param:
 case HVMOP_get_param:
 {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 35f4f94..743429e 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -218,7 +218,13 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
 return;
 }
 
-if ( is_hvm_pv_evtchn_vcpu(v) )
+if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
+{
+uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
+
+vlapic_set_irq(vcpu_vlapic(v), vector, 0);
+}
+else if ( is_hvm_pv_evtchn_vcpu(v) )
 vcpu_kick(v);
 else if ( v->vcpu_id == 0 )
 hvm_set_callback_irq_level(v);
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..edd4523 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -160,6 +160,7 @@ struct hvm_vcpu {
 } u;
 
 struct tasklet  assert_evtchn_irq_tasklet;
+u8  evtchn_upcall_vector;
 
 struct nestedvcpu   nvcpu;
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index a4e5345..a857561 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -370,6 +370,25 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
 
 #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
 
+#if defined(__i386__) || defined(__x86_64__)
+
+/*
+ * HVMOP_set_evtchn_upcall_vector: Set a  that should be used for event
+ * channel upcalls on the specified . If 
set,
+ * this vector will be used in preference to 
the
+ * domain global callback via (see
+ * HVM_PARAM_CALLBACK_IRQ).
+ */
+#define HVMOP_set_evtchn_upcall_vector 23
+struct xen_hvm_set_evtchn_upcall_vector {
+uint32_t vcpu;
+uint8_t vector;
+};
+typedef struct xen_hvm_set_evtchn_upcall_vector 
xen_hvm_set_evtchn_upcall_vector_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
+
+

Re: [Xen-devel] [PATCH for-4.5 v8 4/7] xen: Add vmware_port support

[Jan Beulich]

>>> On 03.10.14 at 00:40,  wrote:
> This is a new domain_create() flag, DOMCRF_vmware_port.  It is
> passed to domctl as XEN_DOMCTL_CDF_vmware_port.

Can you explain why a HVM param isn't suitable here?

> This is both a more complete support then in currently provided by
> QEMU and/or KVM and less.  The missing part requires QEMU changes
> and has been left out until the QEMU patches are accepted upstream.

I vaguely recall the question having been asked before, but I can't
find it to the answer to it: If qemu has support for this, why can't
you build on that rather than adding everything in the hypervisor?

> For AMD (svm) the max instruction length of 15 is hard coded.  This
> is because __get_instruction_length_from_list() has issues that when
> called from #GP handler NRIP is not available, or that NRIP may not
> be available at all on a particular HW, leading to the need read the
> instruction twice --- once in __get_instruction_length_from_list()
> and then again in vmport_gp_check(). Which is bad because memory may
> change between the reads.

I don't get the connection between the first sentence (which just
states an architectural fact) and the rest of this paragraph.

> @@ -2111,6 +2112,31 @@ svm_vmexit_do_vmsave(struct vmcb_struct *vmcb,
>   return;
>   }
> 
> +static void svm_vmexit_gp_intercept(struct cpu_user_regs *regs,
> +struct vcpu *v)
> +{
> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +/*
> + * Just use 15 for the instruction length; vmport_gp_check will
> + * adjust it.  This is because
> + * __get_instruction_length_from_list() has issues, and may
> + * require a double read of the instruction bytes.  At some
> + * point a new routine could be added that is based on the code
> + * in vmport_gp_check with extensions to make it more general.
> + * Since that routine is the only user of this code this can be
> + * done later.
> + */
> +unsigned long inst_len = 15;

Surely this can be unsigned int? And the value be MAX_INST_LEN?

> --- /dev/null
> +++ b/xen/arch/x86/hvm/vmware/vmport.c
> @@ -0,0 +1,262 @@
> +/*
> + * HVM VMPORT emulation
> + *
> + * Copyright (C) 2012 Verizon Corporation
> + *
> + * This file is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License Version 2 (GPLv2)
> + * as published by the Free Software Foundation.
> + *
> + * This file 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 

No need for this.

> +#define MAX_INST_LEN 15

Please move SVM's identical definition into e.g. asm-x86/processor.h
or even x86_emulate/x86_emulate.h (so it can also be used in
x86_emulate/x86_emulate.c), and avoid adding another instance
here.

> +#ifndef NDEBUG
> +unsigned int opt_vmport_debug __read_mostly;
> +integer_param("vmport_debug", opt_vmport_debug);
> +#endif

If this was used anywhere, the variable ought to be static. But
since it seems unused, it ought to be dropped.

> +/* More VMware defines */
> +
> +#define VMWARE_GUI_AUTO_GRAB  0x001
> +#define VMWARE_GUI_AUTO_UNGRAB0x002
> +#define VMWARE_GUI_AUTO_SCROLL0x004
> +#define VMWARE_GUI_AUTO_RAISE 0x008
> +#define VMWARE_GUI_EXCHANGE_SELECTIONS0x010
> +#define VMWARE_GUI_WARP_CURSOR_ON_UNGRAB  0x020
> +#define VMWARE_GUI_FULL_SCREEN0x040
> +
> +#define VMWARE_GUI_TO_FULL_SCREEN 0x080
> +#define VMWARE_GUI_TO_WINDOW  0x100
> +
> +#define VMWARE_GUI_AUTO_RAISE_DISABLED0x200
> +
> +#define VMWARE_GUI_SYNC_TIME  0x400

What do all of the above mean? Without any explanation it is
impossible to understand why reporting any of them set below
is correct/acceptable.

> +int vmport_ioport(int dir, uint32_t port, uint32_t bytes, uint32_t *val)
> +{
> +struct cpu_user_regs *regs = guest_cpu_user_regs();
> +uint16_t cmd = regs->rcx;

As you already have most other variables needed only inside the if()
below declared in that scope, please be consistent with this one.
Albeit the value of this variable is questionable anyway - it's being
used exactly once.

> +int rc = X86EMUL_OKAY;
> +
> +if ( regs->_eax == BDOOR_MAGIC )

With this, is handling other than 32-bit in/out really meaningful/
correct?

> +case BDOOR_CMD_GETHWVERSION:
> +/* vmware_hw */
> +regs->_eax = 0;
> +if ( is_hvm_vcpu(curr) )

Since you can't get here for PV, I can't see what you need this
conditional for.

> +{
> +struct hvm_domain *hd = &d->arch.hvm_domain;
> +
> +regs->_eax = hd->params[HVM_PARAM_VMWARE_HW];
> +}
> +if ( !regs->_eax )
> +

Re: [Xen-devel] how to generate a smaller core with xm dump-core

[Ian Campbell]

On Fri, 2015-01-16 at 16:39 +0800, Zhenzhong Duan wrote:
> I am thinking if port some code from makedumpfile is possible and 
> acceptable.

makedumpfile appears to be GPL, whereas libxc is LGPL, so if you wanted
to port code directly you would need permissions from the copyright
holders to re-license.

I think we would be OK with you reimplementing some of the techniques
within tools/libxc/xc_core*.c though, so long as you don't copy actual
code. Obviously just improving that code without reference to
makedumpfile is fine too.

I don't think we need or want yet another tool for doing this in the
code base though.

Another option would be for you to add Xen support to makedumpfile,
you'd want to speak to the maintainers of the tool about that though.

Ian.


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

[Xen-devel] [rumpuserxen test] 33434: tolerable FAIL - PUSHED

[xen . org]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumpuserxen-i386  5 xen-bootfail pass in 33416
 test-amd64-amd64-rumpuserxen-amd64  8 guest-start  fail in 33416 pass in 33434

version targeted for testing:
 rumpuserxen  ec3b62146d52e5deab349b00c6e768937d39a01f
baseline version:
 rumpuserxen  1e71553faec32af113f1d91c8331341eed320ea5


People who touched revisions under test:
  Antti Kantee 
  Martin Lucina 


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-i386-rumpuserxen-i386 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=rumpuserxen
+ revision=ec3b62146d52e5deab349b00c6e768937d39a01f
+ . 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 rumpuserxen 
ec3b62146d52e5deab349b00c6e768937d39a01f
+ branch=rumpuserxen
+ revision=ec3b62146d52e5deab349b00c6e768937d39a01f
+ . 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=rumpuserxen
+ xenbranch=xen-unstable
+ '[' xrumpuserxen = 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://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.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
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']

Re: [Xen-devel] QEMU 2.2.0 in Xen 4.6

[Stefano Stabellini]

On Thu, 15 Jan 2015, Don Slutz wrote:
> Now that Xen 4.5 has been released, I would like to see at least QEMU
> 2.2.0 in qemu-upstream-stable on the master branch.

Agreed

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

[Xen-devel] about the funtion call memory_type_changed()

[Li, Liang Z]

Hi Jan,

I found the restore process of the live migration is quit long, so I try to 
find out what's going on.
By debugging, I found the most time consuming process is restore the VM's MTRR 
MSR,
The process is done in the function hvm_load_mtrr_msr(), it will call the
memory_type_changed(), which eventually call the time consuming function
flush_all().

All this is caused by adding the memory_type_changed in your patch, here is the 
link
http://lists.xen.org/archives/html/xen-devel/2014-03/msg03792.html,

I am not sure if it's necessary to call flush_all, even it's necessary,  call 
the function
 hvm_load_mtrr_msr one time will cause dozens call of flush_all, and each call 
of the
 flush_all function will consume about 8 milliseconds, in my test environment, 
the VM
 has 4 VCPUs, the hvm_load_mtrr_msr() will be called four times, and totally 
consumes
 about 500 milliseconds. Obviously, there are too many flush_all calls.

 I think something should be done to solve this issue, do you think so?

Liang

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

Re: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls

[Andrew Cooper]

On 16/01/15 10:09, Paul Durrant wrote:
> HVM guests have always been confined to using the domain callback
> via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
> This is usually an IOAPIC vector and is only used if the event
> channel is bound to vcpu 0.
>
> PVHVM Linux uses a pre-defined interrupt vector for the event
> channel upcall, set using HVM_PARAM_CALLBACK_IRQ by ORing in a
> special bit (bit 57) into the value (see params.h). However, it
> does not assert the interrupt via the emulated local APIC.
>
> This mechanism is not suitable in the general case since Windows
> (and potentially other OSes) because they:
>
> - cannot guarantee the same vector for all VCPUs
> - do require the upcall to be asserted via the local APIC
>
> This patch adds a new HVM op allowing a guest to specify a local
> APIC vector to use as an upcall notification for a specific vcpu
> therefore coping with the case of differing vector numbers.
>
> Signed-off-by: Paul Durrant 
> Cc: Keir Fraser 
> Cc: Jan Beulich 
> Cc: David Vrabel 
> ---
> v2:
>  - Addressed comments from Andrew Cooper
>- Check vector >=16
>- Put hypercall in x86-specific section
>
> v3:
>  - Addressed comments from Jan Beulich
>- More verbose check-in comment
>
> v4:
>  - Amended check-in comment as suggested by David Vrabel
>
> v5:
>  - Addressed comments from Jan Beulich
>
>  xen/arch/x86/hvm/hvm.c  |   30 ++
>  xen/arch/x86/hvm/irq.c  |8 +++-
>  xen/include/asm-x86/hvm/vcpu.h  |1 +
>  xen/include/public/hvm/hvm_op.h |   19 +++
>  4 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8b06bfd..85e43b8 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5514,6 +5514,31 @@ static int hvmop_destroy_ioreq_server(
>  return rc;
>  }
>  
> +static int hvmop_set_evtchn_upcall_vector(
> +XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t) uop)
> +{
> +xen_hvm_set_evtchn_upcall_vector_t op;
> +struct domain *d = current->domain;
> +struct vcpu *v;
> +
> +if ( copy_from_guest(&op, uop, 1) )
> +return -EFAULT;
> +
> +if ( !is_hvm_domain(d) )
> +return -EINVAL;
> +
> +if ( op.vector < 0x10 )
> +return -EINVAL;
> +
> +if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
> +return -ENOENT;
> +
> +printk(XENLOG_G_INFO "%pv: upcall vector %u\n", v, op.vector);
> +
> +v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
> +return 0;
> +}
> +
>  /*
>   * Note that this value is effectively part of the ABI, even if we don't need
>   * to make it a formal part of it: A guest suspended for migration in the
> @@ -5573,6 +5598,11 @@ long do_hvm_op(unsigned long op, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
>  break;
>  
> +case HVMOP_set_evtchn_upcall_vector:
> +rc = hvmop_set_evtchn_upcall_vector(
> +guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
> +break;
> +
>  case HVMOP_set_param:
>  case HVMOP_get_param:
>  {
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> index 35f4f94..743429e 100644
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -218,7 +218,13 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
>  return;
>  }
>  
> -if ( is_hvm_pv_evtchn_vcpu(v) )
> +if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> +{
> +uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
> +
> +vlapic_set_irq(vcpu_vlapic(v), vector, 0);
> +}
> +else if ( is_hvm_pv_evtchn_vcpu(v) )
>  vcpu_kick(v);
>  else if ( v->vcpu_id == 0 )
>  hvm_set_callback_irq_level(v);
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index 01e0665..edd4523 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -160,6 +160,7 @@ struct hvm_vcpu {
>  } u;
>  
>  struct tasklet  assert_evtchn_irq_tasklet;
> +u8  evtchn_upcall_vector;
>  
>  struct nestedvcpu   nvcpu;
>  
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index a4e5345..a857561 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -370,6 +370,25 @@ 
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_ioreq_server_state_t);
>  
>  #endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
>  
> +#if defined(__i386__) || defined(__x86_64__)
> +
> +/*
> + * HVMOP_set_evtchn_upcall_vector: Set a  that should be used for 
> event
> + * channel upcalls on the specified . 
> If set,
> + * this vector will be used in preference to 
> the
> + * domain global callback via (see
> + *  

Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

[Tamas K Lengyel]

On Thu, Jan 15, 2015 at 6:31 PM, Ed White  wrote:
> On 01/15/2015 02:39 AM, Tamas K Lengyel wrote:
>>> There are ways of avoiding the
>>> single-step too, although I don't think that falls within the scope
>>> of this conversation.
>>>
>>> Ed
>>
>> I would be very interested in knowing how we can avoid the singlestep
>> phase. Are you envisioning using this with a split-TLB? IMHO this is a
>> pretty critical component of effectively using the new feature so
>> should be within scope of this discussion.
>>
>
> It's an optimization certainly, but it's not required, and it's not
> a technique we have placed in the public domain. You could try talking
> to us under NDA or figure it out for yourself, but I can't detail
> it here.
>
> Ed

That's unfortunate. I would have been happy to extend the xen-access
test tool to exercise this feature but contributing code that is known
to be sub-optimal from the beginning just doesn't feel right.

Tamas

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

Re: [Xen-devel] about the funtion call memory_type_changed()

[Andrew Cooper]

On 16/01/15 10:29, Li, Liang Z wrote:
> Hi Jan,
>
> I found the restore process of the live migration is quit long, so I try to 
> find out what's going on.
> By debugging, I found the most time consuming process is restore the VM's 
> MTRR MSR,
> The process is done in the function hvm_load_mtrr_msr(), it will call the
> memory_type_changed(), which eventually call the time consuming function
> flush_all().
>
> All this is caused by adding the memory_type_changed in your patch, here is 
> the link
> http://lists.xen.org/archives/html/xen-devel/2014-03/msg03792.html,
>
> I am not sure if it's necessary to call flush_all, even it's necessary,  call 
> the function
>  hvm_load_mtrr_msr one time will cause dozens call of flush_all, and each 
> call of the
>  flush_all function will consume about 8 milliseconds, in my test 
> environment, the VM
>  has 4 VCPUs, the hvm_load_mtrr_msr() will be called four times, and totally 
> consumes
>  about 500 milliseconds. Obviously, there are too many flush_all calls.
>
>  I think something should be done to solve this issue, do you think so?

The flush_all() cant be avoided completely, as it is permitted to use
sethvmcontext on an already-running VM.  In this case, the flush
certainly does need to happen if altering the MTRRs has had a real
effect on dirty cache lines.

However, having a batching mechanism across hvm_load_mtrr_msr() with a
single flush at the end seems like a wise move.

~Andrew

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

Re: [Xen-devel] [PATCHv1] grant-table: defer releasing pages acquired in a grant copy

[David Vrabel]

On 15/01/15 16:18, Jan Beulich wrote:
> 
> Wouldn't most of the changes up to here make a nice preparatory
> cleanup patch, easing review?

Yes, so...

> Leaving aside those mostly mechanical comments, content wise the
> patch looks good to me, but I'd hope for at least one other review.

,.. it might be best to wait for v2 before reviewing.

David

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

Re: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper
> Sent: 16 January 2015 10:39
> To: Paul Durrant; xen-devel@lists.xen.org
> Cc: Keir (Xen.org); David Vrabel; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls
> 
> On 16/01/15 10:09, Paul Durrant wrote:
> > HVM guests have always been confined to using the domain callback
> > via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
> > This is usually an IOAPIC vector and is only used if the event
> > channel is bound to vcpu 0.
> >
> > PVHVM Linux uses a pre-defined interrupt vector for the event
> > channel upcall, set using HVM_PARAM_CALLBACK_IRQ by ORing in a
> > special bit (bit 57) into the value (see params.h). However, it
> > does not assert the interrupt via the emulated local APIC.
> >
> > This mechanism is not suitable in the general case since Windows
> > (and potentially other OSes) because they:
> >
> > - cannot guarantee the same vector for all VCPUs
> > - do require the upcall to be asserted via the local APIC
> >
> > This patch adds a new HVM op allowing a guest to specify a local
> > APIC vector to use as an upcall notification for a specific vcpu
> > therefore coping with the case of differing vector numbers.
> >
> > Signed-off-by: Paul Durrant 
> > Cc: Keir Fraser 
> > Cc: Jan Beulich 
> > Cc: David Vrabel 
> > ---
> > v2:
> >  - Addressed comments from Andrew Cooper
> >- Check vector >=16
> >- Put hypercall in x86-specific section
> >
> > v3:
> >  - Addressed comments from Jan Beulich
> >- More verbose check-in comment
> >
> > v4:
> >  - Amended check-in comment as suggested by David Vrabel
> >
> > v5:
> >  - Addressed comments from Jan Beulich
> >
> >  xen/arch/x86/hvm/hvm.c  |   30
> ++
> >  xen/arch/x86/hvm/irq.c  |8 +++-
> >  xen/include/asm-x86/hvm/vcpu.h  |1 +
> >  xen/include/public/hvm/hvm_op.h |   19 +++
> >  4 files changed, 57 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 8b06bfd..85e43b8 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -5514,6 +5514,31 @@ static int hvmop_destroy_ioreq_server(
> >  return rc;
> >  }
> >
> > +static int hvmop_set_evtchn_upcall_vector(
> > +XEN_GUEST_HANDLE_PARAM(xen_hvm_set_evtchn_upcall_vector_t)
> uop)
> > +{
> > +xen_hvm_set_evtchn_upcall_vector_t op;
> > +struct domain *d = current->domain;
> > +struct vcpu *v;
> > +
> > +if ( copy_from_guest(&op, uop, 1) )
> > +return -EFAULT;
> > +
> > +if ( !is_hvm_domain(d) )
> > +return -EINVAL;
> > +
> > +if ( op.vector < 0x10 )
> > +return -EINVAL;
> > +
> > +if ( op.vcpu >= d->max_vcpus || (v = d->vcpu[op.vcpu]) == NULL )
> > +return -ENOENT;
> > +
> > +printk(XENLOG_G_INFO "%pv: upcall vector %u\n", v, op.vector);
> > +
> > +v->arch.hvm_vcpu.evtchn_upcall_vector = op.vector;
> > +return 0;
> > +}
> > +
> >  /*
> >   * Note that this value is effectively part of the ABI, even if we don't 
> > need
> >   * to make it a formal part of it: A guest suspended for migration in the
> > @@ -5573,6 +5598,11 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> >  guest_handle_cast(arg, xen_hvm_destroy_ioreq_server_t));
> >  break;
> >
> > +case HVMOP_set_evtchn_upcall_vector:
> > +rc = hvmop_set_evtchn_upcall_vector(
> > +guest_handle_cast(arg, xen_hvm_set_evtchn_upcall_vector_t));
> > +break;
> > +
> >  case HVMOP_set_param:
> >  case HVMOP_get_param:
> >  {
> > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> > index 35f4f94..743429e 100644
> > --- a/xen/arch/x86/hvm/irq.c
> > +++ b/xen/arch/x86/hvm/irq.c
> > @@ -218,7 +218,13 @@ void hvm_assert_evtchn_irq(struct vcpu *v)
> >  return;
> >  }
> >
> > -if ( is_hvm_pv_evtchn_vcpu(v) )
> > +if ( v->arch.hvm_vcpu.evtchn_upcall_vector != 0 )
> > +{
> > +uint8_t vector = v->arch.hvm_vcpu.evtchn_upcall_vector;
> > +
> > +vlapic_set_irq(vcpu_vlapic(v), vector, 0);
> > +}
> > +else if ( is_hvm_pv_evtchn_vcpu(v) )
> >  vcpu_kick(v);
> >  else if ( v->vcpu_id == 0 )
> >  hvm_set_callback_irq_level(v);
> > diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-
> x86/hvm/vcpu.h
> > index 01e0665..edd4523 100644
> > --- a/xen/include/asm-x86/hvm/vcpu.h
> > +++ b/xen/include/asm-x86/hvm/vcpu.h
> > @@ -160,6 +160,7 @@ struct hvm_vcpu {
> >  } u;
> >
> >  struct tasklet  assert_evtchn_irq_tasklet;
> > +u8  evtchn_upcall_vector;
> >
> >  struct nestedvcpu   nvcpu;
> >
> > diff --git a/xen/include/public/hvm/hvm_op.h
> b/xen/include/public/hvm/hvm_op.h
> > index a4e5345..a857561 100644
> > --- a/xen/include/public/hvm/hvm_op.h
> > +++ b/xen/include/public/hvm/hvm_op.h
> > @@ -370,6 +370,25 @@
> DEFINE_XEN_GUEST_HANDLE(x

Re: [Xen-devel] [rumpuserxen test] 33416: regressions - FAIL [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] [rumpuserxen test] 33416: regressions - 
FAIL"):
...
> I can't easily rerun it by hand, but the cron job is rerunning it
> already.  Also our automatic bisector is working on it.

xen.org writes ("[rumpuserxen test] 33434: tolerable FAIL - PUSHED"):
> flight 33434 rumpuserxen real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33434/
> 
> Failures :-/ but no regressions.
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-rumpuserxen-i386  5 xen-bootfail pass in 33416
>  test-amd64-amd64-rumpuserxen-amd64  8 guest-start  fail in 33416 pass in 
> 33434

The former is nothing to do with the rump kernel code and is due to an
infrastructure problem in the test setup.

The latter is the GPF turning out to be unreproducible.

I guess we should keep an eye out in case it turns out to be a race
rather than a cosmic ray.

Ian.

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

Re: [Xen-devel] how to generate a smaller core with xm dump-core

[Daniel Kiper]

On Fri, Jan 16, 2015 at 10:14:12AM +, Ian Campbell wrote:
> On Fri, 2015-01-16 at 16:39 +0800, Zhenzhong Duan wrote:
> > I am thinking if port some code from makedumpfile is possible and
> > acceptable.
>
> makedumpfile appears to be GPL, whereas libxc is LGPL, so if you wanted
> to port code directly you would need permissions from the copyright
> holders to re-license.
>
> I think we would be OK with you reimplementing some of the techniques
> within tools/libxc/xc_core*.c though, so long as you don't copy actual
> code. Obviously just improving that code without reference to
> makedumpfile is fine too.
>
> I don't think we need or want yet another tool for doing this in the
> code base though.
>
> Another option would be for you to add Xen support to makedumpfile,
> you'd want to speak to the maintainers of the tool about that though.

In general most of Xen related functionality is in place. There are some
issues when you try to use non common things. Once I though about extrating
makedumpfile's core functionality to a library (so file) in makedumpfile
project itself (IIRC, somebody dicussed this topic on kexec list, but
in another context, a few months ago) and then linking xl stuff with it.
Now it is more hand waving and I have this thing on my TODO list but right
now I have more important things to do. So, this is a quite far future work...

Daniel

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

[Xen-devel] [PATCH v2 0/2] tools/configure: Add QEMU dependencies

[Ian Jackson]

Julien Grall writes ("[PATCH v2 0/2] tools/configure: Add QEMU dependencies"):
> This small patch series replaces the patch [1] sent earlier.

Both:

Acked-by: Ian Jackson 

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v2 2/2] tools/configure: Check if pixman is present on the system when building QEMU

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH v2 2/2] tools/configure: Check if pixman is 
present on the system when building QEMU"):
> On Thu, 2015-01-15 at 21:06 +, Julien Grall wrote:
> > -dnl Glib 2.0 is only required when QEMU is built
> > +dnl Glib 2.0 and pixman are only required when QEMU is built
> 
> Rather than an ever increasing list here I propose to say "The following
> are only...", and perhaps insert an "upstream" before QEMU, unless these
> are needed for trad too (in which case the condition isn't quite right).
> I think glib and pixman are only for upstream though.
> 
> I can do that on commit though if you like.

Either way is fine by me.

Ian.

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

Re: [Xen-devel] about the funtion call memory_type_changed()

[Jan Beulich]

>>> On 16.01.15 at 11:46,  wrote:
> On 16/01/15 10:29, Li, Liang Z wrote:
>> I found the restore process of the live migration is quit long, so I try to 
> find out what's going on.
>> By debugging, I found the most time consuming process is restore the VM's 
> MTRR MSR,
>> The process is done in the function hvm_load_mtrr_msr(), it will call the
>> memory_type_changed(), which eventually call the time consuming function
>> flush_all().
>>
>> All this is caused by adding the memory_type_changed in your patch, here is 
> the link
>> http://lists.xen.org/archives/html/xen-devel/2014-03/msg03792.html,
>>
>> I am not sure if it's necessary to call flush_all, even it's necessary,  
> call the function
>>  hvm_load_mtrr_msr one time will cause dozens call of flush_all, and each 
> call of the
>>  flush_all function will consume about 8 milliseconds, in my test 
> environment, the VM
>>  has 4 VCPUs, the hvm_load_mtrr_msr() will be called four times, and totally 
> consumes
>>  about 500 milliseconds. Obviously, there are too many flush_all calls.
>>
>>  I think something should be done to solve this issue, do you think so?
> 
> The flush_all() cant be avoided completely, as it is permitted to use
> sethvmcontext on an already-running VM.  In this case, the flush
> certainly does need to happen if altering the MTRRs has had a real
> effect on dirty cache lines.

Plus the actual functions calling memory_type_changed() in mtrr.c
can also be called while the VM is already running.

> However, having a batching mechanism across hvm_load_mtrr_msr() with a
> single flush at the end seems like a wise move.

And that shouldn't be very difficult to achieve. Furthermore perhaps
it would be possible to check whether the VM did run at all already,
and if it didn't we could avoid the flush altogether in the context load
case?

Jan


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

Re: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls

[Jan Beulich]

>>> On 16.01.15 at 12:07,  wrote:
>> From: Andrew Cooper
>> On 16/01/15 10:09, Paul Durrant wrote:
>> > +#define HVMOP_set_evtchn_upcall_vector 23
>> > +struct xen_hvm_set_evtchn_upcall_vector {
>> > +uint32_t vcpu;
>> > +uint8_t vector;
>> > +};
>> > +typedef struct xen_hvm_set_evtchn_upcall_vector
>> xen_hvm_set_evtchn_upcall_vector_t;
>> > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
>> 
>> I think you should remove "set" from the structure name.  Who knows -
>> someone might want to implement a get hypercall in the future.
>> 
> 
> I didn't want to make any assumption about future use of the structure and 
> followed the convention of tying the name to the hypercall. I'm happy to make 
> the name more generic if anyone else also thinks that's a good idea.

I think this is a good idea, and I can take care of the name change
while committing (unless other reasons for another round should
show up).

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] tools/configure: Check if pixman is present on the system when building QEMU

[Julien Grall]

Hi Ian,

On 16/01/15 10:05, Ian Campbell wrote:
> On Thu, 2015-01-15 at 21:06 +, Julien Grall wrote:
>> QEMU upstream requires the use of pixman. When pixman is not present the
>> system, the configure of QEMU will fail with:
>>
>> ERROR: pixman not present. Your options:
>>  (1) Preferred: Install the pixman devel package (any recent
>>  distro should have packages as Xorg needs pixman too).
>>  (2) Fetch the pixman submodule, using:
>>  git submodule update --init pixman
>>
>> I think we can use by default the version on the system. So check it
>> a Xen configuration time to avoid a build issue later.
>>
>> Signed-off-by: Julien Grall 
>>
>> ---
>> This patch requires to regenerate tools/configure.
>>
>> Changes in v2:
>> - Only check if pixman is present when building QEMU
>> ---
>>  tools/configure.ac | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/configure.ac b/tools/configure.ac
>> index 2aff18d..64dc75c 100644
>> --- a/tools/configure.ac
>> +++ b/tools/configure.ac
>> @@ -323,9 +323,10 @@ esac
>>   AX_CHECK_UUID
>>   AX_CHECK_CURSES
>>  
>> -dnl Glib 2.0 is only required when QEMU is built
>> +dnl Glib 2.0 and pixman are only required when QEMU is built
> 
> Rather than an ever increasing list here I propose to say "The following
> are only...", and perhaps insert an "upstream" before QEMU, unless these
> are needed for trad too (in which case the condition isn't quite right).
> I think glib and pixman are only for upstream though.

Right.

> I can do that on commit though if you like.

Yes please.

Regards,


-- 
Julien Grall

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

Re: [Xen-devel] about the funtion call memory_type_changed()

[Andrew Cooper]

On 16/01/15 11:54, Jan Beulich wrote:
 On 16.01.15 at 11:46,  wrote:
>> On 16/01/15 10:29, Li, Liang Z wrote:
>>> I found the restore process of the live migration is quit long, so I try to 
>> find out what's going on.
>>> By debugging, I found the most time consuming process is restore the VM's 
>> MTRR MSR,
>>> The process is done in the function hvm_load_mtrr_msr(), it will call the
>>> memory_type_changed(), which eventually call the time consuming function
>>> flush_all().
>>>
>>> All this is caused by adding the memory_type_changed in your patch, here is 
>> the link
>>> http://lists.xen.org/archives/html/xen-devel/2014-03/msg03792.html,
>>>
>>> I am not sure if it's necessary to call flush_all, even it's necessary,  
>> call the function
>>>  hvm_load_mtrr_msr one time will cause dozens call of flush_all, and each 
>> call of the
>>>  flush_all function will consume about 8 milliseconds, in my test 
>> environment, the VM
>>>  has 4 VCPUs, the hvm_load_mtrr_msr() will be called four times, and 
>>> totally 
>> consumes
>>>  about 500 milliseconds. Obviously, there are too many flush_all calls.
>>>
>>>  I think something should be done to solve this issue, do you think so?
>> The flush_all() cant be avoided completely, as it is permitted to use
>> sethvmcontext on an already-running VM.  In this case, the flush
>> certainly does need to happen if altering the MTRRs has had a real
>> effect on dirty cache lines.
> Plus the actual functions calling memory_type_changed() in mtrr.c
> can also be called while the VM is already running.
>
>> However, having a batching mechanism across hvm_load_mtrr_msr() with a
>> single flush at the end seems like a wise move.
> And that shouldn't be very difficult to achieve. Furthermore perhaps
> it would be possible to check whether the VM did run at all already,
> and if it didn't we could avoid the flush altogether in the context load
> case?

I am not sure whether we currently have that information available. 
Guests are currently created with a single ref in the systemcontroller
pause count, and require an unpause hypercall to get going.

That said, the overwhelmingly common case is that the only hvmsetcontext
hypercall made on a domain will be during construction, so there are
probably many improvements to be had by knowing there is no dirty state
to flush.

~Andrew

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

[Xen-devel] [PATCH] Xen/hypercall: Update vcpu_op to take an unsigned vcpuid

[Andrew Cooper]

This has no guest-visible change, but makes the Hypervisor side bounds
checking more simple.

Signed-off-by: Andrew Cooper 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Tim Deegan 

---

There are no functional changes as a result of this patch, but I have an RFC
improvement to suggest.

The bounds check against MAX_VIRT_CPUS is spurious now that PVH domains can
use vcpu_op hypercalls.  It is fine as MAX_VIRT_CPUS (8K) is far higher than
current 128 limit for HVM guests, but there is nothing conceptually preventing
an HVM domain from having more than 8k CPUs (x2apic allows for 2^32 unique ids).

I propose dropping the MAX_VIRT_CPU bounds check completely, and relying on
d->max_vcpus to be within the approprate bounds.  This will result in a guest
visible change insofar that some of their -EINVAL errors will turn into
-ENOENT, which is why this is suggestion is RFC.
---
 xen/arch/arm/domain.c   |2 +-
 xen/arch/x86/hvm/hvm.c  |4 ++--
 xen/common/compat/domain.c  |6 +++---
 xen/common/domain.c |6 +++---
 xen/include/asm-arm/hypercall.h |2 +-
 xen/include/public/vcpu.h   |2 +-
 xen/include/xen/hypercall.h |4 ++--
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7221bc8..cfc7ab4 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -777,7 +777,7 @@ void arch_dump_domain_info(struct domain *d)
 }
 
 
-long do_arm_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 {
 switch ( cmd )
 {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8b06bfd..e096094 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4659,7 +4659,7 @@ static long hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 }
 
 static long hvm_vcpu_op(
-int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc;
 
@@ -4718,7 +4718,7 @@ static long hvm_memory_op_compat32(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 }
 
 static long hvm_vcpu_op_compat32(
-int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+int cmd, unsigned vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc;
 
diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c
index b4be3b3..510843d 100644
--- a/xen/common/compat/domain.c
+++ b/xen/common/compat/domain.c
@@ -23,13 +23,13 @@ CHECK_SIZE_(struct, vcpu_info);
 CHECK_vcpu_register_vcpu_info;
 #undef xen_vcpu_register_vcpu_info
 
-int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+int compat_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 {
 struct domain *d = current->domain;
 struct vcpu *v;
 int rc = 0;
 
-if ( (vcpuid < 0) || (vcpuid >= MAX_VIRT_CPUS) )
+if ( vcpuid >= MAX_VIRT_CPUS )
 return -EINVAL;
 
 if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
@@ -59,7 +59,7 @@ int compat_vcpu_op(int cmd, int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 domain_unlock(d);
 
 if ( rc == -ERESTART )
-rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iih",
+rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iuh",
cmd, vcpuid, arg);
 
 xfree(cmp_ctxt);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 336e9ea..e02823e 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1139,14 +1139,14 @@ void unmap_vcpu_info(struct vcpu *v)
 put_page_and_type(mfn_to_page(mfn));
 }
 
-long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 struct domain *d = current->domain;
 struct vcpu *v;
 struct vcpu_guest_context *ctxt;
 long rc = 0;
 
-if ( (vcpuid < 0) || (vcpuid >= MAX_VIRT_CPUS) )
+if ( vcpuid >= MAX_VIRT_CPUS )
 return -EINVAL;
 
 if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
@@ -1174,7 +1174,7 @@ long do_vcpu_op(int cmd, int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 free_vcpu_guest_context(ctxt);
 
 if ( rc == -ERESTART )
-rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iih",
+rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iuh",
cmd, vcpuid, arg);
 
 break;
diff --git a/xen/include/asm-arm/hypercall.h b/xen/include/asm-arm/hypercall.h
index 94a92d4..a0c5a31 100644
--- a/xen/include/asm-arm/hypercall.h
+++ b/xen/include/asm-arm/hypercall.h
@@ -4,7 +4,7 @@
 #include  /* for arch_do_domctl */
 int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
 
-long do_arm_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(vo

Re: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 January 2015 11:59
> To: Andrew Cooper; Paul Durrant; xen-devel@lists.xen.org
> Cc: David Vrabel; Keir (Xen.org)
> Subject: RE: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls
> 
> >>> On 16.01.15 at 12:07,  wrote:
> >> From: Andrew Cooper
> >> On 16/01/15 10:09, Paul Durrant wrote:
> >> > +#define HVMOP_set_evtchn_upcall_vector 23
> >> > +struct xen_hvm_set_evtchn_upcall_vector {
> >> > +uint32_t vcpu;
> >> > +uint8_t vector;
> >> > +};
> >> > +typedef struct xen_hvm_set_evtchn_upcall_vector
> >> xen_hvm_set_evtchn_upcall_vector_t;
> >> >
> +DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_evtchn_upcall_vector_t);
> >>
> >> I think you should remove "set" from the structure name.  Who knows -
> >> someone might want to implement a get hypercall in the future.
> >>
> >
> > I didn't want to make any assumption about future use of the structure and
> > followed the convention of tying the name to the hypercall. I'm happy to
> make
> > the name more generic if anyone else also thinks that's a good idea.
> 
> I think this is a good idea, and I can take care of the name change
> while committing (unless other reasons for another round should
> show up).
> 

Thanks :-)

  Paul

> Jan


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

[Xen-devel] [linux-linus test] 33426: tolerable FAIL - PUSHED

[xen . org]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 33406
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 33406
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33406
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 33406

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  9 guest-start  fail  never pass
 test-armhf-armhf-libvirt  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-amd64-amd64-libvirt  9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   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-i386-xl-qemuu-winxpsp3 14 guest-stopfail 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-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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:
 linux188c901941efd43cbf21e8f4f9e9a276536b989c
baseline version:
 linux971780b701946be0d6e34b4abf6eec1ab05ec0c8


People who touched revisions under test:
  Andrey Skvortsov 
  Boris Ostrovsky 
  Bryan Wu 
  Chen Yu 
  Christian Borntraeger 
  dann frazier 
  David Drysdale 
  David Vrabel 
  Davidlohr Bueso 
  Geert Uytterhoeven 
  Jan Beulich 
  Johan Hovold 
  Juegren Gross 
  Juergen Gross 
  Linus Torvalds 
  Paul E. McKenney 
  Peter Zijlstra 
  Shuah Khan 
  Simon Guinot 
  Srinivas Pandruvada 
  Vitaly Kuznetsov 
  Zhang Rui 


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
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64   

Re: [Xen-devel] [PATCH 0/8] current ACCESS_ONCE patch queue

[Alexander Graf]

On 15.01.15 09:58, Christian Borntraeger wrote:
> Folks,
> 
> fyi, this is my current patch queue for the next merge window. It
> does contain a patch that will disallow ACCESS_ONCE on non-scalar
> types.
> 
> The tree is part of linux-next and can be found at
> git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git linux-next

KVM PPC bits are:

 Acked-by: Alexander Graf 



Alex

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

Re: [Xen-devel] [PATCH] Xen/hypercall: Update vcpu_op to take an unsigned vcpuid

[Jan Beulich]

>>> On 16.01.15 at 13:03,  wrote:
> This has no guest-visible change, but makes the Hypervisor side bounds
> checking more simple.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 

> There are no functional changes as a result of this patch, but I have an RFC
> improvement to suggest.
> 
> The bounds check against MAX_VIRT_CPUS is spurious now that PVH domains can
> use vcpu_op hypercalls.  It is fine as MAX_VIRT_CPUS (8K) is far higher than
> current 128 limit for HVM guests, but there is nothing conceptually 
> preventing
> an HVM domain from having more than 8k CPUs (x2apic allows for 2^32 unique 
> ids).

Not exactly, due to the need to allow for clustered mode, but still
a few hundred k.

> I propose dropping the MAX_VIRT_CPU bounds check completely, and relying on
> d->max_vcpus to be within the approprate bounds.  This will result in a guest
> visible change insofar that some of their -EINVAL errors will turn into
> -ENOENT, which is why this is suggestion is RFC.

I don't think changes in error code values is problematic in any way,
except in cases where for specific ones specific actions are expected
to be taken by the guest. So - go for it.

Jan


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

[Xen-devel] [xen-4.3-testing test] 33427: tolerable FAIL - PUSHED

[xen . org]

flight 33427 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33427/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-installfail like 9
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install  fail like 33379

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install  fail never pass
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install 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
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check fail  never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass

version targeted for testing:
 xen  d07266e83fe6e70fa052618ed205a7ecd0ad7318
baseline version:
 xen  5d4e3ff19c33770ce01bec949c50326b11088fef


People who touched revisions under test:
  Charles Arnold 
  Ian Campbell 
  Ian Jackson 
  Luis R. Rodriguez 
  Wei Liu 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386  

[Xen-devel] [PATCH v1 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Iurii Konovalenko]

From: Oleksandr Tyshchenko 

Signed-off-by: Oleksandr Tyshchenko 
---
 docs/misc/arm/early-printk.txt |   1 +
 xen/arch/arm/Rules.mk  |   4 ++
 xen/arch/arm/arm32/debug-rcar2.inc |  49 +
 xen/include/asm-arm/rcar2-uart.h   | 107 +
 4 files changed, 161 insertions(+)
 create mode 100644 xen/arch/arm/arm32/debug-rcar2.inc
 create mode 100644 xen/include/asm-arm/rcar2-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..ff02893 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 := rcar2
+EARLY_UART_BASE_ADDRESS := 0xe6e6
+endif
 
 ifneq ($(EARLY_PRINTK_INC),)
 EARLY_PRINTK := y
diff --git a/xen/arch/arm/arm32/debug-rcar2.inc 
b/xen/arch/arm/arm32/debug-rcar2.inc
new file mode 100644
index 000..a66895c
--- /dev/null
+++ b/xen/arch/arm/arm32/debug-rcar2.inc
@@ -0,0 +1,49 @@
+/*
+ * xen/arch/arm/arm32/debug-rcar2.inc
+ *
+ * R-Car Gen2 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 
+
+/* R-Car Gen2 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
+
+/* R-Car Gen2 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/rcar2-uart.h b/xen/include/asm-arm/rcar2-uart.h
new file mode 100644
index 000..10a56fb
--- /dev/null
+++ b/xen/include/asm-arm/rcar2-uart.h
@@ -0,0 +1,107 @@
+/*
+ * xen/include/asm-arm/rcar2-uart.h
+ *
+ * Common constant definition between early printk and the UART driver
+ * for the R-Car Gen2 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_RCAR2_H
+#define __ASM_ARM_RCAR2_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 register */
+#define SCIF_SCFCR (0x18)/* FIFO control register  

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

[Iurii Konovalenko]

From: Iurii Konovalenko 

The following patch series adds basic support needed for R-Car Gen2 evm boards.
Verified on Xen 4.5.0 stable on Lager board with and without early_printk.

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

Oleksandr Tyshchenko (2):
  xen/arm: Add R-Car Gen2 support for early printk
  xen/arm: Add new driver for R-Car Gen2 UART

 config/arm32.mk  |   1 +
 docs/misc/arm/early-printk.txt   |   1 +
 xen/arch/arm/Rules.mk|   4 +
 xen/arch/arm/arm32/debug-rcar2.inc   |  49 
 xen/arch/arm/platforms/Makefile  |   1 +
 xen/arch/arm/platforms/shmobile.c| 149 
 xen/drivers/char/Makefile|   1 +
 xen/drivers/char/rcar2-uart.c| 376 +++
 xen/include/asm-arm/platforms/shmobile.h |  24 ++
 xen/include/asm-arm/rcar2-uart.h | 107 +
 10 files changed, 713 insertions(+)
 create mode 100644 xen/arch/arm/arm32/debug-rcar2.inc
 create mode 100644 xen/arch/arm/platforms/shmobile.c
 create mode 100644 xen/drivers/char/rcar2-uart.c
 create mode 100644 xen/include/asm-arm/platforms/shmobile.h
 create mode 100644 xen/include/asm-arm/rcar2-uart.h

-- 
1.9.1


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

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

[Iurii Konovalenko]

From: Iurii Konovalenko 

Signed-off-by: Iurii Konovalenko 
---
 xen/arch/arm/platforms/Makefile  |   1 +
 xen/arch/arm/platforms/shmobile.c| 149 +++
 xen/include/asm-arm/platforms/shmobile.h |  24 +
 3 files changed, 174 insertions(+)
 create mode 100644 xen/arch/arm/platforms/shmobile.c
 create mode 100644 xen/include/asm-arm/platforms/shmobile.h

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8f47c16..29e931a 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) += shmobile.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
diff --git a/xen/arch/arm/platforms/shmobile.c 
b/xen/arch/arm/platforms/shmobile.c
new file mode 100644
index 000..4c78ed6
--- /dev/null
+++ b/xen/arch/arm/platforms/shmobile.c
@@ -0,0 +1,149 @@
+/*
+ * xen/arch/arm/platforms/shmobile.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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+u32 shmobile_read_mode_pins(void)
+{
+static uint32_t mode;
+
+void __iomem *modemr = ioremap_nocache(SHMOBILE_MODEMR, 4);
+if( !modemr )
+{
+dprintk( XENLOG_ERR, "Unable to map shmobile Mode MR\n");
+return 0;
+}
+
+mode = readl_relaxed(modemr);
+iounmap(modemr);
+
+return mode;
+}
+
+static int shmobile_init_time(void)
+{
+uint32_t freq;
+void __iomem *tmu;
+int extal_mhz = 0;
+uint32_t mode = shmobile_read_mode_pins();
+
+/* At Linux boot time the Renesas R-Car Gen2 arch timer comes
+ * up with the counter disabled. Moreover, it may also report
+ * a potentially incorrect fixed 13 MHz frequency. To be
+ * correct these registers need to be updated to use the
+ * frequency EXTAL / 2 which can be determined by the MD pins.
+ */
+
+switch ( mode & (MD(14) | MD(13)) ) {
+case 0:
+extal_mhz = 15;
+break;
+case MD(13):
+extal_mhz = 20;
+break;
+case MD(14):
+extal_mhz = 26;
+break;
+case MD(13) | MD(14):
+extal_mhz = 30;
+break;
+}
+
+/* The arch timer frequency equals EXTAL / 2 */
+freq = extal_mhz * (100 / 2);
+
+/* Remap "armgcnt address map" space */
+tmu = ioremap_attr(SHMOBILE_ARCH_TIMER_BASE, PAGE_SIZE, 
+PAGE_HYPERVISOR_NOCACHE);
+if ( !tmu )
+{
+dprintk(XENLOG_ERR, "Unable to map TMU\n");
+return -ENOMEM;
+}
+/*
+ * Update the timer if it is either not running, or is not at the
+ * right frequency. The timer is only configurable in secure mode
+ * so this avoids an abort if the loader started the timer and
+ * entered the kernel in non-secure mode.
+ */
+
+if ( (readl_relaxed(tmu + SHMOBILE_ARCH_TIMER_CNTCR) & 1) == 0 ||
+readl_relaxed(tmu + SHMOBILE_ARCH_TIMER_CNTFID0) != freq ) {
+/* Update registers with correct frequency */
+writel_relaxed(freq, tmu + SHMOBILE_ARCH_TIMER_CNTFID0);
+
+/* make sure arch timer is started by setting bit 0 of CNTCR */
+writel_relaxed(1, tmu + SHMOBILE_ARCH_TIMER_CNTCR);
+}
+
+iounmap(tmu);
+
+return 0;
+}
+
+static int __init shmobile_smp_init(void)
+{
+void __iomem *p;
+/* setup reset vectors */
+p = ioremap_nocache(SHMOBILE_RAM, 0x1000);
+if( !p )
+{
+dprintk( XENLOG_ERR, "Unable to map shmobile ICRAM\n");
+return -ENOMEM;
+}
+
+writel_relaxed(__pa(init_secondary), p + SHMOBILE_SMP_START_OFFSET);
+iounmap(p);
+
+asm("sev;");
+
+return 0;
+}
+
+static const char const *shmobile_dt_compat[] __initdata =
+{
+"renesas,lager",
+NULL
+};
+
+PLATFORM_START(shmobile, "Renesas R-Car Gen2")
+.compatible = shmobile_dt_compat,
+.init_time = shmobile_init_time,
+.cpu_up = cpu_up_send_sgi,
+.smp_init = shmobile_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:
+ */
diff --git a/xen/include/asm-arm/platforms/shmobile.h 
b/xen/include/asm-arm/platforms/shmobile.h
new file mode 

[Xen-devel] [PATCH v1 2/3] xen/arm: Add new driver for R-Car Gen2 UART

[Iurii Konovalenko]

From: Oleksandr Tyshchenko 

Signed-off-by: Oleksandr Tyshchenko 
Signed-off-by: Iurii Konovalenko 
---
 config/arm32.mk   |   1 +
 xen/drivers/char/Makefile |   1 +
 xen/drivers/char/rcar2-uart.c | 376 ++
 3 files changed, 378 insertions(+)
 create mode 100644 xen/drivers/char/rcar2-uart.c

diff --git a/config/arm32.mk b/config/arm32.mk
index 4f83a63..6ee5173 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_RCAR2 := y
 HAS_NS16550 := y
 
 # Use only if calling $(LD) directly.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 911b788..64428b7 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_RCAR2) += rcar2-uart.o
 obj-$(HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += dt-uart.o
 obj-y += serial.o
diff --git a/xen/drivers/char/rcar2-uart.c b/xen/drivers/char/rcar2-uart.c
new file mode 100644
index 000..85d1b17
--- /dev/null
+++ b/xen/drivers/char/rcar2-uart.c
@@ -0,0 +1,376 @@
+/*
+ * xen/drivers/char/rcar2-uart.c
+ *
+ * Driver for R-Car Gen2 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 rcar2_readb(uart, off)  readb((uart)->regs + (off))
+#define rcar2_writeb(uart, off, val)writeb((val), (uart)->regs + (off))
+
+#define rcar2_readw(uart, off)  readw((uart)->regs + (off))
+#define rcar2_writew(uart, off, val)writew((val), (uart)->regs + (off))
+
+static struct rcar2_uart {
+unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int irq;
+char __iomem *regs;
+struct irqaction irqaction;
+struct vuart_info vuart;
+bool_t irq_en;
+} rcar2_com = {0};
+
+static void rcar2_uart_interrupt(int irq, void *data, struct cpu_user_regs 
*regs)
+{
+struct serial_port *port = data;
+struct rcar2_uart *uart = port->uart;
+uint16_t status, ctrl;
+
+ctrl = rcar2_readw(uart, SCIF_SCSCR);
+status = rcar2_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);
+
+if ( port->txbufc == port->txbufp )
+{
+/*
+ * There is no data bytes to send. We have to disable
+ * TX Interrupt to prevent us from getting stuck in the
+ * interrupt handler
+ */
+ctrl = rcar2_readw(uart, SCIF_SCSCR);
+ctrl &= ~SCSCR_TIE;
+rcar2_writew(uart, SCIF_SCSCR, ctrl);
+}
+}
+
+/* RX Interrupt */
+if ( status & (SCFSR_RDF | SCFSR_DR) )
+serial_rx_interrupt(port, regs);
+
+/* Error Interrupt */
+if ( status & SCIF_ERRORS )
+rcar2_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
+if ( rcar2_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
+rcar2_writew(uart, SCIF_SCLSR, 0);
+
+status = rcar2_readw(uart, SCIF_SCFSR) & ~SCFSR_TEND;
+if ( !(ctrl & SCSCR_TIE) )
+status &= ~SCFSR_TDFE;
+}
+}
+
+static void __init rcar2_uart_init_preirq(struct serial_port *port)
+{
+struct rcar2_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 ( !(rcar2_readw(uart, SCIF_SCFSR) & SCFSR_TEND) );
+
+/* Disable TX/RX parts and all interrupts */
+rcar2_writew(uart, SCIF_SCSCR, 0);
+
+/* Reset TX/RX FIFOs */
+rcar2_writew(uart, SCIF_SCFCR, SCFCR_RFRST | SCFCR_TFRST);
+
+/* Clear all errors and flags */
+rcar2_readw(uart, SCIF_SCFSR);
+rcar2_writew(uart, SCIF_SCFSR, 0);
+rcar2_readw(uart, SCIF_SCLSR);
+rcar2_writew(uart, SCIF_SCLSR, 0);
+
+/* Select Baud rate generator output as 

Re: [Xen-devel] [PATCH v1 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Ian Campbell]

On Fri, 2015-01-16 at 13:05 +, Julien Grall wrote:
> Hello Iurii,
> 
> Thanks for adding the support of a new board in Xen.
> 
> On 16/01/15 12:50, Iurii Konovalenko wrote:
> > diff --git a/xen/include/asm-arm/rcar2-uart.h 
> > b/xen/include/asm-arm/rcar2-uart.h
> > new file mode 100644
> > index 000..10a56fb
> > --- /dev/null
> > +++ b/xen/include/asm-arm/rcar2-uart.h
> 
> [..]
> 
> > +#ifndef __ASM_ARM_RCAR2_H
> > +#define __ASM_ARM_RCAR2_H
> 
> According to the name of the guard should be called __ASM_ARM_RCAR2_UART_H

Is RCAR2 the name of the board, the soc or the name of uart IP block?

I'd prefer the naming (here and for the main driver) to be as far to the
right of that list as possible.

Ian.


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

Re: [Xen-devel] [PATCH v1 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Julien Grall]

Hello Iurii,

Thanks for adding the support of a new board in Xen.

On 16/01/15 12:50, Iurii Konovalenko wrote:
> diff --git a/xen/include/asm-arm/rcar2-uart.h 
> b/xen/include/asm-arm/rcar2-uart.h
> new file mode 100644
> index 000..10a56fb
> --- /dev/null
> +++ b/xen/include/asm-arm/rcar2-uart.h

[..]

> +#ifndef __ASM_ARM_RCAR2_H
> +#define __ASM_ARM_RCAR2_H

According to the name of the guard should be called __ASM_ARM_RCAR2_UART_H

[..]

> +#endif /* __ASM_ARM_RCAR2_H */

Ditto.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v1 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Julien Grall]

On 16/01/15 13:08, Ian Campbell wrote:
> I'd prefer the naming (here and for the main driver) to be as far to the
> right of that list as possible.

All the UART headers in xen/ and asm-arm/ are called myuart-uart.h.

I think it's better if we keep the same convention everywhere.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v1 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Ian Campbell]

On Fri, 2015-01-16 at 13:11 +, Julien Grall wrote:
> On 16/01/15 13:08, Ian Campbell wrote:
> > I'd prefer the naming (here and for the main driver) to be as far to the
> > right of that list as possible.
> 
> All the UART headers in xen/ and asm-arm/ are called myuart-uart.h.
> 
> I think it's better if we keep the same convention everywhere.

I'm trying to confirm that RCAR2 is actually the appropriate value for
myuart.

Ian.


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

Re: [Xen-devel] [PATCH v1 2/3] xen/arm: Add new driver for R-Car Gen2 UART

[Julien Grall]

Hi Iurii,

On 16/01/15 12:50, Iurii Konovalenko wrote:
> +static int __init rcar2_uart_init(struct dt_device_node *dev,
> + const void *data)
> +{
> +const char *config = data;
> +struct rcar2_uart *uart;
> +int res;
> +u64 addr, size;
> +
> +if ( strcmp(config, "") )
> +printk("WARNING: UART configuration is not supported\n");
> +
> +uart = &rcar2_com;
> +
> +uart->clock_hz  = SCIF_CLK_FREQ;
> +uart->baud  = BAUD_AUTO;
> +uart->data_bits = 8;
> +uart->parity= PARITY_NONE;
> +uart->stop_bits = 1;
> +
> +res = dt_device_get_address(dev, 0, &addr, &size);
> +if ( res )
> +{
> +printk("rcar2-uart: Unable to retrieve the base"
> + " address of the UART\n");
> +return res;
> +}
> +
> +uart->regs = ioremap_attr(addr, size, PAGE_HYPERVISOR_NOCACHE);

Please use ioremap_nocache

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v1 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Oleksandr Tyshchenko]

Hi all.

Let me explain.

The Renesas R-Car Gen2 is a family of SoCs (R-Car H2, M2, etc.).
The "Lager" is a name of development board based on R-Car H2 SoC.
The UART IP block named SCIF (Serial Communication Interface with FIFO)
is common for all SoCs in R-Car Gen2 family.


On Fri, Jan 16, 2015 at 3:08 PM, Ian Campbell 
wrote:

> On Fri, 2015-01-16 at 13:05 +, Julien Grall wrote:
> > Hello Iurii,
> >
> > Thanks for adding the support of a new board in Xen.
> >
> > On 16/01/15 12:50, Iurii Konovalenko wrote:
> > > diff --git a/xen/include/asm-arm/rcar2-uart.h
> b/xen/include/asm-arm/rcar2-uart.h
> > > new file mode 100644
> > > index 000..10a56fb
> > > --- /dev/null
> > > +++ b/xen/include/asm-arm/rcar2-uart.h
> >
> > [..]
> >
> > > +#ifndef __ASM_ARM_RCAR2_H
> > > +#define __ASM_ARM_RCAR2_H
> >
> > According to the name of the guard should be called
> __ASM_ARM_RCAR2_UART_H
>
> Is RCAR2 the name of the board, the soc or the name of uart IP block?
>
> I'd prefer the naming (here and for the main driver) to be as far to the
> right of that list as possible.
>
> Ian.
>
>


-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] [PATCH v1 1/3] xen/arm: Add R-Car Gen2 support for early printk

[Ian Campbell]

On Fri, 2015-01-16 at 15:26 +0200, Oleksandr Tyshchenko wrote:
> Hi all. 
> 
> Let me explain.
> 
> 
> The Renesas R-Car Gen2 is a family of SoCs (R-Car H2, M2, etc.).
> The "Lager" is a name of development board based on R-Car H2 SoC.
> The UART IP block named SCIF (Serial Communication Interface with FIFO)
> is common for all SoCs in R-Car Gen2 family.

Sounds like RCAR2 is indeed the right name to use then, thanks.

Ian.



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

[Xen-devel] [linux-next test] 33430: regressions - FAIL

[xen . org]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  8 guest-stop  fail REGR. vs. 33406
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install fail REGR. vs. 33406

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-freebsd10-amd64  7 freebsd-install fail like 33406
 test-amd64-i386-freebsd10-i386  7 freebsd-install  fail like 33406
 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33406
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install  fail like 33406

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel  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-armhf-armhf-xl  10 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd   9 guest-start  fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass
 test-amd64-i386-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  14 guest-stop   fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass

version targeted for testing:
 linuxceb563571477747d61e1bc30b582a9e70e16727b
baseline version:
 linux971780b701946be0d6e34b4abf6eec1ab05ec0c8

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
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-win7-amd64   fail
 test-amd64-i386-xl-win7-amd64fail
 test-amd64-i386-xl-credit2   pass
 test-amd64-i386-freebsd10-i386   fail
 test-amd64-i3

[Xen-devel] [libvirt test] 33443: regressions - FAIL

[xen . org]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 33422
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 33422
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 33422

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

version targeted for testing:
 libvirt  dd69a14f90b4bde9c07a6ef594914323874a26ce
baseline version:
 libvirt  ce745914b33e3f9a136d91655600b931e7a4178f


People who touched revisions under test:
  Daniel P. Berrange 
  Jim Fehlig 
  Jiri Denemark 
  Ján Tomko 
  Kiarie Kahurani 
  Luyao Huang 
  Michal Privoznik 
  Shivaprasad G Bhat 
  Shivaprasad G Bhat 


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



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


Not pushing.


commit dd69a14f90b4bde9c07a6ef594914323874a26ce
Author: Daniel P. Berrange 
Date:   Tue Nov 18 17:34:42 2014 +

Add support for schema validation when passing in XML

The virDomainDefineXMLFlags and virDomainCreateXML APIs both
gain new flags allowing them to be told to validate XML.
This updates all the drivers to turn on validation in the
XML parser when the flags are set

commit 6d06b0d89bfeec8c9e04d99bf7b9fc430ed25d37
Author: Daniel P. Berrange 
Date:   Tue Nov 18 14:50:05 2014 +

Add virXMLValidateAgainstSchema helper method

Add a helper method that can validate an XML document against
an RNG schema

commit c5b6a4a5cb5ae5cf387c363d84f4b7b21e7fc6fa
Author: Daniel P. Berrange 
Date:   Wed Nov 12 15:42:02 2014 +

Change int to size_t in size var for tap/vhost FDs

A number of methods take an int for a parameter that indicates
the size of an array. The correct type for array sizes is
size_t

commit d654bc419017cc7cb4376c0b93debfeb02511628
Author: Daniel P. Berrange 
Date:   Tue Nov 11 18:40:16 2014 +

Log dtrace/systemd probes at INFO level instead of DEBUG

Every dtrace/systemd probe also include a libvirt log message.
These are logged at level DEBUG currently, which means if you
want to see all probes they are drowned by the rest of the
DEBUG messages. Since we don't really use the INFO log level
for much, it seems reasonable to suggest we log all probes at
level INFO.

commit d83ce91fd4492c9267ffd2516dc24418b170a572
Author: Daniel P. Berrange 
Date:   Tue Nov 11 18:39:19 2014 +

Add systemd/dtrace probes for DBus APIs

When debugging libvirt it is helpful to set probes around RPC
calls. We already have probes for libvirt's native RPC layer,
so it makes sense to add them for the DBus RPC layer too.

commit 318df5a05f35ceda70822c5f56ac93e21bbfe691
Author: Daniel P. Berrange 
Date:   Tue Nov 11 17:38:43 2014 +

Add support for systemd-machined CreateMachineWithNetwork

systemd-machined introduced a new method CreateMachineWithNetwork
that obsoletes CreateMachine. It expects to be given a list of
VETH/TAP device indexes for the host side device(s) associated
with a container/machine.

This falls back to the old CreateMachine method when the new
one is not supported.

commit 503527919807b03c4e7b5bcf1aef92fa7b3eafb6
Author: Luyao Huang 
Date:   Tue Jan 13 10:15:52 2015 +0800

qemu: free priv->origname when qemuMigrationPrepareAny fails

Re: [Xen-devel] [libvirt] [PATCH v3 1/3] Add virXMLValidateAgainstSchema helper method

[Ian Campbell]

Hello,

On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> +#  define VIR_WARNINGS_NO_PRINTF \
> +_Pragma ("GCC diagnostic push") \
> +_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")

Xen automated tests are failing to build on all architectures with:

util/virxml.c: In function 'catchRNGError':
util/virxml.c:1094:9: error: unknown option after '#pragma GCC 
diagnostic' kind [-Werror=pragmas]

which I think must be down to one of these additions.

(helpful of gcc not to print the unknown option in question!)

test overview:
http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/
specific failure log:
http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/build-amd64-libvirt/5.ts-libvirt-build.log

We use Debian Wheezy's gcc, which is 4.6.3 AFAIK.

Cheers,
Ian.


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

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

[Julien Grall]

Hi Iurii,

On 16/01/15 12:50, Iurii Konovalenko wrote:
> From: Iurii Konovalenko 
> 
> Signed-off-by: Iurii Konovalenko 
> ---
>  xen/arch/arm/platforms/Makefile  |   1 +
>  xen/arch/arm/platforms/shmobile.c| 149 
> +++
>  xen/include/asm-arm/platforms/shmobile.h |  24 +

We are trying to avoid introduce new platform header. If you don't need
it in other files, please move the defines in the platform code.

[..]

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

The convention is to first include  then .

Futhermore, I think most of the includes are not necessary here.

The following includes should be enough:

#include 
#include 
#include 
#include 


> +
> +u32 shmobile_read_mode_pins(void)

static

> +{
> +static uint32_t mode;

Why the static here?

> +
> +void __iomem *modemr = ioremap_nocache(SHMOBILE_MODEMR, 4);

Missing a blank here between the variable declaration and the code.

> +if( !modemr )
> +{
> +dprintk( XENLOG_ERR, "Unable to map shmobile Mode MR\n");
> +return 0;
> +}
> +
> +mode = readl_relaxed(modemr);
> +iounmap(modemr);
> +
> +return mode;
> +}
> +
> +static int shmobile_init_time(void)

I know the other platform code doesn't do it. But this function is only
call during Xen boot. So it should be __init.

> +{
> +uint32_t freq;
> +void __iomem *tmu;
> +int extal_mhz = 0;
> +uint32_t mode = shmobile_read_mode_pins();
> +
> +/* At Linux boot time the Renesas R-Car Gen2 arch timer comes

The coding style for multiline comment block is:

/*
 * My comment
 * line 2
 */

> + * up with the counter disabled. Moreover, it may also report
> + * a potentially incorrect fixed 13 MHz frequency. To be
> + * correct these registers need to be updated to use the
> + * frequency EXTAL / 2 which can be determined by the MD pins.
> + */
> +
> +switch ( mode & (MD(14) | MD(13)) ) {

The coding style require the bracket to be on a separate line.


switch
{

> +case 0:
> +extal_mhz = 15;
> +break;
> +case MD(13):
> +extal_mhz = 20;
> +break;
> +case MD(14):
> +extal_mhz = 26;
> +break;
> +case MD(13) | MD(14):
> +extal_mhz = 30;
> +break;
> +}
> +
> +/* The arch timer frequency equals EXTAL / 2 */
> +freq = extal_mhz * (100 / 2);
> +
> +/* Remap "armgcnt address map" space */
> +tmu = ioremap_attr(SHMOBILE_ARCH_TIMER_BASE, PAGE_SIZE, 
> +PAGE_HYPERVISOR_NOCACHE);

ioremap_nocache

> +if ( !tmu )
> +{
> +dprintk(XENLOG_ERR, "Unable to map TMU\n");
> +return -ENOMEM;
> +}
> +/*
> + * Update the timer if it is either not running, or is not at the
> + * right frequency. The timer is only configurable in secure mode
> + * so this avoids an abort if the loader started the timer and
> + * entered the kernel in non-secure mode.
> + */
> +
> +if ( (readl_relaxed(tmu + SHMOBILE_ARCH_TIMER_CNTCR) & 1) == 0 ||
> +readl_relaxed(tmu + SHMOBILE_ARCH_TIMER_CNTFID0) != freq ) {

if
{

> +/* Update registers with correct frequency */
> +writel_relaxed(freq, tmu + SHMOBILE_ARCH_TIMER_CNTFID0);
> +
> +/* make sure arch timer is started by setting bit 0 of CNTCR */
> +writel_relaxed(1, tmu + SHMOBILE_ARCH_TIMER_CNTCR);
> +}

AFAIU, this code is based on the Linux version, right? If so some part
of the code differs from upstream:
- Linux is using iowrite32 (i.e writel on Xen)
- Linux is update CNTFRQ

Is there any reason that this code diverge?

> +
> +iounmap(tmu);
> +
> +return 0;
> +}
> +
> +static int __init shmobile_smp_init(void)
> +{
> +void __iomem *p;

Missing blank line here.

> +/* setup reset vectors */
> +p = ioremap_nocache(SHMOBILE_RAM, 0x1000);
> +if( !p )
> +{
> +dprintk( XENLOG_ERR, "Unable to map shmobile ICRAM\n");
> +return -ENOMEM;
> +}
> +
> +writel_relaxed(__pa(init_secondary), p + SHMOBILE_SMP_START_OFFSET);
> +iounmap(p);
> +
> +asm("sev;");

This sev can be reordered by the compiler. We have a macro sev() which
should avoid this issue.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [libvirt] [PATCH v3 1/3] Add virXMLValidateAgainstSchema helper method

[Daniel P. Berrange]

On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> Hello,
> 
> On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > +#  define VIR_WARNINGS_NO_PRINTF \
> > +_Pragma ("GCC diagnostic push") \
> > +_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
> 
> Xen automated tests are failing to build on all architectures with:
> 
> util/virxml.c: In function 'catchRNGError':
> util/virxml.c:1094:9: error: unknown option after '#pragma GCC 
> diagnostic' kind [-Werror=pragmas]
> 
> which I think must be down to one of these additions.
> 
> (helpful of gcc not to print the unknown option in question!)
> 
> test overview:
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/
> specific failure log:
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/build-amd64-libvirt/5.ts-libvirt-build.log
> 
> We use Debian Wheezy's gcc, which is 4.6.3 AFAIK.

The configure logs show

checking whether C compiler handles -Wsuggest-attribute=const... yes
checking whether C compiler handles -Wsuggest-attribute=format... no
checking whether C compiler handles -Wsuggest-attribute=noreturn... yes
checking whether C compiler handles -Wsuggest-attribute=pure... yes

So, can someone with a Debian machine check if it helps to modify

_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")

To be just

_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute\"")

THough, I guess some very old gcc might not support -Wsuggest-attribute
at all, so perhaps we need to check this fully

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

[Xen-devel] [PATCH v2 04/12] xen/arm: device: Rename device_type into device_match

[Julien Grall]

This enum was used for matching a specific device and not to get the
type of device.

Hence the name device_type will be used for another purpose later.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/device.c| 4 ++--
 xen/include/asm-arm/device.h | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 59e94c0..693b9af 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -40,7 +40,7 @@ static bool_t __init device_is_compatible(const struct 
device_desc *desc,
 return 0;
 }
 
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_match type,
const void *data)
 {
 const struct device_desc *desc;
@@ -67,7 +67,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_type type,
 return -EBADF;
 }
 
-enum device_type device_get_type(const struct dt_device_node *dev)
+enum device_match device_get_type(const struct dt_device_node *dev)
 {
 const struct device_desc *desc;
 
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 74a80c6..72a9028 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -4,7 +4,7 @@
 #include 
 #include 
 
-enum device_type
+enum device_match
 {
 DEVICE_SERIAL,
 DEVICE_IOMMU,
@@ -17,7 +17,7 @@ struct device_desc {
 /* Device name */
 const char *name;
 /* Device type */
-enum device_type type;
+enum device_match type;
 /* Array of device tree 'compatible' strings */
 const char *const *compatible;
 /* Device initialization */
@@ -32,7 +32,7 @@ struct device_desc {
  *
  *  Return 0 on success.
  */
-int __init device_init(struct dt_device_node *dev, enum device_type type,
+int __init device_init(struct dt_device_node *dev, enum device_match type,
const void *data);
 
 /**
@@ -41,7 +41,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_type type,
  *
  * Return the device type on success or DEVICE_ANY on failure
  */
-enum device_type device_get_type(const struct dt_device_node *dev);
+enum device_match device_get_type(const struct dt_device_node *dev);
 
 #define DT_DEVICE_START(_name, _namestr, _type) \
 static const struct device_desc __dev_desc_##_name __used   \
-- 
2.1.4


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

[Xen-devel] [PATCH v2 01/12] xen/arm: gic-v2: Change the device name in DT_DEVICE_START

[Julien Grall]

I'm not sure why a ':' has been added in the name... But none of the
other usages doesn't have it.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..f149e09 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -772,7 +772,7 @@ static const char * const gicv2_dt_compat[] __initconst =
 NULL
 };
 
-DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
+DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
 .compatible = gicv2_dt_compat,
 .init = gicv2_init,
 DT_DEVICE_END
-- 
2.1.4


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

[Xen-devel] [PATCH v2 02/12] xen/arm: vgic: Drop unecessary include asm/device.h

[Julien Grall]

The header asm/device.h has been included in the vgic code during
splitting to support multiple version. But no code within those files
requires it.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/vgic-v2.c | 1 -
 xen/arch/arm/vgic-v3.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 4dc2267..1ac46cc 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -26,7 +26,6 @@
 #include 
 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c738ca9..757ffd9 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.1.4


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

[Xen-devel] [PATCH v2 07/12] xen/iommu: Consolidate device assignment ops into a single set

[Julien Grall]

On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a 'device_t'.
Therefore there is no need to add separate ops.

The x86 iommu drivers has not been modified to replace 'struct pci_dev'
by "device_t" because the latter is an alias of the former.

Signed-off-by: Julien Grall 
CC: Jan Beulich 

---
Changes in v2:
- Use the newly type device_t
- It's not neccessary to modify the x86 iommu drivers
---
 xen/drivers/passthrough/device_tree.c |  5 +++--
 xen/drivers/passthrough/pci.c | 20 +++-
 xen/include/xen/iommu.h   | 17 ++---
 3 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/xen/drivers/passthrough/device_tree.c 
b/xen/drivers/passthrough/device_tree.c
index 3e47df5..377d41d 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -41,7 +41,7 @@ int iommu_assign_dt_device(struct domain *d, struct 
dt_device_node *dev)
 if ( !list_empty(&dev->domain_list) )
 goto fail;
 
-rc = hd->platform_ops->assign_dt_device(d, dev);
+rc = hd->platform_ops->assign_device(d, 0, dt_to_dev(dev));
 
 if ( rc )
 goto fail;
@@ -68,7 +68,8 @@ int iommu_deassign_dt_device(struct domain *d, struct 
dt_device_node *dev)
 
 spin_lock(&dtdevs_lock);
 
-rc = hd->platform_ops->reassign_dt_device(d, hardware_domain, dev);
+rc = hd->platform_ops->reassign_device(d, hardware_domain,
+   0, dt_to_dev(dev));
 if ( rc )
 goto fail;
 
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..71415d1 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1254,7 +1254,7 @@ int iommu_add_device(struct pci_dev *pdev)
 if ( !iommu_enabled || !hd->platform_ops )
 return 0;
 
-rc = hd->platform_ops->add_device(pdev->devfn, pdev);
+rc = hd->platform_ops->add_device(pdev->devfn, pci_to_dev(pdev));
 if ( rc || !pdev->phantom_stride )
 return rc;
 
@@ -1263,7 +1263,7 @@ int iommu_add_device(struct pci_dev *pdev)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 return 0;
-rc = hd->platform_ops->add_device(devfn, pdev);
+rc = hd->platform_ops->add_device(devfn, pci_to_dev(pdev));
 if ( rc )
 printk(XENLOG_WARNING "IOMMU: add %04x:%02x:%02x.%u failed (%d)\n",
pdev->seg, pdev->bus, PCI_SLOT(devfn), PCI_FUNC(devfn), rc);
@@ -1284,7 +1284,7 @@ int iommu_enable_device(struct pci_dev *pdev)
  !hd->platform_ops->enable_device )
 return 0;
 
-return hd->platform_ops->enable_device(pdev);
+return hd->platform_ops->enable_device(pci_to_dev(pdev));
 }
 
 int iommu_remove_device(struct pci_dev *pdev)
@@ -1306,7 +1306,7 @@ int iommu_remove_device(struct pci_dev *pdev)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 break;
-rc = hd->platform_ops->remove_device(devfn, pdev);
+rc = hd->platform_ops->remove_device(devfn, pci_to_dev(pdev));
 if ( !rc )
 continue;
 
@@ -1315,7 +1315,7 @@ int iommu_remove_device(struct pci_dev *pdev)
 return rc;
 }
 
-return hd->platform_ops->remove_device(pdev->devfn, pdev);
+return hd->platform_ops->remove_device(pdev->devfn, pci_to_dev(pdev));
 }
 
 /*
@@ -1376,7 +1376,7 @@ static int assign_device(struct domain *d, u16 seg, u8 
bus, u8 devfn)
 
 pdev->fault.count = 0;
 
-if ( (rc = hd->platform_ops->assign_device(d, devfn, pdev)) )
+if ( (rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev))) )
 goto done;
 
 for ( ; pdev->phantom_stride; rc = 0 )
@@ -1384,7 +1384,7 @@ static int assign_device(struct domain *d, u16 seg, u8 
bus, u8 devfn)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 break;
-rc = hd->platform_ops->assign_device(d, devfn, pdev);
+rc = hd->platform_ops->assign_device(d, devfn, pci_to_dev(pdev));
 if ( rc )
 printk(XENLOG_G_WARNING "d%d: assign %04x:%02x:%02x.%u failed 
(%d)\n",
d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
@@ -1419,7 +1419,8 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8 
devfn)
 devfn += pdev->phantom_stride;
 if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
 break;
-ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn, 
pdev);
+ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+pci_to_dev(pdev));
 if ( !ret )
 continue;
 
@@ -1429,7 +1430,8 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8 
devfn)
 }
 
 devfn = pdev->devfn;
-ret = hd->platfo

[Xen-devel] [PATCH v2 06/12] xen/arm: Introduce a generic way to describe device

[Julien Grall]

Currently, Xen is supporting PCI and Platform device (based on Device Tree).

While Xen only supports Platform device on ARM, Xen will gain support of
PCI soon.

Some drivers, such as IOMMU drivers, may handle PCI and platform device in
the same way. Only few lines of code differs.

Rather than requesting to provide 2 set of functions (one for PCI and
one for platform device), introduce a generic structure "device" which
is embedded in each specialized device.

As x86 only supports PCI, introduce a new type device_t which will be an
alias to pci_dev for this architecture. It will avoid to add a new field
for this place.

Signed-off-by: Julien Grall 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Andrew Cooper 

---
Changes in v2:
- As x86 will only support PCI, only introduce the generic
device on ARM
- Introduce a typedef device_t to be used in common code
- Drop the PCI code for ARM for now. It will be reintroduced
when PCI support will be added
- s#asm/device.h#xen/device.h# is not anymore needed
---
 xen/common/device.c   | 21 +
 xen/common/device_tree.c  |  3 +++
 xen/include/asm-arm/device.h  | 26 ++
 xen/include/asm-x86/device.h  | 25 +
 xen/include/xen/device_tree.h | 13 +
 xen/include/xen/iommu.h   |  1 +
 xen/include/xen/pci.h |  1 +
 7 files changed, 90 insertions(+)
 create mode 100644 xen/common/device.c
 create mode 100644 xen/include/asm-x86/device.h

diff --git a/xen/common/device.c b/xen/common/device.c
new file mode 100644
index 000..3450f20
--- /dev/null
+++ b/xen/common/device.c
@@ -0,0 +1,21 @@
+#include 
+#include 
+
+void device_initialize(struct device *dev, enum device_type type)
+{
+dev->type = type;
+
+#ifdef HAS_DEVICE_TREE
+if ( type == DEV_DT )
+dev->of_node = dev_to_dt(dev);
+#endif
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 34a1b9e..d1c716f 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1454,6 +1454,9 @@ static unsigned long __init unflatten_dt_node(const void 
*fdt,
 ((char *)pp->value)[sz - 1] = 0;
 dt_dprintk("fixed up name for %s -> %s\n", pathp,
(char *)pp->value);
+/* Generic device initialization */
+np->dev.type = DEV_DT;
+np->dev.of_node = np;
 }
 }
 if ( allnextpp )
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 72a9028..2fe4280 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -2,8 +2,34 @@
 #define __ASM_ARM_DEVICE_H
 
 #include 
+
+enum device_type
+{
+DEV_DT,
+};
+
+struct dev_archdata {
+void *iommu;/* IOMMU private data */
+};
+
+/* struct device - The basic device structure */
+struct device
+{
+enum device_type type;
+#ifdef HAS_DEVICE_TREE
+struct dt_device_node *of_node; /* Used by drivers imported from Linux */
+#endif
+struct dev_archdata archdata;
+};
+
+typedef struct device device_t;
+
 #include 
 
+/* TODO: Correctly implement dev_is_pci when PCI will be supported on ARM */
+#define dev_is_pci(dev) ((void)(dev), 0)
+#define dev_is_dt(dev)  ((dev->type == DEV_DT)
+
 enum device_match
 {
 DEVICE_SERIAL,
diff --git a/xen/include/asm-x86/device.h b/xen/include/asm-x86/device.h
new file mode 100644
index 000..a016112
--- /dev/null
+++ b/xen/include/asm-x86/device.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_X86_DEVICE_H
+#define __ASM_X86_DEVICE_H
+
+#include 
+
+/*
+ * x86 is only supported PCI. Therefore it's possible to directly use
+ * pci_dev to avoid adding new field.
+ */
+
+typedef struct pci_dev device_t;
+
+#define dev_is_pci(dev) ((void)(dev), 1)
+#define pci_to_dev(pci) (pci)
+
+#endif /* __ASM_X86_DEVICE_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 6502369..c8a0375 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -11,7 +11,9 @@
 #define __XEN_DEVICE_TREE_H__
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,8 +82,19 @@ struct dt_device_node {
 /* IOMMU specific fields */
 bool is_protected;
 struct list_head domain_list;
+
+struct device dev;
 };
 
+#define dt_to_dev(dt_node)  (&(dt_node)->dev)
+
+static inline struct dt_device_node *dev_to_dt(struct device *dev)
+{
+ASSERT(dev->type == DEV_DT);
+
+return container_of(dev, struct dt_device_node, dev);
+}
+
 #define MAX_PHANDLE_ARGS 16
 struct dt_phandle_args {
 struct dt_device_node *np;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..ecb2627 100644
--- a/xen/include/xen/iommu.h
+++

[Xen-devel] [PATCH v2 00/12] xen/arm: Resync the SMMU driver with the Linux one

[Julien Grall]

Hello,

The SMMU drivers has diverged from Linux. Having our own driver doesn't make
any benefits and make difficult to backport fixes and/or porting features such
as PCI.

With this series, the code of the SMMU drivers (copied from Linux) is mostly
not modified. If it's the case a comment /* Xen: ... */ has been added to
explain why.

To make the change obvious the resync of the SMMU code is made in several step
1) Revert the current SMMU driver (patch #5)
2) Import as it is the driver from Linux (patch #9)
3) Apply 2 fixes which are useful to correctly use the SATA with SMMU on
calxeda. I don't know why Linux didn't yet applied (patch #10-11)
4) Chanes for Xen (patch #12)

I also took the opportunity of the resync to consolidate the iommu ops in a
single set. When I added the IOMMU set to handle platform device passthrough (
ops assing_dt_device and reassign_dt_device), I didn't think about merging the
ops with the PCI one. In fact Linux is using a single set and have only few
lines per driver specific to each set (PCI or platform device).

A branch is available with all the changes:
git::/xenbits.xen.org/people/julieng/xen-unstable.git branch smmu-rework-v2

Major changes in v2:
- Introduce the generic struct to describe device on ARM. Alias it
to pci_dev on x86
- Defer the introduction of PCI in the generic device later

Regards,

Andreas Herrmann (2):
  xen/iommu: smmu: Check for duplicate stream IDs when registering
master devices
  xen/iommu: smmu: Introduce automatic stream-id-masking

Julien Grall (10):
  xen/arm: gic-v2: Change the device name in DT_DEVICE_START
  xen/arm: vgic: Drop unecessary include asm/device.h
  xen/dt: Extend dt_device_match to possibly store data
  xen/arm: device: Rename device_type into device_match
  xen/iommu: arm: Remove temporary the SMMU driver
  xen/arm: Introduce a generic way to describe device
  xen/iommu: Consolidate device assignment ops into a single set
  xen/arm: Describe device supported by a driver with dt_match_node
  xen/iommu: arm: Import the SMMU driver from Linux
  xen/iommu: smmu: Add Xen specific code to be able to use the driver

 xen/arch/arm/device.c |   25 +-
 xen/arch/arm/gic-v2.c |   12 +-
 xen/arch/arm/gic-v3.c |8 +-
 xen/arch/arm/platform.c   |2 +-
 xen/arch/arm/vgic-v2.c|1 -
 xen/arch/arm/vgic-v3.c|1 -
 xen/common/device.c   |   21 +
 xen/common/device_tree.c  |   15 +-
 xen/drivers/char/exynos4210-uart.c|8 +-
 xen/drivers/char/ns16550.c|   12 +-
 xen/drivers/char/omap-uart.c  |8 +-
 xen/drivers/char/pl011.c  |8 +-
 xen/drivers/passthrough/arm/smmu.c| 4115 +
 xen/drivers/passthrough/device_tree.c |5 +-
 xen/drivers/passthrough/pci.c |   20 +-
 xen/include/asm-arm/device.h  |   38 +-
 xen/include/asm-arm/gic.h |   15 +-
 xen/include/asm-x86/device.h  |   25 +
 xen/include/xen/device_tree.h |   19 +-
 xen/include/xen/iommu.h   |   18 +-
 xen/include/xen/pci.h |1 +
 21 files changed, 2781 insertions(+), 1596 deletions(-)
 create mode 100644 xen/common/device.c
 create mode 100644 xen/include/asm-x86/device.h

-- 
2.1.4


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

[Xen-devel] [PATCH v2 05/12] xen/iommu: arm: Remove temporary the SMMU driver

[Julien Grall]

The current SMMU driver has completly diverged. That makes me hard to
maintain.

Signed-off-by: Julien Grall 
---
 xen/drivers/passthrough/arm/Makefile |1 -
 xen/drivers/passthrough/arm/smmu.c   | 1784 --
 2 files changed, 1785 deletions(-)
 delete mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e..0484b79 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1 @@
 obj-y += iommu.o
-obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
deleted file mode 100644
index 42bde75..000
--- a/xen/drivers/passthrough/arm/smmu.c
+++ /dev/null
@@ -1,1784 +0,0 @@
-/*
- * IOMMU API for ARM architected SMMU implementations.
- *
- * 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, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- * Based on Linux drivers/iommu/arm-smmu.c (commit 89a23cd)
- * Copyright (C) 2013 ARM Limited
- *
- * Author: Will Deacon 
- *
- * Xen modification:
- * Julien Grall 
- * Copyright (C) 2014 Linaro Limited.
- *
- * This driver currently supports:
- *  - SMMUv1 and v2 implementations (didn't try v2 SMMU)
- *  - Stream-matching and stream-indexing
- *  - v7/v8 long-descriptor format
- *  - Non-secure access to the SMMU
- *  - 4k pages, p2m shared with the processor
- *  - Up to 40-bit addressing
- *  - Context fault reporting
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* Driver options */
-#define SMMU_OPT_SECURE_CONFIG_ACCESS   (1 << 0)
-
-/* Maximum number of stream IDs assigned to a single device */
-#define MAX_MASTER_STREAMIDSMAX_PHANDLE_ARGS
-
-/* Maximum stream ID */
-#define SMMU_MAX_STREAMIDS  (PAGE_SIZE_64K - 1)
-
-/* Maximum number of context banks per SMMU */
-#define SMMU_MAX_CBS128
-
-/* Maximum number of mapping groups per SMMU */
-#define SMMU_MAX_SMRS   128
-
-/* SMMU global address space */
-#define SMMU_GR0(smmu)  ((smmu)->base)
-#define SMMU_GR1(smmu)  ((smmu)->base + (smmu)->pagesize)
-
-/*
- * SMMU global address space with conditional offset to access secure aliases 
of
- * non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448, nsGFSYNR0: 0x450)
- */
-#define SMMU_GR0_NS(smmu)   \
-((smmu)->base + \
- ((smmu->options & SMMU_OPT_SECURE_CONFIG_ACCESS)\
-? 0x400 : 0))
-
-/* Page table bits */
-#define SMMU_PTE_PAGE   (((pteval_t)3) << 0)
-#define SMMU_PTE_CONT   (((pteval_t)1) << 52)
-#define SMMU_PTE_AF (((pteval_t)1) << 10)
-#define SMMU_PTE_SH_NS  (((pteval_t)0) << 8)
-#define SMMU_PTE_SH_OS  (((pteval_t)2) << 8)
-#define SMMU_PTE_SH_IS  (((pteval_t)3) << 8)
-
-#if PAGE_SIZE == PAGE_SIZE_4K
-#define SMMU_PTE_CONT_ENTRIES   16
-#elif PAGE_SIZE == PAGE_SIZE_64K
-#define SMMU_PTE_CONT_ENTRIES   32
-#else
-#define SMMU_PTE_CONT_ENTRIES   1
-#endif
-
-#define SMMU_PTE_CONT_SIZE  (PAGE_SIZE * SMMU_PTE_CONT_ENTRIES)
-#define SMMU_PTE_CONT_MASK  (~(SMMU_PTE_CONT_SIZE - 1))
-#define SMMU_PTE_HWTABLE_SIZE   (PTRS_PER_PTE * sizeof(pte_t))
-
-/* Stage-1 PTE */
-#define SMMU_PTE_AP_UNPRIV  (((pteval_t)1) << 6)
-#define SMMU_PTE_AP_RDONLY  (((pteval_t)2) << 6)
-#define SMMU_PTE_ATTRINDX_SHIFT 2
-#define SMMU_PTE_nG (((pteval_t)1) << 11)
-
-/* Stage-2 PTE */
-#define SMMU_PTE_HAP_FAULT  (((pteval_t)0) << 6)
-#define SMMU_PTE_HAP_READ   (((pteval_t)1) << 6)
-#define SMMU_PTE_HAP_WRITE  (((pteval_t)2) << 6)
-#define SMMU_PTE_MEMATTR_OIWB   (((pteval_t)0xf) << 2)
-#define SMMU_PTE_MEMATTR_NC (((pteval_t)0x5) << 2)
-#define SMMU_PTE_MEMATTR_DEV(((pteval_t)0x1) << 2)
-
-/* Configuration registers */
-#define SMMU_GR0_sCR0   0x0
-#define SMMU_sCR0_CLIENTPD  (1 << 0)
-#define SMMU_sCR0_GFRE  (1 << 1)
-#define SMMU_sCR0_GFIE  (1 << 2)
-#define SMMU_sCR0_GCFGFRE   (1 << 4)
-#define SMMU_sCR0_GCFGFIE   (1 << 5)
-#define SMMU_sCR0_USFCFG(1 << 10)
-#define SMMU_sCR0_VMIDPNE   (1 << 11)
-#define SMMU_sCR0_PTM   (1 << 12)
-#define SMMU_sCR0_FB(1 << 13)
-#define SMMU_sCR0_BSU_SHIFT 14
-#define SMMU_sCR0_BSU_MASK 

[Xen-devel] [PATCH v2 12/12] xen/iommu: smmu: Add Xen specific code to be able to use the driver

[Julien Grall]

The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.

To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own stuff and call Linux ones
- Only modify when required the code which comes from Linux. If so a
comment has been added with /* Xen: ... */ explaining why it's
necessary.

The support for PCI has been commented because it's not yet supported by
Xen ARM and therefore won't compile.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Add the ACCESS_ONCE definition in the drivers. The patch to
introduce the one in common code has been dropped.
- The include xen/device.h has been dropped in favor of
asm/device.h
---
 xen/drivers/passthrough/arm/Makefile |   1 +
 xen/drivers/passthrough/arm/smmu.c   | 678 +++
 2 files changed, 612 insertions(+), 67 deletions(-)

diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index 0484b79..f4cd26e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1 +1,2 @@
 obj-y += iommu.o
+obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 8a6514f..373eee8 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -18,6 +18,13 @@
  *
  * Author: Will Deacon 
  *
+ * Based on Linux drivers/iommu/arm-smmu.c
+ * => commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
+ *
+ * Xen modification:
+ * Julien Grall 
+ * Copyright (C) 2014 Linaro Limited.
+ *
  * This driver currently supports:
  * - SMMUv1 and v2 implementations
  * - Stream-matching and stream-indexing
@@ -28,26 +35,164 @@
  * - Context fault reporting
  */
 
-#define pr_fmt(fmt) "arm-smmu: " fmt
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Xen: The below defines are redefined within the file. Undef it */
+#undef SCTLR_AFE
+#undef SCTLR_TRE
+#undef SCTLR_M
+#undef TTBCR_EAE
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource
+{
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) (res)->size;
+
+#define platform_device dt_device_node
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   ret = dt_device_get_address(pdev, num, &res.addr, &res.size);
+
+   return ((ret) ? NULL : &res);
+
+   case IORESOURCE_IRQ:
+   ret = platform_get_irq(pdev, num);
+   if (ret < 0)
+   return NULL;
+
+   res.addr = ret;
+   res.size = 1;
+
+   return &res;
+
+   default:
+   return NULL;
+   }
+}
+
+/* Alias to Xen IRQ functions */
+#define request_irq(irq, func, flags, name, dev) request_irq(irq, flags, func, 
name, dev)
+#define free_irq release_irq
+
+/*
+ * Device logger functions
+ * TODO: Handle PCI
+ */
+#define dev_print(dev, lvl, fmt, ...)  
\
+printk(lvl "smmu: %s: " fmt, dt_node_full_name(dev_to_dt(dev)), ## 
__VA_ARGS__)
+
+#define dev_dbg(dev, fmt, ...) dev_print(dev, XENLOG_DEBUG, fmt, ## 
__VA_ARGS__)
+#define dev_notice(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
__VA_ARGS__)
+#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## 
__VA_ARGS__)
+#define dev_err(dev, fmt, ...) dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define dev_err_ratelimited(dev, fmt, ...) 
\
+dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
 
-#include 
+#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
 
-#include 

[Xen-devel] [PATCH v2 11/12] xen/iommu: smmu: Introduce automatic stream-id-masking

[Julien Grall]

From: Andreas Herrmann 

Try to determine mask/id values that match several stream IDs of a
master device when doing Stream ID matching. Thus the number of used
SMR groups that are required to map all stream IDs of a master device
to a context should be less than the number of SMR groups used so far
(currently one SMR group is used for one stream ID).

Taken from the Linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226100.html

Changes compare to the Linux ML version:
- _fls doesn't exist on Xen so use fls
- Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
This former is the field used to configure SRMS

Cc: Andreas Herrmann 
Signed-off-by: Andreas Herrmann 
Signed-off-by: Julien Grall 
---
 xen/drivers/passthrough/arm/smmu.c | 177 +
 1 file changed, 162 insertions(+), 15 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index bfc1069..8a6514f 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -346,8 +347,10 @@ struct arm_smmu_smr {
 };
 
 struct arm_smmu_master_cfg {
-   int num_streamids;
+   u32 num_streamids;
u16 streamids[MAX_MASTER_STREAMIDS];
+   int num_s2crs;
+
struct arm_smmu_smr *smrs;
 };
 
@@ -392,6 +395,9 @@ struct arm_smmu_device {
u32 num_context_irqs;
unsigned int*irqs;
 
+   u32 smr_mask_mask;
+   u32 smr_id_mask;
+
struct list_headlist;
struct rb_root  masters;
 };
@@ -1113,6 +1119,137 @@ static void arm_smmu_free_pgtables(struct 
arm_smmu_domain *smmu_domain)
kfree(pgd_base);
 }
 
+/*
+ * For a given set N of 2**order different stream IDs (no duplicates
+ * please!) we determine values mask and id such that
+ *
+ * (1)  (x & mask) == id
+ *
+ * for each stream ID x from the given set N.
+ *
+ * If the number of bits that are set in mask equals n, then there
+ * exist 2**n different values y for which
+ *
+ * (2)  (y & mask) == id
+ *
+ * Thus if n equals order we know that for the calculated mask and id
+ * values there are exactly 2**order == 2**n stream IDs for which (1)
+ * is true. And we finally can use mask and id to configure an SMR to
+ * match all stream IDs in the set N.
+ */
+static int determine_smr_mask(struct arm_smmu_device *smmu,
+ struct arm_smmu_master_cfg *cfg,
+ struct arm_smmu_smr *smr, int start, int order)
+{
+   u16 i, zero_bits_mask, one_bits_mask, const_mask;
+   int nr;
+
+   nr = 1 << order;
+
+   if (nr == 1) {
+   /* no mask, use streamid to match and be done with it */
+   smr->mask = 0;
+   smr->id = cfg->streamids[start];
+   return 0;
+   }
+
+   zero_bits_mask = 0;
+   one_bits_mask = 0x;
+   for (i = start; i < start + nr; i++) {
+   zero_bits_mask |= cfg->streamids[i];/* const 0 bits */
+   one_bits_mask &= cfg->streamids[i]; /* const 1 bits */
+   }
+   zero_bits_mask = ~zero_bits_mask;
+
+   /* bits having constant values (either 0 or 1) */
+   const_mask = zero_bits_mask | one_bits_mask;
+
+   i = hweight16(~const_mask);
+   if (i == order) {
+   /*
+* We have found a mask/id pair that matches exactly
+* nr = 2**order stream IDs which we used for its
+* calculation.
+*/
+   smr->mask = ~const_mask;
+   smr->id = one_bits_mask;
+   } else {
+   /*
+* No usable mask/id pair for this set of streamids.
+* If i > order then mask/id would match more than nr
+* streamids.
+* If i < order then mask/id would match less than nr
+* streamids. (In this case we potentially have used
+* some duplicate streamids for the calculation.)
+*/
+   return 1;
+   }
+
+   if (((smr->mask & smmu->smr_mask_mask) != smr->mask) ||
+   ((smr->id & smmu->smr_id_mask) != smr->id))
+   /* insufficient number of mask/id bits */
+   return 1;
+
+   return 0;
+}
+
+static int determine_smr_mapping(struct arm_smmu_device *smmu,
+struct arm_smmu_master_cfg *cfg,
+struct arm_smmu_smr *smrs, int max_smrs)
+{
+   int nr_sid, nr, i, bit, start;
+
+   /*
+* This function is called only once -- when a master is added
+* to a d

[Xen-devel] [PATCH v2 09/12] xen/iommu: arm: Import the SMMU driver from Linux

[Julien Grall]

Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3.

It's a basic copy of the Linux SMMU drivers code. No Xen code has yet been added
and not build.

Compare to the previous drivers it gains support of PCI. Though it will
need a bit of plumbing for Xen.

Signed-off-by: Julien Grall 

---
Chnages in v2:
- Fix typo in the Signed-off-by
---
 xen/drivers/passthrough/arm/smmu.c | 2193 
 1 file changed, 2193 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/smmu.c

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
new file mode 100644
index 000..6cd47b7
--- /dev/null
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -0,0 +1,2193 @@
+/*
+ * IOMMU API for ARM architected SMMU implementations.
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) 2013 ARM Limited
+ *
+ * Author: Will Deacon 
+ *
+ * This driver currently supports:
+ * - SMMUv1 and v2 implementations
+ * - Stream-matching and stream-indexing
+ * - v7/v8 long-descriptor format
+ * - Non-secure access to the SMMU
+ * - 4k and 64k pages, with contiguous pte hints.
+ * - Up to 48-bit addressing (dependent on VA_BITS)
+ * - Context fault reporting
+ */
+
+#define pr_fmt(fmt) "arm-smmu: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+/* Maximum number of stream IDs assigned to a single device */
+#define MAX_MASTER_STREAMIDS   MAX_PHANDLE_ARGS
+
+/* Maximum number of context banks per SMMU */
+#define ARM_SMMU_MAX_CBS   128
+
+/* Maximum number of mapping groups per SMMU */
+#define ARM_SMMU_MAX_SMRS  128
+
+/* SMMU global address space */
+#define ARM_SMMU_GR0(smmu) ((smmu)->base)
+#define ARM_SMMU_GR1(smmu) ((smmu)->base + (1 << (smmu)->pgshift))
+
+/*
+ * SMMU global address space with conditional offset to access secure
+ * aliases of non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448,
+ * nsGFSYNR0: 0x450)
+ */
+#define ARM_SMMU_GR0_NS(smmu)  \
+   ((smmu)->base + \
+   ((smmu->options & ARM_SMMU_OPT_SECURE_CFG_ACCESS)   \
+   ? 0x400 : 0))
+
+/* Page table bits */
+#define ARM_SMMU_PTE_XN(((pteval_t)3) << 53)
+#define ARM_SMMU_PTE_CONT  (((pteval_t)1) << 52)
+#define ARM_SMMU_PTE_AF(((pteval_t)1) << 10)
+#define ARM_SMMU_PTE_SH_NS (((pteval_t)0) << 8)
+#define ARM_SMMU_PTE_SH_OS (((pteval_t)2) << 8)
+#define ARM_SMMU_PTE_SH_IS (((pteval_t)3) << 8)
+#define ARM_SMMU_PTE_PAGE  (((pteval_t)3) << 0)
+
+#if PAGE_SIZE == SZ_4K
+#define ARM_SMMU_PTE_CONT_ENTRIES  16
+#elif PAGE_SIZE == SZ_64K
+#define ARM_SMMU_PTE_CONT_ENTRIES  32
+#else
+#define ARM_SMMU_PTE_CONT_ENTRIES  1
+#endif
+
+#define ARM_SMMU_PTE_CONT_SIZE (PAGE_SIZE * ARM_SMMU_PTE_CONT_ENTRIES)
+#define ARM_SMMU_PTE_CONT_MASK (~(ARM_SMMU_PTE_CONT_SIZE - 1))
+
+/* Stage-1 PTE */
+#define ARM_SMMU_PTE_AP_UNPRIV (((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_AP_RDONLY (((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_ATTRINDX_SHIFT2
+#define ARM_SMMU_PTE_nG(((pteval_t)1) << 11)
+
+/* Stage-2 PTE */
+#define ARM_SMMU_PTE_HAP_FAULT (((pteval_t)0) << 6)
+#define ARM_SMMU_PTE_HAP_READ  (((pteval_t)1) << 6)
+#define ARM_SMMU_PTE_HAP_WRITE (((pteval_t)2) << 6)
+#define ARM_SMMU_PTE_MEMATTR_OIWB  (((pteval_t)0xf) << 2)
+#define ARM_SMMU_PTE_MEMATTR_NC(((pteval_t)0x5) << 2)
+#define ARM_SMMU_PTE_MEMATTR_DEV   (((pteval_t)0x1) << 2)
+
+/* Configuration registers */
+#define ARM_SMMU_GR0_sCR0  0x0
+#define sCR0_CLIENTPD  (1 << 0)
+#define sCR0_GFRE  (1 << 1)
+#define sCR0_GFIE  (1 << 2)
+#define sCR0_GCFGFRE   (1 << 4)
+#define sCR0_GCFGFIE   (1 << 5)
+#define sCR0_USFCFG(1 << 10)
+#define sCR0_VMIDPNE   (1 << 11)
+#define sCR0_PTM   (1 << 12)
+#define sCR0_FB   

[Xen-devel] [PATCH v2 10/12] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices

[Julien Grall]

From: Andreas Herrmann 

If DT information lists one stream ID twice for the master devices of
an SMMU this can cause a multi match when stream ID matching is used.
For stream ID indexing this might trigger an overwrite of an S2CR that
is already in use.

So better check for duplicates when DT information is parsed.

Taken from the linux ML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html

Cc: Andreas Herrmann 
Signed-off-by: Andreas Herrmann 
Signed-off-by: Julien Grall 
---
 xen/drivers/passthrough/arm/smmu.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 6cd47b7..bfc1069 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -51,6 +51,9 @@
 /* Maximum number of stream IDs assigned to a single device */
 #define MAX_MASTER_STREAMIDS   MAX_PHANDLE_ARGS
 
+/* Maximum stream ID */
+#define ARM_SMMU_MAX_STREAMID  (SZ_64K - 1)
+
 /* Maximum number of context banks per SMMU */
 #define ARM_SMMU_MAX_CBS   128
 
@@ -519,7 +522,8 @@ static int insert_smmu_master(struct arm_smmu_device *smmu,
 
 static int register_smmu_master(struct arm_smmu_device *smmu,
struct device *dev,
-   struct of_phandle_args *masterspec)
+   struct of_phandle_args *masterspec,
+   unsigned long *smmu_sids)
 {
int i;
struct arm_smmu_master *master;
@@ -556,6 +560,12 @@ static int register_smmu_master(struct arm_smmu_device 
*smmu,
masterspec->np->name, smmu->num_mapping_groups);
return -ERANGE;
}
+
+   if (test_and_set_bit(streamid, smmu_sids)) {
+   dev_err(dev, "duplicate stream ID (%d)\n", streamid);
+   return -EEXIST;
+   }
+
master->cfg.streamids[i] = streamid;
}
return insert_smmu_master(smmu, master);
@@ -1977,6 +1987,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
struct device *dev = &pdev->dev;
struct rb_node *node;
struct of_phandle_args masterspec;
+   unsigned long *smmu_sids;
int num_irqs, i, err;
 
smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
@@ -2035,20 +2046,30 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
if (err)
return err;
 
+   smmu_sids = kzalloc(BITS_TO_LONGS(ARM_SMMU_MAX_STREAMID) *
+   sizeof(long), GFP_KERNEL);
+   if (!smmu_sids) {
+   dev_err(dev,
+   "failed to allocate bitmap for stream ID tracking\n");
+   return -ENOMEM;
+   }
+
i = 0;
smmu->masters = RB_ROOT;
while (!of_parse_phandle_with_args(dev->of_node, "mmu-masters",
   "#stream-id-cells", i,
   &masterspec)) {
-   err = register_smmu_master(smmu, dev, &masterspec);
+   err = register_smmu_master(smmu, dev, &masterspec, smmu_sids);
if (err) {
dev_err(dev, "failed to add master %s\n",
masterspec.np->name);
+   kfree(smmu_sids);
goto out_put_masters;
}
 
i++;
}
+   kfree(smmu_sids);
dev_notice(dev, "registered %d master devices\n", i);
 
parse_driver_options(smmu);
-- 
2.1.4


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

[Xen-devel] [PATCH v2 08/12] xen/arm: Describe device supported by a driver with dt_match_node

[Julien Grall]

Xen is currently using list a compatible string to know if the driver
can use device node. This leads to have double definition in the GIC
code.

Futhermore Linux drivers is using dt_match_node (actually called of_device_id
in Linux) to list device supported by the drivers.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/device.c  | 21 ++---
 xen/arch/arm/gic-v2.c  | 10 --
 xen/arch/arm/gic-v3.c  |  8 
 xen/drivers/char/exynos4210-uart.c |  8 
 xen/drivers/char/ns16550.c | 12 ++--
 xen/drivers/char/omap-uart.c   |  8 
 xen/drivers/char/pl011.c   |  8 
 xen/include/asm-arm/device.h   |  4 ++--
 xen/include/asm-arm/gic.h  | 15 +--
 9 files changed, 35 insertions(+), 59 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 693b9af..e4f4603 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -23,23 +23,6 @@
 
 extern const struct device_desc _sdevice[], _edevice[];
 
-static bool_t __init device_is_compatible(const struct device_desc *desc,
-  const struct dt_device_node *dev)
-{
-const char *const *compat;
-
-if ( !desc->compatible )
-return 0;
-
-for ( compat = desc->compatible; *compat; compat++ )
-{
-if ( dt_device_is_compatible(dev, *compat) )
-return 1;
-}
-
-return 0;
-}
-
 int __init device_init(struct dt_device_node *dev, enum device_match type,
const void *data)
 {
@@ -55,7 +38,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_match type,
 if ( desc->type != type )
 continue;
 
-if ( device_is_compatible(desc, dev) )
+if ( dt_match_node(desc->dt_match, dev) )
 {
 ASSERT(desc->init != NULL);
 
@@ -75,7 +58,7 @@ enum device_match device_get_type(const struct dt_device_node 
*dev)
 
 for ( desc = _sdevice; desc != _edevice; desc++ )
 {
-if ( device_is_compatible(desc, dev) )
+if ( dt_match_node(desc->dt_match, dev) )
 return desc->type;
 }
 
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index f149e09..34d622f 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -764,16 +764,14 @@ static int __init gicv2_init(struct dt_device_node *node, 
const void *data)
 return 0;
 }
 
-static const char * const gicv2_dt_compat[] __initconst =
+static const struct dt_device_match gicv2_dt_match[] __initconst =
 {
-DT_COMPAT_GIC_CORTEX_A15,
-DT_COMPAT_GIC_CORTEX_A7,
-DT_COMPAT_GIC_400,
-NULL
+DT_MATCH_GIC_V2,
+{ /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
-.compatible = gicv2_dt_compat,
+.dt_match = gicv2_dt_match,
 .init = gicv2_init,
 DT_DEVICE_END
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 076aa62..35f80b3 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1278,14 +1278,14 @@ static int __init gicv3_init(struct dt_device_node 
*node, const void *data)
 return res;
 }
 
-static const char * const gicv3_dt_compat[] __initconst =
+static const struct dt_device_match gicv3_dt_match[] __initconst =
 {
-DT_COMPAT_GIC_V3,
-NULL
+DT_MATCH_GIC_V3,
+{ /* sentinel */ },
 };
 
 DT_DEVICE_START(gicv3, "GICv3", DEVICE_GIC)
-.compatible = gicv3_dt_compat,
+.dt_match = gicv3_dt_match,
 .init = gicv3_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/exynos4210-uart.c 
b/xen/drivers/char/exynos4210-uart.c
index cba8729..bac1c2b 100644
--- a/xen/drivers/char/exynos4210-uart.c
+++ b/xen/drivers/char/exynos4210-uart.c
@@ -352,14 +352,14 @@ static int __init exynos4210_uart_init(struct 
dt_device_node *dev,
 return 0;
 }
 
-static const char * const exynos4210_dt_compat[] __initconst =
+static const struct dt_device_match exynos4210_dt_match[] __initconst =
 {
-"samsung,exynos4210-uart",
-NULL
+DT_MATCH_COMPATIBLE("samsung,exynos4210-uart"),
+{ /* sentinel */ },
 };
 
 DT_DEVICE_START(exynos4210, "Exynos 4210 UART", DEVICE_SERIAL)
-.compatible = exynos4210_dt_compat,
+.dt_match = exynos4210_dt_match,
 .init = exynos4210_uart_init,
 DT_DEVICE_END
 
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 161b251..d443880 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1185,16 +1185,16 @@ static int __init ns16550_uart_dt_init(struct 
dt_device_node *dev,
 return 0;
 }
 
-static const char * const ns16550_dt_compat[] __initconst =
+static const struct dt_device_match ns16550_dt_match[] __initconst =
 {
-"ns16550",
-"ns16550a",
-"snps,dw-apb-uart",
-NULL
+DT_MATCH_COMPATIBLE("ns16550"),
+DT_MATCH_COMPATIBLE("ns16550a"),
+DT_MATCH_COMPATIBLE("snps,dw-apb-uart"),
+{ /* sentinel */ },
 };
 
 DT_DEVICE_START(ns16550, "NS16550 U

[Xen-devel] [PATCH v2 03/12] xen/dt: Extend dt_device_match to possibly store data

[Julien Grall]

Some drivers may want to configure differently the device depending on
the compatible string.

Also modify the return type of dt_match_node to return the matching
structure.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/platform.c   |  2 +-
 xen/common/device_tree.c  | 12 ++--
 xen/include/xen/device_tree.h |  6 --
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..a79a098 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -157,7 +157,7 @@ bool_t platform_device_is_blacklisted(const struct 
dt_device_node *node)
 if ( platform && platform->blacklist_dev )
 blacklist = platform->blacklist_dev;
 
-return dt_match_node(blacklist, node);
+return (dt_match_node(blacklist, node) != NULL);
 }
 
 unsigned int platform_dom0_evtchn_ppi(void)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index f72b2e9..34a1b9e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -290,11 +290,12 @@ struct dt_device_node *dt_find_node_by_alias(const char 
*alias)
 return NULL;
 }
 
-bool_t dt_match_node(const struct dt_device_match *matches,
- const struct dt_device_node *node)
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+  const struct dt_device_node *node)
 {
 if ( !matches )
-return 0;
+return NULL;
 
 while ( matches->path || matches->type ||
 matches->compatible || matches->not_available )
@@ -314,12 +315,11 @@ bool_t dt_match_node(const struct dt_device_match 
*matches,
 match &= !dt_device_is_available(node);
 
 if ( match )
-return match;
-
+return matches;
 matches++;
 }
 
-return 0;
+return NULL;
 }
 
 const struct dt_device_node *dt_get_parent(const struct dt_device_node *node)
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 08db8bc..6502369 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -28,6 +28,7 @@ struct dt_device_match {
 const char *type;
 const char *compatible;
 const bool_t not_available;
+const void *data;
 };
 
 #define DT_MATCH_PATH(p){ .path = p }
@@ -547,8 +548,9 @@ bool_t dt_device_is_available(const struct dt_device_node 
*device);
  *
  * Returns true if the device node match one of dt_device_match.
  */
-bool_t dt_match_node(const struct dt_device_match *matches,
- const struct dt_device_node *node);
+const struct dt_device_match *
+dt_match_node(const struct dt_device_match *matches,
+  const struct dt_device_node *node);
 
 /**
  * dt_find_matching_node - Find a node based on an dt_device_match match table
-- 
2.1.4


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

[Xen-devel] [PATCH linux-2.6.18] xen: dont use bitfields for indicators modified under different locks

[Juergen Gross]

It is no good idea to have bitfields in the same byte which are modified
with different locks held (or, in this case, one with lock and one
without). Use at least bytes for this purpose.

Signed-off-by: Juergen Gross 

diff -r 3feb5ddb5434 drivers/xen/scsifront/common.h
--- a/drivers/xen/scsifront/common.hWed Jan 14 12:05:46 2015 +0100
+++ b/drivers/xen/scsifront/common.hFri Jan 16 15:18:35 2015 +0100
@@ -113,8 +113,8 @@ struct vscsifrnt_info {
struct task_struct *kthread;
wait_queue_head_t wq;
wait_queue_head_t wq_sync;
-   unsigned int waiting_resp:1;
-   unsigned int waiting_sync:1;
+   unsigned char waiting_resp;
+   unsigned char waiting_sync;
 };
 
 #define DPRINTK(_f, _a...) \

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

[Xen-devel] Xen Project Developer Summit, Seattle, Aug 17-18 (CfP open)

[Lars Kurth]

Hi everyone,
I just wanted to let you know that 
a) the website for the developer summit is up and running now : 
http://events.linuxfoundation.org/events/xen-project-developer-summit/
b) the CfP is also open now at 
http://events.linuxfoundation.org/events/xen-project-developer-summit/program/cfp
 (deadline: May 1st)
Regards
Lars
 ___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [rumpuserxen test] 33416: regressions - FAIL [and 1 more messages]

[Antti Kantee]

On 16/01/15 11:17, Ian Jackson wrote:

The latter is the GPF turning out to be unreproducible.

I guess we should keep an eye out in case it turns out to be a race
rather than a cosmic ray.


I do not believe in cosmic rays.

Some notes in case it resurfaces:

1) the topmost caller address appears to be on the stack (??)

2) "calling main()" seems to be output properly, the next line ("running 
demos") doesn't.  there is exactly one function call (~20 instructions) 
between these two lines


3) the first printf goes to stderr, while the second, supposedly failing 
one, goes to stdout (no idea why)


4) it's crashing calling fp->_swrite().  notably, the execution of 
__sflush() might or might not go that far if fp upon entry points to 
garbage (existing garbage, not page faulting garbage)


5) the call is made as:
   6018b:   41 ff 54 24 50  callq  *0x50(%r12)

from the output:
R12: e02b
(e02b is somewhere in the middle of xenbus_xb_write, highly unlikely to 
be relevant, more likely to be some random garbage)


from the image:
rump-kernel$ nm rump-kernel  | grep __sF
00299d60 D __sF
(stdout is __sF[1])

There are no (user) threads active yet.  I currently have no theories 
how the failure is reachable, at least assuming that the console output 
is accurate.  I still don't believe in cosmic rays, though ;)


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

Re: [Xen-devel] [libvirt] [PATCH v3 1/3] Add virXMLValidateAgainstSchema helper method

[Ian Campbell]

On Fri, 2015-01-16 at 14:19 +, Daniel P. Berrange wrote:
> On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> > Hello,
> > 
> > On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > > +#  define VIR_WARNINGS_NO_PRINTF \
> > > +_Pragma ("GCC diagnostic push") \
> > > +_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
> > 
> > Xen automated tests are failing to build on all architectures with:
> > 
> > util/virxml.c: In function 'catchRNGError':
> > util/virxml.c:1094:9: error: unknown option after '#pragma GCC 
> > diagnostic' kind [-Werror=pragmas]
> > 
> > which I think must be down to one of these additions.
> > 
> > (helpful of gcc not to print the unknown option in question!)
> > 
> > test overview:
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/
> > specific failure log:
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/build-amd64-libvirt/5.ts-libvirt-build.log
> > 
> > We use Debian Wheezy's gcc, which is 4.6.3 AFAIK.
> 
> The configure logs show
> 
> checking whether C compiler handles -Wsuggest-attribute=const... yes
> checking whether C compiler handles -Wsuggest-attribute=format... no
> checking whether C compiler handles -Wsuggest-attribute=noreturn... yes
> checking whether C compiler handles -Wsuggest-attribute=pure... yes
> 
> So, can someone with a Debian machine check if it helps to modify
> 
> _Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
> 
> To be just
> 
> _Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute\"")

I'm afraid it doesn't seem to. Specifically:
diff --git a/src/internal.h b/src/internal.h
index 9855c49..508f8b5 100644
--- a/src/internal.h
+++ b/src/internal.h
@@ -236,7 +236,7 @@
 _Pragma ("GCC diagnostic ignored \"-Wcast-align\"")
 #  define VIR_WARNINGS_NO_PRINTF \
 _Pragma ("GCC diagnostic push") \
-_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
+_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute\"")
 
 #  define VIR_WARNINGS_RESET \
 _Pragma ("GCC diagnostic pop")

Didn't help.

According to
https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Warning-Options.html#Warning-Options
 the valid -Wsuggest-attributes=FOO in that version are pure const and noreturn.

=format seems to have arrived in 4.8, FWIW.

Ian.



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

Re: [Xen-devel] [PATCH v2 06/12] xen/arm: Introduce a generic way to describe device

[Jan Beulich]

>>> On 16.01.15 at 15:24,  wrote:
> ---
>  xen/common/device.c   | 21 +
>  xen/common/device_tree.c  |  3 +++

Is there a Makefile change missing here?

> --- /dev/null
> +++ b/xen/common/device.c
> @@ -0,0 +1,21 @@
> +#include 
> +#include 
> +
> +void device_initialize(struct device *dev, enum device_type type)
> +{
> +dev->type = type;
> +
> +#ifdef HAS_DEVICE_TREE
> +if ( type == DEV_DT )
> +dev->of_node = dev_to_dt(dev);
> +#endif
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 34a1b9e..d1c716f 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -1454,6 +1454,9 @@ static unsigned long __init unflatten_dt_node(const 
> void *fdt,
>  ((char *)pp->value)[sz - 1] = 0;
>  dt_dprintk("fixed up name for %s -> %s\n", pathp,
> (char *)pp->value);
> +/* Generic device initialization */
> +np->dev.type = DEV_DT;
> +np->dev.of_node = np;

Why is this not device_initialize(&np->dev, DEV_DT)?

> --- /dev/null
> +++ b/xen/include/asm-x86/device.h
> @@ -0,0 +1,25 @@
> +#ifndef __ASM_X86_DEVICE_H
> +#define __ASM_X86_DEVICE_H
> +
> +#include 
> +
> +/*
> + * x86 is only supported PCI. Therefore it's possible to directly use

x86 only supports ...

Jan


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

Re: [Xen-devel] [PATCH v2 06/12] xen/arm: Introduce a generic way to describe device

[Julien Grall]

Hi Jan,

On 16/01/15 14:59, Jan Beulich wrote:
 On 16.01.15 at 15:24,  wrote:
>> ---
>>  xen/common/device.c   | 21 +
>>  xen/common/device_tree.c  |  3 +++
> 
> Is there a Makefile change missing here?

No. The file common/device.c should not be there. I drop for my tree but
somehow it stay in the patch. Sorry.

[..]

>> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
>> index 34a1b9e..d1c716f 100644
>> --- a/xen/common/device_tree.c
>> +++ b/xen/common/device_tree.c
>> @@ -1454,6 +1454,9 @@ static unsigned long __init unflatten_dt_node(const 
>> void *fdt,
>>  ((char *)pp->value)[sz - 1] = 0;
>>  dt_dprintk("fixed up name for %s -> %s\n", pathp,
>> (char *)pp->value);
>> +/* Generic device initialization */
>> +np->dev.type = DEV_DT;
>> +np->dev.of_node = np;
> 
> Why is this not device_initialize(&np->dev, DEV_DT)?

Because the file containing the function has been dropped. It's a
left-over of the previous version.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [libvirt] [PATCH v3 1/3] Add virXMLValidateAgainstSchema helper method

[Daniel P. Berrange]

On Fri, Jan 16, 2015 at 02:47:42PM +, Ian Campbell wrote:
> On Fri, 2015-01-16 at 14:19 +, Daniel P. Berrange wrote:
> > On Fri, Jan 16, 2015 at 01:58:27PM +, Ian Campbell wrote:
> > > Hello,
> > > 
> > > On Tue, 2015-01-13 at 17:00 +, Daniel P. Berrange wrote:
> > > > +#  define VIR_WARNINGS_NO_PRINTF \
> > > > +_Pragma ("GCC diagnostic push") \
> > > > +_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
> > > 
> > > Xen automated tests are failing to build on all architectures with:
> > > 
> > > util/virxml.c: In function 'catchRNGError':
> > > util/virxml.c:1094:9: error: unknown option after '#pragma GCC 
> > > diagnostic' kind [-Werror=pragmas]
> > > 
> > > which I think must be down to one of these additions.
> > > 
> > > (helpful of gcc not to print the unknown option in question!)
> > > 
> > > test overview:
> > > http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/
> > > specific failure log:
> > > http://www.chiark.greenend.org.uk/~xensrcts/logs/33443/build-amd64-libvirt/5.ts-libvirt-build.log
> > > 
> > > We use Debian Wheezy's gcc, which is 4.6.3 AFAIK.
> > 
> > The configure logs show
> > 
> > checking whether C compiler handles -Wsuggest-attribute=const... yes
> > checking whether C compiler handles -Wsuggest-attribute=format... no
> > checking whether C compiler handles -Wsuggest-attribute=noreturn... yes
> > checking whether C compiler handles -Wsuggest-attribute=pure... yes
> > 
> > So, can someone with a Debian machine check if it helps to modify
> > 
> > _Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
> > 
> > To be just
> > 
> > _Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute\"")
> 
> I'm afraid it doesn't seem to. Specifically:
> diff --git a/src/internal.h b/src/internal.h
> index 9855c49..508f8b5 100644
> --- a/src/internal.h
> +++ b/src/internal.h
> @@ -236,7 +236,7 @@
>  _Pragma ("GCC diagnostic ignored \"-Wcast-align\"")
>  #  define VIR_WARNINGS_NO_PRINTF \
>  _Pragma ("GCC diagnostic push") \
> -_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute=format\"")
> +_Pragma ("GCC diagnostic ignored \"-Wsuggest-attribute\"")
>  
>  #  define VIR_WARNINGS_RESET \
>  _Pragma ("GCC diagnostic pop")
> 
> Didn't help.
> 
> According to
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Warning-Options.html#Warning-Options
>  the valid -Wsuggest-attributes=FOO in that version are pure const and 
> noreturn.
> 
> =format seems to have arrived in 4.8, FWIW.

I just copied you on an alternative patch that would hopefully fix
it - I explicitly check if suggest-attribute=format exists in the
gcc version used.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [Xen-devel] [PATCH v2 07/12] xen/iommu: Consolidate device assignment ops into a single set

[Jan Beulich]

>>> On 16.01.15 at 15:24,  wrote:
> On ARM, the way to assign device tree node is exactly the same as PCI.
> Futhermore, all devices can be represented by a 'device_t'.
> Therefore there is no need to add separate ops.
> 
> The x86 iommu drivers has not been modified to replace 'struct pci_dev'
> by "device_t" because the latter is an alias of the former.
> 
> Signed-off-by: Julien Grall 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] Using Libvirtd with virt-manager on aarch64

[Stefano Stabellini]

Hello Manish,
recently Clark Laughlin (CC'ed) got OpenStack, libvirt and Xen all
working together on ARM.  He wrote the following wiki page:

https://wiki.linaro.org/OpenStack/DevstackOnXenARM

Cheers,

Stefano

On Fri, 16 Jan 2015, Jaggi, Manish wrote:
> Hi Jim,
> 
> 
> I am trying to run libvirtd / virsh / virt-manager on aarch64 platform 
> (Cavium thunderX).
> 
> Am able to build from the git and able to connect virsh with xen:/// but am 
> not able to get the output of list.
> 
> vish nodeinfo command is working.
> 
> 
> ​Saw  patches in the git log 
> - Add support for parsing/formating Xen XL config
> - tests: Tests for the xen-xl parser
> 
> Could you please help with the steps / pointers to run virsh / virt-manager 
> with libvirtd. 
> ​-Regards
> Manish
> 
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Iurii Konovalenko]

Hi, Julien.

On Fri, Jan 16, 2015 at 4:08 PM, Julien Grall 
wrote:
> Hi Iurii,
>
> On 16/01/15 12:50, Iurii Konovalenko wrote:
>> From: Iurii Konovalenko 
>>
>> Signed-off-by: Iurii Konovalenko 
>> ---
>>  xen/arch/arm/platforms/Makefile  |   1 +
>>  xen/arch/arm/platforms/shmobile.c| 149
+++
>>  xen/include/asm-arm/platforms/shmobile.h |  24 +
>
> We are trying to avoid introduce new platform header. If you don't need
> it in other files, please move the defines in the platform code.

No problem, will move all defines to shmobile.c.

>
> [..]
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> The convention is to first include  then .
>
> Futhermore, I think most of the includes are not necessary here.
>
> The following includes should be enough:
>
> #include 
> #include 
> #include 
> #include 
>

Yes, sure. Will fix it.

>
>> +
>> +u32 shmobile_read_mode_pins(void)
>
> static

OK, will add it.

>
>> +{
>> +static uint32_t mode;
>
> Why the static here?

Sorry, migrated here as static from Linux kernel. Will fix it.

>
>> +
>> +void __iomem *modemr = ioremap_nocache(SHMOBILE_MODEMR, 4);
>
> Missing a blank here between the variable declaration and the code.

OK

>
>> +if( !modemr )
>> +{
>> +dprintk( XENLOG_ERR, "Unable to map shmobile Mode MR\n");
>> +return 0;
>> +}
>> +
>> +mode = readl_relaxed(modemr);
>> +iounmap(modemr);
>> +
>> +return mode;
>> +}
>> +
>> +static int shmobile_init_time(void)
>
> I know the other platform code doesn't do it. But this function is only
> call during Xen boot. So it should be __init.

I used xen/arch/arm/platforms/omap5.c file as a reference. In that file
this function has no such attribute.
But I agree with you and will add this attribute.

>
>> +{
>> +uint32_t freq;
>> +void __iomem *tmu;
>> +int extal_mhz = 0;
>> +uint32_t mode = shmobile_read_mode_pins();
>> +
>> +/* At Linux boot time the Renesas R-Car Gen2 arch timer comes
>
> The coding style for multiline comment block is:
>
> /*
>  * My comment
>  * line 2
>  */
>

OK, will fix it.

>> + * up with the counter disabled. Moreover, it may also report
>> + * a potentially incorrect fixed 13 MHz frequency. To be
>> + * correct these registers need to be updated to use the
>> + * frequency EXTAL / 2 which can be determined by the MD pins.
>> + */
>> +
>> +switch ( mode & (MD(14) | MD(13)) ) {
>
> The coding style require the bracket to be on a separate line.
>
>
> switch
> {
>

OK, will fix it.

>> +case 0:
>> +extal_mhz = 15;
>> +break;
>> +case MD(13):
>> +extal_mhz = 20;
>> +break;
>> +case MD(14):
>> +extal_mhz = 26;
>> +break;
>> +case MD(13) | MD(14):
>> +extal_mhz = 30;
>> +break;
>> +}
>> +
>> +/* The arch timer frequency equals EXTAL / 2 */
>> +freq = extal_mhz * (100 / 2);
>> +
>> +/* Remap "armgcnt address map" space */
>> +tmu = ioremap_attr(SHMOBILE_ARCH_TIMER_BASE, PAGE_SIZE,
>> +PAGE_HYPERVISOR_NOCACHE);
>
> ioremap_nocache
>

OK, will use this API.

>> +if ( !tmu )
>> +{
>> +dprintk(XENLOG_ERR, "Unable to map TMU\n");
>> +return -ENOMEM;
>> +}
>> +/*
>> + * Update the timer if it is either not running, or is not at the
>> + * right frequency. The timer is only configurable in secure mode
>> + * so this avoids an abort if the loader started the timer and
>> + * entered the kernel in non-secure mode.
>> + */
>> +
>> +if ( (readl_relaxed(tmu + SHMOBILE_ARCH_TIMER_CNTCR) & 1) == 0 ||
>> +readl_relaxed(tmu + SHMOBILE_ARCH_TIMER_CNTFID0) != freq ) {
>
> if
> {
>

OK, will fix it.

>> +/* Update registers with correct frequency */
>> +writel_relaxed(freq, tmu + SHMOBILE_ARCH_TIMER_CNTFID0);
>> +
>> +/* make sure arch timer is started by setting bit 0 of CNTCR */
>> +writel_relaxed(1, tmu + SHMOBILE_ARCH_TIMER_CNTCR);
>> +}
>
> AFAIU, this code is based on the Linux version, right? If so some part
> of the code differs from upstream:
> - Linux is using iowrite32 (i.e writel on Xen)

Agree, I will use writel/readl API

> - Linux is update CNTFRQ
>
> Is there any reason that this code diverge?
>

Linux kernel 3.14-ltsi, which I used as a reference, use CNTFID0
in file arch/arm/mach-shmobile/setup-rcar-gen2.c:
iowrite32(freq, base + CNTFID0);

>> +
>> +iounmap(tmu);
>> +
>> +return 0;
>> +}
>> +
>> +static int __init shmobile_smp_init(void)
>> +{
>> +void __iomem *p;
>
> Missing blank line here.
>

OK, will fix it.

>> +/* setup reset vectors */
>> +p = ioremap_nocache(SHMOBILE_RAM, 0x1000);
>> +if( !p )
>> +{
>> +dprintk( XENLOG_ERR, "Unable to map shmobile ICRAM\n");
>> +return -ENOMEM;
>> +}
>> +
>> +writel_

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

[Julien Grall]

On 16/01/15 15:29, Iurii Konovalenko wrote:
>> Is there any reason that this code diverge?
>>
> 
> Linux kernel 3.14-ltsi, which I used as a reference, use CNTFID0
> in file arch/arm/mach-shmobile/setup-rcar-gen2.c:
> iowrite32(freq, base + CNTFID0);

Which seems different from upstream:

1. /* Update registers with correct frequency */
2. iowrite32(freq, base + CNTFID0);
3. asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
4.
5. /* make sure arch timer is started by setting bit 0 of CNTCR */
6. iowrite32(1, base + CNTCR);

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [Qemu-devel] [v3 4/5] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backen.

[Xu, Quan]

> -Original Message-
> From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
> Sent: Thursday, January 15, 2015 11:49 PM
> To: Xu, Quan; qemu-de...@nongnu.org
> Cc: stefano.stabell...@eu.citrix.com; xen-devel@lists.xen.org
> Subject: Re: [Qemu-devel] [v3 4/5] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms
> backen.
> 
> On 12/30/2014 06:03 PM, Quan Xu wrote:
> > This Patch provides the glue for the TPM_TIS(Qemu frontend) to Xen
> > stubdom vTPM domain that provides the actual TPM functionality. It
> > sends data and TPM commends with xen_vtpm_frontend. It is similar as
> > another two vTPM backens:
> >*vTPM passthrough backen Since QEMU 1.5.
> >*vTPM libtpms-based backen.
> >
> > Some details:
> > This part of the patch provides support for the spawning of a thread
> > that will interact with stubdom vTPM domain by the xen_vtpm_frontend.
> > It expects a signal from the frontend to wake and pick up the TPM
> > command that is supposed to be processed and delivers the response
> > packet using a callback function provided by the frontend.
> >
> > The backend connects itself to the frontend by filling out an
> > interface structure with pointers to the function implementing support
> > for various operations.
> >
> > (QEMU) vTPM XenStubdoms backen is initialized by Qemu command line
> options,
> >"-tpmdev xenstubdoms,id=xenvtpm0 -device
> tpm-tis,tpmdev=xenvtpm0"
> >
> > --Changes in v3:
> > -Call vtpm_send() and vtpm_recv() directly.
> >
> > Signed-off-by: Quan Xu 
> > ---
> >   hw/tpm/Makefile.objs |   2 +-
> >   hw/tpm/tpm_xenstubdoms.c | 245
> +++
> >   2 files changed, 246 insertions(+), 1 deletion(-)
> >   create mode 100644 hw/tpm/tpm_xenstubdoms.c
> >
> > diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs index
> > 57919fa..190e776 100644
> > --- a/hw/tpm/Makefile.objs
> > +++ b/hw/tpm/Makefile.objs
> > @@ -1,3 +1,3 @@
> >   common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
> >   common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
> > -common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_vtpm_frontend.o
> > +common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o
> > +xen_vtpm_frontend.o
> > diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c new
> > file mode 100644 index 000..98ea496
> > --- /dev/null
> > +++ b/hw/tpm/tpm_xenstubdoms.c
> > @@ -0,0 +1,245 @@
> > +/*
> > + * Xen Stubdom vTPM driver
> > + *
> > + *  Copyright (c) 2014 Intel Corporation
> > + *  Authors:
> > + *Quan Xu 
> > + *
> > + * This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2 of the License, or (at your option) any later version.
> > + *
> > + * This library 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
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with this library; if not, see
> > +  */
> > +
> > +#include 
> > +#include "qemu-common.h"
> > +#include "qapi/error.h"
> > +#include "qemu/sockets.h"
> > +#include "qemu/log.h"
> > +#include "sysemu/tpm_backend.h"
> > +#include "tpm_int.h"
> > +#include "hw/hw.h"
> > +#include "hw/i386/pc.h"
> > +#include "hw/xen/xen_backend.h"
> > +#include "sysemu/tpm_backend_int.h"
> > +#include "tpm_tis.h"
> > +
> > +#ifdef DEBUG_TPM
> > +#define DPRINTF(fmt, ...) \
> > +do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0) #else
> > +#define DPRINTF(fmt, ...) \
> > +do { } while (0)
> > +#endif
> > +
> > +#define TYPE_TPM_XENSTUBDOMS "tpm-xenstubdoms"
> > +#define TPM_XENSTUBDOMS(obj) \
> > +OBJECT_CHECK(TPMXenstubdomsState, (obj),
> TYPE_TPM_XENSTUBDOMS)
> > +
> > +static const TPMDriverOps tpm_xenstubdoms_driver;
> > +
> > +/* data structures */
> > +typedef struct TPMXenstubdomsThreadParams {
> > +TPMState *tpm_state;
> > +TPMRecvDataCB *recv_data_callback;
> > +TPMBackend *tb;
> > +} TPMXenstubdomsThreadParams;
> > +
> > +struct TPMXenstubdomsState {
> > +TPMBackend parent;
> > +TPMBackendThread tbt;
> > +TPMXenstubdomsThreadParams tpm_thread_params;
> > +bool had_startup_error;
> > +};
> > +
> > +typedef struct TPMXenstubdomsState TPMXenstubdomsState;
> > +
> > +/* functions */
> > +
> > +static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
> > +
> > +static int tpm_xenstubdoms_unix_transfer(const TPMLocality
> > +*locty_data) {
> > +size_t rlen;
> > +struct XenDevice *xendev;
> > +
> > +xendev = xen_be_find_xendev("vtpm", xen_domid, 0);
> > +if (xendev == NULL) {
> > +xen_be_printf(xendev, 0, "Con not find vtpm device\n");
> > +return -1;
> > +}
> > +vtpm_send(xendev, loc

Re: [Xen-devel] [PATCH v1 2/3] xen/arm: Add new driver for R-Car Gen2 UART

[Oleksandr Tyshchenko]

On Fri, Jan 16, 2015 at 3:19 PM, Julien Grall 
wrote:

> Hi Iurii,
>
Hi Julien

>
> On 16/01/15 12:50, Iurii Konovalenko wrote:
> > +static int __init rcar2_uart_init(struct dt_device_node *dev,
> > + const void *data)
> > +{
> > +const char *config = data;
> > +struct rcar2_uart *uart;
> > +int res;
> > +u64 addr, size;
> > +
> > +if ( strcmp(config, "") )
> > +printk("WARNING: UART configuration is not supported\n");
> > +
> > +uart = &rcar2_com;
> > +
> > +uart->clock_hz  = SCIF_CLK_FREQ;
> > +uart->baud  = BAUD_AUTO;
> > +uart->data_bits = 8;
> > +uart->parity= PARITY_NONE;
> > +uart->stop_bits = 1;
> > +
> > +res = dt_device_get_address(dev, 0, &addr, &size);
> > +if ( res )
> > +{
> > +printk("rcar2-uart: Unable to retrieve the base"
> > + " address of the UART\n");
> > +return res;
> > +}
> > +
> > +uart->regs = ioremap_attr(addr, size, PAGE_HYPERVISOR_NOCACHE);
>
> Please use ioremap_nocache
>
ok

>
> --
> Julien Grall
>



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Boris Ostrovsky]

On 01/07/2015 04:12 AM, Jan Beulich wrote:

On 06.01.15 at 14:41,  wrote:

On 06/01/15 02:18, Boris Ostrovsky wrote:

Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.

There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient

Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the fact
that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.

Signed-off-by: Boris Ostrovsky 

If we are going to change the hypercall, then can we see about making it
a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
components which might want/need access to this information.  (i.e. I am
still looking for a reasonable way to get this information from Xen in
hwloc)

In which case leaving the sysctl alone and just adding a new non-sysctl
interface should be considered.


(Sorry for late reply)

Would a platform op be an option here or do you prefer a whole new 
hypercall?


-boris

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

[Xen-devel] [PATCH] Switch QEMU_UPSTREAM_REVISION back to master

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 

diff --git a/Config.mk b/Config.mk
index 0e22057..4745b85 100644
--- a/Config.mk
+++ b/Config.mk
@@ -252,7 +252,7 @@ QEMU_TRADITIONAL_URL ?= 
git://xenbits.xen.org/qemu-xen-unstable.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
-QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc4
+QEMU_UPSTREAM_REVISION ?= master
 SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
 # Thu May 22 16:59:16 2014 -0400
 # python3 fixes for vgabios and csm builds.


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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Jan Beulich]

>>> On 16.01.15 at 16:56,  wrote:
> On 01/07/2015 04:12 AM, Jan Beulich wrote:
> On 06.01.15 at 14:41,  wrote:
>>> On 06/01/15 02:18, Boris Ostrovsky wrote:
 Instead of copying data for each field in xen_sysctl_topologyinfo 
 separately
 put cpu/socket/node into a single structure and do a single copy for each
 processor.

 There is also no need to copy whole op to user at the end, max_cpu_index is
 sufficient

 Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the 
> fact
 that these are used for CPU topology. Subsequent patch will add support for
 PCI topology sysctl.

 Signed-off-by: Boris Ostrovsky 
>>> If we are going to change the hypercall, then can we see about making it
>>> a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
>>> components which might want/need access to this information.  (i.e. I am
>>> still looking for a reasonable way to get this information from Xen in
>>> hwloc)
>> In which case leaving the sysctl alone and just adding a new non-sysctl
>> interface should be considered.
> 
> (Sorry for late reply)
> 
> Would a platform op be an option here or do you prefer a whole new 
> hypercall?

>From an abstract pov a platform op would be fine, but iirc you had
a need for preempting, which doesn't work well for that hypercall.
A whole new one seems overkill too. Perhaps slightly bending what
physdevop-s are used for might be an option...

Jan


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

Re: [Xen-devel] [PATCH] Switch QEMU_UPSTREAM_REVISION back to master

[Ian Jackson]

Stefano Stabellini writes ("[PATCH] Switch QEMU_UPSTREAM_REVISION back to 
master"):
> Signed-off-by: Stefano Stabellini 
> 
> diff --git a/Config.mk b/Config.mk
> index 0e22057..4745b85 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -252,7 +252,7 @@ QEMU_TRADITIONAL_URL ?= 
> git://xenbits.xen.org/qemu-xen-unstable.git
>  SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  endif
>  OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
> -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.5.0-rc4
> +QEMU_UPSTREAM_REVISION ?= master
>  SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5

This was done in staging in 0082626f35af6cfcdd30214d946981a8aec82c08
AFAICT.

Ian.

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

Re: [Xen-devel] [PATCH] Xen/hypercall: Update vcpu_op to take an unsigned vcpuid

[Stefano Stabellini]

On Fri, 16 Jan 2015, Andrew Cooper wrote:
> This has no guest-visible change, but makes the Hypervisor side bounds
> checking more simple.
> 
> Signed-off-by: Andrew Cooper 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Ian Campbell 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> 

For the tiny arm part:

Acked-by: Stefano Stabellini 

> 
> There are no functional changes as a result of this patch, but I have an RFC
> improvement to suggest.
> 
> The bounds check against MAX_VIRT_CPUS is spurious now that PVH domains can
> use vcpu_op hypercalls.  It is fine as MAX_VIRT_CPUS (8K) is far higher than
> current 128 limit for HVM guests, but there is nothing conceptually preventing
> an HVM domain from having more than 8k CPUs (x2apic allows for 2^32 unique 
> ids).
> 
> I propose dropping the MAX_VIRT_CPU bounds check completely, and relying on
> d->max_vcpus to be within the approprate bounds.  This will result in a guest
> visible change insofar that some of their -EINVAL errors will turn into
> -ENOENT, which is why this is suggestion is RFC.
> ---
>  xen/arch/arm/domain.c   |2 +-
>  xen/arch/x86/hvm/hvm.c  |4 ++--
>  xen/common/compat/domain.c  |6 +++---
>  xen/common/domain.c |6 +++---
>  xen/include/asm-arm/hypercall.h |2 +-
>  xen/include/public/vcpu.h   |2 +-
>  xen/include/xen/hypercall.h |4 ++--
>  7 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 7221bc8..cfc7ab4 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -777,7 +777,7 @@ void arch_dump_domain_info(struct domain *d)
>  }
>  
>  
> -long do_arm_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
> +long do_arm_vcpu_op(int cmd, unsigned int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>  switch ( cmd )
>  {
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8b06bfd..e096094 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4659,7 +4659,7 @@ static long hvm_physdev_op(int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  }
>  
>  static long hvm_vcpu_op(
> -int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
> +int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>  long rc;
>  
> @@ -4718,7 +4718,7 @@ static long hvm_memory_op_compat32(int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  }
>  
>  static long hvm_vcpu_op_compat32(
> -int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
> +int cmd, unsigned vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>  long rc;
>  
> diff --git a/xen/common/compat/domain.c b/xen/common/compat/domain.c
> index b4be3b3..510843d 100644
> --- a/xen/common/compat/domain.c
> +++ b/xen/common/compat/domain.c
> @@ -23,13 +23,13 @@ CHECK_SIZE_(struct, vcpu_info);
>  CHECK_vcpu_register_vcpu_info;
>  #undef xen_vcpu_register_vcpu_info
>  
> -int compat_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
> +int compat_vcpu_op(int cmd, unsigned int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>  struct domain *d = current->domain;
>  struct vcpu *v;
>  int rc = 0;
>  
> -if ( (vcpuid < 0) || (vcpuid >= MAX_VIRT_CPUS) )
> +if ( vcpuid >= MAX_VIRT_CPUS )
>  return -EINVAL;
>  
>  if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> @@ -59,7 +59,7 @@ int compat_vcpu_op(int cmd, int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  domain_unlock(d);
>  
>  if ( rc == -ERESTART )
> -rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iih",
> +rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iuh",
> cmd, vcpuid, arg);
>  
>  xfree(cmp_ctxt);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 336e9ea..e02823e 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1139,14 +1139,14 @@ void unmap_vcpu_info(struct vcpu *v)
>  put_page_and_type(mfn_to_page(mfn));
>  }
>  
> -long do_vcpu_op(int cmd, int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
> +long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) 
> arg)
>  {
>  struct domain *d = current->domain;
>  struct vcpu *v;
>  struct vcpu_guest_context *ctxt;
>  long rc = 0;
>  
> -if ( (vcpuid < 0) || (vcpuid >= MAX_VIRT_CPUS) )
> +if ( vcpuid >= MAX_VIRT_CPUS )
>  return -EINVAL;
>  
>  if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> @@ -1174,7 +1174,7 @@ long do_vcpu_op(int cmd, int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  free_vcpu_guest_context(ctxt);
>  
>  if ( rc == -ERESTART )
> -rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iih",
> +rc = hypercall_create_continuation(__HYPERVISOR_vcpu_op, "iuh",
> cmd, vcpuid, arg);
>  
>  break;
> d

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Boris Ostrovsky]

On 01/16/2015 11:06 AM, Jan Beulich wrote:

On 16.01.15 at 16:56,  wrote:

On 01/07/2015 04:12 AM, Jan Beulich wrote:

On 06.01.15 at 14:41,  wrote:

On 06/01/15 02:18, Boris Ostrovsky wrote:

Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.

There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient

Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the

fact

that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.

Signed-off-by: Boris Ostrovsky 

If we are going to change the hypercall, then can we see about making it
a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
components which might want/need access to this information.  (i.e. I am
still looking for a reasonable way to get this information from Xen in
hwloc)

In which case leaving the sysctl alone and just adding a new non-sysctl
interface should be considered.

(Sorry for late reply)

Would a platform op be an option here or do you prefer a whole new
hypercall?

 From an abstract pov a platform op would be fine, but iirc you had
a need for preempting, which doesn't work well for that hypercall.
A whole new one seems overkill too. Perhaps slightly bending what
physdevop-s are used for might be an option...


Since the plan is to query for both CPU and IO topologies physdevops 
doesn't seem to be a logical place for that, does it?


What is the problem with preempting while in platform op? We already do 
this for microcode updates.


-boris


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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Ian Campbell]

On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
> >>> On 16.01.15 at 16:56,  wrote:
> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
> > On 06.01.15 at 14:41,  wrote:
> >>> On 06/01/15 02:18, Boris Ostrovsky wrote:
>  Instead of copying data for each field in xen_sysctl_topologyinfo 
>  separately
>  put cpu/socket/node into a single structure and do a single copy for each
>  processor.
> 
>  There is also no need to copy whole op to user at the end, max_cpu_index 
>  is
>  sufficient
> 
>  Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect 
>  the 
> > fact
>  that these are used for CPU topology. Subsequent patch will add support 
>  for
>  PCI topology sysctl.
> 
>  Signed-off-by: Boris Ostrovsky 
> >>> If we are going to change the hypercall, then can we see about making it
> >>> a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
> >>> components which might want/need access to this information.  (i.e. I am
> >>> still looking for a reasonable way to get this information from Xen in
> >>> hwloc)
> >> In which case leaving the sysctl alone and just adding a new non-sysctl
> >> interface should be considered.
> > 
> > (Sorry for late reply)
> > 
> > Would a platform op be an option here or do you prefer a whole new 
> > hypercall?
> 
> From an abstract pov a platform op would be fine, but iirc you had
> a need for preempting, which doesn't work well for that hypercall.
> A whole new one seems overkill too. Perhaps slightly bending what
> physdevop-s are used for might be an option...

Unlike sysctls, physdevop-s are exposed to/stable for dom0 too aren't
they?

Ian.


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

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

[Iurii Konovalenko]

I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" : :
"r" (freq));
Also I tried to write it via Xen API: WRITE_SYSREG32(freq, CNTFRQ_EL0);

But unfortunately Xen fails on both this instructions with "Undefined
instruction" exception.
You can see log in attachment.
Could you please suggest reason, why it happens?

Best regards.

Iurii Konovalenko | Senior Software Engineer
GlobalLogic
P +3.8044.492.9695 M +38.099.932.2909
S yufuntik
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt

On Fri, Jan 16, 2015 at 5:32 PM, Julien Grall 
wrote:

> On 16/01/15 15:29, Iurii Konovalenko wrote:
> >> Is there any reason that this code diverge?
> >>
> >
> > Linux kernel 3.14-ltsi, which I used as a reference, use CNTFID0
> > in file arch/arm/mach-shmobile/setup-rcar-gen2.c:
> > iowrite32(freq, base + CNTFID0);
>
> Which seems different from upstream:
>
> 1. /* Update registers with correct frequency */
> 2. iowrite32(freq, base + CNTFID0);
> 3. asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
> 4.
> 5. /* make sure arch timer is started by setting bit 0 of CNTCR */
> 6. iowrite32(1, base + CNTCR);
>
> Regards,
>
> --
> Julien Grall
>
- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - 7fff
(XEN) RAM: 00014000 - 0001
(XEN) 
(XEN) MODULE[0]: 70ef9000 - 70efd000 Device Tree  
(XEN) MODULE[1]: 7200 - 7400 Kernel   
(XEN) MODULE[2]: 7400 - 7401 XSM  
(XEN)  RESVD[0]: 7ff9a000 - 7ff9a120
(XEN)  RESVD[1]: 70ef9000 - 70efd000
(XEN) 
(XEN) Command line: dom0_mem=1024M console=dtuart dtuart=serial6 dom0_max_vcpus=4 bootscrub=0 flask_enforcing=1
(XEN) Placing Xen at 0x7fc0-0x7fe0
(XEN) Update BOOTMOD_XEN from 9000-900f9701 => 7fc0-7fcf9701
(XEN) Xen heap: 0001e000-0002 (131072 pages)
(XEN) Dom heap: 917504 pages
(XEN) Domain heap initialised
(XEN) Looking for UART console serial6
 Xen 4.5.0
(XEN) Xen version 4.5.0 (ikonovalenko@) (arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 4.7.3 20130328 (prerelease)) debug=y Fri Jan 16 18:01:31 EET 2015
(XEN) Latest ChangeSet: Thu Nov 6 11:59:59 2014 +0200 git:67995e1-dirty
(XEN) Processor: 413fc0f2: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x2
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Platform: Renesas R-Car Gen2
(XEN) /psci method must be smc, but is: "hvc"
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) CPU0: Unexpected Trap: Undefined Instruction
(XEN) [ Xen-4.5.0  arm32  debug=y  Not tainted ]
(XEN) CPU:0
(XEN) PC: 002560a0 shmobile_init_time+0xb8/0xd8
(XEN) CPSR:   61da MODE:Hypervisor
(XEN)  R0: 10009000 R1: 0040 R2: e6080e71 R3: 
(XEN)  R4: 00989680 R5: 002f6234 R6: 40008c28 R7: 0002
(XEN)  R8: 0004 R9: 0001 R10: R11:002afe8c R12:40001048
(XEN) HYP: SP: 002afe7c LR: 0024a58c
(XEN) 
(XEN)   VTCR_EL2: 8000
(XEN)  VTTBR_EL2: 
(XEN) 
(XEN)  SCTLR_EL2: 30cd187f
(XEN)HCR_EL2: 0038643f
(XEN)  TTBR0_EL2: 7fcf
(XEN) 
(XEN)ESR_EL2: 
(XEN)  HPFAR_EL2: 
(XEN)  HDFAR: 
(XEN)  HIFAR: 
(XEN) 
(XEN) Xen stack trace from sp=002afe7c:
(XEN)0025605c 00255fe8 0004 002afe94 0027e4b0 002afeb4 00280588 00272024
(XEN)0004 0002 00272024 00272024 0004 002aff54 0027f5c4 2131
(XEN)10011142       0001
(XEN)b000 4000  00272010 0002  0002 00298048
(XEN)00298428 0002 00274628 00298028  e000 0001 
(XEN)0002  0002  0002  0018 
(XEN)0001  70ef9000 9000 8fe0 0040 00200540 
(XEN)       
(XEN)       
(XEN)       
(XEN)       
(XEN)       
(XEN)
(XEN) Xen call trace:
(XEN)[<002560a0>] shmobile_init_time+0xb8/0xd8 (PC)
(XEN)[<0024a58c>] map_pa

[Xen-devel] Hypercall overhead measurement on Xen/ARM

[Jintack Lim]

Hi,

I'm trying to measure number of cycles for hypercalls.
I'm working on ARM v7 and v8.

Xentrace seems to be a right tool to use according to this discussion.
http://lists.xen.org/archives/html/xen-devel/2008-10/msg00480.html

However when I ran it on ARM, it gave an error.
The error is the same as in this discussion in 2014 below.
Xentrace on ARM is not supported?
http://lists.xen.org/archives/html/xen-devel/2014-02/msg00154.html
http://lists.xen.org/archives/html/xen-devel/2014-02/msg00206.html

Are there other tools for this purpose?

Thanks,
Jintack


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

[Xen-devel] [PATCH 1/6] arm/setup: Add missing __init to add_boot_module

[Julien Grall]

add_boot_module is calling a function which lies in the init section.
Furthermore, it's only used during Xen boot.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/setup.c| 6 +++---
 xen/include/asm-arm/setup.h | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f49569d..5fc27ce0 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -185,9 +185,9 @@ static void dt_unreserved_regions(paddr_t s, paddr_t e,
 cb(s, e);
 }
 
-struct bootmodule *add_boot_module(bootmodule_kind kind,
-   paddr_t start, paddr_t size,
-   const char *cmdline)
+struct bootmodule __init *add_boot_module(bootmodule_kind kind,
+  paddr_t start, paddr_t size,
+  const char *cmdline)
 {
 struct bootmodules *mods = &bootinfo.modules;
 struct bootmodule *mod;
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index ba5a67d..ed2ba16 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -60,10 +60,10 @@ void discard_initial_modules(void);
 size_t __init boot_fdt_info(const void *fdt, paddr_t paddr);
 const char __init *boot_fdt_cmdline(const void *fdt);
 
-struct bootmodule *add_boot_module(bootmodule_kind kind,
-   paddr_t start, paddr_t size,
-   const char *cmdline);
-struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
+struct bootmodule __init *add_boot_module(bootmodule_kind kind,
+  paddr_t start, paddr_t size,
+  const char *cmdline);
+struct bootmodule __init *boot_module_find_by_kind(bootmodule_kind kind);
 const char * __init boot_module_kind_as_string(bootmodule_kind kind);
 
 #endif
-- 
2.1.4


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

[Xen-devel] [PATCH 2/6] xen/arm: domain_build: Move all DOM0 building code in init section

[Julien Grall]

The code to build DOM0 is only used during Xen boot.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 66 ++---
 xen/include/asm-arm/setup.h |  2 +-
 2 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c2dcb49..d30df08 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -76,7 +76,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 return alloc_vcpu(dom0, 0, 0);
 }
 
-static unsigned int get_11_allocation_size(paddr_t size)
+static unsigned int __init get_11_allocation_size(paddr_t size)
 {
 /*
  * get_order_from_bytes returns the order greater than or equal to
@@ -94,10 +94,10 @@ static unsigned int get_11_allocation_size(paddr_t size)
  * Returns false if the memory would be below bank 0 or we have run
  * out of banks. In this case it will free the pages.
  */
-static bool_t insert_11_bank(struct domain *d,
- struct kernel_info *kinfo,
- struct page_info *pg,
- unsigned int order)
+static bool_t __init insert_11_bank(struct domain *d,
+struct kernel_info *kinfo,
+struct page_info *pg,
+unsigned int order)
 {
 int res, i;
 paddr_t spfn;
@@ -240,7 +240,8 @@ fail:
  * (as described above) we allow higher allocations and continue until
  * that runs out (or we have allocated sufficient dom0 memory).
  */
-static void allocate_memory_11(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory_11(struct domain *d,
+  struct kernel_info *kinfo)
 {
 const unsigned int min_low_order =
 get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -348,7 +349,7 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 }
 }
 
-static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
 {
 
 struct dt_device_node *memory = NULL;
@@ -398,8 +399,8 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 }
 }
 
-static int write_properties(struct domain *d, struct kernel_info *kinfo,
-const struct dt_device_node *node)
+static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
+   const struct dt_device_node *node)
 {
 const char *bootargs = NULL;
 const struct dt_property *prop;
@@ -504,8 +505,8 @@ static int write_properties(struct domain *d, struct 
kernel_info *kinfo,
 
 typedef __be32 gic_interrupt_t[3];
 
-static void set_interrupt_ppi(gic_interrupt_t interrupt, unsigned int irq,
-  unsigned int cpumask, unsigned int level)
+static void __init set_interrupt_ppi(gic_interrupt_t interrupt, unsigned int 
irq,
+ unsigned int cpumask, unsigned int level)
 {
 __be32 *cells = interrupt;
 
@@ -523,8 +524,8 @@ static void set_interrupt_ppi(gic_interrupt_t interrupt, 
unsigned int irq,
  *  "interrupts": contains the list of interrupts
  *  "interrupt-parent": link to the GIC
  */
-static int fdt_property_interrupts(void *fdt, gic_interrupt_t *intr,
-   unsigned num_irq)
+static int __init fdt_property_interrupts(void *fdt, gic_interrupt_t *intr,
+  unsigned num_irq)
 {
 int res;
 
@@ -538,10 +539,9 @@ static int fdt_property_interrupts(void *fdt, 
gic_interrupt_t *intr,
 return res;
 }
 
-static int make_memory_node(const struct domain *d,
-void *fdt,
-const struct dt_device_node *parent,
-const struct kernel_info *kinfo)
+static int __init make_memory_node(const struct domain *d, void *fdt,
+   const struct dt_device_node *parent,
+   const struct kernel_info *kinfo)
 {
 int res, i;
 int reg_size = dt_n_addr_cells(parent) + dt_n_size_cells(parent);
@@ -581,8 +581,8 @@ static int make_memory_node(const struct domain *d,
 return res;
 }
 
-static int make_hypervisor_node(struct domain *d,
-void *fdt, const struct dt_device_node *parent)
+static int __init make_hypervisor_node(struct domain *d, void *fdt,
+   const struct dt_device_node *parent)
 {
 const char compat[] =
 "xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
@@ -646,7 +646,7 @@ static int make_hypervisor_node(struct domain *d,
 return res;
 }
 
-static int make_psci_node(void *fdt, const struct dt_device_node *parent)
+static int __init make_psci_node(void *fdt, const struct dt_

[Xen-devel] [PATCH 3/6] xen/arm: kernel: Move kernel loading code in init section

[Julien Grall]

The code to load the kernel is only used when Xen builds dom0. It
happens during the boot.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/kernel.c | 30 +++---
 xen/arch/arm/kernel.h |  4 ++--
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 209c3dd..5b72c77 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -67,8 +67,8 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long 
len)
 clear_fixmap(FIXMAP_MISC);
 }
 
-static void place_modules(struct kernel_info *info,
-  paddr_t kernbase, paddr_t kernend)
+static void __init place_modules(struct kernel_info *info,
+ paddr_t kernbase, paddr_t kernend)
 {
 /* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment 
*/
 const struct bootmodule *mod = info->initrd_bootmodule;
@@ -121,7 +121,7 @@ static void place_modules(struct kernel_info *info,
 info->initrd_paddr = info->dtb_paddr + dtb_len;
 }
 
-static paddr_t kernel_zimage_place(struct kernel_info *info)
+static paddr_t __init kernel_zimage_place(struct kernel_info *info)
 {
 paddr_t load_addr;
 
@@ -153,7 +153,7 @@ static paddr_t kernel_zimage_place(struct kernel_info *info)
 return load_addr;
 }
 
-static void kernel_zimage_load(struct kernel_info *info)
+static void __init kernel_zimage_load(struct kernel_info *info)
 {
 paddr_t load_addr = kernel_zimage_place(info);
 paddr_t paddr = info->zimage.kernel_addr;
@@ -200,8 +200,8 @@ static void kernel_zimage_load(struct kernel_info *info)
 /*
  * Check if the image is a uImage and setup kernel_info
  */
-static int kernel_uimage_probe(struct kernel_info *info,
- paddr_t addr, paddr_t size)
+static int __init kernel_uimage_probe(struct kernel_info *info,
+  paddr_t addr, paddr_t size)
 {
 struct {
 __be32 magic;   /* Image Header Magic Number */
@@ -261,8 +261,8 @@ static int kernel_uimage_probe(struct kernel_info *info,
 /*
  * Check if the image is a 64-bit Image.
  */
-static int kernel_zimage64_probe(struct kernel_info *info,
- paddr_t addr, paddr_t size)
+static int __init kernel_zimage64_probe(struct kernel_info *info,
+paddr_t addr, paddr_t size)
 {
 /* linux/Documentation/arm64/booting.txt */
 struct {
@@ -315,8 +315,8 @@ static int kernel_zimage64_probe(struct kernel_info *info,
 /*
  * Check if the image is a 32-bit zImage and setup kernel_info
  */
-static int kernel_zimage32_probe(struct kernel_info *info,
- paddr_t addr, paddr_t size)
+static int __init kernel_zimage32_probe(struct kernel_info *info,
+paddr_t addr, paddr_t size)
 {
 uint32_t zimage[ZIMAGE32_HEADER_LEN/4];
 uint32_t start, end;
@@ -364,7 +364,7 @@ static int kernel_zimage32_probe(struct kernel_info *info,
 return 0;
 }
 
-static void kernel_elf_load(struct kernel_info *info)
+static void __init kernel_elf_load(struct kernel_info *info)
 {
 /*
  * TODO: can the ELF header be used to find the physical address
@@ -387,8 +387,8 @@ static void kernel_elf_load(struct kernel_info *info)
 free_xenheap_pages(info->elf.kernel_img, info->elf.kernel_order);
 }
 
-static int kernel_elf_probe(struct kernel_info *info,
-paddr_t addr, paddr_t size)
+static int __init kernel_elf_probe(struct kernel_info *info,
+   paddr_t addr, paddr_t size)
 {
 int rc;
 
@@ -439,7 +439,7 @@ err:
 return rc;
 }
 
-int kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info)
 {
 struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
 int rc;
@@ -476,7 +476,7 @@ int kernel_probe(struct kernel_info *info)
 return rc;
 }
 
-void kernel_load(struct kernel_info *info)
+void __init kernel_load(struct kernel_info *info)
 {
 info->load(info);
 }
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 0050dfb..512b573 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -56,7 +56,7 @@ struct kernel_info {
  *  ->type
  *  ->load hook, and sets loader specific variables ->{zimage,elf}
  */
-int kernel_probe(struct kernel_info *info);
+int __init kernel_probe(struct kernel_info *info);
 
 /*
  * Loads the kernel into guest RAM.
@@ -70,7 +70,7 @@ int kernel_probe(struct kernel_info *info);
  *  ->dtb_paddr
  *  ->initrd_paddr
  */
-void kernel_load(struct kernel_info *info);
+void __init kernel_load(struct kernel_info *info);
 
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
 
-- 
2.1.4


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

[Xen-devel] [PATCH 4/6] xen/arm: device: Move device_type in init section

[Julien Grall]

The function is calling device_is_compatible which lies in init section
and is only called during Xen boot.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/device.c| 2 +-
 xen/include/asm-arm/device.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 59e94c0..3e5c458 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -67,7 +67,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_type type,
 return -EBADF;
 }
 
-enum device_type device_get_type(const struct dt_device_node *dev)
+enum device_type __init device_get_type(const struct dt_device_node *dev)
 {
 const struct device_desc *desc;
 
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 74a80c6..e23673c 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -41,7 +41,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_type type,
  *
  * Return the device type on success or DEVICE_ANY on failure
  */
-enum device_type device_get_type(const struct dt_device_node *dev);
+enum device_type __init device_get_type(const struct dt_device_node *dev);
 
 #define DT_DEVICE_START(_name, _namestr, _type) \
 static const struct device_desc __dev_desc_##_name __used   \
-- 
2.1.4


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

[Xen-devel] [PATCH 0/6] xen/arm: Move in/out code to/from init section

[Julien Grall]

Hello,

This small series add/remove __init on different functions. This allow Xen to
free around 8Kb more of memory after it has finished to boot.

Xen size in memory before to free init section: 1029Kb
Freed memory init: 288Kb

Regards,

Julien Grall (6):
  arm/setup: Add missing __init to add_boot_module
  xen/arm: domain_build: Move all DOM0 building code in init section
  xen/arm: kernel: Move kernel loading code in init section
  xen/arm: device: Move device_type in init section
  xen/arm: platforms: Move init_time and specific_mapping in init
section
  xen/arm: SMP: Move out of the init section the code to bring up a CPU

 xen/arch/arm/arm32/smpboot.c |  4 +--
 xen/arch/arm/device.c|  2 +-
 xen/arch/arm/domain_build.c  | 66 ++--
 xen/arch/arm/kernel.c| 30 
 xen/arch/arm/kernel.h|  4 +--
 xen/arch/arm/platform.c  |  2 +-
 xen/arch/arm/platforms/exynos5.c |  4 +--
 xen/arch/arm/platforms/omap5.c   |  4 +--
 xen/arch/arm/platforms/xgene-storm.c | 16 -
 xen/arch/arm/setup.c |  6 ++--
 xen/arch/arm/smpboot.c   |  2 +-
 xen/include/asm-arm/device.h |  2 +-
 xen/include/asm-arm/setup.h  | 10 +++---
 xen/include/asm-arm/smp.h|  2 +-
 14 files changed, 77 insertions(+), 77 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Jan Beulich]

>>> On 16.01.15 at 17:14,  wrote:
> On 01/16/2015 11:06 AM, Jan Beulich wrote:
> On 16.01.15 at 16:56,  wrote:
>>> On 01/07/2015 04:12 AM, Jan Beulich wrote:
>>> On 06.01.15 at 14:41,  wrote:
> On 06/01/15 02:18, Boris Ostrovsky wrote:
>> Instead of copying data for each field in xen_sysctl_topologyinfo 
>> separately
>> put cpu/socket/node into a single structure and do a single copy for each
>> processor.
>>
>> There is also no need to copy whole op to user at the end, max_cpu_index 
>> is
>> sufficient
>>
>> Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the
>>> fact
>> that these are used for CPU topology. Subsequent patch will add support 
>> for
>> PCI topology sysctl.
>>
>> Signed-off-by: Boris Ostrovsky 
> If we are going to change the hypercall, then can we see about making it
> a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
> components which might want/need access to this information.  (i.e. I am
> still looking for a reasonable way to get this information from Xen in
> hwloc)
 In which case leaving the sysctl alone and just adding a new non-sysctl
 interface should be considered.
>>> (Sorry for late reply)
>>>
>>> Would a platform op be an option here or do you prefer a whole new
>>> hypercall?
>>  From an abstract pov a platform op would be fine, but iirc you had
>> a need for preempting, which doesn't work well for that hypercall.
>> A whole new one seems overkill too. Perhaps slightly bending what
>> physdevop-s are used for might be an option...
> 
> Since the plan is to query for both CPU and IO topologies physdevops 
> doesn't seem to be a logical place for that, does it?

That's why I said "slightly bending ..."

> What is the problem with preempting while in platform op? We already do 
> this for microcode updates.

But there we don't need to alter the arguments passed to the
hypercall, whereas you will need a way to encode where to
continue from.

Jan


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

[Xen-devel] [PATCH 5/6] xen/arm: platforms: Move init_time and specific_mapping in init section

[Julien Grall]

The callbacks init_time and specific_mapping are respectively used
during timer initialization and DOM0 building. These 2 taks only
happen during Xen boot.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/platforms/exynos5.c |  4 ++--
 xen/arch/arm/platforms/omap5.c   |  4 ++--
 xen/arch/arm/platforms/xgene-storm.c | 16 
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index 79e3a5f..e90b659 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -37,7 +37,7 @@ static bool_t secure_firmware;
 
 #define SMC_CMD_CPU1BOOT(-4)
 
-static int exynos5_init_time(void)
+static int __init exynos5_init_time(void)
 {
 uint32_t reg;
 void __iomem *mct;
@@ -80,7 +80,7 @@ static int exynos5_init_time(void)
 }
 
 /* Additional mappings for dom0 (Not in the DTS) */
-static int exynos5250_specific_mapping(struct domain *d)
+static int __init exynos5250_specific_mapping(struct domain *d)
 {
 /* Map the chip ID */
 map_mmio_regions(d, paddr_to_pfn(EXYNOS5_PA_CHIPID), 1,
diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index 9d6e504..7086c0b 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -45,7 +45,7 @@ static uint16_t num_den[8][2] = {
  * clocks, adjusting the increment per clock in hardware accordingly to
  * maintain a constant count rate.
  */
-static int omap5_init_time(void)
+static int __init omap5_init_time(void)
 {
 void __iomem *ckgen_prm_base;
 void __iomem *rt_ct_base;
@@ -99,7 +99,7 @@ static int omap5_init_time(void)
 }
 
 /* Additional mappings for dom0 (not in the DTS) */
-static int omap5_specific_mapping(struct domain *d)
+static int __init omap5_specific_mapping(struct domain *d)
 {
 /* Map the PRM module */
 map_mmio_regions(d, paddr_to_pfn(OMAP5_PRM_BASE), 2,
diff --git a/xen/arch/arm/platforms/xgene-storm.c 
b/xen/arch/arm/platforms/xgene-storm.c
index 0b3492d..8c650c3 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -40,7 +40,7 @@ static uint32_t xgene_storm_quirks(void)
 return PLATFORM_QUIRK_GIC_64K_STRIDE|PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI;
 }
 
-static int map_one_mmio(struct domain *d, const char *what,
+static int __init map_one_mmio(struct domain *d, const char *what,
  unsigned long start, unsigned long end)
 {
 int ret;
@@ -54,8 +54,8 @@ static int map_one_mmio(struct domain *d, const char *what,
 return ret;
 }
 
-static int map_one_spi(struct domain *d, const char *what,
-   unsigned int spi, unsigned int type)
+static int __init map_one_spi(struct domain *d, const char *what,
+  unsigned int spi, unsigned int type)
 {
 unsigned int irq;
 int ret;
@@ -79,10 +79,10 @@ static int map_one_spi(struct domain *d, const char *what,
 }
 
 /* Creates MMIO mappings base..end as well as 4 SPIs from the given base. */
-static int xgene_storm_pcie_specific_mapping(struct domain *d,
- const struct dt_device_node *node,
- paddr_t base, paddr_t end,
- int base_spi)
+static int __init xgene_storm_pcie_specific_mapping(struct domain *d,
+const struct 
dt_device_node *node,
+paddr_t base, paddr_t end,
+int base_spi)
 {
 int ret;
 
@@ -121,7 +121,7 @@ err:
  * "interrupt-map" properties to domain 0). Instead for now map the
  * necessary resources manually.
  */
-static int xgene_storm_specific_mapping(struct domain *d)
+static int __init xgene_storm_specific_mapping(struct domain *d)
 {
 struct dt_device_node *node = NULL;
 int ret;
-- 
2.1.4


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

[Xen-devel] [PATCH 6/6] xen/arm: SMP: Move out of the init section the code to bring up a CPU

[Julien Grall]

When CPU hotplug will be supported, it will require to bring up a CPU.

Signed-off-by: Julien Grall 

---

I'm not sure if we should flag these functions with __cpuinit. The
define doesn't do anything.
---
 xen/arch/arm/arm32/smpboot.c | 4 ++--
 xen/arch/arm/platform.c  | 2 +-
 xen/arch/arm/smpboot.c   | 2 +-
 xen/include/asm-arm/smp.h| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/arm32/smpboot.c b/xen/arch/arm/arm32/smpboot.c
index 2a77f29..226d6fd 100644
--- a/xen/arch/arm/arm32/smpboot.c
+++ b/xen/arch/arm/arm32/smpboot.c
@@ -8,7 +8,7 @@ int __init arch_smp_init(void)
 return platform_smp_init();
 }
 
-int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
+int arch_cpu_init(int cpu, struct dt_device_node *dn)
 {
 /* Not needed on ARM32, as there is no relevant information in
  * the CPU device tree node for ARMv7 CPUs.
@@ -16,7 +16,7 @@ int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
 return 0;
 }
 
-int __init arch_cpu_up(int cpu)
+int arch_cpu_up(int cpu)
 {
 return platform_cpu_up(cpu);
 }
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..0368679 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -108,7 +108,7 @@ int __init platform_specific_mapping(struct domain *d)
 }
 
 #ifdef CONFIG_ARM_32
-int __init platform_cpu_up(int cpu)
+int platform_cpu_up(int cpu)
 {
 if ( psci_ver )
 return call_psci_cpu_on(cpu);
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index a96cda2..a228623 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -343,7 +343,7 @@ void stop_cpu(void)
 wfi();
 }
 
-int __init cpu_up_send_sgi(int cpu)
+int cpu_up_send_sgi(int cpu)
 {
 /* We don't know the GIC ID of the CPU until it has woken up, so just
  * signal everyone and rely on our own smp_up_cpu gate to ensure only
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
index 91b1e52..181aead 100644
--- a/xen/include/asm-arm/smp.h
+++ b/xen/include/asm-arm/smp.h
@@ -17,7 +17,7 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
 
 extern void noreturn stop_cpu(void);
 
-extern int arch_smp_init(void);
+extern int __init arch_smp_init(void);
 extern int arch_cpu_init(int cpu, struct dt_device_node *dn);
 extern int arch_cpu_up(int cpu);
 
-- 
2.1.4


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

[Xen-devel] Tracking guest code execution with EPT violations

[Kevin.Mayer]

Hi all

I`m trying to track code execution with page granularity by setting the access 
rights in the EPT to not executable on Xen 4.4.1.
The idea is as follows:

According to the intel manual  "A reference using a guest-physical address 
whose translation encounters an EPT paging-structure that is not present causes 
an EPT violation."
So whenever a nonexisting memory page gets requested an EPT violation is caused 
(and handled by ept_handle_violation). Extending the  EXIT_REASON_EPT_VIOLATION 
I should be able to set the access rights for every new page to access_rw(By 
using the p2m->get_entry and p2m-> set_entry functions right after the 
violation was handled), leading to a new EPT violation every time an 
instruction is fetched from this page.

There are several problems with my approach so far:

* I get to few unique GFN (derived from the gpa by PAGE_SHIFT in the 
EPT violations when booting a WinXP guest.  I get about 250 EPT_VIOLATIONS with 
unique GFNs when booting the guest OS and none when starting new programs in 
the guest. So something seems to be wrong there. Also I read the access rights 
of the pages back after setting them. Most of the time the initial access 
rights are access_n before and the same after I tried setting them to access_rw 
(this happens when the type is p2m_mmio_dm, when the type is p2m_ram_rw the 
setting works temporarily).

* I never get an EPT violation with the EPT_EXEC_VIOLATION flag set in 
the exit qualifications even for the pages where the setting of the access 
rights did succeed.

* Later when checking the access rights (I simply save the GFNs in an 
array and use p2m->get_entry in an own  call to domctl.c from xl) of the GFNs 
they all have access right access_n and type p2m_mmio_dm , even for the pages 
where the setting of the access rights did succeed or the type was different 
before.

This all tells me that there is something fundamentally wrong with my approach 
so far, leading me to the following questions:


1.   Every time a new page in memory is allocated by the guest I get an 
EPT_VIOLATION, right?

a.   If this is the case then why don't I get new violations after windows 
has finished booting?

2.   What is the difference between types p2m_mmio_dm and p2m_ram_rw? (got 
a feeling that part of the problem lies here)

3.   Are the p2m->get_entry/p2m->set_entry functions the right tools for 
this purpose?

a.   If they are, then why do they sometimes fail?

4.   To get the domain I use struct vcpu *curr = current; and struct 
p2m_domain *p2m = p2m_get_hostp2m(curr->domain); before using the 
get/set_entry-functions. Do I get confused with wrong domains or something like 
that?

5.   Because I just set the access rights to rw every time 
EXIT_REASON_EPT_VIOLATION is called the whole domain should freeze/crash as 
soon as the first page tries to execute an instruction, right? It doesn't 
because I get no execution attempts on the pages I set the access_rw, but why 
don't I get an execution attempt?

I hope it got clear what I try to achieve.

Thanks

Kevin


Virus checked by G Data MailSecurity
Version: AVA 24.6111 dated 16.01.2015
Virus news: www.antiviruslab.com___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5] x86/hvm: Add per-vcpu evtchn upcalls

[Jan Beulich]

>>> On 16.01.15 at 11:09,  wrote:
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -160,6 +160,7 @@ struct hvm_vcpu {
>  } u;
>  
>  struct tasklet  assert_evtchn_irq_tasklet;
> +u8  evtchn_upcall_vector;
>  
>  struct nestedvcpu   nvcpu;
>  

Since where you put this is arbitrary, you should really have used a
slot that's currently padding space - there are a number of places
you could have picked. I'll see to change the placement when
committing.

Jan


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

Re: [Xen-devel] [PATCH 1/6] arm/setup: Add missing __init to add_boot_module

[Andrew Cooper]

On 16/01/15 16:20, Julien Grall wrote:
> add_boot_module is calling a function which lies in the init section.
> Furthermore, it's only used during Xen boot.
>
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/setup.c| 6 +++---
>  xen/include/asm-arm/setup.h | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index f49569d..5fc27ce0 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -185,9 +185,9 @@ static void dt_unreserved_regions(paddr_t s, paddr_t e,
>  cb(s, e);
>  }
>  
> -struct bootmodule *add_boot_module(bootmodule_kind kind,
> -   paddr_t start, paddr_t size,
> -   const char *cmdline)
> +struct bootmodule __init *add_boot_module(bootmodule_kind kind,

__init should be after the type, rather than spliced into the middle of it.

"struct bootmodule * __init add_boot_module(...)" should work.

However, only static functions should be annotated at the definition. 
non-static functions can get their annotation from the declaration alone.

> +  paddr_t start, paddr_t size,
> +  const char *cmdline)
>  {
>  struct bootmodules *mods = &bootinfo.modules;
>  struct bootmodule *mod;
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index ba5a67d..ed2ba16 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -60,10 +60,10 @@ void discard_initial_modules(void);
>  size_t __init boot_fdt_info(const void *fdt, paddr_t paddr);
>  const char __init *boot_fdt_cmdline(const void *fdt);
>  
> -struct bootmodule *add_boot_module(bootmodule_kind kind,
> -   paddr_t start, paddr_t size,
> -   const char *cmdline);
> -struct bootmodule *boot_module_find_by_kind(bootmodule_kind kind);
> +struct bootmodule __init *add_boot_module(bootmodule_kind kind,
> +  paddr_t start, paddr_t size,
> +  const char *cmdline);
> +struct bootmodule __init *boot_module_find_by_kind(bootmodule_kind kind);
>  const char * __init boot_module_kind_as_string(bootmodule_kind kind);
>  
>  #endif



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

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

[Julien Grall]

On 16/01/15 16:17, Iurii Konovalenko wrote:
> I tried to add instruction: asm volatile("mcr p15, 0, %0, c14, c0, 0" :
> : "r" (freq));
> Also I tried to write it via Xen API: WRITE_SYSREG32(freq, CNTFRQ_EL0);
> 
> But unfortunately Xen fails on both this instructions with "Undefined
> instruction" exception.
> You can see log in attachment.
> Could you please suggest reason, why it happens?

CNTFRQ can only be written in Secure PL1 mode.

I have the feeling CNTFRQ is not update automatically when Xen is
writing in CNTFID0. So the frequency may mismatch.

Assuming this, I'm wondering if we hit the second part of the if
sentence [1] and therefore this code useful?

BWT I see in the log:

(XEN) /psci method must be smc, but is: "hvc"

Does it mean your platform support PSCI? Or did you add the PSCI node
for DOM0?

Regards,

[1] readl_relaxed(tmu + SHMOBILE_ARCH_TIMER_CNTFID0) != freq

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH 1/6] arm/setup: Add missing __init to add_boot_module

[Julien Grall]

On 16/01/15 16:28, Andrew Cooper wrote:
> On 16/01/15 16:20, Julien Grall wrote:
>> add_boot_module is calling a function which lies in the init section.
>> Furthermore, it's only used during Xen boot.
>>
>> Signed-off-by: Julien Grall 
>> ---
>>  xen/arch/arm/setup.c| 6 +++---
>>  xen/include/asm-arm/setup.h | 8 
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index f49569d..5fc27ce0 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -185,9 +185,9 @@ static void dt_unreserved_regions(paddr_t s, paddr_t e,
>>  cb(s, e);
>>  }
>>  
>> -struct bootmodule *add_boot_module(bootmodule_kind kind,
>> -   paddr_t start, paddr_t size,
>> -   const char *cmdline)
>> +struct bootmodule __init *add_boot_module(bootmodule_kind kind,
> 
> __init should be after the type, rather than spliced into the middle of it.

Ok.

> "struct bootmodule * __init add_boot_module(...)" should work.
> 
> However, only static functions should be annotated at the definition. 
> non-static functions can get their annotation from the declaration alone.

It's useful for documentation purpose... You directly know this function
should be only used during Xen boot time.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Boris Ostrovsky]

On 01/16/2015 11:20 AM, Jan Beulich wrote:

On 16.01.15 at 17:14,  wrote:

On 01/16/2015 11:06 AM, Jan Beulich wrote:

On 16.01.15 at 16:56,  wrote:

On 01/07/2015 04:12 AM, Jan Beulich wrote:

On 06.01.15 at 14:41,  wrote:

On 06/01/15 02:18, Boris Ostrovsky wrote:

Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.

There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient

Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the

fact

that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.

Signed-off-by: Boris Ostrovsky 

If we are going to change the hypercall, then can we see about making it
a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
components which might want/need access to this information.  (i.e. I am
still looking for a reasonable way to get this information from Xen in
hwloc)

In which case leaving the sysctl alone and just adding a new non-sysctl
interface should be considered.

(Sorry for late reply)

Would a platform op be an option here or do you prefer a whole new
hypercall?

  From an abstract pov a platform op would be fine, but iirc you had
a need for preempting, which doesn't work well for that hypercall.
A whole new one seems overkill too. Perhaps slightly bending what
physdevop-s are used for might be an option...

Since the plan is to query for both CPU and IO topologies physdevops
doesn't seem to be a logical place for that, does it?

That's why I said "slightly bending ..."


What is the problem with preempting while in platform op? We already do
this for microcode updates.

But there we don't need to alter the arguments passed to the
hypercall, whereas you will need a way to encode where to
continue from.


I needed to do this with last version and ended up having a field in the 
interface structure that hypervisor updates before issuing a continuation.


And I think I'd have to do the same for either platform op or physop 
since neither has an extra argument for passing via a continuation.


-boris

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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Jan Beulich]

>>> On 16.01.15 at 17:16,  wrote:
> On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
>> >>> On 16.01.15 at 16:56,  wrote:
>> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
>> > On 06.01.15 at 14:41,  wrote:
>> >>> On 06/01/15 02:18, Boris Ostrovsky wrote:
>>  Instead of copying data for each field in xen_sysctl_topologyinfo 
> separately
>>  put cpu/socket/node into a single structure and do a single copy for 
>>  each
>>  processor.
>> 
>>  There is also no need to copy whole op to user at the end, 
>>  max_cpu_index is
>>  sufficient
>> 
>>  Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect 
>>  the 
>> > fact
>>  that these are used for CPU topology. Subsequent patch will add support 
>>  for
>>  PCI topology sysctl.
>> 
>>  Signed-off-by: Boris Ostrovsky 
>> >>> If we are going to change the hypercall, then can we see about making it
>> >>> a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
>> >>> components which might want/need access to this information.  (i.e. I am
>> >>> still looking for a reasonable way to get this information from Xen in
>> >>> hwloc)
>> >> In which case leaving the sysctl alone and just adding a new non-sysctl
>> >> interface should be considered.
>> > 
>> > (Sorry for late reply)
>> > 
>> > Would a platform op be an option here or do you prefer a whole new 
>> > hypercall?
>> 
>> From an abstract pov a platform op would be fine, but iirc you had
>> a need for preempting, which doesn't work well for that hypercall.
>> A whole new one seems overkill too. Perhaps slightly bending what
>> physdevop-s are used for might be an option...
> 
> Unlike sysctls, physdevop-s are exposed to/stable for dom0 too aren't
> they?

Sure, just like platformop-s. What is it I'm not understanding you
try to point out with your question?

Jan


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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

[Ian Campbell]

On Fri, 2015-01-16 at 16:34 +, Jan Beulich wrote:
> >>> On 16.01.15 at 17:16,  wrote:
> > On Fri, 2015-01-16 at 16:06 +, Jan Beulich wrote:
> >> >>> On 16.01.15 at 16:56,  wrote:
> >> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
> >> > On 06.01.15 at 14:41,  wrote:
> >> >>> On 06/01/15 02:18, Boris Ostrovsky wrote:
> >>  Instead of copying data for each field in xen_sysctl_topologyinfo 
> > separately
> >>  put cpu/socket/node into a single structure and do a single copy for 
> >>  each
> >>  processor.
> >> 
> >>  There is also no need to copy whole op to user at the end, 
> >>  max_cpu_index is
> >>  sufficient
> >> 
> >>  Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect 
> >>  the 
> >> > fact
> >>  that these are used for CPU topology. Subsequent patch will add 
> >>  support for
> >>  PCI topology sysctl.
> >> 
> >>  Signed-off-by: Boris Ostrovsky 
> >> >>> If we are going to change the hypercall, then can we see about making 
> >> >>> it
> >> >>> a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
> >> >>> components which might want/need access to this information.  (i.e. I 
> >> >>> am
> >> >>> still looking for a reasonable way to get this information from Xen in
> >> >>> hwloc)
> >> >> In which case leaving the sysctl alone and just adding a new non-sysctl
> >> >> interface should be considered.
> >> > 
> >> > (Sorry for late reply)
> >> > 
> >> > Would a platform op be an option here or do you prefer a whole new 
> >> > hypercall?
> >> 
> >> From an abstract pov a platform op would be fine, but iirc you had
> >> a need for preempting, which doesn't work well for that hypercall.
> >> A whole new one seems overkill too. Perhaps slightly bending what
> >> physdevop-s are used for might be an option...
> > 
> > Unlike sysctls, physdevop-s are exposed to/stable for dom0 too aren't
> > they?
> 
> Sure, just like platformop-s. What is it I'm not understanding you
> try to point out with your question?

By moving from a sysctl to a physdev op we would then have to declare
the interface stable and lose the ability to change it in the future,
and since it didn't look like the intention here was to expose to dom0
(make more efficient didn't imply that at least) that seems a bit
unnecessary.

Ian.


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