This run is configured for baseline tests only.
flight 68132 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68132/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e148e6e9625f8a0054f131bacba4e5c9a21a4377
baseline v
flight 68133 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68133/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 68091
jobs:
build-amd64 pass
build-armh
flight 102733 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 101737
test-amd64-i386-libvi
On 30/11/2016 23:27, "Stefano Stabellini" wrote:
>On Wed, 23 Nov 2016, Lars Kurth wrote:
>>
>> -Formal Votes {#formal-votes}
>> -
>> -
>> -Sometimes it is necessary to conduct formal voting within the
>>community
>> -(outside of elections). Formal votes are necessary when processes
>>> On 30.11.16 at 14:50, wrote:
> To help with event injection improvements for the PV uses of x86_emulate(),
> implement a event injection API which matches its hvm counterpart.
>
> This is started with taking do_guest_trap() and modifying its calling API to
> pv_inject_event(), subsequentally
>>> On 30.11.16 at 14:50, wrote:
> Rename byte to raw, as the field being a single byte long is an implementation
> detail. Make the bitfields part of an anonymous struct to remove the .flags
> qualifier. Change the types of the flags to being booleans, to match their
> use.
With that you shoul
>>> On 30.11.16 at 14:50, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2656,6 +2656,8 @@ x86_emulate(
>&dst.val, op_bytes, ctxt, ops)) != 0 ||
> (rc = load_seg(src.val, dst.val, 0, NULL, ctx
On Wed, Nov 30, 2016 at 02:26:50PM -0800, Stefano Stabellini wrote:
> On Wed, 30 Nov 2016, Julien Grall wrote:
> > Hi all,
> >
> > Few months ago, Linaro has published the version 2 of the VM specification
> > [1].
> >
> > For those who don't know, the specification provides guidelines to
> > gu
Adding xen-devel and the x86 maintainers, I hope they can provide more insight
on this.
On Wed, Nov 30, 2016 at 11:08:45PM +, Jeff Swicegood wrote:
> jaga@jaga-Desktop:~$ sudo xl debug-keys i
> jaga@jaga-Desktop:~$ sudo xl dmesg
> (XEN) Xen version 4.7.0 (Ubuntu 4.7.0-0ubuntu2) (stefan.ba...@
>>> On 30.11.16 at 14:50, wrote:
> In debug builds, confirm that some properties of x86_emulate()'s behaviour
> actually hold. The first property, fixed in a previous change, is that retire
> flags are only ever set in the X86EMUL_OKAY case.
>
> While adjusting the userspace test harness to cope
On 01/12/16 10:18, Jan Beulich wrote:
On 30.11.16 at 14:50, wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2656,6 +2656,8 @@ x86_emulate(
>>&dst.val, op_bytes, ctxt, ops)) != 0 ||
>> (
>>> On 30.11.16 at 14:50, wrote:
> @@ -1242,27 +1242,38 @@ static void svm_inject_event(const struct x86_event
> *event)
> eventinj.fields.v = 1;
> eventinj.fields.vector = _event.vector;
>
> -/* Refer to AMD Vol 2: System Programming, 15.20 Event Injection. */
> +/*
> + *
On Tue, 2016-11-29 at 15:34 -0800, Stefano Stabellini wrote:
> ### Frontend XenBus Nodes
>
> num-rings
> Values:
>
> Number of rings. It needs to be lower or equal to max-rings.
>
> port- (port-0, port-1, etc)
> Values:
>
>
On 01/12/16 10:40, Jan Beulich wrote:
>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2404,6 +2404,11 @@ x86_decode(
>> #undef insn_fetch_bytes
>> #undef insn_fetch_type
>>
>> +/* Undo DEBUG wrapper. */
>> +#ifdef x86_emulate
>> +#undef x
Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
The current MAX_IO_APICS is 128, which causes the driver initialization
to fail on the system with IOAPIC ID >= 128.
Instead, this patch adds APIC ID in the struct ioapic_sbdf,
which is used to match the entry when searchi
On 01/12/16 10:53, Jan Beulich wrote:
>
>> eventinj.fields.type = X86_EVENTTYPE_SW_INTERRUPT;
>> break;
>>
>> case X86_EVENTTYPE_PRI_SW_EXCEPTION: /* icebp */
>> /*
>> - * icebp's injection must always be emulated. Software injection
>> help
>> -
>>> On 30.11.16 at 14:50, wrote:
> The behaviour of singlestep is to raise #DB after the instruction has been
> completed, but implementing it with inject_hw_exception() causes x86_emulate()
> to return X86EMUL_EXCEPTION, despite succesfully completing execution of the
> instruction, including reg
>>> On 01.12.16 at 11:51, wrote:
> On 01/12/16 10:18, Jan Beulich wrote:
> On 30.11.16 at 14:50, wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -2656,6 +2656,8 @@ x86_emulate(
>>>&dst.val, op_byte
>>> On 01.12.16 at 11:58, wrote:
> On 01/12/16 10:40, Jan Beulich wrote:
>>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -2404,6 +2404,11 @@ x86_decode(
>>> #undef insn_fetch_bytes
>>> #undef insn_fetch_type
>>>
>>> +/* Undo DEBUG wra
On 01/12/16 11:16, Jan Beulich wrote:
On 30.11.16 at 14:50, wrote:
>> The behaviour of singlestep is to raise #DB after the instruction has been
>> completed, but implementing it with inject_hw_exception() causes
>> x86_emulate()
>> to return X86EMUL_EXCEPTION, despite succesfully completing
>>> On 01.12.16 at 12:15, wrote:
> On 01/12/16 10:53, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -1694,8 +1694,6 @@ static int inject_swint(enum x86_swint_type type,
>>> goto raise_exn;
>>>
At 16:49 + on 30 Nov (1480524579), Roger Pau Monne wrote:
> ... and using the "preempted" parameter. Introduce a new helper that can
> be used from both hypercall or idle vcpu context (ie: during Dom0
> creation) in order to check if preemption is needed. If such preemption
> happens, the calle
flight 102740 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102740/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 1f021c88130b4d2d818ba4f269b3929339c00a88
baseline version:
xtf 36431397ac902e791e16a0
At 11:23 + on 01 Dec (1480591394), Andrew Cooper wrote:
> Hmm. It is only the PAE case we want to skip. Perhaps changing the PAE
> entry condition to
>
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index c45d260..28ff945 100644
> --- a/xen/arch/x86/mm/shado
At 13:50 + on 30 Nov (1480513830), Andrew Cooper wrote:
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
>
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator. This removes the need
At 13:50 + on 30 Nov (1480513835), Andrew Cooper wrote:
> Use x86_emul_{hw_exception,pagefault}() rather than
> {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
> faults to be known to the emulator. This requires altering the callers of
> x86_emulate() to properly re-
On 01/12/16 11:39, Tim Deegan wrote:
> At 13:50 + on 30 Nov (1480513835), Andrew Cooper wrote:
>> Use x86_emul_{hw_exception,pagefault}() rather than
>> {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
>> faults to be known to the emulator. This requires altering the
At 13:50 + on 30 Nov (1480513834), Andrew Cooper wrote:
> Use x86_emul_pagefault() rather than pv_inject_page_fault() to cause raised
> pagefaults to be known to the emulator. This requires altering the callers of
> x86_emulate() to properly re-inject the event.
>
> Signed-off-by: Andrew Coop
>>> On 01.12.16 at 12:04, wrote:
> Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
> The current MAX_IO_APICS is 128, which causes the driver initialization
> to fail on the system with IOAPIC ID >= 128.
>
> Instead, this patch adds APIC ID in the struct ioapic_sbdf,
>
>>> On 01.12.16 at 12:23, wrote:
> On 01/12/16 11:16, Jan Beulich wrote:
> On 30.11.16 at 14:50, wrote:
>>> @@ -3422,6 +3422,16 @@ static int sh_page_fault(struct vcpu *v,
>>> v->arch.paging.last_write_emul_ok = 0;
>>> #endif
>>>
>>> +if ( emul_ctxt.ctxt.retire.singlestep )
>>
>>> On 01.12.16 at 11:29, wrote:
>> (XEN) Enabling APIC mode: Flat. Using 2 I/O APICs
>> (XEN) [VT-D] RMRR address range bf7da000..bf7d9fff not in reserved memory;
>> need "iommu_inclusive_mapping=1"?
>> (XEN) [VT-D] RMRR (bf7da000, bf7d9fff) is incorrect
>> (XEN) Failed to parse ACPI DMAR. D
>>> On 30.11.16 at 14:50, wrote:
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
>
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator. This removes the need for the
> inject_{hw_exce
PVHv2 guests don't have any VGA card, and as so it must be notified in the FADT.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
tools/firmware/hvmloader/util.c | 3 ++-
tools/libac
On 01/12/2016 09:52, "Lars Kurth" wrote:
>On 30/11/2016 23:27, "Stefano Stabellini" wrote:
>
>>On Wed, 23 Nov 2016, Lars Kurth wrote:
>>>
>>>
>>
>>This is basically the same voting mechanism described under "Leadership
>>Team
>>Decisions", counted per project, then averaged, isn't?
>
>That is
>>> On 30.11.16 at 14:50, wrote:
> @@ -5379,30 +5380,41 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
> addr,
> page_unlock(page);
> put_page(page);
>
> -/*
> - * The previous lack of inject_{sw,hw}*() hooks caused exceptions raised
> - * by the emulator itself t
>>> On 30.11.16 at 14:50, wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3373,18 +3373,35 @@ static int sh_page_fault(struct vcpu *v,
>
> r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
>
> -/*
> - * The previous lack of inject_{sw,hw}*() ho
>>> On 01.12.16 at 13:40, wrote:
> PVHv2 guests don't have any VGA card, and as so it must be notified in the
> FADT.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Looking at this ...
> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -229,6 +229,7 @@ struct
On 01/12/16 12:57, Jan Beulich wrote:
On 30.11.16 at 14:50, wrote:
>> @@ -5379,30 +5380,41 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
>> addr,
>> page_unlock(page);
>> put_page(page);
>>
>> -/*
>> - * The previous lack of inject_{sw,hw}*() hooks caused except
>>> On 30.11.16 at 14:04, wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -98,6 +98,52 @@ static CHAR16 __initdata newline[] = L"\r\n";
> #define PrintStr(s) StdOut->OutputString(StdOut, s)
> #define PrintErr(s) StdErr->OutputString(StdErr, s)
>
> +#ifndef CONFIG_ARM
>
On 01/12/16 13:00, Jan Beulich wrote:
On 30.11.16 at 14:50, wrote:
>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -3373,18 +3373,35 @@ static int sh_page_fault(struct vcpu *v,
>>
>> r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
>>
>> -/*
>> -
On Wed, Nov 30, 2016 at 05:47:50PM +0800, Zhang Chen wrote:
> The ioreq server make colo run failed.
>
> Signed-off-by: Zhang Chen
> Signed-off-by: Wen Congyang
> ---
> xen/arch/x86/hvm/hvm.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch
On Wed, Nov 30, 2016 at 05:47:51PM +0800, Zhang Chen wrote:
> Because of qemu codes update, we update Xen colo block codes
>
> Signed-off-by: Zhang Chen
COLO being an experimental feature means that you can change it at will,
so for both patches:
Acked-by: Wei Liu
But, this sort of patch does
On Tue, Nov 29, 2016 at 09:20:55PM +0100, Ingo Jürgensmann wrote:
> Am 29.11.2016 um 10:08 schrieb Wei Liu :
> >> http://paste.debian.net/895464/
> > Entry not found -- maybe it expired... Sorry.
>
> Here it is:
>
This is still the same kernel log that was sent some time ago.
So, if you have b
>>> On 01.12.16 at 14:12, wrote:
> On 01/12/16 12:57, Jan Beulich wrote:
> On 30.11.16 at 14:50, wrote:
>>> @@ -5379,30 +5380,41 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned
>>> long addr,
>>> page_unlock(page);
>>> put_page(page);
>>>
>>> -/*
>>> - * The previous l
On Thu, Dec 01, 2016 at 06:09:09AM -0700, Jan Beulich wrote:
> >>> On 01.12.16 at 13:40, wrote:
> > PVHv2 guests don't have any VGA card, and as so it must be notified in the
> > FADT.
> >
> > Signed-off-by: Roger Pau Monné
>
> Reviewed-by: Jan Beulich
>
> Looking at this ...
>
> > --- a/to
On Tue, Nov 29, 2016 at 11:15:36AM -0800, Stefano Stabellini wrote:
> On Tue, 29 Nov 2016, Juergen Gross wrote:
> > On 29/11/16 08:34, Wei Liu wrote:
> > > On Mon, Nov 28, 2016 at 02:53:57PM +0100, Cédric Bosdonnat wrote:
> > >> Resume is sometimes silently failing for HVM guests. Getting the
> > >
On 30.11.16 21:21, Andrew Cooper wrote:
> On 29/11/16 15:09, Artem Mygaiev wrote:
>> Hi Julien
>>
>> On 29.11.16 16:27, Julien Grall wrote:
>>> Hi Artem,
>>>
>>> On 29/11/16 14:21, Artem Mygaiev wrote:
Lars, the project is approved by Coverity. Scan has found some issues in
xen/arch/arm o
On 12/01/2016 08:29 AM, Roger Pau Monne wrote:
On Thu, Dec 01, 2016 at 06:09:09AM -0700, Jan Beulich wrote:
On 01.12.16 at 13:40, wrote:
PVHv2 guests don't have any VGA card, and as so it must be notified in the
FADT.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Looking at t
On 01.12.2016 14:26, Wei Liu wrote:
This is still the same kernel log that was sent some time ago.
So, if you have built Xen with debug=y, could you try to set Xen log
level to the highest and capture "xl dmesg" when guest crashes?
It's not the guest that crashes, it's dom0. So when the host c
flight 102735 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102735/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102704
test-armhf-armhf-libvirt-qc
On Thu, Dec 01, 2016 at 02:59:36PM +0100, Ingo Jürgensmann wrote:
> On 01.12.2016 14:26, Wei Liu wrote:
>
> >This is still the same kernel log that was sent some time ago.
> >So, if you have built Xen with debug=y, could you try to set Xen log
> >level to the highest and capture "xl dmesg" when gu
This run is configured for baseline tests only.
flight 68131 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68131/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
Hi Stefano,
On 30/11/16 21:53, Stefano Stabellini wrote:
On Mon, 28 Nov 2016, Julien Grall wrote:
If not, then it might be worth to consider a 3rd solution where the TEE
SMC
calls are forwarded to a specific domain handling the SMC on behalf of the
guests. This would allow to upgrade the TEE la
On Fri, Nov 18, 2016 at 03:59:59PM +, Wei Liu wrote:
> On Thu, Nov 17, 2016 at 06:35:42PM +0100, Cédric Bosdonnat wrote:
> > Hey all,
> >
> > Here is v2 addressing Wei's comments on patch #1. The 3 libxl.c
> > patches haven't been merged, but the commit message of the first
> > one has been sl
Thursday, December 1, 2016, 2:59:36 PM, you wrote:
> On 01.12.2016 14:26, Wei Liu wrote:
>> This is still the same kernel log that was sent some time ago.
>> So, if you have built Xen with debug=y, could you try to set Xen log
>> level to the highest and capture "xl dmesg" when guest crashes?
>
Hello Julien,
On 1 December 2016 at 16:24, Julien Grall wrote:
> Hi Stefano,
>
>
> On 30/11/16 21:53, Stefano Stabellini wrote:
>>
>> On Mon, 28 Nov 2016, Julien Grall wrote:
>
> If not, then it might be worth to consider a 3rd solution where the TEE
> SMC
> calls are forwarded
On Thu, Dec 01, 2016 at 12:40:01PM +, Roger Pau Monne wrote:
> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -229,6 +229,7 @@ struct acpi_20_fadt {
> */
> #define ACPI_LEGACY_DEVICES (1 << 0)
> #define ACPI_8042 (1 << 1)
> +#define ACPI_FADT_NO_VGA(1 << 2)
On 29/11/16 19:19, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
On 29 November 2016 at 20:55, Julien Grall wrote:
Hi Volodymyr,
On 29/11/16 17:40, Volodymyr Babchuk wrote:
On 29 November 2016 at 18:02, Julien Grall wrote:
On 29/11/16 15:27, Volodymyr Babchuk wrote:
On 28 Nove
>>> On 01.12.16 at 16:08, wrote:
> On Thu, Dec 01, 2016 at 12:40:01PM +, Roger Pau Monne wrote:
>> --- a/tools/libacpi/acpi2_0.h
>> +++ b/tools/libacpi/acpi2_0.h
>> @@ -229,6 +229,7 @@ struct acpi_20_fadt {
>> */
>> #define ACPI_LEGACY_DEVICES (1 << 0)
>> #define ACPI_8042 (1 <<
On 10/31/2016 08:33 AM, Boris Ostrovsky wrote:
>
>
> On 10/14/2016 02:05 PM, Boris Ostrovsky wrote:
>> From: Matt Fleming
>>
>> The new Xen PVH entry point requires page tables to be setup by the
>> kernel since it is entered with paging disabled.
>>
>> Pull the common code out of head_32.S and in
Hi Julien
On 1 December 2016 at 17:19, Julien Grall wrote:
> On 29/11/16 19:19, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
>
> Hi Volodymyr,
>
>
>>
>>
>> On 29 November 2016 at 20:55, Julien Grall wrote:
>>>
>>> Hi Volodymyr,
>>>
>>> On 29/11/16 17:40, Volodymyr Babchuk wrote:
On
On 01/12/16 02:07, Stefano Stabellini wrote:
On Fri, 25 Nov 2016, Julien Grall wrote:
Hi Stefano,
Hi,
On 23/11/16 19:55, Stefano Stabellini wrote:
Actually I am thinking that the default values should be in the
emulators themselves. After all they are the part of the code that knows
more ab
On Thu, Dec 01, 2016 at 06:13:34AM -0700, Jan Beulich wrote:
> >>> On 30.11.16 at 14:04, wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -98,6 +98,52 @@ static CHAR16 __initdata newline[] = L"\r\n";
> > #define PrintStr(s) StdOut->OutputString(StdOut, s)
> > #define
Hi Christoffer,
On 30/11/16 16:24, Christoffer Dall wrote:
On Wed, Nov 30, 2016 at 03:29:32PM +, Julien Grall wrote:
Hi all,
Few months ago, Linaro has published the version 2 of the VM
specification [1].
For those who don't know, the specification provides guidelines to
guarantee a compl
>>> On 29.11.16 at 16:33, wrote:
> @@ -108,12 +111,12 @@ static void pmt_update_time(PMTState *s)
> s->last_gtime = curr_gtime;
>
> /* Update timer value atomically wrt lock-free reads in handle_pmt_io().
> */
> -*(volatile uint32_t *)&s->pm.tmr_val = tmr_val;
> +*(volatile ui
>>> On 29.11.16 at 16:33, wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -291,6 +291,13 @@ struct xen_arch_domainconfig {
> XEN_X86_EMU_PIT)
> uint32_t emulation_flags;
> };
> +
> +/* Location of online VC
>>> On 29.11.16 at 16:33, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/acpi.c
> @@ -0,0 +1,24 @@
> +/* acpi.c: ACPI access handling
> + *
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + */
> +#include
> +#include
> +#include
> +
> +
> +int hvm_acpi_domctl_acce
>>> On 01.12.16 at 16:41, wrote:
> On Thu, Dec 01, 2016 at 06:13:34AM -0700, Jan Beulich wrote:
>> >>> On 30.11.16 at 14:04, wrote:
>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -98,6 +98,52 @@ static CHAR16 __initdata newline[] = L"\r\n";
>> > #define PrintStr(s) Std
On Thu, Dec 01, 2016 at 09:08:45AM -0700, Jan Beulich wrote:
> >>> On 01.12.16 at 16:41, wrote:
> > On Thu, Dec 01, 2016 at 06:13:34AM -0700, Jan Beulich wrote:
> >> >>> On 30.11.16 at 14:04, wrote:
> >> > --- a/xen/common/efi/boot.c
> >> > +++ b/xen/common/efi/boot.c
> >> > @@ -98,6 +98,52 @@ st
flight 102741 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102741/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 10 guest-start fail in 102723 pass in 102741
test-amd64-i386-xl-raw
On 12/01/2016 10:52 AM, Jan Beulich wrote:
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -525,16 +525,16 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>>
>>
>> /*
>> - * PM timer
>> + * ACPI registers
>> */
>>
>> -struct hvm
On 12/01/2016 10:57 AM, Jan Beulich wrote:
On 29.11.16 at 16:33, wrote:
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -291,6 +291,13 @@ struct xen_arch_domainconfig {
>> XEN_X86_EMU_PIT)
>> uint32_t emula
Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision making;
some new roles and minor changes"):
> Maybe Ian has some views on what is better from a theoretical viewpoint:
> Voting mechanisms are a bit of a hobby of his
The underlying problem here is that the reality is that the
On 01/12/16 16:28, Boris Ostrovsky wrote:
> On 12/01/2016 10:52 AM, Jan Beulich wrote:
>>> --- a/xen/include/public/arch-x86/hvm/save.h
>>> +++ b/xen/include/public/arch-x86/hvm/save.h
>>> @@ -525,16 +525,16 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
>>>
>>>
>>> /*
>>> - * PM time
>>> On 29.11.16 at 16:33, wrote:
> +void hvm_acpi_init(struct domain *d)
> +{
> +if ( has_acpi_dm_ff(d) )
> +return;
> +
> +register_portio_handler(d, XEN_ACPI_CPU_MAP,
> +XEN_ACPI_CPU_MAP_LEN, acpi_guest_access);
> +register_portio_handler(d, ACPI_G
On 12/01/2016 11:06 AM, Jan Beulich wrote:
>
>> +++ b/xen/include/public/domctl.h
>> @@ -1144,6 +1144,29 @@ struct xen_domctl_psr_cat_op {
>> typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>>
>> +/* ACPI Generic Address Structu
On 12/01/2016 11:29 AM, Andrew Cooper wrote:
> On 01/12/16 16:28, Boris Ostrovsky wrote:
>> On 12/01/2016 10:52 AM, Jan Beulich wrote:
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -525,16 +525,16 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struc
In debug builds, confirm that some properties of x86_emulate()'s behaviour
actually hold. The first property, fixed in a previous change, is that retire
flags are only ever set in the X86EMUL_OKAY case.
While adjusting the userspace test harness to cope with ASSERT() in
x86_emulate.h, fix a build
The common case is already using fault semantics out of x86_emulate(), as that
is how VT-x/SVM expects to inject the event (given suitable hardware support).
However, x86_emulate() returning X86EMUL_EXCEPTION and also completing a
register writeback is problematic for callers.
Switch the logic to
This is the quantity of changes required to fix some edgecases in XSA-191
which were ultimately chosen not to go out in the security fix. The main
purpose of this series is to fix emulation sufficiently to allow the final
patch to avoid opencoding all of the segmenation logic.
Because this is a v
Use x86_emul_pagefault() rather than pv_inject_page_fault() to cause raised
pagefaults to be known to the emulator. This requires altering the callers of
x86_emulate() to properly re-inject the event.
Signed-off-by: Andrew Cooper
Acked-by: Tim Deegan
Reviewed-by: Jan Beulich
---
v4:
* Tweak c
The behaviour of singlestep is to raise #DB after the instruction has been
completed, but implementing it with inject_hw_exception() causes x86_emulate()
to return X86EMUL_EXCEPTION, despite succesfully completing execution of the
instruction, including register writeback.
Instead, use a retire fl
Use x86_emul_{hw_exception,pagefault}() rather than
{pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
faults to be known to the emulator. This requires altering the callers of
x86_emulate() to properly re-inject the event.
Signed-off-by: Andrew Cooper
Acked-by: Tim Deega
On 12/01/2016 11:32 AM, Jan Beulich wrote:
On 29.11.16 at 16:33, wrote:
>> +void hvm_acpi_init(struct domain *d)
>> +{
>> +if ( has_acpi_dm_ff(d) )
>> +return;
>> +
>> +register_portio_handler(d, XEN_ACPI_CPU_MAP,
>> +XEN_ACPI_CPU_MAP_LEN, acpi_gues
Hi.
Xen 4.8.0 RC8 is tagged. You can check it out from xen.git, where
there is a signed tag:
git://xenbits.xen.org/xen.git 4.8.0-rc8
For you convenience, please find tarball and signature at:
https://downloads.xenproject.org/release/xen/4.8.0-rc8/
Please send bug reports and test reports
On 28/11/16 15:29, t...@kernel.org wrote:
Hello,
Hello,
On Mon, Nov 28, 2016 at 11:59:15AM +, Julien Grall wrote:
commit 3ca45a46f8af8c4a92dd8a08eac57787242d5021
percpu: ensure the requested alignment is power of two
It would have been useful to specify the tree used. In this case,
t
Hi,
While testing XSA-201, I noticed that Xen 4.5 and 4.5 were not able to
boot on the Foundation Model [1].
The Foundation Model is a free model provided by ARM for ARMv8 which is
supported by Xen since the beginning.
I am able to Xen boot after applying the patch:
eb6fe7a "arm64: fix inc
flight 102745 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102745/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eae631bc687c3cbfab01632ce3bc21783d22b590
baseline version:
ovmf e148e6e9625f8a0054f13
flight 102744 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102744/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-raw 10 guest-start fail in 102725 pass in 102744
test-armhf-armhf-xl-vhd
On Wed, Nov 30, 2016 at 07:21:48AM +0100, Ingo Molnar wrote:
>
> * Alex Thorlton wrote:
>
> > It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
> > case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
> > E820_X_MAX is always at least slightly larger than E82
On 12/01/2016 11:55 AM, Andrew Cooper wrote:
> The common case is already using fault semantics out of x86_emulate(), as that
> is how VT-x/SVM expects to inject the event (given suitable hardware support).
>
> However, x86_emulate() returning X86EMUL_EXCEPTION and also completing a
> register writ
On Wed, Nov 30, 2016 at 12:30:04PM +1100, George Dunlap wrote:
> On Tue, Nov 29, 2016 at 4:18 AM, Ronald Rojas wrote:
> > Created basic Makfele for the Golang xenlight
> > project so that the project is built and
> > installed. A template template is alo added.
>
> Thanks Ronald! Not a bad first
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 102749 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102749/
Perfect :-)
All tests
On Thu, 1 Dec 2016, Volodymyr Babchuk wrote:
> Hello Julien,
>
>
>
> On 1 December 2016 at 16:24, Julien Grall wrote:
> > Hi Stefano,
> >
> >
> > On 30/11/16 21:53, Stefano Stabellini wrote:
> >>
> >> On Mon, 28 Nov 2016, Julien Grall wrote:
> >
> > If not, then it might be worth to con
On Thu, 1 Dec 2016, Volodymyr Babchuk wrote:
> > - TEE may run in parallel of the guest OS, this means that we have
> > to make sure the page will never be removed by the guest OS (see
> > XENMEM_decrease_reservation hypercall).
> Hmmm... I don't know how XEN handles guest memory in details
flight 102750 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102750/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102726
test-armhf-armhf-libvirt 13
On Thu, 1 Dec 2016, Julien Grall wrote:
> On 01/12/16 02:07, Stefano Stabellini wrote:
> > On Fri, 25 Nov 2016, Julien Grall wrote:
> > > Hi Stefano,
>
> Hi,
>
> > > On 23/11/16 19:55, Stefano Stabellini wrote:
> > > > Actually I am thinking that the default values should be in the
> > > > emulat
On Thu, 1 Dec 2016, Christoffer Dall wrote:
> On Wed, Nov 30, 2016 at 02:26:50PM -0800, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2016, Julien Grall wrote:
> > > Hi all,
> > >
> > > Few months ago, Linaro has published the version 2 of the VM specification
> > > [1].
> > >
> > > For those who
Done
On Thu, 1 Dec 2016, Julien Grall wrote:
> Hi,
>
> While testing XSA-201, I noticed that Xen 4.5 and 4.5 were not able to boot on
> the Foundation Model [1].
>
> The Foundation Model is a free model provided by ARM for ARMv8 which is
> supported by Xen since the beginning.
>
> I am able to
On Thu, 1 Dec 2016, Ian Jackson wrote:
> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision
> making; some new roles and minor changes"):
> > Maybe Ian has some views on what is better from a theoretical viewpoint:
> > Voting mechanisms are a bit of a hobby of his
>
> The unde
1 - 100 of 119 matches
Mail list logo
