Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

On Wed, Nov 29, Jan Beulich wrote: > With all of the above, was it considered to check /sys/hypervisor > alongside with or perhaps even in preference to /proc/xen? Yes. /proc/xen/capabilities is the one and only place that indicates a dom0. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

On Wed, Nov 29, Jan Beulich wrote: > But in the description you talk about detect_vm() - by its name that > doesn't look to care about Dom0, but whether running on top of > _some_ hypervisor. dom0 has to be handled as "no virtualization" because it has access to all hardware, all services

[Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

list of ignored paths and adjust the check for API mounts. Now "proc-xen.mount" is silently accepted, it gets into state "start condition failed" because "ConditionPathExists=!/proc/xen/capabilities was not met". But all units depending on "proc-xen.mount" sta

[Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

I assume OSS test does not test realworld live migration, therefore the following regression remained unnoticed: name="hvm" builder="hvm" memory=555 vcpus=4 serial="pty" boot="c" disk=[ 'qcow2:/nfs/vdisk.qcow2,hda,w', ] device_model_version="qemu-xen" xl create -cf hvm.cfg sleep N xl migrate hvm

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Thu, 10 May 2018 11:40:18 +0100 schrieb Anthony PERARD : > I'm not sure if that information is going to help, but that what I have > for now about the lock of block images. I think the issue is not with two dom0s locking the same file, but with one qemu process

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Tue, 8 May 2018 18:40:26 +0200 schrieb Olaf Hering <o...@aepfle.de>: > It looks like the IDE unplug is not permanent. Stefano, Jochen pointed me to commit 512b109ec962 ("xen: unplug the emulated devices at resume time"), which I think is wrong. The kernel will most

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Wed, 9 May 2018 14:43:17 -0700 (PDT) schrieb Stefano Stabellini : > 512b109ec962 is a very old commit: why is it causing problems to Xen > 4.10 and Xen 4.11 HVM migration? What is the error exactly? Sorry, I > might be missing some context. It is papering over the real

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Wed, 9 May 2018 14:08:14 -0700 (PDT) schrieb Stefano Stabellini : > I cannot find 512b109ec962 or "xen: unplug the emulated devices at > resume time" anywhere, neither in qemu.org/master nor in the qemu-xen > trees. What am I missing? It is a 7 years old kernel patch.

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Mon, 7 May 2018 17:19:46 +0200 schrieb Olaf Hering <o...@aepfle.de>: > What I gathered during debugging so far is that somehow qemu on the receiving > side locks a region twice: After further debugging with many wild printfs: On the receiving side blockdev_init sets BDRV_O_INAC

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Tue, 8 May 2018 13:31:43 +0200 schrieb Olaf Hering <o...@aepfle.de>: > On the sending side offset 0xc9 is unlocked on the other fd, which allows > F_WRLCK to succeed: > > It seems on the receiving side some code forgets to unclock offset 0xc9, > which causes F_WRLCK to

Re: [Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

Am Fri, 18 May 2018 09:25:07 +0200 schrieb Juergen Gross : > debianhvm The patch is for non-HVM, so perhaps these failures are something else. To me it was not clear from the faillog what exactly failed. Olaf pgpY2ULaICJiC.pgp Description: Digitale Signatur von OpenPGP

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Mon, 7 May 2018 17:19:46 +0200 schrieb Olaf Hering <o...@aepfle.de>: > With qemu-2.11 the sender thinks everything is alright and the domU is moved. Another case of breakage in qemu-2.11: if the targethost does not even have access to the diskimage the sender still thinks e

[Xen-devel] how to recognize in libxl that a domU has qemu-xen attached?

In the other thread about the unsolved migration bugs in qemu-xen it became clear that "xen-save-devices-state" must not only be called for HVM, but for every domU that has qemu-xen attached to it. I wonder how to check for that fact from the migration code. While it can continue to rely on

[Xen-devel] [PATCH v1] libxl: fix return code in qmp_synchronous_send

Use error code from libxl namespace, a plain -1 is not valid in this context. Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/libxl/libxl_qmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index be1fda18ba..0fe4

Re: [Xen-devel] how to recognize in libxl that a domU has qemu-xen attached?

Am Thu, 17 May 2018 14:55:10 +0200 schrieb Juergen Gross : > libxl__need_xenpv_qemu() is used to determine whether a pv domain needs > a qemu process for at least one backend. Thanks. Too bad, d_config is not available in that context. It is probably known somewhere by the

Re: [Xen-devel] how to recognize in libxl that a domU has qemu-xen attached?

Am Thu, 17 May 2018 16:54:00 +0200 schrieb Olaf Hering <o...@aepfle.de>: > Am Thu, 17 May 2018 14:55:10 +0200 > schrieb Juergen Gross <jgr...@suse.com>: > > libxl__need_xenpv_qemu() is used to determine whether a pv domain needs > > a qemu process for at least one

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

Am Tue, 3 Apr 2018 13:14:11 +0200 schrieb Olaf Hering <o...@aepfle.de>: > The exact value of cpu_khz can only be obtained via 'xl dmesg', and > therefore can be lost after some time. 'xl info' truncates the value to > full MHz. Adjust the output to show the full khz value. > T

[Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

se places, it should be enough to check if xenstore contains the relevant info. Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/libxl/libxl_dom_suspend.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_su

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Thu, 10 May 2018 11:40:18 +0100 schrieb Anthony PERARD : > I did fix the bug in QEMU 2.11 (5d6c599fe1d69a1bf8c5c4d3c58be2b31cd625ad) > so Xen 4.11 does include it it the qemu-xen tree. Is this supposed to be called also for PV? In my testing

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

On Tue, Mar 27, Roger Pau Monne wrote: > Allow the path to be set from a configure command line option. Please backport 641f9ce2fa to 4.10 ASAP. See https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02749.html Thanks. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

Am Tue, 22 May 2018 12:14:29 +0100 schrieb Wei Liu : > I think your predicate is correct. Sorry for the noise. Is there anything else to be done to get this fixed? Olaf pgpyQZGDs0CyK.pgp Description: Digitale Signatur von OpenPGP

Re: [Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

Am Fri, 18 May 2018 18:01:42 +0100 schrieb Wei Liu : > You don't need to test if the guest is HVM anymore. You only need to > know if QEMU upstream is running. libxl__domain_suspend_device_model handles qemu-xen and qemu-xen-trad. That function can not be called

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Wed, 16 May 2018 16:53:28 +0200 schrieb Olaf Hering <o...@aepfle.de>: > Am Thu, 10 May 2018 11:40:18 +0100 > schrieb Anthony PERARD <anthony.per...@citrix.com>: > > I did fix the bug in QEMU 2.11 (5d6c599fe1d69a1bf8c5c4d3c58be2b31cd625ad) > > so Xen 4.11 does i

Re: [Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

Am Mon, 21 May 2018 09:18:20 +0100 schrieb Wei Liu : > What I mean is: now you seem to want to call > libxl__domain_suspend_device_model when QEMU upstream is running, > regardless of whether a guest is HVM or PV, so the check for HVM should > be gone.

Re: [Xen-devel] [PATCH v1] unmodified_drivers: unplug the emulated devices at resume time

Am Tue, 12 Jun 2018 09:01:07 -0600 schrieb "Jan Beulich" : > So there's no plan to fix this on the qemu side? Even if there would be one, existing dom0s may not get an update in time. I sent some prototype of a potential fix for qemu, it needs more work. Olaf pgpzDYSfvvGmr.pgp Description:

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

as no code to verify that padding is indeed zero. Due to the lack of a version field it is impossible to know if the sender already has the newly introduced vtsc_tolerance field. In the worst case the receiving domU will get an unemulated TSC. Signed-off-by: Olaf Hering Reviewed-by: Wei Liu (v07/v

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

Am Thu, 07 Jun 2018 08:44:41 -0600 schrieb "Jan Beulich" : > The re-use of the field is acceptable only if all existing senders reliably > fill zero in there. How do we know all senders? I just know about write_tsc_info from xen-4.6+. Olaf pgp7WNmQ7W4Jd.pgp Description: Digitale Signatur von

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

On Thu, Jun 07, Jan Beulich wrote: > >>> On 07.06.18 at 16:49, wrote: > > Am Thu, 07 Jun 2018 08:44:41 -0600 > > schrieb "Jan Beulich" : > >> The re-use of the field is acceptable only if all existing senders reliably > >> fill zero in there. > > How do we know all senders? I just know about

[Xen-devel] [PATCH v1] stubdom/vtpm: fix memcmp in TPM_ChangeAuthAsymFinish

gcc8 spotted this error: error: 'memcmp' reading 20 bytes from a region of size 8 [-Werror=stringop-overflow=] Signed-off-by: Olaf Hering --- stubdom/Makefile| 1 + stubdom/vtpm_TPM_ChangeAuthAsymFinish.patch | 12 2 files changed, 13 insertions

[Xen-devel] [PATCH v1] unmodified_drivers: unplug the emulated devices at resume time

domUs can be migrated to unfixed hosts. Signed-off-by: Olaf Hering --- .../linux-2.6/platform-pci/platform-pci.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c b/unmodified_drivers/linux-2.6/platform-pc

[Xen-devel] [PATCH staging-4.10 v1] tools: set DEBUG_DIR from configure

From: Roger Pau Monne 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

[Xen-devel] [PATCH v1] stubdom/vtpm: include stdio.h for declaration of printf

ected: "); vtpmblk.c:322:7: warning: incompatible implicit declaration of built-in function 'printf' vtpmblk.c:322:7: note: include '' or provide a declaration of 'printf' Signed-off-by: Olaf Hering --- stubdom/vtpm/vtpmblk.c | 1 + 1 file changed, 1 insertion(+) diff --git a/stubdom/vtpm/vtpmblk.c

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

On Fri, May 25, Ian Jackson wrote: > Can you please provide that information ? That should really have > been in your commit message, as the git commit id. TBH, most of what > is in that email could profitably have been in your commit message... Perhaps 641f9ce2fa should have been more

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

Am Thu, 7 Jun 2018 15:08:29 +0200 schrieb Olaf Hering : > Add an option to control when vTSC emulation will be activated for a > domU with tsc_mode=default. Without such option each TSC access from > domU will be emulated, which causes a significant perfomance drop for > workloads t

[Xen-devel] xl vcpu-set in HVM domU fails change cpu online count

xl vcpu-set with a HVM domU sends an ACPI event to do hot-add of cpus. But if the vcpu count is decreased the domU does not offline any cpu. So far the only way to enforce offlining is to process the output of 'xenstore-watch cpu'. Why is HVM excluded in

[Xen-devel] [PATCH] docs: fix kernel config option in xen-pv-channel

HVC is shown underlined, the underscores are missing. Fix it by using underscores. Remove stale I. Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/man/xen-pv-channel.pod.7 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/man/

[Xen-devel] qemu-xen fails to build in staging

With current staging, qemu-xen fails to build. It looks like a ordering issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file. It is (as always) a fresh clean checkout in a clean chroot. [ 505s]

[Xen-devel] [PATCH] docs: clearify symlink usage in xen-pv-channel

The previous version simply states that a symlink has to be created without telling where the symlink should point to. Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/man/xen-pv-channel.pod.7 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/m

Re: [Xen-devel] qemu-xen fails to build in staging

Am Wed, 07 Feb 2018 02:56:55 -0700 schrieb "Jan Beulich" : > I think I had seen this too, and only then I realized that now I need > to set up the respective submodule in the qemu tree. Yes, it looks like qemu has now submodules which are required for build. Neither configure

[Xen-devel] [PATCH] stubdom: install firmware files as data

Remove the executable bits of vtpm files by using _DATA instead of _PROG. Signed-off-by: Olaf Hering <o...@aepfle.de> --- stubdom/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/stubdom/Makefile b/stubdom/Makefile index f45eeabd8b..7cb62e6c36 100644 --- a/s

Re: [Xen-devel] qemu-xen fails to build in staging

Am Wed, 7 Feb 2018 11:13:22 +0100 schrieb Olaf Hering <o...@aepfle.de>: > Yes, it looks like qemu has now submodules which are required for build. How is the required state of the submodules tracked? When I did a local build I got 10739aa from qemu.org, and building xen.git#staging

[Xen-devel] [PATCH] sysctl: correct comment in xen_sysctl_pcitopoinfo

Refer to correct member of struct xen_sysctl_pcitopoinfo in comment. Fixes: commit 61319fbfd9 ("sysctl: add sysctl interface for querying PCI topology") Signed-off-by: Olaf Hering <o...@aepfle.de> --- xen/include/public/sysctl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletio

[Xen-devel] [PATCH] domctl: revert double increment of domctl version

Xen 4.10 has XEN_DOMCTL_INTERFACE_VERSION 0xe, staging should be fine with 0xf until the next release is prepared. Signed-off-by: Olaf Hering <o...@aepfle.de> --- xen/include/public/domctl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/public/domctl.h

Re: [Xen-devel] [PATCH] domctl: revert double increment of domctl version

Am Wed, 21 Feb 2018 17:38:03 + schrieb Wei Liu : > The reason we bumped the number twice is because we want a dedicated > number to denote the recent security fix. Thanks, that was no clear from the commit messages. Olaf pgptLjyZ2XhXq.pgp Description: Digitale

Re: [Xen-devel] [PATCH] domctl: revert double increment of domctl version

Am Wed, 21 Feb 2018 17:53:54 + schrieb Andrew Cooper : > I continue to think that this is a mistake (which is backed up by > everyone else being confused about what is going on), and demonstrates > the ineffectiveness of the *_INTERFACE_VERSIONS in general. Well,

[Xen-devel] device_model_version is set unconditionally to qemu_xen

libxl__domain_build_info_setdefault sets libxl_domain_build_info->device_model_version unconditionally to LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN. This breaks domUs that do not have a qemu attached to it, like PV without vfb= and without qdisk. While that bug does not trigger today, it will once

Re: [Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

Am Thu, 17 May 2018 17:51:08 +0200 schrieb Olaf Hering : > @@ -377,7 +377,9 @@ static void > domain_suspend_common_guest_suspended(libxl__egc *egc, > +libxl__device_model_version_running(gc, dsps->domid) == > +LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) { Please with

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

Am Tue, 26 Jun 2018 19:11:13 +0200 schrieb Olaf Hering : > Am Thu, 7 Jun 2018 15:08:29 +0200 > schrieb Olaf Hering : > > Add an option to control when vTSC emulation will be activated for a > > domU with tsc_mode=default. Without such option each TSC access from > > domU

[Xen-devel] qemu-3.0 fails with staging

This domU.cfg fails for me with staging+qemu-3.0, but qemu-2.12 happens to work: name='fv' serial='pty' vcpus='4' memory='' disk=[ 'vdev=xvda, format=raw, access=rw, target=/nfs_vmimages/disk0.raw' ] vif=[ 'bridge=br0,mac=3e:27:63:30:c0:46,type=vif' ] builder="hvm"

Re: [Xen-devel] qemu-3.0 fails with staging

Am Thu, 9 Aug 2018 10:22:51 + schrieb Paul Durrant : > Oh sorry, I see the xen version is just staging. Still need the dom0 kernel > version though. Kernel 4.4, SLE12SP3. Olaf pgpe1ke1wdMmx.pgp Description: Digitale Signatur von OpenPGP ___

[Xen-devel] incompatible changes in staging break qemu

Since about two weeks, no released qemu can be built against xen.git#staging. The error looks like that: qemu-20180825T130857.235c82acca/include/hw/xen/xen_common.h:677:5: error: too many arguments to function 'xc_domain_create' It looks like staging lacks proper compat wrappers for released

Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes

On Wed, Aug 29, Andrew Cooper wrote: > Architecturally speaking, handing #MC back is probably the closest we > can get to sensible behaviour, but it is still a bug that Linux is > touching the ballooned out page in the first place. Well, the issue is that a read crosses a page boundary. If that

[Xen-devel] build regression in staging

Some change between 36e29dd9e5..b28cd21c3 breaks build of tools/firmware (The pv shim?): [ 391s] Error: size of alternative.o:.data.read_mostly is 0x01 [ 391s] make[11]: ***

Re: [Xen-devel] incompatible changes in staging break qemu

On Mon, Aug 27, Olaf Hering wrote: > Since about two weeks, no released qemu can be built against xen.git#staging. > The error looks like that: > qemu-20180825T130857.235c82acca/include/hw/xen/xen_common.h:677:5: error: too > many arguments to function 'xc_domain_create' > It loo

Re: [Xen-devel] build regression in staging

On Wed, Aug 29, Andrew Cooper wrote: > Is the offending object file available to inspect? I will try to build it locally later today. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes

On Mon, Aug 13, Jan Beulich wrote: > And hence the consideration of mapping in an all zeros page > instead. This is because of the way __hvmemul_read() / > __hvm_copy() work: The latter doesn't tell its caller how many > bytes it was able to read, and hence the former considers the > entire range

Re: [Xen-devel] build regression in staging

On Wed, Aug 29, Olaf Hering wrote: > On Wed, Aug 29, Andrew Cooper wrote: > > Is the offending object file available to inspect? > I will try to build it locally later today. It is attached. Olaf alternative.o.gz Description: GNU Zip compressed data signature.asc Description: P

Re: [Xen-devel] CPU flags disappear on Spectre enabled host

Am Fri, 20 Jul 2018 10:38:30 +0100 schrieb Andrew Cooper : > On 20/07/18 10:21, Olaf Hering wrote: > > Is the loss of cpuflags intentional? > Yes, but they've got nothing to do with Spectre. Thank you, Andrew. After a few more reboots I figured that booting without any cmdline

[Xen-devel] CPU flags disappear on Spectre enabled host

On a host that is booted with the following command line, certain cpu flags disappear in xen-4.9 and later: (XEN) Command line: loglvl=all guest_loglvl=all console=com1 com1=57600 cpuid=ibrsb,stibp,ibpb,ssbd spec-ctrl=ibrs,ibpb,ssbd,bti-thunk=retpoline xpti=yes On my test system the

Re: [Xen-devel] [PATCH v1] tools/firmware: reproducible seabios build

Am Wed, 18 Jul 2018 10:39:31 +0100 schrieb Wei Liu : > > + rm -f seabios-dir/.version > There is no need to rm -f here because the following > will clear its > content anyway. The content of seabios-dir is coming from upstream, ".version" might be a symlink. Thats why I added this rm

Re: [Xen-devel] [PATCH] automation: add SLES 11 SP4 dockerfile

On Tue, Jul 17, Wei Liu wrote: > No OVMF because it requires gcc 4.4 or later. Fine. > No seabios because it requires anonymous union initialisation It is required to build Xen like that (with a custom compiler from gcc48.rpm): test -x "$(type -p gcc)" && CC=$_ test -x "$(type -p gcc-4.8)" &&

[Xen-devel] [PATCH v2] tools/firmware: reproducible seabios build

not take EXTRAVERSION from environment. Adjust the code to create a '.version' file with fixed content. Adjust the code to pass EXTRAVERSION down to make. Signed-off-by: Olaf Hering --- tools/firmware/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/firmware

Re: [Xen-devel] [PATCH v1] xen: creating debug info is optional

Am Thu, 30 Aug 2018 09:23:47 -0600 schrieb "Jan Beulich" : > Reusing? It's been gone since 4.9, and ./INSTALL talks about it as > a tool stack only thing. It does not, it is in the general "make" section. I do not see any valid reason to diverge further. Olaf pgp7_TmCXnfBQ.pgp Description:

[Xen-devel] [PATCH v1] xen: creating debug info is optional

Creating debug info during build is not strictly required at runtime. Make it optional by reusing the existing 'debug_symbols=n' knob. This slightly reduces build time and diskusage, if specified. Signed-off-by: Olaf Hering --- xen/Rules.mk | 5 - 1 file changed, 4 insertions(+), 1 deletion

Re: [Xen-devel] [PATCH v1] xen: avoid crash in disable_hotplug_cpu

Am Wed, 5 Sep 2018 12:55:58 +0200 schrieb Juergen Gross : > Instead of trying to fight the symptoms, I think avoiding to offline > the last cpu would make more sense. Well, apparently the fix is to leave cpu#0 online because of a backtrace like that: WARNING: CPU: 0 PID: 83 at

Re: [Xen-devel] [PATCH v1] xen: avoid crash in disable_hotplug_cpu

Am Wed, 5 Sep 2018 17:14:48 +0200 schrieb Juergen Gross : > I'm not sure this WARN triggers because it is cpu#0. Are you sure > the tested cpu in that WARN was 0? After all the test is just running > on cpu#0 and I don't think it can be offline already. If I leave cpu#0 alone, no WARN is

Re: [Xen-devel] [PATCH v2 2/2] x86/HVM: split page straddling emulated accesses in more cases

st > RAM read fails with HVMTRANS_bad_gfn_to_mfn and if the access straddles > a page boundary, issue accesses separately for both parts. > Signed-off-by: Jan Beulich Tested-by: Olaf Hering Olaf pgpZWJ3qWQhsR.pgp Description: Digitale Signatur von OpenPGP _

Re: [Xen-devel] [PATCH v2 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()

Am Mon, 03 Sep 2018 09:43:45 -0600 schrieb "Jan Beulich" : > It can easily be expressed through hvm_copy_from_guest_linear(), and in > two cases this even simplifies callers. > > Suggested-by: Paul Durrant > Signed-off-by: Jan Beulich > Reviewed-by: Andrew Coo

[Xen-devel] [PATCH v2] xen: avoid crash in disable_hotplug_cpu

, in the second iteration cpu_present is false which causes get_cpu_device to return NULL. In case of cpu#0, cpu_online is apparently always true. Fix this crash by checking if the cpu can be hotplugged, which is false for a cpu that was just removed. Signed-off-by: Olaf Hering --- drivers/xen

[Xen-devel] [PATCH v3] xen: avoid crash in disable_hotplug_cpu

by device_remove, otherwise leave the cpu_present state as it is. Signed-off-by: Olaf Hering --- drivers/xen/cpu_hotplug.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c index d4265c8ebb22..68f9f663da08 100644 --- a/drivers/xen

Re: [Xen-devel] [PATCH v3] xen: avoid crash in disable_hotplug_cpu

Am Fri, 7 Sep 2018 09:33:20 -0400 schrieb Boris Ostrovsky : > what is the purpose of 'xl vcpu-set 0'? Likely just a script that went wrong. But that command should not break the dom0. Olaf pgpf7yM3gq1fu.pgp Description: Digitale Signatur von OpenPGP

Re: [Xen-devel] [PATCH v2] xen: avoid crash in disable_hotplug_cpu

Am Thu, 6 Sep 2018 14:45:57 -0400 schrieb Boris Ostrovsky : > On 09/06/2018 02:37 AM, Olaf Hering wrote: > > The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0: > > This happens because handle_vcpu_hotplug_event is called twice. In the > > first iteration cpu_

Re: [Xen-devel] [PATCH v3] xen: avoid crash in disable_hotplug_cpu

Am Fri, 7 Sep 2018 09:48:28 +0200 schrieb Juergen Gross : > On 07/09/18 08:30, Olaf Hering wrote: > > + if (cpu_online(cpu)) > > + return; > > if (cpu_present(cpu)) > > xen_arch_unregister_cpu(cpu); > Could you merge the two if con

Re: [Xen-devel] [PATCH v2] xen: avoid crash in disable_hotplug_cpu

Am Thu, 6 Sep 2018 22:31:45 +0200 schrieb Olaf Hering : > IF cpu0_hotpluggable is broken, then only "if (!cpu) return;" can help. Another option is to do cpu_online() twice to check if device_offline did anything. Not sure if the compiler would fold the two checks into a single

[Xen-devel] v4.19-rc3, bug in __gnttab_unmap_refs_async with HVM domU

While preparing another variant of the fix for the bug in disable_hotplug_cpu, this crash happend for me while starting my HVM domU a second time. dom0 runs Xen 4.7.6. I guess it crashed while it did shutdown the domU running a xenlinux based kernel. Olaf [ 8114.320383] BUG: unable to handle

[Xen-devel] v4.19-rc3, wrong pageflags in dom0

After reboot I tried to start my HVM domU, this is what I get in dom0: Welcome to SUSE Linux Enterprise Server 12 SP2 (x86_64) - Kernel 4.19.321-default-bug1106594 (hvc0). stein-schneider login: (XEN) HVM1 save: CPU (XEN) HVM1 save: PIC (XEN) HVM1 save: IOAPIC (XEN) HVM1 save: LAPIC (XEN)

Re: [Xen-devel] [PATCH v4] xen: avoid crash in disable_hotplug_cpu

Am Fri, 7 Sep 2018 12:56:37 -0400 schrieb Boris Ostrovsky : > I was hoping you'd respond to my question about warning. > > root@haswell> xl vcpu-set 3 0 > and in the guest > > [root@vm-0238 ~]# [   32.866955] [ cut here ] > [   32.866963] spinlock on CPU0 exists on

Re: [Xen-devel] v4.19-rc3, wrong pageflags in dom0

Am Mon, 10 Sep 2018 14:49:07 +0200 schrieb Olaf Hering : > After reboot I tried to start my HVM domU, this is what I get in dom0: > [ 223.019451] page:ea007bed9040 count:1 mapcount:-1 > mapping: index:0x0 this also happens with rc2 and xen.git#staging as dom0. v4

[Xen-devel] [PATCH v2] xen: add DEBUG_INFO Kconfig symbol

Creating debug info during build is not strictly required at runtime. Make it optional by introducing a new Kconfig knob "DEBUG_INFO". This slightly reduces build time and diskusage, if disabled. Signed-off-by: Olaf Hering --- xen/Kconfig.debug | 7 +++ xen/Rules.mk | 5

Re: [Xen-devel] [PATCH v2] xen: add DEBUG_INFO Kconfig symbol

On Fri, Aug 31, Wei Liu wrote: > But what is the difference between this and DEBUG anyway? DEBUG_INFO is for gcc (-g), DEBUG is for Kconfig. Adding a dependency to DEBUG may change behavior, not sure what the expected outcome of always using '-g' is. Olaf signature.asc Description: PGP

[Xen-devel] [PATCH v3] xen: add DEBUG_INFO Kconfig symbol

Creating debug info during build is not strictly required at runtime. Make it optional by introducing a new Kconfig knob "DEBUG_INFO". This slightly reduces build time and diskusage, if disabled. Signed-off-by: Olaf Hering --- xen/Kconfig.debug | 7 +++ xen/Rules.mk | 3 ++

Re: [Xen-devel] [PATCH v2] xen: add DEBUG_INFO Kconfig symbol

On Fri, Aug 31, Jan Beulich wrote: > Perhaps better move your addition into this conditional section? Then -g would disappear when DEBUG is disabled. Is that intentional? Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list

[Xen-devel] [PATCH v1] tools/mkrpm: switch payload to gzip to reduce turnaround time

. 37MB. Signed-off-by: Olaf Hering --- tools/misc/mkrpm | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm index f9363a1456..ae40e1a4c4 100644 --- a/tools/misc/mkrpm +++ b/tools/misc/mkrpm @@ -37,6 +37,7 @@ Group: System/Hypervisor URL: http

Re: [Xen-devel] [PATCH v1] xen: avoid crash in disable_hotplug_cpu

Am Wed, 5 Sep 2018 12:55:58 +0200 schrieb Juergen Gross : > the last cpu Which one is the "last" one? I mean, if cpu#0 never can be offlined than perhaps the code should check for just that and return early. But if cpu#0 could be disabled while some other cpu is the remaining cpu, some other

[Xen-devel] [PATCH v1] xen: avoid crash in disable_hotplug_cpu

Trace: handle_vcpu_hotplug_event+0xb5/0xc0 xenwatch_thread+0x80/0x140 ? wait_woken+0x80/0x80 kthread+0x112/0x130 ? kthread_create_worker_on_cpu+0x40/0x40 ret_from_fork+0x3a/0x50 Fix this crash by checking the return value of get_cpu_device(). Signed-off-by: Olaf Hering --- drivers/xen

Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes

On Wed, Aug 29, Olaf Hering wrote: > On Mon, Aug 13, Jan Beulich wrote: > > > And hence the consideration of mapping in an all zeros page > > instead. This is because of the way __hvmemul_read() / > > __hvm_copy() work: The latter doesn't tell its caller how many >

Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes

On Thu, Aug 30, Jan Beulich wrote: > approach): One is Paul's idea of making null_handler actually retrieve > RAM contents when (part of) the access touches RAM. Another might This works for me: static int null_read(const struct hvm_io_handler *io_handler, uint64_t addr,

Re: [Xen-devel] [PATCH v4] xen: avoid crash in disable_hotplug_cpu

Am Fri, 7 Sep 2018 12:56:37 -0400 schrieb Boris Ostrovsky : > I was hoping you'd respond to my question about warning. It looks like CONFIG_BOOTPARAM_HOTPLUG_CPU0=y is the reason for the warning. As Jürgen suggested in another mail, Xen should probably disable hotplugging for cpu#0 in the

Re: [Xen-devel] [PATCH v4] xen: avoid crash in disable_hotplug_cpu

Am Tue, 11 Sep 2018 09:52:58 +0200 schrieb Olaf Hering : > As Jürgen suggested in another mail, Xen should probably disable hotplugging > for cpu#0 in the generic setup code. Then cpu_is_hotpluggable(cpu) would > do the right thing. The relevant code is all private to arch/x86/kernel/t

[Xen-devel] [PATCH v1] tools/firmware: reproducible seabios build

not take EXTRAVERSION from environment. Adjust the code to create a '.version' file with fixed content. Adjust the code to pass EXTRAVERSION down to make. Signed-off-by: Olaf Hering -- After commit 1233d253a4 ("firmware/seabios: fix build on systems with non GNU toolchains") this cha

[Xen-devel] vixen and vfb, missing vfb support in qemu

It seems the list of missing features of vixen does not cover the lack of framebuffer support. 'xl create -Vf PV.cfg' would show the guest console in the VNC window. With vixen this can not work because the vfb code triggers only for PV guests. Is that missing feature on anyones radar already? At

[Xen-devel] [PATCH v11 2/3] tools/libxc: add API for bitmap access for restore

Extend API for managing bitmaps. Each bitmap is now represented by a generic struct xc_sr_bitmap. Switch the existing populated_pfns to this API. Signed-off-by: Olaf Hering <o...@aepfle.de> Acked-by: Wei Liu <wei.l...@citrix.com> --- tools/libxc/xc_sr_co

[Xen-devel] [PATCH v11 0/3] tools/libxc: use superpages

avoid Over-allocation check trim bitmap function names, drop trailing "_bit" add some comments v2: split into individual commits based on staging c39cf093fc ("x86/asm: add .file directives") Olaf Hering (3): tools/libxc: move SUPERPAGE macros to common header tools/li

[Xen-devel] [PATCH v11 1/3] tools/libxc: move SUPERPAGE macros to common header

The macros SUPERPAGE_2MB_SHIFT and SUPERPAGE_1GB_SHIFT will be used by other code in libxc. Move the macros to a header file. Signed-off-by: Olaf Hering <o...@aepfle.de> Acked-by: Wei Liu <wei.l...@citrix.com> --- tools/libxc/xc_dom_x86.c | 5 - tools/libxc/xc_private.h | 5 ++

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 : > > Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to adjust the > > tolerance value of a running domU that is supposed to be migrated. > Please can we not proliferate the domctls. > This looks like it

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

20180228T150620.cb671efbf1/non-dbg/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin'. Fixes commit b38c4e1763 ("build: remove shim related targets") Signed-off-by: Olaf Hering <o...@aepfle.de> --- In case this

[Xen-devel] [PATCH] tools: drop stale references to xml2-config

Fixes commit 185bb58be3 ("tools: drop libxen") Signed-off-by: Olaf Hering <o...@aepfle.de> --- config/Tools.mk.in | 1 - tools/configure.ac | 1 - 2 files changed, 2 deletions(-) diff --git a/config/Tools.mk.in b/config/Tools.mk.in index 0f79f4e0c2..7831159257 100644 --- a/co

Re: [Xen-devel] [PATCH] tools: drop stale references to xml2-config

Am Thu, 1 Mar 2018 15:22:21 +0100 schrieb Olaf Hering <o...@aepfle.de>: > Fixes commit 185bb58be3 ("tools: drop libxen") > CURL_CONFIG := @CURL@ > AC_ARG_VAR([CURL], [Path to curl-config tool]) These are stale as well. Somehow I overlooked

[Xen-devel] [PATCH v2] tools: drop stale references to curl/xml2-config

Fixes commit 185bb58be3 ("tools: drop libxen") Signed-off-by: Olaf Hering <o...@aepfle.de> --- config/Tools.mk.in | 2 -- tools/configure.ac | 2 -- 2 files changed, 4 deletions(-) diff --git a/config/Tools.mk.in b/config/Tools.mk.in index 0f79f4e0c2..2d6c440324 100644 --- a/co

Re: [Xen-devel] [PATCH v2] tools: drop stale references to curl/xml2-config

Am Thu, 1 Mar 2018 15:32:05 + schrieb Wei Liu : > If you don't object I can replace the commit message. Yes, please. Olaf pgp_rL2Id687A.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list

  1   2   3   4   5   6   7   8   9   10   >