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

flight 99754 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99754/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 96660

[Xen-devel] [PATCH] x86/vMsi-x: check whether msixtbl_list in msixtbl_pt_register()

MSI-x tables' initializtion had been deferred in the commit 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798. If an assigned device does not support MSI-x, the msixtbl_list won't be initialized. However, the following paths XEN_DOMCTL_bind_pt_irq pt_irq_create_bind

[Xen-devel] [linux-3.14 baseline-only test] 66862: trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 66862 linux-3.14 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66862/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt

Re: [Xen-devel] [PATCH] x86/vMsi-x: check whether the msixtbl_list has been initialized or not when accessing it

On Fri, Jul 29, 2016 at 10:30:07AM +0100, Andrew Cooper wrote: >On 29/07/16 02:35, Chao Gao wrote: >> MSI-x tables' initialization had been detered in the commit >> 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798. If an assigned device does not >> support >> MSI-x, the msixtbl_list won't be initialized.

[Xen-devel] [xen-4.5-testing test] 99752: tolerable FAIL - PUSHED

flight 99752 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99752/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 96516 test-amd64-amd64-xl-rtds

Re: [Xen-devel] [PATCH] arm/vm_event: get/set registers

On Thu, Jul 28, 2016 at 10:16 PM, Razvan Cojocaru wrote: > On 07/29/16 00:25, Julien Grall wrote: >> >> >> On 28/07/2016 22:05, Tamas K Lengyel wrote: >>> On Thu, Jul 28, 2016 at 3:01 PM, Julien Grall >>> wrote: >>> That's not how we do it with

Re: [Xen-devel] [PATCH] xen/arm: p2m: Don't use default access permission when shattering a superpage

On Fri, Jul 29, 2016 at 12:53 PM, Julien Grall wrote: > The following message flood the console when memaccess is enabled on > various platforms: > > traps.c:2510:d1v0 HSR=0x9383004f pc=0x08b7d4c4 gva=0x08eeb8e0 > gpa=0x004903f8e0 > > This is because a

[Xen-devel] [PATCH] docs: define semantics of vncpasswd in xl.cfg

A recent discussion around LSN-2016-0001 [1] included defining the sematics of an empty string for a VNC password. It was stated that "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted". The same applies for vncpasswd setting in

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

flight 99748 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/99748/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 99672

Re: [Xen-devel] [RFC 13/22] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

On Fri, Jul 29, 2016 at 9:06 AM, Julien Grall wrote: > > > On 28/07/16 18:36, Tamas K Lengyel wrote: >> >> On Thu, Jul 28, 2016 at 11:29 AM, Tamas K Lengyel >> wrote: >>> >>> On Thu, Jul 28, 2016 at 8:51 AM, Julien Grall >>>

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Fri, Jul 29, 2016 at 3:38 PM, Julien Grall wrote: > > > On 29/07/2016 22:02, Tamas K Lengyel wrote: >> >> On Fri, Jul 29, 2016 at 11:38 AM, Stefano Stabellini >> wrote: >>> >>> On Fri, 29 Jul 2016, Tamas K Lengyel wrote: On Jul 29, 2016

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On 29/07/2016 22:02, Tamas K Lengyel wrote: On Fri, Jul 29, 2016 at 11:38 AM, Stefano Stabellini wrote: On Fri, 29 Jul 2016, Tamas K Lengyel wrote: On Jul 29, 2016 02:50, "Julien Grall" wrote: On 28/07/16 23:54, Tamas K Lengyel wrote: On

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Fri, Jul 29, 2016 at 11:38 AM, Stefano Stabellini wrote: > On Fri, 29 Jul 2016, Tamas K Lengyel wrote: >> On Jul 29, 2016 02:50, "Julien Grall" wrote: >> > >> > >> > >> > On 28/07/16 23:54, Tamas K Lengyel wrote: >> >> >> >> On Thu, Jul 28, 2016

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Fri, Jul 29, 2016 at 10:27 AM, Andrew Cooper wrote: > On 29/07/16 15:21, Tamas K Lengyel wrote: > > On Jul 29, 2016 02:50, "Julien Grall" wrote: >> >> >> >> On 28/07/16 23:54, Tamas K Lengyel wrote: >>> >>> On Thu, Jul 28, 2016 at 2:38 PM,

[Xen-devel] [linux-3.14 test] 99747: tolerable FAIL - PUSHED

flight 99747 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/99747/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 96226 build-i386-rumpuserxen

Re: [Xen-devel] [RFC 00/22] xen/arm: Rework the P2M code to follow break-before-make sequence

On 29/07/16 17:23, Julien Grall wrote: On 28/07/16 18:46, Tamas K Lengyel wrote: Hi Julien, Hello, I sent this patch series as an RFC because there are still some TODOs in the code (mostly sanity check and possible optimization) and I have done limited testing. However, I think it is a

Re: [Xen-devel] [PATCH RFC 06/12] xen/x86: populate PVHv2 Dom0 physical memory map

On 29/07/16 17:29, Roger Pau Monne wrote: > Craft the Dom0 e820 memory map and populate it. > > Signed-off-by: Roger Pau Monné > --- > Cc: Jan Beulich > Cc: Andrew Cooper > --- > xen/arch/x86/domain_build.c | 199 >

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

flight 99741 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/99741/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 96211

[Xen-devel] [PATCH] xen/arm: p2m: Don't use default access permission when shattering a superpage

The following message flood the console when memaccess is enabled on various platforms: traps.c:2510:d1v0 HSR=0x9383004f pc=0x08b7d4c4 gva=0x08eeb8e0 gpa=0x004903f8e0 This is because a data abort from a guest was received due to a permission fault but memaccess thought there

Re: [Xen-devel] [PATCH RFC 05/12] xen/x86: make print_e820_memory_map global

On 29/07/16 17:29, Roger Pau Monne wrote: > So that it can be called from the Dom0 builder. > > Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH RFC 04/12] xen/x86: split Dom0 build into PV and PVHv2

On 29/07/16 17:28, Roger Pau Monne wrote: > Split the Dom0 builder into two different functions, one for PV (and classic > PVH), and another one for PVHv2. Introduce a new command line parameter, > dom0hvm in order to request the creation of a PVHv2 Dom0. > > Signed-off-by: Roger Pau Monné

Re: [Xen-devel] [PATCH RFC 03/12] xen/x86: allow the emulated APICs to be enbled for the hardware domain

On 29/07/16 17:28, Roger Pau Monne wrote: > if ( is_hardware_domain(d) ) > -config->emulation_flags |= XEN_X86_EMU_PIT; > -if ( config->emulation_flags != 0 && > - (config->emulation_flags != > - (is_hvm_domain(d) ? XEN_X86_EMU_ALL :

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Fri, 29 Jul 2016, Tamas K Lengyel wrote: > On Jul 29, 2016 02:50, "Julien Grall" wrote: > > > > > > > > On 28/07/16 23:54, Tamas K Lengyel wrote: > >> > >> On Thu, Jul 28, 2016 at 2:38 PM, Julien Grall wrote: > >>> > >>> On 28/07/2016 20:35, Tamas K

Re: [Xen-devel] [RFC v3 05/13] sections.h: add sections header to collect all section info

On Fri, 22 Jul 2016 22:37:16 +0100 James Hogan wrote: > > --- /dev/null > > +++ b/arch/alpha/include/asm/sections.h > > @@ -0,0 +1,6 @@ > > +#ifndef _ASM_ALPHA_SECTIONS_H > > +#define _ASM_ALPHA_SECTIONS_H > > + > > +#include > > + > > +#endif /* _ASM_ALPHA_SECTIONS_H

Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t

On Fri, 29 Jul 2016, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set'

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

On 29/07/16 17:28, Roger Pau Monne wrote: > diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c > index 107fc8c..1b270df 100644 > --- a/xen/arch/x86/mm/paging.c > +++ b/xen/arch/x86/mm/paging.c > @@ -953,6 +953,22 @@ void paging_write_p2m_entry(struct p2m_domain *p2m, > unsigned long

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

Thanks for writing this up. The whole email described accurately what we discussed. On Fri, Jul 29, 2016 at 05:18:10PM +0100, Ian Jackson wrote: > The three of us had an IRL conversation. Here is what I think we > agreed: > > * We intend to make the XTF runner capable of reading >

Re: [Xen-devel] [PATCH RFC 01/12] PVHv2 Dom0

Hello, Sorry, I've failed to Cc both Konrad and Boris on this... On Fri, Jul 29, 2016 at 06:28:55PM +0200, Roger Pau Monne wrote: > Hello, > > This is a very rough implementation of a PVHv2 Dom0. There are still a bunch > of things that will not work properly (like SR-IOV, MSI, MSI-X...), but

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On 29/07/16 17:18, Ian Jackson wrote: > The three of us had an IRL conversation. Here is what I think we > agreed: > > * We intend to make the XTF runner capable of reading > xenconsoled-created logfiles. Both XenRT and osstest configure > xenconsoled appropriately. > > The xtf runner will

[Xen-devel] [PATCH RFC 12/12] xen/x86: route legacy PCI interrupts to Dom0

This is done adding some Dom0 specific logic to the IO APIC emulation inside of Xen, so that writes to the IO APIC registers that should unmask an interrupt will take care of setting up this interrupt with Xen. A Dom0 specific EIO handler also has to be used, since Xen doesn't know the topology of

[Xen-devel] [PATCH RFC 03/12] xen/x86: allow the emulated APICs to be enbled for the hardware domain

Allow the used of both the emulated local APIC and IO APIC for the hardware domain. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/domain.c | 22 ++ 1 file changed,

[Xen-devel] [PATCH RFC 11/12] xen/x86: allow a PVHv2 Dom0 to register PCI devices with Xen

This patch allows a PVHv2 Dom0 to register PCI devices with Xen using PHYSDEVOP_pci_mmcfg_reserved, PHYSDEVOP_pci_device_add and PHYSDEVOP_pci_device_remove. The functionality of the pci_device_add function has been expanded so that for PVHv2 Dom0 it also sizes the PCI device BARs and adds them to

[Xen-devel] [PATCH RFC 08/12] xen/x86: setup PVHv2 Dom0 CPUs

Initialize Dom0 BSP/APs and setup the memory and IO permissions. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- The logic used to setup the CPUID leaves is extremely simplistic (and probably wrong for

[Xen-devel] [PATCH RFC 02/12] xen/x86: split the setup of Dom0 permissions to a function

So that it can also be used by the PVH-specific domain builder. This is just code motion, it should not introduce any functional change. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper ---

[Xen-devel] [PATCH RFC 10/12] xen/dcpi: add a dpci passthrough handler for hardware domain

This is very similar to the PCI trap used for the traditional PV(H) Dom0. Signed-off-by: Roger Pau Monné --- Cc: Paul Durrant Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/hvm/io.c | 72

[Xen-devel] [PATCH RFC 07/12] xen/x86: parse Dom0 kernel for PVHv2

Introduce a helper to parse the Dom0 kernel. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/domain_build.c | 139 1 file changed, 139

[Xen-devel] [PATCH RFC 09/12] xen/x86: setup PVHv2 Dom0 ACPI tables

This maps all the regions in the e820 marked as E820_ACPI or E820_NVS to Dom0 1:1. It also shadows the page(s) where the native MADT is placed by mapping a RAM page over it, copying the original data and modifying it afterwards in order to represent the real CPU topology exposed to Dom0.

[Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

... and remove hap_set_alloc_for_pvh_dom0. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap Cc: Tim Deegan --- xen/arch/x86/domain_build.c

[Xen-devel] [PATCH RFC 04/12] xen/x86: split Dom0 build into PV and PVHv2

Split the Dom0 builder into two different functions, one for PV (and classic PVH), and another one for PVHv2. Introduce a new command line parameter, dom0hvm in order to request the creation of a PVHv2 Dom0. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich

[Xen-devel] [PATCH RFC 05/12] xen/x86: make print_e820_memory_map global

So that it can be called from the Dom0 builder. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/e820.c| 2 +- xen/include/asm-x86/e820.h | 1 + 2 files changed, 2 insertions(+), 1

[Xen-devel] [PATCH RFC 01/12] PVHv2 Dom0

Hello, This is a very rough implementation of a PVHv2 Dom0. There are still a bunch of things that will not work properly (like SR-IOV, MSI, MSI-X...), but it *should* be able to boot a Dom0 kernel and it doesn't require using PIRQs. There are some changes compared to a traditional PV or PVH

[Xen-devel] [PATCH RFC 06/12] xen/x86: populate PVHv2 Dom0 physical memory map

Craft the Dom0 e820 memory map and populate it. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/domain_build.c | 199 ++-- 1 file changed, 193

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On 29/07/16 15:21, Tamas K Lengyel wrote: > > On Jul 29, 2016 02:50, "Julien Grall" > wrote: > > > > > > > > On 28/07/16 23:54, Tamas K Lengyel wrote: > >> > >> On Thu, Jul 28, 2016 at 2:38 PM, Julien Grall

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

The three of us had an IRL conversation. Here is what I think we agreed: * We intend to make the XTF runner capable of reading xenconsoled-created logfiles. Both XenRT and osstest configure xenconsoled appropriately. The xtf runner will need to - on each test, wait for the test

Re: [Xen-devel] [RFC 00/22] xen/arm: Rework the P2M code to follow break-before-make sequence

On 28/07/16 18:46, Tamas K Lengyel wrote: > Hi Julien, Hello, >> I sent this patch series as an RFC because there are still some TODOs >> in the code (mostly sanity check and possible optimization) and I have >> done limited testing. However, I think it is a good shape to start reviewing, >>

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Fri, Jul 29, 2016, at 09:03 AM, Konrad Rzeszutek Wilk wrote: > It may very well be added. Just fyi, it's not in here. Yet. > But having extra test-confirmation is always good. Right, and I'm glad to do that. I'd like to. Goal is to keep moving the ball forward. And I've been testing

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Fri, Jul 29, 2016 at 08:57:59AM -0700, li...@ssl-mail.com wrote: > > > On Fri, Jul 29, 2016, at 08:42 AM, Konrad Rzeszutek Wilk wrote: > > did you apply the patch that Vitaly pointed out? > > No. It wasn't clear that it was anything more than a question to > "double-check". There wasn't

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Fri, Jul 29, 2016, at 08:42 AM, Konrad Rzeszutek Wilk wrote: > did you apply the patch that Vitaly pointed out? No. It wasn't clear that it was anything more than a question to "double-check". There wasn't any further comment on my reply. I'm depending on working packages for now. Like

Re: [Xen-devel] OVMF very slow on AMD

On Thu, Jul 28, 2016 at 03:54:34PM -0400, Boris Ostrovsky wrote: > On 07/28/2016 03:44 PM, Andrew Cooper wrote: > As far as Intel vs AMD implementation in Xen, we have vmx_handle_cd() > but no corresponding SVM code. Could it be that we need to set gPAT, for > example? > >>> A

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Fri, Jul 29, 2016 at 07:36:57AM -0700, li...@ssl-mail.com wrote: > On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote: > > This looks suspiciously like the issue which was fixed by c/s > > d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when > > setting early page table

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On 29/07/16 15:31, Ian Jackson wrote: > Wei Liu writes ("Re: [XTF PATCH] xtf-runner: fix two synchronisation issues"): >> On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: >>> The runner existing before xl has torn down the guest is very >>> deliberate, because some part of hvm guests

Re: [Xen-devel] [RFC 13/22] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

On 28/07/16 18:36, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 11:29 AM, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 8:51 AM, Julien Grall wrote: __p2m_lookup is just a wrapper to p2m_get_entry. Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH v7 00/15] Load BIOS via toolstack instead of been embedded in hvmloader.

On 07/29/2016 10:50 AM, Wei Liu wrote: > >>> You need to run ./autogen.sh. Anthony didn't commit the changes to >>> ./configure. >> >> Yes, that did the trick. Except for the machine on which I actually >> wanted it to run: >> >> root@ovs104> ./autogen.sh >> configure.ac:4: error: Autoconf version

Re: [Xen-devel] [PATCH v7 00/15] Load BIOS via toolstack instead of been embedded in hvmloader.

On Fri, Jul 29, 2016 at 10:36:02AM -0400, Boris Ostrovsky wrote: > On 07/29/2016 04:29 AM, Wei Liu wrote: > > On Fri, Jul 29, 2016 at 01:28:02AM -0400, Boris Ostrovsky wrote: > >> > >> On 07/28/2016 06:49 AM, Anthony PERARD wrote: > >>> Hi all, > >>> > >>> Changes in V7: > >>> - There is one new

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On Fri, Jul 29, 2016 at 03:31:30PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [XTF PATCH] xtf-runner: fix two synchronisation issues"): > > On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: > > > The runner existing before xl has torn down the guest is very > > > deliberate,

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On Fri, Jul 29, 2016 at 03:35:06PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [XTF PATCH] xtf-runner: fix two synchronisation issues"): > > On Fri, Jul 29, 2016 at 03:21:52PM +0100, Ian Jackson wrote: > > > Wei Liu writes ("[XTF PATCH] xtf-runner: fix two synchronisation issues"): > > > >

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

On Wed, Jul 27, 2016, at 09:34 AM, Andrew Cooper wrote: > This looks suspiciously like the issue which was fixed by c/s > d6b186c1e2d852a92c43f090d0d8fad4704d51ef "x86/xen: avoid m2p lookup when > setting early page table entries", but that fix is present in Linux 4.7.0 > > Can you check to see

Re: [Xen-devel] [PATCH v7 00/15] Load BIOS via toolstack instead of been embedded in hvmloader.

On 07/29/2016 04:29 AM, Wei Liu wrote: > On Fri, Jul 29, 2016 at 01:28:02AM -0400, Boris Ostrovsky wrote: >> >> On 07/28/2016 06:49 AM, Anthony PERARD wrote: >>> Hi all, >>> >>> Changes in V7: >>> - There is one new patch at the end to fix the doc. >>> - Patch 6 as been change. >>> that's

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

Wei Liu writes ("Re: [XTF PATCH] xtf-runner: fix two synchronisation issues"): > On Fri, Jul 29, 2016 at 03:21:52PM +0100, Ian Jackson wrote: > > Wei Liu writes ("[XTF PATCH] xtf-runner: fix two synchronisation issues"): > > > There were two synchronisation issues for the old code: > > > > > > 1.

[Xen-devel] [qemu-upstream-4.5-testing baseline-only test] 66860: regressions - trouble: broken/fail/pass

This run is configured for baseline tests only. flight 66860 qemu-upstream-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66860/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 3

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Jul 29, 2016 01:27, "Razvan Cojocaru" wrote: > > On 07/28/2016 10:35 PM, Tamas K Lengyel wrote: > > The two functions monitor_traps and mem_access_send_req duplicate > > some of the same functionality. The mem_access_send_req however leaves a > > lot of the standard

Re: [Xen-devel] [PATCH] arm/vm_event: get/set registers

On Jul 29, 2016 08:21, "Razvan Cojocaru" wrote: > > On 07/29/2016 05:11 PM, Julien Grall wrote: > > Which lead to my next question. For instance, we have an app A which is > > built for Xen 4.N and they want to also support Xen 4.(N + 1) which will > > set more

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

Wei Liu writes ("Re: [XTF PATCH] xtf-runner: fix two synchronisation issues"): > On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: > > The runner existing before xl has torn down the guest is very > > deliberate, because some part of hvm guests is terribly slow to tear > > down;

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On 29/07/16 15:21, Ian Jackson wrote: > Wei Liu writes ("[XTF PATCH] xtf-runner: fix two synchronisation issues"): >> There were two synchronisation issues for the old code: >> >> 1. There was no guarantee that guest console was ready before "xl >>console" invocation. > Is this not a bug in xl

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On Fri, Jul 29, 2016 at 03:21:52PM +0100, Ian Jackson wrote: > Wei Liu writes ("[XTF PATCH] xtf-runner: fix two synchronisation issues"): > > There were two synchronisation issues for the old code: > > > > 1. There was no guarantee that guest console was ready before "xl > >console"

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

Wei Liu writes ("[XTF PATCH] xtf-runner: fix two synchronisation issues"): > There were two synchronisation issues for the old code: > > 1. There was no guarantee that guest console was ready before "xl >console" invocation. Is this not a bug in xl console ? > 2. Poll xenstore guest console

Re: [Xen-devel] [PATCH] arm/vm_event: get/set registers

On 07/29/2016 05:11 PM, Julien Grall wrote: > Which lead to my next question. For instance, we have an app A which is > built for Xen 4.N and they want to also support Xen 4.(N + 1) which will > set more registers and take advantage of it. How the app will > differentiate the 2 versions? We

Re: [Xen-devel] [PATCH] mem_access: Use monitor_traps instead of mem_access_send_req

On Jul 29, 2016 02:50, "Julien Grall" wrote: > > > > On 28/07/16 23:54, Tamas K Lengyel wrote: >> >> On Thu, Jul 28, 2016 at 2:38 PM, Julien Grall wrote: >>> >>> On 28/07/2016 20:35, Tamas K Lengyel wrote: >>> This patch is doing more than it is

Re: [Xen-devel] [PATCH] arm/vm_event: get/set registers

Hi Tamas, On 28/07/16 23:45, Tamas K Lengyel wrote: On Thu, Jul 28, 2016 at 4:03 PM, Julien Grall wrote: On 28/07/2016 22:33, Tamas K Lengyel wrote: On Jul 28, 2016 15:25, "Julien Grall" > wrote: On 28/07/2016

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On 29/07/16 13:07, Wei Liu wrote: > > if __name__ == "__main__": > +signal.signal(signal.SIGALRM, sigalrm_handler) > try: > sys.exit(main()) > except RunnerError, e: One final thing before I forget, this addition should be in main(), rather than here. This bit of code

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On Fri, Jul 29, 2016 at 02:23:20PM +0100, Andrew Cooper wrote: > On 29/07/16 14:12, Wei Liu wrote: > > On Fri, Jul 29, 2016 at 02:06:56PM +0100, Andrew Cooper wrote: > >> On 29/07/16 13:58, Wei Liu wrote: > >>> On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: > On 29/07/16

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On 29/07/16 14:12, Wei Liu wrote: > On Fri, Jul 29, 2016 at 02:06:56PM +0100, Andrew Cooper wrote: >> On 29/07/16 13:58, Wei Liu wrote: >>> On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: On 29/07/16 13:07, Wei Liu wrote: > There were two synchronisation issues for the old

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: 29 July 2016 14:11 > To: Paul Durrant > Cc: Stefano Stabellini; Wei Liu; Andrew Cooper; xen-devel@lists.xen.org; > Anthony Perard; zhigang.x.w...@oracle.com > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to

Re: [Xen-devel] Default controller type for USB devices

On 29/07/16 14:00, Juergen Gross wrote: > When specifying no USB controller type for a usb device the default is > chosen in libxl__device_usbctrl_setdefault(). For a HVM guest this is > currently the not yet supported "LIBXL_USBCTRL_TYPE_DEVICEMODEL". > > Wouldn't it make sense to handle HVM

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On Fri, Jul 29, 2016 at 02:06:56PM +0100, Andrew Cooper wrote: > On 29/07/16 13:58, Wei Liu wrote: > > On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: > >> On 29/07/16 13:07, Wei Liu wrote: > >>> There were two synchronisation issues for the old code: > >>> > >>> 1. There was no

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

On Fri, Jul 29, Paul Durrant wrote: > > Could you give the attached patch a try? I believe it should solve the > > problem. Thanks Paul. I tested it with 4.4.20160610T12110 dom0 as sender and 4.6.20160620T12082 as receiver. Initially the result was this: # cat

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On 29/07/16 13:58, Wei Liu wrote: > On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: >> On 29/07/16 13:07, Wei Liu wrote: >>> There were two synchronisation issues for the old code: >>> >>> 1. There was no guarantee that guest console was ready before "xl >>>console" invocation.

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

On Fri, Jul 29, 2016 at 01:45:55PM +0200, Andreas Ziegler wrote: > Hello Wei, > > we tried with kernel 4.6 now, the crashed happened again, though. > > next we want to try the Xen debug build, but we couldn't find any > information on how to enable debug for the build, perhaps you could give >

[Xen-devel] Default controller type for USB devices

When specifying no USB controller type for a usb device the default is chosen in libxl__device_usbctrl_setdefault(). For a HVM guest this is currently the not yet supported "LIBXL_USBCTRL_TYPE_DEVICEMODEL". Wouldn't it make sense to handle HVM guests in the same way as PV guests as long as

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On Fri, Jul 29, 2016 at 01:43:42PM +0100, Andrew Cooper wrote: > On 29/07/16 13:07, Wei Liu wrote: > > There were two synchronisation issues for the old code: > > > > 1. There was no guarantee that guest console was ready before "xl > >console" invocation. > > 2. There was no guarantee that

[Xen-devel] [libvirt test] 99738: tolerable FAIL - PUSHED

flight 99738 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/99738/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12

Re: [Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

On 29/07/16 13:07, Wei Liu wrote: > There were two synchronisation issues for the old code: > > 1. There was no guarantee that guest console was ready before "xl >console" invocation. > 2. There was no guarantee that runner wouldn't not exit before all test >guests were gone. Sorry, but I

[Xen-devel] [qemu-upstream-unstable test] 99728: regressions - trouble: broken/fail/pass

flight 99728 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99728/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 3 host-install(3) broken REGR. vs. 94800

[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 66859: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 66859 qemu-upstream-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66859/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3

[Xen-devel] [XTF PATCH] xtf-runner: fix two synchronisation issues

There were two synchronisation issues for the old code: 1. There was no guarantee that guest console was ready before "xl console" invocation. 2. There was no guarantee that runner wouldn't not exit before all test guests were gone. For xtf-runner to be suitable to run in an automatic

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

Hello Wei, we tried with kernel 4.6 now, the crashed happened again, though. next we want to try the Xen debug build, but we couldn't find any information on how to enable debug for the build, perhaps you could give us a hint. - Andreas Original-Nachricht Betreff: Re:

[Xen-devel] [qemu-upstream-4.3-testing baseline-only test] 66861: tolerable trouble: blocked/broken/fail

This run is configured for baseline tests only. flight 66861 qemu-upstream-4.3-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66861/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-pvops 3

[Xen-devel] [PATCH 2/2] xen: drain submit queue in xen-usb before removing device

When unplugging a device in the Xen pvusb backend drain the submit queue before deallocation of the control structures. Otherwise there will be bogus memory accesses when I/O contracts are finished. Correlated to this issue is the handling of cancel requests: a packet cancelled will still lead to

[Xen-devel] [PATCH 0/2] xen: bug fixes in Xen backend handling

When testing qemu based pvusb backend two bugs have been discovered: - detaching of a usb controller leads to memory clobbering in qemu - detaching of a usb device with active I/O requests could result in crash of qemu Juergen Gross (2): xen: when removing a backend don't remove many of them

[Xen-devel] [PATCH 1/2] xen: when removing a backend don't remove many of them

When a Xenstore watch fires indicating a backend has to be removed don't remove all backends for that domain with the specified device index, but just the one which has the correct type. The easiest way to achieve this is to use the already determined xendev as parameter for xen_be_del_xendev()

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

> -Original Message- > From: Paul Durrant > Sent: 29 July 2016 11:12 > To: Paul Durrant; Olaf Hering > Cc: Stefano Stabellini; Wei Liu; Andrew Cooper; xen-devel@lists.xen.org; > Anthony Perard; zhigang.x.w...@oracle.com > Subject: RE: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in

[Xen-devel] [qemu-upstream-4.3-testing test] 99727: tolerable FAIL - PUSHED

flight 99727 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99727/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 96374

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Paul Durrant > Sent: 26 July 2016 16:49 > To: Olaf Hering > Cc: Stefano Stabellini; Wei Liu; Andrew Cooper; xen-devel@lists.xen.org; > Anthony Perard; zhigang.x.w...@oracle.com > Subject: Re:

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Jul 22, 2016 at 02:24:41PM -0700, Luis R. Rodriguez wrote: > A linker table is a data structure that is stitched together from items > in multiple object files. Linux has historically implicitly used linker > tables for ages, however they were all built in an adhoc manner which > requires

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default

On 29/07/16 08:33, kevin.ma...@gdata.de wrote: > > Hi guys > > > > We are using Xen 4.6.1 to manage our virtual machines on x86-64-servers. > > We start dozens of VMs and destroy them again after 60 seconds, which > works fine as it is, but the next step in our approach requires the > use of the

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default

On Fri, 2016-07-29 at 07:33 +, kevin.ma...@gdata.de wrote: > Hi guys >   Hi, I'm pretty much just Cc-ing maintainers/key people, to see if they have ideas. Only one thing. Since you are rebuilding Xen anyway, I think it could be helpful to try a debug build, and post the dump it will

[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 66857: regressions - trouble: broken/fail/pass

This run is configured for baseline tests only. flight 66857 qemu-upstream-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66857/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 3

[Xen-devel] [qemu-upstream-4.5-testing test] 99725: tolerable FAIL - PUSHED

flight 99725 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99725/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail like 95527

Re: [Xen-devel] [PATCH] x86/vMsi-x: check whether the msixtbl_list has been initialized or not when accessing it

On 29/07/16 02:35, Chao Gao wrote: > MSI-x tables' initialization had been detered in the commit > 74c6dc2d0ac4dcab0c6243cdf6ed550c1532b798. If an assigned device does not > support > MSI-x, the msixtbl_list won't be initialized. Howerver, both of following > paths > XEN_DOMCTL_bind_pt_irq >

[Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t

We pass xen_vcpu_id mapping information to hypercalls which require uint32_t type so it would be cleaner to have it as uint32_t. The initializer to -1 can be dropped as we always do the mapping before using it and we never check the 'not set' value anyway. Signed-off-by: Vitaly Kuznetsov

  1   2   >