Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

On 09.11.2016 13:14, Julien Grall wrote: Hello, On 09/11/16 07:14, Dirk Behme wrote: On 08.11.2016 16:41, Iurii Mykhalskyi wrote: Hello Dirk, I have made only single change - I recompile ATF to leave CPU in EL2 mode and reflash it. Yes, this is what I meant with 'modifying firmware' ;)

[Xen-devel] [xen-unstable test] 102068: tolerable trouble: blocked/broken/fail/pass

flight 102068 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102068/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 3 host-install(3) broken pass in 102045

[Xen-devel] [linux-3.4 test] 102067: tolerable FAIL - PUSHED

flight 102067 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102067/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl 6 xen-boot fail in 101695 pass in 102067 test-amd64-amd64-libvirt-vhd 6

Re: [Xen-devel] [PATCH v3 00/15] Enable L2 Cache Allocation Technology

On 16-11-09 01:37:55, Jan Beulich wrote: > >>> On 09.11.16 at 02:28, wrote: > > Any comment or suggestion to this patch set? That would be very appreciated. > > Please be assured that this has not been forgotten, but there are > more important things to deal with, so it

Re: [Xen-devel] [Xen PATCH] xen-netback: fix error handling output

From: Arnd Bergmann Date: Tue, 8 Nov 2016 14:34:34 +0100 > The connect function prints an unintialized error code after an > earlier initialization was removed: > > drivers/net/xen-netback/xenbus.c: In function 'connect': > drivers/net/xen-netback/xenbus.c:938:3: error: 'err'

Re: [Xen-devel] [PATCH v3] xen-netback: prefer xenbus_scanf() over xenbus_gather()

From: "Jan Beulich" Date: Tue, 08 Nov 2016 00:45:53 -0700 > For single items being collected this should be preferred as being more > typesafe (as the compiler can check format string and to-be-written-to > variable match) and more efficient (requiring one less parameter to be

Re: [Xen-devel] Error migrating VM to secondary host using COLO replication

On 11/10/2016 01:31 AM, Sadi wrote: > Hello again, > > Looking at the primary host's syslog, the arptables command from > xen/etc/scripts/colo-proxy-setup has failed. > > Here's the log: > > Nov 9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: setup > XENBUS_PATH= > Nov 9 14:43:39

[Xen-devel] [xen-unstable-smoke test] 102079: tolerable all pass - PUSHED

flight 102079 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/102079/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [RFC PATCH 24/24] ARM: vGIC: advertising LPI support

On Wed, 28 Sep 2016, Andre Przywara wrote: > To let a guest know about the availability of virtual LPIs, set the > respective bits in the virtual GIC registers and let a guest control > the LPI enable bit. > Only report the LPI capability if the host has initialized at least > one ITS. > >

Re: [Xen-devel] [RFC PATCH 22/24] ARM: vITS: create and initialize virtual ITSes for Dom0

On Wed, 28 Sep 2016, Andre Przywara wrote: > For each hardware ITS create and initialize a virtual ITS for Dom0. > We use the same memory mapped address to keep the doorbell working. > > Signed-off-by: Andre Przywara > --- > xen/arch/arm/vgic-its.c | 22

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On Fri, 4 Nov 2016, Andre Przywara wrote: > Hi, > > On 24/10/16 16:32, Vijay Kilari wrote: > > On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara > > wrote: > >> The INVALL command instructs an ITS to invalidate the configuration > >> data for all LPIs associated with a

Re: [Xen-devel] Xen ARM community call

Hi Julien, all, > I would like to start organizing a recurring community call to discuss and > sync-up on upcoming features for Xen ARM. great idea, I'd like to join too (GMT). > Example of features that could be discussed: > - Sharing co-processor between guests > - PCI

Re: [Xen-devel] [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400

On Wed, 9 Nov 2016, Julien Grall wrote: > Hi Stefano, > > On 08/11/16 19:42, Stefano Stabellini wrote: > > @@ -1189,7 +1194,10 @@ static int __init gicv2_init(void) > > printk(XENLOG_WARNING > > "GICv2: Adjusting CPU interface base to %#"PRIx64"\n", > >

[Xen-devel] [linux-3.10 test] 102063: regressions - FAIL

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

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

On 11/09/2016 02:58 PM, Andrew Cooper wrote: > On 09/11/16 15:14, Boris Ostrovsky wrote: >> On 11/09/2016 09:59 AM, Andrew Cooper wrote: diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h index 2e5809b..e3fa704 100644 ---

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote: > > > > Low 1MB > > --- > > > > When booted with a legacy BIOS, the low 1MB contains firmware related data > > that should be identity mapped to the Dom0. This include the EBDA, video > > memory and possibly ROMs. All non RAM

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

On 09/11/16 15:14, Boris Ostrovsky wrote: > On 11/09/2016 09:59 AM, Andrew Cooper wrote: >>> diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h >>> index 2e5809b..e3fa704 100644 >>> --- a/xen/include/public/hvm/ioreq.h >>> +++ b/xen/include/public/hvm/ioreq.h >>> @@ -24,6

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

On 11/09/2016 02:23 PM, Andrew Cooper wrote: > On 09/11/16 15:29, Boris Ostrovsky wrote: >> On 11/09/2016 10:04 AM, Andrew Cooper wrote: >>> On 09/11/16 14:39, Boris Ostrovsky wrote: This domctl is called when a VCPU is hot-(un)plugged to a guest (via 'xl vcpu-set'). While this currently

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

On 09/11/16 15:29, Boris Ostrovsky wrote: > On 11/09/2016 10:04 AM, Andrew Cooper wrote: >> On 09/11/16 14:39, Boris Ostrovsky wrote: >>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via >>> 'xl vcpu-set'). While this currently is only intended to be needed by >>> PVH guests we

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

On 09/11/16 15:59, Roger Pau Monné wrote: > Hello, > > I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with > physical devices, and what needs to be done inside of Xen in order to > achieve it. Current draft is RFC because I'm quite sure I'm missing bits > that should be

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote: > Hello, > > I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with > physical devices, and what needs to be done inside of Xen in order to > achieve it. Current draft is RFC because I'm quite sure I'm missing bits

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Don't clobber eax and edx if an RDMSR intercept fails

On 09/11/16 14:14, Jan Beulich wrote: On 09.11.16 at 13:28, wrote: >> The original code has a bug; eax and edx get unconditionally updated even >> when >> hvm_msr_read_intercept() doesn't return X86EMUL_OKAY. >> >> It is only by blind luck (vmce_rdmsr() eagerly

Re: [Xen-devel] Error migrating VM to secondary host using COLO replication

Hello again, Looking at the primary host's syslog, the arptables command from xen/etc/scripts/colo-proxy-setup has failed. Here's the log: Nov 9 14:43:39 colop colop: /etc/xen/scripts/colo-proxy-setup: setup XENBUS_PATH= Nov 9 14:43:39 colop kernel: [ 302.825788] u32 classifier Nov 9

Re: [Xen-devel] [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

We just discussed this IRL, and here are our conclusions: Ian Jackson writes ("Re: [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt"): > Do we intend to try to gate xen-unstable on this eventually ? Maybe eventually, but not right now. > AFAICT you pull in

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

flight 102065 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102065/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c3c9892c3b4dafd1d0ccdc8e5e017d80e8c4361e baseline version: ovmf

Re: [Xen-devel] Xen, EFI and kexec

On Wed, Nov 09, 2016 at 03:13:16PM +0100, Sylvain Munaut wrote: > Hi, > > > A bit of background: What I'm currently trying to do is to network > boot a first linux image in EFI mode (using UEFI network boot), then > from that image, kexec into Xen in EFI mode as well. > > It's not working. > >

Re: [Xen-devel] [OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

Anthony PERARD writes ("[OSSTEST PATCH v6 3/3] Create a flight to test OpenStack with xen-unstable and libvirt"): > This patch should create a flight "openstack-nova", with those jobs: > build-amd64 > build-amd64-xsm > build-amd64-pvops > build-amd64-libvirt > test-amd64-amd64-devstack

Re: [Xen-devel] [OSSTEST PATCH v6 2/3] ts-openstack-tempest: Run Tempest to check OpenStack

Anthony PERARD writes ("[OSSTEST PATCH v6 2/3] ts-openstack-tempest: Run Tempest to check OpenStack"): > This script runs the OpenStack integration test suite, Tempest. ... > + push @ignored_tests, > + "^\Q$volume_boot_pattern.test_volume_boot_pattern\E"; > + push @ignored_tests, > +

Re: [Xen-devel] [OSSTEST PATCH v6 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack

Anthony PERARD writes ("[OSSTEST PATCH v6 1/3] ts-openstack-deploy: Deploy OpenStack on a host with devstack"): > This script installs any necessary packages and clones all of the OpenStack > trees which are used by devstack to deploy OpenStack. Thanks for this contribution. I have no knowledge

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Don't clobber eax and edx if an RDMSR intercept fails

On 11/09/2016 07:28 AM, Andrew Cooper wrote: > The original code has a bug; eax and edx get unconditionally updated even when > hvm_msr_read_intercept() doesn't return X86EMUL_OKAY. > > It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content > pointer) that this isn't an

[Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

Hello, I'm attaching a draft of how a PVHv2 Dom0 is supposed to interact with physical devices, and what needs to be done inside of Xen in order to achieve it. Current draft is RFC because I'm quite sure I'm missing bits that should be written down here. So far I've tried to describe what my

Re: [Xen-devel] [linux-3.10 test] 102032: regressions - FAIL

osstest service owner writes ("[linux-3.10 test] 102032: regressions - FAIL"): > flight 102032 linux-3.10 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/102032/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

On 11/09/2016 10:04 AM, Andrew Cooper wrote: > On 09/11/16 14:39, Boris Ostrovsky wrote: >> This domctl is called when a VCPU is hot-(un)plugged to a guest (via >> 'xl vcpu-set'). While this currently is only intended to be needed by >> PVH guests we will call this domctl for all (x86) guests for

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

On 11/09/2016 09:59 AM, Andrew Cooper wrote: > >> diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h >> index 2e5809b..e3fa704 100644 >> --- a/xen/include/public/hvm/ioreq.h >> +++ b/xen/include/public/hvm/ioreq.h >> @@ -24,6 +24,8 @@ >> #ifndef _IOREQ_H_ >> #define

Re: [Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

On 09/11/16 14:39, Boris Ostrovsky wrote: > This domctl is called when a VCPU is hot-(un)plugged to a guest (via > 'xl vcpu-set'). While this currently is only intended to be needed by > PVH guests we will call this domctl for all (x86) guests for consistency. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

On 09/11/16 14:39, Boris Ostrovsky wrote: > ACPI hotplug-related IO accesses (to GPE0 block) are handled > by qemu for HVM guests. Since PVH guests don't have qemu these > accesses will need to be procesed by the hypervisor. > > Because ACPI event model expects pm1a block to be present we > need

Re: [Xen-devel] [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 09 November 2016 14:40 > To: xen-devel@lists.xen.org > Cc: jbeul...@suse.com; Andrew Cooper ; > Wei Liu ; Ian Jackson ; Roger >

Re: [Xen-devel] [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 09 November 2016 14:40 > To: xen-devel@lists.xen.org > Cc: jbeul...@suse.com; Andrew Cooper ; > Wei Liu ; Ian Jackson ; Roger >

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

>>> On 09.11.16 at 15:28, wrote: > On 11/09/2016 01:17 PM, Jan Beulich wrote: > On 09.11.16 at 10:42, wrote: >>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info) >>> +{ >>> +struct vmcb_struct *vmcb =

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

On 11/09/2016 09:48 AM, Julien Grall wrote: > Hi Boris, > > On 09/11/16 14:39, Boris Ostrovsky wrote: >> diff --git a/xen/include/public/arch-arm.h >> b/xen/include/public/arch-arm.h >> index bd974fb..b793774 100644 >> --- a/xen/include/public/arch-arm.h >> +++ b/xen/include/public/arch-arm.h >>

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 09 November 2016 14:40 > To: xen-devel@lists.xen.org > Cc: jbeul...@suse.com; Andrew Cooper ; > Wei Liu ; Ian Jackson ; Roger >

Re: [Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

Hi Boris, On 09/11/16 14:39, Boris Ostrovsky wrote: diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index bd974fb..b793774 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t; * should

Re: [Xen-devel] Help regarding bringing up dom0 for lager board

Thanks it was really the problem of dts. I just followed the proceedings of Ferger in Mailing lists who tried to bring up Dom0 in lager, and I got it booted up. But now the problem is with rootfs. I am checking on that.. Thanks and regards, George On Tue, Nov 8, 2016 at 5:20 PM, Julien Grall

[Xen-devel] [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

PVH guests will have ACPI accesses emulated by the hypervisor as opposed to QEMU (as is the case for HVM guests) Support for IOREQ server emulation of CPU hotplug is indicated by XEN_X86_EMU_IOREQ_CPUHP flag. Logic for the handler will be provided by a later patch. Signed-off-by: Boris

[Xen-devel] [PATCH v2 06/11] acpi: PVH guests need _E02 method

This is the method that will get invoked on an SCI. Signed-off-by: Boris Ostrovsky Reviewed-by: Andrew Cooper --- tools/libacpi/mk_dsdt.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[Xen-devel] [PATCH v2 10/11] pvh: Send an SCI on VCPU hotplug event

.. and update GPE0 registers. Signed-off-by: Boris Ostrovsky --- Changes in v2: * Use has_ioreq_cpuhp() instead of ioreq_gmfn.mask==0 as check for PVH guest xen/arch/x86/domctl.c | 12 1 file changed, 12 insertions(+) diff --git

[Xen-devel] [PATCH v2 11/11] docs: Describe PVHv2's VCPU hotplug procedure

Signed-off-by: Boris Ostrovsky --- Changes in v2: * New patch docs/misc/hvmlite.markdown | 12 1 file changed, 12 insertions(+) diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown index 898b8ee..0045d22 100644 ---

[Xen-devel] [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus

This domctl is called when a VCPU is hot-(un)plugged to a guest (via 'xl vcpu-set'). While this currently is only intended to be needed by PVH guests we will call this domctl for all (x86) guests for consistency. Signed-off-by: Boris Ostrovsky Acked-by: Daniel De

[Xen-devel] [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

Signed-off-by: Boris Ostrovsky --- CC: Paul Durrant --- Changes in v2: * Use 'true/false' values for bools xen/arch/x86/hvm/ioreq.c | 72 1 file changed, 72 insertions(+) diff --git

[Xen-devel] [PATCH v2 05/11] acpi: Power and Sleep ACPI buttons are not emulated for PVH guests

Signed-off-by: Boris Ostrovsky --- Changes in v2: * HVM guests continue having the buttons tools/firmware/hvmloader/util.c | 3 ++- tools/libacpi/build.c | 2 ++ tools/libacpi/libacpi.h | 1 + 3 files changed, 5 insertions(+), 1 deletion(-) diff

[Xen-devel] [PATCH v2 09/11] events/x86: Define SCI virtual interrupt

PVH guests do not have IOAPIC which typically generates an SCI. For those guests SCI will be provided as a virtual interrupt. We also move VIRQ_MCA definition out of xen-mca.h to keep all x86-specific VIRQ_ARCH_* in one place. Signed-off-by: Boris Ostrovsky ---

[Xen-devel] [PATCH v2 00/11] PVH VCPU hotplug support

This series adds support for ACPI-based VCPU hotplug for unprivileged PVH guests. New XEN_DOMCTL_set_avail_vcpus is introduced and is called during guest creation and in response to 'xl vcpu-set' command. This domctl updates GPE0's status and enable registers and sends an SCI to the guest using

[Xen-devel] [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests

ACPI hotplug-related IO accesses (to GPE0 block) are handled by qemu for HVM guests. Since PVH guests don't have qemu these accesses will need to be procesed by the hypervisor. Because ACPI event model expects pm1a block to be present we need to have the hypervisor emulate it as well.

[Xen-devel] [PATCH v2 03/11] pvh: Set online VCPU map to avail_vcpus

ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT. With ACPI-based CPU hotplug we only want VCPUs that are started by the guest to be marked as such. Remaining VCPUs will be set to "enable" by AML code during hotplug. Signed-off-by: Boris Ostrovsky

[Xen-devel] [PATCH v2 04/11] acpi: Make pmtimer optional in FADT

PM timer is not supported by PVH guests. Signed-off-by: Boris Ostrovsky Reviewed-by: Konrad Rzeszutek Wilk --- tools/firmware/hvmloader/util.c | 3 ++- tools/libacpi/build.c | 5 + tools/libacpi/libacpi.h | 1 + 3 files

[Xen-devel] [distros-debian-squeeze test] 68018: tolerable FAIL

flight 68018 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68018/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 67978

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

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

[Xen-devel] [OSSTEST PATCH 2/3] rump build tests: Introduce ts-xen-build-rump

We are going to want to pass a whole slew of options to configure, and hence to ts-xen-build. I think putting that in sg-run-job is undesirable. So, split out the ts-xen-build invocation into its own script. Explicitly set the testid so that it does not change. No significant functional change.

[Xen-devel] [OSSTEST PATCH 3/3] rump build tests: Disable a lot of unwanted Xen things at configure time

Amongst other things, we disable rombios which requires lzma. Signed-off-by: Ian Jackson --- ts-xen-build-rump | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ts-xen-build-rump b/ts-xen-build-rump index 7ce3e73..9ea595b 100755 --- a/ts-xen-build-rump +++

[Xen-devel] [OSSTEST PATCH 0/3] Fix rump tests for lzma et al

Between my last series for fixing the rump tests in osstest, xen.git grew a dependency on liblzma which causese the rump build of the Xen tools to fail. Here I fix this by disabling lots of unwanted stuff by passing appropriate --disable-whatever options to the xen.git configure script. I ran an

[Xen-devel] [OSSTEST PATCH 1/3] ts-xen-build: Support passing arguments to configure

No functional change with existing callers. Signed-off-by: Ian Jackson --- ts-xen-build | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/ts-xen-build b/ts-xen-build index 3e53d74..7dfcda7 100755 --- a/ts-xen-build +++ b/ts-xen-build @@

[Xen-devel] [qemu-mainline test] 102049: regressions - FAIL

flight 102049 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/102049/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101909

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

On 11/09/2016 01:17 PM, Jan Beulich wrote: On 09.11.16 at 10:42, wrote: >> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info) >> +{ >> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb; >> + >> +if ( vmcb->eventinj.fields.v ) >> +

Re: [Xen-devel] question: is it a CVE in relinquish_memory()[xen/arch/x86/domain.c]

>>> On 09.11.16 at 13:01, wrote: > Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between > relinquish_memory and free_domheap_pages'.. > relinquish_memory() [xen/arch/arm/domain.c, arm code], > when couldn't get a reference -- someone is freeing this

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Don't clobber eax and edx if an RDMSR intercept fails

>>> On 09.11.16 at 13:28, wrote: > The original code has a bug; eax and edx get unconditionally updated even when > hvm_msr_read_intercept() doesn't return X86EMUL_OKAY. > > It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content > pointer) that

[Xen-devel] Xen, EFI and kexec

Hi, A bit of background: What I'm currently trying to do is to network boot a first linux image in EFI mode (using UEFI network boot), then from that image, kexec into Xen in EFI mode as well. It's not working. When you kexec into another linux in EFI mode, kexec actually passes some more

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

flight 102058 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/102058/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 102026 test-armhf-armhf-libvirt-qcow2

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

>>> On 09.11.16 at 12:49, wrote: > On 09/11/16 11:32, Razvan Cojocaru wrote: >> On 11/09/2016 01:17 PM, Jan Beulich wrote: >> On 09.11.16 at 10:42, wrote: @@ -259,6 +266,13 @@ struct vm_event_cpuid { uint32_t _pad; };

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

On 11/09/2016 04:04 PM, Jan Beulich wrote: On 09.11.16 at 12:32, wrote: >> On 11/09/2016 01:17 PM, Jan Beulich wrote: >> On 09.11.16 at 10:42, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -532,11

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

>>> On 09.11.16 at 12:32, wrote: > On 11/09/2016 01:17 PM, Jan Beulich wrote: > On 09.11.16 at 10:42, wrote: >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

On 11/09/2016 01:17 PM, Jan Beulich wrote: >> @@ -259,6 +266,13 @@ struct vm_event_cpuid { >> > uint32_t _pad; >> > }; >> > >> > +struct vm_event_interrupt { >> > +uint32_t vector; >> > +uint32_t type; >> > +uint32_t error_code; >> > +uint64_t cr2; >> > +}; > This being

Re: [Xen-devel] [RFC PATCH 13/24] ARM: vITS: handle CLEAR command

Hi, On 09/11/16 00:39, Stefano Stabellini wrote: On Wed, 28 Sep 2016, Andre Przywara wrote: This introduces the ITS command handler for the CLEAR command, which clears the pending state of an LPI. This removes a not-yet injected, but already queued IRQ from a VCPU. In addition this patch

Re: [Xen-devel] [PATCH v3 2/2] Partially revert 21550029f709072aacf3b90edd574e7d3021b400

Hi Stefano, On 08/11/16 19:42, Stefano Stabellini wrote: @@ -1189,7 +1194,10 @@ static int __init gicv2_init(void) printk(XENLOG_WARNING "GICv2: Adjusting CPU interface base to %#"PRIx64"\n", cbase + aliased_offset); -} +} else if ( csize ==

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

flight 102045 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102045/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 102008

[Xen-devel] [linux-3.4 test] 102041: regressions - FAIL

flight 102041 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102041/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 92983

[Xen-devel] [PATCH for-4.8] x86/svm: Don't clobber eax and edx if an RDMSR intercept fails

The original code has a bug; eax and edx get unconditionally updated even when hvm_msr_read_intercept() doesn't return X86EMUL_OKAY. It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content pointer) that this isn't an information leak into guests. While fixing this bug, reduce

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Hello, On 09/11/16 07:14, Dirk Behme wrote: On 08.11.2016 16:41, Iurii Mykhalskyi wrote: Hello Dirk, I have made only single change - I recompile ATF to leave CPU in EL2 mode and reflash it. Yes, this is what I meant with 'modifying firmware' ;) You are loading Xen with U-Boot running in

Re: [Xen-devel] [PATCH] x86emul: correct direction of FPU insn emulations

On 09/11/16 08:25, Jan Beulich wrote: > There are two cases where this was wrong, albeit in a benign way (the > compiler - according to my checking - didn't leverage the wrongness > for any optimizations affecting overall outcome). > > Signed-off-by: Jan Beulich Reviewed-by:

[Xen-devel] question: is it a CVE in relinquish_memory()[xen/arch/x86/domain.c]

Hi, Based on CVE-2015-7814 and commit 1ef01396fdff, ' arm: handle races between relinquish_memory and free_domheap_pages'.. relinquish_memory() [xen/arch/arm/domain.c, arm code], when couldn't get a reference -- someone is freeing this page and has already committed to doing so, so no more to

Re: [Xen-devel] [PATCH for-4.8] libxc: fix unmap of ACPI guest memory region

On 08/11/16 16:22, Roger Pau Monne wrote: > Commit fac7f7 changed the value of ptr so that it points to the right memory > area, taking the page offset into account, but failed to remove this when > doing the unmap, which caused the region to not be unmapped. Fix this by not > modifying ptr and

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

On 09/11/16 11:32, Razvan Cojocaru wrote: > On 11/09/2016 01:17 PM, Jan Beulich wrote: > On 09.11.16 at 10:42, wrote: >>> Added support for a new event type, VM_EVENT_REASON_INTERRUPT, >>> which is now fired in a one-shot manner when enabled via the new >>>

Re: [Xen-devel] CPUID improvements (phase 2) Design Doc

On 09/11/16 08:31, Jan Beulich wrote: On 08.11.16 at 19:36, wrote: >> On 08/11/16 16:32, Jan Beulich wrote: >> On 08.11.16 at 16:35, wrote: Please find inline the design doc for further CPUID improvements, planned for

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

On 11/09/2016 01:17 PM, Jan Beulich wrote: On 09.11.16 at 10:42, wrote: >> Added support for a new event type, VM_EVENT_REASON_INTERRUPT, >> which is now fired in a one-shot manner when enabled via the new >> VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag.

Re: [Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

>>> On 09.11.16 at 10:42, wrote: > Added support for a new event type, VM_EVENT_REASON_INTERRUPT, > which is now fired in a one-shot manner when enabled via the new > VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag. > The patch also fixes the behaviour of the

[Xen-devel] [xen-unstable-coverity test] 102062: all pass - PUSHED

flight 102062 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/102062/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen bcb13635fa503113c981c6ea7423f930c1548452 baseline version: xen

Re: [Xen-devel] per-domain logging

Hi Wei, Ian, I now have a big lot of changes to use the LOG*D family through the libxl code. What should be the best way to submit that for review? I guess a giant commit won't be too easy to handle for review and maintenance, maybe I should have one commit per changed file... any opinion on

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

flight 102050 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102050/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 008e2ccf02e7be65b3a1b48a925f005115027d1c baseline version: ovmf

[Xen-devel] [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

Added support for a new event type, VM_EVENT_REASON_INTERRUPT, which is now fired in a one-shot manner when enabled via the new VM_EVENT_FLAG_GET_NEXT_INTERRUPT vm_event response flag. The patch also fixes the behaviour of the xc_hvm_inject_trap() hypercall, which would lead to non-architectural

[Xen-devel] [linux-3.10 test] 102032: regressions - FAIL

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

Re: [Xen-devel] [PATCH v7 4/6] VT-d: No need to set irq affinity for posted format IRTE

> > > 2. if previous p is 1 and it is in remapped mode, we can only set it to > > remapped mode in _this_ function, setting it to posted mode is in > > another function: pi_update_irte(). > > Which may be part of the problem: Why are there two functions? > I think the reason is that

Re: [Xen-devel] [PATCH v3 00/15] Enable L2 Cache Allocation Technology

>>> On 09.11.16 at 02:28, wrote: > Any comment or suggestion to this patch set? That would be very appreciated. Please be assured that this has not been forgotten, but there are more important things to deal with, so it may take some more time to get to this. That's

Re: [Xen-devel] CPUID improvements (phase 2) Design Doc

>>> On 08.11.16 at 19:36, wrote: > On 08/11/16 16:32, Jan Beulich wrote: > On 08.11.16 at 16:35, wrote: >>> Please find inline the design doc for further CPUID improvements, planned >>> for >>> development during the 4.9 timeframe. >>

Re: [Xen-devel] [PATCH for-4.8] libxc: fix unmap of ACPI guest memory region

On Tue, Nov 08, 2016 at 12:19:06PM -0500, Boris Ostrovsky wrote: > > > On 11/08/2016 11:22 AM, Roger Pau Monne wrote: > > Commit fac7f7 changed the value of ptr so that it points to the right memory > > area, taking the page offset into account, but failed to remove this when > > doing the

[Xen-devel] [PATCH] x86emul: correct direction of FPU insn emulations

There are two cases where this was wrong, albeit in a benign way (the compiler - according to my checking - didn't leverage the wrongness for any optimizations affecting overall outcome). Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++