Re: [Xen-devel] [PATCH] mini-os: link to libgcc.a to fix build with gcc7

On Fri, Jun 30, Olaf Hering wrote: > On Fri, Jun 30, Wei Liu wrote: > > > On second thought I don't think we want to make this worse. So the > > change in this patch should be conditional on gcc. > > How whould I check for gcc in the Makefile? > In xen.git I see a co

Re: [Xen-devel] [PATCH] mini-os: link to libgcc.a to fix build with gcc7

On Fri, Jun 30, Wei Liu wrote: > On second thought I don't think we want to make this worse. So the > change in this patch should be conditional on gcc. How whould I check for gcc in the Makefile? In xen.git I see a conditional for clang. I dont have a clang at hand, perhaps it knows about

[Xen-devel] [PATCH] mini-os: link to libgcc.a to fix build with gcc7

: stubdom/mini-os-x86_32-grub/mini-os] Error 1 ... which the linker only finds if libgcc.a is provided on the commandline. Signed-off-by: Olaf Hering <o...@aepfle.de> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ef8559b..b9c1336

[Xen-devel] [PATCH v2] rombios: prevent building with PIC/PIE

] Error 11 Prevent the failure by enforcing non-PIC/PIE mode. Signed-off-by: Olaf Hering <o...@aepfle.de> --- build tested with staging-4.9/staging. PIE is the default now in openSUSE Tumbleweed: https://lists.opensuse.org/opensuse-factory/2017-06/msg00403.html tools/firmware/rombios/32bit/Ma

Re: [Xen-devel] live migration of HVM domUs with more than 32vcpus fails

On Fri, Jun 23, Ankur Arora wrote: > There was an earlier version of this patch by Konrad -- which takes > care of the migration failure: https://patchwork.kernel.org/patch/6768031/ Thanks so much. That one actually works. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH] rombios: prevent building with PIC

Am Mon, 26 Jun 2017 00:30:50 -0600 schrieb "Jan Beulich" : > In the description you also talk about PIE, but you deal with PIC only here. > Is that intentional? If so, please say why in the description. Thats what the URL says. Unclear what the connection between -fpic and

Re: [Xen-devel] [PATCH] rombios: prevent building with PIC

On Fri, Jun 23, Wei Liu wrote: > We support >=4.1. Please check those as well. Yes, 4.1.2 works as well. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] rombios: prevent building with PIC

On Fri, Jun 23, Wei Liu wrote: > We support >=4.1. Please check those as well. According to the PDF manuals at https://gcc.gnu.org/onlinedocs/ a "-fno-foo" is mentioned, so I think -fno-pic is recognized. I will see if I find a copy of SLE10 to verify with 4.1.2. Olaf signature.asc

Re: [Xen-devel] [PATCH] rombios: prevent building with PIC

On Fri, Jun 23, Wei Liu wrote: > Do you need to check if the compiler supports -fno-pic? In my testing gcc-4.3 and 4.5 know about this option. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org

[Xen-devel] [PATCH] vtpmmgr: make inline functions static

. Signed-off-by: Olaf Hering <o...@aepfle.de> --- stubdom/vtpmmgr/marshal.h | 76 ++ stubdom/vtpmmgr/tcg.h | 14 stubdom/vtpmmgr/tpm2_marshal.h | 58 stubdom/vtpmmgr/tpmrsa.h | 1 + 4

[Xen-devel] [PATCH] rombios: prevent building with PIC

] Error 11 Prevent the failure by enforcing non-PIC mode. Signed-off-by: Olaf Hering <o...@aepfle.de> --- build tested with staging-4.9. PIE is the default now in openSUSE Tumbleweed: https://lists.opensuse.org/opensuse-factory/2017-06/msg00403.html tools/firmware/rombios/32bit/Makefile

Re: [Xen-devel] live migration of HVM domUs with more than 32vcpus fails

On Thu, Jun 22, Boris Ostrovsky wrote: > They are queued for 4.13. > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.13 This works for me. Thanks. I assume there is no ready-to-pull variant for linux-4.4.x? nm. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] live migration of HVM domUs with more than 32vcpus fails

On Thu, Jun 22, Konrad Rzeszutek Wilk wrote: > On Thu, Jun 22, 2017 at 03:57:52PM +0200, Olaf Hering wrote: > > It seems that live migration of HVM domUs with more than 32 vcpus causes > > a hang of the domU on the remote side. Both ping and 'xl console' show no > > react

[Xen-devel] live migration of HVM domUs with more than 32vcpus fails

It seems that live migration of HVM domUs with more than 32 vcpus causes a hang of the domU on the remote side. Both ping and 'xl console' show no reaction. This happens also with kernel-4.12. Is this a known bug? Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH] tools/xen-detect: try sysfs node for obtaining guest type

On Wed, Jun 21, Wei Liu wrote: > Hmm... your gcc seems to be rather strict. :-) Yes, all of them: https://build.opensuse.org/package/show/home:olh:xen-unstable/xen All red. :-) Olaf signature.asc Description: PGP signature ___ Xen-devel mailing

Re: [Xen-devel] [PATCH] tools/xen-detect: try sysfs node for obtaining guest type

On Thu, Jun 15, Juergen Gross wrote: > +++ b/tools/misc/xen-detect.c > +asprintf(, "V%u.%u", > + (uint16_t)(regs[0] >> 16), (uint16_t)regs[0]); > +asprintf(, "V%s.%s", str, tmp); This fails to build: xen-detect.c:196:17: error: ignoring return value of

Re: [Xen-devel] staging aarch64 build fails in xc_dom_arm.c

On Tue, May 30, Andrew Cooper wrote: > Does > +domctl.u.address_size.size = 0; > help? Likely yes. I just scanned the buildlogs and found this failure. I do not have a ARM toolchain around to double check. Not sure why the marco, or its usage, is not like 'struct xen_domctl domctl = {}'

[Xen-devel] staging aarch64 build fails in xc_dom_arm.c

With gcc7 the aarch64 build in staging fails: xc_dom_arm.c: In function 'meminit': xc_dom_arm.c:229:31: error: 'domctl.u.address_size.size' may be used uninitialized in this function [-Werror=maybe-uninitialized] if ( domctl.u.address_size.size == 0 )

Re: [Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

On Tue, May 30, Wei Liu wrote: > subdirs-seabios-dir: EXTRAVERSION=XXX > Limit it to the one that needs the environment variable -- seabios or > ipxe. Ok, I will try it. Last time I looked environment did not work. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

On Tue, May 30, Wei Liu wrote: > In that case, can you confine such hackery to be seabios only? Is it worth the hassle? It seems only ipxe would recognize the EXTRAVERSION. And how would I actually limit it to seabios? Something like "make $(filter-out subdir-seabios-dir, subdirs-$@)"? Olaf

Re: [Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

On Tue, May 30, Wei Liu wrote: > What I meant was: this is passing EXTRAVERSION to all subdir targets, > which seems unnecessary to me. And you already specified a version > string for seabios. True, but scripts/buildversion.py insists on --extra 'whatever'. Olaf signature.asc Description:

Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

On Wed, May 24, Konrad Rzeszutek Wilk wrote: > Is there some form of tests that they can run to verify and test > that this is safe? Or perhaps this is something that is based on the kernel > versions? Like 4.11 are safe, but 3.18 is not? I'm not sure why you are asking for specific kernel

Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

On Mon, May 29, Jan Beulich wrote: > Finally I don't think a host wide option will do. If it is to be of use > (considering that it used wrong may break applications), it needs > to be per-domain, and its value needs to be migrated (perhaps > in the form of a low/high pair of TSC frequency

Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

On Mon, May 29, Jan Beulich wrote: > Well, no, what jitter may be acceptable depends on the > applications running inside the guest. I.e. you can only know > for yourself or ask the application vendor(s). I think such an > option, if we really want to have it, would need to be > prominently

Re: [Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

On Fri, May 26, Ian Jackson wrote: > This seems like a real problem which should be improved. But maybe we > should use Xen's EXTRAVERSION by default ? After thinking about it, why does the tools build not just enforce a fixed string? There is no point for scripts/buildversion.py to put current

[Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

EXTRAVERSION=something' prior to 'make tools' is not sufficient. It has to be passed in as cmdline option to make. Add a make variable SEABIOS_EXTRAVERSION= and pass it to make. Allow changing the default via the environment. Document the new variable in INSTALL. Signed-off-by: Olaf Hering &l

Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

Am Wed, 24 May 2017 11:33:15 -0400 schrieb Konrad Rzeszutek Wilk : > But it does not help customers to figure out if this is OK for them? > As in, how can customers be assured that 1% jitter is OK for their > kernel? That time won't go backwards? Well, that would be some

Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

On Wed, May 24, Konrad Rzeszutek Wilk wrote: > How can that be determined? As in how can the guest (domU) be within > the range? Is there some way to determine that? Is there some > matrix of the various OS-es that can tolerate this? Just cycle through all dom0s and look for the cpu_khz values:

[Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

. To avoid the emulation a tolerance range can be specified during boot with "vtsc-tolerance=N". If the frequency expected by the domU is within the range, TSC access from the domU will remain native. If the domU is migrated to another machine type TSC might be emulated. Signed-of

[Xen-devel] [PATCH] docs: correct paragraph indention in xen-tscmode

Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/man/xen-tscmode.pod.7 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/man/xen-tscmode.pod.7 b/docs/man/xen-tscmode.pod.7 index 0f9345358d..4e1858556c 100644 --- a/docs/man/xen-tscmode.pod.7 +++ b/docs/m

[Xen-devel] [PATCH] docs: replace xm with xl in xen-tscmode

Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/man/xen-tscmode.pod.7 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/man/xen-tscmode.pod.7 b/docs/man/xen-tscmode.pod.7 index 4e1858556c..3bbc96f201 100644 --- a/docs/man/xen-tscmode.pod.7 +++ b/docs/m

Re: [Xen-devel] superpages lost after migration of HVM domU

On Wed, Apr 26, Andrew Cooper wrote: > On 26/04/17 16:43, Olaf Hering wrote: > > On Thu, Apr 20, Jan Beulich wrote: > > > >>>>> On 20.04.17 at 18:04, <o...@aepfle.de> wrote: > >>> On Thu, Apr 20, Andrew Cooper wrote: > >>>

[Xen-devel] compile error in x86_emulate/x86_emulate.c

A compile error was introduced between 4.9.20170413T172409.e412c03be2 and 4.9.20170426T155707.0a5370ee1f when gcc-4.3/4.5 is used: [ 114s] gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -g3 -O0 -fno-omit-frame-pointer

Re: [Xen-devel] superpages lost after migration of HVM domU

On Thu, Apr 20, Jan Beulich wrote: > >>> On 20.04.17 at 18:04, wrote: > > On Thu, Apr 20, Andrew Cooper wrote: > > > >> As it currently stands, the sending side iterates from 0 to p2m_size, > >> and sends every frame on the first pass. This means we get PAGE_DATA > >> records

Re: [Xen-devel] superpages lost after migration of HVM domU

On Thu, Apr 20, Andrew Cooper wrote: > As it currently stands, the sending side iterates from 0 to p2m_size, > and sends every frame on the first pass. This means we get PAGE_DATA > records linearly, in batches of 1024, or two aligned 2M superpages. Is there a way to preserve 1G pages? This

[Xen-devel] superpages lost after migration of HVM domU

Andrew, with eab806a097b ("tools/libxc: x86 PV restore code") the only call of xc_domain_populate_physmap_exact was added to the new restore code. This call always sets order=0. The old migration code did consider superpages, the new one does not. What is the reason for not using superpages when

Re: [Xen-devel] [PATCH RFC] handle tsc_tolerance during migration between identical hosts

On Tue, Apr 18, Jan Beulich wrote: > >>> On 18.04.17 at 11:50, wrote: > > On Tue, Apr 11, Jan Beulich wrote: > > > >> I'm afraid successful testing is not a sufficient criteria here. At > >> the very least the (so far missing) documentation needs to very > >> clearly point out

Re: [Xen-devel] [PATCH RFC] handle tsc_tolerance during migration between identical hosts

On Tue, Apr 11, Jan Beulich wrote: > I'm afraid successful testing is not a sufficient criteria here. At > the very least the (so far missing) documentation needs to very > clearly point out the possible risks associated with using this > option. But with there not being any functional change

[Xen-devel] [PATCH RFC] handle tsc_tolerance during migration between identical hosts

Testing has shown that domUs with 'tsc_mode=default' can be migrated safely between identical hardware, even if the measured clock frequency differs by a few kHz. A change like shown below would allow to migrate between "2.nnGHz" hosts without enforcing emulation. If the domU is migrated to a host

Re: [Xen-devel] inaccurate dirty_count from XEN_DOMCTL_SHADOW_OP

Am Thu, 30 Mar 2017 12:40:34 +0100 schrieb Andrew Cooper <andrew.coop...@citrix.com>: > On 22/03/17 10:59, Olaf Hering wrote: > > On Wed, Mar 22, Olaf Hering wrote: > > > >> Did the xc_shadow_control API change at some point? > > ... staging-4.5 works, wh

Re: [Xen-devel] [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal

Am Fri, 17 Mar 2017 14:15:26 -0400 schrieb Boris Ostrovsky : > Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and > host frequencies are the same") left out optimization for PV guests > when host and guest run at the same frequency. > > For such a

Re: [Xen-devel] inaccurate dirty_count from XEN_DOMCTL_SHADOW_OP

On Wed, Mar 22, Olaf Hering wrote: > Did the xc_shadow_control API change at some point? ... staging-4.5 works, while staging-4.6 does not. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org ht

Re: [Xen-devel] inaccurate dirty_count from XEN_DOMCTL_SHADOW_OP

On Tue, Mar 21, Olaf Hering wrote: > I wonder if the usage of xc_shadow_control is correct. The testing was > done with a xen-4.4 based dom0, I will verify with staging once I find > the time. It does work with xen-4.4, but fails with staging. Did the xc_shadow_control API change at s

[Xen-devel] inaccurate dirty_count from XEN_DOMCTL_SHADOW_OP

To measure how many dirty pages a domU creates within a timeframe the attached tool was created, based on code from xc_domain_save. Once the domU touches many pages the reported dirty rate is high, but after a few seconds the rate drops down from thousands to just a few dozen. I wonder if the

Re: [Xen-devel] PV performance degraded after live migration

On Wed, Mar 15, Jan Beulich wrote: > ..., and iirc PV migration didn't have any issue with TSC freq > changing during migration prior to the introduction of vTSC. When was this introduced? There is a claim that this slowdown is a regression. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] PV performance degraded after live migration

On Wed, Mar 15, Olaf Hering wrote: > On Wed, Mar 15, Andrew Cooper wrote: > > As a crazy idea, doest this help? > > tsc->incarnation = 0 This does indeed help. One system shows now the results below, which means the performance goes down during migration (to localhost) and g

Re: [Xen-devel] PV performance degraded after live migration

On Wed, Mar 15, Andrew Cooper wrote: > As a crazy idea, doest this help? > tsc->incarnation = 0 Had to move to another testhost and this seems to help. Will do more testing once the original testsystems are accessible again. Thanks! Olaf signature.asc Description: PGP signature

[Xen-devel] PV performance degraded after live migration

After reports about degraded performance after a PV domU was migrated from one dom0 to another it turned out that this issue happens with every version of Xen and every version of domU kernel. The used benchmark is 'sysbench memory'. I hacked it up to show how long the actual work takes, and that

[Xen-devel] [PATCH v2] tools: include sys/sysmacros.h on Linux

/sysmacros.h to define these three macros. blktap2 is already Linux specific. The kernel header which was used to get makedev() does not provided it anymore, and it was wrong to use a kernel header anyway. Signed-off-by: Olaf Hering <o...@aepfle.de> --- v2: keep include linux/major.h for MISC_MAJOR

Re: [Xen-devel] [PATCH] tools: Include due to glibc 2.25

On Tue, Mar 14, Anthony PERARD wrote: > +++ b/tools/libxl/libxl_internal.h > +#include There is a __linux__ section in that file. I sent a similar patch yesterday, but with a wrong change for blktap2. Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH] tools: include sys/sysmacros.h on Linux

Am Tue, 14 Mar 2017 11:54:46 + schrieb Wei Liu : > tap-ctl-allocate.c:143:9: error: ‘MISC_MAJOR’ undeclared (first use in That happened because the variant of the change I sent was untested... I will revisit this part. sys/types.h is needed according to mknod(2). Olaf

[Xen-devel] [PATCH] tools: include sys/sysmacros.h on Linux

/sysmacros.h to define these three macros. blktap2 is already Linux specific. The kernel header which was used to get makedev() does not provided it anymore, and it was wrong to use a kernel header anyway. Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/blktap2/control/tap-ctl-allocate

[Xen-devel] [PATCH] tools/xenstore: define off_t

talloc.h uses off_t, but did not include Fixes 7012548e0d ("xenstore: enhance control command support") Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/xenstore/talloc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/xenstore/talloc.h b/tools/xenstor

[Xen-devel] [PATCH] tools/libxendevicemodel: define O_CLOEXEC

Similar defines are already used elsewhere. Fixes e7745d8ef5 ("tools/libxendevicemodel: introduce a Linux-specific implementation") Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/libs/devicemodel/linux.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/

[Xen-devel] [PATCH] doc: fix typo in bios_path_override

Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/man/xl.cfg.pod.5.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in index 46f9caff3e..505c11137f 100644 --- a/docs/man/xl.cfg.pod.5.in +++ b/docs/man/xl.cfg

Re: [Xen-devel] [PATCH 0/2] libxl: add support for pvscsi, iteration 13

Am Mon, 20 Feb 2017 17:05:18 + schrieb Wei Liu : > CC Ian -- I think he followed more closely than I did. Thanks, but this is just a rebase to 4.8 in case anyone needs it. No code changes since last review round. I'm currently working on an update for the idl

[Xen-devel] [PATCH 2/2] Scripts to create and delete xen-scsiback nodes in Linux target framework

These scripts are not use by libxl. These scripts are meant for testing vscsi= in libxl Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/misc/Makefile | 4 + tools/misc/target-create-xen-scsiback.sh | 135 +++ tools/misc/target-dele

[Xen-devel] [PATCH 1/2] libxl: add support for vscsi

Port pvscsi support from xend to libxl: vscsi=['pdev,vdev{,options}'] xl scsi-attach xl scsi-detach xl scsi-list Signed-off-by: Olaf Hering <o...@aepfle.de> Cc: Ian Jackson <ian.jack...@eu.citrix.com> Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com> Cc: Wei Liu &l

[Xen-devel] [PATCH 0/2] libxl: add support for pvscsi, iteration 13

pt was sent a year ago: http://lists.xenproject.org/archives/html/xen-devel/2014-04/msg03958.html Most comments are addressed. This version has been tested with SLES as backend and frontend. This version has been tested with pvops as backend and SLES as frontend. Olaf Hering (2): libxl: add

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Thu, 16 Feb 2017 08:58:01 +0100 schrieb Juergen Gross : > You can't assume ./configure is running on the same system as Xen is > being built for. I think its easy to decide at build time if the target has and/or uses "/run". And

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Thu, 16 Feb 2017 08:58:01 +0100 schrieb Juergen Gross : > You can't assume ./configure is running on the same system as Xen is > being built for. I think its easy to decide at build time if the target has and/or uses "/run". And

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Wed, 15 Feb 2017 15:51:12 -0500 schrieb Konrad Rzeszutek Wilk : > mkdir /run/xen > mkdir /run/xenstored This must be done by the startup scripts because the "run" directories, where ever they are, are volatile. I think

Re: [Xen-devel] STAO spec in xen.git

Am Tue, 14 Feb 2017 20:27:15 + schrieb Wei Liu : > Better to just push to a branch for us to fetch. That would be git://github.com/olafhering/xen.git#libreoffice https://github.com/olafhering/xen/commits/libreoffice Thanks, Olaf pgpgIrWZLs_Dh.pgp Description:

Re: [Xen-devel] STAO spec in xen.git

On Tue, Feb 14, Stefano Stabellini wrote: > Interestingly, my "git am" is unable to apply those patches. Does it > work for you? I cannot see anything wrong with them, but they don't > work. If the problem is that they are too large, please send the files > as attachments. Its the '\ No newline

Re: [Xen-devel] STAO spec in xen.git

On Tue, Feb 14, Stefano Stabellini wrote: > Also, I tried to do the same conversion with my copy of Libreoffice and > the FODT files produced are significantly different from yours, which > means, even if we use FODT docs, we are probably going to be unable to > send changes as meaningful text

Re: [Xen-devel] [PATCH biosdevname]: handle dom0 on AMD systems

Hello, and ping. Olaf On Wed, Aug 17, Olaf Hering wrote: > Starting with xen-4.7 cpuid() will return with the hypervisor bit set > in a dom0 when running on an AMD system. As a result biosdevname > thinks it runs in a guest and does nothing. Detect a dom0 by looking > into xenfs

Re: [Xen-devel] STAO spec in xen.git

On Tue, Jan 17, Stefano Stabellini wrote: > On Tue, 17 Jan 2017, Olaf Hering wrote: > > On Fri, Jan 13, Julien Grall wrote: > > > > > Regarding the format. Does ODT will allow git to do proper diff? > > > > There is flat ODT, "Safe as ..." and pick

[Xen-devel] [PATCH 2/4] docs: convert XENV from odt to fodt

Fixes c33b5f013d ("Add XENV to docs/misc") Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/misc/xen-env-table-spec.fodt | 852 ++ 1 file changed, 852 insertions(+) diff --git a/docs/misc/xen-env-table-spec.fodt b/docs/misc/xen-env-tab

[Xen-devel] [PATCH 1/4] docs: convert STAO from odt to fodt

Fixes 140b31a8de ("Add STAO spec to docs/misc") Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/misc/status-override-table-spec.fodt | 707 ++ 1 file changed, 707 insertions(+) diff --git a/docs/misc/status-override-table-spec.fodt b/docs/misc

[Xen-devel] [PATCH 4/4] docs: remove odt variant of XENV

Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/docs/misc/xen-env-table-spec.odt b/docs/misc/xen-env-table-spec.odt deleted file mode 100

[Xen-devel] [PATCH 3/4] docs: remove odt variant of STAO

Signed-off-by: Olaf Hering <o...@aepfle.de> --- docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/docs/misc/status-override-table-spec.odt b/docs/misc/status-override-table-spec.odt deleted file mode 100

[Xen-devel] [PATCH 0/4] docs: convert from binary to ASCII

The odt files should have been saved as Flat XML via 'Save as ...'. git send-email warns about lines longer than 998 chars. Hopefully all involved mail services have no silly limits. Olaf Olaf Hering (4): docs: convert STAO from odt to fodt docs: convert XENV from odt to fodt docs: remove

Re: [Xen-devel] [PATCH qemu-xen-traditional 1/2] xen_platform: unplug also SCSI disks [and 1 more messages]

On Tue, Jan 31, Ian Jackson wrote: > Olaf Hering writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional 1/2] > xen_platform: unplug also SCSI disks [and 1 more messages]"): > > So what should be done with the two patches? > > Are they acceptable for staging, or will

Re: [Xen-devel] [PATCH qemu-xen-traditional 1/2] xen_platform: unplug also SCSI disks [and 1 more messages]

On Tue, Jan 10, George Dunlap wrote: > On Mon, Jan 9, 2017 at 4:39 PM, Olaf Hering <o...@aepfle.de> wrote: > > The protocol was introduced before upstream had one, xen-3.0 vs. > > xen-3.x. I have not digged into 10 year old emails why it was done that > > way, if it was

Re: [Xen-devel] [PATCH 1/6] libxl: add "merge" function to generic device type support

On Tue, Jul 12, Juergen Gross wrote: > Instead of using a macro generating the code to merge xenstore and > json configuration data, use the generic device type support for > this purpose. > This requires to add some accessor functions to the framework and > a structure for disks (as disks are

Re: [Xen-devel] STAO spec in xen.git

On Fri, Jan 13, Julien Grall wrote: > Regarding the format. Does ODT will allow git to do proper diff? There is flat ODT, "Safe as ..." and pick the better format from the pulldown menu. Olaf signature.asc Description: PGP signature ___ Xen-devel

Re: [Xen-devel] [PATCH qemu-xen-traditional 1/2] xen_platform: unplug also SCSI disks [and 1 more messages]

On Mon, Jan 09, Ian Jackson wrote: > Olaf Hering writes ("[PATCH qemu-xen-traditional 2/2] xen_platform: SUSE > xenlinux unplug for emulated PCI"): > > From: Olaf Hering <oher...@suse.de> > > > > Implement SUSE specific unplug protocol for emulate

Re: [Xen-devel] [PATCH qemu-xen-traditional 0/2] Xen HVM unplug changes

On Thu, Nov 24, Olaf Hering wrote: > Backport from qemu-2.8: > Update unplug in Xen HVM guests to cover more cases. > The patches are used since years in the SUSE xen-tools package. Are these patches in the review queue, or did they get dropped? Olaf signature.asc Description: PGP

Re: [Xen-devel] [PATCH 0/2] Open Xen 4.9-unstable, reenable debug

On Fri, Dec 02, Ian Jackson wrote: > I have pushed the first of these two patches to new-staging. It is > very like all previous such commits. The second, to reenable > hypervisor debug, I decided to get some review on. Please also bump the SONAMEs as it was done in commit

Re: [Xen-devel] [PATCH v3 1/2] xen_platform: unplug also SCSI disks

On Tue, Nov 29, Wei Liu wrote: > On Mon, Nov 28, 2016 at 10:28:21AM -0800, Stefano Stabellini wrote: > > Anthony, are you going to take care of this? > > However, given the state of the release, they'll need a release-ack to > > be applied. > I think these patches will need to wait to be

[Xen-devel] [PATCH qemu-xen-traditional 1/2] xen_platform: unplug also SCSI disks

From: Olaf Hering <oher...@suse.de> Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can be used by the emulated BIOS to boot from disk. If the HVM domU has also PV driver the disk may appear twice in the guest. To avoid this an unplug of the emulated hardware is needed, s

[Xen-devel] [PATCH qemu-xen-traditional 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

From: Olaf Hering <oher...@suse.de> Implement SUSE specific unplug protocol for emulated PCI devices in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'. This protocol was implemented and used since Xen 3.0.4. It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and openSUS

[Xen-devel] [PATCH qemu-xen-traditional 0/2] Xen HVM unplug changes

Backport from qemu-2.8: Update unplug in Xen HVM guests to cover more cases. The patches are used since years in the SUSE xen-tools package. Olaf Olaf Hering (2): xen_platform: unplug also SCSI disks xen_platform: SUSE xenlinux unplug for emulated PCI hw/pci.c | 41

Re: [Xen-devel] [PATCH v3 1/2] xen_platform: unplug also SCSI disks

On Fri, Oct 21, Olaf Hering wrote: > Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can > be used by the emulated BIOS to boot from disk. If the HVM domU has also > PV driver the disk may appear twice in the guest. To avoid this an > unplug of the emulated hardwa

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23. November 2016 21:44:50 MEZ, schrieb Olaf Hering <o...@aepfle.de>: >Is this a can for 2.x? candidate Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23. November 2016 13:27:13 MEZ, schrieb Kevin Wolf : >Am 23.11.2016 um 12:40 hat Eric Blake geschrieben: >> Qualifies as a bug fix, so requesting 2.8 inclusion. >> Reviewed-by: Eric Blake Is this a can for 2.x? Olaf

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Wed, Nov 23, Olaf Hering wrote: > > > +if (!blk_split_discard(ioreq, req->sector_number, > > > req->nr_sectors)) { > > > +goto err; > > How is error handling supposed to work here? In the guest the cmd is stuck, instead of getting

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

Ping. On Fri, Nov 18, Olaf Hering wrote: > On Fri, Nov 18, Olaf Hering wrote: > > > @@ -708,12 +743,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > > +if (!blk_split_discard(ioreq, req->sector_number, > > req->nr_sectors)) { > > +

[Xen-devel] [PATCH v3] xen_disk: split discard input to match internal representation

: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Fixes f313520 ("xen_disk: add discard support") Signed-off-by: Olaf Hering <o...@aepf

Re: [Xen-devel] [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

On Mon, Nov 21, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. Tested-by: Olaf Hering <o...@aepfle.de> This should go

[Xen-devel] [PATCH v2] xen_disk: split discard input to match internal representation

: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Fixes f313520 ("xen_disk: add discard support") Signed-off-by: Olaf Hering <o...@aepf

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Tue, Nov 22, Eric Blake wrote: > if (sec_start + sec_count < sec_count || > sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) { > return false; > } My point was: how does this handle sec_start=0,sec_count=UINT64_MAX or sec_start=INT64_MAX,sec_count=INT64_MAX? For me this gets

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Fri, Nov 18, Eric Blake wrote: > if (sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) I have looked at this for a while now and cant spot how this would cover all cases. Are you saying there should be just a single overflow check, yours? My change has two: one to check for wrap around

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Fri, Nov 18, Eric Blake wrote: > On 11/18/2016 04:24 AM, Olaf Hering wrote: > > +/* Overflowing byte limit? */ > > +if ((sec_start + sec_count) > ((INT64_MAX + INT_MAX) >> > > BDRV_SECTOR_BITS)) { > This is undefined. INT64_MAX + anything non-negati

Re: [Xen-devel] [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

Am 18. November 2016 14:43:18 MEZ, schrieb Eric Blake <ebl...@redhat.com>: >On 11/18/2016 04:24 AM, Olaf Hering wrote: >> The guest sends discard requests as u64 sector/count pairs, but the >> block layer operates internally with s64/s32 pairs. The conversion >> lead

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Fri, Nov 18, Olaf Hering wrote: > @@ -708,12 +743,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > +if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) { > +goto err; How is error handling supposed to work here? Initially I forgot

[Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Signed-off-by: Olaf Hering <o...@aepfle.de> --- hw/block/xen_disk.

Re: [Xen-devel] [PATCH v3 (re-send)] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Thu, Nov 17, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. Thanks, this works for me in 4.4: Tested-by: Olaf Hering <

Re: [Xen-devel] [PATCH v2] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Thu, Nov 17, Boris Ostrovsky wrote: > On 11/17/2016 06:28 AM, Olaf Hering wrote: > > ERROR: "__mpol_dup" [drivers/xen/xen-gntdev.ko] undefined! > > ERROR: "get_task_policy" [drivers/xen/xen-gntdev.ko] undefined! > I just built 4.4.11 with this patc

Re: [Xen-devel] [PATCH v2] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Wed, Nov 16, Boris Ostrovsky wrote: > Unfortunately I haven't been able to trigger NUMA balancing > so while I tested this in general I am not sure I actually > exercised the code path. Thanks for the patch! Would be nice to actually test the code path which caused the initial addition of

<    1   2   3   4   5   6   7   8   9   >