Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when destroying VPMU
>>> On 15.12.14 at 18:15, wrote:
> On 12/15/2014 05:07 AM, Jan Beulich wrote:
> On 12.12.14 at 22:20, wrote:
>>> --- a/xen/arch/x86/hvm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/vpmu.c
>>> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
>>> }
>>> }
>>>
>>> +static void vpmu_clear_last(void *arg)
>>> +{
>>> +struct vcpu *v = (struct vcpu *)arg;
>> Please drop this pointless cast, or perhaps the entire variable, as ...
>>
>>> +
>>> +if ( this_cpu(last_vcpu) == v )
>> ... you don't really need it to be of "struct vcpu *" type - "void *"
>> is quite fine for a comparison.
>>
>>> +this_cpu(last_vcpu) = NULL;
>>> +}
>>> +
>>> void vpmu_destroy(struct vcpu *v)
>>> {
>>> struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>>
>>> +if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
>>> +{
>>> +/* Need to clear last_vcpu in case it points to v */
>>> +if ( vpmu->last_pcpu != smp_processor_id() )
>>> +on_selected_cpus(cpumask_of(vpmu->last_pcpu),
>>> + vpmu_clear_last, (void *)v, 1);
>> The cast here is pointless too. But considering your subsequent
>> reply this code may go away altogether anyway; if it doesn't,
>> explaining (in the commit message) why you need to use an IPI
>> here would seem necessary.
>
> If I do simply
> if (per_cpu(last_vcpu, vpmu->last_pcpu) == v)
> per_cpu(last_vcpu, vpmu->last_pcpu) = NULL
>
> then there is a (rather theoretical) possibility that between the test
> and subsequent clearing the remote cpu (i.e. vpmu->last_pcpu) will do
> load_vpmu() and then save_vpmu() for another VCPU. The former will clear
> last_vcpu and the latter will set last_vcpu to something else. And then
> the destroy_vpmu() will set it again to NULL, which is bad.
So how about using cmpxchg then?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
Hi Jan,
Any comments from you? It would be greatly appreciated if you can look
at this when you have time. Your comments are always important to me :)
Thanks,
Chao
On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote:
> Hi all, we plan to bring Intel CAT into XEN. This is the initial
> design for that. Comments/suggestions are welcome.
>
> Background
> ==
> Traditionally, all Virtual Machines ("VMs") share the same set of system
> cache resources. There is no hardware support to control allocation or
> availability of cache resources to individual VMs. The lack of such
> partition mechanism for cache resource makes the cache utilization for
> different types of VMs inefficient. While on the other side, more and
> more cache resources become available on modern server platforms.
>
> With the introduction of Intel Cache Allocation Technology ("CAT"), now
> Virtualization Machine Monitor ("VMM") has the ability to partition the
> cache allocation per VM, based on the priority of VM.
>
>
> CAT Introduction
>
> Generally speaking, CAT introduces a mechanism for software to enable
> cache allocation based on application priority or Class of Service
> ("COS"). Cache allocation for the respective applications is then
> restricted based on the COS with which they are associated. Each COS can
> be configured using capacity bitmasks ("CBM") which represent cache
> capacity and indicate the degree of overlap and isolation between
> classes. For each logical processor there is a register
> exposed(IA32_PQR_ASSOC MSR) to allow the OS/VMM to specify a COS when an
> application, thread or VM is scheduled. Cache allocation for the
> indicated application/thread/VM is then controlled automatically by the
> hardware based on the COS and the CBM associated with that class.
> Hardware initializes COS of each logical processor to 0 and the
> corresponding CBM is set to all-ones, means all the system cache
> resource can be used for each application.
>
> For more information please refer to Section 17.15 in the Intel SDM [1].
>
>
> Design Overview
> ===
> - Domain COS/CBM association
> When enforcing cache allocation for VMs, the minimum granularity is
> defined as the domain. All Virtual CPUs ("VCPUs") of a domain have the
> same COS, and therefore, correspond to the same CBM. COS is used only in
> hypervisor and is transparent to tool stack/user. System administrator
> can specify the initial CBM for each domain or change it at runtime using
> tool stack. Hypervisor then choses a free COS to associate it with that
> CBM or find a existed COS which has the same CBM.
>
> - VCPU Schedule
> When VCPU is scheduled on the physical CPU ("PCPU"), its COS value is
> then written to MSR (IA32_PQR_ASSOC) of PCPU to notify hardware to use
> the new COS. The cache allocation is then enforced by hardware.
>
> - Multi-Socket
> In multi-socket environment, each VCPU may be scheduled on different
> sockets. The hardware CAT ability(such as maximum supported COS and length
> of CBM) maybe different among sockets. For such system, per-socket COS/CBM
> configuration of a domain is specified. Hypervisor then use this per-socket
> CBM information for VCPU schedule.
>
>
> Implementation Description
> ==
> In this design, one principal is that only implementing the cache
> enforcement mechanism in hypervisor but leaving the cache allocation
> policy to user space tool stack. In this way some complex governors then
> can be implemented in tool stack.
>
> In summary, hypervisor changes include:
> 1) A new field "cat_info" in domain structure to indicate the CAT
>information for each socket. It points to array of structure:
>struct domain_socket_cat_info {
>unsigned int cbm; /* CBM specified by toolstack */
>unsigned int cos; /* COS allocated by Hypervisor */
>}
> 2) A new SYSCTL to expose the CAT information to tool stack:
> * Whether CAT is enabled;
> * Max COS supported;
> * Length of CBM;
> * Other needed information from host cpuid;
> 3) A new DOMCTL to allow tool stack to set/get CBM for a specified domain
>for each socket.
> 4) Context switch: write COS of domain to MSR (IA32_PQR_ASSOC) of PCPU.
> 5) XSM policy to restrict the functions visibility to control domain only.
>
> Hypervisor interfaces:
> 1) Boot line param: "psr=cat" to enable the feature.
> 2) SYSCTL: XEN_SYSCTL_psr_cat_op
> - XEN_SYSCTL_PSR_CAT_INFO_GET: Get system CAT information;
> 3) DOMCTL: XEN_DOMCTL_psr_cat_op
> - XEN_DOMCTL_PSR_CAT_OP_CBM_SET: Set CBM value for a domain.
> - XEN_DOMCTL_PSR_CAT_OP_CBM_GET: Get CBM value for a domain.
>
> xl interfaces:
> 1) psr-cat-show: Show system/runtime CAT information.
> => XEN_SYSCTL_PSR_CAT_INFO_GET/XEN_DOMCTL_PSR_CAT_OP_CBM_GET
> 2) psr-cat-cbm-set [dom] [cbm] [socket]: Set CBM for a domain.
> => XEN_DOMCTL_PSR_CAT_OP_CBM_SET
>
>
> Hardware Limitation & Performance Improve
Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.
On Mon, 2014-12-15 at 17:07 +, Anthony PERARD wrote:
> On Thu, Dec 11, 2014 at 04:23:15PM +, Ian Campbell wrote:
> > On Thu, 2014-12-11 at 16:16 +, Anthony PERARD wrote:
> > > On Tue, Dec 09, 2014 at 03:56:02PM +, Ian Campbell wrote:
> > > > On Tue, 2014-12-09 at 15:39 +, Anthony PERARD wrote:
> > > > > The path to the pty of a Xen PV console is set only in
> > > > > virDomainOpenConsole. But this is done too late. A call to
> > > > > virDomainGetXMLDesc done before OpenConsole will not have the path to
> > > > > the pty, but a call after OpenConsole will.
> > > > >
> > > > > e.g. of the current issue.
> > > > > Starting a domain with ''
> > > > > Then:
> > > > > virDomainGetXMLDesc():
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > virDomainOpenConsole()
> > > > > virDomainGetXMLDesc():
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The patch intend to have the TTY path on the first call of GetXMLDesc.
> > > > > This is done by setting up the path at domain start up instead of in
> > > > > OpenConsole.
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > >
> > > > > Signed-off-by: Anthony PERARD
> > > > >
> > > > > ---
> > > > > Change in V2:
> > > > > Adding bug report link.
> > > > > Reword the last part of the patch description.
> > > > > Cleanup the code.
> > > > > Use VIR_FREE before VIR_STRDUP.
> > > > > Remove the code from OpenConsole as it is now a duplicate.
> > > > > ---
> > > > > src/libxl/libxl_domain.c | 20
> > > > > src/libxl/libxl_driver.c | 15 ---
> > > > > 2 files changed, 20 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > > index 9c62291..325de79 100644
> > > > > --- a/src/libxl/libxl_domain.c
> > > > > +++ b/src/libxl/libxl_domain.c
> > > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr driver,
> > > > > virDomainObjPtr vm,
> > > > > if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > > > goto cleanup_dom;
> > > > >
> > > > > +if (vm->def->nconsoles) {
> > > > > +virDomainChrDefPtr chr = vm->def->consoles[0];
> > > >
> > > > Given vm->def->nconsoles should we loop and do them all?
> > >
> > > Maybe. libvirt it self will not be able to access any console that is
> > > not the first one (virDomainOpenConsole only provide access to console
> > > 0), but a consumer of libvirt could.
> > >
> > > > Also, and I really should know the answer to this (and sorry for not
> > > > thinking of it earlier), but:
> > > >
> > > > > +ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > > +chr->target.port,
> > > > > console_type,
> > > > > +&console);
> > > >
> > > > Might this race against xenconsoled writing the node to xenstore and
> > > > therefore be prone to failing when starting multiple guests all at once?
> > >
> > > I've look through out libxl, xenconsoled and libvirt, and I could not
> > > find any synchronisation point. So I guest it's possible.
> > >
> > > > Is there a hook which is called on virsh dumpxml which could update
> > > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > >
> > > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > > to do the check, or having a xenstore watch on the path (if that is
> > > possible).
> >
> > The aop_console_how option to libxl_domain_create_new and
> > libxl_domain_create_restore is documented as:
> >
> > /* A progress report will be made via ao_console_how, of type
> >* domain_create_console_available, when the domain's primary
> >* console is available and can be connected to.
> >*/
> >
> > Which sounds like exactly what is needed?
>
> It looks like the progress is reported before the main function finish,
> from the description of the type libxl_asyncprogress_how (in libxl.h).
Correct.
> Also, I tryied to use it, it works if xenconsoled is running. But if
> xenconsoled is not running, then the callback is also called and
> libxl_console_get_tty() return an empty string.
I'm not sure xenconsoled not running is a configuration we need to worry
about, or at least it could be expected not to get a console in that
case.
Unless by "not running" you meant bottlenecked or not keeping up
perhaps.
> Or, maybe my test case is not relevant, so another question: Will
> libxl wait for xenconsoled to process the new domain before calling the
> callback?
I don't see an explicit wait in the code, but I don't know if it has
arranged the sequencing some other way.
> Or, should I set the callback to NULL and have the
> domain_create_console_available event sent through
> the callback set by libxl_event_register_callbacks()?
That would make sense, except I don't see li
Re: [Xen-devel] [PATCH v2 for 4.5] x86/VPMU: Clear last_vcpu when destroying VPMU
>>> On 15.12.14 at 23:24, wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
>
> We have to do this via IPI since otherwise there is a (somewheat
> theoretical) chance that between test and subsequent clearing
> of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do
> both load_vpmu() and then save_vpmu() for another VCPU. The former
> will clear last_vcpu and the latter will set it to something else.
Apart from the question of using cmpxchg instead of the IPI (I can
see with the current model that using an IPI is the only clean way,
i.e. the alternative - if usable - would mean altering existing logic
too), please be sure such descriptions are accurate: There are no
functions with the names you mention, and vpmu_load() alters
last_vcpu only indirectly (via vpmu_save_force()).
> void vpmu_destroy(struct vcpu *v)
> {
> struct vpmu_struct *vpmu = vcpu_vpmu(v);
>
> +if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
> +return;
This appears to make unnecessary the respective checks in
amd_vpmu_destroy() and core2_vpmu_destroy().
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Cache Allocation Technology(CAT) design for XEN
>>> On 16.12.14 at 09:55, wrote: > Any comments from you? It would be greatly appreciated if you can look > at this when you have time. Your comments are always important to me :) I don't think I have to say much here: > On Fri, Dec 12, 2014 at 08:27:57PM +0800, Chao Peng wrote: >> Implementation Description >> == >> In this design, one principal is that only implementing the cache >> enforcement mechanism in hypervisor but leaving the cache allocation >> policy to user space tool stack. In this way some complex governors then >> can be implemented in tool stack. With this, the changes to the hypervisor ought to be quite limited, even if length of the list you give seems long at a first glance, and hence I'm fine with the concept. >> Hardware Limitation & Performance Improvement >> = >> As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context >> switch. If the change is frequent then hardware may fail to strictly >> enforce the cache allocation basing on the specified COS. This certainly would deserve a little more explanation: What's the value of the functionality if one can't rely on it being enforced by hardware at all times? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 32387: regressions - trouble: broken/fail/pass
flight 32387 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32387/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 32194 test-amd64-amd64-xl-qemut-win7-amd64 6 leak-check/basis(6) fail REGR. vs. 32194 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32194 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass 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-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-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail 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-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: qemuu54600752a1dd67844c2cf3c467db562c39499838 baseline version: qemuu45e1611de8be0eae55967694dd6e627c2dc354f2 People who touched revisions under test: Alex Bennée Amos Kong Anton Blanchard Antony Pavlov Bastian Koppelmann Christoffer Dall Dmitry Poletaev Dr. David Alan Gilbert Fabian Aggeler Fam Zheng Gary R Hook Gerd Hoffmann Gonglei Greg Bellows Jeff Cody Jun Li Kevin Wolf lijun Liviu Ionescu Markus Armbruster Max Reitz Michael Mueller Michael Tokarev Nikita Belov Paolo Bonzini Pavel Dovgalyuk Peter Maydell Richard Henderson Sergey Fedorov Stefan Hajnoczi Thomas Huth zhanghailiang 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-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 broken test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 broken 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-int
Re: [Xen-devel] xenstored crashes with SIGSEGV
On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> Hello Ian,
>
> On 15.12.2014 18:45, Ian Campbell wrote:
> > On Mon, 2014-12-15 at 14:50 +, Ian Campbell wrote:
> >> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> >>> I just noticed something strange:
> >>>
> #3 0x0040a684 in tdb_open (name=0xff 0xff out of bounds>, hash_size=0,
> tdb_flags=4254928, open_flags=-1, mode=3119127560) at tdb.c:1773
> ...
> > I'm reasonably convinced now that this is just a weird artefact of
> > running gdb on an optimised binary, probably a shortcoming in the debug
> > info leading to gdb getting confused.
> >
> > Unfortunately this also calls into doubt the parameter to talloc_free,
> > perhaps in that context 0xff000 is a similar artefact.
> >
> > Please can you print the entire contents of tdb in the second frame
> > ("print *tdb" ought to do it). I'm curious whether it is all sane or
> > not.
>
> (gdb) print *tdb
> $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
> 16711680,
> locked = 0xff00,
So it really does seem to be 0xff00 in memory.
> flags = 0,
> travlocks = {
> next = 0xff, off = 0, hash = 65280}, next = 0xff,
> device = 280375465082880, inode = 16711680, log_fn = 0x4093b0
> ,
> hash_fn = 0x4092f0 , open_flags = 2}
And here we can see tdb->{flags,open_flags} == 0 and 2, contrary to what
the stack trace says we were called with, which was nonsense. Since 0
and 2 are sensible and correspond to what the caller passes I think the
stack trace is just confused.
> (gdb) info registers
> rax0x0 0
> rbx0x16bff7023854960
> rcx0x -1
> rdx0x40ecd0 4254928
> rsi0x0 0
> rdi0xff00 280375465082880
And here it is in the registers.
> rbp0x7fcaed6c96a8 0x7fcaed6c96a8
> rsp0x7fff9dc86330 0x7fff9dc86330
> r8 0x7fcaece54c08 140509534571528
> r9 0xff00 -72057594037927936
> r100x7fcaed08c14c 140509536895308
> r110x246582
> r120xd 13
> r130xff00 280375465082880
And again.
> r140x4093b0 4232112
> r150x167d62023582240
> rip0x4075c4 0x4075c4
This must be the faulting address.
> eflags 0x10206 [ PF IF RF ]
> cs 0x33 51
> ss 0x2b 43
> ds 0x0 0
> es 0x0 0
> fs 0x0 0
> gs 0x0 0
> fctrl 0x0 0
> fstat 0x0 0
> ftag 0x0 0
> fiseg 0x0 0
> fioff 0x0 0
> foseg 0x0 0
> fooff 0x0 0
> fop0x0 0
> mxcsr 0x0 [ ]
>
> (gdb) disassemble
> Dump of assembler code for function talloc_chunk_from_ptr:
> 0x004075c0 : sub$0x8,%rsp
> 0x004075c4 : mov-0x8(%rdi),%edx
This is the line corresponding to %rip above which is doing a read via %
rdi, which is 0xff00.
It's reading tc->flags. It's been optimised, tc = pp - SIZE, so it is
loading *(pp-SIZE+offsetof(flags)), which is pp-8 (flags is the last
field in the struct).
So rdi contains pp which == the ptr given as an argument to the
function, so ptr was bogus.
So it seems we really do have tdb->locked containing 0xff00.
This is only allocated in one place which is:
tdb->locked = talloc_zero_array(tdb, struct tdb_lock_type,
tdb->header.hash_size+1);
midway through tdb_open_ex. It might be worth inserting a check+log for
this returning 0xff, 0xff00, 0xff ... 0xff00 etc.
> 0x004075c7 : lea-0x50(%rdi),%rax
This is actually calculating tc, ready for return upon success.
> 0x004075cb : mov%edx,%ecx
> 0x004075cd : and
> $0xfff0,%ecx
> 0x004075d0 : cmp$0xe814ec70,%ecx
> 0x004075d6 : jne0x4075e2
>
(tc->flags & ~0xF) != TALLOC_MAGIC
> 0x004075d8 : and$0x1,%edx
> 0x004075db : jne0x4075e2
>
tc->flags & TALLOC_FLAG_FREE
> 0x004075dd : add$0x8,%rsp
> 0x004075e1 : retq
Success, return.
> 0x004075e2 : nopw 0x0(%rax,%rax,1)
> 0x004075e8 : callq 0x401b98
The two TALLOC_ABORTS both end up here if the checks above fail.
> > Can you also "p $_siginfo._sifields._sigfault.si_addr" (in frame 0).
> > This ought to be the actual faulting address, which ought to give a hint
> > on how much we can trust the parameters in the stack trace.
>
> Hmm, my gdb refused to access $_siginfo:
> (gdb) show convenience
> $_siginfo = Unable to read siginfo
That's ok, I think I've convinced myself above what the crash is.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.o
[Xen-devel] [PATCH] xen/blkfront: increase the default value of xen_blkif_max_segments
The default maximum value of segments in indirect requests was 32, IO operations with bigger block size(>32*4k) would be split and performance start to drop. Nowadays backend device usually support 512k max_sectors_kb on desktop, and may larger on server machines with high-end storage system. The default size 128k was not very appropriate, this patch increases the default maximum value to 128(128*4k=512k). Signed-off-by: Bob Liu --- drivers/block/xen-blkfront.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2236c6f..1bf2429 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -94,9 +94,9 @@ static const struct block_device_operations xlvbd_block_fops; * by the backend driver. */ -static unsigned int xen_blkif_max_segments = 32; +static unsigned int xen_blkif_max_segments = 128; module_param_named(max, xen_blkif_max_segments, int, S_IRUGO); -MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 32)"); +MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 128)"); #define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in arch/x86/xen/xen-head.S
On 16/12/14 05:55, Juergen Gross wrote: > On 12/15/2014 01:05 PM, David Vrabel wrote: >> On 11/12/14 18:04, Juergen Gross wrote: >>> Instead of manually list each hypercall in arch/x86/xen/xen-head.S >>> use the auto generated symbol list. >>> >>> This also corrects the wrong address of xen_hypercall_mca which was >>> located 32 bytes higher than it should. >>> >>> Symbol addresses have been verified to match the correct ones via >>> objdump output. >> [...] >>> + >>> +#define HYPERCALL(n) \ >>> +.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \ >>> +.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32 >>> +#include >>> +#undef HYPERCALL >> >> The gas manual[1] suggests the syntax you've used for .type is invalid >> and suggest using .type , STT_FUNC > > Really? In the link below I see: > > The types supported are: > > STT_FUNC > function > Mark the symbol as being a function name. > ... > > So "function" seems to be okay. >From the manual The syntaxes supported are: .type STT_ .type ,# .type ,@ .type ,% .type ,"" And The first variant will be accepted by the GNU assembler on all architectures... David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote:
> (gdb) print *tdb
> $1 = {name = 0x0, map_ptr = 0x0, fd = 47, map_size = 65280, read_only =
> 16711680,
> locked = 0xff00, ecode = 16711680, header = {
> magic_food =
> "\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377\000\000\000\000\000\000\000\000\000\000\377\000\000\000\000\377",
> version = 0, hash_size = 0,
tdb->fd has been initialised, but version and hash_size have not yet.
This means we must have failed somewhere between the open() and the call
to tdb_new_database() (the second one, the first one is only if
TDB_INTERNAL, which is not the case here).
There are three interesting actions in that space.
The first is tdb_brlock, which could have gone wrong.
The second is ftruncate(). This is not a candidate because tdb->flags
doesn't have TDB_CLEAR_IF_FIRST (the actual test is on tdb_flags, which
is changed by the time of the stack trace, but it is stored in
tdb->flags where we can see it. tdb_flags isn't changed before the
check, so baring compiler problems I think we can rule that out).
The third is the read of the header itself. The fact that
tdb->header.magic_food isn't either all zeroes or the requisite magic
string "TDB file\n" is suspicious. Instead it is mostly zero with the
off 0xff in it. An interesting pattern of 0xff..00..00, may be a
coincidence, or not.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: increase the default value of xen_blkif_max_segments
El 16/12/14 a les 11.11, Bob Liu ha escrit: > The default maximum value of segments in indirect requests was 32, IO > operations with bigger block size(>32*4k) would be split and performance start > to drop. > > Nowadays backend device usually support 512k max_sectors_kb on desktop, and > may larger on server machines with high-end storage system. > The default size 128k was not very appropriate, this patch increases the > default > maximum value to 128(128*4k=512k). This looks fine, do you have any data/graphs to backup your reasoning? I would also add to the commit message that this change implies we can now have 32*128+32 = 4128 in-flight grants, which greatly surpasses the default amount of persistent grants blkback can handle, so the LRU in blkback will kick in. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote: > > I notice in your bugzilla (for a different occurrence, I think): > >> [2090451.721705] univention-conf[2512]: segfault at ff ip > >> 0045e238 sp 768dfa30 error 6 in python2.6[40+21e000] > > > > Which appears to have faulted access 0xff0 too. It looks like > > this process is a python thing, it's nothing to do with xenstored I > > assume? > > Yes, that's one univention-config, which is completely independent of > xen(stored). > > > It seems rather coincidental that it should be accessing the > > same sort of address and be faulting. > > Yes, good catch. I'll have another look at those core dumps. With this in mind, please can you confirm what model of machines you've seen this on, and in particular whether they are all the same class of machine or whether they are significantly different. The reason being that randomly placed 0xff values in a field of 0x00 could possibly indicate hardware (e.g. a GPU) DMAing over the wrong memory pages. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote: > On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote: > > > I notice in your bugzilla (for a different occurrence, I think): > > >> [2090451.721705] univention-conf[2512]: segfault at ff ip > > >> 0045e238 sp 768dfa30 error 6 in python2.6[40+21e000] > > > > > > Which appears to have faulted access 0xff0 too. It looks like > > > this process is a python thing, it's nothing to do with xenstored I > > > assume? > > > > Yes, that's one univention-config, which is completely independent of > > xen(stored). > > > > > It seems rather coincidental that it should be accessing the > > > same sort of address and be faulting. > > > > Yes, good catch. I'll have another look at those core dumps. > > With this in mind, please can you confirm what model of machines you've > seen this on, and in particular whether they are all the same class of > machine or whether they are significantly different. > > The reason being that randomly placed 0xff values in a field of 0x00 > could possibly indicate hardware (e.g. a GPU) DMAing over the wrong > memory pages. Thanks for giving me access to the core files. This is very suspicious: (gdb) frame 2 #2 0x0040a348 in tdb_open_ex (name=0x1941fb0 "/var/lib/xenstored/tdb.0x1935bb0", hash_size=, tdb_flags=0, open_flags=, mode=, log_fn=0x4093b0 , hash_fn=) at tdb.c:1958 1958SAFE_FREE(tdb->locked); (gdb) x/96x tdb 0x1921270: 0x 0x 0x 0x 0x1921280: 0x001f 0x00ff 0xff00 0x00ff 0x1921290: 0x 0x00ff 0xff00 0x00ff 0x19212a0: 0x 0x00ff 0xff00 0x00ff 0x19212b0: 0x 0x00ff 0xff00 0x00ff 0x19212c0: 0x 0x00ff 0xff00 0x00ff 0x19212d0: 0x 0x00ff 0xff00 0x00ff 0x19212e0: 0x 0x00ff 0xff00 0x00ff 0x19212f0: 0x 0x00ff 0xff00 0x00ff 0x1921300: 0x 0x00ff 0xff00 0x00ff 0x1921310: 0x 0x00ff 0xff00 0x00ff 0x1921320: 0x 0x00ff 0xff00 0x00ff 0x1921330: 0x 0x00ff 0xff00 0x00ff 0x1921340: 0x 0x 0xff00 0x00ff 0x1921350: 0x 0x00ff 0xff00 0x00ff 0x1921360: 0x 0x00ff 0xff00 0x00ff 0x1921370: 0x004093b0 0x 0x004092f0 0x 0x1921380: 0x0002 0x 0x0091 0x 0x1921390: 0x0193de70 0x 0x01963600 0x 0x19213a0: 0x 0x 0x0193fbb0 0x 0x19213b0: 0x 0x 0x 0x 0x19213c0: 0x00405870 0x 0x0040e3e0 0x 0x19213d0: 0x0038 0x 0xe814ec70 0x6f2f6567 0x19213e0: 0x01963650 0x 0x0193dec0 0x Something has clearly done a number on the ram of this process. 0x1921270 through 0x192136f is 256 bytes... Since it appears to be happening to other processes too I would hazard that this is not a xenstored issue. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen: use generated hypercall symbols in arch/x86/xen/xen-head.S
On 12/16/2014 11:24 AM, David Vrabel wrote: On 16/12/14 05:55, Juergen Gross wrote: On 12/15/2014 01:05 PM, David Vrabel wrote: On 11/12/14 18:04, Juergen Gross wrote: Instead of manually list each hypercall in arch/x86/xen/xen-head.S use the auto generated symbol list. This also corrects the wrong address of xen_hypercall_mca which was located 32 bytes higher than it should. Symbol addresses have been verified to match the correct ones via objdump output. [...] + +#define HYPERCALL(n) \ +.equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \ +.type xen_hypercall_##n, function; .size xen_hypercall_##n, 32 +#include +#undef HYPERCALL The gas manual[1] suggests the syntax you've used for .type is invalid and suggest using .type , STT_FUNC Really? In the link below I see: The types supported are: STT_FUNC function Mark the symbol as being a function name. ... So "function" seems to be okay. From the manual The syntaxes supported are: .type STT_ .type ,# .type ,@ .type ,% .type ,"" And The first variant will be accepted by the GNU assembler on all architectures... grepping through the x86 assembler sources .type ,@function seems to be the preferred syntax (100%). I think I'll switch to that. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
2014-12-16 11:06 GMT+00:00 Ian Campbell : > On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote: >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote: >> > > I notice in your bugzilla (for a different occurrence, I think): >> > >> [2090451.721705] univention-conf[2512]: segfault at ff ip >> > >> 0045e238 sp 768dfa30 error 6 in python2.6[40+21e000] >> > > >> > > Which appears to have faulted access 0xff0 too. It looks like >> > > this process is a python thing, it's nothing to do with xenstored I >> > > assume? >> > >> > Yes, that's one univention-config, which is completely independent of >> > xen(stored). >> > >> > > It seems rather coincidental that it should be accessing the >> > > same sort of address and be faulting. >> > >> > Yes, good catch. I'll have another look at those core dumps. >> >> With this in mind, please can you confirm what model of machines you've >> seen this on, and in particular whether they are all the same class of >> machine or whether they are significantly different. >> >> The reason being that randomly placed 0xff values in a field of 0x00 >> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong >> memory pages. > > Thanks for giving me access to the core files. This is very suspicious: > (gdb) frame 2 > #2 0x0040a348 in tdb_open_ex (name=0x1941fb0 > "/var/lib/xenstored/tdb.0x1935bb0", hash_size=, > tdb_flags=0, open_flags=, mode=, > log_fn=0x4093b0 , hash_fn=) at > tdb.c:1958 > 1958SAFE_FREE(tdb->locked); > > (gdb) x/96x tdb > 0x1921270: 0x 0x 0x 0x > 0x1921280: 0x001f 0x00ff 0xff00 0x00ff > 0x1921290: 0x 0x00ff 0xff00 0x00ff > 0x19212a0: 0x 0x00ff 0xff00 0x00ff > 0x19212b0: 0x 0x00ff 0xff00 0x00ff > 0x19212c0: 0x 0x00ff 0xff00 0x00ff > 0x19212d0: 0x 0x00ff 0xff00 0x00ff > 0x19212e0: 0x 0x00ff 0xff00 0x00ff > 0x19212f0: 0x 0x00ff 0xff00 0x00ff > 0x1921300: 0x 0x00ff 0xff00 0x00ff > 0x1921310: 0x 0x00ff 0xff00 0x00ff > 0x1921320: 0x 0x00ff 0xff00 0x00ff > 0x1921330: 0x 0x00ff 0xff00 0x00ff > 0x1921340: 0x 0x 0xff00 0x00ff > 0x1921350: 0x 0x00ff 0xff00 0x00ff > 0x1921360: 0x 0x00ff 0xff00 0x00ff > 0x1921370: 0x004093b0 0x 0x004092f0 0x > 0x1921380: 0x0002 0x 0x0091 0x > 0x1921390: 0x0193de70 0x 0x01963600 0x > 0x19213a0: 0x 0x 0x0193fbb0 0x > 0x19213b0: 0x 0x 0x 0x > 0x19213c0: 0x00405870 0x 0x0040e3e0 0x > 0x19213d0: 0x0038 0x 0xe814ec70 0x6f2f6567 > 0x19213e0: 0x01963650 0x 0x0193dec0 0x > > Something has clearly done a number on the ram of this process. > 0x1921270 through 0x192136f is 256 bytes... > > Since it appears to be happening to other processes too I would hazard > that this is not a xenstored issue. > > Ian. > Good catch Ian! Strange corruption. Probably not related to xenstored as you suggested. I would be curious to see what's before the tdb pointer and where does the corruption starts. I also don't understand where the "fd = 47" came from a previous mail. 0x1f is 31, not 47 (which is 0x2f). I would not be surprised about a strange bug in libc or the kernel. Frediano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.
On Tue, Dec 16, 2014 at 09:30:28AM +, Ian Campbell wrote:
> On Mon, 2014-12-15 at 17:07 +, Anthony PERARD wrote:
> > On Thu, Dec 11, 2014 at 04:23:15PM +, Ian Campbell wrote:
> > > On Thu, 2014-12-11 at 16:16 +, Anthony PERARD wrote:
> > > > On Tue, Dec 09, 2014 at 03:56:02PM +, Ian Campbell wrote:
> > > > > On Tue, 2014-12-09 at 15:39 +, Anthony PERARD wrote:
> > > > > > The path to the pty of a Xen PV console is set only in
> > > > > > virDomainOpenConsole. But this is done too late. A call to
> > > > > > virDomainGetXMLDesc done before OpenConsole will not have the path
> > > > > > to
> > > > > > the pty, but a call after OpenConsole will.
> > > > > >
> > > > > > e.g. of the current issue.
> > > > > > Starting a domain with ''
> > > > > > Then:
> > > > > > virDomainGetXMLDesc():
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > virDomainOpenConsole()
> > > > > > virDomainGetXMLDesc():
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The patch intend to have the TTY path on the first call of
> > > > > > GetXMLDesc.
> > > > > > This is done by setting up the path at domain start up instead of in
> > > > > > OpenConsole.
> > > > > >
> > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1170743
> > > > > >
> > > > > > Signed-off-by: Anthony PERARD
> > > > > >
> > > > > > ---
> > > > > > Change in V2:
> > > > > > Adding bug report link.
> > > > > > Reword the last part of the patch description.
> > > > > > Cleanup the code.
> > > > > > Use VIR_FREE before VIR_STRDUP.
> > > > > > Remove the code from OpenConsole as it is now a duplicate.
> > > > > > ---
> > > > > > src/libxl/libxl_domain.c | 20
> > > > > > src/libxl/libxl_driver.c | 15 ---
> > > > > > 2 files changed, 20 insertions(+), 15 deletions(-)
> > > > > >
> > > > > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > > > > index 9c62291..325de79 100644
> > > > > > --- a/src/libxl/libxl_domain.c
> > > > > > +++ b/src/libxl/libxl_domain.c
> > > > > > @@ -1290,6 +1290,26 @@ libxlDomainStart(libxlDriverPrivatePtr
> > > > > > driver, virDomainObjPtr vm,
> > > > > > if (libxlDomainSetVcpuAffinities(driver, vm) < 0)
> > > > > > goto cleanup_dom;
> > > > > >
> > > > > > +if (vm->def->nconsoles) {
> > > > > > +virDomainChrDefPtr chr = vm->def->consoles[0];
> > > > >
> > > > > Given vm->def->nconsoles should we loop and do them all?
> > > >
> > > > Maybe. libvirt it self will not be able to access any console that is
> > > > not the first one (virDomainOpenConsole only provide access to console
> > > > 0), but a consumer of libvirt could.
> > > >
> > > > > Also, and I really should know the answer to this (and sorry for not
> > > > > thinking of it earlier), but:
> > > > >
> > > > > > +ret = libxl_console_get_tty(priv->ctx, vm->def->id,
> > > > > > +chr->target.port,
> > > > > > console_type,
> > > > > > +&console);
> > > > >
> > > > > Might this race against xenconsoled writing the node to xenstore and
> > > > > therefore be prone to failing when starting multiple guests all at
> > > > > once?
> > > >
> > > > I've look through out libxl, xenconsoled and libvirt, and I could not
> > > > find any synchronisation point. So I guest it's possible.
> > > >
> > > > > Is there a hook which is called on virsh dumpxml which could update
> > > > > things on the fly (i.e. lookup the console iff it isn't already set)?
> > > >
> > > > I guest we could modify libxlDomainGetXMLDesc and libxlDomainOpenConsole
> > > > to do the check, or having a xenstore watch on the path (if that is
> > > > possible).
> > >
> > > The aop_console_how option to libxl_domain_create_new and
> > > libxl_domain_create_restore is documented as:
> > >
> > > /* A progress report will be made via ao_console_how, of type
> > >* domain_create_console_available, when the domain's primary
> > >* console is available and can be connected to.
> > >*/
> > >
> > > Which sounds like exactly what is needed?
> >
> > It looks like the progress is reported before the main function finish,
> > from the description of the type libxl_asyncprogress_how (in libxl.h).
>
> Correct.
>
> > Also, I tryied to use it, it works if xenconsoled is running. But if
> > xenconsoled is not running, then the callback is also called and
> > libxl_console_get_tty() return an empty string.
>
> I'm not sure xenconsoled not running is a configuration we need to worry
> about, or at least it could be expected not to get a console in that
> case.
>
> Unless by "not running" you meant bottlenecked or not keeping up
> perhaps.
Well, I did meant no xenconsoled process. But after, I also tried `kill
-STOP`, but the same things is happening.
> > Or, maybe my test case is not
Re: [Xen-devel] xenstored crashes with SIGSEGV
Hello, On 16.12.2014 11:45, Ian Campbell wrote: > On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote: >>> I notice in your bugzilla (for a different occurrence, I think): [2090451.721705] univention-conf[2512]: segfault at ff ip 0045e238 sp 768dfa30 error 6 in python2.6[40+21e000] >>> >>> Which appears to have faulted access 0xff0 too. It looks like >>> this process is a python thing, it's nothing to do with xenstored I >>> assume? >> >> Yes, that's one univention-config, which is completely independent of >> xen(stored). >> >>> It seems rather coincidental that it should be accessing the >>> same sort of address and be faulting. >> >> Yes, good catch. I'll have another look at those core dumps. > > With this in mind, please can you confirm what model of machines you've > seen this on, and in particular whether they are all the same class of > machine or whether they are significantly different. They are all from the same vendor, but I have to check the individual models and firmware versions, which might take some time. > The reason being that randomly placed 0xff values in a field of 0x00 > could possibly indicate hardware (e.g. a GPU) DMAing over the wrong > memory pages. Good catch: that would explain why it only happens for us and no one other has seen that strange bug before. Thanks you again. Philipp Hahn ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
On Tue, 2014-12-16 at 11:30 +, Frediano Ziglio wrote: > 2014-12-16 11:06 GMT+00:00 Ian Campbell : > > On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote: > >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote: > >> > > I notice in your bugzilla (for a different occurrence, I think): > >> > >> [2090451.721705] univention-conf[2512]: segfault at ff ip > >> > >> 0045e238 sp 768dfa30 error 6 in > >> > >> python2.6[40+21e000] > >> > > > >> > > Which appears to have faulted access 0xff0 too. It looks like > >> > > this process is a python thing, it's nothing to do with xenstored I > >> > > assume? > >> > > >> > Yes, that's one univention-config, which is completely independent of > >> > xen(stored). > >> > > >> > > It seems rather coincidental that it should be accessing the > >> > > same sort of address and be faulting. > >> > > >> > Yes, good catch. I'll have another look at those core dumps. > >> > >> With this in mind, please can you confirm what model of machines you've > >> seen this on, and in particular whether they are all the same class of > >> machine or whether they are significantly different. > >> > >> The reason being that randomly placed 0xff values in a field of 0x00 > >> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong > >> memory pages. > > > > Thanks for giving me access to the core files. This is very suspicious: > > (gdb) frame 2 > > #2 0x0040a348 in tdb_open_ex (name=0x1941fb0 > > "/var/lib/xenstored/tdb.0x1935bb0", hash_size=, > > tdb_flags=0, open_flags=, mode=, > > log_fn=0x4093b0 , hash_fn=) at > > tdb.c:1958 > > 1958SAFE_FREE(tdb->locked); > > > > (gdb) x/96x tdb > > 0x1921270: 0x 0x 0x 0x > > 0x1921280: 0x001f 0x00ff 0xff00 0x00ff > > 0x1921290: 0x 0x00ff 0xff00 0x00ff > > 0x19212a0: 0x 0x00ff 0xff00 0x00ff > > 0x19212b0: 0x 0x00ff 0xff00 0x00ff > > 0x19212c0: 0x 0x00ff 0xff00 0x00ff > > 0x19212d0: 0x 0x00ff 0xff00 0x00ff > > 0x19212e0: 0x 0x00ff 0xff00 0x00ff > > 0x19212f0: 0x 0x00ff 0xff00 0x00ff > > 0x1921300: 0x 0x00ff 0xff00 0x00ff > > 0x1921310: 0x 0x00ff 0xff00 0x00ff > > 0x1921320: 0x 0x00ff 0xff00 0x00ff > > 0x1921330: 0x 0x00ff 0xff00 0x00ff > > 0x1921340: 0x 0x 0xff00 0x00ff > > 0x1921350: 0x 0x00ff 0xff00 0x00ff > > 0x1921360: 0x 0x00ff 0xff00 0x00ff > > 0x1921370: 0x004093b0 0x 0x004092f0 0x > > 0x1921380: 0x0002 0x 0x0091 0x > > 0x1921390: 0x0193de70 0x 0x01963600 0x > > 0x19213a0: 0x 0x 0x0193fbb0 0x > > 0x19213b0: 0x 0x 0x 0x > > 0x19213c0: 0x00405870 0x 0x0040e3e0 0x > > 0x19213d0: 0x0038 0x 0xe814ec70 0x6f2f6567 > > 0x19213e0: 0x01963650 0x 0x0193dec0 0x > > > > Something has clearly done a number on the ram of this process. > > 0x1921270 through 0x192136f is 256 bytes... > > > > Since it appears to be happening to other processes too I would hazard > > that this is not a xenstored issue. > > > > Ian. > > > > Good catch Ian! > > Strange corruption. Probably not related to xenstored as you > suggested. I would be curious to see what's before the tdb pointer and > where does the corruption starts. (gdb) print tdb $2 = (TDB_CONTEXT *) 0x1921270 (gdb) x/64x 0x1921200 0x1921200: 0x01921174 0x 0x 0x 0x1921210: 0x01921174 0x 0x0171 0x 0x1921220: 0x 0x 0x 0x 0x1921230: 0x01941f60 0x 0x 0x 0x1921240: 0x 0x 0x 0x6f630065 0x1921250: 0x 0x 0x0040e8a7 0x 0x1921260: 0x0118 0x 0xe814ec70 0x 0x1921270: 0x 0x 0x 0x 0x1921280: 0x001f 0x00ff 0xff00 0x00ff 0x1921290: 0x 0x00ff 0xff00 0x00ff 0x19212a0: 0x 0x00ff 0xff00 0x00ff 0x19212b0: 0x 0x00ff
Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.
Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console
on domain startup."):
> On Tue, Dec 16, 2014 at 09:30:28AM +, Ian Campbell wrote:
> > Unless by "not running" you meant bottlenecked or not keeping up
> > perhaps.
>
> Well, I did meant no xenconsoled process. But after, I also tried `kill
> -STOP`, but the same things is happening.
I think this is a bug. I imagine that you can cause `xl create -c' to
malfunction too.
> > > Or, should I set the callback to NULL and have the
> > > domain_create_console_available event sent through
> > > the callback set by libxl_event_register_callbacks()?
> >
> > That would make sense, except I don't see libxl_evdisable_foo for these
> > events, so I'm not sure it is possible.
>
> Well, the domain_create_console_available event is report by
> libxl__ao_progress_report which will either callback() or call
> libxl__event_occurred(). So does not seams better to set callback to
> NULL.
The console available notification is only available via the ao
progress mechanism. So you have to pass a non-NULL aop_console_how,
and the notification will always be generated during the create.
Your options for having the notification delivered are:
I. aop_console_how->callback != NULL:
libxl will call
aop_console_how->callback(aop_console_how->for_callback)
II. aop_console_how->callback == NULL:
libxl will construct an libxl_event *event with
event->domid = the domid of the domain being constructed
event->domuuid = its uuid
event->for_user = aop_console_how->for_event
event->type = LIBXL_EVENT_TYPE_DOMAIN_CREATE_CONSOLE_AVAILABLE
What happens to that event depends on whether and how
libxl_event_register_callbacks has been called.
II(a): If libxl_event_register_callbacks(,hooks,user) was called
and also the bit is set ie
!!(hooks->event_occurs_mask
& (1UL << LIBXL_EVENT_TYPE_DOMAIN_CREATE_CONSOLE_AVAILABLE)):
libxl will call
hooks->event_occurs(user,event)
II(b): If libxl_event_register_callbacks(,hooks,user) was NOT called
or if the bit is clear:
libxl will queue the event for retrieval by libxl_event_check
or libxl_event-wait. (And if the application doesn't call those,
the application will never be notified; the event will be
retained until the libxl ctx is destroyed and then discarded.)
I mention all of these for completeness, and for future reference for
anyone reading the archives later.
In libxl you want option I.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.
Ian Jackson writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console on
domain startup."):
> I mention all of these for completeness, and for future reference for
> anyone reading the archives later.
>
> In libxl you want option I.
I mean `in xl you want option I'. In libvirt you probably want that
too.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.
On Tue, 2014-12-16 at 12:36 +, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [Xen-devel] [PATCH V2] libxl: Set path to console
> on domain startup."):
> > On Tue, Dec 16, 2014 at 09:30:28AM +, Ian Campbell wrote:
> > > Unless by "not running" you meant bottlenecked or not keeping up
> > > perhaps.
> >
> > Well, I did meant no xenconsoled process. But after, I also tried `kill
> > -STOP`, but the same things is happening.
>
> I think this is a bug. I imagine that you can cause `xl create -c' to
> malfunction too.
Presumably the libxl side fix is to register an ev_xswatch (and an
ev_timeout) on the console path (which differs by guest type, see guts
of libxl_console_get_tty) and call the callback out of that instead of
directly at the end of domcreate_
Depending on how racy this is (not very, I suspect) libvirt could ignore
this possibility and assume the event works (and we'll independently fix
it so it always does), or it could be a bit belt and braces and in
addition to handling the callback also check for NULL and-recheck on the
libvirt internal accessors.
Anthony, you should also note that the callback can happen more than
once, e.g. if you are using pygrub you get it once for the bootloader
pty and then again for the actual guests pty.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] dom0 reboot hangs with VMs created with libxl
I am running Ubuntu's xen 4.4 (4.4.1-0ubuntu0.14.04.2), but creating VMs with libxl. When I do a 'shutdown -r' or similar with no VMs running, dom0 reboots fine. When I do this with one or more VMs running, I get: "INFO: task reboot:11897 blocked for more than 120 seconds." repeatedly, and the machine never reboots. I'm taking this is because nothing is forcibly destroying the VMs running. I think this is a bug, but I'm not sure whether it's solely a bug in the Debian / Ubuntu packaging. What is meant to destroy VMs on a clean reboot? -- Alex Bligh ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 32391: regressions - trouble: broken/fail/pass
flight 32391 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32391/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl5 xen-boot fail REGR. vs. 32348 test-armhf-armhf-xl 3 host-install(3) broken REGR. vs. 32348 test-amd64-i386-xl-multivcpu 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-rumpuserxen-i386 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-qemuu-rhel6hvm-amd 5 xen-bootfail REGR. vs. 32348 test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 32348 test-armhf-armhf-libvirt 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-freebsd10-i386 5 xen-bootfail REGR. vs. 32348 test-amd64-i386-xl-qemut-win7-amd64 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-qemut-rhel6hvm-amd 5 xen-bootfail REGR. vs. 32348 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 32348 test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 32348 test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-xl-winxpsp3 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-xl-qemuu-winxpsp3 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-xl-winxpsp3-vcpus1 5 xen-bootfail REGR. vs. 32348 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 32348 test-amd64-i386-xl-win7-amd64 5 xen-boot fail REGR. vs. 32348 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 5 xen-boot fail blocked in 32348 test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail blocked in 32348 test-amd64-i386-xl-credit25 xen-boot fail blocked in 32348 test-amd64-amd64-rumpuserxen-amd64 8 guest-startfail blocked in 32348 test-amd64-amd64-xl 9 guest-start fail blocked in 32348 test-amd64-amd64-xl-sedf 15 guest-localmigrate/x10 fail blocked in 32348 test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail blocked in 32348 test-amd64-i386-rhel6hvm-intel 5 xen-boot fail blocked in 32348 test-amd64-i386-qemuu-rhel6hvm-intel 5 xen-boot fail blocked in 32348 test-amd64-i386-xl-qemuu-ovmf-amd64 5 xen-boot fail blocked in 32348 test-amd64-amd64-pair16 guest-start/debian fail blocked in 32348 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-installfail blocked in 32348 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-installfail blocked in 32348 Tests which did not succeed, but are not blocking: 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-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-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-winxpsp3 14 guest-stop fail never pass version targeted for testing: linux15229b5a1674f7096a547f590f2c70a2a86ae744 baseline version: linux9ea18f8cab5f1c36cdd0f09717e35ceb48c36a87 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 fail test-armhf-armhf-xl broken test-amd64-i386-xl fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemut-rhel6hvm-amd fail test-amd64-
Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for generating hypercall depending symbols
On 12/15/2014 12:38 PM, David Vrabel wrote:
On 11/12/14 18:04, Juergen Gross wrote:
Today there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.
Does arm and arm64 need something similar? If so are the tools here
suitable for them?
I don't think arm* needs this. But in case it does, the tools would
support arm as well.
Juergen
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
Why are these changes here and not in arch/x86/xen/Makefile?
@@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR $@
quiet_cmd_systbl = SYSTBL $@
cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
+quiet_cmd_hypercalls = HYPERCALLS $@
+ cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
+
syshdr_abi_unistd_32 := i386
$(uapi)/unistd_32.h: $(syscall32) $(syshdr)
$(call if_changed,syshdr)
@@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
$(out)/syscalls_64.h: $(syscall64) $(systbl)
$(call if_changed,systbl)
+$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
+ $(call if_changed,hypercalls)
+
+$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
The generated header should end up in asm/xen/
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+ eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+ END {for (i in v) if (!(v[i] in v))
+ print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
Include a comment in the generated output saying what generated it. e.g.,
/* auto-generated by scripts/xen-hypercall.sh */
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: build infrastructure for generating hypercall depending symbols
On 15/12/14 11:47, Jan Beulich wrote: On 15.12.14 at 12:38, wrote: >> On 11/12/14 18:04, Juergen Gross wrote: >>> --- a/arch/x86/syscalls/Makefile >>> +++ b/arch/x86/syscalls/Makefile >> >> Why are these changes here and not in arch/x86/xen/Makefile? > > Because this needs to be done in a step that (afaict) has no hook > in the Xen-specific Makefile. > >>> @@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl) >>> $(out)/syscalls_64.h: $(syscall64) $(systbl) >>> $(call if_changed,systbl) >>> >>> +$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh >>> + $(call if_changed,hypercalls) >>> + >>> +$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h >> >> The generated header should end up in asm/xen/ > > Why is generated/asm/ not good enough? I meant something like generated/asm/xen/hypercall-macros.h So a "xen/" prefix which is consistent with all the other xen specific headers. But if this is non-trivial it's not a major issue. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for 4.5] x86/VPMU: Clear last_vcpu when destroying VPMU
On 12/16/2014 04:31 AM, Jan Beulich wrote: On 15.12.14 at 23:24, wrote: We need to make sure that last_vcpu is not pointing to VCPU whose VPMU is being destroyed. Otherwise we may try to dereference it in the future, when VCPU is gone. We have to do this via IPI since otherwise there is a (somewheat theoretical) chance that between test and subsequent clearing of last_vcpu the remote processor (i.e. vpmu->last_pcpu) might do both load_vpmu() and then save_vpmu() for another VCPU. The former will clear last_vcpu and the latter will set it to something else. Apart from the question of using cmpxchg instead of the IPI (I can see with the current model that using an IPI is the only clean way, i.e. the alternative - if usable - would mean altering existing logic too), You mean something like struct vcpu **last = &per_cpu(last_vcpu, vpmu->last_pcpu); cmpxchg(last, v, NULL); Yes, that could work. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 32413: all pass - PUSHED
flight 32413 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32413/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 2c9e812bc368cb68a6249b99b1fb51ef3299d81c
baseline version:
rumpuserxen d40acc2019bd352e1de13842459b5fecf5bc565e
People who touched revisions under test:
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 pass
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=2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ . 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
2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ branch=rumpuserxen
+ revision=2c9e812bc368cb68a6249b99b1fb51ef3299d81c
+ . 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
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ 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/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ :
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : 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
++
Re: [Xen-devel] xenstored crashes with SIGSEGV
2014-12-16 12:23 GMT+00:00 Ian Campbell : > On Tue, 2014-12-16 at 11:30 +, Frediano Ziglio wrote: >> 2014-12-16 11:06 GMT+00:00 Ian Campbell : >> > On Tue, 2014-12-16 at 10:45 +, Ian Campbell wrote: >> >> On Mon, 2014-12-15 at 23:29 +0100, Philipp Hahn wrote: >> >> > > I notice in your bugzilla (for a different occurrence, I think): >> >> > >> [2090451.721705] univention-conf[2512]: segfault at ff ip >> >> > >> 0045e238 sp 768dfa30 error 6 in >> >> > >> python2.6[40+21e000] >> >> > > >> >> > > Which appears to have faulted access 0xff0 too. It looks like >> >> > > this process is a python thing, it's nothing to do with xenstored I >> >> > > assume? >> >> > >> >> > Yes, that's one univention-config, which is completely independent of >> >> > xen(stored). >> >> > >> >> > > It seems rather coincidental that it should be accessing the >> >> > > same sort of address and be faulting. >> >> > >> >> > Yes, good catch. I'll have another look at those core dumps. >> >> >> >> With this in mind, please can you confirm what model of machines you've >> >> seen this on, and in particular whether they are all the same class of >> >> machine or whether they are significantly different. >> >> >> >> The reason being that randomly placed 0xff values in a field of 0x00 >> >> could possibly indicate hardware (e.g. a GPU) DMAing over the wrong >> >> memory pages. >> > >> > Thanks for giving me access to the core files. This is very suspicious: >> > (gdb) frame 2 >> > #2 0x0040a348 in tdb_open_ex (name=0x1941fb0 >> > "/var/lib/xenstored/tdb.0x1935bb0", hash_size=, >> > tdb_flags=0, open_flags=, mode=, >> > log_fn=0x4093b0 , hash_fn=) at >> > tdb.c:1958 >> > 1958SAFE_FREE(tdb->locked); >> > >> > (gdb) x/96x tdb >> > 0x1921270: 0x 0x 0x 0x >> > 0x1921280: 0x001f 0x00ff 0xff00 0x00ff >> > 0x1921290: 0x 0x00ff 0xff00 0x00ff >> > 0x19212a0: 0x 0x00ff 0xff00 0x00ff >> > 0x19212b0: 0x 0x00ff 0xff00 0x00ff >> > 0x19212c0: 0x 0x00ff 0xff00 0x00ff >> > 0x19212d0: 0x 0x00ff 0xff00 0x00ff >> > 0x19212e0: 0x 0x00ff 0xff00 0x00ff >> > 0x19212f0: 0x 0x00ff 0xff00 0x00ff >> > 0x1921300: 0x 0x00ff 0xff00 0x00ff >> > 0x1921310: 0x 0x00ff 0xff00 0x00ff >> > 0x1921320: 0x 0x00ff 0xff00 0x00ff >> > 0x1921330: 0x 0x00ff 0xff00 0x00ff >> > 0x1921340: 0x 0x 0xff00 0x00ff >> > 0x1921350: 0x 0x00ff 0xff00 0x00ff >> > 0x1921360: 0x 0x00ff 0xff00 0x00ff >> > 0x1921370: 0x004093b0 0x 0x004092f0 0x >> > 0x1921380: 0x0002 0x 0x0091 0x >> > 0x1921390: 0x0193de70 0x 0x01963600 0x >> > 0x19213a0: 0x 0x 0x0193fbb0 0x >> > 0x19213b0: 0x 0x 0x 0x >> > 0x19213c0: 0x00405870 0x 0x0040e3e0 0x >> > 0x19213d0: 0x0038 0x 0xe814ec70 0x6f2f6567 >> > 0x19213e0: 0x01963650 0x 0x0193dec0 0x >> > >> > Something has clearly done a number on the ram of this process. >> > 0x1921270 through 0x192136f is 256 bytes... >> > >> > Since it appears to be happening to other processes too I would hazard >> > that this is not a xenstored issue. >> > >> > Ian. >> > >> >> Good catch Ian! >> >> Strange corruption. Probably not related to xenstored as you >> suggested. I would be curious to see what's before the tdb pointer and >> where does the corruption starts. > > (gdb) print tdb > $2 = (TDB_CONTEXT *) 0x1921270 > (gdb) x/64x 0x1921200 > 0x1921200: 0x01921174 0x 0x 0x > 0x1921210: 0x01921174 0x 0x0171 0x > 0x1921220: 0x 0x 0x 0x 0x0 next (u64) 0x0 prev (u64) > 0x1921230: 0x01941f60 0x 0x 0x 0x01941f60 parent (u64), make sense is not NULL 0x0 child (u64) > 0x1921240: 0x 0x 0x 0x6f630065 0x0 refs (u64) 0x0 null_refs (u32) 0x6f630065 pad, garbage (u32) > 0x1921250: 0x 0x 0x0040e8a7 0x 0x0 destructor (u64) 0x0040e8a7 name (u64) > 0x1921260: 0x0118 0x 0xe814ec70 0x000
[Xen-devel] Xen 4.5 Development Update (RC4)
Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then we have the General Release on Jan 7th! Details for the test-day are at http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions In terms of bugs, we have: #11 qxl hypervisor support #13 Re: [Xen-devel] man page example: xm block-attach #18 xl improve support for migration over non-sshlike tunnels #19 xl migrate transport improvements #22 xl does not support specifying virtual function for passthrough device #23 Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks #24 xl missing support for encrypted VNC #27 Re: [Xen-devel] xend vs xl with pci=['' are not owned by pciback or pcistub will still launch. #28 support PCI hole resize in qemu-xen [ 'mmio_hole' fix it, but the ultimate way is to fix it in QEMU] #30 libxl should implement non-suspend-cancel based resume path #36 credit2 only uses one runqueue instead of one runq per socket #38 Implement VT-d large pages so we can avoid sharing between EPT #40 linux pvops: fpu corruption due to incorrect assumptions #42 "linux, S3 resume of PVHVM fails - missing call to xen_arch_post_suspend?" #43 "30s delay loading xenfb driver on some systems" #44 Security policy ambiguities - XSA-108 process post-mortem #45 arm: domain 0 disables clocks which are in fact being used #46 qemu-upstream: limitation on 4 emulated NICs prevents guest from starting unless PV override is used. = Timeline = We wer planning on a 9-month release cycle - but it is more like an 10 month. Based on that, below are the estimated dates: * Feature Freeze: 24th September 2014 * First RC: 24th October [Friday!] * RC2: Nov 11th * RC2 Test-day: Nov 13th * RC3: Dec 3rd. * RC3 Test-day: Dec 4th * RC4: Dec 15th < WE ARE HERE ===> * RC4 Test-day: Dec 17th Release Date: Jan 7th. The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none -> fair -> ok -> good -> done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the code freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us achieve goals 1-3 above better than not doing so, feel free to make your case. = Open = == Known issues == == Linux == * Linux block multiqueue (ok) v2 posted. - Arianna Avanzini * VPMU - 'perf' support in Linux (ok) Depends on Xen patches Acked by David Vrabel - Boris Ostrovsky * vNUMA in Linux (ok) v6 posted git://gitorious.org/vnuma/linux_vnuma.git - Elena Ufimtseva * vsyscall in Linux (fair) - Konrad Rzeszutek Wilk * COLO Agent in Linux (fair) - Gui Jianfeng - Yang Hongyang - Dong, Eddie == FreeBSD == * PVH FreeBSD dom0 (ok) FreeBSD 11 goal. Toolstack side done in Xen 4.5 - Roger Pau Monné == Other OSes (MiniOS, QNX) == * PV drivers for automotive kernels (fair) - Artem Mygaiev * mini-os: xenbus changes for rump kernels (ok) git://xenbits.xen.org/people/iwj/rumpuser-xen.git branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1 v2 posted - Ian Jackson == GRUB2 == * GRUB2 multiboot2 (fair) - Daniel Kiper == OSSTEST == * OSSTest: libvirt (good) - Ian Campbell == Deferred to QEMU v2.next == * Using qemu-upstream in a stubdomain (fair) Will use rump kernels. - Ian Jackson * AMD Radeon PCI GPU passthrough (none) Focusing on Xen 4.2 and qemu-traditional - Kelly Zytaruk * Intel IGD PCI GPU passthrough (ok) v5 posted - Chen, Tiejun * Update Xen tree to use upstream OVMF (fair) - Anthony PERARD == Deferred to Xen hypervisor 4.6 == * xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good) v7 posted. Treating pieces as bug-fixes only. Low likehood of making it in Xen 4.5. Deferred - Tiejun Chen * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky * Xen Boot Information (xbi) (ok) Dependency for GRUB2 + EFI work http://lists.xen.org/archives/html/xen-devel/2014-10/msg02068.html v4, No go for full patchset. Only some of the patches. No ARM EFI hardware (yet) available to test them. - Daniel Kiper * PVH - AMD hardware support. (fair) Posted. -
[Xen-devel] Xen's Linux kernel config options V2
Hi, This is a design proposal for a rework of the config options on the Linux kernel which are related to Xen. The need to do so arose from the fact that it is currently not possible to build the Xen frontend drivers for a non-pvops kernel, e.g. to run them in a HVM-domain. There are more drawbacks in the current config options to which I'll come later. Current Xen related config options are as follows: Option Selects Depends - XEN PARAVIRT_CLOCK(x86) PARAVIRT(x86) XEN_HAVE_PVMMU(x86) SWIOTLB_XEN(arm,arm64) PCI_XEN(x86) SWIOTLB_XEN XEN_DOM0 PCI_XEN(x86) XEN_BACKEND XEN_BLKDEV_BACKEND XEN_PCIDEV_BACKEND(x86) XEN_SCSI_BACKEND XEN_NETDEV_BACKEND XEN_ACPI_HOTPLUG_MEMORY XEN_STUB XEN_ACPI_HOTPLUG_CPUXEN_STUB XEN_MCE_LOG(x86) XEN_PVHVM(x86) XEN_PVH(x86) XEN_MAX_DOMAIN_MEMORY(x86) XEN_SAVE_RESTORE(x86) XEN_DEBUG_FS(x86) XEN_FBDEV_FRONTENDXEN_XENBUS_FRONTEND INPUT_XEN_KBDDEV_FRONTEND XEN_BLKDEV_FRONTEND XEN_XENBUS_FRONTEND HVC_XEN HVC_XEN_FRONTENDXEN_XENBUS_FRONTEND TCG_XEN XEN_XENBUS_FRONTEND XEN_PCIDEV_FRONTEND PCI_XEN XEN_XENBUS_FRONTEND XEN_SCSI_FRONTEND XEN_XENBUS_FRONTEND INPUT_XEN_KBDDEV_FRONTEND XEN_XENBUS_FRONTEND XEN_WDT XEN_BALLOON XEN_SELFBALLOONING XEN_TMEM XEN_BALLOON_MEMORY_HOTPLUG XEN_SCRUB_PAGES XEN_DEV_EVTCHN XENFS XEN_PRIVCMD XEN_COMPAT_XENFS XEN_SYS_HYPERVISOR XEN_XENBUS_FRONTEND XEN_GNTDEV XEN_GRANT_DEV_ALLOC SWIOTLB_XEN XEN_TMEM(x86) XEN_PRIVCMD XEN_STUB(x86_64) BROKEN XEN_ACPI_PROCESSOR(x86) XEN_HAVE_PVMMU XEN_EFI(x64) XEN_NETDEV_FRONTEND XEN_XENBUS_FRONTEND Legend: - The first column are the Xen config options. Indentation in this column reflects the dependency between those options (e.g. XEN_SCSI_BACKEND depends on XEN_BACKEND, which in turn depends on XEN_DOM0, which depends on XEN). - The second column shows the options which are selected automatically if the corresponding option in the first column is configured. - The last column shows additional dependencies which can't be shown via the indentation level of the first column. - Some options or dependencies are architecture specific, they are listed in brackets (e.g. XEN_TMEM which is available for x86 only). - Non-Xen options are mentioned only if they seem to be really relevant, like e.g. PARAVIRT or BROKEN. There are several reasons to change the config options: - Be able to build Xen frontend drivers for HVM domains without the need for choosing a pvops kernel: currently the frontend drivers need XEN configured which depends on PARAVIRT. - Be able to build a Dom0 using XEN_PVH without having to configure XEN_HAVE_PVMMU. - Be able to build HVM driver domains. - Some features are available for x86 only, in spite of being not architecture specific, e.g. XEN_DEBUG_FS or XEN_TMEM. After some feedback for the first draft I'd suggest the following: Option Selects Depends -- XEN XEN_PV(x86) XEN_HAVE_PVMMU PARAVIRT PARAVIRT_CLOCK XEN_PVH(x86) XEN_PVHVM PARAVIRT PARAVIRT_CLOCK XEN_PVHVM PARAVIRT PARAVIRT_CLOCK XEN_BACKEND SWIOTLB_XEN(arm,arm64) XEN_PV(x86) || XEN_PVH(x86) || XEN_PVHVM XEN_BLKDEV_BACKEND XEN_PCIDEV_BACKEND(x86) XEN_SCSI_BACKEND XEN_NETDEV_BACKEND PCI_XEN(x86) SWIOTLB_XEN XEN_DOM0 XEN_BACKEND XEN_PV(x86) || PCI_XEN(x86)XEN_PVH(x86) XEN_ACPI_HOTPLUG_MEMORY XEN_STUB XEN_ACPI_HOTPLUG_CPUXEN_STUB XEN_MCE_LOG(x86) XEN_MAX_DOMAIN_MEMORY(x86) XEN_SAVE_RESTORE(x86) XEN_DEBUG_FS XEN_WDT XEN_BALLOON XEN_SELFBALLOONING XEN_TMEM XEN_BALLOON_MEMORY_HOTPLUG XEN_SCRUB_PAGES XENFS XEN_PRIVCMD XEN_COMPAT_XENFS XEN_SYS_HYPERVISOR XEN_DEV_EVTCHN XEN_GNTDEV XEN_GRANT_DEV_ALLOC SWIOTLB_XEN XEN_TMEM
Re: [Xen-devel] xenstored crashes with SIGSEGV
On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote: > What does "info all-registers" gdb command say about SSE registers? All zeroes. No ffs anywhere. > Do we have a bug in Xen that affect SSE instructions (possibly already > fixed after Philipp version) ? Possibly. When this was thought to be xenstored (which doesn't change all that much) debugging 4.1 seemed plausible, but since it could be anywhere else I think we either need a plausible reproduction, or a repro on a newer hypervisor (or possibly kernel) I'm afraid. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4)
On Tue, Dec 16, konrad.w...@oracle.com wrote: > In terms of bugs, we have: ... systemd SELinux, but its not listed. Whats your plan with the failures you see? Should I continue to be concerned about that, or will all the be postponed to 4.6? Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
2014-12-16 16:23 GMT+00:00 Ian Campbell : > On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote: >> What does "info all-registers" gdb command say about SSE registers? > > All zeroes. No ffs anywhere. > Could be that core does not dump these registers for some reasons? On my machine I got some FFs even just before the main is reached. >> Do we have a bug in Xen that affect SSE instructions (possibly already >> fixed after Philipp version) ? > > Possibly. When this was thought to be xenstored (which doesn't change > all that much) debugging 4.1 seemed plausible, but since it could be > anywhere else I think we either need a plausible reproduction, or a > repro on a newer hypervisor (or possibly kernel) I'm afraid. > > Ian. > I found these 1) https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.2.8 2) https://sourceware.org/bugzilla/show_bug.cgi?id=16064 1 seems to indicate a problem with kernel 3.2. Second with glibc 2.18. First we (I'll try when I reach home) can check if memset in glibc (or the version called from talloc_zero) can use SSE. A possible dmesg output and /proc/cpuinfo content could help too but I think SSE are now quite common. For the reproduction could be that a program doing some memset(0) continuously while another fill SSE register with garbage could help... at least if they execute on the same CPU (so could be limiting Xen to one CPU). Also doing some FPU operation which could lead to exception could help too. Frediano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.10 test] 32390: regressions - trouble: blocked/broken/fail/pass
flight 32390 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32390/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-intel 5 xen-bootfail pass in 32359 test-amd64-amd64-xl-sedf 9 guest-startfail in 32359 pass in 32390 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail in 32359 pass in 32390 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 3 host-install(3)broken blocked in 26303 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: 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-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xl-qemuu-win7-amd64 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-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-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-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: linux2f9ac85b35cce77eb36e415f8f7a36aefb7d977d baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 797 people touched revisions under test, not listing them all 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 broken build-i386-rumpuserxen pass 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 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass 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-amd64
[Xen-devel] [libvirt test] 32414: tolerable FAIL - PUSHED
flight 32414 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32414/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
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
version targeted for testing:
libvirt a93a3b975cd0bad37ccae508d9b7a69aa72b6181
baseline version:
libvirt c5a54917d5ae97653d29dbfe4995f2efcf5717d6
People who touched revisions under test:
Daniel P. Berrange
Dmitry Guryanov
Erik Skultety
Laine Stump
Luyao Huang
Michal Privoznik
Wang Rui
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
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt
a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ branch=libvirt
+ revision=a93a3b975cd0bad37ccae508d9b7a69aa72b6181
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
+++ besteffort_repo git://git.sv.gnu.org/gnulib.git
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ cached_repo git://git.sv.gnu.org/gnulib.git '[fetch=try]'
+++ local repo=git://git.sv.gnu.org/gnulib.git
+++ 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/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ :
'git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]'
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
Re: [Xen-devel] [PATCH v2] xen/serial: setup UART idle mode for OMAP
On Tue, 2014-12-09 at 11:26 -0500, Konrad Rzeszutek Wilk wrote: > > I'm fully happy with proposed wording (and want the both bits to be used) Done and committed. > > > > > Konrad, this is a bug fix for a particular piece of hardware, it can't > > > affect anything other than the OMAP ARM platform. > > OK, RElease-Acked-by: Konrad Rzeszutek Wilk Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.5 1/3] python/xc: Fix multiple issues in pyflask_context_to_sid()
On Wed, 2014-12-10 at 12:13 -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 09, 2014 at 04:43:22PM +, Andrew Cooper wrote: > > The error handling from a failed memory allocation should return > > PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and > > continuing > > to the memcpy() below, with the dest pointer being NULL. > > > > Coverity also complains about passing a non-NUL terminated string to > > xc_flask_context_to_sid(). xc_flask_context_to_sid() doesn't actually take > > a > > NUL terminated string, but it does take a char* which, in context, used to > > be > > a string, which is why Coverity complains. > > > > One solution would be to use strdup(ctx) which is simpler than a > > strlen()/malloc()/memcpy() combo, which would result in a NUL-terminated > > string being used with xc_flask_context_to_sid(). > > > > However, ctx is strictly an input to the hypercall and is not mutated along > > the way. Both these issues can be fixed, and the error logic simplified, by > > not duplicating ctx in the first place. > > > > Signed-off-by: Andrew Cooper > > Coverity-IDs: 1055305 1055721 > > Acked-by: Ian Campbell > > CC: Ian Jackson > > CC: Wei Liu > > CC: Xen Coverity Team > > > > --- > > v2: Expand the commit message. No code change > > Thank you. > > Release-Acked-by: Konrad Rzeszutek Wilk > Applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5 v2] xl: print message to stdout when (!debug && dryrun)
On Mon, 2014-12-15 at 11:06 +, Ian Campbell wrote: > > Release-Acked-by: Konrad Wilk > > Acked-by: Ian Campbell Applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5] docs/commandline: Minor formatting fixes and clarifications
On Fri, 2014-12-12 at 18:26 +, Andrew Cooper wrote: > `font` had a trailing single quote which was out of place. > > `gnttab_max_frames` was missing escapes for the underscores which caused the > underscores to take their markdown meaning, causing 'max' in the middle to be > italicised. Escape the underscores, and make all command line parameters > bold, to be consistent with the existing style. > > Clarify how the default for `nmi` changes between debug and non debug builds > of Xen. > > Signed-off-by: Andrew Cooper > CC: Ian Campbell > CC: Ian Jackson > CC: Wei Liu > > --- > Requesting for 4.5, under the "strictly a documentation change" allowance Acked + applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.5] libxl: Tell qemu to use raw format when using a tapdisk
On Mon, 2014-12-15 at 16:47 +, George Dunlap wrote: > On Wed, Dec 10, 2014 at 4:30 PM, Konrad Rzeszutek Wilk > wrote: > > On Tue, Dec 09, 2014 at 02:48:21PM +, Ian Campbell wrote: > >> On Tue, 2014-12-09 at 14:04 +, George Dunlap wrote: > >> > At the moment libxl unconditinally passes the underlying file format > >> > to qemu in the device string. However, when tapdisk is in use, > >> > tapdisk handles the underlying format and presents qemu with > >> > effectively a raw disk. When qemu looks at the tapdisk block device > >> > and doesn't find the image format it was looking for, it will fail. > >> > > >> > This effectively means that tapdisk cannot be used with HVM domains at > >> > the moment except for raw files. > >> > > >> > Instead, if we're using a tapdisk backend, tell qemu to use a raw file > >> > format. > >> > > >> > Signed-off-by: George Dunlap > >> > >> Acked-by: Ian Campbell > > > > Release-Acked-by: Konrad Rzeszutek Wilk > > This doesn't seem to have been applied yet. Now applied, nuking the extra blank line which way noticed on the way. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] IO-APIC interrupts getting stuck
Hello,
While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC
interrupts get stuck in a very strange state very easily with the
current PIRQ implementation that I'm using on FreeBSD.
Since I'm not sure what is going on, I would like to ask for some
feedback and possible solutions, because at this point I'm running out
of ideas of what's happening.
In this case I'm going to use IRQ 17 as an example, which is shared
between an Intel(R) PRO/1000 nic, a Broadcom NetXtreme Gigabit nic and
an Intel 82801JI (ICH10) USB controller.
Usually during the boot process, or very shortly after it, Dom0 looses
interrupts from IRQ 17, dumping IRQ information from Xen ('i' key),
gives the following output:
(XEN)IRQ: 17 affinity:0001 vec:a8 type=IO-APIC-level status=0010
in-flight=0 domain-list=0: 17(---),
...
(XEN) IRQ 17 Vec168:
(XEN) Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=1 polarity=1
irr=1 trig=L mask=0 dest_id:1
I've also added some event channel debug functions to the FreeBSD
in-kernel debugger in order to print the status of event channels:
Port 15 Type: PIRQ
Pirq: 17 ActiveHi: 0 EdgeTrigger: 0 NeedsEOI: 1
Masked: 0 Pending: 0
Per-CPU Masks: cpu#0: 0 cpu#1: 0 cpu#2: 1 cpu#3: 0 cpu#4: 0 cpu#5: 0
cpu#6: 0 cpu#7: 0
And the corresponding line from the Xen 'e' debug key:
(XEN) 15 [0/0/1]: s=4 n=2 x=0 p=17 i=17
This makes me thing that the FreeBSD kernel is failing to EOI the
vector (because of the irr=1 in the Xen IRQ debug info), so I've also
added a function to the debugger that allows me to EOI a vector from
it. But even after issuing a PHYSDEVOP_eoi hypercall on the affected
PIRQ (17), the status is exactly the same, because pirq->masked == 0,
so desc_guest_eoi fails to EOI the vector (see xen/arch/x86/irq.c:1433).
So now I'm wondering, how can I "unstuck" this IRQ, and how did it get
into this strange state?
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4)
On 16/12/14 16:13, konrad.w...@oracle.com wrote: > Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then > we have the General Release on Jan 7th! > > Details for the test-day are at > > http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions > > In terms of bugs, we have: >From the XenServer testing. * Fail to reliably boot on IBM Flex x222 blades, apparent regression from 4.4 I have declared this a latent BIOS bug, and not a regression from 4.4. Across regular reboots, the exact positions of the ACPI tables, and the e820 layout is unstable. The first consistent difference between 4.4 and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0. This is because the int $0x13, ah=2 call is returning differently. I can get the call to return differently (and correctly for 4.5) by simply making the boot trampoline larger (with my debugging routines but not being called). * VM fail to resume on upgrade from Xen < 4.5 This is the issue I am currently looking into. Currently, all the "upgrade from older XenServer" tests are failing due to VMs crashing on resume. I have not yet identified whether this is a XenServer issue or a Xen issue. Lifecycle operations on 4.5 itself are all fine including both suspend/resume and migrate. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 32392: tolerable FAIL - PUSHED
flight 32392 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32392/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 5 xen-boot fail like 32361 Tests which did not succeed, but are not blocking: test-amd64-amd64-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-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 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-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-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-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-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-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 2676bc915157ab474ee478d929b0928cf696b385 baseline version: xen 7e73a6e7f12ae080222c5d339799905de3443a6e People who touched revisions under test: Ian Campbell (ARM and generic bits) Jan Beulich jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern 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-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-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 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel
Re: [Xen-devel] IO-APIC interrupts getting stuck
On 16/12/14 17:34, Roger Pau Monné wrote:
> Hello,
>
> While working on the FreeBSD PVH Dom0 port I've realized that IO-APIC
> interrupts get stuck in a very strange state very easily with the
> current PIRQ implementation that I'm using on FreeBSD.
>
> Since I'm not sure what is going on, I would like to ask for some
> feedback and possible solutions, because at this point I'm running out
> of ideas of what's happening.
>
> In this case I'm going to use IRQ 17 as an example, which is shared
> between an Intel(R) PRO/1000 nic, a Broadcom NetXtreme Gigabit nic and
> an Intel 82801JI (ICH10) USB controller.
>
> Usually during the boot process, or very shortly after it, Dom0 looses
> interrupts from IRQ 17, dumping IRQ information from Xen ('i' key),
> gives the following output:
>
> (XEN)IRQ: 17 affinity:0001 vec:a8 type=IO-APIC-level
> status=0010 in-flight=0 domain-list=0: 17(---),
> ...
> (XEN) IRQ 17 Vec168:
> (XEN) Apic 0x00, Pin 17: vec=a8 delivery=LoPri dest=L status=1
> polarity=1 irr=1 trig=L mask=0 dest_id:1
>
> I've also added some event channel debug functions to the FreeBSD
> in-kernel debugger in order to print the status of event channels:
>
> Port 15 Type: PIRQ
> Pirq: 17 ActiveHi: 0 EdgeTrigger: 0 NeedsEOI: 1
> Masked: 0 Pending: 0
> Per-CPU Masks: cpu#0: 0 cpu#1: 0 cpu#2: 1 cpu#3: 0 cpu#4: 0 cpu#5: 0
> cpu#6: 0 cpu#7: 0
>
> And the corresponding line from the Xen 'e' debug key:
>
> (XEN) 15 [0/0/1]: s=4 n=2 x=0 p=17 i=17
>
> This makes me thing that the FreeBSD kernel is failing to EOI the
> vector (because of the irr=1 in the Xen IRQ debug info), so I've also
> added a function to the debugger that allows me to EOI a vector from
> it. But even after issuing a PHYSDEVOP_eoi hypercall on the affected
> PIRQ (17), the status is exactly the same, because pirq->masked == 0,
> so desc_guest_eoi fails to EOI the vector (see xen/arch/x86/irq.c:1433).
>
> So now I'm wondering, how can I "unstuck" this IRQ, and how did it get
> into this strange state?
>
> Roger.
Do you have a xen dmesg with full debugging? According to the first
line from 'i', Xen believes that the irq in question is not in need of
an EOI, which is clearly contrary to the IOAPICs view of the world.
Some random suggestions: does altering interrupt remapping make a
difference? does altering the ioapic_ack_mode make a difference?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1 net] xen-netfront: use napi_complete() correctly to prevent Rx stalling
After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt
masking in NAPI) the napi instance is removed from the per-cpu list
prior to calling the n->poll(), and is only requeued if all of the
budget was used. This inadvertently broke netfront because netfront
does not use NAPI correctly.
If netfront had not used all of its budget it would do a final check
for any Rx responses and avoid calling napi_complete() if there were
more responses. It would still return under budget so it would never
be rescheduled. The final check would also not re-enable the Rx
interrupt.
Additionally, xenvif_poll() would also call napi_complete() /after/
enabling the interrupt. This resulted in a race between the
napi_complete() and the napi_schedule() in the interrupt handler. The
use of local_irq_save/restore() avoided by race iff the handler is
running on the same CPU but not if it was running on a different CPU.
Fix both of these by always calling napi_compete() if the budget was
not all used, and then calling napi_schedule() if the final checks
says there's more work.
Signed-off-by: David Vrabel
Cc: Eric Dumazet
---
drivers/net/xen-netfront.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 2f0a9ce..22bcb4e 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -977,7 +977,6 @@ static int xennet_poll(struct napi_struct *napi, int budget)
struct sk_buff_head rxq;
struct sk_buff_head errq;
struct sk_buff_head tmpq;
- unsigned long flags;
int err;
spin_lock(&queue->rx_lock);
@@ -1050,15 +1049,11 @@ err:
if (work_done < budget) {
int more_to_do = 0;
- napi_gro_flush(napi, false);
-
- local_irq_save(flags);
+ napi_complete(napi);
RING_FINAL_CHECK_FOR_RESPONSES(&queue->rx, more_to_do);
- if (!more_to_do)
- __napi_complete(napi);
-
- local_irq_restore(flags);
+ if (more_to_do)
+ napi_schedule(napi);
}
spin_unlock(&queue->rx_lock);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4] xmalloc: add support for checking the pool integrity
Implemented xmem_pool_check(), xmem_pool_check_locked() and
xmem_pool_check_unlocked() to verity the integrity of the TLSF matrix.
Signed-off-by: Mihai Donțu
---
Changes since v3:
- try harder to respect the 80 column limit
- use 'unsigned int' instead of 'int' where possible
- made the logged messages even shorter
- dropped the use of goto (didn't really make sense)
Changes since v2:
- print the name of the corrupted pool
- adjusted the messages to better fit within 80 columns
- minor style change (a ? a : b -> a ?: b)
Changes since v1:
- fixed the codingstyle
- swaped _locked/_unlocked naming
- reworked __xmem_pool_check_locked() a bit
- used bool_t where appropriate
- made xmem_pool_check() take a pool argument which can be NULL
---
xen/common/xmalloc_tlsf.c | 121 +-
xen/include/xen/xmalloc.h | 7 +++
2 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index a5769c9..eca4f1c 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -120,9 +120,122 @@ struct xmem_pool {
char name[MAX_POOL_NAME_LEN];
};
+static struct xmem_pool *xenpool;
+
+static inline void MAPPING_INSERT(unsigned long r, int *fl, int *sl);
+
/*
* Helping functions
*/
+#ifndef NDEBUG
+static bool_t xmem_pool_check_size(const struct xmem_pool *pool,
+ int fl, int sl)
+{
+const struct bhdr *b = pool->matrix[fl][sl];
+
+while ( b )
+{
+int __fl;
+int __sl;
+
+MAPPING_INSERT(b->size, &__fl, &__sl);
+if ( __fl != fl || __sl != sl )
+{
+printk(XENLOG_ERR
+ "xmem_pool: %s: misplaced block %p:%u ({%d,%d} ->
{%d,%d})\n",
+ pool->name, b, b->size, fl, sl, __fl, __sl);
+return 0;
+}
+b = b->ptr.free_ptr.next;
+}
+return 1;
+}
+
+/*
+ * This function must be called from a context where pool->lock is
+ * already acquired.
+ *
+ * Returns true if the pool has been corrupted, false otherwise
+ */
+#define xmem_pool_check_locked(pool) \
+__xmem_pool_check_locked(__FILE__, __LINE__, pool)
+static bool_t __xmem_pool_check_locked(const char *file, int line,
+ const struct xmem_pool *pool)
+{
+unsigned int i;
+static bool_t once = 1;
+
+if ( !once )
+return 1;
+for ( i = 0; i < REAL_FLI; i++ )
+{
+int fl = (pool->fl_bitmap & (1 << i)) ? i : -1;
+
+if ( fl >= 0 )
+{
+unsigned int j;
+
+if ( !pool->sl_bitmap[fl] )
+{
+printk(XENLOG_ERR
+ "xmem_pool: %s: TLSF bitmap corrupt (!empty FL, empty
SL)\n",
+ pool->name);
+__warn(file, line);
+once = 0;
+break;
+}
+for ( j = 0; j < MAX_SLI; j++ )
+{
+int sl = (pool->sl_bitmap[fl] & (1 << j)) ? j : -1;
+
+if ( sl < 0 )
+continue;
+if ( !pool->matrix[fl][sl] )
+{
+printk(XENLOG_ERR
+ "xmem_pool: %s: TLSF bitmap corrupt
(!matrix[%d][%d])\n",
+ pool->name, fl, sl);
+__warn(file, line);
+once = 0;
+break;
+}
+if ( !xmem_pool_check_size(pool, fl, sl) )
+{
+printk(XENLOG_ERR "xmem_pool: %s: TLSF chunk matrix
corrupt\n",
+ pool->name);
+__warn(file, line);
+once = 0;
+break;
+}
+}
+if ( !once )
+break;
+}
+}
+return !once;
+}
+
+#define xmem_pool_check_unlocked(pool) \
+__xmem_pool_check_unlocked(__FILE__, __LINE__, pool)
+static bool_t __xmem_pool_check_unlocked(const char *file, int line,
+ struct xmem_pool *pool)
+{
+bool_t oops;
+
+spin_lock(&pool->lock);
+oops = __xmem_pool_check_locked(file, line, pool);
+spin_unlock(&pool->lock);
+return oops;
+}
+
+bool_t __xmem_pool_check(const char *file, int line, struct xmem_pool *pool)
+{
+return __xmem_pool_check_unlocked(file, line, pool ?: xenpool);
+}
+#else
+#define xmem_pool_check_locked(pool) ((void)(pool))
+#define xmem_pool_check_unlocked(pool) ((void)(pool))
+#endif
/**
* Returns indexes (fl, sl) of the list used to serve request of size r
@@ -381,6 +494,8 @@ void *xmem_pool_alloc(unsigned long size, struct xmem_pool
*pool)
int fl, sl;
unsigned long tmp_size;
+xmem_pool_check_unlocked(pool);
+
if ( pool->init_region == NULL )
{
if ( (region = pool->get_mem(pool->init_size)) == NULL )
@@ -442,11 +557,13 @@ void *xmem_pool_alloc(unsi
[Xen-devel] [PATCH for 4.6 04/13] xen/dt: Extend dt_device_match to possibly store data
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.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.6 02/13] xen/arm: vgic: Drop unecessary include asm/device.h
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 1369f78..259d04f 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 ff99e50..da27605 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.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.6 11/13] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices
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.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.6 05/13] xen/arm: device: Rename device_type into device_match
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.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.6 00/13] xen/arm: Resync the SMMU driver with the Linux one
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 core of the SMMU drivers (i.e 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 mode in several step: 1) Revert the current SMMU driver (patch #6) 2) Import as it is the driver from Linux (patch #10) 3) Apply 2 fixes useful to correctly use the SATA with the SMMU on calxeda. I don't know why Linux didn't yet applied (patch #11-12) 4) Changes for Xen (patch #13) 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 device tree passthrough ( ops assign_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 device tree). A branch is available with all the changes: git://xenbits.xen.org/people/julieng/xen-unstable.git branch smmu-rework Sincerely yours, 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 (11): xen/arm: gic-v2: Change the device name in DT_DEVICE_START xen/arm: vgic: Drop unecessary include asm/device.h xen: Introduce ACCESS_ONCE macro 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: 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 | 27 +- xen/arch/arm/domain_build.c |2 +- xen/arch/arm/gic-v2.c | 15 +- xen/arch/arm/gic-v3.c | 10 +- xen/arch/arm/gic.c |2 +- xen/arch/arm/platform.c |2 +- xen/arch/arm/vgic-v2.c |1 - xen/arch/arm/vgic-v3.c |1 - xen/common/Makefile |1 + xen/common/device.c | 21 + xen/common/device_tree.c| 13 +- xen/drivers/char/dt-uart.c |4 +- xen/drivers/char/exynos4210-uart.c | 10 +- xen/drivers/char/ns16550.c | 14 +- xen/drivers/char/omap-uart.c| 10 +- xen/drivers/char/pl011.c| 10 +- xen/drivers/passthrough/amd/pci_amd_iommu.c | 14 +- xen/drivers/passthrough/arm/iommu.c |2 +- xen/drivers/passthrough/arm/smmu.c | 4107 +-- xen/drivers/passthrough/device_tree.c |5 +- xen/drivers/passthrough/pci.c | 22 +- xen/drivers/passthrough/vtd/iommu.c | 19 +- xen/include/asm-arm/device.h| 19 +- xen/include/asm-arm/gic.h | 15 +- xen/include/asm-x86/device.h| 17 + xen/include/xen/compiler.h | 14 + xen/include/xen/device.h| 40 + xen/include/xen/device_tree.h | 19 +- xen/include/xen/iommu.h | 18 +- xen/include/xen/pci.h | 12 + 30 files changed, 2843 insertions(+), 1623 deletions(-) create mode 100644 xen/common/device.c create mode 100644 xen/include/asm-x86/device.h create mode 100644 xen/include/xen/device.h -- 2.1.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.6 07/13] xen: Introduce a generic way to describe device
Currently, Xen is supporting PCI and Platform device (based on Device Tree).
While we don't support both at the same time: platform device for ARM
and PCI for x86, ARM will gain support on 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.
At the same time replace any use of asm/device.h by xen/device.h. This
is required to be able to compile ARM correctly.
Signed-off-by: Julien Grall
CC: Jan Beulich
CC: Keir Fraser
---
xen/arch/arm/device.c | 2 +-
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/gic-v2.c | 3 +--
xen/arch/arm/gic-v3.c | 2 +-
xen/arch/arm/gic.c | 2 +-
xen/common/Makefile | 1 +
xen/common/device.c | 21 +++
xen/common/device_tree.c| 1 +
xen/drivers/char/dt-uart.c | 4 ++--
xen/drivers/char/exynos4210-uart.c | 2 +-
xen/drivers/char/ns16550.c | 2 +-
xen/drivers/char/omap-uart.c| 2 +-
xen/drivers/char/pl011.c| 2 +-
xen/drivers/passthrough/arm/iommu.c | 2 +-
xen/drivers/passthrough/pci.c | 2 ++
xen/include/asm-arm/device.h| 3 ++-
xen/include/asm-x86/device.h| 17
xen/include/xen/device.h| 40 +
xen/include/xen/device_tree.h | 13
xen/include/xen/pci.h | 12 +++
20 files changed, 121 insertions(+), 14 deletions(-)
create mode 100644 xen/common/device.c
create mode 100644 xen/include/asm-x86/device.h
create mode 100644 xen/include/xen/device.h
diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 693b9af..de702ff 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -17,7 +17,7 @@
* GNU General Public License for more details.
*/
-#include
+#include
#include
#include
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..b701a2f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -9,10 +9,10 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index f149e09..048350b 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -27,12 +27,11 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include
-
#include
#include
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 076aa62..c6d1876 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -31,12 +31,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index e7a1af5..d1ab6b5 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -27,10 +27,10 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8391246..03ed719 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -2,6 +2,7 @@ obj-y += bitmap.o
obj-y += core_parking.o
obj-y += cpu.o
obj-y += cpupool.o
+obj-y += device.o
obj-$(HAS_DEVICE_TREE) += device_tree.o
obj-y += domctl.o
obj-y += domain.o
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..f471008 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1450,6 +1450,7 @@ static unsigned long __init unflatten_dt_node(const void
*fdt,
prev_pp = &pp->next;
#endif
np->name = pp->value;
+device_initialize(&np->dev, DEV_DT);
memcpy(pp->value, ps, sz - 1);
((char *)pp->value)[sz - 1] = 0;
dt_dprintk("fixed up name for %s -> %s\n", pathp,
diff --git a/xen/drivers/char/dt-uart.c b/xen/drivers/char/dt-uart.c
index fa92b5c..01eced1 100644
--- a/xen/drivers/char/dt-uart.c
+++ b/xen/drivers/char/dt-uart.c
@@ -17,11 +17,11 @@
* GNU General Public License for more details.
*/
-#include
-#include
+#include
#include
#include
#include
+#include
/*
* Co
[Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro
This macro can be used in drivers imported from Linux.
Signed-off-by: Julien Grall
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
---
xen/include/xen/compiler.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 4b3472d..57eb7a6 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -90,4 +90,18 @@
__asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
(typeof(ptr)) (__ptr + (off)); })
+/*
+ * Prevent the compiler from merging or refetching accesses. The compiler
+ * is also forbidden from reordering successive instances of ACCESS_ONCE(),
+ * but only when the compiler is aware of some particular ordering. One way
+ * to make the compiler aware of ordering is to put the two invocations of
+ * ACCESS_ONCE() in different C statements.
+ *
+ * This macro does absolutely -nothing- to prevent the CPU from reordering,
+ * merging, or refetching absolutely anything at any time. Its main intended
+ * use is to mediate communication between process-level code and irq/NMI
+ * handlers, all running on the same CPU.
+ */
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+
#endif /* __LINUX_COMPILER_H */
--
2.1.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.6 01/13] xen/arm: gic-v2: Change the device name in DT_DEVICE_START
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.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
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
---
xen/drivers/passthrough/arm/Makefile | 1 +
xen/drivers/passthrough/arm/smmu.c | 668 +++
2 files changed, 602 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..3cf1773 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,154 @@
* - 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
+/* Alias to Xen allocation helpers */
+#define kfree xfree
+#define kmalloc(size, flags) _xmalloc(size, sizeof(void *))
+#define kzalloc(size, flags) _xzalloc(size, sizeof(void *))
+#define devm_kzalloc(dev, size, fl
[Xen-devel] [PATCH for 4.6 12/13] xen/iommu: smmu: Introduce automatic stream-id-masking
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 for 4.6 10/13] xen/iommu: arm: Import the SMMU driver from Linux
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-of-by: Julien Grall --- 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(1 << 13) +#define sCR0_BSU_SHIFT 14 +#d
[Xen-devel] [PATCH for 4.6 06/13] xen/iommu: arm: Remove temporary the SMMU driver
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 for 4.6 09/13] xen/arm: Describe device supported by a driver with dt_match_node
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 | 8 ++--
xen/include/asm-arm/gic.h | 15 +--
9 files changed, 39 insertions(+), 59 deletions(-)
diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index de702ff..1993929 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 048350b..db3795d 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -763,16 +763,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 c6d1876..1191cb7 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 75246e1..b59e64a 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 6df3f95..a0373a9 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, "NS165
[Xen-devel] [PATCH for 4.6 08/13] xen/iommu: Consolidate device assignment ops into a single set
On ARM, the way to assign device tree node is exactly the same as PCI.
Futhermore, all devices can be represented by a "struct device'.
Therefore there is no need to add separate ops.
Signed-off-by: Julien Grall
CC: Suravee Suthikulpanit
CC: Aravind Gopalakrishnan
CC: Jan Beulich
CC: Yang Zhang
CC: Kevin Tian
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 14 +-
xen/drivers/passthrough/device_tree.c | 5 +++--
xen/drivers/passthrough/pci.c | 20 +++-
xen/drivers/passthrough/vtd/iommu.c | 19 ---
xen/include/xen/iommu.h | 18 +++---
5 files changed, 42 insertions(+), 34 deletions(-)
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index e83bb35..0af13fb 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -355,8 +355,9 @@ void amd_iommu_disable_domain_device(struct domain *domain,
}
static int reassign_device(struct domain *source, struct domain *target,
- u8 devfn, struct pci_dev *pdev)
+ u8 devfn, struct device *dev)
{
+struct pci_dev *pdev = dev_to_pci(dev);
struct amd_iommu *iommu;
int bdf;
struct hvm_iommu *t = domain_hvm_iommu(target);
@@ -394,8 +395,9 @@ static int reassign_device(struct domain *source, struct
domain *target,
}
static int amd_iommu_assign_device(struct domain *d, u8 devfn,
- struct pci_dev *pdev)
+ struct device *dev)
{
+struct pci_dev *pdev = dev_to_pci(dev);
struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev->seg);
int bdf = PCI_BDF2(pdev->bus, devfn);
int req_id = get_dma_requestor_id(pdev->seg, bdf);
@@ -410,7 +412,7 @@ static int amd_iommu_assign_device(struct domain *d, u8
devfn,
ivrs_mappings[req_id].read_permission);
}
-return reassign_device(hardware_domain, d, devfn, pdev);
+return reassign_device(hardware_domain, d, devfn, dev);
}
static void deallocate_next_page_table(struct page_info *pg, int level)
@@ -481,8 +483,9 @@ static void amd_iommu_domain_destroy(struct domain *d)
amd_iommu_flush_all_pages(d);
}
-static int amd_iommu_add_device(u8 devfn, struct pci_dev *pdev)
+static int amd_iommu_add_device(u8 devfn, struct device *dev)
{
+struct pci_dev *pdev = dev_to_pci(dev);
struct amd_iommu *iommu;
u16 bdf;
if ( !pdev->domain )
@@ -503,8 +506,9 @@ static int amd_iommu_add_device(u8 devfn, struct pci_dev
*pdev)
return 0;
}
-static int amd_iommu_remove_device(u8 devfn, struct pci_dev *pdev)
+static int amd_iommu_remove_device(u8 devfn, struct device *dev)
{
+struct pci_dev *pdev = dev_to_pci(dev);
struct amd_iommu *iommu;
u16 bdf;
if ( !pdev->domain )
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 9fbd2a2..43ce5dc 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1256,7 +1256,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;
@@ -1265,7 +1265,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);
@@ -1286,7 +1286,7 @@ int iommu_enable_device(struct pci_dev *pdev)
!hd->platform_ops->enable_device )
return 0;
-return hd->platform_ops->enable_device(pdev);
+r
Re: [Xen-devel] [PATCHv1 net] xen-netfront: use napi_complete() correctly to prevent Rx stalling
From: David Vrabel Date: Tue, 16 Dec 2014 18:59:46 + > After d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less interrupt > masking in NAPI) the napi instance is removed from the per-cpu list > prior to calling the n->poll(), and is only requeued if all of the > budget was used. This inadvertently broke netfront because netfront > does not use NAPI correctly. > > If netfront had not used all of its budget it would do a final check > for any Rx responses and avoid calling napi_complete() if there were > more responses. It would still return under budget so it would never > be rescheduled. The final check would also not re-enable the Rx > interrupt. > > Additionally, xenvif_poll() would also call napi_complete() /after/ > enabling the interrupt. This resulted in a race between the > napi_complete() and the napi_schedule() in the interrupt handler. The > use of local_irq_save/restore() avoided by race iff the handler is > running on the same CPU but not if it was running on a different CPU. > > Fix both of these by always calling napi_compete() if the budget was > not all used, and then calling napi_schedule() if the final checks > says there's more work. > > Signed-off-by: David Vrabel Applied, thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the pool integrity
On 16/12/14 19:33, Mihai Donțu wrote:
> Implemented xmem_pool_check(), xmem_pool_check_locked() and
> xmem_pool_check_unlocked() to verity the integrity of the TLSF matrix.
>
> Signed-off-by: Mihai Donțu
>
> ---
> Changes since v3:
> - try harder to respect the 80 column limit
> - use 'unsigned int' instead of 'int' where possible
> - made the logged messages even shorter
> - dropped the use of goto (didn't really make sense)
>
> Changes since v2:
> - print the name of the corrupted pool
> - adjusted the messages to better fit within 80 columns
> - minor style change (a ? a : b -> a ?: b)
>
> Changes since v1:
> - fixed the codingstyle
> - swaped _locked/_unlocked naming
> - reworked __xmem_pool_check_locked() a bit
> - used bool_t where appropriate
> - made xmem_pool_check() take a pool argument which can be NULL
> ---
> xen/common/xmalloc_tlsf.c | 121
> +-
> xen/include/xen/xmalloc.h | 7 +++
> 2 files changed, 126 insertions(+), 2 deletions(-)
>
> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> index a5769c9..eca4f1c 100644
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -120,9 +120,122 @@ struct xmem_pool {
> char name[MAX_POOL_NAME_LEN];
> };
>
> +static struct xmem_pool *xenpool;
> +
> +static inline void MAPPING_INSERT(unsigned long r, int *fl, int *sl);
> +
> /*
> * Helping functions
> */
> +#ifndef NDEBUG
> +static bool_t xmem_pool_check_size(const struct xmem_pool *pool,
> + int fl, int sl)
> +{
> +const struct bhdr *b = pool->matrix[fl][sl];
> +
> +while ( b )
> +{
> +int __fl;
> +int __sl;
> +
> +MAPPING_INSERT(b->size, &__fl, &__sl);
> +if ( __fl != fl || __sl != sl )
> +{
> +printk(XENLOG_ERR
> + "xmem_pool: %s: misplaced block %p:%u ({%d,%d} ->
> {%d,%d})\n",
Is it liable to get confusing with a hex number and a decimal number
combined with just a colon?
Is b even useful? You have the pool name, indicies and size which seem
to be the salient information.
> + pool->name, b, b->size, fl, sl, __fl, __sl);
> +return 0;
> +}
> +b = b->ptr.free_ptr.next;
> +}
> +return 1;
> +}
> +
> +/*
> + * This function must be called from a context where pool->lock is
> + * already acquired.
> + *
> + * Returns true if the pool has been corrupted, false otherwise
> + */
> +#define xmem_pool_check_locked(pool) \
> +__xmem_pool_check_locked(__FILE__, __LINE__, pool)
> +static bool_t __xmem_pool_check_locked(const char *file, int line,
> + const struct xmem_pool *pool)
> +{
> +unsigned int i;
> +static bool_t once = 1;
What is this static doing? Surely corruption corruption in one pool has
no effect on corruption in a separate pool (other than the usual side
effects of general memory corruption, which tend to be bad).
It looks as if it wants to be an extra field in an xmem_pool.
> +
> +if ( !once )
> +return 1;
> +for ( i = 0; i < REAL_FLI; i++ )
> +{
> +int fl = (pool->fl_bitmap & (1 << i)) ? i : -1;
> +
> +if ( fl >= 0 )
> +{
> +unsigned int j;
> +
> +if ( !pool->sl_bitmap[fl] )
> +{
> +printk(XENLOG_ERR
> + "xmem_pool: %s: TLSF bitmap corrupt (!empty FL, empty
> SL)\n",
> + pool->name);
> +__warn(file, line);
The __warn()s here will currently do a full register dump, as well as
stack dump and stack trace. It occurs to me that only the stack trace
itself is useful at this point.
__bug and __warn() are currently unused (I am struggling to work out
exactly when they were orphaned; they do not form part of regular
BUG()/WARN() operations, which are handled in do_invalid_op()). They
are also not fantastically useful as they will always identify
themselves in the printed information, not their caller. I suspect they
can just be dropped completely.
I suspect you also would be better, and certainly more brief, with
"run_in_exception_handler(show_stack)" instead, which will just print a
stack trace, but nothing more.
> +once = 0;
> +break;
> +}
> +for ( j = 0; j < MAX_SLI; j++ )
> +{
> +int sl = (pool->sl_bitmap[fl] & (1 << j)) ? j : -1;
> +
> +if ( sl < 0 )
> +continue;
> +if ( !pool->matrix[fl][sl] )
> +{
> +printk(XENLOG_ERR
> + "xmem_pool: %s: TLSF bitmap corrupt
> (!matrix[%d][%d])\n",
> + pool->name, fl, sl);
> +__warn(file, line);
> +once = 0;
> +break;
> +}
> +if ( !xmem_pool_check_size(pool, fl,
Re: [Xen-devel] [PATCH] fix segfault in xl migrate --debug
On Mon, 1 Dec 2014, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 28, 2014 at 12:09:41PM +, Ian Campbell wrote:
On Wed, 2014-11-26 at 21:19 +, Andrew Cooper wrote:
On 26/11/2014 19:54, M A Young wrote:
If differences are found during the verification phase of xl migrate
--debug then it is likely to crash with a segfault because the
bogus
pagebuf->pfn_types[pfn] is used in a print statement instead of
pfn_type[pfn] .
Signed-off-by: Michael Young
Reviewed-by: Andrew Cooper
Acked-by: Ian Campbell
Needs a release ack if this is to be for 4.5, Konrad CCd.
On the one hand this fixes an issue which is only present if you enable
debug/verify mode, so it's not that critical. On the other hand it only
touches code which is used if you enable debug/verify mode, so it's not
that risky.
I'm inclined towards the apply it for 4.5 end of the scale...
Release-Acked-by: Konrad Rzeszutek Wilk
xl migrate --debug can segfault because pagebuf->pfn_types[pfn] is
used in a print statement instead of pfn_type[pfn]
--- xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c.orig 2014-10-24
15:22:40.0 +0100
+++ xen-4.5.0-rc1/tools/libxc/xc_domain_restore.c 2014-11-25
21:01:16.604081467 +
@@ -1404,7 +1404,7 @@
int v;
DPRINTF("** pfn=%lx type=%lx gotcs=%08lx "
-"actualcs=%08lx\n", pfn, pagebuf->pfn_types[pfn],
+"actualcs=%08lx\n", pfn, pfn_type[pfn],
csum_page(region_base + i * PAGE_SIZE),
csum_page(buf));
Is this patch going to get committed in time for xen 4.5?
Michael Young
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 32412: regressions - trouble: blocked/broken/fail/pass
flight 32412 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32412/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail REGR. vs. 31241 test-amd64-amd64-xl 14 guest-localmigrate.2 fail REGR. vs. 31241 test-amd64-amd64-pair16 guest-start/debianfail REGR. vs. 31241 build-i386-pvops 4 host-build-prep fail REGR. vs. 31241 test-amd64-amd64-xl-qemut-winxpsp3 5 xen-bootfail REGR. vs. 31241 test-amd64-amd64-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 31241 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 11 guest-saverestore fail REGR. vs. 31241 test-armhf-armhf-xl 9 guest-start fail like 31241 test-amd64-amd64-xl-sedf 15 guest-localmigrate/x10fail REGR. vs. 31241 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 31241 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-credit21 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: linux2dbfca5a181973558277b28b1f4c36362291f5e0 baseline version: linux9f76628da20f96a179ca62b504886f99ecc29223 1848 people touched revisions under test, not listing them all 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 broken build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-armhf-armhf-xl fail test-
Re: [Xen-devel] Xen 4.5 Development Update (RC4)
On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote: > On Tue, Dec 16, konrad.w...@oracle.com wrote: > > > In terms of bugs, we have: > > ... systemd SELinux, but its not listed. > > Whats your plan with the failures you see? Should I continue to be > concerned about that, or will all the be postponed to 4.6? I was under the impression you had some patches which would solve a majority of the issues? And after the discussion with Ian Jackson the way to exec was solved? And for the other - the SELinux context and how to figure this out - I thought (I will have to double-check it tomorrow) that I mentioned it might make sense to talk to the SELinux maintainers to see if they have any recommendation? > > Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4)
On Tue, Dec 16, 2014 at 05:43:08PM +, Andrew Cooper wrote: > On 16/12/14 16:13, konrad.w...@oracle.com wrote: > > Xen 4.5-rc4 was out on Monday (Dec 15th). This is the last RC and then > > we have the General Release on Jan 7th! > > > > Details for the test-day are at > > > > http://wiki.xen.org/wiki/Xen_4.5_RC4_test_instructions > > > > In terms of bugs, we have: > > From the XenServer testing. Thank you for doing this testing! > > * Fail to reliably boot on IBM Flex x222 blades, apparent regression > from 4.4 > > I have declared this a latent BIOS bug, and not a regression from 4.4. > Across regular reboots, the exact positions of the ACPI tables, and the > e820 layout is unstable. The first consistent difference between 4.4 > and 4.5 is that 4.4 reports 1 MBR signature while 4.5 reports 0. This > is because the int $0x13, ah=2 call is returning differently. I can get > the call to return differently (and correctly for 4.5) by simply making > the boot trampoline larger (with my debugging routines but not being > called). This sounds very familiar, but I can't place where I saw mention of a similar issue. > > * VM fail to resume on upgrade from Xen < 4.5 > > This is the issue I am currently looking into. Currently, all the > "upgrade from older XenServer" tests are failing due to VMs crashing on > resume. I have not yet identified whether this is a XenServer issue or Ugh. > a Xen issue. Lifecycle operations on 4.5 itself are all fine including > both suspend/resume and migrate. > > ~Andrew > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] fix segfault in xl migrate --debug
On Tue, Dec 16, 2014 at 08:38:42PM +, M A Young wrote: [...] > Is this patch going to get committed in time for xen 4.5? > Yes. See d36a3734a6. And there's a subsequence patch to fix a regression caused by that patch. See 09b7ff1a. Wei. > Michael Young ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] fix segfault in xl migrate --debug
On Tue, 16 Dec 2014, Wei Liu wrote: On Tue, Dec 16, 2014 at 08:38:42PM +, M A Young wrote: [...] Is this patch going to get committed in time for xen 4.5? Yes. See d36a3734a6. And there's a subsequence patch to fix a regression caused by that patch. See 09b7ff1a. Wei. No that is the other bug in xl migrate --debug (it fails rather than segfaults). Michael Young ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] fix segfault in xl migrate --debug
On Tue, Dec 16, 2014 at 10:04:25PM +, M A Young wrote: > On Tue, 16 Dec 2014, Wei Liu wrote: > > >On Tue, Dec 16, 2014 at 08:38:42PM +, M A Young wrote: > >[...] > >>Is this patch going to get committed in time for xen 4.5? > >> > > > >Yes. See d36a3734a6. > > > >And there's a subsequence patch to fix a regression caused by that > >patch. See 09b7ff1a. > > > >Wei. > > No that is the other bug in xl migrate --debug (it fails rather than > segfaults). > Ah, I misread. Sorry. > Michael Young ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] WARNING: at drivers/xen/gntdev.c:426 unmap_if_in_range+0x5d/0x60 [xen_gntdev]()
On Dec 15, 2014, at 6:11 AM, David Vrabel wrote: > On 11/12/14 15:12, Christopher S. Aker wrote: >> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114 >> Dom0: 3.17.4 >> >> Things go badly after a day or four. We've hit this on a number of >> previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4: >> >> printk: 5441 messages suppressed. >> grant_table.c:567:d0 Failed to obtain maptrack handle. >> grant_table.c:567:d0 Failed to obtain maptrack handle. >> grant_table.c:567:d0 Failed to obtain maptrack handle. >> grant_table.c:567:d0 Failed to obtain maptrack handle. > > Can you provide more details about your networking and storage setup. > In particular, do you have a domU providing networked storage (iscsi for > example) to other domains on the same host? Certainly. Thanks for the response. We're not using iscsi, but we do have some serious kit going on. This is the setup: Storage: BBU hardware RAID (LSI), SSD drives, LVM logical volumes exported to the guests via blkback. Network: Four 10Gbit links, ixgbe, bonded, then bridged onto br0, exported via netback via vifs. Nothing fancier than that :) -Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the pool integrity
Hi, On 16/12/2014 20:28, Andrew Cooper wrote: I suspect you also would be better, and certainly more brief, with "run_in_exception_handler(show_stack)" instead, which will just print a stack trace, but nothing more. FIY, run_in_exception_handler doesn't exists on ARM. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the pool integrity
On 16/12/2014 23:06, Julien Grall wrote: > Hi, > > On 16/12/2014 20:28, Andrew Cooper wrote: >> I suspect you also would be better, and certainly more brief, with >> "run_in_exception_handler(show_stack)" instead, which will just print a >> stack trace, but nothing more. > > FIY, run_in_exception_handler doesn't exists on ARM. > > Regards, > In which case it even more lucky that __bug() and __warn() are orphaned functions, as they don't work correctly on arm. Even more reason to remove them. It doesn't look like run_in_exception_handler() would be hard to add to arm at all. It already has broadly similar bug/warn/assert infrastructure. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] xmalloc: add support for checking the pool integrity
On 16/12/2014 23:26, Andrew Cooper wrote: On 16/12/2014 23:06, Julien Grall wrote: Hi, On 16/12/2014 20:28, Andrew Cooper wrote: I suspect you also would be better, and certainly more brief, with "run_in_exception_handler(show_stack)" instead, which will just print a stack trace, but nothing more. FIY, run_in_exception_handler doesn't exists on ARM. Regards, In which case it even more lucky that __bug() and __warn() are orphaned functions, as they don't work correctly on arm. Even more reason to remove them. It doesn't look like run_in_exception_handler() would be hard to add to arm at all. It already has broadly similar bug/warn/assert infrastructure. It's more difficult than you think. For ARM we had to use a different infrastructure than x86 to setup the BUG_FRAME. This is because %c is not correctly support on most ARM compiler today. So I don't think it worth to spend time on it just for one call. How about introducing dump_stack() which would call run_in_exception_handler() on x86 and something different (maybe a new BUG_FRAME type) on ARM? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 32418: tolerable FAIL - PUSHED
flight 32418 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/32418/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32194 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass 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-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-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail 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-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: qemuu54600752a1dd67844c2cf3c467db562c39499838 baseline version: qemuu45e1611de8be0eae55967694dd6e627c2dc354f2 People who touched revisions under test: Alex Bennée Amos Kong Anton Blanchard Antony Pavlov Bastian Koppelmann Christoffer Dall Dmitry Poletaev Dr. David Alan Gilbert Fabian Aggeler Fam Zheng Gary R Hook Gerd Hoffmann Gonglei Greg Bellows Jeff Cody Jun Li Kevin Wolf lijun Liviu Ionescu Markus Armbruster Max Reitz Michael Mueller Michael Tokarev Nikita Belov Paolo Bonzini Pavel Dovgalyuk Peter Maydell Richard Henderson Sergey Fedorov Stefan Hajnoczi Thomas Huth zhanghailiang 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-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-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel
Re: [Xen-devel] Xen 4.5 Development Update (RC4)
On Tue, Dec 16, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 16, 2014 at 05:34:51PM +0100, Olaf Hering wrote: > > On Tue, Dec 16, konrad.w...@oracle.com wrote: > > > > > In terms of bugs, we have: > > > > ... systemd SELinux, but its not listed. > > > > > Whats your plan with the failures you see? Should I continue to be > > concerned about that, or will all the be postponed to 4.6? > > I was under the impression you had some patches which would solve a > majority of the issues? And after the discussion with Ian Jackson the > way to exec was solved? No. What I did was to handle XENSTORED_TRACE which is just a bool to pass "-T /log/file" to xenstored. I think xenstored can not access the sockets if it was launched with a shell script as it is done now. No idea how to solve that. Maybe "/usr/bin/env $XENSTORED" could be a workaround for the SELinux socket access issue. But perhaps launching it via env or sh fails either way. > And for the other - the SELinux context and how to figure this out - > I thought (I will have to double-check it tomorrow) that I mentioned it might > make sense to talk to the SELinux maintainers to see if they have any > recommendation? For xen-4.5 the easy way would be to remove the context= option and let people who build from source and who want to use SELinux put the required options into /etc/fstab. This would also resolve the issue Anthony is seeing, his mount or kernel does not understand context= at all. No idea how he got into that state in his Arch Linux installation. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Packaging xen 4.5.0 RC4 on Arch Linux
I am creating an Arch Linux AUR package for Xen 4.5 RC4. As this doesn't exist and I am playing around with a xen server. Hopefully I'll be done in time for the test day. (AUR is a package repository for build scripts that make packages for the Arch Linux package manager). The idea is to have something that is usable to build a xen 4.5 RC4 system using Arch Linux as the Dom0. At the moment I have managed to get xen to build from the 4.5 RC4 tarball, using the following commands in the build script: PYTHON=/usr/bin/python2 BISON=/bin/true ./configure \ --prefix=/usr \ --sbindir=/usr/bin \ --enable-systemd \ --disable-debug PYTHON=python2 make dist dist/install.sh "$pkgdir" The directory tree at $pkgdir is what gets installed when the resulting package is installed with the package manager. Installing this mostly works out of the box, with one problem. The default Arch Linux kernel does not have SELinux, causing the var-lib-xenstored.mount unit to fail due to an invalid context. This can be worked around by removing the context option from the mount options in that unit file. I couldn't find out which systemd unit files that are supposed to be enabled for xen to be properly initialized. I'm guessing that xen-init-dom0 is important as without it, xl doesn't work at all. The xendomains service mentions it in the After parameter, but After only does ordering. Is it correct that xen-init-dom0 should not be started when starting the xendomains.service? Without xen-init-dom0, the xendomains service does nothing but spew out errrors on my system. It would be reallly helpful if could get some pointers on how xen should be built for packaging into a distribution, and whether I'm on the right track. Regards Julian Sivertsen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
