[Xen-devel] [xen-4.5-testing baseline-only test] 72359: regressions - FAIL

This run is configured for baseline tests only. flight 72359 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72359/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 15

Re: [Xen-devel] [PATCH 0/6] Intel Processor Trace virtulization enabling

> >>> Hi All, > >>> > >>> Here is a patch-series which adding Processor Trace enabling in XEN > >>> guest. You can get It's software developer manuals from: > >>> https://software.intel.com/sites/default/files/managed/c5/15/archite > >>> ct ure-instruction-set-extensions-programming-reference.pdf

Re: [Xen-devel] [RFC XEN PATCH v3 00/39] Add vNVDIMM support to HVM domains

On 10/27/17 11:26 +0800, Chao Peng wrote: > On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote: > > Overview > > == > > > > > (RFC v2 can be found at https://lists.xen.org/archives/html/xen- > devel/2017-03/msg02401.html) > > > > Well, this RFC v3 changes and inflates a lot

Re: [Xen-devel] [RFC XEN PATCH v3 00/39] Add vNVDIMM support to HVM domains

On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote: > Overview > == > > > (RFC v2 can be found at https://lists.xen.org/archives/html/xen- devel/2017-03/msg02401.html) > > Well, this RFC v3 changes and inflates a lot from previous versions. > The primary changes are listed

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

flight 115247 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/115247/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114825 test-armhf-armhf-libvirt 14

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

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

Re: [Xen-devel] [PATCH V3 8/29] tools/libxl: create vIOMMU during domain construction

On 2017年10月26日 20:05, Wei Liu wrote: > On Thu, Oct 19, 2017 at 11:13:57AM +0100, Roger Pau Monné wrote: >>> + >>> +if (viommu->type == LIBXL_VIOMMU_TYPE_INTEL_VTD) { >>> +ret = xc_viommu_create(ctx->xch, domid, >>> VIOMMU_TYPE_INTEL_VTD, >>> +

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

flight 115244 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/115244/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114682

Re: [Xen-devel] [Qemu-devel] [PATCH] x86: Skip check apic_id_limit for Xen

On 2017年10月26日 22:27, Michael S. Tsirkin wrote: > On Thu, Oct 26, 2017 at 02:19:43PM +0200, Eduardo Habkost wrote: >> On Mon, Aug 21, 2017 at 10:22:15AM +0800, Lan Tianyu wrote: >>> On 2017年08月19日 00:38, Eduardo Habkost wrote: On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote: >

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

flight 115242 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/115242/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114814 Tests which did not

[Xen-devel] [xen-4.7-testing baseline-only test] 72355: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 72355 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72355/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1)

[Xen-devel] [PULL 2/3] xen: dont try setting max grants multiple times

From: Juergen Gross Trying to call xengnttab_set_max_grants() with the same file handle might fail on some kernels, as this operation is allowed only once. This is a problem for the qdisk backend as blk_connect() can be called multiple times for a domain, e.g. in case grub-xen

[Xen-devel] [PULL 0/3] xen-20171026-tag

-dm.git tags/xen-20171026-tag for you to fetch changes up to 7cdcca725b6bfc96634c15e3f74ae4b148cf9c40: xen: Log errno rather than return value (2017-10-26 14:26:48 -0700) Xen 2017/10/26

[Xen-devel] [PULL 3/3] xen: Log errno rather than return value

From: Ross Lagerwall xen_modified_memory() sets errno to communicate what went wrong so log this rather than the return value which is not interesting. Signed-off-by: Ross Lagerwall Acked-by: Anthony PERARD

[Xen-devel] [PULL 1/3] xen: add a global indicator for grant copy being available

From: Juergen Gross The Xen qdisk backend needs to test whether grant copy operations is available in the kernel. Unfortunately this collides with using xengnttab_set_max_grants() on some kernels as this operation has to be the first one after opening the gnttab device. In

Re: [Xen-devel] [PATCH v5.1 5/8] xen: move xc_interface compatibility fallback further up the file

On Fri, 20 Oct 2017, Ian Jackson wrote: > We are going to want to use the dummy xendevicemodel_handle type in > new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000 > section. So we need to provide that definition, or (as applicable) > include the appropriate header, earlier in the

Re: [Xen-devel] [PATCH 1/3] arm/xen: don't inclide rwlock.h directly.1~B

On 10/05/2017 03:58 PM, Stefano Stabellini wrote: > On Thu, 5 Oct 2017, Sebastian Andrzej Siewior wrote: >> rwlock.h should not be included directly. Instead linux/splinlock.h >> should be included. One thing it does is to break the RT build. >> >> Cc: Stefano Stabellini

Re: [Xen-devel] [PATCH v2] xen: fix booting ballooned down hvm guest

On 10/26/2017 10:12 AM, Boris Ostrovsky wrote: > On 10/26/2017 05:50 AM, Juergen Gross wrote: >> Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't >> online new memory initially") introduced a regression when booting a >> HVM domain with memory less than mem-max: instead of

Re: [Xen-devel] [PATCH] xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

On 10/25/2017 12:46 PM, Boris Ostrovsky wrote: > On 10/25/2017 11:08 AM, Juergen Gross wrote: >> In case gntdev_mmap() succeeds only partially in mapping grant pages >> it will leave some vital information uninitialized needed later for >> cleanup. This will lead to an out of bounds array access

Re: [Xen-devel] [PATCH v5.1 1/8] xen: link against xentoolcore

On Fri, 20 Oct 2017, Ian Jackson wrote: > From: Anthony PERARD > > Xen libraries in 4.10 include a new xentoolcore library. This > contains the xentoolcore_restrict_all function which we are about to > want to use. > > Signed-off-by: Ian Jackson

Re: [Xen-devel] [PATCH v5.1 7/8] os-posix: Provide new -runas : facility

CC'ing the maintainers (scripts/get_maintainer.pl is your friend) On Fri, 20 Oct 2017, Ian Jackson wrote: > This allows the caller to specify a uid and gid to use, even if there > is no corresponding password entry. This will be useful in certain > Xen configurations. > > We don't support just

Re: [Xen-devel] [PATCH v5.1 8/8] configure: do_compiler: Dump some extra info under bash

CC'ing the maintainers for this. On Fri, 20 Oct 2017, Ian Jackson wrote: > This makes it much easier to find a particular thing in config.log. > > The information may be lacking in other shells, resulting in harmless > empty output. (This is why we don't use the proper ${FUNCNAME[*]} > array

Re: [Xen-devel] Some Xen pci-passthrough questions

On 10/26/2017 04:48 PM, Sander Eikelenboom wrote: > Hi Boris / Andrew, > > In the aftermath of the linux mmap path I have some questions regarding > pci-passthrough: > > - Is pci-passthrough in combination with an auto-ballooning dom0 supposed to > be a supported combination ? I thought it is.

Re: [Xen-devel] [PATCH v5.1 6/8] xen: destroy_hvm_domain: Try xendevicemodel_shutdown

On Fri, 20 Oct 2017, Ian Jackson wrote: > xc_interface_open etc. is not going to work if we have dropped > privilege, but xendevicemodel_shutdown will if everything is new > enough. > > xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so > provide a stub for earlier versions. > >

Re: [Xen-devel] [PATCH v5.1 4/8] xen: destroy_hvm_domain: Move reason into a variable

On Fri, 20 Oct 2017, Ian Jackson wrote: > We are going to want to reuse this. > > No functional change. > > Signed-off-by: Ian Jackson > Reviewed-by: Anthony PERARD Acked-by: Stefano Stabellini > --- >

Re: [Xen-devel] [PATCH v5.1 3/8] xen: defer call to xen_restrict until just before os_setup_post

This patch affects non-Xen components. CC'ing the relevant maintainers. On Fri, 20 Oct 2017, Ian Jackson wrote: > We need to restrict *all* the control fds that qemu opens. Looking in > /proc/PID/fd shows there are many; their allocation seems scattered > throughout Xen support code in qemu. >

Re: [Xen-devel] [PATCH v5.1 2/8] xen: restrict: use xentoolcore_restrict_all

On Fri, 20 Oct 2017, Ian Jackson wrote: > And insist that it works. > > Drop individual use of xendevicemodel_restrict and > xenforeignmemory_restrict. These are not actually effective in this > version of qemu, because qemu has a large number of fds open onto > various Xen control devices. > >

Re: [Xen-devel] [PATCH v2 1/2] x86/boot: fix early error display

On 10/18/17 4:50 AM, Jan Beulich wrote: On 17.10.17 at 23:41, wrote: >> From: David Esler >> >> In 9180f5365524 a change was made to the send_chr function to take in >> C-strings and print out a character at a time until a NULL was >> encountered.

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/26/2017 04:49 PM, Stefano Stabellini wrote: > On Thu, 26 Oct 2017, Boris Ostrovsky wrote: >> On 10/26/2017 04:16 PM, Stefano Stabellini wrote: >>> On Thu, 26 Oct 2017, Boris Ostrovsky wrote: On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Also add pvcalls-front to the Makefile.

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On Thu, 26 Oct 2017, Boris Ostrovsky wrote: > On 10/26/2017 04:16 PM, Stefano Stabellini wrote: > > On Thu, 26 Oct 2017, Boris Ostrovsky wrote: > >> On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > >>> Also add pvcalls-front to the Makefile. > >>> > >>> Signed-off-by: Stefano Stabellini

[Xen-devel] Some Xen pci-passthrough questions

Hi Boris / Andrew, In the aftermath of the linux mmap path I have some questions regarding pci-passthrough: - Is pci-passthrough in combination with an auto-ballooning dom0 supposed to be a supported combination ? I have used dom0_maxmem settings for dom0 since ages and that works fine

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/26/2017 04:16 PM, Stefano Stabellini wrote: > On Thu, 26 Oct 2017, Boris Ostrovsky wrote: >> On 10/26/2017 03:11 PM, Stefano Stabellini wrote: >>> Also add pvcalls-front to the Makefile. >>> >>> Signed-off-by: Stefano Stabellini >>> CC: boris.ostrov...@oracle.com >>>

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On Thu, 26 Oct 2017, Boris Ostrovsky wrote: > On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > > Also add pvcalls-front to the Makefile. > > > > Signed-off-by: Stefano Stabellini > > CC: boris.ostrov...@oracle.com > > CC: jgr...@suse.com > > Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On 26/10/17 20:29, Sander Eikelenboom wrote: > On 26/10/17 19:49, Craig Bergstrom wrote: >> Sander, thanks for the details, they've been very useful. >> >> I suspect that your host system's mem=2048M parameter is causing the >> problem. Any chance you can confirm by removing the parameter and >>

Re: [Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Also add pvcalls-front to the Makefile. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v7 12/13] xen/pvcalls: implement release command

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both > in_mutex and out_mutex to avoid concurrent accesses. Then, free the > socket. > > For passive sockets, check whether we have already pre-allocated an > active socket for the

Re: [Xen-devel] [PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

On 10/26/2017 03:11 PM, Stefano Stabellini wrote: > Introduce a data structure named pvcalls_bedata. It contains pointers to > the command ring, the event channel, a list of active sockets and a list > of passive sockets. Lists accesses are protected by a spin_lock. > > Introduce a waitqueue to

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

flight 115235 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/115235/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644

Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!

On 26/10/17 19:49, Craig Bergstrom wrote: > Sander, thanks for the details, they've been very useful. > > I suspect that your host system's mem=2048M parameter is causing the > problem. Any chance you can confirm by removing the parameter and > running the guest code path? I removed it, but

[Xen-devel] [PATCH v7 06/13] xen/pvcalls: implement bind command

Send PVCALLS_BIND to the backend. Introduce a new structure, part of struct sock_mapping, to store information specific to passive sockets. Introduce a status field to keep track of the status of the passive socket. Signed-off-by: Stefano Stabellini Reviewed-by: Boris

[Xen-devel] [PATCH v7 05/13] xen/pvcalls: implement connect command

Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for the active socket. Introduce fields in struct sock_mapping to keep track of active sockets. Introduce a waitqueue to allow the frontend to wait on data coming from the backend on the active socket (recvmsg command). Two

[Xen-devel] [PATCH v7 09/13] xen/pvcalls: implement sendmsg

Send data to an active socket by copying data to the "out" ring. Take the active socket out_mutex so that only one function can access the ring at any given time. If not enough room is available on the ring, rather than returning immediately or sleep-waiting, spin for up to 5000 cycles. This

[Xen-devel] [PATCH v7 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

Introduce a xenbus frontend for the pvcalls protocol, as defined by https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. This patch only adds the stubs, the code will be added by the following patches. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky

[Xen-devel] [PATCH v7 07/13] xen/pvcalls: implement listen command

Send PVCALLS_LISTEN to the backend. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-front.c | 57 +

[Xen-devel] [PATCH v7 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

Also add pvcalls-front to the Makefile. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/Kconfig | 11 +++ drivers/xen/Makefile | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/xen/Kconfig

[Xen-devel] [PATCH v7 02/13] xen/pvcalls: implement frontend disconnect

Introduce a data structure named pvcalls_bedata. It contains pointers to the command ring, the event channel, a list of active sockets and a list of passive sockets. Lists accesses are protected by a spin_lock. Introduce a waitqueue to allow waiting for a response on commands sent to the backend.

[Xen-devel] [PATCH v7 04/13] xen/pvcalls: implement socket command and handle events

Send a PVCALLS_SOCKET command to the backend, use the masked req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0 and PVCALLS_NR_REQ_PER_RING. We already have a slot in the rsp array ready for the response, and there cannot be two outstanding responses with the same req_id. Wait

[Xen-devel] [PATCH v7 11/13] xen/pvcalls: implement poll command

For active sockets, check the indexes and use the inflight_conn_req waitqueue to wait. For passive sockets if an accept is outstanding (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking at bedata->rsp[req_id]. If so, return POLLIN. Otherwise use the inflight_accept_req

[Xen-devel] [PATCH v7 00/13] introduce the Xen PV Calls frontend

Hi all, this series introduces the frontend for the newly introduced PV Calls procotol. PV Calls is a paravirtualized protocol that allows the implementation of a set of POSIX functions in a different domain. The PV Calls frontend sends POSIX function calls to the backend, which implements them

[Xen-devel] [PATCH v7 10/13] xen/pvcalls: implement recvmsg

Implement recvmsg by copying data from the "in" ring. If not enough data is available and the recvmsg call is blocking, then wait on the inflight_conn_req waitqueue. Take the active socket in_mutex so that only one function can access the ring at any given time. Signed-off-by: Stefano Stabellini

[Xen-devel] [PATCH v7 12/13] xen/pvcalls: implement release command

Send PVCALLS_RELEASE to the backend and wait for a reply. Take both in_mutex and out_mutex to avoid concurrent accesses. Then, free the socket. For passive sockets, check whether we have already pre-allocated an active socket for the purpose of being accepted. If so, free that as well.

[Xen-devel] [PATCH v7 08/13] xen/pvcalls: implement accept command

Introduce a waitqueue to allow only one outstanding accept command at any given time and to implement polling on the passive socket. Introduce a flags field to keep track of in-flight accept and poll commands. Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make sure that only

[Xen-devel] [PATCH v7 03/13] xen/pvcalls: connect to the backend

Implement the probe function for the pvcalls frontend. Read the supported versions, max-page-order and function-calls nodes from xenstore. Only one frontend<->backend connection is supported at any given time for a guest. Store the active frontend device to a static pointer. Introduce a stub

[Xen-devel] [xen-4.8-testing baseline-only test] 72353: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 72353 xen-4.8-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72353/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 5

Re: [Xen-devel] [PATCH v6 12/13] xen/pvcalls: implement release command

On Thu, 26 Oct 2017, Boris Ostrovsky wrote: > On 10/25/2017 07:00 PM, Stefano Stabellini wrote: > > On Wed, 25 Oct 2017, Boris Ostrovsky wrote: > >> On 10/24/2017 01:33 PM, Stefano Stabellini wrote: > >>> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both > >>> in_mutex and

[Xen-devel] [distros-debian-wheezy test] 72354: tolerable trouble: broken/pass

flight 72354 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72354/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-arm64 2 hosts-allocate broken like 72331 build-arm64-pvops

Re: [Xen-devel] [PATCH 0/9] x86/vvmx: Read instruction operands correctly on VM exit

On 26/10/17 18:03, Euan Harris wrote: > decode_vmx_inst() does not read instruction operands correctly on VM exit: > > * It incorrectly uses vmx_inst_info's address_size field to calculate >the sizes of the exit-causing instruction's operands. The sizes of >the operands are specified in

Re: [Xen-devel] Is that possible to merge MBA into Xen 4.10?

On Tue, Oct 24, 2017 at 10:10:14AM +0800, Yi Sun wrote: > Hi, all, > > As you may know, MBA patch set has got enough Reviewed-by/Acked-by in last > week. > It is ready to be merged. > > This is a feature for Skylake, Intel has launched Skylake and KVM already > supported MBA, so including it

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

On Thu, Oct 26, Andrew Cooper wrote: > I've never really understood why xenfs exists in the first place > (although I expect the answer is "Because that is how someone did it in > the past"), and I'm not aware of any other project which needs its own > custom filesystem driver for device nodes.

[Xen-devel] [PATCH 6/9] x86/vvmx: Remove operand reading from decode_vmx_inst()

Use operand_read() to read memory operands instead of using the value read by decode_vmx_inst() in the following functions: * nvmx_handle_invept() * nvmx_handle_invvpid() * nvmx_handle_vmclear() * nvmx_handle_vmptrld() * nvmx_handle_vmxon() * nvmx_handle_vmwrite() Signed-off-by: Euan

[Xen-devel] [PATCH 1/9] x86/vvmx: Remove enum vmx_regs_enc

This is the standard register encoding, is not VVMX-specific and is only used in a couple of places. Signed-off-by: Euan Harris --- xen/arch/x86/hvm/vmx/vvmx.c| 8 xen/include/asm-x86/hvm/vmx/vvmx.h | 22 -- 2 files changed, 4

[Xen-devel] [PATCH 5/9] x86/vvmx: Replace direct calls to reg_read() with operand_read()

Use operand_read() to read register operands in the following functions: * nvmx_handle_vmread() * nvmx_handle_vmwrite() * nvmx_handle_invept() Direct reading of memory operands will be replaced in a separate patch. Signed-off-by: Euan Harris ---

[Xen-devel] [PATCH 4/9] x86/vvmx: Remove unnecessary VMX operand reads

* vpid is never used in nvmx_handle_invept() so there is no point in reading it. * vmptrst's operand is the memory address to which to write the VMCS pointer. gpa is the pointer to write. Reading the address into gpa is meaningless. Signed-off-by: Euan Harris

[Xen-devel] [PATCH 9/9] x86/vvmx: Use hvm_copy_{to, from}_guest_virt() to read operands

decode_vmx_inst() contains its own segmentation logic.This unnecessarily duplicates segmentation code used elsewhere and contains errors: it raises a #GP fault instead of an #SS fault for an invalid memory access through the stack segment. Replace this logic with

[Xen-devel] [PATCH 2/9] x86/vvmx: Unify operands in struct vmx_inst_decoded

This change prepares the way for abstracting the code which reads memory and register operands into a generic operand_read() function in a future patch. Operand 1 may either be a memory location or a register, depending on the instruction being handled. Operand 2 may only be a register, but it

[Xen-devel] [PATCH 0/9] x86/vvmx: Read instruction operands correctly on VM exit

decode_vmx_inst() does not read instruction operands correctly on VM exit: * It incorrectly uses vmx_inst_info's address_size field to calculate the sizes of the exit-causing instruction's operands. The sizes of the operands are specified in the SDM and might depend on whether the

[Xen-devel] [PATCH 7/9] x86/vvmx: Use correct sizes when reading operands

The sizes of VMX operands are defined in the Intel SDM and have nothing to do with the addr_size field of struct vmx_inst_info: invept: r32/r64, m128 invvpid: r32/r64, m128 vmclear: m64 vmptrld: m64 vmptrst: m64 vmread: r32/64 or m32/64, r32/64 vmwrite:

[Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

Extract the logic for reading operands from decode_vmx_inst() into operand_read(). Future patches will replace operand reading logic in elsewhere with calls to operand_read(). operand_read() must explicitly handle different operand sizes to avoid corrupting the caller's stack. This patch

[Xen-devel] [PATCH 8/9] x86/hvm: Add hvm_copy_{to, from}_guest_virt() helpers

hvm_copy_{to,from}_guest_virt() copy data to and from a guest, performing segmentatino and paging checks on the provided seg:offset virtual address. Signed-off-by: Euan Harris --- xen/arch/x86/hvm/hvm.c| 57 +++

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

On 26/10/17 16:59, Olaf Hering wrote: > On Thu, Oct 26, Andrew Cooper wrote: > >> Can't all information be obtained from /sys/hypervisor?  If not, how >> hard would it be to make happen? > Likely not that hard. Not sure why that was not added in the first place. I've never really understood why

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

On Thu, Oct 26, Andrew Cooper wrote: > Can't all information be obtained from /sys/hypervisor?  If not, how > hard would it be to make happen? Likely not that hard. Not sure why that was not added in the first place. > What happens to all the software which currently has a dependency on >

Re: [Xen-devel] [PATCH v7 for-next 02/12] pci: introduce a type to store a SBDF

>>> On 18.10.17 at 13:40, wrote: > That provides direct access to all the members that constitute a SBDF. > The only function switched to use it is hvm_pci_decode_addr, because > it makes following patches simpler. > > Suggested-by: Andrew Cooper

Re: [Xen-devel] [PATCH v12 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

>>> On 17.10.17 at 15:24, wrote: > v12: > - Dropped limit checks as requested by Jan. Thanks, but ... > +int gnttab_get_status_frame(struct domain *d, unsigned long idx, > +mfn_t *mfn) > +{ > +struct grant_table *gt = d->grant_table; > +

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

On 26/10/17 16:25, Olaf Hering wrote: > An upcoming change in systemd will mount xenfs right away, along with > all other system mounts. This improves the detection of the > virtualization environment, which is currently racy. Some parts of > systemd rely on the presence of /proc/xen/capabilities,

Re: [Xen-devel] [PATCH v2] xen: fix booting ballooned down hvm guest

Juergen Gross: > Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't > online new memory initially") introduced a regression when booting a > HVM domain with memory less than mem-max: instead of ballooning down > immediately the system would try to use the memory up to mem-max >

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> On 26.10.17 at 17:32, wrote: > On 26/10/17 16:26, Jan Beulich wrote: > On 17.10.17 at 15:24, wrote: >>> +/* IN/OUT - If the tools domain is PV then, upon return, frame_list >>> + * will be populated with the MFNs of the

Re: [Xen-devel] [PATCH for-next] x86/pv: Factor out the calculation of LDT/GDT descriptor pointers

On 26/10/17 16:06, Jan Beulich wrote: On 17.10.17 at 17:05, wrote: >> @@ -16,4 +17,14 @@ static inline int pv_emul_is_mem_write(const struct >> x86_emulate_state *state, >>: X86EMUL_UNHANDLEABLE; >> } >> >> +/*

Re: [Xen-devel] [PATCH v12 06/11] x86/hvm/ioreq: add a new mappable resource type...

>>> On 17.10.17 at 15:24, wrote: > @@ -777,6 +887,52 @@ int hvm_get_ioreq_server_info(struct domain *d, > ioservid_t id, > return rc; > } > > +int hvm_get_ioreq_server_frame(struct domain *d, ioservid_t id, There's another silent truncation issue here: Iirc

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

On 26/10/17 16:26, Jan Beulich wrote: On 17.10.17 at 15:24, wrote: +/* IN/OUT - If the tools domain is PV then, upon return, frame_list + * will be populated with the MFNs of the resource. + * If the tools domain is HVM then it is

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> On 17.10.17 at 15:24, wrote: > @@ -535,6 +588,48 @@ int compat_memory_op(unsigned int cmd, > XEN_GUEST_HANDLE_PARAM(void) compat) > rc = -EFAULT; > break; > > +case XENMEM_acquire_resource: > +{ > +const

[Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

An upcoming change in systemd will mount xenfs right away, along with all other system mounts. This improves the detection of the virtualization environment, which is currently racy. Some parts of systemd rely on the presence of /proc/xen/capabilities, which will only exist if xenfs is mounted.

[Xen-devel] [PATCH] osstest: set arch before calling set_freebsd_runvars

Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson --- make-flight | 2 ++ 1 file changed, 2 insertions(+) diff --git a/make-flight b/make-flight index d595101c..76620c18 100755 --- a/make-flight +++ b/make-flight @@ -676,6 +676,8 @@

Re: [Xen-devel] [PATCH for-next 8/9] xsm: add bodge when compiling with llvm coverage support

On 10/26/2017 05:19 AM, Roger Pau Monne wrote: llvm coverage support seems to disable some of the optimizations needed in order to compile xsm, and the end result is that references to __xsm_action_mismatch_detected are left in the object files. Since coverage support cannot be used in

Re: [Xen-devel] [PATCH for-next] x86/pv: Factor out the calculation of LDT/GDT descriptor pointers

>>> On 17.10.17 at 17:05, wrote: > @@ -16,4 +17,14 @@ static inline int pv_emul_is_mem_write(const struct > x86_emulate_state *state, >: X86EMUL_UNHANDLEABLE; > } > > +/* Return a pointer to the GDT/LDT descriptor

[Xen-devel] [xen-4.5-testing test] 115226: tolerable FAIL - PUSHED

flight 115226 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/115226/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail in 115191 pass in 115226

Re: [Xen-devel] [Qemu-devel] [PATCH] x86: Skip check apic_id_limit for Xen

On Thu, Oct 26, 2017 at 02:19:43PM +0200, Eduardo Habkost wrote: > On Mon, Aug 21, 2017 at 10:22:15AM +0800, Lan Tianyu wrote: > > On 2017年08月19日 00:38, Eduardo Habkost wrote: > > > On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote: > > >> On 2017年08月16日 19:21, Paolo Bonzini wrote: > >

Re: [Xen-devel] [PATCH v2] xen: fix booting ballooned down hvm guest

On 10/26/2017 05:50 AM, Juergen Gross wrote: > Commit 96edd61dcf44362d3ef0bed1a5361e0ac7886a63 ("xen/balloon: don't > online new memory initially") introduced a regression when booting a > HVM domain with memory less than mem-max: instead of ballooning down > immediately the system would try to

Re: [Xen-devel] [PATCH v6 12/13] xen/pvcalls: implement release command

On 10/25/2017 07:00 PM, Stefano Stabellini wrote: > On Wed, 25 Oct 2017, Boris Ostrovsky wrote: >> On 10/24/2017 01:33 PM, Stefano Stabellini wrote: >>> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both >>> in_mutex and out_mutex to avoid concurrent accesses. Then, free the >>>

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

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

Re: [Xen-devel] [PATCH 0/6] Intel Processor Trace virtulization enabling

On 26/10/17 05:13, Kang, Luwei wrote: >>> Hi All, >>> >>> Here is a patch-series which adding Processor Trace enabling in XEN guest. >>> You can get It's software developer manuals from: >>> https://software.intel.com/sites/default/files/managed/c5/15/architect >>>

[Xen-devel] [xen-4.9-testing baseline-only test] 72352: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 72352 xen-4.9-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72352/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 11

[Xen-devel] [linux-next test] 115211: regressions - FAIL

flight 115211 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/115211/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-examine 7 reboot fail REGR. vs. 114658

Re: [Xen-devel] [PATCH V3 8/29] tools/libxl: create vIOMMU during domain construction

On Thu, Oct 19, 2017 at 11:13:57AM +0100, Roger Pau Monné wrote: > > + > > +if (viommu->type == LIBXL_VIOMMU_TYPE_INTEL_VTD) { > > +ret = xc_viommu_create(ctx->xch, domid, > > VIOMMU_TYPE_INTEL_VTD, > > + viommu->base_addr,

Re: [Xen-devel] [Qemu-devel] [PATCH] x86: Skip check apic_id_limit for Xen

On Mon, Aug 21, 2017 at 10:22:15AM +0800, Lan Tianyu wrote: > On 2017年08月19日 00:38, Eduardo Habkost wrote: > > On Thu, Aug 17, 2017 at 09:37:10AM +0800, Lan Tianyu wrote: > >> On 2017年08月16日 19:21, Paolo Bonzini wrote: > >>> On 16/08/2017 02:22, Lan Tianyu wrote: > Xen vIOMMU device model

Re: [Xen-devel] [PATCH 5/5 v2] xenconsole: Define and use a macro XEN_INVALID_PFN instead of -1

On Wed, Oct 25, 2017 at 02:57:08PM +0530, Bhupinder Thakur wrote: > xenconsole will use a new macro XEN_INVALID_PFN instead of -1 for > initializing ring-ref. Can you please paste in the error if the compilation fails with -1? The way this series is arranged make me wonder if the compilation is

Re: [Xen-devel] [PATCH 4/5 v2] xenconsole: Change the type of ring_ref to xen_pfn_t in console_create_ring

On Wed, Oct 25, 2017 at 02:57:07PM +0530, Bhupinder Thakur wrote: > Currently, ring_ref is read as an integer in console_create_ring which could > lead to > truncation of the value as it is reading a 64-bit value. > > The fix is to modify the type of ring_ref to xen_pfn_t and use the correct >

Re: [Xen-devel] [PATCH 3/5 v2] libxc: Fix the data type of mfn parameter passed to xc_map_foreign_range()

On Wed, Oct 25, 2017 at 02:57:06PM +0530, Bhupinder Thakur wrote: > Currently the data type of mfn parameter passed to xc_map_foreign_range() is > unsigned > long. This could be problem for 32-bit arm architectures where the lengh of > long is > 32 bits while mfn happens to be a 64-bit value. >

Re: [Xen-devel] [PATCH 2/5 v2] libxl: Change the type of console_mfn to xen_pfn_t

On 26/10/17 12:13, Wei Liu wrote: > On Wed, Oct 25, 2017 at 02:57:05PM +0530, Bhupinder Thakur wrote: >> Currently the type of console mfn is unsigned long in libxl. This may be >> an issue for 32-bit toolstack running on 64-bit Xen, where the pfn are >> 64 bit. To ensure that console_mfn can hold

Re: [Xen-devel] [PATCH 2/5 v2] libxl: Change the type of console_mfn to xen_pfn_t

On Wed, Oct 25, 2017 at 02:57:05PM +0530, Bhupinder Thakur wrote: > Currently the type of console mfn is unsigned long in libxl. This may be > an issue for 32-bit toolstack running on 64-bit Xen, where the pfn are > 64 bit. To ensure that console_mfn can hold any valid 64-bit pfn, the > type of

Re: [Xen-devel] [PATCH 2/2] x86: fix asm() constraint for GS selector update

On 26/10/17 08:57, Jan Beulich wrote: > Exception fixup code may alter the operand, which ought to be reflected > in the constraint. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Hopefully this won't have caused us any real problems in

  1   2   >