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
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 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 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
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
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'
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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: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
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 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 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 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 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.
> > + */
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:
> 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
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
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
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.
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
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
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.
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.
> >
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 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 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
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
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,
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.
>>
>
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
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 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.
>
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
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-
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,
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
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, 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
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
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 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
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
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 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
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
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
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
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
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
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
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
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
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 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,
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 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:
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
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 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
>>> 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:
> 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 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 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 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) && !
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: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,
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 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 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
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 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
>>> 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
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
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
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
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)
97 matches
Mail list logo
