On 17/03/16 10:25, Jan Beulich wrote:
On 16.03.16 at 21:05, wrote:
>> @@ -1742,8 +1742,10 @@ static void load_segments(struct vcpu *n)
>> cs_and_mask = (unsigned short)regs->cs |
>> ((unsigned int)vcpu_info(n, evtchn_upcall_mask) << 16);
>> /* Fold u
TRAPBOUNCE_flags are always available via a displacement from %rdx. This
allows all of %rcx to be used as a scratch register.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/x86_64/compat/entry.S | 5 ++---
xen/arch/x86/x86_64/entry.S| 5
On 17/03/16 15:32, Jan Beulich wrote:
On 17.03.16 at 15:44, wrote:
>> On 17/03/16 14:31, Jan Beulich wrote:
>>> Also - do we really want to make this code dependent on
>>> map_pages_to_xen() not intermediately zapping the mappings
>>> being changed?
>> Do you mean "immediately"?
> No.
>
>> As
On 16/03/16 13:00, Paul Durrant wrote:
> Commit b38d426a "flush remote tlbs by hypercall" add support to allow
> Windows to request flush of remote TLB via hypercall rather than IPI.
> Unfortunately it seems that this code was broken in a couple of ways:
>
> 1) The allocation of the per-vcpu flush
On 18/03/16 19:06, Dario Faggioli wrote:
> like what's there already in both Credit1 and RTDS. In
> fact, when playing with affinity, a lot of cpumask
> manipulation is necessary, inside of various functions.
>
> To avoid having a lot of cpumask_var_t on the stack,
> this patch introduces a global
kernels assumed to be level 0 for the purpose of iopl checks.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/domain.c | 10 +++---
xen/arch/x86/physdev.c | 2 +-
xen/arch/x86/traps.c | 8 ++--
xen/arch/x86/x86_64/asm-offsets.c | 3
> This patch also adds a comment block at the top of the source with
> information on the latest version of the spec. from Microsoft and the
> current URL where it may be found.
>
> Signed-off-by: Paul Durrant
> Cc: Keir Fraser
> Cc: Jan Beulich
> Cc: Andrew Cooper
By the
On 17/03/16 08:02, Jan Beulich wrote:
> This not only eases using the cached value in assembly code, but also
> improves the generated code resulting from such reads in C.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
_
On 21/03/16 11:42, Joao Martins wrote:
>
> On 03/18/2016 08:12 PM, Andrew Cooper wrote:
>> On 17/03/16 16:12, Joao Martins wrote:
>>> This field has two possible flags (as of latest pvclock ABI
>>> shared with KVM).
>>>
>>> flags: bits in this fiel
On 21/03/16 11:45, Joao Martins wrote:
>
> All fixed, though I found one change missing in this series, specifically on
> time_calibration_std_rendezvous. Otherwise this commit would break
> compilation.
> See chunk below for the change I am adding:
>
> @@ -1377,7 +1380,7 @@ static void time_calib
On 21/03/16 13:28, Jason Long wrote:
Don't top post.
> Thank you but I need a diagram like below. It is an diagram about OS
> components :
>
> http://www.c-jump.com/CIS24/Slides/Booting/images/os_components.png
>
> Can you show me similar diagram for Xen?
http://lmgtfy.com/?q=diagram+of+xen+com
On 21/03/16 11:53, Jan Beulich wrote:
+XEN_CPUFEATURE(X2APIC,1*32+21) /*A Extended xAPIC */
>>> Does this make sense for PV?
>> It is currently visible, and we already have to leak APIC through to PV
>> guests.
> Having to leak on piece of state doesn't mean when need to leak
> more,
On 21/03/16 15:10, Jan Beulich wrote:
On 17.03.16 at 17:12, wrote:
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -614,10 +614,14 @@ struct vcpu_time_info {
>> */
>> uint32_t tsc_to_system_mul;
>> int8_t tsc_shift;
>> -int8_t pad1[3];
>> +
On 21/03/16 16:51, Jan Beulich wrote:
On 15.03.16 at 16:35, wrote:
>> +/* Fast-forward bits - Must be set. */
>> +if (ecx & cpufeat_mask(X86_FEATURE_XSAVE))
>> +ecx |= cpufeat_mask(X86_FEATURE_OSXSAVE);
> Wouldn't you think it would be better to als
On 16/03/16 08:32, Konrad Rzeszutek Wilk wrote:
>
>> +
>> +/* Intel-defined CPU features, CPUID level 0x0001.ecx, word 1 */
> This is quite the redefinition of the x86_capability[] array.
>
> As in if folks look at this from Linux and Xen there is quite
> a change.
Why does it matter? People
On 18/03/16 17:09, Jan Beulich wrote:
On 15.03.16 at 16:35, wrote:
>> +static void __init calculate_hvm_featureset(void)
>> +{
>> +unsigned int i;
>> +const uint32_t *hvm_featuremask;
>> +
>> +if ( !hvm_enabled )
>> +return;
>> +
>> +hvm_featuremask = hvm_funcs.hap_sup
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 22/03/16 13:05, Jan Beulich wrote:
> - don't unintentionally increase features reported by sub-leaf 0
> EDX:EAX
> - don't discard the known flags in sub-leaves 2..63 ECX
> - handle components 32...62 (EDX) in sub-leaf 1 consistently with
> 0...31 (ECX)
> - zap sub-leaves beyond 62
>
> Signed
On 22/03/16 12:39, Jan Beulich wrote:
On 22.03.16 at 12:23, wrote:
>> On 18/03/16 17:09, Jan Beulich wrote:
>> On 15.03.16 at 16:35, wrote:
+static void __init calculate_hvm_featureset(void)
+{
+unsigned int i;
+const uint32_t *hvm_featuremask;
+
+
On 22/03/16 14:52, Jan Beulich wrote:
On 22.03.16 at 15:37, wrote:
>> On 22/03/16 12:39, Jan Beulich wrote:
>> On 22.03.16 at 12:23, wrote:
On 18/03/16 17:09, Jan Beulich wrote:
On 15.03.16 at 16:35, wrote:
>> +static void __init calculate_hvm_featureset(void)
>> +
On 22/03/16 12:56, Jan Beulich wrote:
slot => slots in the subject.
> domain_cpuid() returns all zeroes anyway when not finding a match, so
> there's no need to explicitly store such a set of values.
>
> Signed-off-by: Jan Beulich
Review
On 21/03/16 16:11, Jan Beulich wrote:
>
>> +/* OSXSAVE cleared by pv_featureset. Fast-forward CR4 back in. */
>> +if ( (is_pv_domain(currd) && guest_kernel_mode(curr, regs) &&
>> + (this_cpu(cr4) & X86_CR4_OSXSAVE)) ||
>> + (curr->arch.pv_vcpu.ctrlreg[4] &
On 21/03/16 16:23, Jan Beulich wrote:
On 15.03.16 at 16:35, wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -36,6 +36,12 @@ integer_param("cpuid_mask_ext_ecx",
>> opt_cpuid_mask_ext_ecx);
>> unsigned int opt_cpuid_mask_ext_edx = ~0u;
>> integer_param("cpu
On 21/03/16 17:06, Jan Beulich wrote:
On 15.03.16 at 16:35, wrote:
>> @@ -87,6 +88,129 @@ static void update_domain_cpuid_info(struct domain *d,
>> d->arch.x86_model = (ctl->eax >> 4) & 0xf;
>> if ( d->arch.x86 >= 0x6 )
>> d->arch.x86_model |= (ctl->eax >> 12) &
On 22/03/16 14:46, Jan Beulich wrote:
On 22.03.16 at 14:48, wrote:
>>> @@ -300,9 +304,9 @@ static void xc_cpuid_config_xsave(xc_int
>>> {
>>> case 0:
>>> /* EAX: low 32bits of xfeature_enabled_mask */
>>> -regs[0] = info->xfeature_mask & 0x;
>>> +re
On 22/03/16 18:57, Konrad Rzeszutek Wilk wrote:
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -751,3 +751,22 @@ static XSM_INLINE int xsm_xen_version
> (XSM_DEFAULT_ARG uint32_t op)
> return xsm_default_action(XSM_PRIV, current->domain, NULL);
>>
On 22/03/16 20:06, Firas Azar wrote:
> The pygrub command option "isconfig" is broken and obsolete. This patch
> removes it since the alternate options "-l -n" provide the same functionality.
Broken how?
Are you sure that no existing software is using that option?
~Andrew
_
On 22/03/16 08:43, Jan Beulich wrote:
>
> Going through the HAP-only features, btw, revealed another
> possible dependency missing from patch 10: I would think that
> INVPCID depends on PCID.
And, as it turns out PCID on LM.
Attempting to set CR4.PCIDE while IA32_EFER.LMA = 0 is specified to
incu
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 cpuid
> instruction used to id
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 some of the cases
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, having separate flags seem
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
ugly: we have to rely on the current hypervisor implementation
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, wr
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
performed at compile time,
runtime can use a single mask to disable all eventual features.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* New.
v3:
* Vastly more reserch and comments.
v4:
* Expand commit message.
* More tweaks to the dependency tree.
* Avoid for_each_set_bit() walking off
levelling state.
In particular, this means that PV guests may have different levels while
running on the same host, an option which was not previously available.
Andrew Cooper (26):
xen/public: Export cpu featureset information in the public API
xen/x86: Script to automatically process featureset
If Xen doesn't know about a feature, it is unsafe for use and should be
deliberately hidden from Xen's capabilities.
This doesn't make a practical difference yet, but will make a difference
later when the guest featuresets are seeded from the host featureset.
Signed-off-by: Andre
New words are:
* 0x8007.edx - Contains Invarient TSC
* 0x8008.ebx - Newly used for AMD Zen processors
In addition, replace some open-coded ITSC and EFRO manipulation.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
---
v2:
* Rely on ordering of
, FSCAPINTS is currently hardcoded at 9. Future
changes will change this to being dynamically generated.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
v2:
* Rebase over upstream changes
* Collect all feature introductions from later in the series
* Restrict API to Xen and
All of this information will be used by the toolstack to make informed
levelling decisions for VMs, and by Xen to sanity check toolstack-provided
information.
Signed-off-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
---
CC: Jan Beulich
v3:
* Move as much as possible into .init.
* Fix
This script consumes include/public/arch-x86/cpufeatureset.h and generates a
single include/asm-x86/cpuid-autogen.h containing all the processed
information.
It currently generates just FEATURESET_NR_ENTRIES. Future changes will
generate more information.
Signed-off-by: Andrew Cooper
Acked-by
setting for HVM guests.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
---
v3:
* Essentially new. Replaces "Store antifeatures inverted in a featureset"
v4:
* Include X2APIC and HYPERVISOR as special bits.
---
xen/arch/x
guests don't get to use the APIC and the
HVM APIC emulation doesn't support extended space.
Signed-off-by: Andrew Cooper
Reviewed-by: Konrad Rzeszutek Wilk
---
CC: Jan Beulich
v2:
* Annotate features using a magic comment and autogeneration.
v3:
* Rebase over the new namespacei
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 __test_and_set_bit()
---
xen/arch/x86/cpu/common.c | 16
defaults.
The command line parameters are then combined with the hardware defaults to
further restrict the Xen default masking level. Each cpu is then context
switched into the default levelling state.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2:
* Provide extra information if
change the implementation to be in terms of char rather
than unsigned long. This fixes alignment concerns with ARM.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
v2:
* New
v3:
* Implement in terms of char rather than unsigned long to fix
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
---
v2:
* s/cpumasks/cpuidmasks
configuration is no longer special
cased for dom0. There was never any need to, and it will cause dom0 to
observe the same information through native and enlightened cpuid.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v3:
* Don't leave cpuid masking/faulting active for the kexec kerne
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
---
CC: Ian Jackson
v2
leaves which are not maskable.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Use switch() rather than if/elseif chain
* Clamp to static PV featuremask
v3:
* Only set a shadow cpumask if it is available in hardware. This causes
fewer branches in the context switch.
* Fix
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
Acked-by: Wei
-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v2:
* Style fixes.
* Provide extra information if opt_cpu_info.
* Extra comment indicating the expected use of intel_ctxt_switch_levelling().
v3:
* Style fixes.
* Avoid printing the cpumask defaults if faulting is available.
---
xen/arch/x86/cpu
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
v2: No linking hackary
---
.gitignore
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 hypercall documentation
v3:
* Provide libxc implementation for XEN_SYSCTL_get_cpu_levelling_caps as
for testing purposes. Subsequent changes
will cause the mask MSRs to be context switched per-domain, removing the need
to use the command line parameters for heterogeneous levelling purposes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/amd.c | 8 ++--
xen/arch/
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
---
v2: Move boolean_param() adjacent
ts in leaf 1, EBX/ECX. No XSS features are currently supported.
Signed-off-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
CC: Wei Liu
CC: Ian Jackson
v3:
* Reintroduce MPX adjustment (this series has been in development since
before the introduction of MPX upstream, and it got lost
.
* When emulating Intel to a guest, the common features in e1d should be
cleared.
* The APIC bit in e1d (on non-Intel) is also a fast-forward from the
APIC_BASE MSR.
As a small improvement, use compiler-visible &'s and |'s, rather than
{clear,set}_bit().
Signed-off-by: Andrew
switching
logic, after which the interface will report hardware capabilities correctly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* s/cpumasks/cpuidmasks/
v3:
* Reintroduce XEN_SYSCTL_get_levelling_caps (requested by Joao for some
development he has planned).
* Rename to
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 +++
3 files changed, 98 insertions(+)
diff
ature manipulation into a single function which adjusts the
featureset, and perform deep dependency removal.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
---
CC: Ian Jackson
v2:
* Join several related patches together.
v3:
* Correctly adjust HTT/CMP_LEGACY in the policy. PV guests see host details,
On 24/03/16 10:27, Jan Beulich wrote:
On 23.03.16 at 17:36, wrote:
>> Most patches do now how Acks/Reviews. The remaining patches are #1 (Rest),
>> #6-8,11-13,18 (x86), #20 (ARM), 26 (Toolstack).
> #20 doesn't have anything ARM specific, it's pure tools stuff.
It is trying to fix a pointer
On 24/03/16 10:58, Juergen Gross wrote:
> I've searched a little bit in git history in order to understand why
> xen-detect has been invented and/or has all the options which clearly
> are meant to be used in scripts.
>
> The last large modification was done in 2009 and I think Konrad is to
> blame
On 24/03/16 12:44, George Dunlap wrote:
> On 18/03/16 19:27, Andrew Cooper wrote:
>> On 18/03/16 19:06, Dario Faggioli wrote:
>>> like what's there already in both Credit1 and RTDS. In
>>> fact, when playing with affinity, a lot of cpumask
>>> manipulation
h
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 24/03/16 11:30, Jan Beulich wrote:
> There's no point in forwarding these to the device model.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 24/03/16 14:08, Jan Beulich wrote:
On 23.03.16 at 17:36, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/cpufeatureset.h
>> @@ -0,0 +1,32 @@
>> +#ifndef __XEN_X86_CPUFEATURESET_H__
>> +#define __XEN_X86_CPUFEATURESET_H__
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#define XEN_CPUFEATURE(na
ely acquired locks.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 24/03/16 14:31, Jan Beulich wrote:
> They're not really useful past the building stage and only needlessly
> increase binary file sizes.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-de
On 24/03/16 14:33, Jan Beulich wrote:
> This wasn't a good idea after all - make them unavailable except for
> legacy code using an older interface version.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel
On 23/03/16 16:36, Andrew Cooper wrote:
> 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 wh
On 24/03/16 16:47, Jan Beulich wrote:
On 23.03.16 at 17:36, wrote:
>> +if ( !is_pvh_domain(currd) )
>> {
>> -__clear_bit(X86_FEATURE_XSAVE % 32, &c);
>> -__clear_bit(X86_FEATURE_AVX % 32, &c);
>> +/*
>> + * Delete the PVH condit
iew of HTT and CMP_LEGACY through to
>> guests,
>> even though they could be hidden. These flags affect how to interpret other
>> cpuid leaves which are not maskable.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>>
>> v2:
>> *
ff-by: Roger Pau Monné
> Cc: Ian Jackson
> Cc: Wei Liu
Sorry for breaking this.
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 24/03/16 17:11, Jan Beulich wrote:
On 24.03.16 at 18:01, wrote:
>> On 24/03/16 16:47, Jan Beulich wrote:
>> On 23.03.16 at 17:36, wrote:
+if ( !is_pvh_domain(currd) )
{
-__clear_bit(X86_FEATURE_XSAVE % 32, &c);
-__clear_bit(
On 24/03/16 17:19, Paul Durrant wrote:
> @@ -293,10 +292,11 @@ void viridian_start_apic_assist(struct vcpu *v, int
> vector)
> * wrong and the VM will most likely hang so force a crash now
> * to make the problem clear.
> */
> -if ( v->arch.hvm_vcpu.viridian.apic_assist.vecto
an't return both 0 and a positive number for success. I would
recommend "return the number of bytes written, or negative errno on
failure".
Other than these, LGTM.
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
quests made as part
>> of a
>> transaction.
>>
>> Signed-off-by: Jonathan Davies
>> Reviewed-by: Andrew Cooper
>> Reviewed-by: Jon Ludlam
>> Reviewed-by: Euan Harris
>> ---
>> tools/ocaml/xenstored/process.ml | 15 ++-
>> 1
On 04/04/16 14:32, Razvan Cojocaru wrote:
> Hello,
>
> As a test, I've modified xen-access.c to this simplified skeleton:
>
> http://pastebin.com/48WYwW00
>
> then started up an x86 Windows 7 HVM guest, and ran it with:
>
> # ./xen-access write
>
> once the login screen appeared. The guest promptl
On 01/04/16 05:59, Chong Li wrote:
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 305889a..e5d15d8 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1080,15 +1080,13 @@ csched_dom_cntl(
> * lock. Runq lock not needed anywhere in her
On 04/04/16 16:50, Ben Sanda wrote:
> Julien and Wei,
>
>>> You patches all have the same subject line. Please make them more
>>> specific. See my reply to #1 for example.
>> +1
>>
>> Also, you should at least check that Xen still builds after applying
>> each patch. Ideally, you also need to be
On 04/04/16 17:59, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream disk
> argument code"):
>> I looked through the patch in the branch provided in your reply to 0/9
>> [1], and it looks correct; morever, I tested it and it and the basic
>> functionalit
On 04/04/16 18:11, Andrew Cooper wrote:
> On 04/04/16 17:59, Ian Jackson wrote:
>> George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream
>> disk argument code"):
>>> I looked through the patch in the branch provided in your reply to 0/9
>>
gdprintk(XENLOG_WARNING,"Cannot mix foreign mappings with translated
> domains");
Space after comma.
> +goto out;
> +}
> +#endif
> +
> +switch ( domid )
> +{
> +case DOMID_IO:
> + pg_own
On 04/04/2016 23:45, Chong Li wrote:
> From: Chong-Li
>
> Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced
> a bug: it made it possible, in Credit and Credit2, when doing domain
> or vcpu parameters' manipulation, to leave the hypervisor with a
> spinlock held.
And interrup
On 04/04/16 07:28, Jan Beulich wrote:
> With commit 96ae556569 ("x86/HVM: fix forwarding of internally cached
> requests") rc doesn't change anymore in the respective preceding
> switch() statements.
>
> Coverity ID: 1358080
> Signed-off-by: Jan Beu
On 05/04/16 11:55, Razvan Cojocaru wrote:
> Hello,
>
> xen-access.c does roughly this:
>
> for (;;) {
> poll_evt_channel();
>
> if (new_events) {
> while (ring_buffer_has_requests) {
> pull_request();
> process_request();
>
On 28/03/16 16:29, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2016 at 04:36:14PM +0000, Andrew Cooper wrote:
>> 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 subsume
On 05/04/16 16:55, Razvan Cojocaru wrote:
> On 04/05/16 18:35, Tamas K Lengyel wrote:
>>
>> On Tue, Apr 5, 2016 at 6:13 AM, Andrew Cooper > <mailto:andrew.coop...@citrix.com>> wrote:
>>
>> On 05/04/16 11:55, Razvan Cojocaru wrote:
>> > He
On 28/03/16 16:55, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2016 at 04:36:15PM +0000, Andrew Cooper wrote:
>> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
>> commandline-provided masks would take effect in Xen's view of the f
On 28/03/16 17:12, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2016 at 04:36:16PM +0000, Andrew Cooper wrote:
>> 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
>> c
On 28/03/16 19:55, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2016 at 04:36:17PM +0000, Andrew Cooper wrote:
>> 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 use
On 28/03/16 20:14, Konrad Rzeszutek Wilk wrote:
>> + * Context switch levelling state to the next domain. A parameter of NULL
>> is
>> + * used to context switch to the default host state, and is used by the
>> BSP/AP
>> + * startup code.
>> + */
>> +static void intel_ctxt_switch_levelling(const
On 28/03/16 20:40, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2016 at 04:36:20PM +0000, Andrew Cooper wrote:
>> And use them in preference to cpumask_defaults on context switch. HVM
>> domains
> Extra space before HVM
It is normal to have two spaces following a full st
On 31/03/16 08:48, Jan Beulich wrote:
On 23.03.16 at 17:36, wrote:
>> --- a/tools/libxc/xc_cpuid_x86.c
>> +++ b/tools/libxc/xc_cpuid_x86.c
>> @@ -398,54 +398,97 @@ static void intel_xc_cpuid_policy(xc_interface *xch,
>> }
>> }
>>
>> +/* XSTATE bits in XCR0. */
>> +#define X86_XCR0_X87
On 28/03/16 20:27, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 23, 2016 at 04:36:19PM +0000, Andrew Cooper wrote:
>> A single ctxt_switch_levelling() function pointer is provided
>> (defaulting to an empty nop), which is overridden in the appropriate
>> $
On 06/04/16 00:57, Mihai Donțu wrote:
> On Wed, 06 Apr 2016 01:38:32 +0200 wo...@openmailbox.org wrote:
>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
>> Linux distros have been tested and Xorg seg
On 06/04/16 12:01, Wei Liu wrote:
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 5b5dda4..79ff25e 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -410,12 +410,12 @@ PKG_CHECK_MODULES(LIBNL3, [libnl-3.0 >= 3.2.8
> libnl-route-3.0 >= 3.2.8],
> [libnl3_lib="y"],
th,
> setting it to NULL at declaration seems the safer option for now.
>
> Reported-by: Andrew Cooper
> Signed-off-by: George Dunlap
This looks like it will work. Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 06/04/16 15:41, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 01, 2016 at 10:06:54AM -0600, Jan Beulich wrote:
> On 24.03.16 at 21:00, wrote:
>>> --- a/xen/common/xsplice.c
>>> +++ b/xen/common/xsplice.c
>>> @@ -573,6 +573,25 @@ static int prepare_payload(struct payload *payload,
>>>
1 - 100 of 7442 matches
Mail list logo
