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

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 nobody is currently using, or has stated intent to use, this functionality specifically as an HVMOP, this patch removes the HVMOP while adding

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

>>> On 20.03.17 at 03:38, wrote: > On Mon, Mar 20, 2017 at 03:18:18AM -0600, Jan Beulich wrote: > On 20.03.17 at 02:59, wrote: >>> On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich wrote: >>> On 15.03.17 at 06:11, wrote:

[Xen-devel] [PATCH v2] x86/emul: Poision the stubs with debug traps

...rather than leaving fragments of old instructions in place. This reduces the chances of something going further-wrong (as the debug trap will be caught and terminate the guest) in a cascade-failure where we end up executing the instruction fragments. Before: (XEN) d2v0 exception 6

[Xen-devel] Ping#2: [PATCH] AMD-Vi: allocate root table on demand

Suravee? Or alternatively, Sherry, is Suravee unavailable for an extended period of time? Jan >>> On 10.03.17 at 17:19, wrote: On 03.03.17 at 15:29, wrote: >> This was my originally intended fix for the AMD side of XSA-207: >> There's no need to

Re: [Xen-devel] [PATCH v2 7/9] x86/shadow: Use the pagewalk reserved bits helpers

>>> On 16.03.17 at 17:31, wrote: > The shadow logic should not create a valid/present shadow of a guest PTE which > contains reserved bits from the guests point of view. It is not guaranteed > that the hardware pagewalk will come to the same conclusion, and raise a >

Re: [Xen-devel] [PATCH v2 9/9] x86/pagewalk: non-functional cleanup

>>> On 16.03.17 at 17:31, wrote: > * Drop trailing whitespace > * Consistently apply Xen style > * Introduce a local variable block > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [xen-unstable test] 106778: tolerable trouble: blocked/broken/fail/pass

flight 106778 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106778/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken in 106770 pass in 106778

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

>>> On 18.03.17 at 07:31, wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -237,4 +237,26 @@ config FAST_SYMBOL_LOOKUP > The only user of this is Live patching. > > If unsure, say Y. > + > +config CMDLINE > + string "Built-in hypervisor

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

> -Original Message- > From: Philippe Mathieu-Daudé [mailto:philippe.mathieu.da...@gmail.com] > On Behalf Of Philippe Mathieu-Daudé > Sent: 17 March 2017 21:21 > To: Paul Durrant ; qemu-de...@nongnu.org; xen- > de...@lists.xenproject.org > Cc: Anthony Perard

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

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

Re: [Xen-devel] [PATCH 1/7] x86/viridian: update to version 5.0a of the specification

>>> On 17.03.17 at 10:57, wrote: > @@ -48,20 +48,60 @@ > /* Viridian Hypercall Flags. */ > #define HV_FLUSH_ALL_PROCESSORS 1 > > -/* Viridian CPUID 403, Viridian MSR availability. */ > -#define CPUID3A_MSR_TIME_REF_COUNT (1 << 1) > -#define CPUID3A_MSR_APIC_ACCESS

Re: [Xen-devel] [PATCH v2 4/9] x86/pagewalk: Clean up guest_supports_* predicates

>>> On 16.03.17 at 17:31, wrote: > Switch them to returning bool, and taking const parameters. > > Rename guest_supports_superpages() to guest_supports_l2_superpages() to > indicate which level of pagetables it is actually referring to, and rename >

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

>>> On 20.03.17 at 02:59, wrote: > On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich wrote: > On 15.03.17 at 06:11, wrote: >>> +if ( iommu_intpost ) >>> +{ >>> +vcpu = pi_find_dest_vcpu(d, dest, dest_mode, delivery_mode,

Re: [Xen-devel] [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI

On Mon, Mar 20, 2017 at 03:18:18AM -0600, Jan Beulich wrote: On 20.03.17 at 02:59, wrote: >> On Fri, Mar 17, 2017 at 04:43:08AM -0600, Jan Beulich wrote: >> On 15.03.17 at 06:11, wrote: +if ( iommu_intpost ) +{ +

[Xen-devel] [PATCH 6/8] tools/insn-fuzz: Accept fuzzing input on stdin

This is rather faster for afl-fuzz to arrange than using an explicit file parameter. Also update the README to recommend using a tmpfs for findings_dir which reduces disk load and is more performant. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] [PATCH 4/8] tools/insn-fuzz: Use shorter filenames

Amongst other things, these tab complete more easily. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Ian Jackson CC: Wei Liu --- .gitignore | 2 +-

[Xen-devel] [PATCH 1/8] tools/fuzz: Remove .d files in clean

Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Ian Jackson CC: Wei Liu --- tools/fuzz/libelf/Makefile | 2 +- tools/fuzz/x86_instruction_emulator/Makefile | 2 +- 2 files

[Xen-devel] [PATCH 5/8] tools/insn-fuzz: Use getopt() for parsing the command line

Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Ian Jackson CC: Wei Liu --- tools/fuzz/x86_instruction_emulator/afl-harness.c | 40 +++ 1 file changed, 34 insertions(+), 6

[Xen-devel] [PATCH 0/8] Fuzzing misc bugfix and performance improvements

This series is a couple of bugfixes, but is mainly a set of performance improvements to using the AFL test harness. This series increases the performance as reported by afl-fuzz from 6k execs/s to 38k execs/s, or more than 6 times faster. Andrew Cooper (8): tools/fuzz: Remove .d files in clean

[Xen-devel] [PATCH 3/8] tools/fuzz: Include LLVMFuzzerTestOneInput() in the generated .a

Otherwise they are not suitable for use with libfuzz. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Ian Jackson CC: Wei Liu --- tools/fuzz/libelf/Makefile | 2 +-

[Xen-devel] [PATCH 2/8] tools/fuzz: Use $(CC) for linking the harnesses

This is necessary to make use of compiler features such as UBSAN. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Ian Jackson CC: Wei Liu --- tools/fuzz/libelf/Makefile | 1 +

[Xen-devel] [PATCH 7/8] tools/insn-fuzz: Make use of LLVMFuzzerInitialize()

libfuzz can perform one-time initialisation by calling LLVMFuzzerInitialize(). Move emul_test_init() into this, to avoid repeating it on every LLVMFuzzerTestOneInput() call. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Ian Jackson

[Xen-devel] [PATCH 8/8] tools/insn-fuzz: Support AFL's afl-clang-fast mode

AFL has an alternative llvm-base instrumentation mode, which has much lower overhead than the traditional afl-gcc. One extra ability is to chose exactly where the master process gets initialised to, before being forked for testing. This point is chosen after the call to LLVMFuzzerInitialize(),

[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

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

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

Re: [Xen-devel] [PATCH 0/8] Fuzzing misc bugfix and performance improvements

On Mon, Mar 20, 2017 at 11:19:37AM +, Andrew Cooper wrote: > This series is a couple of bugfixes, but is mainly a set of performance > improvements to using the AFL test harness. This series increases the > performance as reported by afl-fuzz from 6k execs/s to 38k execs/s, or more > than 6

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

On 03/20/2017 04:20 PM, 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 >> nobody is currently using, or has stated

Re: [Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

On Mon, Mar 20, 2017 at 04:32:09PM +0100, Jiri Slaby wrote: > On 03/20/2017, 02:32 PM, Josh Poimboeuf wrote: > > On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote: > >> This is a start of series to cleanup macros used for starting functions, > >> data, globals etc. across x86. When we

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

[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 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 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote: > This is a start of series to cleanup macros used for starting functions, > data, globals etc. across x86. When we have all this sorted out, this > will help to inject DWARF unwinding info by objtool later. > > The goal is forcing

Re: [Xen-devel] [PATCH v2 4/9] x86/pagewalk: Clean up guest_supports_* predicates

On 20/03/17 08:45, Jan Beulich wrote: On 16.03.17 at 17:31, wrote: >> Switch them to returning bool, and taking const parameters. >> >> Rename guest_supports_superpages() to guest_supports_l2_superpages() to >> indicate which level of pagetables it is actually

Re: [Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

On Mon, Mar 20, 2017 at 04:40:49AM -0600, Jan Beulich wrote: > >>> On 16.03.17 at 18:54, wrote: > > @@ -154,11 +155,11 @@ static void __init parse_dom0_nodes(const char *s) > > } > > custom_param("dom0_nodes", parse_dom0_nodes); > > > > -static cpumask_t __initdata

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

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

[Xen-devel] [PATCH v3 3/5] x86: split PV dom0 builder to pv/dom0_builder.c

Long term we want to be able to disentangle PV and HVM code. Move the PV domain builder to a dedicated file. This in turn requires exposing a few functions and variables via a new header dom0_build.h. These functions and variables are now prefixed with "dom0_" if they weren't already so. No

[Xen-devel] [PATCH v3 5/5] x86: clean up header files in dom0_build.c

Remove the ones that are no longer needed and sort them. Signed-off-by: Wei Liu Acked-by: Jan Beulich --- xen/arch/x86/dom0_build.c | 40 ++-- 1 file changed, 6 insertions(+), 34 deletions(-) diff --git

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

On Mon, Mar 20, 2017 at 12:38:41PM +0100, Paolo Bonzini wrote: > > > On 20/03/2017 03:40, Lan Tianyu wrote: > >>> Xen only supports emulated I440 and so we enable vIOMMU with emulated > >>> I440 chipset. This works on Linux and Windows guest. > >> Any plans to change this? Why is Xen not able

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

On Fri, Mar 17, 2017 at 07:27:00PM +0800, Lan Tianyu wrote: > This patchset is to introduce vIOMMU framework and add virtual VTD's > interrupt remapping support according "Xen virtual IOMMU high level > design doc V3"(https://lists.xenproject.org/archives/html/xen-devel/ > 2016-11/msg01391.html).

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

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 > nobody is currently using, or has stated intent to use, this functionality > specifically as an

[Xen-devel] [linux-linus test] 106781: regressions - trouble: blocked/broken/fail/pass

flight 106781 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106781/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair4 host-install/dst_host(4) broken REGR. vs. 59254

Re: [Xen-devel] [PATCH v3 3/5] x86: split PV dom0 builder to pv/dom0_builder.c

On 20/03/17 14:14, Wei Liu wrote: > Long term we want to be able to disentangle PV and HVM code. Move the PV > domain builder to a dedicated file. > > This in turn requires exposing a few functions and variables via a new > header dom0_build.h. These functions and variables are now prefixed with >

Re: [Xen-devel] [PATCH v4 04/14] golang/xenlight: Implement libxl_domain_info and libxl_domain_unpause

On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote: > Add calls for the following host-related functionality: > - libxl_domain_info > - libxl_domain_unpause > > Include Golang version for the libxl_domain_info as > DomainInfo. > > Signed-off-by: George Dunlap

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

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

>>> 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 domid; > +uint16_t view_id; > +uint16_t

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] 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 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] 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 2/7] x86/viridian: fix xen-hvmcrash when vp_assist page is present

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Paul Durrant > Sent: 20 March 2017 11:50 > To: 'Jan Beulich' > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [Xen-devel]

Re: [Xen-devel] [PATCH v2 4/9] x86/pagewalk: Clean up guest_supports_* predicates

>>> On 20.03.17 at 14:36, wrote: > On 20/03/17 08:45, Jan Beulich wrote: >> Also I'm still not really happy with the guest_supports_ prefixes >> for this and its L2 counterpart: The question here isn't whether the >> guest supports it (we can't know whether it does),

Re: [Xen-devel] [PATCH v2] AMD-Vi: allocate root table on demand

On 3/20/17 20:55, Jan Beulich wrote: This was my originally intended fix for the AMD side of XSA-207: There's no need to unconditionally allocate the root table, and with that there's then also no way to leak it when a guest has no devices assigned. Signed-off-by: Jan Beulich

[Xen-devel] [PATCH v3 4/5] x86: split PVH dom0 builder to hvm/dom0_build.c

Long term we want to be able to disentangle PV and HVM code. Move the PVH domain builder to a dedicated file. Lift function declarations to dom0_build.h and rename them when necessary. No functional change. Signed-off-by: Wei Liu Acked-by: Roger Pau Monné

[Xen-devel] [PATCH v3 0/5] Refactor x86 dom0 builder

Wei Liu (5): x86: rename domain_build.c to dom0_build.c x86: modify setup_dom0_vcpu to use dom0_cpus internally x86: split PV dom0 builder to pv/dom0_builder.c x86: split PVH dom0 builder to hvm/dom0_build.c x86: clean up header files in dom0_build.c xen/arch/x86/Makefile|

[Xen-devel] [PATCH v3 1/5] x86: rename domain_build.c to dom0_build.c

To reflect the true nature of this file. No functional change. Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper --- xen/arch/x86/Makefile | 2 +- xen/arch/x86/{domain_build.c => dom0_build.c} | 2 +- 2 files changed, 2

[Xen-devel] [PATCH v3 2/5] x86: modify setup_dom0_vcpu to use dom0_cpus internally

We will later move dom0 builders to different directories. To avoid the need of making dom0_cpus visible outside dom0_builder.c, modify setup_dom0_vcpus to cycle through dom0_cpus internally instead of relying on the callers to do that. No functional change. Signed-off-by: Wei Liu

Re: [Xen-devel] [PATCH v3 2/5] x86: modify setup_dom0_vcpu to use dom0_cpus internally

On 20/03/17 14:14, Wei Liu wrote: > We will later move dom0 builders to different directories. To avoid the > need of making dom0_cpus visible outside dom0_builder.c, modify > setup_dom0_vcpus to cycle through dom0_cpus internally instead of > relying on the callers to do that. > > No functional

Re: [Xen-devel] Wondering about cirris and stdvga

> -Original Message- > From: Roger Pau Monne > Sent: 20 March 2017 14:14 > To: Konrad Rzeszutek Wilk > Cc: Dario Faggioli ; Ian Jackson > ; Pasi Kärkkäinen ; Stefano Stabellini >

Re: [Xen-devel] [PATCH v2 05/12] x86/mce_intel: detect and enable LMCE on Intel host

>>> 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 > @@ -29,6 +29,9 @@ boolean_param("mce_fb", mce_force_broadcast); > > static int __read_mostly nr_intel_ext_msrs; > > +/* If mce_force_broadcast

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

>>> On 20.03.17 at 13:51, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 March 2017 12:26 >> >>> On 17.03.17 at 10:57, wrote: >> > --- a/xen/arch/x86/hvm/viridian.c >> > +++ b/xen/arch/x86/hvm/viridian.c >> > @@ -22,6 +22,12

Re: [Xen-devel] [PATCH 7/7] x86/viridian: implement the crash MSRs

>>> On 20.03.17 at 13:48, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 20 March 2017 12:38 >> >>> On 17.03.17 at 10:57, wrote: >> > --- a/xen/include/asm-x86/hvm/viridian.h >> > +++ b/xen/include/asm-x86/hvm/viridian.h >> > @@

[Xen-devel] [PATCH v2] AMD-Vi: allocate root table on demand

This was my originally intended fix for the AMD side of XSA-207: There's no need to unconditionally allocate the root table, and with that there's then also no way to leak it when a guest has no devices assigned. Signed-off-by: Jan Beulich --- v2: Add AMD_IOMMU_DEBUG() +

Re: [Xen-devel] Wondering about cirris and stdvga

On Fri, Mar 17, 2017 at 10:19:47AM -0400, Konrad Rzeszutek Wilk wrote: > On Fri, Nov 25, 2016 at 07:17:31PM +0100, Dario Faggioli wrote: > > On Mon, 2016-11-21 at 10:04 +0100, Dario Faggioli wrote: > > > On Sat, 2016-11-19 at 12:56 +0200, Pasi Kärkkäinen wrote: > > > > 2) It'd good to create an

Re: [Xen-devel] [PATCH v2 04/12] x86/mce: handle LMCE locally

>>> On 17.03.17 at 07:46, wrote: > @@ -52,8 +52,8 @@ void mce_barrier_exit(struct mce_softirq_barrier *bar) > } > } > > -void mce_barrier(struct mce_softirq_barrier *bar) > +void mce_barrier(struct mce_softirq_barrier *bar, bool nowait) > { > -

Re: [Xen-devel] [PATCH v2 2/4] x86: split PV dom0 builder to pv/dom0_builder.c

>>> On 20.03.17 at 14:10, wrote: > On Mon, Mar 20, 2017 at 04:40:49AM -0600, Jan Beulich wrote: >> >>> On 16.03.17 at 18:54, wrote: >> > @@ -154,11 +155,11 @@ static void __init parse_dom0_nodes(const char *s) >> > } >> > custom_param("dom0_nodes",

Re: [Xen-devel] [PATCH v2 3/6] mm: Use statically defined locking order

On 08/03/17 17:46, Ross Lagerwall wrote: > Instead of using a locking order based on line numbers which interacts > poorly with trying to create a live patch, statically define the locking > order. > > Signed-off-by: Ross Lagerwall > Reviewed-by: Dario Faggioli

Re: [Xen-devel] [PATCH 2/7] x86/viridian: fix xen-hvmcrash when vp_assist page is present

>>> On 20.03.17 at 14:42, wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Paul >> Durrant >> Sent: 20 March 2017 11:50 >> > From: Jan Beulich [mailto:jbeul...@suse.com] >> > Sent: 20 March 2017 11:36 >> > >>> On 17.03.17 at 10:57,

Re: [Xen-devel] Wondering about cirris and stdvga

On Mon, Mar 20, 2017 at 02:21:50PM +, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 20 March 2017 14:14 > > To: Konrad Rzeszutek Wilk > > Cc: Dario Faggioli ; Ian Jackson > > ;

[Xen-devel] [PATCH 2/2] Add vlapic timer checks

Signed-off-by: Anthony PERARD --- tests/vlapic-timer/Makefile | 9 +++ tests/vlapic-timer/main.c | 131 2 files changed, 140 insertions(+) create mode 100644 tests/vlapic-timer/Makefile create mode 100644

[Xen-devel] [PATCH 1/2] Import apicdef.h from xen.git

Have only changed the value of APIC_BASE. Signed-off-by: Anthony PERARD --- arch/x86/include/arch/apicdef.h | 392 1 file changed, 392 insertions(+) create mode 100644 arch/x86/include/arch/apicdef.h diff --git

[Xen-devel] [PATCH 0/2] Testing vlapic timer

Hi, This list of check should work on baremetal, but Xen emulation vlapic does not behave like baremetal, so this XTF tests would fail at first, until a fix for Xen that I'm working on is pushed. I don't check TSC deadline yet, but I will give a look as well. For now, it's only one-shot and

Re: [Xen-devel] [PATCH 7/7] x86/viridian: implement the crash MSRs

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2017 13:29 > To: Paul Durrant > Cc: Andrew Cooper ; Ian Jackson > ; Wei Liu ; xen- >

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

On 20/03/2017 15:17, Roger Pau Monné wrote: >>> Hi Paolo: >>> Thanks for review. For Xen side, we won't reuse Intel IOMMU device model >>> in Qemu and create counterpart in Xen hypervisor. The reasons are >>> 1) Avoid round trips between Qemu and Xen hypervisor >>> 2) Ease of integration with

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

Re: [Xen-devel] [PATCH v3 4/5] x86: split PVH dom0 builder to hvm/dom0_build.c

On 20/03/17 14:14, Wei Liu wrote: > Long term we want to be able to disentangle PV and HVM code. Move > the PVH domain builder to a dedicated file. > > Lift function declarations to dom0_build.h and rename them when > necessary. > > No functional change. > > Signed-off-by: Wei Liu

Re: [Xen-devel] [PATCH 1/2] Import apicdef.h from xen.git

On Mon, Mar 20, 2017 at 02:38:45PM +, Anthony PERARD wrote: > Have only changed the value of APIC_BASE. > > Signed-off-by: Anthony PERARD > --- > arch/x86/include/arch/apicdef.h | 392 > > 1 file changed, 392 insertions(+)

Re: [Xen-devel] [PATCH v3 2/5] x86: modify setup_dom0_vcpu to use dom0_cpus internally

On Mon, Mar 20, 2017 at 09:19:43AM -0600, Jan Beulich wrote: > >>> On 20.03.17 at 15:14, wrote: > > @@ -1155,8 +1157,10 @@ static int __init construct_dom0_pv( > > cpu = v->processor; > > for ( i = 1; i < d->max_vcpus; i++ ) > > { > > -cpu =

[Xen-devel] [PATCH] cs-adjust-flight: Work properly on db transaction retry

The variable @changes is eaten during processing. So on db retry, there would be changes missing. (When creating a new flight, this would often mean a flight with no jobs, which cannot be executed.) CC: Roger Pau Monné Signed-off-by: Ian Jackson

Re: [Xen-devel] [PATCH v3 2/5] x86: modify setup_dom0_vcpu to use dom0_cpus internally

>>> On 20.03.17 at 15:14, wrote: > @@ -1155,8 +1157,10 @@ static int __init construct_dom0_pv( > cpu = v->processor; > for ( i = 1; i < d->max_vcpus; i++ ) > { > -cpu = cpumask_cycle(cpu, _cpus); > -setup_dom0_vcpu(d, i, cpu); > +struct

Re: [Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

On 03/20/2017, 02:32 PM, Josh Poimboeuf wrote: > On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote: >> This is a start of series to cleanup macros used for starting functions, >> data, globals etc. across x86. When we have all this sorted out, this >> will help to inject DWARF unwinding

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

On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote: > Add calls for the following host-related functionality: > - libxl_get_max_cpus > - libxl_get_online_cpus > - libxl_get_max_nodes > - libxl_get_free_memory > - libxl_get_physinfo > - libxl_get_version_info > > Include

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

On 03/20/2017 04:20 PM, 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 >> nobody is currently using, or has stated

Re: [Xen-devel] [PATCH v4 02/14] golang/xenlight: Add error constants and standard handling

On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas wrote: > Create error type Errorxl for throwing proper xenlight > errors. > > Update Ctx functions to throw Errorxl errors. > > Signed-off-by: Ronald Rojas FYI, My response to v2 meant to indicate that once

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

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

<    1   2   3   >