[Xen-devel] [PATCH v4 17/26] x86/pv: Provide custom cpumasks for PV domains

And use them in preference to cpumask_defaults on context switch. HVM domains must not be masked (to avoid interfering with cpuid calls within the guest), so always lazily context switch to the host default. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v4 16/26] x86/cpu: Context switch cpuid masks and faulting state in context_switch()

A single ctxt_switch_levelling() function pointer is provided (defaulting to an empty nop), which is overridden in the appropriate $VENDOR_init_levelling(). set_cpuid_faulting() is made private and included within intel_ctxt_switch_levelling(). One functional change is that the faulting

[Xen-devel] [PATCH v4 24/26] tools/libxc: Wire a featureset through to cpuid policy logic

Later changes will cause the cpuid generation logic to seed their information from a featureset. This patch adds the infrastructure to specify a featureset, and will obtain the appropriate default from Xen if omitted. Signed-off-by: Andrew Cooper Acked-by: Wei Liu

[Xen-devel] [PATCH v4 18/26] x86/domctl: Update PV domain cpumasks when setting cpuid policy

This allows PV domains with different featuresets to observe different values from a native cpuid instruction, on supporting hardware. It is important to leak the host view of HTT and CMP_LEGACY through to guests, even though they could be hidden. These flags affect how to interpret other cpuid

[Xen-devel] [PATCH v4 21/26] tools/libxc: Use public/featureset.h for cpuid policy generation

Rather than having a different local copy of some of the feature definitions. Modify the xc_cpuid_x86.c cpumask helpers to appropriate truncate the new values. As some of the feature have been renamed in the public API, similar renames are made here. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH v4 23/26] tools: Utility for dealing with featuresets

It is able to reports the current featuresets; both the static masks and dynamic featuresets from Xen, or to decode an arbitrary featureset into `/proc/cpuinfo` style strings. Signed-off-by: Andrew Cooper Acked-by: Wei Liu --- CC: Ian Jackson

[Xen-devel] [PATCH v4 19/26] xen+tools: Export maximum host and guest cpu featuresets via SYSCTL

And provide stubs for toolstack use. Signed-off-by: Andrew Cooper Acked-by: Wei Liu Acked-by: David Scott Acked-by: Jan Beulich --- CC: Tim Deegan v2: * Rebased to use libxencall * Improve

[Xen-devel] [PATCH v4 15/26] x86/cpu: Rework Intel masking/faulting setup

This patch is best reviewed as its end result rather than as a diff, as it rewrites almost all of the setup. On the BSP, cpuid information is used to evaluate the potential available set of masking MSRs, and they are unconditionally probed, filling in the availability information and hardware

Re: [Xen-devel] [PATCH 02/16] xen: sched: add .init_pdata hook to the scheduler interface

On 18/03/16 19:04, Dario Faggioli wrote: > with the purpose of decoupling the allocation phase and > the initialization one, for per-pCPU data of the schedulers. > > This makes it possible to perform the initialization later > in the pCPU bringup/assignement process, when more information > (for

Re: [Xen-devel] Call for nominations for new Hypervisor subproject maintainers and committers

Hi everyone, I just wanted to let you know that this hasn't dropped off my radar. We do have a shortlist of people now, and I will need to reach out to people who were nominated (and may not know they were). However due to Easter, the time-frame may slip by a week. > On 24 Feb 2016, at

Re: [Xen-devel] [PATCH 03/16] xen: sched: make implementing .alloc_pdata optional

On 18/03/16 19:04, Dario Faggioli wrote: > The .alloc_pdata scheduler hook must, before this change, > be implemented by all schedulers --even those ones that > don't need to allocate anything. > > Make it possible to just use the SCHED_OP(), like for > the other hooks, by using ERR_PTR() and

Re: [Xen-devel] [PATCH 04/16] xen: sched: implement .init_pdata in all schedulers

On 22/03/16 08:03, Juergen Gross wrote: > On 18/03/16 20:04, Dario Faggioli wrote: >> by borrowing some of the code of .alloc_pdata, i.e., >> the bits that perform initializations, leaving only >> actual allocations in there, when any, which is the >> case for Credit1 and RTDS. >> >> On the other

[Xen-devel] [PATCH] tools/python/xc: fix tmem_control parameter parsing

There should be 6 instead of 7 arguments now for tmem_control(). Signed-off-by: Zhigang Wang --- tools/python/xen/lowlevel/xc/xc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/python/xen/lowlevel/xc/xc.c

[Xen-devel] [PATCH v4 26/26] tools/libxc: Calculate xstate cpuid leaf from guest information

It is unsafe to generate the guests xstate leaves from host information, as it prevents the differences between hosts from being hidden. In addition, some further improvements and corrections: - don't discard the known flags in sub-leaves 2..63 ECX - zap sub-leaves beyond 62 - zap all bits in

[Xen-devel] [PATCH v4 11/26] xen/x86: Improvements to in-hypervisor cpuid sanity checks

Currently, {pv,hvm}_cpuid() has a large quantity of essentially-static logic for modifying the features visible to a guest. A lot of this can be subsumed by {pv,hvm}_featuremask, which identify the features available on this hardware which could be given to a PV or HVM guest. This is a step in

[Xen-devel] [PATCH v4 13/26] x86/cpu: Sysctl and common infrastructure for levelling context switching

A toolstack needs to know how much control Xen has over the visible cpuid values in PV guests. Provide an explicit mechanism to query what Xen is capable of. This interface will currently report no capabilities. This change is scaffolding for future patches, which will introduce detection and

[Xen-devel] [PATCH v4 25/26] tools/libxc: Use featuresets rather than guesswork

It is conceptually wrong to base a VM's featureset on the features visible to the toolstack which happens to construct it. Instead, the featureset used is either an explicit one passed by the toolstack, or the default which Xen believes it can give to the guest. Collect all the feature

[Xen-devel] [PATCH v4 12/26] x86/cpu: Move set_cpumask() calls into c_early_init()

Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the commandline-provided masks would take effect in Xen's view of the features. As the masks got applied after the query for features, the redundant call to generic_identify() would clobber the pre-masking feature information

[Xen-devel] [PATCH v4 10/26] xen/x86: Improve disabling of features which have dependencies

APIC and XSAVE have dependent features, which also need disabling if Xen chooses to disable a feature. Use setup_clear_cpu_cap() rather than clear_bit(), as it takes care of dependent features as well. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v4 22/26] tools/libxc: Expose the automatically generated cpu featuremask information

Signed-off-by: Andrew Cooper Acked-by: Wei Liu --- CC: Ian Jackson New in v2 --- tools/libxc/Makefile | 9 ++ tools/libxc/include/xenctrl.h | 14 tools/libxc/xc_cpuid_x86.c| 75

[Xen-devel] [PATCH v4 09/26] xen/x86: Clear dependent features when clearing a cpu cap

When clearing a cpu cap, clear all dependent features. This avoids having a featureset with intermediate features disabled, but leaf features enabled. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- v3: * Style fixes. Use

[Xen-devel] [PATCH v4 14/26] x86/cpu: Rework AMD masking MSR setup

This patch is best reviewed as its end result rather than as a diff, as it rewrites almost all of the setup. On the BSP, cpuid information is used to evaluate the potential available set of masking MSRs, and they are unconditionally probed, filling in the availability information and hardware

[Xen-devel] [PATCH v4 20/26] tools/libxc: Modify bitmap operations to take void pointers

The type of the pointer to a bitmap is not interesting; it does not affect the representation of the block of bits being pointed to. Make the libxc functions consistent with those in Xen, so they can work just as well with 'unsigned int *' based bitmaps. As part of doing so, change the

Re: [Xen-devel] [PATCH v2] xen/arm64: correctly emulate the {w, x}zr registers

Hi Stefano, On 22/02/16 17:38, Stefano Stabellini wrote: On Fri, 15 Jan 2016, Ian Campbell wrote: I read the patch and looks good to me. You can add my Reviewed-by: Stefano Stabellini I have a couple of minor comments, which you can ignore or address as you

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 12:25, Andrew Cooper wrote: > On 23/03/16 11:18, David Vrabel wrote: >> On 23/03/16 11:12, Andrew Cooper wrote: >>> On 23/03/16 10:59, David Vrabel wrote: On 23/03/16 10:55, Andrew Cooper wrote: > On 23/03/16 10:52, Juergen Gross wrote: >> On 23/03/16 11:32, David Vrabel

Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?

On Wed, Mar 23, 2016 at 06:24:40PM +0100, Dirk Behme wrote: > Hi, Hey, CC-ing the ARM MAINTAINERs. > > trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I get > [1] and then its hanging there. > > I'd guess that it hangs due to missing timer interrupt, maybe missing >

Re: [Xen-devel] [PATCH 03/16] xen: sched: make implementing .alloc_pdata optional

On 21/03/16 14:22, Jan Beulich wrote: On 18.03.16 at 20:04, wrote: >> --- a/xen/include/xen/sched-if.h >> +++ b/xen/include/xen/sched-if.h >> @@ -9,6 +9,7 @@ >> #define __XEN_SCHED_IF_H__ >> >> #include >> +#include >> >> /* A global pointer to the initial

Re: [Xen-devel] Outreachy bite-sized tasks

Hey, please, do not use HTML for emails to this list. On Wed, 2016-03-23 at 17:38 +0100, Paulina Szubarczyk wrote: > Hi,  > > Thank you for the proposed tasks. I would like to work on the second > one,  > fixing the return codes in xl. > I just wanted to say that, since I've done (and

Re: [Xen-devel] [PATCH 09/16] xen: sched: close potential races when switching scheduler to CPUs

On 18/03/16 19:05, Dario Faggioli wrote: > by using the sched_switch hook that we have introduced in > the various schedulers. > > The key is to let the actual switch of scheduler and the > remapping of the scheduler lock for the CPU (if necessary) > happen together (in the same critical section)

Re: [Xen-devel] Interested to participate in Outreachy Program

On 3/23/16 11:34 AM, sabiya kazi wrote: > Hi Doug, > Can you have a look at patch and let me know if everything > is correct, I think things are good. > > I would also like to have a word with you for deciding timeline for > project. Meantime, I have started reading stuff about rust language. >

[Xen-devel] [PATCH v3 5/7] x86/mtrr: Fix PAT init handling when MTRR is disabled

get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled. This results in calling pat_init() on BSP only since APs do not call pat_init() when MTRR is disabled. This inconsistency between BSP and APs leads to undefined behavior. Make BSP's calling condition to pat_init() consistent with

[Xen-devel] [PATCH v3 1/7] x86/mm/pat: Add support of non-default PAT MSR setting

In preparation for fixing a regression caused by 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")', PAT needs to support a case that PAT MSR is initialized with a non-default value. When pat_init() is called and PAT is disabled, it initializes PAT table with the BIOS default

[Xen-devel] [PATCH v3 7/7] x86/pat: Document PAT initialization

Update PAT documentation to describe how PAT is initialized under various configurations. Signed-off-by: Toshi Kani Cc: Borislav Petkov Cc: Luis R. Rodriguez Cc: Juergen Gross Cc: Ingo Molnar Cc: H. Peter

[Xen-devel] [PATCH v3 2/7] x86/mm/pat: Add pat_disable() interface

In preparation for fixing a regression caused by 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")', PAT needs to provide an interface that prevents the OS from initializing the PAT MSR. PAT MSR initialization must be done on all CPUs using the specific sequence of operations

[Xen-devel] [PATCH v3 3/7] x86/mm/pat: Replace cpu_has_pat with boot_cpu_has

Borislav Petkov wrote: > Please use on init paths boot_cpu_has(X86_FEATURE_PAT) and on fast > paths static_cpu_has(X86_FEATURE_PAT). No more of that cpu_has_XXX > ugliness. Replace the use of cpu_has_pat on init paths with boot_cpu_has(). Suggested-by: Borislav Petkov

[Xen-devel] [PATCH v3 4/6] x86/mtrr: Fix Xorg crashes in Qemu sessions

A Xorg failure on qemu32 was reported as a regression [1] caused by 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'. This patch fixes this regression. Negative effects of this regression were the following two failures [2] in Xorg on QEMU with QEMU CPU model "qemu32" (-cpu

[Xen-devel] [PATCH v3 6/7] x86/xen, pat: Remove PAT table init code from Xen

Xen supports PAT without MTRRs for its guests. In order to enable WC attribute, it was necessary for xen_start_kernel() to call pat_init_cache_modes() to update PAT table before starting guest kernel. Now that the kernel initializes PAT table to the BIOS handoff state when MTRR is disabled, this

[Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes

A Xorg failure on qemu32 was reported as a regression [1] caused by 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'. This patch-set fixes the regression. Negative effects of this regression were two failures [2] in Xorg on QEMU with QEMU CPU model "qemu32" (-cpu qemu32),

Re: [Xen-devel] [PATCH v4 11/34] xsplice: Design document

On Wed, Mar 23, 2016 at 05:18:39AM -0600, Jan Beulich wrote: > >>> On 15.03.16 at 18:56, wrote: > > +### XEN_SYSCTL_XSPLICE_LIST (2) > > + > > +Retrieve an array of abbreviated status and names of payloads that are > > loaded in the > > +hypervisor. > > + > > +The caller

Re: [Xen-devel] [PATCH v2 3/6] x86/mtrr: Fix Xorg crashes in Qemu sessions

On Wed, 2016-03-23 at 09:53 -0600, Toshi Kani wrote: > On Wed, 2016-03-23 at 09:44 +0100, Borislav Petkov wrote: > > On Tue, Mar 22, 2016 at 03:53:30PM -0600, Toshi Kani wrote: > > > Yes. I had to remove this number since checkpatch complained that I > > > needed to quote the whole patch tile

[Xen-devel] [PATCH] Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483

7c8f3483 introduced a break within a loop in netfront.c such that cons and nr_consumed were no longer always being incremented. The offset at cons will be processed multiple times with the break in place. Remove the break and re-add "some !=0" in the loop for HAVE_LIBC. Signed-off-by: Sarah

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

flight 87027 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/87027/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 86491

Re: [Xen-devel] [PATCH v4 11/34] xsplice: Design document

> diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown > index 6aa5a27..8252e6c 100644 > --- a/docs/misc/xsplice.markdown > +++ b/docs/misc/xsplice.markdown > @@ -487,7 +487,9 @@ hypervisor. > The caller provides: > > * `version`. Initially (on first hypercall) *MUST* be zero.

Re: [Xen-devel] [PATCH 3/3] Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

>>> On 22.03.16 at 18:51, wrote: >> From: George Dunlap [mailto:george.dun...@citrix.com] >> Sent: 22 March 2016 17:27 >> There's not much documentation in the code about how this is expected to >> be used. >> >> For instance, having separate flags seems to imply that

[Xen-devel] [libvirt test] 86994: tolerable FAIL - PUSHED

flight 86994 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/86994/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 10:25, Jan Beulich wrote: On 23.03.16 at 11:14, wrote: >> 7. Report type according to features found (this is a little bit >>ugly: we have to rely on the current hypervisor implementation >>regarding the bits set for the different guest types). > > Well,

Re: [Xen-devel] [PATCH 3/3] Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

On 23/03/16 09:22, Jan Beulich wrote: On 22.03.16 at 18:51, wrote: >>> From: George Dunlap [mailto:george.dun...@citrix.com] >>> Sent: 22 March 2016 17:27 >>> There's not much documentation in the code about how this is expected to >>> be used. >>> >>> For instance,

Re: [Xen-devel] [V5] x86/xsaves: fix overwriting between non-lazy/lazy xsaves

On Wed, Mar 23, 2016 at 04:21:32AM -0600, Jan Beulich wrote: > >>> On 23.03.16 at 07:14, wrote: > > But for hvm_vcpu_reset_state(), I think we should deleting the code > > initializing the xcomp_bv as said below. > >> For hvm_vcpu_reset_state(), we should depend on

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 10:59, David Vrabel wrote: > On 23/03/16 10:55, Andrew Cooper wrote: >> On 23/03/16 10:52, Juergen Gross wrote: >>> On 23/03/16 11:32, David Vrabel wrote: On 23/03/16 10:25, Jan Beulich wrote: On 23.03.16 at 11:14, wrote: >> 7. Report type according

Re: [Xen-devel] [PATCH v4 07/34] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables

>>> On 23.03.16 at 12:17, wrote: > Hi Jan, > > On 23/03/16 08:19, Jan Beulich wrote: > On 22.03.16 at 21:18, wrote: >>> +symbols_lookup_t *symbols_lookup; >>> + >>> +struct { >>> +const struct bug_frame *bugs; /* The pointer to

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 10:10, Jan Beulich wrote: On 23.03.16 at 08:50, wrote: >> xen-detect always thinks a domU is running as HVM guest as the cpuid >> instruction used to identify a Xen guest will always work. >> >> In order to identify a pv guest first try the pv special case of >>

Re: [Xen-devel] [PATCH 3/3] Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

Thanks, Jan. On 3/23/2016 5:22 PM, Jan Beulich wrote: On 22.03.16 at 18:51, wrote: From: George Dunlap [mailto:george.dun...@citrix.com] Sent: 22 March 2016 17:27 There's not much documentation in the code about how this is expected to be used. For instance, having

Re: [Xen-devel] [V5] x86/xsaves: fix overwriting between non-lazy/lazy xsaves

>>> On 23.03.16 at 07:14, wrote: > On Wed, Mar 23, 2016 at 10:02:24AM +0800, Shuai Ruan wrote: > But for hvm_vcpu_reset_state(), I think we should deleting the code > initializing the xcomp_bv as said below. >> For hvm_vcpu_reset_state(), we should depend on whether

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 10:14, Juergen Gross wrote: > On 23/03/16 10:29, Jan Beulich wrote: > On 23.03.16 at 10:19, wrote: >>> On 23/03/16 10:10, Jan Beulich wrote: >>> On 23.03.16 at 08:50, wrote: > xen-detect always thinks a domU is running as HVM guest as the

Re: [Xen-devel] [PATCH v2 0/9] tools: Allow HVM domains emulated access to disks provided by hotplug scripts

On 23/03/16 10:10, Roger Pau Monné wrote: > On Mon, 21 Mar 2016, George Dunlap wrote: > >> In order for HVM domains to provide emulated access to disks provided >> by hotplug scripts, qemu needs access to a "cooked" version of the >> disk. In the case of hotplug scripts, this "cooked" version is

Re: [Xen-devel] [PATCH v6 18/22] arm/acpi: Permit MMIO access of Xen unused devices for Dom0

Hi Shannon, On 17/03/16 09:41, Shannon Zhao wrote: From: Shannon Zhao Firstly it permits full MMIO capabilities for Dom0. Then deny MMIO access of Xen used devices, such as UART, GIC, SMMU. Currently, it only denies the MMIO access of UART and GIC regions. For other

Re: [Xen-devel] [PATCH 1/3] xenalyze: handle DOM0 operaions events

On 12/03/16 11:33, Dario Faggioli wrote: > (i.e., domain creation and destruction) so the > trace will show properly decoded info, rather > than just a bunch of hex codes. > --- For some reason git won't apply your 'v2', complaining: 'corrupt patch at line 14'. But re the content (i.e., this

[Xen-devel] [linux-4.1 test] 86912: regressions - trouble: blocked/broken/fail/pass

flight 86912 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/86912/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 11:12, Andrew Cooper wrote: > On 23/03/16 10:59, David Vrabel wrote: >> On 23/03/16 10:55, Andrew Cooper wrote: >>> On 23/03/16 10:52, Juergen Gross wrote: On 23/03/16 11:32, David Vrabel wrote: > On 23/03/16 10:25, Jan Beulich wrote: > On 23.03.16 at 11:14,

Re: [Xen-devel] [PATCH v4 07/34] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables

Hi Jan, On 23/03/16 08:19, Jan Beulich wrote: On 22.03.16 at 21:18, wrote: +symbols_lookup_t *symbols_lookup; + +struct { +const struct bug_frame *bugs; /* The pointer to array of bug frames. */ +ssize_t n_bugs; /* The number of them. */

Re: [Xen-devel] [PATCH 3/3] xenalyze: handle RTDS scheduler events

On 12/03/16 11:34, Dario Faggioli wrote: > so the trace will show properly decoded info, > rather than just a bunch of hex codes. > > Signed-off-by: Dario Faggioli > Reviewed-by: Konrad Rzeszutek Wilk Acked-by: George Dunlap

Re: [Xen-devel] [PATCH 3/3] Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

>>> On 23.03.16 at 10:44, wrote: > Besides, iiuc, setting the W bit to 1 with R bit cleared in EPT pte is > not really giving the write access right to the guest, and will trigger > ept misconfiguration. Oh, indeed. Quite odd. Jan

Re: [Xen-devel] [PATCH v2 0/9] tools: Allow HVM domains emulated access to disks provided by hotplug scripts

On Mon, 21 Mar 2016, George Dunlap wrote: > In order for HVM domains to provide emulated access to disks provided > by hotplug scripts, qemu needs access to a "cooked" version of the > disk. In the case of hotplug scripts, this "cooked" version is > available in the form of a block device passed

[Xen-devel] help

ello i'm trying to learn more about xen hypervisor .. i install xen in my host with alpine as domu and now i'm trying to build xen from source with linux dom0 for an arm board .. i have a little bit confusion about building xen from the source here's what i did i build xen from the source git

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 11:34, Andrew Cooper wrote: > On 23/03/16 10:25, Jan Beulich wrote: > On 23.03.16 at 11:14, wrote: >>> 7. Report type according to features found (this is a little bit >>>ugly: we have to rely on the current hypervisor implementation >>>regarding the bits

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 10:55, Andrew Cooper wrote: > On 23/03/16 10:52, Juergen Gross wrote: >> On 23/03/16 11:32, David Vrabel wrote: >>> On 23/03/16 10:25, Jan Beulich wrote: >>> On 23.03.16 at 11:14, wrote: > 7. Report type according to features found (this is a little bit >

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

>>> On 23.03.16 at 10:19, wrote: > On 23/03/16 10:10, Jan Beulich wrote: > On 23.03.16 at 08:50, wrote: >>> xen-detect always thinks a domU is running as HVM guest as the cpuid >>> instruction used to identify a Xen guest will always work. >>> >>> In order

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 10:29, Jan Beulich wrote: On 23.03.16 at 10:19, wrote: >> On 23/03/16 10:10, Jan Beulich wrote: >> On 23.03.16 at 08:50, wrote: xen-detect always thinks a domU is running as HVM guest as the cpuid instruction used to identify a Xen

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 10:25, Jan Beulich wrote: On 23.03.16 at 11:14, wrote: >> 7. Report type according to features found (this is a little bit >>ugly: we have to rely on the current hypervisor implementation >>regarding the bits set for the different guest types). > Well, in

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 23/03/16 11:32, David Vrabel wrote: > On 23/03/16 10:25, Jan Beulich wrote: > On 23.03.16 at 11:14, wrote: >>> 7. Report type according to features found (this is a little bit >>>ugly: we have to rely on the current hypervisor implementation >>>regarding the bits

Re: [Xen-devel] [PATCH 2/5] x86/time: implement tsc as clocksource

On 03/23/2016 07:28 AM, Jan Beulich wrote: On 22.03.16 at 21:40, wrote: >> On 03/22/2016 04:02 PM, Jan Beulich wrote: >> On 22.03.16 at 16:51, wrote: On 03/22/2016 12:46 PM, Jan Beulich wrote: On 22.03.16 at 13:41,

Re: [Xen-devel] [PATCH] blkif.h: document scsi/0x12/0x node

On Wed, 23 Mar 2016, Bob Liu wrote: > This patch documents a xenstore node which is used by XENVBD Windows PV > driver. > > The use case is that XenServer may have OEM specific storage backends and > there is requirement to run OEM software in guest which relied on VPD > information supplied by

Re: [Xen-devel] Severe guest disk corruption with device_model_stubdomain_override=1...

On 03/22/2016 11:03 PM, Sarah Newman wrote: > And nested xen. > > CPU: AMD Opteron 2352 > Outer configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux 3.18.25-18.el6.x86_64 > Inner configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux 3.18.25-19.el6.x86_64 > Inner xen command line: cpuinfo loglvl=all

[Xen-devel] x86/vMSI-X emulation issue

All, so I've just learned that Windows (at least some versions and some of their code paths) use REP MOVSD to read/write the MSI-X table. The way at least msixtbl_write() works is not compatible with this (msixtbl_read() also seems affected, albeit to a lesser degree), and apparently it just

[Xen-devel] ARMv8: New board bring up hangs in kernel start?

Hi, trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I get [1] and then its hanging there. I'd guess that it hangs due to missing timer interrupt, maybe missing interrupts at all? Any hints how to debug this? Or where to look? It might be possible that the board's

[Xen-devel] Building tools for ARM (WAS Re: help)

(CC xen-user, BCC xen-devel) On 23/03/16 10:23, Marwa Hamza wrote: ello Hello, Please have a more meaningful subject. Also the question is not related to development so the thread is moved to xen-users. i'm trying to learn more about xen hypervisor .. i install xen in my host with alpine

Re: [Xen-devel] [PATCH 05/16] xen: sched: move pCPU initialization in an helper

On 18/03/16 19:04, Dario Faggioli wrote: > That will turn out useful in following patches, where such > code will need to be called more than just once. Create an > helper now, and move the code there, to avoid mixing code > motion and functional changes later. > > In Credit2, some style cleanup

Re: [Xen-devel] Interested to participate in Outreachy Program

On 3/23/16 11:34 AM, sabiya kazi wrote: > Hi Doug, > Can you have a look at patch and let me know if everything > is correct, I think things are good. > > I would also like to have a word with you for deciding timeline for > project. Meantime, I have started reading stuff about rust language. >

Re: [Xen-devel] [PATCH v4 12/34] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

On Wed, Mar 23, 2016 at 07:51:29AM -0600, Jan Beulich wrote: > >>> On 15.03.16 at 18:56, wrote: > > --- a/xen/common/Kconfig > > +++ b/xen/common/Kconfig > > @@ -168,4 +168,15 @@ config SCHED_DEFAULT > > > > endmenu > > > > +# Enable/Disable xsplice support > >

Re: [Xen-devel] rcu_sched self-detected stall on CPU on kernel 4.4.5/6 in PV DomU

Just wanted to give a bit of a poke about this. Currently running kernel 4.4.6 in a PV DomU and still occasionally getting hangs. Also stumbled across this that may be related: https://lkml.org/lkml/2016/2/4/724 My latest hang shows: [339844.594001] INFO: rcu_sched self-detected stall on

Re: [Xen-devel] [PATCH v4 07/34] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables

> >> > +#ifdef CONFIG_X86 > >> > +#include > >> > +#endif > >> > >> Why? > > > > Otherwise the compilation will fail on ARM as they do not have exceptions > > (and no asm/uaccess.h file) > > Well, the question was for the #include, not the #ifdef. Ah, yes. And with the 'ex' being pointers it

Re: [Xen-devel] [PATCH v4 11/34] xsplice: Design document

On Wed, Mar 23, 2016 at 05:18:39AM -0600, Jan Beulich wrote: > >>> On 15.03.16 at 18:56, wrote: > > +### XEN_SYSCTL_XSPLICE_LIST (2) > > + > > +Retrieve an array of abbreviated status and names of payloads that are > > loaded in the > > +hypervisor. > > + > > +The caller

[Xen-devel] [linux-4.1 test] 87031: regressions - FAIL

flight 87031 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/87031/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen

Re: [Xen-devel] [PATCH v4 04/34] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

. fixed all of those .. > > --- a/xen/xsm/flask/hooks.c > > +++ b/xen/xsm/flask/hooks.c > > @@ -1658,6 +1658,40 @@ static int flask_xen_version (uint32_t op) > > } > > } > > > > +static int flask_version_op (uint32_t op) > > +{ > > +u32 dsid = domain_sid(current->domain); > > + > > +

Re: [Xen-devel] [ovmf test] 87014: regressions - FAIL

On 03/23/2016 09:27 AM, osstest service owner wrote: > flight 87014 ovmf real [real] > http://logs.test-lab.xenproject.org/osstest/logs/87014/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-qemuu-ovmf-amd64 9

Re: [Xen-devel] [PATCH] blkif.h: document scsi/0x12/0x node

On 03/23/2016 08:33 PM, Roger Pau Monné wrote: > On Wed, 23 Mar 2016, Bob Liu wrote: > >> This patch documents a xenstore node which is used by XENVBD Windows PV >> driver. >> >> The use case is that XenServer may have OEM specific storage backends and >> there is requirement to run OEM software

Re: [Xen-devel] [PATCH v4 12/34] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

>>> On 15.03.16 at 18:56, wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -168,4 +168,15 @@ config SCHED_DEFAULT > > endmenu > > +# Enable/Disable xsplice support > +config XSPLICE > + bool "xSplice live patching support" > + default y Isn't

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 03/23/2016 07:33 AM, Juergen Gross wrote: On 23/03/16 11:55, Andrew Cooper wrote: On 23/03/16 10:52, Juergen Gross wrote: On 23/03/16 11:32, David Vrabel wrote: On 23/03/16 10:25, Jan Beulich wrote: On 23.03.16 at 11:14, wrote: 7. Report type according to features found

Re: [Xen-devel] [PATCH 2/5] x86/time: implement tsc as clocksource

>>> On 23.03.16 at 13:05, wrote: > On 03/23/2016 07:28 AM, Jan Beulich wrote: >> Sure - it seems quite obvious that all boot time available CPUs >> should be checked. > Cool, so I will go with moving init_xen_time right after all CPUs are up but > before initcalls are

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

>>> On 23.03.16 at 11:14, wrote: > 7. Report type according to features found (this is a little bit >ugly: we have to rely on the current hypervisor implementation >regarding the bits set for the different guest types). Well, in some of the cases feature flags only make

Re: [Xen-devel] [PATCH v4 11/34] xsplice: Design document

>>> On 15.03.16 at 18:56, wrote: > +### XEN_SYSCTL_XSPLICE_LIST (2) > + > +Retrieve an array of abbreviated status and names of payloads that are > loaded in the > +hypervisor. > + > +The caller provides: > + > + * `version`. Initially (on first hypercall) *MUST* be zero.

Re: [Xen-devel] [PATCH v2 8/9] docs: Document block-script protocol

On 22/03/16 12:52, Roger Pau Monné wrote: > On Mon, 21 Mar 2016, George Dunlap wrote: >> Signed-off-by: George Dunlap >> --- >> Changes since v1: >> - Attempt to make a clear distinction between custom hotplug scripts >> and the script called for raw physical devices and

Re: [Xen-devel] [PATCH 3/3] Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

On 22/03/16 17:51, Paul Durrant wrote: >> -Original Message- >> From: George Dunlap [mailto:george.dun...@citrix.com] >> Sent: 22 March 2016 17:27 >> To: Yu Zhang; xen-devel@lists.xen.org >> Cc: Keir (Xen.org); jbeul...@suse.com; Andrew Cooper; George Dunlap; >> jun.nakaj...@intel.com;

[Xen-devel] [OSSTEST PATCH 2/2] coverity: Rename branch names to `smoke', not `smoked'

c/s d94637b6 "coverity: run tests on smoked rather than master" used `smoked' in several places, including as the name of the input branch (which is already established as `smoke'), and the name of the coverity-tested branch. But we call this `smoke', not `smoked'. After this patch `git-grep

Re: [Xen-devel] [PATCH v6 20/22] xen/acpi: Fix event-channel interrupt when booting with ACPI

Hi Shannon, On 17/03/16 09:41, Shannon Zhao wrote: From: Shannon Zhao Store the event-channel interrupt number and flag in HVM parameter HVM_PARAM_CALLBACK_IRQ. Then Dom0 could get it through hypercall HVMOP_get_param. Signed-off-by: Shannon Zhao

Re: [Xen-devel] [PATCH] blkif.h: document scsi/0x12/0x node

> -Original Message- > From: Bob Liu [mailto:bob@oracle.com] > Sent: 23 March 2016 11:48 > To: xen-devel@lists.xen.org > Cc: Paul Durrant; Ian Jackson; konrad.w...@oracle.com; jgr...@suse.com; > Roger Pau Monne; annie...@oracle.com; David Vrabel; Bob Liu > Subject: [PATCH] blkif.h:

[Xen-devel] Outreachy bite-sized tasks

Hello, First of all, thanks for your interest in the Xen Project, and for wanting to participate in Outreachy. Both of you have expressed interest in the "QEMU xen-blkback performance analysis and improvements" Outreachy project, and AFAIK both of you still need to perform your initial

[Xen-devel] [ovmf test] 87014: regressions - FAIL

flight 87014 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/87014/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

[Xen-devel] Severe guest disk corruption with device_model_stubdomain_override=1...

And nested xen. CPU: AMD Opteron 2352 Outer configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux 3.18.25-18.el6.x86_64 Inner configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux 3.18.25-19.el6.x86_64 Inner xen command line: cpuinfo loglvl=all guest_loglvl=error dom0_mem=512M,max:512M

Re: [Xen-devel] [PATCH v2 5/6] x86/xen, pat: Remove PAT table init code from Xen

On 22/03/16 18:02, Borislav Petkov wrote: > On Wed, Mar 16, 2016 at 06:46:58PM -0600, Toshi Kani wrote: >> Xen supports PAT without MTRR for its guests. In order to >> enable WC attribute, it was necessary for xen_start_kernel() >> to call pat_init_cache_modes() to update PAT table before >>

  1   2   >