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

g 3 14:25:09 2016 +0100 Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20160803-1' into staging usb: bugfixes for xen-usb and ehci, mingw build fix. # gpg: Signature made Wed 03 Aug 2016 14:04:26 BST # gpg:using RSA key 0x4CB6D8EED3E87138 #

[Xen-devel] [Design RFC] Towards work-conserving RTDS scheduler

Hi Dario, I'm thinking about changing the current RTDS scheduler to work-conserving version as we briefly discussed before. Below is a design of the work-conserving RTDS. I'm hoping to get your feedback about the design ideas first before I start writing it in code. I think the code change

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

flight 99928 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99928/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 99917 Regressions which

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

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

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

On 08/03/16 19:16, Konrad Rzeszutek Wilk wrote: > > > 1.4 clwb/clflushopt > > > > > > Writes to NVDIMM may be cached by caches, so certain flushing > > > operations should be performed to make them persistent on > > > NVDIMM. clwb is used in favor of clflushopt and clflush to flush > > >

Re: [Xen-devel] [PATCH RESEND] MAINTAINERS: update email

On Mon, Aug 1, 2016 at 11:53 AM, Xuquan (Euler) wrote: > Wei, thanks!! > This email is sent out from outlook (the Linux can't send out email). the > format may be not correct. If you aren't able to use a tool like 'git send-email' to send out patches, then what most people

Re: [Xen-devel] Some interesting results from schedbench

On Mon, Aug 1, 2016 at 5:26 PM, George Dunlap wrote: > This is due to the difference between credit1 and credit2's load > balancing. Credit1 randomly shifts stuff around based on what it sees > at this instant. Which means that much of the time, it has {A,B} {A,B}, >

[Xen-devel] [PATCH v2] libxl: return any serial tty path in libxl_console_get_tty

When specifying a serial list in domain config, users of libxl_console_get_tty cannot get the tty path of a second specified pty serial, since right now it always returns the tty path of serial 0. Signed-off-by: Bob Liu --- v2: Rename the patch title. --- tools/libxl/libxl.c

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

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

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

This run is configured for baseline tests only. flight 66907 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66907/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 14 guest-saverestore

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

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

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

> > 1.4 clwb/clflushopt > > > > Writes to NVDIMM may be cached by caches, so certain flushing > > operations should be performed to make them persistent on > > NVDIMM. clwb is used in favor of clflushopt and clflush to flush > > writes from caches to memory. > > > > Details of

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

flight 99932 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99932/ 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 12

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

On Wed, Aug 3, 2016 at 4:37 PM, Jan Beulich wrote: On 03.08.16 at 17:28, wrote: >> On 03/08/16 16:25, Jan Beulich wrote: >> On 03.08.16 at 17:11, wrote: On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

On Mon, Jul 18, 2016 at 08:29:12AM +0800, Haozhong Zhang wrote: > Hi, > Hey! Thanks for posting! Sorry for the late review. Below are some of my comment. > Following is version 2 of the design doc for supporting vNVDIMM in > Xen. It's basically the summary of discussion on previous v1 design >

Re: [Xen-devel] [PATCH v2 Altp2m cleanup 0/3] Cleaning up altp2m code

Please disregard this submission for review. I forgot to rebase to current master and this patch is against a code base that is out of date. Apologies for the noise. -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Paul Lai Sent: Wednesday, August

Re: [Xen-devel] HVMOP_guest_request_vm_event only works from guest in ring0

On 03/08/2016 22:00, Razvan Cojocaru wrote: > On 08/03/16 23:44, Andrew Cooper wrote: >> On 03/08/2016 21:37, Bread Cutter wrote: >>> Hello all, >>> >>> I'm writing an executable that runs inside of a guest, and I planned >>> to use vmcall to talk to a tool running in Dom0, using the vm_event >>>

Re: [Xen-devel] HVMOP_guest_request_vm_event only works from guest in ring0

On 08/03/16 23:44, Andrew Cooper wrote: > On 03/08/2016 21:37, Bread Cutter wrote: >> Hello all, >> >> I'm writing an executable that runs inside of a guest, and I planned >> to use vmcall to talk to a tool running in Dom0, using the vm_event >> API. It didn't work, and looking through the code,

Re: [Xen-devel] HVMOP_guest_request_vm_event only works from guest in ring0

On 03/08/2016 21:37, Bread Cutter wrote: > Hello all, > > I'm writing an executable that runs inside of a guest, and I planned > to use vmcall to talk to a tool running in Dom0, using the vm_event > API. It didn't work, and looking through the code, the first thing > hvm_do_hypercall() does is

Re: [Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)

On Wed, 3 Aug 2016, Stefano Stabellini wrote: > On Wed, 3 Aug 2016, Wei Liu wrote: > > > # PV Calls Protocol > > > > > > ## Rationale > > > > > > PV Calls is a paravirtualized protocol for the POSIX socket API. > > > > > > The purpose of PV Calls is to allow the implementation of a specific set

[Xen-devel] HVMOP_guest_request_vm_event only works from guest in ring0

Hello all, I'm writing an executable that runs inside of a guest, and I planned to use vmcall to talk to a tool running in Dom0, using the vm_event API. It didn't work, and looking through the code, the first thing hvm_do_hypercall() does is check if the guest is in ring0. If not, it returns

[Xen-devel] [PATCH v2 Altp2m cleanup 1/3] altp2m cleanup work

Indent goto labels by one space Inline (header) altp2m functions Define default behavior in switch Define max and min for range of altp2m macroed values Signed-off-by: Paul Lai --- xen/arch/x86/hvm/hvm.c| 46 ---

[Xen-devel] [PATCH v2 Altp2m cleanup 3/3] Making altp2m struct dynamically allocated.

Ravi Sahita's dynamically allocated altp2m structs Signed-off-by: Paul Lai Reviewed-by: Ravi Sahita --- xen/arch/x86/hvm/hvm.c | 8 +++--- xen/arch/x86/hvm/vmx/vmx.c | 2 +- xen/arch/x86/mm/altp2m.c | 18 ++---

[Xen-devel] [PATCH v2 Altp2m cleanup 2/3] Move altp2m specific functions to altp2m files.

Move altp2m specific functions to altp2m files. This makes the code a little easier to read. Also moving ept code to ept specific files as requested in: https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html Signed-off-by: Paul Lai ---

[Xen-devel] [PATCH v2 Altp2m cleanup 0/3] Cleaning up altp2m code

Incorporating comments from v1 altp2m clean code URLs: https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03223.html https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03465.html https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03467.html Older

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

flight 99929 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99929/ 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 12

Re: [Xen-devel] [PATCH v6 1/7] xen/arm: Introduce alternative runtime patching

On Wed, Jul 27, 2016 at 05:37:05PM +0100, Julien Grall wrote: > Some of the processor erratum will require to modify code sequence. > As those modifications may impact the performance, they should only > be enabled on affected cores. Furthermore, Xen may also want to take > advantage of new

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

Hi Wei, On 02/08/16 12:01, Wei Liu wrote: On Thu, Jul 28, 2016 at 08:42:05PM +0800, Shannon Zhao wrote: On 2016年07月28日 19:06, Julien Grall wrote: On 26/07/16 02:17, Boris Ostrovsky wrote: On 07/25/2016 07:40 PM, Stefano Stabellini wrote: On Mon, 25 Jul 2016, Boris Ostrovsky wrote: On

[Xen-devel] [qemu-mainline test] 99922: trouble: broken/fail/pass

l host-install(3) Not pushing. commit 90f54472f407f1d0ad0ccab6f59d65b286f269b2 Merge: 8b54a6a 7005f7f Author: Peter Maydell <peter.mayd...@linaro.org> Date: Wed Aug 3 11:52:53 2016 +0100 Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.7-20160

Re: [Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)

On Wed, 3 Aug 2016, Wei Liu wrote: > > # PV Calls Protocol > > > > ## Rationale > > > > PV Calls is a paravirtualized protocol for the POSIX socket API. > > > > The purpose of PV Calls is to allow the implementation of a specific set > > of POSIX functions to be done in a domain other than your

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

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

Re: [Xen-devel] [PATCH v2 10/25] arm/altp2m: Add HVMOP_altp2m_create_p2m.

Hello Sergej, On 01/08/16 18:10, Sergej Proskurin wrote: Signed-off-by: Sergej Proskurin --- Cc: Stefano Stabellini Cc: Julien Grall --- v2: Cosmetic fixes. --- xen/arch/arm/altp2m.c| 23 +++

Re: [Xen-devel] [PATCH v2 09/25] arm/altp2m: Add altp2m table flushing routine.

Hello Sergej, On 01/08/16 18:10, Sergej Proskurin wrote: The current implementation differentiates between flushing and destroying altp2m views. This commit adds the function altp2m_flush, which allows to flush all or individual altp2m views without destroying the entire table. In this way,

Re: [Xen-devel] [PATCH v2 08/25] arm/altp2m: Add HVMOP_altp2m_set_domain_state.

Hello Sergej, On 01/08/16 18:10, Sergej Proskurin wrote: The HVMOP_altp2m_set_domain_state allows to activate altp2m on a specific domain. This commit adopts the x86 HVMOP_altp2m_set_domain_state implementation. Note that the function altp2m_flush is currently implemented in form of a stub.

[Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

The two functions monitor_traps and mem_access_send_req duplicate some of the same functionality. The mem_access_send_req however leaves a lot of the standard vm_event fields to be filled by other functions. Remove mem_access_send_req() completely, making use of monitor_traps() to put requests

[Xen-devel] [PATCH] x86/hvm: Drop the info level HVM save/restore messages

These are not very useful at all, and overly voluminous since the domain builder switched to using XEN_DOMCTL_{get,set}hvmcontext to construct HVM domains. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/common/hvm/save.c | 4 1 file

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Wed, Aug 3, 2016 at 12:16 PM, Julien Grall wrote: > > > On 03/08/16 19:11, Tamas K Lengyel wrote: >> >> On Wed, Aug 3, 2016 at 11:56 AM, Julien Grall >> wrote: >>> >>> >>> >>> On 03/08/16 18:51, Tamas K Lengyel wrote: On Wed, Aug 3,

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

On Wed, 3 Aug 2016, Julien Grall wrote: > Hi Jan, > > On 03/08/16 09:53, Jan Beulich wrote: > > > > > On 02.08.16 at 20:43, wrote: > > > On Tue, 2 Aug 2016, Jan Beulich wrote: > > > > > > > On 02.08.16 at 16:59, wrote: > > > > > On 02/08/16

Re: [Xen-devel] [PATCH v2 06/25] arm/altp2m: Cosmetic fixes - function prototypes.

Hello Sergej, Title: s/altp2m/p2m/ and please remove the full stop. Also this is not really a cosmetic change. On 01/08/16 18:10, Sergej Proskurin wrote: This commit changes the prototype of the following functions: - p2m_alloc_vmid - p2m_free_vmid Signed-off-by: Sergej Proskurin

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 03/08/16 19:11, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 11:56 AM, Julien Grall wrote: On 03/08/16 18:51, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall wrote: The whole discussion of this series was to defer

[Xen-devel] unable start xen in hikey

Hi all, I am unable to start xen in hikey successfully but getting to this prompt message: >* Xen 4.7.0 (c/s Mon Jun 20 11:38:15 2016 +0100 git:9a6cc4f) EFI loader* >* Using configuration file 'xen.cfg'* > * Image: 0x79fd-0x7acb8c00* *> Unable to create new FDT* *Shell* I

[Xen-devel] [PATCH v2] arm/mem_access: don't reinject stage 2 access exceptions

The only way a guest may trip with stage 2 access violation is if mem_access is or was in-use, so reinjecting these exceptions to the guest is never required. Requested-by: Julien Grall Signed-off-by: Tamas K Lengyel --- Cc: Stefano Stabellini

Re: [Xen-devel] [PATCH v2 07/25] arm/altp2m: Add altp2m init/teardown routines.

Hello Sergej, On 01/08/16 18:10, Sergej Proskurin wrote: The p2m initialization now invokes initialization routines responsible for the allocation and initialization of altp2m structures. The same applies to teardown routines. The functionality has been adopted from the x86 altp2m

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Wed, Aug 3, 2016 at 11:56 AM, Julien Grall wrote: > > > On 03/08/16 18:51, Tamas K Lengyel wrote: >> >> On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall >> wrote: >>> >>> The whole discussion of this series was to defer the exposition of altp2m >>>

Re: [Xen-devel] [PATCH v2 05/25] arm/altp2m: Rename and extend p2m_alloc_table.

Hello Sergej, Title: s/altp2m/p2m/ On 01/08/16 18:10, Sergej Proskurin wrote: The initially named function "p2m_alloc_table" allocated pages solely required for the host's p2m. The new implementation leaves p2m allocation related parts inside of this function to generally initialize p2m/altp2m

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 03/08/16 18:51, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall wrote: The whole discussion of this series was to defer the exposition of altp2m HVMOP to the guest until we find a usage. I.e a simple: xsm_hvm_altp2m_op(XSM_PRIV/XSM_DM_PRIV, d);

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

On Mon, Aug 01, 2016 at 10:25:22AM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, Aug 01, 2016 at 04:15:10PM +0200, Petr Tesarik wrote: > > On Mon, 1 Aug 2016 15:47:58 +0200 [...] > I wonder if Xen should do that - as in 'fix' the bootparams to not have it. > Or perhaps Linux code during bootup

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall wrote: > > > On 03/08/16 18:43, Tamas K Lengyel wrote: >> >> On Wed, Aug 3, 2016 at 11:30 AM, Andrew Cooper >> wrote: >>> >>> On 03/08/16 17:51, Julien Grall wrote: On 03/08/16

Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls

On Wed, 3 Aug 2016, Juergen Gross wrote: > On 02/08/16 20:27, Stefano Stabellini wrote: > > On Tue, 2 Aug 2016, Juergen Gross wrote: > >> Instead of calling xen_be_register() for each supported backend type > >> for hvm and pv guests in their machine init functions use a common > >> function in

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 03/08/16 18:43, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 11:30 AM, Andrew Cooper wrote: On 03/08/16 17:51, Julien Grall wrote: On 03/08/16 17:42, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall wrote: Hi

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Wed, Aug 3, 2016 at 11:30 AM, Andrew Cooper wrote: > On 03/08/16 17:51, Julien Grall wrote: >> >> >> On 03/08/16 17:42, Tamas K Lengyel wrote: >>> On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall >>> wrote: Hi Tamas, On

Re: [Xen-devel] [PATCH v2 04/25] arm/altp2m: Move hostp2m init/teardown to individual functions.

Hello Sergej, Title: s/altp2m/p2m/ and please drop the full stop. On 01/08/16 18:10, Sergej Proskurin wrote: This commit pulls out generic init/teardown functionality out of p2m_init and p2m_teardown into p2m_init_one, p2m_free_one, and p2m_flush_table functions. This allows our future

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 03/08/16 17:51, Julien Grall wrote: > > > On 03/08/16 17:42, Tamas K Lengyel wrote: >> On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall >> wrote: >>> Hi Tamas, >>> >>> >>> On 03/08/16 17:01, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall

[Xen-devel] [PATCHv1 2/2] libxencall: release the buffer cache before closing the fd

Freeing a buffer may now call the IOCTL_PRIVCMD_HCALL_BUF_UNLOCK ioctl on the fd, so the fd should only be closed after the buffer cache is released. Signed-off-by: David Vrabel --- tools/libs/call/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Xen-devel] [PATCHv1 1/2] libxencall/linux: use LOCK/UNLOCK ioctls for hypercall buffers

Using just mlock'd buffers for hypercalls is not sufficient as these are still subject to compaction and page migration. Use the new IOCTL_PRIVCMD_HCALL_BUF_LOCK and IOCTL_PRIVCMD_HCALL_BUF_UNLOCK ioctls provided by the privcmd driver to prevent this. Since not all kernels support these ioctls,

[Xen-devel] libxencall/linux: prevent page migration for hypercall buffers

This is the libxencall side of the "xen/privcmd: prevent page migration for hypercall buffers​" series for Linux. It calls the necessary LOCK/UNLOCK ioctls. This should not be applied until after the Linux series is applied. David ___ Xen-devel

[Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

Original version of that patch (commit a89941816726) had to be reverted due to Xen allocating irqs in its cpu_up ops. The first patch moves allocations into hotplug notifiers and the second one restores the original patch (with minor adjustments to new hotplug framework) This originally went

[Xen-devel] [PATCH v2 1/2] xen/x86: Move irq allocation from Xen smp_op.cpu_up()

Commit ce0d3c0a6fb1 ("genirq: Revert sparse irq locking around __cpu_up() and move it to x86 for now") reverted irq locking introduced by commit a89941816726 ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down") because of Xen allocating irqs in both of its cpu_up ops. We can move

[Xen-devel] [PATCH v2 2/2] hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)

Now that Xen no longer allocates irqs in _cpu_up() we can restore commit a89941816726 ("hotplug: Prevent alloc/free of irq descriptors during cpu up/down") Signed-off-by: Boris Ostrovsky Acked-by: Thomas Gleixner CC: x...@kernel.org CC: Thomas

Re: [Xen-devel] [PATCH v2 03/25] arm/altp2m: Add struct vttbr.

(CC Stefano) On 03/08/16 18:04, Julien Grall wrote: Hello Sergej, Title: s/altp2m/p2m/ On 01/08/16 18:10, Sergej Proskurin wrote: The struct vttbr introduces a simple way to precisely access the individual fields of the vttbr. I am not sure whether this is really helpful. You don't seem to

[Xen-devel] [PATCH] x86/debug: Avoid crashing in early boot because of debugger_trap_entry()

debugger_trap_entry() is not safe to use during early boot, as it follows current before it is necesserily safe to do so. Futhermore it does this unconditionally, despite most callsites turning into no-ops because of the vector test. Inline debugger_trap_entry() into the two callers where

Re: [Xen-devel] [PATCH v2 03/25] arm/altp2m: Add struct vttbr.

Hello Sergej, Title: s/altp2m/p2m/ On 01/08/16 18:10, Sergej Proskurin wrote: The struct vttbr introduces a simple way to precisely access the individual fields of the vttbr. I am not sure whether this is really helpful. You don't seem to take often advantage of those fields and the actual

[Xen-devel] [PATCHv1 2/2] xen/privcmd: add ioctls for locking/unlocking hypercall buffers

Using mlock() for hypercall buffers is not sufficient since mlocked pages are still subject to compaction and page migration. Page migration can be prevented by taking additional references to the pages. Introduce two new ioctls: IOCTL_PRIVCMD_HCALL_BUF_LOCK and IOCTL_PRIVCMD_HCALL_BUF_UNLOCK

[Xen-devel] [PATCHv1 0/2] xen/privcmd: prevent page migration for hypercall buffers

Currently libxencall using mlocked buffers for hypercall buffers. This pages are subject to compaction and page migration. A userspace process may see a hypercall fail with -EFAULT if a page backing a hypercall buffer is in the process of being migrated. Page migration can be prevented by taking

[Xen-devel] [PATCHv1 1/2] xen/prvicmd: use ENOTTY if the IOCTL is not supported

The standard return value for ioctl(2) where the cmd is not supported is ENOTTY, not EINVAL. Signed-off-by: David Vrabel --- drivers/xen/privcmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

Hello Sergej, On 01/08/16 18:10, Sergej Proskurin wrote: This commit moves the altp2m-related code from x86 to ARM. Functions that are no yet supported notify the caller or print a BUG message stating their absence. Also, the struct arch_domain is extended with the altp2m_active attribute,

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On 03/08/16 17:42, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall wrote: Hi Tamas, On 03/08/16 17:01, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall wrote: Hello Sergej, Please try to reply to all

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall wrote: > Hi Tamas, > > > On 03/08/16 17:01, Tamas K Lengyel wrote: >> >> On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall wrote: >>> >>> Hello Sergej, >>> >>> Please try to reply to all when answering on the

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On Wed, Aug 3, 2016 at 10:10 AM, George Dunlap wrote: > On 03/08/16 16:58, Tamas K Lengyel wrote: >> On Wed, Aug 3, 2016 at 9:44 AM, George Dunlap >> wrote: >>> On 03/08/16 16:40, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 9:30 AM,

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

Hi Tamas, On 03/08/16 17:01, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall wrote: Hello Sergej, Please try to reply to all when answering on the ML. Otherwise the answer may be delayed/lost. On 03/08/16 13:45, Sergej Proskurin wrote: The

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

On Wed, Aug 03, 2016 at 10:15:51AM -0600, Jan Beulich wrote: > >>> On 03.08.16 at 18:00, wrote: > > On Wed, Aug 03, 2016 at 09:37:41AM -0600, Jan Beulich wrote: > >> >>> On 03.08.16 at 17:28, wrote: > >> > On 03/08/16 16:25, Jan Beulich wrote: > >>

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

>>> On 03.08.16 at 18:10, wrote: > George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> So before qemu devpriv can be usable, *all* the HVMCTL operations would >> need to be audited, and those that were deemed insecure would need

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On 03/08/16 16:58, Tamas K Lengyel wrote: Well, you never know when your series gets split up and have only bits of it merged. So having each patch tested individually is a necessity to ensure nothing gets broken midway through. Especially since mem_access/monitor/vm_event is not tested

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

flight 99926 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99926/ 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 12

Re: [Xen-devel] [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests

On 03/08/16 17:11, Jan Beulich wrote: On 05.07.16 at 21:05, wrote: >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int >> domcr_flags, >> } >> else >> { >> -

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

>>> On 03.08.16 at 18:00, wrote: > On Wed, Aug 03, 2016 at 09:37:41AM -0600, Jan Beulich wrote: >> >>> On 03.08.16 at 17:28, wrote: >> > On 03/08/16 16:25, Jan Beulich wrote: >> > On 03.08.16 at 17:11, wrote: >>

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"): > So before qemu devpriv can be usable, *all* the HVMCTL operations would > need to be audited, and those that were deemed insecure would need to be > either fixed or removed. Even worse, the bad HVMCTLs would

Re: [Xen-devel] [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests

>>> On 05.07.16 at 21:05, wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int > domcr_flags, > } > else > { > -if ( (config->emulation_flags &

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On 03/08/16 16:58, Tamas K Lengyel wrote: > On Wed, Aug 3, 2016 at 9:44 AM, George Dunlap > wrote: >> On 03/08/16 16:40, Tamas K Lengyel wrote: >>> On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap >>> wrote: On 03/08/16 16:18, Tamas K

Re: [Xen-devel] [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi

>>> On 05.07.16 at 21:05, wrote: > Signed-off-by: Boris Ostrovsky Acked-by: Jan Beulich with a suggestion and a minor remark: > @@ -90,16 +87,20 @@ ROMS += $(SEABIOS_ROM) > endif > > .PHONY: all > -all: subdirs-all

Re: [Xen-devel] [PATCH v1 15/20] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated

>>> On 05.07.16 at 21:05, wrote: > --- a/xen/arch/x86/hvm/vlapic.c > +++ b/xen/arch/x86/hvm/vlapic.c > @@ -1115,7 +1115,12 @@ static int __vlapic_accept_pic_intr(struct vcpu *v) > struct domain *d = v->domain; > struct vlapic *vlapic = vcpu_vlapic(v); >

Re: [Xen-devel] [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so _everything_ uses git cache

Andrew Cooper writes ("Re: [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so _everything_ uses git cache"): > On 03/08/16 16:47, Ian Jackson wrote: > Note that the git config url insteadOf feature is backwards: one > configures the config variable "url.NEW-URL.insteadOf.OLD-URL". So >

[Xen-devel] [xen-unstable test] 99917: tolerable FAIL - PUSHED

flight 99917 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99917/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 9 debian-di-install fail in 99911 pass in 99917 test-armhf-armhf-xl-rtds 11

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall wrote: > Hello Sergej, > > Please try to reply to all when answering on the ML. Otherwise the answer > may be delayed/lost. > > On 03/08/16 13:45, Sergej Proskurin wrote: >> >> The interesting part about #VE is that it allows to

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

On Wed, Aug 03, 2016 at 09:37:41AM -0600, Jan Beulich wrote: > >>> On 03.08.16 at 17:28, wrote: > > On 03/08/16 16:25, Jan Beulich wrote: > > On 03.08.16 at 17:11, wrote: > >>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On Wed, Aug 3, 2016 at 9:44 AM, George Dunlap wrote: > On 03/08/16 16:40, Tamas K Lengyel wrote: >> On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap >> wrote: >>> On 03/08/16 16:18, Tamas K Lengyel wrote: On Wed, Aug 3, 2016 at 8:41 AM,

[Xen-devel] [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so _everything_ uses git cache

In particular, when xen.git clones a subtrees, whose url we didn't specify in the runvars, we end up using the url from xen.git's Config.mk. Arrange to use the git cache for all git urls, via the insteadOf feature. Note that the git config url insteadOf feature is backwards: one configures the

Re: [Xen-devel] [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so _everything_ uses git cache

On 03/08/16 16:47, Ian Jackson wrote: > In particular, when xen.git clones a subtrees, whose url we didn't > specify in the runvars, we end up using the url from xen.git's > Config.mk. > > Arrange to use the git cache for all git urls, via the insteadOf > feature. > > Note that the git config url

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On 03/08/16 16:40, Tamas K Lengyel wrote: > On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap > wrote: >> On 03/08/16 16:18, Tamas K Lengyel wrote: >>> On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap >>> wrote: On 01/08/16 17:52, Tamas K

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Aug 3, 2016, at 07:50 AM, li...@ssl-mail.com wrote: > So *today's* simplest working combination seems to be After the sytem is booted with + patched kernel - /mapbs + efi=no-rs I now get tons of these at serial console (XEN) [2016-08-03 15:23:25] d1v0

Re: [Xen-devel] [PATCH v7 06/15] xen: Move the hvm_start_info C representation to the public headers

>>> On 28.07.16 at 12:50, wrote: > Instead of having several representation of hvm_start_info in C, define > it in public/arch-x86/hvm/start_info.h so both libxc and hvmloader can > use it. > > Also move the comment describing the binary format to be alongside the > C

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap wrote: > On 03/08/16 16:18, Tamas K Lengyel wrote: >> On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap >> wrote: >>> On 01/08/16 17:52, Tamas K Lengyel wrote: The two functions monitor_traps and

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

>>> On 03.08.16 at 17:28, wrote: > On 03/08/16 16:25, Jan Beulich wrote: > On 03.08.16 at 17:11, wrote: >>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich wrote: >>> On 02.08.16 at 17:49,

Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings

On Wed, Aug 3, 2016 at 5:43 AM, Julien Grall wrote: > Hi Tamas, > > On 02/08/16 23:47, Tamas K Lengyel wrote: >> >> On Tue, Aug 2, 2016 at 4:05 PM, Julien Grall wrote: >>> >>> On 02/08/2016 22:34, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On 03/08/16 16:18, Tamas K Lengyel wrote: > On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap > wrote: >> On 01/08/16 17:52, Tamas K Lengyel wrote: >>> The two functions monitor_traps and mem_access_send_req duplicate some of >>> the >>> same functionality. The

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

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

Re: [Xen-devel] [PATCH 8/9] x86/hypercall: Merge the hypercall arg tables

>>> On 03.08.16 at 17:15, wrote: > On 03/08/16 16:12, Jan Beulich wrote: > On 18.07.16 at 11:51, wrote: >>> For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables" and >>> (TODO - changeset) "x86/pv: Merge the pv hypercall

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

On 03/08/16 16:25, Jan Beulich wrote: On 03.08.16 at 17:11, wrote: >> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich wrote: >> On 02.08.16 at 17:49, wrote: On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

>>> On 03.08.16 at 17:11, wrote: > On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich wrote: > On 02.08.16 at 17:49, wrote: >>> On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote: On Fri, Jul 29, 2016 at

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap wrote: > On 01/08/16 17:52, Tamas K Lengyel wrote: >> The two functions monitor_traps and mem_access_send_req duplicate some of the >> same functionality. The mem_access_send_req however leaves a lot of the >> standard

  1   2   >