Re: [Xen-devel] [PATCH v1] Rename DEBUG_DIR to XEN_DEBUG_DIR

Am Tue, 13 Mar 2018 11:56:51 + schrieb Roger Pau Monné : > Do you think that would solve your issues? This will most likely work, yes. Thanks. Olaf pgpOkexrAA35u.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel

Re: [Xen-devel] [PATCH v4] new config option vtsc_tolerance_khz to avoid TSC emulation

Am Tue, 13 Mar 2018 17:04:25 + schrieb Wei Liu : > There were questions on previous patches as to why this approach is > better than what we already have. Are those comments addressed? Which questions? I do not see any. What we have is tsc_mode=native, which avoids

Re: [Xen-devel] [PATCH] tools/xenstore: add libdl dependency to libxenstore

On Fri, Mar 09, Juergen Gross wrote: > So how does this work? No idea, at least this output differs: abuild@latitude:~> readelf -Wa /usr/lib64/libpython2.7.so | grep dlsym 003e5e08 00d90007 R_X86_64_JUMP_SLOT dlsym@GLIBC_2.2.5 + 0 217:

Re: [Xen-devel] [PATCH] tools/xenstore: add libdl dependency to libxenstore

On Fri, Mar 09, Olaf Hering wrote: > abuild@latitude:~> readelf -Wa /usr/lib64/libpython2.7.so | grep dlsym > 003e5e08 00d90007 R_X86_64_JUMP_SLOT > dlsym@GLIBC_2.2.5 + 0 >217: 0 FUNCGLOBAL DEFAULT UND dlsym@GLI

[Xen-devel] staging fails to build due to missing qemu patch for memfd_create

Please update the qemu-xen tree to include 75e5b70e6b ("memfd: fix configure test"). Currently xen.git#staging fails like this: xen-staging/tools/qemu-xen-dir/util/memfd.c:40:12: error: static declaration of 'memfd_create' follows non-static declaration Thank you. Olaf signature.asc

Re: [Xen-devel] [PATCH] tools/xenstore: add libdl dependency to libxenstore

On Wed, Mar 07, Juergen Gross wrote: > On 07/03/18 13:06, ian.jack...@citrix.com wrote: > > Juergen Gross writes ("Re: [PATCH] tools/xenstore: add libdl dependency to > > libxenstore"): > >> On 07/03/18 12:19, Ian Jackson wrote: > >>> Juergen Gross writes ("[PATCH] tools/xenstore: add libdl

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

The point was to document the counter part. Grep -w 1024 is not helpful. Olaf___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4] new config option vtsc_tolerance_khz to avoid TSC emulation

l.h - update python tests - flask check bound to tsc permissions - not runtime tested due to dlsym() build errors in staging Signed-off-by: Olaf Hering <o...@aepfle.de> --- .gitignore | 1 + docs/man/xen-tscmode.pod.7 | 16 ++

Re: [Xen-devel] [PATCH v1] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

On Fri, Mar 09, Andrew Cooper wrote: > On 09/03/18 16:01, Olaf Hering wrote: > > The value of num is always the same as domctl->u.getpageframeinfo3.num, > > it was assigned just a few lines before. > > > > Signed-off-by: Olaf Hering <o...@aepfle.de> > >

[Xen-devel] [PATCH v2] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

The value of num is always the same as domctl->u.getpageframeinfo3.num, it was assigned just a few lines before. Avoid truncation by making num the same size as i, which is the only place where num is used. Signed-off-by: Olaf Hering <o...@aepfle.de> --- xen/arch/x86/domctl.c | 5 ++--

[Xen-devel] [PATCH v1] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

The value of num is always the same as domctl->u.getpageframeinfo3.num, it was assigned just a few lines before. Signed-off-by: Olaf Hering <o...@aepfle.de> --- xen/arch/x86/domctl.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/arch/x86/domctl.c b/xen

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On Fri, Mar 02, Wei Liu wrote: > But still, Juergen must have tested the change, so I wonder why it > doesn't work in your setup. What is your build environment? Gcc version? Unclear what the difference is between building in clean chroot and locally. This change fixes it for me: ---

[Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

sions - not runtime tested due to dlsym() build errors in staging Signed-off-by: Olaf Hering <o...@aepfle.de> --- .gitignore | 1 + docs/man/xen-tscmode.pod.7 | 16 + docs/man/xl.cfg.pod.5.in | 10 +++ docs/specs/libxc-mig

Re: [Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

Am Tue, 6 Mar 2018 11:07:54 + schrieb Andrew Cooper : > > One option to avoid the TSC option is to run domUs with tsc_mode=native. > > This has the drawback that migrating a domU from a "2.3GHz" class host > > to a "2.4GHz" class host may change the rate at wich the

[Xen-devel] [PATCH v1] xl: show full value of cpu_khz in xl info output

during live migration for the decision if access to TSC should be emualted. Commit eb5277a30e ("bitkeeper revision 1.959.1.4 (40d04a87acOb29u-5Y5OxMhHvP2x9g)" gives no hint why cpu_mhz instead of cpu_khz was chosen. Signed-off-by: Olaf Hering <o...@aepfle.de> -- This is related

[Xen-devel] crash in csched_load_balance after xl vcpu-pin

While hunting some other bug we run into the single BUG in sched_credit.c:csched_load_balance(). This happens with all versions since 4.7, staging is also affected. Testsystem is a Haswell model 63 system with 4 NUMA nodes and 144 threads. (XEN) Xen BUG at sched_credit.c:1694 (XEN) [

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Tue, Apr 10, Olaf Hering wrote: > (XEN) Xen BUG at sched_credit.c:1694 Another variant: This time the domUs had just vcpus=36 and cpus=nodes:N,node:^0/cpus_soft=nodes:N,node:^0 (XEN) Xen BUG at sched_credit.c:280 (XEN) [ Xen-4.11.20180407T144959.e62e140daa-2.bug1087289_411 x86

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Tue, Apr 10, Olaf Hering wrote: > (XEN) Xen BUG at sched_credit.c:1694 And another one with debug=y and this config: memory= vcpus=36 cpu="nodes:1,^node:0" cpu_soft="nodes:1,^node:0" (nodes=1 cycles between 1-3 for each following domU). (XEN) Assertion 'CSCHED_PCPU

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Tue, Apr 10, Dario Faggioli wrote: > On Tue, 2018-04-10 at 17:59 +0200, Olaf Hering wrote: > > memory= > > vcpus=36 > > cpu="nodes:1,^node:0" > > cpu_soft="nodes:1,^node:0" > As said, its cpus= and cpus_soft=, and you probably just need &g

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Tue, Apr 10, Olaf Hering wrote: > On Tue, Apr 10, Dario Faggioli wrote: > > > In the meanwhile --let me repeat myself-- just go ahead with "node:2", > > "node:3", etc. :-D > > I did, and that fails. I think the man page is not that clear, to me

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Tue, Apr 10, Dario Faggioli wrote: > So, Olaf, if you're fancy giving this a tray anyway, well, go ahead. BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc))); (XEN) Xen BUG at sched_credit.c:876 (XEN) [ Xen-4.11.20180410T125709.50f8ba84a5-3.bug1087289_411 x86_64 debug=y Not tainted ]

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Tue, Apr 10, Dario Faggioli wrote: > In the meanwhile --let me repeat myself-- just go ahead with "node:2", > "node:3", etc. :-D I did, and that fails. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Dario Faggioli wrote: > So, now, when you say 'does not work', do you mean 'domain creation is > aborted with errors' or 'domain is created, but memory is not where it > should be'. domU can not be created due to "libxl__set_vcpuaffinity: setting vcpu affinity: Invalid argument".

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Dario Faggioli wrote: > Olaf, can you give it a try? It should be fine to run it on top of the > last debug patch (the one that produced this crash). Yes, with both changes it did >4k iterations already. Thanks. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Dario Faggioli wrote: > If you're interested in figuring out, I'd like to see: > - full output of `xl info -n' > - output of `xl debug-key u' > - xl vcpu-list > - xl list -n Logs for this .cfg attached: name='fv_sles12sp1.0' vif=[ 'mac=00:18:3e:58:00:c1,bridge=br0' ] memory=

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Olaf Hering wrote: > On Wed, Apr 11, Dario Faggioli wrote: > > > Olaf, can you give it a try? It should be fine to run it on top of the > > last debug patch (the one that produced this crash). > > Yes, with both changes it did >4k iterations already. T

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Olaf Hering wrote: > On Wed, Apr 11, Olaf Hering wrote: > > On Wed, Apr 11, Dario Faggioli wrote: > > > Olaf, can you give it a try? It should be fine to run it on top of the > > > last debug patch (the one that produced this crash). > >

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

Am Wed, 11 Apr 2018 09:38:59 -0600 schrieb "Jan Beulich" : > And till now I had assumed we've taken care of them with earlier > fixes (all 4.7 reports were with old packages, like 4.7.2 based > ones). Can you repro this with a debug hypervisor (so we can > both trust the stack

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Dario Faggioli wrote: > It will crash, again, possibly with the same stack trace, but I think > it's worth a try. BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc))); (XEN) grant_table.c:1769:d15v18 Expanding d15 grant table from 12 to 13 frames (XEN) grant_table.c:1769:d15v20 Expanding

[Xen-devel] bug in _shadow_prealloc during migration of PV domU

I was testing 'virsh migrate domU host' and did some libvirtd debugging on 'host'. This means the migration was attempted a few times, but did not actually start because libvirtd was in gdb. Not sure if libvirt on the sender does anything with the domU before a connection to the remote host is

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

Am Thu, 12 Apr 2018 12:16:34 +0200 schrieb Dario Faggioli : > Olaf, new patch. Please, remove _everything_ and apply _only_ this one. dies after the first iteration. BUG_ON(!test_bit(_VPF_migrating, >pause_flags)); (XEN) Xen BUG at schedule.c:1570 (XEN) [

Re: [Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation

Am Mon, 09 Apr 2018 08:19:53 -0600 schrieb "Jan Beulich" : > Is there any guarantee that old hypervisors will send this field as zero > (rather than some random value)? If so, I think this should be said > explicitly in the commit message, together with the fact that you >

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Fri, Apr 13, Dario Faggioli wrote: > Yes. In fact, Olaf, I still think that doing a run with George's RFC > applied, would be useful, if only as a data point. First tests indicate that this series fixes the bug. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Tue, Apr 10, Dario Faggioli wrote: > I remember specifically wanting for it to support not only "nodes:", but also > "node:", because I thought that, e.g., "nodes:3" would have sound weird to > users. It turned out that I had a typo all the time in my template, it used 'cpu=' rather than

Re: [Xen-devel] [RFC PATCH 2/3] xen: Refactor migration

Am Tue, 17 Apr 2018 09:20:33 +0200 schrieb Dario Faggioli <dfaggi...@suse.com>: > And I guess we can add a 'Tested-by: Olaf Hering', as he actually did > that, what do you say Olaf? Yes, that is true. I have tested these three patches with staging. Tested-by: Olaf Hering <o...@a

Re: [Xen-devel] bogus wrap check in xen-netback

Am Wed, 25 Apr 2018 09:28:38 +0200 schrieb Juergen Gross : > Why? (u16)0 - (u16)65400 == 136 My helloworld.c shows that ushort gets promoted to uint, unless it is done like that: - if (queue->tx.sring->req_prod - queue->tx.req_cons > -

Re: [Xen-devel] bogus wrap check in xen-netback

Am Wed, 25 Apr 2018 11:31:25 +0100 schrieb Wei Liu : > My bad. Yes, they are converted to int, not unsigned int. Hopefully that happens only if the target is int, not if all involved variables are short. Unless there are objections I will prepare a patch to deal with

Re: [Xen-devel] bogus wrap check in xen-netback

Am Wed, 25 Apr 2018 09:59:23 +0100 schrieb Wei Liu : > Do you have the full diff of your changes? Not right now. But without 'val', or val being uint, the same error happens in f(): #include void f(void) { unsigned short req_prod = 0, req_cons = 65400;

[Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

tsc_tolerance_khz v3: - rename vtsc_khz_tolerance to vtsc_tolerance_khz - separate domctls to adjust values - more docs - update libxl.h - update python tests - flask check bound to tsc permissions - not runtime tested due to dlsym() build errors in staging Signed-off-by: Olaf Hering <o.

Re: [Xen-devel] [PATCH for-4.11] tools: set DEBUG_DIR from configure

On Tue, Mar 27, Roger Pau Monne wrote: > +AC_ARG_WITH([debugdir], > +AS_HELP_STRING([--with-debugdir=DIR], > +[Path to directory for debug symbols. [PREFIX/usr/lib/debug]]), > +[debugdir_path=$withval], > +[debugdir_path=$prefix/usr/lib/debug]) Would that create

[Xen-devel] [PATCH v7] new config option vtsc_tolerance_khz to avoid TSC emulation

- separate domctls to adjust values - more docs - update libxl.h - update python tests - flask check bound to tsc permissions - not runtime tested due to dlsym() build errors in staging Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/man/xen-tscmode.pod.7 | 16 +++

[Xen-devel] stubdom --disable-pv-grub has not effect

Since the source of pv-grub is not ready for todays compilers, and we have pvgrub2, I tried to disable it with --enable-stubdom --disable-pv-grub. But the toplevel Makefile does "make install-grub" unconditionally. I'm not familiar with stubdom. Is pvgrub a hard requirement for every stubdom

Re: [Xen-devel] [PATCH v7] new config option vtsc_tolerance_khz to avoid TSC emulation

On Sun, Apr 01, Andrew Cooper wrote: > On 01/04/18 18:03, Olaf Hering wrote: > > diff --git a/tools/libxc/xc_sr_stream_format.h > > b/tools/libxc/xc_sr_stream_format.h > > index 15ff1c7efb..9b52f6ace6 100644 > > --- a/tools/libxc/xc_sr_stream_format.h > > +++ b/

[Xen-devel] [PATCH v8] new config option vtsc_tolerance_khz to avoid TSC emulation

d this change showed a jitter of up to 200 KHz across systems of the same class. Existing padding fields are reused to store vtsc_khz_tolerance as u16. Signed-off-by: Olaf Hering <o...@aepfle.de> -- v8: - adjust also python stream checker for added tolerance member v7: - use uint16 in lib

Re: [Xen-devel] seabios regression in staging

On Thu, Mar 29, Doug Goldstein wrote: > If you'd be willing to create a SLE11 Docker container, we can add that > to the tree and start doing builds against it. I do not know how to do that. Any pointers? Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

On Thu, Mar 29, Jan Beulich wrote: > Actually I was wrong - we have an abstraction already, just that > it's upper case: ABS(). But it requires its input to have signed type. Would this be acceptable? khz_diff = ABS((long)cpu_khz - (long)gtsc_khz); Olaf signature.asc Description: PGP

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

On Thu, Mar 29, Jan Beulich wrote: > >>> On 27.03.18 at 11:26, wrote: > > +khz_diff = cpu_khz > gtsc_khz ? > > + cpu_khz - gtsc_khz : gtsc_khz - cpu_khz; > abs() (or some variant of it, like __builtin_absl(), seeing that we > don't appear to have

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

On Thu, Mar 29, Roger Pau Monné wrote: > IMO if hardware TSC scaling is supported vtsc_tolerance_khz should be > ignored, and the TSC should be scaled by the hardware always in order > to provide accurate values. Good point, I will double check that part and do nothing if hardware scaling

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

On Thu, Mar 29, Jan Beulich wrote: > When you use abs() or alike in places like this, it is more immediately > obvious to the reader what you're doing. Does every supported compiler actually understand this? int khz_diff = __builtin_abs(cpu_khz - gtsc_khz); Or do we need an inline abs() in case

[Xen-devel] fuzz/wrappers.c fails to build due to missing x86-emulate.h

In my automated SLE_11 builds I often see failures like that: [ 74s] wrappers.c:5:25: error: x86-emulate.h: No such file or directory [ 74s] make[6]: *** [wrappers.o] Error 1 Just retriggering the package build fixes the error. SLE11 has make-3.81. Is that version of make perhaps too old to

Re: [Xen-devel] fuzz/wrappers.c fails to build due to missing x86-emulate.h

On Thu, Mar 29, Jan Beulich wrote: > wrappers.o: $(x86_emulate.h) Thanks. This did probably help, the build got further. Will send a patch. But another unrelated regression appeared. Olaf signature.asc Description: PGP signature ___ Xen-devel

[Xen-devel] [PATCH v1] fuzz: wrappers.c depends on x86_emulate.h

In my automated SLE_11 builds I often see failures like that: [ 74s] wrappers.c:5:25: error: x86-emulate.h: No such file or directory [ 74s] make[6]: *** [wrappers.o] Error 1 Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/fuzz/x86_instruction_emulator/Makefile | 2 ++ 1 file c

[Xen-devel] seabios regression in staging

It seems the latest seabios that was pulled into staging recently fails to compile, at least in SLE_11: [ 86s] Compile checking out/src/hw/blockcmd.o [ 86s] src/hw/blockcmd.c: In function 'scsi_rep_luns_scan': [ 86s] src/hw/blockcmd.c:229: error: unknown field 'cdbcmd' specified in

[Xen-devel] [PATCH v6] new config option vtsc_tolerance_khz to avoid TSC emulation

ython tests - flask check bound to tsc permissions - not runtime tested due to dlsym() build errors in staging Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/man/xen-tscmode.pod.7 | 16 docs/man/xl.cfg.pod.5.in | 10 ++ docs/specs/lib

Re: [Xen-devel] stubdom --disable-pv-grub has not effect

Am Mon, 2 Apr 2018 10:44:23 +0100 schrieb Wei Liu : > I suppose you hit some sort of compile error because pv-grub has rotten? A post-build check scans the build log for warnings. Some of them are seen as fatal, and the otherwise successful build is marked as FAIL, no rpm

Re: [Xen-devel] stubdom --disable-pv-grub has not effect

On Sun, Apr 01, Wei Liu wrote: > No. That's a bug in our build system. Thanks. For some reason only gcc48-4.8.3.rpm from SLE_11 is affected, not gcc43-4.3.4.rpm from SLE_11 nor gcc48-4.8.5.rpm from SLE_12. This fixes my packages for the time being: sed -i '/ stubdom install-grub/d' Makefile

Re: [Xen-devel] seabios regression in staging

On Thu, Mar 29, Wei Liu wrote: > Do you use a non-default seabios configuration? Osstest seems to be > happy with the update. Not sure how I would create a non-default seabios or toolchain build. osstest does not use SLE11, so it can not possibly spot such compile errors. It would certainly be

Re: [Xen-devel] seabios regression in staging

On Thu, Mar 29, Wei Liu wrote: > I think this is a problem with seabios upstream. We should ask them to > fix it and do another release. https://mail.coreboot.org/pipermail/seabios/2017-November/011932.html gcc-4.6+ is now required. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH v3] new config option vtsc_tolerance_khz to avoid TSC emulation

So, how do we address the performance regression fixed by this patch? Olaf Am Mon, 12 Mar 2018 10:15:08 +0100 schrieb Olaf Hering <o...@aepfle.de>: > Am Tue, 6 Mar 2018 11:07:54 + > schrieb Andrew Cooper <andrew.coop...@citrix.com>: > &

[Xen-devel] [PATCH v2] new config option vtsc_khz_tolerance to avoid TSC emulation

eam should get a new record type, the ordering of records sent during migration becomes important. The value of vtsc_khz_tolerance must be known by the receiving host before configuring TSC, because this is the place where the decision of vTSC emulation is made. Signed-off-by: Olaf Hering <o...@a

Re: [Xen-devel] [PATCH v2] new config option vtsc_khz_tolerance to avoid TSC emulation

Am Mon, 05 Mar 2018 06:18:17 -0700 schrieb "Jan Beulich" : > >>> On 05.03.18 at 12:35, wrote: > > One thing I'm missing in the description (or the added documentation) > is a discussion of the conditions under which it is safe to make use of > the new

Re: [Xen-devel] [PATCH v2] new config option vtsc_khz_tolerance to avoid TSC emulation

Am Mon, 05 Mar 2018 07:45:24 -0700 schrieb "Jan Beulich" : > I'm only talking about additions you make, and I don't see a size > difference between "vtsc_khz_tolerance" and "vtsc_tolerance_khz". Oh, I misunderstood that sentence. I will change the name as suggested. Olaf

[Xen-devel] untracked pvshim related dirty files in staging

While building staging I got these two untracked dirty files. I wonder what should be done about it? Changes not staged for commit: modified: tools/firmware/xen-dir/shim.config Untracked files: tools/firmware/xen-dir/xen-shim-syms What is the value of adding version and

[Xen-devel] Usage of DEBUG_DIR breaks OVMF build

The default DEBUG_DIR=/usr/lib/debug can not be used for rpm builds because that directory is "owned" by rpm-packaging itself to store the autogenerated ${pkg}-debuginfo.rpm data. Thats why I set it to /boot. This worked fine until recently, only /boot/xen-syms was affected by that change, and in

[Xen-devel] usage of libxc compat function fails with staging

I have a matrix of various qemu.git#stable-x.y that build against xen.git#staging*. Since some months qemu.git#stable-2.x fails to build against xen.git#staging. qemu-2.10+ works with staging. To me it is not clear how to fix this failure:

[Xen-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS

: 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6 Signed-off-by: Olaf Hering --- include/hw/xen/xen_common.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h index 5f1402b494..33fa2d3497 100644 --- a/include/hw/xen/xen_common.h +++ b

Re: [Xen-devel] usage of libxc compat function fails with staging

Am Thu, 25 Oct 2018 14:08:08 +0200 schrieb Olaf Hering : > qemu-2.9-20170907T112512.4cd42653f5/include/hw/xen/xen_common.h:61:16: > warning: implicit declaration of function 'xc_map_foreign_bulk' > qemu is built with the various compat flags like > :-DXC_WANT_COMPAT_MAP_FOREIGN_AP

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

Thanks for all the replies. I will work through them. One remark now: Am Mon, 1 Oct 2018 13:39:51 +0100 schrieb Andrew Cooper : > > With the new option the host admin can decide how a domU should behave > > when it is migrated across systems of the same class. Since there is > > always some

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

Am Thu, 13 Sep 2018 09:39:13 +0200 schrieb Olaf Hering : > this patch was not applied yet, even after a few "pings". No reaction since months. So scrap that patch, just in case it is still part of someones to-consider queue. Olaf pgpFtD6Pj968F.pgp Description: Digitale Signatu

[Xen-devel] tools/fuzz fails due build, osstest did not notice

Since about two months staging fails to build because tools/fuzz can not cope with CFLAGS="-O2 -Wall -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection". While I can easily hide the bug by undefining _FORTIFY_SOURCE, I always wonder why osstest does

Re: [Xen-devel] tools/fuzz fails due build, osstest did not notice

Am Mon, 03 Sep 2018 06:35:42 -0600 schrieb "Jan Beulich" : > what is the actual problem? The mere > listing of compiler flags passed does not make clear to me where the clash > is, or how it would surface. As I noticed just now, it fails to build only in Tumbleweed. So in this specific case

Re: [Xen-devel] Command line options of dubious use

On Mon, Dec 31, Andrew Cooper wrote: > * tbuf_size and tevt_mask > Given that xentrace can set them at runtime, and it is debugging > functionality, I don't see a plausible use the command line options at all. 'tbuf_size=-1 dom0_mem=N' collects events during boot. xenalyze is (or was) unable to

Re: [Xen-devel] [PATCH] tools/firmware: update OVMF Makefile

Am Mon, 14 Jan 2019 17:44:57 + schrieb Wei Liu : > - $(GIT) submodule update --init --recursive > + [ -d .git ] && $(GIT) submodule update --init --recursive This syntax fails, but this works for me: if test -d .git ; then $(GIT) submodule update --init --recursive ;

Re: [Xen-devel] [PATCH] tools/firmware: update OVMF Makefile

Am Mon, 14 Jan 2019 17:11:56 + schrieb Anthony PERARD : > I think it's fine to keep the current `submodule update` call where it > is. We could just make it check that it's an actual git worktree by > checking for the presence of ".git" (file or directory) before executing > git. > > Would

[Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

ected to still cover the possible drift that NTP can handle. Signed-off-by: Olaf Hering -- v11: - trim patch and use calculated tolerance value, no admin interaction required v10: - rebase to ae01a8e315 - remove changes for libxl and save/restore protocol, the feature has to be per host

Re: [Xen-devel] qemu assert in staging during HVM live migration

Am Fri, 23 Nov 2018 15:54:49 + schrieb Anthony PERARD : > On Thu, Nov 22, 2018 at 11:03:45AM +0100, Olaf Hering wrote: > > qemu-system-i386: block/block-backend.c:903: blk_get_attached_dev_id: > > Assertion `!blk->legacy_dev' failed. > xen-disk (qdisk) is currently using

[Xen-devel] [PATCH v1] xen_disk: fix memory leak

uf before reassignment. Signed-off-by: Olaf Hering --- hw/block/xen_disk.c | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 36eff94f84..e15eefe625 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @

[Xen-devel] memory leak in block/xen_disk in qemu-3.x

What are the live time rules of ioreq->buf? In my testing the memory usage of qemu is constantly growing from about 250MB to several GB after a few days. Some debugging shows that ioreq_runio_qemu_aio() overwrites ioreq->buf, which contributes to the leak. In addition, ioreq_reset() also just

Re: [Xen-devel] memory leak in block/xen_disk in qemu-3.x

On Tue, Dec 11, Paul Durrant wrote: > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > > Of Olaf Hering > > Sent: 11 December 2018 15:31 > > To: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org > &

Re: [Xen-devel] [PATCH v10] new config option vtsc_tolerance_khz to avoid TSC emulation

On Fri, Dec 07, Olaf Hering wrote: > [ the math added to xen-tscmode.7 suggests that a domU should see a time > drift, which ntpd corrects. But the actual correction reported in > ntp.drift is entirely different than the one calculated in the > example. To me it is unclear why

Re: [Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

Am Wed, 12 Dec 2018 09:39:25 -0700 schrieb "Jan Beulich" : > >>> On 12.12.18 at 16:20, wrote: > > If a domU uses TSC as clocksoure it also must run NTP in some way to > > avoid the potential drift what will most likely happen, independent of > > any migration. > Which drift? While anyone's

Re: [Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

Am Thu, 13 Dec 2018 01:45:39 -0700 schrieb "Jan Beulich" : > >>> On 13.12.18 at 09:18, wrote: > > Am Wed, 12 Dec 2018 09:39:25 -0700 > > schrieb "Jan Beulich" : > > > >> >>> On 12.12.18 at 16:20, wrote: > >> > If a domU uses TSC as clocksoure it also must run NTP in some way to > >> >

Re: [Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

Am Thu, 13 Dec 2018 03:41:44 -0700 schrieb "Jan Beulich" : > In a second step, let's consider what impact errors in calibration have. > Between two systems with exactly the same hardware crystal > frequency there of course is going to be some drift. The problem > though is - between the two

Re: [Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

Am Thu, 13 Dec 2018 03:41:44 -0700 schrieb "Jan Beulich" : > And further argumentation that everyone is using NTP anyway > doesn't make it any better, when it's no-where written down that > Xen is unusable with NTP running in all guests (I'm exaggerating > here just to get the point over). Don't

Re: [Xen-devel] xen_disk qdevification (was: [PATCH 0/3] Performance improvements for xen_disk v2)

On Fri, Nov 02, Kevin Wolf wrote: > A while ago, a downstream patch review found out that there are some QMP > commands that would immediately crash if a xen_disk device were present > because of the lacking qdevification. This is not the code quality > standard I envision for QEMU. It's time for

Re: [Xen-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS

Ping? On Fri, Oct 26, Olaf Hering wrote: > A given Qemu version can not predict what version of Xen it will run on. > There are some checks in configure to decide what Xen libraries and > functions are available. How exactly these functions must be accessed > has to be decided

Re: [Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

Am Thu, 13 Dec 2018 07:46:36 -0700 schrieb "Jan Beulich" : > >>> On 13.12.18 at 14:25, wrote: > > The question is, how much drift can be tolerated even without my patch. > This depends on what a system is used for. A few seconds off may > be fine for one purpose, but a significant problem

Re: [Xen-devel] [PATCH v2] xl: free bitmaps on exit

Am Tue, 27 Nov 2018 17:19:06 + schrieb Wei Liu : > The other option -- to call atexit right after -- looks plausible to me. After looking through main(), moving the atexit() seems safe to me. Olaf pgpYhWjmpbrZl.pgp Description: Digitale Signatur von OpenPGP

[Xen-devel] [PATCH v10] new config option vtsc_tolerance_khz to avoid TSC emulation

the newly added knob is a global, optional per-host configuration file. Since it affects only the restore path, the used configfile is /etc/xen/sr.conf. Signed-off-by: Olaf Hering -- v10: - rebase to ae01a8e315 - remove changes for libxl and save/restore protocol, the feature has to be per host

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

Thanks Andrew and Ian for taking the time to look at this change. In turn it took me some time to get back to this topic. Am Mon, 1 Oct 2018 13:39:51 +0100 schrieb Andrew Cooper : > On 07/06/18 14:08, Olaf Hering wrote: > > Add an option to control when vTSC emulation will be

Re: [Xen-devel] qemu assert in staging during HVM live migration

Am Fri, 23 Nov 2018 15:54:49 + schrieb Anthony PERARD : > Is your toolstack runs the QMP command 'query-block' or some other > command related to block behind libxl's back? This is plain xl create + xl migrate from staging. > Beside that, I don't know if something else might be wrong. What

Re: [Xen-devel] [PATCH v2] xl: free bitmaps on exit

Am Tue, 27 Nov 2018 16:55:38 + schrieb Wei Liu : > Looking more closely into this, these lines should be moved even > earlier before the call to libxl_ctx_alloc -- there is an exit there. Is it required to install the atexit handler before alloc()? To me it looks like atexit(xl_ctx_free)

[Xen-devel] qemu assert in staging during HVM live migration

While debugging something else, it turned out that staging and/or qemu can not migrate HVM domUs. qemu runs into an assert when the domU is about to be migrated with 'xl migrate domU dom0': qemu-system-i386: block/block-backend.c:903: blk_get_attached_dev_id: Assertion `!blk->legacy_dev' failed.

Re: [Xen-devel] [PATCH v1] xl: free bitmaps on exit

Am Mon, 26 Nov 2018 15:58:22 +0100 schrieb Olaf Hering : > +++ b/tools/xl/xl.c > @@ -229,6 +229,9 @@ static void parse_global_config(const char *configfile, Actually I think that should go to xl_ctx_free() instead. I moved it down to parse_global_config() by accident. Olaf pgptRsIXARF

[Xen-devel] [PATCH v2] xl: free bitmaps on exit

Every invocation of xl via valgrind will show three leaks. Since libxl_bitmap_alloc uses NOGC, the caller has to free the memory after use. And since xl_ctx_free might be called before parse_global_config, also move the libxl_bitmap_init calls into xl_ctx_alloc. Signed-off-by: Olaf Hering

Re: [Xen-devel] [PATCH v1] Increase framebuffer size to todays standards

Am Mon, 26 Nov 2018 03:31:27 -0700 schrieb "Jan Beulich" : > And I think a change like this should (a) address the more general > case rather than just your laptop (or laptops in general) and (b) > actually add some headroom. Hence at the very least I'd see us > go to 4096x3072. WHUXGA would even

[Xen-devel] [PATCH v3] xl: free bitmaps on exit

() after xl_ctx_alloc, because the latter is also called again in postfork. Signed-off-by: Olaf Hering --- tools/xl/xl.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/tools/xl/xl.c b/tools/xl/xl.c index 7d2142f16f..ddd29b3f1b 100644 --- a/tools/xl/xl.c +++ b/tools/xl

[Xen-devel] [PATCH v1] Increase framebuffer size to todays standards

arbitrary, so just bump them to fix my system. The filters for notebooks at https://geizhals.eu/ indicate the upper limit could be even larger, like 3840x2160. Fixes commit e7cb35e8b1b8f872d906800c72f92f10d701f79c ("xen: introduce a generic framebuffer driver") Signed-off-by: Olaf Hering

Re: [Xen-devel] status of non-live migration of HVM with libvirt

Am Fri, 4 Jan 2019 17:48:31 +0100 schrieb Olaf Hering : > Am Fri, 4 Jan 2019 16:57:55 +0100 > schrieb Olaf Hering : > > > worth keeping (and fixing) the concept of an "offline migration" > > And regarding the fix, it looks like qmp_xen_save_devices_state does n

Re: [Xen-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS

Am Thu, 13 Dec 2018 11:05:25 + schrieb Anthony PERARD : > Hi, > > Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen > libs be able to use old interfaces. Do you think it's a good idea to > have this consumers (QEMU here) #undef the flag when it has implemented > the

<    1   2   3   4   5   6   7   8   9   10   >