Re: [Xen-devel] [PATCH v3 5/7] tools/fuzz: introduce x86 instruction emulator target

>>> On 12.12.16 at 18:51, wrote: > On Mon, Dec 12, 2016 at 02:58:39AM -0700, Jan Beulich wrote: >> >>> On 12.12.16 at 10:28, wrote: >> > Instruction emulator fuzzing code is from code previous written by >> > Andrew and George. Adapted to llvm fuzzer and hook up the build system. >> > >> > Signe

Re: [Xen-devel] [PATCH 2/3] VT-d: correct dma_msi_set_affinity()

>>> On 13.12.16 at 06:23, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Friday, December 09, 2016 4:47 PM >> >> >>> On 08.12.16 at 18:33, wrote: >> > On 08/12/16 16:01, Jan Beulich wrote: >> >> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748 >> > >> > Which

Re: [Xen-devel] [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok and elf_strcmp_safe

>>> On 12.12.16 at 17:56, wrote: > Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce > elf_iter_ok and elf_strcmp_safe"): >> Well, I have to confess that I've read the above as max() when >> in fact it is min(). > > Sadly we can't use min() and max() here it seems. Sure, I und

[Xen-devel] [GIT PULL] xen: features and fixes for 4.10 rc0

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.10-rc0-tag xen: features and fixes for 4.10 rc0 These are some fixes, a move of some arm related headers to share them between arm and arm64 and a series introducing a helper to make

Re: [Xen-devel] [PATCH v2] X86/VPMU:clear the overflow status of which counter happened overflow

> > From: Kang, Luwei > > Sent: Tuesday, December 13, 2016 10:50 AM > > > > just set the corresponding bits of which counter happened overflow, > > rather than set all the available bits of IA32_PERF_GLOBAL_OVF_CTRL > > when happened pmu interrupt. > > "when pmu interrupt happens" > When a co

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

> Subject: RE: [Xen-devel] Future support of 5-level paging in Xen:wq > > > From: Li, Liang Z > > Sent: Tuesday, December 13, 2016 11:58 AM > > > > Hi All, > > > > We are now working on enabling 5 level paging & 5 level EPT for XEN. > > We need the community's opinions about the following aspects:

Re: [Xen-devel] Intel board support for xen

no, I meant some embedded platform like say for example minnowboard. Any other boards like minnowboard? thanks and regards, George On Mon, Dec 12, 2016 at 8:11 PM, Konrad Rzeszutek Wilk < konrad.w...@oracle.com> wrote: > On Mon, Dec 12, 2016 at 12:56:32PM +0530, George John wrote: > > hi, > > >

Re: [Xen-devel] [PATCH 2/3] VT-d: correct dma_msi_set_affinity()

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, December 09, 2016 4:47 PM > > >>> On 08.12.16 at 18:33, wrote: > > On 08/12/16 16:01, Jan Beulich wrote: > >> That commit ("VT-d: use msi_compose_msg()) together with 15aa6c6748 > > > > Which commit? > > Oops - initially I had intend

Re: [Xen-devel] [PATCH] X86/VPMU: mask off uncore overflow bit on xeon phi knights landing

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, December 09, 2016 5:43 PM ing > > >>> On 09.12.16 at 04:17, wrote: > > IA32_PERF_GLOBAL_STATUS.OvfUncore (MSR 38EH, bit[61]) is always 0 and > > writing 1 to IA32_PERF_GLOBAL_OVF_CTRL.ClrOvfUncore (MSR 390H, bit[61]) > > signals #GP.

Re: [Xen-devel] [PATCH v2] X86/VPMU:clear the overflow status of which counter happened overflow

> From: Kang, Luwei > Sent: Tuesday, December 13, 2016 10:50 AM > > just set the corresponding bits of which counter happened overflow, > rather than set all the available bits of IA32_PERF_GLOBAL_OVF_CTRL > when happened pmu interrupt. "when pmu interrupt happens" > > Signed-off-by: Luwei Kang

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation

On Tue, Dec 13, 2016 at 10:47 AM, Kevin Grittner wrote: > On Mon, Dec 12, 2016 at 1:06 PM, Kevin Grittner wrote: >> On Mon, Dec 12, 2016 at 12:32 PM, Kevin Grittner wrote: >> >>> As you can see, this generated a serialization failure. >> >> That was on 9.6. On earlier versions it does indeed al

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

> > From: Li, Liang Z > > Sent: Tuesday, December 13, 2016 11:58 AM > > > > Hi All, > > > > We are now working on enabling 5 level paging & 5 level EPT for XEN. We need > the > > community's opinions about the following aspects: > > > > 1. Should we enable 5 level paging for PV guest ? (You are di

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

> From: Li, Liang Z > Sent: Tuesday, December 13, 2016 11:58 AM > > Hi All, > > We are now working on enabling 5 level paging & 5 level EPT for XEN. We need > the > community's opinions about the following aspects: > > 1. Should we enable 5 level paging for PV guest ? (You are discussing) > 2.

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

Hi All, We are now working on enabling 5 level paging & 5 level EPT for XEN. We need the community's opinions about the following aspects: 1. Should we enable 5 level paging for PV guest ? (You are discussing) 2. Should we make the 5 level paging and 4 level paging supported with one binary?

[Xen-devel] [xen-4.4-testing test] 103166: regressions - FAIL

flight 103166 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103166/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 102521 test-xtf-amd64-

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

flight 68207 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68207/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail like 68160 test-amd64-i386-i38

[Xen-devel] [PATCH v2 6/9] ts-xen-build: Build the livepatch test-cases

The test-cases are quite tied to the Xen hypervisor. In fact they must be built on the same exact xen.gz (and correspondigly xen-syms) that will be running on the host. This is due to build-id dependency which the test-cases are built with. The hypervisor directory only has the `tests` target - no

[Xen-devel] [PATCH v2 4/9] ts-xen-build: Make {xen|}dist.tar.gz only if $builddir/install/{$xen|}install

directories exist. This paves way for adding optional ways to stash other tarballs, such as the livepatch one (xentlpdist). Signed-off-by: Konrad Rzeszutek Wilk --- v2: New submission. --- ts-xen-build | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/ts-xen-build b/ts-

[Xen-devel] [PATCH v2 5/9] ts-xen-build: Enable livepatch.

Livepatch compiles and works on x86/ARM{32|64} so we can unconditionaly enable it. Acked-by: Ian Jackson Signed-off-by: Konrad Rzeszutek Wilk --- v1: First submission v2: Added Ian's Ack --- ts-xen-build | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ts-xen-build b/ts-xen-build index f2

[Xen-devel] [PATCH v2 2/9] Osstest: Add target_cmd_output_root_status

Which is similar to target_cmd_root_status except it outputs both return value _and_ output. To make this work we expose the $backstatusok in tcmdout sub-routine and if set - return the value and output. Otherwise the old mechanism is used. Signed-off-by: Konrad Rzeszutek Wilk --- v2: New patch

[Xen-devel] [PATCH v2 7/9] ts-livepatch-[install|run]: Install and initial test-cases.

There are 37 of the test-cases in there. Before we run any of them we verify that the payload files are present in /usr/lib/debug. If so we go through all of the test-cases. Also as a dependency we only install them if xenltpdist.tar.gz exists. Signed-off-by: Konrad Rzeszutek Wilk --- v1: Initi

[Xen-devel] [PATCH v2 8/9] sg-run-job: Add the test-livepatch.

This way we have the test-livepatch which can unroll to depend on: ts-livepatch-install ts-livepatch-run Signed-off-by: Konrad Rzeszutek Wilk --- v1: Initial submission v2: Include the plus host on the recipe. --- sg-run-job | 6 ++ 1 file changed, 6 insertions(+) diff --git a/sg-run-job

[Xen-devel] [PATCH v2 1/9] OssTest: Add target_cmd_root_status which returns return code.

All the different target_cmd_* end up calling tcmdex which has the unfortunate side-effect of calling 'die' if the SSH sessions results in any return code not zero. That is fine, except for tests where we want to get a non-zero return value. This patch adds the $badstatusok to tcmdex - and makes

[Xen-devel] [PATCH v2 3/9] OssTest: Add target_dir_exists

We have target_file_exists but not an equivalant one for directories. This adds it in and is used in the "ts-xen-build: Make {xen|}dist.tar.gz only if $builddir/install/{$xen|}install" patch. Signed-off-by: Konrad Rzeszutek Wilk --- v2: New patch. --- Osstest/TestSupport.pm | 9 + 1 file

[Xen-devel] [PATCH v2] OSSTest test-harness for livepatches.

Heya! Since v1: - Acted on all reviews (I hope) - Added more patches. With this test-harness I am able to run the regressions tests on livepatches on Xen 4.8. I only used the standalone tests. The incantations was: To prep: ./sg-run-job build-amd64 ./sg-run-job build-amd64-pvops And then to r

[Xen-devel] [PATCH v2] X86/VPMU:clear the overflow status of which counter happened overflow

just set the corresponding bits of which counter happened overflow, rather than set all the available bits of IA32_PERF_GLOBAL_OVF_CTRL when happened pmu interrupt. Signed-off-by: Luwei Kang --- v2:modify the description of this patch. --- xen/arch/x86/cpu/vpmu_intel.c | 2 +- 1 file changed, 1

[Xen-devel] [qemu-mainline test] 103164: tolerable FAIL - PUSHED

flight 103164 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/103164/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102835 test-armhf-armhf-libvirt-x

Re: [Xen-devel] Possible improvement to Xen Security Response Process

On Mon, Dec 12, 2016 at 9:11 AM, Matthew Allen wrote: > On Wed, 2016-12-07 at 16:23 +, Ian Jackson wrote: >> ... >> I have an alternative concrete suggestion: >> >> Unless there are good reasons to diverge, our suggestions to >> discoverer(s) will be based on the following criteria, in order

Re: [Xen-devel] [PATCH 2/3] Add Xen colo support for qemu-upstream colo codes

On 12/12/2016 06:37 PM, Wei Liu wrote: On Thu, Dec 01, 2016 at 01:20:18PM +, Wei Liu wrote: On Wed, Nov 30, 2016 at 05:47:51PM +0800, Zhang Chen wrote: Because of qemu codes update, we update Xen colo block codes Signed-off-by: Zhang Chen COLO being an experimental feature means that y

[Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-amd64-pvgrub

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-amd64-pvgrub testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional

Re: [Xen-devel] [RFC XEN PATCH 03/16] xen/x86: add a hypercall XENPF_pmem_add to report host pmem regions

On 12/12/16 09:44 -0500, Konrad Rzeszutek Wilk wrote: On Mon, Dec 12, 2016 at 04:38:38PM +0800, Haozhong Zhang wrote: On 12/12/16 01:30 -0700, Jan Beulich wrote: > > > > On 12.12.16 at 05:16, wrote: > > On 12/09/16 17:02 -0500, Konrad Rzeszutek Wilk wrote: > > > On Mon, Oct 10, 2016 at 08:32:22

[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-

Re: [Xen-devel] [PATCH v2] AMD IOMMU: Support IOAPIC IDs larger than 128

On 12/12/16 21:46, Jan Beulich wrote: On 05.12.16 at 20:36, wrote: +unsigned int ioapic_id_to_index(unsigned int apic_id) +{ +unsigned int idx; + +if ( !nr_ioapic_sbdf ) +return MAX_IO_APICS; This is pointless (redundant with ... +for ( idx = 0 ; idx < nr_ioapic_sbdf;

[Xen-devel] [xen-4.4-testing bisection] complete test-xtf-amd64-amd64-4

branch xen-4.4-testing xenbranch xen-4.4-testing job test-xtf-amd64-amd64-4 testid leak-check/check Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xen

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

On Mon, Dec 12, 2016 at 2:28 PM, Julien Grall wrote: > Hi Tamas, > > > On 12/12/2016 19:41, Tamas K Lengyel wrote: >> >> On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall >> wrote: >>> >>> Hi Tamas, >>> >>> On 12/12/16 18:42, Tamas K Lengyel wrote: On Mon, Dec 12, 2016 at 4:46 AM, Jul

[Xen-devel] [xen-4.7-testing test] 103163: tolerable FAIL - PUSHED

flight 103163 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103163/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-pair 4 host-install/dst_host(4) broken in 103038 pass in 103163 test-amd64-i386-lib

[Xen-devel] [xen-unstable-smoke test] 103221: tolerable all pass - PUSHED

flight 103221 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103221/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 1

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

flight 103168 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/103168/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8b78de74dc6a7d655de50f1e203cbc830de1d9ae baseline version: ovmf 8537bd7ef64f2ccf3b0db

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation

On Mon, Dec 12, 2016 at 1:06 PM, Kevin Grittner wrote: > On Mon, Dec 12, 2016 at 12:32 PM, Kevin Grittner wrote: > >> As you can see, this generated a serialization failure. > > That was on 9.6. On earlier versions it does indeed allow the > transaction on connection 2 to commit, yielding a non-

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

Hi Tamas, On 12/12/2016 19:41, Tamas K Lengyel wrote: On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall wrote: Hi Tamas, On 12/12/16 18:42, Tamas K Lengyel wrote: On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall wrote: The translation VA to IPA (guest physical address) is done using hardware.

[Xen-devel] [xen-unstable-smoke test] 103214: tolerable all pass - PUSHED

flight 103214 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/103214/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 1

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

On Mon, Dec 12, 2016 at 12:11 PM, Julien Grall wrote: > Hi Tamas, > > On 12/12/16 18:42, Tamas K Lengyel wrote: >> >> On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall >> wrote: >>> >>> The translation VA to IPA (guest physical address) is done using >>> hardware. >>> If the underlying memory of the

Re: [Xen-devel] [DOC v2] Xen transport for 9pfs

On Mon, 12 Dec 2016, Wei Liu wrote: > On Mon, Dec 05, 2016 at 05:33:23PM -0800, Stefano Stabellini wrote: > [...] > > ## Xenstore > > > > The frontend and the backend connect via xenstore to exchange > > information. The toolstack creates front and back nodes with state > > [XenbusStateInitialisin

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

> > So basically you are telling us that due to nested virt on AWS we will > > never be able to drop PV support, right? > > That's right, although never say never :-) Unless cloud provides exposes VMX to the guests (nested virtualization). > > > > Why are we pushing PVH then? > > Because it i

[Xen-devel] [PATCH v3] fix potential pa_range_info out of bound access

pa_range_info has only 8 elements and is accessed using pa_range as index. pa_range is initialized to 16, potentially causing out of bound access errors. Fix the issue by checking that pa_range is not greater than the size of the array. Remove the now superfluous pa_range&0x8 check. Coverity-ID:

Re: [Xen-devel] [PATCH v2] fix potential pa_range_info out of bound access

On Mon, 12 Dec 2016, Julien Grall wrote: > On 12/12/16 19:17, Stefano Stabellini wrote: > > On Mon, 12 Dec 2016, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 09/12/16 19:46, Stefano Stabellini wrote: > > > > pa_range_info has only 8 elements and is accessed using pa_range as > > > > index.

[Xen-devel] [xen-unstable test] 103162: regressions - FAIL

flight 103162 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/103162/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 102942 test-amd64-i386-xl

Re: [Xen-devel] [PATCH v2] fix potential pa_range_info out of bound access

On 12/12/16 19:17, Stefano Stabellini wrote: On Mon, 12 Dec 2016, Julien Grall wrote: Hi Stefano, On 09/12/16 19:46, Stefano Stabellini wrote: pa_range_info has only 8 elements and is accessed using pa_range as index. pa_range is initialized to 16, potentially causing out of bound access err

Re: [Xen-devel] [PATCH v2] fix potential pa_range_info out of bound access

On Mon, 12 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 09/12/16 19:46, Stefano Stabellini wrote: > > pa_range_info has only 8 elements and is accessed using pa_range as > > index. pa_range is initialized to 16, potentially causing out of bound > > access errors. Fix the issue by checking th

Re: [Xen-devel] Future support of 5-level paging in Xen:wq

On Mon, 12 Dec 2016, Juergen Gross wrote: > On 09/12/16 20:31, Stefano Stabellini wrote: > > On Fri, 9 Dec 2016, Juergen Gross wrote: > >> On 09/12/16 00:50, Stefano Stabellini wrote: > >>> On Thu, 8 Dec 2016, Andrew Cooper wrote: > On 08/12/2016 19:18, Stefano Stabellini wrote: > > On Thu

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

Hi Tamas, On 12/12/16 18:42, Tamas K Lengyel wrote: On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall wrote: The translation VA to IPA (guest physical address) is done using hardware. If the underlying memory of the stage-1 page table is protected, so the translation will fail. Given that this fun

Re: [Xen-devel] [PATCH v2] x86/smpboot: Make logical package management more robust

On 12/12/2016 05:04 AM, Thomas Gleixner wrote: > The logical package management has several issues: > > - The APIC ids provided by ACPI are not required to be the same as the >initial APIC id which can be retrieved by CPUID. The APIC ids provided >by ACPI are those which are written by the

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation

On Mon, Dec 12, 2016 at 12:32 PM, Kevin Grittner wrote: > As you can see, this generated a serialization failure. That was on 9.6. On earlier versions it does indeed allow the transaction on connection 2 to commit, yielding a non-serializable result. This makes a pretty strong case for back-pa

[Xen-devel] SMBIOS UUID

Hello all, sorry, as this might be a stupid question for some of you, but I wonder why here: https://github.com/mirage/xen/blob/master/tools/firmware/hvmloader/smbios.c#L438 You allow almost everything to be overwritten in SMBIOS type 1 table except the UUID. Would there be any problems if U

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

On Mon, Dec 12, 2016 at 4:46 AM, Julien Grall wrote: > > > On 12/12/16 07:47, Tamas K Lengyel wrote: >> >> >> >> On Dec 12, 2016 00:42, "Jan Beulich" > > wrote: >> >> >>> On 09.12.16 at 20:59, > > wrote: >> > --- a/xen/arch/a

Re: [Xen-devel] [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation

On Mon, Dec 12, 2016 at 8:45 AM, Ian Jackson wrote: > AIUI the documented behavour is that "every set of successful > transactions is serialisable". Well, in context that is referring to serializable transactions. No such guarantee is provided for other isolation levels. By the way, existing be

[Xen-devel] [PATCH 2/2] xen: Fix determining when domain creation is complete

d->creation_finished is used in several places alter behaviour depending on whether the domain is being created, or is already running. However, there is a latent bug if a toolstack component makes a pair of pause/unpause calls, where creation will be considered finished prematurely. Signed-off-b

[Xen-devel] [PATCH 1/2] x86/hvm: Fix HVMOP_get_param when skipping creating the default ioreq server

c/s e7dabe5 "x86/hvm: don't unconditionally create a default ioreq server" added a break statement, but the logic previously depended on falling through into the default case to fill in the value the caller asked for. This causes the sending migration code to put a junk PARAM into the stream, and

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 12 December 2016 18:04 > To: Paul Durrant > Cc: Konrad Rzeszutek Wilk ; Zhang Chen > ; Changlong Xie > ; Wei Liu ; Eddie Dong > ; Andrew Cooper ; > Ian Jackson ; Wen Congyang > ; Yang Hongyang ; Xen > devel

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

Paul Durrant writes ("RE: [Xen-devel] [PATCH 1/3] Don't create default ioreq server"): > The read side effects are indeed because of the need to support the > old qemu interface. If trad were patched then we could at least > deprecate the default ioreq server but I'm not sure how long we'd > need

Re: [Xen-devel] ioreq server regression

On 12/12/2016 11:36 AM, Andrew Cooper wrote: > On 12/12/16 16:01, Boris Ostrovsky wrote: >> Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a >> default ioreq server") breaks restore for HVM guests. >> >> I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log. >> >> -

Re: [Xen-devel] [PATCH v3 5/7] tools/fuzz: introduce x86 instruction emulator target

On Mon, Dec 12, 2016 at 05:59:40PM +, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH v3 5/7] tools/fuzz: introduce x86 instruction > emulator target"): > > On Mon, Dec 12, 2016 at 04:30:30AM -0700, Jan Beulich wrote: > >>> On 12.12.16 at 12:19, wrote: > > > > I mean "states". There are thre

Re: [Xen-devel] [PATCH v3 5/7] tools/fuzz: introduce x86 instruction emulator target

Wei Liu writes ("Re: [PATCH v3 5/7] tools/fuzz: introduce x86 instruction emulator target"): > On Mon, Dec 12, 2016 at 04:30:30AM -0700, Jan Beulich wrote: >>> On 12.12.16 at 12:19, wrote: > > > I mean "states". There are three states we need to reset. > > > > Hmm, to me as a non-native speaker

Re: [Xen-devel] [PATCH v3 5/7] tools/fuzz: introduce x86 instruction emulator target

On Mon, Dec 12, 2016 at 02:58:39AM -0700, Jan Beulich wrote: > >>> On 12.12.16 at 10:28, wrote: > > Instruction emulator fuzzing code is from code previous written by > > Andrew and George. Adapted to llvm fuzzer and hook up the build system. > > > > Signed-off-by: Andrew Cooper > > Signed-off-b

[Xen-devel] [PATCH v2] x86/emul: Implement the STAC and CLAC instructions

Note that unlike most privilege restricted instructions, STAC and CLAC are documented to raise #UD rather than #GP[0], and indeed do so. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v2: * Exclude the use of legacy prefixes. Their exclusion is undocumented but consistent with observed b

Re: [Xen-devel] [OSSTEST PATCH v8 0/3] Have OpenStack tested on top of xen's master and libvirt's master.

Anthony PERARD writes ("Re: [OSSTEST PATCH v8 0/3] Have OpenStack tested on top of xen's master and libvirt's master."): > On Mon, Dec 12, 2016 at 04:51:47PM +, Ian Jackson wrote: > > The way you have done things, the test-amd64-amd64-devstack job will > > run on a Xen dom0 installed by osstes

Re: [Xen-devel] [PATCH v3] libxl: QED disks support

Cédric Bosdonnat writes ("[PATCH v3] libxl: QED disks support"): > Qdisk supports qcow and qcow2, extend it to also support qed disk > format. The patch is good. I have a qualm, though. I think this would increase our security support footprint to include the qemu qed disk format driver. Specif

Re: [Xen-devel] [OSSTEST PATCH v8 0/3] Have OpenStack tested on top of xen's master and libvirt's master.

On Mon, Dec 12, 2016 at 04:51:47PM +, Ian Jackson wrote: > Anthony PERARD writes ("[OSSTEST PATCH v8 0/3] Have OpenStack tested on top > of xen's master and libvirt's master."): > > I have looked into getting OpenStack been tested on the latest Xen via > > osstest. > > Run of AP_FETCH_PLACEHOL

Re: [Xen-devel] [PATCH v1 6/7] tools/livepatch: Remove unused struct member

On Mon, Dec 12, 2016 at 04:18:09PM +, Ross Lagerwall wrote: > Signed-off-by: Ross Lagerwall Reviewed-by: Konrad Rzeszutek Wilk > --- > tools/misc/xen-livepatch.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c > index d683860.

Re: [Xen-devel] [PATCH v1 3/7] tools/livepatch: Improve output

On Mon, Dec 12, 2016 at 05:02:52PM +, Wei Liu wrote: > On Mon, Dec 12, 2016 at 04:18:06PM +, Ross Lagerwall wrote: > > Improving the output of xen-livepatch, which is currently hard to read, > > especially when an error occurs. > > > > Some examples of the changes: > > Before: > > $ xe

Re: [Xen-devel] [PATCH v1 4/7] livepatch: Set timeout unit to nanoseconds

On Mon, Dec 12, 2016 at 05:02:59PM +, Wei Liu wrote: > On Mon, Dec 12, 2016 at 04:18:07PM +, Ross Lagerwall wrote: > > The hypervisor already expects the timeout from the hypercall to be in > > nanoseconds, so set this expectation everywhere. > > > > Signed-off-by: Ross Lagerwall > > ---

Re: [Xen-devel] [PATCH v4 12/15] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

On Mon, Dec 12, 2016 at 12:14:36PM -0500, Boris Ostrovsky wrote: > On 12/12/2016 12:09 PM, Wei Liu wrote: > > On Mon, Dec 12, 2016 at 11:50:53AM -0500, Boris Ostrovsky wrote: > >> On 12/12/2016 11:47 AM, Boris Ostrovsky wrote: > >>> Come think of it, maybe we should do this for all guests (which re

Re: [Xen-devel] [PATCH v4 12/15] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

On 12/12/2016 12:09 PM, Wei Liu wrote: > On Mon, Dec 12, 2016 at 11:50:53AM -0500, Boris Ostrovsky wrote: >> On 12/12/2016 11:47 AM, Boris Ostrovsky wrote: >>> Come think of it, maybe we should do this for all guests (which really >>> means for HVM too)? >> I meant, of course, for qemu-upstream HVM

Re: [Xen-devel] Possible improvement to Xen Security Response Process

On Wed, 2016-12-07 at 16:23 +, Ian Jackson wrote: > ... > I have an alternative concrete suggestion: > > Unless there are good reasons to diverge, our suggestions to > discoverer(s) will be based on the following criteria, in order of > precedence: > 1. Avoiding disclosure on Fridays, week

Re: [Xen-devel] [PATCH v4 12/15] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

On Mon, Dec 12, 2016 at 11:50:53AM -0500, Boris Ostrovsky wrote: > On 12/12/2016 11:47 AM, Boris Ostrovsky wrote: > > > > Come think of it, maybe we should do this for all guests (which really > > means for HVM too)? > > I meant, of course, for qemu-upstream HVM guests too. > Fine by me -- but p

Re: [Xen-devel] [PATCH v4 1/2] tools/libacpi: update FADT layout to support version 5

On Mon, Dec 12, 2016 at 04:04:24PM +, Roger Pau Monne wrote: > Update the structure of the FADT table to version 5, and use that version for > PVHv2 guests. Note that HVM guests will continue to use FADT 4. In order to do > this, add a new field to acpi_config that contains the ACPI revision to

Re: [Xen-devel] [PATCH v1 6/7] tools/livepatch: Remove unused struct member

On Mon, Dec 12, 2016 at 04:18:09PM +, Ross Lagerwall wrote: > Signed-off-by: Ross Lagerwall Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 4/7] livepatch: Set timeout unit to nanoseconds

On Mon, Dec 12, 2016 at 04:18:07PM +, Ross Lagerwall wrote: > The hypervisor already expects the timeout from the hypercall to be in > nanoseconds, so set this expectation everywhere. > > Signed-off-by: Ross Lagerwall > --- > tools/libxc/include/xenctrl.h | 2 +- > xen/common/livepatch.c

Re: [Xen-devel] [PATCH v1 7/7] tools/livepatch: Exit with 2 if a timeout occurs

On Mon, Dec 12, 2016 at 04:18:10PM +, Ross Lagerwall wrote: > Exit with 0 for success. > Exit with 1 for an error. > Exit with 2 if the operation should be retried for any reason (e.g. a > timeout or because another operation was in progress). > > This allows a program or script driving xen-li

Re: [Xen-devel] [PATCH v1 2/7] tools/livepatch: Set stdout and stderr unbuffered

On Mon, Dec 12, 2016 at 04:18:05PM +, Ross Lagerwall wrote: > Using both stdout and stderr interleaved without newlines can result in > strange output when using line buffered mode (e.g. a terminal) or when > fully buffered (e.g. redirected to a file). Set both to unbuffered mode > to fix this.

Re: [Xen-devel] [PATCH v1 1/7] tools/livepatch: Show the correct expected state before action

On Mon, Dec 12, 2016 at 04:18:04PM +, Ross Lagerwall wrote: > Somewhat confusingly, before the action has been executed the patch is > expected to be in the "allowed" state, not the "expected" state. The ITYM "allow", according to your code. > check for this was correct but the subsequent er

Re: [Xen-devel] [PATCH v1 5/7] tools/livepatch: Remove pointless retry loop

On Mon, Dec 12, 2016 at 04:18:08PM +, Ross Lagerwall wrote: > The default timeout in the hypervisor for a livepatch operation is 30 ms, > but xen-livepatch currently waits for up to 30 seconds for the operation > to complete. Instead, remove the retry loop and simply wait for 2 * 30 ms > for th

Re: [Xen-devel] [PATCH v1 3/7] tools/livepatch: Improve output

On Mon, Dec 12, 2016 at 04:18:06PM +, Ross Lagerwall wrote: > Improving the output of xen-livepatch, which is currently hard to read, > especially when an error occurs. > > Some examples of the changes: > Before: > $ xen-livepatch apply test > Performing apply:. completed > After: >

Re: [Xen-devel] [PATCH v4 12/15] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

On 12/12/2016 11:35 AM, Wei Liu wrote: > On Tue, Nov 29, 2016 at 10:33:19AM -0500, Boris Ostrovsky wrote: > [...] >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c >> index 33c5e4c..d80ab77 100644 >> --- a/tools/libxl/libxl.c >> +++ b/tools/libxl/libxl.c >> @@ -5147,8 +5147,14 @@ int libxl_

Re: [Xen-devel] ioreq server regression

On 12/12/16 16:01, Boris Ostrovsky wrote: > Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a > default ioreq server") breaks restore for HVM guests. > > I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log. > > -boris > Does this help? The current creation_finish

Re: [Xen-devel] ioreq server regression

> -Original Message- > From: Paul Durrant > Sent: 12 December 2016 16:29 > To: Andrew Cooper ; Boris Ostrovsky > ; Jan Beulich ; Juergen > Gross ; xen-devel > Cc: zhangchen.f...@cn.fujitsu.com > Subject: RE: ioreq server regression > > > -Original Message- > > From: Andrew Cooper

Re: [Xen-devel] [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok and elf_strcmp_safe

Jan Beulich writes ("Re: [PATCH 1/8] libelf: loop safety: Introduce elf_iter_ok and elf_strcmp_safe"): > Well, I have to confess that I've read the above as max() when > in fact it is min(). Sadly we can't use min() and max() here it seems. > On 12.12.16 at 17:00, wrote: > > The max_size_for_de

Re: [Xen-devel] ioreq server regression

> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 12 December 2016 16:02 > To: Paul Durrant ; Jan Beulich > ; Andrew Cooper ; > Juergen Gross ; xen-devel > Cc: zhangchen.f...@cn.fujitsu.com > Subject: ioreq server regression > > Looks like commit e7d

Re: [Xen-devel] [PATCH v2] AMD IOMMU: Support IOAPIC IDs larger than 128

>>> On 05.12.16 at 20:36, wrote: > Currently, the driver uses the APIC ID to index into the ioapic_sbdf array. > The current MAX_IO_APICS is 128, which causes the driver initialization > to fail on the system with IOAPIC ID >= 128. > > Instead, this patch adds APIC ID in the struct ioapic_sbdf, >

Re: [Xen-devel] [PATCH] libs/xenstore: set correct FreeBSD device

On Mon, Dec 12, 2016 at 04:07:40PM +, Roger Pau Monne wrote: > The path to the xenstore FreeBSD device is /dev/xen/xenstore. > > Signed-off-by: Roger Pau Monné Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen

Re: [Xen-devel] [OSSTEST PATCH v8 0/3] Have OpenStack tested on top of xen's master and libvirt's master.

Anthony PERARD writes ("[OSSTEST PATCH v8 0/3] Have OpenStack tested on top of xen's master and libvirt's master."): > I have looked into getting OpenStack been tested on the latest Xen via > osstest. > Run of AP_FETCH_PLACEHOLDERS=y ./standalone-generate-dump-flight-runvars on > master (5d88d6299

Re: [Xen-devel] [OSSTEST PATCH v8 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack

Anthony PERARD writes ("[OSSTEST PATCH v8 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack"): > This script installs any necessary packages and clones all of the OpenStack > trees which are used by devstack to deploy OpenStack. > > Signed-off-by: Anthony PERARD Acked-by: Ian J

Re: [Xen-devel] [PATCH v4 12/15] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

On Tue, Nov 29, 2016 at 10:33:19AM -0500, Boris Ostrovsky wrote: [...] > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 33c5e4c..d80ab77 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -5147,8 +5147,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t > domid

Re: [Xen-devel] [PATCH v4 12/15] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

On 12/12/2016 11:47 AM, Boris Ostrovsky wrote: > > Come think of it, maybe we should do this for all guests (which really > means for HVM too)? I meant, of course, for qemu-upstream HVM guests too. -boris ___ Xen-devel mailing list Xen-devel@lists.xe

Re: [Xen-devel] ioreq server regression

> -Original Message- > From: Andrew Cooper > Sent: 12 December 2016 16:27 > To: Paul Durrant ; Boris Ostrovsky > ; Jan Beulich ; Juergen > Gross ; xen-devel > Cc: zhangchen.f...@cn.fujitsu.com > Subject: Re: ioreq server regression > > On 12/12/16 16:22, Paul Durrant wrote: > >> -Orig

Re: [Xen-devel] ioreq server regression

On 12/12/16 16:22, Paul Durrant wrote: >> -Original Message- >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] >> Sent: 12 December 2016 16:02 >> To: Paul Durrant ; Jan Beulich >> ; Andrew Cooper ; >> Juergen Gross ; xen-devel >> Cc: zhangchen.f...@cn.fujitsu.com >> Subject: ior

Re: [Xen-devel] [PATCH v1 7/7] make-flight/mfi-common: Add them in the matrix.

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH v1 7/7] make-flight/mfi-common: Add them in the matrix."): > On Thu, Nov 17, 2016 at 12:24:20PM +, Ian Jackson wrote: > > Can you accompany this with a diff of the output of > >standalone-generate-dump-flight-runvars > > before and afte

[Xen-devel] [PATCH v1 0/7] xen-livepatch misc fixes/changes

Hi all, This series contains a few fixes to the xen-livepatch tool. It also contains a few changes to make the output more readable. Ross Lagerwall (7): tools/livepatch: Show the correct expected state before action tools/livepatch: Set stdout and stderr unbuffered tools/livepatch: Improve

[Xen-devel] [PATCH v1 6/7] tools/livepatch: Remove unused struct member

Signed-off-by: Ross Lagerwall --- tools/misc/xen-livepatch.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c index d683860..9633c4a 100644 --- a/tools/misc/xen-livepatch.c +++ b/tools/misc/xen-livepatch.c @@ -238,7 +238,6 @@ struct {

Re: [Xen-devel] [PATCH 7/8] libelf: loop safety cleanup: Remove superseded image size copy check

>>> On 09.12.16 at 16:44, wrote: > Now, elf_load_image eventually calls elf_memcpy_safe, which calls > elf_iter_ok_counted. > > So there is a work limit of 4x the image size. This is larger than > the previous limit of 2x the image size, but it includes a lot of > other processing too. And the

  1   2   3   >