Re: [Xen-devel] [alsa-devel] [PATCH] ALSA: xen: ensure nul-terminated device name

On 05/28/2018 06:59 PM, Arnd Bergmann wrote: gcc-8 warns that pcm_instance->name is not necessarily terminated correctly if the input is more than 80 characters long or lacks a termination byte itself: In function 'strncpy', inlined from 'cfg_device' at sound/xen/xen_snd_front_cfg.c:399:3,

Re: [Xen-devel] XSM in osstest, grub config, outstanding patch

On 5/17/18 10:09 AM, Ian Jackson wrote: > Hi, I'm emailing you because I know you have an interest in XSM > (and therefore in its testing in osstest). > > osstest manages the booting of its test hosts using the > distro-supplied bootloader arrangements for its dom0s. For Debian > that is

Re: [Xen-devel] [PATCH RFC 1/3] automation: install texinfo in debian

On 5/23/18 5:20 AM, Wei Liu wrote: > Stubdom build requires that. > CentOS & Ubuntu will need the change too. Though in a way I'd almost ask why --enable-docs doesn't need it but stubdoms do? Seems like a weird dep for stubdom... -- Doug Goldstein

Re: [Xen-devel] [PATCH RFC 2/3] automation: build stubdom and rombios, and tools on 32 bit

On 5/23/18 5:20 AM, Wei Liu wrote: > > # SeaBIOS cannot be built with clang > @@ -20,12 +18,6 @@ if [[ "${CC}" == "clang" ]]; then > cfgargs+=("--with-system-seabios=/usr/share/seabios/bios.bin") > fi > > -if [[ "${XEN_TARGET_ARCH}" == "x86_64" ]]; then > -

[Xen-devel] [distros-debian-sid test] 74754: tolerable FAIL

flight 74754 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74754/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 74732

[Xen-devel] Building xen-hypervisor 4.10 and xen-tools on Ubuntu 16.04 for PVH

Hello, I am doing a study on Virtual Machine Introspection on Intel SGX based system using Xen based VMs. I followed the article - https://wiki.xenproject.org/wiki/Linux_PVH , in order to build

[Xen-devel] [xen-unstable-smoke test] 123328: regressions - FAIL

flight 123328 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

[Xen-devel] [ovmf baseline-only test] 74755: all pass

This run is configured for baseline tests only. flight 74755 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74755/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 20274d2389eb012812f4561c8eb7cffc57a68850 baseline

[Xen-devel] [xen-unstable-smoke test] 123321: regressions - FAIL

flight 123321 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123321/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

[Xen-devel] [linux-4.14 test] 123283: regressions - FAIL

flight 123283 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123283/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123147

[Xen-devel] [xen-unstable test] 123280: tolerable FAIL

flight 123280 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/123280/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 6 xen-install fail like 123238

[Xen-devel] [PATCH v4 14/21] hw: Do not include "sysemu/blockdev.h" if it is not necessary

Remove those unneeded includes to speed up the compilation process a little bit. Code change produced with: $ git grep '#include "sysemu/blockdev.h"' | \ cut -d: -f-1 | \ xargs egrep -L "(BlockInterfaceType|DriveInfo|drive_get|blk_legacy_dinfo|blockdev_mark_auto_del)" | \

[Xen-devel] [PATCH v4 12/21] hw: Do not include "sysemu/block-backend.h" if it is not necessary

Remove those unneeded includes to speed up the compilation process a little bit. (Continue 7eceff5b5a1fa cleanup) Signed-off-by: Philippe Mathieu-Daudé --- hw/arm/collie.c | 1 - hw/arm/gumstix.c | 1 - hw/arm/mainstone.c |

[Xen-devel] [xen-unstable-smoke test] 123319: regressions - FAIL

flight 123319 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123319/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

[Xen-devel] Question about patch "svm: fix incorrect TSC scaling"

Hi Haozhong and AMD SVM maintainers, I am writing to ask about below patch as I am not familiar with AMD tsc scaling: commit 11eeca65126e51f03a883907751d5ccbe4f35aa3 Author: Haozhong Zhang Date: Tue Dec 8 09:46:12 2015 +0100 svm: fix incorrect TSC scaling SVM TSC ratio is

[Xen-devel] [libvirt test] 123285: regressions - FAIL

flight 123285 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/123285/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 6 xen-install fail REGR. vs. 123189 Tests which did not

[Xen-devel] [PATCH v2] x86/xen: Combine PV features to be disabled in xen_nopv

From: Konrad Rzeszutek Wilk Extend 'xen_nopv' parameter to disable individual features in the following format: xen_nopv={ [spin,][ipi] | all } 'spin' to disable PV spinlocks 'ipi' to disable PV IPI 'all' to disable all of the above and PV drivers 'all' ideally would be the set of features

[Xen-devel] [xen-unstable-smoke test] 123313: regressions - FAIL

flight 123313 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123313/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

[Xen-devel] [linux-3.18 test] 123274: tolerable FAIL - PUSHED

flight 123274 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123274/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 6 xen-install fail in 123222 pass in 123274 test-armhf-armhf-xl-arndale 6

[Xen-devel] [xen-unstable-smoke test] 123306: regressions - FAIL

flight 123306 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123306/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

[Xen-devel] [ovmf test] 123281: all pass - PUSHED

flight 123281 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/123281/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 20274d2389eb012812f4561c8eb7cffc57a68850 baseline version: ovmf

[Xen-devel] [linux-linus test] 123271: regressions - FAIL

flight 123271 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/123271/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123188

[Xen-devel] [qemu-mainline test] 123268: regressions - FAIL

flight 123268 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/123268/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 122357

Re: [Xen-devel] [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Fri 25-05-18 09:43:09, Huaisheng HS1 Ye wrote: > From: Michal Hocko [mailto:mho...@kernel.org] > Sent: Thursday, May 24, 2018 8:19 PM> > > > Let me try to reply your questions. > > > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two > > > advantages > > > from the series of

Re: [Xen-devel] [PATCH][next] ALSA: xen-front: remove redundant error check on ret

On Mon, 28 May 2018 00:42:12 +0200, Takashi Sakamoto wrote: > > Hi, > > On May 28 2018 06:23, Colin King wrote: > > From: Colin Ian King > > > > The error for a -ve value in ret is redundant as all previous > > assignments to ret have an associated -ve check and hence

[Xen-devel] [PATCH] ALSA: xen: ensure nul-terminated device name

gcc-8 warns that pcm_instance->name is not necessarily terminated correctly if the input is more than 80 characters long or lacks a termination byte itself: In function 'strncpy', inlined from 'cfg_device' at sound/xen/xen_snd_front_cfg.c:399:3, inlined from 'xen_snd_front_cfg_card' at

[Xen-devel] [xen-unstable-smoke test] 123303: regressions - FAIL

flight 123303 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123303/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

Re: [Xen-devel] [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD

On Fri 25-05-18 05:00:44, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote: > > > ie if we had more, > > > could we solve our pain by making them more generic? > > > > Well, if you have more you will consume more bits in the struct pages, > > right? > > Not

Re: [Xen-devel] [PATCH] x86/XPTI: fix S3 resume (and CPU offlining in general)

On 24/05/18 15:41, Jan Beulich wrote: > In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image") > I've failed to remember the fact that multiple CPUs share a stub > mapping page. Therefore it is wrong to unconditionally zap the mapping > when bringing down a CPU; it may only be

Re: [Xen-devel] [PATCH v2] x86/XPTI: fix S3 resume (and CPU offlining in general)

On 25/05/18 08:02, Jan Beulich wrote: > We should index an L1 table with an L1 index. > > Reported-by: Simon Gaiser > Signed-off-by: Jan Beulich Release-acked-by: Juergen Gross Juergen

[Xen-devel] Commit moratorium is lifted

Committers, With OSSTEST doing a push the commit moratorium is lifted, please commit patches that are already Release-acked. Juergen Gross ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] Commit moratorium is lifted

Committers, With OSSTEST doing a push the commit moratorium is lifted, please commit patches that are already Release-acked. Juergen Gross ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH][next] ALSA: xen-front: fix unsigned error check on return from to_sndif_format

On Mon, 28 May 2018 00:49:03 +0200, Takashi Sakamoto wrote: > > Hi, > > On May 28 2018 06:32, Colin King wrote: > > From: Colin Ian King > > > > The negative error return from the call to to_sndif_format is being > > assigned to an unsigned 8 bit integer and hence the

Re: [Xen-devel] [PATCH 5/9] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

On 27/05/18 04:56, Tian, Kevin wrote: >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Tuesday, May 22, 2018 7:21 PM >> >> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, >> Xen >> updates a host MSR load list entry with the current hardware value of >>

[Xen-devel] Debug guest state (VMI)

Hi ! I'm playing with the VMI APIs using LibVMI, and i need to track down a bug that i reported here: https://github.com/libvmi/libvmi/issues/621 Basically the domain is still paused even thought i called the right API to resume it and the event buffer is supposed to be empty. Now there are 2

Re: [Xen-devel] [PATCH 4/9] x86/vmx: Support remote access to the MSR lists

On 27/05/18 04:47, Tian, Kevin wrote: >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Tuesday, May 22, 2018 7:21 PM >> >> At the moment, all modifications of the MSR lists are in current context. >> However, future changes may need to put MSR_EFER into the lists from >> domctl

[Xen-devel] [PATCH 2/6] x86: Improvements to ler debugging

* Command line documentation for what the option does. * Implement a canonicalise_addr() helper and replace the opencoded use in sign_extend_msr() * Canonicalise the ler pointers and print symbol information. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] [PATCH 4/6] x86/vmx: Simplify PAT handling during vcpu construction

The host PAT value is a compile time constant, and doesn't need to be read out of hardware. Merge this if block into the previous block, which has an identical condition. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima

[Xen-devel] [PATCH 1/6] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit

Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, Xen updates a host MSR load list entry with the current hardware value of MSR_DEBUGCTL. This is wrong. On VMExit, hardware automatically resets MSR_DEBUGCTL to 0. The only case where different behaviour is needed is if Xen is

[Xen-devel] [PATCH 0/6] x86/vmx: Misc fixes and improvements

Patch 1 might want to be considered for 4.11. All others are 4.12 material at this point. Andrew Cooper (6): x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit x86: Improvements to ler debugging x86/pat: Simplify host PAT handling x86/vmx: Simplify PAT handling during vcpu construction

[Xen-devel] [PATCH 5/6] x86/vmx: Defer vmx_vmcs_exit() as long as possible in construct_vmcs()

paging_update_paging_modes() and vmx_vlapic_msr_changed() both operate on the VMCS being constructed. Avoid dropping and re-acquiring the reference multiple times. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima

[Xen-devel] [PATCH 3/6] x86/pat: Simplify host PAT handling

With the removal of the 32bit hypervisor build, host_pat is a constant value. Drop the variable and the redundant cpu_has_pat predicate, and use a define instead. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC:

[Xen-devel] [PATCH 6/6] x86/vmx: Drop VMX signal for full real-mode

The hvmloader code which used this signal was deleted 10 years ago (c/s 50b12df83 "x86 vmx: Remove vmxassist"). Furthermore, the value gets discarded anyway because the HVM domain builder unconditionally sets %rax to 0 in the same action it uses to set %rip to the appropriate entrypoint.

Re: [Xen-devel] [PATCH v2] x86/CPUID: don't override tool stack decision to hide STIBP

On 28/05/18 08:08, Jan Beulich wrote: > Other than in the feature sets, where we indeed want to offer the > feature even if not enumerated on hardware, we shouldn't dictate the > feature being available if tool stack or host admin have decided to not > expose it (for whatever [questionable?]

[Xen-devel] [ovmf baseline-only test] 74752: all pass

This run is configured for baseline tests only. flight 74752 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74752/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 03ac238b1fe40cfbb1424bf72e2ac8276345e03c baseline

[Xen-devel] [xen-unstable-smoke test] 123300: regressions - FAIL

flight 123300 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123300/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

[Xen-devel] [xen-unstable baseline-only test] 74751: tolerable FAIL

This run is configured for baseline tests only. flight 74751 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74751/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 guest-start fail

[Xen-devel] [xen-unstable-smoke test] 123296: regressions - FAIL

flight 123296 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/123296/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 123071 Tests which

[Xen-devel] [linux-4.9 test] 123257: regressions - FAIL

flight 123257 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123257/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 6 xen-install fail REGR. vs. 122969

Re: [Xen-devel] [PATCH v4 00/10] xen/arm64: Suspend preconditions and CPU hotplug fixes

Hi, Could you please provide feedback for the remaining patches? Thanks, Mirela On Tue, May 15, 2018 at 1:44 PM, Mirela Simonovic < mirela.simono...@aggios.com> wrote: > This patch set contains fixes that are required as precondition for > suspend to > RAM support, including the CPU hotplug

[Xen-devel] [PATCH v2] x86/CPUID: don't override tool stack decision to hide STIBP

Other than in the feature sets, where we indeed want to offer the feature even if not enumerated on hardware, we shouldn't dictate the feature being available if tool stack or host admin have decided to not expose it (for whatever [questionable?] reason). That feature set side override is

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