[Xen-devel] [ovmf test] 94104: regressions - FAIL

flight 94104 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/94104/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 65543 build-amd64

[Xen-devel] [xen-4.5-testing test] 94079: regressions - FAIL

flight 94079 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94079/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 93989

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

Hi Julien and Dushyant, >>> (XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller ! (XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller ! (XEN) DOM0: [0.00] irq: no irq domain found for /interrupt-controller !

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

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94089: trouble: blocked/broken

flight 94089 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94089/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 3 host-install(3) broken

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

This run is configured for baseline tests only. flight 44413 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44413/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 4

Re: [Xen-devel] [PATCH v2] Xen: EFI: Parse DT parameters for Xen specific UEFI

(Including more folks, quoting entire patch) On Thu, 12 May, at 08:19:54PM, Shannon Zhao wrote: > From: Shannon Zhao > > The EFI DT parameters for bare metal are located under /chosen node, > while for Xen Dom0 they are located under /hyperviosr/uefi node. These >

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

flight 94073 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/94073/ 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] [RFC 11/16] xen/arm: Detect silicon revision and set cap bits accordingly

> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c > index 7a1b56b..aa7c5b1 100644 > --- a/xen/arch/arm/cpufeature.c > +++ b/xen/arch/arm/cpufeature.c > @@ -24,6 +24,22 @@ > > DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS); > > +void update_cpu_capabilities(const struct

Re: [Xen-devel] [PATCH V2] libxl: don't add cache mode for qdisk cdrom drives

On 05/10/2016 04:06 AM, Stefano Stabellini wrote: > On Mon, 9 May 2016, Wei Liu wrote: >> On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote: >>> qemu commit 91a097e7 forbids specifying cache mode for empty >>> drives. Attempting to create a domain with an empty qdisk cdrom >>> drive

[Xen-devel] [TESTDAY] Test report

* Hardware: ZCU102 ZynqMP board * Software: Rolled my own dom0 linux * Tested: Start dom0 The test fails with the following error: (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @

Re: [Xen-devel] [RFC 09/16] xen/arm: arm64: Add helpers to decode and encode branch instructions

> diff --git a/xen/include/asm-arm/arm64/insn.h > b/xen/include/asm-arm/arm64/insn.h > new file mode 100644 > index 000..cfcdbe9 > --- /dev/null > +++ b/xen/include/asm-arm/arm64/insn.h > @@ -0,0 +1,72 @@ > +/* > + * Copyright (C) 2013 Huawei Ltd. > + * Author: Jiang Liu >

Re: [Xen-devel] [RFC 10/16] xen/arm: Introduce alternative runtime patching

On Thu, May 05, 2016 at 05:34:19PM +0100, Julien Grall wrote: > Some of the processor erratum will require to modify code sequence. > As those modifications may impact the performance, they should only > be enabled on affected cores. Furthermore, Xen may also want to take > advantage of new

Re: [Xen-devel] [PATCH v4 0/4] arm64, xen: add xen_boot support into grup-mkconfig

On Tue, May 10, 2016 at 10:03:22PM +0800, fu@linaro.org wrote: > From: Fu Wei > > This patchset add xen_boot support into grup-mkconfig for > generating xen boot entrances automatically > All of them look good to me. Thanks! > Also update the docs/grub.texi for new

[Xen-devel] [PATCH] AMD IOMMU: Introduce support for IVHD block type 11h

From: Suravee Suthikulpanit Along with the IVHD block type 10h, newer AMD platforms also come with types 11h, which is a superset of the older one. Having multiple IVHD block types in the same platform allows backward compatibility of newer systems to work with

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

flight 94112 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/94112/ 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 12

[Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

From: Suravee Suthikulpanit The guest_iommu_init() is currently called by the following code path: arch/x86/domain.c: arch_domain_create() ]- drivers/passthrough/iommu.c: iommu_domain_init() |- drivers/passthrough/amd/pci_amd_iommu.c:

[Xen-devel] [PATCH V2 0/2] Fix xen crash when starting HVM guest due to missing io handler

From: Suravee Suthikulpanit Hi All, On systems with iommu v2 enabled, the hypervisor crashes when trying to start up an HVM guest. Investigating shows that the guest_iommu_init() is called before the HVM domain is initialized. It then tries to

[Xen-devel] [PATCH V2 1/2] x86/hvm: Add check when register io handler

From: Suravee Suthikulpanit At the time of registering HVM I/O handler, the HVM domain might not have been initialized, which means the hvm_domain.io_handler would be NULL. In the hvm_next_io_handler(), this should be checked before returning and referencing the

Re: [Xen-devel] [PATCH v3 1/6] build: add debug menu to Kconfig

On Tue, May 10, 2016 at 04:05:24PM -0500, Doug Goldstein wrote: > There are a number of debugging options for Xen so the idea is to have a > menu to group them all together. Enabling this menu item will also > disable NDEBUG which will result in more debug prints. This was > previously wired into

[Xen-devel] [PATCH v2 for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a general L1 p2m walk. It is fine for AMD as NPT share the same format as normal pagetables. For Intel EPT however, it is wrong. The translation ends up correct (as the formats are sufficiently similar), but the control

Re: [Xen-devel] [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling

On 13/05/16 18:02, Wei Liu wrote: > On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote: >> As has been explained previously[1], SMAP (and with less relevance >> also SMEP) is not compatible with 32-bit PV guests which aren't >> aware/prepared to be run with that feature enabled. Andrew's

[Xen-devel] [PATCH 0/2] Fix xen crash when starting HVM guest due to missing io handler

From: Suravee Suthikulpanit Hi All, On systems with iommu v2 enabled, the hypervisor crashes when trying to start up an HVM guest. Investigating shows that the guest_iommu_init() is called before the HVM domain is initialized. It then tries to

[Xen-devel] [PATCH 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

From: Suravee Suthikulpanit The guest_iommu_init() is currently called by the following code path: arch/x86/domain.c: arch_domain_create() ]- drivers/passthrough/iommu.c: iommu_domain_init() |- drivers/passthrough/amd/pci_amd_iommu.c:

[Xen-devel] [PATCH 1/2] x86/hvm: Add check when register io handler

From: Suravee Suthikulpanit At the time of registering HVM I/O handler, the HVM domain might not have been initialized, which means the hvm_domain.io_handler would be NULL. In the hvm_next_io_handler(), this should be checked before returning and referencing the

Re: [Xen-devel] [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling

On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote: > As has been explained previously[1], SMAP (and with less relevance > also SMEP) is not compatible with 32-bit PV guests which aren't > aware/prepared to be run with that feature enabled. Andrew's > original approach either sacrificed

[Xen-devel] [xen-4.4-testing test] 94065: tolerable FAIL - PUSHED

flight 94065 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94065/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail in 94038 pass in 94065

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

On Fri, May 13, 2016 at 10:12 AM, Jan Beulich wrote: On 13.05.16 at 17:31, wrote: >> On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote: >> On 13.05.16 at 16:50, wrote: On Fri, May 13, 2016 at 6:00

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

>>> On 13.05.16 at 17:35, wrote: > On 05/13/2016 11:09 AM, Jan Beulich wrote: > On 13.05.16 at 16:50, wrote: > [...] > @@ -1468,6 +1505,69 @@ int > mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) > } >

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

On Fri, 2016-05-13 at 10:23 +0100, Andrew Cooper wrote: > On 13/05/16 09:55, Jan Beulich wrote: > >  > > But anyway, L2 or L3 - I can't see how this context switching would > > DTRT when there are vCPU-s of different domains on the same > > socket (or core, if L2s and MSRs were per-core): The one

Re: [Xen-devel] [PATCH v3 5/4] x86: reduce code size of struct cpu_info member accesses

On 17/03/16 16:14, Jan Beulich wrote: > Instead of addressing these fields via the base of the stack (which > uniformly requires 4-byte displacements), address them from the end > (which for everything other than guest_cpu_user_regs requires just > 1-byte ones). This yields a code size reduction

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

>>> On 13.05.16 at 17:31, wrote: > On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote: > On 13.05.16 at 16:50, wrote: >>> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote: >>> On 12.05.16 at 17:25,

Re: [Xen-devel] [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

>>> On 13.05.16 at 17:57, wrote: > On 17/03/16 08:03, Jan Beulich wrote: >> Alternatives patching code picks the most suitable NOPs for the >> running system, so simply use it to replace the pre-populated ones. >> >> Use an arbitrary, always available feature to key off

Re: [Xen-devel] [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

On 13/05/16 17:06, Jan Beulich wrote: On 13.05.16 at 17:57, wrote: >> On 17/03/16 08:03, Jan Beulich wrote: >>> Alternatives patching code picks the most suitable NOPs for the >>> running system, so simply use it to replace the pre-populated ones. >>> >>> Use an

Re: [Xen-devel] [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

On 17/03/16 08:03, Jan Beulich wrote: > Since such guests' kernel code runs in ring 1, their memory accesses, > at the paging layer, are supervisor mode ones, and hence subject to > SMAP/SMEP checks. Such guests cannot be expected to be aware of those > two features though (and so far we also

Re: [Xen-devel] [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

On 17/03/16 08:03, Jan Beulich wrote: > Alternatives patching code picks the most suitable NOPs for the > running system, so simply use it to replace the pre-populated ones. > > Use an arbitrary, always available feature to key off from, but > hide this behind the new X86_FEATURE_ALWAYS. > >

Re: [Xen-devel] [PATCH v2 1/3] x86: suppress SMEP and SMAP while running 32-bit PV guest code

On 10/03/16 09:53, Jan Beulich wrote: > Since such guests' kernel code runs in ring 1, their memory accesses, > at the paging layer, are supervisor mode ones, and hence subject to > SMAP/SMEP checks. Such guests cannot be expected to be aware of those > two features though (and so far we also

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

>>> On 13.05.16 at 17:27, wrote: > We're approaching the release date so I would like to wrap this up. > > As I understand it, there is indeed an issue in the emulator, but a > proper fix that take into consideration all cases has not been proposed. > > Should we make this

Re: [Xen-devel] potential problem with qdisk backend

>>> On 06.05.16 at 13:41, wrote: > Looking at the qdisk backend implementation I wondered whether > blkif_get_x86_32_req() is really correct, especially for the > BLKIF_OP_DISCARD case. The Linux kernel based blk backend seems to > distinguish 32- and 64-bit layouts of

Re: [Xen-devel] [PATCH v2 2/3] x86: use optimal NOPs to fill the SMEP/SMAP placeholders

On 10/03/16 09:54, Jan Beulich wrote: > Alternatives patching code picks the most suitable NOPs for the > running system, so simply use it to replace the pre-populated ones. > > Use an arbitrary, always available feature to key off from, but > hide this behind the new X86_FEATURE_ALWAYS. > >

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

On 05/13/2016 11:09 AM, Jan Beulich wrote: On 13.05.16 at 16:50, wrote: [...] @@ -1468,6 +1505,69 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) } break; +case XENMEM_sharing_op_bulk_share: +{ +

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

On Fri, May 13, 2016 at 09:30:23AM -0600, Jan Beulich wrote: > >>> On 13.05.16 at 17:21, wrote: > > On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote: > >> >>> On 17.03.16 at 09:03, wrote: > >> > Since such guests' kernel code runs in ring 1, their memory accesses,

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

>>> On 13.05.16 at 17:24, wrote: > On 13/05/16 16:00, Andrew Cooper wrote: >> On 13/05/16 15:13, Jan Beulich wrote: >> On 13.05.16 at 15:33, wrote: --- a/xen/arch/x86/mm/hap/nested_hap.c +++ b/xen/arch/x86/mm/hap/nested_hap.c

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote: On 13.05.16 at 16:50, wrote: >> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote: >> On 12.05.16 at 17:25, wrote: +if ( !rc ) +

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

>>> On 13.05.16 at 17:21, wrote: > On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote: >> >>> On 17.03.16 at 09:03, wrote: >> > Since such guests' kernel code runs in ring 1, their memory accesses, >> > at the paging layer, are supervisor mode ones, and hence

[Xen-devel] [ovmf test] 94064: regressions - FAIL

flight 94064 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/94064/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 5 kernel-build fail REGR. vs. 65543 Tests which did not

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

>>> On 22.04.16 at 12:54, wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also specified > vpmu will be turned off. > As the virtualisation is not 100% safe, don't use

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

We're approaching the release date so I would like to wrap this up. As I understand it, there is indeed an issue in the emulator, but a proper fix that take into consideration all cases has not been proposed. Should we make this a blocker for the release? I'm inclined to say no because it has

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

On 13/05/16 16:00, Andrew Cooper wrote: > On 13/05/16 15:13, Jan Beulich wrote: > On 13.05.16 at 15:33, wrote: >>> --- a/xen/arch/x86/mm/hap/nested_hap.c >>> +++ b/xen/arch/x86/mm/hap/nested_hap.c >>> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct

Re: [Xen-devel] Build problems with xen 4.7

On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote: > On Fri, 13 May 2016, Jan Beulich wrote: > > > >>> On 13.05.16 at 15:49, wrote: > > > ... > > > > > > Still an issue - with 4.7.0-rc1. > > > > And I don't recall anyone having contributed a fix/workaround. > >

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

On Tue, May 03, 2016 at 07:58:58AM -0600, Jan Beulich wrote: > >>> On 17.03.16 at 09:03, wrote: > > Since such guests' kernel code runs in ring 1, their memory accesses, > > at the paging layer, are supervisor mode ones, and hence subject to > > SMAP/SMEP checks. Such guests cannot be expected to

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

>>> On 13.05.16 at 17:00, wrote: > On 13/05/16 15:13, Jan Beulich wrote: > On 13.05.16 at 15:33, wrote: >>> +unsigned int l1_page_order; >>> +int rv; >>> >>> /* translate l2 guest va into l2 guest gfn */ >>>

[Xen-devel] [TESTDAY] Test report

* Hardware: Intel(R) Xeon(R) CPU E5-2430 * Sofware: Debian Jessie dom0 * Functionality tested: xl save/resume vm_event/mem_access/monitor/altp2m Comment: everything works as expected. Cheers, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org

[Xen-devel] [PATCH] mm, frontswap: convert frontswap_enabled to static key

I have noticed that frontswap.h first declares "frontswap_enabled" as extern bool variable, and then overrides it with "#define frontswap_enabled (1)" for CONFIG_FRONTSWAP=Y or (0) when disabled. The bool variable isn't actually instantiated anywhere. This all looks like an unfinished attempt to

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

>>> On 13.05.16 at 16:50, wrote: > On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote: > On 12.05.16 at 17:25, wrote: >>> +if ( !rc ) >>> +mem_sharing_share_pages(d, bulk->start, sh, cd, >>>

Re: [Xen-devel] [TESTDAY] Test report - xl sched-rtds

On Fri, May 13, 2016 at 5:31 AM, Wei Liu wrote: > On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote: >> * Hardware: >> CPU: Intel Core2 Quad Q9400 >> Total Memory: 2791088 kB >> >> * Software: >> Ubuntu 14.04 >> Linux kernel: 3.13.0-68 >> >> * Guest operating systems:

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

On 13/05/16 15:13, Jan Beulich wrote: On 13.05.16 at 15:33, wrote: >> --- a/xen/arch/x86/mm/hap/nested_hap.c >> +++ b/xen/arch/x86/mm/hap/nested_hap.c >> @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m, >> * walk is successful, the

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote: On 12.05.16 at 17:25, wrote: >> --- a/xen/arch/x86/mm/mem_sharing.c >> +++ b/xen/arch/x86/mm/mem_sharing.c >> @@ -1294,6 +1294,43 @@ int relinquish_shared_pages(struct domain *d) >> return rc;

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

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

Re: [Xen-devel] Build problems with xen 4.7

On Fri, 13 May 2016, Jan Beulich wrote: > >>> On 13.05.16 at 15:49, wrote: > > ... > > > > Still an issue - with 4.7.0-rc1. > > And I don't recall anyone having contributed a fix/workaround. > > > If I do: > > > > $export CFLAGS=" "' > > $make > > > > I end up with:

Re: [Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

>>> On 13.05.16 at 15:33, wrote: > --- a/xen/arch/x86/mm/hap/nested_hap.c > +++ b/xen/arch/x86/mm/hap/nested_hap.c > @@ -141,7 +141,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct p2m_domain *p2m, > * walk is successful, the translated value is returned in > * L1_gpa.

Re: [Xen-devel] Build problems with xen 4.7

>>> On 13.05.16 at 15:49, wrote: > On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote: >> On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote: >> > >>> On 01.12.15 at 15:36, wrote: >> > > On December 1, 2015 8:19:32 AM

Re: [Xen-devel] Build problems with xen 4.7

On Tue, Dec 01, 2015 at 10:59:41AM -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 01, 2015 at 08:56:03AM -0700, Jan Beulich wrote: > > >>> On 01.12.15 at 15:36, wrote: > > > On December 1, 2015 8:19:32 AM EST, Jan Beulich wrote: > > > On 01.12.15

Re: [Xen-devel] Stubdom compilation failure on Fedora 24 beta

Hi Marek On Fri, May 13, 2016 at 02:35:21PM +0200, Marek Marczykowski-Górecki wrote: > Hi, > > I'm trying to build Xen 4.6.1 on Fedora 24 beta. Since gcc 6, I need to pull > some patches from unstable, but then I hit some strange problem: > > During configure run in stubdom/gmp-x86_64 I've got:

[Xen-devel] [PATCH for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker

hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a general L1 p2m walk. It is fine for AMD as NPT share the same format as normal pagetables. For Intel EPT however, it is wrong. The translation ends up correct (as the formats are sufficiently similar), but the control

[Xen-devel] Stubdom compilation failure on Fedora 24 beta

Hi, I'm trying to build Xen 4.6.1 on Fedora 24 beta. Since gcc 6, I need to pull some patches from unstable, but then I hit some strange problem: During configure run in stubdom/gmp-x86_64 I've got: checking size of unsigned short... configure: error: cannot compute sizeof (unsigned short)

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

> > > >This is what I've been remembering: > > > > > > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84c340ba4c3eb9 > > > 927 > > > > 8b6ba885616bb183b88ad67 > > > > > > The comment on this link describes exactly what I am experiencing. > > > Thanks so much. > > > > Thanks Jan for

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

> -Original Message- > From: Wu, Feng [mailto:feng...@intel.com] > Sent: Friday, May 13, 2016 3:11 AM > To: Zytaruk, Kelly; Jan Beulich > Cc: Tian, Kevin; xen-devel@lists.xen.org; Wu, Feng > Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not > executed\n") > > >

Re: [Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

>>> On 12.05.16 at 17:25, wrote: > --- a/xen/arch/x86/mm/mem_sharing.c > +++ b/xen/arch/x86/mm/mem_sharing.c > @@ -1294,6 +1294,43 @@ int relinquish_shared_pages(struct domain *d) > return rc; > } > > +static int bulk_share(struct domain *d, struct domain *cd,

Re: [Xen-devel] [PATCH V9] vm_event: Allow subscribing to write events for specific MSR-s

>>> On 06.05.16 at 16:33, wrote: > Previously, subscribing to MSR write events was an all-or-none > approach, with special cases for introspection MSR-s. This patch > allows the vm_event consumer to specify exactly what MSR-s it is > interested in, and as a side-effect

Re: [Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow

>>> On 13.05.16 at 12:55, wrote: > Am 18.04.2016 um 15:31 schrieb Xen.org security team: >> +/* >> + * Bit 24 of a 24-bit flag mask! This is not any bit of a real pte, >> + * and is only used for signalling in variables that contain flags. >> + */ >> +#define

Re: [Xen-devel] [PATCH net-next v4 2/4] xen-netback: add control protocol implementation

On Fri, May 13, 2016 at 09:37:27AM +0100, Paul Durrant wrote: > My recent patch to include/xen/interface/io/netif.h defines a new shared > ring (in addition to the rx and tx rings) for passing control messages > from a VM frontend driver to a backend driver. > > A previous patch added the

Re: [Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow

Hi, Am 18.04.2016 um 15:31 schrieb Xen.org security team: > Xen Security Advisory CVE-2016-3960 / XSA-173 > version 3 > > x86 shadow pagetables: address width overflow ... > ISSUE DESCRIPTION > = > In the x86 shadow

Re: [Xen-devel] [xen-4.6-testing test] 94059: regressions - FAIL

On Fri, May 13, 2016 at 04:52:43AM -0600, Jan Beulich wrote: > >>> On 13.05.16 at 12:41, wrote: > > On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote: > >> flight 94059 xen-4.6-testing real [real] > >>

Re: [Xen-devel] [xen-4.6-testing test] 94059: regressions - FAIL

>>> On 13.05.16 at 12:41, wrote: > On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote: >> flight 94059 xen-4.6-testing real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/94059/ >> >> Regressions :-( >> >> Tests which did not succeed and are

Re: [Xen-devel] [xen-4.6-testing test] 94059: regressions - FAIL

>>> On 13.05.16 at 12:33, wrote: > flight 94059 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/94059/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

[Xen-devel] [qemu-upstream-4.3-testing test] 94063: trouble: blocked/broken

flight 94063 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94063/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 3 host-install(3) broken

Re: [Xen-devel] [xen-4.6-testing test] 94059: regressions - FAIL

On Fri, May 13, 2016 at 10:33:08AM +, osstest service owner wrote: > flight 94059 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/94059/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

[Xen-devel] [xen-4.6-testing test] 94059: regressions - FAIL

flight 94059 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94059/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 93932

Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

On Thu, May 12, 2016 at 05:48:13PM +0200, Olaf Hering wrote: > Migrating a HVM guest from staging-4.4 to staging-4.5 fails: > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log > char device redirected to /dev/pts/4 (label serial0) > xen_ram_alloc: do not alloc f80 bytes of ram

Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

On Thu, 12 May 2016, Olaf Hering wrote: > On Thu, May 12, Olaf Hering wrote: > > > One thing to fix it in staging-4.5 is to introduce a dummy device which > > handles a section named "kvm-tpr-opt". I already have a hack which does > > that, and the migration proceeds. I will propose a patch to

[Xen-devel] 2nd opinion on backportability of c35eefded2

Hi George, after quite a bit of debugging on 4.6.1 I learned that said commit ("x86/P2M: consolidate handling of types not requiring a valid MFN") is more than just cleanup: Since p2m_set_entry() happily performs arithmetic on the passed in MFN, shadow mode guests (verified) as well as HAP ones

Re: [Xen-devel] [TESTDAY] Test report - xl sched-rtds

On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote: > * Hardware: > CPU: Intel Core2 Quad Q9400 > Total Memory: 2791088 kB > > * Software: > Ubuntu 14.04 > Linux kernel: 3.13.0-68 > > * Guest operating systems: > Ubuntu 14.04 (PV) > > * Functionality tested: > xl sched-rtds (for set/get

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

On 13/05/16 09:55, Jan Beulich wrote: On 13.05.16 at 09:43, wrote: >> On 13/05/2016 07:48, Jan Beulich wrote: >> On 13.05.16 at 08:26, wrote: On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote: On 12.05.16 at

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

On May 13, 2016 5:09 PM, Jan Beulich wrote: > >>> On 13.05.16 at 10:04, wrote: > > On May 12, 2016 11:06 PM, Jan Beulich wrote: > >> >>> On 12.05.16 at 16:28, wrote: > >> > On May 10, 2016 2:54 PM, Jan Beulich

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

>>> On 13.05.16 at 10:04, wrote: > On May 12, 2016 11:06 PM, Jan Beulich wrote: >> >>> On 12.05.16 at 16:28, wrote: >> > On May 10, 2016 2:54 PM, Jan Beulich wrote: >> >> >>> On 10.05.16 at 05:41,

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

>>> On 13.05.16 at 09:43, wrote: > On 13/05/2016 07:48, Jan Beulich wrote: > On 13.05.16 at 08:26, wrote: >>> On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote: >>> On 12.05.16 at 11:40, wrote: >

[Xen-devel] [PATCH net-next v4 0/4] xen-netback: support for control ring

My recent patch to import an up-to-date include/xen/interface/io/netif.h from the Xen Project brought in the necessary definitions to support the new control shared ring and protocol. This patch series updates xen-netback to support the new ring. Patch #1 adds the necessary boilerplate to map the

[Xen-devel] [PATCH net-next v4 1/4] xen-netback: add control ring boilerplate

My recent patch to include/xen/interface/io/netif.h defines a new shared ring (in addition to the rx and tx rings) for passing control messages from a VM frontend driver to a backend driver. This patch adds the necessary code to xen-netback to map this new shared ring, should it be created by a

[Xen-devel] [PATCH net-next v4 2/4] xen-netback: add control protocol implementation

My recent patch to include/xen/interface/io/netif.h defines a new shared ring (in addition to the rx and tx rings) for passing control messages from a VM frontend driver to a backend driver. A previous patch added the necessary boilerplate for mapping the control ring from the frontend, should it

[Xen-devel] [PATCH net-next v4 3/4] xen-netback: pass hash value to the frontend

My recent patch to include/xen/interface/io/netif.h defines a new extra info type that can be used to pass hash values between backend and guest frontend. This patch adds code to xen-netback to pass hash values calculated for guest receive-side packets (i.e. netback transmit side) to the

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

flight 94056 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/94056/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 94035 REGR. vs. 92982 Tests which are

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

On May 12, 2016 11:06 PM, Jan Beulich wrote: > >>> On 12.05.16 at 16:28, wrote: > > On May 10, 2016 2:54 PM, Jan Beulich wrote: > >> >>> On 10.05.16 at 05:41, wrote: > >> > On May 10, 2016 12:14 AM, Jan Beulich

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

On 13/05/2016 07:48, Jan Beulich wrote: On 13.05.16 at 08:26, wrote: >> On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote: >> On 12.05.16 at 11:40, wrote: We plan to bring new PQoS feature called Intel L2 Cache Allocation

Re: [Xen-devel] [PATCH] xen: sched: rtds: refactor code

On Thu, 2016-05-12 at 23:34 -0400, Meng Xu wrote: > On Wed, May 11, 2016 at 11:20 AM, Tianyang Chen > wrote: > > > > No functional change: > >  -Various coding style fix > >  -Added comments for UPDATE_LIMIT_SHIFT. > > Hey, Tianyang, thanks for this. > > Use non-atomic

Re: [Xen-devel] [PATCH v5 0/3] usb, xen: add pvUSB backend

On Do, 2016-05-12 at 16:13 +0200, Juergen Gross wrote: > This series adds a Xen pvUSB backend driver to qemu. USB devices > connected to the host can be passed through to a Xen guest. The > devices are specified via Xenstore. Access to the devices is done > via host-libusb.c > > I've tested the

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

> -Original Message- > From: Zytaruk, Kelly [mailto:kelly.zyta...@amd.com] > Sent: Thursday, May 12, 2016 10:21 PM > To: Jan Beulich > Cc: Wu, Feng ; Tian, Kevin ; xen- > de...@lists.xen.org > Subject: RE: [Xen-devel]

[Xen-devel] [distros-debian-jessie test] 44412: trouble: blocked/broken

flight 44412 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44412/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 4 capture-logs !broken

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

>>> On 13.05.16 at 08:26, wrote: > On Thu, May 12, 2016 at 04:05:36AM -0600, Jan Beulich wrote: >> >>> On 12.05.16 at 11:40, wrote: >> > We plan to bring new PQoS feature called Intel L2 Cache Allocation >> > Technology (L2 CAT) to Xen. >> > >>

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

flight 94055 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94055/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 93989

  1   2   >