Re: [Xen-devel] David Vrabel mail bouncing

Hi Juergen, On Wed, 26 Apr 2017 07:47:49 +0200 Juergen Gross wrote: > > On 26/04/17 07:03, Stephen Rothwell wrote: > > Hi all, > > > > David's citrix.com email address is bouncing. Is there a new one I should > > use for the xen-tip tree contact, or should I just remove him? > > > > Just re

Re: [Xen-devel] [Qemu-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

Stefano Stabellini writes: > On Tue, 25 Apr 2017, Markus Armbruster wrote: >> Stefano Stabellini writes: [...] >> > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h >> > new file mode 100644 >> > index 000..6e33d77 >> > --- /dev/null >> > +++ b/hw/9pfs/xen-9pfs.h >> > @@ -0,0 +1,21 @@ >>

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Wed, Apr 26, 2017 at 06:45:42AM +0200, Juergen Gross wrote: > The really clean solution would be to add this test to set_cpu_bug() No, the really clean solution is to set it once and not play toggle games. > This would work. OTOH I'd prefer to test whether the bit should be > forced to remain

Re: [Xen-devel] [seabios bisection] complete build-amd64-xsm

>>> On 26.04.17 at 04:27, wrote: > branch xen-unstable > xenbranch xen-unstable > job build-amd64-xsm > testid xen-build > > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git > Tree: qemuu git://xenbits.xen.org/qemu-xen.git > Tree: seabios git://git.seabios.org/seabios.git > Tree: xen git

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

>>> On 25.04.17 at 17:24, wrote: > On 24/04/17 18:54, Mohit Gambhir wrote: >> This patch adds Intel PMU MSR addresses as macros for VPMU testing >> >> Signed-off-by: Mohit Gambhir >> --- >> arch/x86/include/arch/msr-index.h | 11 +++ >> 1 file changed, 11 insertions(+) >> >> diff --git a

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

>>> On 25.04.17 at 16:52, wrote: > On 25/04/17 14:52, Wei Liu wrote: >> + >> +for_each_vcpu( d, v ) >> +{ >> +rc = setup_compat_arg_xlat(v); >> +if ( !rc ) >> +rc = setup_compat_l4(v); >> + >> +if ( rc ) >> +goto undo_and_fail; > > This is o

[Xen-devel] [seabios test] 107684: regressions - FAIL

flight 107684 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107684/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

[Xen-devel] Is Xen supports banana PI?

Is Xen supports banana PI? Cause It’s A-20 but there’s no document for support banana-pi Cause I’m wonder if there’s do ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] David Vrabel mail bouncing

On 26/04/17 07:03, Stephen Rothwell wrote: > Hi all, > > David's citrix.com email address is bouncing. Is there a new one I should > use for the xen-tip tree contact, or should I just remove him? > Just remove him, please. He is no longer maintainer of the Xen tree. Juergen _

[Xen-devel] [seabios bisection] complete build-amd64

branch xen-unstable xenbranch xen-unstable job build-amd64 testid xen-build Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://git.seabios.org/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced pro

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

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

[Xen-devel] Is Xen supports banana PI?

Is Xen supports banana PI? Cause It’s A-20 but there’s no document for support banana-pi Cause I’m wonder if there’s documentation for support banana-pi or anyone who already started for banana pi ___ Xen-devel mailing list Xen-devel@lists.xen.org https:

[Xen-devel] David Vrabel mail bouncing

Hi all, David's citrix.com email address is bouncing. Is there a new one I should use for the xen-tip tree contact, or should I just remove him? -- Cheers, Stephen Rothwell ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, On Wed, 12 Apr 2017 14:30:21 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the xen-tip tree got a conflict in: > > arch/x86/xen/enlighten.c > > between commit: > > 687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820 > code") > > from the t

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 21:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > > So the whole thing we're doing right now i

[Xen-devel] [seabios bisection] complete build-amd64-xsm

branch xen-unstable xenbranch xen-unstable job build-amd64-xsm testid xen-build Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://git.seabios.org/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced

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

flight 107644 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107644/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-amd 19 guest-start/debian.repeat fail REGR. vs. 107636 Tests which did n

Re: [Xen-devel] [Qemu-devel] [PATCH 10/21] xen: import ring.h from xen

On 04/25/2017 03:35 PM, Stefano Stabellini wrote: Do not use the ring.h header installed on the system. Instead, import the header into the QEMU codebase. This avoids problems when QEMU is built against a Xen version too old to provide all the ring macros. Signed-off-by: Stefano Stabellini Revi

Re: [Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

On Fri, Apr 21, 2017 at 04:12:40PM +0200, Jiri Slaby wrote: > Somewhere END was used to end a function. It is not intended to be used > for functions, because it does not mark the actual symbols as functions. > Use ENDPROC in such cases which does the right job. > > Signed-off-by: Jiri Slaby > Cc

[Xen-devel] [qemu-mainline baseline-only test] 71230: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71230 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71230/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 de

[Xen-devel] [seabios test] 107677: regressions - FAIL

flight 107677 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107677/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

[Xen-devel] [xtf test] 107664: all pass - PUSHED

flight 107664 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/107664/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 1846c75ecc946a877b455dc997e38f8424d31906 baseline version: xtf 637b0d1d1a02b0563cd196

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

flight 107642 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107642/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107635 test-amd64-i386-xl-qemuu-win7-amd64

[Xen-devel] [seabios test] 107670: regressions - FAIL

flight 107670 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107670/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

Re: [Xen-devel] [PATCH v3 2/2][XTF] xtf/vpmu: MSR read/write tests for VPMU

On 04/25/2017 02:20 PM, Andrew Cooper wrote: On 24/04/17 18:54, Mohit Gambhir wrote: This patch tests VPMU functionality in the hypervisor on Intel machines. The tests write to all valid bits in the MSRs that get exposed to the guests when VPMU is enabled. The tests also write invalid values t

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 09:17:13PM +0100, Andrew Cooper wrote: > The problem (for all ring-deprivileged virtuailsation; not just Xen PV), > is that I know what that that bug flag is for. I'm asking whether the xen guest boot sets a flag early - like XENPV, for example - which can differentiate be

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > So the whole thing we're doing right now is w

Re: [Xen-devel] [PATCH v8 for-4.9 3/5] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

On 24/04/17 09:19, Jan Beulich wrote: On 21.04.17 at 18:10, wrote: >> On 21/04/17 16:45, Jan Beulich wrote: >> On 21.04.17 at 16:05, wrote: +#define COPY_FROM_GUEST_BUF(dst, args, buf_idx) \ +_raw_copy_from_guest_buf(&dst, args, buf_idx, sizeof(dst)) + +#define CO

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: > And what happens when there is a scheduling event right here? > __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong > path. So the whole thing we're doing right now is wrong: set bit and then clear bit. We should not

Re: [Xen-devel] [PATCH v3 0/2][XTF] xtf/vpmu VPMU tests

On 24/04/17 18:54, Mohit Gambhir wrote: > Mohit Gambhir (2): > xtf/vpmu: Add Intel PMU MSR addresses > xtf/vpmu: MSR read/write tests for VPMU > > arch/x86/include/arch/msr-index.h | 11 + > tests/vpmu/Makefile | 9 + > tests/vpmu/main.c | 504 > ++

Re: [Xen-devel] [PATCH v3 2/2][XTF] xtf/vpmu: MSR read/write tests for VPMU

On 24/04/17 18:54, Mohit Gambhir wrote: > This patch tests VPMU functionality in the hypervisor on Intel machines. > The tests write to all valid bits in the MSRs that get exposed to the guests > when VPMU is enabled. The tests also write invalid values to the bits > that should be masked and expec

[Xen-devel] [PATCH 17/21] xen/9pfs: build and register Xen 9pfs backend

Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/Makefile.objs| 1 + hw/xen/xen_backend.c | 3 +++ include/hw/xen/xen_backend.h | 3 +++ 3 files changed, 7 insertions(+) di

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

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

[Xen-devel] [PATCH 20/21] move xen-hvm.c to hw/i386/xen/

From: Anthony Xu move xen-hvm.c to hw/i386/xen/ Signed-off -by: Anthony Xu Reviewed-by: Stefano Stabellini --- Makefile.target |3 +- hw/i386/xen/Makefile.objs |2 +- hw/i386/xen/trace-events | 11 + hw/i386/xen/xen-hvm.c | 1429 +++

[Xen-devel] [PATCH 21/21] move xen-mapcache.c to hw/i386/xen/

From: Anthony Xu move xen-mapcache.c to hw/i386/xen/ Signed-off -by: Anthony Xu Reviewed-by: Stefano Stabellini --- Makefile.target| 3 - default-configs/i386-softmmu.mak | 1 - default-configs/x86_64-softmmu.mak | 1 - hw/i386/xen/Makefile.objs | 2 +-

[Xen-devel] [PULL 0/21] Please pull xen-20170421-v2-tag for 2.10

Added a fix for the clang build, see alpine.DEB.2.10.1704251014320.2875@sstabellini-ThinkPad-X260 The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059: Update version for v2.9.0-rc1 release (2017-03-21 17:13:29 +) are available in the git repository at: git://xen

[Xen-devel] [PATCH 10/21] xen: import ring.h from xen

Do not use the ring.h header installed on the system. Instead, import the header into the QEMU codebase. This avoids problems when QEMU is built against a Xen version too old to provide all the ring macros. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: anthony.per...@citrix.com CC

[Xen-devel] [PATCH 19/21] move xen-common.c to hw/xen/

From: Anthony Xu move xen-common.c to hw/xen/ Signed-off -by: Anthony Xu Reviewed-by: Stefano Stabellini --- Makefile.target | 2 - hw/xen/Makefile.objs | 2 +- hw/xen/xen-common.c | 169 +++ stubs/Makefile.objs | 1 + stubs/xen-com

[Xen-devel] [PATCH 13/21] xen/9pfs: connect to the frontend

Write the limits of the backend to xenstore. Connect to the frontend. Upon connection, allocate the rings according to the protocol specification. Initialize a QEMUBH to schedule work upon receiving an event channel notification from the frontend. Signed-off-by: Stefano Stabellini CC: anthony.pe

[Xen-devel] [PATCH 16/21] xen/9pfs: send responses back to the frontend

Once a request is completed, xen_9pfs_push_and_notify gets called. In xen_9pfs_push_and_notify, update the indexes (data has already been copied to the sg by the common code) and send a notification to the frontend. Schedule the bottom-half to check if we already have any other requests pending.

[Xen-devel] [PATCH 15/21] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

Implement xen_9pfs_init_in/out_iov_from_pdu and xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the data on the ring. This is safe as we only handle one request per ring at any given time. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: An

[Xen-devel] [PATCH 12/21] xen/9pfs: introduce Xen 9pfs backend

Introduce the Xen 9pfs backend: add struct XenDevOps to register as a Xen backend and add struct V9fsTransport to register as v9fs transport. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Ane

[Xen-devel] [PATCH 18/21] add xen-9p-backend to MAINTAINERS under Xen

Signed-off-by: Stefano Stabellini Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: gr...@kaod.org CC: anthony.per...@citrix.com --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 779c429..420505e 100644 --- a/MAINTAINERS +++ b/MAINTAI

[Xen-devel] [PATCH 14/21] xen/9pfs: receive requests from the frontend

Upon receiving an event channel notification from the frontend, schedule the bottom half. From the bottom half, read one request from the ring, create a pdu and call pdu_submit to handle it. For now, only handle one request per ring at a time. Signed-off-by: Stefano Stabellini CC: anthony.per...

[Xen-devel] [PATCH 09/21] configure: use pkg-config for obtaining xen version

From: Juergen Gross Instead of trying to guess the Xen version to use by compiling various test programs first just ask the system via pkg-config. Only if it can't return the version fall back to the test program scheme. If configure is being called with dedicated flags for the Xen libraries use

[Xen-devel] [PATCH 04/21] configure: detect presence of libxendevicemodel

From: Paul Durrant This patch adds code in configure to set CONFIG_XEN_CTRL_INTERFACE_VERSION to a new value of 490 if libxendevicemodel is present in the build environment. Signed-off-by: Paul Durrant Signed-off-by: Stefano Stabellini Reviewed-by: Anthony Perard Reviewed-by: Stefano Stabelli

[Xen-devel] [PATCH 05/21] xen: use libxendevicemodel when available

From: Paul Durrant This patch modifies the wrapper functions in xen_common.h to use the new xendevicemodel interface if it is available along with compatibility code to use the old libxenctrl interface if it is not. Signed-off-by: Paul Durrant Signed-off-by: Stefano Stabellini Reviewed-by: Ant

[Xen-devel] [PATCH 02/21] xen: rename xen_modified_memory() to xen_hvm_modified_memory()

From: Paul Durrant This patch is a purely cosmetic change that avoids a name collision in a subsequent patch. Signed-off-by: Paul Durrant Reviewed-by: Anthony Perard Reviewed-by: Stefano Stabellini --- include/exec/ram_addr.h | 4 ++-- include/hw/xen/xen.h| 2 +- xen-hvm-stub.c

[Xen-devel] [PATCH 03/21] xen: create wrappers for all other uses of xc_hvm_XXX() functions

From: Paul Durrant This patch creates inline wrapper functions in xen_common.h for all open coded calls to xc_hvm_XXX() functions outside of xen_common.h so that use of xen_xc can be made implicit. This again is in preparation for the move to using libxendevicemodel. Signed-off-by: Paul Durrant

[Xen-devel] [PATCH 11/21] 9p: introduce a type for the 9p header

Use the new type in virtio-9p-device. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz Reviewed-by: Philippe Mathieu-Daudé CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/9p.h | 6 ++ hw/9pfs/virtio-9p-device.c | 6 +-

[Xen-devel] [PATCH 07/21] xen: use libxendevice model to restrict operations

From: Paul Durrant This patch adds a command-line option (-xen-domid-restrict) which will use the new libxendevicemodel API to restrict devicemodel [1] operations to the specified domid. (Such operations are not applicable to the xenpv machine type). This patch also adds a tracepoint to allow su

[Xen-devel] [PATCH 06/21] xen: use 5 digit xen versions

From: Juergen Gross Today qemu is using e.g. the value 480 for Xen version 4.8.0. As some Xen version tests are using ">" relations this scheme will lead to problems when Xen version 4.10.0 is being reached. Instead of the 3 digit schem use a 5 digit scheme (e.g. 40800 for version 4.8.0). Signe

[Xen-devel] [PATCH 01/21] xen: make use of xen_xc implicit in xen_common.h inlines

From: Paul Durrant Doing this will make the transition to using the new libxendevicemodel interface less intrusive on the callers of these functions, since using the new library will require a change of handle. NOTE: The patch also moves the 'externs' for xen_xc and xen_fmem from xen_backe

[Xen-devel] [PATCH 08/21] xen: additionally restrict xenforeignmemory operations

From: Paul Durrant Commit f0f272baf3a7 "xen: use libxendevice model to restrict operations" added a command-line option (-xen-domid-restrict) to limit operations using the libxendevicemodel API to a specified domid. The commit also noted that the restriction would be extended to cover operations

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 20:24, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote: >> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set >> on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test >> cpu_caps_cleared to not have disabled this b

Re: [Xen-devel] [OSSTEST PATCH] ts-openstack-deploy: Set http proxy

Anthony PERARD writes ("Re: [OSSTEST PATCH] ts-openstack-deploy: Set http proxy"): > The patch itself looks good, but I think http_proxy_envsettings only set > http_proxy, twice, but does not set https_proxy. Indeed. See my patch "proxy config: Actually set https_proxy too" posted today, when I

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote: > When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set > on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test > cpu_caps_cleared to not have disabled this bit. > > This bug/feature bit is kind of specia

[Xen-devel] [seabios test] 107663: regressions - FAIL

flight 107663 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107663/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-i386-xsm

[Xen-devel] [libvirt test] 107640: tolerable all pass - PUSHED

flight 107640 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/107640/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107613 test-armhf-armhf-libvirt-raw 12 saveresto

Re: [Xen-devel] [OSSTEST PATCH] ts-openstack-deploy: Set http proxy

On Tue, Apr 25, 2017 at 04:14:32PM +0100, Ian Jackson wrote: > This allows ./stack.sh to access the global internet. > > CC: Anthony PERARD > Signed-off-by: Ian Jackson > --- > ts-openstack-deploy | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/ts-openstack-deploy b/ts-openstack-de

[Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test cpu_caps_cleared to not have disabled this bit. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit a

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

On Tue, 25 Apr 2017, Bhupinder Thakur wrote: > On 20 April 2017 at 00:10, Stefano Stabellini wrote: > > We don't have a formal protocol spec for PV console, but if we had, it > > would say that the frontend (Xen in this case) should send notifications > > every time there is new data to write. Thu

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

On 04/25/2017 11:24 AM, Andrew Cooper wrote: On 24/04/17 18:54, Mohit Gambhir wrote: This patch adds Intel PMU MSR addresses as macros for VPMU testing Signed-off-by: Mohit Gambhir --- arch/x86/include/arch/msr-index.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Tue, 25 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 24/04/17 20:16, Stefano Stabellini wrote: > > Given the outstanding regression we need to fix as soon as possible, > > I'll queue these patches on the xentip tree for 4.12. > > It looks like there is another rc for 4.11. I am wondering

Re: [Xen-devel] [Qemu-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

On Tue, 25 Apr 2017, Markus Armbruster wrote: > Stefano Stabellini writes: > > > On Mon, 24 Apr 2017, Peter Maydell wrote: > >> On 24 April 2017 at 22:25, Stefano Stabellini > >> wrote: > >> > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h > >> > new file mode 100644 > >> > index 000.

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

On 24/04/17 18:54, Mohit Gambhir wrote: > This patch adds Intel PMU MSR addresses as macros for VPMU testing > > Signed-off-by: Mohit Gambhir > --- > arch/x86/include/arch/msr-index.h | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/x86/include/arch/msr-index.h > b/arch

[Xen-devel] [distros-debian-snapshot test] 71228: tolerable trouble: blocked/broken/fail/pass

flight 71228 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71228/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail blocked in 71200 test-

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints

On 25/04/17 16:00, Andrew Cooper wrote: On 25/04/17 10:04, Jan Beulich wrote: Stub invocations need to have the space the stub occupies as an input, to prevent the compiler from re-ordering (or omitting) writes to it. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Release-acked-b

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints

On 25/04/17 10:04, Jan Beulich wrote: > Stub invocations need to have the space the stub occupies as an input, > to prevent the compiler from re-ordering (or omitting) writes to it. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-dev

Re: [Xen-devel] [PATCH] x86/32on64: properly honor add-to-physmap-batch's size

On 25/04/17 10:03, Jan Beulich wrote: > Commit 407a3c00ff ("compat/memory: fix build with old gcc") "fixed" a > build issue by switching to the use of uninitialized data. Due to > - the bounding of the uninitialized data item > - the accessed area being outside of Xen space > - arguments being prop

Re: [Xen-devel] [PATCH for-next v2 10/10] x86/domain: move HVM specific code to hvm/domain.c

On 25/04/17 14:52, Wei Liu wrote: > diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c > new file mode 100644 > index 00..dd03cffd0b > --- /dev/null > +++ b/xen/arch/x86/hvm/domain.c > @@ -0,0 +1,326 @@ > +/* > + * HVM domain specific functions. > + * > + * Copyright (C) 201

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

flight 107639 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/107639/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358 Tests which are faili

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

On 25/04/17 14:52, Wei Liu wrote: > - fail: > -pv_domain_destroy(d); > - > -return rc; > -} > - > +void paravirt_ctxt_switch_from(struct vcpu *v); > +void paravirt_ctxt_switch_to(struct vcpu *v); > int arch_domain_create(struct domain *d, unsigned int domcr_flags, >

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

>>>> (XEN) [2017-04-25 10:25:25.092] AMD-Vi: Setup I/O page table: device id = >>>> 0xa3, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3 >>>> (XEN) [2017-04-25 10:25:25.106] AMD-Vi: Setup I/O page table: device id = >>>> 0xa4, ty

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

Hi, Wei On Tue, Apr 25, 2017 at 6:23 PM, Wei Liu wrote: > On Wed, Apr 19, 2017 at 07:26:44PM +0100, Julien Grall wrote: >> Hi Oleksandr, >> >> Please CC the appropriate maintainers for all the components you modify. >> >> On 15/03/17 20:05, Oleksandr Tyshchenko wrote: >> > From: Oleksandr Tyshche

[Xen-devel] [xtf test] 107659: all pass - PUSHED

flight 107659 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/107659/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 637b0d1d1a02b0563cd1966bee800e9e5617e9fa baseline version: xtf 36d926fe0e9b7db39965f4

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

>>> On 25.04.17 at 17:14, wrote: > On 25/04/17 15:54, Vijay Kilari wrote: >> On Tue, Apr 25, 2017 at 5:58 PM, Julien Grall wrote: >> >> By setting 1, we are enabling acpi_numa by default. If not enabled, the >> below >> call has check srat_disabled() before proceeding fails. >

[Xen-devel] [xen-unstable baseline-only test] 71227: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71227 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71227/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3864 host-build-prep

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

On Tue, Apr 25, 2017 at 03:52:06PM +0100, Andrew Cooper wrote: > On 25/04/17 14:52, Wei Liu wrote: > > - fail: > > -pv_domain_destroy(d); > > - > > -return rc; > > -} > > - > > +void paravirt_ctxt_switch_from(struct vcpu *v); > > +void paravirt_ctxt_switch_to(struct vcpu *v); > > int arch_

Re: [Xen-devel] [PATCH for-next v2 08/10] x86/domain: factor out pv_domain_initialise

On 25/04/17 14:52, Wei Liu wrote: > Lump everything PV related in arch_domain_create into > pv_domain_initialise. > > Though domcr_flags and config are not necessary, the new function is > given those to match hvm counterpart. > > Since it cleans up after itself there is no need to clean up in > ar

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

On Wed, Apr 19, 2017 at 07:26:44PM +0100, Julien Grall wrote: > Hi Oleksandr, > > Please CC the appropriate maintainers for all the components you modify. > > On 15/03/17 20:05, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > > > This flag is intended to let Xen know that the gue

[Xen-devel] [OSSTEST PATCH] ts-openstack-deploy: Set http proxy

This allows ./stack.sh to access the global internet. CC: Anthony PERARD Signed-off-by: Ian Jackson --- ts-openstack-deploy | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ts-openstack-deploy b/ts-openstack-deploy index a1c974f..d4c041d 100755 --- a/ts-openstack-deploy +++ b/ts-openstack

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

flight 107638 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/107638/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl

[Xen-devel] [OSSTEST PATCH 1/3] mg-repro-setup: Cope with flights referencing other builds

We attempted to do this by trying to adjust build runvars only if they didn't have a `.'. But cs-adjust-flight runvar-build-set has special handling for : it is always qualified with the flight. So change the match to look for the current flight number. Signed-off-by: Ian Jackson --- mg-repro-

[Xen-devel] [OSSTEST PATCH 2/3] proxy config: Actually set https_proxy too

05406e5aaffb "proxy config: Set https_proxy too" was ineffective because in d22b80bb "proxy config: Factor out http_proxy_envsettings" the variable name $var was not substituted into the new supposedly-more-general shell rune, which consequently lacked the appropriate generality. Signed-off-by: Ia

[Xen-devel] [OSSTEST PATCH 3/3] mg-hosts: -l: print subtask info too

Signed-off-by: Ian Jackson --- mg-allocate | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/mg-allocate b/mg-allocate index 2dfbdb1..4f02ce5 100755 --- a/mg-allocate +++ b/mg-allocate @@ -612,13 +612,19 @@ END qw(restype resname sharei

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

On 25/04/17 15:54, Vijay Kilari wrote: On Tue, Apr 25, 2017 at 5:58 PM, Julien Grall wrote: By setting 1, we are enabling acpi_numa by default. If not enabled, the below call has check srat_disabled() before proceeding fails. My understanding is on x86 acpi_numa is disabled by default an

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

On 04/25/2017 04:36 AM, Jan Beulich wrote: On 24.04.17 at 19:54, wrote: --- a/arch/x86/include/arch/msr-index.h +++ b/arch/x86/include/arch/msr-index.h @@ -38,6 +38,17 @@ #define MSR_GS_BASE 0xc101 #define MSR_SHADOW_GS_BASE 0xc102 +#define MSR_

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

On Tue, Apr 25, 2017 at 5:58 PM, Julien Grall wrote: > > > On 25/04/17 13:20, Vijay Kilari wrote: >> >> On Tue, Apr 25, 2017 at 5:34 PM, Julien Grall >> wrote: >>> >>> Hello Vijay, >>> >>> On 25/04/17 07:54, Vijay Kilari wrote: On Thu, Apr 20, 2017 at 9:29 PM, Julien Grall wr

Re: [Xen-devel] [PATCH for-next v2 06/10] x86/domain: push some code down to hvm_domain_initialise

On Tue, Apr 25, 2017 at 03:15:03PM +0100, Andrew Cooper wrote: > On 25/04/17 14:52, Wei Liu wrote: > > We want to have a single entry point to initialise hvm guest. Now the > > timing to set hap bit and create per domain mapping is deferred, but > > that's not a problem. > > This wording is a lit

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

On Tue, Apr 25, 2017 at 03:08:23PM +0100, Andrew Cooper wrote: > On 25/04/17 14:52, Wei Liu wrote: > > Move PV specific vcpu initialisation code to said function, but leave > > the only line needed by idle domain in vcpu_initialise. > > > > Use pv_vcpu_destroy in error path to simplify code. It is

Re: [Xen-devel] [PATCH for-next v2 07/10] x86/domain: factor out pv_domain_destroy

On 25/04/17 14:52, Wei Liu wrote: > No functional change. > > Signed-off-by: Wei Liu > --- > v2: > 1. reset fields > 2. destroy perdomain mapping You are introducing an additional destroy_perdomain_mapping(), and freeing of the cpuidmasks into this path. Functionally it is fine, but it needs cal

[Xen-devel] [xen-unstable-smoke test] 107650: tolerable trouble: broken/pass - PUSHED

flight 107650 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107650/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12 mig

Re: [Xen-devel] EFI + tboot + Xen

On 04/17/2017 06:05 PM, Rich Persaud wrote: > On Apr 14, 2017, at 16:43, Daniel Kiper > wrote: > >> On Fri, Apr 14, 2017 at 04:17:54PM +0100, Andrew Cooper wrote: >>> On 14/04/2017 15:54, Daniel Kiper wrote: Hey, Has anybody tried to run EFI + tboot

Re: [Xen-devel] [PATCH for-next v2 06/10] x86/domain: push some code down to hvm_domain_initialise

On 25/04/17 14:52, Wei Liu wrote: > We want to have a single entry point to initialise hvm guest. Now the > timing to set hap bit and create per domain mapping is deferred, but > that's not a problem. This wording is a little odd to read. How about "To do this, the setting of hap_enabled and cre

[Xen-devel] [PATCH for-next v2 10/10] x86/domain: move HVM specific code to hvm/domain.c

There is only one function arch_set_info_hvm_guest is moved. The check_segment function is also moved since arch_set_info_hvm_guest is the only user. No functional change. Signed-off-by: Wei Liu Acked-by: Jan Beulich --- xen/arch/x86/domain.c | 291 -

[Xen-devel] [xtf test] 107657: all pass - PUSHED

flight 107657 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/107657/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 36d926fe0e9b7db39965f430cdb4c5f1daf4eef3 baseline version: xtf e399b894f042d3f50d07a8

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

On 25/04/17 14:52, Wei Liu wrote: > Move PV specific vcpu initialisation code to said function, but leave > the only line needed by idle domain in vcpu_initialise. > > Use pv_vcpu_destroy in error path to simplify code. It is safe to do so > because the destruction function accepts partially initia

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

179] AMD-Vi: Skipping host bridge :00:18.0 >>> (XEN) [2017-04-25 10:25:25.194] AMD-Vi: Skipping host bridge :00:18.1 >>> (XEN) [2017-04-25 10:25:25.209] AMD-Vi: Skipping host bridge :00:18.2 >>> (XEN) [2017-04-25 10:25:25.223] AMD-Vi: Skipping host bridge :00

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

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

  1   2   >