Re: [Xen-devel] [PATCH for 4.5] x86/VPMU: Clear last_vcpu when destroying VPMU
On 15.12.14 at 18:15, boris.ostrov...@oracle.com wrote:
On 12/15/2014 05:07 AM, Jan Beulich wrote:
On 12.12.14 at 22:20, boris.ostrov...@oracle.com 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 Improvement
=
As the COS of PCPU in IA32_PQR_ASSOC is changed on each VCPU context
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 'console type=pty/'
Then:
virDomainGetXMLDesc():
devices
console type='pty'
target type='xen' port='0'/
/console
/devices
virDomainOpenConsole()
virDomainGetXMLDesc():
devices
console type='pty' tty='/dev/pts/30'
source path='/dev/pts/30'/
target type='xen' port='0'/
/console
/devices
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 anthony.per...@citrix.com
---
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 libxl_evdisable_foo for these
events, so I'm not sure it is possible.
Ian.
___
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 15.12.14 at 23:24, boris.ostrov...@oracle.com 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, chao.p.p...@linux.intel.com 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 alex.ben...@linaro.org Amos Kong ak...@redhat.com Anton Blanchard an...@samba.org Antony Pavlov antonynpav...@gmail.com Bastian Koppelmann kbast...@mail.uni-paderborn.de Christoffer Dall christoffer.d...@linaro.org Dmitry Poletaev poletaev-q...@yandex.ru Dr. David Alan Gilbert dgilb...@redhat.com Fabian Aggeler aggel...@ethz.ch Fam Zheng f...@redhat.com Gary R Hook gary.h...@nimboxx.com Gerd Hoffmann kra...@redhat.com Gonglei arei.gong...@huawei.com Greg Bellows greg.bell...@linaro.org Jeff Cody jc...@redhat.com Jun Li junm...@gmail.com Kevin Wolf kw...@redhat.com lijun junm...@gmail.com Liviu Ionescu i...@livius.net Markus Armbruster arm...@redhat.com Max Reitz mre...@redhat.com Michael Mueller m...@linux.vnet.ibm.com Michael Tokarev m...@tls.msk.ru Nikita Belov zod...@ispras.ru Paolo Bonzini pbonz...@redhat.com Pavel Dovgalyuk pavel.dovga...@ispras.ru Peter Maydell peter.mayd...@linaro.org Richard Henderson r...@twiddle.net Sergey Fedorov s.fedo...@samsung.com Stefan Hajnoczi stefa...@redhat.com Thomas Huth th...@linux.vnet.ibm.com zhanghailiang zhang.zhanghaili...@huawei.com 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
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 Address
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
null_log_fn,
hash_fn = 0x4092f0 default_tdb_hash, 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 talloc_chunk_from_ptr+4
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 talloc_chunk_from_ptr+0: sub$0x8,%rsp
0x004075c4 talloc_chunk_from_ptr+4: 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 talloc_chunk_from_ptr+7: lea-0x50(%rdi),%rax
This is actually calculating tc, ready for return upon success.
0x004075cb talloc_chunk_from_ptr+11: mov%edx,%ecx
0x004075cd talloc_chunk_from_ptr+13: and
$0xfff0,%ecx
0x004075d0 talloc_chunk_from_ptr+16: cmp$0xe814ec70,%ecx
0x004075d6 talloc_chunk_from_ptr+22: jne0x4075e2
talloc_chunk_from_ptr+34
(tc-flags ~0xF) != TALLOC_MAGIC
0x004075d8 talloc_chunk_from_ptr+24: and$0x1,%edx
0x004075db talloc_chunk_from_ptr+27: jne0x4075e2
talloc_chunk_from_ptr+34
tc-flags TALLOC_FLAG_FREE
0x004075dd talloc_chunk_from_ptr+29: add$0x8,%rsp
0x004075e1 talloc_chunk_from_ptr+33: retq
Success, return.
0x004075e2 talloc_chunk_from_ptr+34: nopw 0x0(%rax,%rax,1)
0x004075e8 talloc_chunk_from_ptr+40: callq 0x401b98 abort@plt
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
[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 bob@oracle.com --- 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] 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 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=value optimized out, tdb_flags=0, open_flags=value optimized out, mode=value optimized out, log_fn=0x4093b0 null_log_fn, hash_fn=value optimized out) 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] xenstored crashes with SIGSEGV
2014-12-16 11:06 GMT+00:00 Ian Campbell ian.campb...@citrix.com: 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=value optimized out, tdb_flags=0, open_flags=value optimized out, mode=value optimized out, log_fn=0x4093b0 null_log_fn, hash_fn=value optimized out) 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 'console type=pty/'
Then:
virDomainGetXMLDesc():
devices
console type='pty'
target type='xen' port='0'/
/console
/devices
virDomainOpenConsole()
virDomainGetXMLDesc():
devices
console type='pty' tty='/dev/pts/30'
source path='/dev/pts/30'/
target type='xen' port='0'/
/console
/devices
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 anthony.per...@citrix.com
---
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 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
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 ian.campb...@citrix.com: 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=value optimized out, tdb_flags=0, open_flags=value optimized out, mode=value optimized out, log_fn=0x4093b0 null_log_fn, hash_fn=value optimized out) 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 0xff00 0x00ff 0x19212c0: 0x 0x00ff 0xff00
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] [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
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
[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 mar...@lucina.net
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
++ :
Re: [Xen-devel] xenstored crashes with SIGSEGV
2014-12-16 16:23 GMT+00:00 Ian Campbell ian.campb...@citrix.com: 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 berra...@redhat.com
Dmitry Guryanov dgurya...@parallels.com
Erik Skultety eskul...@redhat.com
Laine Stump la...@laine.org
Luyao Huang lhu...@redhat.com
Michal Privoznik mpriv...@redhat.com
Wang Rui moon.wang...@huawei.com
Wei Liu wei.l...@citrix.com
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
+++
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 ian.campb...@citrix.com (ARM and generic bits) Jan Beulich jbeul...@suse.com 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
[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 mdo...@bitdefender.com
---
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(unsigned long size,
[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 julien.gr...@linaro.org
---
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 11/13] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices
From: Andreas Herrmann andreas.herrm...@calxeda.com
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 herrmann.der.u...@googlemail.com
Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
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 03/13] xen: Introduce ACCESS_ONCE macro
This macro can be used in drivers imported from Linux. Signed-off-by: Julien Grall julien.gr...@linaro.org CC: Ian Jackson ian.jack...@eu.citrix.com CC: Jan Beulich jbeul...@suse.com CC: Keir Fraser k...@xen.org --- 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 julien.gr...@linaro.org --- 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 12/13] xen/iommu: smmu: Introduce automatic stream-id-masking
From: Andreas Herrmann andreas.herrm...@calxeda.com
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 herrmann.der.u...@googlemail.com
Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
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 linux/platform_device.h
#include linux/slab.h
#include linux/spinlock.h
+#include linux/bitops.h
#include linux/amba/bus.h
@@ -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
[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 julien.gr...@linaro.org --- 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 will.dea...@arm.com + * + * 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 linux/delay.h +#include linux/dma-mapping.h +#include linux/err.h +#include linux/interrupt.h +#include linux/io.h +#include linux/iommu.h +#include linux/mm.h +#include linux/module.h +#include linux/of.h +#include linux/pci.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/spinlock.h + +#include linux/amba/bus.h + +#include asm/pgalloc.h + +/* 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)
[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 julien.gr...@linaro.org
---
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, NS16550
[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 julien.gr...@linaro.org
CC: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
CC: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
CC: Jan Beulich jbeul...@suse.com
CC: Yang Zhang yang.z.zh...@intel.com
CC: Kevin Tian kevin.t...@intel.com
---
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)
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 m.a.yo...@durham.ac.uk Reviewed-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com 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 konrad.w...@oracle.com 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
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 david.vra...@citrix.com 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: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
