[Xen-devel] ARM: SMMUv3 support

Hi, Is there any effort put by anyone to get SMMUv3 support in Xen for ARM64?. Would be glad to know. Regards Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

On 2017年03月21日 10:28, Lan Tianyu wrote: > On 2017年03月20日 22:23, Roger Pau Monné wrote: >> Thanks! So you add all this vIOMMU code, but the maximum number of allowed >> vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). >> Is >> there any missing pieces in order to bump

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

On 17/03/17 19:33, Stefano Stabellini wrote: > On Fri, 17 Mar 2017, Juergen Gross wrote: >> On 16/03/17 21:20, Stefano Stabellini wrote: >>> On Thu, 16 Mar 2017, Juergen Gross wrote: Instead of trying to guess the Xen version to use by compiling various test programs first just ask the

Re: [Xen-devel] Supporting systems with large E820 maps

On 20/03/17 20:03, Alex Thorlton wrote: > Hey everyone, > > Recently, I've been working with Boris Ostrovsky to get Xen running on > some of our larger systems, and we've run into a few problems with the > amount of space that Xen sets aside for the E820 map. > > The first problem that I hit was

[Xen-devel] Supporting systems with large E820 maps

Hey everyone, Recently, I've been working with Boris Ostrovsky to get Xen running on some of our larger systems, and we've run into a few problems with the amount of space that Xen sets aside for the E820 map. The first problem that I hit was that E820MAX is far too small, at 128 entries, for

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

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

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

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

[Xen-devel] [PATCH v9 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

After an ioreq server has unmapped, the remaining p2m_ioreq_server entries need to be reset back to p2m_ram_rw. This patch does this synchronously by iterating the p2m table. The synchronous resetting is necessary because we need to guarantee the p2m table is clean before another ioreq server is

[Xen-devel] [PATCH v9 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

A new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added to let one ioreq server claim/disclaim its responsibility for the handling of guest pages with p2m type p2m_ioreq_server. Users of this DMOP can specify which kind of operation is supposed to be emulated in a parameter named flags.

[Xen-devel] [PATCH v9 3/5] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.

In ept_handle_violation(), write violations are also treated as read violations. And when a VM is accessing a write-protected address with read-modify-write instructions, the read emulation process is triggered first. For p2m_ioreq_server pages, current ioreq server only forwards the write

[Xen-devel] [PATCH v9 4/5] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

After an ioreq server has unmapped, the remaining p2m_ioreq_server entries need to be reset back to p2m_ram_rw. This patch does this asynchronously with the current p2m_change_entry_type_global() interface. This patch also disallows live migration, when there's still any outstanding

[Xen-devel] [PATCH v9 0/5] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the

[Xen-devel] [PATCH v9 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

Routine hvmemul_do_io() may need to peek the p2m type of a gfn to select the ioreq server. For example, operations on gfns with p2m_ioreq_server type will be delivered to a corresponding ioreq server, and this requires that the p2m type not be switched back to p2m_ram_rw during the emulation

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

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

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

On 3/21/2017 9:18 AM, Yu Zhang wrote: On 3/21/2017 1:03 AM, Jan Beulich wrote: On 18.03.17 at 11:53, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,

Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

On 2017年03月20日 22:23, Roger Pau Monné wrote: > Thanks! So you add all this vIOMMU code, but the maximum number of allowed > vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). > Is > there any missing pieces in order to bump this? To increase vcpu number, we need to

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

On March 20, 2017 3:35 PM, Jan Beulich wrote: On 20.03.17 at 02:58, wrote: >> On March 16, 2017 11:32 PM, Jan Beulich wrote: >> On 16.03.17 at 15:21, wrote: On March 16, 2017 10:06 PM, Jan Beulich wrote: On 16.03.17 at 14:55,

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

On 3/21/2017 1:03 AM, Jan Beulich wrote: On 18.03.17 at 11:53, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla, (npfec.write_access &&

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 2017年03月20日 19:38, Paolo Bonzini wrote: > Fair enough, though I'd be worried about increasing the attack surface > of the hypervisor. For KVM, for example, IOMMU emulation requires using > the "split irqchip" feature to move the PIC and IOAPIC out of the kernel > and back to QEMU. Yes, just

Re: [Xen-devel] [PATCH 11/11] Enable cirros tests in the default config

On Sun, 19 Mar 2017, Géza Gémes wrote: > The existing cirros tests are enabled, with the following > exceptions: > > cirros-minios-stubdom-hvm and cirros-minios-stubdom-pvhvm are > skipped as raisin does not install the stubdom > > Signed-off-by: Géza Gémes Reviewed-by:

Re: [Xen-devel] [raisin][PATCH 00/11] pygrub fix + cirros tests

Thanks for the patches! :-) I committed patch #2. Please resend the rest of the series addressing the comments. I didn't reply to each patch, but the cirros tests look good except for the few comments regarding the way they interact with the common functions. Cheers, Stefano On Sun, 19 Mar

Re: [Xen-devel] [PATCH 04/11] Introduce cirros-separate-kernel-pv test

On Sun, 19 Mar 2017, Géza Gémes wrote: > This test is the cirros equivalent of the bussybox-pv test > > Signed-off-by: Géza Gémes > --- > tests/cirros-separate-kernel-pv | 28 > tests/series| 1 + > 2 files changed, 29

Re: [Xen-devel] [PATCH 03/11] Introduce cirros tests

On Sun, 19 Mar 2017, Géza Gémes wrote: > Add support for using cirros images in raisin tests > > Signed-off-by: Géza Gémes > --- > configs/config-cirros | 44 ++ > defconfig | 2 + > lib/common-tests.sh | 102 >

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

On Thu, 16 Mar 2017, Julien Grall wrote: > Hi Stefano > > On 03/16/2017 10:33 PM, Stefano Stabellini wrote: > > On Wed, 15 Mar 2017, Julien Grall wrote: > > > Hi Wei, > > > > > > On 15/03/17 08:34, Wei Chen wrote: > > > > On 2017/3/15 8:25, Stefano Stabellini wrote: > > > > > On Mon, 13 Mar

Re: [Xen-devel] [PATCH 02/11] Fix lopartsetup parsing of fdisk output

On Sun, 19 Mar 2017, Géza Gémes wrote: > Change lopartsetup in order to handle partitions, which have the > boot flag enabled. > > Signed-off-by: Géza Gémes Reviewed-by: Stefano Stabellini > --- > scripts/lopartsetup | 6 +- > 1 file

Re: [Xen-devel] [PATCH 01/11] Fix installation of python libs

On Sun, 19 Mar 2017, Géza Gémes wrote: > Change deb package build in order to symlink the files installed > to site-packages to dist-packages to have them inluded in the > default PYTHONPATH > > Signed-off-by: Géza Gémes > --- > scripts/mkdeb | 9 + > 1 file

Re: [Xen-devel] [PATCH 2/3] xen: sched_null: support for hard affinity

On Fri, 17 Mar 2017, Dario Faggioli wrote: > As a (rudimental) way of directing and affecting the > placement logic implemented by the scheduler, support > vCPU hard affinity. > > Basically, a vCPU will now be assigned only to a pCPU > that is part of its own hard affinity. If such pCPU(s) > is

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

flight 106786 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106786/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 106770 Regressions which

Re: [Xen-devel] [PATCH 1/3] xen: sched: introduce the 'null' semi-static scheduler

On Fri, 17 Mar 2017, Dario Faggioli wrote: > In cases where one is absolutely sure that there will be > less vCPUs than pCPUs, having to pay the cose, mostly in > terms of overhead, of an advanced scheduler may be not > desirable. > > The simple scheduler implemented here could be a solution. >

Re: [Xen-devel] [PATCH 3/3] tools: sched: add support for 'null' scheduler

On Fri, 17 Mar 2017, Dario Faggioli wrote: > It being very very basic, also means this scheduler does > not need much support at the tools level (for now). > > Basically, just the definition of the symbol of the > scheduler itself and a couple of stubs. > > Signed-off-by: Dario Faggioli

Re: [Xen-devel] [PATCH 0/3] The 'null' Scheduler

On Fri, 17 Mar 2017, Dario Faggioli wrote: > Hello, > > This patch series implements what I call the 'null' scheduler. > > It's a very simple, very static scheduling posicy that always schedules the > same vCPU(s) on the same pCPU(s). That's it. > > If there are less vCPUs than pCPUs, some of

Re: [Xen-devel] [PATCH v6] xen: Allow a default compiled-in command line using Kconfig

On Tue, 21 Mar 2017, Zhongze Liu wrote: > Added 2 new config entries in common/Kconfig: > CMDLINE and CMDLINE_OVERRIDE > Modifed common/kernel.c:cmdline_parse(). > > The 2 new entries enable an embedded command line to be compiled > in the hypervisor. CMDLINE depends on EXPERT = "y", and

Re: [Xen-devel] [PATCH 0/2] xen/arm32: Use alternative to skip the check of pending serrors

On Thu, 16 Mar 2017, Julien Grall wrote: > Hi, > > On 03/16/2017 09:53 AM, Wei Chen wrote: > > We have provided an option to administrator to determine how to > > handle the SErrors. In order to avoid add overhead to check the > > option at every trap, we want to use the alternative to skip > >

Re: [Xen-devel] [PATCH 18/18] xen/arm: Handle guest external abort as guest SError

On Mon, 13 Mar 2017, Wei Chen wrote: > The guest generated external data/instruction aborts can be treated > as guest SErrors. We already have a handler to handle the SErrors, > so we can reuse this handler to handle guest external aborts. > > Signed-off-by: Wei Chen

Re: [Xen-devel] [PATCH 17/18] xen/arm: Prevent slipping hypervisor SError to guest

On Mon, 13 Mar 2017, Wei Chen wrote: > If there is a pending SError while we're returning from trap. If the > SError handle option is "DIVERSE", we have to prevent slipping this > hypervisor SError to guest. So we have to use the dsb/isb to guarantee > that the pending hypervisor SError would be

Re: [Xen-devel] [PATCH 16/18] xen/arm: Isolate the SError between the context switch of 2 vCPUs

On Mon, 13 Mar 2017, Wei Chen wrote: > If there is a pending SError while we are doing context switch, if the > SError handle option is "FORWARD", We have to guranatee this serror to > be caught by current vCPU, otherwise it will be caught by next vCPU and > be forwarded to this wrong vCPU. > >

Re: [Xen-devel] [PATCH 15/18] xen/arm: Introduce a helper to synchronize SError

On Mon, 20 Mar 2017, Stefano Stabellini wrote: > On Mon, 13 Mar 2017, Wei Chen wrote: > > We may have to isolate the SError between the context switch of > > 2 vCPUs or may have to prevent slipping hypervisor SError to guest. > > I thought the problem is not the risk of slipping hypervisor

Re: [Xen-devel] [PATCH 15/18] xen/arm: Introduce a helper to synchronize SError

On Mon, 13 Mar 2017, Wei Chen wrote: > We may have to isolate the SError between the context switch of > 2 vCPUs or may have to prevent slipping hypervisor SError to guest. I thought the problem is not the risk of slipping hypervisor SErrors to guest, but the risk of slipping previous guest

Re: [Xen-devel] [PATCH 14/18] xen/arm: Unmask the Abort/SError bit in the exception entries

On Mon, 13 Mar 2017, Wei Chen wrote: > Currently, we masked the Abort/SError bit in Xen exception entries. > So Xen could not capture any Abort/SError while it's running. > Now, Xen has the ability to handle the Abort/SError, we should unmask > the Abort/SError bit by default to let Xen capture

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On Mon, Mar 20, 2017 at 2:20 PM, Razvan Cojocaru wrote: > On 03/20/2017 06:54 PM, Jan Beulich wrote: > On 20.03.17 at 17:48, wrote: > >> On 03/20/2017 06:40 PM, Jan Beulich wrote: > >> On 20.03.17 at 17:16,

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

;a=summary Not pushing. commit bedf13ecab38bcd479e9db6994ebc3b2c5c7a3ae Merge: ebedf0f 7bc4f08 Author: Peter Maydell <peter.mayd...@linaro.org> Date: Mon Mar 20 10:05:45 2017 + Merge remote-tracking branch 'remotes/kraxel/tags/pull-fixes-20170320-1

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

flight 106791 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106791/ 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 build-arm64-pvops 5

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

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

Re: [Xen-devel] [RFC] xen/pvh: detect PVH after kexec

On 03/20/2017 02:20 PM, Vitaly Kuznetsov wrote: > PVH guests after kexec boot like normal HVM guests and we're not entering > xen_prepare_pvh() Is it not? Aren't we going via xen_hvm_shutdown() and then SHUTDOWN_soft_reset which would restart at the same entry point as regular boot? -boris >

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On 03/20/2017 06:54 PM, Jan Beulich wrote: On 20.03.17 at 17:48, wrote: >> On 03/20/2017 06:40 PM, Jan Beulich wrote: >> On 20.03.17 at 17:16, wrote: On 03/20/2017 06:14 PM, Razvan Cojocaru wrote: > In any case, back when

[Xen-devel] [linux-next test] 106784: regressions - trouble: blocked/broken/fail/pass

flight 106784 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/106784/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 3 host-install(3)broken REGR. vs. 106777

[Xen-devel] [PATCH v4] altp2m: Allow specifying external-only use-case

Currently setting altp2mhvm=1 in the domain configuration allows access to the altp2m interface for both in-guest and external privileged tools. This poses a problem for use-cases where only external access should be allowed, requiring the user to compile Xen with XSM enabled to be able to

Re: [Xen-devel] [PATCH] x86/monitor: add support for descriptor access events

On Fri, 17 Mar 2017 05:03:44 -0600 "Jan Beulich" wrote: > >>> On 10.03.17 at 16:50, wrote: > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -3645,6 +3645,41 @@ gp_fault: > > return X86EMUL_EXCEPTION; > > } > > > > +int

Re: [Xen-devel] [PATCH v2 09/12] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

Haozhong Zhang writes ("[PATCH v2 09/12] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP"): > If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is > present in xl config, the LMCE capability will be exposed in guest > MSR_IA32_MCG_CAP. By default, LMCE is not

Re: [Xen-devel] [PATCH 3/5] x86/vioapic: introduce support for multiple vIO APICS

On Fri, Mar 03, 2017 at 10:06:03AM -0700, Jan Beulich wrote: > >>> On 23.02.17 at 12:52, wrote: > > +struct hvm_hw_vioapic *gsi_vioapic(struct domain *d, unsigned int gsi, > > const struct domain *d ? > > > +static unsigned int pin_gsi(struct domain *d, struct

[Xen-devel] [RFC] xen/pvh: detect PVH after kexec

PVH guests after kexec boot like normal HVM guests and we're not entering xen_prepare_pvh() but we still want to know that we're PVH. This hack does the job by using XEN_IOPORT_MAGIC but I didn't find any straitforward way to do it. Did I miss something? Or shall we introduce a CPUID leaf or

[Xen-devel] [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

Hi all, This patch series implements a new transport for 9pfs, aimed at Xen systems. The transport is based on a traditional Xen frontend and backend drivers pair. This patch series implements the backend, which typically runs in Dom0. I sent another series to implement the frontend in Linux

Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add tests host related functionality functions

George Dunlap writes ("Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add tests host related functionality functions"): > I had a chat with Ian Jackson, and we agreed that it would be better > to create a file, maybe "test-common.c", that would contain this > variable, as well as the three

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

flight 106789 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106789/ 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 build-arm64-pvops 5

[Xen-devel] [PATCH 2/2] libxl: preserve console tty across soft reset

On soft reset we remove the domain from xenstore and introduce it back to have everything reconnected. Console, however, stays attached (as xenconsoled checks if the domain is dying and our domain is not) but we lose the information about tty: before soft reset: console = "" ... type =

[Xen-devel] [PATCH 1/2] libxl: don't try to rename dm save file for PVH

Guests with LIBXL_DEVICE_MODEL_VERSION_NONE don't have a device model running so there is no save file to rename. Signed-off-by: Vitaly Kuznetsov --- tools/libxl/libxl_create.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git

[Xen-devel] [PATCH 0/2] libxl: fix soft reset for PVHv2 guests

Hi, I'm trying to make kexec/kdump work for PVHv2 guests too. PVHv2 guests are almost HVM guests so no major changes to the soft reset procedures are required. A few issues, however, arose during testing. Linux also requires some changes to boot after kexec. As PVH guests boot like normal HVM

[Xen-devel] [PATCH v5 4/7] xen/9pfs: connect to the backend

Implement functions to handle the xenbus handshake. Upon connection, allocate the rings according to the protocol specification. Initialize a work_struct and a wait_queue. The work_struct will be used to schedule work upon receiving an event channel notification from the backend. The wait_queue

[Xen-devel] [PATCH v5 7/7] xen/9pfs: build 9pfs Xen transport driver

This patch adds a Kconfig option and Makefile support for building the 9pfs Xen driver. Signed-off-by: Stefano Stabellini Reviewed-by: Juergen Gross CC: gr...@kaod.org CC: boris.ostrov...@oracle.com CC: jgr...@suse.com CC: Eric Van Hensbergen

[Xen-devel] [PATCH v5 5/7] xen/9pfs: send requests to the backend

Implement struct p9_trans_module create and close functions by looking at the available Xen 9pfs frontend-backend connections. We don't expect many frontend-backend connections, thus walking a list is OK. Send requests to the backend by copying each request to one of the available rings (each

[Xen-devel] [PATCH v5 2/7] xen: introduce the header file for the Xen 9pfs transport protocol

It uses the new ring.h macros to declare rings and interfaces. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com CC: gr...@kaod.org --- include/xen/interface/io/9pfs.h | 42

[Xen-devel] [PATCH v5 6/7] xen/9pfs: receive responses

Upon receiving a notification from the backend, schedule the p9_xen_response work_struct. p9_xen_response checks if any responses are available, if so, it reads them one by one, calling p9_client_cb to send them up to the 9p layer (p9_client_cb completes the request). Handle the ring following the

[Xen-devel] [PATCH v5 3/7] xen/9pfs: introduce Xen 9pfs transport driver

Introduce the Xen 9pfs transport driver: add struct xenbus_driver to register as a xenbus driver and add struct p9_trans_module to register as v9fs driver. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky

[Xen-devel] [PATCH v5 1/7] xen: import new ring macros in ring.h

Sync the ring.h file with upstream Xen, to introduce the new ring macros. They will be used by the Xen transport for 9pfs. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com CC: gr...@kaod.org --- NB: The new

[Xen-devel] [PATCH v5 0/7] Xen transport for 9pfs frontend driver

Hi all, This patch series implements a new transport for 9pfs, aimed at Xen systems. The transport is based on a traditional Xen frontend and backend drivers pair. This patch series implements the frontend, which typically runs in a regular unprivileged guest. I also sent a series that

Re: [Xen-devel] [PATCH v4 01/14] golang/xenlight: Create stub package

On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote: > Create a basic Makefile to build and install libxenlight Golang > bindings. Also add a stub package which only opens libxl context. > > Include a global xenlight.Ctx variable which can be used as the > default context by

[Xen-devel] [PATCH v2 2/3] Introduce the Xen 9pfs transport header

Define the ring according to the protocol specification, using the new DEFINE_XEN_FLEX_RING_AND_INTF macro. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com --- xen/include/public/io/9pfs.h | 57 1 file changed, 57

[Xen-devel] [PATCH v2 1/3] [RESEND] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

This patch introduces macros, structs and functions to handle rings in the format described by docs/misc/pvcalls.markdown and docs/misc/9pfs.markdown. The index page (struct __name##_data_intf) contains the indexes and the grant refs to setup two rings. Indexes page

[Xen-devel] [PATCH v2 0/3] new ring macros, 9pfs and pvcalls headers

Hi all, this patch series introduces a set of new ring macros to support rings in the formats specified by the Xen 9pfs transport and PV Calls protocol. It also introduces the Xen 9pfs and PV Calls protocols headers. Changes in v2: - replace __attribute__((packed)) with #pragma pack - remove

Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add tests host related functionality functions

On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote: > Create tests for the following functions: > - GetVersionInfo > - GetPhysinfo > - GetDominfo > - GetMaxCpus > - GetOnlineCpus > - GetMaxNodes > - GetFreeMemory > > Signed-off-by: Ronald Rojas >

[Xen-devel] [PATCH v2 3/3] Introduce the pvcalls header

Define the ring and request and response structs according to the specification. Use the new DEFINE_XEN_FLEX_RING macro. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com --- xen/include/public/io/pvcalls.h | 152 1 file

Re: [Xen-devel] [PATCH v2 3/3] x86emul: correct FPU code/data pointers and opcode handling

On 15/03/17 10:28, Jan Beulich wrote: > Prevent leaking the hypervisor ones (stored by hardware during stub > execution), at once making sure the guest sees correct values there. > This piggybacks on the backout logic used to deal with write faults of > FPU insns. > > Deliberately ignore the

Re: [Xen-devel] [PATCH v2 1/3] x86emul: centralize put_fpu() invocations

On 15/03/17 10:27, Jan Beulich wrote: > ..., splitting parts of it into check_*() macros. This is in > preparation of making ->put_fpu() do further adjustments to register > state. (Some of the check_xmm() invocations could be avoided, as in > some of the cases no insns handled there can actually

[Xen-devel] [PATCH v2 1/6] x86/viridian: fix xen-hvmcrash when vp_assist page is present

Currently use of xen-hvmcrash will cause an immediate domain_crash() in initialize_vp_assist() because it is called from viridian_load_vcpu_ctxt() without having first cleared any previous mapping. This patch addes a check into viridian_load_vcpu_ctxt() to avoid re- initialization and turned the

[Xen-devel] [PATCH v2 0/6] viridian updates

Only 6 patches now... Paul Durrant (6): x86/viridian: fix xen-hvmcrash when vp_assist page is present x86/viridian: don't put Xen version information in CPUID leaf 2 x86/viridian: get rid of the magic numbers in CPUID leaves 1 and 2 x86/viridian: add warnings for unimplemented hypercalls

[Xen-devel] [PATCH v2 4/6] x86/viridian: add warnings for unimplemented hypercalls and MSRs

These warnings can be useful when Microsoft updates Windows. In the past there have been several cases when Windows erroneously uses hypercalls and MSRs that should be gated on CPUID flags than Xen does not set. The usual symptom is a guest crash with little or no information in the hypervisor

[Xen-devel] [PATCH v2 6/6] x86/viridian: implement the crash MSRs

Section 2.4.4 of the Hypervisor Top Level Functional Specification states that enabling bit 10 in EDX of CPUID leaf 3 advertises to Windows a set of MSRs into which it can write crash information. This patch advertises that bit and implements the MSRs such that Xen can log the information if a

[Xen-devel] [PATCH v2 5/6] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

The current threshold before the guest issues the hypercall is, and always has been, hard-coded to 2047. It is not clear where this number came from so, to at least allow for ease of experimentation, this patch makes the threshold tunable via the Xen command line. Signed-off-by: Paul Durrant

[Xen-devel] [PATCH v2 2/6] x86/viridian: don't put Xen version information in CPUID leaf 2

The Hypervisor Top Level Functional Specification v5.0a states in section 2.5: "The hypervisor version information is encoded in leaf 0x4002. Two version numbers are provided: the main version and the service version. The main version includes a major and minor version number and a build

[Xen-devel] [PATCH v2 3/6] x86/viridian: get rid of the magic numbers in CPUID leaves 1 and 2

The numbers correspond to ASCII characters so just use appropriate character strings directly. Signed-off-by: Paul Durrant --- Cc: Jan Beulich Cc: Andrew Cooper v2: - Use memcpy() rather than cast-and-assign ---

Re: [Xen-devel] [PATCH 6/7] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

> -Original Message- > From: Andrew Cooper > Sent: 20 March 2017 17:03 > To: Paul Durrant ; xen-de...@lists.xenproject.org > Cc: Jan Beulich > Subject: Re: [PATCH 6/7] x86/viridian: make the threshold for > HvNotifyLongSpinWait tunable > > On

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

>>> On 18.03.17 at 11:53, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned > long gla, > (npfec.write_access && >(p2m_is_discard_write(p2mt) ||

Re: [Xen-devel] [PATCH 6/7] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

On 17/03/17 09:57, Paul Durrant wrote: > The current threshold before the guest issues the hypercall is, and always > has been, hard-coded to 2047. It is not clear where this number came > from so, to at least allow for ease of experimentation, this patch makes > the threshold tunable via the Xen

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

>>> On 20.03.17 at 17:48, wrote: > On 03/20/2017 06:40 PM, Jan Beulich wrote: > On 20.03.17 at 17:16, wrote: >>> On 03/20/2017 06:14 PM, Razvan Cojocaru wrote: In any case, back when I've added xc_set_mem_access_multi() I've also

Re: [Xen-devel] [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface

2017-03-20 17:18 GMT+01:00 Wei Liu : > On Mon, Mar 20, 2017 at 09:12:54AM +0100, Felix Schmoll wrote: > > 2017-03-16 17:27 GMT+01:00 Wei Liu : > > > > #undef COMP > > diff --git a/xen/common/kernel.c b/xen/common/kernel.c > > index 4b87c60845..de07ee529b

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On 03/20/2017 06:40 PM, Jan Beulich wrote: On 20.03.17 at 17:16, wrote: >> On 03/20/2017 06:14 PM, Razvan Cojocaru wrote: >>> On 03/20/2017 06:07 PM, Jan Beulich wrote: >>> On 20.03.17 at 10:50, wrote: > ---

[Xen-devel] [PATCH v2] xen: use libxendevice model to restrict operations

This patch adds a command-line option (-xen-domid-restrict) which will use the new libxendevicemodel API to restrict devicemodel operations to the specified domid. This patch also adds a tracepoint to allow successful enabling of the restriction to be monitored. Signed-off-by: Paul Durrant

Re: [Xen-devel] [PATCH v6] xen: Allow a default compiled-in command line using Kconfig

>>> On 20.03.17 at 17:32, wrote: > Added 2 new config entries in common/Kconfig: > CMDLINE and CMDLINE_OVERRIDE > Modifed common/kernel.c:cmdline_parse(). > > The 2 new entries enable an embedded command line to be compiled > in the hypervisor. CMDLINE depends on EXPERT

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

>>> On 20.03.17 at 17:16, wrote: > On 03/20/2017 06:14 PM, Razvan Cojocaru wrote: >> On 03/20/2017 06:07 PM, Jan Beulich wrote: >> On 20.03.17 at 10:50, wrote: --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h

Re: [Xen-devel] [PATCH v2 10/12] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

>>> On 17.03.17 at 07:46, wrote: > --- a/xen/arch/x86/cpu/mcheck/mce.c > +++ b/xen/arch/x86/cpu/mcheck/mce.c > @@ -1546,6 +1546,21 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc) > } > break; > > +case

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On Mon, Mar 20, 2017 at 8:20 AM, Andrew Cooper wrote: > On 20/03/17 09:50, Razvan Cojocaru wrote: > > xc_altp2m_set_mem_access() and xc_set_mem_access() end up doing the same > thing > > in the hypervisor, but the former is a HVMOP and the latter a DOMCTL. > Since > >

Re: [Xen-devel] [PATCH v2 09/12] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

>>> On 17.03.17 at 07:46, wrote: > --- a/xen/include/public/hvm/params.h > +++ b/xen/include/public/hvm/params.h > @@ -259,6 +259,11 @@ > */ > #define HVM_PARAM_VM86_TSS_SIZED 37 > > -#define HVM_NR_PARAMS 38 > +/* Enable MCA capabilities. */ > +#define

[Xen-devel] [PATCH v6] xen: Allow a default compiled-in command line using Kconfig

Added 2 new config entries in common/Kconfig: CMDLINE and CMDLINE_OVERRIDE Modifed common/kernel.c:cmdline_parse(). The 2 new entries enable an embedded command line to be compiled in the hypervisor. CMDLINE depends on EXPERT = "y", and CMDLINE_OVERRIDE depends on CMDLINE != "". If CMDLINE

[Xen-devel] [PATCH] tools/libxc: Drop dombuilder support for PV autotranslate guests

c/s 4045953 "x86/paging: Enforce PG_external == PG_translate == PG_refcounts" in the hypervisor finally prevented the construction of PV autotranslate guests. Remove support for such guests in the domain builder, bailing out with an obvious "no longer supported" message, rather than a more

Re: [Xen-devel] [PATCH 05/11] xen/arm: vpl011: Initialize nr_spis in vgic_init in Xen to atleast 1

On 16 March 2017 at 18:54, Julien Grall wrote: > Hi Bhupinder, > > On 03/16/2017 10:31 AM, Bhupinder Thakur wrote: >> >> On 16 March 2017 at 13:54, Julien Grall wrote: The other option is to reserve a SPI for pl011 at compile time and

Re: [Xen-devel] [PATCH v2 08/12] x86/vmce: enable injecting LMCE to guest on Intel host

>>> On 17.03.17 at 07:46, wrote: > @@ -88,18 +89,31 @@ mc_memerr_dhandler(struct mca_binfo *binfo, > goto vmce_failed; > } > > -if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL || > -

Re: [Xen-devel] [PATCH v2 07/12] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

>>> On 17.03.17 at 07:46, wrote: > --- a/xen/include/public/arch-x86/hvm/save.h > +++ b/xen/include/public/arch-x86/hvm/save.h > @@ -599,6 +599,8 @@ struct hvm_vmce_vcpu { > uint64_t caps; > uint64_t mci_ctl2_bank0; > uint64_t mci_ctl2_bank1; > +

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On 03/20/2017 06:14 PM, Razvan Cojocaru wrote: > On 03/20/2017 06:07 PM, Jan Beulich wrote: > On 20.03.17 at 10:50, wrote: >>> --- a/xen/include/public/memory.h >>> +++ b/xen/include/public/memory.h >>> @@ -444,6 +444,8 @@ struct xen_mem_access_op { >>> /*

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

On 03/20/2017 06:07 PM, Jan Beulich wrote: On 20.03.17 at 10:50, wrote: >> --- a/xen/include/public/memory.h >> +++ b/xen/include/public/memory.h >> @@ -444,6 +444,8 @@ struct xen_mem_access_op { >> /* xenmem_access_t */ >> uint8_t access; >> domid_t

Re: [Xen-devel] [PATCH v2 06/12] x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL

>>> On 17.03.17 at 07:46, wrote: > --- a/xen/arch/x86/cpu/mcheck/mce_intel.c > +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c > @@ -955,3 +955,7 @@ int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, > uint64_t *val) > return 1; > } > > +bool

  1   2   3   >