flight 118524 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118524/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 118487
pass in 118524
test-amd64-i38
flight 118520 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118520/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in
118483 pass in 118520
test-amd64-amd64
flight 118515 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118515/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118474
test-armhf-armhf-libvirt 14 sav
When the client sends a regular blocking accept request, the backend is
expected to return only when the accept is completed, simulating a
blocking behavior, or return an error.
Specifically, on EAGAIN from inet_accept, the backend shouldn't return
"EAGAIN" to the client. Instead, it should simply
flight 118547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118547/
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 02/02/2018 10:32 AM, Arnd Bergmann wrote:
> The legacy hypercall handlers were originally added with
> a comment explaining that "copying the argument structures in
> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
> variable is sufficiently safe" and only made sure to n
On 02/02/2018 22:48, Stefano Stabellini wrote:
Committed, thanks
I know you acked/reviewed all the patches, but it would have been nice
to wait/give more feedback regarding Andre's valid point on patch #4.
Cheers,
On Fri, 2 Feb 2018, Julien Grall wrote:
Hi all,
This small series replac
Committed, thanks
On Fri, 2 Feb 2018, Julien Grall wrote:
> 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 g
flight 118544 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118544/
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
flight 118505 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118505/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 118468
test-armhf-armhf-libvirt-xsm 14 saveresto
flight 118532 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118532/
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
Committed, thanks
On Fri, 2 Feb 2018, Julien Grall wrote:
> 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 encourage
flight 118542 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118542/
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 Fri, Feb 2, 2018 at 12:56 AM, Juergen Gross wrote:
> On 02/02/18 01:36, Chris Patterson wrote:
>> Works great, tested it and it fixes booting Linux v4.15 kernel for me :)
>
> Can I add your "Tested-by:" to the patch when committing it?
>
>
Sure thing, have a great day.
___
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
afte
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
[ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ]
Add early interrupt handlers activated by idt_setup_early_handler() to
the handlers supported by Xen pv guests. This
>>> On 02.02.18 at 14:29, wrote:
> On 07/12/17 14:07, Jan Beulich wrote:
>> --- a/tools/tests/x86_emulator/x86-emulate.c
>> +++ b/tools/tests/x86_emulator/x86-emulate.c
>> @@ -120,6 +120,19 @@ int emul_test_read_cr(
>> return X86EMUL_UNHANDLEABLE;
>> }
>>
>> +int emul_test_read_xcr(
>> +
To match all our other emulation handling.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/pv/Makefile | 2 +-
xen/arch/x86/pv/{ro-page-fault.c => emul-ro-page-fault.c} | 2 +-
2 files changed, 2 insertions(+), 2 deletion
* Drop trailing whitespace
* Use ARRAY_SIZE() rather than opencoding it
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 13 ++---
xen/arch/x86/x86_emulate/x86_emulate.h | 12 ++--
2 files changed, 12 insertions(+), 13 deletions(-)
On 07/12/17 14:19, Jan Beulich wrote:
> @@ -298,14 +332,43 @@ hvm_emulate_cmpxchg(enum x86_segment seg
> if ( rc )
> return rc;
>
> +/* Unaligned writes are only acceptable on HVM */
> +if ( (addr & (bytes - 1)) && !is_hvm_vcpu(v) )
> +return X86EMUL_UNHANDLEABLE;
>
On 07/12/17 14:18, Jan Beulich wrote:
> @@ -1778,6 +1781,42 @@ void *sh_emulate_map_dest(struct vcpu *v
> return map;
> }
>
> +/**/
> +/* Optimization: If we see two emulated writes of zeros to the same
> + * page-table
On 07/12/17 14:17, Jan Beulich wrote:
> ..., at least as far as currently possible, i.e. when a mapping can be
> obtained.
>
> Signed-off-by: Jan Beulich
> ---
> v3: New.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1187,6 +1187,61 @@ static int hvmemul_write(
>
On 07/12/17 14:16, Jan Beulich wrote:
> ..., at least as far as currently possible, i.e. when a mapping can be
> obtained.
>
> Signed-off-by: Jan Beulich
> ---
> v3: New.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1296,8 +1296,83 @@ static int hvmemul_cmpxchg(
>
On Fri, Feb 02, 2018 at 05:11:02PM +0100, Arnd Bergmann wrote:
> On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter
> wrote:
> > On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:
> >> switch (cmd) {
> >> + case EVTCHNOP_bind_interdomain:
> >> + len = sizeof(struct ev
On 02/02/18 16:19, Jan Beulich wrote:
On 02.02.18 at 14:30, wrote:
>> On 07/12/17 14:08, Jan Beulich wrote:
>>> Experimentally MPX instructions have been confirmed to behave as NOPs
>>> unless both related XCR0 bits are set to 1. By implication branches
>>> then also don't clear BNDn.
>>>
>>>
On Vi, 2018-02-02 at 15:58 +, Andrew Cooper wrote:
> On 02/02/18 09:37, Alexandru Isaila wrote:
> >
> > This commit enables the breakpoint events for svm.
> >
> > Signed-off-by: Alexandru Isaila
> > ---
> > xen/arch/x86/hvm/svm/svm.c| 52
> > ---
> >
>>> On 02.02.18 at 14:41, wrote:
> On 07/12/17 14:11, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich
>> ---
>> v3: New.
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -5047,6 +5047,24 @@ x86_emulate(
>> goto done;
>>
flight 118539 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118539/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR.
vs. 118537
T
On 07/12/17 14:16, Jan Beulich wrote:
> In order to correctly emulate read-modify-write insns, especially
> LOCKed ones, we should not issue reads and writes separately. Use a
> new hook to combine both, and don't uniformly read the memory
> destination anymore. Instead, DstMem opcodes without Mov
>>> On 02.02.18 at 14:30, wrote:
> On 07/12/17 14:08, Jan Beulich wrote:
>> Experimentally MPX instructions have been confirmed to behave as NOPs
>> unless both related XCR0 bits are set to 1. By implication branches
>> then also don't clear BNDn.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/
On 02/02/18 15:22, Jan Beulich wrote:
On 02.02.18 at 14:02, wrote:
>> On 07/12/17 14:05, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -355,6 +355,36 @@ static const struct {
>>> [0xff] = { ModRM }
>>> };
>>>
On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter wrote:
> On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:
>> --- a/drivers/xen/fallback.c
>> +++ b/drivers/xen/fallback.c
>> @@ -7,75 +7,87 @@
>>
>> int xen_event_channel_op_compat(int cmd, void *arg)
>> {
>> - struct evtchn_op op;
On 02/02/18 15:15, Jan Beulich wrote:
On 02.02.18 at 12:43, wrote:
>> On 07/12/17 14:04, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -458,6 +458,20 @@ static const opcode_desc_t xop_table[] =
>>> DstReg|SrcIm
On 02/02/18 09:37, Alexandru Isaila wrote:
> This commit enables the breakpoint events for svm.
>
> Signed-off-by: Alexandru Isaila
> ---
> xen/arch/x86/hvm/svm/svm.c| 52
> ---
> xen/include/asm-x86/monitor.h | 3 ++-
> 2 files changed, 46 insertions
On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:
> The legacy hypercall handlers were originally added with
> a comment explaining that "copying the argument structures in
> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
> variable is sufficiently safe" and o
On Fri, Feb 2, 2018 at 2:37 AM, Alexandru Isaila
wrote:
> This commit enables the breakpoint events for svm.
>
> Signed-off-by: Alexandru Isaila
> ---
> xen/arch/x86/hvm/svm/svm.c| 52
> ---
> xen/include/asm-x86/monitor.h | 3 ++-
> 2 files changed,
On 31/01/18 11:36, Jan Beulich wrote:
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)
O
Hi
On 02.02.18 16:31, Julien Grall wrote:
Hi,
On 02/02/18 14:23, Volodymyr Babchuk wrote:
On 02.02.18 13:41, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PS
On Fri, Feb 2, 2018 at 2:37 AM, Alexandru Isaila
wrote:
> This commit separates the svm caps from the vmx caps.
>
> Signed-off-by: Alexandru Isaila
> ---
> xen/include/asm-x86/monitor.h | 33 -
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/x
On Fri, Feb 2, 2018 at 1:14 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 in hv
The legacy hypercall handlers were originally added with
a comment explaining that "copying the argument structures in
HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
variable is sufficiently safe" and only made sure to not write
past the end of the argument structure, the
>>> On 02.02.18 at 14:03, wrote:
> On 07/12/17 14:06, Jan Beulich wrote:
>> This allows the section contents to be disassembled without going
>> through any extra hoops, simplifying the analysis of problems in test
>> and/or emulation code.
>>
>> The blobs being emitted as (r/o) data means we need
>>> On 02.02.18 at 14:02, wrote:
> On 07/12/17 14:05, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -355,6 +355,36 @@ static const struct {
>> [0xff] = { ModRM }
>> };
>>
>> +static const uint16_t _3dnow_table[16] =
>>> On 02.02.18 at 13:03, wrote:
> On 07/12/17 14:04, Jan Beulich wrote:
>> @@ -8027,6 +8060,13 @@ x86_emulate(
>> generate_exception_if(vex.w, EXC_UD);
>> goto simd_0f_imm8_avx;
>>
>> +case X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* vpermil2ps
>> $imm,{x,y}mm/mem,{x,y}mm,{x,y}m
>>> On 02.02.18 at 12:43, wrote:
> On 07/12/17 14:04, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -458,6 +458,20 @@ static const opcode_desc_t xop_table[] =
>> DstReg|SrcImm|ModRM,
>> };
>>
>> +static const struct
Hi,
On 02/02/18 14:47, Julien Grall wrote:
>
>
> On 02/02/18 14:34, Andre Przywara wrote:
>> Hi,
>
> Hi,
>
>> On 02/02/18 10:14, Julien Grall wrote:
>>> At the moment, try_handle_mmio() will do check on the HSR and bail out
>>> if one check fail. This means that another method will be tried to
On 02/02/18 14:37, Andre Przywara wrote:
Hi,
Hi,
On 02/02/18 10:14, Julien Grall wrote:
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...).
On 07/12/17 14:15, Jan Beulich wrote:
> If the ->cmpxchg() hook finds a mismatch, we should deal with this the
> same way as when the "manual" comparison reports a mismatch.
>
> This involves reverting bfce0e62c3 ("x86/emul: Drop
> X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now
>
On 02/02/18 14:34, Andre Przywara wrote:
Hi,
Hi,
On 02/02/18 10:14, 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 retu
On 02/02/18 14:34, Andre Przywara wrote:
Hi,
Hi,
On 02/02/18 10:14, Julien Grall wrote:
At the moment, try_handle_mmio() will do check on the HSR and bail out
if one check fail. This means that another method will be tried to
handle the fault even for bad access on emulated region. While t
Hi,
On 02/02/18 10:14, Julien Grall wrote:
> 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:
Hi,
On 02/02/18 10:14, Julien Grall wrote:
> 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.
Very nice!
Hi,
On 02/02/18 10:14, 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
Hi,
On 02/02/18 10:14, Julien Grall wrote:
> At the moment, try_handle_mmio() will do check on the HSR and bail out
> if one check fail. This means that another method will be tried to
> handle the fault even for bad access on emulated region. While this
> should not be an issue, this is not futur
Hi,
On 02/02/18 14:23, Volodymyr Babchuk wrote:
On 02.02.18 13:41, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is dif
On 02.02.18 13:41, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
req
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.
This is part of XSA-2
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
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-off-by: 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 based on Linux patch fro
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.h | 4
1 file ch
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 fourth version posted by Marc Zyngier on Linux-arm
mailing list (see [1]).
This is
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 implementation-specific mitigation
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 return_from_trap, r11 wil
Hi Julien,
Thanks, it looks like the issue was with the way I verified this - cat on
/sys/firmware/devicetree/base/psci/compatible from dom0's console returns
only the first compatible string set by Xen no matter what.
I have verified by debugging that linux finds the right compatible string
in ps
On 07/12/17 14:14, Jan Beulich wrote:
> This is necessary for the hook to correctly perform the operation.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org
On 07/12/17 14:12, Jan Beulich wrote:
> I'm in the process of putting together a gas change issuing at least
> warnings when the intended size of a memory operation can't be deduced
> from another (register) operand. Add missing suffixes to silence such
> future diagnostics.
>
> Signed-off-by: Jan
On 07/12/17 14:11, Jan Beulich wrote:
> As mentioned in Linux commit 87c00572ba ("kvm: x86: emulate monitor and
> mwait instructions as nop"), older OS X versions (for example) may make
> use of the insns without checking CPUID flags (presumably implying
> availability from family/model).
-1 to th
On 02.02.18 13:41, Julien Grall wrote:
The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.
However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC
Hi Julien,
On 02.02.18 13:41, Julien Grall wrote:
The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and
implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION
for SMCCC).
The new SMCCC framework is able to deal with unimplemented function and
return the proper error cod
On 07/12/17 14:11, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
> ---
> v3: New.
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -5047,6 +5047,24 @@ x86_emulate(
> goto done;
> break;
>
> +case 0xf8: /*
On 07/12/17 14:10, Jan Beulich wrote:
> Use the generic stub exception handling instead.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Paul Durrant
Acked-by: Andrew Cooper , because I'm happy
with the change but you've got quite a lot of rebasing to get this to
apply to staging.
___
On 07/12/17 14:09, Jan Beulich wrote:
> While this means quite some reduction of (source) code, the main
> purpose is to no longer have exceptions raised from other than stubs.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper for the reduction
alone, but with a recommendation.
> @@ -42
On 07/12/17 14:08, Jan Beulich wrote:
> Experimentally MPX instructions have been confirmed to behave as NOPs
> unless both related XCR0 bits are set to 1. By implication branches
> then also don't clear BNDn.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/
On 07/12/17 14:07, Jan Beulich wrote:
> --- a/tools/tests/x86_emulator/x86-emulate.c
> +++ b/tools/tests/x86_emulator/x86-emulate.c
> @@ -120,6 +120,19 @@ int emul_test_read_cr(
> return X86EMUL_UNHANDLEABLE;
> }
>
> +int emul_test_read_xcr(
> +unsigned int reg,
> +uint64_t *val,
>
flight 118537 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118537/
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 07/12/17 14:06, Jan Beulich wrote:
> This allows the section contents to be disassembled without going
> through any extra hoops, simplifying the analysis of problems in test
> and/or emulation code.
>
> The blobs being emitted as (r/o) data means we need to accept an
> assembler warning here (a
On 07/12/17 14:05, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -355,6 +355,36 @@ static const struct {
> [0xff] = { ModRM }
> };
>
> +static const uint16_t _3dnow_table[16] = {
Comment explaining how these mappings w
On 07/12/17 14:04, Jan Beulich wrote:
> @@ -8027,6 +8060,13 @@ x86_emulate(
> generate_exception_if(vex.w, EXC_UD);
> goto simd_0f_imm8_avx;
>
> +case X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* vpermil2ps
> $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
> +
On Thu, Feb 1, 2018 at 4:45 PM, Andy Shevchenko
wrote:
> 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 Shevchenk
On 07/12/17 14:04, Jan Beulich wrote:
> Convert the few existing opcodes so far supported.
>
> Also adjust two vex_* case labels to better be ext_* (the values are
> identical).
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emu
Hi all,
This small patch series contains SMCCC fixes (see #2) and PSCI clean-up.
Cheers,
Julien Grall (3):
xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU
xen/arm: vsmc: Don't implement function ID that doesn't exist
xen/arm: vpsci: Move PSCI function dispatching from vsmc.c
The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and
implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION
for SMCCC).
The new SMCCC framework is able to deal with unimplemented function and
return the proper error code. So remove the implementations for both
function.
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI fun
The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.
However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC32 functions have
equivalent in the SMC64.
flight 118501 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118501/
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
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
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
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
At the moment, try_handle_mmio() will do check on the HSR and bail out
if one check fail. This means that another method will be tried to
handle the fault even for bad access on emulated region. While this
should not be an issue, this is not future proof.
Move the checks of try_handle_mmio() in ha
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
---
On 02/02/2018 10:54 AM, Eduardo Otubo wrote:
On Wed, Jan 31, 2018 at 05:00:23PM +0200, Oleksandr Andrushchenko wrote:
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] Unregisteri
>>> On 01.02.18 at 21:53, wrote:
> On 07/12/17 14:03, Jan Beulich wrote:
>> @@ -2805,13 +2808,17 @@ x86_decode(
>> ea.type = OP_MEM;
>> if ( modrm_rm == 4 )
>> {
>> -sib = insn_fetch_type(uint8_t);
>> -sib_index = ((sib >> 3) &
This commit enables controlregister events for svm.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/svm/svm.c| 11 +++
xen/include/asm-x86/monitor.h | 3 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
i
This commit separates the svm caps from the vmx caps.
Signed-off-by: Alexandru Isaila
---
xen/include/asm-x86/monitor.h | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index a044
This commit enables MSR events for svm.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/svm/svm.c| 9 +
xen/include/asm-x86/monitor.h | 3 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 14a5f60..dc
Hi all,
This series provides a skeleton for enabling vm_events on SVM. For the
first step, the MSR, CR, Breakpoint and GuestRequest have been tested
and added to the capabilities list.
Cheers,
Alexandru Isaila
___
Xen-devel mailing list
Xen-devel@list
This commit enables the breakpoint events for svm.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/svm/svm.c| 52 ---
xen/include/asm-x86/monitor.h | 3 ++-
2 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.
On 02/02/18 01:36, Chris Patterson wrote:
> Works great, tested it and it fixes booting Linux v4.15 kernel for me :)
Can I add your "Tested-by:" to the patch when committing it?
Juergen
>
> Cheers!
>
> On Thu, Feb 1, 2018 at 3:17 PM, Boris Ostrovsky
> wrote:
>> On 02/01/2018 07:40 AM, Juerge
>>> On 01.02.18 at 20:45, wrote:
> On 07/12/17 14:03, Jan Beulich wrote:
>> @@ -2973,7 +2985,7 @@ x86_decode(
>> }
>> break;
>>
>> -case simd_scalar_fp:
>> +case simd_scalar_fp: /* case simd_scalar_dq: */
>
> I don't see this case label used, or introduced in any later
1 - 100 of 106 matches
Mail list logo
