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

[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

[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

[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

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

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

[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

[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

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

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

[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

[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

[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

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

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

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) \ +

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

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

[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

[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

[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 +

[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 -

[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:

[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

[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

[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

[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:

[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:

[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

[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

[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-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

[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

[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

[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.

[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:

[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

[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

[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-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

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

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

[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

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(+)

[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

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

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

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

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

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

[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

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

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

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

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)

[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

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

t; (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, type = 0x5, root

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: >> >

[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

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

[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

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

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 >

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

[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

[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

[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

[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:

[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

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

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

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,

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

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

[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

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

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

[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

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

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

ipping host bridge :00:18.0 >>> (XEN) [2017-04-25 10:25:25.194] AMD-Vi: Skipping host bridge 0000: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:18.3 >>&

[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

Re: [Xen-devel] [PATCH for-next v2 02/10] x86/domain: provide pv_{create, destroy}_gdt_ldt_l1tab and use them

On Tue, Apr 25, 2017 at 02:56:01PM +0100, Andrew Cooper wrote: > On 25/04/17 14:52, Wei Liu wrote: > > This patch encapsulates the perdomain creation and destruction into > > helper functions and use them where appropriate. > > > > Since destroy_perdomain_mapping is idempotent, it is safe to call

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

Hi, On 25/04/17 14:54, Wei Liu wrote: On Tue, Apr 25, 2017 at 03:03:42AM -0600, 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

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

On 25/04/17 14:52, Wei Liu wrote: > The function is made idempotent on purpose. > > No functional change. > > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH for-next v2 03/10] x86/domain: make release_compact_l4 NULL tolerant

On 25/04/17 14:52, Wei Liu wrote: > Push the check in caller down to that function so that it becomes > idempotent. > > No functional change. > > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___

Re: [Xen-devel] [PATCH for-next v2 02/10] x86/domain: provide pv_{create, destroy}_gdt_ldt_l1tab and use them

On 25/04/17 14:52, Wei Liu wrote: > This patch encapsulates the perdomain creation and destruction into > helper functions and use them where appropriate. > > Since destroy_perdomain_mapping is idempotent, it is safe to call the > destruction function multiple times. > > Signed-off-by: Wei Liu

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

On Tue, Apr 25, 2017 at 03:03:42AM -0600, 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

Re: [Xen-devel] [PATCH for-next v2 01/10] x86/mm: make free_perdomain_mappings idempotent

On 25/04/17 14:52, Wei Liu wrote: > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper > --- > Cc: Tim Deegan > Cc: George Dunlap > Cc: Jan Beulich > Cc: Andrew Cooper

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

No functional change. Signed-off-by: Wei Liu --- v2: 1. reset fields 2. destroy perdomain mapping Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/domain.c | 21 + 1 file changed, 13 insertions(+), 8

  1   2   >