>>> On 24.01.18 at 14:12, wrote:
> void __init init_speculation_mitigations(void)
> {
> enum ind_thunk thunk = THUNK_DEFAULT;
> +bool ibrs = false;
>
> /*
> * Has the user specified any custom BTI mitigations? If so, follow
> their
> * instructions exactly and disab
At the same time also report the state of the two defined
ARCH_CAPABILITIES MSR bits (but don't expose the MSR to guests yet).
Signed-off-by: Jan Beulich
---
Should we disable XPTI right here when we find RDCL_NO?
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -21,7 +21,7 @@
#
On 01/25/2018 11:37 PM, Julien Grall wrote:
Hi,
I forgot to mention one thing about the placement of
do_fixup_vgic_errata.
On 16/01/18 15:42, mja...@caviumnetworks.com wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..d4f0581d33 100644
--- a/xen/arch/arm/tra
Support both a "disable everything" and a "disable all RSB overwriting"
sub-option.
Signed-off-by: Jan Beulich
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -246,7 +246,7 @@ enough. Setting this to a high value may
the NMI watchdog is also enabled.
##
On 01/25/2018 10:30 PM, Julien Grall wrote:
Hi Manish,
On 16/01/18 15:43, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
In order to be able to trap Group-1 GICv3 system registers, we need to
set ICH_HCR_EL2.TALL1 before entering the guest. This is controlled by
the command line parame
On 01/25/2018 10:22 PM, Julien Grall wrote:
Hi,
On 16/01/18 15:43, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
gicv3_ich_read/write_lr functions are static in gic-v3.c
This patch creates wrapper functions which can be used from outside
the file.
Signed-off-by: Manish Jaggi
---
From: Oleksandr Andrushchenko
Hi, all!
While working on DRM PV frontend driver I faced an issue with
driver removal, e.g. when driver's .remove callback is called
the driver is already disconnected form the xenbus and it is not
possible to synchronize the process of removal with the backend.
Bac
On 01/25/2018 10:14 PM, Julien Grall wrote:
Hi Manish,
On 16/01/18 15:42, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.
This commit (and likely the follo
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove callback.
This makes it impossible for the driver to listen to backend's
state changes and synchronize the removal procedure.
Fix this by removing oth
>>> On 24.01.18 at 14:12, wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -383,6 +383,16 @@ static void __init calculate_pv_max_policy(void)
> /* Unconditionally claim to be able to set the hypervisor bit. */
> __set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
>
>
>>> On 01.02.18 at 08:29, wrote:
> On 01/02/18 07:20, Zhang, Xiong Y wrote:
>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ]
>> (XEN) CPU:0
>> (XEN) RIP:e033:[]
>> (XEN) RFLAGS: 0292 EM: 1 CONTEXT: pv guest (
>>> On 31.01.18 at 13:50, wrote:
> For a release build, bloat-o-meter reports:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111)
> function old new delta
> x86_emulate 126458 121347 -5111
>
> or in other
On 01/02/18 10:14, Jan Beulich wrote:
On 01.02.18 at 08:29, wrote:
>> On 01/02/18 07:20, Zhang, Xiong Y wrote:
>>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>>> (XEN) [ Xen-4.11-unstable x86_64 debug=y Not tainted ]
>>> (XEN) CPU:0
>>> (XEN) RIP:e033:[]
>>> (XEN) RFLAGS: 0
On 01/02/2018 09:20, Jan Beulich wrote:
On 31.01.18 at 13:50, wrote:
>> For a release build, bloat-o-meter reports:
>>
>> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111)
>> function old new delta
>> x86_emulate
On Wed, Jan 31, 2018 at 09:55:21AM -0700, Jan Beulich wrote:
> There are multiple issues here, and I'm happy to split the patch up if
> that's what it takes:
> - "set -e" on a separate Makefile line is meaningless. Glue together all
> the lines that this is supposed to cover.
> - I have no idea w
On Wed, Jan 31, 2018 at 08:33:46AM -0700, Jan Beulich wrote:
> Current upstream gas silently assumes 32-bit operand size for most
> operations where the size can't be inferred from an involved register
> (my own one doesn't anymore, which is how I've noticed this). It is pure
> luck that the 3 byte
>>> On 01.02.18 at 11:01, wrote:
> On Wed, Jan 31, 2018 at 09:55:21AM -0700, Jan Beulich wrote:
>> --- a/tools/firmware/xen-dir/Makefile
>> +++ b/tools/firmware/xen-dir/Makefile
>> @@ -16,18 +16,18 @@ DEP_FILES=$(foreach i, $(LINK_FILES), $(
>>
>> linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
On Tue, Jan 30, 2018 at 12:57:28PM -0600, Michael Glasgow wrote:
> Roger Pau [Monn_] wrote:
> > On Fri, Jan 26, 2018 at 01:54:30PM -0600, Michael Glasgow wrote:
> > > This recent patch can be simplified a bit. (The patch below is
> > > untested, just a suggestion.)
> >
> > Thanks, this LGTM, but
>>> On 30.01.18 at 18:50, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4126,6 +4126,10 @@ int xenmem_add_to_physmap_one(
> }
> case XENMAPSPACE_gmfn_foreign:
> return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
> +case XENMA
>>> On 01.02.18 at 11:13, wrote:
> On Tue, Jan 30, 2018 at 12:57:28PM -0600, Michael Glasgow wrote:
>> Roger Pau [Monn_] wrote:
>> > On Fri, Jan 26, 2018 at 01:54:30PM -0600, Michael Glasgow wrote:
>> > > This recent patch can be simplified a bit. (The patch below is
>> > > untested, just a sugge
On Thu, Feb 01, 2018 at 03:11:28AM -0700, Jan Beulich wrote:
> >>> On 01.02.18 at 11:01, wrote:
> > On Wed, Jan 31, 2018 at 09:55:21AM -0700, Jan Beulich wrote:
> >> --- a/tools/firmware/xen-dir/Makefile
> >> +++ b/tools/firmware/xen-dir/Makefile
> >> @@ -16,18 +16,18 @@ DEP_FILES=$(foreach i, $(L
On Thu, Feb 01, 2018 at 03:25:50AM -0700, Jan Beulich wrote:
> >>> On 01.02.18 at 11:13, wrote:
> > On Tue, Jan 30, 2018 at 12:57:28PM -0600, Michael Glasgow wrote:
> >> Roger Pau [Monn_] wrote:
> >> > On Fri, Jan 26, 2018 at 01:54:30PM -0600, Michael Glasgow wrote:
> >> > > This recent patch can
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
may have broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus
applications are in charge of exchange xenbus message exchange with the
correct header a
Hi Manish,
On 01/02/18 08:51, Manish Jaggi wrote:
On 01/25/2018 11:37 PM, Julien Grall wrote:
Hi,
I forgot to mention one thing about the placement of
do_fixup_vgic_errata.
On 16/01/18 15:42, mja...@caviumnetworks.com wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6
Hi Manish,
On 01/02/18 08:57, Manish Jaggi wrote:
On 01/25/2018 10:14 PM, Julien Grall wrote:
Hi Manish,
On 16/01/18 15:42, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_E
On Fri, Jan 26, 2018 at 03:29:10PM +, Roger Pau Monne wrote:
> Disable SMAP in the shim before bouncing the hypercall, or else L0
> will fail to get the hypercall buffer.
>
> Signed-off-by: Roger Pau Monné
> Reported-by: Fatih Acar
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Ian Jack
Hi,
On 31/01/18 16:30, Julien Grall wrote:
>
>
> On 31/01/18 15:54, Andre Przywara wrote:
>> Hi,
>>
>> Yeah! Locking discussions! Have fun below ;-)
>>
>> On 30/01/18 13:19, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 24/01/18 18:10, Andre Przywara wrote:
At the moment we happily access VG
When running as Xen pv guest %gs is initialized some time after
C code is started. Depending on stack protector usage this might be
too late, resulting in page faults.
So setup %gs and MSR_GS_BASE in assembly code already.
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
arch/x86/xen
On 01/02/18 12:16, Juergen Gross wrote:
> When running as Xen pv guest %gs is initialized some time after
> C code is started. Depending on stack protector usage this might be
> too late, resulting in page faults.
>
> So setup %gs and MSR_GS_BASE in assembly code already.
>
> Cc: sta...@vger.kernel
On 01/02/18 13:22, Andrew Cooper wrote:
> On 01/02/18 12:16, Juergen Gross wrote:
>> When running as Xen pv guest %gs is initialized some time after
>> C code is started. Depending on stack protector usage this might be
>> too late, resulting in page faults.
>>
>> So setup %gs and MSR_GS_BASE in as
On 01/02/18 08:52, Jan Beulich wrote:
> At the same time also report the state of the two defined
> ARCH_CAPABILITIES MSR bits (but don't expose the MSR to guests yet).
>
> Signed-off-by: Jan Beulich
> ---
> Should we disable XPTI right here when we find RDCL_NO?
I was planning to wait for a work
On 01/02/18 08:52, Jan Beulich wrote:
> @@ -268,6 +271,8 @@ functionality is still set up so IBRS ca
> On hardware supporting IBPB, the `ibpb=` option can be used to prevent Xen
> from issuing Branch Prediction Barriers on vcpu context switches.
>
> +The `rsb=` option can be used to uniformly s
When running as Xen pv guest %gs is initialized some time after
C code is started. Depending on stack protector usage this might be
too late, resulting in page faults.
So setup %gs and MSR_GS_BASE in assembly code already.
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
arch/x86/xen
flight 118509 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118509/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 1
>>> On 01.02.18 at 13:29, wrote:
> On 01/02/18 08:52, Jan Beulich wrote:
>> At the same time also report the state of the two defined
>> ARCH_CAPABILITIES MSR bits (but don't expose the MSR to guests yet).
>>
>> Signed-off-by: Jan Beulich
>> ---
>> Should we disable XPTI right here when we find R
flight 118471 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118471/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-armhf-pvops 4 host-instal
Hi,
On 30/01/18 14:36, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
>> On ARM the maximum number of IRQs is a constant, but we share it being
>> a variable to match x86. Since we are not supposed to alter it, let's
>> mark it as "const" to avoid accident
On 01/02/18 13:18, Jan Beulich wrote:
On 01.02.18 at 13:29, wrote:
>> On 01/02/18 08:52, Jan Beulich wrote:
>>> At the same time also report the state of the two defined
>>> ARCH_CAPABILITIES MSR bits (but don't expose the MSR to guests yet).
>>>
>>> Signed-off-by: Jan Beulich
>>> ---
>>> Sh
On 01/02/18 13:42, Andrew Cooper wrote:
> On 01/02/18 13:18, Jan Beulich wrote:
>
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -244,6 +244,7 @@ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /
XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+
Hi Andre,
On 01/02/18 13:43, Andre Przywara wrote:
On 30/01/18 14:36, Roger Pau Monné wrote:
On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
On ARM the maximum number of IRQs is a constant, but we share it being
a variable to match x86. Since we are not supposed to alter it, le
On Wed, Jan 31, 2018 at 8:36 PM, Andrii Anisov wrote:
> Hello Saumya,
>
>
> On 18.01.18 09:50, Saumya Rajesh wrote:
>>
>> Actually I am planning to set up Android as guest in Xen.
>
> I see.
>
>> In order to enable sound in the Android guest, I need to passthrough the
>> audio codec device which c
On 01/02/18 09:06, Jan Beulich wrote:
On 24.01.18 at 14:12, wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -383,6 +383,16 @@ static void __init calculate_pv_max_policy(void)
>> /* Unconditionally claim to be able to set the hypervisor bit. */
>> __set_bit(X
On Thu, Feb 01, 2018 at 01:43:09PM +, Andre Przywara wrote:
> Hi,
>
> On 30/01/18 14:36, Roger Pau Monné wrote:
> > On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
> >> On ARM the maximum number of IRQs is a constant, but we share it being
> >> a variable to match x86. Since we
On 01/02/18 08:41, Jan Beulich wrote:
On 24.01.18 at 14:12, wrote:
>> void __init init_speculation_mitigations(void)
>> {
>> enum ind_thunk thunk = THUNK_DEFAULT;
>> +bool ibrs = false;
>>
>> /*
>> * Has the user specified any custom BTI mitigations? If so, follow
>>
On 31/01/18 06:57, Juergen Gross wrote:
> * per-CPU/L4-shadowing (fairly-RFC)
> - Andrew Cooper
Probably best to drop this from the list. Given the technical
complications, it may never go in.
> * Mitigations for SP2/CVE-2017-5715/Branch Target Injection (v7)
> - Andrew Cooper
Now commi
Hi,
On 01/02/18 13:47, Julien Grall wrote:
> Hi Andre,
>
> On 01/02/18 13:43, Andre Przywara wrote:
>> On 30/01/18 14:36, Roger Pau Monné wrote:
>>> On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
On ARM the maximum number of IRQs is a constant, but we share it being
a v
This patch was originally released as part of XSA-226. It retains the same
command line syntax (as various downstreams are mitigating XSA-226 using this
mechanism) but the defaults have been updated due to the revised XSA-226
patched, after which transitive grants are believed to functioning
prope
On 01/02/18 14:34, Andre Przywara wrote:
Hi,
Hi,
On 01/02/18 13:47, Julien Grall wrote:
Hi Andre,
On 01/02/18 13:43, Andre Przywara wrote:
On 30/01/18 14:36, Roger Pau Monné wrote:
On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
On ARM the maximum number of IRQs is a co
Hi,
On 01/02/18 13:57, Roger Pau Monné wrote:
> On Thu, Feb 01, 2018 at 01:43:09PM +, Andre Przywara wrote:
>> Hi,
>>
>> On 30/01/18 14:36, Roger Pau Monné wrote:
>>> On Wed, Jan 24, 2018 at 06:10:58PM +, Andre Przywara wrote:
On ARM the maximum number of IRQs is a constant, but we sh
Hi,
On 01/02/18 14:39, Julien Grall wrote:
>
>
> On 01/02/18 14:34, Andre Przywara wrote:
>> Hi,
>
> Hi,
>
>> On 01/02/18 13:47, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 01/02/18 13:43, Andre Przywara wrote:
On 30/01/18 14:36, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 06:10
flight 118474 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118474/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118449
test-armhf-armhf-libvirt 14 sav
On Thu, Feb 1, 2018 at 12:31 AM, Razvan Cojocaru
wrote:
> On 01/29/2018 11:48 PM, Razvan Cojocaru wrote:
>> On exit, xen-access did not unsubscribe from CR4 write vm_events,
>> potentially leaving the guest stuck.
>>
>> Signed-off-by: Razvan Cojocaru
Acked-by: Tamas K Lengyel
>>
>> ---
>> Chan
On 31/01/18 11:00, Jan Beulich wrote:
On 30.01.18 at 20:26, wrote:
>> On 30/01/18 08:39, Jan Beulich wrote:
>> On 29.01.18 at 16:38, wrote:
+/*
+ * We are the CPU performing the patching, and might have ended up
here by
+ * hitting a breakpoint.
+
On Thu, Feb 1, 2018 at 9:57 AM, Rafael J. Wysocki wrote:
> On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko
> wrote:
>> On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki wrote:
>>> On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko
>>> wrote:
>> Instead of declaring function as __weak, establis
flight 118488 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118488/
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
test-arm64-arm64-xl 1 build-check
On 07/12/17 14:02, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 01.02.18 at 16:20, wrote:
> On 31/01/18 11:00, Jan Beulich wrote:
> On 30.01.18 at 20:26, wrote:
>>> On 30/01/18 08:39, Jan Beulich wrote:
>>> On 29.01.18 at 16:38, wrote:
> +/*
> + * We are the CPU performing the patching, and might have ended up
> here by
>>
Hi Jan,
2018-02-01 18:23 GMT+08:00 Jan Beulich :
On 30.01.18 at 18:50, wrote:
[...]
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -521,6 +521,12 @@ static XSM_INLINE int
>> xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
>> return xsm_default_acti
Currently, Xen is considering that an IO could either be handled or
unhandled. When unhandled, the stage-2 abort function will try another
way to resolve the abort.
However, the MMIO emulation may return unhandled when the address
belongs to an emulated range but was not correct. In that case, Xen
Now the MMIO emulation is able to distinguish unhandled IO from aborted
one, there are no need to crash the domain when the region is access
with a bad width.
Instead let Xen inject a data abort to the guest and decide what to do.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Hi all,
This small series replaces all call to domain_crash_synchronous by injecting
an exception to the guest.
This will result to a nicer trace from the guest (no need to manually walk
the stack) and give a chance to the guest to give a bit more information on
what it was doing.
Cheers,
Julie
domain_crash_synchronous() should only be used when something went wrong
in Xen. It is better to inject to the guest as it will be in a better
position to provide helpful information (stack trace...).
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
We potentially want to re
Hi,
I'm working on switching to PSCI v1.0 in Xen (needed to support suspend
to RAM).
In addition to updates in PSCI implementation, we assumed that
compatible property in psci device tree node should be extended with
"arm,psci-1.0" (not a must since this doesn't affect Dom0's
functionality
On Thu, 1 Feb 2018, Julien Grall wrote:
> Currently, Xen is considering that an IO could either be handled or
> unhandled. When unhandled, the stage-2 abort function will try another
> way to resolve the abort.
>
> However, the MMIO emulation may return unhandled when the address
> belongs to an e
On 01/02/18 19:00, Mirela Simonovic wrote:
Hi,
Hi Mirela,
I'm working on switching to PSCI v1.0 in Xen (needed to support suspend > to
RAM).
I am about to send a series to add support for PSCI 1.1 (I need it for
the spectre mitigation). I can send you a temporary branch if you want
to
(sorry for the formatting)
On 1 Feb 2018 19:05, "Stefano Stabellini" wrote:
On Thu, 1 Feb 2018, Julien Grall wrote:
> Currently, Xen is considering that an IO could either be handled or
> unhandled. When unhandled, the stage-2 abort function will try another
> way to resolve the abort.
>
> Howev
On Tue, 30 Jan 2018, Julien Grall wrote:
> Xen does not properly support big.LITTLE platform. All vCPUs of a guest
> will always have the MIDR of the boot CPU (see arch_domain_create).
> At best the guest may see unreliable performance (vCPU switching between
> big and LITTLE), at worst the guest w
On 07/12/17 14:03, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -370,7 +370,7 @@ static const struct {
> [0x0c ... 0x0f] = { .simd_size = simd_packed_fp },
> [0x10] = { .simd_size = simd_packed_int },
> [0x13] =
No functional change, but it makes the diff context line more helpful when
reviewing patches which alter the opcode tables. e.g. Consider:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -370,7 +370,7 @@ static const struct {
[0x0c ... 0x0
On 1 February 2018 at 19:37, Stefano Stabellini wrote:
> On Tue, 30 Jan 2018, Julien Grall wrote:
>> Xen does not properly support big.LITTLE platform. All vCPUs of a guest
>> will always have the MIDR of the boot CPU (see arch_domain_create).
>> At best the guest may see unreliable performance (v
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Current xenbus frontend driver removal flow first disconnects
> the driver from xenbus and then calls driver's remove callback.
> This makes it impossible for the driver to listen to backend's
> state change
On 02/01/2018 07:40 AM, Juergen Gross wrote:
> When running as Xen pv guest %gs is initialized some time after
> C code is started. Depending on stack protector usage this might be
> too late, resulting in page faults.
>
> So setup %gs and MSR_GS_BASE in assembly code already.
>
> Cc: sta...@vger.k
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove callback.
This makes it impossible for the d
On 07/12/17 14:03, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -391,6 +391,7 @@ static const struct {
> [0x78 ... 0x79] = { .simd_size = simd_other, .two_op = 1 },
> [0x8c] = { .simd_size = simd_other },
> [0x8
On 02/01/2018 03:24 PM, Oleksandr Andrushchenko wrote:
>
>
> On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
>> On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Current xenbus frontend driver removal flow first disconnects
>>> the driver from xenbus a
flight 118483 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118483/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR.
vs. 118291
Tests whic
Works great, tested it and it fixes booting Linux v4.15 kernel for me :)
Cheers!
On Thu, Feb 1, 2018 at 3:17 PM, Boris Ostrovsky
wrote:
> On 02/01/2018 07:40 AM, Juergen Gross wrote:
>> When running as Xen pv guest %gs is initialized some time after
>> C code is started. Depending on stack prote
flight 118487 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken in 118314
test-amd64-i386-xl-qemuu-ws
flight 118490 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118490/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 118315
Tests which di
Over the next few weeks, the Automotive Grade Linux (AGL) community will draft
a white paper [1] on virtualization. I'm assisting Lars with coordination of
Xen contributions. Here is a summary of discussions preceding this message:
https://docs.google.com/document/d/1-_Uyi46L2jqrNKyOxo4GLI4
flight 118502 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On 02/01/2018 11:09 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:24 PM, Oleksandr Andrushchenko wrote:
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconn
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvhv2-intel
testid guest-start
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditio
83 matches
Mail list logo
