On 01/31/2018 06:57 AM, Juergen Gross wrote:
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.11 so that people have an idea what is going on and
prioritise accordingly.
snip>
* Mitigations for SP2/CVE-2017-5715/Branch Target Injection (v7)
On Wed, Jan 31, 2018 at 07:57:51AM +0100, Juergen Gross wrote:
> === x86 ===
* PCI config space emulation in Xen for PVH Dom0 (v8)
- Roger Pau Monné
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg02042.html
Thanks, Roger.
___
X
flight 118449 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118449/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118411
test-armhf-armhf-libvirt 14 sav
flight 118462 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118462/
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 31.01.18 at 07:57, wrote:
> === x86 ===
>
> * Enable Memory Bandwidth Allocation in Xen (v10)
> - XEN-48
> - Yi Sun
I think this has all gone in, the tools parts a little less than two weeks
ago.
Jan
___
Xen-devel mailing list
Xen-dev
>>> On 30.01.18 at 15:29, wrote:
> On 23/01/18 10:38, Jan Beulich wrote:
>> When XPTI is active, the CR3 load in restore_all_guest is sufficient
>> when switching to user mode, improving in particular system call and
>> page fault exit paths for the guest.
>>
>> Signed-off-by: Jan Beulich
>
> Wh
flight 118472 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118472/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 16a31ca735165e63d67e86f60996f2b6a31cc0ee
baseline version:
xen 4c7e
>>> On 30.01.18 at 18:12, wrote:
> On 30/01/18 16:40, Jan Beulich wrote:
> On 22.01.18 at 13:32, wrote:
>>> +static int pv_vcpu_init_xpti(struct vcpu *v)
>>> +{
>>> +struct domain *d = v->domain;
>>> +struct page_info *pg;
>>> +void *ptr;
>>> +struct cpu_info *info;
>>> +u
>>> On 22.01.18 at 13:32, wrote:
> For support of per-vcpu stacks we need per-vcpu trampolines. To be
> able to put those into the per-domain mappings the upper levels
> page tables must not have NX set for per-domain mappings.
>
> In order to be able to reset the NX bit for a per-domain mapping
On 31/01/18 06:07, Juergen Gross wrote:
> On 30/01/18 20:26, Andrew Cooper wrote:
>> However, there is literally nothing we can do to prevent #MC from
>> arriving. We can stop servicing #MC by disabling CR4.MCE, but then the
>> processor will shut down.
> Hmm, there is a way to avoid #MC on other
>>> On 30.01.18 at 18:19, wrote:
> On 30/01/18 17:07, Jan Beulich wrote:
> On 22.01.18 at 13:32, wrote:
>>> --- a/xen/arch/x86/x86_64/asm-offsets.c
>>> +++ b/xen/arch/x86/x86_64/asm-offsets.c
>>> @@ -137,6 +137,10 @@ void __dummy__(void)
>>> OFFSET(CPUINFO_processor_id, struct cpu_info,
A command line such as "cpuid=no-ibrsb,no-stibp" tickles a bug in
parse_boolean() because the separating comma fails the NUL case.
Instead, check for slen == nlen which accounts for the boundary (if any)
passed via the 'e' parameter.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
This wants
>>> On 30.01.18 at 18:33, wrote:
> On 30/01/18 17:33, Jan Beulich wrote:
> On 22.01.18 at 13:32, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -1585,9 +1585,28 @@ static inline bool need_full_gdt(const struct domain
>>> *d)
>>> return is_pv_domain(d) && !
>>> On 31.01.18 at 11:36, wrote:
> A command line such as "cpuid=no-ibrsb,no-stibp" tickles a bug in
> parse_boolean() because the separating comma fails the NUL case.
>
> Instead, check for slen == nlen which accounts for the boundary (if any)
> passed via the 'e' parameter.
>
> Signed-off-by:
>>> 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.
>>> + *
>>> + * Either way, we need to complet
>>> On 30.01.18 at 16:56, wrote:
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one cosmetic remark:
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -442,6 +442,21 @@ int main(int argc, char **argv)
> goto fa
>>> On 30.01.18 at 16:56, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1935,36 +1935,67 @@ load_seg(
> return rc;
> }
>
> +/* Map GPRs by ModRM encoding to their offset within struct cpu_user_regs. */
> +static const uint8_t cpu
>>> On 30.01.18 at 16:56, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1957,9 +1957,8 @@ const uint8_t cpu_user_regs_gpr_offsets[] = {
> #endif
> };
>
> -void *
> -decode_register(
> -uint8_t modrm_reg, struct cpu_user_regs *reg
Right now,
http://logs.test-lab.xenproject.org/osstest/results/host/laxton1.html
contains ~200 jobs as expected, but that covers only 4 days. We
obviously would like more like a month.
The effect ought to be some more db work, but not worse concurrency.
CC: Julien Grall
Signed-off-by: Ian Jac
On 31/01/18 11:06, Jan Beulich wrote:
On 30.01.18 at 16:56, wrote:
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> with one cosmetic remark:
>
>> --- a/tools/tests/x86_emulator/test_x86_emulator.c
>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
>> @@ -442,6 +442,21 @@ int
On Wed, Jan 31, 2018 at 07:57:51AM +0100, Juergen Gross wrote:
> * Comet: Run PV in PVH container (v2)
> - Wei Liu
>
This is committed some time ago.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
Hi Julien,
On 31.01.18 00:06, Julien Grall wrote:
On 30 January 2018 at 19:35, Volodymyr Babchuk
wrote:
On 30.01.18 20:44, Julien Grall wrote:
On 30/01/18 18:28, Volodymyr Babchuk wrote:
Hi Julien,
On 30.01.18 20:01, Julien Grall wrote:
On 26/01/18 18:27, Volodymyr Babchuk wrote:
Hi,
On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2 functions
in it and
the number of PSCI calls. That's it.
Is this really a problem? It is quite natural to find declarations for
something.c in something.h. By moving declaration into
Hi Stefano,
On 31/01/18 00:01, Stefano Stabellini wrote:
> I am testing Xen support in ThunderX, but I am having some issues
> booting Dom0 using Xen staging and the Ubuntu Xenial kernel (it has
> CONFIG_XEN enabled). The trace is appened to this email. I am using the
> device tree converted from
Hi Stefano,
On 30/01/18 19:21, Stefano Stabellini wrote:
On Tue, 30 Jan 2018, Julien Grall wrote:
Hi,
On 30/01/18 18:29, Andrew Cooper wrote:
On 30/01/18 17:00, Julien Grall wrote:
On 30/01/18 16:38, Andrew Cooper wrote:
On 30/01/18 16:14, Julien Grall wrote:
Hi all,
This small series r
Hi Stefano,
On 30/01/18 19:09, Stefano Stabellini wrote:
On Tue, 30 Jan 2018, Julien Grall wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c8534d6cff..843adf4959 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1864,10 +1864,10 @@ static inline bool hpfar_i
flight 118479 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118479/
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
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 words, a 4% redunction in code size from this c
CC: Andrew Cooper
Reported-by: Andrew Cooper
Signed-off-by: Ian Jackson
---
SUPPORT.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 42ffa9f..a1810b8 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,7 +9,7 @@ for the definitions of the support s
CC: Andrew Cooper
Reported-by: Andrew Cooper
Signed-off-by: Ian Jackson
---
docs/process/release-checklist.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/process/release-checklist.txt
b/docs/process/release-checklist.txt
index b96964e..c791ad2 100644
--- a/docs/process/release-ch
Security-Support-Until should be `TBD'. We need to answer these
questions properly, but let's not block fixing the obvious bugs here
for that policy discussion.
CC: Andrew Cooper
CC: Lars Kurth
Reported-by: Andrew Cooper
Signed-off-by: Ian Jackson
---
SUPPORT.md | 6 +++---
1 file changed, 3
On 31/01/18 13:03, Ian Jackson wrote:
> CC: Andrew Cooper
> Reported-by: Andrew Cooper
> Signed-off-by: Ian Jackson
> ---
> docs/process/release-checklist.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/docs/process/release-checklist.txt
> b/docs/process/release-checklist.txt
> in
On 31/01/18 13:06, Ian Jackson wrote:
> Security-Support-Until should be `TBD'. We need to answer these
> questions properly, but let's not block fixing the obvious bugs here
> for that policy discussion.
>
> CC: Andrew Cooper
> CC: Lars Kurth
> Reported-by: Andrew Cooper
> Signed-off-by: Ian J
flight 118452 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118452/
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
Hi,
On 31.01.18 13:36, Julien Grall wrote:
Hi,
On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2 functions
in it and
the number of PSCI calls. That's it.
Is this really a problem? It is quite natural to find declarations
for something.
flight 118485 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118485/
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
>>> On 31.01.18 at 14:10, wrote:
> On 31/01/18 13:06, Ian Jackson wrote:
>> Security-Support-Until should be `TBD'. We need to answer these
>> questions properly, but let's not block fixing the obvious bugs here
>> for that policy discussion.
>>
>> CC: Andrew Cooper
>> CC: Lars Kurth
>> Reporte
On 31/01/18 14:29, Volodymyr Babchuk wrote:
Hi,
Hi Volodymyr,
On 31.01.18 13:36, Julien Grall wrote:
Hi,
On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2
functions in it and
the number of PSCI calls. That's it.
Is this really a p
On 31.01.18 16:54, Julien Grall wrote:
On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2
functions in it and
the number of PSCI calls. That's it.
Is this really a problem? It is quite natural to find declarations
for something.c in so
Hi, Eduardo!
I am working on a frontend driver (PV DRM) and also seeing some strange
things on driver unloading:
xt# rmmod -f drm_xen_front.ko
[ 3236.462497] [drm] Unregistering XEN PV vdispl
[ 3236.485745] [drm:xen_drv_remove [drm_xen_front]] *ERROR* Backend
state is InitWait while removing d
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 communicates through the I2C bus. For
BE/FE scheme, I think sharing the in
Hi,
On 30/01/18 11:31, Andrew Cooper wrote:
On 30/01/18 11:29, Julien Grall wrote:
Hi Andrew,
Thank you for doing the clean-up.
On 30/01/18 11:16, Andrew Cooper wrote:
ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
!HAS_ALTERNATIVE code in include/asm-arm/alternative.h
On 26/01/18 16:21, Julien Grall wrote:
"Therefore hypervisor code running with guest vectors table should be
minimized and always have interrupts and async aborts masked to reduce
the risk to use them."
Do you think that it is clearer?
Well, that was covered by "interrupts". If you look at t
Hi Stefano,
On 25/01/18 19:35, Stefano Stabellini wrote:
This means that bne will branch only when bit 2 is set. So the only way to end
here is because the first 3-bit are equal to 0x00X. This corresponds to
IRQ/FIQ vector.
I got it the other way around, thanks for the explanation :-)
Signed-
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 bytes following pvh_boot are currently padding ones.
Signed-off-by: Jan
On Mon, Jan 29, 2018 at 5:01 AM, Rafael J. Wysocki wrote:
> On Fri, Jan 26, 2018 at 7:08 PM, Andy Shevchenko
> wrote:
>> I have stumbled on the similar stuff and realize that.
>>
>> Perhaps, one of the solution is to have an additional struct under
>> x86_init to alternate ACPI related stuff.
>
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:
>> On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross wrote:
>>> On 26/01/18 19:08, Andy Shevchenko wrote:
On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross wrote:
The probl
On 31/01/18 15:33, 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 bytes following pvh_boot ar
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 VGIC internal data structures like
>> the rank and struct pending_irq in gic.c, which should be VGIC agnostic.
>>
>
Hi,
On 24/01/18 18:10, Andre Przywara wrote:
At the moment we happily access the VGIC internal struct pending_irq
(which describes a virtual IRQ) in irq.c.
Factor out the actually needed functionality to learn the associated
hardware IRQ and move that into gic-vgic.c to improve abstraction.
Sig
Hi,
On 31/01/18 16:16, Julien Grall wrote:
> Hi,
>
> On 24/01/18 18:10, Andre Przywara wrote:
>> At the moment we happily access the VGIC internal struct pending_irq
>> (which describes a virtual IRQ) in irq.c.
>> Factor out the actually needed functionality to learn the associated
>> hardware IR
On 31/01/18 16:24, Andre Przywara wrote:
Hi,
On 31/01/18 16:16, Julien Grall wrote:
Hi,
On 24/01/18 18:10, Andre Przywara wrote:
At the moment we happily access the VGIC internal struct pending_irq
(which describes a virtual IRQ) in irq.c.
Factor out the actually needed functionality to lea
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 VGIC internal data structures like
the rank and struct pending_irq in gic.c,
On Wed, 31 Jan 2018, Julien Grall wrote:
> On 26/01/18 16:21, Julien Grall wrote:
> > > "Therefore hypervisor code running with guest vectors table should be
> > > minimized and always have interrupts and async aborts masked to reduce
> > > the risk to use them."
> > >
> > > Do you think that it i
On Wed, 31 Jan 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 25/01/18 19:35, Stefano Stabellini wrote:
> > > This means that bne will branch only when bit 2 is set. So the only way to
> > > end
> > > here is because the first 3-bit are equal to 0x00X. This corresponds to
> > > IRQ/FIQ vector.
> >
From: Julien Grall
In order to avoid aliasing attacks against the branch predictor on
Cortex A-15, let's invalidate the BTB on guest exit, which can only be
done by invalidating the icache (with ACTLR[0] being set).
We use the same hack as for A12/A17 to perform the vector decoding.
This is bas
Hi all,
This series provides a skeleton for mitigating branch predictor hardening for
arm32 on exception entry.
It also implements mitigation for Cortex-A12, A15 and A17. SoC vendors with
affected CPUs are strongly encouraged to update.
For more information about the impact of this issue and the
From: Julien Grall
The only difference between all the DEFINE_TRAP_ENTRY_* macros are the
interrupts (Asynchronous Abort, IRQ, FIQ) unmasked.
Rather than duplicating the code, introduce __DEFINE_TRAP_ENTRY macro
that will take the list of interrupts to unmask.
This is part of XSA-254.
Signed-
From: Julien Grall
Cortex-A17 and A12 MIDR will be used in a follow-up patch for hardening
the branch predictor.
This is part of XSA-254.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/include/asm-arm/processor.
From: Julien Grall
Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.
This patch adds initiatial skeleton code behind a new Kconfig option
to enable implementatio
From: Julien Grall
At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
r0).
This is rather unintuitive and will result to execute the trap
undefined. Instead introduce trap helpers for reset and will generate an
error message in the unlikely case that reset will be called.
From: Julien Grall
It took me a bit of time to understand why __DEFINE_TRAP_ENTRY is
storing the original stack pointer in r11. It is working in pair with
return_traps_entry where sp will be restored from r11.
This is fine because per the AAPCS r11 must be preserved by the
subroutine. So in retu
From: Julien Grall
In order to avoid aliasing attackes agains the branch predictor, let's
invalidate the BTB on guest exist. This is made complicated by the fact
that we cannot take a branch invalidating the BTB.
This is based on the first version posrted by Marc Zyngier on Linux-arm
mailing lis
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 what *.d1 is supposed to refer to - we only have .*.d
and .*.d2 files
On Wed, 31 Jan 2018, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
> r0).
>
> This is rather unintuitive and will result to execute the trap
> undefined. Instead introduce trap helpers for reset and will generate an
> error
On Wed, 31 Jan 2018, Julien Grall wrote:
> From: Julien Grall
>
> Aliasing attacked against CPU branch predictors can allow an attacker to
> redirect speculative control flow on some CPUs and potentially divulge
> information from one context to another.
>
> This patch adds initiatial skeleton c
Hi,
On 31/01/18 16:53, Julien Grall wrote:
+GLOBAL(hyp_traps_vector_bp_inv)
+/*
+ * We encode the exception entry in the bottom 3 bits of
+ * SP, and we have to guarantee to be 8 bytes aligned.
+ */
+add sp, sp, #1 /* Reset7 */
On Wed, 31 Jan 2018, Julien Grall wrote:
> Hi,
>
> On 31/01/18 16:53, Julien Grall wrote:
> > +GLOBAL(hyp_traps_vector_bp_inv)
> > +/*
> > + * We encode the exception entry in the bottom 3 bits of
> > + * SP, and we have to guarantee to be 8 bytes aligned.
> > + */
On 31/01/18 17:39, Stefano Stabellini wrote:
On Wed, 31 Jan 2018, Julien Grall wrote:
Hi,
On 31/01/18 16:53, Julien Grall wrote:
+GLOBAL(hyp_traps_vector_bp_inv)
+/*
+ * We encode the exception entry in the bottom 3 bits of
+ * SP, and we have to guarantee to be 8 byt
> On 30. Jan 2018, at 22:56, Michael Young wrote:
>
> The ocaml safe-strings patch uses code introduced in ocaml 4.02
> so update the minimal version.
> Signed-off-by: Michael Young
> ---
> stubdom/configure| 4 ++--
> stubdom/configure.ac | 2 +-
> tools/configure | 2 +-
> tools/config
"
On Tue, Jan 30, 2018 at 2:16 AM, Razvan Cojocaru
wrote:
> The emulation layers of Xen lack PCID support, and as we only offer
> PCID to HAP guests, all writes to CR3 are handled by hardware,
> except when introspection is involved. Consequently, trying to set
> CR3 when the noflush bit is set i
On Wed, Jan 31, 2018 at 11:44 AM, Tamas K Lengyel wrote:
> "
>
> On Tue, Jan 30, 2018 at 2:16 AM, Razvan Cojocaru
> wrote:
>> The emulation layers of Xen lack PCID support, and as we only offer
>> PCID to HAP guests, all writes to CR3 are handled by hardware,
>> except when introspection is invol
On 07/12/17 14:00, Jan Beulich wrote:
> Note that this avoids emulating the behavior of VCVTPS2PH found on at
> least some Intel CPUs, which update MXCSR even when the memory write
> faults.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
X
flight 118456 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs.
118441
Tests which did
On 07/12/17 14:01, 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 Tue, Jan 30, 2018 at 11:31:27AM +, Andrew Cooper wrote:
> On 30/01/18 11:29, Julien Grall wrote:
> > Hi Andrew,
> >
> > Thank you for doing the clean-up.
> >
> > On 30/01/18 11:16, Andrew Cooper wrote:
> >> ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
> >> !HAS_ALTER
Corrects some EFER.SVME checks in intercepts. See AMD APM vol2 section
15.4 for more details. VMMCALL isn't checked due to guests needing it
to boot.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/nestedsvm.c | 10 --
xen/arch/x86/hvm/svm/svm.c |
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/svm.c | 69 +
xen/arch/x86/hvm/svm/vmcb.c | 17 ---
2 files changed, 69 insertions(+), 17 d
This is a small series of SVM cleanup patches. The first patch is
correcting a couple of checks relating to VGIF. The other two are
ensuring that nested SVM functionality is emulated/setup more
correctly.
Brian Woods (3):
x86/svm: update VGIF support
x86/svm: add EFER SVME support for VGIF/V
There are places where the GIF value is checked. A guest with VGIF
enabled can change the GIF value without the host being involved,
therefore it needs to check the GIF value in the VMCB rather the one in
the nestedsvm struct.
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/nestedsvm.c | 14
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvhv2-amd
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-traditiona
On Wed, 31 Jan 2018, Adi Pircalabu wrote:
(XEN) d8v0: unhandled page fault (ec=)
(XEN) Pagetable walk from 0028:
(XEN) L4[0x000] =
(XEN) domain_crash_sync called from entry.S: fault at 82d08022a472
create_bounce_frame+0x12b/0x13a
(XEN) Doma
flight 118464 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118464/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
test-amd64-amd64-xl
flight 118484 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118484/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 9eeb26f3faeb25925c0cfde9ec18571fdbfbe4fa
baseline version:
xtf bade68b7087acd6b5ca631
flight 118475 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd broken
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
On Wed, 31 Jan 2018, Michael Young wrote:
(XEN) Guest stack trace from rsp=82203e20:
(XEN) 81036a89
(XEN)0001e030 00010092 82203e68 e02b
(XEN) 00
On Wed, 31 Jan 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 30/01/18 19:09, Stefano Stabellini wrote:
> > On Tue, 30 Jan 2018, Julien Grall wrote:
> > > > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > > > index c8534d6cff..843adf4959 100644
> > > > > --- a/xen/arch/arm/traps.c
On 18-01-31 02:57:32, Jan Beulich wrote:
> >>> On 31.01.18 at 07:57, wrote:
> > === x86 ===
> >
> > * Enable Memory Bandwidth Allocation in Xen (v10)
> > - XEN-48
> > - Yi Sun
>
> I think this has all gone in, the tools parts a little less than two weeks
> ago.
>
Yes, all patches have b
flight 118465 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118465/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118446 pass
in 118465
test-xtf-amd64-amd64
flight 118468 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118468/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 118447
test-armhf-armhf-libvirt-xsm 14 saveresto
This is the message with debug=y
Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4)
5.4.0 20160609) debug=y Tue Jan 30 02:38:14 CST 2018
(XEN) Latest ChangeSet: Wed Jan 24 12:01:55 2018 + git:1252e28
(XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.8
(XE
Ian, Wei,
could you please take a look at the below?
Thank you,
Oleksandr
On 12/20/2017 06:27 PM, Oleksandr Andrushchenko wrote:
Hi, all!
While trying to reboot a domain which has iomem configured
(we are passing through some devices), I found an issue,
that after domain reboot those iomem'
At least Linux kernels have been able to work with gzip-ed initrd for
quite some time; initrd compressed with other methods aren't even being
attempted to unpack. Furthermore the unzip-ing routine used here isn't
capable of dealing with various forms of concatenated files, each of
which was gzip-ed
On 01/02/18 01:17, Michael Young wrote:
> On Wed, 31 Jan 2018, Michael Young wrote:
>
>> (XEN) Guest stack trace from rsp=82203e20:
>> (XEN)
>> 81036a89
>> (XEN) 0001e030 00010092 82203e68
>> 0
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
>
> ---
> Changes since V1:
> - Made all the ignored parameters of xc_monitor_write_ctrlreg() zeroes.
> --
On 01/02/18 07:20, Zhang, Xiong Y wrote:
> This is the message with debug=y
> Xen 4.11-unstable
> (XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4)
> 5.4.0 20160609) debug=y Tue Jan 30 02:38:14 CST 2018
> (XEN) Latest ChangeSet: Wed Jan 24 12:01:55 2018 + git:1252e2
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:
>>> On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross wrote:
On 26/01/18 19:08, Andy Shevchenko wrote:
> On Thu
97 matches
Mail list logo
