Re: [Xen-devel] [PATCH v3 17/24] x86/pv: Avoid raising faults behind the emulators back

>>> 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); >>>

[Xen-devel] [xen-unstable test] 102735: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v10 06/13] efi: create new early memory allocator

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)

Re: [Xen-devel] [PATCH 2/3] Add Xen colo support for qemu-upstream colo codes

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

Re: [Xen-devel] [PATCH v2 00/35] libxl LOG*D functions

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

Re: [Xen-devel] [PATCH] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

>>> 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

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

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

Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian

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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

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

Re: [Xen-devel] [PATCH] libxl: invert xc and domain model resume calls in xc_domain_resume()

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 > >

Re: [Xen-devel] [PATCH] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

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

Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian

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

Re: [Xen-devel] [PATCH v4 01/15] x86/pmtimer: Move ACPI registers from PMTState to hvm_domain

>>> 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 *)>pm.tmr_val =

Re: [Xen-devel] [PATCH v4 05/15] acpi/x86: Define ACPI IO registers for PVH guests

>>> 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; > }; >

Re: [Xen-devel] [PATCH 1/3] Don't create default ioreq server

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

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

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

Re: [Xen-devel] [PATCH] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

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é

Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian

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?

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

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

Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian

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

[Xen-devel] [qemu-mainline baseline-only test] 68131: tolerable FAIL

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

Re: [Xen-devel] [PATCH] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

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 <<

Re: [Xen-devel] [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup

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

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

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

Re: [Xen-devel] [COVERITY ACCESS] for Embedded/Automotive team

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

Re: [Xen-devel] [PATCH v4 01/15] x86/pmtimer: Move ACPI registers from PMTState to hvm_domain

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

Re: [Xen-devel] [PATCH v4 01/15] x86/pmtimer: Move ACPI registers from PMTState to hvm_domain

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,

Re: [Xen-devel] [PATCH v10 06/13] efi: create new early memory allocator

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 > >> > +++

Re: [Xen-devel] [PATCH v4 07/15] pvh/acpi: Install handlers for ACPI-related PVH IO accesses

>>> 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); > +

Re: [Xen-devel] [PATCH v4 06/15] domctl: Add XEN_DOMCTL_acpi_access

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

[Xen-devel] [ovmf test] 102745: all pass - PUSHED

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

[Xen-devel] [PATCH v4 10/24] x86/emul: Always use fault semantics for software events

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

[Xen-devel] [PATCH v4 for-4.9 00/24] [SUBSET] XSA-191 followup

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

[Xen-devel] [PATCH v4 09/24] x86/emul: Provide a wrapper to x86_emulate() to ASSERT() certain behaviour

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

Re: [Xen-devel] Kernel Panics on Xen ARM64 for Domain0 and Guest

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,

[Xen-devel] ARM: Request backport for Xen 4.6 and Xen 4.5

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

Re: [Xen-devel] [PATCH v10 06/13] efi: create new early memory allocator

>>> 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

[Xen-devel] [xen-4.6-testing test] 102741: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v4 05/15] acpi/x86: Define ACPI IO registers for PVH guests

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-devel] [PATCH v4 17/24] x86/pv: Avoid raising faults behind the emulators back

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

[Xen-devel] [PATCH v4 11/24] x86/emul: Implement singlestep as a retire flag

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

[Xen-devel] [PATCH v4 18/24] x86/shadow: Avoid raising faults behind the emulators back

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

Re: [Xen-devel] [PATCH v4 07/15] pvh/acpi: Install handlers for ACPI-related PVH IO accesses

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, >> +

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

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

[Xen-devel] [libvirt test] 102750: tolerable all pass - PUSHED

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

[Xen-devel] [rumprun baseline test] 102749: all pass

"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

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

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

[Xen-devel] [xen-4.7-testing test] 102744: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v4 10/24] x86/emul: Always use fault semantics for software events

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

Re: [Xen-devel] [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

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

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

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 > > > >

Re: [Xen-devel] ARM: Request backport for Xen 4.6 and Xen 4.5

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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

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

Re: [Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

On Thu, 1 Dec 2016, Lars Kurth wrote: > On 01/12/2016 22:36, "Stefano Stabellini" wrote: > > >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

Re: [Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

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

Re: [Xen-devel] [DOC v1] Xen transport for 9pfs

On Thu, 1 Dec 2016, Dario Faggioli wrote: > 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-

[Xen-devel] [xen-4.4-testing test] 102751: regressions - trouble: blocked/broken/fail/pass

flight 102751 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102751/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 3 host-install(3)broken REGR. vs. 102521 build-armhf

Re: [Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

On 01/12/2016 22:36, "Stefano Stabellini" wrote: >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

Re: [Xen-devel] [DOC v1] Xen transport for 9pfs

On Wed, 30 Nov 2016, David Vrabel wrote: > On 29/11/16 23:34, Stefano Stabellini wrote: > > > > The producer (the backend for **in**, the frontend for **out**) writes to > > the > > array in the following way: > > > - read memory barrier > > - read *cons*, *prod* from shared memory > > - write

Re: [Xen-devel] [PATCH v4 06/15] domctl: Add XEN_DOMCTL_acpi_access

>>> 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 > + >

Re: [Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

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

Re: [Xen-devel] [PATCH v4 01/15] x86/pmtimer: Move ACPI registers from PMTState to hvm_domain

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

[Xen-devel] [ANNOUNCEMENT] Xen 4.8 RC8

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

Re: [Xen-devel] [PATCH] AMD IOMMU: Support IOAPIC IDs larger than 128

Hi Jan, On 12/01/2016 06:58 PM, Jan Beulich wrote: 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

[Xen-devel] [linux-3.18 test] 102754: regressions - FAIL

flight 102754 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102754/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 6 xen-bootfail REGR. vs. 101675

Re: [Xen-devel] Intentional EPT Misconfigurations in xen

Hi, Thanks a lot. I find that if guest writes or reads MSR related to MTRR which will cause vm exit, xen will just calculate mtrr type and store it without setting the EPT. Why doesn't xen set the memory type (ie,emt filed)in entry of EPT when handling vm exit resulting from writing/reading MSR

Re: [Xen-devel] ARM: Request backport for Xen 4.6 and Xen 4.5

>>> On 01.12.16 at 18:58, wrote: > 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

[Xen-devel] [ovmf baseline-only test] 68147: all pass

This run is configured for baseline tests only. flight 68147 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68147/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf eae631bc687c3cbfab01632ce3bc21783d22b590 baseline

Re: [Xen-devel] [PATCH v4 06/15] domctl: Add XEN_DOMCTL_acpi_access

>>> On 01.12.16 at 17:43, wrote: > 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; >>>

[Xen-devel] XC_PAGE_SIZE or XEN_PAGE_SIZE?

Hi, all! While working on display protocol I found that there is no(?) common ???_PAGE_SIZE define I can use for both Xen and Linux kernel: Xen defines XC_PAGE_SIZE which is also used in Linux user-space and kernel has XEN_PAGE_SIZE, but no XC_PAGE_SIZE. So, the question is which define

Re: [Xen-devel] [ARM] Handling CMA pool device nodes in Dom0

On Tue, Nov 29, 2016 at 01:49:51PM +, Julien Grall wrote: >(CC Stefano) > >On 25/11/16 12:19, Iurii Mykhalskyi wrote: >>Hello! > >Hi Iurii, > >> >>I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X) >>support in Xen mainline. >> >>Salvator-X has several CMA pool nodes, for

Re: [Xen-devel] [PATCH] AMD IOMMU: Support IOAPIC IDs larger than 128

>>> On 02.12.16 at 04:48, wrote: > On 12/01/2016 06:58 PM, Jan Beulich wrote: > 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,

Re: [Xen-devel] [PATCH] AMD IOMMU: Support IOAPIC IDs larger than 128

>>> 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

Re: [Xen-devel] [PATCH v3 11/24] x86/emul: Implement singlestep as a retire flag

>>> 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

[Xen-devel] IO APIC interrupt stuck with irr=1 (was: Re: [Xen-users] xen hypervisor does not like my Dom0 LVM partition: I/O Errors)

>>> 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

Re: [Xen-devel] [PATCH v3 13/24] x86/emul: Rework emulator event injection

>>> 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

[Xen-devel] [ovmf baseline-only test] 68132: all pass

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

[Xen-devel] [distros-debian-wheezy test] 68133: all pass

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

[Xen-devel] [linux-4.1 test] 102733: regressions - FAIL

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

Re: [Xen-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

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

Re: [Xen-devel] [PATCH v3 10/24] x86/emul: Always use fault semantics for software events

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 >> -

Re: [Xen-devel] [PATCH v3 11/24] x86/emul: Implement singlestep as a retire flag

>>> 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

Re: [Xen-devel] [PATCH v3 08/24] x86/emul: Correct the behaviour of pop %ss and interrupt shadowing

>>> 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 @@

Re: [Xen-devel] [PATCH v3 09/24] x86/emul: Provide a wrapper to x86_emulate() to ASSERT() certain behaviour

>>> 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

Re: [Xen-devel] [PATCH v3 11/24] x86/emul: Implement singlestep as a retire flag

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,

Re: [Xen-devel] [PATCH v4 03/14] xen/x86: allow calling {shadow/hap}_set_allocation with the idle domain

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

[Xen-devel] [xtf test] 102740: all pass - PUSHED

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

Re: [Xen-devel] [PATCH v3 11/24] x86/emul: Implement singlestep as a retire flag

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 > ---

Re: [Xen-devel] [PATCH v3 13/24] x86/emul: Rework emulator event injection

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

Re: [Xen-devel] [PATCH v3 18/24] x86/shadow: Avoid raising faults behind the emulators back

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: [Xen-devel] [PATCH v3 18/24] x86/shadow: Avoid raising faults behind the emulators back

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

Re: [Xen-devel] [PATCH v3 17/24] x86/pv: Avoid raising faults behind the emulators back

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

Re: [Xen-devel] [PATCH v3 07/24] x86/emul: Clean up the naming of the retire union

>>> 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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

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 > >

Re: [Xen-devel] [PATCH v3 09/24] x86/emul: Provide a wrapper to x86_emulate() to ASSERT() certain behaviour

>>> 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

Re: [Xen-devel] [DOC v1] Xen transport for 9pfs

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:  > >   

Re: [Xen-devel] [PATCH v3 09/24] x86/emul: Provide a wrapper to x86_emulate() to ASSERT() certain behaviour

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

[Xen-devel] [PATCH] AMD IOMMU: Support IOAPIC IDs larger than 128

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

  1   2   >