There's no need to have shim specific targets, so just use the regular
xen makefile targets in order to build the shim binary.
When the shim is build as part of the firmware directory use the
xen-syms as the shim binary.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew
>>> On 19.02.18 at 18:51, wrote:
> We're noticing a reproducible system boot hang on certain
> Skylake platforms where the BIOS is configured in legacy
> boot mode with x2APIC disabled. The system stalls immediately
> after writing the first SMP initialization sequence into APIC ICR.
>
> The caus
>>> On 19.02.18 at 18:19, wrote:
> On 19/02/18 17:59, Jan Beulich wrote:
> On 15.02.18 at 13:52, wrote:
>>> --- a/xen/arch/x86/x86_64/entry.S
>>> +++ b/xen/arch/x86/x86_64/entry.S
>>> @@ -46,10 +46,13 @@ restore_all_guest:
>>> .Lrag_cr3_start:
>>> mov VCPU_cr3(%rbx), %r9
>>>
There a bunch of bits in CR4 that should be allowed to be set directly
by the guest without requiring Xen intervention, currently this is
already done by passing through guest writes into the CR4 used when
running in non-root mode, but taking an expensive vmexit in order to
do so.
xenalyze reports
At the moment this is currently set at VMC{S/B} creation and not changed,
but further patches are going to change the CR4 mask at runtime.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Kevin Tian
---
C
Hello,
Following two-patch series optimize CR4 access for vmx/hap.
I couldn't figure out a similar approach for AMD, since according to
section 15.9 (Instruction Intercepts), you either intercept all access
to CR4 or none. In any case a similar optimization for AMD can always be
added later.
Tha
On 20/02/18 09:56, Jan Beulich wrote:
On 19.02.18 at 18:19, wrote:
>> On 19/02/18 17:59, Jan Beulich wrote:
>> On 15.02.18 at 13:52, wrote:
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -46,10 +46,13 @@ restore_all_guest:
.Lrag_cr3_start:
>>>
>>> On 20.02.18 at 09:23, wrote:
> There's no need to have shim specific targets, so just use the regular
> xen makefile targets in order to build the shim binary.
>
> When the shim is build as part of the firmware directory use the
> xen-syms as the shim binary.
Why the (much larger) xen-syms i
>>> On 20.02.18 at 10:03, wrote:
> On 20/02/18 09:56, Jan Beulich wrote:
> On 19.02.18 at 18:19, wrote:
>>> On 19/02/18 17:59, Jan Beulich wrote:
>>> On 15.02.18 at 13:52, wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -46,10 +46,13 @@ res
>>> On 19.02.18 at 15:16, wrote:
> --- a/xen/include/asm-x86/indirect_thunk_asm.h
> +++ b/xen/include/asm-x86/indirect_thunk_asm.h
> @@ -3,6 +3,10 @@
> * usual #ifdef'ary to turn into comments.
> */
>
> +.ifndef CONFIG_INDIRECT_THUNK
> +.equ CONFIG_INDIRECT_THUNK, 0
> +.endif
I have to
On 20/02/18 10:10, Jan Beulich wrote:
On 20.02.18 at 10:03, wrote:
>> On 20/02/18 09:56, Jan Beulich wrote:
>> On 19.02.18 at 18:19, wrote:
On 19/02/18 17:59, Jan Beulich wrote:
On 15.02.18 at 13:52, wrote:
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86
flight 119682 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119227
test-xtf-amd64-
Add documentation for statistic attribute ds_req - the number of
discarded requests.
Signed-off-by: Aishwarya Pant
---
Documentation/ABI/stable/sysfs-bus-xen-backend | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-bus-xen-backend
b/Documentation/ABI/sta
On Tue, Feb 20, 2018 at 02:04:24AM -0700, Jan Beulich wrote:
> >>> On 20.02.18 at 09:23, wrote:
> > There's no need to have shim specific targets, so just use the regular
> > xen makefile targets in order to build the shim binary.
> >
> > When the shim is build as part of the firmware directory u
On Tue, Feb 20, 2018 at 02:15:24AM -0700, Jan Beulich wrote:
> >>> On 19.02.18 at 15:16, wrote:
> > --- a/xen/include/asm-x86/indirect_thunk_asm.h
> > +++ b/xen/include/asm-x86/indirect_thunk_asm.h
> > @@ -3,6 +3,10 @@
> > * usual #ifdef'ary to turn into comments.
> > */
> >
> > +.ifndef CON
Hi Stefano,
On 19/02/18 21:58, Stefano Stabellini wrote:
There can be processors of different kinds on a single system. Make
processor a per_cpu variable pointing to the right processor type for
each core.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Gral
On Lu, 2018-02-19 at 08:25 -0700, Tamas K Lengyel wrote:
> On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila
> wrote:
> >
> > At this moment the CPUID events for the AMD architecture are not
> > forwarded to the monitor layer.
> >
> > This patch adds the CPUID event to the common capabilities and
Hi Stefano,
On 19/02/18 21:58, Stefano Stabellini wrote:
On big.LITTLE systems not all cores have the same ACTLR. Instead of
reading ACTLR and setting v->arch.actlr in vcpu_initialise, do it later
on the same pcpu where the vcpu will run.
This way, assuming that the vcpu has been created with t
On Tue, Feb 20, 2018 at 10:19:16AM +, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 02:15:24AM -0700, Jan Beulich wrote:
> > >>> On 19.02.18 at 15:16, wrote:
> > > --- a/xen/include/asm-x86/indirect_thunk_asm.h
> > > +++ b/xen/include/asm-x86/indirect_thunk_asm.h
> > > @@ -3,6 +3,10 @@
> >
Hi Stefano,
On 19/02/18 21:58, Stefano Stabellini wrote:
On big.LITTLE systems not all cores have the same midr. Instead of
storing only one vpidr per domain, make it per vcpu and initialize it to
the value of the midr of the pcpu where the vcpu will run.
This way, assuming that the vcpu has be
>>> On 20.02.18 at 11:06, wrote:
> On Tue, Feb 20, 2018 at 02:04:24AM -0700, Jan Beulich wrote:
>> >>> On 20.02.18 at 09:23, wrote:
>> > --- a/tools/firmware/xen-dir/Makefile
>> > +++ b/tools/firmware/xen-dir/Makefile
>> > @@ -48,10 +48,10 @@ shim-%config: $(D) FORCE
>> >KCONFIG_CONFI
>>> On 20.02.18 at 12:01, wrote:
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -15,6 +15,9 @@
> #include
>
> #ifdef __ASSEMBLY__
> +#ifndef CONFIG_INDIRECT_THUNK
> +.equ CONFIG_INDIRECT_THUNK, 0
> +#endif
> # include
> #else
> asm ( "\t.equ CONFIG_IND
On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> There's no need to have shim specific targets, so just use the regular
> xen makefile targets in order to build the shim binary.
>
> When the shim is build as part of the firmware directory use the
> xen-syms as the shim binary.
>
On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
> >>> On 20.02.18 at 12:01, wrote:
> > --- a/xen/include/asm-x86/asm_defns.h
> > +++ b/xen/include/asm-x86/asm_defns.h
> > @@ -15,6 +15,9 @@
> > #include
> >
> > #ifdef __ASSEMBLY__
> > +#ifndef CONFIG_INDIRECT_THUNK
> > +.equ CONFIG
On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> > There's no need to have shim specific targets, so just use the regular
> > xen makefile targets in order to build the shim binary.
> >
> > When the shim is build as part
On Tue, Feb 20, 2018 at 11:26:44AM +, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote:
> > On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> > > There's no need to have shim specific targets, so just use the regular
> > > xen makefile targets in
Hi Stefano,
On 19/02/18 21:58, Stefano Stabellini wrote:
On big.LITTLE systems the cacheline size might differ between big and
LITTLE cores. Instead of reading the cacheline size once at boot,
read it as needed from the system registers.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabel
On Tue, Feb 20, 2018 at 11:29:58AM +, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 11:26:44AM +, Roger Pau Monné wrote:
> > On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote:
> > > On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> > > > There's no need to have shim specif
Hello Dario,
On 16.02.18 20:37, Dario Faggioli wrote:
And what is it that is running in DomR, the same thing as before, when
the load was synthetic?
For sure I compare apples to apples.
And in any case, is it, in its turn (I mean the
workload running in DomR) a synthetic real-time load, or i
Hi Stefano,
On 19/02/18 21:58, Stefano Stabellini wrote:
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 2184cb9..8997904 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1007,7 +1007,12 @@ Control Xens u
flight 119721 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119721/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
guests. It is RFC because I haven't done extensive testing on the result, and
because there are some functional changes for the virtualised TSC modes.
Andrew Cooper (5):
x86/hvm: Don't shadow the domain parameter in hvm_
If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in
MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
advertised/hidden.
At the moment, paravirt_ctxt_switch_to() only writes to MSR_TSC_AUX if
TSC_MODE_PVRDTSCP mode is enabled, but this is not the defau
The handling of RDTSCP for PV guests has been broken (AFAICT forever).
To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
be unreachable. However, this appears to be a "feature" of TSC_MODE_PVRDTSCP,
and the emulator doesn't perform appropriate feature checking. (Conve
There are many problems with MSR_TSC_AUX handling.
To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally
depends on RDTSCP.
For PV guests, we hide RDTSCP but advertise RDPID. We also silently drop
writes
c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally
ended up shadowing the "struct domain *d" function parameter. Rename the
former to desc.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/hvm/h
Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
the way of some intended cleanup.
* Drop the rdtscp parameter and always make the caller responsible for ecx
updates when appropriate.
* Switch the function from being void, and return the main timestamp in the
r
>>> On 20.02.18 at 12:22, wrote:
> On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
>> >>> On 20.02.18 at 12:01, wrote:
>> > --- a/xen/include/asm-x86/asm_defns.h
>> > +++ b/xen/include/asm-x86/asm_defns.h
>> > @@ -15,6 +15,9 @@
>> > #include
>> >
>> > #ifdef __ASSEMBLY__
>> > +#i
Any thoughts are appreciated.
> This patch is adding a way to enable/disable nested pagefault
> events. It introduces the xc_monitor_nested_pagefault function
> and adds the nested_pagefault_disabled in the monitor structure.
> This is needed by the introspection so it will only get gla
> faults a
On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote:
> >>> On 20.02.18 at 12:22, wrote:
> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
> >> >>> On 20.02.18 at 12:01, wrote:
> >> > --- a/xen/include/asm-x86/asm_defns.h
> >> > +++ b/xen/include/asm-x86/asm_defns.h
> >> > @
>>> On 20.02.18 at 13:42, wrote:
> On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote:
>> >>> On 20.02.18 at 12:22, wrote:
>> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
>> >> >>> On 20.02.18 at 12:01, wrote:
>> >> > --- a/xen/include/asm-x86/asm_defns.h
>> >> > +++ b
On Tue, Feb 20, 2018 at 05:53:08AM -0700, Jan Beulich wrote:
> >>> On 20.02.18 at 13:42, wrote:
> > On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote:
> >> >>> On 20.02.18 at 12:22, wrote:
> >> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
> >> >> >>> On 20.02.18 at 12:
Hi Wei,
On 31/10/17 13:51, Wei Liu wrote:
> First version of this series can be found at [0].
>
> This version contains workaround for Arndale boards. They are now functional.
I need the following patch [1] to use that branch on Arm64 boxes.
Also, on Thunder-X I needed a hack to keep the interf
If the required features are met by the integrated clang assembler
(support for .includes and propagation of .macro-s between asm()-s)
do not disable it.
Only disable the integrated assembler for assembly files, like it was
done prior to "x86: Support indirect thunks from assembly code".
Signed-o
When indirect_thunk_asm.h is instantiated directly into assembly files
CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against
it is wrong.
Add a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so
that using .if CONFIG_INDIRECT_THUNK is always correct.
This suppresses th
Or else disable the integrated assembler for assembly files. This is
relevant for older clang versions which integrated assembler don't
support .skip with labels.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
If the assembler is not used. This happens when using cc -E or cc -S
for example. GCC will just ignore the -Wa,... when the assembler is
not called, but clang will complain loudly and fail.
Also enable passing -Wa,-I$(BASEDIR)/include to clang now that it's
safe to do so.
Signed-off-by: Roger Pau
Hardcoding as-insn to use AFLAGS is not correct. For once the test is
performed using a C file with inline assembly, and secondly the flags
used can be passed by the caller together with the CC.
Fix as-insn-check to pass the flags given as parameter to the test.
Signed-off-by: Roger Pau Monné
--
Hello,
The following series re-enable the integrated clang assembler when the
features required in order to build Xen are available.
This series has been tested with clang 6, clang 3.5, gcc 6 and gcc 7
with indirect branch support.
Thanks, Roger.
Roger Pau Monne (5):
build: do not hardcode A
There's no need to have shim specific targets, so just use the regular
xen makefile targets in order to build the shim binary.
When the shim is build as part of the firmware directory install the
stripped Xen binary to the firmware directory and place a binary with
symbols in the debug directory.
On Tue, Feb 20, 2018 at 01:38:12PM +, Julien Grall wrote:
> Hi Wei,
>
> On 31/10/17 13:51, Wei Liu wrote:
> > First version of this series can be found at [0].
> >
> > This version contains workaround for Arndale boards. They are now
> > functional.
>
> I need the following patch [1] to use
On 20/02/18 14:37, Roger Pau Monne wrote:
> diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile
> index 7fd36a0e15..01a2850194 100644
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE
>
On Tue, Feb 20, 2018 at 02:37:54PM +, Roger Pau Monne wrote:
> xen-shim: $(D) shim-olddefconfig
> - $(MAKE) -C $(D)/xen install-shim \
> + $(MAKE) -C $(D)/xen build \
> XEN_CONFIG_EXPERT=y \
> - KCONFIG_CONFIG=$(CURDIR)/shim.config \
> - DESTDIR=$(
On Tue, Feb 20, 2018 at 11:58:39AM +, Andrew Cooper wrote:
> c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally
> ended up shadowing the "struct domain *d" function parameter. Rename the
> former to desc.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
On Tue, Feb 20, 2018 at 02:42:27PM +, Andrew Cooper wrote:
> On 20/02/18 14:37, Roger Pau Monne wrote:
> > diff --git a/tools/firmware/xen-dir/Makefile
> > b/tools/firmware/xen-dir/Makefile
> > index 7fd36a0e15..01a2850194 100644
> > --- a/tools/firmware/xen-dir/Makefile
> > +++ b/tools/firmwa
On Tue, Feb 20, 2018 at 02:43:25PM +, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 02:37:54PM +, Roger Pau Monne wrote:
> > xen-shim: $(D) shim-olddefconfig
> > - $(MAKE) -C $(D)/xen install-shim \
> > + $(MAKE) -C $(D)/xen build \
> > XEN_CONFIG_EXPERT=y \
> > - KCON
Roger Pau Monne writes ("[PATCH] build: remove shim related targets"):
> There's no need to have shim specific targets, so just use the regular
> xen makefile targets in order to build the shim binary.
I haven't been following this, mostly because I've been away, but:
Previously (in the Comet adv
On Tue, Feb 20, 2018 at 11:58:39AM +, Andrew Cooper wrote:
> c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally
> ended up shadowing the "struct domain *d" function parameter. Rename the
> former to desc.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Wei Liu writes ("Re: [OSSTEST PATCH v2 00/19] Upgrade to Stretch"):
> IIRC Ian suggested you copy one of the udev rules from Jessie's d-i to
> the initrd osstest generated for stretch, and perhaps copy it to the
> installed OS as well. I can't remember which files and don't have a
> jessie system t
On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in
> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
> advertised/hidden.
>
This setup works only because CR4.TSD=0?
> At the moment,
On 20/02/18 15:22, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
>> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value
>> in
>> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
>> advertised/hidden.
>>
> This setup work
On Tue, Feb 20, 2018 at 03:26:20PM +, Andrew Cooper wrote:
> On 20/02/18 15:22, Wei Liu wrote:
> > On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
> >> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the
> >> value in
> >> MSR_TSC_AUX, irrespective of whether t
On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote:
> Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
> the way of some intended cleanup.
>
> * Drop the rdtscp parameter and always make the caller responsible for ecx
>updates when appropriate.
> * Swi
On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in
> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
> advertised/hidden.
>
> At the moment, paravirt_ctxt_switch_to() only writes to MS
On Tue, Feb 20, 2018 at 03:09:18PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH] build: remove shim related targets"):
> > There's no need to have shim specific targets, so just use the regular
> > xen makefile targets in order to build the shim binary.
>
> I haven't been following
Roger Pau Monné writes ("Re: [PATCH] build: remove shim related targets"):
> On Tue, Feb 20, 2018 at 03:09:18PM +, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH] build: remove shim related targets"):
> > > There's no need to have shim specific targets, so just use the regular
> > > xen
>>> On 20.02.18 at 15:37, wrote:
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE
> KCONFIG_CONFIG=$(CURDIR)/shim.config
>
> xen-shim: $(D) shim-olddefconfig
> - $(MAKE) -C $(D)/xen install-shim \
>
On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote:
> Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
> the way of some intended cleanup.
>
> * Drop the rdtscp parameter and always make the caller responsible for ecx
>updates when appropriate.
> * Swi
On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
>
> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
> be unreachable. However, this appears to be a "feature" of TSC_MODE_PVRDTSCP,
On 20/02/18 16:04, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote:
>> Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
>> the way of some intended cleanup.
>>
>> * Drop the rdtscp parameter and always make the caller responsible
flight 119702 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119702/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 119539
test-armhf-armhf-libvirt-raw 13 saveresto
On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
>
> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
> be unreachable. However, this appears to be a "feature" of TSC_MODE_PVRDTSCP,
On Tue, 20 Feb 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 19/02/18 21:58, Stefano Stabellini wrote:
> > diff --git a/docs/misc/xen-command-line.markdown
> > b/docs/misc/xen-command-line.markdown
> > index 2184cb9..8997904 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc
On 20/02/18 16:28, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
>> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
>>
>> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
>> be unreachable. However, this
On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
> There are many problems with MSR_TSC_AUX handling.
>
> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
^
begin
> RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally
> depends
On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
> There are many problems with MSR_TSC_AUX handling.
>
> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
> RDTSCP feature which enumerates the MSR. Therefore, RDPID functionally
> depends on RDTSCP.
>
> For
On Tue, Feb 20, 2018 at 04:37:51PM +, Andrew Cooper wrote:
> On 20/02/18 16:28, Roger Pau Monné wrote:
> > On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
> >> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
> >>
> >> To start with, RDTSCP is hidden from PV
On 20/02/18 17:03, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
>> There are many problems with MSR_TSC_AUX handling.
>>
>> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
> ^
> begin
>
>> RDTSCP feature which enumerates the MS
flight 119698 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd broken
test-amd64-amd64-xl-qemuu-ws16-amd64 17
flight 119692 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119692/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 119644
test-amd64-amd64-xl-qemuu-win7-amd6
On 20/02/18 17:35, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
>> There are many problems with MSR_TSC_AUX handling.
>>
>> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
>> RDTSCP feature which enumerates the MSR. Therefore, R
flight 119687 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119687/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 118324
test-amd64-i386-xl-
On Tue, Feb 20, 2018 at 3:37 AM, Alexandru Stefan ISAILA
wrote:
> On Lu, 2018-02-19 at 08:25 -0700, Tamas K Lengyel wrote:
>> On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila
>> wrote:
>> >
>> > At this moment the CPUID events for the AMD architecture are not
>> > forwarded to the monitor layer.
On Tue, 20 Feb 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 19/02/18 21:58, Stefano Stabellini wrote:
> > On big.LITTLE systems not all cores have the same midr. Instead of
> > storing only one vpidr per domain, make it per vcpu and initialize it to
> > the value of the midr of the pcpu where th
On Tue, 20 Feb 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 19/02/18 21:58, Stefano Stabellini wrote:
> > On big.LITTLE systems the cacheline size might differ between big and
> > LITTLE cores. Instead of reading the cacheline size once at boot,
> > read it as needed from the system registers.
>
flight 119752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119752/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi,
On 20/02/2018 21:03, Stefano Stabellini wrote:
On Tue, 20 Feb 2018, Julien Grall wrote:
On 19/02/18 21:58, Stefano Stabellini wrote:
+mrc CP32(r6, CSSELR_EL1)
The size of the cache is read using CSSIDR_EL1. But it looks like the way we
get the cache line size in Xen is fragile.
On 20/02/2018 21:16, Julien Grall wrote:
> Hi,
>
> On 20/02/2018 21:03, Stefano Stabellini wrote:
>> On Tue, 20 Feb 2018, Julien Grall wrote:
>>> On 19/02/18 21:58, Stefano Stabellini wrote:
+ mrc CP32(r6, CSSELR_EL1)
>>>
>>> The size of the cache is read using CSSIDR_EL1. But it l
I've seen patch 1 and 3 are in but this one isn't. Any status on it?
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 02/20/2018 05:00 PM, Brian Woods wrote:
> I've seen patch 1 and 3 are in but this one isn't. Any status on it?
>
That's possibly because you needed an SVM maintainer ACK.
I think Jan was waiting for decision on how to present the ASSERT. From
the 3 options I slightly more prefer
ASSERT(neste
On Tue, Feb 20, 2018 at 05:09:24PM -0500, Boris Ostrovsky wrote:
> That's possibly because you needed an SVM maintainer ACK.
>
> I think Jan was waiting for decision on how to present the ASSERT. From
> the 3 options I slightly more prefer
>
> ASSERT(nestedhvm_enabled(v->domain) || !(v->arch.hvm_
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/nestedsvm.c| 66 +
xen/arch/x86/hvm/svm/svm.c | 6 +++
xen/arch/x86/hvm/svm/vmcb.c
On 02/20/2018 05:27 PM, Brian Woods wrote:
> Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Brian Woods
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists
On Mon, 19 Feb 2018 02:45:27 +0800 kbuild test robot wrote:
> [auto build test ERROR on mmotm/master]
> [also build test ERROR on v4.16-rc1 next-20180216]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0da
On Tue, 20 Feb 2018, Julien Grall wrote:
> On 20/02/2018 21:16, Julien Grall wrote:
> > Hi,
> >
> > On 20/02/2018 21:03, Stefano Stabellini wrote:
> >> On Tue, 20 Feb 2018, Julien Grall wrote:
> >>> On 19/02/18 21:58, Stefano Stabellini wrote:
> + mrc CP32(r6, CSSELR_EL1)
> >>>
> >>>
This patch series adds support and enablement of the pause filtering
threshold. Once there's pause filtering threshold amount of cycles
between pauses, the pause filtering counter resets to what was in the
VMCB. This allows the pause filtering count to "reset" between pauses
and keeps the guset f
Add support for enabling the pause filtering threshold feature. This
causes the pause filtering count to reset if there's pause filtering
threshold cycles or greater between pauses. See AMD APM Vol 2 Section
15.14.4 for more details.
The values of the pause filtering count and threshold were fou
If available, enable the pause filtering threshold feature. See the
previous commit for more information.
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/svm.c | 1 +
xen/arch/x86/hvm/svm/vmcb.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x
On Thu, 15 Feb 2018, Julien Grall wrote:
> PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed
> via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or
> earlier) and the function return an error, then we considered SMCCC 1.0
> is implemented.
>
> Signed-off-by: Juli
HW Setup:
CPU: AMD EPYC 7401 24c/48t x 2
RAM: 128GB RAM
Storage: HDD for dom0, SSDs for VMs
SW Setup:
Xen base 4c7e478d597b0346eef3a256cfd6794ac778b608
32 VMs
6 VPCUs per VM
3.5GB RAM per VM
7.5GB disk per VM
1 - 100 of 121 matches
Mail list logo
